🥇So überprüfen Sie Festplatten mit FIO auf ausreichende Leistung für etcd

Notiz. übersetzen: Dieser Artikel ist das Ergebnis einer Mini-Recherche, die von IBM Cloud-Ingenieuren auf der Suche nach einer Lösung für ein reales Problem im Zusammenhang mit dem Betrieb der etcd-Datenbank durchgeführt wurde. Eine ähnliche Aufgabe war für uns relevant, jedoch kann der Verlauf der Überlegungen und Aktionen der Autoren in einem breiteren Kontext interessant sein.

Kurze Zusammenfassung des gesamten Artikels: fio und etcd

Die Leistung eines etcd-Clusters hängt stark von der Geschwindigkeit des zugrunde liegenden Speichers ab. etcd exportiert verschiedene Prometheus-Metriken, um die Leistung zu überwachen. Einer von ihnen ist wal_fsync_duration_seconds. In der Dokumentation für etcd sagtdass die Speicherung als schnell genug angesehen werden kann, wenn das 99. Perzentil dieser Metrik 10 ms nicht überschreitet …

Wenn Sie über die Einrichtung eines etcd-Clusters auf Linux-Rechnern nachdenken und prüfen möchten, ob Laufwerke (z. B. SSDs) schnell genug sind, empfehlen wir die Verwendung des beliebten I/O-Testers namens Gewinde. Es reicht aus, den folgenden Befehl auszuführen (Verzeichnis test-data muss sich in der gemounteten Partition des getesteten Laufwerks befinden):

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

Es bleibt nur noch, sich die Ausgabe anzusehen und zu prüfen, ob das 99. Perzentil passt fdatasync in 10 ms. Wenn ja, dann arbeitet Ihr Laufwerk schnell genug. Hier ist eine Beispielausgabe:

fsync/fdatasync/sync_file_range:
  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (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]

Ein paar Anmerkungen:

Im obigen Beispiel haben wir die Parameter angepasst --size и --bs für einen konkreten Fall. Um ein aussagekräftiges Ergebnis zu erhalten fioGeben Sie Werte an, die für Ihren Anwendungsfall geeignet sind. Wie man sie auswählt, wird weiter unten besprochen.
Nur während des Tests fio lädt das Festplattensubsystem. Im wirklichen Leben ist es wahrscheinlich, dass andere Prozesse auf die Festplatte schreiben (außer denen, die damit zusammenhängen). wal_fsync_duration_seconds). Diese zusätzliche Belastung kann zunehmen wal_fsync_duration_seconds. Mit anderen Worten, wenn das 99. Perzentil aus dem Test mit fio, nur etwas weniger als 10 ms, besteht eine gute Chance, dass die Speicherleistung nicht ausreicht.
Für den Test benötigen Sie die Version fio nicht weniger als 3.5, da ältere Versionen keine Ergebnisse aggregieren fdatasync in Form von Perzentilen.
Die obige Schlussfolgerung ist nur ein kleiner Auszug aus der allgemeinen Schlussfolgerung fio.

Mehr über fio und etcd

Ein paar Worte zu WALs usw

Im Allgemeinen werden Datenbanken verwendet proaktive Protokollierung (Write-Ahead-Protokollierung, WAL). etcd ist ebenfalls betroffen. Eine Diskussion von WAL würde den Rahmen dieses Artikels sprengen, aber für unsere Zwecke müssen Sie wissen, dass jedes etcd-Clustermitglied WAL im persistenten Speicher speichert. etcd schreibt einige Schlüsselwertspeichervorgänge (z. B. Aktualisierungen) in WAL, bevor sie ausgeführt werden. Wenn ein Knoten zwischen Snapshots abstürzt und neu startet, kann etcd Transaktionen seit dem vorherigen Snapshot basierend auf dem Inhalt der WAL wiederherstellen.

Jedes Mal, wenn ein Client dem KV-Speicher einen Schlüssel hinzufügt oder den Wert eines vorhandenen Schlüssels aktualisiert, fügt etcd die Beschreibung des Vorgangs zur WAL hinzu, bei der es sich um eine reguläre Datei im persistenten Speicher handelt. etcd MUSS zu 100 % sicher sein, dass der WAL-Eintrag tatsächlich gespeichert wurde, bevor Sie fortfahren. Um dies unter Linux zu erreichen, reicht es nicht aus, den Systemaufruf zu verwenden write, da der Schreibvorgang selbst auf das physische Medium verzögert sein kann. Beispielsweise kann Linux einen WAL-Eintrag für einige Zeit in einem speicherinternen Kernel-Cache (z. B. im Seiten-Cache) aufbewahren. Um sicherzustellen, dass die Daten auf das Medium geschrieben werden, muss nach dem Schreiben ein Systemaufruf aufgerufen werden fdatasync – genau das macht etcd (wie Sie in der folgenden Ausgabe sehen können). strace; Hier 8 - WAL-Dateideskriptor):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ".20210220361223255266632$1020103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

Leider dauert das Schreiben in den persistenten Speicher einige Zeit. Eine längere Ausführung von fdatasync-Aufrufen kann die Leistung von etcd beeinträchtigen. In der Repository-Dokumentation angezeigt wird, dass für eine ausreichende Leistung das 99. Perzentil der Dauer aller Anrufe erforderlich ist fdatasync beim Schreiben in eine WAL-Datei weniger als 10 ms dauerte. Es gibt noch andere Kennzahlen im Zusammenhang mit der Speicherung, aber dieser Artikel konzentriert sich auf diese.

Wertspeicher mit FIO bewerten

Mit dem Dienstprogramm können Sie beurteilen, ob ein bestimmter Speicher für die Verwendung mit etcd geeignet ist Gewinde – ein beliebter I/O-Tester. Bedenken Sie, dass Festplatten-E/A auf viele verschiedene Arten erfolgen kann: synchron/asynchron, viele verschiedene Systemaufrufklassen und so weiter. Die andere Seite der Medaille ist das fio äußerst schwierig zu bedienen. Das Dienstprogramm verfügt über viele Parameter und unterschiedliche Kombinationen ihrer Werte führen zu völlig unterschiedlichen Ergebnissen. Um eine vernünftige Schätzung für etcd zu erhalten, müssen Sie sicherstellen, dass die von fio generierte Schreiblast so nah wie möglich an der Schreiblast der WAL-Datei von etcd liegt:

Dies bedeutet, dass die erzeugte fio Der Ladevorgang sollte mindestens aus einer Reihe aufeinanderfolgender Schreibvorgänge in die Datei bestehen, wobei jeder Schreibvorgang aus einem Systemaufruf besteht writegefolgt von fdatasync.
Um sequentielles Schreiben zu ermöglichen, müssen Sie das Flag angeben --rw=write.
Dass fio schrieb mit Anrufen write (anstelle anderer Systemaufrufe – zum Beispiel pwrite), verwenden Sie die Flagge --ioengine=sync.
Endlich die Flagge --fdatasync=1 sorgt dafür, dass jeder write sollte fdatasync.
Die anderen beiden Parameter in unserem Beispiel sind: --size и --bs - kann je nach konkretem Anwendungsfall variieren. Im nächsten Abschnitt wird ihre Konfiguration beschrieben.

Warum wir uns für fio entschieden haben und wie wir gelernt haben, wie man es einrichtet

Diese Notiz stammt aus einem realen Fall, dem wir begegnet sind. Wir hatten einen Cluster auf Kubernetes v1.13 mit Überwachung auf Prometheus. Als Speicher für etcd v3.2.24 wurden SSDs verwendet. Etcd-Metriken zeigten zu hohe Latenzen fdatasync, auch wenn der Cluster im Leerlauf war. Für uns erschienen diese Kennzahlen sehr zweifelhaft und wir waren uns nicht sicher, was sie genau darstellten. Zudem bestand der Cluster aus virtuellen Maschinen, sodass nicht gesagt werden konnte, ob die Verzögerung auf die Virtualisierung oder die SSD zurückzuführen war.

Darüber hinaus haben wir verschiedene Änderungen in der Hardware- und Softwarekonfiguration in Betracht gezogen und brauchten daher eine Möglichkeit, diese zu bewerten. Natürlich wäre es möglich, etcd in jeder Konfiguration auszuführen und sich die entsprechenden Prometheus-Metriken anzusehen, aber das würde einen erheblichen Aufwand erfordern. Was wir brauchten, war eine einfache Möglichkeit, eine bestimmte Konfiguration zu bewerten. Wir wollten unser Verständnis der Prometheus-Metriken von etcd testen.

Dazu mussten zwei Probleme gelöst werden:

Erstens: Wie sieht die von etcd beim Schreiben in WAL-Dateien erzeugte E/A-Last aus? Welche Systemaufrufe werden verwendet? Wie groß sind die Datensatzblöcke?
Nehmen wir zweitens an, wir haben Antworten auf die oben genannten Fragen. So reproduzieren Sie die entsprechende Last mit fio? Letztendlich fio — äußerst flexibles Dienstprogramm mit einer Fülle von Parametern (Dies lässt sich leicht überprüfen, z. B. hier - ca. übersetzt).

Wir haben beide Probleme mit demselben befehlsbasierten Ansatz gelöst lsof и strace:

Mit lsof Sie können alle vom Prozess verwendeten Dateideskriptoren sowie die Dateien anzeigen, auf die sie verweisen.
Mit strace Sie können einen bereits laufenden Prozess analysieren oder einen Prozess ausführen und beobachten. Der Befehl zeigt alle von diesem Prozess getätigten Systemaufrufe und ggf. seine Nachkommen an. Letzteres ist wichtig für Prozesse, die forken, und etcd ist ein solcher Prozess.

Das erste, was wir taten, war zu verwenden strace um den etcd-Server im Kubernetes-Cluster zu untersuchen, während er inaktiv war.

So wurde festgestellt, dass WAL-Datensatzblöcke sehr dicht gruppiert sind und die Größe der Mehrheit im Bereich von 2200 bis 2400 Bytes liegt. Aus diesem Grund verwendet der Befehl am Anfang dieses Artikels das Flag --bs=2300 (bs ist die Größe in Bytes jedes Schreibblocks in fio).

Bitte beachten Sie, dass die Größe der etcd-Schreibblöcke je nach Version, Bereitstellung, Parameterwerten usw. variieren kann. - Es beeinflusst die Dauer fdatasync. Wenn Sie einen ähnlichen Anwendungsfall haben, analysieren Sie mit strace Ihre etcd-Prozesse, um aktuelle Werte zu erhalten.

Um eine klare und umfassende Vorstellung davon zu bekommen, wie etcd mit dem Dateisystem funktioniert, haben wir es dann von unten begonnen strace mit Fahnen -ffttT. Dadurch war es möglich, untergeordnete Prozesse zu erfassen und die Ausgabe jedes einzelnen Prozesses in eine separate Datei zu schreiben. Darüber hinaus wurden detaillierte Informationen über den Startzeitpunkt und die Dauer jedes Systemaufrufs eingeholt.

Wir haben den Befehl auch verwendet lsofum Ihr Verständnis der Ausgabe zu bestätigen strace in Bezug darauf, welcher Dateideskriptor für welchen Zweck verwendet wurde. Ich habe die Schlussfolgerung gezogen strace, ähnlich wie oben. Statistische Manipulationen mit Synchronisationszeiten bestätigten, dass die Metrik wal_fsync_duration_seconds von etcd entspricht Anrufen fdatasync mit WAL-Dateideskriptoren.

Mit generieren fio Bei einem ähnlichen Arbeitsaufwand wie bei etcd wurde die Dokumentation des Dienstprogramms untersucht und die für unsere Aufgabe geeigneten Parameter ausgewählt. Wir haben überprüft, ob die richtigen Systemaufrufe ausgeführt werden, und ihre Dauer durch Ausführen bestätigt fio von strace (wie es im Fall von etcd gemacht wurde).

Besonderes Augenmerk wurde auf die Bestimmung des Wertes des Parameters gelegt --size. Es stellt die gesamte vom FIO-Dienstprogramm generierte E/A-Last dar. In unserem Fall ist dies die Gesamtzahl der auf das Medium geschriebenen Bytes. Sie ist direkt proportional zur Anzahl der Anrufe write (Und fdatasync). Für einen bestimmten bs Anzahl der Anrufe fdatasync ist gleich size / bs.

Da uns das Perzentil interessierte, wollten wir, dass die Anzahl der Stichproben groß genug ist, um statistisch signifikant zu sein. Und das habe ich entschieden 10^4 (was einer Größe von 22 MB entspricht) reicht aus. Kleinere Parameterwerte --size gab stärkere Geräusche (z. B. Anrufe). fdatasync, die viel länger als üblich dauern und sich auf das 99. Perzentil auswirken).

Es liegt an Ihnen

Der Artikel zeigt die Verwendung fio Man kann beurteilen, ob das für die Verwendung mit etcd vorgesehene Medium schnell genug ist. Jetzt liegt es an Ihnen! Sie können virtuelle Maschinen mit SSD-basiertem Speicher im Dienst erkunden IBM Cloud.

PS vom Übersetzer

Mit vorgefertigten Anwendungsfällen fio Weitere Aufgaben finden Sie unter Dokumentation oder direkt an Projektrepositorys (Es gibt viel mehr davon als in der Dokumentation erwähnt).

PPS vom Übersetzer

Lesen Sie auch auf unserem Blog:

Source: habr.com

So überprüfen Sie Festplatten mit FIO auf ausreichende Leistung für etcd