Avago megaraid sas 9361 8i обновление прошивки
Обновлено: 05.07.2024
Добрый день!
Посоветуйте, как правильно настроить рейд-контроллер.
Контроллер: LSI AVAGO MegaRAID SAS 9361-8i с комплектом защиты LSI MegaRAID CacheVault < LSI00418 LSICVM02 > CVPM02.
Будут следующие массивы:
Диск С, Винда - 2 ССД в зеркало.
Диск Д, файл транзакций *.LDF - 2 SAS в зеркало
Диск Е, база данных SQL *.MDF - 4 SAS в Рэйд 10
Создал пробные зеркала, увидел, что если щелкнуть в утилите MegaRaid Storage Manager на дисковой группе, то параметр Data Protection - Disabled.
Есть такое подозрение, что при наличии батарейки должно быть Enabled. как перенастроить?
Подскажите, какие выбрать остальные параметры:
Write Policy
Read Policy
IO Policy
Access Policy
Disk Cache Policy
Будут ли настройки зависеть от того, что будет на массиве (винда, бд, файл транзакций).
Установлен server 2016 R2.
Заранее благодарен!
Войдите в меню контроллера при включении питания. Такие параметры настраиваются там.
Sponge Bob писал(а): Добрый день.
Войдите в меню контроллера при включении питания. Такие параметры настраиваются там.
Да, есть такое. Только я запутался. Если зайти в настройку контроллера при включении сервера, там в меню будет опция "Disable Data Protection", вот скрин:
При этом (опция=Disable Data Protection, как на скрине), в винде видим что защита на уровне контроллера включена:
а на уровне Drive Group выключена. почему и как ее включить?
mcmurphy94 писал(а): Добрый день!
Создал пробные зеркала, увидел, что если щелкнуть в утилите MegaRaid Storage Manager на дисковой группе, то параметр Data Protection - Disabled.
Есть такое подозрение, что при наличии батарейки должно быть Enabled. как перенастроить?
Среди меня есть мнение, что пар-р "Data Protection" не имеет отношения к BBU/CV-защите кеша контроллера.
Имхуется мне, что при наличии исправного BBU/CV никаких отдельных настроек для защиты кеша контроллера не нужно - он будет подпитываться от BBU или сбрасываться на флеш в случае CV по-любому, для любого LUN`а (VD) без специального указания.
А Data Protection, мнится мне, имеет отношение к опции PI контроллера - защита информации на уровне физического носителя по стандарту Т10/DIF, для работы с "нестандартными" физ.секторами (например, 520b вместо 512b и т.д) с избыточной информацией (КС/КЧ) .
Ок, спасибо!
А как правильно сделать - после создания массива запустить инициализацию (если не была выбрана опция инициализировать сразу после создания)? Это актуально и для SAS и для SSD?
Утилита от LSI MSM не пишет, был ли проинициализирован массив. Если запустить инициализацию, предупреждает, что данные будут потеряны. Это действительно так, если есть файлы, то их затрет?
К сравнению, интеловский рейд на С600 и утилита Intel Rapid позволяет запускать инициализацию на массиве с файлами и ничего не затирается. У них разные подходы?
И еще - когда надо провести проверку консистентности - уже после заполенения массива файлами, или нет?
mcmurphy94 писал(а): Ок, спасибо!А как правильно сделать - после создания массива запустить инициализацию (если не была выбрана опция инициализировать сразу после создания)? Это актуально и для SAS и для SSD?
Не уверен, что понял, как второй вопрос из вышеотквоченного сочетается/связан со первым.
Мои семантические фильтры сбоят?
Актуальна ли инициализация массива как для HDD, так и для SSD.
Или актуальна ли инициализация массива как для SAS, так и для SATA носителей?
И по запуску тоже как-то коряво спрошено.
Даже если Вы не включите фоновую инициализацию и откажетесь инициализировать массив после его создания (если БИОС контроллера допускает такое вольнодумство ), то у Вас остаётся возможность "подстраховаться" впоследствии, задействовать механизмы PR или СС (см.ниже).
Это вопросы к создателям утилиты MSM (хотя я бы их - за одну лишь тормозную явовскую морду и вечный косяк с multicast/unicast-коннектами к сетевым агентам - просто распнул бы. не смертельным, но очччень обидным образом).
Надеюсь, что про потерю данных они так "шутят"-перестраховываются. Т.к. инициализация массива может проводиться контроллером в т.ч. и в фоновом режиме прямо в процессе работы контроллера с данными на носителях.
Если это ТА ЖЕ инициализация, то нафига так пугать народ?
А если это "какая-то другая" инициализация, то. какая?
Вообще же из более-менее детальной проработки документации у меня по некоторым признакам сложилось впечатление, что пресловутая "инициализация массива" - неважно, фоновая она, или "фронт-эндная" - использует тот же механизм/алгоритм, что и так называемое "патрульное чтение" (Patrol Reading), проверяя абсолютно все блоки носителей на читабельность (и при нужде - на писабельность), с соответствующими выводами (аналог ремапа битых физ.секторов, проводимого внутри hdd или ssd их собственными фирмварями).
По итогам инициализации в метаданные массива записывается помимо прочего ещё и инфа о состоянии носителей (указание на имеющиеся "ремапы", пометки в Bad Strip Table, etc.).
И да - и инициализация, и Patrol Reading абсолютно недеструктивны для данных на массиве (конечно, при штатном развитии событий, что является нормой для исправного контроллера).
Повторюсь - LSI (как и остальные вендоры) реализовал точно такой же механизм инициализации, по сути стандарт.
Почему MSM пугает уничтожением данных - "вопрос не по окладу"(с).
mcmurphy94 писал(а): И еще - когда надо провести проверку консистентности - уже после заполенения массива файлами, или нет?
Если Вы имеете в виду СС - Check Consistency - то она, в отличие от Patrol Reading, работает только на блоках с данными (PP проверяет все блоки без исключения).
Соответственно, запускать СС на пустом массиве бесполезно.
Будем прошивать RAID контроллер: Avago MegaRAID SAS 9380-8i8e со своего компа из ОС Windows 10. Для прошивки нам потребуется утилита Avago MegaRAID Storage Manager.
Итак, втыкаем контроллер в свой комп и ставим софтину: Avago MegaRAID Storage Manager. Ссылки ниже приводятся.
Ссылки
Находим прошивку
При загрузке видим следующее:
Уже понятно, что потребуется обновление. Но где брать текущую версию? Нам нужна строчка FW package. Версия 24.19.0-0047.
Не забываем перед прошивкой подключиться к ИБП:
Итак, мы имеем текущую версию прошивки: Версия 24.19.0-0047.
Ищем свежую прошивку:
Нашёл версию. 24.22.0-0045.
Качаем, будем ставить.
Запускаю MegaRAID Storage Manager:
Подключаюсь к своей машине.
Вроде контроллер увиделся. Находим внизу ссылку Update firmware - жмакаем.
Я хочу рассказать вам о том, как я восстанавливал прошивку RAID-контроллера LSI MegaRAID после неудачного обновления.
Когда эта беда случилась со мной, то информации об этом я практически не нашел, хотя, допускаю, что плохо гуглил.
Анамнез
В своей работе я уже достаточно давно использую серверы Supermicro, так как у них есть большой выбор платформ, достаточно демократичная цена и приличная надежность.
Зачастую, особенно в случае с 1U серверами я беру их уже с интегрированным контроллером LSI MegaRAID.
Но проблема с ними заключается в том, что сама Supermicro не очень охотно выкладывает прошивки для встроенных контроллеров, так что я их обычно прошиваю актуальной прошивкой (масло масляное, да) от аналогичного контроллера LSI. Проблем не возникало до этих пор.
Недавно привезли несколько серверов с контроллерами LSI 2208 на борту и достаточно старой прошивкой.
Т.к. дискретные контроллеры на этих чипах я тоже активно использую, то особо не сомневаясь загрузился с флешки с Linux-ом, запустил привычное:
и пошел заниматься дальше своими делами.
Делаю Reset и вижу такую картину:
Да, беда. Поиски в интернетах не привели к какому-либо результату. Судя по всему, проблема достаточно редкая.
Лечение
Я попробовал загрузиться с флэшки и прошить контроллер заново, но ни под DOS, ни под Linux утилита MegaCli его уже не определяла вообще. Прошивать, соответственно, тоже отказывалась.
Так что я обратился в саппорт LSI, где добрый человек с индусским именем указал мне на документацию к MegaRAID, а именно на страницу 305, где есть такой достаточно незаметный подраздел, который толком не объясняет зачем же делать то, что в нем написано:
Ага, подумали партизаны, наверное это прошивка в режиме восстановления, и взялись за дело.
Под Windows флэшку с FreeDOS сделать проще всего используя утилиту Rufus, буквально в один клик.
Под Linux сделать аналогичное можно подручными средствами (используя syslinux или GRUB), на эту тему есть много статей.
Обращаю внимание, что указывать адаптер (опция -a) не нужно, судя по всему он прошивает все какие найдёт, либо первый попавшийся на PCI шине.
Прошивка в этом режиме занимает достаточно долгое время, около 15 минут, так что наберитесь терпения.
Когда он закончит — выключаем сервер по питанию, включаем его обратно и ждем чуда.
Но вместо чуда видим мы такую вот безрадостную картину:
Гугление по такой ошибке приводит к единственной ссылке на блог нашего соотечественника, где он на чистом английском советует отключить от контроллера BBU, вынуть контроллер из сервера и потом поставить обратно.
В моем случае вынуть карту из сервера можно только лобзиком, BBU у меня нет, так что не вариант.
Пробую прошить стандартным способом, MegaCli обнаруживает контроллер, но говорит то же самое, мол F/W is in fault state, так что ничего делать не буду.
Обращаемся опять в саппорт, который разводит руками и советует попробовать LSI Pre-Boot USB and CD tool, а если он не поможет, то сдавать железо назад.
Ок, качаем ISO, подключаем его через IPMI к серверу и грузимся.
Выбираем в меню загрузки пункт recovmr, затем нам предлагают написать в командной строке recover и наступит счастье. Но не наступило.
BAT-файл не может найти подключенный диск D:, видимо драйвер CDROM в FreeDOS на этом образе LSI не дружит с виртуальным приводом IPMI.
Хорошо, заглядываем в BAT файл и смотрим, что же он там собирался делать:
Открываем ISO, ищем этот загадочный файл и видим, что он размером аж 16 мегабайт (да, мы уже догадывались из названия), что вдвое больше стандартной прошивки. Видимо, этот образ ROM полностью переписывает микросхему Flash на контроллере.
Пытаемся прошить его так же, как это собирался делать BAT-ник, но получаем знакомое: F/W is in fault state
Да, так себе Recovery-образ подготовила нам LSI.
Ладно, используем наш предыдущий опыт и пытаемся прошить этот файл через Mode0.
На этот раз прошивка заняла минут 30, так как файл вдвое больше обычного. После прошивки обесточиваем сервер, включаем его обратно и видим заветный экран:
Салют, шампанское, сервер спасён!
Но этот живительный образ содержит не самую свежую версию прошивки, так что я с легким сердцем опять загрузился с FreeDOS-флешки и пошел прошивать его свежей прошивкой от Supermicro… и опять получил зависание на той же стадии, как в самом начале:
Круг замкнулся. Я даже для верности оставил его в таком виде на ночь, но ничего не изменилось.
После перезагрузки имеем опять битую прошивку.
Методом проб и ошибок было выяснено, что после прошивки образа восстановления нужно сделать сброс к заводским настройкам:
и выключить-включить сервер.
После этого прошивается уже без зависания, и мы видим свежую версию прошивки:
Всё, на этот раз получилась 100% победа над непокорным железом!
Выписка
Мораль сей басни такова: если не хочется потратить пару дней на восстановление или еще больше на возврат оборудования, то лучше все-таки прошиваться предназначенными производителем железа прошивками (если он их выкладывает, у того же Supermicro я ее нашел только копаясь в дебрях FTP — на странице сервера или материнской платы ссылок нет), либо ничего не трогать и жить с той, которая уже есть.
Хотя я не уверен что проблема была вызвана именно «инородной» прошивкой, а не каким-то случайным глюком, но проверять это еще раз мне не хочется.
Бывают и такие случаи, когда прошивка просто по какой-то причине портится (выключили электричество во время прошивки или еще какой гамма-всплеск случился в ближнем космосе), и тогда придётся прибегнуть к аварийному восстановлению.
Надеюсь, что эта статья поможет тем, кто наткнётся на похожую проблему в будущем.
LSI MegaRAID обновление версии firmware
Если что-то пошло не так.
У меня после перезагрузки случилась катастрофа, сервер FreeBSD на zfs отказывался грузиться
Мой пул zfs назывался tank
Чего только не попробовал за 3е суток мата.
Первое, что увидел
При загрузке ошибка:
Trying to mount root from zfs:tank [].
Mounting from zfs:tank failed with error 2 Unknown filesystem
При загрузке еще ошибки:
zfs io error all block copies unavailable warning error reading /boot/loader.conf
Пробую грузиться из пукта 3 при загрузке:
Ага, кто-то обновлял систему и забыл год назад перезагрузиться.
Вижу kernel.old, пробую грузиться со старого ядра
unload
load /boot/kernel.old/kernel
load /boot/kernel.old/opensolaris.ko
load /boot/kernel.old/zfs.ko
load -t cache /boot/zfs/zpool.cache
Не вышло, пробуем еще раз:
unload
load /boot/kernel.old/kernel
load /boot/kernel.old/opensolaris.ko
load /boot/kernel.old/zfs.ko
Пункт выбираем предыдущий (kernel) пункт "5"
Грузимся (внезапно прокатило)
Пробую прописать в лоадер:
vi /boot/defaults/loader.conf
zfs_load="YES"
vfs.root.mountfrom="zfs:tank"
zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 10.8T 10.3T 522G - - 78% 95% 1.00x ONLINE -
zfs list
NAME USED AVAIL REFER MOUNTPOINT
tank 7.71T 132G 25.4K none
tank/ROOT 1.89G 132G 25.4K none
tank/ROOT/default 1.89G 132G 1.89G /
zpool get bootfs tank
NAME PROPERTY VALUE SOURCE
tank bootfs tank/ROOT/default local
Равнозначно:
zpool set bootfs=tank/ROOT/default tank
cat /etc/rc.conf | grep zfs
zfs_enable="YES"
Не помогло, перезагрузился и ошибки снова
Пробуем по другому, грузимся до ошибок и загружаем диск
mountroot> cd9660:/dev/cd0
Trying to mount root from cd9660:/dev/cd0 [].
g_vfs_done():cd0[READ(offset=32768, length=2048)]error = 6
И тут засада.
Вот варианты, как прокатило (разные диски вставлял):
?
mountroot> cd9660:/dev/iso9660/12_0_RELEASE_AMD64_CD rw
mountroot> cd9660:/dev/iso9660/12_0_RELEASE_AMD64_DVD rw
mountroot> cd9660:/dev/iso9660/11_2_RELEASE_AMD64_DVD rw
Или так из 3его пункта:
unload
lsdev
set currdev=cd0
boot
Но есть момент, с диска все в рионли монтируется
Загружайтесь с флешки и делайте моунт корня на rw
Далее поднимаем ssh на LiveCD
ifconfig igb0 192.168.1.9 255.255.255.0
ifconfig igb0 up
route add default 192.168.1.1
mkdir /tmp/etc
mount_unionfs /tmp/etc /etc
vi /etc/resolv.conf
nameserver 8.8.8.8
vi /etc/ssh/sshd_config
PermitRootLogin yes
Импортирую и монтирую свой многострадальный пул:
zpool import -R /mnt tank/ROOT/default
mount -t zfs tank/ROOT/default /mnt
Кстати о птичках, еще когда вылезет ошибка загрузчика, делаем так:
cant find /boot/zfsloader
gpart bootcode -b /mnt/boot/pmbr -p /mnt/boot/gptzfsboot -i 1 mfid0
Где mfid0 имя устройства, у меня их 4 было, делаем на каждый
Это связано с новой версией загрузчика 12й версии FreeBSD
В общем тупо забираем загрузчик и ядро с нашей флешки
Копируем в систему многострадальную:
rm -rf /mnt/boot/*
cp -R /mnt/boot.orig/* /mnt/boot/
ls -l /mnt/boot/kernel.old/
Грузимся, у меня прошло на ура.
Устати еще кэш как включить на дисках:
mfiutil show volumes
mfi0 Volumes:
Id Size Level Stripe State Cache Name
mfid0 ( 2794G) RAID-0 64K OPTIMAL Writes
mfid1 ( 2794G) RAID-0 64K OPTIMAL Writes
mfid2 ( 2794G) RAID-0 64K OPTIMAL Writes
mfid3 ( 2794G) RAID-0 64K OPTIMAL Writes
MegaCli -LDSetProp -Cached -Immediate -Lall -aAll
Set Cache Policy to Cached on Adapter 0, VD 0 (target id: 0) success
Set Cache Policy to Cached on Adapter 0, VD 1 (target id: 1) success
Set Cache Policy to Cached on Adapter 0, VD 2 (target id: 2) success
Set Cache Policy to Cached on Adapter 0, VD 3 (target id: 3) success
mfiutil show volumes
mfi0 Volumes:
Id Size Level Stripe State Cache Name
mfid0 ( 2794G) RAID-0 64K OPTIMAL Enabled
mfid1 ( 2794G) RAID-0 64K OPTIMAL Enabled
mfid2 ( 2794G) RAID-0 64K OPTIMAL Enabled
mfid3 ( 2794G) RAID-0 64K OPTIMAL Enabled
Читайте также: