У нас только что есть SAN, и я буду помогать в его установке и настройке. Я попросил кого-нибудь объяснить мне, что мы получим от зонирования SAN, но он не смог ответить на мой вопрос, может ли кто-нибудь здесь объяснить мне, что Вот некоторые из преимуществ, которые мы получим от зонирования SAN с помощью Brocade.
Спасибо
Вы имеете в виду зонирование ФК? Если это так, то это в основном что-то вроде VLAN, поскольку позволяет жестко ограничивать соединения между устройствами.
Имея только одну большую зону, практически все точки могут общаться со всеми другими точками, это звучит хорошо, особенно если у вас есть правильный переключатель, который поможет с управлением полосой пропускания (раньше были концентраторы FC bitd, показывающие мой возраст там), но часто это приятно / требовал большего контроля.
Например, в нашей среде, полностью основанной на Cisco, я должен сказать, все очень жестко связано по определению. Так, например, любой данный порт HBA может взаимодействовать только с портами, с которыми он предназначен для общения в наших массивах, и ни с чем другим. Да, это труднее, но в жизни это означает, что мы можем легче устранять неполадки, и наши нацисты, работающие в сфере безопасности, любят это и никогда ничего не бросают в нас.
Итак, все сводится к простоте и контролю.
Зонирование SAN ОЧЕНЬ важно, и вы обязательно должны это сделать. Концептуально это похоже на VLAN, но не вводите в заблуждение. Существуют разные причины, определяющие его использование и назначение. Зона - это контейнер, в который вы помещаете набор инициаторов SCSI (адаптеры шины хоста на вашем клиенте) и набор целей SCSI (порт (ы) в вашем массиве). Каждая вещь в зоне может взаимодействовать с другими вещами в зоне - и вы обычно обнаружите, что каждый инициатор выполняет вход в порт (PLOGI) для каждой цели в зоне. По сути, это создает арбитражный цикл устройств.
Это важно - для начала, там может быть ограничением на количество входов в порт, поддерживаемых массивом. На более современных массивах это довольно большое количество. Но имейте в виду, что у вас есть проблема геометрического роста - зачем встраивать проблемы масштабируемости, когда вам это не нужно.
Но важная причина использования зонирования заключается в том, что когда что-то покидает зону или присоединяется к ней, все остальные участники должны повторно войти в порты. Если у вас небольшие зоны, то подключение или отключение одного устройства не имеет значения - условно есть прерывание обслуживания, но оно незначительно. Однако, если у вас много устройств, то количество устройств, которые должны повторно выполнять арбитраж, растет, как и частота событий PLOGI.
Еще хуже, если у вас есть неисправный HBA, который колеблется - если вы не зонируете, это может создать условие отказа в обслуживании в вашей сети.
http://en.wikipedia.org/wiki/Registered_State_Change_Notification
Лучший способ думать о зонах - это «программное определение вашей шины SCSI». Фактически, вы соединяете шину SCSI некоторых серверов и некоторые порты хранения вместе. Как уже говорили другие, это может помочь в отказоустойчивости или контроле доступа, или сократить область уведомлений об изменении состояния.
Если ваша цель хранилища запускает сброс шины, вы хотите, чтобы все ваши серверы видели это или только несколько?
Зонирование также похоже на прокладку дорог на карте: оно определяет, где разрешено движение транспорта. Это не означает, что ваши серверы будут использовать его, но он ограничивает их определенными путями. вы можете использовать это, чтобы обеспечить сбалансированный доступ к портам хранилища или зарезервировать некоторые порты хранилища для более важных приложений. Кажется, это неплохая причина заняться зонированием, но - как говорили другие до меня - будьте осознанны, имейте план.
Некоторые рекомендуют зонировать HBA одного сервера на один или несколько портов хранения; другие рекомендуют один порт хранения для многих серверов. Тем не менее, некоторые из них уравновешивают множество серверов и множество портов хранения в одной зоне. В каждом практическом правиле есть те, кто скажет вам не делать этого. Я обычно рекомендую выбрать правило, иметь для него причину и придерживаться его; меньшее количество устройств в каждой зоне сокращает область изменения состояния, но создает большую логистическую нагрузку, поэтому будьте осторожны с тем, какую рабочую нагрузку вы даете себе.
Такие инструменты, как BNA / CMCNE / DCNM, как правило, помогают, а OCI стремится помочь вам сохранить рассудок, но правила и условности, которые вы выбираете, могут помочь сохранить согласованность в вашей группе. (Предостережение: я не работаю с поставщиками BNA, CMCNE, OCI или DCNM, но я использую fibrechannel ежедневно)
Как уже упоминалось выше, настройка «зон» в фабриках SAN выполняется для обеспечения изоляции неисправностей устройств от других устройств на том же коммутаторе. Ниже приведены несколько ссылок на документы Brocade, которые я считаю полезными по теме зонирования.
Чтобы получить краткий обзор и советы, я бы посмотрел на страницы 10 и 11 в руководстве SAN Admin Best Practices: http://www.brocade.com/downloads/documents/best_practice_guides/san-admin-best-practices-bp.pdf
Более подробное описание, а также шаги по реализации можно найти в разделе зонирования в Руководстве администратора FOS. Ссылка ниже относится к версии FOS v7.2.0: http://www.brocade.com/downloads/documents/html_product_manuals/FOS_AG_720/wwhelp/wwhimpl/js/html/wwhelp.htm#href=zone.18.01.html
Думаю, это в основном вопрос безопасности.
Он позволяет разделять трафик в том смысле, что HOSTA может общаться только со STORAGEA, что очень похоже на VLAN в мире сетей.
Это похоже на использование VLAN в сетевых коммутаторах. Я скажу то же самое, что и я, когда говорю о VLAN: не применяйте зонирование только потому, что вы можете или потому, что кто-то другой говорит вам, что вы должны. Убедитесь, что у вас есть четкие и определенные потребности для этого.