PVE/CEPH Cluster Verhalten

kokel

Member
Mar 9, 2021
34
5
13
37
Hallo,

wir haben ein 3-Node CEPH/PVE Cluster (PVE 6.4-5/ CEPH 15.2.11) und haben ein paar Ausfalltests durchgeführt. Dabei ist uns aufgefallen, dass CEPH quasi gar nicht mehr reagiert, wenn die Links vom CEPH Public und CEPH Cluster Netzwerk down sind. Also auch die (pve-)ceph. Befehle geben keinerlei Rückmeldung und laufen in einen (gefühlt) ewigen Timeout.

Jeder Node hat abgesehen von 2 dedizierten 1GBit/s Links für GUI + Corosync 4 10GBit/s Links. Je 2 davon laufen als Active/Passive (Failover) Bond.

  • Bond 1:
    • Frontend Netze für VMs
  • Bond 2:
    • CEPH Public VLAN (Corosync Fallback)
    • CEPH Cluster VLAN
    • Live Migration VLAN
Wir haben testweise Bond 2 von einem Node komplett deaktiviert, mit folgenden Beobachtungen:
  1. CEPH-Kommandos (pveceph + ceph) liefen in einen ewigen Timeout. Es war quasi nicht möglich irgendeinen Status von CEPH abzufragen.
  2. PVE Cluster (Corosync) lief brav weiter, aus dieser Sicht war alles gut.
  3. Virtuelle Maschinen liefen weiter, das Storage wurde denen unterm Hintern weggezogen, klar. Keine Lese/Schreiboperationen möglich.

Dazu folgende Fragen:
  1. Wieso laufen die CEPH-Kommandos in einen ewigen Timeout? Für mein Verständnis sollte zumindest der Status abfragbar sein, auch wenn dieser lautet, dass der Node grad keinen Status abfragen kann oder das CEPH Cluster komplett tot ist. Einfach keine Rückmeldung über Minuten ist maximal suboptimal. Gibts da Konfigurationsmöglichkeiten?
  2. Gibts eine (Fencing?-)Möglichkeit, dass das PVE Cluster "merkt", dass das Storage für seine VMs grad bzw. +ber längere Zeit nicht verfügbar ist? In diesem Fall wäre Fencing des Nodes gut, sodass die VMs auf den verbleibenden PVE Nodes wieder hochgefahren werden.

Nachdem wir Bond 2 wieder aktiviert haben, war CEPH ziemlich selbst heilend. Wir verwenden CEPHFS für ISO Images. Dieses CEPHFS kam aber nicht ordentlich wieder hoch. Erst nach einem umount /mnt/pve/vm_isos war es wieder zugreifbar. Dazu gab es folgendes im Log:

Code:
May 05 17:25:59 node2 kernel: libceph: mds0 (1)10.1.2.4:6801 socket closed (con state OPEN)
May 05 17:26:00 node2 kernel: libceph: mds0 (1)10.1.2.4:6801 connection reset
May 05 17:26:00 node2 kernel: libceph: reset on mds0
May 05 17:26:00 node2 kernel: ceph: mds0 closed our session
May 05 17:26:00 node2 kernel: ceph: mds0 reconnect start
May 05 17:26:00 node2 kernel: libceph: mds0 (1)10.1.2.4:6801 socket closed (con state NEGOTIATING)
May 05 17:26:00 node2 systemd[1]: Starting Proxmox VE replication runner...
May 05 17:26:00 node2 systemd[1]: pvesr.service: Succeeded.
May 05 17:26:00 node2 systemd[1]: Started Proxmox VE replication runner.
May 05 17:26:01 node2 pvestatd[4000]: mkdir /mnt/pve/vm_isos: File exists at /usr/share/perl5/PVE/Storage/Plugin.pm line 1175.
May 05 17:26:01 node2 kernel: ceph: mds0 rejected session

Ist das bekanntes Verhalten?

Vielen Dank!
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!