Автоматический мониторинг и восстановление файловых систем: готовые скрипты и интеграции для DevOps

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

Эта статья предоставляет готовые инструменты для построения такой системы. Вы получите скрипты для безопасного автоматического запуска fsck, конфигурации для интеграции с популярными системами мониторинга и стратегии отказоустойчивого восстановления, адаптированные под разные среды, включая облачные хранилища и контейнерные платформы.

Получение готовых, безопасных и проверенных скриптов для автоматизации

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

Ниже приведен пример bash-скрипта safe_fsck_runner.sh с базовыми проверками безопасности.

#!/bin/bash
# safe_fsck_runner.sh - безопасный запуск fsck для указанного устройства
set -euo pipefail

DEVICE="${1:-}"
LOG_FILE="/var/log/fsck_${DEVICE//\//_}.log"

if [[ -z "$DEVICE" ]]; then
    echo "Ошибка: укажите устройство (например, /dev/sda1)" >&2
    exit 1
fi

# 1. Проверяем, существует ли устройство
if [[ ! -b "$DEVICE" ]]; then
    echo "Устройство $DEVICE не найдено." | tee -a "$LOG_FILE"
    exit 1
fi

# 2. Проверяем, смонтировано ли устройство в режиме read-only или read-write
MOUNT_INFO=$(findmnt -n -o OPTIONS "$DEVICE" 2>/dev/null || true)
if echo "$MOUNT_INFO" | grep -q 'rw,'; then
    echo "КРИТИЧЕСКИЙ ОТКАЗ: Устройство $DEVICE смонтировано в режиме read-write. Запуск fsck невозможен." | tee -a "$LOG_FILE"
    exit 1
fi

echo "$(date): Начало проверки $DEVICE" >> "$LOG_FILE"

# 3. Если устройство смонтировано как read-only, можно продолжить.
# 4. Запускаем fsck в non-interactive режиме с автоматическим исправлением.
#    Используем флаг '-y' для автоматического ответа 'yes' на запросы.
if fsck -y "$DEVICE" 2>&1 | tee -a "$LOG_FILE"; then
    echo "$(date): Проверка $DEVICE завершена успешно." >> "$LOG_FILE"
    exit 0
else
    FSECK_EXIT_CODE=${PIPESTATUS[0]}
    echo "$(date): Проверка $DEVICE завершилась с кодом $FSECK_EXIT_CODE. Требуется вмешательство." >> "$LOG_FILE"
    exit $FSECK_EXIT_CODE
fi

Для регулярного выполнения скрипта используйте планировщик cron или systemd timer. Systemd предпочтительнее для лучшего контроля и логирования.

Пример unit-файла systemd службы (/etc/systemd/system/safe-fsck.service):

[Unit]
Description=Safe Automatic Fsck for /dev/sda1
After=local-fs.target
Requires=local-fs.target
ConditionPathIsBlockDevice=/dev/sda1

[Service]
Type=oneshot
ExecStart=/usr/local/bin/safe_fsck_runner.sh /dev/sda1
# Отправляем вывод в syslog для централизованного сбора
StandardOutput=syslog
StandardError=syslog

[Install]
WantedBy=multi-user.target

Пример systemd таймера для запуска службы каждое воскресенье в 03:00 (/etc/systemd/system/safe-fsck.timer):

[Unit]
Description=Run safe-fsck weekly

[Timer]
OnCalendar=Sun *-*-* 03:00:00
Persistent=true
Unit=safe-fsck.service

[Install]
WantedBy=timers.target

Активируйте таймер командами: systemctl daemon-reload, systemctl enable --now safe-fsck.timer.

Интеграция мониторинга с алертингом для немедленного реагирования

Плановые проверки - это профилактика. Реагирование на сбои в реальном времени требует интеграции с системами мониторинга. Ключевые метрики для отслеживания:

• Статус файловой системы (read-only): Принудительное переключение тома в режим только для чтения - явный признак ошибки ввода-вывода.
• Количество ошибок ввода-вывода (IO errors): Счетчики из /sys/block/{device}/stat или /proc/diskstats.
• Доступное место inode: Исчерпание inode приводит к сбоям, даже если свободно место на диске.

Для сбора этих метрик используйте node_exporter для Prometheus или агент Zabbix. Node_exporter по умолчанию предоставляет метрику node_filesystem_readonly{device="/dev/sda1"}.

Пример правила алертинга для Prometheus Alertmanager, которое срабатывает, если файлова система перешла в read-only более чем на 30 секунд:

groups:
- name: filesystem_alerts
  rules:
  - alert: FilesystemReadOnly
    expr: node_filesystem_readonly{device=~"/dev/.*"} == 1
    for: 30s
    labels:
      severity: critical
    annotations:
      summary: "Файловая система {{ $labels.mountpoint }} перешла в режим только для чтения"
      description: "Устройство {{ $labels.device }} (точка монтирования {{ $labels.mountpoint }}) находится в состоянии read-only. Требуется проверка fsck."

Цель алерта - не просто уведомить, а запустить процесс восстановления. Настройте в Alertmanager webhook, который будет вызывать скрипт автоматического реагирования. Этот скрипт может:

1. Получить из алерта информацию об устройстве ($labels.device).
2. Попытаться безопасно демонтировать том (если это возможно в вашей архитектуре).
3. Запустить скрипт safe_fsck_runner.sh для этого устройства.
4. По результатам выполнения отправить уведомление в Slack, Telegram или тикет в Jira.

Аналогичную логику можно реализовать в Zabbix с помощью триггеров и действий (Actions), которые выполняют скрипты на целевом хосте.

Создание отказоустойчивой процедуры восстановления без простоя

Автоматический запуск fsck на работающем сервере - это всегда риск. Идеальная процедура включает изоляцию узла, перенос нагрузки и работу с томом в офлайн-режиме. В средах с оркестрацией это реализуемо.

Сценарий для Kubernetes (K8s):

1. При получении алерта о проблеме с файловой системой на ноде K8s, система мониторинга вызывает скрипт оркестрации.
2. Скрипт помечает ноду как unschedulable и выполняет drain, чтобы эвакуировать поды на другие ноды.
3. После освобождения ноды запускается процедура проверки и восстановления файловой системы.
4. После успешного восстановления нода возвращается в пул (uncordon).

Для автоматизации этого сценария можно использовать инструменты вроде Ansible или написать скрипт, использующий kubectl. Критически важно перед любыми действиями убедиться в наличии актуальной резервной копии критичных данных. Интеграция с системами резервного копирования должна быть частью runbook.

Для standalone-серверов или виртуальных машин стратегия иная. Если позволяет инфраструктура, используйте снимки (snapshots) дисков перед запуском восстановительных операций. В облачных средах (AWS EBS, GCP Persistent Disk) создание снапшота - операция в несколько команд.

Например, для AWS EC2 с томом EBS, на котором обнаружена ошибка, процедура может быть такой:

# 1. Создать снапшот проблемного тома для подстраховки
aws ec2 create-snapshot --volume-id vol-1234567890abcdef0 --description "Pre-fsck snapshot for $(date)"

# 2. Остановить инстанс (или отмонтировать том, если это возможно)
aws ec2 stop-instances --instance-ids i-0abcdef1234567890

# 3. Подключить том к специальной "ремонтной" инстанс
aws ec2 detach-volume --volume-id vol-1234567890abcdef0
aws ec2 attach-volume --volume-id vol-1234567890abcdef0 --instance-id i-repairinstance --device /dev/sdf

# 4. На ремонтной инстанс запустить fsck
ssh repair-instance "sudo fsck -y /dev/sdf"

# 5. Вернуть том на исходный инстанс и запустить его

Оценка рисков и предотвращение потери данных

Частота автоматических проверок зависит от критичности данных и интенсивности работы:

• Высоконагруженные БД, виртуальные машины: Еженедельная плановая проверка (например, в воскресенье).
• Системные тома, томы с логами: Ежемесячная проверка может быть достаточной.
• Тома, перешедшие в read-only: Немедленная реакция по алерту.

Главное правило: автоматический fsck с флагом исправления (-y) никогда не должен запускаться на томах, смонтированных в режиме read-write. Скрипт должен это категорически проверять и прерывать выполнение. Запуск возможен только на отмонтированных томах или томах, принудительно переведенных в read-only ядром.

Обязательный этап - тестирование всей процедуры в изолированном staging-окружении. Создайте виртуальную машину, смоделируйте повреждение файловой системы (например, с помощью dd для записи мусора в суперблок) и проверьте, как срабатывает ваша система мониторинга, алертинг и скрипт восстановления. Это позволит выявить недостатки runbook до реального инцидента.

Адаптация решения под конкретные среды и файловые системы

Скрипты и подходы, описанные выше, в первую очередь ориентированы на традиционные файловые системы, такие как ext4 и XFS. Для других ФС требуются корректировки.

Для ZFS: Вместо fsck используется команда zpool scrub для проверки целостности данных в пуле. Мониторинг нужно настраивать на проверку состояния пула (zpool status). Автоматическое восстановление в ZFS часто сводится к замене сбойного диска, если используется избыточность (mirror, RAIDZ).

Для Btrfs: Проверка выполняется командой btrfs scrub. Восстановление может быть более сложным, часто требует балансировки или использования снимков.

Для сетевых файловых систем (NFS): Проверка на стороне клиента часто невозможна. Мониторинг должен быть сосредоточен на доступности share, задержках и ошибках ввода-вывода. Восстановление обычно требует действий на стороне NFS-сервера.

В облачных средах: Работа с файловой системой на облачных дисках (AWS EBS, Azure Disk, GCP Persistent Disk) имеет свою специфику. Часто проще и быстрее отмонтировать поврежденный том, создать новый из последнего исправного снапшота и подключить его, чем пытаться выполнить длительный fsck. Автоматизация в таком случае смещается в плоскость Infrastructure as Code (Terraform, CloudFormation) для воссоздания ресурсов.

Верификация и документирование рабочего процесса

Любая автоматизация должна быть задокументирована в формате Runbook. Runbook для автоматического восстановления файловой системы должен содержать:

• Цель: Краткое описание процедуры.
• Триггер: При каких условиях запускается (например, алерт "FilesystemReadOnly").
• Необходимые условия: Проверки перед запуском (существование снапшота, статус резервной копии).
• Пошаговые действия: Детальное описание шагов, которые выполняет автоматизация, с указанием выполняемых команд.
• Критерии успеха: Как проверить, что процедура завершилась успешно (файловая система смонтирована rw, сервисы работают).
• Действия при ошибке: Что делать, если автоматическая процедура не смогла восстановить систему (например, эскалация на on-call инженера).

Все действия скриптов должны записываться в структурированные логи (например, в JSON) для последующего аудита. После каждого реального срабатывания автоматики, даже успешного, рекомендуется проводить короткий post-mortem анализ, чтобы ответить на вопросы: все ли шаги выполнились корректно, можно ли сократить время восстановления, были ли ложные срабатывания?

Например, вы можете интегрировать свои скрипты с системой, которая автоматически создает страницу в Confluence или инцидент в Jira Service Desk с полным логом выполнения для анализа.

Внедрение описанной системы - это не разовая задача, а процесс. Начните с самого критичного сервера, разверните на нем мониторинг базовых метрик, напишите и протестируйте в staging простой скрипт безопасной проверки. Затем добавьте алертинг и простейшую автоматическую реакцию (например, уведомление в Telegram с готовой командой для запуска fsck). Постепенно усложняйте логику, добавляя интеграцию с оркестрацией и системами резервного копирования. Такой подход позволит значительно повысить отказоустойчивость вашей инфраструктуры хранения данных.