Энэ нийтлэлд би саяхан манай VPS үүл дэх серверүүдийн нэгэнд тохиолдсон нөхцөл байдлын талаар ярих болно, энэ нь намайг хэдэн цагийн турш гацсан. Би 15 жилийн турш Линукс серверүүдийг тохируулж, алдааг олж засварлаж байгаа боловч энэ тохиолдол миний практикт огт тохирохгүй байна - Би хэд хэдэн худал таамаг дэвшүүлж, асуудлын шалтгааныг зөв тодорхойлж, шийдвэрлэхээс өмнө бага зэрэг цөхрөнгөө барсан. .
Оршил
Бид 32 цөм, 256 ГБ RAM болон 4500 TB PCI-E Intel P4 NVMe диск бүхий стандарт сервер дээр бүтээдэг дунд хэмжээний үүл ажиллуулдаг. Энэ тохиргоо нь VM инстанцийн төрлийн түвшинд зөв хязгаарлалтыг хангаснаар IO нэмэлт зардалд санаа зовох шаардлагагүй болсон тул бид үнэхээр дуртай. Учир нь NVMe Intel нь гайхалтай гүйцэтгэлтэй тул бид машинуудад IOPS-ийн бүрэн хангамж, IOWAIT-гүй нөөц серверт нөөц хадгалалтыг нэгэн зэрэг хангаж чадна.
Бид VM-ийн эзлэхүүнийг хадгалахын тулд хэт нийлсэн SDN болон бусад загварлаг, загварлаг, залуучуудын зүйлсийг ашигладаггүй хуучин итгэгчдийн нэг бөгөөд систем нь энгийн байх тусам "гол гуру явсан" нөхцөлд алдааг олж засварлахад хялбар болно гэж итгэдэг. уул руу." Үүний үр дүнд бид VM-ийн эзлэхүүнийг QCOW2 форматаар LVM4 дээр байрлуулсан XFS эсвэл EXT2 форматаар хадгалдаг.
Мөн бид зохион байгуулалтад ашигладаг Apache CloudStack бүтээгдэхүүнээр QCOW2-г ашиглахаас өөр аргагүй болдог.
Нөөцлөхийн тулд бид эзлэхүүний бүрэн зургийг LVM2 агшин зуурын хэлбэрээр авдаг (тиймээ, LVM2 агшин зуурын зураг удаан гэдгийг бид мэднэ, гэхдээ Intel P4500 бидэнд энд бас тусалдаг). Бид хийдэг lvmcreate -s .. мөн тусламжтайгаар dd Бид нөөц хуулбарыг ZFS санах ойтой алсын сервер рүү илгээдэг. Энд бид бага зэрэг дэвшилттэй хэвээр байна - эцэст нь ZFS өгөгдлийг шахсан хэлбэрээр хадгалах боломжтой бөгөөд бид үүнийг ашиглан хурдан сэргээх боломжтой. DD эсвэл ашиглан бие даасан VM хэмжээг авах mount -o loop ....
Мэдээжийн хэрэг та LVM2 эзлэхүүний бүрэн дүрсийг устгаж болохгүй, гэхдээ файлын системийг дотор нь холбож болно
ROмөн QCOW2 зургуудыг өөрсдөө хуулж авсан ч XFS үүнээс болж муу болсон тул тэр даруй биш, харин урьдчилан таамаглах аргагүй байдлаар нүүр тулсан. Хэзээ болох нь тодорхойгүй алдаанаас болж амралтын өдөр, шөнө эсвэл баярын өдрүүдэд гипервизорын хостууд гэнэт "наалддаг" нь бид үнэхээр дургүй. Тиймээс, XFS-ийн хувьд бид хормын хувилбарыг ашиглахгүйROэзлэхүүнийг задлахын тулд бид зүгээр л LVM2 эзлэхүүнийг бүхэлд нь хуулна.
Нөөц сервер рүү нөөцлөлт хийх хурд нь манай тохиолдолд нөөц серверийн гүйцэтгэлээр тодорхойлогддог бөгөөд энэ нь шахагдашгүй мэдээллийн хувьд ойролцоогоор 600-800 МБ/с байдаг бөгөөд өөр нэг хязгаарлагч нь нөөц сервер холбогдсон 10 Гбит/с суваг юм. кластер руу.
Энэ тохиолдолд 8 гипервизор серверийн нөөц хуулбарыг нэг нөөц серверт нэгэн зэрэг байршуулна. Иймээс нөөц серверийн диск болон сүлжээний дэд системүүд нь удаан байдаг тул гипервизорын хостуудын дискний дэд системүүдийг хэт ачаалахыг зөвшөөрдөггүй, учир нь тэд гипервизорын хостууд амархан ажиллуулж болох 8 ГБ/сек хурдыг боловсруулах боломжгүй байдаг. үйлдвэрлэх.
Дээрх хуулбарлах үйл явц нь цаашдын түүхийн хувьд маш чухал бөгөөд түүний дотор хурдан Intel P4500 дискийг ашиглах, NFS ашиглах, магадгүй ZFS ашиглах зэрэг болно.
Нөөц түүх
Гипервизорын зангилаа бүр дээр бид 8 ГБ хэмжээтэй жижиг SWAP хуваалттай бөгөөд бид гипервизорын зангилааг өөрөө "өнхрүүлдэг". DD лавлагаа зурагнаас. Сервер дээрх системийн эзлэхүүний хувьд бид LSI эсвэл HP техник хангамжийн хянагч дээр 2xSATA SSD RAID1 эсвэл 2xSAS HDD RAID1 ашигладаг. Ерөнхийдөө бидний системийн хэмжээ SWAP-аас бусад тохиолдолд "бараг л унших" горимд ажилладаг тул дотор нь юу байгаа нь бидэнд огт хамаагүй. Бид сервер дээр маш их хэмжээний RAM-тай бөгөөд 30-40% үнэ төлбөргүй байдаг тул SWAP-ийн талаар огт боддоггүй.
Нөөцлөх үйл явц. Энэ даалгавар нь иймэрхүү харагдаж байна:
#!/bin/bash
mkdir -p /mnt/backups/volumes
DIR=/mnt/images-snap
VOL=images/volume
DATE=$(date "+%d")
HOSTNAME=$(hostname)
lvcreate -s -n $VOL-snap -l100%FREE $VOL
ionice -c3 dd iflag=direct if=/dev/$VOL-snap bs=1M of=/mnt/backups/volumes/$HOSTNAME-$DATE.raw
lvremove -f $VOL-snapанхаарал хандуулах ionice -c3, үнэн хэрэгтээ энэ зүйл нь NVMe төхөөрөмжүүдийн хувьд огт хэрэггүй, учир нь тэдгээрийн IO төлөвлөгчийг дараах байдлаар тохируулсан болно.
cat /sys/block/nvme0n1/queue/scheduler
[none] Гэсэн хэдий ч бидэнд ердийн SSD RAID бүхий хэд хэдэн хуучин зангилаанууд байгаа бөгөөд энэ нь тэдний хувьд хамааралтай тул тэд хөдөлж байна. ЯГ БАЙНА. Ерөнхийдөө энэ бол зүгээр л ашиггүй байдлыг тайлбарласан сонирхолтой код юм ionice ийм тохиргоотой тохиолдолд.
Туг дээр анхаарлаа хандуулаарай iflag=direct нь DD. Унших үед IO буферийг шаардлагагүй солихоос зайлсхийхийн тулд бид буфер кэшийг тойрон шууд IO ашигладаг. Гэсэн хэдий ч, oflag=direct Бид үүнийг ашиглах үед ZFS-ийн гүйцэтгэлийн асуудалтай тулгарсан учраас тэгдэггүй.
Бид энэ схемийг хэдэн жилийн турш асуудалгүй амжилттай ашиглаж ирсэн.
Тэгээд л эхэлсэн... Бид нэг зангилаа нөөцлөхөө больсон бөгөөд өмнөх нь 50%-ийн аймшигт IOWAIT-тай ажиллаж байгааг олж мэдсэн. Яагаад хуулбарлахгүй байгааг ойлгохыг оролдох үед бид дараах үзэгдэлтэй тулгарсан.
Volume group "images" not foundБид "Intel P4500-ийн төгсгөл ирлээ" гэж бодож эхэлсэн боловч дискийг солихын тулд серверээ унтраахаас өмнө нөөцлөлт хийх шаардлагатай хэвээр байв. Бид LVM2 нөөцөөс мета өгөгдлийг сэргээж LVM2-г зассан:
vgcfgrestore imagesБид нөөцлөлтийг эхлүүлж, энэ тосон будгийг харсан:
Дахин бид маш их гунигтай байсан - бид ингэж амьдарч чадахгүй нь тодорхой байсан, учир нь бүх VPS-ууд зовж шаналах болно, энэ нь бид ч бас зовох болно гэсэн үг юм. Юу болсон нь бүрэн тодорхойгүй байна - iostat өрөвдмөөр IOPS болон хамгийн өндөр IOWAIT-ыг харуулсан. “NVMe-г орлуулъя” гэхээс өөр санаа байгаагүй ч яг цагаа олсон юм.
Нөхцөл байдалд алхам алхмаар дүн шинжилгээ хийх
Түүхийн сэтгүүл. Хэдхэн хоногийн өмнө энэ сервер дээр 128 ГБ RAM бүхий том VPS үүсгэх шаардлагатай болсон. Санах ой хангалттай байгаа мэт санагдсан ч аюулгүй байх үүднээс солилцооны хуваалтад зориулж өөр 32 ГБ хуваарилсан. VPS-г үүсгэж, даалгавраа амжилттай биелүүлж, үйл явдал мартагдсан боловч SWAP хуваалт хэвээр үлджээ.
Тохиргооны онцлогууд. Бүх үүл серверийн хувьд параметр vm.swappiness анхдагчаар тохируулсан 60. Мөн SWAP нь SAS HDD RAID1 дээр бүтээгдсэн.
Юу болсон бэ (редакторын хэлснээр). Нөөцлөх үед DD NFS-д бичихээс өмнө RAM-ийн буферт байрлуулсан маш олон бичих өгөгдлийг үйлдвэрлэсэн. Бодлогоор удирдуулсан системийн цөм swappiness, VPS санах ойн олон хуудсыг удаан HDD RAID1 эзлэхүүн дээр байрлах своп талбар руу шилжүүлж байсан. Энэ нь IOWAIT-ыг маш хүчтэй өсгөхөд хүргэсэн боловч IO NVMe-ээс биш, харин IO HDD RAID1-ийн улмаас.
Асуудлыг хэрхэн шийдсэн бэ. 32 ГБ-ын солилцооны хуваалтыг идэвхгүй болгосон. Үүнд 16 цаг зарцуулсан бөгөөд SWAP хэрхэн, яагаад ийм удаан унтардаг талаар та тусад нь уншиж болно. Тохиргоог өөрчилсөн swappiness -тэй тэнцүү утгатай байна 5 үүлэн дээгүүр.
Яаж ийм зүйл болохгүй гэж?. Нэгдүгээрт, хэрэв SWAP нь SSD RAID эсвэл NVMe төхөөрөмж дээр байсан бол, хоёрдугаарт, NVMe төхөөрөмж байхгүй байсан ч ийм хэмжээний өгөгдөл гаргахгүй удаан төхөөрөмж байсан бол энэ NVMe хэтэрхий хурдан учраас асуудал гарсан.
Үүний дараа бүх зүйл өмнөх шигээ ажиллаж эхэлсэн - тэг IOWAIT-тай.
Эх сурвалж: www.habr.com