Bevor Sie online gehen, müssen Sie die Ceph-Objektspeicherung verstehen

Ceph kann als Open-Source-Software für verteilten Speicher die lokalen Speicherressourcen des X86-Servers nutzen, um einen oder mehrere Speicherressourcenpools zu erstellen und Benutzern einheitliche Speicherdienste basierend auf den Ressourcenpools bereitzustellen, einschließlich Blockspeicher und Objektspeicher ., Dateispeicher, der den Anforderungen von Unternehmen an hohe Zuverlässigkeit, hohe Leistung und hohe Skalierbarkeit des Speichers entspricht und von Unternehmen zunehmend bevorzugt wird. Nach einer Vielzahl von Produktionspraktiken wurde bewiesen, dass das Designkonzept von Ceph fortschrittlich, umfassend in den Funktionen, flexibel in der Verwendung und flexibel ist. Diese Vorteile von Ceph sind jedoch auch ein zweischneidiges Schwert für Unternehmen. Wenn sie gut kontrolliert werden, können sie dem Unternehmen gute Dienste leisten Im Folgenden werde ich es tun. Es ist ein solcher Fall, den ich mit Ihnen teilen möchte.

Unternehmen A bietet externe Cloud-Speicherdienste durch die Bereitstellung von Ceph-Objektspeicherclustern und stellt ein SDK bereit, um Kunden dabei zu helfen, unstrukturierte Daten wie Bilder, Videos und APK-Installationspakete schnell zu realisieren. Cloud-Management. Bevor das Unternehmen offiziell gestartet wurde, wurden auf Ceph ausreichende Funktionstests, Ausnahmetests und Leistungstests durchgeführt.

Die Clustergröße ist nicht sehr groß. Es gibt insgesamt 30 Server, die mit 32 GB Speicher, 10 4T SATA-Festplatten und 1 160G Intel S3700 SSD ausgestattet sind. 300 SATA-Festplatten bilden einen Datenressourcenpool (die Standardkonfiguration ist ein Pool mit dem Namen .rgw.buckets) zum Speichern von Objektdaten; 30 SSD-Festplatten bilden einen Metadatenressourcenpool (die Standardkonfiguration ist ein Pool mit dem Namen .rgw.buckets.index pool). , das Objektmetadaten speichert. Freunde, die Erfahrung im Betrieb und in der Wartungsbereitstellung von Ceph-Objektspeichern haben, wissen, dass diese Konfiguration auch eine internationale Praxis ist, da Ceph-Objektspeicher die Mandantenfähigkeit unterstützt. Wenn mehrere Benutzer Objekte in denselben Bucket (einen logischen Bereich des Benutzers) legen, werden die Metadaten gespeichert Da das gleiche Bucket-Indexobjekt gemeinsam genutzt wird, muss dieses Indexobjekt während des Zugriffs gesperrt werden, und das Bucket-Indexobjekt wird in einem Ressourcenpool gespeichert, der aus einer Hochleistungsfestplatten-SSD besteht Dadurch wird die Zeit jedes Indexobjektzugriffs verkürzt, die E/A-Leistung verbessert und die allgemeine Parallelität des Objektspeichers erhöht.

Nachdem das System online ging, wurden Kundendaten kontinuierlich im Ceph-Objektspeichercluster gespeichert. In den ersten drei Monaten lief alles normal. In dieser Zeit kam es auch zu Ausfällen bei SATA-Festplatten, die mithilfe der Fehlererkennungs- und Reparaturmechanismen von Ceph leicht behoben werden konnten. Die Betriebs- und Wartungsbrüder fühlten sich sehr entspannt. Anfang Mai beschwerten sich die Betriebs- und Wartungsbrüder gelegentlich darüber, dass das der SSD-Festplatte entsprechende OSD manchmal sehr langsam wurde, was zu Geschäftsverzögerungen führte. Als sie auf diese Situation stießen, bestand ihre einfache und effektive Möglichkeit darin, das OSD neu zu starten und zum Normalzustand zurückzukehren. Dieses Phänomen trat wahrscheinlich einige Male sporadisch auf, und der Betriebs- und Wartungsbruder fragte, ob etwas mit der Verwendung von SSDs nicht in Ordnung sei. Nach der Analyse sind wir der Meinung, dass die Anwendung von SSD-Festplatten nichts Besonderes ist, außer dass der Festplattenplanungsalgorithmus auf Frist geändert wurde, sodass wir dieser Angelegenheit keine allzu große Aufmerksamkeit schenken.

Am 28. Mai um 21:30 Uhr erhielten die Betriebs- und Wartungsbrüder einen Systemalarm auf ihren Mobiltelefonen. Eine kleine Anzahl von Dateien konnte nicht geschrieben werden. Sie meldeten sich sofort zur Überprüfung im System an und stellte fest, dass es am OSD lag, das der SSD-Festplatte auf einem Server entsprach. Verursacht durch langsames Lesen und Schreiben. Nach bisherigen Erfahrungen kann in solchen Fällen der OSD-Prozess nach einem Neustart bedenkenlos wieder normalisiert werden. Starten Sie den OSD-Prozess bedenkenlos neu und warten Sie, bis das System wieder normal ist. Aber dieses Mal startete der OSD-Prozess der SSD sehr langsam, was dazu führte, dass der OSD-Prozess der SATA-Festplatte auf demselben Server einfrierte und seinen Takt verlor. Nach einiger Zeit wurde festgestellt, dass der OSD-Prozess der SSD-Festplatte auf anderen Servern langsam einzufrieren begann Server. Führen Sie weiterhin einen Neustart der OSD-Prozesse durch, die den SSD-Festplatten auf anderen Servern entsprechen. Nach wiederholtem Neustart der SSD-Festplatten-OSD-Prozesse können immer mehr SSD-Festplatten-OSD-Prozesse nicht gestartet werden. Die Betriebs- und Wartungsbrüder meldeten die Situation sofort der technischen Forschungs- und Entwicklungsabteilung und forderten sofortige Unterstützung.

Nach unserer Ankunft im Büro bestiegen wir basierend auf dem Feedback der Betriebs- und Wartungsbrüder den Server, versuchten, die OSD-Prozesse für mehrere SSD-Festplatten zu starten, und beobachteten wiederholt den Startvorgang des Vergleichsprozesses :

1 Verwenden Sie den Befehl top, um festzustellen, dass der OSD-Prozess nach dem Start verrückterweise bis zu 20 GB oder manchmal sogar 30 GB zuweist Der letzte Vorgang wurde erfolgreich durchgeführt, das OSD ist noch mit bis zu 10 GB Speicher belegt.

2. Überprüfen Sie das OSD-Protokoll und stellen Sie fest, dass die Protokollausgabe nach dem Eintritt in die FileJournal::_open-Phase stoppt. Nach einer langen Zeit (mehr als 30 Minuten) tritt die Ausgabe in die Phase „load_pg“ ein. Nach dem Eintritt in die Phase „load_pg“ gibt es eine weitere lange Wartezeit. Obwohl „load_pg“ abgeschlossen ist, begeht der Prozess immer noch Selbstmord und wird beendet.

3. Verwenden Sie während des oben genannten langen Startvorgangs pstack, um die Prozessaufrufstapelinformationen anzuzeigen. Der in der FileJournal::_open-Phase angezeigte Aufrufstapel ist die Wiedergabe des OSD-Protokolls und das Löschen des LevelDB-Datensatzes wird während der Transaktionsverarbeitung durchgeführt ; Die in der Phase „load_pg“ angezeigten Aufrufstapelinformationen verwenden das levelDB-Protokoll, um die levelDB-Datei zu reparieren.

4. Manchmal startet ein SSD-Festplatten-OSD-Prozess erfolgreich, aber nach einiger Zeit bricht ein anderer SSD-Festplatten-OSD-Prozess abnormal ab.

Nach diesen Phänomenen zu urteilen, hängen sie alle mit levelDB zusammen. Hängt die große Speicherzuweisung damit zusammen? Nachdem wir uns den LevelDB-bezogenen Code genauer angesehen haben, haben wir festgestellt, dass bei Verwendung eines LevelDB-Iterators in einer Transaktion während des Zugriffs des Iterators auf Datensätze kontinuierlich Speicher zugewiesen wird und der gesamte Speicher erst dann freigegeben wird, wenn der Iterator aufgebraucht ist. Unter diesem Gesichtspunkt wird, wenn die Anzahl der Datensätze, auf die der Iterator zugreift, sehr groß ist, während des Iterationsprozesses viel Speicher zugewiesen. Auf dieser Grundlage untersuchten wir die Anzahl der Objekte im Bucket und stellten fest, dass die Anzahl der Objekte in mehreren Buckets 20 Millionen, 30 Millionen und 50 Millionen erreichte und die Speicherorte dieser großen Bucket-Indexobjekte zufällig die gleichen waren wo das Problem aufgetreten ist. Der Grund für den hohen Speicherverbrauch sollte gefunden sein. Es ist bereits 21:00 Uhr am 30. In den letzten zwei Tagen haben Benutzer begonnen, sich zu beschweren, und die Brüder haben alle das Gefühl ist „großes Problem“. Sie kämpfen seit fast 48 Stunden und die Augen der Brüder sind rot und geschwollen. Sie müssen innehalten und sich ausruhen, sonst werden einige Brüder vor Tagesanbruch fallen.

Am 31. um 8:30 Uhr zogen die Brüder erneut in die Schlacht.

Es gibt ein weiteres Problem: Einige OSDs durchlaufen einen langen Startvorgang und werden schließlich durch Selbstmord beendet, nachdem „load_pg“ abgeschlossen ist. Durch das Lesen des Ceph-Codes wurde bestätigt, dass einige Threads aufgrund einer Zeitüberschreitung Selbstmord begangen haben, weil sie für längere Zeit nicht geplant waren (möglicherweise weil der LevelDB-Thread die CPU für längere Zeit belegt). In der Ceph-Konfiguration gibt es einen Parameter „filestore_op_thread_suicide_timeout“. Durch Testen und Verifizieren kann diese Art von Selbstmord vermieden werden. Wir sahen wieder ein wenig Licht und die Uhr zeigte auf 12:30.

Nachdem einige Prozesse gestartet wurden, belegen sie immer noch bis zu 10 GB Speicher. Wenn dieses Problem nicht behoben ist, ist der Betrieb anderer SATA-Festplatten-OSDs auf demselben Server auch dann nicht möglich, wenn das SSD-Festplatten-OSD hochgezogen wird wird aufgrund von unzureichendem Speicher beeinträchtigt. Brüder, macht weiter so, das ist die Dunkelheit vor der Morgendämmerung, ihr müsst sie durchstehen. Einige Leute überprüften die Informationen, andere schauten sich den Code an und fanden schließlich um 14:30 Uhr einen Befehl, um die Freigabe von Speicher aus dem Ceph-Informationsdokument zu erzwingen: ceph tell osd.* heap release Dieser Befehl kann nach dem Prozess ausgeführt werden begann, den durch den OSD-Prozess belegten überschüssigen Speicher freizugeben. Alle waren sehr begeistert und haben sofort getestet und bestätigt, dass es tatsächlich wirksam ist.

Nachdem ein SSD-Festplatten-OSD gestartet wurde und eine Weile läuft, wird der OSD-Prozess anderer SSD-Festplatten beendet. Basierend auf der obigen Analyse und Positionierung ist dies hauptsächlich auf die Datenmigration zurückzuführen Durch das Löschen zugehöriger Datensatzinformationen wird levelDB dazu veranlasst, Objektmetadatendatensätze zu löschen. Sobald levelDB auf ein übergroßes Bucket-Indexobjekt stößt, durchläuft es die Metadatendatensätze des Objekts mit einem Iterator, was zu einem übermäßigen Speicherverbrauch und zu einem abnormalen OSD-Prozess auf dem Server führt.

Basierend auf der obigen Analyse und nach fast zwei Stunden wiederholter Diskussionen und Demonstrationen haben wir die folgenden Notfallmaßnahmen formuliert:

1 Setzen Sie die Noout-Flagge auf den Cluster und lassen Sie PG nicht zu Migration, denn sobald die PG-Migration erfolgt und das PG aus dem OSD verschoben wird, werden die Objektdaten im PG gelöscht, nachdem das PG entfernt wurde, was dazu führt, dass levelDB den Objektmetadatensatz löscht, wenn ein übergroßer Bucket vorhanden ist Indexobjekt im PG, der Iterator durchläuft die Metadaten. Die Datenprotokollierung verbraucht viel Speicher.

2. Um das der SSD entsprechende OSD zu speichern und das System so schnell wie möglich wiederherzustellen, fügen Sie beim Starten des der SSD entsprechenden OSD-Prozesses den Startparameter filestore_op_thread_suicide_timeout hinzu und legen Sie einen großen Wert fest. Wenn das fehlerhafte OSD aufgerufen wird, wird die CPU von einer Reihe von LevelDB-Prozessen belegt, wodurch die Thread-Planung blockiert wird. Es gibt einen Thread-Deadlock-Erkennungsmechanismus. Wenn der Thread nach der durch diesen Parameter konfigurierten Zeit immer noch nicht geplant ist. Es wird festgestellt, dass es sich um einen Thread-Deadlock handelt. Um einen Prozessselbstmord aufgrund eines Thread-Deadlocks zu vermeiden, muss dieser Parameter festgelegt werden.

3. Unter der aktuellen Situation mit begrenztem Speicher wird bei einem abnormalen OSD-Start die Swap-Partition verwendet. Um den OSD-Prozessstart zu beschleunigen, passen Sie die Swap-Partition an die SSD-Festplatte an.

4. Starten Sie eine geplante Aufgabe und führen Sie den Befehl ceph tell osd.* heap release regelmäßig aus, um die Freigabe des vom OSD belegten Speichers zu erzwingen.

5. Wenn es ein Problem mit dem OSD gibt, das der SSD entspricht, führen Sie die folgenden Schritte aus:

a) Stoppen Sie zunächst alle OSD-Prozesse auf dem Server, um den gesamten Speicher freizugeben.

b) Starten Sie dann den OSD-Prozess und übertragen Sie den Parameter filestore_op_thread_suicide_timeout, wobei Sie einen großen Wert angeben, z. B. 72000.

c) Beobachten Sie den Startvorgang von OSD. Sobald „load_pgs“ ausgeführt wird, können Sie den Befehl „ceph tell osd.N heap release“ sofort manuell ausführen, um den von ihm belegten Speicher zwangsweise freizugeben.

d) Beobachten Sie den Clusterstatus. Wenn der Status aller PGs wieder normal ist, starten Sie die OSD-Prozesse entsprechend anderen SATA-Festplatten.

Befolgen Sie die oben genannten Schritte und stellen Sie die OSD-Prozesse ab 17:30 Uhr nacheinander wieder her. Während des Wiederherstellungsprozesses dauert das Auffüllen mehrerer sehr großer Bucket-Indexobjekte lange. Zugriff auf diesen Bucket Alle Anforderungen werden blockiert, was zu einer Zeitüberschreitung bei Anwendungsgeschäftsanforderungen führt. Dies ist auch eine negative Auswirkung, die durch das Speichern einer großen Anzahl von Objekten in einem einzelnen Bucket verursacht wird.

Am 31. Mai um 23:00 Uhr waren alle OSD-Prozesse endlich wiederhergestellt. Vom Ausfall bis zur erfolgreichen Wiederherstellung des Systems kämpften wir 72 Stunden lang spannend. Wir setzten unsere Bemühungen fort und diskutierten und formulierten gemeinsam eine Lösung, um dieses Problem vollständig zu lösen:

1. Erweitern Sie den Serverspeicher auf 64 GB.

2. Begrenzen Sie für neue Buckets die maximale Anzahl von Speicherobjekten.

3. Nachdem Ceph Version 0.94 vollständig getestet wurde, wird es auf Version 0.94 aktualisiert, um das Problem übermäßig großer Single-Bucket-Indexobjekte zu lösen.

4. Optimieren Sie die Verwendung von LevelDB-Iteratoren. In einer großen Transaktion zeichnet ein Iterator seine aktuelle Iterationsposition auf und gibt sie nach Abschluss einer bestimmten Anzahl von Datensatzdurchläufen frei Neuer Iterator und setzen Sie die Durchquerung ab der Position der letzten Iteration fort, sodass die Speichernutzung des Iterators gesteuert werden kann.

Als Lehrer, der die Vergangenheit nie vergisst und Lehren aus der Vergangenheit zieht, fassen wir die folgenden Punkte zusammen:

1 Das System muss vollständig getestet werden, bevor es online geht

Bevor das System online ging, wurde Ceph zwar vollständig auf Funktionen, Leistung und Ausnahmen getestet, es gab jedoch keinen Stresstest für eine große Datenmenge. Wenn zuvor zig Millionen Objekte in einem einzigen Bucket getestet wurden, besteht diese versteckte Gefahr könnte im Voraus entdeckt werden.

2. Auf jede Auffälligkeit im Betriebs- und Wartungsprozess muss rechtzeitig geachtet werden.

In diesem Fall hatte die Betriebs- und Wartungsabteilung dies bereits einige Zeit vor Ausbruch des Problems gemeldet Das Problem der SSD-Anomalie hat unsere Aufmerksamkeit leider nicht erregt. Hätten wir zu diesem Zeitpunkt eine eingehende Analyse durchgeführt, hätten wir möglicherweise die Grundursache des Problems finden und Vermeidungsmaßnahmen formulieren können.

3. Finden Sie das Temperament von Ceph heraus

Für jedes Softwareprodukt gelten entsprechende Spezifikationseinschränkungen, und Ceph ist keine Ausnahme. Wenn wir im Voraus ein tiefes Verständnis der Ceph-Architektur und ihrer Implementierungsprinzipien haben, die negativen Auswirkungen einer übermäßigen Speicherung einer großen Anzahl von Objekten in einem einzigen Bucket verstehen und im Voraus planen können, werden die in diesem Fall auftretenden Probleme auftreten nicht vorkommen. RGW bietet eine sehr umfassende Unterstützung für Kontingente, einschließlich Kontingente auf Benutzerebene und Bucket-Ebene. Die maximale Anzahl von Objekten, die in einem einzelnen Bucket gespeichert werden dürfen, kann konfiguriert werden.

4. Verfolgen Sie immer den neuesten Fortschritt der Community

In Version 0.94 von Ceph wurde die Shard-Funktion von Bucket-Indexobjekten unterstützt. Ein Bucket-Indexobjekt kann in mehrere Shard-Objekte unterteilt werden für die Speicherung, wodurch das Problem übermäßig großer Single-Bucket-Indexobjekte effektiv gelindert werden kann.