Lagringshastighet lämplig för etcd? Låt oss fråga fio

En kort berättelse om fio och etcd

Klustrets prestanda ETCD beror till stor del på prestandan för dess lagring. etcd exporterar vissa mätvärden till Prometheusför att tillhandahålla den önskade lagringsprestandainformationen. Till exempel måttet wal_fsync_duration_seconds. Dokumentationen för etcd säger: För att lagring ska anses vara tillräckligt snabb måste den 99:e percentilen för detta mått vara mindre än 10ms. Om du planerar att köra ett etcd-kluster på Linux-maskiner och vill utvärdera om din lagring är tillräckligt snabb (t.ex. SSD), kan du använda Fio är ett populärt verktyg för att testa I/O-operationer. Kör följande kommando, där test-data är katalogen under lagringsmonteringspunkten:

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

Du behöver bara titta på resultaten och kontrollera att den 99:e percentilen av varaktigheten fdatasync mindre än 10 ms. Om så är fallet har du ganska snabb lagring. Här är ett exempel på resultaten:

  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]

Anteckningar

• Vi har anpassat alternativen --size och --bs för vårt specifika scenario. För att få ett användbart resultat från fio, ange dina egna värderingar. Var får man tag i dem? Läsa hur vi lärde oss att konfigurera fio.
• Under testning kommer all I/O-belastning från fio. I ett verkligt scenario kommer det sannolikt att komma andra skrivförfrågningar in i lagringen förutom de som är relaterade till wal_fsync_duration_seconds. Den extra belastningen kommer att öka värdet på wal_fsync_duration_seconds. Så om den 99:e percentilen är nära 10ms, håller ditt lagringsutrymme på att ta slut.
• Ta versionen Fio inte lägre än 3.5 (de tidigare visar inte fdatasync varaktighetspercentiler).
• Ovan är bara ett axplock av resultaten från fio.

Lång berättelse om fio och etcd

Vad är WAL i etcd

Vanligtvis använder databaser framskrivningslogg; etcd använder det också. Vi kommer inte att diskutera WAL-loggen i detalj här. Det räcker för oss att veta att varje medlem i etcd-klustret håller det i beständig lagring. etcd skriver varje nyckel-värde operation (som en uppdatering) till WAL innan den appliceras på butiken. Om en av lagringsmedlemmarna kraschar och startar om mellan ögonblicksbilder, kan den lokalt återställa transaktioner sedan den senaste ögonblicksbilden av WAL-innehåll.

När en klient lägger till en nyckel till nyckel-värdelagret eller uppdaterar värdet på en befintlig nyckel, registrerar etcd operationen i WAL, som är en vanlig fil i beständig lagring. etcd MÅSTE vara helt säker på att WAL-posten faktiskt inträffade innan du fortsätter med bearbetningen. På Linux räcker det inte med ett systemanrop för detta. skriva, eftersom själva skrivningen till fysisk lagring kan bli försenad. Till exempel kan Linux lagra en WAL-post i en cache i kärnminnet (som en sidcache) under en tid. Och för att data ska skrivas korrekt till beständig lagring, behövs fdatasync-systemanropet efter skrivningen, och etcd använder det bara (som du kan se i resultatet av arbetet strace, där 8 är WAL-filbeskrivningen):

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>

Tyvärr händer det inte omedelbart att skriva till beständig lagring. Om fdatasync-anropet är långsamt kommer prestanda för etcd-systemet att lida. Dokumentationen för etcd sägeratt lagringen anses vara tillräckligt snabb om, i den 99:e percentilen, fdatasync-anrop tar mindre än 10ms att skriva till WAL-filen. Det finns andra användbara mått för lagring, men i det här inlägget pratar vi bara om detta mått.

Uppskattning av förvaring med fio

Om du behöver utvärdera om din lagring är lämplig för etcd, använd fio, ett mycket populärt I/O-lasttestverktyg. Man bör komma ihåg att diskoperationer kan vara väldigt olika: synkrona och asynkrona, många klasser av systemanrop, etc. Som ett resultat är fio ganska svårt att använda. Den har många parametrar, och olika kombinationer av deras värden ger väldigt olika I/O-arbetsbelastningar. För att få tillräckliga siffror för etcd bör du se till att testskrivbelastningen från fio är så nära den faktiska belastningen från etcd som möjligt när du skriver WAL-filer.

Därför bör fio, som ett minimum, skapa en belastning av en serie sekventiella skrivningar till filen, varje skrivning kommer att bestå av ett systemanrop skrivaföljt av systemanropet fdatasync. Sekventiell skrivning till fio kräver alternativet --rw=write. För fio att använda skrivsystemet anrop när du skriver, snarare än skriva, bör du ange parametern --ioengine=sync. Slutligen, för att anropa fdatasync efter varje skrivning, måste du lägga till parametern --fdatasync=1. De andra två alternativen i det här exemplet (--size och -bs) är skriptspecifika. I nästa avsnitt visar vi dig hur du ställer in dem.

Varför fio och hur vi lärde oss att sätta upp det

I det här inlägget beskriver vi ett verkligt fall. Vi har ett kluster Kubernetes v1.13 som vi övervakade med Prometheus. etcd v3.2.24 var värd på en SSD. Etcd-mått visade att fdatasync-latenserna var för höga, även när klustret inte gjorde något. Mätvärdena var konstiga och vi visste inte riktigt vad de betydde. Klustret bestod av virtuella maskiner, det var nödvändigt att förstå vad problemet var: i fysiska SSD:er eller i virtualiseringslagret. Dessutom gjorde vi ofta ändringar i hård- och mjukvarukonfigurationen, och vi behövde ett sätt att utvärdera deras resultat. Vi skulle kunna köra etcd i alla konfigurationer och titta på Prometheus-mått, men det är för mycket krångel. Vi letade efter ett ganska enkelt sätt att utvärdera en specifik konfiguration. Vi ville kontrollera om vi förstår Prometheus-mått från etcd korrekt.

Men för detta måste två problem lösas. För det första, hur ser I/O-belastningen ut som etcd skapar när man skriver till WAL? Vilka systemanrop används? Hur stor är skivorna? För det andra, om vi svarar på dessa frågor, hur återskapar vi en liknande arbetsbelastning med fio? Glöm inte att fio är ett väldigt flexibelt verktyg med många alternativ. Vi löste båda problemen med ett tillvägagångssätt - med hjälp av kommandona lsof и strace. lsof listar alla filbeskrivningar som används av processen och deras associerade filer. Och med strace kan du undersöka en redan pågående process, eller starta en process och undersöka den. strace skriver ut alla systemanrop från den process som undersöks (och dess underordnade processer). Det senare är mycket viktigt, eftersom etcd bara tar ett liknande tillvägagångssätt.

Vi använde först strace för att utforska etcd-servern för Kubernetes när det inte fanns någon belastning på klustret. Vi såg att nästan alla WAL-poster var ungefär lika stora: 2200–2400 byte. Därför angav vi i kommandot i början av inlägget parametern -bs=2300 (bs betyder storleken i byte för varje fio-post). Observera att storleken på etcd-posten beror på etcd-versionen, distributionen, parametervärden, etc., och påverkar fdatasync-varaktigheten. Om du har ett liknande scenario, undersök dina etcd-processer med strace för att ta reda på de exakta siffrorna.

Sedan, för att få en god uppfattning om vad etcd-filsystemet gör, startade vi det med strace och -ffttT-alternativen. Så vi försökte undersöka de underordnade processerna och registrera utdata från var och en av dem i en separat fil, och även få detaljerade rapporter om starten och varaktigheten av varje systemsamtal. Vi använde lsof för att bekräfta vår analys av strace-utgången och se vilken filbeskrivning som användes för vilket ändamål. Så med hjälp av strace erhölls resultaten som visas ovan. Synkroniseringstidsstatistik bekräftade att wal_fsync_duration_seconds från etcd överensstämmer med fdatasync-anrop med WAL-fildeskriptorer.

Vi gick igenom dokumentationen för fio och valde alternativ för vårt script så att fio skulle generera en laddning liknande etcd. Vi kontrollerade också systemanrop och deras varaktighet genom att köra fio från strace, liknande etcd.

Vi har noggrant valt värdet på parametern --size för att representera hela I/O-belastningen från fio. I vårt fall är detta det totala antalet byte som skrivits till lagringen. Det visade sig vara direkt proportionellt mot antalet skriv- (och fdatasync) systemanrop. För ett visst värde på bs är antalet fdatasync-anrop = storlek/bs. Eftersom vi var intresserade av percentilen var vi tvungna att ha tillräckligt med prover för att vara säkra, och vi beräknade att 10^4 skulle räcka för oss (det är 22 mebibyte). Om --size är mindre kan extremvärden inträffa (till exempel tar flera fdatasync-anrop längre tid än vanligt och påverkar den 99:e percentilen).

Prova själv

Vi visade dig hur du använder fio och ser om lagringen är tillräckligt snabb för att etcd ska fungera bra. Nu kan du prova det själv med hjälp av till exempel virtuella maskiner med SSD-lagring i IBM Cloud.

Källa: will.com