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 zu starten und beurteilen möchten, ob Ihr Speicher schnell genug ist (zum Beispiel SSD), können Sie — ein beliebtes Tool zur Testung von Ein- und Ausgabeoperationen. Führen Sie den folgenden Befehl aus, wobei test-data das Verzeichnis unter dem Speicheranschlusspunkt ist:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestSie müssen nur die Ergebnisse betrachten und überprüfen, ob der 99. Perzentil der Dauer von 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]Hinweise
- Wir haben die Parameterwerte —size und —bs für unser spezifisches Szenario eingestellt. Um nützliche Ergebnisse von fio zu erhalten, geben Sie Ihre Werte an. Woher bekommen Sie diese? Lesen Sie, .
- Während des Tests erfolgt die gesamte I/O-Last von fio. In einem realen Szenario werden mit hoher Wahrscheinlichkeit auch andere Schreibanforderungen an den Speicher gesendet, neben denen, die mit wal_fsync_duration_seconds zusammenhängen. Zusätzliche Last erhöht den Wert von wal_fsync_duration_seconds. Wenn also der 99. Perzentil fast 10 ms erreicht hat, hat Ihr Speicher nicht die erforderliche Geschwindigkeit.
- Verwenden Sie eine Version nicht unter 3,5 (frühere Versionen zeigen keine Perzentile der fdatasync-Dauer an).
- Oben ist nur ein Auszug der Ergebnisse von fio gezeigt.
Eine lange Geschichte über fio und etcd
Was ist WAL in etcd
Normalerweise verwenden Datenbanken ; etcd verwendet dies ebenfalls. Hier werden wir nicht im Detail auf das Write-Ahead-Log (WAL) eingehen. Es reicht 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 Updates) im WAL, bevor sie im Speicher angewendet wird. Wenn zwischen Snapshots eines der Speicher-Mitglieder unerwartet abstürzt und neu gestartet wird, kann es lokale Transaktionen seit dem letzten Snapshot anhand des Inhalts des WAL wiederherstellen.
Wenn ein Client einen Schlüssel zum Schlüssel-Wert-Speicher hinzufügt oder den Wert eines bestehenden Schlüssels aktualisiert, protokolliert etcd diese Operation im WAL, das eine normale Datei im persistenten Speicher darstellt. Bevor die Verarbeitung fortgesetzt wird, MUSS etcd sich absolut sicher sein, dass der Eintrag im WAL tatsächlich erfolgt ist. Unter Linux reicht dafür nicht ein einziger Systemaufruf aus. , da der tatsächliche Schreibvorgang im physischen Speicher verzögert werden kann. Zum Beispiel kann Linux eine Weile die WAL-Aufzeichnung im Cache des Kernel-Speichers (z. B. im Seitencache) aufbewahren. Um sicherzustellen, dass die Daten korrekt in den permanenten Speicher geschrieben werden, ist ein Systemaufruf fdatasync nach dem Schreiben erforderlich, und genau das verwendet etcd (wie aus der Ausführung ersichtlich ist. , wobei 8 der Dateideskriptor von 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 permanenten Speicher nicht sofort. Wenn der Aufruf von fdatasync langsam ist, beeinträchtigt dies die Leistung des etcd-Systems. , dass der Speicher als ausreichend schnell angesehen wird, wenn im 99. Perzentil der Aufrufe von fdatasync beim Schreiben in die WAL-Datei weniger als 10 ms benötigt werden. Es gibt auch andere nützliche Metriken für den Speicher, aber in diesem Beitrag sprechen wir nur über diese Metrik.
Bewertung des Speichers mit fio
Wenn Sie überprüfen möchten, ob Ihr Speicher für etcd geeignet ist, verwenden Sie fio — ein sehr beliebtes Tool zum Testen der Eingabe-/Ausgabe-Last. Es ist wichtig zu beachten, dass es viele verschiedene Arten von Festplattenoperationen gibt: synchron und asynchron, sowie zahlreiche Klassen von Systemaufrufen usw. Daher ist die Verwendung von fio ziemlich komplex. Es bietet viele Parameter, und verschiedene Kombinationen dieser Werte ergeben völlig unterschiedliche Eingabe-/Ausgabebelastungen. Um vernünftige Zahlen für etcd zu erhalten, sollten Sie sicherstellen, dass die Schreiblast von fio so nah wie möglich an der realen Last von etcd beim Schreiben von WAL-Dateien liegt.
Daher sollte fio mindestens eine Last in Form einer Reihe von aufeinanderfolgenden Schreiboperationen in eine Datei erzeugen, wobei jeder Schreibvorgang aus einem Systemaufruf besteht , gefolgt von einem Systemaufruf fdatasync. Für aufeinanderfolgende Schreiboperationen benötigt fio den Parameter —rw=write. Damit fio beim Schreiben den Systemaufruf write anstelle von , geben Sie den Parameter —ioengine=sync an. Schließlich müssen Sie, um nach jedem Schreibvorgang fdatasync aufzurufen, den Parameter —fdatasync=1 hinzufügen. Die beiden anderen Parameter in diesem Beispiel (—size und —bs) hängen von dem spezifischen Szenario ab. Im nächsten Abschnitt erklären wir, wie sie konfiguriert werden können.
Warum genau fio und wie wir gelernt haben, es zu konfigurieren
In diesem Beitrag beschreiben wir einen realen Fall. Wir hatten ein Cluster v1.13, das wir mit Prometheus überwacht haben. etcd v3.2.24 war auf SSD platziert. Die Metriken von etcd zeigten zu hohe Latenzen für fdatasync, selbst wenn das Cluster keine Arbeit verrichtete. Die Metriken waren seltsam, und wir wussten nicht genau, was sie bedeuteten. Das Cluster bestand aus virtuellen Maschinen, und wir mussten verstehen, wo das Problem lag: an den physischen SSDs oder in der Virtualisierungsschicht. Zudem änderten wir häufig die Hardware- und Softwarekonfiguration, und wir benötigten eine Möglichkeit, deren Ergebnisse zu bewerten. Wir konnten etcd in jeder Konfiguration starten und die Prometheus-Metriken beobachten, aber das war zu mühsam. Wir suchten nach einer ausreichend einfachen Möglichkeit, eine spezifische Konfiguration zu bewerten. Wir wollten überprüfen, ob wir die Prometheus-Metriken von etcd richtig verstehen.
Um dies zu erreichen, mussten wir zwei Probleme lösen. Erstens, wie sieht die I/O-Last 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 reproduzieren wir eine ähnliche Arbeitslast mit fio? Vergessen Sie nicht, dass fio ein äußerst 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 einen bereits laufenden Prozess untersuchen oder einen neuen Prozess starten und analysieren. strace gibt alle Systemaufrufe des analysierten Prozesses (und seiner Kindprozesse) aus. Letzteres ist sehr wichtig, da etcd genau diesen Ansatz verwendet.
Zuerst haben wir strace verwendet, um den etcd-Server für Kubernetes zu untersuchen, als der Cluster keine Last hatte. Wir stellten fest, dass fast alle WAL-Einträge etwa gleich groß waren: 2200–2400 Byte. Daher haben wir im obigen Team den Parameter —bs=2300 angegeben (bs steht für die Größe in Byte 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 ein besseres Verständnis der Aktionen im Dateisystem von etcd zu gewinnen, haben wir es mit strace und den Parametern -ffttT ausgeführt. Auf diese Weise versuchten wir, Kindprozesse zu untersuchen und die Ausgaben jedes einzelnen in eine separate Datei zu schreiben, sowie detaillierte Berichte über den Beginn und die Dauer jedes Systemaufrufs zu erhalten. Wir verwendeten lsof, um unsere Analyse der strace-Ausgabe zu bestätigen und zu sehen, welcher Dateideskriptor für welche Zwecke verwendet wurde. Die Ergebnisse, die wir mit strace erhalten haben, sind oben dargestellt. Die Statistik zur Synchronisationszeit bestätigte, dass der Wert von wal_fsync_duration_seconds aus etcd den Aufrufen von fdatasync mit den Dateideskriptoren des WAL entspricht.
Wir haben die Dokumentation zu fio durchgesehen und die Parameter für unser Szenario ausgewählt, damit fio eine ähnliche Last wie etcd erzeugt. Außerdem haben wir die Systemaufrufe und deren Dauer überprüft, indem wir fio über strace ausgeführt haben, ähnlich wie bei etcd.
Wir haben die Bedeutung des Parameters —size sorgfältig ausgewählt, der die gesamte E/A-Belastung von fio darstellt. In unserem Fall handelt es sich um die Gesamtzahl der Bytes, die im Speicher geschrieben werden. Diese ist direkt proportional zur Anzahl der Systemaufrufe `write` (und `fdatasync`). Für einen bestimmten `bs`-Wert ist die Anzahl der Aufrufe von `fdatasync` = size/bs. Da uns der Perzentil interessiert hat, mussten wir ausreichend Proben für die Genauigkeit haben, und wir haben geschätzt, dass 10^4 ausreichend sein würden (das ergibt 22 MiB). Wenn —size kleiner ist, können Ausreißer auftreten (zum Beispiel wenn einige `fdatasync`-Aufrufe länger als üblich benötigen und den 99. Perzentil beeinflussen).
Versuchen Sie es selbst
Wir haben gezeigt, wie man fio verwendet und herausfindet, ob der Speicher schnell genug für eine hohe Leistung von etcd ist. Jetzt können Sie dies selbst in der Praxis ausprobieren, zum Beispiel mit virtuellen Maschinen, die SSD-Speicher in .
Quelle: habr.com
