Система мониторинга и проактивного обслуживания дисковых массивов в 2026 году

Надежная система мониторинга дисковых массивов в 2026 году должна контролировать четыре уровня: физические диски, RAID-контроллеры и полки, пул или файловую систему, а также фактическую нагрузку приложений. Для каждого объекта собирайте состояние, IOPS, latency, throughput, глубину очереди, температуру, ошибки носителей, состояние кэша и SMART-атрибуты. Одного сигнала о том, что массив доступен, недостаточно: деградация производительности часто начинается за часы или дни до отказа.

Практичная схема использует опрос состояния каждые 30-60 секунд, сбор метрик производительности каждые 15-60 секунд, SMART и NVMe health каждые 5-15 минут. Конфигурацию, версии микрокода, состояние батарей контроллера и свободное место проверяйте минимум раз в сутки. Пороговые значения задаются от baseline конкретной системы: latency выше обычного уровня в 2 раза в течение 10 минут требует проверки, а degraded RAID, отключенный write-back cache, media error или pending sector требуют немедленной реакции.

Начните с инвентаризации всех массивов, контроллеров, дисков, пулов и точек подключения. Затем подключите SNMP и CLI/API-сборщики, сохраните базовые значения в штатном режиме, разделите алерты по приоритету и подготовьте процедуры замены диска, обновления микрокода, scrub и расширения пула. Такой цикл снижает риск внезапного простоя и помогает заменить компонент до потери данных.

Архитектура мониторинга дисковых массивов

Система наблюдения должна оставаться доступной при проблеме самого хранилища. Размещайте два сборщика в разных отказовых доменах, используйте отдельные сетевые интерфейсы управления и храните метрики вне контролируемого массива. Если хранилище недоступно, мониторинг должен показать отсутствие данных, а не потерять событие вместе с ним.

Четыре уровня контроля

Физический уровень: модель, серийный номер, слот, температура, питание, обороты вентиляторов, ошибки чтения и записи, состояние линка SAS, SATA или NVMe.
Уровень контроллера: состояние батареи или флеш-кэша, режим write-back или write-through, cache hit ratio, состояние виртуальных дисков, hot spare, rebuild и patrol read.
Уровень пула: health, свободное место, фрагментация, checksum errors, scrub, состояние vdev или RAID-группы, количество snapshot и thin provisioning.
Уровень нагрузки: IOPS, latency p50, p95 и p99, throughput, queue depth, доля чтения и записи, задержки подтверждения записи для баз данных и виртуальных машин.

Для аппаратного RAID полезно связать серийный номер диска с физическим слотом через CLI контроллера. Для ZFS идентифицируйте носитель по стабильному имени устройства и серийному номеру, а не по имени вроде /dev/sdb, которое может измениться после перезагрузки.

Базовые принципы настройки RAID, кэширования и интеграции с Zabbix или Prometheus собраны в руководстве по дисковому контроллеру. Используйте его вместе с паспортом конкретной модели контроллера.

Какие метрики собирать

Метрика	Интервал	Начальный порог	Действие
Состояние массива или пула	30-60 секунд	Любое degraded, failed, offline	Аварийное уведомление, проверка диска и журнала
Latency p95 и p99	15-60 секунд	2x baseline 10 минут, критично 4x или выход за SLO	Сопоставить с queue depth, IOPS и нагрузкой хостов
IOPS	15-60 секунд	Падение более чем на 30% при прежней нагрузке	Проверить rebuild, throttling, кэш и ошибки путей
Throughput	15-60 секунд	Падение более чем на 30% относительно baseline	Проверить сеть, multipath и перегруженный контроллер
Queue depth	15-60 секунд	Устойчивый рост при неизменном объеме запросов	Найти узкое место и определить тип нагрузки
Write-back cache	30-60 секунд	Режим отключен, батарея или flash backup degraded	Проверить питание и кэш, оценить риск потери подтвержденных записей
Свободное место	5 минут	70% warning, 80-85% critical для пула	Удалить временные данные по политике, расширить емкость или перенести нагрузку
SMART и NVMe health	5-15 минут	Pending или uncorrectable error, быстрый рост media errors	Проверить диск и подготовить замену
Температура	1-5 минут	Порог производителя, для HDD 45 градусов можно взять как начальный warning	Проверить поток воздуха, вентиляторы и плотность установки

Абсолютное число IOPS или MB/s само по себе мало полезно. Массив из HDD, RAID 6 и последовательная запись будут иметь другой профиль, чем NVMe-пул под виртуальные машины. Сохраняйте baseline минимум 7-14 дней, разделяйте рабочие и ночные часы и сравнивайте одинаковые интервалы.

IOPS, latency и throughput

IOPS показывает число операций ввода-вывода в секунду. Мелкие случайные операции создают высокий IOPS при небольшом throughput. Крупные последовательные операции дают высокий throughput при умеренном IOPS.

Latency показывает время ожидания операции. Для приложений используйте p95 и p99, потому что среднее значение скрывает редкие, но болезненные задержки. Рост latency вместе с queue depth обычно означает насыщение дисков, контроллера или канала. Рост latency при низком IOPS чаще указывает на ошибки, rebuild, повторные передачи или проблемы питания.

Throughput измеряйте отдельно для чтения и записи. Снижение скорости во время перестроения RAID ожидаемо, но его нужно сопоставить с SLO приложений. Если latency вышла за допустимый уровень, временно перенесите тяжелые задания, ограничьте scrub или измените расписание резервного копирования.

Состояние кэша контроллера

Write-back cache подтверждает запись до отправки данных на диски, поэтому состояние батареи, supercapacitor или flash-backed cache нужно проверять как отдельный объект. При неисправном резервном питании многие контроллеры переходят в write-through. Данные сохраняются, но latency записи может вырасти в несколько раз.

Сигнал cache disabled нельзя объединять с обычным информационным событием. Создайте отдельный critical trigger и укажите в уведомлении контроллер, причину перехода и время последнего исправного состояния. Не включайте write-back вручную, пока не проверены батарея, supercapacitor, firmware и политика защиты от потери питания.

SMART и здоровье SSD

Для HDD отслеживайте Reallocated Sector Count, Current Pending Sector, Offline Uncorrectable, UDMA CRC Error Count, число ошибок чтения и температуру. Ненулевой Pending Sector на диске, который входит в RAID-группу, требует диагностики и подготовки замены. Рост CRC-ошибок без роста ошибок носителя чаще связан с кабелем, разъемом или backplane.

Для SSD и NVMe собирайте Percentage Used, Available Spare, Available Spare Threshold, Media and Data Integrity Errors, Error Information Log Entries, Data Units Written и температуру. Атрибут Percentage Used не показывает точный остаточный срок службы: разные производители считают ресурс по-разному. Смотрите на скорость роста показателя, объем записанных данных и ошибки целостности.

SMART через RAID-контроллер может быть неполным. Если контроллер скрывает диски, используйте его health-метрики и штатный pass-through, если производитель разрешает такой режим. Не запускайте частые destructive-тесты на рабочем массиве.

Для одиночных HDD и SSD под Windows пригодится сравнение инструментов SMART-мониторинга. На сервере проверяйте, что приложение видит реальный серийный номер и получает данные через правильный тип интерфейса.

Сбор данных через SNMP

SNMP удобен для полок, аппаратных массивов и сетевых компонентов. Включите SNMPv3 с authPriv, выделите отдельную учетную запись только для чтения и разрешите запросы с адресов сборщиков. SNMPv1 и общие community strings оставляйте только для изолированной лаборатории.

У каждого производителя собственная MIB и собственные OID для health, дисков, виртуальных дисков, кэша и rebuild. Поэтому не подставляйте универсальный OID массива в продакшен. Получите MIB из комплекта вашей прошивки, сопоставьте имена объектов с серийными номерами и проверьте значения ручным запросом.

Базовый shell-скрипт

Скрипт ниже собирает uptime и таблицу производителя. Переменная ARRAY_TABLE_OID должна содержать OID таблицы дисков или состояния массива для вашей платформы. Вывод можно передать в агент мониторинга или сохранить для первичного baseline.

#!/bin/sh
set -eu

TARGET="${1:?укажите IP или DNS-имя массива}"
ARRAY_TABLE_OID="${ARRAY_TABLE_OID:?укажите vendor OID таблицы}"
SNMP_USER="${SNMP_USER:?укажите SNMP_USER}"
SNMP_AUTH="${SNMP_AUTH:?укажите SNMP_AUTH}"
SNMP_PRIV="${SNMP_PRIV:?укажите SNMP_PRIV}"

COMMON="-v3 -l authPriv -u $SNMP_USER -a SHA -A $SNMP_AUTH -x AES -X $SNMP_PRIV"
STAMP=$(date -u +%FT%TZ)

printf 'timestamp=%s\n' "$STAMP"
printf 'target=%s\n' "$TARGET"
printf 'sysUpTime=' 
snmpget $COMMON -Oqv "$TARGET" 1.3.6.1.2.1.1.3.0
printf 'array_table_begin\n'
snmpbulkwalk $COMMON -On "$TARGET" "$ARRAY_TABLE_OID"
printf 'array_table_end\n'

Для постоянного сбора храните не только текст ответа. Преобразуйте значения в числовые элементы с единицами измерения, а индексы таблиц свяжите с serial, enclosure и slot. При смене диска индекс SNMP может сохраниться, поэтому алерт должен содержать оба идентификатора.

Сбор через CLI и API

CLI полезен для сверки данных SNMP и аварийной диагностики. Опрос запускайте с узла управления или через ограниченный remote execution. Пароли не записывайте в командную строку и историю shell, а учетной записи API выдайте минимальные права.

Аппаратный RAID

storcli /cALL show
storcli /c0 show all
storcli /c0/eall/sall show all
storcli /c0/vall show all

Эти команды позволяют увидеть контроллер, виртуальные диски, физические диски, состояние rebuild и часть параметров кэша. Номера enclosure и slot сверяйте с маркировкой корпуса. Перед любой операцией запишите вывод в журнал изменения.

ssacli ctrl all show config detail
ssacli ctrl slot=0 ld all show detail
ssacli ctrl slot=0 pd all show detail

Для HPE набор команд зависит от поколения контроллера и установленной утилиты. Метрики HPE SMH и iLO, а также практические примеры контроля IOPS, latency и throughput описаны в руководстве по мониторингу HP-массивов.

TrueNAS и ZFS

zpool status -x
zpool list
zpool iostat -v 10
zpool get health,capacity,fragmentation pool_name
smartctl -a /dev/sdX
nvme smart-log /dev/nvme0

Команда zpool status -x быстро показывает, есть ли проблема в пулах. zpool iostat -v 10 помогает найти vdev, который отстает по latency или throughput. Для SSD NVMe используйте nvme smart-log, а для SATA и SAS проверяйте доступность SMART через контроллер или HBA.

Для TrueNAS API применяйте отдельную учетную запись и TLS с проверкой сертификата:

curl --fail --silent --show-error --user "$TRUENAS_USER:$TRUENAS_PASSWORD" -H 'Content-Type: application/json' "$TRUENAS_URL/api/v2.0/pool"
curl --fail --silent --show-error --user "$TRUENAS_USER:$TRUENAS_PASSWORD" -H 'Content-Type: application/json' "$TRUENAS_URL/api/v2.0/disk"
curl --fail --silent --show-error --user "$TRUENAS_USER:$TRUENAS_PASSWORD" -H 'Content-Type: application/json' "$TRUENAS_URL/api/v2.0/alert/list?alert dismissed=false"

В последнем запросе в рабочем скрипте корректно кодируйте параметры URL и фильтруйте только активные алерты. Не используйте --insecure в рабочей среде. При обновлении TrueNAS или API-плагина проверьте схему ответа, имена полей и права service account.

Пороги и алерты

Порог без контекста создает шум. Зафиксируйте baseline для каждого массива: средние и p95 значения latency, типичный read/write ratio, рабочий диапазон IOPS, температуру, скорость роста свободного места и частоту media errors.

Приоритеты событий

P1: pool или virtual disk failed, потеря redundancy, uncorrectable error, несколько offline-дисков, недоступный массив, потеря write-back protection. Уведомление отправляется сразу, дежурный подтверждает его в течение 5 минут.
P2: degraded array с рабочим rebuild, pending sector, неисправный hot spare, рост p95 latency в 2 раза, критическое заполнение пула, повышенная температура. Инженер начинает проверку в течение 15 минут.
P3: медленный рост Percentage Used, устаревший микрокод, редкая CRC-ошибка, завершение ресурса батареи, отклонение от расписания scrub. Событие попадает в плановую работу.

Связывайте алерты. При rebuild не отправляйте отдельные сообщения о каждом изменении процента. Создайте одно событие с началом, текущей скоростью, прогнозом завершения и финальным результатом. Когда rebuild закончился, автоматически запустите проверку состояния массива и целостности данных.

Для Zabbix полезны LLD по дискам и триггеры с привязкой к серийному номеру. Готовые схемы обнаружения, smartctl и кастомных условий собраны в статье о мониторинге дисков в Zabbix.

Для Telegram и email используйте дедупликацию, паузу на плановые работы и повторное уведомление, если P1 не подтвержден. Практические варианты маршрутизации алертов описаны в руководстве по уведомлениям о состоянии дисков.

Плановое обслуживание

Обновление микрокода

Соберите инвентарь: модель массива, controller, HBA, backplane, диски, версии firmware и драйверов.
Проверьте совместимость версии с контроллером, дисками, multipath, гипервизором и файловой системой.
Сделайте резервную копию конфигурации контроллера и убедитесь, что резервные копии данных восстанавливаются.
Проверьте отсутствие degraded-состояния, активного rebuild, ошибок кэша и проблем с питанием.
Обновляйте один отказовой домен за раз. Для двух контроллеров сначала проверьте переключение путей и состояние второго контроллера.
После перезагрузки сравните firmware, health, latency, cache mode, multipath и журналы операционной системы.

Не совмещайте обновление контроллера с заменой диска, изменением RAID-группы или расширением пула. Если новая прошивка меняет алгоритм кэша или порядок идентификации устройств, проведите тест на стенде с похожей конфигурацией.

Безопасная замена диска

Подтвердите проблему по двум признакам: состояние контроллера или пула и серийный номер физического диска.
Найдите слот через CLI и включите индикатор locate. Не извлекайте диск только по номеру, напечатанному в графическом интерфейсе.
Проверьте резервную копию, наличие hot spare, состояние redundancy и допустимую нагрузку на время rebuild.
Установите диск той же или совместимой категории: интерфейс, сектор, емкость, endurance и firmware должны подходить для массива.
Запустите rebuild штатной командой контроллера или замену по процедуре ZFS. Не создавайте новый virtual disk вместо восстановления существующей группы.
Контролируйте скорость rebuild, ошибки чтения, latency приложений и температуру. После завершения снова проверьте health и журнал.

Если массив потерял redundancy, сначала зафиксируйте состояние и сохраните диагностические логи. Любая дополнительная ошибка чтения в этот период повышает риск отказа группы. Для RAID 5 и RAID 6 заранее учитывайте время восстановления: большой диск, медленный rebuild и высокая нагрузка продлевают окно риска.

Scrub и проверка целостности

Для ZFS запускайте scrub по расписанию, которое не пересекается с пиковыми резервными копированиями. Частота зависит от размера пула и скорости изменения данных, но для критичных пулов часто используют ежемесячный цикл. После завершения анализируйте checksum errors, repaired errors и число ошибок по каждому vdev.

zpool scrub pool_name
zpool status -v pool_name

Scrub не заменяет резервную копию. Он обнаруживает поврежденные блоки и восстанавливает их только при наличии другой корректной копии в зеркале или RAIDZ. Для аппаратного RAID применяйте consistency check и patrol read по политике производителя, учитывая их нагрузку на рабочие диски.

Расширение пулов без простоя

Онлайн-расширение возможно только при поддержке конкретного контроллера, файловой системы и конфигурации. Перед операцией подтвердите процедуру на тестовом массиве, проверьте резервную копию и оставьте свободный ресурс для rebuild.

В аппаратном RAID расширение logical drive может потребовать перераспределения данных. Запускайте его через штатную утилиту, контролируйте progress и не перезагружайте узел без необходимости.
В ZFS добавление нового vdev меняет структуру пула. Добавляйте vdev с тем же уровнем redundancy, иначе надежность всего пула будет ограничена самым слабым vdev.
Для зеркала расширение обычно выполняется добавлением устройства в mirror, после чего запускается resilver. Для RAIDZ доступность расширения зависит от версии OpenZFS и TrueNAS.
В thin pool следите за физической емкостью underlying storage. Логическое свободное место не защищает от переполнения физического пула.

После расширения проверьте размер файловой системы, распределение данных, свободное место, latency и состояние резервного копирования. Не добавляйте одиночный диск без redundancy в пул с критичными данными ради быстрого увеличения емкости.

Емкость и прогнозирование отказов

Система должна показывать не текущий процент заполнения, а дату достижения критического порога. Рассчитайте среднюю скорость роста за 30 дней и отдельно учитывайте сезонные пики, snapshot, резервные копии и временные файлы. Для ZFS оставляйте минимум 20% свободного пространства как рабочий ориентир, а при интенсивных snapshot и random I/O закладывайте больший запас.

Для SSD стройте график Percentage Used и Data Units Written. Если за 30 дней показатель вырос на 6 процентных пунктов, а до критического порога осталось 15 пунктов, планируйте закупку и замену заранее. Такой расчет не дает гарантии даты отказа, но помогает избежать срочной закупки совместимых накопителей.

Храните запасные диски с учетом интерфейса, сектора, емкости, endurance и firmware. Диск большей емкости не всегда подходит для старого контроллера, а потребительский SSD может быстро исчерпать ресурс при записи журналов виртуальных машин.

Отказоустойчивость самого мониторинга

Размещайте коллекторы на двух независимых узлах.
Отправляйте heartbeat каждые 60 секунд и создавайте P1 при отсутствии данных 5 минут.
Синхронизируйте время по NTP, иначе события массива и хоста будет трудно сопоставить.
Храните метрики производительности минимум 30-90 дней, а события замены и firmware дольше срока гарантии оборудования.
Защищайте SNMPv3, API и CLI-доступ сетевыми ACL, MFA для интерактивных учетных записей и отдельными service account.
Проверяйте доставку уведомлений тестовым событием каждый месяц.

Для резервного мониторинга или хранения архивов метрик можно выделить отдельный облачный ресурс, например облачную инфраструктуру Timeweb Cloud. Доступ к такому узлу должен сохраняться при отказе локального массива, а резервные данные нужно шифровать и регулярно восстанавливать на тестовой площадке.

Пошаговый запуск за один рабочий цикл

Составьте таблицу активов с полями site, host, array, controller, enclosure, slot, serial, pool, firmware и владельцем сервиса.
Подключите сбор состояния через SNMPv3 и CLI/API. Сначала собирайте сырые ответы, затем добавляйте преобразование в метрики.
Настройте сбор IOPS, latency p95, throughput, queue depth, cache mode, температуры, SMART и свободного места.
Снимите baseline в течение 7-14 дней и разделите рабочие, ночные и резервные нагрузки.
Создайте P1, P2 и P3 с дедупликацией, маршрутами и временем реакции.
Проверьте сценарии: отключение диска в тестовой системе, переход write-back в write-through, пропадание SNMP и заполнение пула.
Оформите runbook для замены диска, rebuild, scrub, обновления микрокода и расширения емкости.
Раз в месяц проверяйте восстановление резервной копии, доставку алертов и актуальность совместимых запасных дисков.

Чек-лист администратора

У каждого массива есть два независимых канала наблюдения.
Состояние RAID, ZFS pool и hot spare проверяется автоматически.
IOPS, latency p95/p99, throughput и queue depth сохраняются с понятными единицами.
Write-back cache связан с состоянием батареи или flash backup.
SMART и NVMe health доступны для каждого диска с серийным номером и слотом.
Порог заполнения пула учитывает snapshot, thin provisioning и скорость роста данных.
Rebuild, scrub и consistency check не запускаются одновременно без расчета нагрузки.
Есть проверенная процедура замены конкретной модели диска.
Firmware обновляется после проверки совместимости и резервной копии конфигурации.
Мониторинг отправляет heartbeat, а отсутствие данных создает отдельный алерт.

Система мониторинга приносит пользу, когда каждое событие связано с действием: проверить слот, ограничить нагрузку, заменить диск, восстановить кэш или запланировать расширение. Собирайте технические метрики вместе с контекстом, поддерживайте актуальный инвентарь и регулярно проверяйте процедуры на тестовом оборудовании. Так массив остается предсказуемым, а обслуживание проходит до отказа, а не после него.