MD3000i SAN - обновление прошивки в режиме реального времени
У меня есть MD3000i Dell SAN с двумя контроллерами. Короче говоря - ему удалось испортить некоторые из своих собственных показаний на дисках, и поддержка Dell сказала мне, что я мог бы попытаться избавиться от него с помощью прошивки и обновления NVSRAM, которые мне все равно нужны. Поскольку у меня есть двойной контроллер, это, очевидно, можно сделать вживую, и процесс обновления обрабатывает перестановки LUN между контроллерами при обновлении.
У кого-нибудь есть опыт с этим? Технический специалист Dell утверждал, что это можно сделать, и документация предлагает то же самое для конфигураций с двумя контроллерами, но я очень нервничаю.
Мои основные вопросы:
- Кто-нибудь сделал это успешно или знает кого-то, кто это сделал?
- Есть ли подводные камни, о которых следует знать?
2 ответа
Я успешно выполнил подобное обновление на том же аппаратном уровне по очень похожим причинам в нескольких случаях. Мой опыт был хорошим и не требовал простоев, хотя он был ограничен парой хостов esx 3. Определенно нужно иметь хорошие резервные копии и выполнять во время окна обслуживания.
Только вчера вечером у меня было плохое обновление прошивки для моего HP san, и потребовалось три часа, чтобы его очистить. Это включало более часа простоя для всех виртуальных машин, использующих это хранилище.
Я пытался заменить контроллер San 2 раза, 1 хорошо, 1 плохо.
Первый раз был с кластером vsphere, второй - с отказоустойчивым кластером Windows.
Оба обслуживания включали замену контроллера и синхронизацию встроенного ПО контроллера (обновление встроенного ПО на старом контроллере с новым на новое).
В первый раз все прошло очень гладко.
Во второй раз, хотя в процессе обновления ни один путь san не был потерян, все луны были видны все время. почему-то был запущен отказоустойчивый оракул, и первичный сервер попытался перенести роль на вторичный сервер, но потерпел неудачу, вторичный сервер не смог обнаружить это и забрать базу данных, что привело к приостановке обслуживания.
Причина второго случая была все еще неясна, хотя одной из возможностей была неправильная конфигурация программного обеспечения кластера. Я определенно рекомендовал бы окна обслуживания, только ради стабильности.