🥇Hur man kontrollerar diskar med fio för tillräcklig prestanda för etcd

Notera. transl.: Den här artikeln är resultatet av en miniforskning utförd av IBM Cloud-ingenjörer i jakt på en lösning på ett verkligt problem relaterat till driften av etcd-databasen. En liknande uppgift var relevant för oss, men författarnas reflektioner och agerande kan vara intressant i ett bredare sammanhang.

Kort sammanfattning av hela artikeln: fio och etcd

Prestandan för ett etcd-kluster är starkt beroende av hastigheten på den underliggande lagringen. etcd exporterar olika Prometheus-mått för att övervaka prestanda. En av dem är wal_fsync_duration_seconds. I dokumentationen för etcd det ståratt lagringen kan anses vara tillräckligt snabb om den 99:e percentilen för detta mått inte överstiger 10 ms...

Om du funderar på att sätta upp ett etcd-kluster på Linux-maskiner och vill kontrollera om enheter (som SSD-enheter) är tillräckligt snabba rekommenderar vi att du använder den populära I/O-testaren som heter Fio. Det räcker att köra följande kommando (katalog test-data måste finnas i den monterade partitionen på den testade enheten):

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

Det återstår bara att titta på utdata och kontrollera om den 99:e percentilen passar fdatasync om 10 ms. Om så är fallet, fungerar din enhet 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 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]

Några anteckningar:

I exemplet ovan har vi justerat parametrarna --size и --bs för ett specifikt fall. För att få ett meningsfullt resultat av fio, ange värden som är lämpliga för ditt användningsfall. Hur man väljer dem kommer att diskuteras nedan.
Endast under testning fio laddar diskundersystemet. I det verkliga livet är det troligt att andra processer kommer att skriva till disk (förutom de som är relaterade till wal_fsync_duration_seconds). Denna extra belastning kan öka wal_fsync_duration_seconds. Med andra ord, om den 99:e percentilen från att testa med fio, bara något mindre än 10 ms, det finns en god chans att lagringsprestanda inte är tillräcklig.
För testet behöver du versionen fio inte lägre än 3.5, eftersom äldre versioner inte samlar resultat fdatasync i form av percentiler.
Ovanstående slutsats är bara ett litet utdrag ur den allmänna slutsatsen fio.

Mer om fio och etcd

Några ord om WALs etcd

I allmänhet använder databaser proaktiv loggning (Write-ahead-loggning, WAL). etcd påverkas också. En diskussion om WAL ligger utanför ramen för denna artikel, men för våra syften behöver vi veta följande: varje medlem i etcd-klustret lagrar WAL i beständig lagring. etcd skriver några nyckel-värdelagringsoperationer (som uppdateringar) till WAL innan de körs. Om en nod kraschar och startar om mellan ögonblicksbilder, kan etcd återställa transaktioner sedan föregående ögonblicksbild baserat på innehållet i WAL.

Sålunda, varje gång en klient lägger till en nyckel till KV-minnet eller uppdaterar värdet på en befintlig nyckel, etcd lägger till beskrivningen av operationen till WAL, som är en vanlig fil i det persistenta lagret. etcd MÅSTE vara 100 % säker på att WAL-posten verkligen har sparats innan du fortsätter. För att uppnå detta på Linux räcker det inte att använda systemanropet writeeftersom själva skrivoperationen till det fysiska mediet kan försenas. Till exempel kan Linux behålla en WAL-post i en kärncache i minnet (t.ex. i sidcachen) under en tid. För att säkerställa att data skrivs till media måste ett systemanrop anropas efter skrivningen fdatasync - det här är precis vad etcd gör (som du kan se i följande utdata strace; Här 8 - WAL-filbeskrivning):

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>

Tyvärr tar det lite tid att skriva till beständig lagring. Långvarig körning av fdatasync-anrop kan påverka prestanda för etcd. I förvarets dokumentation anges, att för tillräcklig prestanda är det nödvändigt att den 99:e percentilen av varaktigheten för alla samtal fdatasync vid skrivning till en WAL-fil var mindre än 10 ms. Det finns andra lagringsrelaterade mätvärden, men den här artikeln kommer att fokusera på den.

Värdera förråd med fio

Du kan utvärdera om en viss lagring är lämplig för användning med etcd med hjälp av verktyget Fio — en populär I/O-testare. Tänk på att disk I/O kan ske på många olika sätt: synk/asynkron, många olika syscall-klasser och så vidare. Den andra sidan av myntet är det fio extremt svår att använda. Verktyget har många parametrar, och olika kombinationer av deras värden leder till helt olika resultat. För att få en rimlig uppskattning för etcd måste du se till att skrivbelastningen som genereras av fio är så nära som möjligt etcd:s WAL-fil skrivbelastning:

Detta innebär att den genererade fio laddningen bör åtminstone vara en serie av på varandra följande skrivningar till filen, där varje skrivning består av ett systemanrop writeföljd av fdatasync.
För att aktivera sekventiell skrivning måste du ange flaggan --rw=write.
Att fio skrev med samtal write (istället för andra systemanrop - t.ex. pwrite), använd flaggan --ioengine=sync.
Äntligen flaggan --fdatasync=1 säkerställer att varje write måste vara fdatasync.
De andra två parametrarna i vårt exempel är: --size и --bs - kan variera beroende på det specifika användningsfallet. Nästa avsnitt kommer att beskriva deras konfiguration.

Varför vi valde fio och hur vi lärde oss hur man ställer in det

Den här anteckningen kommer från ett verkligt fall vi stött på. Vi hade ett kluster på Kubernetes v1.13 med övervakning på Prometheus. SSD-enheter användes som lagring för etcd v3.2.24. Etcd-mått visade för höga latenser fdatasync, även när klustret var inaktivt. För oss verkade dessa mätvärden mycket tveksamma och vi var inte säkra på exakt vad de representerade. Dessutom bestod klustret av virtuella maskiner, så det gick inte att säga om förseningen berodde på virtualisering eller om SSD:n var skyldig.

Dessutom övervägde vi olika förändringar i hård- och mjukvarukonfigurationen, så vi behövde ett sätt att utvärdera dem. Naturligtvis skulle det vara möjligt att köra etcd i varje konfiguration och titta på motsvarande Prometheus-mått, men det skulle kräva betydande ansträngning. Det vi behövde var ett enkelt sätt att utvärdera en specifik konfiguration. Vi ville testa vår förståelse för Prometheus-måtten som kommer från etcd.

Detta krävde att lösa två problem:

För det första, hur ser I/O-belastningen som genereras av etcd när man skriver till WAL-filer ut? Vilka systemanrop används? Vad är storleken på postblocken?
För det andra, låt oss säga att vi har svar på ovanstående frågor. Hur man återger motsvarande belastning med fio? Trots allt fio — extremt flexibelt verktyg med ett överflöd av parametrar (detta är lätt att verifiera, t.ex. här - cirka. översätt.).

Vi löste båda problemen med samma kommandobaserade tillvägagångssätt lsof и strace:

Med lsof du kan se alla filbeskrivningar som används av processen, såväl som filerna de refererar till.
Med strace du kan analysera en redan pågående process eller köra en process och titta på den. Kommandot visar alla systemanrop som gjorts av denna process och, om nödvändigt, dess ättlingar. Det sistnämnda är viktigt för processer som är forking, och etcd är en sådan process.

Det första vi gjorde var att använda strace för att undersöka etcd-servern i Kubernetes-klustret medan den var inaktiv.

Så det visade sig att WAL-postblock är mycket tätt grupperade, storleken på majoriteten låg i intervallet 2200-2400 byte. Det är därför kommandot i början av denna artikel använder flaggan --bs=2300 (bs är storleken i byte för varje skrivblock in fio).

Observera att storleken på etcd-skrivblock kan variera beroende på version, distribution, parametervärden etc. - det påverkar varaktigheten fdatasync. Om du har ett liknande användningsfall, analysera med strace dina etcd-processer för att få aktuella värden.

Sedan, för att få en tydlig och heltäckande uppfattning om hur etcd fungerar med filsystemet, startade vi det från under strace med flaggor -ffttT. Detta gjorde det möjligt att fånga underordnade processer och skriva utdata från varje till en separat fil. Dessutom erhölls detaljerad information om starttid och varaktighet för varje systemanrop.

Vi använde också kommandot lsofför att bekräfta din förståelse av resultatet strace när det gäller vilken filbeskrivning som användes för vilket ändamål. Jag fick slutsatsen strace, liknande den ovan. Statistiska manipulationer med synkroniseringstider bekräftade att måttet wal_fsync_duration_seconds från etcd matchar samtal fdatasync med WAL-filbeskrivningar.

Att generera med fio en arbetsbelastning liknande den från etcd, dokumentationen av verktyget studerades och de parametrar som lämpade sig för vår uppgift valdes ut. Vi har verifierat att rätt systemsamtal pågår och bekräftat deras varaktighet genom att köra fio av strace (som det gjordes vid etcd).

Särskild uppmärksamhet ägnades åt att bestämma parameterns värde --size. Den representerar den totala I/O-belastningen som genereras av fio-verktyget. I vårt fall är detta det totala antalet byte som skrivits till media. Det är direkt proportionellt mot antalet samtal write (och fdatasync). För en specifik bs antal samtal fdatasync är size / bs.

Eftersom vi var intresserade av percentilen ville vi att antalet stickprov skulle vara tillräckligt stort för att vara statistiskt signifikant. Och bestämde det 10^4 (vilket motsvarar en storlek på 22 MB) kommer att räcka. Mindre parametervärden --size gav mer uttalat ljud (till exempel samtal fdatasync, vilket tar mycket längre tid än vanligt och påverkar 99:e percentilen).

Det är upp till dig

Artikeln visar hur du använder fio man kan bedöma om de medier som är avsedda att användas med etcd är tillräckligt snabba. Nu är det upp till dig! Du kan utforska virtuella maskiner med SSD-baserad lagring i tjänsten IBM Cloud.

PS från översättaren

Med färdiga användningsfall fio För andra uppgifter, se dokumentation eller direkt till projektförråd (det finns många fler av dem än vad som nämns i dokumentationen).

PPS från översättaren

Läs även på vår blogg:

Källa: will.com

Hur man kontrollerar diskar med fio för tillräcklig prestanda för etcd