У меня с 6120 и mtu 9000 почему-то кластерная сеть не поднялась с ontap 8.3rc1/8.3.1rc1.
Вы могли бы дать свой конфиг свича, версию прошивки, включенные фичи?
navion
Производительность свичей не тестировалась. В данном случае в этом нет большой надобности.
Так как архитектура кластеризации Data ONTAP устроена таким образом, чтобы кластерные интерконнекты исспользовались только в редких ситуациях. Как правило каждый контроллер и его порты обслуживают данные, которые непосредственно расположены на том же контроллере, для, чего разработан ряд механизмов, таких как:
ALUA (для SAN)
pNFS 4.1 (NAS)
и CIFS v3.0 (NAS)
Таким образом кластерные свичи, как правило, нужны только для подстраховки на тот момент, пока данные мигрируют из одной ноды на другую. Другими словами в нормально настроенном и работающем продакшн кластерные свичи не вносят коррективов в скорость отклика к данным так как практически не исспользуются.
Вопрос ухудшения отклика меня не интересовал, так при выборе двух из трех пунктов
Онлайн миграция
Скорость отклика
Возможность исспользования подручных свичей
Вопрос скорости отклика был на самом последнем приоритете.
По поводу стандартной процедуры.
Команда unjoin сама по себе конечно же очень простая и KB есть.
Но на практике столкнулся, что KB ничего не говорит про:
Системные вольюмы
Про cifs аудит
Про фэйловер-группы
Пришлось тыкать самому. Мелочь, а может сэкономить 3 часа времени ;)
По поводу SAN lif, да в основном их мигрировать не нужно. Но можно
И иногда в редких случаях в этом есть необходимости. Такие случаи действительно крайне редкие и скорее экзотика.
Я понял с чем у вас возникла путаница.
Когда я написал
рекомендуется применять World Wide Port Name zoning
имелось ввиду зонирование с исспользованием WWPN адресов. Вас сбило с толку слово «Port», в данном случае под WWPN (World Wide Port Name) подразумевается адрес порта.
В последнем абзаце я хотел подчеркнуть, что так как на физическом порту живут несколько WWPN, это сбивает с толку админов при мапинге лунов и зонировании.
И те WWPN, которые адресуют физический порт и начинаются на «5», они не исспользуются вообще.
А те WWPN, которые адресуют LIF'ы (которые живут на физических портах) и начинаются на «2», должны быть исспользованы для зонирования и мапинга лунов.
Вот и хорошо, что все рекомендуют то же самое, так что получается это не только «для устройств NetApp, работающих в cluster mode»? Стоит также отметить, что soft zoning существовал не всегда, в начале его небыло.
Должен ещё вас дополнить, что схема подключения и зонирования схожа с другими кластерными СХД, к примеру IBM Storwize. Я не собирался в этой статье открывать Америку, а хотел всего лишь визуализировать подключение и зонирование, так как некоторых людей сбивает с толку менстрим кластеризации.
Мои статьи это материал к действию инженерам интеграторов и заказчиков интересующихся технологиями NetApp, именно по этому, по-видимому, вы и не поняли последний абзац. Если вам всё-же интерестно, то понимание последнего абзаца кроется в разделе про LIF'ы. Можете также обратиться вот к этой статье.
Как правило все мои статьи появляются после того, как происходит инсталяция СХД и у инженеров вознивают вопросы, в этом случае вопрос был, «А как это подключать и зонировать»?
Так что на счёт маркетинга, могу сказать только, что тяжело искать чёрную кошку в тёмной комнате, особенно когда ёё там нет.
Меня удивляет, когда в полку люди ставят 12 SATA дисков и загадочно так говорят, «она подключена одним четырехканальными SAS 2 кабелем, что теоретически даст 24 Gb/s».
Следом за ростом компании неизбежно следует рост ЦОД. И админы такого ЦОДа должны немного опережать его развитие. А получается что они немного запаздывают:
Вместо того, чтобы админы думали об масштабируемости, отказоустойчивости, управляемости, репликации, удобстве резервного копирования и восстановления, они, «во главу» всего ставят «цену вопроса». И лишь спустя время, жизнь учит, расставит приоритеты и утрясёт всё так, что «цена вопроса» для них смещается с первого места. Иногда смещение происходит вместе с админом с рабочего места. И тогда они понимают, что «не в производительности счастье».
Симметрично этому феномену существует ещё один, который наблюдается в руководстве компании, заключается он в том, что финансы выделять не хоят они, а ответственность за работоспособность ЦОДа спрашивают почему-то с админов. По именно руководство бизнеса провоцирует первый феномен. и только после «Шеф всё пропало», финансы на «правильные» решения чудесным образом находятся.
Мой совет заключается в том, чтобы не допустить ситуации «финансы НЕ выделили мы, а ответственные за неработоспособность вы».
Относительно приведенной ссылки, должен отметить, то латентность, как правило ухудшается не из-за сети, а из-за недостатка дисков. Собственно автор сам отметил что все было хорошо пока виртуальная инфраструктура не выросла. Так что сравнение FC и SAS в приведенном примере не корректно. Естественно на FC/FCoE/iSCSI латентность можно получить на много ниже, к примеру 1 мс на SSD дисках. Это простой пример показывающий что дело в основном в дисках, а не сети.
Что-же касается одного-двух серверов, то на мой взгляд лучше выбрать, сразу такую технологию, которая позволит масштабироваться вашему ЦОДу в будущем. И если SAS по-вашему мнению обеспечит такую возможность, почему бы и нет.
Но как я сказал ранее, смотрю со скептицизмом на SAS свичи потому, что их нигде в продакшине не видел.
О SAS могу сказать из того, что я видел — SAS используют для подключения полок к СХД. Не смотря на то, что существуют в природе SAS свичи, во всех ЦОДах которые я видел, от миниатюрных до очень-больших, нигде не было SAS свичей. Даже JBOD полки для серверов почему то мне не попадались на глаза. По-видимому владельцы ЦОДов не рассматривают SAS свичи как замену блочным FC/FCoE/iSCSI, а также по каким-то причинам не спешат адаптировать такие дизайны в своих ЦОДах. В то же время iSCSI (работающий поверх Ethernet) продолжает отъедать долю у других блочных протоколов и встречается в 1/3 всех ЦОД которые я видел.
Мне сложно сравнивать SAS протокол с FC/FCoE/iSCSI, так как я не много знаю о его преимуществах. Следя за тенденциями и новыми развивающимися технологиями ЦОД, нигде для себя не замечал каких-то специальных, особых возможностей SAS, для того чтобы он занял место одного из выше перечисленных протоколов. Похоже он занял свою нишу и останется там.
Среди протоколов которые набирают популярность в ЦОД для подключения разнообразных хранилищ стоит отметить Ethernet.
Собственно об этом и статья, как сделать так, чтобы и бюджетно, и в будущем «лишнего» не покупать, и при этом всём иметь возможность вырасти, максимально утилизируя имеющееся оборудование.
А в плане возможностей балансировки нагрузки для малых ЦОД, к примеру с двумя серверами и 4 сетевыми линками от каждого узла, балансировка LACP будет иметь существенные недостатки, по сравнению с блочным протоколами, для приведенного примера из-за внутреннего устройства балансировки трафика.
Для того чтобы обойти эти ограничения, для малых инфраструктур, необходимо предпринимать ряд дополнительных действий. habrahabr.ru/post/215351
Вы могли бы дать свой конфиг свича, версию прошивки, включенные фичи?
Производительность свичей не тестировалась. В данном случае в этом нет большой надобности.
Так как архитектура кластеризации Data ONTAP устроена таким образом, чтобы кластерные интерконнекты исспользовались только в редких ситуациях. Как правило каждый контроллер и его порты обслуживают данные, которые непосредственно расположены на том же контроллере, для, чего разработан ряд механизмов, таких как:
Таким образом кластерные свичи, как правило, нужны только для подстраховки на тот момент, пока данные мигрируют из одной ноды на другую. Другими словами в нормально настроенном и работающем продакшн кластерные свичи не вносят коррективов в скорость отклика к данным так как практически не исспользуются.
Вопрос ухудшения отклика меня не интересовал, так при выборе двух из трех пунктов
Вопрос скорости отклика был на самом последнем приоритете.
Команда unjoin сама по себе конечно же очень простая и KB есть.
Но на практике столкнулся, что KB ничего не говорит про:
Системные вольюмы
Про cifs аудит
Про фэйловер-группы
Пришлось тыкать самому. Мелочь, а может сэкономить 3 часа времени ;)
И иногда в редких случаях в этом есть необходимости. Такие случаи действительно крайне редкие и скорее экзотика.
Как по-вашему стоит перефразировать, чтобы предложение легче понималось?
Когда я написал имелось ввиду зонирование с исспользованием WWPN адресов. Вас сбило с толку слово «Port», в данном случае под WWPN (World Wide Port Name) подразумевается адрес порта.
В первом же предложении первого абзаца написано: .
И те WWPN, которые адресуют физический порт и начинаются на «5», они не исспользуются вообще.
А те WWPN, которые адресуют LIF'ы (которые живут на физических портах) и начинаются на «2», должны быть исспользованы для зонирования и мапинга лунов.
Должен ещё вас дополнить, что схема подключения и зонирования схожа с другими кластерными СХД, к примеру IBM Storwize. Я не собирался в этой статье открывать Америку, а хотел всего лишь визуализировать подключение и зонирование, так как некоторых людей сбивает с толку менстрим кластеризации.
Мои статьи это материал к действию инженерам интеграторов и заказчиков интересующихся технологиями NetApp, именно по этому, по-видимому, вы и не поняли последний абзац. Если вам всё-же интерестно, то понимание последнего абзаца кроется в разделе про LIF'ы. Можете также обратиться вот к этой статье.
Как правило все мои статьи появляются после того, как происходит инсталяция СХД и у инженеров вознивают вопросы, в этом случае вопрос был, «А как это подключать и зонировать»?
Так что на счёт маркетинга, могу сказать только, что тяжело искать чёрную кошку в тёмной комнате, особенно когда ёё там нет.
Может по-этому?
Следом за ростом компании неизбежно следует рост ЦОД. И админы такого ЦОДа должны немного опережать его развитие. А получается что они немного запаздывают:
Вместо того, чтобы админы думали об масштабируемости, отказоустойчивости, управляемости, репликации, удобстве резервного копирования и восстановления, они, «во главу» всего ставят «цену вопроса». И лишь спустя время, жизнь учит, расставит приоритеты и утрясёт всё так, что «цена вопроса» для них смещается с первого места. Иногда смещение происходит вместе с админом с рабочего места. И тогда они понимают, что «не в производительности счастье».
Симметрично этому феномену существует ещё один, который наблюдается в руководстве компании, заключается он в том, что финансы выделять не хоят они, а ответственность за работоспособность ЦОДа спрашивают почему-то с админов. По именно руководство бизнеса провоцирует первый феномен. и только после «Шеф всё пропало», финансы на «правильные» решения чудесным образом находятся.
Мой совет заключается в том, чтобы не допустить ситуации «финансы НЕ выделили мы, а ответственные за неработоспособность вы».
Но как я сказал ранее, смотрю со скептицизмом на SAS свичи потому, что их нигде в продакшине не видел.
Мне сложно сравнивать SAS протокол с FC/FCoE/iSCSI, так как я не много знаю о его преимуществах. Следя за тенденциями и новыми развивающимися технологиями ЦОД, нигде для себя не замечал каких-то специальных, особых возможностей SAS, для того чтобы он занял место одного из выше перечисленных протоколов. Похоже он занял свою нишу и останется там.
Среди протоколов которые набирают популярность в ЦОД для подключения разнообразных хранилищ стоит отметить Ethernet.
Собственно об этом и статья, как сделать так, чтобы и бюджетно, и в будущем «лишнего» не покупать, и при этом всём иметь возможность вырасти, максимально утилизируя имеющееся оборудование.
Для того чтобы обойти эти ограничения, для малых инфраструктур, необходимо предпринимать ряд дополнительных действий.
habrahabr.ru/post/215351