Comments 18
Феноменально! 2015 год на дворе!
Я таким методом ОС на Linux-сервера уже лет 10 ставлю — небольшие разделы под OS + оставшееся место под данные.
Плюс почти все NASы SOHO сегмента так же себя ведут, насколько я знаю.
Я таким методом ОС на Linux-сервера уже лет 10 ставлю — небольшие разделы под OS + оставшееся место под данные.
Плюс почти все NASы SOHO сегмента так же себя ведут, насколько я знаю.
Крупным заказчикам важнее доступность, поэтому никто сильно не жаловался на расход дисков под систему и появление ADP прошло незамеченным, а мелкие [были] не очень интересны NetApp.
Статью написали по моей просьбе, за что ещё раз огромное спасибо bbk.
Статью написали по моей просьбе, за что ещё раз огромное спасибо bbk.
Я скажу больше, если бы не архитектурная необходимость в наличии root-агрегатов в cDOT, Root-Data партишиненга вообще не было бы.
В мире админов хостов это действительно может показаться странным. Но в мире администраторов СХД это вполне естесственно и понятно.
Потомучто это два близких, но совершенно разных мира.
Вот кпримеру админы Linux могут запустить команду удаления системных файлов, обладая root правами, и вообще в этом мире действует идеология: «больше функционала», «нет ограничений у суперпользователя», «всё и сразу», «если админ делает глупости, это его проблемы».
В мире же СХД действует совсем другая идеология: максимум отказоустойчивости, безопасности и производительности, админ не может делать всё если это противоречит первым трем утверждениям. Многие веши заблокированы для админа СХД, ему не дают права «делать всё» и стараются максимум оградить от ошибок.
В мире СХД очень важно чтобы партиционирование не повлияло на производительность и безопасность, и вписалось во все уровни обеспечения отказоустойчивости СХД, по-этому партиционирование только сейчас помошло на помошь системным разделам.
В мире админов хостов это действительно может показаться странным. Но в мире администраторов СХД это вполне естесственно и понятно.
Потомучто это два близких, но совершенно разных мира.
Вот кпримеру админы Linux могут запустить команду удаления системных файлов, обладая root правами, и вообще в этом мире действует идеология: «больше функционала», «нет ограничений у суперпользователя», «всё и сразу», «если админ делает глупости, это его проблемы».
В мире же СХД действует совсем другая идеология: максимум отказоустойчивости, безопасности и производительности, админ не может делать всё если это противоречит первым трем утверждениям. Многие веши заблокированы для админа СХД, ему не дают права «делать всё» и стараются максимум оградить от ошибок.
В мире СХД очень важно чтобы партиционирование не повлияло на производительность и безопасность, и вписалось во все уровни обеспечения отказоустойчивости СХД, по-этому партиционирование только сейчас помошло на помошь системным разделам.
А по поводу SOHO, я вам скажу так:
Это абсолютно разные продукты для разных целевых аудиторий, финансовых возможностей, требований к отказоустойчивости, масштабированию, производительности и её предсказуемости.
Соответственно функционал совершенно разный.
Это абсолютно разные продукты для разных целевых аудиторий, финансовых возможностей, требований к отказоустойчивости, масштабированию, производительности и её предсказуемости.
Соответственно функционал совершенно разный.
Товарищи, причём тут это всё? Сравнение Linux/СХД и тому подобного.
Мы разговариваем об архитектуре -, а такая архитектура (ОС размазана, а не на отдельных дисках) — она наиболее рациональна, особенно в случае entry-level СХД с небольшим количеством дисков в полке. И то, что к ней в итоге пришли — говорит в пользу этого утверждения.
Меня удивляет именно то, что в таких достаточно дорогих игрушках как СХД не реализовали этого с самого начала.
Мы разговариваем об архитектуре -, а такая архитектура (ОС размазана, а не на отдельных дисках) — она наиболее рациональна, особенно в случае entry-level СХД с небольшим количеством дисков в полке. И то, что к ней в итоге пришли — говорит в пользу этого утверждения.
Меня удивляет именно то, что в таких достаточно дорогих игрушках как СХД не реализовали этого с самого начала.
Зависит от архитектуры самой СХД.
Я с ужасом вспоминаю пляски с бубном вокруг сервера HP, когда вылетел диск в смешанном массиве. А при активном доступе к системному разделу меняется профиль нагрузки у всего массива, так как головка ездит туда-сюда.
Я с ужасом вспоминаю пляски с бубном вокруг сервера HP, когда вылетел диск в смешанном массиве. А при активном доступе к системному разделу меняется профиль нагрузки у всего массива, так как головка ездит туда-сюда.
Такие дорогие игрушки расчитаны на сотни и тысячи жестких дисков.
Да, я согласен что появление партишенинга говорит о том, что он всё-же востребован, именно востребован миром Enterprise потребителей, а не тем, «что это даже есть в SOHO». Я бы даже сказал похожая технология нашла своё применение и в ентерпрайз, но это не значит что она там была обязана быть просто, «чтобы было». На всё есть свои причины.
- И во-первых на фоне такого количества дисков 4-6 дисков совсем ничего не значят.
- Во-вторых возвращаемся к вопросу сосуществования всех уровней отказоустойчивости и стабильной, предсказуемой производительности. А как только дело касается выбора между производительностью с отказоустойчивостью и экономией 4-6 дисков, мы сразу же возвращаемся к п.1.
- И в третьих агрумент «это даже есть в SOHO» для мира ентерпрайз СХД вообще не звучит. Ну вот к примеру в домашнем синолоджи или кюнапе есть встроенный торент клиент, а в ентерпрайз нет. Ну да нет. Ентерпрайз не ориентируется на SOHO. точно тоже самое можно сказать про SOHO, что вот посмотрите в Enterprise есть интеграция с резервным копированием на ленточки, а в SOHO нет.
Да, я согласен что появление партишенинга говорит о том, что он всё-же востребован, именно востребован миром Enterprise потребителей, а не тем, «что это даже есть в SOHO». Я бы даже сказал похожая технология нашла своё применение и в ентерпрайз, но это не значит что она там была обязана быть просто, «чтобы было». На всё есть свои причины.
Интересно как такое разбиение повлияет на производительность. Есть какая-то статистика по нагрузке на системный раздел? Не будет так, что все диски, пригруженные нагрузкой ОСи самих контроллеров, будут медленней обрабатывать запросы от клиентов? Ведь для WAFL имеет место практически линейная запись, т.е. почти все запросы на запись от клиентов упираются в линейную скорость записи дисков, а если в эти линейные операции будут вмешиться периодические бегания головки в начало диска, не убьёт ли это изначальную идею на корню?
Я бы предположил, что диски нагруженные от хостов могут влиять на root-агрегаты, но не наоборот.
Именно по-этому у нас Root-Data partitioning есть только
Сама cDOT читает конфиги с root-агрегатов и пишет логи, в общем она генерирует совсем не много дисковых операций.
Статистики к сожалению нет. Но есть множество систем работающих в продакшн в которых отрицательного влияния одно на другое незамечено.
Именно по-этому у нас Root-Data partitioning есть только
- на FAS2240/25XX истемах, предполагая что на этих системах на столько большой нагрузки не будет, чтобы вызвать это негативное влияние.
- на AFF, где исспользуются высокоскоросные SSD, чтобы опять таки не вызвать негативного влияния.
Сама cDOT читает конфиги с root-агрегатов и пишет логи, в общем она генерирует совсем не много дисковых операций.
Статистики к сожалению нет. Но есть множество систем работающих в продакшн в которых отрицательного влияния одно на другое незамечено.
Интересно. Есть желание тестануть это на 2240-2, осталось придумать как пересыпать стор, не отстрелив себе головы :)
Жаль что нельзя на горячую переконфигурить.
Жаль что нельзя на горячую переконфигурить.
Общий алгоритм следующий:
Обратитесь к вашему дистрибьютору, попросите дать оборудование из демо-фонда на подмену, запишитесь в очередь заранее.
Спланируйте переезд с начала года до весны, когда спрос на демо оборудование минимальный.
Или договоритесь о миграции с авторизированным интегратором за деньги.
Контакты дистрибьютора/интегратора может подсказать локальный офис NetApp.
Обратитесь к вашему дистрибьютору, попросите дать оборудование из демо-фонда на подмену, запишитесь в очередь заранее.
Спланируйте переезд с начала года до весны, когда спрос на демо оборудование минимальный.
Или договоритесь о миграции с авторизированным интегратором за деньги.
Контакты дистрибьютора/интегратора может подсказать локальный офис NetApp.
Спасибо за статью!
Тема новая и интересная, использовать ее не хочется, но иногда надо:))
Честно говоря я не знаю, что там сделали в последних версиях ONTAP на эту тему, но ведь чудес не бывает и разные RAID группы в агрегате обязательно будут приводить к различной производительности «частей» тома. Возможно они научились делать разные по длине страйпы, но производительность все равно будет страдать.
Тема новая и интересная, использовать ее не хочется, но иногда надо:))
В таком случае мы получим первую группу немного короче чем вторую, но это не проблема, так как в последних версиях ONTAP специально для этой цели оптимизировали механизм работы рейд груп, теперь допускается иметь достаточно большую разбежность рейдгрупп в одном агрегате.
Честно говоря я не знаю, что там сделали в последних версиях ONTAP на эту тему, но ведь чудес не бывает и разные RAID группы в агрегате обязательно будут приводить к различной производительности «частей» тома. Возможно они научились делать разные по длине страйпы, но производительность все равно будет страдать.
Вы же наверняка не думали, что ADP это просто разбиение дисков на партиции?
Это не объединение нескольких разных по геометрии дисков в одну, ведь диски физически то одинаковые, с одинаковой производительностью.
В конце концов у вас всегда остаётся вариант создать отдельный агрегат.
Давайте рассмотрим конкрентый случай, когда же стоит этот самый вопрос «добавлять ли диски в агрегат к более короткой рейд группе?». Такое может произойти:
Если у вас была собрана Active-Active конфигурация т.е. у вас уже есть два агрегата на каждом контроллере из 11 дисков. И логично было бы увеличить длинну каждой рейд-группы, хотябы из тех соображений чтобы получить больше полезного пространства (не тартиться на лишние Parity диски).
В таклм случае я бы предложил поступить следующим образом:
Когда вам приезжает ещё одна полка, вы можете создать на этой полке новый агрегат, в онлайне мигрировать вольюмы с одного из старых агрегатов построенных на укороченных дисках. После этого поменять у высвобожденных укороченных дисков овнершип на овнершип соседа. После чего добавить высвобожденные укороченные диски вагрегат к таким же дискам.
Если же у вас уже есть Active-Passive конфигурация, и вы докупили ещё полку с дисками, добавлять их в тот же агрегат нет смысла из соображений полезного пространства, так как 2 парити диска всё-равно будут потеряны. Другими словами в таком случае вам рационально было бы превратить вашу Active-Passive конфигурацию в Active-Active и получить такое же полезное пространство. Т.е. на первой ноде будем иметь один большой агрегат из всех дисков которые укорочены, а на пасивной ноде собрать агрегат из новых, не укороченных дисков и сделать её активной.
А если вы сразу покупали 48 дисков или более, то сразу собираете Active-Active конфигурацию по схеме приведённой выше.
Другими словами ситуация с агрегатом, состоящим из двух типов дисков маловероятна
Это не объединение нескольких разных по геометрии дисков в одну, ведь диски физически то одинаковые, с одинаковой производительностью.
В конце концов у вас всегда остаётся вариант создать отдельный агрегат.
Давайте рассмотрим конкрентый случай, когда же стоит этот самый вопрос «добавлять ли диски в агрегат к более короткой рейд группе?». Такое может произойти:
Если у вас была собрана Active-Active конфигурация т.е. у вас уже есть два агрегата на каждом контроллере из 11 дисков. И логично было бы увеличить длинну каждой рейд-группы, хотябы из тех соображений чтобы получить больше полезного пространства (не тартиться на лишние Parity диски).
В таклм случае я бы предложил поступить следующим образом:
Когда вам приезжает ещё одна полка, вы можете создать на этой полке новый агрегат, в онлайне мигрировать вольюмы с одного из старых агрегатов построенных на укороченных дисках. После этого поменять у высвобожденных укороченных дисков овнершип на овнершип соседа. После чего добавить высвобожденные укороченные диски вагрегат к таким же дискам.
Если же у вас уже есть Active-Passive конфигурация, и вы докупили ещё полку с дисками, добавлять их в тот же агрегат нет смысла из соображений полезного пространства, так как 2 парити диска всё-равно будут потеряны. Другими словами в таком случае вам рационально было бы превратить вашу Active-Passive конфигурацию в Active-Active и получить такое же полезное пространство. Т.е. на первой ноде будем иметь один большой агрегат из всех дисков которые укорочены, а на пасивной ноде собрать агрегат из новых, не укороченных дисков и сделать её активной.
А если вы сразу покупали 48 дисков или более, то сразу собираете Active-Active конфигурацию по схеме приведённой выше.
Другими словами ситуация с агрегатом, состоящим из двух типов дисков маловероятна
Я, в общем-то, согласен, я свою мысль вел к тому, что не нужно делать агрегат из 4 RAID групп следующего вида:
rg0 — 11disks
rg1 — 22disks
rg2 — 22disks
rg3 — 22disks,
так как что бы там не придумал NetApp в последних прошивках, такая конфигурация всегда будет тормозить.
Если же делать одну группу чуть меньше емкостью, но при этом сохранить кол-во дисков одинаковым, то это не должно сильно сказываться на производительности до момента полного заполнения емкости агрегата (что и так приведет к огромным проблемам производительности).
rg0 — 11disks
rg1 — 22disks
rg2 — 22disks
rg3 — 22disks,
так как что бы там не придумал NetApp в последних прошивках, такая конфигурация всегда будет тормозить.
Если же делать одну группу чуть меньше емкостью, но при этом сохранить кол-во дисков одинаковым, то это не должно сильно сказываться на производительности до момента полного заполнения емкости агрегата (что и так приведет к огромным проблемам производительности).
NetApp действительно не рекомендовал и не рекомендует иметь разнобой в размере рейд групп в рамках одного агрегата. Но с появлением ADP теперь это допускается. А также с выходом прошивки 8.2 допускается иметь разнобой дисков не более чем в два раза от остальных рейд групп. Другими словами приведённый вами пример теперь допускается исспользовать в продакшн.
Я не выполнял нагрузочного тестирования для такой конфигурации и не могу сказать о её влиянии на производительность.
Я не выполнял нагрузочного тестирования для такой конфигурации и не могу сказать о её влиянии на производительность.
Спасибо за статью, как раз запустил такую процедуру у себя на FAS2552. Проапгрейдил до 8.3.2, но разбивка дисков осталась старой. Не совсем понятно зачем делать wipeconfig? В документации написано, что после удаления ownership с дисков на всех нодах надо просто по очереди запустить "Clean configuration and initialize all disks." — option 4 из boot menu. По идее там автоматом wipeconfig и делается.
Вайпконфиг чистит хвосты старой конфиги онтапа на флеше.
Вообще-то 4 пункт бутменю делает инициалмзацию и Вайпконфиг.
Его было обязательно выполнять в более старой версии онтапа после перехода с 7-мода на кластер. У меня как-то давно была ситуация, что кластер не хотел собираться, я долго не мог понять почему и Вайпконфиг мне помог именно ДО того как я конвертировал онтап в кластер мод, ПОТОМ конвертировал в кластер, выполнил 4-й пункт бутменю и все получилось.
Теперь я его всегда делаю, выполнить не сложно и совсем не долго, так что я его делаю по старой памяти, чтобы не наступать на старые грабли дважды. Может сейчас уже этого делать и не нужно.
Вообще-то 4 пункт бутменю делает инициалмзацию и Вайпконфиг.
Его было обязательно выполнять в более старой версии онтапа после перехода с 7-мода на кластер. У меня как-то давно была ситуация, что кластер не хотел собираться, я долго не мог понять почему и Вайпконфиг мне помог именно ДО того как я конвертировал онтап в кластер мод, ПОТОМ конвертировал в кластер, выполнил 4-й пункт бутменю и все получилось.
Теперь я его всегда делаю, выполнить не сложно и совсем не долго, так что я его делаю по старой памяти, чтобы не наступать на старые грабли дважды. Может сейчас уже этого делать и не нужно.
Вот ещё нашёл описание этой же процедуры для FAS2552. Там с картинками, что происходит с дисками. Тоже может кому полезно будет.
Sign up to leave a comment.
Data ONTAP 8.3 ADP: Root-Data Partitioning