Пересматриваю это, так как проблемы все еще возникают. К положительным новостям: похоже, обновление прошивки Mellanox card могло решить эту проблему, и с тех пор она больше не давала сбои. Я также внес некоторые изменения: corosync теперь работает в 10G сети, общей с VM, так как там, как мне кажется, меньше трафика. Также установил PVE на свою машину для работы, в качестве dual boot ubuntu/PVE... эта машина обычно выключена или загружена в Ubuntu. Я хотел иметь эту машину как резервный PVE сервер на случай, если мне придется отключать всю стойку. Поэтому она присоединена к кластеру, но я настроил ее так, чтобы она не участвовала в голосовании. Думаю, я все настроил правильно, но по какой-то причине у меня очень повторяющиеся проблемы. Если я перенесу все VM на vhost2 и выключу vhost1, vhost2 теряет кворум, затем сам себя отключает и перезагружается. Это произошло 3 раза подряд в тестах, каждый раз с одними и теми же симптомами: перед выключением vhost1, ожидаемое и максимальное количество голосов показывают 3, как и положено, общее количество голосов 3, кворум 2. После выключения vhost1, ожидаемое, максимальное и кворум остаются прежними, но общее количество падает до 1 – как будто qnet устройство не предоставляет голос.

Код:
root@VHOST2:~# pvecm status
Cluster information
-------------------
Name:             homelab
Config Version:   5
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Fri May 31 13:11:30 2024
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          0x00000002
Ring ID:          1.1616
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2
Flags:            Quorate Qdevice

Membership information
----------------------
   Nodeid      Votes    Qdevice Name
0x00000001          1         NR 192.168.1.10
0x00000002          1    A,V,NMW 192.168.1.20 (local)
0x00000000          1            Qdevice

root@VHOST2:~# pvecm status
Cluster information
-------------------
Name:             homelab
Config Version:   5
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Fri May 31 13:11:32 2024
Quorum provider:  corosync_votequorum
Nodes:            1
Node ID:          0x00000002
Ring ID:          2.161a
Quorate:          No

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      1
Quorum:           2 Activity blocked
Flags:            Qdevice

Membership information
----------------------
   Nodeid      Votes    Qdevice Name
0x00000002          1   A,NV,NMW 192.168.1.20 (local)
0x00000000          0            Qdevice (votes 1)

Заметил вот эту последнюю строку, где qdevice показывает 0 голосов, но указывает голоса 1 в скобках.

Вот новая конфигурация corosync с резервной машиной, которая не участвует в голосовании – я сделал это так, потому что эта машина предназначена только для резерва, а не для кластера как такового, но похоже, нет другого способа live migrate, если она не включена в кластер:

Код:
root@VHOST2:~# cat /etc/pve/corosync.conf
logging {
 debug: off
 to_syslog: yes
}

nodelist {
 node {
   name: VHOST1
   nodeid: 1
   quorum_votes: 1
   ring0_addr: 192.168.1.10
 }
 node {
   name: VHOST2
   nodeid: 2
   quorum_votes: 1
   ring0_addr: 192.168.1.20
 }
 node {
   name: VHOST-backup
   nodeid: 3
   quorum_votes: 0
   ring0_addr: 192.168.1.40
 }
}

quorum {
 device {
   model: net
   net {
     algorithm: ffsplit
     host: 192.168.1.30
     tls: on
   }
   votes: 1
 }
 provider: corosync_votequorum
 expected_votes: 3
}

totem {
 cluster_name: homelab
 config_version: 5
 interface {
   linknumber: 0
 }
 ip_version: ipv4-6
 link_mode: passive
 secauth: on
 version: 2
}

Если это неправильный способ сделать это, пожалуйста, дайте знать, как я должен был настроить это вместо этого. Я исхожу из долгой истории RHEL/CentOS и RHev/oVirt и OpenStack, поэтому внутренности PVE немного отличаются, хотя corosync нет. Но переход на PVE дома был из-за заманчивой перспективы live migration с поддержкой vgpu (неофициально поддерживается, но подтверждено работающим с некоторыми оговорками), и хотя у нас много RHEL лицензий на работе, они не применимы к моим игрушкам дома.

Заметил такую штуку, может и не в тему, а может и ерунда! Ты спрашиваешь: На каком хосте находится этот виртуальный роутер? Как это влияет на сеть, когда выключается его хост?

И раз уж, скорее всего, спросят, причина, по которой есть резервный хост, чтобы некоторые вещи продолжали работать, если вдруг я выключу весь шкаф, — это практически только пара небольших ВМ с внешними сервисами и, самое главное, мой роутер. Не хотелось бы возвращаться к временам, когда роутер работал на отдельном устройстве, когда он так счастлив быть виртуализированным, бедняга...

Не должно быть никакой причины, чтобы связь между qdevice и vhost2 перестала работать, когда node 1 недоступен, ведь каждая машина подключена к коммутатору через свой собственный канал связи. Видимо, проблема в V to NV, но почему он переключается? Вывод статуса показывает число узлов как "2", поэтому я подозреваю, что резервный узел без голоса не считается узлом. Но, если читать мануал, который ты прислал, там сказано: "Для использования этого алгоритма необходимо установить количество голосов на узел равным 1 (по умолчанию), и количество голосов у qdevice также должно быть 1. Это достигается установкой ключа quorum.device.votes в файле corosync.conf равным 1." – так что я не уверен, означает ли это, что узел с 0 голосов вызовет сбой ffsplit. Я ничего не делал, чтобы vhost1 отображался как NR, поэтому не знаю, почему так происходит. Сейчас проверяю, всё выглядит нормально:

Код: Информация о членстве
----------------------
   Nodeid      Votes    Qdevice Name
0x00000001          1    A,V,NMW 192.168.1.10
0x00000002          1    A,V,NMW 192.168.1.20 (local)
0x00000000          1            Qdevice

Я ничего не трогал в конфигурациях или сервисах с прошлой недели, когда проводил тестирование. Сейчас перенесу всё на vhost2 и выключу vhost1 и посмотрю, что произойдет...