Сейчас у меня в производстве находится единственный коммутатор Brocade Silkworm 200e. Через него к массиву clariion cx3 подключены корпоративный сервер обмена и 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 в циклическом режиме, или коммутатор предпочитает только определенный путь, если только он не отключился? Пример - использует ли сервер обмена SPA0 или SPA1, или он использует и 0, и 1 активный / активный?
Я предполагаю, что если он использует оба пути к активному / активному SP, нарушение одного из них представляет меньший риск, потому что я уверен, что он уже использует другой путь без проблем. Я боюсь принудительно переключиться на альтернативный путь, который он раньше не использовал, а затем обнаружить, что кабель был шатким или что-то в этом роде.
Должен ли я полностью нарушить работу компании и выключить все виртуальные машины и сервер обмена, чтобы убедиться, что данные не будут повреждены в случае плохой отработки отказа? Или это чрезмерно? В любом случае, я собираюсь выполнить операцию сразу же после полного цикла резервного копирования.
Как бы вы отслеживали аварийное переключение, когда оно происходит? Собирается ли парча 200e подробно регистрировать это? Мне нужна максимальная уверенность в том, что все работает, когда я вытаскиваю вилки. Я могу повторно сканировать хранилище на хостах esx и наблюдать за монитором powerpath биржи. Что я могу сделать лучше?
Я бы предпочел быть гораздо более осторожным, чем того требует ситуация, чем делать излишне самоуверенные предположения о том, чтобы сделать что-то подобное впервые, когда все наши яйца находятся в одной корзине.
Я надеюсь, что вы планируете создать вторую независимую фабрику, это вообще считается хорошей идеей.
Вы не говорите, есть ли у ваших серверов несколько 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. В свойствах вы можете увидеть доступные пути, которые являются активными и которые находятся в режиме ожидания, а в диалоговом окне «Управление путями» вы можете изменить политику (Fixed \ MRU \ Round Robin). Вам не нужно ничего менять, но вы снова захотите убедиться, что путь аварийного переключения, который вы хотите использовать, доступен. Опять же, многопутевый стек ESX будет обрабатывать отказоустойчивость, если IO находятся в полете по активному пути, он повторно отправит их по другому пути, если обнаружит, что произошел сбой. ESX 3.5 поддерживает циклический перебор нескольких путей только экспериментально, поэтому в этом случае вам не стоит возиться с ним. Вы можете временно установить политику фиксированного пути и принудительно переключить LUN на нужный вам путь, если вы хотите быть активными, но стандартная настройка для CX3 - оставить его на MRU, и это должно быть нормально.
В обоих случаях может произойти некоторая задержка до того, как произойдет переключение при отказе, и операции ввода-вывода могут ненадолго остановиться, но ничего не должно выйти из строя, если резервные пути действительно исправны.