Приостановка передачи в SAN

Один из читателей блга прислал мне чрезвычайно интересный вопрос по поводу приостановки передачи данных в фабрике. Дмитрий, большое спасибо.
Ответом я решил поделиться со всеми и сделал из него такой короткий пост. Сори, если он получился слишком техническим и не понятным…

Одними из наиболее распространенных причин приостановки передачи данных в фабрике сети SAN являются процессы перестроения (Build Fabric) и реконфигурации фабрики (Reconfigure Fabric).

Для начала разберемся в принципиальных различиях между ними.
Процесс Build Fabric (BF) является не разрушающим (non-disruptive), т. е. хотя передача данных на какой-то небольшой период времени приостанавливается, но никакая информация не теряется. Это связано с тем, что списки Domain ID не обнуляются и адресация всех устройств гарантированно сохраняется. Principal Switch, приоритеты и маршруты передачи остаются прежними. Открытые exchange не сбрасываются.

Процесс Reconfigure Fabric (RCF), напротив, является разрушающим (disruptive) и передаваемые данные всегда теряются. Ведь списки Domain ID непременно сбрасываются и Domain ID назначаются заново. Если Domain ID какого-либо коммутатора изменился, после обязательного повторного логина в фабрику всех оконечных устройств изменятся и адреса соответствующих N-портов. При RCF весь трафик класса F прерывается. Обязательно начинается процесс перевыборов Principal Switch. По времени RCF продолжительнее, чем BF.

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

• Новый коммутатор с чистым списком Domain ID присоединяется к уже функционирующей фабрике. Ему нужно назначить Domain ID, поэтому начнется процесс BF.
• Сливаются две продуктивные фабрики, имеющие собственные списки Domain ID. При этом, одинаковых Domain ID в этих фабриках нет. В этом случае необходимо вместо двух независимых Principal Switch выбрать один. В ходе процесса BF выбирается новый единый Principal Switch.
• Предыдущий случай, но в фабриках есть совпадающие Domain ID. Конфликт надо разрешить, поэтому начинается процесс RCF.
• Соединяются два новых коммутатора с девственно чистыми списками Domain ID. Начинаются выборы Principal Switch и, соответственно, процесс BF (или RCF).
• Если по каким-то причинам разрывается upstream principal ISL. Для нахождения альтернативного пути запускается BF. Если такой путь не найден, то после BF проходит RCF.
• Если какой-то коммутатор пытается достигнуть Domain ID, которого нет в фабрике, Principal Switch начинает RCF.
• В случае наличия сегментированных портов, модернизация микрокода может вызвать BF или даже RCF.
• При разрыве trunk master в 1Gbps и 2Gbps коммутаторов Brocade запускается BF.
• Если Principal Switch выключился или начал перегружаться, начинаются перевыборы и процесс RCF.
• Если по какой-то причине процесс BF закончился не удачно (не были получены пакеты подтверждения), начинается RCF.
• В коммутаторах Cisco вы можете принудительно вручную рестартовать домен. При disruptive restart запускается RCF, при nondisruptive restart – BF. Сделать disruptive restart обязательно придется, если захочется сменить текущее значение Domain ID (например, для разрешения конфликта). Изменение параметра Preferred Domain ID по понятным причинам потребует всего лишь nondisruptive restart.

Избежать задержек передачи данных в результате BF или RCF не возможно. Ведь эти процессы предназначены для обеспечения жизнедеятельности самой фабрики. Однако, в некоторых случаях можно значительно сократить время BF и минимизировать его влияние на коммутаторы. Так, в коммутаторах Cisco при включенной опции fast restart, выход из строя Principal Link не вызывает полноценный Build Fabric. Если между коммутаторам существует дублирующий линк, то процесс его назначения Principal Link затронет не всю VSAN, а только два соответствующих коммутатора и займет всего несколько миллисекунд. Если дублирующего линка нет, то опция, конечно не поможет…

Остается вопрос, как же все-таки минимизировать воздействие описанных выше процессов на SAN? Ответ вы, конечно, знаете сами. Обязательное построение сети хранения в виде двух физически или логически (VSAN) изолированных друг от друга redundant фабрики вкупе с ПО multipathing!!!

Добавлено Brocade утверждает,что в современных релизах FOS Reconfigure Fabric никогда не происходит.  Охотно верю.