🥇Hoe om skywe met fio na te gaan vir voldoende werkverrigting vir etcd

Let wel. vertaal.: Hierdie artikel is die resultaat van 'n mini-navorsing wat deur IBM Cloud-ingenieurs uitgevoer is op soek na 'n oplossing vir 'n werklike probleem wat verband hou met die werking van die etcd-databasis. 'n Soortgelyke taak was vir ons relevant, maar die verloop van besinning en optrede van die skrywers kan in 'n breër konteks interessant wees.

Kort opsomming van die hele artikel: fio en ens

Die werkverrigting van 'n ens-groepering is hoogs afhanklik van die spoed van die onderliggende berging. etcd voer verskeie Prometheus-metrieke uit om prestasie te monitor. Een van hulle is wal_fsync_duration_seconds. In die dokumentasie vir ens dit sêdat berging vinnig genoeg beskou kan word as die 99ste persentiel van hierdie maatstaf nie 10 ms oorskry nie...

As jy dit oorweeg om 'n ens-groepering op Linux-masjiene op te stel en wil kyk of aandrywers (soos SSD's) vinnig genoeg is, beveel ons aan om die gewilde I/O-toetser genaamd fio. Dit is genoeg om die volgende opdrag (directory test-data moet in die gemonteerde partisie van die getoetsde skyf geleë wees):

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

Dit bly net om na die uitset te kyk en te kyk of die 99ste persentiel pas fdatasync oor 10 ms. Indien wel, dan werk jou aandrywing vinnig genoeg. Hier is 'n voorbeeld uitset:

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]

'n Paar notas:

In die voorbeeld hierbo het ons die parameters aangepas --size и --bs vir 'n spesifieke geval. Om 'n sinvolle resultaat van te kry fio, spesifiseer waardes wat gepas is vir u gebruiksgeval. Hoe om hulle te kies, sal hieronder bespreek word.
Slegs tydens toetsing fio laai die skyfsubstelsel. In die werklike lewe is dit waarskynlik dat ander prosesse na skyf sal skryf (behalwe dié wat verband hou met wal_fsync_duration_seconds). Hierdie bykomende vrag kan toeneem wal_fsync_duration_seconds. Met ander woorde, as die 99ste persentiel van die toets met fio, net effens minder as 10 ms, is daar 'n goeie kans dat bergingprestasie nie voldoende is nie.
Vir die toets sal jy die weergawe nodig hê fio nie laer as 3.5 nie, want ouer weergawes versamel nie resultate nie fdatasync in die vorm van persentiele.
Bogenoemde gevolgtrekking is slegs 'n klein uittreksel uit die algemene gevolgtrekking fio.

Meer oor fio en ens

'n Paar woorde oor WAL's ens

Oor die algemeen gebruik databasisse proaktiewe aanteken (voorskryf-aantekening, WAL). ens word ook geraak. 'n Bespreking van WAL is buite die bestek van hierdie artikel, maar vir ons doeleindes, wat jy moet weet is dat elke ens-groeplid WAL in aanhoudende berging stoor. etcd skryf 'n paar sleutelwaarde-bergingsbewerkings (soos opdaterings) na WAL voordat dit uitgevoer word. As 'n nodus ineenstort en herbegin tussen foto's, sal etcd transaksies kan herstel sedert die vorige momentopname gebaseer op die inhoud van die WAL.

Dus, elke keer as 'n kliënt 'n sleutel by die KV-winkel voeg of die waarde van 'n bestaande sleutel opdateer, voeg ens die beskrywing van die bewerking by die WAL, wat 'n gewone lêer in die aanhoudende winkel is. etcd MOET 100% seker wees dat die WAL-inskrywing werklik gestoor is voordat jy voortgaan. Om dit op Linux te bereik, is dit nie genoeg om die stelseloproep te gebruik nie write, aangesien die skryfbewerking self na die fisiese media vertraag kan word. Linux kan byvoorbeeld 'n WAL-inskrywing in 'n in-geheue kernkas (bv. in die bladsykas) vir 'n geruime tyd hou. Om te verseker dat die data na die media geskryf word, moet 'n stelseloproep na die skryf opgeroep word fdatasync - dit is presies wat etcd doen (soos u in die volgende uitvoer kan sien strace; Hier 8 - WAL lêer beskrywing):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ".20210220361223255266632$1020103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

Ongelukkig neem skryf na aanhoudende berging 'n geruime tyd. Langdurige uitvoering van fdatasync-oproepe kan die werkverrigting van etcd beïnvloed. In die bewaarplek dokumentasie aangedui, dat vir voldoende prestasie dit nodig is dat die 99ste persentiel van die duur van alle oproepe fdatasync toe skryf na 'n WAL-lêer was minder as 10 ms. Daar is ander bergingverwante maatstawwe, maar hierdie artikel sal daarop fokus.

Waardeer berging met fio

Jy kan evalueer of 'n sekere berging geskik is vir gebruik met ens met die hulpprogram fio — 'n gewilde I/O-toetser. Hou in gedagte dat skyf I/O op baie verskillende maniere kan gebeur: sinchroniseer/asinkroniseer, baie verskillende stelseloproepklasse, ensovoorts. Die ander kant van die munt is dit fio uiters moeilik om te gebruik. Die nut het baie parameters, en verskillende kombinasies van hul waardes lei tot heeltemal verskillende resultate. Om 'n redelike skatting vir etcd te kry, moet jy seker maak dat die skryflading wat deur fio gegenereer word so na as moontlik aan etcd se WAL-lêer skryflading is:

Dit beteken dat die gegenereerde fio die las moet ten minste 'n reeks opeenvolgende skrywes na die lêer wees, waar elke skrywe uit 'n stelseloproep bestaan writegevolg deur fdatasync.
Om opeenvolgende skryfwerk moontlik te maak, moet jy die vlag spesifiseer --rw=write.
Wat fio geskryf met behulp van oproepe write (eerder as ander stelseloproepe - bv. pwrite), gebruik die vlag --ioengine=sync.
Ten slotte, die vlag --fdatasync=1 verseker dat elke write behoort fdatasync.
Die ander twee parameters in ons voorbeeld is: --size и --bs - kan verskil na gelang van die spesifieke gebruiksgeval. Die volgende afdeling sal hul konfigurasie beskryf.

Hoekom ons fio gekies het en hoe ons geleer het hoe om dit op te stel

Hierdie nota kom van 'n werklike geval wat ons teëgekom het. Ons het 'n groepering op Kubernetes v1.13 gehad met monitering op Prometheus. SSD's is gebruik as berging vir etcd v3.2.24. Ens-statistieke het te hoë latensies getoon fdatasync, selfs wanneer die tros ledig was. Vir ons het hierdie maatstawwe baie twyfelagtig gelyk, en ons was nie seker wat hulle presies verteenwoordig nie. Boonop het die groep uit virtuele masjiene bestaan, so dit was nie moontlik om te sê of die vertraging te wyte was aan virtualisering of die SSD die skuld was nie.

Daarbenewens het ons verskeie veranderinge in die hardeware- en sagteware-konfigurasie oorweeg, so ons het 'n manier nodig gehad om dit te evalueer. Natuurlik sou dit moontlik wees om etcd in elke konfigurasie uit te voer en na die ooreenstemmende Prometheus-metrieke te kyk, maar dit sal aansienlike moeite verg. Wat ons nodig gehad het, was 'n eenvoudige manier om 'n spesifieke konfigurasie te evalueer. Ons wou ons begrip van die Prometheus-metrieke wat van etcd kom, toets.

Dit vereis die oplossing van twee probleme:

Eerstens, hoe lyk die I/O-lading wat deur etcd gegenereer word wanneer na WAL-lêers geskryf word? Watter stelseloproepe word gebruik? Wat is die grootte van die rekordblokke?
Tweedens, kom ons sê ons het antwoorde op bogenoemde vrae. Hoe om die ooreenstemmende lading weer te gee met fio? Na alles fio - uiters buigsame nut met 'n oorvloed van parameters (dit is maklik om te verifieer, bv. hier - ongeveer. vertaal.).

Ons het albei probleme met dieselfde opdraggebaseerde benadering opgelos lsof и strace:

Met lsof jy kan alle lêerbeskrywings sien wat deur die proses gebruik word, sowel as die lêers waarna hulle verwys.
Met strace jy kan 'n proses wat reeds loop, ontleed of 'n proses uitvoer en daarna kyk. Die opdrag vertoon alle stelseloproepe wat deur hierdie proses gemaak word en, indien nodig, sy afstammelinge. Laasgenoemde is belangrik vir prosesse wat vurk, en ens is een so 'n proses.

Die eerste ding wat ons gedoen het, was om te gebruik strace om die etcd-bediener in die Kubernetes-kluster te ondersoek terwyl dit ledig was.

Daar is dus gevind dat WAL-rekordblokke baie dig gegroepeer is, die grootte van die meerderheid was in die reeks van 2200-2400 grepe. Dit is hoekom die opdrag aan die begin van hierdie artikel die vlag gebruik --bs=2300 (bs is die grootte in grepe van elke skryfblok in fio).

Neem asseblief kennis dat die grootte van etcd-skryfblokke kan wissel na gelang van die weergawe, ontplooiing, parameterwaardes, ens. - dit beïnvloed die duur fdatasync. As jy 'n soortgelyke gebruiksgeval het, ontleed met strace jou etcd-prosesse om bygewerkte waardes te kry.

Dan, om 'n duidelike en omvattende idee te kry van hoe etcd met die lêerstelsel werk, het ons dit van onder begin strace met vlae -ffttT. Dit het dit moontlik gemaak om kinderprosesse vas te lê en die uitvoer van elkeen na 'n aparte lêer te skryf. Daarbenewens is gedetailleerde inligting oor die begintyd en duur van elke stelseloproep verkry.

Ons het ook die opdrag gebruik lsofom jou begrip van die uitset te bevestig strace in terme van watter lêerbeskrywer vir watter doel gebruik is. Ek het die gevolgtrekking gekry strace, soortgelyk aan die een hierbo. Statistiese manipulasies met sinchronisasie tye het bevestig dat die metrieke wal_fsync_duration_seconds van etcd pas oproepe fdatasync met WAL-lêerbeskrywings.

Om mee te genereer fio 'n werklading soortgelyk aan dié van etcd, die dokumentasie van die hulpprogram is bestudeer en die parameters wat geskik is vir ons taak is gekies. Ons het geverifieer dat die korrekte stelseloproepe aan die gang is en die duur daarvan bevestig deur te hardloop fio van strace (soos dit gedoen is in geval van ens.).

Daar is veral aandag gegee aan die bepaling van die waarde van die parameter --size. Dit verteenwoordig die totale I/O-lading wat deur die fio-hulpprogram gegenereer word. In ons geval is dit die totale aantal grepe wat na die media geskryf is. Dit is direk eweredig aan die aantal oproepe write (en fdatasync). Vir 'n spesifieke bs aantal oproepe fdatasync ewe veel size / bs.

Aangesien ons in die persentiel belanggestel het, wou ons hê die aantal steekproewe moet groot genoeg wees om statisties betekenisvol te wees. En dit besluit 10^4 (wat ooreenstem met 'n grootte van 22 MB) sal voldoende wees. Kleiner parameterwaardes --size het meer uitgesproke geraas gegee (byvoorbeeld oproepe fdatasync, wat baie langer as gewoonlik neem en die 99ste persentiel beïnvloed).

Dit hang van jou af

Die artikel wys hoe om te gebruik fio mens kan oordeel of die media wat bedoel is vir gebruik met ens vinnig genoeg is. Nou is dit aan jou! U kan virtuele masjiene met SSD-gebaseerde berging in die diens verken IBM Cloud.

PS van vertaler

Met gereedgemaakte gebruik gevalle fio Vir ander take, sien dokumentasie of direk aan projekbewaarplekke (daar is baie meer van hulle as wat in die dokumentasie genoem word).

Hoe om skywe met fio na te gaan vir voldoende werkverrigting vir ens