Zum Inhalt

Administration

Ziel

In diesem Lab übst du zwei alltägliche Administrationsaufgaben, die in jedem produktiven Rook-Ceph-Cluster regelmäßig anfallen: den kontrollierten Austausch eines defekten Datenträgers und die geplante Wartung eines Kubernetes-Nodes. Am Ende weißt du, wie du beide Vorgänge sicher durchführst und den Cluster dabei jederzeit im Blick behältst. In diesem Lab lernst du:

  • einen OSD und den zugehörigen Kubernetes-Node identifizieren
  • einen Node für eine Wartung vorbereiten, drainen und wieder einbinden
  • einen OSD kontrolliert entfernen und einen Ersatz-Datenträger einbinden
  • die Auswirkungen beider Maßnahmen auf den Clusterzustand beobachten und validieren

Hilfsmittel

  • Nutze die Rook-Toolbox für Ceph-Kommandos und kubectl für Kubernetes-Ressourcen.
  • Öffne dir wenn möglich ein zweites Terminal mit ceph -w, um den Cluster während der Übungen live zu beobachten.
  • Arbeite im Namespace rook-ceph.
  • Versuche, die Aufgaben mit Hilfe der Folien und des Cheatsheets eigenständig zu lösen.

Aufgabe 1 – Ausgangszustand aufnehmen

Bevor du etwas veränderst, verschaffst du dir einen Überblick über die aktuelle Verteilung der OSDs auf die Kubernetes-Nodes.

1.1: OSD-zu-Node-Zuordnung ermitteln

Finde heraus, welche OSD-Pods auf welchen Kubernetes-Nodes laufen.

Lösung (Klicken Sie auf den Pfeil, falls Sie nicht weiterkommen) 
kubectl -n rook-ceph get pods -l app=rook-ceph-osd -o wide

1.2: Ceph-OSD-Baum anzeigen

Lasse dir in der Rook-Toolbox die Ceph-interne Sicht auf die OSDs anzeigen.

Lösung (Klicken Sie auf den Pfeil, falls Sie nicht weiterkommen) 
kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash

ceph osd tree

Notiere dir eine OSD-ID, die du in Aufgabe 3 austauschen wirst, sowie den Kubernetes-Node, auf dem sie läuft. Diesen Node verwendest du auch in Aufgabe 2.

1.3: Zugehörigen Datenträger ermitteln

Finde heraus, welches Blockgerät auf dem Node zu deiner notierten OSD-ID gehört. Das musst du jetzt tun, solange die OSD noch aktiv ist: Nach dem Austausch in Aufgabe 3 liefert Ceph für diese OSD keine Metadaten mehr.

kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash

ceph osd metadata <OSD-ID> | grep -E "\"devices\"|\"device_paths\""

Die Ausgabe enthält sowohl den Kernel-Gerätenamen (z. B. sdb) als auch einen stabilen Pfad unter /dev/disk/by-path/.... Notiere dir diesen Pfad als <DEVICE> für Aufgabe 3.

1.4: Referenzzustand speichern

Speichere den aktuellen Zustand, damit du ihn am Ende mit dem Ergebnis vergleichen kannst.

kubectl exec -n rook-ceph deploy/rook-ceph-tools -- ceph status > ceph-status-before.txt

kubectl exec -n rook-ceph deploy/rook-ceph-tools -- ceph osd tree > ceph-osd-tree-before.txt

Aufgabe 2 – Einen Node für eine Wartung vorbereiten, drainen und neu starten

Jetzt simulierst du eine geplante Wartung an dem Node, den du in Aufgabe 1 notiert hast.

2.1: Ausgangszustand des Clusters prüfen

Bevor du den Node cordonst, vergewisserst du dich, dass der Cluster aktuell in einem gesunden Zustand ist.

kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash

ceph status

Achte insbesondere auf:

health: HEALTH_OK
...
pgs: active+clean

Nur wenn der Cluster hier bereits HEALTH_OK meldet und alle Placement Groups active+clean sind, kannst du spätere Health-Abweichungen eindeutig auf die Wartung zurückführen.

2.2: Pod Disruption Management prüfen

Prüfe, ob Rook für diesen Cluster die automatische Verwaltung von Pod Disruption Budgets (PDBs) für OSDs aktiviert hat.

kubectl -n rook-ceph get cephcluster rook-ceph \
  -o jsonpath='{.spec.disruptionManagement}'

Die Ausgabe sollte etwa so aussehen:

spec:
  disruptionManagement:
    managePodBudgets: true
    osdMaintenanceTimeout: 30

Optional kannst du dir auch die tatsächlich erzeugten PDBs ansehen:

kubectl -n rook-ceph get pdb

Was bedeutet das und welche Konsequenz hat das für noout?

Ist managePodBudgets: true gesetzt, legt der Rook-Operator selbst PodDisruptionBudgets für die OSDs an und reagiert automatisch auf einen laufenden Drain: Sobald OSDs auf einem Node evicted werden sollen, setzt Rook selbstständig das Flag noout, damit Ceph die betroffenen OSDs während der Wartung nicht sofort aus der Datenverteilung entfernt. Nach Abschluss der Wartung (oder spätestens nach osdMaintenanceTimeout Minuten) entfernt Rook das Flag wieder automatisch.

Für dich als Betreiber bedeutet das: Bei einem regulären kubectl drain, der die PDBs respektiert, musst du noout in diesem Lab nicht manuell setzen oder entfernen – Rook übernimmt das für dich. Würdest du OSDs stattdessen mit --disable-eviction oder durch direktes Löschen der Pods umgehen, würde dieser automatische Schutz nicht greifen.

2.3: Node cordonen

Markiere den Node als nicht mehr schedulable, damit keine neuen Pods dort landen.

kubectl cordon <NODE>

2.4: Node drainen

Entferne alle verschiebbaren Pods vom Node.

Lösung (Klicken Sie auf den Pfeil, falls Sie nicht weiterkommen) 
kubectl drain <NODE> --ignore-daemonsets --delete-emptydir-data

Beobachte parallel in deinem zweiten Terminal mit ceph -w, wie der Cluster reagiert.

OSD-Pods sind über Node-Affinity fest an den Node gebunden, auf dem ihr Datenträger eingehängt ist. Beim Drain werden sie deshalb nicht auf einen anderen Node verschoben, sondern beendet, und bleiben Pending, bis der Node wieder schedulable ist. Ceph markiert die betroffenen OSDs als down, sobald ihr Heartbeat ausbleibt.

2.5: Node wieder einbinden

Vor diesem Schritt würden in einer echten Wartung die Arbeiten am Node durchgeführt werden. In diesem Lab findet kein echter Eingriff statt, deshalb kannst du den Node jetzt wieder schedulable

Mache den Node wieder schedulable.

Lösung (Klicken Sie auf den Pfeil, falls Sie nicht weiterkommen) 
kubectl uncordon <NODE>

Prüfe anschließend, den Cluster-Zustand:

kubectl -n rook-ceph get pods -l app=rook-ceph-osd -o wide

kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash


ceph status

Achte in der Ausgabe erneut auf:

health: HEALTH_OK
...
pgs: active+clean

Prüfe außerdem, ob die zuvor betroffenen OSDs wieder vollständig up und in sind:

ceph osd tree

Wie erkenne ich, ob eine OSD wieder in ist?

Jede OSD-Zeile enthält zwei Statuswerte: den Zustand des Daemons (up/down) und die Zugehörigkeit zur Datenverteilung (in/out). Beispiel:

ID  CLASS  WEIGHT   TYPE NAME       STATUS  REWEIGHT  PRI-AFF
 2    hdd  1.00000      osd.2         up   1.00000  1.00000

Die Spalte STATUS zeigt up oder down. Ob eine OSD zusätzlich in oder out ist, erkennst du an der Spalte REWEIGHT: 1.00000 bedeutet in, der Wert 0 bedeutet out. Nach einer erfolgreichen Wartung sollten alle zuvor betroffenen OSDs STATUS up und REWEIGHT 1.00000 zeigen.

Aufgabe 3 – Einen defekten Datenträger austauschen

Jetzt simulierst du den Ausfall eines Datenträgers und ersetzt ihn durch ein neues Gerät. Rook unterstützt dafür einen kontrollierten Austausch über eine Annotation am OSD-Deployment: Du löst den Austausch aus, Rook drained und zerstört die OSD selbstständig, du tauschst den Datenträger, und Rook provisioniert die Ersatz-OSD mit derselben OSD-ID und CRUSH-Position. Dadurch backfillt Ceph anschließend nur die Daten dieser einen OSD, statt den ganzen Cluster neu zu verteilen.

Voraussetzung

Der Austausch über eine Annotation setzt voraus, dass am CephCluster spec.healthCheck.daemonHealth.osd.disabled: false und spec.removeOSDsIfOutAndSafeToRemove: false gesetzt sind. In diesem Cluster sind das bereits die aktiven Werte.

3.1: Austausch der OSD auslösen

Markiere das Deployment der in Aufgabe 1 notierten OSD für den Austausch. Die OSD-ID muss dabei sowohl im Deployment-Namen als auch im Annotation-Wert übereinstimmen.

kubectl -n rook-ceph annotate deployment rook-ceph-osd-<OSD-ID> \
  osd.rook.io/replace=yes-really-replace-osd-<OSD-ID>

3.2: Auf die Bereitschaft zum Tausch warten

Warte, bis Rook die OSD gedraint und zerstört hat. Das erkennst du daran, dass am Deployment die Annotation osd.rook.io/replace-ready-for-swap erscheint.

Parallel kannst du in der Toolbox mit ceph osd df osd.<OSD-ID> beobachten, wie ihre Auslastung gegen 0 sinkt, bevor Rook sie zerstört.

kubectl -n rook-ceph get deployment rook-ceph-osd-<OSD-ID> \
  -o jsonpath='{.metadata.annotations.osd\.rook\.io/replace-ready-for-swap}{"\n"}'
Solange der Wert leer ist, drained die OSD noch.

3.3: Datenträger tauschen

Jetzt, wo die Annotation osd.rook.io/replace-ready-for-swap gesetzt ist, kannst du den defekten Datenträger gefahrlos entfernen und durch das Ersatzgerät ersetzen. Da du in diesem Lab keinen Zugriff auf den Host hast und den Datenträger nicht physisch austauschen kannst, simulierst du den Tausch, indem du das Gerät über einen Job auf dem betroffenen Node bereinigst, sodass Rook es wie ein neues Gerät erkennt.

Erstelle dazu eine Datei wipe-device.yaml:

apiVersion: batch/v1
kind: Job
metadata:
  name: wipe-device
  namespace: rook-ceph
spec:
  backoffLimit: 0
  template:
    spec:
      restartPolicy: Never
      nodeName: <NODE>
      containers:
        - name: wipe-device
          image: rook/ceph:v1.20.3
          securityContext:
            privileged: true
            runAsUser: 0
          command:
            - blkdiscard
            - "<DEVICE>"
          volumeMounts:
            - name: dev
              mountPath: /dev
      volumes:
        - name: dev
          hostPath:
            path: /dev

Ersetze <NODE> durch den Namen des Nodes, auf dem die OSD lief, und <DEVICE> durch den stabilen Pfad des Datenträgers, den du in Aufgabe 1.3 ermittelt hast.

Starte den Job und warte auf den Abschluss:

kubectl apply -f wipe-device.yaml

kubectl -n rook-ceph wait --for=condition=complete job/wipe-device

Prüfe bei Bedarf die Logs:

kubectl -n rook-ceph logs job/wipe-device

Lösche den Job anschließend wieder:

kubectl -n rook-ceph delete job wipe-device

3.4: Austausch verifizieren

Warte, bis Rook den bereinigten Datenträger erkennt und die Ersatz-OSD mit derselben OSD-ID wieder hochfährt.

kubectl -n rook-ceph get deployment rook-ceph-osd-<OSD-ID>
Das Deployment sollte wieder 1/1 READY melden, mit derselben OSD-ID wie vor dem Austausch.

Sollte das länger dauern, kannst du ein neues erkennen der Platte über einen neustart des Rook-Operator erzwingen:

kubectl -n rook-ceph rollout restart deployment rook-ceph-operator

Prüfe anschließend in der Toolbox, dass Ceph die Daten auf die neue OSD zurückbackfillt und alle Placement Groups wieder active+clean werden.

ceph status

ceph osd df osd.<OSD-ID>

Aufgabe 4 – Abschlusskontrolle

Zum Abschluss vergleichst du den Zustand des Clusters mit deiner Referenz aus Aufgabe 1.

4.1: Health und OSD-Anzahl prüfen

ceph status

ceph osd df

Prüfe, ob der Cluster wieder vollständig HEALTH_OK meldet und die Anzahl der OSDs wieder identisch mit dem Ausgangszustand aus Aufgabe 1 ist.