🥇Hoe gebruik je fio om de schijven te controleren op voldoende prestaties voor etcd

Opmerking vertaler.: Dit artikel is de uitkomst van een mini-onderzoek uitgevoerd door IBM Cloud-engineers, op zoek naar een oplossing voor een echt probleem met de werking van de etcd-database. Voor ons was een soortgelijke taak relevant, maar de redenering en acties van de auteurs kunnen ook in een bredere context interessant zijn.

Korte samenvatting van het hele artikel: fio en etcd

De prestaties van de etcd-cluster zijn sterk afhankelijk van de snelheid van de onderliggende opslag. Om de prestaties van etcd te controleren, exporteert het verschillende Prometheus-statistieken. Een daarvan is wal_fsync_duration_seconds. In de documentatie van etcd staat, dat de opslag als snel genoeg kan worden beschouwd als de 99e percentiel van deze statistiek niet meer dan 10 ms bedraagt…

Als u nadenkt over de mogelijkheid om een etcd-cluster op machines met Linux op te zetten en wilt controleren of de opslag snel genoeg is (bijvoorbeeld SSD's), raden we aan gebruik te maken van een populaire I/O-tester genaamd fio. Voer eenvoudig de volgende opdracht uit (de map test-data moet zich bevinden op de aangekoppelde schijf die u test):

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

Vervolgens kunt u de uitvoer bekijken en controleren of de 99e percentiel van fdatasync binnen de 10 ms valt. Als dat zo is, werkt uw opslag voldoende snel. Hier is een voorbeeld van de uitvoer:

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]

Enkele opmerkingen:

In het bovenstaande voorbeeld hebben we de parameters --size en --bs aangepast aan de specifieke situatie. Om een zinvolle uitkomst van fiote krijgen, gebruik waarden die geschikt zijn voor uw gebruiksscenario. Hoe u deze kunt kiezen, wordt hieronder uitgelegd.
Tijdens de test is alleen fio de schijfsysteem belast. In de echte wereld is het goed mogelijk dat andere processen ook op de schijf schrijven (naast degenen die gerelateerd zijn aan wal_fsync_duration_seconds). Deze extra belasting kan leiden tot een verhoogde wal_fsync_duration_seconds. Met andere woorden, als de 99e percentiel verkregen uit de test met fio, slechts iets onder de 10 ms ligt, is de kans groot dat de prestaties van de opslag onvoldoende zijn.
Voor de test heeft u een versie nodig fio niet minder dan 3,5, omdat oudere versies de resultaten niet aggregeren fdatasync in de vorm van percentielen.
Bovenstaand resultaat is slechts een klein fragment van de totale output fio.

Meer informatie over fio en etcd

Enkele woorden over de WAL's van etcd

Over het algemeen gebruiken databases write-ahead logging (write-ahead logging, WAL). Dit geldt ook voor etcd. De discussie over WAL valt buiten het bereik van dit artikel, maar voor onze doeleinden is het belangrijk om te weten: elk lid van de etcd-cluster slaat WAL op in persistentieopslag. etcd registreert bepaalde operaties met de key-value-opslag (bijvoorbeeld updates) in WAL voordat ze worden uitgevoerd. Als een knooppunt uitvalt en opnieuw opstart tussen snapshots, kan etcd transacties herstellen die zijn uitgevoerd sinds de vorige snapshot, gebaseerd op de inhoud van WAL.

Telkens wanneer een klant een sleutel toevoegt aan de KV-opslag of de waarde van een bestaande sleutel bijwerkt, voegt etcd een beschrijving van de operatie toe aan WAL, wat een gewoon bestand is in persistentieopslag. Voordat het zijn werk kan voortzetten, moet etcd 100% zeker zijn dat de registratie in WAL daadwerkelijk is opgeslagen. Om dit in Linux te garanderen, is het niet genoeg om de systeemaanroep writete gebruiken, omdat de schrijfbewerking op het fysieke apparaat kan worden uitgesteld. Bijvoorbeeld, Linux kan enige tijd de WAL-schrijfactie in de kernelcache in het geheugen houden (bijvoorbeeld in de paginacache). Om te garanderen dat de gegevens op het opslagmedium zijn geschreven, moet na het schrijven de systeemaanroep worden aangeroepen fdatasync — dat is wat etcd doet (zoals te zien is in het volgende output strace; hier 8 — bestandshandle 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

Helaas duurt het enige tijd om naar persistentieopslag te schrijven. Een vertraagde uitvoering van de fdatasync-aanroep kan de prestaties van etcd beïnvloeden. In de documentatie van de opslag wordt aangegeven, dat voor voldoende prestaties de 99e percentiel van de duur van alle aanroepen fdatasync bij het schrijven naar het WAL-bestand minder dan 10 ms moet zijn. Er zijn andere statistieken die met de opslag verband houden, maar dit artikel richt zich specifiek op deze.

We evalueren de opslag met fio

U kunt de geschiktheid van een bepaalde opslag voor gebruik met etcd beoordelen met behulp van de tool fio — een populaire I/O-tester. Houd er rekening mee dat schijf-I/O op verschillende manieren kan plaatsvinden: sync/async, verschillende klassen systeemaanroepen, enz. De schaduwkant is dat fio het extreem moeilijk is in gebruik. De tool heeft veel parameters, en verschillende combinaties van deze waarden leiden tot volkomen verschillende resultaten. Om een redelijke beoordeling te krijgen in het geval van etcd, moet u ervoor zorgen dat de schrijflast die door fio wordt gegenereerd, zoveel mogelijk lijkt op de last van etcd bij het schrijven naar WAL-bestanden:

Dit betekent dat de gegenereerde fio last in ieder geval een reeks opeenvolgende schrijfacties naar een bestand moet zijn, waarbij elke schrijfoperatie bestaat uit een systeemaanroep write, gevolgd door fdatasync.
Om opeenvolgend schrijven in te schakelen, moet u de vlag opgeven --rw=write.
Om fio schrijven met systeemaanroepen write (en niet andere systeemaanroepen — bijvoorbeeld, pwrite), gebruik de vlag --ioengine=sync.
Ten slotte zorgt de vlag --fdatasync=1 ervoor dat er na elke write volgt fdatasync.
Twee andere parameters in ons voorbeeld: --size en --bs — kunnen variëren afhankelijk van het specifieke gebruiksscenario. In de volgende sectie wordt hun configuratie beschreven.

Waarom we fio hebben gekozen en waar we hebben geleerd hoe we het moeten configureren

Deze notitie kwam voort uit een echte situatie waar we mee te maken hadden. We hadden een cluster op Kubernetes v1.13 met monitoring op Prometheus. Solid-state drives dienden als opslag voor etcd v3.2.24. De metrics van etcd toonden te hoge latenties aan fdatasync, zelfs wanneer het cluster inactief was. We vonden deze statistieken zeer twijfelachtig, en we waren niet zeker wat ze precies vertegenwoordigden. Bovendien bestond het cluster uit virtuele machines, dus het was niet mogelijk om te zeggen of de latentie verband hield met virtualisatie of dat alle problemen voortkwamen uit de SSD's.

Bovendien hebben we verschillende wijzigingen in de hardware- en softwareconfiguraties overwogen, dus er was een manier nodig om deze te evalueren. Natuurlijk zou het mogelijk zijn om etcd in elke configuratie te starten en naar de overeenkomstige Prometheus-metrieken te kijken, maar dat zou aanzienlijke inspanningen vergen. We hadden een eenvoudige manier nodig om een specifieke configuratie te beoordelen. We wilden onze begrip van de Prometheus-metrieken die van etcd komen, testen.

Hiervoor moesten we twee problemen oplossen:

Ten eerste, hoe ziet de I/O-belasting eruit die door etcd wordt gegenereerd bij het schrijven naar WAL-bestanden? Welke systeemoproepen worden gebruikt? Wat is de grootte van de schrijfblokken?
Ten tweede, laten we aannemen dat we de antwoorden op de bovenstaande vragen hebben. Hoe reproduceren we de overeenkomstige belasting met fio? Ведь fio — een uiterst flexibele tool met een overvloed aan parameters (dit is gemakkelijk te verifiëren, bijvoorbeeld, hier — vert. opm.).

We hebben beide problemen opgelost met hetzelfde aanpak, gebaseerd op de commando's lsof en strace:

Met lsof je kunt alle bestandshandles bekijken die door het proces worden gebruikt, en ook de bestanden waar ze betrekking op hebben.
Met strace je kunt een al draaiend proces analyseren of een proces starten en het in de gaten houden. De opdracht geeft alle systeemoproepen weer die door dit proces zijn gedaan en, indien nodig, zijn nakomelingen. Dit laatste is belangrijk voor processen die forked, en etcd is zo'n proces.

Het eerste wat we deden, was gebruiken strace om de etcd-server in het Kubernetes-cluster te bestuderen terwijl deze idle was.

Daarbij werd ontdekt dat de schrijfblokken in de WAL zeer dicht gegroepeerd zijn, de meeste liggen in het bereik van 2200-2400 bytes. Daarom wordt in het commando aan het begin van dit artikel de vlag gebruikt --bs=2300 (bs — de grootte in bytes van elk schrijfblok in fio).

Houd er rekening mee dat de grootte van de schrijfblokken in etcd kan variëren afhankelijk van de versie, de implementatie, parameterwaarden, enz. — dit beïnvloedt de duur fdatasync. Als je een vergelijkbaar gebruiksscenario hebt, analyseer dan met strace je etcd-processen om actuele waarden te verkrijgen.

Daarna, om een duidelijk en omvattend beeld van de werking van etcd met het bestandssysteem te krijgen, hebben we het uitgeruimd met strace met de vlaggen -ffttT. Dit maakte het mogelijk om kindprocessen te omvatten en de uitvoer van elk in een apart bestand vast te leggen. Daarnaast werden gedetailleerde gegevens over het startmoment en de duur van elke systeemaanroep verkregen.

We maakten ook gebruik van het commando lsof, om ons begrip van de uitvoer te bevestigen strace met betrekking tot welke bestandsdescriptor voor welk doel werd gebruikt. De uitvoer was strace, vergelijkbaar met die hierboven weergegeven. Statistische manipulaties van de synchronisatietijden bevestigden dat de metriek wal_fsync_duration_seconds van etcd overeenkomt met de aanroepen fdatasync met de WAL-bestandsdescriptoren.

Om samen met fio een werklast te genereren die vergelijkbaar is met die van etcd, werd de documentatie van de tool bestudeerd en werden de parameters geselecteerd die geschikt waren voor onze taak. We hebben bevestigd dat de benodigde systeemaanroepen werden gebruikt en hun duur bevestigd door fio uit strace (zoals gedaan in het geval van etcd).

Bijzondere aandacht werd besteed aan het bepalen van de waarde van de parameter --size. Het vertegenwoordigt de totale I/O-last die door de tool fio wordt gegenereerd. In ons geval is dit het totale aantal bytes dat op het medium is geschreven. Het is recht evenredig met het aantal aanroepen write (en fdatasync). Voor een bepaalde bs aantal aanroepen fdatasync gelijk is aan size / bs.

Aangezien we geïnteresseerd waren in de percentiel, streefden we ernaar dat het aantal monsters groot genoeg was voor statistische significantie. En we besloten dat 10^4 (wat overeenkomt met een grootte van 22 MB) voldoende zou zijn. Kleinere waarden van de parameter --size brachten meer uitgesproken ruis met zich mee (bijvoorbeeld aanroepen fdatasync, die veel langer duren dan normaal en invloed hebben op het 99e percentiel).

Het is aan jou

In het artikel wordt getoond hoe met behulp van fio kan worden geëvalueerd of de draagbare opslag die bedoeld is voor gebruik met etcd snel genoeg is. Nu is het aan jou! Je kunt virtuele machines met SSD-gebaseerde opslag onderzoeken in de service IBM Cloud.

P.S. van de vertaler

Met kant-en-klare voorbeelden van gebruik fio voor het oplossen van andere taken kun je kijken in de documentatie of rechtstreeks in de projectrepository (daar worden er veel meer gepresenteerd dan in de documentatie wordt vermeld).