🥇Sådan tjekker du diske med fio for tilstrækkelig ydeevne til etcd

Bem. overs.: denne artikel er resultaterne af et mini-forskningsprojekt udført af ingeniører fra IBM Cloud, der søger en løsning på et reelt problem relateret til driften af etcd-databasen. Vi havde en lignende udfordring, men forløbet af forfatternes overvejelser og handlinger kan også være interessant i en bredere kontekst.

Kort resumé af hele artiklen: fio og etcd

Ydeevnen af etcd-klyngen afhænger i høj grad af hastigheden på det underliggende lager. For at overvåge ydeevnen eksporterer etcd forskellige Prometheus-metrics. En af dem er wal_fsync_duration_seconds. I dokumentationen til etcd står der, at lageret kan betragtes som tilstrækkeligt hurtigt, hvis 99. percentil for denne metric ikke overstiger 10 ms…

Hvis du overvejer at sætte en etcd-klynge op på maskiner, der kører Linux, og vil teste, om dine lagringsenheder (for eksempel SSD'er) er hurtige nok, anbefaler vi at bruge det populære I/O-testværktøj kaldet fio. Det er blot at køre følgende kommando (mappen test-data skal være placeret i det monterede volumesystem på det testede lager):

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

Det er kun tilbage at se på outputtet og kontrollere, om 99. percentil for fdatasync er under 10 ms. Hvis det er tilfældet, betyder det, at dit lager fungerer hurtigt nok. Her er et eksempel på output:

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]

Nogle bemærkninger:

I det ovenstående eksempel har vi justeret parametrene --size og --bs til den specifikke situation. For at få et meningsfuldt resultat fra fio, angiv værdier, der passer til dit brugs-scenarie. Hvordan man vælger dem, vil blive diskuteret nedenfor.
Under testen er der kun fio belastning på disksystemet. I virkeligheden kan det være sandsynligt, at andre processer også skriver til disken (udover dem, der relaterer sig til wal_fsync_duration_seconds). En sådan ekstra belastning kan føre til en stigning i wal_fsync_duration_seconds. Med andre ord, hvis 99. percentil, opnået ved testningen, med fio, kun lidt mindre end 10 ms, er der stor sandsynlighed for, at lagerpræstationen er utilstrækkelig.
Du har brug for versionen fio ikke lavere end 3.5, da ældre versioner ikke aggregerer resultaterne fdatasync som percentiler.
Den ovenfor nævnte output er kun et lille uddrag af den samlede output fio.

Detaljer om fio og etcd

Nogle ord om WAL'er i etcd

Generelt bruger databaser forudskrevet logføring (write-ahead logging, WAL). Dette gælder også for etcd. Diskussionen om WAL går ud over denne artikel, men til vores formål er det vigtigt at vide, at hvert medlem af etcd-klassen gemmer WAL i permanent lager. etcd registrerer visse operationer med key-value-lageret (f.eks. opdateringer) i WAL, før de udføres. Hvis en node går ned og genstartes mellem snapshots, kan etcd gendanne transaktionerne, der er udført siden det forrige snapshot, ved at referere til indholdet af WAL.

Dermed, hver gang en klient tilføjer en nøgle til KV-lageret eller opdaterer værdien af en eksisterende nøgle, tilføjer etcd en beskrivelse af operationen til WAL, som er en almindelig fil i permanent lager. Før arbejdet fortsætter, SKAL etcd være 100% sikker på, at registreringen i WAL rent faktisk er gemt. For at opnå dette i Linux er det ikke nok at bruge systemopkaldet write, da selve skriveoperationen til det fysiske medium kan være forsinket. For eksempel kan Linux holde WAL-registreringen i kernens cache i hukommelsen i et stykke tid (f.eks. i sideskabelonen). For at sikre, at dataene bliver skrevet til mediet, er det nødvendigt at aktivere systemopkaldet fdatasync — sådan gør etcd (som set i næste output strace; her 8 — fildescriptoren 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 tager det tid at skrive til permanent lager. En forsinket udførelse af fdatasync-opkaldet kan påvirke præstationen af etcd. I dokumentationen til lageret nævnes der, at for tilstrækkelig præstation skal den 99. percentil for varigheden af alle opkald fdatasync Ved skrivning til WAL-filen var tiden mindre end 10 ms. Der er andre metrikker relateret til lageret, men denne artikel vil fokusere på netop denne.

Vi vurderer lageret med fio

For at vurdere, om et bestemt lager er velegnet til brug med etcd, kan man bruge værktøjet fio — den populære I/O-tester. Vær opmærksom på, at disk I/O kan foregå på forskellige måder: synkron/ asynkron, mange forskellige klasser af systemopkald osv. Bagsiden af medaljen er, at fio det er ekstremt komplekst at bruge. Værktøjet har mange parametre, og forskellige kombinationer af deres værdier fører til helt forskellige resultater. For at få en rimelig vurdering i tilfælde af etcd, skal du sikre dig, at den skrivetræk, der genereres af fio, mest muligt ligner den belastning, etcd genererer, når der skrives til WAL-filer:

Det betyder, at den genererede fio belastning i det mindste skal repræsentere en række sekventielle skrivninger til filen, hvor hver skriveoperation består af et systemopkald write, efterfulgt af fdatasync.
For at aktivere sekventiel skrivning skal du angive flaget --rw=write.
For at fio som skriver ved hjælp af opkald write (og ikke andre systemopkald — for eksempel pwrite), brug flaget --ioengine=sync.
Endelig sikrer flaget --fdatasync=1 at der efter hver write you should fdatasync.
De to andre parametre i vores eksempel: --size og --bs — kan ændre sig afhængigt af det specifikke brugsscenarie. I det følgende afsnit vil deres konfiguration blive beskrevet.

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

Denne note opstod fra en virkelig situation, vi stødte på. Vi havde en klynge på Kubernetes v1.13 med overvågning på Prometheus. Solid-state-drev fungerede som lager for etcd v3.2.24. Metrikkerne fra etcd viste for høje forsinkelser fdatasync, selv når klyngen var inaktiv. Vi fandt disse metrikker meget mistænkelige, og vi var ikke sikre på, hvad de egentlig repræsenterede. Desuden bestod klyngen af virtuelle maskiner, så vi kunne ikke afgøre, om forsinkelsen skyldtes virtualisering eller om SSD'erne var skyld i det.

Derudover overvejede vi forskellige ændringer i konfigurationen af hardware og software, hvilket krævede en måde at evaluere dem på. Selvfølgelig kunne vi køre etcd i hver konfiguration og se på de tilhørende Prometheus-metrics, men det ville kræve betydelige ressourcer. Vi havde brug for en simpel metode til at vurdere en specifik konfiguration. Vi ønskede at teste vores forståelse af de Prometheus-metrics, der kommer fra etcd.

For dette var det nødvendigt at løse to problemer:

For det første, hvordan ser I/O-belastningen, der genereres af etcd under skriveoperationer til WAL-filer, ud? Hvilke systemopkald bliver brugt? Hvad er størrelsen på skriveblokke?
For det andet, lad os antage, at vi har svarene på de ovennævnte spørgsmål. Hvordan kan vi reproducere den tilsvarende belastning med fio? Ведь fio — et ekstremt fleksibelt værktøj med mange parametre (det er let at se, fx her — bem. red.).

Vi løste begge problemer ved hjælp af den samme tilgang, der bygger på kommandoerne lsof og strace:

Ved hjælp af lsof man kan se alle filbeskrivelser, der bruges af processen, samt de filer, de henviser til.
Ved hjælp af strace man kan analysere en allerede kørende proces eller starte en proces og observere den. Kommandoen viser alle systemopkald, der udføres af denne proces og, om nødvendigt, dens efterkommere. Det sidste er vigtigt for processer, der forkes, og etcd er en af sådanne processer.

Det første, vi gjorde, var at bruge strace til at studere etcd-serveren i Kubernetes-klusteret, mens den var inaktiv.

Det blev fundet, at skriveblokke i WAL var meget tæt grupperet, størrelsen på de fleste lå i intervallet 2200-2400 byte. Derfor bruger kommandoen i starten af denne artikel flaget --bs=2300 (bs — størrelsen i byte af hver skriveblok i fio).

Bemærk, at størrelsen på skriveblokke i etcd kan variere afhængigt af versionen, deployment'en, parameterindstillingerne osv. — dette påvirker varigheden fdatasync. Hvis du har et lignende brugsscenario, skal du analysere dine etcd-processer for at få aktuelle værdier. strace Derefter, for at få en klar og omfattende forståelse af, hvordan etcd fungerer med filsystemet, kørte vi den under

med flagene strace -ffttT -ffttT. Dette gjorde det muligt at dække underliggende processer og registrere outputtet fra hver enkelt i en separat fil. Derudover blev der indhentet detaljerede oplysninger om hvornår og hvor længe hver systemopkald fandt sted.

Vi benyttede også kommandoen lsof, for at bekræfte vores forståelse af outputtet strace i forhold til hvilken filbeskrivelse der blev brugt til hvilket formål. Resultatet var strace, der lignede det ovenfor. Statistiske manipulationer med synkroniseringstiderne bekræftede, at metrikken wal_fsync_duration_seconds fra etcd svarede til opkaldene fdatasync med WAL filbeskrivelser.

For at generere fio en arbejdsbyrde, der svarer til belastningen fra etcd, blev dokumentationen for værktøjet gennemgået, og parametre, der passede til vores opgave, blev valgt. Vi sikrede os, at de nødvendige systemopkald blev aktiveret, og bekræftede deres varighed ved at køre fio af strace (ligesom det blev gjort i tilfældet med etcd).

Der blev lagt særlig vægt på at definere værdien af parameteren --size. Det repræsenterer den samlede I/O-belastning genereret af værktøjet fio. I vores tilfælde er det det samlede antal byte skrevet til mediet. Det er direkte proportionalt med antallet af opkald write (og fdatasync). For et givent bs antal opkald fdatasync er lig med size / bs.

Da vi var interesserede i percentilen, stræbte vi efter at have et tilstrækkeligt stort antal prøver for statistisk betydning. Og vi konkluderede, at 10^4 (hvilket svarer til en størrelse på 22 MB) ville være tilstrækkeligt. Mindre værdier af parameteren --size gav mere udtalt støj (for eksempel opkald fdatasync, der tager meget længere tid end normalt og påvirker den 99. percentil).

Det er op til dig

Artiklen viser, hvordan man med fio kan vurdere, om et lagermedie, der er beregnet til brug med etcd, er hurtigt nok. Nu er det op til dig! Du kan udforske virtuelle maskiner med SSD-baseret lagring i tjenesten IBM Cloud.

P.S. fra oversætteren

For at se eksempler på anvendelse fio til at løse andre opgaver kan du finde dem i dokumentationen eller direkte i projektets repository (der er mange flere repræsenteret der end nævnt i dokumentationen).