Wir haben
bereits darüber gesprochen, wie / warum wir Rook mögen: Es vereinfacht in erheblichem Maße die Arbeit mit Speichern in Kubernetes-Clustern. Mit dieser Einfachheit sind jedoch gewisse Schwierigkeiten verbunden. Wir hoffen, dass das neue Material hilft, solche Schwierigkeiten besser zu verstehen, noch bevor sie sich manifestieren.
Und um es interessanter zu lesen, beginnen wir mit den
Konsequenzen eines hypothetischen Problems im Cluster.
"Alles ist weg!"
Stellen Sie sich vor, Sie haben Rook einmal in Ihrem K8-Cluster konfiguriert und gestartet. Er war mit seiner Arbeit zufrieden, aber in einem „wunderbaren“ Moment passiert Folgendes:
- Neue Pods können keine Ceph-RBDs mounten.
- Befehle wie
lsblk und df funktionieren nicht auf Kubernetes-Hosts. Dies bedeutet automatisch, dass mit den knotenmontierten RBD-Images etwas nicht stimmt. Ich kann sie nicht lesen, was auf die Unzugänglichkeit von Monitoren hinweist ... - Ja, der Cluster enthält keine Betriebsmonitore. Darüber hinaus gibt es weder Pods mit OSD noch Pods mit MGR.
Wann wurde der Pod
rook-ceph-operator den
rook-ceph-operator ? Vor nicht allzu langer Zeit wurde er eingesetzt. Warum? Rook-Operator hat beschlossen, einen neuen Cluster zu erstellen ... Wie können wir nun den Cluster und die darin enthaltenen Daten wiederherstellen?
Lassen Sie uns zunächst einen
längeren, interessanten Weg beschreiten, nachdem wir die „Interna“ von Rook gründlich untersucht und seine Komponenten schrittweise restauriert haben. Natürlich gibt es einen
kürzeren richtigen Weg: das Verwenden von Backups. Wie Sie wissen, gibt es zwei Arten von Administratoren: diejenigen, die keine Backups durchführen, und diejenigen, die sie bereits durchführen ... Aber mehr dazu nach den Ermittlungen.
Ein bisschen Übung oder ein langer Weg
Schauen Sie sich die Monitore an und stellen Sie sie wieder her
Schauen wir uns also die Liste der ConfigMaps an: Für die Sicherung sind
rook-ceph-config und
rook-config-override erforderlich. Sie werden nach erfolgreicher Bereitstellung des Clusters angezeigt.
Hinweis : In neuen Versionen sind ConfigMaps nach der Einführung dieses PR kein Indikator für den Erfolg einer Clusterbereitstellung mehr.Um weitere Aktionen ausführen zu können, müssen alle Server, auf denen gemountete RBD-Images vorhanden sind, neu
ls /dev/rbd* werden (
ls /dev/rbd* ). Dies muss über sysrq (oder "zu Fuß" zum Rechenzentrum) erfolgen. Diese Anforderung wird durch die Aufgabe verursacht, gemountete RBDs zu trennen, für die ein regulärer Neustart nicht funktioniert (es wird erfolglos versucht, sie normal zu mounten).
Das Theater beginnt mit einem Kleiderbügel und der Ceph-Cluster beginnt mit Monitoren. Schauen wir sie uns an.
Rook stellt die folgenden Entitäten im Monitor-Pod bereit:
Volumes: rook-ceph-config: Type: ConfigMap (a volume populated by a ConfigMap) Name: rook-ceph-config rook-ceph-mons-keyring: Type: Secret (a volume populated by a Secret) SecretName: rook-ceph-mons-keyring rook-ceph-log: Type: HostPath (bare host directory volume) Path: /var/lib/rook/kube-rook/log ceph-daemon-data: Type: HostPath (bare host directory volume) Path: /var/lib/rook/mon-a/data Mounts: /etc/ceph from rook-ceph-config (ro) /etc/ceph/keyring-store/ from rook-ceph-mons-keyring (ro) /var/lib/ceph/mon/ceph-a from ceph-daemon-data (rw) /var/log/ceph from rook-ceph-log (rw)
Mal sehen, was das Geheimnis von
rook-ceph-mons-keyring :
kind: Secret data: keyring: LongBase64EncodedString=
Wir entschlüsseln und erhalten den üblichen Schlüsselring mit Rechten für den Administrator und die Monitore:
[mon.] key = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA== caps mon = "allow *" [client.admin] key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp== caps mds = "allow *" caps mon = "allow *" caps osd = "allow *" caps mgr = "allow *"
Erinnere dich. Schauen Sie sich nun den Schlüsselring im geheimen
rook-ceph-admin-keyring :
kind: Secret data: keyring: anotherBase64EncodedString=
Was ist drin?
[client.admin] key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp== caps mds = "allow *" caps mon = "allow *" caps osd = "allow *" caps mgr = "allow *"
Derselbe. Mal sehen, mehr ... Hier ist zum Beispiel das Geheimnis von
rook-ceph-mgr-a-keyring :
[mgr.a] key = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew== caps mon = "allow *" caps mds = "allow *" caps osd = "allow *"
Am Ende finden wir ein paar weitere Geheimnisse in ConfigMap rook
rook-ceph-mon :
kind: Secret data: admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp== cluster-name: a3ViZS1yb29r fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg== mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
Und dies ist die erste Liste mit Schlüsselbund, aus der alle oben beschriebenen Geheimnisse stammen.
Wie Sie wissen (siehe
dataDirHostPath in der
Dokumentation ), speichert Rook diese Daten an zwei Stellen. Gehen wir daher zu den Knoten, um den Schlüsselbund zu betrachten, der in den Verzeichnissen liegt, die in Pods mit Monitoren und OSD eingebunden sind. Suchen Sie dazu die Knoten
/var/lib/rook/mon-a/data/keyring und sehen Sie:
# cat /var/lib/rook/mon-a/data/keyring [mon.] key = AXAbS19d8NNUXOBB+XyYwXqXI1asIzGcGlzMGg== caps mon = "allow *"
Plötzlich stellte sich heraus, dass
das Geheimnis anders war - nicht wie in ConfigMap.
Was ist mit dem Admin-Schlüsselbund? Wir haben es 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 ist ein Fehler aufgetreten: Der Cluster wurde neu erstellt ... aber in Wirklichkeit nicht.
Es wird deutlich, dass der neu generierte Schlüsselring in Geheimnissen gespeichert ist und
nicht aus unserem alten Cluster stammt. Deshalb:
- wir nehmen den Schlüsselring vom Monitor aus der Datei
/var/lib/rook/mon-a/data/keyring (oder aus dem Backup); - ändere den Schlüsselring im geheimen
rook-ceph-mons-keyring . - Registrieren Sie den Schlüsselbund vom Admin und Monitor in ConfigMap'e rook
rook-ceph-mon . - Entfernen Sie Pod-Controller mit Monitoren.
Das Wunder wird nicht lange dauern: Monitore erscheinen und starten. Hurra, ein Anfang!
OSD wiederherstellen
Wir gehen in den Pod-
rook-operator : Der Aufruf von
ceph mon dump zeigt an, dass alle Monitore vorhanden sind, und
ceph -s dass sie sich in einem Quorum befinden. Wenn Sie sich jedoch den OSD-Baum (
ceph osd tree )
ceph osd tree , werden Sie etwas Seltsames darin sehen:
ceph osd tree , aber sie sind leer. Es stellt sich heraus, dass sie auch irgendwie restauriert werden müssen. Aber wie?
In der Zwischenzeit wurden in
rook-ceph-config und
rook-ceph-config rook-config-override sowie viele andere ConfigMaps mit Namen der Form
rook-ceph-osd-$nodename-config angezeigt. Schauen wir sie uns an:
kind: ConfigMap data: osd-dirs: '{"/mnt/osd1":16,"/mnt/osd2":18}'
Alles ist falsch, alles ist durcheinander!
Skalieren Sie den Operator-Pod auf Null, löschen Sie die generierten Bereitstellungs-Pods aus dem OSD und korrigieren Sie diese ConfigMaps. Aber wo bekommt man die
richtige OSD-Karte nach Knoten?
- Versuchen wir noch einmal, die
/mnt/osd[1-2] auf den Knoten zu /mnt/osd[1-2] - in der Hoffnung, dass wir dort etwas fassen können. - Es gibt 2 Unterverzeichnisse im Verzeichnis
/mnt/osd1 : osd0 und osd16 . Das letzte ist nur die ID, die in ConfigMap (16) angegeben ist? - Lassen Sie uns
osd0 Größe osd0 und osd0 dass osd0 viel größer als osd16 .
Wir schließen daraus, dass
osd0 das erforderliche OSD ist, das in ConfigMap als
/mnt/osd1 angegeben wurde (da wir verzeichnisbasiertes
osd verwenden ).
Schritt für Schritt überprüfen wir alle Knoten und bearbeiten ConfigMaps. Nach all den Anweisungen können Sie den Pod des Rook-Bedieners ausführen und dessen Protokolle lesen. Und in ihnen ist alles wunderbar:
- Ich bin ein Clusterbetreiber.
- Ich habe Laufwerke auf Knoten gefunden.
- Ich habe Monitore gefunden;
- Monitore wurden Freunde, d.h. ein Kollegium gebildet;
- Ausführen von OSD-Bereitstellungen ...
Kehren wir zum Pod des Rook-Operators zurück und überprüfen die Clusterlebensdauer ... Ja, wir haben einen kleinen Fehler bei den Schlussfolgerungen zu den OSD-Namen auf einigen Knoten gemacht! Es spielt keine Rolle: Sie haben ConfigMaps erneut korrigiert, die zusätzlichen Verzeichnisse aus den neuen OSDs gelöscht und sind in den lang ersehnten Zustand von
HEALTH_OK !
Überprüfen Sie die Bilder im Pool:
Alles ist an Ort und Stelle - der Cluster wird gespeichert!
Ich bin faul Backups zu machen, oder der schnelle Weg
Wenn für Rook Sicherungen durchgeführt wurden, wird das Wiederherstellungsverfahren viel einfacher und läuft auf Folgendes hinaus:
- Bereitstellung des Rook-Operators auf Null skalieren;
- Wir entfernen alle Bereitstellungen mit Ausnahme des Rook-Operators.
- Wir stellen alle Geheimnisse und ConfigMaps aus dem Backup wieder her.
- Stellen Sie den Inhalt der
/var/lib/rook/mon-* auf den Knoten wieder her. - Wiederherstellen (falls plötzlich verloren) CRD
CephCluster , CephFilesystem , CephBlockPool , CephNFS , CephObjectStore ; - Skalieren Sie die Bereitstellung des Rook-Operators auf 1 zurück.
Hilfreiche Ratschläge
Machen Sie Backups!
Und um Situationen zu vermeiden, in denen Sie sich davon erholen müssen:
- Skalieren Sie den Rook-Operator auf Null, damit er nicht zu viel bewirkt, bevor Sie in großem Umfang mit dem Cluster arbeiten, der aus Serverneustarts besteht.
- Fügen Sie auf Monitoren vorher nodeAffinity hinzu .
ROOK_MON_HEALTHCHECK_INTERVAL ROOK_MON_OUT_TIMEOUT der Timeouts ROOK_MON_HEALTHCHECK_INTERVAL und ROOK_MON_OUT_TIMEOUT .
Anstelle einer Schlussfolgerung
Es macht keinen Sinn zu behaupten, dass Rook als zusätzliche "Schicht" (im allgemeinen Schema der Speicherorganisation in Kubernetes) sowohl vereinfacht als auch neue Schwierigkeiten und potenzielle Probleme in der Infrastruktur hinzufügt. Die Sache bleibt „klein“: Eine ausgewogene und fundierte Wahl zwischen diesen Risiken einerseits und den Vorteilen, die die Lösung in Ihrem speziellen Fall bringt, andererseits zu treffen.
Übrigens wurde kürzlich der Abschnitt „Einen vorhandenen Rook Ceph-Cluster in einen neuen Kubernetes-Cluster übernehmen“
in die Rook-Dokumentation aufgenommen. Es wird detaillierter beschrieben, was zu tun ist, um vorhandene Daten in einen neuen Kubernetes-Cluster zu verschieben oder einen Cluster wiederherzustellen, der aus dem einen oder anderen Grund zusammengebrochen ist.
PS
Lesen Sie auch in unserem Blog: