Gestern hat's gescheppert...

[thoe]

Hallo,

gestern hab ich Updates auf den Nodes eingespielt. Dafür hab ich den jeweilligen Node freimigriert.
Dabei war auf einam mal die Netzwerkverbindung komplett weg. Als sie wiederkam sah ich dass alle VMs und Container auf allen drei Nodes rebootet hatten.

Vier blieben gelocked aus. Leider habe ich den Grund dafür nicht rausgefunden.

qm unlock <vmid>

funktionierte nicht.

Was half war in der /etc/pve/ha/resources.cfg die HA-Einträge der VMs zu löschen. Danach wurden die VMs freigegeben und ließen sich wieder starten.

Meine PVE-Version:

pveversion -v
proxmox-ve: 5.3-1 (running kernel: 4.15.18-11-pve)
pve-manager: 5.3-9 (running version: 5.3-9/ba817b29)
pve-kernel-4.15: 5.3-2
pve-kernel-4.15.18-11-pve: 4.15.18-33
pve-kernel-4.15.18-10-pve: 4.15.18-32
pve-kernel-4.15.18-9-pve: 4.15.18-30
pve-kernel-4.15.18-8-pve: 4.15.18-28
pve-kernel-4.15.18-7-pve: 4.15.18-27
pve-kernel-4.15.17-1-pve: 4.15.17-9
ceph: 12.2.11-pve1
corosync: 2.4.4-pve1
criu: 2.11.1-1~bpo90
glusterfs-client: 3.8.8-1
ksm-control-daemon: 1.2-2
libjs-extjs: 6.0.1-2
libpve-access-control: 5.1-3
libpve-apiclient-perl: 2.0-5
libpve-common-perl: 5.0-46
libpve-guest-common-perl: 2.0-20
libpve-http-server-perl: 2.0-11
libpve-storage-perl: 5.0-38
libqb0: 1.0.3-1~bpo9
lvm2: 2.02.168-pve6
lxc-pve: 3.1.0-3
lxcfs: 3.0.3-pve1
novnc-pve: 1.0.0-2
proxmox-widget-toolkit: 1.0-22
pve-cluster: 5.0-33
pve-container: 2.0-34
pve-docs: 5.3-2
pve-edk2-firmware: 1.20181023-1
pve-firewall: 3.0-17
pve-firmware: 2.0-6
pve-ha-manager: 2.0-6
pve-i18n: 1.0-9
pve-libspice-server1: 0.14.1-2
pve-qemu-kvm: 2.12.1-1
pve-xtermjs: 3.10.1-1
qemu-server: 5.0-46
smartmontools: 6.5+svn4324-1
spiceterm: 3.0-5
vncterm: 1.5-3
zfsutils-linux: 0.7.12-pve1~bpo1

Kam das Problem auch bei anderen vor?

 

[sb-jw]

Ich stoppe vor Updates in einem Cluster wo es HA VMs gibt die Dienste "pve-ha-lrm" und "pve-ha-crm" auf dem zu aktualisierenden Node.

 

[Alwin]

Naja, eine Vermutung von mir, läuft Corosync auf dem selben Interface wie die Migration und das Storage?

 

[thoe]

Ich stoppe vor Updates in einem Cluster wo es HA VMs gibt die Dienste "pve-ha-lrm" und "pve-ha-crm" auf dem zu aktualisierenden Node.

Ich dachte der Nummer könnte ich ausweichen, wenn ich den upzudatenden Node vorher freiziehe.

Naja, eine Vermutung von mir, läuft Corosync auf dem selben Interface wie die Migration und das Storage?

Hmmm....ich hab ein Netz für Ceph (10Gbit) und eines für die normale Anbindung (1Gbit). Für weitere Netze gehen mir einfach die Nics aus.

 

[Alwin]

Ich dachte der Nummer könnte ich ausweichen, wenn ich den upzudatenden Node vorher freiziehe.

Das sollte es sich auch.

Hmmm....ich hab ein Netz für Ceph (10Gbit) und eines für die normale Anbindung (1Gbit). Für weitere Netze gehen mir einfach die Nics aus.

Da nämlich hier die Krux liegt, die Latenz ist vermutlich zu hoch und alle Nodes fallen aus dem Cluster (Corosync). Das sollte sich im Syslog wiederfinden (corosync retransmit).

 

[thoe]

Das sollte es sich auch.


Da nämlich hier die Krux liegt, die Latenz ist vermutlich zu hoch und alle Nodes fallen aus dem Cluster (Corosync). Das sollte sich im Syslog wiederfinden (corosync retransmit).

Hmmm, im syslog finde ich dazu leider nix. Ich kann doch aus...

cat corosync.conf
logging {
  debug: off
  to_syslog: yes
}

nodelist {
  node {
    name: prox1
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 192.168.100.35
  }
  node {
    name: prox2
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 192.168.100.36
  }
  node {
    name: prox3
    nodeid: 3
    quorum_votes: 1
    ring0_addr: 192.168.100.37
  }
}

quorum {
  provider: corosync_votequorum
}

totem {
  cluster_name: gmlcluster
  config_version: 3
  interface {
    bindnetaddr: 192.168.100.35
    ringnumber: 0
  }
  ip_version: ipv4
  secauth: on
  version: 2
}

...schließen, dass Corosync über das 100.ter Netz läuft? Damit wäre es getrennt vom Storage.
Es kann dann doch eigentlich nur zu Latenzproblemen kommen, wenn gerade zu diesem Zeitpunkt der/die/das VMs viel übers Netz abfackeln.
Die Lösung wäre also corosync komplett über ein eigenes Netzwerk laufen zu lassen??

Gruß Thomas

 

[sb-jw]

Die Lösung wäre also corosync komplett über ein eigenes Netzwerk laufen zu lassen??

Noch nen eigenen Switch dazu dann hättest du best practice. Ich muss aber aus der Erfahrung heraus sagen, dass in der Regel 2x 10GbE im LACP vollkommen ausreichend ist, mir ist bisher noch kein Cluster unterkommen was aufgrund von Corosync ausgefallen wäre.

Aber probier beim nächsten mal einfach die Services zu stoppen. Mir ist deshalb früher immer der Cluster komplett ausgestiegen, daher mache ich das einfach Routine mäßig davor, ein Ausfall ist nicht hinnehmbar für mich.