Container absichern mit verteilten Dateisystemen: Unsinkbare Containerschiffe Teil 1

English version: Click!
Update: Docker on Debian 11

Neulich hatte ich ein Problem in meinem Homelab.

Container absichern mit verteilten Dateisystemen: Unsinkbare Containerschiffe Teil 1

Einer meiner Docker Hosts war wollte nicht mehr, und obwohl dort keine essenziellen Container lagen, gab es Auswirkungen auf System auf einem anderen Server.
Die Schönheit von Microservices!

Lektion 1:
Ich hätte den Docker Host überwachen sollen.

Lektion 2:
Ich bin paranoid: Bei mir im Lab sitzen zwei DCs, die zwei DNS liefern, DHCP ist in Failover-Konfiguration inklusive ordentlicher Relays für die VLANs, eine SQL-AvailabilityGroup stellt die Basis für mein Orion in High Availability Mode.
Und dann sind es die Kleinigkeiten, die Ärger bereiten.

Das Ziel: Verfügbarkeit erhöhen und absichern

Ich hatte zahlreiche Ideen wie z.B. die Orion Plattform zu nutzen, um das Routing zu einem anderen Container zu schieben, bis ich gemerkt habe, dass ich die offensichtliche Lösung übersehen habe: Das Erstellen eines Docker Swarms.

Während meiner Nachforschungen entdeckte ich einen sehr interessanten Ansatz: Einen Docker Swarm auf einem verteilten Dateisystem mit festsitzendem Storage. Nun wollte ich mehr wissen!

Es gibt verschiedene verteilte Dateisysteme für solchen Szenarien, manche sind Open Source, manche zu Lizenzieren, aber sogar einige der Lizenz-Lösungen kommen mit kostenlosen Developer/Community Versionen.
Ich habe mich entschlossen, etwas Zeit mit Ceph zu verbringen, weil es Open Source ist, schon einige Jahre auf dem Markt, von großen Unternehmen produktiv genutzt wird und vor allem hervorragend dokumentiert ist.

Ceph ist zuerst etwas beängstigend. Wenn man sich das anschaut, denkt man sich, das ist viel zu wackelig, um produktiv eingesetzt zu werden, aber tatsächlich nutzen viele Enterprise Storage-Anbieter Ceph als unterliegende Architektur. Darüber hinaus ist es Teil von RedHat’s Storage Lösung und wird out of the box von anderen Linux Distributionen unterstützt.

Ich überlege auch meine Arrays von Truenas zu QuantaStor zu wechseln, also ist das Eintauchen in Ceph eine gute Vorbereitung.

Zuerst ist die Dokumentation überwältigend, da sehr detailliert und, in der Tat, reden wir über ein komplexes Thema. Aber ein halb-automatisierter Ansatz nimmt einen Teil der Komplexität weg.

Also, wo anfangen?

Ich habe eine Ubuntu VM (2 vCPU, 4 GB mem, 16 * 40 GB disk) vorbereitet und mit einer simplen Konfiguration wie SSH/root, SNMP, Zeitzone und NTP angelegt, darauf dann Docker plus Compose, und statische IPs mit DNS vorwärts/rückwärts Einträgen.
Um die Paranoia zu bekämpfen, habe ich auch gleich eine host Datei angelegt:

Die VM bekommt vier Clones, damit ich mit fünf Maschinen verteilt auf vier ESXi arbeiten kann, natürlich, dann ich möchte ja Redundanz. BTW; mach es besser als ich und vergesse nicht, die Hostnamen der Clones zu verändern!

Swarm1 wird mein Swarm Manager, und ich lasse die Installation da laufen. Es gibt ein offizielles Ubuntu Paket:

apt install -y cephadm

Der nächste Schritt ist das Cluster einzuleiten:

cephadm bootstrap --mon-ip 10.0.10.31

Das verifiziert die Netzwerkverbindung, zieht das aktuelle Container Image, und erstellt den ersten Knoten mit einem schönen Dashboard.
Aufgepasst: Am Ende der Installation wird ein Password angezeigt, das am besten sofort irgendwo hin kopieren.

Auf dem Dashboard gibt es im Moment noch nichts zu sehen, also erledigen wir erst ein paar andere Dinge.

In einem späteren Schritt benötigen wir die CLI, also installieren wir sie:

cephadm install ceph-common

Man kann nun jederzeit den aktuellen Status überprüfen:

ceph status

Wir brauchen mehr Knoten!

Wir können auf dem Manager bleiben und die anderen Knoten remote hinzufügen. Eine Voraussetzung ist der Austausch eines Schlüssels, und das geht über SSH. Manchmal kann Linux wirklich bequem sein.

ssh-copy-id -f -i /etc/ceph/ceph.pub root@10.0.10.32
(Repeat for the other nodes)

Knoten hinzufügen:

ceph orch host add swarm2 10.0.10.32 --labels _admin
(Repeat)

Was ist das Label Ding jetzt?
Die kann man zum Markieren von Objekten nutzen. Allgemein dienen sie internen Referenzen, aber manche sind speziell wie z.B. admin, was einen Knoten mit administrativen Fähigkeiten ausstattet.

In meinem kleinen Cluster können ruhig alle mitmachen, also füge ich admin überall hinzu.
Angeblich ist der erste Knoten automatisch der Manager, aber das Label tauchte bei mir nicht auf. Daher nun manuell:

ceph orch host label add swarm1 _admin

Verifizieren mit:

ceph orch host ls

Jetzt brauchen wir Storage

Erinnert ihr euch, dass ich die Maschinen mit zwei Disks angelegt hatte? Wir verknüpfen die zweite nun mit Ceph als Storage Device, die in der entsprechenden Terminologie OSD heißen.
Die Doku zeigt ein viel versprechendes Kommando, um alles in einem Abwasch zu erledigen:

ceph orch apply osd --all-available-devices

Leider hat das für mich gar nichts getan. Also manuell:

ceph orch daemon add osd swarm1:/dev/sdb
(Repeat)

Verifizieren:

ceph orch device ls

Meilenstein erreicht. Der nächste Schritt ist, das tatsächliche Dateisystem zu erstellen, und das geht ganz einfach:

ceph fs volume create data

Verifizieren (ich weiß, ich bin Paranoid, aber so sieht man nach jedem Schritt, ob alles in Ordnung ist):

ceph -s

Mounting des Pools

Dieser Schritt erfordert leider etwas Arbeit, und ich brauchte etwas Zeit, um die notwendigen Schritte der Dokumentation zu entnehmen.

Wir müssen einen Ordner erstellen, Moment, wir sind auf Linux, also erstellen wir ein Verzeichnis.
Von dort aus die Konfiguration an die anderen Knoten verteilen.
Also in den swam2 einloggen und los geht’s:

mkdir -p -m 755 /etc/ceph
ssh root@10.0.10.31 "sudo ceph config generate-minimal-conf" | sudo tee /etc/ceph/ceph.conf
chmod 644 /etc/ceph/ceph.conf

Ein Verzeichnis wird erstellt, eine Kopie der “minimalen Konfiguration” ebenfalls und die Berechtigungen angepasst. Die Doku erwähnt einen weiteren Schritt um die Schlüsseldatei zu kopieren:

ssh root@10.0.10.31 "sudo ceph fs authorize data client.admin / rw" | sudo tee /etc/ceph/ceph.client.admin.keyring

Das hat bei mir leider versagt und nur eine leere Datei erstellt, also habe ich die Datei /etc/ceph/ceph.client.admin.keyring per SSH Client durch die Gegend kopiert.

Die anderen Knoten erfordern die gleiche Vorbereitung.

Der nächste Schritt ist das Erstellen eines Mountpoints und diesen zu Verknüpfen. Die Schritte müssen wieder auf allen Knoten durchgeführt werden:

mkdir /var/data
apt install ceph-fuse -y
ceph-fuse --id admin /var/data

Natürlich auch in /etc/fstab:

none /var/data fuse.ceph ceph.id=admin,_netdev,defaults 0 0
none /var/data fuse.ceph ceph.id=admin,ceph.conf=/etc/ceph/ceph.conf,_netdev,defaults 0 0

Den Budenzauber testen!

Erstellen wir eine Datei, ich bin auf swarm1:

touch /var/data/mylittlepony

Und wir können die Datei auf jedem anderen Knoten sehen. Sehr gut!

Ich denke nun ist eine gute Gelegenheit ins Dashboard zu hüpfen, da wir mittlerweile einiges sehen können.
Es gibt eine http und eine https Variante.
Http nutzt Port 8080, was für einen späteren Schritt suboptimal ist, also vorab ändern:

ceph config set mgr mgr/dashboard/server_port 8081

Wir sehen auch die Cluster Teilnehmer und deren Funktionen sowie das Dateisystem, das wir erstellt haben.

Man kann nun einfach im Dashboard die Funktionen verteilen und so die Redundanz weiter erhöhen.
Die Dokumentation ist voll von Schaltern, um die Umgebung anzupassen, aber es war mir nicht ganz klar, wo man diese einfügen soll.
Wenn man in das Configuration Tab schaut, sieht man nur sechs Seiten von Variablen, das ist nicht viel, zumal am Boden steht “1700 in total”, also, wo sind die anderen?

Oben rechts ist ein kleines Pulldown-Menü für den Developer Mode. Ja klasse, Dev Mode 0 unlimited Power!

Erledigt.

Für mein aktuelles Szenario war es das – ich habe shared storage in Hochverfügbarkeit an mehreren Docker Hosts. Perfekt!

Um das System produktiv einzusetzen, sollte man noch Protokolle wie iSCSI und NFS aktivieren.
Ebenso gibt es einen Windows Client, den ich aber nicht getestet habe.

Ceph ist eine sehr interessante Technologie zum Spielen, und ich werde es sicherlich in anderer Form noch einmal einsetzen.

Aber mein nächstes Projekt ist, was ich eigentlich vorhatte, den Schwarm zu gründen.
Das wird nicht schwer, und ich werde erklären, wie man ihn erstellt und überwacht im nächsten Teil!