Er ist kein dRook.

Angesichts der wachsenden Beliebtheit von Rook möchte ich über seine Fallstricke und die Probleme sprechen, die Sie auf Ihrem Weg erwarten.

Über mich: Erfahrung in der Verwaltung von Ceph seit Version Hammer, Gründer der Community t.me/ceph_de in Telegram.

Um nicht unbegründet zu sein, werde ich auf die am Hub veröffentlichten (laut Ranking) Beiträge über Probleme mit Ceph verweisen. Mit den meisten dieser Probleme bin ich ebenfalls konfrontiert worden. Links zu den verwendeten Materialien am Ende des Beitrags.

Im Artikel über Rook erwähnen wir Ceph nicht ohne Grund – Rook ist im Grunde Ceph, das in Kubernetes verpackt ist, was bedeutet, dass es alle seine Probleme erbt. Mit den Problemen von Ceph fangen wir an.

Vereinfachung des Cluster-Managements

Einer der Vorteile von Rook ist die bequeme Verwaltung von Ceph über Kubernetes.

Allerdings enthält Ceph über 1000 Parameter zur Konfiguration, während wir über Rook nur einen kleineren Teil von ihnen anpassen können.

Beispiel für Luminous
> ceph daemon mon.a config show | wc -l
1401

Rook wird als bequemer Weg positioniert, Ceph zu installieren und zu aktualisieren.
Mit der Installation von Ceph ohne Rook gibt es keine Probleme – ein Ansible-Playbook wird in 30 Minuten geschrieben, aber beim Aktualisieren gibt es massenhaft Probleme.

Zitat aus dem Krok-Beitrag

Beispiel: Fehlfunktion der Crush-Tunables nach dem Upgrade von Hammer auf Jewel

> ceph osd crush show-tunables
{
…
„straw_calc_version“: 1,
„allowed_bucket_algs“: 22,
„profile“: „unknown“,
„optimal_tunables“: 0,
…
}

Aber selbst innerhalb kleinerer Versionen gibt es Probleme.

Beispiel: Update 12.2.6, das den Cluster in den Zustand health err und bedingt beschädigte PG versetzt
ceph.com/releases/v12-2-8-released

Nicht aktualisieren, warten und testen? Aber wir nutzen doch Rook auch für die Bequemlichkeit der Updates.

Schwierigkeit der Disaster-Recovery im Cluster mit Rook

Beispiel: OSD fällt mit Fehlern zusammen. Sie vermuten, dass das Problem in einem der Parameter in der Konfiguration liegt, möchten die Konfiguration für einen bestimmten Daemon ändern, können es jedoch nicht, weil Sie Kubernetes und DaemonSet haben.

Es gibt keine Alternative. ceph tell osd.Num injectargs funktioniert nicht – das OSD ist schließlich ausgefallen.

Schwierigkeit beim Debuggen

Für einige Einstellungen und Leistungstests muss man direkt mit dem Socket des OSD-Daemons verbinden. Im Fall von Rook muss man zunächst den richtigen Container finden, dann in ihn eintreten, das fehlende Debugging-Tool entdecken und sehr enttäuscht sein.

Schwierigkeit mit dem sequentiellen Hochfahren von OSDs

Beispiel: OSD fällt wegen OOM aus, es beginnt eine Re-Balancierung, danach fallen die nächsten aus.

Lösung: OSDs nacheinander hochfahren, auf das vollständige Hochlaufen im Cluster warten und die nächsten hochfahren. (Mehr im Bericht Ceph. Anatomie einer Katastrophe).

Bei baremetal-Installationen geschieht dies einfach von Hand. Bei Rook und einem OSD pro Node gibt es keine besonderen Probleme. Probleme beim nacheinander Hochfahren treten auf, wenn > 1 OSD pro Node vorhanden ist.

Natürlich sind sie lösbar, aber wir bringen Rook ein, um es zu vereinfachen, und erhalten stattdessen Komplikationen.

Schwierigkeit bei der Festlegung der Limits für Ceph-Demons.

Für baremetal-Installationen ist es relativ einfach, die benötigten Ressourcen für den Cluster zu berechnen – es gibt Formeln und Studien. Bei schwachen CPUs müssen Sie dennoch eine Reihe von Leistungstests durchführen und verstehen, was Numa ist, aber das ist immer noch einfacher als bei Rook.

Bei Rook müssen Sie neben den Speichergrenzen, die Sie berechnen können, auch eine CPU-Grenze festlegen.

Hier werden Sie gefordert, Leistungstests durchzuführen. Bei zu niedrigen Limits erhalten Sie einen langsamen Cluster, bei unlimitierten Limits wird die CPU während der Rebalancierung stark beansprucht, was sich negativ auf Ihre Anwendungen in Kubernetes auswirkt.

Probleme mit der Netzwerkintegration v1.

Für Ceph wird empfohlen, ein 2x10 Gb-Netzwerk zu verwenden. Eins für den Clientverkehr, eines für die administrativen Bedürfnisse von Ceph (Rebalancierung). Wenn Sie mit Ceph auf baremetal leben, ist diese Trennung einfach einzurichten. Wenn Sie mit Rook arbeiten, kann diese Netzwerktrennung problematisch sein, da nicht jede Cluster-Konfiguration es ermöglicht, einem Pod zwei verschiedene Netzwerke zuzuweisen.

Probleme mit der Netzwerkintegration v2.

Wenn Sie sich gegen die Trennung der Netzwerke entscheiden, wird der Ceph-Verkehr beim Rebalancieren die gesamte Bandbreite auslasten und Ihre Anwendungen in Kubernetes werden hängen bleiben oder abstürzen. Sie können die Rebalancierungsrate von Ceph reduzieren, aber dann riskieren Sie durch die längere Rebalancierung, dass der zweite Node aufgrund von Disk-Fehlern oder OOM aus dem Cluster fällt, was zu einem garantierten Read-Only-Zustand für den Cluster führt.

Lange Rebalancierung – lange Verzögerungen für Anwendungen.

Zitat aus dem Beitrag Ceph. Anatomie einer Katastrophe.

Leistung des Testclusters:

Ein Schreibvorgang mit einer Größe von 4 KB benötigt 1 ms, Leistung 1000 Operationen/Sekunde in 1 Thread.

Ein Vorgang mit einer Größe von 4 MB (Objektgröße) benötigt 22 ms, Leistung 45 Operationen/Sekunde.

Daher bleibt der Cluster, wenn eine der drei Domänen ausfällt, eine Zeit lang in einem degradierten Zustand, und die Hälfte der heißen Objekte verteilt sich auf verschiedene Versionen, sodass die Hälfte der Schreibvorgänge mit einer erzwungenen Wiederherstellung beginnt.

Die Zeit für die erzwungene Wiederherstellung wird ungefähr berechnet – Schreibvorgänge auf das degradierte Objekt.

Zuerst lesen wir 4 MB in 22 ms, schreiben 22 ms, und anschließend schreiben wir in 1 ms 4 KB tatsächlicher Daten. Insgesamt also 45 ms für einen Schreibvorgang auf ein degradierte Objekt auf SSD, wo die reguläre Leistung bei 1 ms lag – ein Performance-Rückgang um das 45-fache.

Je höher der Prozentsatz der degradierten Objekte, desto schlimmer wird es.

Die Geschwindigkeit des Rebalancings ist entscheidend für das korrekte Funktionieren des Clusters.

Spezifische Servereinstellungen für Ceph

Ceph benötigt möglicherweise spezifisches Host-Tuning.

Beispiel: sysctl-Einstellungen und JumboFrame, einige dieser Einstellungen können sich negativ auf Ihr Payload auswirken.

Die tatsächliche Notwendigkeit von Rook bleibt fraglich.

Wenn Sie in der Cloud sind, haben Sie Speicher von Ihrem Cloud-Anbieter, was viel bequemer ist.

Wenn Sie auf Ihren eigenen Servern sind, ist die Verwaltung von Ceph ohne Kubernetes einfacher.

Mieten Sie Server bei einem kostengünstigen Hosting-Anbieter? Dann wartet viel Spaß mit dem Netzwerk, den Verzögerungen und der Bandbreite auf Sie, was sich eindeutig negativ auf Ceph auswirkt.

Insgesamt: Die Implementierung von Kubernetes und die Implementierung von Speicher sind unterschiedliche Aufgaben mit unterschiedlichen Anforderungen und unterschiedlichen Lösungsmöglichkeiten – diese zu vermischen, bedeutet, einen potenziell gefährlichen Trade-off zugunsten des einen oder anderen zu machen. Diese Lösungen im Planungsprozess zu verbinden, wird sehr schwierig sein, und es gibt auch die Betriebsphase.

Literaturliste:

Beitrag #1 Aber Sie sagen Ceph… ist er wirklich so gut?
Beitrag #2 Ceph. Anatomie einer Katastrophe

Quelle: habr.com