Angesichts der zunehmenden Beliebtheit von Rook möchten wir über die Fallstricke und Probleme sprechen, die Sie auf Ihrem Weg erwarten werden.
Über mich: Erfahrung in der Ceph-Administration seit Version Hammer, Gründer der Community auf Telegram.
Um nicht unbegründet zu sein, werde ich auf die anerkannten Habr-Posts (laut Ranking) zu Problemen mit Ceph verweisen. Mit den meisten dieser Probleme habe ich ebenfalls Erfahrung. Die Links zu den verwendeten Materialen finden Sie am Ende des Beitrags.
Im Beitrag über Rook erwähnen wir Ceph nicht ohne Grund – Rook ist im Grunde genommen Ceph, das in Kubernetes verpackt ist, und erbt somit all seine Probleme. Lassen Sie uns mit den Problemen von Ceph beginnen.
Vereinfachung der Clusterverwaltung
Einer der Vorteile von Rook ist die bequeme Verwaltung von Ceph über Kubernetes.
Allerdings enthält Ceph über 1000 Konfigurationsparameter, während wir über Rook nur einen kleineren Teil von ihnen anpassen können.
Beispiel in Luminous
> ceph daemon mon.a config show | wc -l
1401
Rook wird als einfacher Weg positioniert, um Ceph zu installieren und zu aktualisieren.
Es gibt keine Probleme bei der Installation von Ceph ohne Rook – ein Ansible-Playbook lässt sich in 30 Minuten schreiben, doch beim Aktualisieren gibt es massenhaft Probleme.
Zitat aus dem Krok-Beitrag
Beispiel: Fehlfunktion von crush tunables nach der Aktualisierung von Hummer auf Jewel
> ceph osd crush show-tunables
{
…
«straw_calc_version»: 1,
«allowed_bucket_algs»: 22,
«profile»: «unknown»,
«optimal_tunables»: 0,
…
}
Doch selbst innerhalb von Minor-Versionen können Probleme auftreten.
Beispiel: Das Update auf 12.2.6 versetzt den Cluster in den Zustand health err und verursacht einen möglicherweise fehlerhaften PG.
Nicht aktualisieren, warten und testen? Aber wir nutzen Rook auch wegen der Komfortabel für Updates.
Die Herausforderungen der Disaster Recovery im Cluster mit Rook.
Beispiel: Ein OSD fällt mit einer Vielzahl von Fehlern aus. Sie vermuten, dass das Problem in einer der Konfigurationseinstellungen liegt, möchten die Konfiguration für einen bestimmten Daemon ändern, können das aber nicht, weil Sie Kubernetes und DaemonSet verwenden.
Es gibt keine Alternative. ceph tell osd.Num injectargs funktioniert nicht – das OSD ist schließlich ausgefallen.
Probleme beim Debugging.
Für einige Einstellungen und Leistungstests ist es notwendig, direkt mit dem OSD-Daemon-Socket zu verbinden. Im Fall von Rook müssen Sie zunächst den entsprechenden Container finden, dann in diesen eintreten, sich über das fehlende Debugging-Tool ärgern und sehr enttäuscht sein.
Herausforderungen beim sequentiellen Hochfahren von OSD.
Beispiel: Ein OSD fällt aufgrund von OOM aus, es beginnt ein Rebalancing, und danach fallen die nächsten aus.
Lösung: Heben Sie die OSD einzeln an, warten Sie, bis diese vollständig im Cluster aktiviert ist, und heben Sie dann die nächsten an. (Mehr dazu im Bericht Ceph. Anatomie einer Katastrophe).
Bei Baremetal-Installationen geschieht dies einfach manuell. Bei Rook und einer OSD pro Node gibt es keine größeren Probleme, Probleme beim nacheinander Anheben treten auf, wenn OSD > 1 pro Node vorhanden ist.
Natürlich sind diese Probleme lösbar, aber wir nutzen Rook zur Vereinfachung und erhalten dennoch eine Komplikation.
Komplexität bei der Festlegung von Limits für Ceph-Demonen.
Für Baremetal-Installationen von Ceph ist es relativ einfach, die erforderlichen Ressourcen für den Cluster zu berechnen — es gibt Formeln und Studien dazu. 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.
Im Falle von Rook kommt neben den berechneten Speicherlimits auch die Frage nach der Festlegung des CPU-Limits auf.
Hier müssen Sie sich intensiver mit Leistungstests beschäftigen. Bei zu niedrigen Limits erhalten Sie einen langsamen Cluster, und bei unbegrenzten Limits werden Sie eine aktive CPU-Nutzung beim Rebalancing feststellen, was sich negativ auf Ihre Anwendungen in Kubernetes auswirken wird.
Probleme mit der Netzwerkintegration v1
Für Ceph wird empfohlen, ein 2x10 Gbit Netzwerk zu verwenden. Eines für den Client-Verkehr, ein anderes für die administrativen Aufgaben von Ceph (Rebalancing). Wenn Sie Ceph auf Baremetal betreiben, lässt sich diese Trennung leicht einrichten. Bei der Verwendung von Rook könnte diese Netztrennung jedoch Probleme verursachen, da nicht jeder Cluster-Konfigurationsansatz zwei verschiedene Netzwerke für ein Pod unterstützt.
Probleme mit der Netzwerkintegration v2
Wenn Sie sich entscheiden, die Netzwerke nicht zu trennen, wird der Ceph-Verkehr beim Rebalancing die gesamte Bandbreite in Anspruch nehmen und Ihre Anwendungen in Kubernetes werden verlangsamt oder ausfallen. Sie können die Geschwindigkeit des Ceph-Rebalancings reduzieren, doch dadurch erhöht sich das Risiko, dass der zweite Knoten aufgrund von Festplattenschwierigkeiten oder OOM (Out of Memory) aus dem Cluster ausfällt, was dazu führt, dass das Cluster nur noch im Lese-Modus arbeitet.
Langes Rebalancing — lange Verzögerungen bei Anwendungen
Zitat aus dem Ceph-Post. Anatomie einer Katastrophe.
Leistung des Testclusters:
Ein Schreibvorgang von 4 KByte benötigt 1 ms, mit einer Leistung von 1000 Operationen/Sekunde in einem Thread.
Ein Vorgang von 4 MByte (Objektgröße) benötigt 22 ms, mit einer Leistung von 45 Operationen/Sekunde.
Wenn also eine von drei Domänen ausfällt, befindet sich der Cluster eine Zeit lang im degradierten Zustand. In diesem Fall werden die heißen Objekte auf verschiedene Versionen verteilt, und die Hälfte der Schreiboperationen wird durch ein erzwungenes Wiederherstellen eingeleitet.
Die Zeit für die erzwungene Wiederherstellung wird ungefähr berechnet – es handelt sich um die Schreiboperationen für das degradierte Objekt.
Zuerst lesen wir 4 MB in 22 ms, schreiben ebenfalls 22 ms, und dann schreiben wir in 1 ms 4 KB tatsächlicher Daten. Insgesamt benötigen wir 45 ms für eine Schreiboperation in ein degradiertes Objekt auf SSD, während die Normalleistung bei 1 ms lag – ein Leistungsabfall von 45-fach.
Je mehr wir von degradierenden Objekten haben, desto alarmierender wird die Situation.
Die Geschwindigkeit des Rebalancings ist entscheidend für die ordnungsgemäße Funktion des Clusters.
Spezifische Servereinstellungen für Ceph
Ceph benötigt oft spezifisches Tuning des Hosts.
Beispiel: sysctl-Einstellungen und JumboFrames; einige dieser Einstellungen können sich negativ auf Ihren Payload auswirken.
Die tatsächliche Notwendigkeit von Rook bleibt fraglich.
Wenn Sie in der Cloud sind, haben Sie Speicherplatz von Ihrem Cloud-Anbieter, was deutlich bequemer ist.
Wenn Sie auf Ihren eigenen Servern sind, ist die Verwaltung von Ceph ohne Kubernetes einfacher.
Mieten Sie Server bei einem preiswerten Anbieter? Dann erwarten Sie viele Herausforderungen mit dem Netzwerk, einschließlich Latenz und Durchsatz, die sich eindeutig negativ auf Ceph auswirken.
Insgesamt: Die Implementierung von Kubernetes und die Einführung von Speicher sind unterschiedliche Aufgaben mit unterschiedlichen Anforderungen und Lösungsansätzen. Diese beiden zu vermischen, bedeutet, möglicherweise einen gefährlichen Kompromiss einzugehen. Es wird sehr schwierig sein, diese Lösungen bereits in der Entwurfsphase zu kombinieren, ganz zu schweigen von der Betriebsphase.
Literaturverzeichnis:
Sie sprechen von Ceph... ist es wirklich so gut?
Ceph. Anatomie einer Katastrophe
Quelle: habr.com
