Преимущества и недостатки зонирования SAN
Мы только что получили SAN, и я буду помогать в его установке и настройке, я попросил кого-нибудь объяснить мне, что мы получим, используя зонирование SAN, но он не смог ответить на мой вопрос, может кто-нибудь здесь объяснить мне, что Вот некоторые преимущества, которые мы получим от зонирования SAN с использованием Brocade.
Спасибо
6 ответов
Вы имеете в виду зонирование ФК? если это так, то это в основном что-то вроде VLAN в том смысле, что оно позволяет жестко ограничивать соединения между устройствами.
Только с одной большой зоной, по существу, все точки могут общаться со всеми остальными точками, это звучит хорошо, особенно если у вас есть правильный переключатель, который поможет с управлением полосой пропускания (раньше были концентраторы FC, показывающие мой возраст), но это часто приятно / требуется, чтобы у вас было больше контроля.
Например, в нашей среде, полностью основанной на Cisco, я должен сказать, что все очень сильно связано по определению. Так, например, любой данный порт HBA может взаимодействовать только с теми портами, с которыми он спроектирован, чтобы общаться в наших массивах - и никак иначе. Да, это тяжелая работа, но в жизни это означает, что мы можем легче устранять неполадки, и наши нацистские охранники любят это и никогда не бросают нам ничего в ответ.
Так что все сводится к легкости против контроля.
САН-ЗОНИРОВАНИЕ ОЧЕНЬ важно, и вы обязательно должны это сделать. Концептуально, это похоже на 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, но я делаю фибреканал ежедневно)
Как уже упоминалось выше, настройка "зон" в фабриках SAN осуществляется для обеспечения защиты от сбоев устройств от других устройств на том же коммутаторе. Ниже приведены несколько ссылок на документы Brocade, которые я считаю полезными по этому вопросу зонирования.
Краткий обзор и советы приведены на страницах 10 и 11 в Руководстве по рекомендациям администратора SAN: 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
Я думаю, это в основном вопрос безопасности.
Это позволяет вам разделять трафик, в том смысле, что HOSTA может общаться только со STORAGEA, очень похоже на VLAN в сетевом мире.
Это похоже на использование VLAN в ваших сетевых коммутаторах. Я скажу то же, что и я, когда говорю о VLAN: не используйте зонирование только потому, что вы можете или потому, что кто-то еще говорит вам, что вы должны. Убедитесь, что у вас есть четкие и определенные потребности для этого.