🥇Hur man använder fio för att kontrollera diskar för tillräcklig prestanda för etcd

Obs. övers.: Denna artikel sammanfattar en mini-studie utförd av IBM Cloud-ingenjörer för att hitta en lösning på ett verkligt problem kopplat till drift av databasen etcd. Vi hade en liknande uppgift, men författarnas tankegångar och åtgärder kan vara intressanta i ett bredare sammanhang.

Sammanfattning av hela artikeln: fio och etcd

Prestandan hos etcd-klustret beror starkt på hastigheten hos den underliggande lagringen. För att övervaka prestandan exporterar etcd olika Prometheus-metrik. En av dessa är wal_fsync_duration_seconds. I dokumentationen för etcd säger, anses lagringen vara tillräckligt snabb om den 99:e percentilen för denna metrik inte överstiger 10 ms…

Om du överväger att sätta upp ett etcd-kluster på maskiner som kör Linux och vill kontrollera om dina lagringsenheter (till exempel SSD) är tillräckligt snabba, rekommenderar vi att du använder den populära I/O-testaren fio. Du behöver bara köra följande kommando (katalogen test-data ska ligga i den monterade partitionen av den testade lagringsenheten):

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

Du behöver bara titta på utdata och kontrollera om den 99:e percentilen fdatasync är inom 10 ms. Om så är fallet, fungerar din lagringsenhet tillräckligt snabbt. Här är ett exempel på utdata:

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

Några kommentarer:

I exemplet ovan anpassade vi parametrarna --size och --bs till det specifika fallet. För att få meningsfulla resultat från fio, ange värden som är lämpliga för ditt användningsscenario. Hur man väljer dem kommer att förklaras nedan.
Under testningen är det endast fio som belastar lagringssystemet. I verkliga livet är det mycket troligt att andra processer också skriver till disken (förutom de relaterade till wal_fsync_duration_seconds). En sådan extra belastning kan leda till en ökning av wal_fsync_duration_seconds. Med andra ord, om den 99:e percentilen som erhållits vid testningen med fio, bara ligger något under 10 ms, är det stor sannolikhet att lagringens prestanda är otillräcklig.
För testet behöver du versionen fio inte lägre än 3.5, eftersom äldre versioner inte aggregerar resultaten fdatasync i form av percentiler.
Den ovan angivna utdata är bara ett litet utdrag från den totala utdata. fio.

Mer om fio och etcd.

Några ord om WAL:ar i etcd.

Som regel använder databaser förhandsloggning (write-ahead logging, WAL). Detta gäller även etcd. Diskussionen om WAL ligger utanför denna artikel, men för våra syften behöver vi veta följande: varje medlem i etcd-klustret lagrar WAL i en permanent lagringslösning. etcd skriver vissa operationer med nyckel-värde-lagret (t.ex. uppdateringar) i WAL innan de genomförs. Om en nod kraschar och startas om mellan snapshots, kan etcd återställa transaktionerna som genomfördes från den föregående snapshoten, baserat på innehållet i WAL.

Så varje gång en klient lägger till en nyckel i KV-lagret eller uppdaterar värdet av en befintlig nyckel, lägger etcd till en beskrivning av operationen i WAL, som är en vanlig fil i permanent lagring. Innan den fortsätter sitt arbete MÅSTE etcd vara 100% säker på att inspelningen i WAL verkligen är sparad. För att uppnå detta i Linux räcker det inte med att använda systemanropet skriv, eftersom själva skrivoperationen på den fysiska enheten kan fördröjas. Till exempel kan Linux under en tid hålla WAL-inspelningen i kärnans cache i minnet (t.ex. i sidcache). För att säkerställa att data skrivs till enheten, måste ett systemanrop genomföras efter skrivning fdatasync — det är vad etcd gör (som man kan se i nästa utdrag för att kontrollera paketöverföringen åt båda håll; här 8 — WAL-fildeskriptor):

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

Tyvärr tar det lite tid att skriva till permanent lagring. Långvariga fdatasync-anrop kan påverka prestandan för etcd. I dokumentationen för lagringen nämns anges, att för tillräcklig prestanda bör den 99:e percentilen av varaktigheten för alla anrop fdatasync vid skrivning till WAL-filen vara mindre än 10 ms. Det finns andra mått relaterade till lagringen, men denna artikel fokuserar just på detta.

Utvärderar lagringen med fio.

Om ett visst lagringsalternativ är lämpligt för användning med etcd kan bedömas med hjälp av verktyget fio — populär testare av I/O. Tänk på att disk I/O kan ske på olika sätt: sync/async, ett flertal olika klasser av systemanrop osv. Den baksidan är att fio den är extremt svår att använda. Verktyget har många parametrar, och olika kombinationer av deras värden ger helt olika resultat. För att få en rimlig bedömning när det gäller etcd måste du se till att skrivbelastningen som genereras av fio mest liknar den belastning etcd hanterar vid skrivning till WAL-filer:

Detta innebär att den genererade fio belastningen minst måste representera en serie sekventiella skrivningar till en fil, där varje skrivoperation består av ett systemanrop skriv, följt av fdatasync.
För att aktivera sekventiell skrivning måste du ange flaggan --rw=write.
För att fio som skrevs med hjälp av anrop skriv (inte andra systemanrop — till exempel, pwrite), använd flaggan --ioengine=sync.
Slutligen, flaggan --fdatasync=1 garanterar att varje skriv man fdatasync.
De två andra parametrarna i vårt exempel: --size och --bs — kan ändras beroende på det specifika användningsfallet. Deras konfiguration kommer att beskrivas i nästa avsnitt.

Varför vi valde fio och hur vi lärde oss att konfigurera det

Denna anteckning kom från en verklig situation vi stötte på. Vi hade en kluster på Kubernetes v1.13 med övervakning på Prometheus. Förlagring för etcd v3.2.24 var SSD-enheter. Metrikarna från etcd visade för höga latenser fdatasync, även när klustret var inaktivt. Vi tyckte att dessa metrikar verkade mycket tvivelaktiga, och vi var osäkra på vad de egentligen representerade. Dessutom bestod klustret av virtuella maskiner, så vi kunde inte säga om latensen berodde på virtualisering eller om SSD:erna var den verkliga syndaren.

Vi övervägde dessutom olika förändringar i maskin- och programvarukonfigurationen, så vi behövde ett sätt att utvärdera dem. Självklart kunde man ha kört etcd i varje konfiguration och tittat på de motsvarande metrikarna från Prometheus, men det skulle kräva betydande insatser. Vi behövde ett enkelt sätt att kunna bedöma en specifik konfiguration. Vi ville kontrollera vår förståelse av de metrikar från Prometheus som kom från etcd.

För detta behövde vi lösa två problem:

För det första, hur ser I/O-belastningen ut som genereras av etcd vid skrivning till WAL-filer? Vilka systemanrop används? Vad är storleken på skrivblocken?
För det andra, anta att vi har svar på ovanstående frågor. Hur kan vi reproducera motsvarande belastning med fio? Ведь fio — ett extremt flexibelt verktyg med många alternativ (detta kan lätt verifieras, till exempel, här — anm. övers.).

Vi löste båda problemen med samma angreppssätt, baserat på kommandon lsof och för att kontrollera paketöverföringen åt båda håll:

Med hjälp av lsof man kan visa alla filbeskrivare som används av processen, samt de filer som de hänvisar till.
Med hjälp av för att kontrollera paketöverföringen åt båda håll man kan analysera en redan körande process eller starta en process och observera den. Kommandot visar alla systemanrop som gjorts av denna process och, vid behov, dess avkommor. Det här är viktigt för processer som forkas, och etcd är en sådan process.

Det första vi gjorde var att använda för att kontrollera paketöverföringen åt båda håll för att studera etcd-servern i Kubernetes-klustret medan den var inaktiv.

Det upptäcktes att skrivblocken i WAL var mycket tätt grupperade, majoriteten låg inom spannet 2200-2400 byte. Det är därför flaggan --bs=2300 (bs — storleken i byte på varje skrivblock i fio).

Observera att storleken på skrivblocken i etcd kan variera beroende på version, deployment, parameterinställningar och så vidare — detta påverkar varaktigheten. fdatasync. Om du har ett liknande användarscenario, analysera för att kontrollera paketöverföringen åt båda håll dina etcd-processer för att få aktuella värden.

Sedan, för att få en tydlig och heltäckande bild av hur etcd arbetar med filsystemet, körde vi det med för att kontrollera paketöverföringen åt båda håll med flaggorna -ffttT. Detta gjorde det möjligt att täcka avkommande processer och skriva utdata av varje i en separat fil. Dessutom fick vi detaljerad information om när varje systemanrop startade och hur länge de varade.

Vi använde också kommandot lsof, för att bekräfta vår förståelse av utskriften för att kontrollera paketöverföringen åt båda håll när det gäller vilken filbeskrivare som användes för vilket syfte. Utskriften blev för att kontrollera paketöverföringen åt båda håll, liknande den som ges ovan. Statistiska manipulationer av synkroniseringstider bekräftade att mätningen wal_fsync_duration_seconds från etcd motsvarar anropen fdatasync med filbeskrivare för WAL-filer.

För att generera med hjälp av fio Arbetsbelastningen, som liknar belastningen från etcd, granskades i dokumentationen för verktyget och parametrarna anpassades till vår uppgift. Vi bekräftade att de nödvändiga systemanropen användes och verifierade deras varaktighet genom att köra fio från för att kontrollera paketöverföringen åt båda håll (på samma sätt som det gjordes för etcd).

Särskild uppmärksamhet ägnades åt att bestämma värdet av parametern --size. Det representerar den totala I/O-belastningen som genereras av verktyget fio. I vårt fall är det det totala antalet byte som skrivs till enheten. Det är direkt proportionellt mot antalet anrop skriv (och fdatasync). För ett visst bs antal anrop fdatasync är lika med size / bs.

Eftersom vi var intresserade av percentilen strävade vi efter att antalet prov skulle vara tillräckligt stort för statistisk signifikans. Vi beslutade att 10^4 (vilket motsvarar en storlek på 22 MB) skulle vara tillräckligt. Mindre värden på parametern --size gav mer uttalad brus (till exempel anrop fdatasync, som tar mycket mer tid än vanligt och påverkar 99:e percentilen).

Nu är det upp till er

Artikeln visar hur man med hjälp av fio kan bedöma om en enhet som är avsedd för användning med etcd är tillräckligt snabb. Nu är det upp till er! Ni kan utforska virtuella maskiner med SSD-baserad lagring i tjänsten IBM Cloud.

P.S. från översättaren

Med färdiga exempel på användning fio för att lösa andra uppgifter kan ni bekanta er med dokumentationen eller direkt i projektets repository (där det finns många fler än som nämns i dokumentationen).