В пятничное утро я обнаружил неприятный сюрприз
Мой рейд рассыпался.
Контейнеры встали.
Последний раз резервная копия была сделана пару месяцев назад и там нет много чего.
Начал готовится к худшему...
Небольшая ремарка
Данные и сами машины/контейнеры хранятся на рейде md0, состоящем из 10 SATA SSD.
md0 является raid0 из двух raid5 (md50 и md51), т.е. по сути является raid50.
Когда-то я пришел к выводу, что такой рейд обеспечит для меня оптимальное соотношение скорость чтения/записи / полезный объем / отказоустойчивость.
Отказоустойчивость, кстати говоря, такого рейда составляет 1-2 диска. Причем 2 диска только в случае, если отказавшие окажутся в разных raid5, т.к. каждый raid5 переживет сбой только одного диска.
Для raid6 это 2 диска, но меньше полезный объем, ниже скорость записи, быстрее расходуется ресурс дисков за счет большего объема избыточности.
Диски у меня потребительские и по низу рынка. Лишний раз лучше на них не писать. Потому отдал предпочтение mdadm с raid50.
При сборке было закуплено от 3 марок: Goldenfir, SomnAmbulist, Xraydisk, по 5 дисков. 10 - должны были пойти в рейд, а 5 - на подмену.
По цене разброс составлял меньше 5%. Но Goldenfir, несмотря на красочную коробку, оказались полным мусором. Вместо 1ТБ внутри оказалось две микросхемы по 64ГБ, причем натуральная отбраковка. Из 5 шт. только один удалось переделать в 64ГБ с более-менее живой памятью. Ну да ладно, отвлеклись.
Каждый raid5 составлялся из дисков разных марок для повышения отказоустойчивости. Т.к. марок вместо 3х оказалось 2, то получились рейды: XXSXS и SXSSX, где X - Xraydisk, S - SomnAmbulist.
22.08.24 23:22
Вышел из строя /dev/sdd (XrayDisk 1TB SSD) из состава md50.
Все продолжает работать штатно. 1 диск на рейд, по SMART у остальных предупреждений нет - не страшно.
Т.к. подменных нет придется сходить до ближайшего магазина утром-вечером.
23.08.24 02:20
mdadm помечает как сбойный /dev/sda (XrayDisk 1TB SSD) из состава md50.
Тут уже страшно. md50 и состоящий из него md0 переходят в неактивное состояние.
Контейнеры не были остановлены. Данные на всех 10 дисках превратятся в кашу, если не восстановить хотя бы один диск.
Утро 23.08.24
Обнаруживаю, что сервер не отвечает. Отправляю в перезагрузку по питанию.
После перезагрузки в сеть не выходит.
Подключаю монитор и вижу, что не удалось примонтировать md0, потому система не загрузилась. Все плохо.
Вечер 23.08.24
Хм. Но ведь у дисков по SMART не было предупреждений.
Говорят, что mdadm может ошибочно отметить нерабочим диск из-за какой-то случайной и незначительной ошибки. Попробую пересобрать массивы.
mdadm --assemble --scan --force
Собралось!
Быстренько монтирую в режиме чтения и запускаю копирование на резервный диск (ed).
mount /dev/md0 /mnt/md0 -o ro
rsync -varh --progress /mnt/md0 /mnt/ed
О проверке файловой системы не было и мыслей, т.к. /dev/sda мог пойти вслед за своим собратом и тогда бы пришлось выкручиваться как-то иначе.
Копирование завершилось удачно.
Провожу параллели
/dev/sda подключен к SATA-контроллеру материнской платы.
/dev/sdd - к raid контроллеру (в режиме Initiator-Target).
Тут связи не видно. А вот что оба диска XrayDisk - это занятно.
А что там все же по смарт? Набрасываю скриптик:
#!/bin/bash
for i in {a..j}; do
echo "Disk sd$i" $SN $MD
smartctl -a /dev/sd$i | grep -P 'Device Model|Serial Number|Erase_Fail_Count_Chip|Current_Pending_Sector|Offline_Uncorrectable|Available_Reservd_Space|Total_LBAs_Written|Total_LBAs_Read'
done
На выходе получаю картину:
И новая странность с XrayDisk! Куча ошибок стирания и ни одного переназначенного сектора или хотя бы кандидата (ладно, просто у XrayDisk нет этой статистики в SMART). Хотя откуда переназначать есть.
Здесь я понял, что больше полагаться на XrayDisk я не могу и закупаться нужно не 2-3 дисками, а 7-8. К такому я был не готов.
Отрицание, гнев... Время торга
Оценив размер данных, решил собрать из 9 дисков только raid5 с 5 дисками в массиве и 4 дисками к нему на горячей замене.
Конечно, можно было собрать и два raid5 по 4 диска, так же объединить в raid0 и поставить оставшийся диск на горячую замену, но после увиденных SMART нет уверенности, что за время (депрессии, принятия) заказа и доставки новых дисков рейд доживет.
Разрушаю и собираю новый (после перезагрузки и извлечения сбойного диска имя sdd здесь имеет уже другой диск):
mdadm --stop /dev/md0 # останавливаем страйп
mdadm --stop /dev/md50 # останавливаем 1 raid5
mdadm --stop /dev/md51 # останавливаем 2 raid5
mdadm --zero-superblock /dev/sd{a,b,c,d,e,f,g,h,i} # стираем информацию, что диски предписаны к какому-либо рейду
wipefs --all --force /dev/sd{a,b,c,d,e,f,g,h,i} # подчищаем от меток
mdadm --create --verbose /dev/md50 --level=5 --size=975175680 --raid-devices=5 --spare-devices=4 /dev/sd{a,b,c,d,e,f,g,h,i} # собираем 5 рейд из 5 дисков и 4 на горячей замене
mdadm --zero-superblock /dev/md50 # т.к. когда-то рейд был приписан к md0 нам нужно удалить эту привязку, иначе можем получить ошибку "Perhaps a running process, mounted filesystem or active volume group?" при попытке создания ФС на следующем шаге
mkfs.ext4 /dev/md50 # создаем ФС
После создания рейд будет синхронизироваться. Этот шаг, конечно можно пропустить, но лучше просто поднять ограничения:
echo "1200000" > /sys/block/md50/md/sync_speed_min
echo "1200000" > /sys/block/md50/md/sync_speed_max
и дождаться завершения.
За прогрессом можно следить в реальном времени:
watch cat /proc/mdstat
Теперь можем монтировать, возвращать данные из резервного диска и пользоваться.
Не без жертв
Запустил контейнеры.
Начал работу.
Создал пару папок, файлов.
Запустил make и... куча ошибок. make clean? Не-а!
Ошибка: "rm: cannot remove bad message".
Повреждены образы контейнеров. Что ж, вылечим.
Сначала посмотрим все наши образы дисков.
ls /mnt/md0/images/*/*.raw
/mnt/md0/images/101/vm-101-disk-2.raw
/mnt/md0/images/105/vm-105-disk-0.raw
/mnt/md0/images/108/vm-108-disk-0.raw
/mnt/md0/images/103/vm-103-disk-0.raw
...
Пройдемся по всем утилитой для работы с ФС (в примере для машины 103):
e2fsck -p -c -f -v /mnt/md0/images/103/*.raw
Если было что восстановить и нарушена консистентность, то утилита может предложить запустить себя с другими параметрами для исправления:
e2fsck -y -v /mnt/md0/images/103/*.raw
Что там с /dev/sdd?
Тест скорости в CrystalDiskMark показывает результаты как у вполне живого:
А вот с Bulldog на запись получилось все очень плохо:
Средняя скорость записи во время теста 44.5 КБ/с.
Карта секторов имеет редкие проблески с малым временем доступа.
Большая же часть напоминает текстурные спрайты из ретро игр.
Средняя скорость доступа на запись так и шепчет: "в мууусор...".
Заключение
Ничего другого от дешевых потребительских дисков я и не ждал.
Когда только-только собрал сервер с другом у меня был такой диалог:
Д: А ты уверен, что гонять их на максимуме - хорошая идея?
Тише едешь - дальше будешь
Я: Если бы я хотел их видеть всегда как новыми я бы их не вытаскивал бы из коробки и держал всегда в шкафу. Но они не там.
Д: Одно дело пользоваться, другое - топить на полную
Я: Лучше сейчас я замучаю эти диски, чем позже буду плеваться что диски коммерческого уровня сдохли через год.
Д: Ну если аргументация такая, то ладно)
Конечно, задачи становятся все серьезнее, данные ценнее. Пора бы обновлять и улучшать сервер или даже собирать сразу новый уже со знанием дела.
Как по мне круто еще и то, что вместе с такими сбоями приобретается реальный опыт, который в критических моментах на серьезных задачах с головой окупит затраченные средства на такой "тренажер".
Ну а пока буду думать заказывать ли новые диски и какие.