ОС Data ONTAP 8.3 cDOT это один из наибольших релизов NetApp. Одной из ключевых особенностей релиза является технология Advanced Drive Partitioning (ADP). Более подробно о том что нового в cDOT 8.3 здесь.
Технология ADP имеет два основных применения:
В этой статье речь пойдёт про 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 и разобьет диски на две партиции. Нигде вас об этом не спросят и не предупредят.
Наличие минимум 4-х дисков на один контроллер (минимум 8 для двух контроллеров).
Если вам приехала новая система с 8.3 или новее, там уже есть Root-Data Partitioning, расслабитесь, делать ничего не нужно.
Если вы хотите использовать Root-Data Partitioning на вашей существующей системе, то необходимо перевести её в cDOT (7-Mode не поддерживает 8.3 и ADP) и все диски необходимо будет отформатировать (все данные будут уничтожены! Другого пути включить Root-Data Partitioning нет).
Это зависит от числа дисков в системе, их типа и от количества контроллеров (1 или 2). Как правило необходимо иметь минимум 4ре диска на каждый контроллер. Размер партиции подбирается так, чтобы в результате получить достаточное количество полезного пространства для root вольюма, который будет занимать всё пространство на root-агрегате, состоящий из root-партиций. Все возможные комбинации заранее просчитаны и вшиты в систему, это не настраивается. Более точную информацию по всем возможным комбинациям можно посмотреть на сайте hwu.netapp.com, в разделе Advanced Drive Partitioning.
Здесь я приведу пару примеров:
Что мы выигрываем с Root-Data Partitioning и какие преимущества у этой технологии?
При добавлении новых дисков у нас есть несколько вариантов:
Давайте сравним в каких случаях есть смысл использовать Active-Passive, а в каких стоит использовать Active-Active. Если у вас система из 24 или меньше дисков, разделять их между контроллерами практически не имеет смысла только из соображений некоего дополнительного перформенса, который теоретически могбы быть выше благодаря тому, что данные будут обслуживаться сразу двумя контроллерами. Дело в том что каждый контроллер FAS2XXX рассчитан на то чтобы смочь обслужить 144 диска (даже в случае когда партнёр умирает). Нужно понимать что как правило пропускная способность системы упирается не в контроллер, а в дисковую подсистему на бэк-энде. Таким образом в конфигурациях с 24 дисками и меньше, как правило никакого дополнительного перфоменса получить не получится, если просто использовать два контроллера вместо одного.
В Active-Active конфигурации вы только потеряете 3 лишних диска (2 парити + 1 Spare), которые могли бы вам дать больший перформенс на бекенде и большую ёмкость.
Резюме. Для систем FAS2XXX c меньше чем 24 дисками, за частую имеет смысл делать Active-Passive конфигурации, так как перфоменс фронт-энда и отказоустойчивость не ухудшается, улучшается перфоменс на бэкенде дисковой подсистемы и увеличивается полезное пространство. Для всех остальных случаев используйте Active-Active конфигурации.
После завершения инициализации и начальной настройки системы она будет в 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>)
Пример:
Здесь P1 это data-партиция диска 0a.10.14, партицией ещё владеет контроллер sys1 (с него же выполняется команда), партиция будет переназначена контроллеру-соседу sys2, (Serial Number у которого 536880408), вместо флага -s можно использовать -o <имя-соседа>.
Root-Data Partitioning технология которая скрыта под капотом системы, администраторы могут даже не догадываться о схеме её работы. Если использовать систему «как-есть», нет никаких сложностей с её обслуживанием, можно сказать, это «вещь в себе», которая просто есть и просто работает, в процессе эксплуатации не вызывает никаких проблем. В целом технология улучшает соотношение полезного пространства к сырому, а также косвенно повышает производительность бэкенда (особенно, когда речь про AFF, ведь каждый сэкономленный SSD диск может добавить тысячи IOPS, а их мы можем сэкономить до 6 шт благодаря Root-Data Partitioning). Если знать тонкости Root-Data Partitioning, то можно на этапе инсталляции ещё больше выиграть в полезном пространстве, не уступив отказоустойчивости и производительности.
FAQ по работе ADP доступен на Fieldportal.
Сообщения по ошибкам в тексте прошу направлять в ЛС.
Замечания, дополнения и вопросы по статье напротив, прошу в комментарии.
Технология 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 нет).
- Запускаем оба контроллера, заходим на обоих в мейтетененс мод (из бут меню)
- На обоих убиваем все старые агрегаты (все данные будут уничтожены! По другому Root-Data Partitioning не включить)
- Удаляем овнершип со всех дисков командой disk removeownership, ребутаемся. Это важно для Root-Data Partitioning!
- Заходим в бут меню, пишем wipeconfig (вместо цифр), подтверждаем, ожидаем, система ребутнётся два раза
- (для конвертации с 7-Mode в cDOT перегружаемся и входим в лоадер, меняем в лоадере параметр загрузки, чтобы система грузила cDOT)
- Входим в бут меню снова, выбираем пункт 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 для работы обоих контроллеров, но при этом иметь один большой агрегат живущий на одном контроллере.
Апгрейд и добавление новых дисков:
При добавлении новых дисков у нас есть несколько вариантов:
- Самый простой это создать новый агрегат и не добавлять новые диски в существующие Data агрегаты, которые живут на Data-партициях.
- Второй вариант добавить новые диски в существующую рейд-группу существующего Data-агрегата, который живёт на Data-партиции. В таком случае новые диски усекутся до размера Data-партиций и будут добавлены в эту рейд-группу. Так как размер рейд-группы не бесконечен расширить её можно вплоть до 28/20 дисков (SAS/SSD 26+2, SATA/NL-SAS 18+2). И если достигнут максимум, нужно перейти к третьему варианту.
- Третий вариант, когда мы добавляем диски в новую рейд-группу в существующий агрегат, состоящий изначально из рейд-группы, которая использует Data-партиции. В таком случае мы получим первую группу немного короче чем вторую, но это не проблема, так как в последних версиях ONTAP специально для этой цели оптимизировали механизм работы рейд груп, теперь допускается иметь достаточно большую разбежность рейдгрупп в одном агрегате.
- При конвертации 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, партицией ещё владеет контроллер sys1 (с него же выполняется команда), партиция будет переназначена контроллеру-соседу sys2, (Serial Number у которого 536880408), вместо флага -s можно использовать -o <имя-соседа>.
Выводы:
Root-Data Partitioning технология которая скрыта под капотом системы, администраторы могут даже не догадываться о схеме её работы. Если использовать систему «как-есть», нет никаких сложностей с её обслуживанием, можно сказать, это «вещь в себе», которая просто есть и просто работает, в процессе эксплуатации не вызывает никаких проблем. В целом технология улучшает соотношение полезного пространства к сырому, а также косвенно повышает производительность бэкенда (особенно, когда речь про AFF, ведь каждый сэкономленный SSD диск может добавить тысячи IOPS, а их мы можем сэкономить до 6 шт благодаря Root-Data Partitioning). Если знать тонкости Root-Data Partitioning, то можно на этапе инсталляции ещё больше выиграть в полезном пространстве, не уступив отказоустойчивости и производительности.
FAQ по работе ADP доступен на Fieldportal.
Сообщения по ошибкам в тексте прошу направлять в ЛС.
Замечания, дополнения и вопросы по статье напротив, прошу в комментарии.
Комментарии (11)
pcmaniac
03.11.2015 18:04+1Интересно как такое разбиение повлияет на производительность. Есть какая-то статистика по нагрузке на системный раздел? Не будет так, что все диски, пригруженные нагрузкой ОСи самих контроллеров, будут медленней обрабатывать запросы от клиентов? Ведь для WAFL имеет место практически линейная запись, т.е. почти все запросы на запись от клиентов упираются в линейную скорость записи дисков, а если в эти линейные операции будут вмешиться периодические бегания головки в начало диска, не убьёт ли это изначальную идею на корню?
bbk
03.11.2015 19:05Я бы предположил, что диски нагруженные от хостов могут влиять на root-агрегаты, но не наоборот.
Именно по-этому у нас Root-Data partitioning есть только
- на FAS2240/25XX истемах, предполагая что на этих системах на столько большой нагрузки не будет, чтобы вызвать это негативное влияние.
- на AFF, где исспользуются высокоскоросные SSD, чтобы опять таки не вызвать негативного влияния.
Сама cDOT читает конфиги с root-агрегатов и пишет логи, в общем она генерирует совсем не много дисковых операций.
Статистики к сожалению нет. Но есть множество систем работающих в продакшн в которых отрицательного влияния одно на другое незамечено.pcmaniac
03.11.2015 19:53+1Интересно. Есть желание тестануть это на 2240-2, осталось придумать как пересыпать стор, не отстрелив себе головы :)
Жаль что нельзя на горячую переконфигурить.bbk
03.11.2015 21:36Общий алгоритм следующий:
Обратитесь к вашему дистрибьютору, попросите дать оборудование из демо-фонда на подмену, запишитесь в очередь заранее.
Спланируйте переезд с начала года до весны, когда спрос на демо оборудование минимальный.
Или договоритесь о миграции с авторизированным интегратором за деньги.
Контакты дистрибьютора/интегратора может подсказать локальный офис NetApp.
blind_oracle
Феноменально! 2015 год на дворе!
Я таким методом ОС на Linux-сервера уже лет 10 ставлю — небольшие разделы под OS + оставшееся место под данные.
Плюс почти все NASы SOHO сегмента так же себя ведут, насколько я знаю.
navion
Крупным заказчикам важнее доступность, поэтому никто сильно не жаловался на расход дисков под систему и появление ADP прошло незамеченным, а мелкие [были] не очень интересны NetApp.
Статью написали по моей просьбе, за что ещё раз огромное спасибо bbk.
bbk
Я скажу больше, если бы не архитектурная необходимость в наличии root-агрегатов в cDOT, Root-Data партишиненга вообще не было бы.
В мире админов хостов это действительно может показаться странным. Но в мире администраторов СХД это вполне естесственно и понятно.
Потомучто это два близких, но совершенно разных мира.
Вот кпримеру админы Linux могут запустить команду удаления системных файлов, обладая root правами, и вообще в этом мире действует идеология: «больше функционала», «нет ограничений у суперпользователя», «всё и сразу», «если админ делает глупости, это его проблемы».
В мире же СХД действует совсем другая идеология: максимум отказоустойчивости, безопасности и производительности, админ не может делать всё если это противоречит первым трем утверждениям. Многие веши заблокированы для админа СХД, ему не дают права «делать всё» и стараются максимум оградить от ошибок.
В мире СХД очень важно чтобы партиционирование не повлияло на производительность и безопасность, и вписалось во все уровни обеспечения отказоустойчивости СХД, по-этому партиционирование только сейчас помошло на помошь системным разделам.
bbk
А по поводу SOHO, я вам скажу так:
Это абсолютно разные продукты для разных целевых аудиторий, финансовых возможностей, требований к отказоустойчивости, масштабированию, производительности и её предсказуемости.
Соответственно функционал совершенно разный.
blind_oracle
Товарищи, причём тут это всё? Сравнение Linux/СХД и тому подобного.
Мы разговариваем об архитектуре -, а такая архитектура (ОС размазана, а не на отдельных дисках) — она наиболее рациональна, особенно в случае entry-level СХД с небольшим количеством дисков в полке. И то, что к ней в итоге пришли — говорит в пользу этого утверждения.
Меня удивляет именно то, что в таких достаточно дорогих игрушках как СХД не реализовали этого с самого начала.
navion
Зависит от архитектуры самой СХД.
Я с ужасом вспоминаю пляски с бубном вокруг сервера HP, когда вылетел диск в смешанном массиве. А при активном доступе к системному разделу меняется профиль нагрузки у всего массива, так как головка ездит туда-сюда.
bbk
Такие дорогие игрушки расчитаны на сотни и тысячи жестких дисков.
Да, я согласен что появление партишенинга говорит о том, что он всё-же востребован, именно востребован миром Enterprise потребителей, а не тем, «что это даже есть в SOHO». Я бы даже сказал похожая технология нашла своё применение и в ентерпрайз, но это не значит что она там была обязана быть просто, «чтобы было». На всё есть свои причины.