Проверка железа раз в квартал: SMART, температура, ошибки памяти

MAATRIX

Диск не ломается в одну секунду — он неделями копит нечитаемые сектора, память тихо накапливает исправленные ошибки, вентилятор постепенно теряет обороты. Если не смотреть на эти сигналы, вы узнаете о проблеме в момент аварии: RAID уходит в degraded под нагрузкой, сервис падает в пятницу вечером. Ниже — конкретный регламент проверки физического состояния сервера раз в квартал: что смотреть, какими командами и как отличить «ничего страшного» от «меняем компонент на этой неделе».

Кому это нужно, а кому нет

Это регламент именно для выделенного сервера, а не для облачной виртуальной машины. На VPS физическое железо абстрагировано гипервизором: диски виртуальной машины лежат на отказоустойчивом хранилище провайдера, и если один физический накопитель в хосте начинает сыпаться, это забота провайдера — он подменяет компонент прозрачно для арендатора виртуалки. Разницу между этими моделями подробно разбирали в статье хостинг, VPS или выделенный сервер: что выбрать.

На выделенном сервере всё иначе: машина ваша целиком, никакой прослойки. Провайдер обязан заменить компонент, который уже вышел из строя, но заметить, что диск начинает сыпать ошибками, а память копит ECC-события — ваша зона ответственности, если вы не покупаете managed-обслуживание отдельно. У вас есть прямой доступ к SMART-данным дисков, датчикам IPMI и системным журналам — этим стоит пользоваться, а не полагаться на то, что «сервер сам скажет, если что-то не так».

Зачем проверять железо заранее

Механические и электронные компоненты изнашиваются предсказуемо, и у этого износа почти всегда есть измеримые ранние индикаторы задолго до отказа:

• HDD накапливает нечитаемые сектора и постепенно переназначает их из резервной области — это видно в SMART за месяцы до полного отказа головок или пластин.
• SSD и NVMe вырабатывают ресурс ячеек флеш-памяти (циклы записи/стирания) — процент износа растёт линейно и предсказуемо, скачков обычно не бывает.
• Модули памяти начинают давать единичные исправляемые (correctable) ошибки ECC задолго до того, как ошибка станет неисправимой и уронит систему.
• Вентиляторы теряют обороты постепенно, из-за чего растёт температура соседних компонентов — это заметно по трендам задолго до перегрева.

Разница между плановой и аварийной заменой — не только нервы. Плановая замена диска — это заказ запасного тома, синхронизация в спокойном режиме, минута простоя в согласованное окно. Аварийная замена — это ребилд RAID под нагрузкой (самый рискованный момент для массива, когда чтение каждого оставшегося диска на пределе может добить второй), возможная потеря данных и незапланированный даунтайм в неудобное время. Ежеквартальная проверка — это способ систематически перехватывать первый сценарий вместо второго.

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

SMART-статус дисков

SMART (Self-Monitoring, Analysis and Reporting Technology) — встроенная в контроллер диска система самодиагностики, которая есть практически на всех современных HDD, SSD и NVMe-накопителях. Инструмент для чтения — smartctl из пакета smartmontools:

# Debian/Ubuntu
apt install smartmontools

# AlmaLinux/RHEL
dnf install smartmontools

Список дисков в системе и поддержку SMART можно увидеть так:

smartctl --scan
lsblk -d -o NAME,SIZE,MODEL,ROTA

Быстрая проверка общего статуса:

smartctl -H /dev/sda

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

smartctl -a /dev/sda

Атрибуты, которые реально стоит отслеживать по трендам от квартала к кварталу (для HDD и SATA SSD):

Для NVMe-накопителей формат другой, и смотреть нужно nvme-cli:

apt install nvme-cli
nvme smart-log /dev/nvme0n1

Ключевые поля вывода: critical_warning (в норме 0), percentage_used (расчётный износ ресурса, у большинства производителей 100% — это условный предел, после которого гарантия и предсказуемость надёжности заканчиваются, а не мгновенная смерть диска), media_errors (ошибки на самих ячейках) и temperature.

Раз в квартал также имеет смысл запускать длинный самотест — он проверяет диск целиком, а не полагается только на накопленную статистику:

smartctl -t long /dev/sda
# самотест идёт в фоне, для HDD на несколько ТБ — часы; проверить статус:
smartctl -l selftest /dev/sda

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

Температура: диски, процессор, память, блок питания

Устойчиво высокая температура ускоряет деградацию почти любого компонента — от электролитических конденсаторов до контроллера SSD. Квартальная проверка должна охватывать не только CPU, но и диски, память и питание.

Температуру процессора и материнской платы на Linux читает lm-sensors:

apt install lm-sensors
sensors-detect   # один раз при первой настройке, отвечайте на вопросы по умолчанию
sensors

Вывод покажет температуру по каждому ядру (Core 0, Core 1…) и общий Package-показатель. Ориентируйтесь на спецификацию конкретного CPU от производителя (Tjunction/Tcase) — универсального «безопасного числа» нет, но для серверных Xeon и EPYC под нормальной нагрузкой устойчивые значения обычно заметно ниже максимума, и рост от квартала к кварталу при той же нагрузке — повод проверить систему охлаждения раньше, чем термотрещина проявит себя иначе.

Температуру диска показывает сам SMART:

smartctl -A /dev/sda | grep -i temp
nvme smart-log /dev/nvme0n1 | grep -i temp

Для HDD комфортный диапазон обычно около 25-45°C — и long-term ниже 20°C тоже не идеален (термоциклирование), и выше 50°C ускоряет старение. Для SSD/NVMe контроллеры терпят кратковременные пики до 70°C, но устойчивая работа около верхней границы заметно сокращает ресурс — это ориентир, а не жёсткий норматив: сверяйтесь с даташитом конкретной модели.

Если сервер оснащён BMC (IPMI) — а на арендованных выделенных серверах это почти всегда так — датчики можно прочитать напрямую с материнской платы, независимо от операционной системы:

ipmitool sensor list
ipmitool sdr type temperature

Это отдельный набор данных от показаний ОС: BMC видит температуру на входе/выходе воздуха (inlet/exhaust), температуру блока питания и материнской платы там, где sensors и smartctl не достают. Если сервер под управлением аппаратного RAID-контроллера — у него тоже есть собственный температурный датчик и статус батареи/суперконденсатора кэша записи, который проверяется утилитой конкретного вендора (storcli, megacli, perccli, arcconf — в зависимости от контроллера).

Ошибки памяти в системных журналах

Модули оперативной памяти с поддержкой ECC (Error-Correcting Code) — стандарт для серверного железа — самостоятельно исправляют одиночные битовые ошибки на лету и параллельно логируют факт исправления. Единичная исправленная ошибка раз в полгода — это фоновый шум, свойственный любой памяти. А вот растущая частота исправляемых ошибок на одном и том же модуле за квартал — почти всегда ранний признак деградации именно этой планки, задолго до необратимого сбоя.

Базовая проверка — прямо в логе ядра:

dmesg -T | grep -iE 'edac|mce|ecc'
journalctl -k --since "-90 days" | grep -iE 'edac|mce'

Проблема в том, что буфер dmesg и журнал journalctl переживают не любой аптайм и не любую ротацию — для системного и постоянного учёта таких событий на серверах используется подсистема ядра EDAC (Error Detection and Correction) через утилиту edac-util:

apt install edac-utils   # пакет может называться иначе в зависимости от дистрибутива
edac-util -v
edac-util --report=full

Более полную картину с накоплением истории (переживающей перезагрузки) даёт демон rasdaemon, который перехватывает RAS-события (Reliability, Availability, Serviceability) ядра и складывает их в локальную базу:

apt install rasdaemon
systemctl enable --now rasdaemon
ras-mc-ctl --summary
ras-mc-ctl --error-count

Ещё один независимый от ОС источник — журнал событий самого BMC (System Event Log), который фиксирует аппаратные события памяти на уровне материнской платы, включая случаи, когда сервер уже был перезагружен между вашими проверками:

ipmitool sel list
ipmitool sel elist

Если в SEL или EDAC накапливаются исправляемые ошибки, привязанные к конкретному слоту DIMM (в выводе обычно указан физический номер слота), — это повод запланировать замену модуля в следующее окно обслуживания, не дожидаясь, пока ошибка станет неисправимой (uncorrectable) и приведёт к падению системы или её принудительной перезагрузке контроллером памяти.

RAID-массив и сводный чек-лист

Диски редко стоят в одиночку — почти всегда это RAID, и квартальная проверка должна закрывать и его состояние отдельно от состояния отдельных дисков. Для программного RAID (mdadm):

cat /proc/mdstat
mdadm --detail /dev/md0

Статус State: clean — норма, degraded или recovering вне запланированного ребилда — сигнал разбираться немедленно. Для аппаратного RAID-контроллера команда зависит от вендора:

# LSI/Broadcom/Avago (современные карты)
storcli64 /c0/vall show
storcli64 /c0/eall/sall show

# LSI, более старые карты
megacli -LDInfo -Lall -aAll
megacli -PDList -aAll

# Dell PERC
perccli64 /c0/vall show

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

Сводный чек-лист на квартал, который удобно превратить в собственный скрипт или плейбук:

Результаты каждой проверки стоит сохранять (даже простым логом в текстовый файл с датой) — сама по себе разовая проверка полезна, но тренд от квартала к кварталу говорит больше, чем единичный снимок.

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