Migration von Proxmox-CephX-Schlüsseln für alte OSDs

Nach dem abgeschlossen Update von Ceph auf die Version 19.2.6 oder 20.2.4 liefert ein ceph status einen HEALTH_ERR. Der Puls geht hoch, das Monitoring-System verschickt E-Mails, das Dashboard von Proxmox zeigt einen großen, roten Kreis:

Der Puls geht wieder herunter, sobald klar ist, dass das Ceph noch funktioniert, es möchte nur sehr eindrücklich darauf hinweisen, dass der bisher verwendete Algorithmus für die Schlüssel der Komponenten jetzt als unsicher eingestuft wird. Die Schlüssel müssen also getauscht werden.

Die Migration der Schlüssel ist bei Proxmox dokumentiert. Proxmox bringt ein Skript mit, welches einem die meisten Schritte der Schlüssel-Migration abnimmt.

Allerdings erhielt ich auf einem Cluster gleich beim Ausführen des ersten Skriptes die folgende Fehlermeldung:

FAIL: These keys cannot be rewritten where their daemons read them, so rotating them would strand the daemons: the bluestore label of osd.0 on node ’node01′ carries no ‚osd_key‘, so a rotated key could not be made to survive a reboot

Das Skript weigerte sich, die Migration durchzuführen. Die gleiche Fehlermeldung wurde auch für ein Dutzend weiterer OSDs ausgegeben, jedoch nicht für alle. Alle OSDs waren Bluestore-OSDs, von Ceph nicht mehr unterstützte Filestore-OSDs waren nicht vorhanden. Die OSDs im Cluster wurden zu verschiedenen Zeitpunkten erstellt. In der Fehlermeldung wurden nur ältere OSDs aufgeführt, welche unter Ceph Luminous mit ceph-disk angelegt wurden. Neuere, mit ceph-volume lvm erzeugte, waren nicht betroffen.

Die Proxmox-Dokumentation schreibt dazu:

If the plan reports no blocker, apply the same selection

Der Fall, dass es einen Blocker gibt, ist in der Dokumentation schlicht nicht vorgesehen. Daher möchte ich hier beschreiben, wie dieses Problem gelöst werden kann.

Zu jeder OSD gibt es Metadaten. Diese werden in Form von Schlüssel-Werte-Paaren zusammen mit den Nutzdaten auf dem Datenträger gespeichert und „Bluestore-Label“ genannt. Welche Daten hinterlegt sind, kann sich zwischen verschiedenen OSDs unterscheiden. Dies hängt unter anderem auch davon ab, mit welchem Tool die OSD erstellt wurde. Wurde die OSD mit ceph-volume lvm angelegt, gibt es einen Schlüssel mit dem Namen osd_key; bei mit ceph-disk angelegten OSDs fehlt dieser. ceph-disk ist in aktuellen Ceph-Versionen nicht mehr vorhanden, damit erstellte OSDs können aber weiterhin verwendet werden.

Im Betrieb wird der Schlüssel osd_key nicht zwingend benötigt, das Migrations-Skript für die Rotation der CephX-Schlüssel lässt sich aber nicht ausführen, wenn sie fehlen. Es gibt drei Möglichkeiten, dieses Problem zu lösen:

1. Es können nacheinander alle betroffenen OSDs gelöscht und neu erstellt werden, dabei wird automatisch ceph-volume lvm verwendet. Dabei müssen aber alle Daten auf den betroffenen OSDs einmal komplett neu geschrieben werden.
2. Die CephX-Schlüssel-Rotation kann manuell durchgeführt werden.
3. Die alten CephX-Schlüssel können nachträglich in die Bluestore-Label der OSDs geschrieben werden, anschließend funktioniert das Migrationsskript.

Hier wird die dritte Variante beschrieben.

Für jede OSD gibt es auf dem Host ein Verzeichnis, für die OSD 0 ist dies beispielsweise /var/lib/ceph/osd/ceph-0. In diesem Verzeichnis gibt es einen Symlink mit dem Namen block, welcher auf das zugehörige Block-Device verweist, im Beispiel auf /dev/sdc2. Auf diesem Block-Device sind das Bluestore-Label und die Daten der OSD gespeichert.

Die Schlüssel und Werte des Bluestore-Labels dieser OSD können mit dem ceph-bluestore-tool ermittelt werden:

# ceph-bluestore-tool show-label --dev /dev/sdc2 
{ 
    "/dev/sdc2": { 
        "osd_uuid": "f0021ce9-7298-4ffa-9cf2-6f2a2695cec1", 
        "size": 479998054400, 
        "btime": "2019-03-31T13:12:55.507583+0100", 
        […] 
    } 
}

Wenn die OSD mit ceph-disk erstellt wurde, wird es hier keinen Schlüssel osd_key geben, was sich mit der Fehlermeldung des Migrations-Skriptes deckt.

Der CephX-Schlüssel für die OSD muss also auf einem anderen Weg ermittelt werden. Eine zuverlässige Methode ist, den Schlüssel der OSD aus dem Keyring von Ceph auszulesen:

# ceph auth get osd.0:
[osd.0]
  key = AQACVKpqfD3vORAAkABxNVsVztZZ3ZXL2udSHQ==
  caps mgr = "allow profile osd"
  caps mon = "allow profile osd"
  caps osd = "allow *"

Der ermittelte CephX-Schlüssel kann jetzt als Wert des Schlüssels osd_key im Bluestore-Label der OSD hinterlegt werden. Dazu muss die OSD kurz gestoppt werden:

# systemctl stop ceph-osd@0.service
# ceph-bluestore-tool set-label-key --dev /dev/sdc2 --key osd_key --value 'AQACVKpqfD3vORAAkABxNVsVztZZ3ZXL2udSHQ=='
# systemctl start ceph-osd@0.service

Eine erneute Abfrage des Labels sollte jetzt auch diesen Schlüssel anzeigen:

# ceph-bluestore-tool show-label --dev /dev/sdc2
{
    "/dev/sdc2": {
        […]
        "osd_key": "AQDIZapqQEuULhAAgP2X0nY2et409lQ+lSvt5w==",
        […]
    }
}

Wahrscheinlich sind mehrere OSDs betroffen. Folgender Befehl führt alle Schritte automatisch für die angegebene OSD, in diesem Fall OSD 1, aus:

OSD=1; systemctl stop ceph-osd@${OSD}.service && ceph-bluestore-tool set-label-key --dev /var/lib/ceph/osd/ceph-${OSD}/block --key osd_key --value $(ceph auth get osd.${OSD} | awk '/key/ { print $3 }') && systemctl start ceph-osd@${OSD}.service

Dieser Befehl muss für alle betroffenen OSDs auf dem Knoten ausgeführt werden, auf welchem die OSD läuft.

Wurden die CephX-Schlüssel aller OSDs im Bluestore-Label hinterlegt, sollte das Migrations-Skript von Proxmox jetzt keine Fehlermeldung mehr anzeigen:

# /usr/share/pve-manager/migrations/pve-cephx-rotate-service-keys --rotate-cluster-keys
[…]
Dry run finished
PASS: Preflight checks passed for the displayed plan.
Review the plan, then run this again with '--apply' to carry it out.

Die Migration auf den neuen Algorithmus kann jetzt gemäß der offiziellen Anleitung durchgeführt werden.