ProHoster > Blogs > Administrācija > UzglabāŔanas ātrums piemērots etcd? Pajautāsim fio

UzglabāŔanas ātrums piemērots etcd? Pajautāsim fio

UzglabāŔanas ātrums piemērots etcd? Pajautāsim fio

ÄŖss stāsts par fio un utt

Klasteru veiktspēja utt lielā mērā ir atkarÄ«gs no tā uzglabāŔanas veiktspējas. etcd eksportē dažus rādÄ«tājus uz Prometejslai sniegtu vēlamo krātuves veiktspējas informāciju. Piemēram, metrika wal_fsync_duration_seconds. etcd dokumentācijā teikts: lai uzglabāŔanu uzskatÄ«tu par pietiekami ātru, Ŕīs metrikas 99. procentilei ir jābÅ«t mazākai par 10 ms. Ja plānojat palaist etcd klasteru Linux iekārtās un vēlaties novērtēt, vai jÅ«su krātuve ir pietiekami ātra (piemēram, SSD), varat izmantot FIO ir populārs rÄ«ks I/O darbÄ«bu testÄ“Å”anai. Palaidiet Å”o komandu, kur testa dati ir direktorijs zem krātuves pievienoÅ”anas punkta:

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

Jums vienkārÅ”i jāaplÅ«ko rezultāti un jāpārbauda, ā€‹ā€‹vai ilguma 99. procentile fdatasync mazāk nekā 10 ms. Ja tā, jums ir pietiekami ātra uzglabāŔana. Å eit ir rezultātu piemērs:

  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]

piezīmes

  • Mēs esam pielāgojuÅ”i opcijas --size un --bs mÅ«su konkrētajam scenārijam. Lai no fio iegÅ«tu noderÄ«gu rezultātu, norādiet savas vērtÄ«bas. Kur tās dabÅ«t? LasÄ«t kā mēs iemācÄ«jāmies konfigurēt fio.
  • Pārbaudes laikā visa I/O slodze nāk no fio. Reālajā dzÄ«vē, iespējams, krātuvē tiks saņemti citi rakstÄ«Å”anas pieprasÄ«jumi, izņemot tos, kas saistÄ«ti ar wal_fsync_duration_seconds. Papildu slodze palielinās wal_fsync_duration_seconds vērtÄ«bu. Tātad, ja 99. procentile ir tuvu 10 ms, jÅ«su krātuves ātrums beigsies.
  • Paņemiet versiju FIO ne mazāk kā 3.5 (iepriekŔējie nerāda fdatasync ilguma procentiles).
  • IepriekÅ” ir tikai fragments no fio rezultātiem.

GarŔ stāsts par fio un utt

Kas ir WAL programmā etcd

Parasti izmanto datu bāzes priekÅ”rakstÄ«Å”anas žurnāls; etcd to arÄ« izmanto. Å eit mēs sÄ«kāk neapspriedÄ«sim priekÅ”rakstÄ«Å”anas žurnālu (WAL). Mums pietiek zināt, ka katrs etcd klastera dalÄ«bnieks to uztur pastāvÄ«gā krātuvē. etcd ieraksta katru atslēgas vērtÄ«bas darbÄ«bu (piemēram, atjauninājumu) WAL, pirms to lieto veikalā. Ja kāds no krātuves dalÄ«bniekiem avarē un tiek restartēts starp momentuzņēmumiem, tas var lokāli atjaunot darÄ«jumus kopÅ” pēdējā WAL satura momentuzņēmuma.

Kad klients pievieno atslēgu atslēgu vērtÄ«bu krātuvei vai atjaunina esoŔās atslēgas vērtÄ«bu, etcd ieraksta darbÄ«bu WAL, kas ir parasts fails pastāvÄ«gā krātuvē. etcd Pirms apstrādes turpināŔanas JĀBÅŖT pilnÄ«bā pārliecinātam, ka WAL ieraksts patieŔām ir noticis. Operētājsistēmā Linux Å”im nolÅ«kam nepietiek ar vienu sistēmas zvanu. rakstÄ«t, jo faktiskā ierakstÄ«Å”ana fiziskajā krātuvē var aizkavēties. Piemēram, Linux kādu laiku var saglabāt WAL ierakstu kodola atmiņas keÅ”atmiņā (piemēram, lapas keÅ”atmiņā). Un, lai dati tiktu precÄ«zi ierakstÄ«ti pastāvÄ«gā krātuvē, pēc rakstÄ«Å”anas ir nepiecieÅ”ams fdatasync sistēmas izsaukums, un etcd to vienkārÅ”i izmanto (kā redzat darba rezultātā strace, kur 8 ir WAL faila deskriptors):

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>

Diemžēl rakstÄ«Å”ana uz pastāvÄ«gu krātuvi nenotiek uzreiz. Ja fdatasync izsaukums ir lēns, tiks ietekmēta etcd sistēmas veiktspēja. etcd dokumentācijā teiktska krātuve tiek uzskatÄ«ta par pietiekami ātru, ja 99. procentilē fdatasync izsaukumu ierakstÄ«Å”ana WAL failā aizņem mazāk nekā 10 ms. Ir arÄ« citi noderÄ«gi glabāŔanas rādÄ«tāji, taču Å”ajā ziņā mēs runājam tikai par Å”o rādÄ«tāju.

Krātuves aprēķins ar fio

Ja nepiecieÅ”ams novērtēt, vai jÅ«su krātuve ir piemērota uttd, izmantojiet fio, ļoti populāru I/O slodzes pārbaudes rÄ«ku. Jāatceras, ka diska darbÄ«bas var bÅ«t ļoti dažādas: sinhronas un asinhronas, daudzas sistēmas izsaukumu klases utt. Tā rezultātā fio ir diezgan grÅ«ti lietojams. Tam ir daudz parametru, un dažādas to vērtÄ«bu kombinācijas rada ļoti dažādas I/O darba slodzes. Lai iegÅ«tu atbilstoÅ”us etcd skaitļus, rakstot WAL failus, jums jāpārliecinās, vai testa rakstÄ«Å”anas slodze no fio ir pēc iespējas tuvāka faktiskajai slodzei no etcd.

Tāpēc fio ir vismaz jāizveido failā secÄ«gu ierakstu sērija, katra rakstÄ«Å”ana sastāvēs no sistēmas izsaukuma rakstÄ«tkam seko fdatasync sistēmas izsaukums. SecÄ«gai rakstÄ«Å”anai uz fio ir nepiecieÅ”ama opcija --rw=write. Lai fio rakstÄ«Å”anas laikā izmantotu rakstÄ«Å”anas sistēmas zvanu, nevis rakstÄ«t, jānorāda parametrs --ioengine=sync. Visbeidzot, lai pēc katras rakstÄ«Å”anas izsauktu fdatasync, jums jāpievieno parametrs --fdatasync=1. Pārējās divas opcijas Å”ajā piemērā (--size un -bs) ir atkarÄ«gas no skripta. Nākamajā sadaļā mēs parādÄ«sim, kā tos iestatÄ«t.

Kāpēc fio un kā mēs iemācījāmies to iestatīt

Å ajā rakstā mēs aprakstām reālu gadÄ«jumu. Mums ir klasteris Kubernetes v1.13, kuru mēs uzraudzÄ«jām, izmantojot Prometheus. etcd v3.2.24 tika mitināts SSD. Etcd metrika uzrādÄ«ja pārāk augstu fdatasync latentumu, pat ja klasteris neko nedarÄ«ja. Metrikas bija dÄ«vainas, un mēs Ä«sti nezinājām, ko tie nozÄ«mē. Klasteris sastāvēja no virtuālajām maŔīnām, bija jāsaprot, kas par problēmu: fiziskajos SSD vai virtualizācijas slānÄ«. Turklāt mēs bieži veicām izmaiņas aparatÅ«ras un programmatÅ«ras konfigurācijā, un mums bija nepiecieÅ”ams veids, kā novērtēt to rezultātus. Mēs varētu palaist etcd katrā konfigurācijā un apskatÄ«t Prometheus metriku, taču tas ir pārāk daudz problēmu. Mēs meklējām diezgan vienkārÅ”u veidu, kā novērtēt konkrētu konfigurāciju. Mēs vēlējāmies pārbaudÄ«t, vai mēs pareizi saprotam Prometheus metriku no etcd.

Taču Å”im nolÅ«kam bija jāatrisina divas problēmas. Pirmkārt, kā izskatās I/O slodze, ko etcd rada, rakstot uz WAL? Kādi sistēmas izsaukumi tiek izmantoti? Kāds ir ierakstu lielums? Otrkārt, ja mēs atbildam uz Å”iem jautājumiem, kā mēs varam reproducēt lÄ«dzÄ«gu darba slodzi ar fio? Neaizmirstiet, ka fio ir ļoti elastÄ«gs rÄ«ks ar daudzām iespējām. Abas problēmas atrisinājām ar vienu pieeju ā€“ izmantojot komandas lsof Šø strace. lsof uzskaita visus procesā izmantotos failu deskriptorus un ar tiem saistÄ«tos failus. Izmantojot strace, varat pārbaudÄ«t jau esoÅ”u procesu vai sākt procesu un to pārbaudÄ«t. strace izdrukā visus sistēmas izsaukumus no pārbaudāmā procesa (un tā pakārtotajiem procesiem). Pēdējais ir ļoti svarÄ«gs, jo etcd tikai izmanto lÄ«dzÄ«gu pieeju.

Vispirms mēs izmantojām strace, lai izpētÄ«tu Kubernetes etcd serveri, kad klasterim nebija slodzes. Mēs redzējām, ka gandrÄ«z visi WAL ieraksti bija aptuveni vienāda izmēra: 2200ā€“2400 baiti. Tāpēc ziņojuma sākumā esoÅ”ajā komandā mēs norādÄ«jām parametru -bs=2300 (bs nozÄ«mē katra fio ieraksta lielumu baitos). Ņemiet vērā, ka etcd ieraksta lielums ir atkarÄ«gs no etcd versijas, izplatÄ«Å”anas, parametru vērtÄ«bām utt., kā arÄ« ietekmē fdatasync ilgumu. Ja jums ir lÄ«dzÄ«gs scenārijs, pārbaudiet savus etcd procesus ar strace, lai uzzinātu precÄ«zus skaitļus.

Pēc tam, lai iegÅ«tu labu priekÅ”statu par etcd failu sistēmas darbÄ«bu, mēs to sākām ar strace un -ffttT opcijām. Tāpēc mēs mēģinājām pārbaudÄ«t pakārtotos procesus un ierakstÄ«t katra no tiem izvadi atseviŔķā failā, kā arÄ« iegÅ«t detalizētus pārskatus par katra sistēmas zvana sākumu un ilgumu. Mēs izmantojām lsof, lai apstiprinātu strace izvades analÄ«zi un redzētu, kurÅ” faila deskriptors tika izmantots kādam nolÅ«kam. Tātad ar strace palÄ«dzÄ«bu tika iegÅ«ti iepriekÅ” parādÄ«tie rezultāti. Sinhronizācijas laika statistika apstiprināja, ka wal_fsync_duration_seconds no etcd atbilst fdatasync izsaukumiem ar WAL failu deskriptoriem.

Mēs izskatījām fio dokumentāciju un izvēlējāmies mūsu skripta opcijas, lai fio radītu slodzi, kas līdzīga etcd. Mēs arī pārbaudījām sistēmas zvanus un to ilgumu, palaižot fio no strace, līdzīgi kā etcd.

Mēs esam rÅ«pÄ«gi izvēlējuÅ”ies parametra --size vērtÄ«bu, lai attēlotu visu I/O slodzi no fio. MÅ«su gadÄ«jumā tas ir kopējais krātuvē ierakstÄ«to baitu skaits. Tas izrādÄ«jās tieÅ”i proporcionāls rakstÄ«Å”anas (un fdatasync) sistēmas zvanu skaitam. Noteiktai bs vērtÄ«bai fdatasync zvanu skaits = izmērs/bs. Tā kā mÅ«s interesēja procentile, mums bija jābÅ«t pietiekami daudz paraugu, lai pārliecinātos, un mēs aprēķinājām, ka mums pietiks ar 10^4 (tas ir 22 mebibaiti). Ja --size ir mazāks, var rasties novirzes (piemēram, vairāki fdatasync izsaukumi aizņem ilgāku laiku nekā parasti un ietekmē 99. procentili).

Izmēģiniet pats

Mēs parādÄ«jām, kā izmantot fio un pārbaudÄ«t, vai krātuve ir pietiekami ātra, lai etcd darbotos labi. Tagad varat to izmēģināt pats, izmantojot, piemēram, virtuālās maŔīnas ar SSD krātuvi IBM Cloud.

Avots: www.habr.com

Pievieno komentāru