Microsoft Way

HP p410 или почем экономия

Неприятности как известно случаются всегда в самый неподходящий момент. И ровно в день когда курс национальной валюты сделал забавный скачок вверх, в «ерундохранилище» домохозяйства один из дисков решил стремительно уйти в страну вечной охоты.

На кое событие разумеется всегда следует реагировать незамедлительно:
1. Опыт показывает, что даже в дорогой дисковой полке с массивами raid-60 уведомление может придти о выходе из строя…уже второго диска четности когда подменных (spare) больше не осталось.  Где же были уведомления об отбросе предыдущих дисков? Нигде их не было.  А потому что так когда-то кто-то настроил. То есть как ни полагайся на видимую продуманность системы, а когда-то может просто не повезти.
Это пассаж к тому, что в менее солидных решениях, если один диск однозначно рапортует себя сбойным, вовсе не факт, что с остальных гарантировано получится считать информацию. Особенно если часть дисков имеет одинаковую наработку.
2. Даже если от функционирования ИТ решения зависит сайт-визитка репетитора ИПшника, информационный сайт мелкой некоммерческой организации, небольшая личная записная книжка-блог и файлохранилище, то тем не менее. Время простоя может и некритично, но потеря данных всегда неприятна. А как же содержимое возможно очень важной папки /mnt/sdm1/transfertosrv/unsorted2/myfiles5fromNtb/Unsorted2008/ ?
3. Время перестроения массива (дублирования данных в случае зеркала) очевидно прямо пропорционально объемам дисков (или одного диска в случае восстановления зеркала). Кстати именно поэтому плохой идеей являются массивы с четностью на объемных  магнитных дисках. За время восстановления может выйти из строя или еще один диск или собственные нервы.

По этим же соображениям правильный алгоритм замены диска выглядит как сначала подменить сбойный диск в raid10 массиве, дождаться синхронизации и только затем запускать проверку четности всех хранящихся данных.
Но для начала необходимо где-то взять подменный диск. А, нет, ура! Подменный же диск есть, лежит на полке в холодном резерве. Потому что использование хороших практик — это хорошая практика.

Поскольку у нас нет hotswap салазок и необходимо выключение сервера, до этого крайне желательно отредактировать fstab и исключить монтирование массива где будет заменен диск. Иначе при загрузке потребуется лишняя потеря времени.
Далее на загрузившемся сервере вручную монтируем массив с аварийной опцией, то есть
mount -o degraded /dev/sdb1 (здесь вместо sdb1 любой из составляющих массив) /mnt/sdm2

И далее смотрим, какого по номеру диска не хватает и его необходимо подменить. Новый (пустой) диск  будет всегда под номером 0. То есть вводим команду
btrfs device usage
Видим например, что missing, ID: 2. Значит его и будем заменять
btrfs replace start 2 /dev/sdh1 /mnt/sdm2

Прогресс будет долог, отслеживать его возможно так:
btrfs replace status /mnt/sdm2

После того как процесс будет завершен, необходимо провести конвертацию возможно имеющихся одиночных (без дублирования) данных. Если таких данных нет, то процесс завершится без задержки
btrfs balance start -dconvert=raid10,soft -mconvert=raid10,soft /mnt/sdm2

Теперь можно проверить все остальные данные массива и отслеживать статус процесса
btrfs scrub start  /mnt/sdm2
btrfs scrub status  /mnt/sdm2

И самое тут неприятное, если по завершению процесса результат будет содержать отличные от нуля значения исправленных ошибок. Про неисправимые лучше даже не думать. Но и такое возможно. Это означает что есть проблемы на тех дисках массива, которые до этого момента считались полностью работающими.
А бывает даже и такое: буквально через час после завершения замены диска в массиве, система прислала сообщение о том, что на установленном подменном диске smart зафиксировал плохой сектор и диск сделал его rеmap. Чуть выше уже упоминалось:  как ни полагайся на видимую продуманность системы, а когда-то может просто не повезти. И размышлять как же так получилось, времени прямо скажем нет, нужно что-то делать.

Напомню вводную: только что произошло резкое изменение курса национальной валюты, а значит:
— Некие паникеры кинулись скупать все подряд, слабо думая, а зачем им еще три диска и два телевизора
— Тут же продавцы не растерялись, подняли цены в два раза и заявили, что у них нет ничего в остатках, все только новые закупки, а значит новая цена оправдана
— Продавцы на площадках торговли б.у. комплектующими, явно с криками «ура, дефицит!» столь же необоснованно подняли ценники на свое хилое-дохлое-в-рейс-ходившее. То есть вплоть до того, что вчерашний диск стомостью 50$ (по курсу) сегодня стал стоить 80$(и это по новому курсу). То есть в национальной валюте цена изменилась раза в 4.
— Восстанавливаемое решение не является инфраструктурой для бизнеса и тратить на нее существенные финансовые ресурсы прямо скажем неразумно.

Ок, начинаем проявлять смекалку.
Во-первых, в срочном порядке придется сократить количество «лишней» информации дабы все уместилось на меньшее количество дисков. Или часть временно вынести в облако/внешние носители/разное.
А далее обратить свое внимание на бывшие в эксплуатации sas диски. Причем спустя недельку. Цена может даже подупасть. Правда с sas и рисков больше: вовсе не факт, что они работали в охлаждаемой серверной, а не кипятились 24х7 в углу душного подвала.

Поищем контроллер, вроде даже где-то был. Был… А был ли он? Да, есть. HP p400. И радиатор приклеен и батарейка переделана на ААА аккумуляторы, даже жаль что прошлый проект не взлетел: пока искалось время на реализацию, появились и SSD по разумным ценам и сменилась специфика профессиональной деятельности. Массив на много iops под виртуальные машины стал неактуален. Да…
Впрочем,  p400 оказался в сегодняшнем случае тоже не вариант, т.к. он не поддерживает диски объемом более 2Тб. И прошивке в что-нибудь родственное, но более похожее на тупую hba, увы, он тоже не подлежит.

Ладно же. Ладно-ладно же.

В соседнем городе был найден smart array p410. Тоже та еще поделка, да и с кэшем 256, что даже не смешно. То есть он конечно полноценно поддерживает большие диски и умеет строить из них raid, но зачем такое малоконтролируемое счастье с ребилдами по двое суток в случае замены диска. Что там насчет перешивки в hba режим? Увы, он тоже неведома зверушка, перешиваемая только родными фирмварями. Зато насчет переключения в hba вроде какие-то варианты есть, официально не поддерживаемые, но и все же.
Так что, а почему бы не поставить пару опытов, при такой стоимости-то контроллера. Но как выяснилось в дальнейшем, цена ведь как бы намекала.
Сразу следует оговориться: это контроллер из сервера HP, никто и никогда из HP не утверждал, что его в принципе возможно эксплуатировать в составе решений другого производителя. Поэтому предварительный поиск по диагонали все же был: вроде есть успешные сборки. Пробуем.

Берем, устанавливаем, включаем. Высвечивается bios контроллера, идет поиск устройств, перезагрузка. И так в цикле. Вход и настройки материнской платы при этом невозможен.
Меняем слот установки, ситуация повторяется. Вынимаем контроллер, заходим в настройки материнской платы. Находим пункт  Option ROM и отключаем его. О, так лучше. Контроллер не выводит свой экран, загрузка в ОС проходит.
Подключенные диски успешно видны как /dev/sgN устройства. Полноценных блочных устройств вида /dev/sdX и с которыми можно было бы дальше работать, не видно. Все правильно, теперь нужно перевести контроллер в hba режим.
Готовое решение для управления можно скачать здесь https://github.com/artizirk/hpsahba Собираем, запускаем, меняем. Вот и диски увиделись. Едино что,  необходимо наложить патчи на ядро, по ссылке об этом упомянуто. Также для моей системы необходимо оказалось предварительно отредактировать Makefile из ./contrib/dkms/ — изменить значение на  KDIR := /lib/modules/$(KRELEASE)/build Ну и далее собственно патчим:
dkms add ./
dkms install —force hpsa-dkms/1.0
modprobe -r hpsa
modprobe hpsa hpsa_use_nvram_hba_flag=1
echo «options hpsa hpsa_use_nvram_hba_flag=1» > /etc/modprobe.d/hpsa.conf
update-initramfs -u

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

Устанавливаем, включаем. Высвечивается bios контроллера, идет поиск устройств, перезагрузка. Точно. Отключить Option ROM нужно же.
А нет его там. Прошивка материнской платы самая свежая. Опции нет. Замечательно приплыли.

Уже сильно сомневаясь в том, а нужно ли продолжать эксперименты, все же пойдем на принцип.
У прошивок данного контроллера есть особенность: до определенной версии они имели возможность настройки параметров массивов непосредственно из POST экрана своего bios. В более новых прошивках данный функционал был убран и настройки массива производились только фирменными утилитами, например, путем загрузки с liveusb.
Так вот, те самые старые версии прошивок, что имели интерфейс управления, корректно передают управление материнской плате по завершении отображения post экрана bios контроллера. То есть нам необходимо сделать downgrade прошивки.
Это кстати оказалось не то чтобы особо просто, попытка запуска фирменной утилиты для установки прошивки у меня заканчивалась segmentation fault. Пришлось искать фирменный дистрибутив со старой версий ОС и прошивками от HP. Ищется например по запросу firmware-9.30-0.zip Далее всего-то нужно было на стенде с этого загрузиться и сделать даунгрейд прошивки контроллера.

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

Вот теперь уже надоело. Пошли искать какой-нибудь старый LSI1068 hba. А чудо по имени HP p410 пополнит коллекцию «дохлых ворон», что и выкинуть жалко и сильно сомнительно что это когда-нибудь пригодится.