Автоматический failover при недоступности mount-точки

Неприятная ситуация когда mount вроде есть, но по факту хранилище уже умерло. NFS отвалился. iSCSI завис. Ceph не отвечает. Сервис продолжает писать… в никуда.

Решение - автоматическая логика: Проверка -> попытка remount -> переключение на fallback.

▪️ Логика failover

Проверяем, что mount существует;
Проверяем доступность записи;
Если ошибка, то пробуем remount;
Если не помогло - переключаемся на fallback.

🛠 Пример скрипта

#!/usr/bin/env bash

MOUNT_POINT="/data"
FALLBACK="/data_local"
TEST_FILE="$MOUNT_POINT/.healthcheck"

log() {
  echo "$(date '+%F %T') | $1"
}

check_mount() {
  mountpoint -q "$MOUNT_POINT" || return 1
  timeout 3 touch "$TEST_FILE" 2>/dev/null || return 1
  rm -f "$TEST_FILE"
}

remount() {
  log "Попытка remount..."
  mount -o remount "$MOUNT_POINT"
}

switch_to_fallback() {
  log "Переключение на fallback $FALLBACK"
  umount -l "$MOUNT_POINT"
  mount --bind "$FALLBACK" "$MOUNT_POINT"
}

main() {
  if check_mount; then
    log "Mount работает нормально"
    exit 0
  fi

  log "Mount недоступен"

  remount && sleep 2

  if check_mount; then
    log "Remount помог"
    exit 0
  fi

  switch_to_fallback
}

main

▪️ Что здесь важно

1. timeout - если NFS завис, без timeout скрипт повиснет навсегда.
2. mountpoint -q - Проверяет именно mount, а не просто директорию.
3. umount -l - lazy umount - полезно, если есть залипшие процессы.

▪️ Как запускать правильно

Лучше всего: systemd timer или healthcheck внутри сервиса или отдельный watchdog unit

⚠️ Нюансы

Если сервис пишет активно, то нужно ставить его на паузу перед failover;
fallback должен быть заранее подготовлен;
важно логировать переключения;
нужен механизм возврата обратно.

BashTex 📱 #bash #utils