Ceph freez nach Update - Fehler "OSD heartbeat_check no reply from"

P

PhilLIPHT

New Member
Feb 19, 2025
5
1
3
Guten Tag zusammen,

nach meiner Proxmox-Schulung Anfang des Jahres testen wir aktuell Proxmox im 3-Node-Cluster. Bisher lief alles super. Doch kaum sind die ersten echt-VMs auf dem Cluster, kommt der erste Crash.
Nachdem wir nun die Standard-Subscription eingespielt haben, habe ich die anstehenden Updates durchgeführt.
- VMs auf übrige Nodes 1 und 3 migriert
- Node 2 updates gestartet und erfolgreich durchgeführt
- Node 2 neu gestartet
- Nach Neustart vorerst keine Auffälligkeiten
- Ceph alles grün, alles okay
- Updates für weitere Nodes auf die gleiche Art und Weise durchgeführt.
- Irgendwann taucht dann folgender Fehler auf:
osd.6 4022 heartbeat_check: no reply from 192.168.11.1:6838 osd.14 since back 2025-...
Eine VM die während des Updates auf einem anderen Node lag, ist nicht mehr "schreibbar". Die Platten waren im Freeze, keine Möglichkeit mehr, die VM zu nutzen.

Was könnte ich noch als Ansatz liefern für eine Problemlösung oder eine Prävention, damit das in Zukunft nicht mehr passiert.

Vielen Dank an dieser Stelle und einen schönen Tag.
 
Hallo,

das ist leider schwer zu sagen ohne weitere Informationen.

- Welches Update wurde eingespielt?
- Sind nur die OSDs des aktualisierten Nodes betrroffen? Falls ja deuten die Schreibprobleme auf eine fehlende Redundanz von Ceph Komponenten (https://docs.ceph.com/en/mimic/start/intro/) hin oder eine zu niedrige Redundanz des Storage-Pools hin.

Meiner Erfahrung nach sind normale Systemupdates (auch Kernel) unauffällig. Der Einsatz von Ceph erfordert jedoch die Beachtung der ggf. von Proxmox unabhängigen Ceph-Release-Zyklen. So kann zu einem Minor-Update der Proxmox-Version auch ein Ceph-Upgrade dringend notwendig sein.

Die Ceph-Upgrades werden getrennt behandelt: https://pve.proxmox.com/wiki/Category:Ceph_Upgrade

Wenn man Ceph-Upgrades durchführt und sich dabei die notwendige Zeit lässt, dann lassen sich alle Cluster-Upgrade ohne Dienstausfall bewerkstelligen.

Ansatz für das weitere Vorgehen:
1. Keine Panik: Ceph verliert in der Regel keine Daten ohne manuelles zutun und hat erstaunliche Selbstheilungsfähigkeiten
2. Informationen sammeln: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pve_ceph_mon_and_ts

Dann ist die Fehlerursache möglichst zu identifizieren und zu beheben.

Um Ausfälle in Zukunft gänzlich zu verhindern muss das gesamte Setup auf allen Ebenen hochverfügbar (>= 3 Knoten, Redundanzen, etc.) ausgelegt sein.
 
  • Like
Reactions: florian-n
entschuldigt die späte Antwort.
Ich kann gern noch weitere Infos liefern.
Wir haben drei nodes, jede node hat einen Ceph-Monitor, jede einen Manager, jede node hat 6 OSDs und jede hat einen Metadata-Server.

Wir haben free-range-routing laufen für Ceph.

Auffällig war, dass bei Änderungen am SDN (z. B. VNet hinzugefügt) und anschließendem Apply die o. g. Fehlermeldungen kommen wie z. B.
osd.6 4022 heartbeat_check: no reply from 192.168.11.1:6838 osd.14 since back 2025-...

Kann es sein, dass bei der Übernahme der Änderungen alle notwendigen Änderungen übernommen werden, ohne dabei zu beachten, ob alle Monitore etc. für Ceph vorhanden sind oder evtl. Änderungen an node1 noch nicht vollständig abgeschlossen sind, node2 aber schon vom Netz gegangen ist? Dann hätte man nämlich ein solches Phänomen, dass angeblich Server down sind, die gar nicht down sind.

Ich hoffe ich konnte noch ein paar Infos liefern und bin natürlich dankbar für alle Tipps.

Danke und noch einen schönen Tag.
 
UdoB said:
Du sagst nix über die Anzahl der OSDs und vor allem nichts zum Netzwerk.

Ich hatte im Laufe eines Jahres - im Homelab mit kleiner Hardware, nicht im Job - festgestellt, dass Ceph bei "produktiver" Nutzung durchaus mehr "Dinge" braucht, als das offizielle Minimum suggeriert.

Meine Notizen sind hier: https://forum.proxmox.com/threads/fabu-can-i-use-ceph-in-a-_very_-small-cluster.159671/
Click to expand...

Wir haben einen AMD-Server mit 96 Cores, 1 Terbyte RAM, je 6 OSD als NVME aus der KIOXIA CD8P-V-Serie.
Ich denke, damit sollten wir rein hardware-seitig sehr gut für Proxmox aufgestellt sein. Wir sprechen hier ja auch über ein kommerziell eingesetztes System mit Subscription und eben kein Homelab.

Aber sicher hast du vollkommen Recht, dass Ceph ordentlich Ressourcen frisst. Darauf haben die Jungs von Proxmox in der Schulung auch hingewiesen. War auch ebenfalls einer von vielen wichtigen Tipps :)
 
  • Like
Reactions: UdoB
Ich werde nicht ganz schlau, was du mit SDN und dem Ceph Netzwerk machst, aber ich gehe bei der Hardware mal von einem Konfigurationsfehler im Netzwerk aus.
 
Falk R. said:
Ich werde nicht ganz schlau, was du mit SDN und dem Ceph Netzwerk machst, aber ich gehe bei der Hardware mal von einem Konfigurationsfehler im Netzwerk aus.
Click to expand...
Danke für deine Antwort, hier habe ich nochmal unsere configs:

Code: 
root@pm01:~# cat /etc/ceph/ceph.conf
[global]
        auth_client_required = cephx
        auth_cluster_required = cephx
        auth_service_required = cephx
        cluster_network = 192.168.16.3/28
        fsid = 018054a7-4711-4bb4-964d-d3a1b022a28e
        mon_allow_pool_delete = true
        mon_host = 192.168.16.3 192.168.16.2 192.168.16.1
        ms_bind_ipv4 = true
        ms_bind_ipv6 = false
        osd_pool_default_min_size = 2
        osd_pool_default_size = 3
        public_network = 192.168.16.3/28

[client]
        keyring = /etc/pve/priv/$cluster.$name.keyring

[client.crash]
        keyring = /etc/pve/ceph/$cluster.$name.keyring

[mds]
        keyring = /var/lib/ceph/mds/ceph-$id/keyring

[mds.pm01]
        host = pm01
        mds_standby_for_name = pve

[mds.pm02]
        host = pm02
        mds_standby_for_name = pve

[mds.pm03]
        host = pm03
        mds_standby_for_name = pve

[mon.pm01]
        public_addr = 192.168.16.1

[mon.pm02]
        public_addr = 192.168.16.2

[mon.pm03]
        public_addr = 192.168.16.3

Code: 
root@pm01:~# cat /etc/frr/frr.conf
# default to using syslog. /etc/rsyslog.d/45-frr.conf places the log in
# /var/log/frr/frr.log
#
# Note:
# FRR's configuration shell, vtysh, dynamically edits the live, in-memory
# configuration while FRR is running. When instructed, vtysh will persist the
# live configuration to this file, overwriting its contents. If you want to
# avoid this, you can edit this file manually before starting FRR, or instruct
# vtysh to write configuration to a different file.

frr defaults traditional
hostname pm01
log syslog warning
ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface lo
 ip address 192.168.16.1/32
 ip router openfabric 1
 openfabric passive
!
interface ens17f0np0
 ip router openfabric 1
 openfabric csnp-interval 2
 openfabric hello-interval 1
 openfabric hello-multiplier 2
!
interface ens17f1np1
 ip router openfabric 1
 openfabric csnp-interval 2
 openfabric hello-interval 1
 openfabric hello-multiplier 2
!
line vty
!
router openfabric 1
 net 49.0001.1111.1111.1111.00
 lsp-gen-interval 1
 max-lsp-lifetime 600
 lsp-refresh-interval 180

vielleicht hilft das ja noch? Weiterhin finde ich auch bei Suchen im Forum hier oder im Netz keine Infos zu "heartbeat no reply from".
 
  • Like
Reactions: PhilLIPHT
Falk R. said:
Du kennst diese Anleitung?
https://pve.proxmox.com/wiki/Full_Mesh_Network_for_Ceph_Server#.2Fetc.2Fnetwork.2Finterfaces

Da beim apply des SDN der FRR Service neu gestartet wird, hast du immer kleine Aussetzer wenn du am Netzwerk rum konfigurierst.
Da ich immer switched Setups mache, kann ich dir nicht ganz so viel weiterhelfen beim Routing.
Click to expand...
ja wir haben auch genau nach der Anleitung konfiguriert - Routed Setup (with Fallback)

Wir beobachten das mal. Eigentlich ist es jedoch sehr unglücklich wenn man z. B. ein neues VNet anlegt, muss man es natürlich auch mit apply übernehmen, was dann jedoch wieder Fehler auslöst weil es einen Timeout gibt...klingt natürlich logisch wenn der FRR neu gestartet wird. Eigentlich hat man doch aber mehr als 2 Nodes, damit genau das nicht passiert... :-/
 
You must log in or register to reply here.
Top Bottom