Är lagringshastigheten tillräcklig för etcd? Vi frågar fio

En kort historia om fio och etcd

Prestanda för klustret i den motsvarande Docker-bilden beror i stor utsträckning på prestandan hos dess lagring. etcd exporterar vissa mätvärden till Prometheus, för att ge nödvändig information om lagringsprestanda. Till exempel mätvärdet wal_fsync_duration_seconds. Dokumentationen för etcd säger: för att lagringen ska anses tillräckligt snabb, måste 99:e percentilen av detta mätvärde vara mindre än 10 ms. Om du planerar att köra ett etcd-kluster på Linux-maskiner och vill bedöma om din lagring är tillräckligt snabb (till exempel SSD), kan du använda fio — ett populärt verktyg för att testa in- och utmatningsoperationer. Kör följande kommando, där test-data är en katalog under monteringspunkten för lagringen:

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 99:e percentilen av varaktigheten fdatasync är mindre än 10 ms. Om så är fallet, har du tillräckligt snabb lagring. Här är ett exempel på resultat:

  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]

Anteckningar

• Vi har konfigurerat parameterstorlekarna —size och —bs för vårt specifika scenario. För att få användbara resultat från fio, ange dina värden. Var får man dem ifrån? Läs, hur vi lärde oss att konfigurera fio.
• Under testning kommer hela in- och utmatningsbelastningen från fio. I ett verkligt scenario kommer det förmodligen också att komma andra skrivförfrågningar till lagringen, utöver de som är relaterade till wal_fsync_duration_seconds. Ytterligare belastning ökar värdet på wal_fsync_duration_seconds. Så om 99:e percentilen nästan når 10 ms, kommer din lagring inte att vara tillräckligt snabb.
• Använd version fio inte lägre än 3.5 (tidigare versioner visar inte percentiler av varaktigheten för fdatasync).
• Ovanstående visar endast ett urval av resultaten från fio.

En lång historia om fio och etcd

Vad är WAL i etcd

Vanligtvis använder databaser journal med förhandsinspelning; etcd använder också det. Här kommer vi inte att diskutera journalen för write-ahead log (WAL) i detalj. Vi behöver bara veta att varje medlem av etcd-klustret håller den i ett permanent lagringsutrymme. etcd registrerar varje operation med nyckel-värde-par (till exempel uppdatering) i WAL innan de tillämpas i lagringen. Om en av medlemmarna i lagringen kraschar och startar om mellan ögonblicksbilder kan den återställa transaktioner lokalt från den senaste ögonblicksbilden baserat på innehållet i WAL.

När en klient lägger till en nyckel i nyckel-värde-lagringen eller uppdaterar värdet av en befintlig nyckel, gör etcd en post om denna operation i WAL, vilket är en vanlig fil i det permanenta lagringsutrymmet. Innan etcd fortsätter behandlingen MÅSTE det vara helt säkert på att posten i WAL verkligen har gjorts. I Linux räcker det inte med ett enda systemanrop. skriv, eftersom själva skrivningen till det fysiska lagringsutrymmet kan fördröjas. Till exempel kan Linux hålla posten i WAL i minnescache (som sidcache) en tid. För att säkerställa att data skrivs till det permanenta lagringsutrymmet krävs ett systemanrop fdatasync efter skrivningen, och etcd använder precis det (som kan ses i resultatet av för att kontrollera paketöverföringen åt båda håll, där 8 är filbeskrivaren för 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

Tyvärr sker skrivningen till det permanenta lagringsutrymmet inte omedelbart. Om fdatasync-anropet går långsamt sänks prestandan för etcd-systemet. I dokumentationen för etcd står det, att lagringen anses vara tillräckligt snabb om 99:e percentiler av fdatasync-anrop vid skrivning till WAL-filen tar mindre än 10 ms. Det finns även andra användbara metrikar för lagringen, men i det här inlägget pratar vi endast om denna metrik.

Utvärdering av lagringen med hjälp av fio

Om du behöver bedöma om ditt lagringsutrymme är lämpligt för etcd, använd fio — ett mycket populärt verktyg för att testa insignal- och utsignalbelastningar. Det är viktigt att komma ihåg att diskoperationer kan vara av många olika slag: synkrona och asynkrona, ett flertal klasser av systemanrop osv. Som en följd av detta är fio ganska svårt att använda. Det har många parametrar, och olika kombinationer av dessa värden ger helt olika insignal- och utsignalbelastningar. För att få adekvata siffror för etcd bör du säkerställa att testbelastningen för skrivning från fio ligger så nära den verkliga belastningen från etcd vid skrivning av WAL-filer som möjligt.

Därför bör fio åtminstone skapa en belastning av en sekvens av sekventiella skrivoperationer till en fil, där varje skrivning kommer att bestå av ett systemanrop skriv, följt av systemanropet fdatasync. För sekventiella skrivoperationer behöver fio parametern —rw=write. För att fio ska använda systemanropet write vid skrivning, istället för pwrite, bör du ange parametern —ioengine=sync. Slutligen, för att fdatasync ska kallas efter varje skrivning, måste du lägga till parametern —fdatasync=1. De två andra parametrarna i det här exemplet (—size och —bs) beror på det specifika scenariot. I nästa avsnitt kommer vi att förklara hur du konfigurerar dem.

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

I det här inlägget beskriver vi ett verkligt fall. Vi hade en kluster Kubernetes v1.13, som vi övervakade med Prometheus. etcd v3.2.24 var placerad på SSD. Metrikerna för etcd visade för höga latenser för fdatasync, även när klustret inte gjorde något. Metrikerna var underliga, och vi visste inte riktigt vad de betydde. Klustret bestod av virtuella maskiner, och vi behövde förstå vad problemet var: i de fysiska SSD:erna eller i virtualiseringslagret. Dessutom gjorde vi ofta ändringar i hårdvaru- och mjukvarukonfigurationen, och vi behövde ett sätt att utvärdera deras resultat. Vi kunde köra etcd i varje konfiguration och titta på Prometheus-metrikerna, men det var för krångligt. Vi sökte efter ett tillräckligt enkelt sätt att utvärdera en specifik konfiguration. Vi ville kontrollera om vi förstod Prometheus-metrikerna för etcd korrekt.

Men för att göra detta behövde vi lösa två problem. För det första, hur ser I/O-belastningen ut som etcd skapar vid skrivning till WAL? Vilka systemanrop används? Vad är storleken på posterna? För det andra, om vi svarar på dessa frågor, hur kan vi återskapa en liknande arbetsbelastning med fio? Tänk på att fio är ett mycket flexibelt verktyg med många parametrar. Vi löste båda problemen med en metod — med hjälp av kommandon. lsof och för att kontrollera paketöverföringen åt båda håll. lsof visar alla filbeskrivare som används av processen samt de filer som är kopplade till dem. Med strace kan vi analysera en redan körande process eller starta en process och studera den. strace skriver ut alla systemanrop från den studerade processen (och dess barnprocesser). Det senare är mycket viktigt, eftersom etcd använder just denna metod.

Först använde vi strace för att studera etcd-servern för Kubernetes när klustret inte hade belastning. Vi såg att nästan alla WAL-poster var ungefär samma storlek: 2200–2400 byte. Därför angav vi i kommandot i början av inlägget parametern —bs=2300 (bs betyder storlek i byte för varje fio-post). Observera att storleken på posterna i etcd beror på versionen av etcd, distributionen, parameterinställningarna osv. och påverkar varaktigheten av fdatasync. Om du har ett liknande scenario, studera dina etcd-processer med hjälp av strace för att få exakta siffror.

Sedan, för att få en bra uppfattning om aktiviteterna i filsystemet för etcd, körde vi den med strace och parametrarna -ffttT. På så sätt försökte vi analysera barnprocesserna och skriva utdata från var och en av dem till en separat fil, samt få detaljerade rapporter om början och varaktigheten av varje systemanrop. Vi använde lsof för att bekräfta vår analys av strace-data och se vilken filbeskrivare som användes för vilka syften. Så, med hjälp av strace, fick vi de resultat som visas ovan. Statistik över synkroniseringstiden bekräftade att wal_fsync_duration_seconds från etcd motsvarar anropen till fdatasync med filbeskrivare från WAL.

Vi studerade dokumentationen för fio och valde parametrar för vårt scenario så att fio skulle generera en belastning som liknar den för etcd. Vi kontrollerade även systemanropen och deras varaktighet genom att köra fio från strace, på samma sätt som med etcd.

Vi har noggrant valt betydelsen av parametern —size, som representerar hela belastningen av in- och utdata från fio. I vårt fall är detta det totala antalet byte som skrivs till lagring. Det visade sig vara direkt proportionellt mot antalet systemanrop write (och fdatasync). För ett visst värde av bs är antalet fdatasync-anrop = size/bs. Eftersom vi var intresserade av percentiler, behövde vi tillräckligt med prov för tillförlitlighet, och vi beräknade att 10^4 skulle vara tillräckligt (det blir 22 mebibyte). Om —size är mindre kan det uppstå utstickare (till exempel kan flera fdatasync-anrop ta längre tid än normalt och påverka den 99:e percentilen).

Prova själv

Vi har visat hur man använder fio och hur man avgör om lagringen har tillräcklig hastighet för hög prestanda i etcd. Nu kan du pröva det i praktiken själv, till exempel med virtuella maskiner med SSD-lagring i IBM Cloud.

Källa: habr.com