Назад | Перейти на главную страницу

MD3000i SAN - обновление прошивки в реальном времени

У меня есть MD3000i Dell SAN с двумя контроллерами. Короче говоря, ему удалось испортить некоторые из собственных показаний на дисках, и служба поддержки Dell сказала мне, что я могу попытаться избавиться от него с помощью прошивки и обновления NVSRAM, которые мне в любом случае нужны. Поскольку у меня есть двойной контроллер, это, очевидно, можно сделать в реальном времени, и процесс обновления обрабатывает перетасовку LUN между контроллерами при обновлении.

У кого-нибудь есть опыт с этим? Технический специалист Dell утверждал, что это возможно, и документация предлагает то же самое для конфигураций с двумя контроллерами, но это заставляет меня очень нервничать.

Мои основные вопросы:

  1. Кто-нибудь делал это успешно или знает кого?
  2. Есть ли подводные камни, о которых следует знать?

Я успешно выполнил подобное обновление на том же аппаратном способе по очень похожим причинам пару раз. Мой опыт был хорошим и не требовал простоя, хотя он был ограничен парой хостов esx 3. Определенно необходимо иметь хорошие резервные копии и выполнять их в течение периода обслуживания.

Только вчера вечером у меня было плохое обновление прошивки для моего HP san, и мне потребовалось три часа, чтобы это исправить. Это включало более часа простоя всех виртуальных машин, использующих это хранилище.

Я пробовал заменить контроллер san 2 раза, 1 хороший, 1 плохой.

Первый раз был с кластером vsphere, второй раз с отказоустойчивым кластером Windows Oracle.

Оба обслуживания включали замену контроллера и синхронизацию микропрограммы контроллера (обновление микропрограммы старого контроллера на новый).

В первый раз все прошло очень гладко.

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

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