Rookify: Migration von Ceph-Ansible zu Rook

Um den Übergang von Ceph-Ansible zu Rook zu erleichtern, hat SCS ein Migrationswerkzeug namens Rookify fast fertig entwickelt. Dieses Tool vereinfacht und optimiert den Migrationsprozess, sodass Benutzer problemlos von einer Ceph-Ansible-Installation zu Rook wechseln können. Das Tool befindet sich derzeit in einem ersten technischen Preview und wird getestet.

Funktionen und Design

Statemachine (Zustandsautomat)

Rookify ist ein Python-Paket, das einen auf ‘transitions’ basierenden Zustandsautomaten-Ansatz verwendet, um verschiedene Ressourcen (wie Monitore, Manager, OSDs, MDS und Andere) zu Rook zu migrieren. Jede dieser Ressourcen hat ein entsprechendes Modul in Rookify, das unabhängig oder in Kombination mit anderen Modulen ausgeführt werden kann.

Es ist wichtig zu beachten, dass die meisten Module Abhängigkeiten zu anderen Modulen haben und diese bei Bedarf implizit ausführen. Zum Beispiel muss das migrate_mons Modul zuerst das analyze_ceph Modul ausführen (wie durch die REQUIRES-Variable angegeben). Dies ist notwendig, damit Rookify den aktuellen Standort der Monitore bestimmen und festlegen kann, wohin sie migriert werden sollen.

Rookify kann durch Bearbeiten einer umfassenden config.yaml-Datei konfiguriert werden, wie zum Beispiel in der bereitgestellten config.example.yaml. Diese Konfigurationsdatei spezifiziert verschiedene Abhängigkeiten (wie SSH-Schlüssel, Kubernetes- und Ceph-Konfigurationen) und ermöglicht es Benutzern, einfach zu entscheiden, welche Module ausgeführt werden sollen (siehe den Abschnitt migration_modules unten im config.yaml).

Pickle-Unterstützung

Rookify unterstützt optional (empfohlen) die Verwendung einer Pickle-Datei (siehe oben im Abschnitt general in config.example.yaml). Pickle ist ein Modul zur Objektserialisierung, dass den Fortschrittsstatus extern speichert, d.h. welche Module ausgeführt wurden und Informationen über die Zielmaschine. Das bedeutet:

• Wenn eine laufende Migration aus irgendeinem Grund gestoppt wird, kann Rookify die Pickle-Datei verwenden, um vom gespeicherten Zustand fortzufahren.
• Wenn eine Migration in Teilen ausgeführt wird (z.B. Module werden inkrementell ausgeführt), ermöglicht es die Pickle-Datei den Zustand des Clusters, d.h. der Migration, zu speichern.

⚠️ Wichtig: Die Pickle-Datei sollte manuell gelöscht werden, wenn dieselbe Rookify-Installation verwendet werden soll, um mehr als ein Cluster zu migrieren, oder wenn sich das eine Cluster plötzlich erheblich geändert hat.

Ein einfaches CLI

Derzeit bietet Rookify eine simple CLI-Schnittstelle, die durch Ausführen von rookify mit -h oder --help angezeigt werden kann:

usage: Rookify [-h] [-d] [-m] [-s]

Optionen:
  -h, --help         Zeigt diese Hilfemeldung an und beendet das Programm.
  -d, --dry-run      Vorab-Analyse der Daten und Validierung der Migration.
  -m, --migrate      Führe die Migration durch.
  -s, --show-states  Zeigt den Status der Module an.

Das Argument -m oder --migrate wurde hinzugefügt, um Rookify (wirklich) auszuführen, während die Ausführung ohne Argumente im Preflight-Modus läuft, d.h. mit -d oder --dry-run.

Das Argument -s oder --show-states wurde hinzugefügt, um den Fortschritt zu verfolgen. Hierzu wird die Pickle-Datei ausgelesen. Anschließend berichtet jedes Modul über den bekannten Zustand auf stdout.

Rookify’s Arbeitsablauf: Wie wird die Aufgabe erledigt?

Die Hauptfunktion von Rookify ist es, alle Ressourcen von Ceph zu Rook zu migrieren. Schauen wir uns den Abschnitt migration_modules in der config.yaml-Datei an:

# config.yaml
migration_modules:
- migrate_mons

Diese Konfiguration lässt Rookify die folgenden Schritte ausführen:

1. Preflight-Modus: Das migrate_mons Modul läuft zuerst im Preflight-Modus, der auch manuell mit dem Befehl rookify --dry-run ausgelöst werden kann. In dieser Phase führt Rookify die Preflight-Methoden für die konfigurierten Module und ihre abhängigen Module aus. Außerdem überprüft Rookify den Ausführungsstatus aus der Pickle-Datei. Wenn die Migration bereits erfolgreich abgeschlossen wurde, endet das Modul hier.
2. Abhängigkeitsprüfung: Wenn das migrate_mons Modul noch nicht ausgeführt wurde (angezeigt durch eine leere Pickle-Datei), überprüft Rookify auf Abhängigkeiten, z.B. andere Module, die zuerst ausgeführt werden müssen. Es führt diese Module zuerst im Preflight-Modus und dann in Echtzeit aus. Der Status jedes Moduls wird optional in der Pickle-Datei gespeichert.
   1. Das analyze_ceph Modul: Rookify erkennt, dass das analyze_ceph Modul in jedem Fall zuerst ausgeführt werden muss. Das analyze_ceph Modul sammelt Daten über die laufenden Ceph-Ressourcen und die Kubernetes-Umgebung mit dem dort laufendem Rook-Operator. Beachten Sie, dass analyze_ceph zuerst, wie bei jedem anderen Modul, im Preflight-Modus läuft. Es wird geprüft, ob der Zustand bereits in der Pickle-Datei erfasst wurde. Wenn kein Zustand gefunden wird, sammelt analyze_ceph die notwendigen Informationen.
   2. Das k8s_prerequisites_check Modul: Hier erfolgt die Validierung für die k8s-Namespaces, da der Cluster-Namespace manuell erstellt werden muss. Nur die CephCluster-Ressource wird im nächsten Schritt durch create_rook_cluster erzeugt.
   3. Das create_rook_cluster Module : Nach erfolgreicher Ausführung der analyze_ceph und k8s_prerequisites_check Module überprüft Rookify auf weitere Abhängigkeiten wie das create_rook_cluster Modul. Dieses Modul erstellt die clustermap.yaml für Rook basierend auf den Informationen aus analyze_ceph und k8s_prerequisites_check.
3. Migrationsausführung: Nach erfolgreicher Ausführung von analyze_ceph und create_cluster wird das migrate_mons Modul ausgeführt. Rookify fährt den ersten laufenden Ceph-Monitor auf dem ersten Worker-Node herunter (indem es sudo systemctl disable --now ceph-mon.target verwendet) und aktiviert sofort den entsprechenden Monitor in Rook (indem es seine Metadaten in der clustermap.yaml auf “true” setzt).
4. Monitor-Migration: Rookify setzt diesen Prozess für jeden Monitor fort, bis alle zu Rook migriert und in Betrieb genommen wurden. Optional kann der Zustand in der Pickle-Datei gespeichert werden.

Für sowohl Manager als auch Monitore wird Rookify den gerade beschriebenen Ansatz verwenden: Es wird versuchen, die Ceph-Ressource auszuschalten, nachdem sichergestellt wurde, dass eine entsprechende Ressource im Rook-Cluster neu erstellt werden kann. Bei OSDs und MDSs ist der Migrationsalgorithmus jedoch etwas anders.

Migration von OSDs

Hier funktioniert der für Manager und Monitore beschriebene „Eins-nach-dem-anderen“-Algorithmus nicht, da Rook einen Container namens rook-ceph-osd-prepare verwendet, der immer versucht, alle OSDs auf einem Pfad zu finden und sie gleichzeitig zu erstellen. Beachten Sie, dass es Konfigurationsoptionen gibt, die den Eindruck erwecken, dies zu handhaben, wie useAllNodes=false und useAllDevices=false (siehe rook docs). Beide Variablen sind standardmäßig in der Rook-Bereitstellung von OSISM auf „false“ gesetzt, dennoch versucht rook-ceph-osd-prepare, alle OSDs pro Knoten zu scannen und zu verarbeiten. Dies bedeutet in der Praxis, dass ein device is busy-Fehler sowie ein Crashloop-Feedback auftreten werden. Dieses Verhalten wurde durch das Herunterfahren aller OSD-Dämonen pro Knoten entschärft:

1. Alle OSD-Daemons pro Node müssen gleichzeitig ausgeschaltet werden.
2. Die Pfade der OSD-Geräte müssen einzeln an prepare_osd übergeben werden, um eine sequenzielle Verarbeitung zu erzwingen.
3. Warten, bis jeder OSD auf dem Knoten gestartet ist, bevor fortgefahren wird.

Migration von MDSs

Der „Eins-nach-dem-anderen“-Algorithmus funktioniert hier ebenfalls nicht, da Rook möglicherweise Instanzen aktualisieren (also updaten) möchte, während die Migration im Gange ist. Dies kann zum Beispiel passieren, wenn eine MDS-Instanz des Ceph-Ansible-Deployments abgeschaltet wird und Rook diese Instanz innerhalb von Kubernetes neu erstellen will. Dann möchte Rook möglicherweise alle MDS-Instanzen aktualisieren und wird daher versuchen, alle Instanzen versuchen auszuschalten: auch diejenigen, die noch unter Ceph-Ansible laufen. Rook kann diese Instanzen nicht erreichen und es werden dadurch Abhängigkeiten innerhalb von Rook nicht aufgelöst.

Eine Möglichkeit dieses Problem zu lösen wäre, alle MDS-Instanzen unter Ceph-Ansible auszuschalten und Rook zu erlauben, sie alle neu zu erstellen. Das würde jedoch zu minimalen Ausfallzeiten führen und Rookify strebt an, keine Ausfallzeiten zu verursachen.

Deshalb verwendet Rookify derzeit den folgenden Ansatz:

1. Zwei MDS-Instanzen (mindestens eine muss aktiv sein) werden unter Ceph-Ansible belassen, alle anderen werden ausgeschaltet. Zum Beispiel, im Falle von insgesamt drei MDS-Instanzen wird nur eine MDS-Instanz ausgeschaltet.
2. Von den verbliebenen zwei Instanzen wird nun die erste ebenfalls abgeschaltet aber anschließend in Rook zum Scheduling freigegeben, sodass eine Rook-Instanz startet. Auf diesen Start wird gewartet, bevor die zweite (verbliebene) Instanz abgeschaltet und in Rook aktiviert wird. Alle weiteren Instanzen werden anschließend in Rook abgebildet.

Testlauf: Ausprobieren und beim Testen helfen

Um mit Rookify zu beginnen, stellen Sie sicher, dass Sie die README.md im Repository durchlesen.

Wenn Sie den aktuellen Stand von Rookify testen möchten (sehr geschätzt - melden Sie gerne Issues bei Github), können Sie das Testbed von OSISM verwenden.

Testbed-Einrichtung

ℹ️ Info: Das OSISM-Testbed ist für Testzwecke gedacht, was bedeutet, dass es instabil sein kann. Wenn Ceph und K3s nicht fehlerfrei bereitgestellt werden können, müssen Sie möglicherweise auf eine Fehlerbehebung warten oder eine Umgehungslösung finden, um Rookify zu testen.

Um das Testbed einzurichten, konsultieren Sie zunächst die Testbed-Dokumentation von OSISM um sicherzustellen, dass Sie alle Anforderungen erfüllen. Wenn alles in Ordnung ist, klonen Sie das Repository und verwenden Sie make ceph, um ein Ceph-Testbed einzurichten. Dieser Befehl zieht automatisch die notwendigen Ansible-Rollen, bereitet eine virtuelle Umgebung vor, baut die Infrastruktur mit OpenStack, erstellt einen Manager-Node und stellt Ceph auf drei Worker-Nodes bereit:

git clone github.com:osism/testbed.git
make ceph

Sobald die Infrastruktur für Ceph und das Testbed bereitgestellt wurde, melden Sie sich mit make login an und stellen Sie K3s sowie einen Rook-Operator bereit:

make login 
osism apply k3s
osism apply rook-operator

Wenn Sie Konfigurationen ändern möchten, z.B. eine Rook-Einstellung, gehen Sie zu /opt/configuration/environments/rook/ und sehen Sie in der Dokumentation zu Rook von OSISM nach, um verschiedene Einstellungen zu finden.

Rookify-Einrichtung/Konfiguration für das Testbed von OSISM

1. Klonen des Rookify-Repository’s

Führen Sie make setup aus, damit automatisch das Rookify-Repository gekloned und aufgesetzt wird: es erstellt automatisch eine virtuelle Python-Umgebung, lädt die nötigen Python-Bybliotheken herunter und baut damit ein Python Packet für Rookify in ./.venv/bin/rookify. Sie können auch die andere Hilfefunktionen des Makefile auflisten lassen, indem Sie einfach make (das gleiche wie make help) im Stammverzeichnis des Arbeitsverzeichnisses ausführen.

git clone https://github.com/SovereignCloudStack/rookify
cd rookify
make setup

ℹ️ Info: Wenn Sie einen Fehler der python-rados-Bibliothek erhalten, können Sie make check-radoslib ausführen, um zu prüfen, ob die Bibliothek lokal installiert ist. Wenn nicht, installieren Sie das Paket manuell. Die python-rados-Bibliothek sollte zum Zeitpunkt des Schreibens Version 2.0.0 sein (überprüfen Sie die README.md-Datei von Rookify für die aktuellste Dokumentation). Die Bibliothek konnte nicht in die Einrichtung integriert werden, da Ceph derzeit keine Builds für pip anbietet.

2. Konfigurieren von Rookify

Kopieren Sie config.example.osism.yaml nach config.yamlund ändern Sie die verschiedenen Konfigurationseinstellungen nach Bedarf. Rookify benötigt Zugriff auf einen SSH-Schlüssel (z.B. die .id_rsa-Datei im Terraform-Verzeichnis im Testbed-Repository), Ceph-Konfigurationsdateien (siehe /etc/ceph/ auf einem der Worker-Nodes) und Kubernetes-Dateien (z.B. ~/.kube/config vom Manager-Node). Prüfen Sie gegebenfalls, ob das Makefile Hilfsfunktionen enthält, die Ihnen helfen können.

📝 Hinweis: Stellen Sie sicher, dass Rookify eine Verbindung zum Testbed herstellen kann. Weitere Informationen zum Einrichten einer VPN-Verbindung finden Sie in der OSISM-Dokumentation.

general:
  machine_pickle_file: data.pickle

logging:
  level: INFO # Stufe, auf der das Logging beginnen soll
  format:
    time: "%Y-%m-%d %H:%M.%S" # anderes Beispiel: "iso"
    renderer: console # oder: json

ceph:
  config: ./.ceph/ceph.conf
  keyring: ./.ceph/ceph.client.admin.keyring

# korrekten Pfad zum privaten Schlüssel einfügen
ssh:
  private_key: /home/USER/.ssh/cloud.private
  hosts:
    testbed-node-0:
      address: 192.168.16.10
      user: dragon
    testbed-node-1:
      address: 192.168.16.11
      user: dragon
    testbed-node-2:
      address: 192.168.16.12
      user: dragon

kubernetes:
  config: ./k8s/config

rook:
  cluster:
    name: osism-ceph
    namespace: rook-ceph
    mds_placement_label: node-role.osism.tech/rook-mds
    mgr_placement_label: node-role.osism.tech/rook-mgr
    mon_placement_label: node-role.osism.tech/rook-mon
    osd_placement_label: node-role.osism.tech/rook-osd
    rgw_placement_label: node-role.osism.tech/rook-rgw
  ceph:
    image: quay.io/ceph/ceph:v18.2.1

migration_modules: # legt fest, welche Module ausgeführt werden sollen. Beachten Sie, dass einige der Module andere Module erfordern, die ebenfalls ausgeführt werden müssen. Dies geschieht automatisch.
- analyze_ceph

3. Rookify ausführen:

Jetzt können Sie endlich Rookify ausführen um es zu testen. Rookify erlaubt die Verwendung von --dry-run, um Module im Preflight-Modus auszuführen. Beachten Sie, dass Rookify die verschiedenen Module immer zuerst im Preflight-Modus ausführt bevor anschließend, bei fehlerfreiem Durchlauf, eine Migration gestartet wird.

Wenn alles korrekt eingerichtet ist, können Sie Rookify ohne Argumente ausführen oder sie wagen es explizit --migrate als Argument zu geben. In diesem Fall machen Sie nichts kaput, wenn Sie das analyze_ceph-Modul auszuführen, da dieses keine kritischen Änderungen vornimmt:

📝 Hinweis: Ohne Argumente wird Rookify per default im Preflight-Modus laufen (es wird dann --dry-run hinzugefügt).

# Preflight-Modus
.venv/bin/rookify --dry-run
# Reales Ausführen: das analyze_ceph Modul sollte nichts kaputt machen
.venv/bin/rookify --migrate

⚠️ Wichtig: Es wird empfohlen, jedes Modul zuerst im Preflight-Modus auszuführen, um echte Änderungen zu vermeiden.

Sie sollten dann folgende Ausgabe auf der Konsole sehen:

.venv/bin/rookify
2024-09-02 15:21.37 [info     ] Execution started with machine pickle file
2024-09-02 15:21.37 [info     ] AnalyzeCephHandler ran successfully.

Beachten Sie, dass es jetzt eine Datei “data.pickle” (je nach dem wie es benannt wurde im config.yaml) im Stammverzeichnis des Arbeitsverzeichnisses gibt. Diese Datei sollte Daten enthalten:

du -sh data.pickle
8.0K	data.pickle

An diesem Punkt können wir die Datei config.yaml erneut bearbeiten, um die osds-, mds-, mgr- und rgw- Ressourcen zu migrieren:

migration_modules:
- analyze_ceph
- create_rook_cluster
- migrate_mons
- migrate_osds
- migrate_osd_pools
- migrate_mds
- migrate_mds_pools
- migrate_mgrs
- migrate_rgws
- migrate_rgw_pools

ℹ️ Info: Einige der Module sind redundant in dem Sinne, dass ihre REQUIRED-Variablen die Module bereits als ihre Abhängigkeiten enthalten. Zum Beispiel hat migrate_osds die folgende REQUIRED-Variable: REQUIRES = [„migrate_mons“], und migrate_mons hat REQUIRES = [„analyze_ceph“, „create_rook_cluster“]. Man könnte also die ersten drei Module aus der Konfiguration entfernen. Die zusätzliche Erwähnung der Module kann hier aber die Übersichtlichkeit für den Leser verbessern. Tatsächlich wird Rookify die Module nur einmal ausführen, so dass es nicht schadet, sie in der config.yaml hinzuzufügen.

Wir können Rookify zunächst mit pre-flight starten, um zu prüfen, ob alles in Ordnung ist und es dann explizit mit dem Argument --migrate versehen, um die wirkliche Migration zu starten. Als Ergebnis sollten wir folgenden Output sehen:

.venv/bin/rookify
2024-09-04 08:52.02 [info     ] Execution started with machine pickle file
2024-09-04 08:52.04 [info     ] AnalyzeCephHandler ran successfully.
2024-09-04 08:52.04 [info     ] Validated Ceph to expect cephx auth
2024-09-04 08:52.04 [warning  ] Rook Ceph cluster will be configured without a public network and determine it automatically during runtime
2024-09-04 08:52.04 [info     ] Rook Ceph cluster will be configured without a cluster network
2024-09-04 08:52.11 [warning  ] ceph-mds filesystem 'cephfs' uses an incompatible pool metadata name 'cephfs_metadata' and can not be migrated to Rook automatically
2024-09-04 08:52.16 [info     ] Creating Rook cluster definition
2024-09-04 08:52.16 [info     ] Waiting for Rook cluster created
2024-09-04 08:52.16 [info     ] Migrating ceph-mon daemon 'testbed-node-0'
2024-09-04 08:52.32 [info     ] Disabled ceph-mon daemon 'testbed-node-0'
2024-09-04 08:53.45 [info     ] Quorum of 3 ceph-mon daemons successful
2024-09-04 08:53.45 [info     ] Migrating ceph-mon daemon 'testbed-node-1'
2024-09-04 08:54.07 [info     ] Disabled ceph-mon daemon 'testbed-node-1'
2024-09-04 08:54.44 [info     ] Quorum of 3 ceph-mon daemons successful
2024-09-04 08:54.44 [info     ] Migrating ceph-mon daemon 'testbed-node-2'
2024-09-04 08:55.04 [info     ] Disabled ceph-mon daemon 'testbed-node-2'
2024-09-04 08:55.52 [info     ] Quorum of 3 ceph-mon daemons successful
2024-09-04 08:55.52 [info     ] Migrating ceph-osd host 'testbed-node-0'
2024-09-04 08:55.55 [info     ] Disabled ceph-osd daemon 'testbed-node-0@0'
2024-09-04 08:55.57 [info     ] Disabled ceph-osd daemon 'testbed-node-0@4'
2024-09-04 08:55.57 [info     ] Enabling Rook based ceph-osd node 'testbed-node-0'
2024-09-04 08:57.00 [info     ] Rook based ceph-osd daemon 'testbed-node-0@0' available
2024-09-04 08:57.02 [info     ] Rook based ceph-osd daemon 'testbed-node-0@4' available
2024-09-04 08:57.02 [info     ] Migrating ceph-osd host 'testbed-node-1'
2024-09-04 08:57.05 [info     ] Disabled ceph-osd daemon 'testbed-node-1@1'
2024-09-04 08:57.07 [info     ] Disabled ceph-osd daemon 'testbed-node-1@3'
2024-09-04 08:57.07 [info     ] Enabling Rook based ceph-osd node 'testbed-node-1'
2024-09-04 08:58.46 [info     ] Rook based ceph-osd daemon 'testbed-node-1@1' available
2024-09-04 08:58.46 [info     ] Rook based ceph-osd daemon 'testbed-node-1@3' available
2024-09-04 08:58.46 [info     ] Migrating ceph-osd host 'testbed-node-2'
2024-09-04 08:58.48 [info     ] Disabled ceph-osd daemon 'testbed-node-2@2'
2024-09-04 08:58.50 [info     ] Disabled ceph-osd daemon 'testbed-node-2@5'
2024-09-04 08:58.50 [info     ] Enabling Rook based ceph-osd node 'testbed-node-2'
2024-09-04 09:00.25 [info     ] Rook based ceph-osd daemon 'testbed-node-2@2' available
2024-09-04 09:00.27 [info     ] Rook based ceph-osd daemon 'testbed-node-2@5' available
2024-09-04 09:00.27 [info     ] Migrating ceph-mds daemon at host 'testbed-node-0'
2024-09-04 09:00.27 [info     ] Migrating ceph-mds daemon at host 'testbed-node-1'
2024-09-04 09:00.27 [info     ] Migrating ceph-mds daemon at host 'testbed-node-2'
2024-09-04 09:00.27 [info     ] Migrating ceph-mgr daemon at host'testbed-node-0'
2024-09-04 09:01.03 [info     ] Disabled ceph-mgr daemon 'testbed-node-0' and enabling Rook based daemon
2024-09-04 09:01.20 [info     ] 3 ceph-mgr daemons are available
2024-09-04 09:01.20 [info     ] Migrating ceph-mgr daemon at host'testbed-node-1'
2024-09-04 09:01.51 [info     ] Disabled ceph-mgr daemon 'testbed-node-1' and enabling Rook based daemon
2024-09-04 09:02.09 [info     ] 3 ceph-mgr daemons are available
2024-09-04 09:02.09 [info     ] Migrating ceph-mgr daemon at host'testbed-node-2'
2024-09-04 09:02.41 [info     ] Disabled ceph-mgr daemon 'testbed-node-2' and enabling Rook based daemon
2024-09-04 09:03.00 [info     ] 3 ceph-mgr daemons are available
2024-09-04 09:03.00 [info     ] Migrating ceph-rgw zone 'default'
2024-09-04 09:03.00 [info     ] Migrated ceph-rgw zone 'default'
2024-09-04 09:03.00 [info     ] Migrating ceph-osd pool 'backups'
2024-09-04 09:03.01 [info     ] Migrated ceph-osd pool 'backups'
2024-09-04 09:03.01 [info     ] Migrating ceph-osd pool 'volumes'
2024-09-04 09:03.01 [info     ] Migrated ceph-osd pool 'volumes'
2024-09-04 09:03.01 [info     ] Migrating ceph-osd pool 'images'
2024-09-04 09:03.01 [info     ] Migrated ceph-osd pool 'images'
2024-09-04 09:03.01 [info     ] Migrating ceph-osd pool 'metrics'
2024-09-04 09:03.01 [info     ] Migrated ceph-osd pool 'metrics'
2024-09-04 09:03.01 [info     ] Migrating ceph-osd pool 'vms' 
2024-09-04 09:03.01 [info     ] Migrated ceph-osd pool 'vms'  
2024-09-04 09:03.01 [info     ] Migrating ceph-rgw daemon at host 'testbed-node-2'
2024-09-04 09:04.27 [info     ] Disabled ceph-rgw host 'testbed-node-2'
2024-09-04 09:04.35 [info     ] Rook based RGW daemon for node 'testbed-node-2' available
2024-09-04 09:04.35 [info     ] Migrating ceph-rgw daemon at host 'testbed-node-1'
2024-09-04 09:04.41 [info     ] Disabled ceph-rgw host 'testbed-node-1'
2024-09-04 09:05.09 [info     ] Rook based RGW daemon for node 'testbed-node-1' available
2024-09-04 09:05.09 [info     ] Migrating ceph-rgw daemon at host 'testbed-node-0'
2024-09-04 09:05.13 [info     ] Disabled ceph-rgw host 'testbed-node-0'
2024-09-04 09:05.19 [info     ] Rook based RGW daemon for node 'testbed-node-0' available

Wow! Wir sind von Ceph-Ansible nach Rook migriert! Wenn wir jetzt in das Testbed einloggen können wir die “Health” des clusters nochmal mit ceph -s kontrollieren. Mit kubectl kann man noch checken, das alle Pods da sind.

Über den Autor