Eine kurze Geschichte über fio und etcd.
Die Leistung des Clusters hängt stark von der Leistung seines Speichers ab. etcd exportiert einige Metriken in , um die erforderlichen Informationen über die Speicherleistung bereitzustellen. Zum Beispiel die Metrik wal_fsync_duration_seconds. : Damit der Speicher als schnell genug gilt, muss der 99. Perzentil dieser Metrik unter 10 ms liegen. Wenn Sie planen, einen etcd-Cluster auf Linux-Maschinen auszuführen und einschätzen möchten, ob Ihr Speicher schnell genug ist (z.B. SSD), können Sie verwenden — ein beliebtes Tool zum Testen von Ein-/Ausgabe-Operationen. Führen Sie den folgenden Befehl aus, wobei test-data das Verzeichnis am Speicheranschlusspunkt ist:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestSie müssen nur die Ergebnisse ansehen und überprüfen, ob der 99. Perzentil der Dauer unter 10 ms liegt. Wenn ja, haben Sie einen ausreichend schnellen Speicher. Hier ist ein Beispiel für die Ergebnisse:
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]Anmerkungen
- Wir haben die Parameterwerte —size und —bs für unser spezifisches Szenario angepasst. Um von fio nützliche Ergebnisse zu erhalten, geben Sie Ihre Werte an. Woher bekommen Sie diese? Lesen Sie, .
- Während des Tests kommt die gesamte Ein-/Auslastung von fio. In einem realen Szenario werden wahrscheinlich auch andere Schreibanfragen an den Speicher gerichtet, die nichts mit der wal_fsync_duration_seconds zu tun haben. Zusätzliche Last wird den Wert von wal_fsync_duration_seconds erhöhen. Wenn der 99. Perzentil also fast 10 ms erreicht, ist Ihr Speicher nicht schnell genug.
- Verwenden Sie die Version nicht unter 3.5 (frühere Versionen zeigen keine Perzentile für die Dauer von fdatasync an).
- Oben wurde nur ein Ausschnitt der Ergebnisse von fio gezeigt.
Eine lange Geschichte über fio und etcd.
Was ist WAL in etcd?
Normalerweise verwenden Datenbanken ; etcd verwendet es ebenfalls. Hier werden wir das Write-Ahead-Log (WAL) nicht im Detail besprechen. Es genügt zu wissen, dass jedes Mitglied des etcd-Clusters es in einem persistenten Speicher führt. etcd protokolliert jede Operation mit Schlüssel-Wert-Paaren (zum Beispiel Aktualisierungen) im WAL, bevor diese im Speicher angewendet werden. Wenn ein Mitglied des Speichers zwischen den Snapshots abstürzt und neu startet, kann es die Transaktionen lokal anhand des Inhalts des WAL seit dem letzten Snapshot wiederherstellen.
Wenn ein Client einen Schlüssel im Speicher der Schlüssel-Wert-Paare hinzufügt oder den Wert eines bestehenden Schlüssels aktualisiert, wird diese Operation im WAL protokolliert, das eine normale Datei im persistenten Speicher darstellt. Bevor das Verfahren fortgesetzt wird, muss etcd davon vollständig überzeugt sein, dass der Eintrag im WAL tatsächlich erfolgt ist. Unter Linux reicht dazu ein einziger Systemaufruf nicht aus , da die physische Speicherung tatsächlich verzögert werden kann. Beispielsweise kann Linux eine Weile den WAL-Eintrag im Kernel-Speichercache (wie im Seiten-Cache) halten. Um sicherzustellen, dass die Daten tatsächlich im persistenten Speicher gespeichert sind, ist ein Systemaufruf fdatasync nach dem Schreiben erforderlich, und genau das nutzt etcd (wie in den Ergebnissen zu sehen ist , wobei 8 der Dateideskriptor des WAL ist):
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) = 0Leider erfolgt die Speicherung im persistenten Speicher nicht sofort. Wenn der Aufruf von fdatasync langsam ist, sinkt die Leistung des etcd-Systems. , dass der Speicher als ausreichend schnell gilt, wenn in 99 Prozent der Fälle die Aufrufe von fdatasync zur Speicherung in der WAL-Datei weniger als 10 ms dauern. Es gibt weitere nützliche Metriken für den Speicher, aber in diesem Beitrag sprechen wir nur über diese Metrik.
Bewertung des Speichers mit fio
Wenn Sie bewerten möchten, ob Ihr Speicher für etcd geeignet ist, verwenden Sie fio – ein sehr beliebtes Werkzeug für Lasttests bei Ein- und Ausgabe. Es ist zu beachten, dass Festplattenoperationen sehr unterschiedlich sein können: synchron und asynchron, viele Klassen von Systemaufrufen usw. Folglich ist fio relativ kompliziert zu verwenden. Es verfügt über viele Parameter, und verschiedene Kombinationen ihrer Werte ergeben ganz unterschiedliche Ein- und Auslastungen. Um angemessene Zahlen für etcd zu erhalten, sollte sichergestellt werden, dass die Testlast von fio in der Schreibweise so nah wie möglich an der realen Last von etcd beim Schreiben von WAL-Dateien ist.
Daher sollte fio mindestens eine Last in Form einer Serie von sequenziellen Schreiboperationen in eine Datei erzeugen, wobei jeder Schreibvorgang aus einem Systemaufruf bestehen wird , gefolgt von dem Systemaufruf fdatasync. Für sequenzielle Schreibvorgänge benötigt fio den Parameter —rw=write. Damit fio beim Schreiben den Systemaufruf write und nicht , sollte der Parameter —ioengine=sync angegeben werden. Schließlich muss der Parameter —fdatasync=1 hinzugefügt werden, um nach jedem Schreiben fdatasync aufzurufen. Die beiden anderen Parameter in diesem Beispiel (—size und —bs) hängen vom spezifischen Szenario ab. Im nächsten Abschnitt erklären wir, wie man sie anpasst.
Warum fio und wie wir gelernt haben, es zu konfigurieren
In diesem Beitrag beschreiben wir einen echten Fall. Wir hatten einen Cluster v1.13, den wir mit Prometheus überwacht haben. etcd v3.2.24 lief auf SSD. Die Metriken für etcd zeigten zu hohe Latenzen für fdatasync, selbst wenn der Cluster nichts tat. Die Metriken waren seltsam, und wir wussten nicht genau, was sie bedeuteten. Der Cluster bestand aus virtuellen Maschinen, und wir mussten herausfinden, wo das Problem lag: bei den physischen SSDs oder im Virtualisierungsschicht. Außerdem haben wir häufig Änderungen an der Hardware- und Softwarekonfiguration vorgenommen, und wir benötigten eine Möglichkeit, deren Auswirkungen zu bewerten. Wir konnten etcd in jeder Konfiguration starten und die Metriken von Prometheus beobachten, aber das war zu umständlich. Wir suchten nach einer relativ einfachen Möglichkeit, eine bestimmte Konfiguration zu bewerten. Wir wollten überprüfen, ob wir die Metriken von Prometheus von etcd richtig verstanden.
Aber dafür mussten zwei Probleme gelöst werden. Erstens, wie sieht die Eingabe-/Ausgabebelastung aus, die etcd beim Schreiben in das WAL erzeugt? Welche Systemaufrufe werden verwendet? Wie groß sind die Einträge? Zweitens, wenn wir diese Fragen beantworten, wie können wir eine ähnliche Arbeitslast mit fio reproduzieren? Vergessen Sie nicht, dass fio ein sehr flexibles Tool mit vielen Parametern ist. Wir haben beide Probleme mit einem Ansatz gelöst – durch Befehle. und . lsof zeigt alle von einem Prozess verwendeten Dateideskriptoren und die zugehörigen Dateien an. Mit strace kann man entweder einen bereits laufenden Prozess untersuchen oder einen Prozess starten und ihn analysieren. strace gibt alle Systemaufrufe des untersuchten Prozesses (und seiner Kindprozesse) aus. Letzteres ist sehr wichtig, da etcd genau diesen Ansatz anwendet.
Zunächst haben wir strace verwendet, um den etcd-Server für Kubernetes zu untersuchen, als keine Last auf dem Cluster war. Wir sahen, dass fast alle WAL-Einträge ungefähr gleich groß waren: 2200–2400 Bytes. Deshalb haben wir in der Befehlszeile zu Beginn diesen Parameter angegeben —bs=2300 (bs steht für die Größe in Bytes für jeden fio-Eintrag). Beachten Sie, dass die Größe des etcd-Eintrags von der Version des etcd, der Bereitstellung, den Parameterwerten usw. abhängt und die Dauer von fdatasync beeinflusst. Wenn Sie ein ähnliches Szenario haben, untersuchen Sie Ihre etcd-Prozesse mit strace, um die genauen Zahlen zu erfahren.
Um einen guten Eindruck von den Aktionen im Dateisystem von etcd zu bekommen, haben wir es mit strace und den Parametern -ffttT gestartet. So versuchten wir, die Kindprozesse zu untersuchen und die Ausgaben jedes einzelnen in einer separaten Datei zu speichern, und außerdem detaillierte Berichte über den Beginn und die Dauer jedes Systemaufrufs zu erhalten. Wir verwendeten lsof, um unsere Analyse der strace-Ausgaben zu bestätigen und zu sehen, welcher Dateideskriptor für welche Zwecke verwendet wurde. So erhielten wir mit strace die oben gezeigten Ergebnisse. Die Statistiken zur Synchronisationszeit bestätigten, dass der Indikator wal_fsync_duration_seconds von etcd den Aufrufen von fdatasync mit den WAL-Dateideskriptoren entspricht.
Wir haben die Dokumentation zu fio studiert und Parameter für unser Szenario ausgewählt, damit fio eine Last generiert, die mit der von etcd vergleichbar ist. Außerdem haben wir die Systemaufrufe und ihre Dauer überprüft, indem wir fio über strace gestartet haben, ähnlich wie bei etcd.
Wir haben sorgfältig den Parameter –size ausgewählt, der die gesamte Ein- und Auslastung von fio darstellt. In unserem Fall ist dies die Gesamtzahl der Bytes, die im Speicher geschrieben werden. Es stellte sich heraus, dass es proportional zur Anzahl der Systemaufrufe von write (und fdatasync) war. Für einen bestimmten Wert von bs beträgt die Anzahl der Aufrufe von fdatasync = size/bs. Da uns das Perzentil interessierte, mussten wir genügend Proben für die Zuverlässigkeit haben, und wir haben berechnet, dass uns 10^4 (also 22 Mebibyte) ausreichen würden. Wenn –size kleiner ist, können Ausreißer auftreten (zum Beispiel dauern einige Aufrufe von fdatasync länger als gewöhnlich und beeinflussen das 99. Perzentil).
Versuchen Sie es selbst
Wir haben gezeigt, wie man fio verwendet und herausfindet, ob der Speicher ausreichend Geschwindigkeit für eine hohe Leistung von etcd hat. Jetzt können Sie dies selbst praktisch ausprobieren, beispielsweise mit virtuellen Maschinen, die über SSD-Speicher verfügen. .
Quelle: habr.com
