En novelle om fio og etcd
Klyngeydelse afhænger i høj grad af ydeevnen af dens opbevaring. etcd eksporterer nogle målinger til for at give den ønskede information om lagringsydelse. For eksempel metric'en wal_fsync_duration_seconds. : For at lagring kan anses for at være hurtig nok, 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 evaluere, om din lagring er hurtig nok (f.eks. SSD), kan du bruge er et populært værktøj til at teste I/O-operationer. Kør følgende kommando, hvor test-data er mappen under lagermonteringspunktet:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestDu skal bare se på resultaterne og kontrollere, at den 99. percentil af varigheden mindre end 10 ms. Hvis ja, har du rimelig hurtig opbevaring. Her er et eksempel på resultaterne:
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]noter
- Vi har tilpasset --size og --bs mulighederne til vores særlige scenarie. For at få et brugbart resultat fra fio skal du angive dine egne værdier. Hvor kan man få dem? Læs .
- Under test kommer al I/O-belastning fra fio. I et virkeligt scenarie vil der sandsynligvis være andre skriveanmodninger, der kommer ind i lageret udover dem, der er relateret til wal_fsync_duration_seconds. Den ekstra belastning vil øge værdien af wal_fsync_duration_seconds. Så hvis den 99. percentil er tæt på 10ms, er din lagerplads ved at løbe tør for hastighed.
- Tag versionen ikke lavere end 3.5 (de foregående viser ikke fdatasync-varighedspercentiler).
- Ovenfor er blot et udsnit af resultaterne fra fio.
Lang historie om fio og etcd
Hvad er WAL i etcd
Normalt bruger databaser ; etcd bruger det også. Vi vil ikke diskutere skrive-ahead-loggen (WAL) i detaljer her. Det er nok for os at vide, at hvert medlem af etcd-klyngen opretholder det i vedvarende lagring. etcd skriver hver nøgleværdi-handling (såsom en opdatering) til WAL, før den anvendes til butikken. Hvis et af lagermedlemmerne går ned og genstarter mellem snapshots, kan det lokalt gendanne transaktioner siden det sidste snapshot af WAL-indhold.
Når en klient tilføjer en nøgle til nøgleværdilageret eller opdaterer værdien af en eksisterende nøgle, registrerer etcd operationen i WAL, som er en almindelig fil i vedvarende lagring. etcd SKAL være helt sikker på, at WAL-indtastningen faktisk fandt sted, før du fortsætter med behandlingen. På Linux er et systemkald ikke nok til dette. , da selve skrivningen til fysisk lager kan blive forsinket. For eksempel kan Linux gemme en WAL-post i en cache i kernehukommelsen (såsom en sidecache) i nogen tid. Og for at dataene kan skrives nøjagtigt til vedvarende lagring, er fdatasync-systemkaldet nødvendigt efter skrivningen, og etcd bruger det bare (som du kan se i resultatet af arbejdet , hvor 8 er WAL-filbeskrivelsen):
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>Desværre sker skrivning til vedvarende lagring ikke øjeblikkeligt. Hvis fdatasync-kaldet er langsomt, vil ydeevnen af etcd-systemet lide. at lagringen anses for at være hurtig nok, hvis det i 99. percentilen tager fdatasync-kald mindre end 10ms at skrive til WAL-filen. Der er andre nyttige metrics til opbevaring, men i dette indlæg taler vi kun om denne metric.
Anslå lager med fio
Hvis du har brug for at vurdere, om dit lager er egnet til etcd, så brug fio, et meget populært I/O-belastningstestværktøj. Det skal huskes, at diskoperationer kan være meget forskellige: synkrone og asynkrone, mange klasser af systemopkald osv. Som et resultat er fio ret vanskelig at bruge. Den har mange parametre, og forskellige kombinationer af deres værdier producerer meget forskellige I/O-arbejdsbelastninger. For at få tilstrækkelige tal for etcd, bør du sikre dig, at testskrivebelastningen fra fio er så tæt som muligt på den faktiske belastning fra etcd, når du skriver WAL-filer.
Derfor bør fio som minimum skabe en belastning af en række sekventielle skrivninger til filen, hver skrivning vil bestå af et systemkald efterfulgt af fdatasync-systemkaldet. Sekventielle skrivninger til fio kræver --rw=write-indstillingen. For fio at bruge skrivesystemet opkald, når du skriver, i stedet for , skal du angive parameteren --ioengine=sync. Til sidst, for at kalde fdatasync efter hver skrivning, skal du tilføje parameteren --fdatasync=1. De to andre muligheder i dette eksempel (--size og -bs) er script-specifikke. I næste afsnit viser vi dig, hvordan du konfigurerer dem.
Hvorfor fio og hvordan vi lærte at sætte det op
I dette indlæg beskriver vi en virkelig sag. Vi har en klynge v1.13, som vi overvågede med Prometheus. etcd v3.2.24 var hostet på en SSD. Etcd-målinger viste fdatasync-forsinkelser for høje, selv når klyngen ikke gjorde noget. Målingerne var underlige, og vi vidste ikke rigtig, hvad de betød. Klyngen bestod af virtuelle maskiner, det var nødvendigt at forstå, hvad problemet var: i fysiske SSD'er eller i virtualiseringslaget. Derudover lavede vi ofte ændringer i hardware- og softwarekonfigurationen, og vi havde brug for en måde at evaluere deres resultater på. Vi kunne køre etcd i enhver konfiguration og se på Prometheus-metrics, men det er for meget besvær. Vi ledte efter en ret simpel måde at evaluere en specifik konfiguration på. Vi ville tjekke, om vi forstår Prometheus-metrics fra etcd korrekt.
Men hertil skulle to problemer løses. For det første, hvordan ser den I/O-belastning ud, som etcd skaber, når du skriver til WAL? Hvilke systemopkald bruges? Hvad er størrelsen af posterne? For det andet, hvis vi besvarer disse spørgsmål, hvordan reproducerer vi en lignende arbejdsbyrde med fio? Glem ikke, at fio er et meget fleksibelt værktøj med mange muligheder. Vi løste begge problemer med én tilgang - ved at bruge kommandoerne и . lsof viser alle filbeskrivelser, der bruges af processen, og deres tilknyttede filer. Og med strace kan du undersøge en allerede kørende proces, eller starte en proces og undersøge den. strace udskriver alle systemkald fra den proces, der undersøges (og dens underordnede processer). Sidstnævnte er meget vigtigt, da etcd netop tager en lignende tilgang.
Vi brugte først strace til at udforske etcd-serveren til Kubernetes, da der ikke var nogen belastning på klyngen. Vi så, at næsten alle WAL-poster havde omtrent samme størrelse: 2200-2400 bytes. Derfor specificerede vi i kommandoen i begyndelsen af indlægget parameteren -bs=2300 (bs betyder størrelsen i bytes for hver fio-indgang). Bemærk, at størrelsen på etcd-indgangen afhænger af etcd-versionen, distributionen, parameterværdier osv. og påvirker fdatasync-varigheden. Hvis du har et lignende scenario, skal du undersøge dine etcd-processer med strace for at finde ud af de nøjagtige tal.
Derefter, for at få en god idé om, hvad etcd-filsystemet laver, startede vi det med strace og -ffttT-indstillingerne. Så vi forsøgte at undersøge de underordnede processer og registrere output fra hver af dem i en separat fil og også få detaljerede rapporter om starten og varigheden af hvert systemkald. Vi brugte lsof til at bekræfte vores analyse af strace-outputtet og se, hvilken fildeskriptor der blev brugt til hvilket formål. Så ved hjælp af strace blev resultaterne vist ovenfor opnået. Synkroniseringstidsstatistikker bekræftede, at wal_fsync_duration_seconds fra etcd er i overensstemmelse med fdatasync-kald med WAL-fildeskriptorer.
Vi gennemgik dokumentationen for fio og valgte muligheder for vores script, så fio ville generere en belastning svarende til etcd. Vi tjekkede også systemkald og deres varighed ved at køre fio fra strace, svarende til etcd.
Vi har omhyggeligt valgt værdien af parameteren --size til at repræsentere hele I/O-belastningen fra fio. I vores tilfælde er dette det samlede antal bytes skrevet til lageret. Det viste sig at være direkte proportionalt med antallet af skrive- (og fdatasync) systemkald. For en vis værdi af bs er antallet af fdatasync-kald = størrelse/bs. Da vi var interesserede i percentilen, skulle vi have nok prøver for at være sikre, og vi beregnede, at 10^4 ville være nok for os (det er 22 mebibyte). Hvis --size er mindre, kan afvigelser forekomme (for eksempel tager flere fdatasync-kald længere tid end normalt og påvirker 99. percentilen).
Prøv det selv
Vi viste dig, hvordan du bruger fio og se, om lagringen har nok hastighed til høj ydeevne etcd. Nu kan du selv prøve det ved at bruge for eksempel virtuelle maskiner med SSD-lager i .
Kilde: www.habr.com