En kort historie om fio og etcd
Klyngens ydeevne afhænger i høj grad af ydeevnen fra dets lager. etcd eksporterer nogle metrikker til , for at give de nødvendige oplysninger om lagerydelse. For eksempel metrikken wal_fsync_duration_seconds. : 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 — 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=mytestDu skal bare se resultaterne og kontrollere, at den 99. percentil af varigheden 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, .
- 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 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 ; 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 , 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 , 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) = 0Desværre går registreringen i den permanente opbevaring ikke øjeblikkeligt. Hvis opkaldet til fdatasync går langsomt, falder systemets ydeevne for etcd. , 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 , 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 , 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 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. og . 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 .
Kilde: habr.com
