Admin-Alltag: Lernen aus einem Beinahe-Desaster mit Ceph

Gut, wenn man größere Ausfälle ohne Datenverlust und Geschäftsunterbrechung übersteht. Es gilt: Je besser die Vorbereitung, desto kleiner das Desaster.

Artikel verschenken
In Pocket speichern vorlesen Druckansicht 6 Kommentare lesen

(Bild: AdobeStock, Valentino Sani)

Lesezeit: 17 Min.
Von
  • Michael Prokop
Inhaltsverzeichnis

An einem Freitagabend, im Wartungsfenster für die IT-Infrastruktur eines Kunden, stand das Upgrade eines Ceph-Clusters nach vorliegender Checkliste auf dem Plan. Das Test-Upgrade ebenso wie vergleichbare Upgrades bei anderen Kunden waren bereits mehrfach erfolgreich durchgelaufen. Aber an diesem Abend, auf diesem System lief nichts nach Plan: Von 36 Platten im Ceph-Cluster fielen 33 aus.

Das betroffene System ist ein hyperkonvergenter Cluster mit Proxmox Virtual Environment und Ceph, es kombiniert also Hypervisor und Software-defined Storage auf einem Cluster. Er besteht aus drei Debian-Servern, genannt server1, server2 und server3, die auf Proxmox VE v5 mit Debian 9 und Ceph Luminous v12.2.13 laufen. Jeder Knoten verfügt über 12 Festplatten für den Einsatz als Ceph-OSDs mit insgesamt 65 TByte.

Die Aktualisierung des Systems begann mit dem Upgrade von Proxmox VE v5/Debian 9 auf Proxmox VE v6/Debian 10. Dazu gehörte es, das für die Clusterkommunikation zuständige corosync von Version 2 auf 3 zu aktualisieren. Dieses Upgrade erforderte einige Konfigurationsänderungen, unter anderem die corosync-Konfiguration von ring0 und ring1 sowie die mon_host-Konfiguration von Ceph.