Zoning FC SAN: правила для Brocade и Cisco MDS без риска

Где чаще всего возникают инциденты при изменениях FC SAN

Большинство сбоев в FC SAN происходит не из-за отказа коммутатора или HBA, а из-за изменений: добавили новый сервер, переделали зоны, активировали конфигурацию, и внезапно часть путей пропала. В SAN даже мелкая ошибка быстро превращается в простой, потому что доступ к LUN зависит от цепочки настроек сразу на нескольких устройствах.

Чаще всего доступ ломается из-за zoning: он определяет, кто вообще может «увидеть» нужный порт. Если сервер и СХД перестают видеть друг друга, мультипасинг теряет пути, а ОС и приложения реагируют по-разному: от деградации производительности до полной остановки.

Типовые последствия:

• простой приложений из-за потери всех путей к LUN
• деградация при потере части путей (I/O идет по одному пути, растут задержки)
• «мигающие» пути после активации, когда где-то остались лишние или пересекающиеся зоны
• сложная диагностика, потому что проблема проявляется не сразу (например, при пиковой нагрузке)

Корень почти всегда в процессе изменений. Частые причины: правки «вживую» без плана отката, путаница в именах и WWPN, смешение подходов (single-initiator и «общие» зоны) и самое опасное - активация не той конфигурации или непонимание, что именно поменяется после Activate/Enable.

Хороший zoning решает не «красоту схемы», а практичные задачи: предсказуемость (понятно, что увидит каждый хост), контроль (минимум лишних связей) и повторяемость (одинаковые правила для всех подключений). Тогда изменение проще проверить и так же просто откатить.

Базовые термины, чтобы говорить на одном языке

Многие инциденты начинаются с того, что люди называют разные вещи одним словом или путают идентификаторы.

WWPN (World Wide Port Name) - уникальный адрес FC-порта. Это не MAC-адрес (он про Ethernet) и не серийный номер устройства (он про железо целиком). Серийник может быть один, а WWPN у HBA-портов будет два (или больше). WWPN меняется, например, после замены HBA или некоторых обновлений.

В FC обычно две роли:

• Инициатор (initiator) - сервер с HBA, который отправляет запросы к дискам.
• Таргет (target) - порт СХД, который эти запросы принимает.

Простая логика: сервер должен видеть только нужные таргеты СХД, а не все подряд.

Основные объекты, с которыми вы работаете:

• Alias - понятное имя для WWPN (например, srv01_hba1 или storageA_ctrl0_p1).
• Zone - правило, кто с кем может общаться (обычно инициатор + нужные таргеты).
• Zoneset (Cisco) или cfg (Brocade) - набор зон, который реально применяется на фабрике.

Отдельная важная деталь для Cisco MDS: VSAN. Это виртуальные фабрики внутри одного коммутатора. Zoning и активация делаются в рамках конкретного VSAN. Одна и та же пара WWPN в другом VSAN ничего не даст.

В реальной инфраструктуре почти всегда две независимые фабрики A/B. Это два отдельных пути от сервера к СХД для отказоустойчивости. Зонирование нужно повторить в обеих фабриках, но не копировать вслепую: сверяйте, что WWPN и порты действительно соответствуют Fabric A и Fabric B.

Правила zoning, которые снижают риск ошибок

Цель zoning в FC SAN простая: при любом изменении вы должны точно понимать, кто с кем может общаться, и быстро откатиться, если что-то пошло не так. Эти правила помогают держать конфигурацию предсказуемой и уменьшают шанс случайно «зацепить» чужие хосты или порты СХД.

1) Single-initiator zoning

Самое полезное правило: один initiator (один HBA-порт сервера, один WWPN) на одну зону. В зоне, кроме этого initiator, находятся только нужные target-порты СХД.

Так ошибка в одном подключении не затронет другие серверы, а диагностика становится проще: открываете зону и сразу видите, какой это HBA и к каким портам массива он ходит.

2) Минимально необходимый доступ

Добавляйте только те target-порты массива, которые реально нужны этому серверу. Не включайте «все порты контроллеров на всякий случай». Это снижает риск лишних путей, неожиданных «видимых» LUN и проблем при будущих миграциях.

Обычно выбирают набор портов под конкретную фабрику (A или B) и под требуемую отказоустойчивость.

3) Единые и читаемые имена

Имена должны помогать, а не быть загадкой. Хорошая схема обычно отражает хост, номер HBA, роль (init/target), массив, порт и фабрику. Тогда в ночном окне изменений меньше шансов перепутать WWPN или добавить «почти такой же» объект.

Минимальный набор правил нейминга:

• один формат для алиасов WWPN и зон
• Fabric A/B прямо в имени
• никаких произвольных сокращений без «словаря»
• одинаковый принцип имен на Brocade и Cisco MDS

Когда допустимы исключения

Иногда от правил приходится отступать: кластеры с общими дисками, отдельные варианты tape sharing или требования вендора. Главное - чтобы исключение было осознанным и записанным: почему так сделано, для каких хостов, кто согласовал, и что именно проверять после изменения. Без этого «временное» быстро становится постоянным источником инцидентов.

Пошаговый алгоритм внесения изменений (общий)

Инциденты возникают не из-за «сложных команд», а из-за спешки и неполных данных. Если держать один и тот же порядок действий, риск заметно падает даже при частых подключениях новых серверов.

До изменений: подготовка и сбор фактов

Начните с дисциплины вокруг заявки: что подключаем, к чему, в какое окно, кто подтверждает результат. Сразу подготовьте план отката: что вернете назад, если хост не увидит LUN или, наоборот, увидит лишнее.

Перед тем как трогать фабрику, соберите минимум:

• WWPN инициаторов (HBA) и WWPN целевых портов СХД (нужные target-порты)
• конкретные switch-порты, где физически подключены устройства, и их текущее состояние
• модель доступа (без «широких» зон)
• ограничения по времени и критерий успеха (что считается «работает»)
• ответственного за проверку на стороне ОС и СХД

После этого сверяйте факты с реальностью: одна перепутанная пара символов в WWPN часто стоит простоя.

Выполнение и контроль

Работайте маленькими шагами и проверяйте каждый:

• создайте понятные алиасы для новых WWPN (хост и target), чтобы не работать «голыми» значениями
• создайте новую зону по принципу «инициатор + нужные target-порты» (без лишних участников)
• добавьте зону в активный набор (zoneset/cfg), не меняя чужие зоны без необходимости
• активируйте изменения в согласованное окно и убедитесь, что конфигурация применена без ошибок
• проверьте видимость на хосте и на СХД, затем понаблюдайте 10-30 минут: логины, ошибки путей, флаппинг

Простой пример: подключаете новый сервер к СХД. Фиксируете два WWPN HBA, выбираете target-порты массива, делаете по зоне на каждый fabric и только потом активируете. Если что-то пошло не так, откат - возврат к предыдущему активному набору.

Сразу после работ зафиксируйте: дату и окно, кто делал, какие WWPN и алиасы добавлены, какие зоны и в какой набор включены, результат проверки на хосте и на СХД. Это экономит часы при следующем изменении и при разборе инцидентов.

Brocade: практические правила и типовой порядок команд

В Brocade успех почти всегда упирается в дисциплину имен и в то, как вы отделяете подготовку от активации. Если делать одинаково каждый раз, изменения становятся предсказуемыми даже в большой fabric.

Алиасы и зоны: простая структура

Алиасы должны отражать устройство и порт, а зоны - пару «инициатор-таргет».

Подход, который обычно хорошо живет в эксплуатации:

• Алиасы: SRV_<host>_HBA1, SRV_<host>_HBA2, STG_<array>_P1, STG_<array>_P2
• Зоны: Z_<host>_HBA1_<array>_P1 (одна зона на один путь)
• Конфиг: один активный cfg на fabric, например CFG_PROD

Старайтесь избегать «широких» зон с большим числом членов: их сложнее проверять и сложнее разбирать в инциденте.

Типовой порядок команд (логика)

Смысл последовательности простой: сначала создаем алиасы и зоны, затем добавляем в cfg, и только потом включаем.

alicreate "SRV_APP01_HBA1", "10:00:00:00:00:00:00:01"
alicreate "STG_A_P1",        "50:00:00:00:00:00:00:A1"

zonecreate "Z_APP01_HBA1_STGA_P1", "SRV_APP01_HBA1; STG_A_P1"

cfgadd "CFG_PROD", "Z_APP01_HBA1_STGA_P1"

cfgenable "CFG_PROD"
cfgsave

Ключевое правило: не делайте cfgenable, пока не уверены, что правите нужный cfg и добавляете только нужные зоны.

Как не получить неожиданные изменения при cfgenable

cfgenable применяет конфигурацию целиком, поэтому «сюрпризы» появляются из-за чужих незасейвленных правок или путаницы с cfg.

Перед активацией проверьте:

• какой cfg сейчас активен и какой вы собираетесь включить
• нет ли параллельных работ и правок zoning
• корректны ли WWPN (ошибка часто выглядит как «тихо не работает»)
• состояние нужных портов (online, правильная скорость)
• счетчики ошибок на портах (CRC, link resets), чтобы не списать проблему линии на zoning

Если сомневаетесь, подготовьте алиасы и зоны, но отложите cfgenable до согласованного окна. Это дешевле, чем ловить массовый re-login и жалобы приложений.

Cisco MDS: практические правила и типовой порядок команд

На Cisco MDS чаще ошибаются не в синтаксисе, а в контексте: неправильный VSAN, не тот fabric, не те порты. Поэтому начните с проверок, и только потом создавайте зоны.

Device-alias и naming: как не запутаться

Используйте device-alias для всех хостов и портов СХД и держите единый шаблон имени (например, srv-<имя>-hba0, stor-<имя>-p1). Главное, чтобы alias однозначно соответствовал WWPN, а не «как принято на площадке».

Пара правил, которые обычно лучше всего защищают от ошибок:

• Работайте через alias, а не напрямую по WWPN (кроме аварийных случаев).
• Одна зона под одну понятную пару «инициатор - таргет», без лишних участников.
• Отдельные zoneset для каждого VSAN.
• Изменения вносите в неактивный zoneset и активируйте только после проверки.
• Делайте изменения симметрично на обоих fabrics (A/B), но по очереди, чтобы оставалось окно отката.

Зоны, zoneset, VSAN и активация

Ниже типовой порядок команд. Он не единственный, но обычно безопасный: сначала имена, потом зоны, потом добавление в zoneset, и только затем активация в нужном VSAN.

conf t
  device-alias database
    device-alias name srv-app01-hba0 pwwn 20:00:00:xx:xx:xx:xx:01
    device-alias name stor-a-ct0-p1  pwwn 50:00:00:yy:yy:yy:yy:11
  device-alias commit

  zone name Z_APP01_CT0_P1 vsan 10
    member device-alias srv-app01-hba0
    member device-alias stor-a-ct0-p1

  zoneset name ZS_PROD vsan 10
    member Z_APP01_CT0_P1
end

zoneset activate name ZS_PROD vsan 10

Если у вас несколько VSAN и разные fabrics, фиксируйте это в имени (например, ZS_PROD_V10, ZS_TEST_V20) и не полагайтесь на «я точно в том контексте». На втором fabric повторяйте те же шаги, но проверяйте, что WWPN и VSAN совпадают с планом.

После активации не ограничивайтесь тем, что команда «прошла». Проверьте факты: зона действительно в активном zoneset нужного VSAN, члены соответствуют ожидаемым WWPN, инициатор и таргет видны в Name Server, логины поднялись, а на хосте и на СХД появились нужные пути без лишних устройств.

Проверки до и после: что обязательно валидировать

Проблемы возникают, когда ожидания не совпали с фактом. Перед изменениями стоит потратить 10 минут на проверки и зафиксировать, что именно вы хотите получить.

До изменения: что проверить

• WWPN: правильные ли HBA у сервера и правильные ли порты/WWPN у массива (частая ошибка - перепутали HBA0 и HBA1 или взяли WWNN вместо WWPN).
• Текущая видимость: какие устройства уже видит сервер и какие зоны уже есть для этих WWPN.
• Конфликт имен: одинаковые алиасы или зоны с разным содержимым (часто появляется после ручных правок разными людьми).
• Принцип «минимального доступа»: в планируемой зоне только сервер и нужные порты массива.
• Исходное состояние: снимок активной конфигурации (чтобы было куда откатиться и с чем сравнить).

Чтобы сравнение было быстрым, заранее заполните простую таблицу ожиданий:

Сразу после изменения: что подтвердить

Проверяйте не только «появилось ли», но и «не появилось ли лишнее». Сравните фактическую картину с таблицей: видны ли ровно ожидаемые порты массива, поднялись ли пути с обеих HBA, нет ли дополнительных таргетов.

Если у сервера есть мультипасинг, убедитесь, что пути распределены по фабрикам так, как задумано (например, по одному пути через каждую). При двух фабриках проверьте, что изменения внесены симметрично.

В журнал изменений стоит записать минимум:

• кто и когда вносил правку
• что менялось (WWPN, алиасы, зоны)
• цель (какой сервер, какая СХД, для какой задачи)
• результат проверки (ожидалось/получилось)
• план отката

Частые ошибки и ловушки в zoning

Инциденты в zoning обычно происходят не из-за сложных команд, а из-за мелких несоответствий в данных и привычки «сделать быстро».

Путаница с идентификаторами и «старыми» портами

Классика - перепутать WWNN и WWPN. Для zoning почти всегда нужен WWPN конкретного порта HBA, а не WWNN узла. Ошибка выглядит невинно: зона активируется, но хост не видит LUN, потому что в фабрику внесен «не тот» идентификатор.

Вторая частая история - устаревший WWPN. Сервер переустановили, заменили HBA, перенесли VM между хостами, а в документации и в алиасах остался старый WWPN. В результате вы открываете доступ «в пустоту», а нужный порт остается без зоны.

Когда зона «слишком широкая»

Зоны с несколькими инициаторами (несколько серверов в одной зоне с одним таргетом) дают неожиданные эффекты: лишние регистрации, сложнее найти источник проблем при RSCN, выше шанс, что кто-то случайно получит доступ не туда. Делайте так только по понятной причине и фиксируйте ее.

Перед активацией полезно пробежать глазами типовые ловушки:

• В алиасе указан WWNN вместо WWPN, или WWPN взят не от того порта.
• Используются «исторические» WWPN после замены HBA или миграции.
• В одной зоне больше одного инициатора без явной необходимости.
• Правки делаются прямо в активный zoneset без плана отката и точки «как было».
• Имена зон и алиасов не повторяемые и не объясняют состав.

Несогласованность Fabric A/B

Отдельная боль - когда Fabric A настроен правильно, а в Fabric B забыли добавить вторую пару WWPN или активировать набор. Снаружи это выглядит как «все работало, но один путь упал»: один HBA логинится и видит хранилище, второй висит без доступа, и мультипасинг уходит в degraded.

Чтобы снизить риск, держите простой минимум:

• Имена алиасов: роль + хост + порт (например, SRV01_HBA0).
• Имена зон: инициатор + таргет + fabric (чтобы видно было состав).
• Перед активацией сверяйте, что изменения симметричны в A и B.
• Делайте снимок текущей конфигурации, чтобы можно было быстро вернуть.

Такая дисциплина особенно важна в больших инфраструктурах, где подключают десятки серверов и СХД, включая локально произведенные платформы и серверы: ошибка в одном WWPN легко превращается в цепочку инцидентов.

Короткий чеклист перед нажатием Activate/Enable

Перед активацией остановитесь на 2 минуты. Большинство инцидентов происходит из-за мелких несостыковок: перепутанный WWPN, неправильный zoneset, или зона, которая случайно затронула лишний хост.

Проверьте перед тем, как нажать Brocade Activate или Cisco MDS enable zoneset:

• WWPN подтверждены по двум источникам (например, из ОС/утилиты HBA и из fabric login). Вы точно знаете, где инициаторы и где таргеты.
• Алиасы созданы по одному шаблону и читаются однозначно (хост, HBA A/B, массив, порт). Нет «свободного текста» и похожих имен.
• Каждая зона сделана по принципу: один инициатор и только нужные таргеты.
• Вы добавляете зоны в правильный zoneset/cfg и в правильную fabric/VSAN. Контекст (fabric и VSAN) проверен дважды.
• План отката записан и реалистичен: что именно возвращаете назад, какой командой, и что проверяете после.

После этого сделайте короткую «мысленную симуляцию»: что изменится для конкретного сервера? При подключении нового хоста должны появиться только нужные пути к массиву, а у соседних хостов ничего не должно измениться.

Если в команде нет единого шаблона имен и правил зон, закрепите их в регламенте. На проектах интеграции (включая инфраструктуру ЦОД) такие чеклисты обычно экономят часы простоя и разборов.

Пример из жизни: подключаем новый сервер к СХД без сюрпризов

Типовая задача: новый сервер с двумя HBA, два FC-коммутатора (Fabric A и Fabric B) и массив с двумя контроллерами (SP A и SP B). Цель простая: дать серверу доступ только к нужным LUN и не задеть существующие хосты.

Сначала собираем данные и раскладываем их по fabrics. На сервере берем WWPN каждого порта HBA (не путать с WWNN). На массиве заранее определяем, какие target-порты будут принимать подключения в Fabric A и в Fabric B, и фиксируем их WWPN. Дальше правило: HBA0 работает только с target-портами Fabric A, HBA1 - только с target-портами Fabric B. Так меньше шансов случайно «перемешать» пути.

Перед правками удобно сделать заготовку на один change:

• имя хоста и его HBA0/HBA1 WWPN
• target WWPN контроллеров для Fabric A и Fabric B
• названия будущих зон (по одному шаблону)
• список того, что не трогаем (существующие зоны/алиасы)
• окно работ и план отката

Дальше zoning делаем по принципу «один инициатор - один таргет» (single initiator, single target). В каждой fabric создаем отдельную зону: HBA0 -> targetA и HBA1 -> targetB. Так фабрика не открывает лишний доступ: даже если на массиве где-то ошиблись, лишние устройства не появятся на уровне SAN.

Важно помнить: доступ к LUN все равно должен ограничиваться маскированием на СХД (host/initiator groups, LUN mapping).

После активации проверяем, что поднялись все пути: на коммутаторе порты в Online, сервер видит таргеты, а в ОС/мультипасинге пути в ожидаемом статусе (например, Active/Optimized).

Если часть путей не поднялась, чаще всего причина в одном из пунктов:

• перепутали WWPN (взяли WWNN или не тот порт HBA)
• зона создана в неправильной fabric или с неправильным target-портом
• порт на коммутаторе не залогинен (кабель/SFP/скорость)
• на массиве не сделано mapping для нужного initiator
• в сервере отключен порт HBA или неверные параметры драйвера

Такой сценарий обычно проходит спокойно, потому что каждое изменение локальное и легко проверяется по шагам.

Следующие шаги: стандарты, регламент и поддержка

Когда базовые правила понятны, главный способ снизить риски дальше - договориться об одинаковом подходе для всех. Zoning редко ломается из-за самой технологии. Чаще проблема в разном «стиле» изменений и отсутствии общего порядка.

Стандарт имен и шаблоны

Начните с единого нейминга и пары шаблонов зон. Хорошие имена позволяют заметить ошибку еще до активации, например, когда в названии неожиданно фигурирует порт другого хоста.

Практичный минимум:

• единый формат имен алиасов, зон и конфигов (хост, HBA-порт, СХД, фабрика, среда)
• шаблон «один хостовый порт - один порт СХД» (или другой выбранный стандарт) и понятное правило, когда допускаются исключения
• короткий набор примеров (пусть даже в виде небольшого документа), чтобы новички не придумывали заново

Регламент изменений и «гигиена» SAN

Регламент должен быть коротким и обязательным. Он защищает от суеты: кто согласует, когда делаем, как откатываем, что проверяем, где фиксируем.

Обычно достаточно:

• план работ: что меняем, на каких портах, какие зоны затрагиваем
• окно работ и критерии «стоп», если что-то пошло не так
• откат: что возвращаем и в каком порядке
• проверки до и после и журнал изменений

Раз в квартал или раз в полгода полезно пересматривать зоны: убирать неиспользуемые связи, «временные» доступы и мусорные алиасы. Это снижает шанс случайно задеть живой путь при следующем изменении.

Если нужна помощь в проектировании SAN или сопровождении, полезно привлекать интегратора, который возьмет на себя стандарты, регламент и дежурство. Например, GSE.kz (gse.kz) как системный интегратор работает с инфраструктурой ЦОД и поддержкой 24/7, что удобно, когда изменения в SAN приходится делать в жесткие окна и с обязательной фиксацией результата.