🥇Unsere Hände sind nicht zum Herumlungern da: Wiederherstellung des Rook-Clusters in K8s

Wir hat bereits darüber berichtet, wie/warum wir Rook mögen: Es erleichtert die Arbeit mit Speichern in Kubernetes-Clustern erheblich. Allerdings bringt diese Einfachheit auch bestimmte Herausforderungen mit sich. Wir hoffen, dass das neue Material dabei hilft, diese Herausforderungen besser zu verstehen, noch bevor sie auftreten.

Um das Lesen interessanter zu gestalten, beginnen wir mit den Folgen eines hypothetischen Problems im Cluster.

„Alles ist verloren!“

Stellen Sie sich vor, Sie haben eines Tages Rook in Ihrem K8s-Cluster eingerichtet und gestartet, und es hat gut funktioniert, aber in einem „wunderbaren“ Moment geschieht Folgendes:

Neue Pods können RBD-Images aus Ceph nicht einhängen.
Befehle wie lsblk und df funktionieren nicht auf den Kubernetes-Knoten. Das bedeutet automatisch: „Etwas stimmt nicht“ mit den an die Knoten montierten RBD-Images. Sie können nicht gelesen werden, was auf die Nichtverfügbarkeit der Monitoren hinweist…
Ja, im Cluster gibt es keine aktiven Monitore. Darüber hinaus gibt es nicht einmal Pods mit OSD oder einen Pod mit MGR.

Wann wurde der Pod gestartet? rook-ceph-operator? Не так давно, как его деплоили. Почему? Rook-operator решил сделать новый кластер… Как же нам теперь восстановить работу кластера и данные в нём?

Zunächst wollen wir den längeren, interessanteren Weg einschlagen, indem wir eine gründliche Untersuchung der „Inneren Werte“ von Rook durchführen und seine Komponenten Schritt für Schritt wiederherstellen. Natürlich gibt es auch einen kürzeren, richtigen Weg: das Verwenden von Backups. Wie bekannt ist, unterteilen sich Administratoren in zwei Typen: diejenigen, die keine Backups machen, und diejenigen, die es bereits tun… Aber dazu mehr nach der Untersuchung.

Ein wenig Praxis, oder der lange Weg

Schauen wir uns um und stellen wir die Monitore wieder her

Sehen wir uns also die Liste der ConfigMaps an: Es gibt die notwendigen für die Sicherung rook-ceph-config und rook-config-override. Sie erscheinen bei erfolgreicher Bereitstellung des Clusters.

NB: In neuen Versionen, nach Annahme dieses PR, sind ConfigMaps kein Indikator mehr für die Erfolgreichheit der Cluster-Bereitstellung.

Für weitere Schritte benötigen wir einen harten Reboot aller Server, auf denen die montierten RBD-Images vorhanden sind (ls /dev/rbd*). Dieser muss über sysrq (oder „zu Fuß“ ins Rechenzentrum) durchgeführt werden. Diese Anforderung ergibt sich aus der Notwendigkeit, die montierten RBD zu trennen, wofür ein normaler Reboot nicht geeignet ist (es wird erfolglos versucht werden, sie richtig zu demontieren).

Das Theater beginnt mit einem Kleiderhaken, und der Ceph-Cluster beginnt mit Monitoren. Schauen wir uns diese an.

Rook hängt solche Entitäten im Monitor-Pod ein:

Volumes:
 rook-ceph-config:
   Typ:      ConfigMap (ein Volumen, das durch ein ConfigMap bereitgestellt wird)
   Name:      rook-ceph-config
 rook-ceph-mons-keyring:
   Typ:        Geheimnis (ein Volumen, das durch ein Geheimnis bereitgestellt wird)
   SecretName:  rook-ceph-mons-keyring
 rook-ceph-log:
   Typ:          HostPath (reines Hostverzeichnisvolumen)
   Pfad:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Typ:          HostPath (reines Hostverzeichnisvolumen)
   Pfad:          /var/lib/rook/mon-a/data
Mounts:
  /etc/ceph von rook-ceph-config (ro)
  /etc/ceph/keyring-store/ von rook-ceph-mons-keyring (ro)
  /var/lib/ceph/mon/ceph-a von ceph-daemon-data (rw)
  /var/log/ceph von rook-ceph-log (rw)

Lass uns sehen, was im Geheimnis ist rook-ceph-mons-keyring:

art: Geheimnis
daten:
 keyring: LongBase64EncodedString=

Wir dekodieren und erhalten ein normales keyring mit Rechten für Admin und Monitore:

[mon.]
       key = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
       caps mon = "allow *"
[client.admin]
       key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

Das merken wir uns. Und jetzt schauen wir uns das keyring im Geheimnis an rook-ceph-admin-keyring:

art: Geheimnis
daten:
 keyring: anotherBase64EncodedString=

Was ist darin?

[client.admin]
       key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

Der gleiche. Schauen wir weiter… Hier, zum Beispiel, das Geheimnis rook-ceph-mgr-a-keyring:

[mgr.a]
       key = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew==
       caps mon = "allow *"
       caps mds = "allow *"
       caps osd = "allow *"

Am Ende finden wir noch einige Geheimnisse im ConfigMap rook-ceph-mon:

art: Geheimnis
daten:
 admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
 cluster-name: a3ViZS1yb29r
 fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg==
 mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==

Und dies ist die ursprüngliche Liste der keyrings, aus der alle oben genannten Geheimnisse stammen.

Wie bekannt ist (siehe dataDirHostPath in Dokumentation), speichert Rook solche Daten an zwei Stellen. Daher wollen wir zu den Knoten gehen, um die keyrings zu sehen, die in den Verzeichnissen liegen, die in Pods mit Monitoren und OSDs gemountet sind. Dazu suchen wir auf den Knoten /var/lib/rook/mon-a/data/keyring und sehen:

# cat /var/lib/rook/mon-a/data/keyring
[mon.]
       key = AXAbS19d8NNUXOBB+XyYwXqXI1asIzGcGlzMGg==
       caps mon = "allow *"

Überraschenderweise war das Geheimnis anders — nicht wie in ConfigMaps.

Und wie steht es um den Admin-keyring? Den haben wir auch:

# cat /var/lib/rook/kube-rook/client.admin.keyring
[client.admin]
       key = AXAbR19d8GGSMUBN+FyYwEqGI1aZizGcJlHMLgx= 
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

Hier liegt das Problem. Es gab einen gewissen Ausfall: der Cluster wurde neu erstellt… aber tatsächlich nicht.

Es wird klar, dass in den Geheimnissen neu generierte keyrings gespeichert sind, und sie nicht von unserem alten Cluster. Daher:

nehmen wir den keyring vom Monitor aus der Datei /var/lib/rook/mon-a/data/keyring (oder aus einem Backup);
ändern den keyring im Geheimnis rook-ceph-mons-keyring;
tragen den keyring vom Admin und Monitor in das ConfigMap ein rook-ceph-mon;
löschen die Controller der Pods mit Monitoren.

Ein Wunder wird nicht lange auf sich warten lassen: Die Monitore werden erscheinen und starten. Hurra, der Anfang ist gemacht!

Wir stellen OSD wieder her

Wir betreten den Pod rook-operator: Aufruf ceph mon dump zeigt, dass alle Monitore an ihrem Platz sind, und ceph -s — darauf, dass sie im Quorum sind. Wenn wir jedoch den Baum OSD betrachten (ceph osd tree), sehen wir etwas Seltsames: OSDs tauchen auf, aber sie sind leer. Das bedeutet, sie müssen auch irgendwie wiederhergestellt werden. Aber wie?

In der Zwischenzeit sind in den ConfigMaps die dringend benötigten rook-ceph-config und rook-config-override, sowie viele andere ConfigMaps mit Namen wie rook-ceph-osd-$nodename-config. Schauen wir sie uns an:

kind: ConfigMap
data:
 osd-dirs: '{"/mnt/osd1":16,"/mnt/osd2":18}'

Es ist alles durcheinander!

Wir skalieren das Pod des Operators auf Null, entfernen die generierten Deployments der Pods mit OSD und korrigieren diese ConfigMaps. Aber woher bekommen wir die richtige OSD-Karte nach Knoten?

Lass uns wieder in den Verzeichnissen /mnt/osd[1-2] auf den Knoten nachsehen — in der Hoffnung, dass wir dort etwas finden.
Im Verzeichnis /mnt/osd1 gibt es 2 Unterverzeichnisse: osd0 und osd16. Der letzte ist genau die ID, die in der ConfigMap angegeben ist (16)?
Lass uns die Größen überprüfen und sehen, dass osd0 deutlich größer osd16.

ist. Wir kommen zu dem Schluss, dass osd0 das der gesuchte OSD ist, der als /mnt/osd1 in der ConfigMap angegeben wurde (schließlich verwenden wir directory based osd.)

Schritt für Schritt überprüfen wir alle Knoten und korrigieren die ConfigMaps. Nach all den Anpassungen können wir das Pod des Rook-Operators starten und seine Protokolle lesen. Und darin ist alles großartig:

Ich bin der Cluster-Operator;
Ich habe die Festplatten auf den Knoten gefunden;
Ich habe die Monitore gefunden;
die Monitore haben sich verbunden, d.h. ein Quorum gebildet;
ich starte die OSD-Deployments…

Lass uns wieder ins Pod des Rook-Operators gehen und die Lebendigkeit des Clusters überprüfen… ja, wir lagen mit den Namen der OSD auf einigen Knoten etwas daneben! Macht nichts: wir haben die ConfigMaps erneut korrigiert, überflüssige Verzeichnisse neuer OSD entfernt und sind zu dem lang erwarteten Zustand gekommen. HEALTH_OK!

Lass uns die Images im Pool überprüfen:

# rbd ls -p kube
pvc-9cfa2a98-b878-437e-8d57-acb26c7118fb
pvc-9fcc4308-0343-434c-a65f-9fd181ab103e
pvc-a6466fea-bded-4ac7-8935-7c347cff0d43
pvc-b284d098-f0fc-420c-8ef1-7d60e330af67
pvc-b6d02124-143d-4ce3-810f-3326cfa180ae
pvc-c0800871-0749-40ab-8545-b900b83eeee9
pvc-c274dbe9-1566-4a33-bada-aabeb4c76c32
…

Alles ist an Ort und Stelle — der Cluster ist gerettet!

Ich mache faul Backups, oder der schnelle Weg

Wenn Backups für Rook gemacht wurden, wird die Wiederherstellungsprozedur erheblich einfacher und reduziert sich auf Folgendes:

Wir skalieren das Deployment des Rook-Operators auf Null;
Wir entfernen alle Deployments außer dem des Rook-Operators;
Wir stellen alle Secrets und ConfigMaps aus dem Backup wieder her;
Wir stellen den Inhalt der Verzeichnisse /var/lib/rook/mon-* auf den Knoten wieder her;
Wir stellen (falls verloren) CRD CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
Wieder auf die ursprüngliche Größe des Deployments des Rook-Operators in 1.

Nützliche Tipps

Macht Backups!

Und um Situationen zu vermeiden, in denen eine Wiederherstellung notwendig ist:

Vor umfangreichen Arbeiten am Cluster, die Serverneustarts umfassen, skaliert den Rook-Operator auf Null, damit er nichts überflüssiges tut.
Fügt den Monitoren im Voraus nodeAffinity hinzu..
Achten Sie auf die Vorabkonfiguration der Zeitüberschreitungen ROOK_MON_HEALTHCHECK_INTERVAL und ROOK_MON_OUT_TIMEOUT.

Zum Abschluss

Es hat keinen Sinn zu bestreiten, dass Rook, als zusätzliche "Schicht" (in der allgemeinen Struktur der Speicherung in Kubernetes), sowohl vieles vereinfacht als auch neue Schwierigkeiten und potenzielle Probleme in der Infrastruktur hinzufügt. Die Entscheidung bleibt bei den "Kleinen": eine ausgewogene, fundierte Wahl zwischen diesen Risiken auf der einen Seite und dem Nutzen, den die Lösung in Ihrem speziellen Fall bringt, auf der anderen.

Übrigens wurde kürzlich die Dokumentation von Rook um einen Abschnitt „Übernehmen eines bestehenden Rook Ceph-Clusters in einen neuen Kubernetes-Cluster“ erweitert. Dort wird detaillierter beschrieben, wie man mit vorhandenen Daten in einen neuen Kubernetes-Cluster umzieht oder wie man den Betrieb eines ausgefallenen Clusters aus verschiedenen Gründen wiederherstellt.