Wenn wir Ceph als Netzwerkspeicher in Projekten mit unterschiedlicher Auslastung verwenden, können wir auf verschiedene Aufgaben stoßen, die auf den ersten Blick nicht einfach oder trivial erscheinen. Zum Beispiel:
- Migration von Daten vom alten Ceph zum neuen mit teilweiser Nutzung bisheriger Server im neuen Cluster;
- Lösung für das Problem der Speicherplatzzuweisung in Ceph.
Bei der Bewältigung solcher Probleme stehen wir vor der Notwendigkeit, das OSD korrekt zu entfernen, ohne Daten zu verlieren, was besonders beim Umgang mit großen Datenmengen wichtig ist. Dies wird im Artikel besprochen.
Die unten beschriebenen Methoden sind für jede Ceph-Version relevant. Darüber hinaus wird der Tatsache Rechnung getragen, dass Ceph große Datenmengen speichern kann: Um Datenverlust und andere Probleme zu verhindern, werden einige Aktionen in mehrere andere „aufgeteilt“.
Vorwort zum OSD
Da zwei der drei besprochenen Rezepte dem OSD gewidmet sind (), bevor wir uns mit dem praktischen Teil befassen – kurz darüber, was es in Ceph ist und warum es so wichtig ist.
Zunächst einmal ist zu sagen, dass der gesamte Ceph-Cluster aus vielen OSDs besteht. Je mehr es sind, desto größer ist das kostenlose Datenvolumen in Ceph. Von hier aus ist es leicht zu verstehen Haupt-OSD-Funktion: Es speichert Ceph-Objektdaten in den Dateisystemen aller Clusterknoten und bietet Netzwerkzugriff darauf (zum Lesen, Schreiben und für andere Anfragen).
Auf derselben Ebene werden Replikationsparameter durch das Kopieren von Objekten zwischen verschiedenen OSDs festgelegt. Und hier können Sie auf verschiedene Probleme stoßen, deren Lösungen im Folgenden besprochen werden.
Fall Nr. 1. Entfernen Sie OSD sicher aus dem Ceph-Cluster, ohne Daten zu verlieren
Die Notwendigkeit, das OSD zu entfernen, kann dadurch verursacht werden, dass der Server aus dem Cluster entfernt wird – beispielsweise um ihn durch einen anderen Server zu ersetzen – was uns passiert ist und Anlass zum Schreiben dieses Artikels gegeben hat. Das ultimative Ziel der Manipulation besteht also darin, alle OSDs und Mons auf einem bestimmten Server zu extrahieren, damit dieser gestoppt werden kann.
Der Einfachheit halber und um zu vermeiden, dass wir bei der Ausführung von Befehlen einen Fehler bei der Angabe des erforderlichen OSD machen, legen wir eine separate Variable fest, deren Wert die Nummer des zu löschenden OSD ist. Rufen wir sie an ${ID} — hier und im Folgenden ersetzt eine solche Variable die Nummer des OSD, mit dem wir arbeiten.
Schauen wir uns den Zustand vor Arbeitsbeginn 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-Entfernung einzuleiten, müssen Sie eine reibungslose Durchführung durchführen reweight darauf auf Null. Auf diese Weise reduzieren wir die Datenmenge im OSD, indem wir sie auf andere OSDs verteilen. Führen Sie dazu die folgenden Befehle aus:
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.
Reibungsloses Auswuchten erforderlichum keine Daten zu verlieren. Dies gilt insbesondere dann, wenn das OSD eine große Datenmenge enthält. Um sicherzustellen, dass nach der Ausführung der Befehle reweight Alles hat gut geklappt, Sie können es fertigstellen ceph -s oder in einem separaten Terminalfenster ausführen ceph -w um Veränderungen in Echtzeit beobachten zu können.
Wenn das OSD „geleert“ ist, können Sie mit dem Standardvorgang zum Entfernen fortfahren. Übertragen Sie dazu das gewünschte OSD in den Zustand down:
ceph osd down osd.${ID}Lassen Sie uns das OSD aus dem Cluster „ziehen“:
ceph osd out osd.${ID}Stoppen wir den OSD-Dienst und unmounten seine Partition im FS:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Entfernen Sie das OSD von :
ceph osd crush remove osd.${ID}Löschen wir den OSD-Benutzer:
ceph auth del osd.${ID}Und schließlich entfernen wir das OSD selbst:
ceph osd rm osd.${ID}Beachten: Wenn Sie die Ceph Luminous-Version oder höher verwenden, können die oben genannten Schritte zum Entfernen des OSD auf zwei Befehle reduziert werden:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Wenn Sie nach Abschluss der oben beschriebenen Schritte den Befehl ausführen ceph osd tree, dann sollte klar sein, dass auf dem Server, auf dem die Arbeit ausgeführt wurde, keine OSDs mehr vorhanden sind, für die die oben genannten Vorgänge 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
Beachten Sie dabei, dass der Status des Ceph-Clusters zu wechselt HEALTH_WARNAußerdem werden wir eine Verringerung der Anzahl der OSDs und des verfügbaren Speicherplatzes feststellen.
Im Folgenden werden die Schritte beschrieben, die erforderlich sind, wenn Sie den Server vollständig stoppen und entsprechend aus Ceph entfernen möchten. In diesem Fall ist es wichtig, sich daran zu erinnern Bevor Sie den Server herunterfahren, müssen Sie alle OSDs entfernen auf diesem Server.
Wenn auf diesem Server keine weiteren OSDs mehr vorhanden sind, müssen Sie den Server nach dem Entfernen aus der OSD-Karte ausschließen hv-2indem Sie den folgenden Befehl ausführen:
ceph osd crush rm hv-2
Entfernen mon vom Server hv-2indem Sie den folgenden Befehl auf einem anderen Server ausführen (d. h. in diesem Fall auf hv-1):
ceph-deploy mon destroy hv-2Danach können Sie den Server stoppen und mit weiteren Aktionen beginnen (erneute Bereitstellung usw.).
Fall Nr. 2. Verteilung des Speicherplatzes in einem bereits erstellten Ceph-Cluster
Ich beginne die zweite Geschichte mit einem Vorwort über PG (). Die Hauptaufgabe von PG in Ceph besteht hauptsächlich darin, Ceph-Objekte zu aggregieren und sie weiter im OSD zu replizieren. Die Formel, mit der Sie die benötigte Menge an PG berechnen können, finden Sie in Ceph-Dokumentation. Auch dieses Thema wird dort anhand konkreter Beispiele diskutiert.
Also: Eines der häufigsten Probleme bei der Verwendung von Ceph ist die unausgeglichene Anzahl von OSD und PG zwischen Pools in Ceph.
Aus diesem Grund kann es erstens zu einer Situation kommen, in der zu viele PGs in einem kleinen Pool angegeben sind, was im Wesentlichen eine irrationale Nutzung des Speicherplatzes im Cluster darstellt. Zweitens gibt es in der Praxis ein schwerwiegenderes Problem: den Datenüberlauf in einem der OSDs. Dies bedeutet, dass der Cluster zunächst in den Zustand übergeht HEALTH_WARNund dann HEALTH_ERR. Der Grund dafür ist, dass Ceph bei der Berechnung der verfügbaren Datenmenge (Sie können es herausfinden durch MAX AVAIL in der Befehlsausgabe ceph df für jeden Pool separat) basiert auf der Menge der verfügbaren Daten im OSD. Wenn in mindestens einem OSD nicht genügend Platz vorhanden ist, können keine weiteren Daten geschrieben werden, bis die Daten ordnungsgemäß auf alle OSDs verteilt sind.
Es lohnt sich, diese Probleme klarzustellen werden größtenteils in der Ceph-Cluster-Konfigurationsphase entschieden. Eines der Tools, die Sie verwenden können, ist . Mit seiner Hilfe lässt sich die benötigte PG-Menge übersichtlich berechnen. Sie können jedoch auch darauf zurückgreifen, wenn der Ceph-Cluster vorhanden ist bereits falsch konfiguriert. Es lohnt sich hier klarzustellen, dass Sie im Rahmen der Korrekturarbeiten höchstwahrscheinlich die Anzahl der PGs reduzieren müssen und diese Funktion in älteren Versionen von Ceph nicht verfügbar ist (sie erschien nur in Version ).
Stellen wir uns also das folgende Bild vor: Der Cluster hat einen Status HEALTH_WARN weil auf einem der OSDs nicht mehr genügend Platz vorhanden ist. Dies wird durch einen Fehler angezeigt HEALTH_WARN: 1 near full osd. Nachfolgend finden Sie einen Algorithmus, um aus dieser Situation herauszukommen.
Zunächst müssen Sie die verfügbaren Daten auf die verbleibenden OSDs verteilen. Eine ähnliche Operation haben wir bereits im ersten Fall durchgeführt, als wir den Knoten „entleert“ haben – mit dem einzigen Unterschied, dass wir jetzt etwas reduzieren müssen reweight. Zum Beispiel bis zu 0.95:
ceph osd reweight osd.${ID} 0.95Dadurch wird Speicherplatz im OSD freigegeben und der Fehler im Ceph-Zustand behoben. Wie bereits erwähnt, tritt dieses Problem jedoch hauptsächlich aufgrund einer falschen Konfiguration von Ceph in der Anfangsphase auf: Es ist sehr wichtig, eine Neukonfiguration vorzunehmen, damit es in Zukunft nicht mehr auftritt.
In unserem speziellen Fall kam es auf Folgendes an:
- Wert zu hoch
replication_countin einem der Pools, - zu viel PG in einem Pool und zu wenig in einem anderen.
Nutzen wir den bereits erwähnten Rechner. Es zeigt deutlich, was eingegeben werden muss und im Prinzip gibt es nichts Kompliziertes. Nachdem wir die notwendigen Parameter eingestellt haben, erhalten wir folgende Empfehlungen:
Beachten: Wenn Sie einen Ceph-Cluster von Grund auf einrichten, ist eine weitere nützliche Funktion des Rechners die Generierung von Befehlen, die Pools mit den in der Tabelle angegebenen Parametern von Grund auf erstellen.
Die letzte Spalte hilft Ihnen beim Navigieren - Empfohlene PG-Anzahl. In unserem Fall ist auch die zweite Option nützlich, bei der der Replikationsparameter angegeben wird, da wir uns entschieden haben, den Replikationsmultiplikator zu ändern.
Zuerst müssen Sie also die Replikationsparameter ändern – dies lohnt sich zunächst, da wir durch die Reduzierung des Multiplikators Speicherplatz freigeben. Während der Befehl ausgeführt wird, werden Sie feststellen, dass der verfügbare Speicherplatz zunimmt:
ceph osd pool $pool_name set $replication_size
Und nach seiner Fertigstellung ändern wir die Parameterwerte pg_num и pgp_num следующим обрахом:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberEs ist wichtig,: Wir müssen die Anzahl der PGs nacheinander in jedem Pool ändern und dürfen die Werte in anderen Pools nicht ändern, bis die Warnungen verschwinden „Verminderte Datenredundanz“ и „n-Anzahl der abgebauten Seiten“.
Sie können auch anhand der Befehlsausgaben überprüfen, ob alles gut gelaufen ist ceph health detail и ceph -s.
Fall Nr. 3. Migration einer virtuellen Maschine von LVM zu Ceph RBD
In einer Situation, in der ein Projekt virtuelle Maschinen verwendet, die auf gemieteten Bare-Metal-Servern installiert sind, stellt sich häufig das Problem der fehlertoleranten Speicherung. Es ist auch sehr wünschenswert, dass in diesem Speicher genügend Speicherplatz vorhanden ist... Eine weitere häufige Situation: Auf dem Server befindet sich eine virtuelle Maschine mit lokalem Speicher und Sie müssen die Festplatte erweitern, aber Sie können nirgendwo hingehen, da keine vorhanden ist Freier Speicherplatz auf dem Server.
Das Problem kann auf unterschiedliche Weise gelöst werden – zum Beispiel durch Migration auf einen anderen Server (falls vorhanden) oder das Hinzufügen neuer Festplatten zum Server. Da dies jedoch nicht immer möglich ist, kann die Migration von LVM zu Ceph eine hervorragende Lösung für dieses Problem sein. Durch die Wahl dieser Option vereinfachen wir auch den weiteren Migrationsprozess zwischen Servern, da kein lokaler Speicher von einem Hypervisor auf einen anderen verschoben werden muss. Der einzige Haken ist, dass Sie die VM stoppen müssen, während die Arbeit ausgeführt wird.
Das folgende Rezept stammt aus , dessen Anleitungen in der Praxis getestet wurden. Übrigens, Dort wird auch die Methode der problemlosen Migration beschriebenIn unserem Fall wurde es jedoch einfach nicht benötigt, sodass wir es nicht überprüft haben. Wenn dies für Ihr Projekt von entscheidender Bedeutung ist, freuen wir uns über die Ergebnisse in den Kommentaren.
Kommen wir zum praktischen Teil. Im Beispiel verwenden wir virsh und entsprechend libvirt. Stellen Sie zunächst sicher, dass der Ceph-Pool, in den die Daten migriert werden, mit libvirt verbunden ist:
virsh pool-dumpxml $ceph_poolDie Poolbeschreibung muss Verbindungsdaten zu Ceph mit Autorisierungsdaten 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 Bildes ab:
qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_nameNach der Konvertierung verbleibt ein LVM-Image, was nützlich ist, wenn die Migration der VM zu RBD fehlschlägt und Sie die Änderungen rückgängig machen müssen. Um Änderungen schnell rückgängig machen zu können, erstellen wir außerdem eine Sicherungskopie der Konfigurationsdatei der virtuellen Maschine:
virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml
... und bearbeiten Sie das Original (vm_name.xml). Suchen wir einen Block mit einer Beschreibung der Festplatte (beginnt mit der Zeile <disk type='file' device='disk'> und endet mit </disk>) und reduzieren Sie es auf die folgende Form:
<disk type='network' device='disk'>
<driver name='qemu'/>
<auth username='libvirt'>
<secret type='ceph' uuid='sec-ret-uu-id'/>
</auth>
<source protocol='rbd' name='$ceph_pool/$vm_image_name>
<host name='10.0.0.1' port='6789'/>
<host name='10.0.0.2' port='6789'/>
</source>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>Schauen wir uns einige Details an:
- Zum Protokoll
sourceDie Adresse zum Speicher in Ceph RBD wird angegeben (dies ist die Adresse, die den Namen des Ceph-Pools und des RBD-Images angibt, die in der ersten Phase festgelegt wurde). - Im Block
secretTyp angegeben istceph, sowie die UUID des Geheimnisses, um eine Verbindung herzustellen. Seine UUID kann mit dem Befehl gefunden werdenvirsh secret-list. - Im Block
hostAdressen zu Ceph-Monitoren werden angezeigt.
Nachdem Sie die Konfigurationsdatei bearbeitet und die LVM-zu-RBD-Konvertierung abgeschlossen haben, können Sie die geänderte Konfigurationsdatei anwenden und die virtuelle Maschine starten:
virsh define $vm_name.xml
virsh start $vm_name
Es ist an der Zeit zu überprüfen, ob die virtuelle Maschine korrekt gestartet ist: Sie können dies beispielsweise herausfinden, indem Sie eine Verbindung zu ihr über SSH oder über herstellen virsh.
Wenn die virtuelle Maschine ordnungsgemäß funktioniert und Sie keine anderen Probleme festgestellt haben, können Sie das nicht mehr verwendete LVM-Image löschen:
lvremove main/$vm_image_nameAbschluss
Alle beschriebenen Fälle sind uns in der Praxis begegnet – wir hoffen, dass die Anleitung anderen Administratoren bei der Lösung ähnlicher Probleme hilft. Wenn Sie Kommentare oder ähnliche Geschichten zu Ihren Erfahrungen mit Ceph haben, würden wir uns freuen, diese in den Kommentaren zu sehen!
PS
Lesen Sie auch auf unserem Blog:
- «";
- «";
- «";
- «".
Source: habr.com