Eine kurze Geschichte über Fio und etcd
Die Leistung des etcd- Clusters hängt weitgehend von der Leistung seines Speichers ab. etcd exportiert einige Metriken nach Prometheus , um die erforderlichen Informationen zur Speicherleistung bereitzustellen. Zum Beispiel die Metrik wal_fsync_duration_seconds. In der Dokumentation zu etcd heißt es : Damit der Speicher als schnell genug angesehen werden kann, sollte das 99. Perzentil dieser Metrik weniger als 10 ms betragen. Wenn Sie den etcd-Cluster auf Linux-Computern ausführen möchten und prüfen möchten, ob Ihr Speicher schnell genug ist (z. B. SSDs), können Sie fio verwenden , ein beliebtes Tool zum Testen von E / A-Vorgängen. Führen Sie den folgenden Befehl aus, wobei test-data das Verzeichnis unterhalb des Speicher-Mount-Punkts ist:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest
Sie müssen sich nur die Ergebnisse ansehen und sicherstellen , dass das 99. Perzentil der fdatasync- Dauer weniger als 10 ms beträgt. Wenn ja, haben Sie einen ziemlich schnellen Speicher. Hier ist ein Beispiel für die 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]
Anmerkungen
- Wir haben die Optionen --size und --bs für unser spezielles Szenario konfiguriert. Geben Sie Ihre Werte ein, um ein nützliches Ergebnis von fio zu erhalten. Wo bekommt man sie? Lesen Sie, wie wir gelernt haben, wie man fio konfiguriert .
- Während des Tests kommt die gesamte E / A-Last von fio. In einem realen Szenario werden wahrscheinlich andere Schreibanforderungen an das Repository gesendet, mit Ausnahme derjenigen, die sich auf wal_fsync_duration_seconds beziehen. Durch zusätzliches Laden wird der Wert von wal_fsync_duration_seconds erhöht. Wenn das 99. Perzentil also fast 10 ms erreicht hat, hat Ihr Speicher nicht genügend Geschwindigkeit.
- Nehmen Sie die fio- Version nicht niedriger als 3.5 (die vorherigen zeigen keine Perzentile der fdatasync-Dauer).
- Oben ist nur ein Ausschnitt der Ergebnisse von fio.
Eine lange Geschichte über Fio und etcd
Was ist WAL in etcd
Datenbanken verwenden normalerweise Write-Ahead-Protokolle . etcd benutzt es auch. Hier wird das WAL-Protokoll (Write-Ahead-Protokoll) nicht im Detail erläutert. Wir müssen nur wissen, dass jedes Mitglied des etcd-Clusters es in einem dauerhaften Speicher verwaltet. etcd schreibt jede Schlüssel-Wert-Paar-Operation (z. B. Aktualisierung) in die WAL, bevor sie auf das Repository angewendet wird. Wenn zwischen den Snapshots eines der Speichermitglieder abstürzt und neu gestartet wird, können Transaktionen aus dem letzten Snapshot mithilfe des WAL-Inhalts lokal wiederhergestellt werden.
Wenn ein Client einem Speicher von Schlüssel-Wert-Paaren einen Schlüssel hinzufügt oder den Wert eines vorhandenen Schlüssels aktualisiert, zeichnet etcd diesen Vorgang in der WAL auf, einer regulären Datei im persistenten Speicher. Bevor Sie fortfahren, MUSS etcd absolut sicher sein, dass das Schreiben an die WAL wirklich stattgefunden hat. Unter Linux reicht ein einziger Schreibsystemaufruf dafür nicht aus, da das eigentliche Schreiben in den physischen Speicher verzögert sein kann. Beispielsweise kann Linux einen WAL-Datensatz für einige Zeit in einem Cache im Kernelspeicher speichern (z. B. einen Seitencache). Und damit die Daten genau in den persistenten Speicher geschrieben werden können, benötigen Sie nach dem Schreiben den Systemaufruf fdatasync, und etcd verwendet ihn nur (wie Sie an strace 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, ".\0\0\0\0\0\0\202\10\2\20\361\223\255\266\6\32$\10\0\20\10\30\26\"\34\"\r\n\3fo"..., 2296) = 2296 <0.000130> 21:23:09.895041 fdatasync(8) = 0 <0.008314>
Leider geht das Schreiben in einen dauerhaften Speicher nicht sofort. Wenn der Aufruf von fdatasync langsam ist, sinkt die Systemleistung von etcd. Die Dokumentation für etcd besagt, dass das Repository als schnell genug angesehen wird, wenn im 99. Perzentil von fdatasync-Aufrufen das Schreiben in die WAL-Datei weniger als 10 ms dauert. Es gibt andere nützliche Metriken für die Speicherung, aber in diesem Beitrag sprechen wir nur über diese Metrik.
Bewerten Sie die Lagerung mit fio
Wenn Sie bewerten müssen, ob Ihr Repository für etcd geeignet ist, verwenden Sie fio, ein sehr beliebtes Tool zum Testen von E / A-Belastungen. Es sollte beachtet werden, dass Festplattenoperationen sehr unterschiedlich sein können: synchron und asynchron, viele Klassen von Systemaufrufen usw. Daher ist die Verwendung von fio sehr schwierig. Es hat viele Parameter und verschiedene Kombinationen ihrer Werte führen zu völlig unterschiedlichen E / A-Workloads. Um ausreichende Zahlen für etcd zu erhalten, sollten Sie sicherstellen, dass die Testaufzeichnungslast von fio beim Schreiben von WAL-Dateien so nahe wie möglich an der tatsächlichen Last von etcd liegt.
Folglich sollte fio mindestens eine Last in Form einer Reihe von sequentiellen Schreibvorgängen in die Datei erstellen. Jeder Datensatz besteht aus einem Schreibsystemaufruf , gefolgt von einem fdatasync-Systemaufruf. Für sequentielle Schreibvorgänge benötigt fio die Option --rw = write. Damit fio beim Aufzeichnen den Schreibsystemaufruf anstelle von pwrite verwenden kann , muss der Parameter --ioengine = sync angegeben werden. Damit fdatasync nach jedem Eintrag aufgerufen werden kann, müssen Sie den Parameter --fdatasync = 1 hinzufügen. Die beiden anderen Optionen in diesem Beispiel (--size und --bs) sind szenariospezifisch. Im nächsten Abschnitt zeigen wir Ihnen, wie Sie sie konfigurieren.
Warum fio und wie wir gelernt haben, es zu konfigurieren
In diesem Beitrag beschreiben wir den realen Fall. Wir hatten einen Kubernetes v1.13-Cluster, den wir mit Prometheus überwacht haben. etcd v3.2.24 wurde auf einer SSD gehostet. Etcd-Metriken zeigten zu hohe Latenzen für fdatasync, selbst wenn der Cluster nichts unternahm. Die Metriken waren seltsam und wir wussten wirklich nicht, was sie bedeuteten. Der Cluster bestand aus virtuellen Maschinen. Man musste verstehen, wo das Problem lag: auf physischen SSDs oder in der Virtualisierungsschicht. Darüber hinaus haben wir häufig Änderungen an der Hardware- und Softwarekonfiguration vorgenommen und mussten die Ergebnisse bewerten. Wir könnten etcd in jeder Konfiguration ausführen und uns die Prometheus-Metriken ansehen, aber das ist zu mühsam. Wir suchten nach einer ziemlich einfachen Möglichkeit, eine bestimmte Konfiguration zu bewerten. Wir wollten überprüfen, ob wir die Prometheus-Metriken von etcd richtig verstanden haben.
Dafür mussten jedoch zwei Probleme gelöst werden. Wie sieht die E / A-Last aus, die etcd beim Schreiben in die WAL erstellt? Welche Systemaufrufe werden verwendet? Wie groß sind die Datensätze? Zweitens, wenn wir diese Fragen beantworten, wie reproduziere ich eine ähnliche Arbeitslast mit fio? 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 und strace . lsof zeigt alle vom Prozess verwendeten Dateideskriptoren und die zugehörigen Dateien an. Und mit strace können Sie einen bereits laufenden Prozess studieren oder einen Prozess starten und studieren. strace zeigt alle Systemaufrufe des untersuchten Prozesses (und seiner untergeordneten Prozesse) an. Letzteres ist sehr wichtig, da etcd nur einen ähnlichen Ansatz verfolgt.
Zunächst haben wir strace verwendet, um den etcd-Server für Kubernetes zu lernen, wenn der Cluster nicht belastet war. Wir haben gesehen, dass fast alle WAL-Datensätze ungefähr gleich groß waren: 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 Eintrags etcd von der Version von etcd, der Übermittlung, den Parameterwerten usw. abhängt und sich auf die Dauer von fdatasync auswirkt. Wenn Sie ein ähnliches Szenario haben, überprüfen Sie Ihre etcd-Prozesse mit Strace, um die genauen Zahlen herauszufinden.
Um eine gute Vorstellung von den Aktionen im etcd-Dateisystem zu bekommen, haben wir es mit strace und den Optionen -ffttT gestartet. Deshalb haben wir versucht, die untergeordneten Prozesse zu untersuchen und die Ausgabe jedes einzelnen in eine separate Datei zu schreiben. Außerdem haben wir detaillierte Berichte über den Start und die Dauer jedes Systemaufrufs erhalten. Wir haben lsof verwendet, um unsere Analyse der Strace-Ausgabe zu bestätigen und festzustellen, welcher Dateideskriptor für welchen Zweck verwendet wurde. Mit strace haben wir also die oben gezeigten Ergebnisse erhalten. Die Statistik zur Synchronisationszeit bestätigte, dass der Indikator wal_fsync_duration_seconds von etcd fdatasync-Aufrufen mit WAL-Dateideskriptoren entspricht.
Wir haben die fio-Dokumentation studiert und die Optionen für unser Skript ausgewählt, damit fio eine ähnliche Last wie etcd generiert. Wir haben auch die Systemaufrufe und ihre Dauer überprüft, indem wir fio von strace ausgeführt haben, ähnlich wie bei etcd.
Wir haben den Wert des Parameters --size sorgfältig ausgewählt, der die gesamte E / A-Last von fio darstellt. 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 ist. Für einen bestimmten bs-Wert ist die Anzahl der Aufrufe von fdatasync = size / bs. Da wir uns für Perzentile interessierten, hätten wir genügend Stichproben für die Zuverlässigkeit haben müssen, und wir berechneten, dass 10 ^ 4 für uns ausreichen würden (wir erhalten 22 Mebibyte). Wenn --size kleiner ist, können Ausreißer auftreten (z. B. arbeiten mehrere fdatasync-Aufrufe länger als gewöhnlich und wirken sich auf das 99. Perzentil aus).
Probieren Sie es selbst aus
Wir haben gezeigt, wie man fio verwendet und ob der Speicher genug Geschwindigkeit für hohe Leistung usw. hat. Jetzt können Sie es in der Praxis selbst ausprobieren, indem Sie beispielsweise virtuelle Maschinen mit SSD-Speicher in der IBM Cloud verwenden .