Sie wollen also einen Ceph-Cluster aufbauen?

Ich bin ein großer Fan von Ceph, der quelloffenen, massiv skalierbaren Software-definierten Speicherlösung. Seine Fähigkeit zur Selbstheilung und zur Bewältigung ansonsten traumatischer Cluster-Ereignisse (oh, Sie haben einen Knoten verloren? kein Problem!), kombiniert mit dem Fehlen von Single Points of Failure, macht es zu einem meiner Favoriten.

Nachfolgend finden Sie drei einfache Prinzipien, die bei der Entwicklung großer oder kleiner Cluster helfen können.

Wenn Ihr Hauptaugenmerk auf den Dollar pro Megabyte Speicherplatz gerichtet ist, dann werden Sie sich natürlich zu den Servern hingezogen fühlen, die die größte Anzahl von Festplatten aufnehmen können, und zu den größten Festplatten, die Sie bekommen können.

Seien Sie hier vorsichtig. Es gibt einige Überlegungen zu „engen und tiefen“ Clustern:

1. Jeder Knoten enthält einen größeren Anteil der Daten Ihres Clusters. Beispiel: In einem Cluster mit drei Knoten enthält jeder Knoten 33 % Ihrer Daten. In einem Cluster mit zehn Knoten sind es nur 10 % pro Knoten. Der Verlust eines einzelnen Knotens in einem kleinen Cluster führt zu einer wesentlich stärkeren Datenmigration, insbesondere wenn sich der Cluster zu füllen beginnt, und möglicherweise zu einem Ausfall, wenn Sie das Verhältnis zwischen vollem und fast vollem Cluster nicht korrekt konfiguriert haben.
2. Erzwingen von mehr Netzwerkverkehr über weniger Knoten. Ceph ist ein netzwerkbasiertes Speichersystem, so dass Sie mit weniger Knoten eine Menge Client-Traffic über weniger NICs erzwingen. Dies wird noch schlimmer, wenn die Anzahl der Festplatten pro Knoten steigt, da mehr OSDs um die begrenzte Bandbreite konkurrieren. Schlimmer noch: Bei Wiederherstellungsereignissen konkurriert der Wiederherstellungsdatenverkehr mit der Client-E/A über das Netzwerk, was die Benutzerfreundlichkeit weiter beeinträchtigt.
3. Bei einer hohen Anzahl von Festplatten pro Knoten kann der Festplatten-Controller einen Engpass darstellen, wenn er nicht über genügend Bandbreite verfügt, um alle Festplatten mit voller Geschwindigkeit zu übertragen.
4. Erhöhte Wiederherstellungs- und Heilungszeit bei Verlust eines ganzen Knotens, da mehr Daten repliziert und wiederhergestellt werden müssen.

Die Leistung des gesamten Clusters skaliert sehr gut, wenn die Anzahl der Knoten steigt. Hier finden Sie einen Vergleich zwischen einem 3-Knoten- und einem 5-Knoten-Cluster mit BlueStore.

Wenn Sie einen großen Cluster anstreben, widerstehen Sie der Versuchung, alle Festplatten auf so wenige Knoten wie möglich zu packen.

Zusammenfassend:

• Ceph skaliert sehr gut, wenn die Anzahl der Knoten steigt.
• Wenn Sie zu wenige Knoten im Cluster haben, befinden sich mehr Ihrer Clusterdaten auf jedem Knoten, was die Wiederherstellungs-E/A und die Wiederherstellungszeiten erhöht.
• Sie können mit nur drei Knoten beginnen, aber wenn Sie es sich leisten können, Ihre Festplatten auf mehr Knoten zu verteilen, ist es besser, dies zu tun.

Seien Sie großzügig bei der Vernetzung

Es macht keinen Sinn, schnelle Medien in einen Server einzubauen und ihn dann mit einer 1GbE-Netzwerkverbindung zu behindern. Streben Sie für die Produktion mindestens 10GbE an, und noch besser ist es, mehrere 10Gb-Schnittstellen mit Link Aggregation Control Protocol (LACP) zu verbinden, um die Bandbreite zu erhöhen. Ceph ist ein netzwerkbasiertes Speichersystem, daher sollte es dem Cluster nicht an Netzwerkbandbreite mangeln.

Trennen Sie immer Ihr öffentliches Netzwerk von Ihrem internen Clusternetzwerk. Das öffentliche Netzwerk ist für den Client-Verkehr zuständig, während das interne Netzwerk für den Heartbeat-, Replikations- und Wiederherstellungsverkehr zwischen den OSDs zuständig ist. Wenn Sie die NICs entbehren können, sollten Sie diese beiden Netzwerke über getrennte Schnittstellen führen. Die Trennung verbessert die Reaktionsfähigkeit der Clients bei Wiederherstellungsereignissen und trägt dazu bei, dass die Wiederherstellungsereignisse schneller abgeschlossen werden, da die Wiederherstellungs-E/A nicht mit der Client-E/A auf derselben NIC konkurriert.

Denken Sie auch daran, dass das interne Netzwerk Ihren Replikationsverkehr überträgt, so dass jeder Schreibvorgang im öffentlichen Netzwerk zu (n-1) Schreibvorgängen im internen Netzwerk führt, wobei n die Anzahl der Replikate ist. Ceph bestätigt einen Schreibvorgang auf dem Client erst dann, wenn er in die Journal/WALs aller Replikate geschrieben wurde – Sie wollen also nicht, dass die Replikationsschreibvorgänge zu einem Engpass im Netzwerk führen. Wenn Sie stark von replizierten Pools Gebrauch machen, sollten Sie Ihr Clusternetzwerk so dimensionieren, dass es n-1 mal größer ist als das öffentliche Netzwerk.

Zu guter Letzt sollten Sie aus Redundanzgründen sicherstellen, dass Sie Ihre Knoten mit redundanten Top-of-Rack-Switches verkabeln. Sie wollen nicht einen ganzen Knoten – oder eine Reihe von Knoten – verlieren, weil ein einzelner Switch ausgefallen ist!

Zusammenfassend:

• 10Gbit Ethernet für die Produktion im Minimum.
• Trennen Sie Ihr öffentliches und Ihr Clusternetzwerk, idealerweise auf verschiedenen NICs, aber zumindest in verschiedenen VLANs/Subnetzen.
• Erinnern Sie sich an die (n-1)-Faustregel für replizierte Daten – denken Sie daran, Ihr internes Netzwerk so zu dimensionieren, dass es n-1 mal größer als das öffentliche ist.
• Vergessen Sie nicht, für Redundanz zu verkabeln und Ihre Verbindungen auf Betriebssystemebene korrekt einzurichten.
• Und als Extra: Vergessen Sie nicht, Jumbo Frames auf Ihren Schnittstellen zu verwenden!

Flash-Medien für BlueStore-Metadaten.

Ceph bestätigt einen Schreibvorgang an den Client erst, wenn die Daten in das Write-ahead-Log (WAL) des primären OSD und in die WALs aller Replikate geschrieben wurden. Je schneller also in das WAL geschrieben wird, desto schneller bestätigt Ceph den Schreibvorgang und desto besser sind die IOPS für den Client.

Ihre WALs und idealerweise auch Ihre BlueStore RocksDB-Metadaten sollten sich auf den schnellsten Medien befinden, die Sie bekommen können – mindestens SSD und wenn möglich NVMe. Wenn Sie einen Full-HDD-Cluster aufbauen, sollten Sie unbedingt ein wenig mehr pro Knoten ausgeben und mindestens zwei schnelle Mediengeräte für Metadaten und WAL hinzufügen.

Um Engpässe auf Ihrem schnellen Mediengerät zu vermeiden, sollten Sie die Dauerschreibgeschwindigkeit Ihrer Datenfestplatten mit der Dauerschreibgeschwindigkeit Ihres schnellen Geräts vergleichen. Wenn Ihre HDD mit 100 MB/s dauerhaft schreiben kann und Ihre SSD 500 MB/s dauerhaft bewältigen kann, dann werden Sie bei mehr als 4-5 OSDs pro SSD einen Engpass bei den Schreibvorgängen haben. NVMe eignet sich perfekt für diesen Anwendungsfall, da ihre anhaltenden Schreibgeschwindigkeiten bis in den Gigabyte-Bereich pro Sekunde reichen können.

Schließlich sollten Sie immer mehr als ein SSD/NVMe-Gerät pro Knoten für Metadaten/WAL haben, um sicherzustellen, dass Sie nicht alle OSDs auf dem Knoten verlieren, wenn ein Metadatengerät ausfällt.

Zusammenfassend:

• Ceph bestätigt einen Schreibvorgang an einen Client, wenn er in die WAL des primären OSD und in die WALs aller Replikate geschrieben wurde. Dies geschieht, um die Integrität der Daten zu bewahren.
• WAL und RocksDB sollten sich auf den schnellsten Medien befinden, die Sie bekommen können – idealerweise NVMe – um eine Antwort an den Client so schnell wie möglich zu erhalten.
• Überschreiben Sie Ihre schnellen Geräte für Ihr WAL/RocksDB nicht. Wenn Sie das tun, verlagern Sie den Engpass nur auf Ihr schnelles Gerät.
• Haben Sie mehr als ein schnelles Gerät, um zu vermeiden, dass alle OSDs auf einem Knoten verloren gehen, wenn Ihr WAL-Gerät ausfällt.

Zusammenfassend

Ceph ist ein netzwerkbasiertes, softwaredefiniertes Speichersystem, das außergewöhnlich gut horizontal skaliert. Dies sind nur einige wenige Grundsätze, die Ihnen bei der Zusammenstellung eines leistungsstarken Systems helfen sollen – gehen Sie nicht zu eng oder zu tief, versorgen Sie den Cluster mit Bandbreite und verwenden Sie schnelle Medien für Ihre Metadaten und WAL.