🥇Er lagringshastigheden egnet til etcd? Lad os spørge fio

En kort historie om fio og etcd

Klyngens ydeevne i den relevante Docker-container afhænger i høj grad af ydeevnen fra dets lager. etcd eksporterer nogle metrikker til Prometheus, for at give de nødvendige oplysninger om lagerydelse. For eksempel metrikken wal_fsync_duration_seconds. Dokumentationen til etcd siger: for at lageret betragtes som tilstrækkeligt hurtigt, skal den 99. percentil af denne metrik være mindre end 10 ms. Hvis du planlægger at køre en etcd-klynge på Linux-maskiner og ønsker at vurderer, om dit lager er hurtigt nok (for eksempel SSD), kan du bruge fio — et populært værktøj til test af input/output-operationer. Kør følgende kommando, hvor test-data er en mappe under det monterede punkt for lageret:

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

Du skal bare se resultaterne og kontrollere, at den 99. percentil af varigheden fdatasync er mindre end 10 ms. Hvis ja, har du et hurtigt nok lager. Her er et eksempel på resultaterne:

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

Noter

Vi har justeret indstillingerne —size og —bs til vores specifikke scenario. For at få et nyttigt resultat fra fio, angiv dine værdier. Hvor kan de findes? Læs, hvordan vi lærte at konfigurere fio.
Under testen kommer al input/output belastning fra fio. I et reelt scenario vil der sandsynligvis også komme andre skriveanmodninger til lageret, udover dem der er relateret til wal_fsync_duration_seconds. Yderligere belastning vil øge værdien af wal_fsync_duration_seconds. Så hvis den 99. percentil næsten når 10 ms, har dit lager ikke tilstrækkelig hastighed.
Tag versionen fio ikke lavere end 3.5 (de tidligere viser ikke percentiler for varigheden af fdatasync).
Ovenfor vises kun et uddrag af resultaterne fra fio.

En lang historie om fio og etcd

Hvad er WAL i etcd

Databaser bruger normalt forhåndsskrivningslog; etcd bruger også det. Her vil vi ikke gå i dybden med write-ahead log (WAL). Det er tilstrækkeligt at vide, at hvert medlem af etcd-klyngen fører det i en permanent opbevaring. etcd registrerer hver operation med nøgle-værdi-par (fx opdatering) i WAL, før de anvendes i opbevaringen. Hvis et udvalg medlem af opbevaringen oplever en nedbrud og genstartes mellem snapshots, kan det lokalt genskabe transaktionerne fra det sidste snapshot baseret på indholdet af WAL.

Når en klient tilføjer en nøgle til nøgle-værdi-opbevaringen eller opdaterer værdien af en eksisterende nøgle, registrerer etcd denne operation i WAL, som er en almindelig fil i den permanente opbevaring. Før den fortsætter behandlingen, SKAL etcd være helt sikker på, at registreringen i WAL faktisk er sket. I Linux er det ikke nok med ét systemopkald write, da selve registreringen i det fysiske opbevaringssystem kan blive forsinket. For eksempel kan Linux i et stykke tid holde WAL-registreringen i kernen cache (fx side-cache). Og for at dataene præcist bliver registreret i den permanente opbevaring, kræves et systemopkald fdatasync efter registrering, og det er netop det, etcd bruger (som man kan se i resultatet strace, hvor 8 er filbeskriveren for WAL):

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)            = 0

Desværre går registreringen i den permanente opbevaring ikke øjeblikkeligt. Hvis opkaldet til fdatasync går langsomt, falder systemets ydeevne for etcd. I dokumentationen for etcd står der, at opbevaringen anses for hurtigt nok, hvis i 99. percentil opkaldene til fdatasync ved registrering i filen WAL tager mindre end 10 ms. Der er også andre nyttige metrikker for opbevaringen, men i dette indlæg taler vi kun om denne metrik.

Evaluering af opbevaringen med fio

Hvis du har brug for at vurdere, om dit lager er egnet til etcd, skal du bruge fio - et meget populært værktøj til belastningstest. Det er vigtigt at huske, at diskoperationer kan være meget forskellige: synkrone og asynkrone, mange klasser af systemopkald osv. Som følge heraf kan fio være ret svært at bruge. Det har mange parametre, og forskellige kombinationer af deres værdier giver helt forskellige I/O-belastninger. For at få adekvate tal for etcd, skal du sørge for, at skrivebelastningen fra fio er så tæt som muligt på den reelle belastning fra etcd ved skrivning af WAL-filer.

Derfor skal fio mindst lave en belastning i form af en række sekventielle skriveoperationer til en fil, hvor hver skrivning vil bestå af et systemopkald write, efterfulgt af systemopkaldet fdatasync. For sekventielle skriveoperationer kræver fio parameteren —rw=write. For at fio skal bruge systemopkaldet write under skrivning i stedet for pwrite, skal parameteren —ioengine=sync angives. Endelig, for at fdatasync skal kaldes efter hver skrivning, skal parameteren —fdatasync=1 tilføjes. De to andre parametre i dette eksempel (—size og —bs) afhænger af det specifikke scenarie. I det næste afsnit fortæller vi, hvordan man konfigurerer dem.

Hvorfor netop fio, og hvordan vi lærte at konfigurere det

I dette indlæg beskriver vi et reelt tilfælde. Vi havde en klynge Kubernetes v1.13, som vi overvågede med Prometheus. etcd v3.2.24 blev hostet på SSD. Metrikkerne for etcd viste alt for høje forsinkelser for fdatasync, selv når klyngen ikke lavede noget. Metrikkerne var mærkelige, og vi vidste ikke rigtig, hvad de betød. Klyngen bestod af virtuelle maskiner, og vi skulle finde ud af, hvor problemet lå: i de fysiske SSD'er eller i virtualiseringslaget. Desuden foretog vi ofte ændringer i hardware- og softwarekonfigurationen, og vi havde brug for en måde at vurdere deres resultater. Vi kunne køre etcd i hver konfiguration og se på Prometheus-metrikkerne, men det var for besværligt. Vi søgte efter en tilstrækkelig enkel måde at vurdere en bestemt konfiguration på. Vi ville kontrollere, om vi korrekt forstod Prometheus-metrikkerne fra etcd.

Men for at gøre det skulle vi løse to problemer. For det første, hvordan ser I/O-belastningen ud, som etcd skaber ved skrivning til WAL? Hvilke systemopkald anvendes? Hvad er størrelsen på posterne? For det andet, hvis vi besvarer disse spørgsmål, hvordan kan vi så reproducere en lignende arbejdsbelastning med fio? Husk, at fio er et meget fleksibelt værktøj med mange parametre. Vi løste begge problemer med én tilgang — ved hjælp af kommandoer. lsof og strace. lsof viser alle filbeskrivelser, der bruges af processen, samt de relaterede filer. Og med strace kan man undersøge en allerede kørende proces eller starte en proces og analysere den. strace viser alle systemopkald fra den undersøgte proces (og dens underprocesser). Det sidste er meget vigtigt, da etcd netop anvender en lignende tilgang.

Først brugte vi strace til at undersøge etcd-serveren for Kubernetes, da klyngen ikke havde nogen belastning. Vi så, at næsten alle WAL-poster var af nogenlunde samme størrelse: 2200–2400 byte. Derfor angav vi i kommandoen i begyndelsen af indlægget parameteren —bs=2300 (bs betyder størrelsen i byte for hver fio-post). Vær opmærksom på, at størrelsen på etcd-poster afhænger af versionen af etcd, leveringen, parameterværdier osv. og påvirker varigheden af fdatasync. Hvis du har et tilsvarende scenarie, så undersøg dine etcd-processer med strace for at finde de nøjagtige tal.

Derefter, for bedre at forstå handlingerne i filsystemet for etcd, kørte vi det med strace og parametrene -ffttT. På den måde forsøgte vi at undersøge underprocesserne og registrere uddataene fra hver af dem i en separat fil, samt få detaljerede rapporter om start og varighed af hver systemopkald. Vi brugte lsof til at bekræfte vores analyse af uddataene fra strace og for at se, hvilken filbeskrivelse der blev brugt til hvilke formål. Således med strace opnåede vi de resultater, der er vist ovenfor. Synkroniseringens tidsstatistik bekræftede, at målingen wal_fsync_duration_seconds fra etcd svarer til opkaldene fdatasync med WAL-fildeskriptorerne.

Vi undersøgte dokumentationen for fio og valgte parametre til vores scenarie, så fio kunne generere en belastning, der svarer til etcd. Vi kontrollerede også systemopkaldene og deres varighed ved at køre fio fra strace, ligesom med etcd.

Vi har omhyggeligt valgt betydningen af parameteren —size, som repræsenterer den samlede I/O-belastning fra fio. I vores tilfælde er dette det samlede antal byte, der skrives til lagringen. Det viste sig at være direkte proportionalt med antallet af systemopkald write (og fdatasync). For et givent værdibasse, er antallet af opkald fdatasync = size/bs. Da vi var interesserede i percentiler, skulle vi have tilstrækkeligt med prøver for at sikre pålidelighed, og vi har beregnet, at 10^4 (det svarer til 22 mibibyte) ville være tilstrækkeligt. Hvis —size er mindre, kan der opstå udslag (for eksempel kan flere opkald til fdatasync tage længere tid end normalt og påvirke den 99. percentil).

Prøv selv

Vi har vist, hvordan man bruger fio og tjekker, om lagringen har tilstrækkelig hastighed til højtydende etcd. Nu kan du prøve det selv i praksis, for eksempel ved at bruge virtuelle maskiner med SSD-lagring i IBM Cloud.

Kilde: habr.com