Комментарии 31
Жаль не сделали внутреннего интерконнекта хотя бы в младших моделях — без коммутатора можно подключить только 3 хоста вместо 4.
Весь прикол кластера в возможности масштабироваться, по этому внутренних портов небыло и не будет.
В следующем же поколении сделали не внутренний шиной, а внешними портами, просто на 2552 теперь не 2 а 4 порта на контроллер из которых два под кластер.
Так или иначе на практике я не видел чтобы 2240, cDOT и active-passive/active-active конфигурацией упирался в производительность порта.
В следующем же поколении сделали не внутренний шиной, а внешними портами, просто на 2552 теперь не 2 а 4 порта на контроллер из которых два под кластер.
Так или иначе на практике я не видел чтобы 2240, cDOT и active-passive/active-active конфигурацией упирался в производительность порта.
А что скажите про возможное узкое место в виде ATTO 6500N на AFF системе (в конфигурации MetroCluster)?
Кстати может стоило добавить и MC в перечень.
В MetroCluster есть рекомендация на длину стека (петлю), т.е. в зависимости от типа полок, дисков, конфигурации (MC или обычная система), версии Data ONTAP и контроллеров есть рекомендации на количество таких полок одном стеке.
На каждый стек приходится по два SAS-FC бриджа: в начале и конце стека.
Поддерживаются SAS-FC бриджи ATTO 6500 и новые ATTO 7500.
Первый бридж имеет 2 порта 8FC, второй 2 порта 16FC соответственно.
Рекомендации по длине стека для MC подбираются исходя из пропускной способности бриджей, чтобы они не были узким местом дисковой подсистемы.
К примеру для 8.3.0 MC поддерживается ATTO 6500 со следующей длинной стека:
В 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 полок.
А есть инфа по реальному использованию интерконнекта? Если например вместо одного 10Г порта использовать 4х1Г, всё равно простаивают :)
Если всё сконфигурино правильно, то кластерный интерконнект практически не используется.
По ним бегает синхронизация нескольких системных баз данных между всеми нодами кластера, размером в пару мегабайт.
Технически 1Gbit может выполнять эту роль, но если вы мигрируете данные между нодами, 1Gbit точно будет узким горлышком, в связи с этим нетапп официально НЕ ПОДДЕРЖИВАЕТ работу кластерного интерконнекта на 1Gbit портах.
Стоит отдельно оговорить случай с 2240. Если у вас только один кластерный линк 10Gbit и этот линк по какой-то причине будет разорван, одна нода из HA пары перезагрузится. В этом нет ничего ужасного, так как отработает take over (HA). Take-over относительно дорогая операция и её можно избежать при помощи трюка с запасным 1Gbit портом с кластерной ролью, который нужно добавить в Cluster'ный бродкаст домен. Таким образом, 1Gbit не используется для кластерной сети, до тех пор, пока не произойдет разрыв 10Gbit линка. Как только основной 10Gbit умрёт, кластерный LIF (по стандартной политике) переедет на первый доступный порт в кластеном бродкаст домене, т.е. на 1Gb порт, избежав не нужной операции Take-Over. По-этому я написал
По ним бегает синхронизация нескольких системных баз данных между всеми нодами кластера, размером в пару мегабайт.
Технически 1Gbit может выполнять эту роль, но если вы мигрируете данные между нодами, 1Gbit точно будет узким горлышком, в связи с этим нетапп официально НЕ ПОДДЕРЖИВАЕТ работу кластерного интерконнекта на 1Gbit портах.
Стоит отдельно оговорить случай с 2240. Если у вас только один кластерный линк 10Gbit и этот линк по какой-то причине будет разорван, одна нода из HA пары перезагрузится. В этом нет ничего ужасного, так как отработает take over (HA). Take-over относительно дорогая операция и её можно избежать при помощи трюка с запасным 1Gbit портом с кластерной ролью, который нужно добавить в Cluster'ный бродкаст домен. Таким образом, 1Gbit не используется для кластерной сети, до тех пор, пока не произойдет разрыв 10Gbit линка. Как только основной 10Gbit умрёт, кластерный LIF (по стандартной политике) переедет на первый доступный порт в кластеном бродкаст домене, т.е. на 1Gb порт, избежав не нужной операции Take-Over. По-этому я написал
не пожадничайте отдать ещё один порт 1Gbit под те же нужды, хотя это уже не является обязательным требованием.
Так если одна нода перезагрузится, то на её стороне потухнут оба линка, и 10Г и 1Г. В чём тогда смысл? Take over всё равно произойдёт. Или я чего-то не понимаю?
Не путайте одно с другим :)
если одна нода будет в дауне, это не значит что вторая пойдет в даун, только лишь потому что у нее кластерные порты потухнут.
Описанная мною ранее ситуация имеет место только в случае обрыва кластерного соединения между нодами НА пары, при том всего нод в кластере две и обе не видят друг друга.
если одна нода будет в дауне, это не значит что вторая пойдет в даун, только лишь потому что у нее кластерные порты потухнут.
Описанная мною ранее ситуация имеет место только в случае обрыва кластерного соединения между нодами НА пары, при том всего нод в кластере две и обе не видят друг друга.
А, понял, речь идёт о защите от Split Brain? Тогда да, лучше перестраховаться :)
Да это защита, но не от сплитбрейна.
Вот предположим вы мигрировали вольюм, а LIF еще не перенесли.
Или на хосте не настроен правильно мультипасинг и хост обращается к контроллеру нетапа который не владеет луном.
В обоих этих случаях доступ к данным будет прозрачно проксироваться и ходить к контроллеру через кластерный интерконнект.
А тут у нас берет и пропадает кластерный коннект.
Что сделать чтобы хост гарантированно продолжил получать доступ к данным и сообщить ему про правильные пути? Никак, нужно просто убрать эти пути:
Потушить одну ноду и переместить все пути к данным на оставшуюся ноду.
Вот предположим вы мигрировали вольюм, а LIF еще не перенесли.
Или на хосте не настроен правильно мультипасинг и хост обращается к контроллеру нетапа который не владеет луном.
В обоих этих случаях доступ к данным будет прозрачно проксироваться и ходить к контроллеру через кластерный интерконнект.
А тут у нас берет и пропадает кластерный коннект.
Что сделать чтобы хост гарантированно продолжил получать доступ к данным и сообщить ему про правильные пути? Никак, нужно просто убрать эти пути:
Потушить одну ноду и переместить все пути к данным на оставшуюся ноду.
А если онлайн миграция не используется, мультипасинг настроен правильно и ломать его никто не планирует. Можно для кластерного интерконнекта ограничиться 4х1Г линками? Просто если они в данном случае будут всегда простаивать, то какой смысл под это выделять 10Г, если по 4 1Г порта на каждой голове свободны и никогда не будут использоваться в продакшене т.к. слишком велики там задержки и разница в скорости с 10Г очень заметна даже на маленькой нагрузке.
1 Гбит можно настроить под кластерный интерконнект это мною проверено — работает.
Но официально НЕ ПОДДЕРЖИВАЕТСЯ. Это значит, что если система у вас еще на поддержке и у вас будут какие-то проблемы связанные с кластерным интерконнектом и вы обратились в поддержку, то как только обнаружится что для кластерного интерконнект используется 1 Гб, есть большая вероятность, что поддержка скажет вернуть кластерный интерконнект на 10 Гб.
Но официально НЕ ПОДДЕРЖИВАЕТСЯ. Это значит, что если система у вас еще на поддержке и у вас будут какие-то проблемы связанные с кластерным интерконнектом и вы обратились в поддержку, то как только обнаружится что для кластерного интерконнект используется 1 Гб, есть большая вероятность, что поддержка скажет вернуть кластерный интерконнект на 10 Гб.
Полный вайп системы при апгрейде 7-mode -> cDOT всё еще требуется? :)
Теперь есть возможность полку с дисками отключить от старой системы 7M и подключить к новой СМ. Это называется Copy-Free-Transition (CFT).
При переключении полки минимальный простой не избежен.
Данные будут сохранены и будут полностью доступны на чтение и запись. Для этого необходимо иметь новую систему с установленной СМ плюс нужно иметь минимальное количество дисков для Root Aggregate, это обязательный минимум.
In-place (т.е. Обновление прошивки на существующем контроллере) апгрейд с 7М на СМ не поддерживается. Это связано именно с необходимостью в Root Aggregate.
Что можно сделать:
Можно взять на тест у партнера/Дисти/Вендора систему FAS с дисками с уже установленной СМ.
Переключить вашу полку на нее. Здесь будет простой.
Далее смигрировать данные на временную полку уже в онлайне.
Обновить вашу систему до СМ и добавить ее в кластер.
Забрать вашу старую (и уже пустую) полку со временной FAS системы и подключить ее к вашей старой FAS системе (и уже обновленной до СМ).
Далее в онлайне мигрируйте данные со временной FAS назад на вашу старую систему со старой полкой.
Удаляем временную систему со временной полкой из кластера.
Итого:
Одно переключение полок с прерыванием
Две Онлайн миграции.
И на вашей старой системе с обновленной прошивкой оказываются ваши старые данные.
Полка с данными может не обнульться (форматироваться).
Я проводил подобную процедуру.
При переключении полки минимальный простой не избежен.
Данные будут сохранены и будут полностью доступны на чтение и запись. Для этого необходимо иметь новую систему с установленной СМ плюс нужно иметь минимальное количество дисков для Root Aggregate, это обязательный минимум.
In-place (т.е. Обновление прошивки на существующем контроллере) апгрейд с 7М на СМ не поддерживается. Это связано именно с необходимостью в Root Aggregate.
Что можно сделать:
Можно взять на тест у партнера/Дисти/Вендора систему FAS с дисками с уже установленной СМ.
Переключить вашу полку на нее. Здесь будет простой.
Далее смигрировать данные на временную полку уже в онлайне.
Обновить вашу систему до СМ и добавить ее в кластер.
Забрать вашу старую (и уже пустую) полку со временной FAS системы и подключить ее к вашей старой FAS системе (и уже обновленной до СМ).
Далее в онлайне мигрируйте данные со временной FAS назад на вашу старую систему со старой полкой.
Удаляем временную систему со временной полкой из кластера.
Итого:
Одно переключение полок с прерыванием
Две Онлайн миграции.
И на вашей старой системе с обновленной прошивкой оказываются ваши старые данные.
Полка с данными может не обнульться (форматироваться).
Я проводил подобную процедуру.
In-place (т.е. Обновление прошивки на существующем контроллере) апгрейд с 7М на СМ не поддерживается. Это связано именно с необходимостью в Root Aggregate.
У меня на всех системах выделенный root-агрегат и уже давно…
Система объемом 4 стойки, боюсь фокус с «переключить» не выйдет и пока я не освобожу все 4 стойки — апгрейд не светит… Подождем, вдруг что-нибудь придумают с апгрейдом 8.2 — > 8.3 без вайпа, учитывая, что у меня метро-кластер и я могу переключить совсем всё на одну площадку, дилемма только с возвращением назад.
Не в курсе по поводу CFT для МС, может быть что для такого случая это не работает.
По поводу выделенных Root Aggregate на 7М. В контексте CFT они не спасут, дело в том что при CFT миграции предусматривается использование утилиты 7МТТ для переноса старой конфигурациистарой 7М в СМ. В связи с чем выделенные Root Aggregate в 7М, пока что будут нужны.
Возможно в будущем это будет реализовано (при наличии выделенных root aggregate для 7М) путем создания второго вольюма с СМ root volume на на тех жевольюма Root агрегатах. Это вполне возможно, учитывая что в обоих режимах используется одинаковый тип HA политики для Root Aggregate (CFO). Но это только предположение, я не знаю роадмапродмап CFT.
По поводу выделенных Root Aggregate на 7М. В контексте CFT они не спасут, дело в том что при CFT миграции предусматривается использование утилиты 7МТТ для переноса старой конфигурациистарой 7М в СМ. В связи с чем выделенные Root Aggregate в 7М, пока что будут нужны.
Возможно в будущем это будет реализовано (при наличии выделенных root aggregate для 7М) путем создания второго вольюма с СМ root volume на на тех жевольюма Root агрегатах. Это вполне возможно, учитывая что в обоих режимах используется одинаковый тип HA политики для Root Aggregate (CFO). Но это только предположение, я не знаю роадмапродмап CFT.
Самое обидное, что с pNFS не возможно иметь разделы, которые распределены по нескольким узлам в кластере.
Оказывается Infinite Vol поддерживают NFSv4.1 и pNFS.
Да, infiniVol пока что не работает с pNFS.
Чего не хватает, на мой взгляд, это того, что NFSv4 в vSphere6 пока что не поддерживает балансировку по линкам (мультипасинг), множественные пути исспользуются только в режиме один активный, все остальные запасные.
Хотя в контексте vVol это этом нет большой необходимости.
Чего не хватает, на мой взгляд, это того, что NFSv4 в vSphere6 пока что не поддерживает балансировку по линкам (мультипасинг), множественные пути исспользуются только в режиме один активный, все остальные запасные.
Хотя в контексте vVol это этом нет большой необходимости.
в NFSv4,1/pNFS мультипасинг не предназначен для балансировки, к тому-же сервер должен поддерживать session connection trunking.
Почему вы считаете что мультипасинг NFSv4 не поедназначен и не сможет балансировать трафик?
rfc5661#13.5 конечно говорит о «Data-server-level multipathing is used for bandwidth scaling via trunking and for higher availability», однако у клиента нет никакой информации о том разные ли это интерфейсы и о их качественных характеристиках (скорость, задержки). Это всего лишь лист IP адресов по которым можно достучатся до сервера
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
tools.ietf.org/html/rfc5661#section-13.5
Правильно. Наши дата-сервера возвращают два IP адреса — v4 и v6 того-же самого интерфейса. Лоад балансиг не имеет смысла и клиент об этом не знает.
Пока что cDOT не поддерживает trunking в NFSv4.1, также как и vSphere6.
Но поддержка trunking планируется в будущих версиях cDOT.
Но поддержка trunking планируется в будущих версиях cDOT.
trunking в NFSv4.1 пока что нет в ONTAP 9.1.
Мониторить ситуацию, появилась ли поддержка в новых версиях, можно через документ TR-4067, раздел под названием «NFSv4.1» или по ключевому слову «RFC 5661».
Мониторить ситуацию, появилась ли поддержка в новых версиях, можно через документ TR-4067, раздел под названием «NFSv4.1» или по ключевому слову «RFC 5661».
Infinite Volumes поддерживают pNFS начиная с версии Clustered Data ONTAP® 8.2.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Зачем обновляться до Data ONTAP Cluster Mode?