Berging spoed geskik vir ens? Kom ons vra vir fio

'n Kortverhaal oor fio en ens

Cluster prestasie ens hang grootliks af van die werkverrigting van die berging daarvan. etcd voer sommige statistieke uit na Prometheusom die verlangde bergingsprestasie-inligting te verskaf. Byvoorbeeld, die wal_fsync_duration_seconds-metriek. Die dokumentasie vir etcd sê: Vir berging om as vinnig genoeg beskou te word, moet die 99ste persentiel van hierdie metrieke minder as 10ms wees. As jy van plan is om 'n etcd-kluster op Linux-masjiene te laat loop en wil evalueer of jou berging vinnig genoeg is (bv. SSD), kan jy gebruik fio is 'n gewilde instrument om I/O-operasies te toets. Voer die volgende opdrag uit, waar test-data die gids onder die bergingspunt is:

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

Jy hoef net na die resultate te kyk en seker te maak dat die 99ste persentiel van die duur fdatasync minder as 10 ms. Indien wel, het jy redelik vinnige berging. Hier is 'n voorbeeld van die resultate:

  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]

Notes

• Ons het die --size en --bs opsies vir ons spesifieke scenario aangepas. Om 'n nuttige resultaat van fio te kry, verskaf jou eie waardes. Waar om hulle te kry? Lees hoe ons geleer het om fio te konfigureer.
• Tydens toetsing kom alle I/O-lading van fio. In 'n werklike scenario sal daar waarskynlik ander skryfversoeke in die stoor kom, behalwe dié wat verband hou met wal_fsync_duration_seconds. Die ekstra las sal die waarde van wal_fsync_duration_seconds verhoog. So as die 99ste persentiel naby aan 10ms is, is jou berging besig om uit spoed te raak.
• Neem die weergawe fio nie laer as 3.5 nie (die voriges wys nie fdatasync duur persentiele nie).
• Hierbo is net 'n brokkie van die resultate van fio.

Lang storie oor fio en ens

Wat is WAL in ens

Gewoonlik gebruik databasisse vooruitskryf-logboek; etcd gebruik dit ook. Ons sal nie die vooruitskryf-logboek (WAL) hier in detail bespreek nie. Dit is genoeg vir ons om te weet dat elke lid van die etcd-groep dit in aanhoudende berging onderhou. etcd skryf elke sleutel-waarde-bewerking (soos 'n opdatering) na WAL voordat dit op die winkel toegepas word. As een van die stoorlede ineenstort en tussen momentopnames herbegin, kan dit plaaslik transaksies herstel sedert die laaste momentopname deur WAL-inhoud.

Wanneer 'n kliënt 'n sleutel by die sleutel-waarde stoor voeg of die waarde van 'n bestaande sleutel opdateer, teken ens die bewerking in WAL aan, wat 'n gereelde lêer in aanhoudende berging is. etcd MOET heeltemal seker wees dat die WAL-inskrywing werklik plaasgevind het voordat jy met verwerking voortgaan. Op Linux is een stelseloproep nie genoeg hiervoor nie. skryf, aangesien die werklike skryf na fisiese berging vertraag kan word. Linux kan byvoorbeeld 'n WAL-inskrywing in 'n kas in kerngeheue (soos 'n bladsykas) vir 'n geruime tyd stoor. En sodat die data akkuraat geskryf kan word na aanhoudende berging, is die fdatasync-stelseloproep nodig na die skryf, en etcd gebruik dit net (soos jy kan sien in die resultaat van die werk strewe, waar 8 die WAL-lêerbeskrywing 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>

Ongelukkig vind skryf na aanhoudende berging nie onmiddellik plaas nie. As die fdatasync-oproep stadig is, sal die werkverrigting van die etcd-stelsel daaronder ly. Die dokumentasie vir etcd sêdat die berging as vinnig genoeg beskou word as, in die 99ste persentiel, fdatasync-oproepe minder as 10ms neem om na die WAL-lêer te skryf. Daar is ander nuttige maatstawwe vir berging, maar in hierdie pos praat ons net van hierdie maatstaf.

Beraam berging met fio

As jy moet evalueer of jou berging geskik is vir ens, gebruik fio, 'n baie gewilde I/O-ladingstoetsinstrument. Daar moet onthou word dat skyfbedrywighede baie verskillend kan wees: sinchroon en asinchroon, baie klasse stelseloproepe, ens. As gevolg hiervan is fio redelik moeilik om te gebruik. Dit het baie parameters, en verskillende kombinasies van hul waardes produseer baie verskillende I/O-werkladings. Om voldoende syfers vir etcd te kry, moet jy seker maak dat die toetsskryflading vanaf fio so na as moontlik aan die werklike lading vanaf etcd is wanneer WAL-lêers geskryf word.

Daarom moet fio, op 'n minimum, 'n las van 'n reeks opeenvolgende skrywes na die lêer skep, elke skrywe sal bestaan ​​uit 'n stelseloproep skryfgevolg deur die fdatasync-stelseloproep. Opeenvolgende skryfwerk na fio vereis die --rw=skryf opsie. Vir fio om die skryfstelsel te gebruik, bel wanneer jy skryf, eerder as skryf, moet jy die --ioengine=sync parameter spesifiseer. Ten slotte, om fdatasync na elke skryf te noem, moet jy die --fdatasync=1 parameter byvoeg. Die ander twee opsies in hierdie voorbeeld (--grootte en -bs) is skrifspesifiek. In die volgende afdeling sal ons jou wys hoe om dit op te stel.

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

In hierdie pos beskryf ons 'n werklike geval. Ons het 'n cluster Kubernetes v1.13 wat ons met Prometheus gemonitor het. etcd v3.2.24 is op 'n SSD gehuisves. Ens-metrieke het getoon dat fdatasync-vertragings te hoog is, selfs wanneer die groep niks gedoen het nie. Die maatstawwe was vreemd en ons het nie regtig geweet wat dit beteken nie. Die groep het bestaan ​​uit virtuele masjiene, dit was nodig om te verstaan ​​wat die probleem was: in fisiese SSD's of in die virtualisasielaag. Daarbenewens het ons dikwels veranderinge aan die hardeware- en sagteware-konfigurasie aangebring, en ons het 'n manier nodig gehad om hul resultate te evalueer. Ons kan ens in elke konfigurasie hardloop en na Prometheus-statistieke kyk, maar dit is te veel van 'n gesukkel. Ons was op soek na 'n redelik eenvoudige manier om 'n spesifieke konfigurasie te evalueer. Ons wou kyk of ons Prometheus-metrieke van etcd reg verstaan.

Maar hiervoor moes twee probleme opgelos word. Eerstens, hoe lyk die I/O-lading wat ens. skep wanneer na WAL geskryf word? Watter stelseloproepe word gebruik? Wat is die grootte van die rekords? Tweedens, as ons hierdie vrae beantwoord, hoe reproduseer ons 'n soortgelyke werklading met fio? Moenie vergeet dat fio 'n baie buigsame instrument met baie opsies is nie. Ons het albei probleme met een benadering opgelos - deur die opdragte te gebruik lsof и strewe. lsof lys alle lêerbeskrywings wat deur die proses gebruik word en hul verwante lêers. En met strace kan jy 'n proses wat reeds loop, ondersoek, of 'n proses begin en dit ondersoek. strace druk alle stelseloproepe van die proses wat ondersoek word (en sy kindprosesse) af. Laasgenoemde is baie belangrik, aangesien etcd net 'n soortgelyke benadering volg.

Ons het eers strace gebruik om die etcd-bediener vir Kubernetes te verken toe daar geen las op die cluster was nie. Ons het gesien dat byna alle WAL-rekords omtrent dieselfde grootte was: 2200–2400 grepe. Daarom, in die opdrag aan die begin van die pos, het ons die parameter -bs=2300 gespesifiseer (bs beteken die grootte in grepe vir elke fio-inskrywing). Let daarop dat die grootte van die etcd-inskrywing afhang van die etcd-weergawe, verspreiding, parameterwaardes, ens., en die fdatasync-duur beïnvloed. As jy 'n soortgelyke scenario het, ondersoek jou etcd-prosesse met strace om die presiese getalle uit te vind.

Toe, om 'n goeie idee te kry van wat die etcd-lêerstelsel doen, het ons dit begin met strace en die -ffttT-opsies. Ons het dus probeer om die kinderprosesse te ondersoek en die uitset van elkeen van hulle in 'n aparte lêer aan te teken, en ook gedetailleerde verslae te kry oor die begin en duur van elke stelseloproep. Ons het lsof gebruik om ons ontleding van die strace-uitvoer te bevestig en te sien watter lêerbeskrywer vir watter doel gebruik is. So met die hulp van strace is die resultate hierbo verkry. Sinchronisasietydstatistieke het bevestig dat wal_fsync_duration_seconds vanaf etcd ooreenstem met fdatasync-oproepe met WAL-lêerbeskrywings.

Ons het deur die dokumentasie vir fio gegaan en opsies vir ons script gekies sodat fio 'n las soortgelyk aan etcd sou genereer. Ons het ook stelseloproepe en hul duur nagegaan deur fio vanaf strace te laat loop, soortgelyk aan ens.

Ons het die waarde van die --size parameter versigtig gekies om die hele I/O-lading vanaf fio voor te stel. In ons geval is dit die totale aantal grepe wat na die berging geskryf is. Dit blyk direk eweredig te wees aan die aantal skryf (en fdatasync) stelseloproepe. Vir 'n sekere waarde van bs is die aantal fdatasync-oproepe = grootte/bs. Aangesien ons in die persentiel belanggestel het, moes ons genoeg monsters hê om seker te wees, en ons het bereken dat 10^4 vir ons genoeg sou wees (dit is 22 mebigrepe). As --grootte kleiner is, kan uitskieters voorkom (byvoorbeeld, verskeie fdatasync-oproepe neem langer as gewoonlik en beïnvloed die 99ste persentiel).

Probeer dit self

Ons het jou gewys hoe om fio te gebruik en kyk of die berging genoeg spoed het vir hoë werkverrigting ens. Nou kan jy dit self probeer deur byvoorbeeld virtuele masjiene met SSD-berging in te gebruik IBM Cloud.

Bron: will.com