Есть FlexPod Datacenter: с прямым включением и через Nexus.
FlexPod Express: с прямым включением и через Nexus.
FlexPod Select.
Посмотрите документы по этим архитектурам, опредилитесь какая из них похожа га вашу.
FlexPod может отклоняться от изначальной архитектуры, к примеру можно поставить большую или меньшую модель СХД, заменить модели серверов, добавить линки или протокол, добавить количество компонент и т.д.
Есть три основные компоненты: СХД должна быть от NetApp, сервера UCS, а сеть Nexus. Определяет является ли ваша конфигурация техническая команда из инженеров обоих компаний, если ваша конфигурация существенно отличается.
Что же касается числа конфигураций. Рекомендую погуглить, конфигураций достаточно много. Только лишь в этой статье порядка 12 разных конфиг.
В текущей схеме CFT не поддерживается миграция MetroCluster с 7-Mode на cDOT.
Другими словами для MetroCluster, wipeconfig по-прежнему необходимо выполнять.
The NFSv4.1 file layout supports multipathing to multiple data server addresses. Data-server-level multipathing is used for bandwidth scaling via trunking (Section 2.10.5) and for higher availability of use in the case of a data-server failure. tools.ietf.org/html/rfc5661#section-13.5
Чего не хватает, на мой взгляд, это того, что NFSv4 в vSphere6 пока что не поддерживает балансировку по линкам (мультипасинг), множественные пути исспользуются только в режиме один активный, все остальные запасные.
Хотя в контексте vVol это этом нет большой необходимости.
Не в курсе по поводу CFT для МС, может быть что для такого случая это не работает.
По поводу выделенных Root Aggregate на 7М. В контексте CFT они не спасут, дело в том что при CFT миграции предусматривается использование утилиты 7МТТ для переноса старой конфигурациистарой 7М в СМ. В связи с чем выделенные Root Aggregate в 7М, пока что будут нужны.
Возможно в будущем это будет реализовано (при наличии выделенных root aggregate для 7М) путем создания второго вольюма с СМ root volume на на тех жевольюма Root агрегатах. Это вполне возможно, учитывая что в обоих режимах используется одинаковый тип HA политики для Root Aggregate (CFO). Но это только предположение, я не знаю роадмапродмап CFT.
Теперь есть возможность полку с дисками отключить от старой системы 7M и подключить к новой СМ. Это называется Copy-Free-Transition (CFT).
При переключении полки минимальный простой не избежен.
Данные будут сохранены и будут полностью доступны на чтение и запись. Для этого необходимо иметь новую систему с установленной СМ плюс нужно иметь минимальное количество дисков для Root Aggregate, это обязательный минимум.
In-place (т.е. Обновление прошивки на существующем контроллере) апгрейд с 7М на СМ не поддерживается. Это связано именно с необходимостью в Root Aggregate.
Что можно сделать:
Можно взять на тест у партнера/Дисти/Вендора систему FAS с дисками с уже установленной СМ.
Переключить вашу полку на нее. Здесь будет простой.
Далее смигрировать данные на временную полку уже в онлайне.
Обновить вашу систему до СМ и добавить ее в кластер.
Забрать вашу старую (и уже пустую) полку со временной FAS системы и подключить ее к вашей старой FAS системе (и уже обновленной до СМ).
Далее в онлайне мигрируйте данные со временной FAS назад на вашу старую систему со старой полкой.
Удаляем временную систему со временной полкой из кластера.
Итого:
Одно переключение полок с прерыванием
Две Онлайн миграции.
И на вашей старой системе с обновленной прошивкой оказываются ваши старые данные.
Полка с данными может не обнульться (форматироваться).
1 Гбит можно настроить под кластерный интерконнект это мною проверено — работает.
Но официально НЕ ПОДДЕРЖИВАЕТСЯ. Это значит, что если система у вас еще на поддержке и у вас будут какие-то проблемы связанные с кластерным интерконнектом и вы обратились в поддержку, то как только обнаружится что для кластерного интерконнект используется 1 Гб, есть большая вероятность, что поддержка скажет вернуть кластерный интерконнект на 10 Гб.
Да это защита, но не от сплитбрейна.
Вот предположим вы мигрировали вольюм, а LIF еще не перенесли.
Или на хосте не настроен правильно мультипасинг и хост обращается к контроллеру нетапа который не владеет луном.
В обоих этих случаях доступ к данным будет прозрачно проксироваться и ходить к контроллеру через кластерный интерконнект.
А тут у нас берет и пропадает кластерный коннект.
Что сделать чтобы хост гарантированно продолжил получать доступ к данным и сообщить ему про правильные пути? Никак, нужно просто убрать эти пути:
Потушить одну ноду и переместить все пути к данным на оставшуюся ноду.
Не путайте одно с другим :)
если одна нода будет в дауне, это не значит что вторая пойдет в даун, только лишь потому что у нее кластерные порты потухнут.
Описанная мною ранее ситуация имеет место только в случае обрыва кластерного соединения между нодами НА пары, при том всего нод в кластере две и обе не видят друг друга.
Если всё сконфигурино правильно, то кластерный интерконнект практически не используется.
По ним бегает синхронизация нескольких системных баз данных между всеми нодами кластера, размером в пару мегабайт.
Технически 1Gbit может выполнять эту роль, но если вы мигрируете данные между нодами, 1Gbit точно будет узким горлышком, в связи с этим нетапп официально НЕ ПОДДЕРЖИВАЕТ работу кластерного интерконнекта на 1Gbit портах.
Стоит отдельно оговорить случай с 2240. Если у вас только один кластерный линк 10Gbit и этот линк по какой-то причине будет разорван, одна нода из HA пары перезагрузится. В этом нет ничего ужасного, так как отработает take over (HA). Take-over относительно дорогая операция и её можно избежать при помощи трюка с запасным 1Gbit портом с кластерной ролью, который нужно добавить в Cluster'ный бродкаст домен. Таким образом, 1Gbit не используется для кластерной сети, до тех пор, пока не произойдет разрыв 10Gbit линка. Как только основной 10Gbit умрёт, кластерный LIF (по стандартной политике) переедет на первый доступный порт в кластеном бродкаст домене, т.е. на 1Gb порт, избежав не нужной операции Take-Over. По-этому я написал
не пожадничайте отдать ещё один порт 1Gbit под те же нужды, хотя это уже не является обязательным требованием.
В MetroCluster есть рекомендация на длину стека (петлю), т.е. в зависимости от типа полок, дисков, конфигурации (MC или обычная система), версии Data ONTAP и контроллеров есть рекомендации на количество таких полок одном стеке.
На каждый стек приходится по два SAS-FC бриджа: в начале и конце стека.
Поддерживаются SAS-FC бриджи ATTO 6500 и новые ATTO 7500.
Первый бридж имеет 2 порта 8FC, второй 2 порта 16FC соответственно.
Рекомендации по длине стека для MC подбираются исходя из пропускной способности бриджей, чтобы они не были узким местом дисковой подсистемы.
К примеру для 8.3.0 MC поддерживается ATTO 6500 со следующей длинной стека:
Если это обычные диски (нет SSD), то длинна стека для полок DS424X и DS2246 составит до 10 полок.
Если использовать «гибридные полки» и количество SSD от 1 до 24, то количество полок на стек должно быть до 7.
Если количество SSD от 25 до 48, поддерживается до 4 полок.
Весь прикол кластера в возможности масштабироваться, по этому внутренних портов небыло и не будет.
В следующем же поколении сделали не внутренний шиной, а внешними портами, просто на 2552 теперь не 2 а 4 порта на контроллер из которых два под кластер.
Так или иначе на практике я не видел чтобы 2240, cDOT и active-passive/active-active конфигурацией упирался в производительность порта.
Если ваша модель у NetApp ещё на поддержке, то продлевать сервис на неё можно столько раз сколько нужно, до того момента пока оно не станет End of Support (EOS).
К примеру NetApp анонсировал систему 2240 в ноябре 2011, дата когда ещё можно заказать EOA (End of Availability) у этой системы март 2015, а End of Support (EOS) март 2020. Итого эта модель может поддерживаться 9 лет: до объявления EOA прошло 4 года и она ещё будет поддерживается начиная с последней продажи 5 лет.
NetApp действительно не рекомендовал и не рекомендует иметь разнобой в размере рейд групп в рамках одного агрегата. Но с появлением ADP теперь это допускается. А также с выходом прошивки 8.2 допускается иметь разнобой дисков не более чем в два раза от остальных рейд групп. Другими словами приведённый вами пример теперь допускается исспользовать в продакшн.
Я не выполнял нагрузочного тестирования для такой конфигурации и не могу сказать о её влиянии на производительность.
FlexPod Express: с прямым включением и через Nexus.
FlexPod Select.
Посмотрите документы по этим архитектурам, опредилитесь какая из них похожа га вашу.
FlexPod может отклоняться от изначальной архитектуры, к примеру можно поставить большую или меньшую модель СХД, заменить модели серверов, добавить линки или протокол, добавить количество компонент и т.д.
Есть три основные компоненты: СХД должна быть от NetApp, сервера UCS, а сеть Nexus. Определяет является ли ваша конфигурация техническая команда из инженеров обоих компаний, если ваша конфигурация существенно отличается.
Что же касается числа конфигураций. Рекомендую погуглить, конфигураций достаточно много. Только лишь в этой статье порядка 12 разных конфиг.
Другими словами для MetroCluster, wipeconfig по-прежнему необходимо выполнять.
Но поддержка trunking планируется в будущих версиях cDOT.
tools.ietf.org/html/rfc5661#section-13.5
Чего не хватает, на мой взгляд, это того, что NFSv4 в vSphere6 пока что не поддерживает балансировку по линкам (мультипасинг), множественные пути исспользуются только в режиме один активный, все остальные запасные.
Хотя в контексте vVol это этом нет большой необходимости.
По поводу выделенных Root Aggregate на 7М. В контексте CFT они не спасут, дело в том что при CFT миграции предусматривается использование утилиты 7МТТ для переноса старой конфигурациистарой 7М в СМ. В связи с чем выделенные Root Aggregate в 7М, пока что будут нужны.
Возможно в будущем это будет реализовано (при наличии выделенных root aggregate для 7М) путем создания второго вольюма с СМ root volume на на тех жевольюма Root агрегатах. Это вполне возможно, учитывая что в обоих режимах используется одинаковый тип HA политики для Root Aggregate (CFO). Но это только предположение, я не знаю роадмапродмап CFT.
При переключении полки минимальный простой не избежен.
Данные будут сохранены и будут полностью доступны на чтение и запись. Для этого необходимо иметь новую систему с установленной СМ плюс нужно иметь минимальное количество дисков для Root Aggregate, это обязательный минимум.
In-place (т.е. Обновление прошивки на существующем контроллере) апгрейд с 7М на СМ не поддерживается. Это связано именно с необходимостью в Root Aggregate.
Что можно сделать:
Можно взять на тест у партнера/Дисти/Вендора систему FAS с дисками с уже установленной СМ.
Переключить вашу полку на нее. Здесь будет простой.
Далее смигрировать данные на временную полку уже в онлайне.
Обновить вашу систему до СМ и добавить ее в кластер.
Забрать вашу старую (и уже пустую) полку со временной FAS системы и подключить ее к вашей старой FAS системе (и уже обновленной до СМ).
Далее в онлайне мигрируйте данные со временной FAS назад на вашу старую систему со старой полкой.
Удаляем временную систему со временной полкой из кластера.
Итого:
Одно переключение полок с прерыванием
Две Онлайн миграции.
И на вашей старой системе с обновленной прошивкой оказываются ваши старые данные.
Полка с данными может не обнульться (форматироваться).
Я проводил подобную процедуру.
Но официально НЕ ПОДДЕРЖИВАЕТСЯ. Это значит, что если система у вас еще на поддержке и у вас будут какие-то проблемы связанные с кластерным интерконнектом и вы обратились в поддержку, то как только обнаружится что для кластерного интерконнект используется 1 Гб, есть большая вероятность, что поддержка скажет вернуть кластерный интерконнект на 10 Гб.
Вот предположим вы мигрировали вольюм, а LIF еще не перенесли.
Или на хосте не настроен правильно мультипасинг и хост обращается к контроллеру нетапа который не владеет луном.
В обоих этих случаях доступ к данным будет прозрачно проксироваться и ходить к контроллеру через кластерный интерконнект.
А тут у нас берет и пропадает кластерный коннект.
Что сделать чтобы хост гарантированно продолжил получать доступ к данным и сообщить ему про правильные пути? Никак, нужно просто убрать эти пути:
Потушить одну ноду и переместить все пути к данным на оставшуюся ноду.
если одна нода будет в дауне, это не значит что вторая пойдет в даун, только лишь потому что у нее кластерные порты потухнут.
Описанная мною ранее ситуация имеет место только в случае обрыва кластерного соединения между нодами НА пары, при том всего нод в кластере две и обе не видят друг друга.
По ним бегает синхронизация нескольких системных баз данных между всеми нодами кластера, размером в пару мегабайт.
Технически 1Gbit может выполнять эту роль, но если вы мигрируете данные между нодами, 1Gbit точно будет узким горлышком, в связи с этим нетапп официально НЕ ПОДДЕРЖИВАЕТ работу кластерного интерконнекта на 1Gbit портах.
Стоит отдельно оговорить случай с 2240. Если у вас только один кластерный линк 10Gbit и этот линк по какой-то причине будет разорван, одна нода из HA пары перезагрузится. В этом нет ничего ужасного, так как отработает take over (HA). Take-over относительно дорогая операция и её можно избежать при помощи трюка с запасным 1Gbit портом с кластерной ролью, который нужно добавить в Cluster'ный бродкаст домен. Таким образом, 1Gbit не используется для кластерной сети, до тех пор, пока не произойдет разрыв 10Gbit линка. Как только основной 10Gbit умрёт, кластерный LIF (по стандартной политике) переедет на первый доступный порт в кластеном бродкаст домене, т.е. на 1Gb порт, избежав не нужной операции Take-Over. По-этому я написал
В MetroCluster есть рекомендация на длину стека (петлю), т.е. в зависимости от типа полок, дисков, конфигурации (MC или обычная система), версии Data ONTAP и контроллеров есть рекомендации на количество таких полок одном стеке.
На каждый стек приходится по два SAS-FC бриджа: в начале и конце стека.
Поддерживаются SAS-FC бриджи ATTO 6500 и новые ATTO 7500.
Первый бридж имеет 2 порта 8FC, второй 2 порта 16FC соответственно.
Рекомендации по длине стека для MC подбираются исходя из пропускной способности бриджей, чтобы они не были узким местом дисковой подсистемы.
К примеру для 8.3.0 MC поддерживается ATTO 6500 со следующей длинной стека:
В следующем же поколении сделали не внутренний шиной, а внешними портами, просто на 2552 теперь не 2 а 4 порта на контроллер из которых два под кластер.
Так или иначе на практике я не видел чтобы 2240, cDOT и active-passive/active-active конфигурацией упирался в производительность порта.
К примеру NetApp анонсировал систему 2240 в ноябре 2011, дата когда ещё можно заказать EOA (End of Availability) у этой системы март 2015, а End of Support (EOS) март 2020. Итого эта модель может поддерживаться 9 лет: до объявления EOA прошло 4 года и она ещё будет поддерживается начиная с последней продажи 5 лет.
Я не выполнял нагрузочного тестирования для такой конфигурации и не могу сказать о её влиянии на производительность.