Нюансы работы Principal switch

В комментариях к посту Приостановка передачи в SAN Виктор (кстати, огромное спасибо) задал очень интересные вопросы. Чтобы их не потерять, я решил ответить в отдельном посте.

Вопросы синим, ответы зеленым.

1) В той статье, на стр.51 указывается, что если Fabric стабильна и если подключается новый switch, то выборы Principal switch не происходят. Что означает "стабильна"? 

“Стабильна” в данном контексте означает, что в фабрике не происходит процессов перевыборов Principal коммутатора или других переходных процессов.

Правда ли, что если Fabric имеет несколько switch-ей, и если на них выключено питание, а затем включено, то 1-й из них, кто загрузится быстрее будет Principal switch?

Да, если они заранее соединены ISLs между ними.

Тогда, как в этом случае форсировать выборы другого Principal switch-а, когда все остальные switch-и загрузятся если мне этого захочется и кстати: а какая может быть объективная причина это сделать, если Fabric работает без проблем?

Principal коммутатор рекомендуется загружать в первую очередь. Форсировать можно выключением текущего Principal, тогда назначится коммутатор с установленным флагом Principal Selection Mode или с минимальным WWN.

Если все работает без проблем, я считаю, форсировать ничего не надо. Однако поставить флаг все же стоит. Эта процедура совершенно безопасная, а соответствующий Principal коммутатор будет выбран (важно, что здесь используется “жесткий” термин selected, а не “справедливый” elected) после следующей модернизации микрокода.

2) Можно ли более подробно пояснить: как выполняется сравнение WWN как операция над ASCII строками при выборе Principal switch? Вы сравниваете два WWN: 10:00:00:0d:ec:01:00:00 и 10:00:00:0d:ec:0a:00:00. ASCII код a (97) больше, чем ASCII код 1 (49). Выигрывает меньшее по идее.

Да, вы правы. В статье ошибка, должно быть наоборот.

Так как свои статьи я обычно перечитываю достаточно редко, то обнаружил ее совершенно случайно только прошлым летом. Интересно, что до вас ее никто еще не заметил ;) или поленился сказать.

3) Могли бы ли вы пояснить ситуацию со временем: одна из функций Principal switch – синхронизация времени во всей Fabric. Как тогда следует пользоваться командами «tsclockserver ip_addr_ntp_server» и «date»? По идее я должен дать их только на Principal switch?

Команда tsclockserver используется для синхронизации Principal коммутатора с NTP сервером, соответственно пользоваться ей надо только на Principal switch.

Как тогда Principal switch заставит другие switch-и синхронизировать время с его собственным?

Principal switch будет периодически (каждые 64 сек.) рассылать другим коммутаторам ELS фреймы с адреса FFFFF6.

Надо ли что-то делать на других switch-ах?

Нет, все распространение апдейтов времени на остальные коммутаторы происходит автоматически. На всех коммутаторах есть свой локальный Time Server daemon (LOCL), однако с NTP сервером соединяется и бродкастит время только Principal switch. Получив апдейт, коммутатор переписывает свои локальные установки времени.

Что произойдет со временем, если произойдут перевыборы Principal switch-а?

При присоединении к фабрике новый коммутатор получает от Principal switch IP адреса всех NTP серверов и сохраняет их где-то во flash памяти. Я предполагаю, что после перевыборов новый Principal switch просто синхронизируется с NTP сервером.

4) Насчет zoning: если я хочу использовать только лишь zoning на основе PID, то мне следует опасаться перевыборов Principal switch? Тогда единственный способ избежать проблем – это включить на каждом switch-е Insistent Domain ID Mode командой «configure» ?

Включенный флаг Insistent Domain ID Mode вообще является best practice не зависимо от способа зонирования. В случае использования в любых настройках фабрики или адресации оконечных устройств 24-битных адресов PID, этот параметр становится критичным и обязательным к применению.

5) В целом: в чем заключается весь полезный функционал Principal switch? Только лишь в автоматическом назначении Domain ID и синхронизации времени?

Это основные его функции. Замете, принципиально важные для функционирования фабрики.

Также Principal switch участвует в выборе Principal ISLs, по которым в дальнейшем будет передаваться информация об изменении конфигурации фабрики. Spanning tree гарантирует невозможность “закольцовывания” служебного трафика.

Сейчас точно не припомню в каких коммутаторах (Brocade, Cisco или McData) (где-то записано, но на бумажных носителях Ctrl-F не работает ;( ) управление и мониторинг фабрикой осуществляется только через Principal switch. Т. е. даже когда вы задаете команду с какого-то другого коммутатора, она по протоколу IPFC (не путать с FCIP) засылается на Management server,находящийся на Principal switch, который, в свою очередь, формирует ответ и посылает обратно на коммутатор, с которого пришел запрос. Именно по этому рекомендуется “рулить” фабрикой с Principal коммутатора.

Добавлено в ответ на комментарий все-таки нашел в своих записях упоминание о том, что так работают коммутаторы Cisco. Источник - общение за кофе с преподавателем курсов по Cisco MDS в 2006 г. Если это правда, то и в современных коммутаторах так.

Какова ситуация с Brocade не знаю. При случае спрошу (важно знать кого   ;)   ).

В документации по Cisco упоминание про Principal switch так найти и не смог.Есть более пространное: "An NMS (network management systems) host running IP protocol over a FC interface can access the switch using the IPFC functionality. If the NMS does not have a Fibre Channel HBA, in-band management can still be performed using one of the switches as an access point to the fabric."