Lagringshastighet egnet for etcd? La oss spørre fio

En novelle om fio og etcd

Klyngeytelse osv avhenger i stor grad av ytelsen til lagringen. etcd eksporterer noen beregninger til Prometheusfor å gi ønsket informasjon om lagringsytelse. For eksempel metrikken wal_fsync_duration_seconds. Dokumentasjonen for etcd sier: For at lagring skal anses som rask nok, må 99. persentilen til denne beregningen være mindre enn 10 ms. Hvis du planlegger å kjøre en etcd-klynge på Linux-maskiner og ønsker å vurdere om lagringen din er rask nok (f.eks. SSD), kan du bruke Fio er et populært verktøy for å teste I/O-operasjoner. Kjør følgende kommando, der test-data er katalogen under lagringsmonteringspunktet:

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

Du trenger bare å se på resultatene og sjekke at den 99. persentilen av varigheten fdatasync mindre enn 10 ms. I så fall har du rimelig rask lagring. Her er et eksempel på resultatene:

  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]

Merknader

• Vi har tilpasset --size og --bs alternativene for vårt spesielle scenario. For å få et nyttig resultat fra fio, oppgi dine egne verdier. Hvor får man tak i dem? Lese hvordan vi lærte å konfigurere fio.
• Under testing kommer all I/O-belastning fra fio. I et virkelighetsscenario vil det sannsynligvis være andre skriveforespørsler som kommer inn i lagringen i tillegg til de som er relatert til wal_fsync_duration_seconds. Den ekstra belastningen vil øke verdien av wal_fsync_duration_seconds. Så hvis den 99. persentilen er nær 10ms, går lagringsplassen din tom for hastighet.
• Ta versjonen Fio ikke lavere enn 3.5 (de forrige viser ikke fdatasync-varighetspersentiler).
• Ovenfor er bare et utdrag av resultatene fra fio.

Lang historie om fio og etcd

Hva er WAL i etcd

Vanligvis bruker databaser fremskrivningslogg; etcd bruker det også. Vi vil ikke diskutere WAL-loggen i detalj her. Det er nok for oss å vite at hvert medlem av etcd-klyngen opprettholder den i vedvarende lagring. etcd skriver hver nøkkelverdi-operasjon (som en oppdatering) til WAL før den brukes på butikken. Hvis et av lagringsmedlemmene krasjer og starter på nytt mellom øyeblikksbilder, kan det lokalt gjenopprette transaksjoner siden siste øyeblikksbilde av WAL-innhold.

Når en klient legger til en nøkkel til nøkkelverdilageret eller oppdaterer verdien til en eksisterende nøkkel, registrerer etcd operasjonen i WAL, som er en vanlig fil i vedvarende lagring. etcd MÅ være helt sikker på at WAL-oppføringen faktisk skjedde før du fortsetter med behandlingen. På Linux er ikke ett systemanrop nok for dette. skrive, siden selve skrivingen til fysisk lagring kan bli forsinket. For eksempel kan Linux lagre en WAL-oppføring i en hurtigbuffer i kjerneminnet (som en sidebuffer) i noen tid. Og for at dataene skal skrives nøyaktig til vedvarende lagring, er fdatasync-systemanropet nødvendig etter skrivingen, og etcd bruker det bare (som du kan se i resultatet av arbeidet strace, 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>

Dessverre, skriving til vedvarende lagring skjer ikke umiddelbart. Hvis fdatasync-kallet er tregt, vil ytelsen til etcd-systemet lide. Dokumentasjonen for etcd sierat lagringen anses som rask nok hvis, i 99. persentil, fdatasync-kall tar mindre enn 10ms å skrive til WAL-filen. Det er andre nyttige beregninger for lagring, men i dette innlegget snakker vi kun om denne metrikken.

Estimerer lagring med fio

Hvis du trenger å vurdere om lagringen din er egnet for etcd, bruk fio, et veldig populært I/O-lasttestingsverktøy. Det bør huskes at diskoperasjoner kan være svært forskjellige: synkron og asynkron, mange klasser av systemanrop, etc. Som et resultat er fio ganske vanskelig å bruke. Den har mange parametere, og forskjellige kombinasjoner av verdiene deres produserer svært forskjellige I/O-arbeidsbelastninger. For å få tilstrekkelige tall for etcd bør du sørge for at testskrivebelastningen fra fio er så nær som mulig den faktiske belastningen fra etcd når du skriver WAL-filer.

Derfor bør fio som et minimum opprette en belastning i form av en serie påfølgende skrivinger til filen, hver skriving vil bestå av et systemkall skriveetterfulgt av systemkallet fdatasync. Sekvensiell skriving til fio krever --rw=skrivealternativet. For fio å bruke skrivesystemet kall når du skriver, i stedet for skrive, bør du spesifisere --ioengine=sync-parameteren. Til slutt, for å kalle fdatasync etter hver skriving, må du legge til parameteren --fdatasync=1. De to andre alternativene i dette eksemplet (--size og -bs) er skriptspesifikke. I neste avsnitt viser vi deg hvordan du setter dem opp.

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

I dette innlegget beskriver vi en reell sak. Vi har en klynge Kubernetes v1.13 som vi overvåket med Prometheus. etcd v3.2.24 var vert på en SSD. Etcd-beregninger viste fdatasync-forsinkelser for høye, selv når klyngen ikke gjorde noe. Beregningene var rare, og vi visste egentlig ikke hva de betydde. Klyngen besto av virtuelle maskiner, det var nødvendig å forstå hva problemet var: i fysiske SSD-er eller i virtualiseringslaget. I tillegg gjorde vi ofte endringer i maskinvare- og programvarekonfigurasjonen, og vi trengte en måte å evaluere resultatene på. Vi kunne kjøre etcd i alle konfigurasjoner og se på Prometheus-målinger, men det er for mye problem. Vi var på utkikk etter en ganske enkel måte å evaluere en spesifikk konfigurasjon på. Vi ønsket å sjekke om vi forstår Prometheus-metrikker fra etcd riktig.

Men for dette måtte to problemer løses. For det første, hvordan ser I/O-belastningen ut som etcd skaper når du skriver til WAL? Hvilke systemanrop brukes? Hva er størrelsen på postene? For det andre, hvis vi svarer på disse spørsmålene, hvordan gjenskaper vi en lignende arbeidsmengde med fio? Ikke glem at fio er et veldig fleksibelt verktøy med mange alternativer. Vi løste begge problemene i én tilnærming – ved å bruke kommandoene lsof и strace. lsof viser alle filbeskrivelser som brukes av prosessen og tilhørende filer. Og med strace kan du undersøke en allerede pågående prosess, eller starte en prosess og undersøke den. strace skriver ut alle systemanrop fra prosessen som undersøkes (og dens underordnede prosesser). Det siste er veldig viktig, siden etcd bare tar en lignende tilnærming.

Vi brukte først strace for å utforske etcd-serveren for Kubernetes når det ikke var noen belastning på klyngen. Vi så at nesten alle WAL-poster var omtrent like store: 2200–2400 byte. Derfor, i kommandoen i begynnelsen av innlegget, spesifiserte vi parameteren -bs=2300 (bs betyr størrelsen i byte for hver fio-oppføring). Merk at størrelsen på etcd-oppføringen avhenger av etcd-versjonen, distribusjonen, parameterverdiene osv., og påvirker fdatasync-varigheten. Hvis du har et lignende scenario, undersøk dine etcd-prosesser med strace for å finne ut de nøyaktige tallene.

Deretter, for å få en god ide om hva etcd-filsystemet gjør, startet vi det med strace og -ffttT-alternativene. Så vi prøvde å undersøke de underordnede prosessene og registrere utdataene fra hver av dem i en egen fil, og også få detaljerte rapporter om starten og varigheten av hvert systemanrop. Vi brukte lsof for å bekrefte analysen vår av strace-utgangen og se hvilken filbeskrivelse som ble brukt til hvilket formål. Så ved hjelp av strace ble resultatene vist ovenfor oppnådd. Synkroniseringstidsstatistikk bekreftet at wal_fsync_duration_seconds fra etcd stemmer overens med fdatasync-anrop med WAL-filbeskrivelser.

Vi gikk gjennom dokumentasjonen for fio og valgte alternativer for skriptet vårt slik at fio skulle generere en belastning som ligner på etcd. Vi sjekket også systemanrop og deres varighet ved å kjøre fio fra strace, som ligner på etcd.

Vi har nøye valgt verdien av --size-parameteren for å representere hele I/O-belastningen fra fio. I vårt tilfelle er dette det totale antallet byte skrevet til lagringen. Det viste seg å være direkte proporsjonalt med antall skrive- (og fdatasync) systemanrop. For en viss verdi av bs, antall fdatasync-kall = størrelse/bs. Siden vi var interessert i persentilen, måtte vi ha nok prøver for å være sikre, og vi regnet ut at 10^4 ville være nok for oss (det er 22 mebibyte). Hvis --size er mindre, kan avvik forekomme (for eksempel tar flere fdatasync-anrop lengre tid enn vanlig og påvirker 99. persentilen).

Prøv det selv

Vi viste deg hvordan du bruker fio og se om lagringen er rask nok til at etcd fungerer bra. Nå kan du prøve det selv ved å bruke for eksempel virtuelle maskiner med SSD-lagring inne IBM Cloud.

Kilde: www.habr.com