Akeh RAM gratis, NVMe Intel P4500 lan kabeh alon banget - crita babagan tambahan partisi swap sing ora sukses

Ing artikel iki, aku bakal ngomong babagan kahanan sing bubar kedadeyan karo salah sawijining server ing awan VPS kita, sing nggawe aku bingung nganti pirang-pirang jam. Aku wis ngonfigurasi lan ngatasi masalah server Linux udakara udakara 15 taun, nanging kasus iki ora cocog karo praktikku - aku nggawe sawetara asumsi palsu lan nekat banget sadurunge aku bisa nemtokake sababe masalah kasebut lan ngrampungake. .

Preamble

We operate awan medium-ukuran, kang dibangun ing server standar karo konfigurasi ing ngisor iki - 32 intine, 256 GB RAM lan 4500TB PCI-E Intel P4 NVMe drive. Kita seneng banget karo konfigurasi iki amarga ora perlu kuwatir babagan overhead IO kanthi menehi watesan sing bener ing tingkat jinis conto VM. Amarga NVMe Intel P4500 wis kinerja nyengsemaken, kita bisa bebarengan nyedhiyani loro provisioning IOPS lengkap kanggo mesin lan panyimpenan serep menyang server serep karo nul IOWAIT.

Kita minangka salah sawijining wong percaya lawas sing ora nggunakake SDN hyperconverged lan barang-barang sing apik banget, modis, pemuda kanggo nyimpen volume VM, percaya yen sistem sing luwih gampang, luwih gampang ngatasi masalah kasebut ing kahanan "guru utama wis ilang. menyang gunung.” Akibaté, kita nyimpen volume VM ing format QCOW2 ing XFS utawa EXT4, sing disebarake ing ndhuwur LVM2.

Kita uga dipeksa nggunakake QCOW2 dening produk sing digunakake kanggo orkestrasi - Apache CloudStack.

Kanggo nindakake serep, kita njupuk gambar lengkap volume minangka gambar asli seko LVM2 (ya, kita ngerti sing jepretan LVM2 alon, nanging Intel P4500 mbantu kita metu kene uga). Kita nindakake lvmcreate -s .. lan kanthi bantuan dd kita ngirim salinan serep menyang server remot karo panyimpenan ZFS. Ing kene kita isih rada progresif - sawise kabeh, ZFS bisa nyimpen data ing wangun sing dikompres, lan kita bisa mulihake kanthi cepet nggunakake DD utawa njaluk volume VM individu nggunakake mount -o loop ....

Sampeyan bisa, mesthi, mbusak ora gambar lengkap volume LVM2, nanging Gunung sistem file ing RO lan nyalin gambar QCOW2 piyambak, Nanging, kita padha ngadhepi karo kasunyatan sing XFS dadi ala saka iki, lan ora langsung, nanging ing cara ranyono. Kita pancene ora seneng nalika hypervisor sarwa dumadi "kelet" dumadakan ing akhir minggu, ing wayah wengi utawa ing preian amarga kesalahan sing ora cetha nalika bakal kelakon. Mulane, kanggo XFS kita ora nggunakake snapshot mounting ing RO kanggo extract volume, kita mung nyalin kabeh volume LVM2.

Kacepetan serep menyang server serep ditemtokake ing kasus kita kanthi kinerja server serep, yaiku udakara 600-800 MB / s kanggo data sing ora bisa dikompres; watesan luwih lanjut yaiku saluran 10Gbit / s sing nyambungake server serep. menyang kluster.

Ing kasus iki, salinan serep 8 server hypervisor bebarengan diunggah menyang siji server serep. Mangkono, disk lan subsistem jaringan saka server serep, dadi luwih alon, ora ngidini subsistem disk saka host hypervisor overload, amarga mung ora bisa diproses, ucapake, 8 GB / sec, sing bisa ditindakake dening hypervisor host kanthi gampang. ngasilaken.

Proses nyalin ndhuwur iku penting banget kanggo crita luwih, kalebu rincian - nggunakake drive Intel P4500 cepet, nggunakake NFS lan, mbokmenawa, nggunakake ZFS.

Crita serep

Ing saben simpul hypervisor kita duwe partisi SWAP cilik ukuran 8 GB, lan kita "muter metu" simpul hypervisor dhewe nggunakake DD saka gambar referensi. Kanggo volume sistem ing server, kita nggunakake 2xSATA SSD RAID1 utawa 2xSAS HDD RAID1 ing controller hardware LSI utawa HP. Umumé, kita ora peduli apa sing ana ing njero, amarga volume sistem operasi ing mode "meh diwaca", kajaba SWAP. Lan wiwit kita duwe akeh RAM ing server lan iku 30-40% free , kita ora mikir bab SWAP.

Proses serep. Tugas iki katon kaya iki:

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

nggatekake ionice -c3, nyatane, perkara iki ora ana gunane kanggo piranti NVMe, amarga panjadwal IO kanggo piranti kasebut disetel minangka:

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

Nanging, kita duwe sawetara simpul warisan karo RAID SSD konvensional, kanggo wong-wong mau iki cocog, supaya padha obah. AS IS. Sakabèhé, iki mung potongan kode menarik sing nerangake futility ionice ing cilik saka konfigurasi kuwi.

Pay manungsa waé kanggo gendéra iflag=direct kanggo DD. Kita nggunakake IO langsung ngliwati cache buffer supaya ora ngganti buffer IO sing ora perlu nalika maca. Nanging, oflag=direct kita ora amarga kita wis nemokke masalah kinerja ZFS nalika nggunakake.

Kita wis nggunakake skema iki kanthi sukses sajrone pirang-pirang taun tanpa masalah.

Lan banjur wiwit... We katutup sing siji saka kelenjar wis ora digawe serep maneh, lan sadurunge mlaku karo IOWAIT monstrous 50%. Nalika nyoba mangertos kenapa nyalin ora kedadeyan, kita nemoni fenomena ing ngisor iki:

Volume group "images" not found

Kita wiwit mikir babagan "ing pungkasan wis teka kanggo Intel P4500," Nanging, sadurunge mateni server kanggo ngganti drive, isih kudu nggawe serep. Kita ndandani LVM2 kanthi mulihake metadata saka cadangan LVM2:

vgcfgrestore images

Kita ngluncurake serep lan ndeleng lukisan minyak iki:

Maneh, kita sedhih banget - jelas yen kita ora bisa urip kaya iki, amarga kabeh VPS bakal nandhang sangsara, tegese kita uga bakal nandhang sangsara. Apa sing kedadeyan ora jelas - iostat nuduhake IOPS melas lan IOWAIT paling dhuwur. Ora ana ide liyane kajaba "ayo ngganti NVMe," nanging ana wawasan sing kedadeyan.

Analisis kahanan langkah demi langkah

majalah sajarah. Sawetara dina sadurungé, ing server iki perlu kanggo nggawe VPS gedhe karo 128 GB RAM. Ana ketoke cukup memori, nanging ing sisih aman, kita diparengake liyane 32 GB kanggo pemisahan swap. VPS digawe, kasil ngrampungake tugas lan kedadeyan kasebut dilalekake, nanging partisi SWAP tetep.

Fitur Konfigurasi. Kanggo kabeh server maya parameter vm.swappiness disetel menyang gawan 60. Lan SWAP digawe ing SAS HDD RAID1.

Apa sing kedadeyan (miturut editor). Nalika gawe serep DD diprodhuksi akèh data nulis, kang diselehake ing buffer RAM sadurunge nulis kanggo NFS. Inti sistem, dipandu dening kabijakan swappiness, iki mindhah akeh kaca memori VPS menyang wilayah swap, kang dumunung ing volume HDD RAID1 alon. Iki nyebabake IOWAIT tuwuh banget, nanging ora amarga IO NVMe, nanging amarga IO HDD RAID1.

Carane masalah iki ditanggulangi. Partisi swap 32GB dipateni. Iki njupuk 16 jam; sampeyan bisa maca kanthi kapisah babagan carane lan ngapa SWAP dipateni alon-alon. Setelan wis diganti swappiness menyang nilai sing padha karo 5 kabeh liwat mega.

Kepiye carane iki ora kedadeyan?. Kaping pisanan, yen SWAP ana ing piranti SSD RAID utawa NVMe, lan kapindho, yen ora ana piranti NVMe, nanging piranti sing luwih alon sing ora bakal ngasilake volume data kasebut - ironis, masalah kasebut kedadeyan amarga NVMe kasebut cepet banget.

Sawise iku, kabeh wiwit bisa digunakake kaya sadurunge - karo nol IOWAIT.

Source: www.habr.com