Ko'p bepul operativ xotira, NVMe Intel P4500 va hamma narsa juda sekin - almashtirish bo'limining muvaffaqiyatsiz qo'shilishi haqidagi hikoya

Ushbu maqolada men yaqinda VPS bulutimizdagi serverlardan biri bilan sodir bo'lgan vaziyat haqida gapiraman, bu meni bir necha soat davomida qotib qoldirdi. Men taxminan 15 yil davomida Linux serverlarini sozlash va muammolarni bartaraf etish bilan shug'ullanaman, lekin bu holat mening amaliyotimga umuman to'g'ri kelmaydi - men bir nechta noto'g'ri taxminlar qildim va muammoning sababini to'g'ri aniqlash va uni hal qilishdan oldin biroz umidsizlikka tushdim. .

Ibtido

Biz o'rta o'lchamli bulutni boshqaramiz, uni quyidagi konfiguratsiyaga ega standart serverlarda quramiz - 32 yadro, 256 GB operativ xotira va 4500TB PCI-E Intel P4 NVMe drayveri. Bizga ushbu konfiguratsiya juda yoqadi, chunki u VM namunasi turi darajasida toʻgʻri cheklovni taʼminlash orqali IO qoʻshimcha xarajatlari haqida tashvishlanish zaruratini yoʻq qiladi. Chunki NVMe Intel P4500 ta'sirchan ishlashga ega, biz bir vaqtning o'zida mashinalar uchun to'liq IOPS ta'minotini va nol IOWAIT bilan zahiraviy serverga zaxira saqlashni ta'minlay olamiz.

Biz VM hajmlarini saqlash uchun giperkonverged SDN va boshqa zamonaviy, moda, yosh narsalardan foydalanmaydigan eski imonlilardanmiz, chunki tizim qanchalik sodda bo'lsa, "asosiy guru ketdi" sharoitida uni bartaraf etish osonroq bo'ladi. tog'larga." Natijada, biz VM hajmlarini QCOW2 formatida XFS yoki EXT4 formatida saqlaymiz, u LVM2 tepasida joylashgan.

Shuningdek, biz orkestratsiya uchun foydalanadigan mahsulot - Apache CloudStack tomonidan QCOW2 dan foydalanishga majburmiz.

Zaxira nusxasini yaratish uchun biz LVM2 oniy tasviri sifatida ovoz balandligining to'liq tasvirini olamiz (ha, biz LVM2 suratlari sekin ekanligini bilamiz, lekin Intel P4500 bu erda ham bizga yordam beradi). Biz qilamiz lvmcreate -s .. va yordami bilan dd biz zaxira nusxasini ZFS xotirasi bilan uzoq serverga yuboramiz. Bu erda biz hali ham biroz progressivmiz - axir, ZFS ma'lumotlarni siqilgan shaklda saqlashi mumkin va biz ularni tezda tiklashimiz mumkin. DD yoki yordamida individual VM hajmlarini oling mount -o loop ....

Siz, albatta, LVM2 hajmining to'liq tasvirini emas, balki fayl tizimini o'rnatishingiz mumkin RO va QCOW2 tasvirlarini o'zlaridan nusxa ko'chiring, ammo biz XFS zudlik bilan emas, balki oldindan aytib bo'lmaydigan tarzda yomonlashganiga duch keldik. Dam olish kunlarida, tunda yoki bayramlarda qachon sodir bo'lishi aniq bo'lmagan xatolar tufayli hipervisor xostlari to'satdan "yopishib" qo'yishi bizga juda yoqmaydi. Shuning uchun, XFS uchun biz snapshot o'rnatishdan foydalanmaymiz RO jildlarni chiqarish uchun biz shunchaki butun LVM2 hajmini nusxalaymiz.

Zaxira serveriga zaxiralash tezligi bizning holatlarimizda zaxira serverining ishlashi bilan belgilanadi, bu siqilmaydigan ma'lumotlar uchun taxminan 600-800 MB / s ni tashkil qiladi; boshqa cheklovchi bu zaxira serveri ulangan 10 Gbit / s kanaldir. klasterga.

Bunday holda, bir vaqtning o'zida bitta zaxira serverga 8 ta gipervisor serverlarining zaxira nusxalari yuklanadi. Shunday qilib, zaxira serverining disk va tarmoq quyi tizimlari sekinroq bo'lib, gipervisor xostlarining disk quyi tizimlarini ortiqcha yuklashga imkon bermaydi, chunki ular oddiygina, masalan, gipervisor xostlari osongina ishlashi mumkin bo'lgan 8 Gb/sek tezlikni qayta ishlay olmaydi. mahsulot.

Yuqoridagi nusxa ko'chirish jarayoni keyingi hikoya uchun juda muhim, jumladan tafsilotlar - tezkor Intel P4500 drayveridan foydalanish, NFS-dan foydalanish va, ehtimol, ZFS-dan foydalanish.

Zaxira hikoya

Har bir gipervisor tugunida bizda 8 GB hajmdagi kichik SWAP bo'limi mavjud va biz gipervizor tugunining o'zini "tashqariga chiqaramiz". DD mos yozuvlar rasmidan. Serverlardagi tizim hajmi uchun biz LSI yoki HP apparat boshqaruvchisida 2xSATA SSD RAID1 yoki 2xSAS HDD RAID1 dan foydalanamiz. Umuman olganda, biz ichida nima borligiga umuman ahamiyat bermaymiz, chunki bizning tizim hajmi SWAP-dan tashqari "deyarli faqat o'qish" rejimida ishlaydi. Va serverda juda ko'p RAM mavjud va u 30-40% bepul bo'lgani uchun biz SWAP haqida o'ylamaymiz.

Zaxiralash jarayoni. Bu vazifa quyidagicha ko'rinadi:

#!/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

E'tibor bering ionice -c3, aslida, bu narsa NVMe qurilmalari uchun mutlaqo foydasiz, chunki ular uchun IO rejalashtiruvchisi quyidagicha o'rnatiladi:

cat /sys/block/nvme0n1/queue/scheduler
[none] 

Biroq, bizda an'anaviy SSD RAID-larga ega bir qator eski tugunlar mavjud, ular uchun bu muhim, shuning uchun ular harakatlanmoqda. SHUNDAYKI. Umuman olganda, bu befoydalikni tushuntiradigan qiziqarli kod qismidir ionice bunday konfiguratsiya bo'lsa.

Bayroqqa e'tibor bering iflag=direct uchun DD. Biz o'qish paytida IO buferlarini keraksiz almashtirmaslik uchun bufer keshini chetlab o'tib, to'g'ridan-to'g'ri IO dan foydalanamiz. Biroq, oflag=direct Biz buni qilmaymiz, chunki biz uni ishlatishda ZFS ishlash muammolariga duch kelganmiz.

Biz ushbu sxemani bir necha yillardan beri muammosiz muvaffaqiyatli ishlatib kelmoqdamiz.

Va keyin boshlandi... Biz tugunlardan biri endi zaxiralanmaganligini va avvalgisi dahshatli IOWAIT 50% bilan ishlayotganini aniqladik. Nima uchun nusxa ko'chirish sodir bo'lmasligini tushunishga harakat qilganda, biz quyidagi hodisaga duch keldik:

Volume group "images" not found

Biz "Intel P4500 ning oxiri keldi" haqida o'ylay boshladik, ammo drayverni almashtirish uchun serverni o'chirishdan oldin hali ham zaxira nusxasini yaratish kerak edi. LVM2 zahirasidan metadata tiklash orqali LVM2 ni tuzatdik:

vgcfgrestore images

Biz zaxira nusxasini ishga tushirdik va ushbu moyli rasmni ko'rdik:

Biz yana juda xafa bo'ldik - biz bunday yashay olmasligimiz aniq edi, chunki barcha VPSlar azob chekishadi, ya'ni biz ham azob chekamiz. Nima bo'lganligi mutlaqo noma'lum - iostat achinarli IOPS va eng yuqori IOWAIT ko'rsatdi. "NVMe-ni almashtiramiz" dan boshqa g'oyalar yo'q edi, ammo o'z vaqtida tushuncha paydo bo'ldi.

Vaziyatni bosqichma-bosqich tahlil qilish

Tarixiy jurnal. Bir necha kun oldin, ushbu serverda 128 GB operativ xotiraga ega katta VPS yaratish kerak edi. Xotira yetarli bo'lib tuyuldi, ammo xavfsiz tomonda bo'lish uchun biz almashtirish bo'limi uchun yana 32 GB ajratdik. VPS yaratildi, o'z vazifasini muvaffaqiyatli bajardi va voqea unutildi, ammo SWAP bo'limi qoldi.

Konfiguratsiya xususiyatlari. Barcha bulutli serverlar uchun parametr vm.swappiness sukut bo'yicha o'rnatildi 60. Va SWAP SAS HDD RAID1 da yaratilgan.

Nima bo'ldi (tahririyatga ko'ra). Zaxiralashda DD juda ko'p yozish ma'lumotlarini ishlab chiqardi, ular NFSga yozishdan oldin RAM buferlariga joylashtirilgan. Siyosat asosida boshqariladigan tizim yadrosi swappiness, VPS xotirasining ko'p sahifalarini sekin HDD RAID1 hajmida joylashgan almashtirish maydoniga ko'chirdi. Bu IOWAIT ning juda kuchli o'sishiga olib keldi, lekin IO NVMe tufayli emas, balki IO HDD RAID1 tufayli.

Muammo qanday hal qilindi. 32 Gb almashtirish bo'limi o'chirilgan. Bu 16 soat davom etdi; SWAP qanday va nima uchun juda sekin o'chayotgani haqida alohida o'qishingiz mumkin. Sozlamalar o‘zgartirildi swappiness ga teng qiymatga 5 butun bulut bo'ylab.

Qanday qilib bunday bo'lmasligi mumkin edi?. Birinchidan, agar SWAP SSD RAID yoki NVMe qurilmasida bo'lsa, ikkinchidan, agar NVMe qurilmasi bo'lmasa, lekin bunday hajmdagi ma'lumotlarni ishlab chiqarmaydigan sekinroq qurilma bo'lsa - bu NVMe juda tez bo'lganligi sababli muammo yuzaga keldi.

Shundan so'ng, hamma narsa avvalgidek ishlay boshladi - nol IOWAIT bilan.

Manba: www.habr.com