Data ONTAP 8.3 ADP: Root-Data Partitioning

    ОС Data ONTAP 8.3 cDOT это один из наибольших релизов NetApp. Одной из ключевых особенностей релиза является технология Advanced Drive Partitioning (ADP). Более подробно о том что нового в cDOT 8.3 здесь.

    Технология ADP имеет два основных применения:
    • Root-Data Partitioning
    • FlashPool Partitioning (Storage Pools)

    В этой статье речь пойдёт про Root-Data Partitioning.


    Root-Data Partitioning


    Root-Data Partitioning применяется для того, чтобы каждый диск разбить на две партиции, одна большая (обычно первая, назовём её data-партиция) и другая намного меньшая по размеру (обычно вторая, назовём её root-партиция). Дальше каждая партиция рассматривается как отдельный диск и может иметь независимо первая от второй своего владельца (контроллер). На маленьких партициях создаются root aggregates для обоих контроллеров, а на больших создаются Data Aggregates. Это позволяет вместо выделенных дисков использовать только маленькую партицию под root aggregate. Важно отметить что эта технология доступна на FAS22XX / FAS25XX и AFF8XXXX системах. Root-Data Partitioning включается только на дисках которые находятся в первой полке подключённой к системе (для FAS2XXX диски из первой полки считаются те, которые находятся в том же шасси что и контроллеры). Каждая партиция «работает» как отдельный диск, имеет своё имя и с командами, которые классически работают с дисками мы будем подставлять эти имена «виртуальных» дисков.

    На FAS8XXX по-прежнему необходимо иметь выделенные диски под root aggregates. Почему, спросите вы? Потому что FAS8000 архитектурно спроектированы для очень большого количества дисков и на этом фоне 4-6 дисков не играют роли. Для маленьких же систем эти 4-6 дисков могут сэкономить существенное количество пространства, то же касается дорогих AFF систем, где очень не рационально тратить дорогостоящие и высокопроизводительные диски под системные нужды.

    Root-Data Partitioning это технология, которая никак не настраивается и не выключается. Она есть на всех новых системах которые идут с 8.3. Если старую систему (FAS22XX / FAS25XX и AFF8XXXX) обновить до 8.3 и заново пере-форматировать, то она автоматически включает Root-Data Partitioning и разобьет диски на две партиции. Нигде вас об этом не спросят и не предупредят.

    Для работы Root-Data Partitioning нужно:



    Наличие минимум 4-х дисков на один контроллер (минимум 8 для двух контроллеров).

    Если вам приехала новая система с 8.3 или новее, там уже есть Root-Data Partitioning, расслабитесь, делать ничего не нужно.

    Если вы хотите использовать Root-Data Partitioning на вашей существующей системе, то необходимо перевести её в cDOT (7-Mode не поддерживает 8.3 и ADP) и все диски необходимо будет отформатировать (все данные будут уничтожены! Другого пути включить Root-Data Partitioning нет).

    1. Запускаем оба контроллера, заходим на обоих в мейтетененс мод (из бут меню)
    2. На обоих убиваем все старые агрегаты (все данные будут уничтожены! По другому Root-Data Partitioning не включить)
    3. Удаляем овнершип со всех дисков командой disk removeownership, ребутаемся. Это важно для Root-Data Partitioning!
    4. Заходим в бут меню, пишем wipeconfig (вместо цифр), подтверждаем, ожидаем, система ребутнётся два раза
    5. (для конвертации с 7-Mode в cDOT перегружаемся и входим в лоадер, меняем в лоадере параметр загрузки, чтобы система грузила cDOT)
    6. Входим в бут меню снова, выбираем пункт 4 (initialize all disks) на каждом контроллере и ожидаем окончания disk zerroring.


    Какой размер каждой партиции?


    Это зависит от числа дисков в системе, их типа и от количества контроллеров (1 или 2). Как правило необходимо иметь минимум 4ре диска на каждый контроллер. Размер партиции подбирается так, чтобы в результате получить достаточное количество полезного пространства для root вольюма, который будет занимать всё пространство на root-агрегате, состоящий из root-партиций. Все возможные комбинации заранее просчитаны и вшиты в систему, это не настраивается. Более точную информацию по всем возможным комбинациям можно посмотреть на сайте hwu.netapp.com, в разделе Advanced Drive Partitioning.


    Здесь я приведу пару примеров:
    FAS2240-2 / FAS2552
    • Если система будет иметь два контроллера и 8 дисков, размер root-партиции будет 110.82 GiB. Итак в этой конфигурации мы получим по 4 root-партиции на контроллер, по одному root-агрегату на контроллер. Каждый агрегат будет состоять из 2 партиций под данные и 2 партиций парити, без спар партиций. Размер каждого root-агрегата будет 2*110.82
    • Если на той же системе будет 12 дисков, то root-партиция будет занимать 73.89 GiB. А каждый root-агрегат будет состоять из следующей комбинации партиций: 3 данные + 2 парити +1 Spare. Размер каждого root-агрегата будет 3*73.89
    • На 24 дисках будем иметь 27.72 GiB root-партицию и комбинацию партиций под root-аргегаты: 8 данные + 2 парити +2 Spare. Размер каждого root-агрегата будет 8*27.72


    FAS2240-4 / FAS2554
    • Для HA cистем FAS2240-4 и FAS2554 и 8 дисков, root-партиция 215.47GiB, каждый агрегат будет состоять из: 2 данные +2 парити, без спар партиции. Размер каждого root-агрегата будет 2*215.47
    • Если на той же системе будет 12 дисков, то root-партиция будет занимать 143.65 GiB, каждый агрегат будет состоять из: 3 данные +2 парити, 1 спар партиция. Размер каждого root-агрегата будет 3*143.65
    • На 24 дисках партиция будет 53.88GiB, каждый агрегат 8 дата, 2 парити, 2 Spare. Размер каждого root-агрегата будет 8*53.88



    Полезное пространство


    Что мы выигрываем с Root-Data Partitioning и какие преимущества у этой технологии?
    • Во-первых, мы выигрываем 4-6 дисков которые могут быть добавлены в data-агрегат, пускай даже каждый из них будет немного «короче».
    • Во-вторых, мы «снимаем» перфоменс с этих дополнительных 4-6 Дисков. так как Root агрегат мало нагружен.
    • В третьих, мы можем иметь Active-Passive конфигурации, использовать Root-Partitioning для работы обоих контроллеров, но при этом иметь один большой агрегат живущий на одном контроллере.



    Апгрейд и добавление новых дисков:


    При добавлении новых дисков у нас есть несколько вариантов:
    1. Самый простой это создать новый агрегат и не добавлять новые диски в существующие Data агрегаты, которые живут на Data-партициях.
    2. Второй вариант добавить новые диски в существующую рейд-группу существующего Data-агрегата, который живёт на Data-партиции. В таком случае новые диски усекутся до размера Data-партиций и будут добавлены в эту рейд-группу. Так как размер рейд-группы не бесконечен расширить её можно вплоть до 28/20 дисков (SAS/SSD 26+2, SATA/NL-SAS 18+2). И если достигнут максимум, нужно перейти к третьему варианту.
    3. Третий вариант, когда мы добавляем диски в новую рейд-группу в существующий агрегат, состоящий изначально из рейд-группы, которая использует Data-партиции. В таком случае мы получим первую группу немного короче чем вторую, но это не проблема, так как в последних версиях ONTAP специально для этой цели оптимизировали механизм работы рейд груп, теперь допускается иметь достаточно большую разбежность рейдгрупп в одном агрегате.
    4. Когда вам приезжает ещё одна полка, вы можете создать на этой полке новый агрегат, в онлайне мигрировать вольюмы с одного из старых агрегатов построенных на укороченных дисках. После этого поменять у высвобожденных укороченных дисков овнершип на овнершип соседа. Далее добавить высвобожденные укороченные диски вагрегат к таким же укороченным дискам. Таким образом обойдя третий вариант.
    5. При конвертации FAS2240/FAS2552/FAS2554 в полку и подключении их к старшим системам, например к FAS8020 Root-Data Partitioning будет работать. Это единственный способ заставить FAS8XXX работать с Root-Data Partitioning.



    Недостатки


    • В случае выхода из строя одного или нескольких дисков, мы можем получить деградированный root и data агрегаты сразу одновременно. Выход root-агрегата не так страшен потому что он защищен HA парой, и в случае если контроллер с повреждённым root-агрегатом не сможет обслуживать свои диски, это сделает HA партнёр. В случае работы системы без Root-Data Partitioning можно было бы избежать переключение агрегатов на соседа.
    • Усечение дисков приводит к тому, что часть диска не используется.


    Active-Pasive vs Active-Active


    Давайте сравним в каких случаях есть смысл использовать Active-Passive, а в каких стоит использовать Active-Active. Если у вас система из 24 или меньше дисков, разделять их между контроллерами практически не имеет смысла только из соображений некоего дополнительного перформенса, который теоретически могбы быть выше благодаря тому, что данные будут обслуживаться сразу двумя контроллерами. Дело в том что каждый контроллер FAS2XXX рассчитан на то чтобы смочь обслужить 144 диска (даже в случае когда партнёр умирает). Нужно понимать что как правило пропускная способность системы упирается не в контроллер, а в дисковую подсистему на бэк-энде. Таким образом в конфигурациях с 24 дисками и меньше, как правило никакого дополнительного перфоменса получить не получится, если просто использовать два контроллера вместо одного.

    В Active-Active конфигурации вы только потеряете 3 лишних диска (2 парити + 1 Spare), которые могли бы вам дать больший перформенс на бекенде и большую ёмкость.


    Резюме. Для систем FAS2XXX c меньше чем 24 дисками, за частую имеет смысл делать Active-Passive конфигурации, так как перфоменс фронт-энда и отказоустойчивость не ухудшается, улучшается перфоменс на бэкенде дисковой подсистемы и увеличивается полезное пространство. Для всех остальных случаев используйте Active-Active конфигурации.

    Как настроить Active-Passive

    После завершения инициализации и начальной настройки системы она будет в Active-Active конфигурации по-умолчанию, вам необходимо «отобрать» партиции предназначенные для данных (в конце названия диска есть окончание P1 или P2) у одного контроллера и отдать второму. Если на отбираемых партициях уже есть data-агрегат, вам придётся его удалить, ведь иначе из агрегата диски не забрать. Это делается из 7-Mode shell'a (system node run -node local). Перед изменением удостоверьтесь, какая партиция это root-партиция и какая data-партиция (aggr status <root_aggr> -r). Изменить овнер-шип диска на новый можно из того контроллера, который им владеет (disk assign <disk.name.P1> -s <new-serial-number>). Каждая партиция «работает» как отдельный диск: у неё свой овнершип, который может отличаться от овнершипа физического диска и других партиций на том же физическом диске, изменение овнершипа партиции выполняется при помощи той же команды, что и для изменения овнершипа физического диска.
    Пример:
    sys::> system node run -node local
    sys-01> aggr status rootA -r
    sys-01> disk show 
    sys-01> disk assign 0a.10.14P1 -f -s 536880408
    

    Здесь P1 это data-партиция диска 0a.10.14, партицией ещё владеет контроллер sys-01 (с него же выполняется команда), партиция будет переназначена контроллеру-соседу sys-02, (Serial Number у которого 536880408), вместо флага -s можно использовать -o <имя-соседа>.

    Выводы:


    Root-Data Partitioning технология которая скрыта под капотом системы, администраторы могут даже не догадываться о схеме её работы. Если использовать систему «как-есть», нет никаких сложностей с её обслуживанием, можно сказать, это «вещь в себе», которая просто есть и просто работает, в процессе эксплуатации не вызывает никаких проблем. В целом технология улучшает соотношение полезного пространства к сырому, а также косвенно повышает производительность бэкенда (особенно, когда речь про AFF, ведь каждый сэкономленный SSD диск может добавить тысячи IOPS, а их мы можем сэкономить до 6 шт благодаря Root-Data Partitioning). Если знать тонкости Root-Data Partitioning, то можно на этапе инсталляции ещё больше выиграть в полезном пространстве, не уступив отказоустойчивости и производительности.

    FAQ по работе ADP доступен на Fieldportal.

    Сообщения по ошибкам в тексте прошу направлять в ЛС.
    Замечания, дополнения и вопросы по статье напротив, прошу в комментарии.
    Поделиться публикацией
    Комментарии 18
      0
      Феноменально! 2015 год на дворе!
      Я таким методом ОС на Linux-сервера уже лет 10 ставлю — небольшие разделы под OS + оставшееся место под данные.
      Плюс почти все NASы SOHO сегмента так же себя ведут, насколько я знаю.
        +1
        Крупным заказчикам важнее доступность, поэтому никто сильно не жаловался на расход дисков под систему и появление ADP прошло незамеченным, а мелкие [были] не очень интересны NetApp.
        Статью написали по моей просьбе, за что ещё раз огромное спасибо bbk.
          +1
          Я скажу больше, если бы не архитектурная необходимость в наличии root-агрегатов в cDOT, Root-Data партишиненга вообще не было бы.
          В мире админов хостов это действительно может показаться странным. Но в мире администраторов СХД это вполне естесственно и понятно.
          Потомучто это два близких, но совершенно разных мира.

          Вот кпримеру админы Linux могут запустить команду удаления системных файлов, обладая root правами, и вообще в этом мире действует идеология: «больше функционала», «нет ограничений у суперпользователя», «всё и сразу», «если админ делает глупости, это его проблемы».
          В мире же СХД действует совсем другая идеология: максимум отказоустойчивости, безопасности и производительности, админ не может делать всё если это противоречит первым трем утверждениям. Многие веши заблокированы для админа СХД, ему не дают права «делать всё» и стараются максимум оградить от ошибок.

          В мире СХД очень важно чтобы партиционирование не повлияло на производительность и безопасность, и вписалось во все уровни обеспечения отказоустойчивости СХД, по-этому партиционирование только сейчас помошло на помошь системным разделам.
            0
            А по поводу SOHO, я вам скажу так:

            Это абсолютно разные продукты для разных целевых аудиторий, финансовых возможностей, требований к отказоустойчивости, масштабированию, производительности и её предсказуемости.

            Соответственно функционал совершенно разный.
              0
              Товарищи, причём тут это всё? Сравнение Linux/СХД и тому подобного.

              Мы разговариваем об архитектуре -, а такая архитектура (ОС размазана, а не на отдельных дисках) — она наиболее рациональна, особенно в случае entry-level СХД с небольшим количеством дисков в полке. И то, что к ней в итоге пришли — говорит в пользу этого утверждения.

              Меня удивляет именно то, что в таких достаточно дорогих игрушках как СХД не реализовали этого с самого начала.
                +2
                Зависит от архитектуры самой СХД.
                Я с ужасом вспоминаю пляски с бубном вокруг сервера HP, когда вылетел диск в смешанном массиве. А при активном доступе к системному разделу меняется профиль нагрузки у всего массива, так как головка ездит туда-сюда.
                  +2
                  Такие дорогие игрушки расчитаны на сотни и тысячи жестких дисков.
                  1. И во-первых на фоне такого количества дисков 4-6 дисков совсем ничего не значят.
                  2. Во-вторых возвращаемся к вопросу сосуществования всех уровней отказоустойчивости и стабильной, предсказуемой производительности. А как только дело касается выбора между производительностью с отказоустойчивостью и экономией 4-6 дисков, мы сразу же возвращаемся к п.1.
                  3. И в третьих агрумент «это даже есть в SOHO» для мира ентерпрайз СХД вообще не звучит. Ну вот к примеру в домашнем синолоджи или кюнапе есть встроенный торент клиент, а в ентерпрайз нет. Ну да нет. Ентерпрайз не ориентируется на SOHO. точно тоже самое можно сказать про SOHO, что вот посмотрите в Enterprise есть интеграция с резервным копированием на ленточки, а в SOHO нет.


                  Да, я согласен что появление партишенинга говорит о том, что он всё-же востребован, именно востребован миром Enterprise потребителей, а не тем, «что это даже есть в SOHO». Я бы даже сказал похожая технология нашла своё применение и в ентерпрайз, но это не значит что она там была обязана быть просто, «чтобы было». На всё есть свои причины.
              +1
              Интересно как такое разбиение повлияет на производительность. Есть какая-то статистика по нагрузке на системный раздел? Не будет так, что все диски, пригруженные нагрузкой ОСи самих контроллеров, будут медленней обрабатывать запросы от клиентов? Ведь для WAFL имеет место практически линейная запись, т.е. почти все запросы на запись от клиентов упираются в линейную скорость записи дисков, а если в эти линейные операции будут вмешиться периодические бегания головки в начало диска, не убьёт ли это изначальную идею на корню?
                0
                Я бы предположил, что диски нагруженные от хостов могут влиять на root-агрегаты, но не наоборот.
                Именно по-этому у нас Root-Data partitioning есть только
                • на FAS2240/25XX истемах, предполагая что на этих системах на столько большой нагрузки не будет, чтобы вызвать это негативное влияние.
                • на AFF, где исспользуются высокоскоросные SSD, чтобы опять таки не вызвать негативного влияния.

                Сама cDOT читает конфиги с root-агрегатов и пишет логи, в общем она генерирует совсем не много дисковых операций.
                Статистики к сожалению нет. Но есть множество систем работающих в продакшн в которых отрицательного влияния одно на другое незамечено.
                  +1
                  Интересно. Есть желание тестануть это на 2240-2, осталось придумать как пересыпать стор, не отстрелив себе головы :)
                  Жаль что нельзя на горячую переконфигурить.
                    0
                    Общий алгоритм следующий:
                    Обратитесь к вашему дистрибьютору, попросите дать оборудование из демо-фонда на подмену, запишитесь в очередь заранее.
                    Спланируйте переезд с начала года до весны, когда спрос на демо оборудование минимальный.

                    Или договоритесь о миграции с авторизированным интегратором за деньги.
                    Контакты дистрибьютора/интегратора может подсказать локальный офис NetApp.
                +1
                Спасибо за статью!
                Тема новая и интересная, использовать ее не хочется, но иногда надо:))

                В таком случае мы получим первую группу немного короче чем вторую, но это не проблема, так как в последних версиях ONTAP специально для этой цели оптимизировали механизм работы рейд груп, теперь допускается иметь достаточно большую разбежность рейдгрупп в одном агрегате.

                Честно говоря я не знаю, что там сделали в последних версиях ONTAP на эту тему, но ведь чудес не бывает и разные RAID группы в агрегате обязательно будут приводить к различной производительности «частей» тома. Возможно они научились делать разные по длине страйпы, но производительность все равно будет страдать.
                  0
                  Вы же наверняка не думали, что ADP это просто разбиение дисков на партиции?
                  Это не объединение нескольких разных по геометрии дисков в одну, ведь диски физически то одинаковые, с одинаковой производительностью.
                  В конце концов у вас всегда остаётся вариант создать отдельный агрегат.

                  Давайте рассмотрим конкрентый случай, когда же стоит этот самый вопрос «добавлять ли диски в агрегат к более короткой рейд группе?». Такое может произойти:

                  Если у вас была собрана Active-Active конфигурация т.е. у вас уже есть два агрегата на каждом контроллере из 11 дисков. И логично было бы увеличить длинну каждой рейд-группы, хотябы из тех соображений чтобы получить больше полезного пространства (не тартиться на лишние Parity диски).
                  В таклм случае я бы предложил поступить следующим образом:
                  Когда вам приезжает ещё одна полка, вы можете создать на этой полке новый агрегат, в онлайне мигрировать вольюмы с одного из старых агрегатов построенных на укороченных дисках. После этого поменять у высвобожденных укороченных дисков овнершип на овнершип соседа. После чего добавить высвобожденные укороченные диски вагрегат к таким же дискам.

                  Если же у вас уже есть Active-Passive конфигурация, и вы докупили ещё полку с дисками, добавлять их в тот же агрегат нет смысла из соображений полезного пространства, так как 2 парити диска всё-равно будут потеряны. Другими словами в таком случае вам рационально было бы превратить вашу Active-Passive конфигурацию в Active-Active и получить такое же полезное пространство. Т.е. на первой ноде будем иметь один большой агрегат из всех дисков которые укорочены, а на пасивной ноде собрать агрегат из новых, не укороченных дисков и сделать её активной.

                  А если вы сразу покупали 48 дисков или более, то сразу собираете Active-Active конфигурацию по схеме приведённой выше.

                  Другими словами ситуация с агрегатом, состоящим из двух типов дисков маловероятна
                    +1
                    Я, в общем-то, согласен, я свою мысль вел к тому, что не нужно делать агрегат из 4 RAID групп следующего вида:
                    rg0 — 11disks
                    rg1 — 22disks
                    rg2 — 22disks
                    rg3 — 22disks,
                    так как что бы там не придумал NetApp в последних прошивках, такая конфигурация всегда будет тормозить.
                    Если же делать одну группу чуть меньше емкостью, но при этом сохранить кол-во дисков одинаковым, то это не должно сильно сказываться на производительности до момента полного заполнения емкости агрегата (что и так приведет к огромным проблемам производительности).
                      0
                      NetApp действительно не рекомендовал и не рекомендует иметь разнобой в размере рейд групп в рамках одного агрегата. Но с появлением ADP теперь это допускается. А также с выходом прошивки 8.2 допускается иметь разнобой дисков не более чем в два раза от остальных рейд групп. Другими словами приведённый вами пример теперь допускается исспользовать в продакшн.
                      Я не выполнял нагрузочного тестирования для такой конфигурации и не могу сказать о её влиянии на производительность.
                  +1

                  Спасибо за статью, как раз запустил такую процедуру у себя на FAS2552. Проапгрейдил до 8.3.2, но разбивка дисков осталась старой. Не совсем понятно зачем делать wipeconfig? В документации написано, что после удаления ownership с дисков на всех нодах надо просто по очереди запустить "Clean configuration and initialize all disks." — option 4 из boot menu. По идее там автоматом wipeconfig и делается.

                    0
                    Вайпконфиг чистит хвосты старой конфиги онтапа на флеше.
                    Вообще-то 4 пункт бутменю делает инициалмзацию и Вайпконфиг.

                    Его было обязательно выполнять в более старой версии онтапа после перехода с 7-мода на кластер. У меня как-то давно была ситуация, что кластер не хотел собираться, я долго не мог понять почему и Вайпконфиг мне помог именно ДО того как я конвертировал онтап в кластер мод, ПОТОМ конвертировал в кластер, выполнил 4-й пункт бутменю и все получилось.

                    Теперь я его всегда делаю, выполнить не сложно и совсем не долго, так что я его делаю по старой памяти, чтобы не наступать на старые грабли дважды. Может сейчас уже этого делать и не нужно.
                      +2

                      Вот ещё нашёл описание этой же процедуры для FAS2552. Там с картинками, что происходит с дисками. Тоже может кому полезно будет.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое