Лучшие практики добавления второго коммутатора FC в фабрику в производственной среде?

Лучшие практики добавления второго коммутатора FC в фабрику в производственной среде?

У меня сейчас в работе один коммутатор Brocade Silkworm 200e. Через него к массиву clariion cx3 подключены сервер corp exchange и 3 хоста ESX 3.5. Порты 0,1 — это SPA0 и 1, а порты 4,5 — это SPB0 и 1.

Мой план состоит в том, чтобы добавить коммутатор Brocade Silkworm 300 рядом с коммутатором 200 (он уже установлен в стойку и включен), пойти в центр обработки данных, вытащить SPA1 и SPB0 из коммутатора 200 и вставить их в порты коммутатора 300.

Я немного параноидально отношусь к вытаскиванию путей FC, которые находятся в производстве. У меня есть логическое предположение, что все просто перейдет на SPA0 и SPB1, а A1 и B0 не будут пропущены. Однако я хотел бы иметь 100% четкое понимание того, что я могу сделать, чтобы еще больше минимизировать риски, если это возможно.

Если LUN в настоящее время принадлежит SPA, использует ли он автоматически и SPA0, и SPA1 в циклическом режиме или коммутатор предпочитает определенный путь исключительно, если только не произошел сбой? Пример — использует ли сервер Exchange SPA0 или SPA1, или он использует и 0, и 1 активный/активный?

Я предполагаю, что если он использует оба пути к SP active/active, то прерывание одного из них менее рискованно, потому что я уверен, что он уже использует другой путь без проблем. Я боюсь принудительного переключения на альтернативный путь, который он раньше не использовал, а затем обнаружить, что кабель был шатким или что-то в этом роде.

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

Как бы вы отслеживали отказоустойчивость по мере ее возникновения? Будет ли Brocade 200e вести подробный журнал? Мне нужна максимальная уверенность в том, что все будет работать, когда я вытащу эти вилки. Я могу повторно просканировать хранилище на хостах esx и посмотреть монитор powerpath Exchange. Что-нибудь еще лучше, что я могу сделать?

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

решение1

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

Вы не говорите, есть ли у ваших серверов несколько HBA или нет. Я бы на это надеялся, так как это позволит вам правильно перенастроить избыточные фабрики, но если нет, то это не окажет существенного влияния на ваш непосредственный план.

Powerpath будет обрабатывать отказоустойчивость для сервера Exchange и должен выбрать путь через A1, когда A0 отключен, а не B0 или B1, если только оба порта SPA не вышли из строя. Если какие-либо пути не работают, он сообщит вам об этом, или, по крайней мере, вы не увидите ожидаемых путей. В зависимости от того, какая у вас версия Powerpath (например, версия SE или полностью лицензированная версия), у вас могут быть активны политики балансировки нагрузки с несколькими путями, но в любом случае отказоустойчивость пути должна быть надежной для описанной вами настройки. Если вы случайно отключите активный путь, Powerpath перенаправит неисправные IO через альтернативный путь, если они исправны. Вы можете проверить состояние пути в графическом интерфейсе Powerpath или из командной строки, используя powermt checkдля проверки неисправных\новых путей или и powermt restoreдля проверки и удаления\добавления неисправных\новых путей. Если политика пути уже установлена ​​для балансировки нагрузки и есть исправные пути, видимые как через SPA0, так и через SPA1 (например), то у вас довольно высокая степень уверенности в том, что все в порядке.

На серверах ESX вы должны иметь возможность проверить пути, доступные для каждого LUN, на вкладке VI Client->Configuration->Storage. В свойствах вы можете увидеть доступные пути, которые активны и которые находятся в режиме ожидания, а в диалоговом окне Manage Paths вы можете изменить политику (Fixed\MRU\Round Robin). Вам не нужно ничего менять, но снова вам нужно будет убедиться, что путь аварийного переключения, который вы хотите использовать, доступен. Опять же, стек многопутевого переключения ESX будет обрабатывать аварийное переключение, если IO находятся в полете на активном пути, он перенаправит их на другой путь, если обнаружит, что он неисправен. ESX 3.5 поддерживает многопутевой режим round robin только экспериментально, поэтому в этом случае вам не захочется с ним возиться. Вы можете временно установить политику фиксированного пути и принудительно переключить LUN на нужный вам путь, если вы хотите быть проактивными, но стандартная настройка для CX3 — оставить его на MRU, и это должно быть нормально.

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

Связанный контент