Танец с NFS — Как переобуть кластер на лету и не убить виртуалки

Теоретическая часть: «Почему hard — это не круто, а soft — спасение» 🔧

💾 Введение: История одной пятницы

Представьте: пятница, 17:45, вы уже мысленно в пивной. И тут тишина... Мониторинг орет красным. Ваш Proxmox кластер из 4 нод превратился в группу статуй. Ни одна VM не отвечает, команды qm list висят, а в логах — таинственные вопросительные знаки на месте дисков.

😱 Диагноз: NFS-сервер упал, а монтирование было с опцией hard. Все ноды дружно вошли в D-state (непрерываемый сон) и отказались просыпаться.

Мораль: hard монтирование в NFS — это как клей Moment. Склеивает намертво. И оторвать потом невозможно.

📊 Анатомия проблемы: Почему мы так жили и чем это кончилось

🎯 Главная проблема: Не в том, что NFS падает. А в том, как система реагирует на падение.

📡 Ключевая концепция: Hard vs Soft в NFS

🔬 Практическая часть: Как переобуть кластер без потрясений

📋 Ситуация: «Мы так жили, и всё работало... пока не упало»

Исходные данные:

• 4 ноды Proxmox в кластере

• NFS смонтирован через /etc/rc.local

• Опция hard, таймаут 600 секунд

• VM конфиги используют storage имена data: и ssd:

🎯 Цель: Перевести все ноды на Proxmox Storage с опцией soft без потери данных

Этап 1: "Сначала аудит, потом тушение" — Диагностика

bash

# 🔍 Смотрим, что у нас есть
echo "=== Текущие монтирования ==="
mount | grep nfs

echo "=== Кто чем пользуется ==="
for vmid in $(qm list | awk 'NR>1 {print $1}'); do
    echo "VM $vmid:"
    qm config $vmid | grep -E "(virtio|ide|scsi|sata|efidisk)"
    echo "---"
done

echo "=== Что в Proxmox Storage ==="
pvesm status

Находим сюрпризы:

• Старое монтирование: /store/nfs/data (hard)

• Новое монтирование: /mnt/pve/nfs-data (soft)

• Важно! Это одно и то же NFS-хранилище, просто видимое по-разному

Этап 2: "Добавили, но не включили" — Создание новых storage

Правило безопасности: Сначала добавляем новые storage, потом мигрируем, только потом удаляем старые.

bash

# ➕ Добавляем новые storage с правильными опциями
pvesm add nfs nfs-data \
  --path /mnt/pve/nfs-data \
  --server 10.10.10.10 \
  --export /storage/nfs/data \
  --options "vers=4.2,soft,timeo=30,retrans=3,noac" \
  --content images,rootdir

pvesm add nfs nfs-ssd \
  --path /mnt/pve/nfs-ssd \
  --server 10.10.10.20 \
  --export /storage/ssd \
  --options "vers=4.2,soft,timeo=30,retrans=3,noac" \
  --content images,rootdir

⚠️ Важно: Старые storage пока работают. VM даже не заметят, что появилось что-то новое.

Этап 3: "Миграция — это вам не миграция" — Переезд VM

3.1 План переезда одной ноды

bash

# 1. Выключаем HA (чтобы не убежала)
ha-manager set vm:101 --enabled 0

# 2. Отправляем VM в гости к соседям
qm migrate 101 prxmx-04 --online

# 3. На целевой ноде готовим конфиг
qm stop 101
qm set 101 --virtio0 nfs-data:101/vm-101-disk-1.qcow2
qm set 101 --ide0 nfs-data:101/vm-101-disk-0.qcow2
qm start 101

# 4. Возвращаем на место
qm migrate 101 prxmx-02 --online

3.2 Вариант: "А давайте выключим всё и переделаем" (метод доверия)

Когда работает: Если у вас есть окно обслуживания и вы доверяете своим конфигам.

bash

# 1. Выключаем ВСЕ VM на ноде
for vmid in $(qm list | awk 'NR>1 {print $1}'); do
    qm stop $vmid
done

# 2. Меняем storage для всех VM
for vmid in 101 102 103 104 105; do
    # Пример для VM с virtio дисками
    qm set $vmid --virtio0 nfs-data:$vmid/vm-$vmid-disk-0.qcow2
    # ... и так для всех дисков
done

# 3. Включаем обратно
for vmid in 101 102 103 104 105; do
    qm start $vmid
done

🛑 Глава: "Как мы чуть не убили VM 102 и почему unused — зло"

Живой пример из практики:

bash

# ❌ НЕ ДЕЛАЙТЕ ТАК! 
qm set 102 --delete unused0
# Результат: диск физически удалён, VM падает, восстановление из бэкапа

Почему так произошло? В некоторых версиях Proxmox команда qm set VMID --delete unusedN удаляет физический диск без возможности восстановления.

Правильный способ:

bash

# ✅ БЕЗОПАСНЫЙ вариант:
# 1. Отключаем старое хранилище в GUI
# Datacenter → Storage → выбрать data → Edit → отключить (Disable)

# 2. Теперь можно удалять unused записи
sed -i '/^unused[0-9]:/d' /etc/pve/nodes/$(hostname)/qemu-server/$vmid.conf

# 3. Storage data отключено, физический диск не удалится

Этап 4: "Генеральная уборка" — Отключение старого

После того как все VM перешли на новые storage:

bash

# 1. Отключаем старые монтирования
umount /store/nfs/data
umount /store/nfs/ssd
umount /store/nfs/iso

# 2. Чистим rc.local (убираем legacy)
sed -i '/mount -t nfs/d' /etc/rc.local

# 3. Отключаем старые storage в Proxmox
# В GUI: Datacenter → Storage → data → Edit → Disable
# Или через CLI:
pvesm set data --disable
pvesm set ssd --disable

Этап 5: "Чистка хвостов" — Удаление unused записей

bash

# Автоматическая очистка на всех нодах
for NODE in prxmx-01 prxmx-02 prxmx-03 prxmx-04; do
    echo "=== Нода: $NODE ==="
    ssh $NODE "for vmid in \$(qm list | awk 'NR>1 {print \$1}'); do
        if qm config \$vmid | grep -q unused; then
            echo \"  VM \$vmid - чистим...\"
            qm stop \$vmid
            sed -i '/^unused[0-9]:/d' /etc/pve/nodes/\$(hostname)/qemu-server/\$vmid.conf
            qm start \$vmid
        fi
    done"
done

📊 Итоговая таблица: Что было и что стало

✅ Чек-лист успешной миграции

• Созданы новые storage с soft опциями

• Все VM переведены на новые storage

• Старые монтирования отключены

• /etc/rc.local почищен

• Unused записи удалены (безопасно!)

• HA включен обратно

• Тестовая перезагрузка ноды пройдена

• Все VM запустились автоматически

🎯 Главные уроки

1. Никогда не используйте hard монтирование для NFS в Proxmox — это верный способ убить кластер

2. Сначала добавляем новые storage, потом мигрируем, потом удаляем старые — только так безопасно

3. unused диски — это ловушка — в вашей версии Proxmox их удаление = удаление физического диска

4. Всегда отключайте HA перед работой с VM — иначе они разбегутся по кластеру

"Если вы не тестируете свои бэкапы — считайте, что их нет. Если вы не тестируете перезагрузку ноды — считайте, что она не выживет. А если вы используете hard NFS — считайте, что у вас уже был даунтайм, просто вы ещё не знаете когда." 😄