🥇Hvordan sjekke disker med fio for tilstrekkelig ytelse for etcd

Merk. overs.: Denne artikkelen er resultatet av en mini-forskning utført av IBM Cloud-ingeniører på jakt etter en løsning på et reelt problem knyttet til driften av etcd-databasen. En lignende oppgave var relevant for oss, men forfatternes refleksjons- og handlingsforløp kan være interessant i en bredere sammenheng.

Kort oppsummering av hele artikkelen: fio og etcd

Ytelsen til en etcd-klynge er svært avhengig av hastigheten til den underliggende lagringen. etcd eksporterer ulike Prometheus-målinger for å overvåke ytelsen. En av dem er wal_fsync_duration_seconds. I dokumentasjonen for etcd det stårat lagring kan anses som rask nok hvis den 99. persentilen til denne metrikken ikke overstiger 10 ms...

Hvis du vurderer å sette opp en etcd-klynge på Linux-maskiner og vil teste om stasjoner (som SSD-er) er raske nok, anbefaler vi å bruke den populære I/O-testeren kalt Fio. Det er nok å kjøre følgende kommando (katalog test-data må være plassert i den monterte partisjonen til den testede stasjonen):

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

Det gjenstår bare å se på utgangen og sjekke om 99. persentilen passer fdatasync om 10 ms. I så fall fungerer stasjonen raskt nok. Her er et eksempel på utdata:

fsync/fdatasync/sync_file_range:
  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]

Noen få merknader:

I eksemplet ovenfor har vi justert parametrene --size и --bs for en konkret sak. For å få et meningsfylt resultat fra fio, spesifiser verdier som er passende for ditt bruksområde. Hvordan velge dem vil bli diskutert nedenfor.
Kun under testing fio laster diskundersystemet. I det virkelige liv er det sannsynlig at andre prosesser vil skrive til disk (foruten de som er relatert til wal_fsync_duration_seconds). Denne ekstra belastningen kan øke wal_fsync_duration_seconds. Med andre ord hvis 99. persentilen fra testing med fio, bare litt mindre enn 10 ms, er det en god sjanse for at lagringsytelsen ikke er tilstrekkelig.
For testen trenger du versjonen fio ikke lavere enn 3.5, fordi eldre versjoner ikke samler resultater fdatasync i form av persentiler.
Konklusjonen ovenfor er bare et lite utdrag fra den generelle konklusjonen fio.

Mer om fio og etcd

Noen få ord om WALs etcd

Vanligvis bruker databaser proaktiv logging (forhåndslogging, WAL). etcd påvirkes også. En diskusjon om WAL er utenfor rammen av denne artikkelen, men for våre formål er det du trenger å vite at hvert etcd-klyngemedlem lagrer WAL i vedvarende lagring. etcd skriver noen nøkkelverdilagringsoperasjoner (som oppdateringer) til WAL før de utføres. Hvis en node krasjer og starter på nytt mellom øyeblikksbilder, kan etcd gjenopprette transaksjoner siden forrige øyeblikksbilde basert på innholdet i WAL.

Hver gang en klient legger til en nøkkel til KV-lageret eller oppdaterer verdien til en eksisterende nøkkel, legger etcd til operasjonsbeskrivelsen til WAL, som er en vanlig fil i det vedvarende lagret. etcd MÅ være 100 % sikker på at WAL-oppføringen faktisk er lagret før du fortsetter. For å oppnå dette på Linux er det ikke nok å bruke systemkallet write, siden selve skriveoperasjonen til det fysiske mediet kan bli forsinket. For eksempel kan Linux beholde en WAL-oppføring i en kjernebuffer i minnet (f.eks. i sidebufferen) i noen tid. For å sikre at dataene skrives til media, må et systemanrop påkalles etter skrivingen fdatasync - dette er nøyaktig hva etcd gjør (som du kan se i følgende utgang strace; Her 8 - WAL-filbeskrivelse):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ".20210220361223255266632$1020103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

Dessverre tar det litt tid å skrive til vedvarende lagring. Langvarig kjøring av fdatasync-anrop kan påvirke ytelsen til etcd. I depotdokumentasjonen angitt, at for tilstrekkelig ytelse er det nødvendig at den 99. persentilen av varigheten av alle samtaler fdatasync ved skriving til en WAL-fil var mindre enn 10 ms. Det finnes andre lagringsrelaterte beregninger, men denne artikkelen vil fokusere på den.

Verdsetter lager med fio

Du kan vurdere om et bestemt lager er egnet for bruk med etcd ved å bruke verktøyet Fio — en populær I/O-tester. Husk at disk I/O kan skje på mange forskjellige måter: synkronisering/asynkronisering, mange forskjellige syscall-klasser og så videre. Den andre siden av mynten er det fio ekstremt vanskelig å bruke. Verktøyet har mange parametere, og forskjellige kombinasjoner av verdiene deres fører til helt forskjellige resultater. For å få et rimelig estimat for etcd, må du sørge for at skrivebelastningen generert av fio er så nært som mulig til etcds WAL-fil skrivelast:

Dette betyr at den genererte fio belastningen bør minst være en serie påfølgende skrivinger til filen, der hver skriving består av et systemkall writeetterfulgt av fdatasync.
For å aktivere sekvensiell skriving, må du spesifisere flagget --rw=write.
At fio skrev ved hjelp av samtaler write (i stedet for andre systemanrop - f.eks. pwrite), bruk flagget --ioengine=sync.
Til slutt flagget --fdatasync=1 sikrer at hver write bør fdatasync.
De to andre parameterne i vårt eksempel er: --size и --bs - kan variere avhengig av den spesifikke brukssaken. Den neste delen vil beskrive konfigurasjonen deres.

Hvorfor vi valgte fio og hvordan vi lærte å sette det opp

Dette notatet kommer fra en ekte sak vi har møtt. Vi hadde en klynge på Kubernetes v1.13 med overvåking på Prometheus. SSD-er ble brukt som lagring for etcd v3.2.24. Etcd-beregninger viste for høye ventetider fdatasync, selv når klyngen var inaktiv. For oss virket disse beregningene veldig tvilsomme, og vi var ikke sikre på nøyaktig hva de representerte. I tillegg bestod klyngen av virtuelle maskiner, så det var ikke mulig å si om forsinkelsen skyldtes virtualisering eller SSD-en var skyld i.

I tillegg vurderte vi ulike endringer i maskinvare- og programvarekonfigurasjonen, så vi trengte en måte å evaluere dem på. Selvfølgelig ville det være mulig å kjøre etcd i hver konfigurasjon og se på de tilsvarende Prometheus-metrikkene, men det ville kreve betydelig innsats. Det vi trengte var en enkel måte å evaluere en spesifikk konfigurasjon på. Vi ønsket å teste vår forståelse av Prometheus-beregningene som kommer fra etcd.

Dette krevde å løse to problemer:

For det første, hvordan ser I/O-belastningen som genereres av etcd når du skriver til WAL-filer ut? Hvilke systemanrop brukes? Hva er størrelsen på postblokkene?
For det andre, la oss si at vi har svar på spørsmålene ovenfor. Hvordan gjengi tilsvarende belastning med fio? Tross alt fio — ekstremt fleksibelt verktøy med en overflod av parametere (dette er lett å verifisere, f.eks. her - ca. oversett.).

Vi løste begge problemene med samme kommandobaserte tilnærming lsof и strace:

Med lsof du kan se alle filbeskrivelser som brukes av prosessen, samt filene de refererer til.
Med strace du kan analysere en allerede kjørende prosess eller kjøre en prosess og se den. Kommandoen viser alle systemanrop utført av denne prosessen og, om nødvendig, dens etterkommere. Det siste er viktig for prosesser som er forking, og etcd er en slik prosess.

Det første vi gjorde var å bruke strace for å undersøke etcd-serveren i Kubernetes-klyngen mens den var inaktiv.

Så det ble funnet at WAL-postblokker er veldig tett gruppert, størrelsen på majoriteten var i området 2200-2400 byte. Det er derfor kommandoen i begynnelsen av denne artikkelen bruker flagget --bs=2300 (bs er størrelsen i byte for hver skriveblokk i fio).

Vær oppmerksom på at størrelsen på etcd-skriveblokker kan variere avhengig av versjon, distribusjon, parameterverdier osv. - det påvirker varigheten fdatasync. Hvis du har en lignende use case, analyser med strace dine etcd-prosesser for å få oppdaterte verdier.

Så, for å få en klar og omfattende ide om hvordan etcd fungerer med filsystemet, startet vi det fra under strace med flagg -ffttT. Dette gjorde det mulig å fange opp underordnede prosesser og skrive utdataene fra hver til en separat fil. I tillegg ble det innhentet detaljert informasjon om starttidspunkt og varighet for hvert systemanrop.

Vi brukte også kommandoen lsoffor å bekrefte forståelsen av resultatet strace når det gjelder hvilken filbeskrivelse som ble brukt til hvilket formål. Jeg fikk konklusjonen strace, lik den ovenfor. Statistiske manipulasjoner med synkroniseringstider bekreftet at metrikken wal_fsync_duration_seconds fra etcd matcher samtaler fdatasync med WAL-filbeskrivelser.

Å generere med fio en arbeidsmengde lik den fra etcd, dokumentasjonen av verktøyet ble studert og parametrene egnet for vår oppgave ble valgt. Vi har bekreftet at de riktige systemanropene pågår og bekreftet varigheten ved å kjøre fio av strace (som det ble gjort i tilfelle etcd).

Spesiell oppmerksomhet ble viet til å bestemme verdien av parameteren --size. Den representerer den totale I/O-belastningen generert av fio-verktøyet. I vårt tilfelle er dette det totale antallet byte skrevet til media. Det er direkte proporsjonalt med antall samtaler write (og fdatasync). For en bestemt bs antall samtaler fdatasync er size / bs.

Siden vi var interessert i persentilen, ønsket vi at antallet prøver skulle være stort nok til å være statistisk signifikant. Og bestemte det 10^4 (som tilsvarer en størrelse på 22 MB) vil være tilstrekkelig. Mindre parameterverdier --size ga mer uttalt støy (for eksempel anrop fdatasync, som tar mye lengre tid enn vanlig og påvirker 99. persentilen).

Det er opp til deg

Artikkelen viser hvordan du bruker fio man kan bedømme om mediene beregnet for bruk med etcd er raske nok. Nå er det opp til deg! Du kan utforske virtuelle maskiner med SSD-basert lagring i tjenesten IBM Cloud.

PS fra oversetter

Med ferdige brukssaker fio For andre oppgaver, se dokumentasjon eller direkte til prosjektdepoter (det er mange flere av dem enn nevnt i dokumentasjonen).

PPS fra oversetter

Les også på bloggen vår:

Kilde: www.habr.com

Hvordan sjekke disker med fio for tilstrekkelig ytelse for etcd