Er braucht dich nicht

Im Zusammenhang mit der wachsenden Popularität von Rook möchte ich über seine Fallstricke und die Probleme sprechen, die Sie auf dem Weg erwarten.

Über mich: Ceph-Verwaltungserfahrung mit der Hammer-Version, Gründer der t.me/ceph_ru-Community in Telegrammen.

Um nicht unbegründet zu sein, werde ich auf von Habr akzeptierte Beiträge (gemessen an der Bewertung) zu Problemen mit Ceph verweisen. Ich bin auch in diesen Beiträgen auf die meisten Probleme gestoßen. Links zu dem am Ende des Beitrags verwendeten Material.

In einem Beitrag über Rook erwähnen wir Ceph aus einem Grund - Rook ist im Wesentlichen Ceph, das in Kubernetes gehüllt ist, was bedeutet, dass es alle seine Probleme erbt. Wir werden mit Ceph-Problemen beginnen.

Vereinfachen Sie die Clusterverwaltung

Einer der Vorteile von Rook ist die Bequemlichkeit der Verwaltung von Ceph durch Kuberentes.

Ceph enthält jedoch mehr als 1000 Parameter für die Abstimmung. Gleichzeitig können wir über rook nur einen kleinen Teil davon bearbeiten.

Leuchtendes Beispiel
> ceph daemon mon.a config show | wc -l
1401

Rook ist eine bequeme Möglichkeit, Ceph zu installieren und zu aktualisieren
Es gibt keine Probleme bei der Installation von ceph ohne Rook - ansible Playbook ist in 30 Minuten geschrieben, aber es gibt viele Probleme bei der Aktualisierung der Probleme.

Zitat aus Kroks Beitrag

Beispiel: Fehlbedienung von Crush-Tunables nach dem Upgrade von Hummer auf Jewel

> Ceph Osd Crush Show-Tunables
{
...
"Straw_calc_version": 1,
"Allowed_bucket_algs": 22,
"Profil": "unbekannt",
Optimal_tunables: 0,
...
}}

Aber auch innerhalb der Nebenversionen gibt es Probleme.

Beispiel: Update 12.2.6 bringt den Cluster in einen fehlerfreien Zustand und bedingt defektes PG
ceph.com/releases/v12-2-8-released

Nicht aktualisieren, warten und testen? Aber wir verwenden Rook auch, um Updates zu vereinfachen.

Die Komplexität des Disaster Recovery-Clusters in Rook

Beispiel: OSD stürzt Hautausschlagfehler unter seinen Füßen ab. Sie vermuten, dass das Problem in einem der Parameter in der Konfiguration liegt. Sie möchten die Konfiguration für einen bestimmten Dämon ändern, können dies jedoch nicht, da Sie über Kubernetes und DaemonSet verfügen.

Es gibt keine Alternative. ceph tell osd.Num Injectargs funktioniert nicht - OSD lügt.

Debug-Komplexität

Für einige Einstellungen und Leistungstests müssen Sie eine direkte Verbindung zum osd-Daemon-Socket herstellen. Im Fall von Rook müssen Sie zuerst den richtigen Container finden, dann hineingehen, den fehlenden für die Debug-Optimierung finden und sehr verärgert sein.

Die Schwierigkeit, das OSD nacheinander anzuheben

Beispiel: OSD fällt auf OOM, die Neuverteilung beginnt, dann der folgende Fall.

Lösung: Erhöhen Sie das OSD nacheinander, warten Sie, bis es vollständig im Cluster enthalten ist, und erhöhen Sie die nächsten. (Mehr im Bericht von Ceph. Anatomie einer Katastrophe.)

Bei der Baremetallinstallation erfolgt dies einfach von Hand. Bei Rook und einem OSD auf dem Knoten treten keine besonderen Probleme auf. Bei OSD> 1 auf dem Knoten treten Probleme beim sukzessiven Anheben auf.

Natürlich sind sie lösbar, aber wir tragen Rook zur Vereinfachung, aber wir bekommen Komplikationen.

Die Schwierigkeit, Grenzen für Ceph-Dämonen auszuwählen

Für Baremetall-Ceph-Installationen ist es einfach genug, die erforderlichen Ressourcen pro Cluster zu berechnen - es gibt Formeln und Studien. Wenn Sie schwache CPUs verwenden, müssen Sie noch eine Reihe von Leistungstests durchführen, um herauszufinden, was Numa ist, aber es ist immer noch einfacher als in Rook.

Im Fall von Rook stellt sich zusätzlich zu den berechnbaren Speichergrenzen die Frage, ob die CPU-Grenze festgelegt werden soll.

Und dann muss man mit Leistungstests schwitzen. Wenn Sie die Grenzwerte unterschätzen, erhalten Sie einen langsamen Cluster. Wenn Sie unlim setzen, erhalten Sie eine aktive CPU-Auslastung mit Neuausrichtung, was sich negativ auf Ihre Anwendungen in Kubernetes auswirkt.

Netzwerkprobleme v1

Für Ceph wird empfohlen, ein 2x10 GB-Netzwerk zu verwenden. Eine für den Client-Verkehr, eine andere für die Office-Nutzung von Ceph (Rebalance). Wenn Sie mit Ceph auf Baremetal leben, ist diese Trennung einfach zu konfigurieren. Wenn Sie mit Rook leben, führt dies bei der Trennung nach Netzwerken zu Problemen für Sie, da Sie bei weitem nicht von jeder Cluster-Konfiguration zwei verschiedene Netzwerke an den Pod senden können.

Netzwerkprobleme v2

Wenn Sie sich weigern, Netzwerke gemeinsam zu nutzen, verstopft der Ceph-Verkehr bei einer Neuverteilung den gesamten Kanal und Ihre Anwendungen in Kubernetes werden langsamer oder stürzen ab. Sie können die Ceph-Neuausgleichsrate reduzieren, aber aufgrund des langen Neuausgleichs besteht ein erhöhtes Risiko, dass der zweite Knoten auf Festplatten oder OOM aus dem Cluster fällt, und es ist bereits garantiert, dass er nur im Cluster schreibgeschützt ist.

Langes Nachwuchten - lange Bremsen

Zitat aus einem Ceph-Beitrag. Katastrophenanatomie.

Testclusterleistung:

Eine 4-KB-Schreiboperation dauert 1 ms, die Leistung 1000 Operationen / Sekunde in einem Stream.

Eine Operation mit einer Größe von 4 MB (Objektgröße) dauert 22 ms, die Leistung 45 Operationen / Sekunde.

Wenn daher eine der drei Domänen ausfällt, befindet sich der Cluster für einige Zeit in einem verschlechterten Zustand, und die Hälfte der Hot-Objekte wird gemäß verschiedenen Versionen verteilt. Die Hälfte der Schreibvorgänge beginnt mit einer erzwungenen Wiederherstellung.

Die erzwungene Wiederherstellungszeit wird ungefähr berechnet - Schreibvorgänge in einem verschlechterten Objekt.

Zuerst lesen wir 4 MB in 22 ms, schreiben 22 ms und dann schreiben wir 1 ms 4 KB Daten selbst. Insgesamt 45 ms für eine Schreiboperation auf ein verschlechtertes Objekt auf der SSD, wenn die Standardleistung 1 ms betrug - ein Leistungsabfall von 45 Mal.

Je mehr wir den Prozentsatz an degradierten Objekten haben, desto schlimmer wird es.

Es stellt sich heraus, dass die Neuausgleichsrate für den korrekten Betrieb des Clusters entscheidend ist.

Serverspezifische Einstellungen für ceph

Ceph benötigt möglicherweise eine spezielle Host-Optimierung.

Beispiel: Sysctl-Einstellungen und derselbe JumboFrame. Einige dieser Einstellungen können sich negativ auf Ihre Nutzlast auswirken.

Die wirkliche Notwendigkeit eines Turmes bleibt in Frage

Wenn Sie sich in der Cloud befinden, haben Sie Speicherplatz von Ihrem Cloud-Anbieter, was viel praktischer ist.

Wenn Sie sich auf Ihren Servern befinden, ist die Ceph-Verwaltung ohne Kubernetes bequemer.

Mieten Sie einen Server in einem kostengünstigen Hosting? Dann werden Sie viel Spaß mit dem Netzwerk, seinen Verzögerungen und seiner Bandbreite finden, was sich offensichtlich negativ auf ceph auswirkt.

Insgesamt: Die Einführung von Kuberentes und die Einführung des Repositorys sind unterschiedliche Aufgaben mit unterschiedlichen Einführungs- und Lösungsoptionen - um sie zu mischen und dann einen gefährlichen Kompromiss für dieses oder jenes einzugehen. Das Kombinieren dieser Lösungen wird bereits in der Entwurfsphase sehr schwierig sein, und es gibt noch eine Betriebsdauer.

Liste der verwendeten Literatur:

Post # 1 Aber du sagst Ceph ... aber ist er gut?
Post # 2 Ceph. Katastrophenanatomie