Эксперты в подборе IT-оборудования
Сервер работает, пользователи не жалуются, но что-то подсказывает, что с дисками не всё в порядке. Едва заметно выросло время отклика, из стойки доносятся странные звуки, приложения иногда подвисают на пару секунд. Диагностировать это на продакшене - отдельная задача: остановить сервер нельзя, а неосторожная команда способна уронить и то, что пока работает.
Диски умеют долго скрывать проблемы. SSD прячет плохие блоки за резервной областью, жёсткий диск переназначает сектора. Когда симптомы становятся очевидными, спасать данные обычно уже поздно.
Хорошая новость: почти всё можно посмотреть, не останавливая сервер. Ниже - что запускать, что эти команды покажут, как добраться до дисков, спрятанных за RAID-контроллером, и какие инструменты нельзя трогать под нагрузкой. Здесь речь про сервер, который работает. Отдельный порядок действий на случай, если сервер уже не стартует, разобран в другой статье.
Диски редко умирают внезапно. Обычно этому предшествуют симптомы, которые несколько недель никто не связывает с железом.
Выросло время отклика. Симптом коварный: пользователи говорят, что «стало медленнее», но конкретизировать не могут. Приложения подвисают на несколько секунд, потом работают как ни в чём не бывало.
Ошибки в системных логах. Ядро Linux пишет проблемы с дисками в /var/log/messages или /var/log/syslog, но среди сотен обычных строк они теряются. Искать стоит sector read error, medium error, device timeout.
Звуки. Здоровый HDD гудит ровно и почти неслышно. Щелчки, скрежет, периодические клацанья - механика на выходе. SSD бесшумны, поэтому звук рядом с ними означает проблему с вентилятором, а не с накопителем.
Начинают с четырёх команд, ни одна из которых не создаёт заметной нагрузки.
df -h покажет заполненность файловых систем. Проценты тут не главное. Смотрите на разделы, которые внезапно перемонтировались в режим только для чтения: это частая реакция ядра на ошибки ввода-вывода.
dmesg -T | grep -i -E 'error|fail|timeout' выведет сообщения ядра с человекочитаемым временем. Ключ -T важен: без него вы получите секунды с момента загрузки и не сможете связать ошибку с инцидентом.
lsblk покажет структуру блочных устройств. Пропавший или неопознанный диск - повод смотреть на контроллер и кабели, а не на поверхность.
iostat -x 1 из пакета sysstat даёт расширенную статистику ввода-вывода с обновлением раз в секунду. На что смотреть - разберём ниже, в разделе про производительность.
SMART - встроенная система самодиагностики накопителя. Она непрерывно считает собственные ошибки и умеет сообщить о деградации задолго до отказа.
Основной инструмент - smartctl из пакета smartmontools. Полная информация по диску:
smartctl -a /dev/sda
Атрибутов в выводе десятки, и у каждого вендора своя система подсчёта. На работающем сервере обычно хватает четырёх:
Полная расшифровка атрибутов со значениями порогов и вендорскими особенностями - тема отдельная, она у нас разобрана в статье про показатели SMART на серверных дисках. Здесь дальше - про то, чего в ней нет: как вообще добраться до SMART на сервере.
Вот место, где обрывается большинство инструкций. На типовом сервере диски подключены не напрямую, а через аппаратный RAID-контроллер - Dell PERC, HPE Smart Array, LSI или Broadcom MegaRAID. Операционная система видит один логический том, физических дисков за ним нет. Команда smartctl -a /dev/sda в такой конфигурации либо ничего не покажет, либо выдаст характеристики виртуального диска, к здоровью накопителей отношения не имеющие.
Решение - указать smartctl тип устройства и номер диска на контроллере:
smartctl -a -d megaraid,0 /dev/sda
Номер после запятой - идентификатор физического диска на контроллере, от 0 до 127. Перебирать вслепую не надо: список дисков и их номера показывают вендорские утилиты. Тот же ключ работает и с контроллерами Dell PERC, потому что это перемаркированные LSI.
Для контроллеров HPE применяется другой тип:
smartctl -a -d cciss,0 /dev/sg0
На новых поколениях HPE диски часто видны и напрямую как /dev/sg* - тогда достаточно обычного вызова с указанием этого устройства.
Вендорские утилиты полезны сами по себе, потому что показывают состояние массива целиком - какой диск деградировал, идёт ли перестроение, жива ли батарея кэша:
Честная оговорка: не всякий контроллер отдаёт SMART наружу. Некоторые модели и прошивки показывают только собственную оценку состояния диска - «здоров», «предупреждение», «отказ». В этом случае вендорская утилита останется единственным источником, и придётся довольствоваться её вердиктом.
У NVMe своя схема журналов, и классических SMART-атрибутов там нет. Свежие версии smartctl их понимают:
smartctl -a /dev/nvme0
Либо специализированная утилита из пакета nvme-cli:
nvme smart-log /dev/nvme0
Смотреть стоит на три показателя. Percentage Used - израсходованный ресурс записи, идёт от 0 к 100 и работает как индикатор остатка жизни. Critical Warning - сводный флаг контроллера: любое ненулевое значение требует разбора. Media and Data Integrity Errors - неисправимые ошибки данных, аналог uncorrectable у обычных дисков.
Отдельно у NVMe полезна температура. Перегретый накопитель уходит в тротлинг и отдаёт заметно меньше, чем должен, оставаясь по SMART здоровым.
SMART умеет запускать самопроверку: короткую, расширенную и выборочную. Короткая занимает несколько минут и проверяет основные узлы, расширенная может идти часами, но смотрит поверхность целиком.
Запускать самотестирование на продакшене можно - оно выполняется силами самого диска в фоне. Но расширенный тест добавляет нагрузку и заметен на дисках, которые и так под потоком, поэтому его планируют на окно минимальной активности.
Результат PASSED не гарантирует ничего на завтра. А вот FAILED - однозначный повод менять диск. Отдельного внимания заслуживают тесты, которые прерываются или завершаются ошибкой чтения: это уже симптом сам по себе.
Производительность падает постепенно, и без регулярных замеров это легко пропустить.
iotop показывает процессы, которые прямо сейчас грузят диски. Помогает отличить аппаратную проблему от приложения, устроившего внеплановую индексацию.
hdparm -t /dev/sda измеряет скорость последовательного чтения. Тест создаёт нагрузку, поэтому на продакшене им злоупотреблять не стоит. Результат сравнивают со спецификацией диска или с прошлым замером - абсолютное число само по себе мало о чём говорит.
fio собирает детальный тест под конкретный профиль нагрузки: случайное чтение, последовательная запись, смешанный режим. Инструмент мощный и по этой же причине опасный на рабочей системе.
Основной рабочий инструмент - iostat -x 1. Показатели, которые действительно помогают:
r_await и w_await: чтение и запись деградируют по-разному, и разделение часто сразу указывает на характер проблемы.Про %util есть важная оговорка. На обычном HDD с одной очередью 100 % действительно означают, что диск загружен полностью. На SSD и особенно на NVMe, которые обслуживают десятки запросов параллельно, показатель упирается в 100 % задолго до реального насыщения. Делать по нему выводы о NVMe нельзя: смотрите на await и на фактическую пропускную способность.
Ещё одно: в старых инструкциях встречается совет смотреть на колонку svctm. Не ищите её - этот показатель удалён из sysstat начиная с версии 12.1.2 (декабрь 2018) и в современных дистрибутивах, включая RHEL 9, его в выводе просто нет. Убрали потому, что на многоочередных устройствах его нельзя посчитать достоверно.
sar -d 1 даёт ту же статистику в более читаемом виде и, в отличие от iostat, умеет показывать историю за прошлые сутки, если сбор включён. Для разбора «что было ночью» это удобнее.
atop показывает картину целиком: диски, процессы, память - и тоже умеет писать историю.
Механические диски и твердотельные накопители ломаются по-разному, поэтому и ищут в них разное.
HDD содержит движущиеся части, и почти все его болезни механические: деградируют головки, разбалансируется шпиндель, теряет свойства магнитный слой.
Акустика. Метод специфический, но рабочий: щелчки, скрежет и нерегулярные звуки часто предшествуют отказу на дни и недели.
Вибрация. В плотно набитой стойке соседние диски раскачивают друг друга, и на высокооборотных дисках это заметно повышает число ошибок чтения. Пустые салазки и незакреплённые крышки проблему усугубляют.
Температура. Перегрев ускоряет деградацию поверхности. Температурный атрибут SMART стоит держать в мониторинге постоянно, а не смотреть по случаю. Про проверку механических дисков подручными средствами у нас есть отдельный разбор - диагностика жёстких дисков.
У SSD своя логика износа, и ключевые показатели другие.
Wear Leveling Count отражает, насколько равномерно расходуются ячейки. Program/Erase Cycle Count - число циклов перезаписи; у каждого типа памяти есть предел, после которого ячейки становятся ненадёжными. Available Reserved Space показывает остаток резервных блоков: когда он кончается, накопитель может уйти в режим только для чтения - и это происходит без предупреждения для приложений.
Uncorrectable Error Count у SSD означает исчерпание ресурса или проблему контроллера, а вовсе не механику. Здесь это почти всегда сигнал, что накопитель близок к концу.
Названия атрибутов у разных вендоров отличаются, и часть из них smartctl показывает как Unknown_Attribute с номером. Сверяться приходится с документацией производителя.
Когда штатные средства не дают ясности, идут дальше.
badblocks -v /dev/sda ищет повреждённые блоки в режиме чтения. Относительно безопасен, но на больших дисках идёт долго и создаёт постоянную нагрузку. Важно: на смонтированной файловой системе его результаты малоинформативны, а режимы с записью уничтожают данные - на продакшене их не запускают никогда.
Анализ системного журнала за длительный период показывает то, чего не видно в моменте: повторяющиеся ошибки чтения одних и тех же секторов, регулярные таймауты, сообщения о переназначении блоков.
filefrag показывает фрагментацию конкретных файлов. На HDD с большими базами данных это иногда объясняет просадку, которой нет в статистике блочного устройства.
Часть проблем проявляется только под нагрузкой. stress-ng умеет создать её управляемо, включая интенсивный ввод-вывод.
На рабочем сервере это крайняя мера. Если решились - тестируйте в окно, следите за результатом в реальном времени и знайте, чего ждёте: здоровый диск держит стабильное время отклика даже под потоком. Скачки await, рост числа ошибок и проседание скорости по ходу теста и есть искомый ответ.
Сводка того, что было рассыпано оговорками выше. Колонка «нагрузка» - про то, что инструмент делает с диском, а не с процессором.
| Инструмент | Нагрузка на диск | Можно под нагрузкой |
|---|---|---|
df -h, lsblk, dmesg | Нет | Да, в любое время |
smartctl -a (чтение атрибутов) | Нет | Да, в любое время |
iostat -x, sar -d, atop, iotop | Нет | Да, это штатный мониторинг |
nvme smart-log | Нет | Да |
| Короткий self-test SMART | Минимальная | Да |
| Расширенный self-test SMART | Заметная | Лучше в окно минимальной активности |
hdparm -t | Заметная, кратковременно | С осторожностью, вне пика |
badblocks в режиме чтения | Высокая, длительная | Только в окно |
fio, stress-ng | Высокая | Крайняя мера, только в согласованное окно |
badblocks в режимах записи | Разрушающая | Никогда на рабочих данных |
Практическое правило: всё, что только читает счётчики, запускайте свободно. Всё, что генерирует ввод-вывод, планируйте.
Диагностика по факту - всегда работа в цейтноте. Дешевле ловить деградацию заранее.
Автоматизируйте проверку SMART. Демон smartd из того же пакета smartmontools умеет опрашивать диски по расписанию, запускать самотестирование и слать уведомления при изменении критических атрибутов. Для парка серверов те же данные обычно забирают в общую систему мониторинга.
Следите за трендом, а не за порогом. Медленный рост переназначенных секторов или постепенное увеличение await говорят больше, чем однократное превышение. Как строить прогноз по такому тренду штатными средствами, разобрано в статье про предиктивный мониторинг серверов.
Ведите учёт дисков. Модель, серийный номер, дата установки, наработка в часах, динамика ключевых атрибутов. Без этого решение о замене принимается на ощупь. Общий подход к тому, что и как отслеживать, - в разборе про комплексный мониторинг серверов.
Проверяйте восстановление. RAID-массив, который никто ни разу не перестраивал, и резервная копия, из которой никто не восстанавливался, - это надежда, а не защита.
Если диск уже посыпался и данные под угрозой, дальше начинается другая работа - снять образ диска и вытащить данные, пока он ещё отвечает.
Почему smartctl -a /dev/sda на сервере ничего не показывает?
Скорее всего, диски за аппаратным RAID-контроллером, и система видит только логический том. Нужно указать тип устройства и номер диска: smartctl -a -d megaraid,0 /dev/sda для LSI, Broadcom и Dell PERC, -d cciss,N для HPE. Часть контроллеров SMART наружу не отдаёт вовсе - тогда остаются вендорские утилиты storcli, perccli или ssacli.
Можно ли проверять диски, не останавливая сервер?
Чтение SMART-атрибутов, iostat, sar, atop, короткий self-test - да, в любое время. Всё, что само создаёт ввод-вывод (badblocks, fio, hdparm -t, stress-ng), планируют на окно.
Диск показывает несколько переназначенных секторов. Менять?
Само по себе небольшое ненулевое значение не приговор, но это повод перевести диск под наблюдение и проверить резервные копии. Тревожит динамика: если число растёт от недели к неделе или рядом появились ожидающие сектора, замену стоит планировать.
Почему в выводе sar -d нет колонки svctm?
Её убрали из sysstat в версии 12.1.2 в 2018 году: на устройствах с несколькими очередями этот показатель нельзя посчитать достоверно. Ориентируйтесь на await, r_await, w_await и глубину очереди.
Чем диагностика NVMe отличается от обычных дисков?
Другой набор журналов и другие команды: smartctl -a /dev/nvme0 или nvme smart-log /dev/nvme0. Смотрят на Percentage Used, Critical Warning и ошибки целостности данных. И помните, что %util для NVMe недостоверен.
Подбираем серверы и дисковые подсистемы под задачу.
Если диагностика показала, что диски или контроллер отработали своё, поможем подобрать замену: конфигурацию под вашу нагрузку, совместимость с имеющимся контроллером, тестирование перед отгрузкой.
Смотрите стоечные серверы или напишите нам - разберёмся вместе.
Телефон: 8 800 551-80-12. Почта: info@ittelo.ru. На рынке серверов 11+ лет.
