Brocade SAN Часть 9: NPIV и режим Access Gateway

NPIV позволяет нескольким экземплярам виртуальной ОС на одном и том же физическом сервере иметь свой собственный WWPN, что позволяет другим сетевым устройствам рассматривать их как разные устройства. По сути, это позволяет через один физический HBA пропускать трафик нескольких серверов (виртуальных, или, например, блейдовых), при этом строить независимый зонинг для каждого из них. С повсеместным использованием виртуализации — эта технология стала крайне актуальной.

Каждый физический порт может обслуживать до 256 виртуальных портов. Стоит отметить, что NPIV используется не только с серверами. Массивы NPIV используют технологию SVM (Storage Virtual Machines), которая позволяет изолировать совместно используемые дисковые ресурсы. Каждый SVM может иметь собственные тома, порты и т.д. и может управляться разными администраторами (в рунете есть несколько блогов, посвящённых СХД компании NetApp, наиболее популярные из них — http://blog.aboutnetapp.ru который вёл Роман Хмелевский, ныне инженер компании Nutanix и https://alikulov.me/blog/ который вёл Артур Аликулов, инженер по СХД NetApp в компании Мерлион. К сожалению, оба блога уже не активны, но полезной информации оттуда можно получить очень много, так что, если вы только столкнулись с массивами NetApp — крайне рекомендую к ознакомлению).

Для корректной работы с NPIV на вашем коммутаторе на портах должна быть включена опция «NPIV capability». Она не требует лицензирования, поддерживается всеми коммутаторами со времён 4Gb/s и по умолчанию включена.
Со стороны коммутатора это выглядит следующим образом
switch:admin> switchshow
…
Index Port Address Media Speed State Proto
==================================================
2 2 0b0200 id N8 Online FC F-Port 1 N Port + 1 NPIV public
3 3 0b0300 id N8 Online FC F-Port 1 N Port + 1 NPIV public
…

Как можно заметить, данный вывод немного отличается от того, что мы видели раньше, в частности — на портах не видны WWN устройства, которое к нему подключено. Но коммутатор говорит о том, что у нас подключен N_Port, т.е. порт устройства и на нём есть один виртуальный WWN. Что бы увидеть адреса, нам необходимо посмотреть информацию по порту:
switch:admin> portshow 2
…
portWwn of device(s) connected:
20:06:00:a0:98:ad:28:69
50:0a:09:81:80:b2:42:7c
…

Я специально убрал весь лишний вывод — какую информацию можно получить при помощи команды portshow мы обсуждали уже ранее, а в данном примере я хочу лишь показать только интересующую нас информацию о подключенных девайсах. Что бы получить больше информации о том, что за устройства имеют эти WWN мы воспользуемся командой nodefind
switch:admin> nodefind 50:0a:09:81:80:b2:42:7c
Local:
Type Pid COS PortName NodeName SCR
N 0b0200; 3;50:0a:09:81:80:b2:42:7c;50:0a:09:80:80:b2:42:7c; 0x00000000
PortSymb: [44] «NetApp FC Target Adapter (8324) oncloud_1:0e»
NodeSymb: [36] «NetApp FAS8200 (oncloud_1/oncloud_2)»
Fabric Port Name: 20:02:00:27:f8:de:cc:f8
Permanent Port Name: 50:0a:09:81:80:b2:42:7c
Device type: Physical Unknown(initiator/target)
Port Index: 2
Share Area: No
Device Shared in Other AD: No
Redirect: No
Partial: No
LSAN: No
Aliases:

switch:admin> nodefind 20:06:00:a0:98:ad:28:69
Local:
Type Pid COS PortName NodeName SCR
N 0b0201; 3;20:06:00:a0:98:ad:28:69;20:05:00:a0:98:ad:28:69; 0x00000003
FC4s: FCP
PortSymb: [59] «NetApp FC Target Port (8324) FC_old_cluster:FirstClass_1_0e»
NodeSymb: [29] «NetApp Vserver FC_old_cluster»
Fabric Port Name: 20:02:00:27:f8:de:cc:f8
Permanent Port Name: 50:0a:09:81:80:b2:42:7c
Device type: NPIV Target
Port Index: 2
Share Area: No
Device Shared in Other AD: No
Redirect: No
Partial: No
LSAN: No
Aliases: FirstClass_8200_1_0e

Как мы видим, устройство с WWN 50:0a:09:81:80:b2:42:7c — это физический порт NetApp FC Target Adapter. По сути, это адрес HBA, установленной в СХД NetApp, второй же адрес — 20:06:00:a0:98:ad:28:69, как мы видим из описания — NPIV Target и относится к виртуальному серверу NetApp с именем FC_old_cluster. NetApp Vserver — это как раз и есть те самые SVM, о которых я говорил выше. Как можно видеть из этого же примера — физический адаптер не имеет алиаса, а я могу сказать, что он и не участвует в зонинге. А вот виртуальный порт имеет алиас и используется в зонинге с хостами, которым презентованы луны из этого SVM.

Коммутаторы Brocade могут работать в специальном режиме — Access Gateway. После того, как коммутатор был переведён в режим Access Gateway, он больше не участвует в сети SAN в качестве коммутатора Fibre Channel и не имеет служб FC, таких как зонирование, сервер имен и адресация FC. Это позволяет получить большее количество портов в фабрике, не увеличивая при этом количество администрируемых коммутаторов и упрощает настройку и управление в большой фабрике за счет сокращения количества идентификаторов и портов домена. Постараюсь привести простой пример: Blade-корзина, с установленными в неё блейдами с FC и, соответственно коммутаторными модулями FC. Перевод их (коммутаторов корзины) в режим AG позволит не делать их членами фабрики, чтобы не увеличивать её размеры (ведь корзин могут быть десятки), при этом не осуществлять конфигурирование этих коммутаторов, т.к. коммутаторы в режиме AG абсолютно прозрачны как для подключённых хостов, так и для остальных коммутаторов. Есть ещё один интересный момент в этом примере — если в ваших корзинах установлены коммутаторные модули Brocade, то вы не сможете подключить их в фабрику, построенную на коммутаторах Cisco, т.к. они не совместимы между собой, но перевод коммутаторов корзин в режим AG сделает возможным их подключение и функционирование в фабрике Cisco. Транкинг при этом поддерживается между коммутаторами в разных режимах, поэтому проблем со скоростью на подключаемых устройствах у вас не возникнет.
Достигается это за счёт того, что в режиме AG не поддерживается следующий функционал:

• FCAL
• Fabric Manager
• FICON
• IP over FC
• ISL Trunking
• Extended Fabrics
• Management Platform services
• Name services (SNS)
• Port Mirroring
• SMI-S
• Zoning

Включение режима AG
Выключим все порты, что бы остановить все операции ввода/вывода через коммутатор
switch:admin> switchdisable
Включим режим AG
switch:admin> ag —modeenable
После этого коммутатор перезагрузится

Выключение
switch:admin> switchdisable
switch:admin> ag —modedisable

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

При переключении в режим AG нас становится доступен функционал — Port mapping, который позволит распределить трафик с устройств/хостов до фабрики. Здесь нет такой возможности, которую мы обсуждали в Часть 3: FCP роутинг, когда кратчайший путь между устройствами вычислялся автоматически. В данном случае нам необходимо сопоставить порты. Конечно можно и с настройками по умолчанию, но для лучшей балансировки — придётся это выполнять самостоятельно.

Настройки мапинга можно посмотреть с помощью команды
switch:admin> ag —mapshow

К сожалению, показать вывод данной команды я не могу, т.к. под рукой у меня нет ни одного коммутатора в режиме AG.
Удаление и добавление мапинга производится с помощью команд
switch:admin> ag —mapdel
switch:admin> ag —mapadd

Могу порекомендовать посмотреть вот это видео

Оно хоть и на немецком, но презентация на английском и из вывода на консоли и так становится всё понятно.

Ещё одним важный вопросом является использование Access Gateway policies, но это я вам предлагаю почитать уже самостоятельно в Access Gateway Administrator’s Guide. Данные политики могут быть использованы для расширенной конфигурации коммутатора:

• Advanced Device Security policy
• Automatic Port Configuration policy
• Port Grouping policy
• Device Load Balancing policy
• Persistent ALPA policy
• Failover policy
• Failback policy

В конце концов данной серией статей я планировал познакомить с технологиями и возможностями, сделав это максимально просто, но не все вещи мне удаётся объяснить легко (значит сам не так хорошо их понимаю).