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

Die Verwendung von Ceph als Netzwerkspeicher in Projekten mit unterschiedlicher Auslastung kann uns vor verschiedene Herausforderungen stellen, die auf den ersten Blick nicht einfach oder trivial erscheinen. Zum Beispiel:

Migration von Daten aus dem alten Ceph in ein neues mit teilweisem Einsatz der vorherigen Server im neuen Cluster;
Lösung des Problems der Verteilung des Speicherplatzes in Ceph.

Wenn wir uns solchen Aufgaben stellen, sehen wir uns der Notwendigkeit gegenüber, OSD korrekt zu entfernen, ohne Daten zu verlieren, was besonders bei großen Datenmengen von Bedeutung ist. Genau darum wird es in diesem Artikel gehen.

Die im Folgenden beschriebenen Methoden sind für alle Ceph-Versionen relevant. Darüber hinaus werden wir berücksichtigen, dass in Ceph eine große Datenmenge gespeichert werden kann: Um Datenverluste und andere Probleme zu vermeiden, werden einige Aktionen in mehrere unterteilt.

Einführung in OSD

Da zwei der drei betrachteten Rezepte OSD gewidmet sind (Object Storage Daemon), werden wir, bevor wir in den praktischen Teil eintauchen, kurz darauf eingehen, was das überhaupt in Ceph ist und warum es so wichtig ist.

Zunächst sei gesagt, dass der gesamte Ceph-Cluster aus vielen OSD besteht. Je mehr es gibt, desto mehr freier Speicherplatz ist in Ceph verfügbar. Daraus lässt sich leicht ableiten, die Hauptfunktion von OSD: es speichert die Datenobjekte von Ceph auf den Dateisystemen aller Clusterknoten und stellt Netzwerkzugang zu ihnen bereit (zum Lesen, Schreiben und für andere Anfragen).

Auf derselben Ebene werden die Replikationsparameter festgelegt, indem Objekte zwischen verschiedenen OSD kopiert werden. Hier können auch verschiedene Probleme auftreten, deren Lösungen im Folgenden beschrieben werden.

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

Die Notwendigkeit, OSD zu entfernen, kann durch die Deaktivierung eines Servers im Cluster entstehen – zum Beispiel, um ihn durch einen anderen Server zu ersetzen –, was bei uns der Grund für das Schreiben dieses Artikels war. Daher ist das Endziel der Manipulationen, alle OSD und Monitore auf diesem Server zu entfernen, damit dieser abgeschaltet werden kann.

Zur Erleichterung und um eine Situation zu vermeiden, in der wir bei der Ausführung der Befehle einen Fehler bei der Angabe des gewünschten OSD machen, definieren wir eine separate Variable, deren Wert die Nummer des zu entfernenden OSD sein wird. Nennen wir sie ${ID} — hier und im Folgenden ersetzt eine solche Variable die Nummer des OSD, mit dem wir arbeiten.

Werfen wir einen Blick auf den Zustand vor Beginn der Arbeiten:

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 Löschung des OSD einzuleiten, ist es erforderlich, dies schrittweise durchzuführen. Neuweitung bis auf null. Dadurch reduzieren wir die Menge an Daten im OSD, indem wir sie auf andere OSDs balancieren. Dazu sind folgende Befehle erforderlich:

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 schrittweise Balancierung ist notwendig, um Datenverluste zu vermeiden. Dies ist besonders wichtig, wenn sich im OSD eine große Menge an Daten befindet. Um sicherzustellen, dass nach der Ausführung der Befehle Neuweitung alles erfolgreich war, kann man ceph -s oder in einem separaten Terminalfenster ceph -w ausführen, um die Änderungen in Echtzeit zu verfolgen.

Sobald das OSD "entleert" ist, kann mit dem Standardverfahren zur Löschung fortgefahren werden. Dazu versetzen wir das entsprechende OSD in den Zustand down:

ceph osd down osd.${ID}

„Holen“ wir das OSD aus dem Cluster:

ceph osd out osd.${ID}

Wir stoppen den OSD-Dienst und demontieren seine Partition im FS:

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

Wir entfernen das OSD aus CRUSH-Karte:

ceph osd crush remove osd.${ID}

Wir löschen den OSD-Benutzer:

ceph auth del osd.${ID}

Und schließlich löschen wir das OSD selbst:

ceph osd rm osd.${ID}

Hinweis: wenn Sie eine Ceph Luminous-Version oder höher verwenden, können die oben beschriebenen Schritte zur Löschung des OSD auf zwei Befehle reduziert werden:

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

Wenn nach der Ausführung der oben genannten Befehle der Befehl ceph osd tree, ausgeführt wird, sollte sichtbar sein, dass auf dem Server, auf dem die Arbeiten durchgeführt wurden, keine OSD mehr vorhanden ist, für die die oben genannten Operationen durchgefü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

Es sei darauf hingewiesen, dass der Zustand des Ceph-Clusters in HEALTH_WARN, übergeht und wir auch eine Verringerung der Anzahl der OSD und des verfügbaren Speicherplatzes sehen werden.

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

Wenn auf diesem Server keine OSDs mehr vorhanden sind, müssen nach deren Löschung der OSD-Server hv-2, aus der OSD-Karte entfernt werden, indem der folgende Befehl ausgeführt wird:

ceph osd crush rm hv-2

Löschen mon vom Server hv-2, indem Sie den folgenden Befehl auf einem anderen Server ausführen (d.h. in diesem Fall auf der hv-1):

ceph-deploy mon destroy hv-2

Danach kann der Server gestoppt werden und es können die nächsten Schritte (wie das erneute Bereitstellen usw.) durchgeführt werden.

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

Die zweite Geschichte beginne ich mit einer Einführung über PG (Placement Groups). Die Hauptfunktion von PG in Ceph besteht hauptsächlich darin, Ceph-Objekte zu aggregieren und anschließend in OSD zu replizieren. Die Formel, mit der die erforderliche Anzahl von PG berechnet werden kann, finden Sie in der entsprechenden Abschnitt Ceph-Dokumentation. Dort wird auch dieses Thema anhand konkreter Beispiele behandelt.

Eine der häufigsten Probleme beim Betrieb von Ceph ist also die unausgewogene Anzahl von OSD und PG zwischen den Pools in Ceph.

Erstens kann dies zu einer Situation führen, in der eine zu große Anzahl von PG in einem kleinen Pool angegeben wird, was im Grunde genommen eine ineffiziente Nutzung des Speicherplatzes im Cluster darstellt. Zweitens ergibt sich in der Praxis ein ernsthafteres Problem: eine Datenüberlastung in einem der OSD. Dies führt dazu, dass der Cluster zuerst in einen Zustand HEALTH_WARN, und dann in einen HEALTH_ERR. Der Grund dafür ist, dass Ceph bei der Berechnung des verfügbaren Speicherplatzes (dies kann man über MAX AVAIL in der Ausgabe des Befehls ceph df für jeden Pool einzeln) auf das Volumen der verfügbaren Daten in OSD angewiesen ist. Wenn in einem OSD nicht genügend Platz vorhanden ist, können keine weiteren Daten geschrieben werden, bis die Daten ordnungsgemäß auf alle OSD verteilt sind.

Es ist anzumerken, dass diese Probleme in der Regel während der Konfiguration des Ceph-Clusters gelöst werden. Ein Werkzeug, das Sie nutzen können, ist Ceph PGCalc. Damit kann die erforderliche Anzahl von PG anschaulich berechnet werden. Dennoch sollte es auch in Situationen in Anspruch genommen werden, in denen der Ceph-Cluster bereits falsch konfiguriert ist. Hier ist zu beachten, dass Sie wahrscheinlich die Anzahl der PG reduzieren müssen, um Korrekturen vorzunehmen, und diese Möglichkeit steht in älteren Versionen von Ceph (sie ist erst seit Version Nautilus).

verfügbar) nicht zur Verfügung. HEALTH_WARN Stellen wir uns folgendes Szenario vor: der Cluster hat den Status wegen Platzmangel in einem der OSD endet. Dies wird durch die Fehlermeldung angezeigtHEALTH_WARN: 1 near full osd

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 "entwässert" haben - mit dem einzigen Unterschied, dass wir nun eine geringfügige Reduzierung vornehmen müssen. Neuweitung. Zum Beispiel bis 0.95:

ceph osd reweight osd.${ID} 0.95

Damit wird Speicherplatz im OSD freigegeben und der Fehler in ceph health behoben. Wie bereits erwähnt, tritt dieses Problem hauptsächlich aufgrund einer fehlerhaften Konfiguration von Ceph in den frühen Phasen auf: Es ist sehr wichtig, eine Rekonfiguration vorzunehmen, um zukünftige Probleme zu vermeiden.

In unserem speziellen Fall lag das Problem an:

einem zu hohen Wert von replication_count in einem der Pools,
einer zu hohen Anzahl von PGs in einem Pool und zu wenigen in einem anderen.

Wir nutzen den bereits erwähnten Rechner. Dort wird anschaulich gezeigt, was eingegeben werden muss, und im Grunde gibt es nichts Schwieriges. Nachdem wir die erforderlichen Parameter eingegeben haben, erhalten wir die folgenden Empfehlungen:

Hinweis: Wenn Sie einen 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 von Grund auf neu erstellen.

Zur Orientierung hilft die letzte Spalte - Suggested PG Count. In unserem Fall ist auch die zweite Spalte nützlich, in der der Replikationsparameter angegeben ist, da wir beschlossen haben, den Replikationsfaktor zu ändern.

Zunächst müssen wir die Replikationsparameter ändern - das sollte an erster Stelle erfolgen, denn durch die Verringerung des Faktors werden wir Speicherplatz freigeben. Während der Ausführung des Befehls können wir beobachten, dass der verfügbare Speicherplatz zunimmt:

ceph osd pool $pool_name set $replication_size

Und nach Abschluss ändern wir die Werte der Parameter pg_num und pgp_num folgendermaßen ausführen:

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 der Reihe nach die Anzahl der PGs ändern und die Werte in anderen Pools nicht ändern, bis die Warnungen verschwunden sind "Degraded data redundancy" und "n-number of pgs degraded".

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

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

In Situationen, in denen virtuelle Maschinen auf gemieteten Bare-Metal-Servern verwendet werden, stellt sich oft die Frage nach fehlertoleranten Speichermöglichkeiten. Zudem ist es wünschenswert, dass genügend Platz in diesem Speicher vorhanden ist... Eine andere verbreitete Situation: Es gibt eine virtuelle Maschine mit lokalem Speicher auf dem Server, und der Speicherplatz muss erweitert werden, aber es gibt keinen verfügbaren Platz, da auf dem Server kein freier Speicher mehr vorhanden ist.

Das Problem kann auf verschiedene Weise gelöst werden – beispielsweise durch Migration auf einen anderen Server (sofern vorhanden) oder durch Hinzufügen neuer Festplatten zu dem Server. Aber nicht immer lässt sich dies umsetzen, weshalb die Migration von LVM zu Ceph eine ausgezeichnete Lösung für dieses Problem sein kann. Wenn wir diese Option wählen, erleichtern wir auch den weiteren Migrationsprozess zwischen den Servern, da das lokale Speicher aus einem Hypervisor nicht auf einen anderen verschoben werden muss. Der einzige Haken – die VM muss für die Dauer der Arbeiten angehalten werden.

Als nächstes Rezept wird ein Artikel aus diesem Blog, dessen Anleitungen in der Praxis erprobt wurden. Übrigens, wird dort auch ein Verfahren zur unkomplizierten Migration beschrieben,das jedoch in unserem Fall einfach nicht benötigt wurde, weshalb wir es nicht überprüft haben. Sollte dies jedoch entscheidend für Ihr Projekt sein – freuen wir uns über Rückmeldungen in den Kommentaren.

Lassen Sie uns mit dem praktischen Teil beginnen. In diesem Beispiel verwenden wir virsh und соответственно libvirt. Stellen Sie zunächst sicher, dass der Ceph-Pool, in den die Daten migriert werden, mit libvirt verbunden ist:

virsh pool-dumpxml $ceph_pool

In der Beschreibung des Pools sollten die Verbindungsdaten zu Ceph mit den Anmeldedaten enthalten sein.

Der nächste Schritt besteht darin, dass das LVM-Image in Ceph RBD konvertiert wird. Die Dauer 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 erhalten, das nützlich sein wird, falls die Migration der VM in RBD nicht möglich ist und Änderungen zurückgesetzt werden müssen. Zudem – um Änderungen schnell zurückzusetzen – erstellen wir ein Backup 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). Wir suchen den Block mit der Beschreibung der Festplatte (beginnt mit der Zeile <disk type='file' device='disk'> und endet mit </disk>) und bringen ihn in folgende Form:

Betrachten wir einige Details:

Im Protokoll source wird die Adresse des Speichers in Ceph RBD angegeben (dies ist die Adresse mit dem Namen des Ceph-Pools und des RBD-Images, das in der ersten Phase festgelegt wurde).
Im Block secret Der Typ ceph, sowie die UUID des Secrets zur Verbindung werden angegeben. Ihre UUID kann mit dem Befehl virsh secret-list.
Im Block host die Adressen der Ceph-Monitore angegeben.

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

virsh define $vm_name.xml
virsh start $vm_name

Es ist an der Zeit zu überprüfen, ob die virtuelle Maschine korrekt gestartet wurde: dies kann man beispielsweise herausfinden, indem man sich über SSH oder über virsh.

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

lvremove main/$vm_image_name

Fazit

Alle 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 Erfahrungen mit der Nutzung von Ceph haben, würden wir uns freuen, diese in den Kommentaren zu sehen!