Короткий ответ

Если pve1 пингуется по SSH, а в pvecm nodes он offline — чините кластерную сеть и corosync, не переустанавливайте PVE. Сверьте IP ring в corosync.conf, firewall, MTU, время. Не делайте pvecm delnode pve1, пока узел жив и вы хотите его вернуть: удаление узла — другая процедура.

Соседи с кворумом могут работать. Задача — снова связать knet.

Симптомы и как отличить

Типичная картина:

  • GUI: узел red/offline;
  • на самом pve1 VM могут быть running;
  • systemctl status corosync failed или токены;
  • /etc/pve на отпавшем узле отстаёт.

Отличия:

Что видноКуда
Нет кворума на всехQuorum
Нет SSHЗагрузка / сеть хоста
Сломан vmbr0Bridge
8006 нет локальноpveproxy

Возможные причины

  1. Down линка кластера, неверный VLAN.
  2. Firewall на UDP портов corosync.
  3. IP узла сменили только в interfaces, не в кластере.
  4. NTP уехал далеко.
  5. После апдейта corosync не стартовал.
  6. Разъехавшийся corosync.conf (ручная правка).

Диагностика

На отпавшем pve1 и на живом pve2:

pveversion
pvecm status
pvecm nodes
systemctl status corosync pve-cluster --no-pager
journalctl -u corosync --since '1 hour ago' --no-pager
ip -br addr
ping -c 3 <cluster-ip-pve2>
corosync-cfgtool -s

corosync-cfgtool -s показывает линки knet. Faulty link — ваш кандидат.

Сверьте nodeid и адреса в конфиге на обоих узлах (если pmxcfs RO, локальная копия).

Решение

Сценарий A. Мёртвый cluster NIC

Поднимите линк, VLAN, правильный IP из corosync.conf. Не вешайте cluster IP на случайный vmbr. После UP:

systemctl restart corosync
pvecm status

Рестарт corosync на одном узле, не на всех сразу.

Сценарий B. Firewall

Разрешите трафик corosync между узлами. Не pve-firewall stop навсегда. Проверьте, не режет ли фильтр только новый VLAN.

Сценарий C. Время

timedatectl

Синхронизируйте NTP. Большой skew ломает токены.

Сценарий D. Служба не стартует после патча

systemctl restart corosync pve-cluster
pveversion -v

Если пакет недоустановлен — добейте apt, не downgrade с случайного зеркала. Кластер обновляют поузлово.

Сценарий E. Смена IP узла

Используйте документированную процедуру PVE для смены адреса в кластере. Правка только interfaces оставляет старый bind в corosync — узел «выпал».

knet, второй ring и разъезд конфига

corosync-cfgtool -s печатает LINK ID, status, MTU. Fairly healthy vs Faulty — не игнорируйте Faulty «пока GUI зелёный с другого кольца». Одно кольцо живёт, пока не упадёт и оно.

corosync-cfgtool -s
corosync-cmapctl | grep -E 'nodelist|link|knet'
journalctl -u corosync -n 80 --no-pager

Разный cluster_name или nodeid после ручной правки /etc/pve/corosync.conf на одном узле (когда fs была RW) раскалывает кластер. Откатывайтесь к версии с кворумного узла, не «усредняйте» файлы.

Если pve1 долго был выключен, pmxcfs догонит. Не копируйте /etc/pve/qemu-server/101.conf с pve2 на локальный диск pve1 мимо fuse: получите расхождение, которое кластер потом перезапишет.

Смена hostname без процедуры PVE оставляет узел в nodes/oldname. GUI «выпал» при живом corosync. Это чинится переименованием по документации, не delnode.

Проверьте, что UDP не NAT-ится между площадками. Corosync за NAT без явного knet/туннеля — типичный «узел выпал после переезда в другой офис».

Как проверить, что проблема устранена

pvecm status
pvecm nodes
corosync-cfgtool -s
ls /etc/pve/nodes/pve1

Узел online, quorate. GUI с pve2 видит pve1. Изменение конфига VM реплицируется. Миграция тестовой VM туда-сюда проходит. После ребута pve1 членство сохраняется.

Проверьте MTU кластерного линка симметрично. Один узел 9000, второй 1500 даёт silent drop больших totem/knet кадров: ping мелкий проходит, corosync нет. Временно выровняйте MTU в 1500 для доказательства, затем решайте jumbo отдельно.

ip -br link
ping -M do -s 1472 -c 3 10.0.10.12

Если DF-ping 1472 не проходит — сначала MTU, не systemctl restart corosync по кругу. Для второго ring повторите ping на его IP. Документируйте, какой NIC для какого ring: после замены карты имена путают.

Если не помогло

  • Link 0 ok, link 1 faulty: второй ring; чините его или временно работайте на одном, если так было спроектировано.
  • Узел входит и выпадает: flapping, дубль IP кластерной сети.
  • /etc/pve на pve1 старый: дождитесь pmxcfs, не rsync.
  • Имя узла меняли hostnamectl: для PVE это ломает пути /etc/pve/nodes/....
  • Остался призрак в HA: разберите resources, не delnode первым.

Профилактика

  • Мониторинг corosync и отдельного линка.
  • Два ring если есть два NIC.
  • Не патчить все узлы разом.
  • Документировать cluster IP ≠ management IP.
  • Запрет delnode без вывода VM.
  • Алерт на Faulty knet link, даже если GUI ещё зелёный по второму кольцу кластера.
  • NTP общий для всех узлов; после замены NIC сразу ping DF и corosync-cfgtool -s.

FAQ

Чем delnode отличается от выключения узла?

Выключение — узел остаётся в конфиге, кворум считает votes (зависит от числа). delnode удаляет членство. Для ремонта питания delnode не нужен.

Нужно ли pvecm updatecerts при возврате?

Если сертификаты узлов разъехались после долгого офлайна — по ситуации. Не первая команда при faulty knet.

Можно ли systemctl restart corosync на всех?

Риск краткой потери кворума. По одному.

Узел в GUI есть, pvecm nodes нет?

Смотрите, в какой GUI вы смотрите (кэш) и локальный статус. Верьте CLI на узле.

VM на отпавшем узле остановить?

Пока диск local — они могут работать. Не стартуйте те же VMID на другом узле, пока этот жив.

Узел «offline» только в HA, pvecm nodes зелёный — чинить corosync?

Сначала HA manager и fenced/ресурсы, не knet. Corosync уже в кворуме. Смотрите ha-manager status и, не стартует ли VM дважды. delnode здесь тем более не нужен.