Сброс / Удаление кластера PROXMOX

Введение

Иногда возникают проблемы с кластером PROXMOX, чаще всего это происходит из-за непонимания того как этот кластер вообще работает. В случае когда чистые сервера объединяются в новый кластер как правило проблем никаких не возникает, но ситуации бывают разные.

Наверное все кто работал с данной системой виртуализации натыкались на разные "грабли". Я рекомендую перед тем как что-то сделать на сервере PROXMOX создать резервные копии файлов виртуальных машин, а так же файл storage.cfg - это значительно облегчит Вам жизни. Сделать это можно например так:

mkdir /root/pve-backup && cp -r /etc/pve/{storage.cfg,nodes}

Этого вполне достаточно, что-бы сэкономить время.

Но это уже скорее всего лирика, кластер уже лежит раз Вы читаете эту статью. Не будем терять времени и приступим к восстановлению.

Резервная копия конфигурации ноды

Заходим на сервер по SSH, смотреть на pvecm status особого смысла нет т.к. все у нас лежит. На всякий случай делаем бэкап того, что мы имеем:

mkdir /root/pve-backup && cp -r /etc/pve/{storage.cfg,nodes}

Бывает, что /etc/pve не доступен из-за падения служб или их зависанием. Настоятельно рекомендую добиться того, чтобы скопировать текущие файлы кластера перезапустив кластер systemctl restart pve-cluster.service. После перезапуска пытаемся сделать резервную копию. Если не получилось идем на другой сервер который в этом кластере и пытаемся сделать тоже самое т.к. если кластер работал то конфигурация машин и хранилища будут всех нод.

Обнуляем ноду PROXMOX

Смотрим текущий статус кластера:

pvecm status

Все машины которые кроме этой ноды - удаляем:

pvecm delnode [Имя ноды или IP адрес]

Останавливаем все сервисы:

systemctl stop pvestatd.service
systemctl stop pvedaemon.service
systemctl stop pve-cluster.service
systemctl stop corosync

Заходим базу данных кластера:

sqlite3 /var/lib/pve-cluster/config.db

Удаляем конфигурацию:

SQLite version 3.27.2 2019-02-25 16:06:06
Enter ".help" for usage hints.
sqlite> delete from tree where name = 'corosync.conf';
sqlite> .quit

Сносим остальные файлы конфигурации:

pmxcfs -l
rm /etc/pve/corosync.conf
rm /etc/corosync/*
rm /var/lib/corosync/*
rm -rf /etc/pve/nodes/*

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

Восстановление конфигурации хранилища

После перезагрузки копируем из резервной копии файл storage.cfg:

cp -r /root/pve-backup/storage.cfg /etc/pve/

Открываем файл при помощи консольного редактора:

nano -w /etc/pve/storage.cfg

Если эта нода не являлась мастером, тогда удаляем все хранилища которые не содержать nodes [название ноды], после чего на каждом хранилище удаляем эту строку.

Если нода являлась мастером, тогда удаляем все хранилища которы содержать nodes [название ноды].

Копируем файлы файлы виртуальных машин, если Вы не собираетесь добавлять ноду в кластер:

cp -r /root/pve-backup/nodes/[название ноды]/qemu-server/* /etc/pve/qemu-server/
cp -r /root/pve-backup/nodes/[название ноды]/lxc/* /etc/pve/lxc/
cp -r /root/pve-backup/nodes/[название ноды]/openvz/* /etc/pve/openvz/

Если вы собрались добавить ноду в кластер, тогда добавляем и в случае успешного добавления копируем виртуальные машины:

cp -r /root/pve-backup/nodes/[название ноды]/qemu-server/* /etc/pve/nodes/[название ноды]/qemu-server/
cp -r /root/pve-backup/nodes/[название ноды]/lxc/* /etc/pve/nodes/[название ноды]/lxc/
cp -r /root/pve-backup/nodes/[название ноды]/openvz/* /etc/pve/nodes/[название ноды]/openvz/

Открываем WEB-интерфейс, проверям наличие хранилища и виртуальных машин. 

Заключение

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

Если вы строите кластер из разных точек доступности (такое возможно), проверяйте сперва сеть между нодами на наличие multicast иначе corosync упадет не успев подняться.