🥇Wie man mit fio die Festplatten auf ausreichende Leistung für etcd prüft

Hinweis.: dieser Artikel fasst die Ergebnisse einer Mini-Studie zusammen, die von Ingenieuren von IBM Cloud durchgeführt wurde, um eine reale Herausforderung im Betrieb der Datenbank etcd zu lösen. Uns war eine ähnliche Aufgabe relevant, jedoch könnte der Denk- und Handlungsprozess der Autoren auch in einem breiteren Kontext von Interesse sein.

Kurze Zusammenfassung des gesamten Artikels: fio und etcd

Die Leistung des etcd-Clusters hängt stark von der Geschwindigkeit des darunterliegenden Speichers ab. Zur Überwachung der Leistung exportiert etcd verschiedene Prometheus-Metriken. Eine davon ist wal_fsync_duration_seconds. In der Dokumentation zu etcd wird gesagt, dass der Speicher als ausreichend schnell betrachtet werden kann, wenn der 99. Perzentil dieser Metrik 10 ms nicht überschreitet…

Wenn Sie darüber nachdenken, einen etcd-Cluster auf Linux-Maschinen einzurichten und überprüfen möchten, ob die Speichermedien (z. B. SSDs) schnell genug sind, empfehlen wir, den beliebten I/O-Tester namens fio. Führen Sie einfach den folgenden Befehl aus (das Verzeichnis test-data sollte im gemounteten Abschnitt des getesteten Speichermediums liegen):

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

Jetzt müssen Sie nur noch die Ausgabe betrachten und prüfen, ob der 99. Perzentil fdatasync in 10 ms. Wenn das der Fall ist, funktioniert Ihr Speichergerät schnell genug. Hier ist ein Beispiel für die Ausgabe:

fsync/fdatasync/sync_file_range:
  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync-Pzentile (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

Einige Anmerkungen:

Im obigen Beispiel haben wir die Parameter --size und --bs für den speziellen Fall angepasst. Um aussagekräftige Ergebnisse von fio, geben Sie Werte an, die für Ihr Nutzungsszenario geeignet sind. Darauf wird im Folgenden näher eingegangen.
Während des Tests fio belastet nur das Laufwerkssystem. Im realen Leben könnte es wahrscheinlich sein, dass auch andere Prozesse auf das Laufwerk schreiben (außer den, die mit wal_fsync_duration_seconds). Eine zusätzliche Last könnte die wal_fsync_duration_secondserhöhen. Mit anderen Worten, wenn das 99. Perzentil, das aus dem Test mit fio, leicht unter 10 ms liegt, ist die Wahrscheinlichkeit hoch, dass die Speicherleistung nicht ausreicht.
Für den Test benötigen Sie die Version fio nicht unter 3,5, da ältere Versionen die Ergebnisse nicht aggregieren fdatasync in Form von Perzentilen.
Die obige Ausgabe ist nur ein kleiner Ausschnitt aus der Gesamtausgabe. fio.

Detaillierte Informationen zu fio und etcd.

Ein paar Worte zu den WALs von etcd.

Im Allgemeinen verwenden Datenbanken Write-Ahead-Logging (write-ahead logging, WAL). Das gilt auch für etcd. Eine Diskussion über WAL fällt jedoch nicht in den Rahmen dieses Artikels. Für unsere Zwecke ist es wichtig zu wissen, dass jedes Mitglied des etcd-Clusters WAL im persistenten Speicher speichert. etcd protokolliert bestimmte Operationen mit dem Key-Value-Speicher (z. B. Aktualisierungen) im WAL, bevor sie ausgeführt werden. Wenn ein Knoten zwischen Snapshots abstürzt und neu startet, kann etcd die Transaktionen, die seit dem vorherigen Snapshot durchgeführt wurden, anhand des Inhalts des WAL wiederherstellen.

So fügt etcd jedes Mal, wenn ein Client einen Schlüssel zum KV-Speicher hinzufügt oder den Wert eines bestehenden Schlüssels aktualisiert, eine Beschreibung der Operation in das WAL ein, das eine normale Datei im persistenten Speicher darstellt. Bevor etcd mit der Arbeit fortfährt, MUSS es sich zu 100 % sicher sein, dass der Eintrag im WAL tatsächlich gespeichert ist. Um dies unter Linux zu erreichen, reicht es nicht aus, einen Systemaufruf zu verwenden. write, da der Schreibvorgang auf das physische Medium selbst verzögert werden kann. Zum Beispiel kann Linux WAL-Schreibvorgänge für eine gewisse Zeit im Seiten-Cache des Kernels im Speicher halten. Um sicherzustellen, dass die Daten auf das Medium geschrieben wurden, muss nach dem Schreiben ein Systemaufruf aktiviert werden. fdatasync — genau so verhält sich etcd (wie im folgenden Output zu sehen ist strace; hier 8 — Dateideskriptor WAL):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 
21:23:09.894911 write(8, ".      20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 
21:23:09.895041 fdatasync(8)            = 0

Leider benötigt das Schreiben in den persistenten Speicher einige Zeit. Eine verzögerte Ausführung des Aufrufs fdatasync kann sich negativ auf die Leistung von etcd auswirken. In der Dokumentation des Speichers angegeben wird, wird aufgeführt, dass für eine ausreichende Leistung der 99. Perzentil der Dauer aller Aufrufe fdatasync beim Schreiben in die WAL-Datei weniger als 10 ms betragen sollte. Es gibt auch andere Metriken, die den Speicher betreffen, aber in diesem Artikel wird speziell über diese gesprochen.

Bewertung des Speichers mit fio

Um zu evaluieren, ob ein bestimmter Speicher für die Verwendung mit etcd geeignet ist, kann das Tool fio — ein beliebter I/O-Tester. Bitte beachten Sie, dass die Festplattenein- und -ausgabe unterschiedlich erfolgen kann: sync/async, verschiedene Klassen von Systemaufrufen usw. Das Problem ist, dass fio es äußerst kompliziert zu bedienen ist. Das Tool verfügt über viele Optionen und verschiedene Kombinationen dieser Parameter führen zu völlig unterschiedlichen Ergebnissen. Um eine vernünftige Bewertung im Fall von etcd zu erhalten, müssen Sie sicherstellen, dass die von fio generierte Schreiblast der Schreiblast von etcd bei der Aufnahme in die WAL-Dateien möglichst ähnlich ist:

Das bedeutet, dass die erzeugte fio Last zumindest eine Reihe von sequentiellen Schreibvorgängen in eine Datei darstellen muss, wobei jeder Schreibvorgang aus einem Systemaufruf besteht write, gefolgt von fdatasync.
Um die sequentielle Aufzeichnung zu aktivieren, müssen Sie das Flag --rw=write.
Um fio verwenden, das mit Systemaufrufen gearbeitet hat write (und nicht mit anderen Systemaufrufen – zum Beispiel pwrite), verwenden Sie das Flag --ioengine=sync.
Schließlich sorgt das Flag --fdatasync=1 dafür, dass jeder write folgt fdatasync.
Die zwei anderen Parameter in unserem Beispiel: --size und --bs — können je nach spezifischem Nutzungsszenario variieren. In dem nächsten Abschnitt wird deren Konfiguration beschrieben.

Warum wir fio gewählt haben und wie wir gelernt haben, es einzurichten

Diese Anmerkung basiert auf einem realen Fall, mit dem wir konfrontiert waren. Wir hatten einen Cluster auf Kubernetes v1.13 mit Monitoring über Prometheus. Als Speicher für etcd v3.2.24 kamen SSDs zum Einsatz. Die etcd-Metriken zeigten sogar bei Leerlauf des Clusters zu hohe Latenzen. fdatasyncDiese Werte schienen uns sehr fragwürdig, und wir waren uns nicht sicher, was sie genau repräsentieren. Darüber hinaus bestand der Cluster aus virtuellen Maschinen, sodass nicht klar war, ob die Latenz mit der Virtualisierung zusammenhing oder ob die SSDs die Ursache waren.

Zudem betrachteten wir verschiedene Änderungen an der Hardware- und Softwarekonfiguration, weshalb wir einen Weg zur Bewertung benötigten. Natürlich hätte man etcd in jeder Konfiguration starten und die entsprechenden Prometheus-Metriken beobachten können, aber das hätte erheblichen Aufwand erfordert. Wir benötigten eine einfache Methode zur Bewertung einer bestimmten Konfiguration. Wir wollten unser Verständnis der von etcd kommenden Prometheus-Metriken überprüfen.

Dafür mussten zwei Probleme gelöst werden:

Zunächst einmal, wie sieht die I/O-Last aus, die von etcd beim Schreiben in die WAL-Dateien erzeugt wird? Welche Systemaufrufe kommen zum Einsatz? Wie groß sind die Schreibblöcke?
Zweitens, nehmen wir an, wir haben die Antworten auf die oben genannten Fragen. Wie können wir die entsprechende Last mit fio? Ведь fio — einem äußerst flexiblen Tool mit zahlreichen Optionen (was sich leicht prüfen lässt, zum Beispiel, hier — Anm. d. Red.).

Wir haben beide Probleme mit demselben Ansatz gelöst, der auf Befehlen basiert, lsof und strace:

Mit lsof mit dem man alle offenen Dateideskriptoren des Prozesses sowie die zugehörigen Dateien einsehen kann.
Mit strace Man kann einen bereits laufenden Prozess analysieren oder einen Prozess starten und dessen Aktivitäten beobachten. Der Befehl zeigt alle Systemaufrufe an, die von diesem Prozess und, falls erforderlich, dessen Nachkommen getätigt wurden. Letzteres ist wichtig für Prozesse, die forked werden, und etcd ist einer dieser Prozesse.

Das Erste, was wir taten, war, strace um den etcd-Server im Kubernetes-Cluster zu untersuchen, während dieser im Leerlauf war.

Es wurde festgestellt, dass die Schreibblöcke im WAL sehr eng gruppiert sind, die Größe der meisten lag im Bereich von 2200 bis 2400 Byte. Aus diesem Grund wird am Anfang dieses Artikels im Team-Flag eingesetzt --bs=2300 (bs — die Größe in Bytes jedes Schreibblocks in fio).

Bitte beachten Sie, dass die Größe der Schreibblöcke von etcd je nach Version, Deployment, Parameterwerten usw. variieren kann – dies beeinflusst die Dauer fdatasync. Wenn Sie ein ähnliches Nutzungsszenario haben, analysieren Sie mit Hilfe von strace Ihren etcd-Prozessen, um aktuelle Werte zu erhalten.

Um dann ein klares und umfassendes Verständnis dafür zu bekommen, wie etcd mit dem Dateisystem arbeitet, haben wir es mit strace den Flags -ffttTausgeführt. Dies ermöglichte es, Nachfolgeprozesse zu erfassen und die Ausgabe jedes in eine separate Datei zu schreiben. Außerdem wurden detaillierte Informationen zum Zeitpunkt des Starts und der Dauer jedes Systemaufrufs erhalten.

Wir haben auch den Befehl lsofverwendet, um unser Verständnis der Ausgabe zu bestätigen strace in Bezug darauf, welcher Dateideskriptor für welchen Zweck verwendet wurde. Es ergab sich eine Ausgabe strace, ähnlich wie der oben angegebene. Statistische Manipulationen der Synchronisationszeiten bestätigten, dass die Metrik wal_fsync_duration_seconds von etcd den Aufrufen entspricht fdatasync mit den WAL-Dateideskriptoren.

Um zu generieren mit fio einer Arbeitslast, die der von etcd ähnelt, wurde die Dokumentation des Tools studiert und Parameter ausgewählt, die für unsere Aufgabe geeignet sind. Wir haben sichergestellt, dass die erforderlichen Systemaufrufe verwendet werden und ihre Dauer bestätigt, indem wir fio von strace ausgeführt haben (so wie es bei etcd gemacht wurde).

Besonderes Augenmerk wurde auf die Bestimmung des Wertes des Parameters --sizegelegt. Er stellt die gesamte I/O-Last dar, die von der Utility fio erzeugt wird. In unserem Fall ist dies die Gesamtzahl an Bytes, die auf das Medium geschrieben werden. Sie ist direkt proportional zur Anzahl der Aufrufe write (und fdatasync). Für eine bestimmte bs Anzahl der Aufrufe fdatasync gleich size / bs.

Da uns der Perzentil interessierte, strebten wir danach, dass die Anzahl der Proben groß genug für die statistische Signifikanz ist. Wir entschieden, dass 10^4 (was einer Größe von 22 MB entspricht) ausreichend sein wird. Kleinere Werte des Parameters --size führten zu ausgeprägterem Rauschen (zum Beispiel Aufrufen fdatasync, die viel länger dauern als üblich und die 99. Perzentile beeinflussen).

Es liegt an Ihnen

Der Artikel zeigt, wie man fio bewerten kann, ob ein Speichermedium schnell genug für die Verwendung mit etcd ist. Nun liegt es an Ihnen! Virtuelle Maschinen mit SSD-basiertem Speicher können im Service IBM Cloud.

P.S. vom Übersetzer

Mit praktischen Anwendungsbeispielen fio für die Lösung anderer Aufgaben finden Sie unter Dokumentation. oder direkt in Projekt-Repository (dort sind viel mehr verfügbar, als in der Dokumentation erwähnt wird).