Ceph: Die Reise zu 1 TiB/s

Ceph: Die Reise zu 1TiB/s

• Ein Artikel über die Reise zur Leistungssteigerung eines Ceph-Clusters: Nach langem Debugging und Performance-Tuning wurde eine Datenverarbeitungsrate von 1TiB/s erreicht.
• Er teilt verschiedene technische Probleme und Lösungsansätze, die auftraten, als das Unternehmen Clyso beim Aufbau eines NVMe-basierten 10-Petabyte-Ceph-Clusters half.
• Das Netzwerk des Kunden ist äußerst schnell und gehört zu den schnellsten Ethernet-Konfigurationen.

Danksagung

• Dank an den Kunden von Clyso, dessen Zusammenarbeit es möglich machte, diese Erfahrungen mit der Ceph-Community zu teilen.
• Ebenso Dank an IBM/Red Hat und Samsung dafür, dass sie die für Vergleichstests verwendete Hardware bereitgestellt haben.
• Auch den Ceph-Mitwirkenden wird für ihren Einsatz gedankt, Ceph zu einer hervorragenden Software zu machen.

Cluster-Konfiguration

• Der Kunde schlug 34 Dual-Socket-2U-Knoten in 17 Racks vor, Clyso empfahl jedoch verschiedene Konfigurationen mit kleineren Knoten.
• Letztlich wurde eine Dell-Architektur gewählt, um Kosten zu senken und zugleich schnelleren Speicherdurchsatz, mehr CPU-Ressourcen und höheren Netzwerkdurchsatz zu bieten.
• Die Auswirkungen eines Knotenausfalls auf die Cluster-Wiederherstellung wurden dadurch halbiert.

Test-Setup

• Mit CBT wurde ein temporärer Ceph-Cluster bereitgestellt und FIO-Tests wurden ausgeführt.
• Mithilfe bibliotheksbasierter FIO-Tests wurde der Cluster in kleinere Einheiten zerlegt und mit früheren Ergebnissen verglichen.
• Getestet wurden 3-fache Replikation und 6+2 Erasure Coding sowie Message Version 2 im verschlüsselten und im sicheren Modus.

Hinweis zur PG-Anzahl

• Der Einfluss der PG-Anzahl auf die Performance wurde experimentell untersucht.
• Eine hohe PG-Anzahl kann sich positiv auf die Performance auswirken, sollte in produktiven Umgebungen jedoch zusammen mit anderen Einstellungen betrachtet werden.

Warum der Start schwierig war

• Nach dem ersten Login auf der Hardware bereitete die Fehlersuche Schwierigkeiten, weil die Performance deutlich unter den Erwartungen lag.
• Die ersten Performance-Tests waren gut, doch bei Tests mit mehreren OSDs trat ein Leistungseinbruch auf.

Seltsames Verhalten

• Bei verschiedenen Kombinationen von OSD-Tests wurde ein ungewöhnliches Muster in der Performance entdeckt.
• Es wurde beobachtet, dass die Systemleistung nach Multi-OSD-Tests abfiel und sich erst einige Stunden später wieder erholte.

Drei Lösungen

• Latenzprobleme durch CPU-C-State-Wechsel wurden behoben, was die Performance leicht verbesserte.
• Durch das Deaktivieren von IOMMU wurde die Performance deutlich gesteigert.
• Ein Problem mit RocksDB-Kompilierflags wurde behoben, wodurch sich die 4K-Zufallsschreib-Performance verdoppelte.

Die erste Woche 2024

• Wegen eines größeren Ausfalls in einem anderen Cluster am Neujahrstag konnte man sich nicht auf die Performance-Tests konzentrieren.
• Am Freitag wurden die Tests wieder aufgenommen und bestätigt, dass der Cluster auch unter hoher Last gut funktionierte.

Das Lächeln des Schicksals

• Mit besseren Testergebnissen wurde bestätigt, dass der Cluster linear skaliert.
• In einem Cluster mit 63 Knoten wurde eine Datenverarbeitungsrate von 635GiB/s erreicht.

Ein teilweise funktionierender Todesstern

• Da Client-Knoten fehlten, mussten sich OSD-Knoten und FIO-Prozesse die Ressourcen teilen.
• Selbst in dieser Konfiguration wurde nahezu eine Performance von 950GiB/s erreicht.

1TiB/s erreicht

• Durch Anpassung der Anzahl der OSD-Shards und der Messenger-Threads wurde eine Datenverarbeitungsrate von 1TiB/s erreicht.

Schlaf; Erasure Coding

• Nach Tests mit 3-facher Replikation wurde der Cluster für den vom Kunden genutzten 6+2-Erasure-Coding-Modus umkonfiguriert und erneut getestet.
• Die Leseleistung lag bei über 500GiB/s, die Schreibleistung erreichte fast 400GiB/s.

GN⁺-Meinung:

1. Dieser Artikel beschreibt den Prozess der Performance-Optimierung eines Ceph-Clusters im Detail und liefert technische Einblicke, indem er zeigt, wie durch komplexe Problemlösungen hohe Leistung erzielt wurde.
2. Er zeigt, wie die Zusammenarbeit mit dem Kunden, die Anstrengungen der Community-Mitwirkenden und verschiedene Hardware- und Software-Optimierungsstrategien in der Praxis zu großen Erfolgen führen können.
3. Der Beitrag bietet nützliche Informationen nicht nur für Fachleute, die mit großskaligen Datenspeichersystemen arbeiten, sondern auch für Techniker, die sich für Performance-Optimierung interessieren.

[GN⁺]

Hacker-News-Kommentare

• CERNs Erreichen von 1 TB/s und die Geschichte von Ceph
  • Ein Nutzer erwähnt, dass CERN mit einem EOS-Cluster eine Geschwindigkeit von 1 TB/s erreicht habe, und erklärt, dass dieser Cluster hauptsächlich HDDs nutzt und mehr Nodes besitzt. Außerdem teilt er die interessante Geschichte, dass Ceph bei Dreamhost aus internen Anforderungen heraus entstand und später von Red Hat übernommen wurde.
• Erfahrungen eines früheren technischen Leiters und Sympathie für Ceph
  • Ein Nutzer erinnert sich daran, als technischer Leiter bei Cisco Kubernetes auf Bare Metal eingerichtet und mit GlusterFS sowie Ceph experimentiert zu haben, und erwähnt, dass ihm diese Experimente Spaß gemacht hätten. Außerdem lobt er den gut geschriebenen Artikel.
• Vorschlag zur Verkleinerung der Node-Größe
  • Ein Nutzer weist darauf hin, dass der aktuelle Energieverbrauch pro Node hoch sei, und schlägt vor, technische Anstrengungen in eine Verkleinerung der Nodes zu investieren. Dadurch wären auch weniger Nodes ausreichend, und die Auswirkungen eines einzelnen Ausfalls auf 10 Festplatten könnten reduziert werden.
• Historische Perspektive auf die Menge gespeicherter digitaler Daten
  • Ein Nutzer merkt an, dass es irgendwann in den letzten 60 Jahren einen Tag gegeben haben müsse, an dem weltweit zum ersten Mal insgesamt 1 TiB an digitalen Daten gespeichert war, und drückt sein Erstaunen darüber aus, dass heute eine solche Datenmenge pro Sekunde bewegt wird.
• Erfahrung mit Leistungssteigerung des Docker-Caches durch einen Ceph-Cluster
  • Ein Nutzer berichtet, dass er einen Ceph-Storage-Cluster betreibt, um den Docker-Layer-Cache zu erhalten, und dass sich der Durchsatz nach dem Wechsel von EBS zu Ceph deutlich verbessert habe. Er erwähnt außerdem, dass Ceph fast keinen Wartungsaufwand erfordere.
• Probleme mit Storage-Controller-Software in Kubernetes
  • Ein Nutzer sagt, dass das größte Problem bei dynamischem Storage in Kubernetes nicht mit I/O zusammenhänge, sondern dann auftrete, wenn die Storage-Controller-Software mit echten Problemen konfrontiert werde. Insbesondere habe er bei der Nutzung von rook/ceph und Longhorn erlebt, dass PVCs sich erst nach sehr langer Zeit anhängen.
• Analyse der 1-TiB/s-Leistung im Vergleich zu den theoretischen Hardware-Grenzen
  • Ein Nutzer analysiert, wie sich die Leistung von 1 TiB/s zu den theoretischen Grenzen der Hardware verhält, und weist darauf hin, dass das Netzwerk den Flaschenhals bilde. Außerdem kommt er zu dem Schluss, dass die Komplexität von Ceph die CPU erheblich belaste und das OSD-Threading-Modell nicht optimal sei, und hofft auf Verbesserungen.
• Wunsch nach Vergleich von Ceph mit anderen Object-Storage-Engines
  • Ein Nutzer bittet darum, Vergleiche und Benchmarks zwischen Ceph und anderen Object-Storage-Engines wie MinIO und Garage zu sehen.
• Frage zur Eignung von Ceph für transaktionalen Datenbank-Storage und zur IO-Latenz
  • Ein Nutzer fragt, ob Ceph für transaktionalen Datenbank-Storage geeignet sei und wie die IO-Latenz aussehe, und äußert den Wunsch, zu einem günstigen Dateisystem zu wechseln, das mit Systemen wie Oracles Cluster-Dateisystem oder Veritas konkurrieren könne.