🥇 Tipps & Tricks für die Arbeit mit Ceph in belasteten Projekten

Wenn wir Ceph als Netzwerkstorage in unterschiedlich ausgelasteten Projekten einsetzen, können wir auf verschiedene Herausforderungen stoßen, die auf den ersten Blick nicht einfach oder trivial erscheinen.

Migration von Daten aus einem alten Ceph zu einem neuen unter teilweiser Nutzung der vorherigen Server im neuen Cluster;
Lösung von Problemen bei der Verteilung des Speicherplatzes in Ceph.

Bei der Bewältigung solcher Aufgaben müssen wir in der Lage sein, OSDs korrekt zu entfernen, ohne Daten zu verlieren, was besonders bei großen Datenmengen von Bedeutung ist. Genau darum geht es in diesem Artikel.

Die nachfolgend beschriebenen Methoden sind für alle Versionen von Ceph relevant. Zudem wird berücksichtigt, dass in Ceph große Datenmengen gespeichert werden können: Um Datenverluste und andere Probleme zu vermeiden, werden einige Aktionen in mehrere Schritte unterteilt.

Einführung zu OSD

Da zwei der drei behandelten Rezepte OSDs (Object Storage Daemon) betreffen, möchte ich vor dem praktischen Teil kurz erläutern, was das überhaupt in Ceph ist und warum es so wichtig ist.

Zunächst sollte erwähnt werden, dass der gesamte Ceph-Cluster aus vielen OSD besteht. Je mehr OSD vorhanden sind, desto mehr Speicherplatz steht im Ceph zur Verfügung. Daraus ergibt sich leicht, die Hauptfunktion der OSD: sie speichern die Ceph-Objektdaten auf den Dateisystemen aller Cluster-Knoten und stellen Netzwerkzugang zu ihnen bereit (zum Lesen, Schreiben und für andere Anfragen).

Auf dieser Ebene werden auch die Replikationsparameter festgelegt, indem Objekte zwischen verschiedenen OSD kopiert werden. Hier kann man auf verschiedene Probleme stoßen, deren Lösungen im Folgenden erläutert werden.

Fall Nr. 1. Sicheres Entfernen von OSD aus dem Ceph-Cluster ohne Datenverlust

Die Notwendigkeit, OSD zu entfernen, kann durch das Herausnehmen eines Servers aus dem Cluster entstehen – zum Beispiel zur Ersetzung durch einen anderen Server, was bei uns der Fall war und den Anlass für diesen Artikel gegeben hat. Somit ist das endgültige Ziel der Manipulationen, alle OSD und Monitore auf diesem Server zu entfernen, damit er abgeschaltet werden kann.

Um eine einfache Handhabung zu gewährleisten und Situationen zu vermeiden, in denen wir beim Ausführen von Befehlen die falschen OSD angeben, definieren wir eine separate Variable, die den Wert der zu entfernenden OSD-Nummer enthält. Nennen wir sie ${ID} — hier und in der Folge ersetzt diese Variable die OSD-Nummer, mit der wir arbeiten.

Sehen wir uns den Zustand vor Beginn der Arbeiten an:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME      STATUS REWEIGHT PRI-AFF
-1       0.46857 root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
 1   ssd 0.15619      osd.1     up     1.00000  1.00000
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2     up     1.00000  1.00000

Um die OSD-Löschung einzuleiten, muss reweight sanft auf null ausgeführt werden. Dadurch verringern wir die Datenmenge in der OSD und balancieren sie auf andere OSDs. Dafür werden folgende Befehle ausgeführt:

ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78

… und so weiter bis null.

Eine sanfte Balance ist erforderlich, um Datenverlust zu vermeiden. Dies ist besonders relevant, wenn sich große Datenmengen in der OSD befinden. Um sicherzustellen, dass nach Ausführung der Befehle reweight alles erfolgreich verlaufen ist, kann man ceph -s oder in einem separaten Terminalfenster ceph -w ausführen, um Änderungen in Echtzeit zu beobachten.

Wenn die OSD „entleert“ ist, kann man mit dem Standardvorgang zu ihrer Löschung fortfahren. Dazu setzen wir die benötigte OSD in den Zustand down:

ceph osd down osd.${ID}

„Entfernen“ wir die OSD aus dem Cluster:

ceph osd out osd.${ID}

Wir stoppen den OSD-Dienst und unmounten seine Partition im Dateisystem:

systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}

Wir entfernen den OSD aus CRUSH-Karte:

ceph osd crush remove osd.${ID}

Wir löschen den OSD-Benutzer:

ceph auth del osd.${ID}

Und schließlich entfernen wir den OSD selbst:

ceph osd rm osd.${ID}

Hinweis: Wenn Sie die Ceph-Version Luminous oder höher verwenden, können die oben beschriebenen Schritte zur OSD-Entfernung auf zwei Befehle reduziert werden:

ceph osd out osd.${ID}
ceph osd purge osd.${ID}

Wenn Sie nach der Ausführung der oben genannten Schritte den Befehl ceph osd tree, ausführen, sollte zu sehen sein, dass auf dem Server, auf dem die Arbeiten durchgeführt wurden, keine OSDs mehr vorhanden sind, für die die oben genannten Operationen ausgeführt wurden:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.46857      root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2    up     1.00000  1.00000

Wir möchten anmerken, dass der Zustand des Ceph-Clusters wechselt zu HEALTH_WARN, und wir werden eine Verringerung der Anzahl der OSDs und des verfügbaren Speicherplatzes sehen.

Im Folgenden werden die Schritte beschrieben, die erforderlich sind, wenn Sie den Server vollständig ausschalten und dementsprechend aus Ceph entfernen möchten. In diesem Fall ist es wichtig zu beachten, dass vor dem Abschalten des Servers alle OSDs auf diesem Server entfernt werden müssen.

Wenn auf diesem Server keine OSD mehr vorhanden sind, müssen diese nach ihrer Entfernung aus der OSD-Karte ausgeschlossen werden. hv-2, indem Sie den folgenden Befehl ausführen:

ceph osd crush rm hv-2

Entfernen mon vom Server hv-2, indem Sie den untenstehenden Befehl auf einem anderen Server ausführen (in diesem Fall also auf hv-1):

ceph-deploy mon destroy hv-2

Danach können Sie den Server herunterfahren und mit den nächsten Schritten (z. B. der erneuten Bereitstellung usw.) fortfahren.

Fall Nr. 2. Verteilung des Speicherplatzes in einem bereits erstellten Ceph-Cluster

Die zweite Geschichte beginne ich mit einer Einleitung über PG (Placement Groups). Die Hauptrolle von PG in Ceph besteht vor allem darin, Ceph-Objekte zu aggregieren und sie anschließend in OSD zu replizieren. Die Formel, mit der die erforderliche Anzahl von PG berechnet werden kann, finden Sie in der dem entsprechenden Abschnitt Ceph-Dokumentation. Diese Frage wird dort auch anhand konkreter Beispiele behandelt.

Eine der häufigsten Herausforderungen beim Betrieb von Ceph ist das unausgeglichene Verhältnis von OSD und PG zwischen den Pools in Ceph.

Zunächst kann es zu einer Situation kommen, in der zu viele PG in einem kleinen Pool angegeben werden, was im Wesentlichen eine ineffiziente Nutzung des Speicherplatzes im Cluster darstellt. Zweitens ergibt sich in der Praxis ein ernsthafteres Problem: das Überlaufen von Daten in einem der OSD. Dies führt dazu, dass der Cluster zunächst in einen Zustand HEALTH_WARN, und dann in HEALTH_ERR. Der Grund dafür liegt darin, dass Ceph beim Berechnen des verfügbaren Datenvolumens (das lässt sich über MAX AVAIL im Ausgabeergebnis des Kommandos ceph df für jeden Pool separat) auf das verfügbare Datenvolumen in OSD zurückgreift. Wenn in auch nur einem OSD nicht genügend Speicherplatz vorhanden ist, können keine weiteren Daten geschrieben werden, bis die Daten ordnungsgemäß zwischen allen OSD verteilt sind.

Es sei darauf hingewiesen, dass diese Probleme größtenteils in der Konfigurationsphase des Ceph-Clusters gelöst werden. Ein Werkzeug, das genutzt werden kann, ist Ceph PGCalc. Mit ihm lässt sich anschaulich die notwendige Anzahl an PG berechnen. Dabei kann es auch in Situationen nützlich sein, in denen der Ceph-Cluster bereits besteht. bereits falsch konfiguriert. Hier ist zu beachten, dass Sie im Rahmen der Korrekturarbeiten wahrscheinlich die Anzahl der PG verringern müssen, und diese Möglichkeit ist in älteren Versionen von Ceph nicht verfügbar (sie wurde erst mit der Version Nautilus).

Vorstellen wir uns folgendes Szenario: Der Cluster hat den Status HEALTH_WARN weil in einem der OSD der Speicherplatz zur Neige geht. Dies wird durch die folgende Fehlermeldung angezeigt HEALTH_WARN: 1 near full osd. Nachfolgend finden Sie einen Algorithmus für den Umgang mit dieser Situation.

Zunächst müssen die vorhandenen Daten auf die restlichen OSD verteilt werden. Eine ähnliche Operation haben wir bereits im ersten Fall durchgeführt, als wir den Knoten «entleerten» – mit dem einzigen Unterschied, dass wir jetzt die Anzahl der PG leicht verringern müssen reweight. Zum Beispiel auf 0,95:

ceph osd reweight osd.${ID} 0.95

Auf diese Weise wird Speicherplatz im OSD freigegeben und der Fehler im Ceph-Status behoben. Wie bereits erwähnt, tritt dieses Problem hauptsächlich aufgrund einer falschen Konfiguration von Ceph in den frühen Phasen auf: Es ist sehr wichtig, eine Neukonfiguration durchzuführen, um zukünftige Probleme zu vermeiden.

In unserem spezifischen Fall gab es keinerlei Probleme bezüglich:

einem zu hohen Wert von replication_count in einem der Pools,
Eine zu hohe Anzahl an PG in einem Pool und zu wenig in einem anderen.

Lassen Sie uns den zuvor genannten Rechner verwenden. Er zeigt anschaulich, was eingegeben werden muss, und grundsätzlich gibt es nichts Kompliziertes daran. Bei Eingabe der erforderlichen Parameter erhalten wir die folgenden Empfehlungen:

Hinweis: Wenn Sie ein Ceph-Cluster von Grund auf neu einrichten, wird eine weitere nützliche Funktion des Rechners die Generierung von Befehlen sein, die Pools mit den in der Tabelle angegebenen Parametern erstellen.

Zur Orientierung dient die letzte Spalte — Vorgeschlagene PG-Anzahl. In unserem Fall ist auch die zweite Spalte nützlich, in der der Replikationsparameter angegeben ist, da wir beschlossen haben, den Replikationsmultiplikator zu ändern.

Zuerst müssen die Replikationsparameter geändert werden — dies sollte als erstes erfolgen, da wir durch die Verringerung des Multiplikators Speicherplatz freigeben. Während der Ausführung des Befehls kann man beobachten, dass der verfügbare Speicherplatz zunimmt:

ceph osd pool $pool_name set $replication_size

Und nach dessen Abschluss ändern wir die Werte der Parameter pg_num und pgp_num $ ../..../waf ...

ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_number

Wichtig: Wir müssen in jedem Pool nacheinander die Anzahl der PGs ändern und die Werte in anderen Pools nicht verändern, bis die Warnungen verschwunden sind. „Verminderte Datenredundanz“ und „n-Anzahl der PGs verschlechtert“.

Es kann auch überprüft werden, ob alles erfolgreich war, anhand der Ausgaben der Befehle ceph health detail und ceph -s.

Fall Nr. 3. Migration einer virtuellen Maschine von LVM zu Ceph RBD

In Situationen, in denen in einem Projekt virtuelle Maschinen eingesetzt werden, die auf gemieteten Bare-Metal-Servern installiert sind, stellt sich häufig die Frage nach einem ausfallsicheren Speicher. Zudem ist es wünschenswert, ausreichend Platz in diesem Speicher zu haben... Eine weitere häufige Situation ist, wenn eine virtuelle Maschine mit lokalem Speicher auf dem Server vorhanden ist und die Festplatte erweitert werden muss, aber kein Platz vorhanden ist, da auf dem Server kein freier Speicherplatz mehr verfügbar ist.

Das Problem kann auf verschiedene Weise gelöst werden – zum Beispiel durch die Migration zu einem anderen Server (sofern vorhanden) oder durch das Hinzufügen neuer Festplatten zum Server. Doch nicht immer ist dies möglich, daher kann die Migration von LVM zu Ceph eine exzellente Lösung für dieses Problem darstellen. Wenn Sie sich für diese Option entscheiden, vereinfachen Sie auch den zukünftigen Migrationsprozess zwischen Servern, da das lokale Speicherinfrastruktur nicht von einem Hypervisor zum anderen verschoben werden muss. Der einzige Nachteil – Sie müssen die VM während der Arbeiten vorübergehend anhalten.

Als nachfolgendes Rezept wurde ein Artikel aus diesem Blog, dessen Anweisungen in der Praxis erprobt wurden. Übrigens, wird dort auch ein Weg zur migrationslosen Migration beschrieben, allerdings war dies in unserem Fall nicht erforderlich, weshalb wir es nicht getestet haben. Sollte dies jedoch entscheidend für Ihr Projekt sein – freuen wir uns über Ihr Feedback in den Kommentaren.

Lassen Sie uns mit dem praktischen Teil beginnen. Im Beispiel verwenden wir virsh und damit libvirt. Stellen Sie zunächst sicher, dass der Ceph-Pool, in den die Daten migriert werden sollen, an libvirt angeschlossen ist:

virsh pool-dumpxml $ceph_pool

Die Beschreibung des Pools sollte Verbindungsdaten zu Ceph mit den Authentifizierungsinformationen enthalten.

Der nächste Schritt besteht darin, dass das LVM-Image in Ceph RBD konvertiert wird. Die Ausführungszeit hängt in erster Linie von der Größe des Images ab:

qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_name

Nach der Konvertierung bleibt das LVM-Image, das nützlich sein kann, falls die Migration der VM nach RBD nicht möglich ist und Änderungen zurückgerollt werden müssen. Um die Änderungen schnell zurücksetzen zu können, erstellen wir auch eine Sicherung der Konfigurationsdatei der virtuellen Maschine:

virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml

… und bearbeiten das Original (vm_name.xml). Suchen Sie den Block mit der Beschreibung der Festplatte (beginnt mit der Zeile <disk type='file' device='disk'> und endet mit </disk>). Bringen Sie ihn in die folgende Form:

Lassen Sie uns einige Details durchgehen:

Im Protokoll source Die Adresse zum Speicher in Ceph RBD wird angegeben (dies ist die Adresse mit dem Namen des Ceph-Pools und dem RBD-Image, das in der ersten Phase festgelegt wurde).
Im Block secret Es wird der Typ angegeben ceph, sowie die UUID des Geheimnisses zur Verbindung. Seine UUID kann mit dem Befehl ermittelt werden virsh secret-list.
Im Block host Es werden die Adressen zu den Ceph-Monitoren angegeben.

Nach der Bearbeitung der Konfigurationsdatei und dem Abschluss der Konvertierung von LVM zu RBD kann die geänderte Konfigurationsdatei angewendet und die virtuelle Maschine gestartet werden:

virsh define $vm_name.xml
virsh start $vm_name

Jetzt ist es an der Zeit zu überprüfen, ob die virtuelle Maschine korrekt gestartet wurde: das kann beispielsweise durch eine SSH-Verbindung oder über virsh.

Wenn die virtuelle Maschine korrekt funktioniert und Sie keine weiteren Probleme festgestellt haben, können Sie das nicht mehr verwendete LVM-Image löschen:

lvremove main/$vm_image_name

Fazit

All diese beschriebenen Fälle haben wir in der Praxis erlebt – wir hoffen, dass die Anleitungen auch anderen Administratoren helfen, ähnliche Probleme zu lösen. Wenn Sie Anmerkungen oder andere ähnliche Geschichten aus Ihrer Erfahrung mit Ceph haben – wir freuen uns, diese in den Kommentaren zu sehen!