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

Anmerkung des Übersetzers.: Dieser Artikel ist das Ergebnis einer Mini-Studie, die von IBM Cloud Ingenieuren durchgeführt wurde, um Lösungen für ein reales Problem im Zusammenhang mit dem Betrieb der Datenbank etcd zu finden. Für uns war eine ähnliche Aufgabe relevant, jedoch könnte der Denk- und Handlungsansatz 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 zugrunde liegenden 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, wird erwähnt, 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 Ihre Speicher (z.B. SSDs) schnell genug sind, empfehlen wir die Nutzung eines beliebten I/O-Testprogramms mit dem Namen fio. Sie müssen lediglich den folgenden Befehl ausführen (das Verzeichnis test-data sollte im gemounteten Verzeichnis des getesteten Speichers liegen):

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

Überprüfen Sie jetzt einfach die Ausgabe und stellen Sie sicher, dass der 99. Perzentil fdatasync unter 10 ms liegt. Wenn dem so ist, funktioniert Ihr Speicher ausreichend schnell. 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 Perzentile (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 an den spezifischen Fall angepasst. Um sinnvolle Ergebnisse von fiozu erhalten, geben Sie Werte an, die zu Ihrem Nutzungsszenario passen. Wie man diese auswählt, wird weiter unten erläutert.
Während des Tests fio belastet nur das Datensystem. In der realen Welt könnte es durchaus sein, dass auch andere Prozesse (neben denjenigen, die mit wal_fsync_duration_seconds) auf die Festplatte schreiben. Diese zusätzliche Belastung könnte zu einer Erhöhung von wal_fsync_duration_secondsführen. Mit anderen Worten, wenn der 99. Perzentil, der aus dem Test mit fio, gewonnen wurde, nur leicht unter 10 ms liegt, besteht eine hohe Wahrscheinlichkeit, dass die Speichergeschwindigkeit nicht ausreichend ist.
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 des gesamten Outputs. fio.

Detaillierte Informationen zu fio und etcd.

Einige Worte zu den WALs von etcd.

In der Regel verwenden Datenbanken Write-Ahead-Logging (Write-Ahead Logging, WAL). Das gilt auch für etcd. Die Diskussion über WAL überschreitet den Rahmen dieses Artikels; für unsere Zwecke ist jedoch Folgendes wichtig: Jedes Mitglied des etcd-Clusters speichert WAL im persistenten Speicher. etcd protokolliert einige Operationen mit dem Key-Value-Speicher (z. B. Updates) im WAL, bevor es sie ausführt. Falls ein Knoten zwischen den Snapshots ausfällt und neu gestartet wird, kann etcd die seit dem letzten Snapshot durchgeführten Transaktionen anhand des Inhalts des WAL wiederherstellen.

Somit fügt etcd jedes Mal, wenn ein Client einen Schlüssel zum KV-Speicher hinzufügt oder einen Wert eines bestehenden Schlüssels aktualisiert, eine Beschreibung der Operation zum WAL hinzu, das eine gewöhnliche Datei im persistenten Speicher darstellt. Bevor etcd fortfahren kann, MUSS es sich zu 100 % sicher sein, dass der Eintrag im WAL tatsächlich gespeichert wurde. Um dies in Linux zu gewährleisten, reicht es nicht aus, den Systemaufruf schreiben, da die eigentliche Schreiboperation auf den physischen Speicher verzögert werden kann. Zum Beispiel kann Linux eine WAL-Aufzeichnung eine Zeit lang im Kernel-Cache im Speicher halten (z. B. im Seiten-Cache). Um sicherzustellen, dass die Daten auf das Medium geschrieben sind, muss der Systemaufruf nach dem Schreiben aktiviert werden. fdatasync — genau so verfährt etcd (wie im folgenden Output zu sehen ist strace; hier 8 — der WAL-Dateideskriptor):

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 dauert die Speicherung im persistenten Speicher eine gewisse Zeit. Eine verzögerte Ausführung des Aufrufs fdatasync kann die Leistung von etcd beeinträchtigen. In der Dokumentation des Speichers angegeben, wird angegeben, dass für eine ausreichende Leistung der 99. Perzentil der Dauer aller Aufrufe fdatasync zum Schreiben in die WAL-Datei weniger als 10 ms betragen sollte. Es gibt auch andere Kennzahlen im Zusammenhang mit dem Speicher, aber in diesem Artikel wird genau diese behandelt.

Bewertung des Speichers mit fio.

Um zu beurteilen, ob ein bestimmter Speicher für die Verwendung mit etcd geeignet ist, kann das Tool verwendet werden. fio — beliebtem I/O-Tester. Beachten Sie, dass die Festplatten-ein- und -ausgabe unterschiedlich erfolgen kann: sync/async, zahlreiche verschiedene Klassen von Systemaufrufen usw. Die Kehrseite ist, dass fio äußerst kompliziert in der Anwendung ist. Das Tool hat viele Parameter, und verschiedene Kombinationen ihrer Werte führen zu völlig unterschiedlichen Ergebnissen. Um eine sinnvolle Bewertung im Falle von etcd zu erhalten, müssen Sie sicherstellen, dass die Schreiblast, die von fio erzeugt wird, der Last von etcd beim Schreiben in die WAL-Dateien so nahe wie möglich kommt:

Das bedeutet, dass die generierte fio Last mindestens eine Reihe von sequenziellen Schreibvorgängen in eine Datei darstellen sollte, wobei jeder Schreibvorgang aus einem Systemaufruf besteht schreiben, gefolgt von fdatasync.
Um sequenzielles Schreiben zu aktivieren, müssen Sie das Flag angeben --rw=write.
Um fio schrieb mit Systemaufrufen schreiben (und nicht anderen Systemaufrufen — zum Beispiel, pwrite), verwenden Sie das Flag --ioengine=sync.
Schließlich garantiert das Flag --fdatasync=1 dass nach jedem schreiben sollte fdatasync.
Die beiden anderen Parameter in unserem Beispiel: --size und --bs — können je nach spezifischem Nutzungsszenario variieren. Im nächsten Abschnitt wird deren Konfiguration beschrieben.

Warum wir fio gewählt haben und woher wir wussten, wie man es konfiguriert

Diese Notiz entstand aus 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 Metriken von etcd zeigten viel zu hohe Latenzen fdatasync, selbst als der Cluster im Leerlauf war. Diese Metriken erschienen uns sehr fragwürdig, und wir waren uns nicht sicher, was genau sie repräsentierten. Außerdem bestand der Cluster aus virtuellen Maschinen, sodass wir nicht feststellen konnten, ob die Latenz mit der Virtualisierung oder den SSDs zusammenhing.

Außerdem betrachteten wir verschiedene Änderungen in der Hardware- und Softwarekonfiguration, sodass eine Möglichkeit zur Bewertung erforderlich war. Natürlich hätten wir etcd in jeder Konfiguration ausführen und die entsprechenden Prometheus-Metriken betrachten können, aber das hätte erheblichen Aufwand erfordert. Wir benötigten einen einfachen Weg, um eine spezifische Konfiguration zu bewerten. Wir wollten unser Verständnis der von etcd gelieferten Prometheus-Metriken überprüfen.

Dafür mussten zwei Probleme gelöst werden:

Wie sieht zunächst die I/O-Last aus, die etcd beim Schreiben in die WAL-Dateien erzeugt? Welche Systemaufrufe werden verwendet? Wie groß sind die Schreibblöcke?
Zweitens, angenommen, wir haben die Antworten auf die oben genannten Fragen. Wie reproduzieren wir die entsprechende Last mit fio? Ведь fio — ein äußerst flexibles Tool mit einer Vielzahl von Optionen (das lässt sich leicht überprüfen, zum Beispiel, hier — Anm. d. Ü..

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

Mit Hilfe von lsof man kann alle von einem Prozess verwendeten Dateideskriptoren sowie die Dateien, auf die sie verweisen, anzeigen.
Mit Hilfe von strace man kann einen bereits laufenden Prozess analysieren oder einen Prozess starten und ihn beobachten. Der Befehl gibt alle Systemaufrufe aus, die von diesem Prozess und, wenn nötig, seinen Nachkommen durchgeführt wurden. Letzteres ist wichtig für Prozesse, die geforkt werden, und etcd ist einer dieser Prozesse.

Das erste, was wir gemacht haben, ist, strace um den etcd-Server im Kubernetes-Cluster zu untersuchen, während er im Leerlauf war.

Dabei wurde festgestellt, dass die Schreibblöcke in der WAL sehr eng gruppiert sind, die Größe der meisten lag im Bereich von 2200 bis 2400 Bytes. Deshalb wird in dem Befehl zu Beginn dieses Artikels das Flag --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 strace Ihre etcd-Prozesse, um aktuelle Werte zu erhalten.

Um dann ein klares und umfassendes Bild von der Funktionsweise von etcd mit dem Dateisystem zu erhalten, haben wir es unter strace mit den Flags -ffttTausgeführt. Dies ermöglichte es, die Nachfolgeprozesse zu erfassen und die Ausgabe jedes in eine separate Datei zu schreiben. Darüber hinaus wurden detaillierte Informationen über den Startzeitpunkt und die Dauer jedes Systemaufrufs erhalten.

Wir haben auch den Befehl lsofverwendet, um unser Verständnis der Ausgabe zu bestätigen strace hinsichtlich, welcher Dateideskriptor für welchen Zweck verwendet wurde. Es entstand eine Ausgabe strace, die der oben dargestellten ähnelt. Statistische Manipulationen mit den Synchronisationszeiten bestätigten, dass der Metrik wal_fsync_duration_seconds von etcd den Aufrufen entsprach fdatasync mit den Dateideskriptoren der WAL-Dateien.

Um mit zu generieren fio Die Arbeitslast, die mit der von etcd vergleichbar ist, wurde die Dokumentation des Tools studiert und die für unsere Aufgabe passenden Parameter ausgewählt. Wir haben sichergestellt, dass die erforderlichen Systemaufrufe verwendet werden, und deren Dauer bestätigt, indem wir fio aus strace (wie es im Fall von etcd gemacht wurde).

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

Da uns das Perzentil interessierte, strebten wir an, dass die Anzahl der Proben ausreichend groß für statistische Signifikanz ist. Und wir entschieden, dass 10^4 (was einer Größe von 22 MB entspricht) ausreichend sein würde. Kleinere Werte des Parameters --size führten zu stärkerem Rauschen (zum Beispiel Aufrufe fdatasync, die viel länger dauern als gewöhnlich und das 99. Perzentil beeinflussen).

Es liegt an Ihnen

In dem Artikel wird gezeigt, wie man mit Hilfe von fio einschätzen kann, ob ein ausreichend schnelles Medium für die Nutzung mit etcd geeignet ist. Jetzt liegt es an Ihnen! Virtuelle Maschinen mit SSD-basiertem Speicher können im Service IBM Cloud.

P.S. vom Übersetzer

Mit fertigen Anwendungsbeispielen fio für die Lösung anderer Aufgaben können Sie in Dokumentation oder direkt in Projekt-Repository (dort sind viel mehr präsentiert als in der Dokumentation erwähnt).

P.P.S. vom Übersetzer

Lesen Sie auch in unserem Blog:

Quelle: habr.com