Opslagsnelheid geschikt voor etcd? Laten we het eens vragen

Een kort verhaal over fio en etcd

Clusterprestaties enz hangt grotendeels af van de prestaties van de opslag. etcd exporteert enkele statistieken naar Prometheusom de gewenste informatie over de opslagprestaties te verstrekken. Bijvoorbeeld de metriek wal_fsync_duration_seconds. De documentatie voor etcd zegt: Om opslag als snel genoeg te beschouwen, moet het 99e percentiel van deze statistiek minder dan 10 ms zijn. Als u van plan bent een etcd-cluster op Linux-machines uit te voeren en wilt evalueren of uw opslag snel genoeg is (bijv. SSD), kunt u FIO is een populaire tool voor het testen van I/O-bewerkingen. Voer de volgende opdracht uit, waarbij test-data de map is onder het opslagkoppelpunt:

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

U hoeft alleen maar naar de resultaten te kijken en te controleren of het 99e percentiel van de duur is fdatasync minder dan 10 ms. Dan heb je redelijk snelle opslag. Hier is een voorbeeld van de 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 opties --size en --bs aangepast voor ons specifieke scenario. Geef uw eigen waarden op om een ​​bruikbaar resultaat van fio te krijgen. Waar kun je ze krijgen? Lezen hoe we fio hebben leren configureren.
• Tijdens het testen komt alle I/O-belasting van fio. In een real-life scenario zullen er waarschijnlijk andere schrijfverzoeken in de opslag komen naast die met betrekking tot wal_fsync_duration_seconds. De extra belasting verhoogt de waarde van wal_fsync_duration_seconds. Dus als het 99e percentiel in de buurt van 10 ms ligt, raakt uw opslag bijna vol.
• Neem de versie FIO niet minder dan 3.5 (de vorige tonen geen fdatasync-duurpercentielen).
• Hierboven is slechts een fragment van de resultaten van fio.

Lang verhaal over fio en etcd

Wat is WAL in enz

Meestal gebruiken databases vooruitschrijvend logboek; etcd gebruikt het ook. We zullen hier niet in detail ingaan op het vooruitschrijflogboek (WAL). Het is voor ons voldoende om te weten dat elk lid van het etcd-cluster het in permanente opslag onderhoudt. etcd schrijft elke sleutelwaardebewerking (zoals een update) naar WAL voordat deze wordt toegepast op de winkel. Als een van de opslagleden crasht en opnieuw opstart tussen momentopnamen, kan het lokaal transacties herstellen sinds de laatste momentopname door WAL-inhoud.

Wanneer een client een sleutel toevoegt aan de sleutel-waarde-opslag of de waarde van een bestaande sleutel bijwerkt, registreert etcd de bewerking in WAL, wat een regulier bestand is in permanente opslag. etcd MOET er volledig zeker van zijn dat de WAL-invoer daadwerkelijk heeft plaatsgevonden voordat u doorgaat met verwerken. Op Linux is één systeemoproep hiervoor niet voldoende. schrijven, aangezien het daadwerkelijke schrijven naar fysieke opslag kan worden vertraagd. Linux kan bijvoorbeeld een WAL-item enige tijd opslaan in een cache in het kernelgeheugen (zoals een paginacache). En om ervoor te zorgen dat de gegevens nauwkeurig naar permanente opslag worden geschreven, is de fdatasync-systeemaanroep nodig na het schrijven, en etcd gebruikt het gewoon (zoals u kunt zien in het resultaat van het werk spoor, waarbij 8 de WAL-bestandsdescriptor is):

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>

Helaas gebeurt het schrijven naar permanente opslag niet onmiddellijk. Als de fdatasync-aanroep traag is, zullen de prestaties van het etcd-systeem eronder lijden. De documentatie voor etcd zegtdat de opslag als snel genoeg wordt beschouwd als fdatasync-oproepen in het 99e percentiel minder dan 10 ms nodig hebben om naar het WAL-bestand te schrijven. Er zijn andere handige statistieken voor opslag, maar in dit bericht hebben we het alleen over deze statistiek.

Opslag schatten met fio

Als u wilt evalueren of uw opslag geschikt is voor etcd, gebruikt u fio, een zeer populaire tool voor het testen van I/O-belasting. Er moet aan worden herinnerd dat schijfbewerkingen heel verschillend kunnen zijn: synchroon en asynchroon, veel klassen systeemaanroepen, enz. Als gevolg hiervan is fio vrij moeilijk te gebruiken. Het heeft veel parameters en verschillende combinaties van hun waarden produceren zeer verschillende I/O-workloads. Om adequate cijfers voor etcd te krijgen, moet u ervoor zorgen dat de testschrijfbelasting van fio zo dicht mogelijk bij de daadwerkelijke belasting van etcd ligt bij het schrijven van WAL-bestanden.

Daarom zou fio minimaal een belasting moeten creëren in de vorm van een reeks opeenvolgende schrijfbewerkingen naar het bestand, elke schrijfbewerking zal bestaan ​​uit een systeemaanroep schrijvengevolgd door de fdatasync-systeemaanroep. Sequentiële schrijfbewerkingen naar fio vereisen de optie --rw=write. Voor fio om de schrijfsysteemaanroep te gebruiken tijdens het schrijven, in plaats van schrijf, moet u de parameter --ioengine=sync opgeven. Ten slotte, om fdatasync aan te roepen na elke schrijfbewerking, moet u de parameter --fdatasync=1 toevoegen. De andere twee opties in dit voorbeeld (--size en -bs) zijn scriptspecifiek. In het volgende gedeelte laten we u zien hoe u ze instelt.

Waarom precies fio en hoe we het hebben leren opzetten

In dit bericht beschrijven we een echte casus. We hebben een cluster Kubernetes v1.13 die we hebben gemonitord met Prometheus. etcd v3.2.24 werd gehost op een SSD. Etcd-statistieken toonden te hoge fdatasync-latenties, zelfs als het cluster niets deed. De statistieken waren raar en we wisten niet echt wat ze betekenden. Het cluster bestond uit virtuele machines, het was nodig om te begrijpen wat het probleem was: in fysieke SSD's of in de virtualisatielaag. Bovendien brachten we vaak wijzigingen aan in de hardware- en softwareconfiguratie en hadden we een manier nodig om hun resultaten te evalueren. We zouden etcd in elke configuratie kunnen draaien en naar Prometheus-statistieken kijken, maar dat is te veel gedoe. We waren op zoek naar een vrij eenvoudige manier om een ​​specifieke configuratie te evalueren. We wilden controleren of we Prometheus-statistieken van etcd correct begrijpen.

Maar hiervoor moesten twee problemen worden opgelost. Ten eerste, hoe ziet de I/O-belasting eruit die etcd creëert bij het schrijven naar WAL? Welke systeemoproepen worden gebruikt? Wat is de grootte van de records? Ten tweede, als we deze vragen beantwoorden, hoe reproduceren we dan een vergelijkbare werklast met fio? Vergeet niet dat fio een zeer flexibele tool is met veel opties. We hebben beide problemen met één benadering opgelost - met behulp van de commando's lsof и spoor. lsof somt alle bestandsbeschrijvingen op die door het proces worden gebruikt en de bijbehorende bestanden. En met strace kunt u een reeds lopend proces onderzoeken, of een proces starten en onderzoeken. strace drukt alle systeemoproepen af ​​van het proces dat wordt onderzocht (en de onderliggende processen). Dit laatste is erg belangrijk, aangezien etcd gewoon een vergelijkbare aanpak hanteert.

We hebben eerst strace gebruikt om de etcd-server voor Kubernetes te verkennen toen het cluster niet werd belast. We zagen dat bijna alle WAL-records ongeveer even groot waren: 2200–2400 bytes. Daarom specificeerden we in het commando aan het begin van de post de parameter -bs=2300 (bs betekent de grootte in bytes voor elk fio-item). Merk op dat de grootte van het etcd-item afhangt van de etcd-versie, distributie, parameterwaarden, enz., en de duur van fdatasync beïnvloedt. Als je een soortgelijk scenario hebt, onderzoek dan je etcd-processen met strace om de exacte cijfers te achterhalen.

Om vervolgens een goed idee te krijgen van wat het etcd-bestandssysteem doet, zijn we begonnen met strace en de -ffttT-opties. Dus probeerden we de onderliggende processen te onderzoeken en de uitvoer van elk ervan in een apart bestand vast te leggen, en ook om gedetailleerde rapporten te krijgen over het begin en de duur van elke systeemaanroep. We gebruikten lsof om onze analyse van de strace-uitvoer te bevestigen en te zien welke bestandsdescriptor voor welk doel werd gebruikt. Dus met behulp van strace werden de hierboven getoonde resultaten verkregen. Synchronisatietijdstatistieken bevestigden dat wal_fsync_duration_seconds van etcd consistent is met fdatasync-oproepen met WAL-bestandsdescriptors.

We hebben de documentatie voor fio doorgenomen en opties voor ons script gekozen, zodat fio een belasting zou genereren die vergelijkbaar is met etcd. We hebben ook systeemaanroepen en hun duur gecontroleerd door fio vanuit strace uit te voeren, vergelijkbaar met etcd.

We hebben de waarde van de parameter --size zorgvuldig gekozen om de volledige I/O-belasting van fio weer te geven. In ons geval is dit het totale aantal bytes dat naar de opslag is geschreven. Het bleek recht evenredig te zijn met het aantal schrijf- (en fdatasync) systeemoproepen. Voor een bepaalde waarde van bs is het aantal fdatasync-oproepen = size/bs. Omdat we geïnteresseerd waren in het percentiel, moesten we genoeg monsters hebben om zeker te zijn, en we berekenden dat 10^4 genoeg zou zijn voor ons (dat is 22 mebibytes). Als --size kleiner is, kunnen er uitschieters optreden (bijvoorbeeld, meerdere fdatasync-aanroepen duren langer dan normaal en hebben invloed op het 99e percentiel).

Probeer het zelf

We hebben je laten zien hoe je fio gebruikt en kijken of de opslag snel genoeg is om etcd goed te laten presteren. Nu kunt u het zelf uitproberen met bijvoorbeeld virtuele machines met SSD-opslag erin IBM Cloud.

Bron: www.habr.com