🥇Is de snelheid van de opslag geschikt voor etcd? Laten we het vragen aan fio

Een kort verhaal over fio en etcd

De prestaties van het cluster etcd zijn voor een groot deel afhankelijk van de prestaties van de opslag. etcd exporteert enkele statistieken naar Prometheus, om de benodigde informatie over de opslagprestaties te verstrekken. Bijvoorbeeld de statistiek wal_fsync_duration_seconds. In de documentatie van etcd staat: om te overwegen dat de opslag snel genoeg is, moet de 99e percentiel van deze statistiek lager zijn dan 10 ms. Als u van plan bent om een etcd-cluster op Linux-machines te draaien en u wilt beoordelen of uw opslag snel genoeg is (bijvoorbeeld SSD), kunt u fio gebruiken - een populair hulpmiddel voor het testen van invoer/uitvoeroperaties. Voer de volgende opdracht uit, waarbij test-data de directory is onder het aanknopingspunt van de opslag:

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

Kijk gewoon naar de resultaten en controleer of de 99e percentiel duur fdatasync lager is dan 10 ms. Als dat het geval is, heeft u voldoende snelle opslag. Hier is een voorbeeld van 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]

Opmerkingen

We hebben de parameters —size en —bs ingesteld voor onze specifieke scenario. Om nuttige resultaten van fio te krijgen, geef uw waarden op. Waar verkrijgt u deze? Lees hoe we fio hebben geconfigureerd.
Tijdens de test komt alle invoer/uitvoerbelasting van fio. In een realistisch scenario zullen er waarschijnlijk ook andere schrijfbewerkingen op de opslag plaatsvinden, naast diegene die verband houden met wal_fsync_duration_seconds. Extra belasting zal de waarde van wal_fsync_duration_seconds verhogen. Dus als de 99e percentiel bijna 10 ms bereikt, is uw opslag niet snel genoeg.
Neem versie fio niet minder dan 3,5 eerdere versies tonen geen percentielen van fdatasync-duur).
Boven staat alleen een fragment van de resultaten van fio.

Een lang verhaal over fio en etcd

Wat is WAL in etcd

Gewoonlijk gebruiken databases write-ahead log; etcd gebruikt het ook. Hier zullen we de write-ahead log (WAL) niet in detail bespreken. Het is voldoende om te weten dat elk lid van de etcd-cluster deze in permanente opslag bijhoudt. etcd registreert elke operatie met sleutel-waarde paren (bijvoorbeeld een update) in de WAL voordat ze in de opslag worden toegepast. Als een van de leden van de opslag tussen snapshots onverwacht uitvalt en opnieuw opstart, kan het lokaal transacties herstellen vanaf het laatste snapshot aan de hand van de inhoud van de WAL.

Wanneer een klant een sleutel toevoegt aan de opslag van sleutel-waarde paren of de waarde van een bestaande sleutel bijwerkt, maakt etcd een record van deze operatie in de WAL, die een gewoon bestand is in de permanente opslag. Voordat etcd de verwerking voortzet, MOET het er volledig zeker van zijn dat de opname in de WAL daadwerkelijk heeft plaatsgevonden. In Linux is het niet voldoende om slechts één systeemaanroep te doen. write, omdat de opname in de fysieke opslag in werkelijkheid kan worden uitgesteld. Bijvoorbeeld, Linux kan op een bepaald moment de WAL-opname in de kerngeheugen cache (bijvoorbeeld de paginacache) bewaren. En om te zorgen dat de gegevens daadwerkelijk in permanente opslag zijn opgeslagen, is een systeemaanroep fdatasync nodig na de opname, en etcd maakt daar gebruik van (zoals te zien is in de output. strace, waar 8 de bestandshandle van de WAL is):

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 gaat de opname in permanente opslag niet onmiddellijk. Als de fdatasync-aanroep langzaam werkt, daalt de prestaties van het etcd-systeem. In de documentatie van etcd staat., dat de opslag als snel genoeg wordt beschouwd als in het 99e percentiel van fdatasync-aanroepen voor het schrijven naar het WAL-bestand minder dan 10 ms in beslag neemt. Er zijn andere nuttige metrics voor de opslag, maar in deze post bespreken we alleen deze metric.

Beoordeling van de opslag met fio

Als je wilt beoordelen of je opslag geschikt is voor etcd, gebruik dan fio - een zeer populaire tool voor het testen van invoer-/uitvoerbelasting. Het is belangrijk om te onthouden dat schijfbewerkingen heel divers kunnen zijn: synchrone en asynchrone bewerkingen, verschillende klassen systeemaanroepen, enzovoort. Als gevolg hiervan is fio behoorlijk lastig te gebruiken. Het heeft veel parameters, en verschillende combinaties van deze waarden leveren heel verschillende invoer-/uitvoerbelastingen op. Om passende cijfers voor etcd te krijgen, moet je ervoor zorgen dat de schrijfbelasting van fio zo dicht mogelijk bij de echte belasting van etcd ligt bij het schrijven van WAL-bestanden.

Daarom moet fio in ieder geval een belasting genereren in de vorm van een reeks opeenvolgende schrijfoperaties naar een bestand, waarbij elke schrijfoperatie een systeemaanroep zal zijn write, gevolgd door een systeemaanroep fdatasync. Voor opeenvolgende schrijfoperaties heeft fio de parameter -rw=write nodig. Om ervoor te zorgen dat fio de systeemaanroep write gebruikt tijdens het schrijven in plaats van pwrite, moet je de parameter -ioengine=sync opgeven. Ten slotte moet je om ervoor te zorgen dat fdatasync na elke schrijfoperatie wordt aangeroepen, de parameter -fdatasync=1 toevoegen. De andere twee parameters in dit voorbeeld (-size en -bs) zijn afhankelijk van het specifieke scenario. In het volgende gedeelte zullen we uitleggen hoe je deze kunt configureren.

Waarom juist fio en hoe we hebben geleerd het in te stellen

In deze post beschrijven we een reëel geval. We hadden een cluster Kubernetes v1.13, dat we monitoren met Prometheus. etcd v3.2.24 draaide op SSD. De statistieken van etcd wezen op te hoge vertragingen voor fdatasync, zelfs wanneer het cluster niets deed. De statistieken waren vreemd, en we wisten niet goed wat ze betekenden. Het cluster bestond uit virtuele machines, we moesten begrijpen waar het probleem lag: bij de fysieke SSD's of in de virtualisatielaag. Bovendien moesten we vaak wijzigingen aanbrengen in de hardware- en softwareconfiguratie, en we hadden een manier nodig om de resultaten te evalueren. We konden etcd in elke configuratie uitvoeren en de statistieken van Prometheus bekijken, maar dat was te omslachtig. We zochten naar een vrij eenvoudige manier om een specifieke configuratie te beoordelen. We wilden controleren of we de statistieken van Prometheus van etcd correct begrepen.

Maar daarvoor moesten we twee problemen oplossen. Ten eerste, hoe ziet de invoer-/uitvoerlading eruit die etcd genereert bij het schrijven naar WAL? Welke systeemoproepen worden gebruikt? Wat is de grootte van de vermeldingen? Ten tweede, als we deze vragen beantwoorden, hoe reproduceren we een vergelijkbare werklast met fio? Vergeet niet dat fio een zeer flexibele tool is met veel parameters. We hebben beide problemen opgelost met een enkele aanpak - met behulp van commando's. lsof en strace. lsof toont alle bestandshandvaten die door het proces worden gebruikt en de daarmee verbonden bestanden. Met strace kunnen we een al draaiend proces bestuderen of een proces starten en deze bestuderen. strace geeft alle systeemoproepen van het bestudeerde proces (en zijn kindprocessen) weer. Het laatste is bijzonder belangrijk, aangezien etcd precies zo'n benadering toepast.

Als eerste hebben we strace gebruikt om de etcd-server voor Kubernetes te bestuderen toen er geen belasting op de cluster was. We zagen dat bijna alle WAL-vermeldingen ongeveer dezelfde grootte hadden: 2200–2400 bytes. Daarom hebben we in het begin van de post de parameter -bs=2300 aangegeven (bs staat voor de grootte in bytes voor elke fio-vermelding). Let op, de grootte van de etcd-vermelding hangt af van de versie van etcd, de distributie, parameterwaarden, enz. en beïnvloedt de duur van fdatasync. Als u een vergelijkbaar scenario heeft, bestudeer dan uw etcd-processen met strace om de exacte cijfers te achterhalen.

Daarna, om goed inzicht te krijgen in de activiteiten in het bestandssysteem van etcd, hebben we het uitgevoerd met strace en de parameters -ffttT. Op deze manier probeerden we de kindprocessen te bestuderen en de uitvoer van elk van hen in een apart bestand op te slaan, en bovendien gedetailleerde rapporten te krijgen over het begin en de duur van elke systeemoproep. We gebruikten lsof om onze analyse van de uitvoer van strace te bevestigen en te zien welk bestandshandvat voor welke doeleinden werd gebruikt. Zo hebben we met strace de bovenstaande resultaten verkregen. De tijdstatistieken voor synchronisatie bevestigden dat de wal_fsync_duration_seconds van etcd overeenkomen met de oproepen van fdatasync met de WAL-bestandshandvaten.

We hebben de documentatie van fio bestudeerd en parameters voor ons scenario gekozen, zodat fio een belasting genereerde die vergelijkbaar is met die van etcd. Ook hebben we de systeemoproepen en hun duur gecontroleerd door fio vanuit strace uit te voeren, net zoals bij etcd.

We hebben de waarde van de parameter —size zorgvuldig geselecteerd, die de totale input-output belasting van fio weergeeft. In ons geval is dit het totale aantal bytes dat naar de opslag wordt geschreven. Het blijkt recht evenredig te zijn met het aantal systeemoproepen write (en fdatasync). Voor een bepaalde waarde van bs is het aantal oproepen fdatasync = size/bs. Aangezien we geïnteresseerd waren in percentielen, moesten we voldoende monsters hebben voor betrouwbaarheid, en we hebben berekend dat 10^4 (dit is 22 mebibytes) voldoende zou zijn. Als —size kleiner is, kunnen er uitschieters optreden (bijvoorbeeld, verschillende oproepen fdatasync duren langer dan normaal en beïnvloeden het 99e percentiel).

Probeer het zelf

We hebben laten zien hoe je fio kunt gebruiken en kunt nagaan of de opslag voldoende snelheid heeft voor hoge prestaties van etcd. Nu kun je dit zelf in de praktijk proberen, bijvoorbeeld met virtuele machines met SSD-opslag in. IBM Cloud.

Bron: habr.com