Батарейка RAID-контроллера села, и запись стала в 20 раз медленнее

MAATRIX

Сервер работал нормально месяцами, конфигурацию никто не трогал, нагрузка приложения не менялась — и вдруг запись на диск начала тормозить так, будто вместо RAID из SAS-дисков подставили флешку через USB-хаб. Чтение при этом оставалось быстрым, как всегда. Такая избирательность — тормозит только запись — почти всегда указывает не на приложение и не на файловую систему, а на сам RAID-контроллер и его кэш. Разберём типичный случай: как это выглядело, куда сначала посмотрели зря и что на самом деле произошло с батарейкой контроллера.

Симптом: чтение в норме, запись — как будто диск умер

Жалоба обычно формулируется расплывчато: «сервер стал тормозить». Но при внимательном разборе картина оказывается куда более конкретной. Тестовая запись файла через dd:

dd if=/dev/zero of=/data/testfile bs=1M count=1024 oflag=direct

раньше укладывалась в пару секунд, а теперь тянется заметно дольше — причём именно на этом сервере и именно сейчас, без изменений в коде, крон-задачах или профиле нагрузки. Чтение того же объёма данных с диска показывает скорость, которая ничем не отличается от вчерашней. База данных, которая раньше спокойно переваривала пиковую нагрузку по вставкам и обновлениям, начинает копить очередь запросов — iostat -x 1 показывает нормальную загрузку по чтению и почти зашкаливающий %util вместе с ростом w_await именно на операциях записи.

Первая реакция — проверить, не деградировал ли сам RAID-массив, не выпал ли диск. Но статус массива зелёный, все диски на месте, ошибок в dmesg про сектора или таймауты нет. Это сбивает с толку сильнее всего: обычно резкое падение производительности диска ассоциируется либо с умирающим накопителем — тема разобрана в материале про SMART-показатели, предсказывающие смерть диска, либо с проблемами самого массива, как в случае, когда диск в RAID сыпался месяц, а мониторинг молчал. Здесь же ни один диск не жалуется, массив цел, а тормозит именно запись — и только она.

Ложный след: грешим на нагрузку и конфигурацию

Первый час-два расследования почти всегда уходит не в ту сторону — это нормально, потому что статистически чаще всего замедление действительно вызвано изменением на стороне приложения. Проверяют:

• не выросла ли реальная нагрузка (число одновременных соединений к базе, размер батчей на вставку);
• не поменялись ли настройки файловой системы или планировщика ввода-вывода (cat /sys/block/sda/queue/scheduler);
• не включился ли где-то fsync на каждую операцию там, где раньше был буферизованный режим;
• не забрал ли соседний процесс (бэкап, антивирус, переиндексация) диск себе.

Все проверки заканчиваются ничем: конфигурация приложения не менялась, крон не запускал ничего нового, соседних тяжёлых процессов нет. Именно момент, когда все стандартные подозреваемые оправданы, а симптом «запись медленная, чтение нормальное» никуда не делся — это сигнал перестать искать причину в софте и посмотреть на слой ниже, на сам RAID-контроллер. Резкое и при этом избирательное (только запись) замедление без единого изменения конфигурации — классический отпечаток переключения режима кэширования контроллера, а не деградации диска или перегрузки системы.

Как работает write-back кэш RAID-контроллера

Чтобы понять, что произошло, нужно вспомнить, зачем вообще существует кэш на самом RAID-контроллере. У аппаратного RAID-контроллера есть собственная память (обычно от нескольких сотен мегабайт до пары гигабайт), которая может работать в одном из двух режимов записи:

Write-back — операция записи считается завершённой сразу, как только данные попали в быструю память кэша контроллера. Приложению и операционной системе тут же возвращается подтверждение «записано», хотя реальная запись на медленные физические диски происходит асинхронно, чуть позже, когда это удобно контроллеру. Это резко ускоряет запись, особенно мелкими блоками и с большим количеством операций в секунду — контроллер группирует их и пишет на диск эффективнее, чем если бы каждая операция ждала своей очереди на пластинах или ячейках памяти.

Write-through — операция записи считается завершённой только тогда, когда данные реально физически легли на диск. Никакого «обещания на будущее» — контроллер честно ждёт подтверждения от накопителя. Это надёжнее, потому что вообще не существует момента, когда данные есть только в кэше, но никак не защищены. Плата за эту надёжность — куда меньшая скорость: каждая операция записи стоит в очереди на реальную запись, вместо мгновенного возврата из быстрой памяти.

Разница в скорости между этими режимами не какая-то абстрактная величина — на нагрузке с большим числом мелких операций записи (типичная база данных, почтовый сервер, лог-система) она может быть очень значительной, потому что write-back по сути превращает случайную запись в последовательную пачку операций, а write-through выполняет её напрямую, диск за диском. Именно поэтому write-back — стандартная настройка на серверах с активной записью, где важна отзывчивость приложения.

Почему контроллер сам ушёл в write-through: находка через утилиту

Ключевой вопрос: кто и почему решил переключить режим кэширования, если никто из администраторов этого не делал? Ответ нашёлся не в логах операционной системы (там про это чаще всего нет ни слова), а в статусе самого контроллера — через его фирменную утилиту управления.

Для контроллеров на чипах LSI/Broadcom MegaRAID (в том числе под брендами Dell PERC, часть HPE и Lenovo) статус смотрят так:

# Статус контроллера и логических дисков
storcli64 /c0 show

# Статус батареи (BBU) или конденсаторной защиты (CacheVault)
storcli64 /c0/bbu show status
storcli64 /c0/cv show

Для Dell PERC (перемаркированный MegaRAID) — та же логика через perccli64:

perccli64 /c0/bbu show

Для Adaptec:

arcconf getconfig 1 AD

— в выводе есть отдельная секция с состоянием батареи контроллера.

Для HPE Smart Array:

ssacli ctrl slot=0 show config detail

— статус кэша и батареи виден в блоке Cache Board.

Именно такая проверка — конкретно статуса контроллера и его батареи, а не общего состояния массива или дисков — и показала предупреждение вроде BBU Status: Bad / Charge: Failed (формулировка зависит от модели и прошивки контроллера — точный текст сообщения стоит смотреть в документации к своей модели). Рядом стояла строка о текущем режиме кэша записи, изменившемся с WriteBack на WriteThrough — контроллер сделал это автоматически, без участия администратора, потому что так спроектирована его логика безопасности.

Корневая причина: батарея кэша садится незаметно

Логика контроллера предельно рациональна и по-своему честна: если батарея, которая должна сохранить содержимое кэша при внезапном отключении питания, разряжена или неисправна — доверять write-back больше нельзя. При потере питания в этот момент данные, которые контроллер уже подтвердил приложению как «записанные», физически существовали бы только в энергозависимой памяти кэша и были бы потеряны безвозвратно — то есть ровно то повреждение данных, ради предотвращения которого RAID и строился. Поэтому контроллер защищается сам: аварийно переключается в write-through, жертвуя скоростью ради гарантии, что подтверждённая запись действительно долетела до диска.

Корневая причина произошедшего — естественный износ батареи. У RAID-контроллеров с BBU (Battery Backup Unit, обычно на основе никель-металлгидридных или литиевых элементов) есть ограниченный срок службы, обычно измеряемый годами, а не десятилетиями эксплуатации без обслуживания. Точный ожидаемый ресурс своей батареи и рекомендованный интервал замены нужно смотреть в документации к конкретной модели контроллера — он различается между производителями и поколениями плат, и называть тут одну универсальную цифру для всех моделей было бы нечестно.

Проблема в том, что деградация батареи почти никогда не заявляет о себе заранее заметным образом — контроллер не присылает администратору письмо за месяц до того, как батарея сядет окончательно. Пока батарея держит заряд, всё работает в write-back и выглядит идеально. Как только контроллер по внутренней самопроверке решает, что заряда недостаточно для гарантированного сохранения кэша при сбое питания — переключение происходит мгновенно и без предупреждения на уровне операционной системы. Именно поэтому сервер «работал нормально месяцами, а потом вдруг стал медленным» — по сути, батарея садилась постепенно всё это время, просто симптом появился только в момент, когда контроллер перешёл черту.

Что делать: мониторинг батареи и плановая замена

Из этого случая следуют вполне конкретные практические выводы, а не абстрактное «следите за железом».

Мониторить статус батареи отдельно, а не только статус массива. Зелёный статус RAID-массива ничего не говорит о состоянии батареи кэша — это разные параметры контроллера. Нужна отдельная плановая проверка именно bbu show status (или аналог для своей модели), включённая в регулярный мониторинг, а не запускаемая вручную post-factum, когда запись уже упала. Разница между «мониторить диски» и «мониторить конкретно батарею контроллера» — та же, что в истории с диском, который сыпался месяц, пока мониторинг молчал: проверялось не то, что действительно предсказывало проблему.

Практический вариант — периодический (например, ежесуточный) запуск команды статуса батареи по крону с парсингом вывода и алертом при любом значении, отличном от «здорова»:

#!/bin/bash
STATUS=$(storcli64 /c0/bbu show status | grep -i "Battery State")
if ! echo "$STATUS" | grep -qi "Optimal\|Operational"; then
    echo "RAID BBU degraded: $STATUS" | mail -s "ALERT: RAID battery" admin@example.com
fi

Точные ключевые слова в выводе («Optimal», «Operational», «Bad», «Charging») зависят от модели и прошивки — перед тем как полагаться на такой скрипт в проде, стоит один раз посмотреть реальный вывод команды на своём железе и подстроить условие под него.

Заменять батарею планово, по истечении расчётного срока службы, не дожидаясь, пока контроллер сам обнаружит проблему и переключится в медленный режим. Дата установки сервера или последней замены батареи — та отметка, от которой стоит отсчитывать плановую замену, сверяясь со сроком службы конкретной модели в документации производителя.

Держать в голове честный компромисс write-back. Ускорение записи в этом режиме — не бесплатное: это ускорение ценой риска потери недозаписанных данных при сбое питания, и единственное, что делает этот риск приемлемым — рабочая батарея (или flash-защита кэша нового поколения, не требующая батареи вовсе — если контроллер поддерживает CacheVault или аналог, стоит рассмотреть переход на неё при следующей замене платы). Состояние батареи — не второстепенная деталь конфигурации, а параметр, от которого буквально зависит, можно ли доверять режиму ускорения в принципе. Если хочется убедиться, что производительность диска после ремонта или замены батареи вернулась к прежним значениям, а не осталась на уровне «терпимо» — честный замер через fio, а не через приблизительные ощущения, покажет разницу без иллюзий.

Частые вопросы