🥇Fio-тэй дискүүдийг etcd |-д хангалттай гүйцэтгэлтэй эсэхийг хэрхэн шалгах вэ ProHoster

Анхаарна уу. орчуулга.: Энэхүү нийтлэл нь etcd мэдээллийн сангийн үйл ажиллагаатай холбоотой бодит асуудлын шийдлийг хайж IBM Cloud инженерүүдийн хийсэн мини судалгааны үр дүн юм. Үүнтэй төстэй даалгавар нь бидний хувьд хамааралтай байсан ч зохиогчдын бодол санаа, үйл ажиллагааны чиглэл нь илүү өргөн хүрээнд сонирхолтой байж магадгүй юм.

Нийтлэлийн товч тойм: fio and etcd

etcd кластерын гүйцэтгэл нь үндсэн хадгалалтын хурдаас ихээхэн хамаардаг. etcd нь гүйцэтгэлийг хянахын тулд янз бүрийн Prometheus хэмжигдэхүүнүүдийг экспортолдог. Тэдний нэг нь wal_fsync_duration_seconds. etcd-ийн баримт бичигт энэ нь хэлдэг, хэрэв энэ хэмжүүрийн 99-р хувь нь 10 мс-ээс хэтрээгүй бол хадгалалтыг хангалттай хурдан гэж үзэж болно...

Хэрэв та Линукс машинууд дээр etcd кластер байгуулахаар төлөвлөж байгаа бөгөөд хөтчүүд (SSD гэх мэт) хангалттай хурдан эсэхийг шалгахыг хүсвэл бид алдартай I/O тестерийг ашиглахыг зөвлөж байна. fio. Зүгээр л дараах тушаалыг ажиллуулна уу (лавлах test-data шалгагдсан хөтөчийн суурилуулсан хэсэгт байрлах ёстой):

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

Зөвхөн гаралтыг харж, 99-р хувь тохирох эсэхийг шалгахад л үлддэг fdatasync 10 мс-д. Хэрэв тийм бол таны хөтөч хангалттай хурдан ажиллаж байна. Энд жишээ гаралт байна:

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]

Хэд хэдэн тэмдэглэл:

Дээрх жишээн дээр бид параметрүүдийг тохируулсан --size и --bs тодорхой тохиолдолд. -аас утга учиртай үр дүнд хүрэхийн тулд fio, ашиглах тохиолдолд тохирох утгуудыг зааж өгнө үү. Тэдгээрийг хэрхэн сонгох талаар доор хэлэлцэх болно.
Зөвхөн туршилтын үеэр fio дискний дэд системийг ачаална. Бодит амьдрал дээр бусад процессууд диск рүү бичих магадлалтай (холбогдохоос гадна wal_fsync_duration_seconds). Энэ нэмэлт ачаалал нэмэгдэж болно wal_fsync_duration_seconds. Өөрөөр хэлбэл, хэрэв 99-р хувьтай тест хийсэн бол fio, 10 мс-ээс бага зэрэг бага хугацаатай, хадгалах чадвар хангалтгүй байх магадлал өндөр байна.
Туршилтын хувьд танд хувилбар хэрэгтэй болно fio 3.5-аас доошгүй, хуучин хувилбарууд нь үр дүнг нэгтгэдэггүй fdatasync хувь хэлбэрээр.
Дээрх дүгнэлт нь ерөнхий дүгнэлтээс зөвхөн жижиг хэсэг юм fio.

fio болон бусад зүйлсийн талаар дэлгэрэнгүй

WAL гэх мэтийн талаар хэдэн үг хэлье

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

Тиймээс үйлчлүүлэгч KV дэлгүүрт түлхүүр нэмэх эсвэл одоо байгаа түлхүүрийн утгыг шинэчлэх болгонд etcd нь байнгын дэлгүүрт байдаг ердийн файл болох WAL-д үйлдлийнхээ тайлбарыг нэмдэг. etcd үргэлжлүүлэхийн өмнө WAL оруулга үнэхээр хадгалагдсан гэдэгт 100% итгэлтэй байх ЗААВАЛ. Линукс дээр үүнийг хэрэгжүүлэхийн тулд системийн дуудлагыг ашиглах нь хангалтгүй юм write, учир нь биет зөөвөрлөгч рүү бичих үйлдэл нь хойшлогдож магадгүй юм. Жишээлбэл, Линукс нь WAL оруулгыг санах ойн цөмийн кэшэд (жишээ нь, хуудасны кэш) хэсэг хугацаанд хадгалж болно. Мэдээллийг зөөвөрлөгч рүү бичсэн эсэхийг баталгаажуулахын тулд бичсний дараа системийн дуудлагыг дуудах ёстой fdatasync - энэ бол яг etd-ийн хийдэг зүйл юм (та дараах гаралтаас харж болно strace; Энд 8 - WAL файлын тодорхойлогч):

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>

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

Хадгалах санг fio ашиглан үнэлж байна

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

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

Бид яагаад fio-г сонгосон, хэрхэн тохируулах талаар сурсан

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

Нэмж дурдахад бид техник хангамж, програм хангамжийн тохиргоонд янз бүрийн өөрчлөлтүүдийг авч үзсэн тул тэдгээрийг үнэлэх арга зам хэрэгтэй болсон. Мэдээжийн хэрэг, тохиргоо бүрд etcd-г ажиллуулж, Prometheus-ийн харгалзах хэмжүүрүүдийг харах боломжтой боловч үүнд ихээхэн хүчин чармайлт шаардагдана. Бидэнд хэрэгтэй зүйл бол тодорхой тохиргоог үнэлэх энгийн арга байсан. Бид etcd-ээс ирсэн Prometheus хэмжигдэхүүнүүдийн талаарх ойлголтоо шалгахыг хүссэн.

Энэ нь хоёр асуудлыг шийдэх шаардлагатай байв:

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

Бид хоёр асуудлыг ижил тушаалд суурилсан аргаар шийдсэн lsof и strace:

Тусламжийн тусламжтайгаар lsof Та процесст ашигладаг бүх файлын тодорхойлогч, мөн тэдгээрт хамаарах файлуудыг харах боломжтой.
Тусламжийн тусламжтайгаар strace Та аль хэдийн ажиллаж байгаа процесст дүн шинжилгээ хийх эсвэл процессыг ажиллуулж, ажиглаж болно. Энэ команд нь энэ процессоор хийгдсэн бүх системийн дуудлагууд болон сонголтоор түүний үр удамуудыг харуулдаг. Сүүлийнх нь салаа процессуудад чухал ач холбогдолтой ба etcd нь ийм процессуудын нэг юм.

Бидний хийсэн хамгийн эхний зүйл бол ашиглах явдал байв strace Kubernetes кластер дахь etcd серверийг идэвхгүй байхад нь шалгах.

Тиймээс WAL бичлэгийн блокууд нь маш нягт бүлэглэгдсэн, дийлэнх нь 2200-2400 байт хэмжээтэй байдаг нь тогтоогдсон. Тийм ч учраас энэ өгүүллийн эхэнд байгаа тушаал нь тугийг ашигладаг --bs=2300 (bs нь бичих блок бүрийн байтаар илэрхийлсэн хэмжээ юм fio).

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

Дараа нь, etcd файлын системтэй хэрхэн ажилладаг талаар тодорхой бөгөөд иж бүрэн ойлголт авахын тулд бид үүнийг доороос нь ажиллуулсан. strace тугуудтай -ffttT. Энэ нь хүүхдийн процессуудыг авч, тус бүрийн гаралтыг тусдаа файлд бичих боломжтой болсон. Түүнчлэн системийн дуудлага бүрийн эхлэх цаг, үргэлжлэх хугацааны талаарх дэлгэрэнгүй мэдээллийг авсан.

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

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

Параметрийн утгыг тодорхойлоход онцгой анхаарал хандуулсан --size. Энэ нь fio хэрэгслээр үүсгэгдсэн нийт оролт/гаралтын ачааллыг илэрхийлнэ. Манай тохиолдолд энэ нь хэвлэл мэдээллийн хэрэгсэлд бичсэн нийт байт юм. Энэ нь дуудлагын тоотой шууд пропорциональ байна write (ба fdatasync). Тодорхой зүйлийн хувьд bs дуудлагын тоо fdatasync тэнцүү байна size / bs.

Бид хувь хэмжээг сонирхож байсан тул дээжийн тоог статистикийн хувьд хангалттай их байлгахыг хүссэн. Тэгээд шийдсэн 10^4 (энэ нь 22 МБ хэмжээтэй тохирч байна) хангалттай байх болно. Жижиг параметрийн утгууд --size илүү тод дуу чимээ гаргасан (жишээлбэл, дуудлага fdatasync, энэ нь ердийнхөөс хамаагүй удаан үргэлжилж, 99-р хувь) нөлөөлдөг).

Энэ нь танаас хамаарна

Хэрхэн ашиглахыг нийтлэлд харуулав fio etcd-тэй ашиглахад зориулагдсан медиа хангалттай хурдан эсэхийг шүүж болно. Одоо танаас шалтгаална! Та үйлчилгээнд SSD-д суурилсан санах ойтой виртуал машинуудыг судлах боломжтой IBM Cloud.

Орчуулагчийн жич

Бэлэн хэрэглээний хайрцагтай fio Бусад даалгавруудыг үзнэ үү баримт бичиг эсвэл шууд төслийн агуулахууд (баримт бичигт дурдсанаас илүү олон тоо байдаг).

Орчуулагчаас авсан PPS

Мөн манай блог дээрээс уншина уу:

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

Fio-тэй дискүүдийг etcd-д хангалттай гүйцэтгэлтэй эсэхийг хэрхэн шалгах вэ