etcd-д тохиромжтой хадгалах хурд? За асууя

etcd-д тохиромжтой хадгалах хурд? За асууя

Fio болон бусад зүйлийн тухай богино өгүүллэг

Кластерын гүйцэтгэл гэх мэт түүний хадгалалтын гүйцэтгэлээс ихээхэн хамаардаг. etcd зарим хэмжигдэхүүнийг экспортлодог Prometheusхүссэн хадгалалтын гүйцэтгэлийн мэдээллээр хангах. Жишээлбэл, wal_fsync_duration_seconds хэмжигдэхүүн. etcd-ийн баримт бичигт ингэж бичсэн байна: Хадгалалт хангалттай хурдан гэж үзэхийн тулд энэ хэмжүүрийн 99 дэх хувь нь 10 мс-ээс бага байх ёстой. Хэрэв та Линукс машинууд дээр etcd кластер ажиллуулахаар төлөвлөж байгаа бөгөөд таны санах ой хангалттай хурдан байгаа эсэхийг (жишээ нь, SSD) үнэлэхийг хүсвэл ашиглаж болно. fio нь оролт гаралтын ажиллагааг шалгах түгээмэл хэрэгсэл юм. Дараах командыг ажиллуулна уу, энд test-data нь хадгалах холбох цэгийн доорх директор юм:

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

Та зүгээр л үр дүнг харж, үргэлжлэх хугацааны 99 дэх хувь байгаа эсэхийг шалгах хэрэгтэй fdatasync 10 мс-ээс бага. Хэрэв тийм бол танд хангалттай хурдан хадгалах боломжтой. Үр дүнгийн жишээ энд байна:

  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]

Тэмдэглэл

  • Бид --size болон --bs сонголтуудыг өөрийн хувилбарт тохируулсан. Fio-аас ашигтай үр дүнд хүрэхийн тулд өөрийн үнэлэмжийг оруулаарай. Тэднийг хаанаас авах вэ? Унших Бид fio-г хэрхэн тохируулж сурсан.
  • Туршилтын явцад бүх оролт гаралтын ачаалал fio-аас ирдэг. Бодит хувилбарт wal_fsync_duration_seconds-тай холбоотой бусад бичих хүсэлтүүд хадгалах санд ирэх магадлалтай. Нэмэлт ачаалал нь wal_fsync_duration_seconds-ийн утгыг нэмэгдүүлэх болно. Хэрэв 99 дэх хувь нь 10 мс-тэй ойролцоо байвал таны хадгалах сангийн хурд дуусч байна.
  • Хувилбараа аваарай fio 3.5-аас доошгүй (өмнөх нь fdatasync үргэлжлэх хугацааны хувь хэмжээг харуулдаггүй).
  • Дээрх нь fio-ийн үр дүнгийн зөвхөн нэг хэсэг юм.

Fio болон бусад зүйлийн тухай урт түүх

etcd-д WAL гэж юу вэ

Ихэвчлэн мэдээллийн санг ашигладаг урьдчилан бичих бүртгэл; etcd үүнийг бас ашигладаг. Бид энд урьдчилан бичих бүртгэлийг (WAL) дэлгэрэнгүй авч үзэхгүй. etcd кластерын гишүүн бүр үүнийг байнгын хадгалалтад хадгалдаг гэдгийг мэдэхэд хангалттай. etcd нь түлхүүр утгын үйлдэл бүрийг (шинэчлэлт гэх мэт) дэлгүүрт хэрэглэхээсээ өмнө WAL руу бичдэг. Хадгалалтын гишүүдийн аль нэг нь гацаж, хормын хувилбаруудын хооронд дахин ачаалбал WAL агуулгын сүүлийн агшингаас хойшхи гүйлгээг дотооддоо сэргээх боломжтой.

Үйлчлүүлэгч түлхүүр утгын хадгалалтад түлхүүр нэмэх эсвэл одоо байгаа түлхүүрийн утгыг шинэчлэх үед etcd нь үйлдлийг WAL-д бүртгэдэг бөгөөд энэ нь байнгын хадгалалтад байдаг ердийн файл юм. etcd боловсруулалтыг үргэлжлүүлэхээс өмнө WAL оруулга үнэхээр гарсан гэдэгт бүрэн итгэлтэй байх ЗААВАЛ. Линукс дээр нэг системийн дуудлага хийх нь хангалтгүй юм. бичих, учир нь бодит санах ойд бичих хугацаа хойшлогдож магадгүй юм. Жишээлбэл, Линукс нь WAL оруулгыг цөмийн санах ой дахь кэшэд (хуудасны кэш гэх мэт) хэсэг хугацаанд хадгалж болно. Өгөгдлийг байнгын хадгалалтад үнэн зөв бичихийн тулд бичсэний дараа fdatasync системийн дуудлага шаардлагатай бөгөөд etcd үүнийг зүгээр л ашигладаг (ажлын үр дүнгээс харж болно). мөр, энд 8 нь WAL файлын тодорхойлогч):

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>

Харамсалтай нь байнгын санах ой руу бичих нь тэр дороо тохиолддоггүй. Хэрэв fdatasync дуудлага удаан байвал etcd системийн гүйцэтгэл муудна. etcd-ийн баримт бичигт ингэж бичсэн байнаХэрэв 99-р хувь дахь fdatasync дуудлагыг WAL файл руу бичихэд 10 мс-ээс бага хугацаа шаардагддаг бол хадгалалт хангалттай хурдан гэж тооцогддог. Хадгалахад хэрэгтэй бусад хэмжүүрүүд байдаг, гэхдээ энэ нийтлэлд бид зөвхөн энэ хэмжүүрийн тухай ярьж байна.

Fio ашиглан хадгалах санг тооцоолж байна

Хэрэв таны хадгалах сан etcd-д тохирох эсэхийг шалгах шаардлагатай бол оролт/гаралтын ачааллыг шалгах маш алдартай хэрэгсэл болох fio-г ашиглаарай. Дискний үйлдлүүд нь маш өөр байж болно гэдгийг санах нь зүйтэй: синхрон ба асинхрон, системийн дуудлагын олон ангиуд гэх мэт. Үүний үр дүнд fio-г ашиглахад нэлээд хэцүү байдаг. Энэ нь олон параметртэй бөгөөд тэдгээрийн утгуудын өөр өөр хослолууд нь маш өөр I/O ажлын ачааллыг үүсгэдэг. etcd-д тохирох тоон үзүүлэлтийг авахын тулд та WAL файлыг бичихдээ fio-ийн туршилтын бичих ачаалал etcd-ийн бодит ачаалалтай аль болох ойрхон байгаа эсэхийг шалгах хэрэгтэй.

Тиймээс, fio хамгийн багадаа файлд дараалсан бичих ачааллыг үүсгэх ёстой бөгөөд бичих бүр нь системийн дуудлагаас бүрдэнэ. бичихдараа нь fdatasync системийн дуудлага. fio руу дараалсан бичих нь --rw=write сонголтыг шаарддаг. Fio-ийн хувьд бичихдээ бичих системийн дуудлагыг ашиглахаас илүү бичих, та --ioengine=sync параметрийг зааж өгөх ёстой. Эцэст нь бичих болгоны дараа fdatasync дуудахын тулд та --fdatasync=1 параметрийг нэмэх хэрэгтэй. Энэ жишээний бусад хоёр сонголт (--size ба -bs) нь скриптэд зориулагдсан. Дараагийн хэсэгт бид тэдгээрийг хэрхэн тохируулахыг харуулах болно.

Яагаад fio, бид үүнийг хэрхэн тохируулж сурсан

Энэ нийтлэлд бид бодит тохиолдлыг тайлбарлах болно. Бидэнд кластер бий Kubernetes v1.13-ыг бид Prometheus-тай хамт хянаж байсан. etcd v3.2.24 нь SSD дээр байрладаг. Etcd хэмжигдэхүүнүүд нь кластер юу ч хийхгүй байсан ч fdatasync хоцролтыг хэт өндөр харуулсан. Хэмжигдэхүүнүүд нь хачирхалтай байсан бөгөөд бид юу гэсэн үг болохыг мэдэхгүй байсан. Кластер нь виртуал машинуудаас бүрдсэн тул асуудал юу болохыг ойлгох шаардлагатай байсан: физик SSD эсвэл виртуалчлалын давхаргад. Нэмж дурдахад бид ихэвчлэн техник хангамж, програм хангамжийн тохиргоонд өөрчлөлт оруулдаг байсан бөгөөд тэдгээрийн үр дүнг үнэлэх арга зам хэрэгтэй байсан. Бид бүх тохиргоонд etcd-г ажиллуулж, Prometheus хэмжигдэхүүнийг харж болох ч энэ нь хэтэрхий төвөгтэй юм. Бид тодорхой тохиргоог үнэлэх маш энгийн аргыг хайж байсан. Бид etcd-аас Prometheus хэмжигдэхүүнийг зөв ойлгож байгаа эсэхийг шалгахыг хүссэн.

Гэхдээ үүний тулд хоёр асуудлыг шийдэх ёстой байв. Нэгдүгээрт, WAL руу бичих үед etcd-ийн үүсгэсэн оролт/гаралтын ачаалал ямар харагддаг вэ? Ямар системийн дуудлагуудыг ашигладаг вэ? Бүртгэлийн хэмжээ хэд вэ? Хоёрдугаарт, хэрэв бид эдгээр асуултад хариулбал, бид ижил төстэй ажлын ачааллыг fio-тэй хэрхэн хуулбарлах вэ? Fio бол маш уян хатан, олон сонголттой хэрэгсэл гэдгийг бүү мартаарай. Бид хоёр асуудлыг нэг арга замаар шийдсэн - командуудыг ашиглан тийм и мөр. lsof нь процесст ашигладаг бүх файлын тодорхойлогч болон тэдгээртэй холбоотой файлуудыг жагсаадаг. Мөн strace-ийн тусламжтайгаар та аль хэдийн ажиллаж байгаа процессыг шалгаж эсвэл процессыг эхлүүлж, шалгаж болно. strace нь шалгаж буй процессын бүх системийн дуудлагыг хэвлэдэг (мөн түүний хүүхэд процессууд). Сүүлийнх нь маш чухал, учир нь etcd нь ижил төстэй арга барилыг авч байна.

Кластерт ачаалал байхгүй үед бид эхлээд Kubernetes-д зориулсан etcd серверийг судлахын тулд strace ашигласан. Бараг бүх WAL бичлэгүүд ижил хэмжээтэй байсныг бид харсан: 2200–2400 байт. Тиймээс, нийтлэлийн эхэнд байгаа команд дээр бид -bs=2300 параметрийг зааж өгсөн (bs гэдэг нь fio оруулга бүрийн байт дахь хэмжээг илэрхийлдэг). Etsd оруулгын хэмжээ нь etcd хувилбар, тархалт, параметрийн утга гэх мэтээс хамаарах ба fdatasync үргэлжлэх хугацаанд нөлөөлдөг гэдгийг анхаарна уу. Хэрэв танд ижил төстэй хувилбар байгаа бол нарийн тоог олохын тулд etcd процессуудаа шалгаарай.

Дараа нь etcd файлын систем юу хийж байгааг сайн ойлгохын тулд бид үүнийг strace болон -ffttT сонголтуудаас эхлүүлсэн. Тиймээс бид хүүхдийн процессуудыг шалгаж, тэдгээрийн гаралтыг тус тусад нь файлд бичиж, системийн дуудлагын эхлэл, үргэлжлэх хугацааны талаар нарийвчилсан тайлангуудыг авахыг хичээсэн. Бид lsof-ийг ашиглан strace гаралтын дүн шинжилгээг баталгаажуулж, ямар файлын тодорхойлогчийг ямар зорилгоор ашиглаж байгааг харна. Тиймээс strace-ийн тусламжтайгаар дээр үзүүлсэн үр дүнг олж авсан. Синхрончлолын цагийн статистик нь etcd-ийн wal_fsync_duration_seconds нь WAL файлын тодорхойлогчтой fdatasync дуудлагатай нийцэж байгааг баталсан.

Бид fio-ийн баримт бичгийг судалж үзээд fio нь etcd-тэй төстэй ачааллыг үүсгэхийн тулд скриптийнхээ сонголтыг сонгосон. Бид мөн etcd-тэй адил strace-аас fio-г ажиллуулж системийн дуудлагууд болон тэдгээрийн үргэлжлэх хугацааг шалгасан.

Бид fio-аас оролт/гаралтын ачааллыг бүхэлд нь илэрхийлэхийн тулд --size параметрийн утгыг анхааралтай сонгосон. Манай тохиолдолд энэ нь хадгалах санд бичигдсэн байтуудын нийт тоо юм. Энэ нь бичих (болон fdatasync) системийн дуудлагын тоотой шууд пропорциональ байсан. bs-ийн тодорхой утгын хувьд fdatasync дуудлагын тоо = size/bs. Бид хувь хэмжээг сонирхож байсан тул итгэлтэй байхын тулд хангалттай хэмжээний дээж авах шаардлагатай байсан бөгөөд бид 10^4 хангалттай байх болно гэж тооцоолсон (энэ нь 22 мебибайт). Хэрэв --size бага бол хэт давчуу үзүүлэлт гарч болзошгүй (жишээлбэл, хэд хэдэн fdatasync дуудлага ердийнхөөс удаан үргэлжилж, 99-р хувь нөлөөлдөг).

Өөрөө туршаад үзээрэй

Бид танд fio-г хэрхэн ашиглахыг харуулсан бөгөөд хадгалах сан нь etcd сайн ажиллахад хангалттай хурдан эсэхийг шалгана. Одоо та жишээ нь SSD санах ойтой виртуал машин ашиглан үүнийг өөрөө туршиж үзэх боломжтой IBM Cloud.

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх