Eine Kurzgeschichte über Fio und etcd
Clusterleistung hängt weitgehend von der Leistung seines Speichers ab. etcd exportiert einige Metriken nach um die gewünschten Informationen zur Speicherleistung bereitzustellen. Zum Beispiel die Metrik wal_fsync_duration_seconds. : Damit die Speicherung als schnell genug gilt, muss das 99. Perzentil dieser Metrik weniger als 10 ms betragen. Wenn Sie planen, einen etcd-Cluster auf Linux-Rechnern auszuführen und prüfen möchten, ob Ihr Speicher schnell genug ist (z. B. SSD), können Sie ihn verwenden ist ein beliebtes Tool zum Testen von E/A-Vorgängen. Führen Sie den folgenden Befehl aus, wobei test-data das Verzeichnis unter dem Speicher-Mount-Punkt ist:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestSie müssen sich nur die Ergebnisse ansehen und überprüfen, ob das 99. Perzentil der Dauer vorliegt weniger als 10 ms. Wenn ja, verfügen Sie über einen einigermaßen schnellen Speicher. Hier ist ein Beispiel der Ergebnisse:
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]Aufzeichnungen
- Wir haben die Optionen --size und --bs für unser spezielles Szenario angepasst. Um ein nützliches Ergebnis von fio zu erhalten, geben Sie Ihre eigenen Werte an. Wo bekommt man sie? Lesen .
- Während des Tests kommt die gesamte E/A-Last von FIO. In einem realen Szenario werden neben den mit wal_fsync_duration_seconds verbundenen Schreibanforderungen wahrscheinlich auch andere Schreibanforderungen in den Speicher eingehen. Die zusätzliche Last erhöht den Wert von wal_fsync_duration_seconds. Wenn also das 99. Perzentil nahe bei 10 ms liegt, geht Ihrem Speicher die Geschwindigkeit aus.
- Nimm die Version nicht weniger als 3.5 (Die vorherigen zeigen keine Perzentile für die fdatasync-Dauer an).
- Oben ist nur ein Ausschnitt der Ergebnisse von fio.
Lange Geschichte über Fio und etcd
Was ist WAL in etcd
Normalerweise werden Datenbanken verwendet ; etcd verwendet es auch. Wir werden hier nicht im Detail auf das Write-Ahead-Protokoll (WAL) eingehen. Für uns reicht es aus zu wissen, dass jedes Mitglied des etcd-Clusters es im dauerhaften Speicher verwaltet. etcd schreibt jeden Schlüsselwertvorgang (z. B. eine Aktualisierung) in WAL, bevor er ihn auf den Store anwendet. Wenn eines der Speichermitglieder zwischen den Snapshots abstürzt und neu startet, kann es Transaktionen seit dem letzten Snapshot lokal anhand des WAL-Inhalts wiederherstellen.
Wenn ein Client einen Schlüssel zum Schlüsselwertspeicher hinzufügt oder den Wert eines vorhandenen Schlüssels aktualisiert, zeichnet etcd den Vorgang in WAL auf, einer regulären Datei im persistenten Speicher. etcd MUSS völlig sicher sein, dass der WAL-Eintrag tatsächlich erfolgt ist, bevor mit der Verarbeitung fortgefahren wird. Unter Linux reicht hierfür ein Systemaufruf nicht aus. , da das eigentliche Schreiben auf den physischen Speicher verzögert werden kann. Beispielsweise kann Linux einen WAL-Eintrag für einige Zeit in einem Cache im Kernel-Speicher (z. B. einem Seiten-Cache) speichern. Und damit die Daten korrekt in den persistenten Speicher geschrieben werden, ist nach dem Schreiben der Systemaufruf fdatasync erforderlich, und etcd verwendet ihn einfach (wie Sie im Ergebnis der Arbeit sehen können). , wobei 8 der WAL-Dateideskriptor ist):
21:23:09.894875 lseek(8, 0, SEEK_CUR) = 12808 <0.000012>
21:23:09.894911 write(8, ". 20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8) = 0 <0.008314>Leider erfolgt das Schreiben in den persistenten Speicher nicht sofort. Wenn der fdatasync-Aufruf langsam ist, leidet die Leistung des etcd-Systems. dass der Speicher als schnell genug gilt, wenn fdatasync-Aufrufe im 99. Perzentil weniger als 10 ms zum Schreiben in die WAL-Datei benötigen. Es gibt noch weitere nützliche Kennzahlen für die Speicherung, aber in diesem Beitrag geht es nur um diese Kennzahl.
Speicher mit FIO schätzen
Wenn Sie beurteilen müssen, ob Ihr Speicher für etcd geeignet ist, verwenden Sie fio, ein sehr beliebtes Tool zum Testen der I/O-Last. Es sollte beachtet werden, dass Festplattenoperationen sehr unterschiedlich sein können: synchron und asynchron, viele Klassen von Systemaufrufen usw. Daher ist FIO ziemlich schwierig zu verwenden. Es verfügt über viele Parameter und unterschiedliche Kombinationen ihrer Werte führen zu sehr unterschiedlichen E/A-Arbeitslasten. Um angemessene Zahlen für etcd zu erhalten, sollten Sie sicherstellen, dass die Testschreiblast von fio beim Schreiben von WAL-Dateien möglichst nahe an der tatsächlichen Last von etcd liegt.
Daher sollte fio mindestens eine Last aus einer Reihe aufeinanderfolgender Schreibvorgänge in die Datei erzeugen, wobei jeder Schreibvorgang aus einem Systemaufruf besteht gefolgt vom fdatasync-Systemaufruf. Sequentielle Schreibvorgänge in FIO erfordern die Option --rw=write. Damit fio beim Schreiben den Systemaufruf write verwendet, anstatt , sollten Sie den Parameter --ioengine=sync angeben. Um fdatasync nach jedem Schreibvorgang aufzurufen, müssen Sie schließlich den Parameter --fdatasync=1 hinzufügen. Die anderen beiden Optionen in diesem Beispiel (--size und -bs) sind skriptspezifisch. Im nächsten Abschnitt zeigen wir Ihnen, wie Sie diese einrichten.
Warum Fio und wie wir gelernt haben, es einzurichten
In diesem Beitrag beschreiben wir einen realen Fall. Wir haben einen Cluster v1.13, die wir mit Prometheus überwacht haben. etcd v3.2.24 wurde auf einer SSD gehostet. Etcd-Metriken zeigten zu hohe fdatasync-Latenzen, selbst wenn der Cluster nichts tat. Die Messwerte waren seltsam und wir wussten nicht wirklich, was sie bedeuteten. Da der Cluster aus virtuellen Maschinen bestand, musste man verstehen, wo das Problem lag: in physischen SSDs oder in der Virtualisierungsschicht. Darüber hinaus haben wir häufig Änderungen an der Hardware- und Softwarekonfiguration vorgenommen und benötigten eine Möglichkeit, deren Ergebnisse auszuwerten. Wir könnten etcd in jeder Konfiguration ausführen und uns die Prometheus-Metriken ansehen, aber das wäre zu aufwändig. Wir suchten nach einer relativ einfachen Möglichkeit, eine bestimmte Konfiguration zu bewerten. Wir wollten überprüfen, ob wir Prometheus-Metriken von etcd richtig verstehen.
Dafür mussten jedoch zwei Probleme gelöst werden. Erstens: Wie sieht die I/O-Last aus, die etcd beim Schreiben in WAL erzeugt? Welche Systemaufrufe werden verwendet? Wie groß sind die Datensätze? Zweitens: Wenn wir diese Fragen beantworten, wie können wir mit FIO eine ähnliche Arbeitslast reproduzieren? Vergessen Sie nicht, dass Fio ein sehr flexibles Tool mit vielen Optionen ist. Wir haben beide Probleme mit einem Ansatz gelöst – mit den Befehlen и . lsof listet alle vom Prozess verwendeten Dateideskriptoren und die zugehörigen Dateien auf. Und mit Strace können Sie einen bereits laufenden Prozess untersuchen oder einen Prozess starten und ihn untersuchen. strace gibt alle Systemaufrufe des untersuchten Prozesses (und seiner untergeordneten Prozesse) aus. Letzteres ist sehr wichtig, da etcd einen ähnlichen Ansatz verfolgt.
Wir haben Strace zum ersten Mal verwendet, um den etcd-Server für Kubernetes zu erkunden, als der Cluster nicht ausgelastet war. Wir haben gesehen, dass fast alle WAL-Datensätze ungefähr die gleiche Größe hatten: 2200–2400 Bytes. Daher haben wir im Befehl am Anfang des Beitrags den Parameter -bs=2300 angegeben (bs bedeutet die Größe in Bytes für jeden FIO-Eintrag). Beachten Sie, dass die Größe des etcd-Eintrags von der etcd-Version, Verteilung, Parameterwerten usw. abhängt und sich auf die fdatasync-Dauer auswirkt. Wenn Sie ein ähnliches Szenario haben, untersuchen Sie Ihre etcd-Prozesse mit strace, um die genauen Zahlen herauszufinden.
Um eine gute Vorstellung davon zu bekommen, was das etcd-Dateisystem tut, haben wir es dann mit strace und den Optionen -ffttT gestartet. Deshalb haben wir versucht, die untergeordneten Prozesse zu untersuchen und die Ausgabe jedes einzelnen Prozesses in einer separaten Datei aufzuzeichnen sowie detaillierte Berichte über den Start und die Dauer jedes Systemaufrufs zu erhalten. Wir haben lsof verwendet, um unsere Analyse der Strace-Ausgabe zu bestätigen und zu sehen, welcher Dateideskriptor für welchen Zweck verwendet wurde. Mit Hilfe von Strace wurden die oben gezeigten Ergebnisse erzielt. Statistiken zur Synchronisierungszeit bestätigten, dass wal_fsync_duration_seconds von etcd mit fdatasync-Aufrufen mit WAL-Dateideskriptoren übereinstimmt.
Wir haben die Dokumentation für fio durchgesehen und Optionen für unser Skript ausgewählt, damit fio eine Last ähnlich wie etcd generiert. Wir haben auch Systemaufrufe und deren Dauer überprüft, indem wir fio von Strace aus ausgeführt haben, ähnlich wie etcd.
Wir haben den Wert des Parameters --size sorgfältig ausgewählt, um die gesamte E/A-Last von fio darzustellen. In unserem Fall ist dies die Gesamtzahl der in den Speicher geschriebenen Bytes. Es stellte sich heraus, dass es direkt proportional zur Anzahl der Schreib- (und fdatasync-)Systemaufrufe war. Für einen bestimmten Wert von bs ist die Anzahl der fdatasync-Aufrufe = Größe/bs. Da uns das Perzentil interessierte, mussten wir zur Sicherheit genügend Stichproben haben, und wir haben berechnet, dass 10^4 für uns ausreichen würden (das sind 22 Mebibyte). Wenn --size kleiner ist, können Ausreißer auftreten (z. B. dauern mehrere fdatasync-Aufrufe länger als gewöhnlich und wirken sich auf das 99. Perzentil aus).
Probieren Sie es aus
Wir haben Ihnen gezeigt, wie Sie fio verwenden und sehen, ob der Speicher schnell genug ist, damit etcd eine gute Leistung erbringt. Jetzt können Sie es selbst ausprobieren, beispielsweise mit virtuellen Maschinen mit SSD-Speicher .
Source: habr.com