Rebuild vd0 ползёт сутками: измерить MB/s и не убивать второй диск

Короткий ответ

Долгий rebuild — чаще норма на 8–20 ТБ HDD плюс прод-нагрузка, а не «зависший контроллер». Снимите процент дважды с интервалом 15 минут, переведите в MB/s и ETA. Сверьте rebuildrate (MegaRAID) / rebuildpriority (HPE). Не ребутайте сервер «чтобы ускорить»: rebuild начнётся сначала или VD уйдёт Offline. Параллельно смотрите SMART оставшихся членов: второй отказ во время Rbld на RAID 5 = потеря vd0.

Если процента нет совсем — это rebuild не стартовал, не «медленно».

Симптомы и как отличить

Типичная картина:

• storcli /c0/v0 show rebuild показывает 30% спустя 18 часов на 12 ТБ RAID 5;
• пользователи жалуются на лаги, VD ещё Dgrd;
• ZFS tank resilver 2% в час на raidz2 из «больших» дисков.

Возможные причины

1. Низкий rebuildrate / Low rebuild priority при жирных VM.
2. Огромный used space: hardware RAID часто идёт по всему VD, не по занятым файлам.
3. Медленные SATA, 5400 rpm «NAS», смешанные модели в DG.
4. Patrol/CC конкурируют с rebuild.
5. Media errors на исходных дисках: перечиты, retry, скорость падает.
6. ZFS resilver на фрагментированном pool почти полон — хуже, чем hardware sequential.
7. Узкое место backplane/expander (редко диагностируют, пока не сравнят с другим слотом).

Диагностика

1. Скорость MegaRAID

storcli /c0/v0 show rebuild
storcli /c0 show rebuildrate
storcli /c0/eall/sall show

Два замера. Если 15 минут дали +0.4% на VD 10 ТиБ, грубая оценка: полный проход ≈ 15 / 0.004 ≈ 3750 минут. Запишите ETA в заявку.

Посмотрите State остальных PD: Predictive / media errors.

2. HPE

ssacli ctrl slot=0 ld all show detail
ssacli ctrl slot=0 show | grep -i rebuild

Rebuild Priority = low|medium|high. Процент Recovering в detail.

3. Нагрузка ОС

Ubuntu:

iostat -xz 5 3

Windows Server (SQL01): Resource Monitor Disk / Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Read'. Latency VD во время rebuild 20–50 мс на HDD — неприятно, но ожидаемо; секунды — ищите второй дохлый диск.

4. ZFS (если это не vd0, а tank)

zpool status tank
zpool iostat tank 5 6

scan: resilvered с растущим объёмом. zfs get capacity tank > 80% сильно замедляет.

5. SMART оставшихся

smartctl -a -d megaraid,0 /dev/sda
smartctl -a -d megaraid,1 /dev/sda

Рост Pending/Offline uncorrectable на диске-источнике rebuild — риск сорвать проход. Планируйте замену после стабилизации, не выдёргивайте второй сейчас без понимания RAID-уровня.

Решение

Сценарий A. Нужно быстрее, прод может потерпеть ночь

MegaRAID (значение 0–100, доля I/O на rebuild):

storcli /c0 show rebuildrate
storcli /c0 set rebuildrate=60

HPE:

ssacli ctrl slot=0 modify rebuildpriority=high

Верните low/30 после Optimal. Не оставляйте 90% навсегда: патруль и CC потом ударят прод так же.

Сценарий B. Прод важнее ETA

Оставьте rate низким, перенесите тяжёлые job (backup, reindex) с этого VD. RAID 5 на одном томе с SQL — плохое совпадение; учите на планировании ёмкости.

Сценарий C. Скорость обвалилась, появляются media error

Не abort rebuild. Снизьте нагрузку, проверьте кабель слота-источника. Abort + ручной restart с нуля удлиняет окно degraded. Если VD ушёл Failed — backup, не «ещё раз start rebuild».

Сценарий D. ZFS resilver

Не scrub параллельно. Не zpool import -f. Можно временно снизить нагрузку на dataset. zfs set rebuild нет; throttling через нагрузку приложений. После — zpool status -v.

Считайте риск второго диска явно: возраст партии, SMART Remaining членов, температура, вибрация полки. Если три диска одной поставки и одному уже Failed, ETA rebuild 30 часов — это аргумент снизить нагрузку SQL ночью или поднять rebuildrate, не «подождём выходных как обычно». RAID 6 здесь spare time, RAID 5 — нет.

Контроллер иногда показывает Copyback после того, как spare уже собрал Optimal: пользователь видит «долго что-то копируется» и выдёргивает spare. Не делайте так. Дождитесь конца copyback, иначе снова Dgrd.

Запись ETA в тикет с двумя замерами защищает от субъективного «висит». Если MB/s упал на порядок против начала прохода — media retry, не «так и должно быть на 99%».

Как проверить, что проблема устранена

Повторный show rebuild: процент дошёл до 100, VD Optl, rate вернули к политике. Latency SQL/VM вернулась к базе. SMART членов без нового скачка Pending. Для tank: scan: resilvered completed, 0 errors.

Если не помогло

• 0% после повышения rate: процесса нет, вернитесь к foreign/UGood.
• Rebuild циклически рестартится: диск-донор сыпется, готовьте второй диск и backup.
• HPE Expand + Rebuild вместе: expand больших LD длится дольше rebuild — не путать.
• Один слот медленнее всех: backplane, не «медленный Seagate vs WD» в первую очередь.

Профилактика

• RAID 10 или RAID 6 на больших HDD, не RAID 5.
• Не заполнять VD под 95% «потому что места жалко» — это не ускорит hardware rebuild (он всё равно sequential по VD), но спасёт ZFS/файлы при других авариях.
• Окно замены диска + снижение backup job.
• Мониторинг времени последнего rebuild и SMART.
• Горячий spare, чтобы rebuild начался сразу, а не через день закупки.

FAQ

Можно ли прервать rebuild и начать ночью?

Прерывание возвращает Dgrd и часто сбрасывает прогресс. Планируйте rate, не abort.

Rebuild 99% час стоит. Это норма?

На финальном verify иногда да. Час на 99.0 без движения — снимите лог контроллера, возможен retry на bad block.

Ускоряет ли выключение VM rebuild?

Да, меньше random I/O. Для SQL согласуйте downtime vs риск второго диска: иногда час простоя дешевле суток Dgrd под нагрузкой.

ZFS говорит 300 часов. Правда?

На полном raidz и мелких блоках ETA в zpool status бывает пессимистичным и плавает. Смотрите zpool iostat, не только надпись.

Нужен ли второй spare во время rebuild?

Не обязателен, но снижает панику. На RAID 6 второй отказ переживается, на RAID 5 — нет.