Танец с 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 nfsecho "=== Кто чем пользуется ==="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 "---"doneecho "=== Что в 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,rootdirpvesm 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 101qm set 101 --virtio0 nfs-data:101/vm-101-disk-1.qcow2qm set 101 --ide0 nfs-data:101/vm-101-disk-0.qcow2qm 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 $vmiddone# 2. Меняем storage для всех VMfor 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 $vmiddone

---

🛑 Глава: «Как мы чуть не убили 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/dataumount /store/nfs/ssdumount /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 --disablepvesm 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 — считайте, что у вас уже был даунтайм, просто вы ещё не знаете когда.» 😄