NĂ« kĂ«tĂ« artikull, do tĂ« flas pĂ«r njĂ« situatĂ« qĂ« ndodhi sĂ« fundmi me njĂ« nga serverĂ«t e cloud tonĂ« VPS, qĂ« mĂ« la pa fjalĂ« pĂ«r disa orĂ«. Kam rreth 15 vjet qĂ« merrem me konfigurimin dhe zgjidhjen e problemeve tĂ« serverĂ«ve Linux, por ky rast nuk pĂ«rputhet fare me praktikat e mia â bĂ«ra disa supozime tĂ« gabuara dhe paksa u dĂ«shpĂ«rova pĂ«rpara se tĂ« mund tĂ« pĂ«rcaktoj saktĂ«sisht shkakun e problemit dhe ta zgjidhja atĂ«.
Preambula
Ne operojmĂ« njĂ« cloud me pĂ«rmasa tĂ« mesme, tĂ« cilin e ndĂ«rtuam nĂ« serverĂ« standardĂ« me kĂ«tĂ« konfigurim â 32 bĂ«rthama, 256 GB RAM dhe njĂ« disk NVMe PCI-E Intel P4500 me kapacitet 4TB. Na pĂ«lqen shumĂ« kjo konfigurim, pasi na lejon tĂ« mos mendojmĂ« pĂ«r mungesĂ«n e IO, duke siguruar njĂ« kufizim tĂ« saktĂ« nĂ« nivelin e llojeve tĂ« instancave (ekzemplarĂ«ve) VM. Duke qenĂ« se NVMe Intel ka njĂ« performancĂ« mbresĂ«lĂ«nĂ«se, ne mund tĂ« ofrojmĂ« nĂ« tĂ« njĂ«jtĂ«n kohĂ« si IOPS tĂ« plota pĂ«r makinat, ashtu edhe rezervimin e ruajtjes nĂ« serverin e kopjimeve rezervĂ« pa kosto tĂ« IOWAIT.
Ne jemi ata vetë të vjetër që nuk përdorim SDN hiperkonvergjente dhe gjërat e tjera stiliste, të modës dhe rinore për ruajtjen e volumeve VM, duke besuar se sa më e thjeshtë të jetë sistemi, aq më e lehtë është zgjidhja e problemeve në kushte "guri guru iku në mal". Si rezultat, ne ruajmë volume VM në format QCOW2 në XFS ose EXT4, të cilat zhvillohen mbi LVM2.
PĂ«rdorimi i QCOW2 na detyrohet gjithashtu nga produkti qĂ« pĂ«rdorim pĂ«r orkestrimin â Apache CloudStack.
PĂ«r tĂ« kryer rezervimin, ne marrim njĂ« imazh tĂ« plotĂ« tĂ« volumit, si njĂ« snapshot LVM2 (po, e dimĂ« qĂ« snapshot-et LVM2 janĂ« tĂ« ngadalta, por Intel P4500 na ndihmon edhe kĂ«tu). Ne bĂ«jmĂ« lvmcreate -s .. dhe me ndihmĂ«n e dd dĂ«rgojmĂ« rezervimin nĂ« njĂ« server tĂ« largĂ«t me ruajtje ZFS. KĂ«tu jemi paksa progresivĂ« â ZFS di tĂ« ruajĂ« tĂ« dhĂ«nat nĂ« format tĂ« kompakt, dhe ne mund t'i rikuperojmĂ« ato shpejt me DD ose tĂ« nxjerrim volume tĂ« veçanta VM me ndihmĂ«n e mount -o loop ....
Natyrisht, mund të krijohet edhe imazhi jo i plotë i volumit LVM2, duke montuar sistemin e skedave në mënyrë
ROdhe të kopjoni vetë imazhet QCOW2, megjithatë, ne jemi ndeshur me faktin se XFS fillonte të shkonte keq, duke ndodhur jo menjëherë, por në mënyrë të paqartë. Ne nuk e pëlqejmë aspak kur hypervisorët "ngjiten" papritur në fundjavë, natën ose për festa për shkak të gabimeve që nuk dihet kur do të ndodhin. Prandaj, për XFS ne nuk përdorim montimin e Snapshot në mënyrëROpër nxjerrjen e volumit, por thjesht kopjojmë të gjithë volumet LVM2.
Shpejtësia e kopjimit në serverin e kopjeve përcaktohet në rastin tonë nga performanca e serverit të kopjeve, i cili arrin rreth 600-800 MB/s për të dhënat e pa kompresuara, ndërsa kufiri tjetër është kanali 10Gbit/s, me të cilin është lidhur serveri i kopjeve me klustërin.
Në të njëjtën kohë, një server kopjesh ngarkon kopjet e rezervuara për 8 serverësh hypervisorë. Kështu, sistemet diskore dhe rrjetë të serverit të kopjeve, duke qenë më të ngadalta, nuk i japin mundësi për të ngarkuar sistemet diskore të hypervisorëve, pasi thjesht nuk janë në gjendje të përpunojnë, për shembull, 8 GB/s, që hypervisorët mund t'i ofrojnë pa ndonjë vështirësi.
Procesi i pĂ«rshkruar mĂ« sipĂ«r i kopjimit Ă«shtĂ« shumĂ« i rĂ«ndĂ«sishĂ«m pĂ«r rrĂ«fimin e mĂ«tejshĂ«m, duke pĂ«rfshirĂ« detajet â pĂ«rdorimin e ruajtĂ«sit tĂ« shpejtĂ« Intel P4500, pĂ«rdorimin e NFS dhe ndoshta pĂ«rdorimin e ZFS.
Historiku i kopjimit
Në çdo nyjë hypervisor kemi një seksion të vogël SWAP me përmasë 8 GB, dhe nyja hypervisor ajo është ndërtuar me DD nga një imazh referencë. Për volumet sistemore në serverë ne përdorim 2xSATA SSD RAID1 ose 2xSAS HDD RAID1 në kontrollorin e pajisjeve LSI ose HP. Në përgjithësi, nuk na intereson aspak se çfarë ndodhet brenda, pasi volumi sistemor punon në mënyrën "gati readonly", përveç SWAP-it. Dhe pasi kemi shumë RAM në server dhe ajo është e lirë 30-40%, ne nuk mendojmë për SWAP-in.
Procesi i krijimit të një kopjeje. Ky detyrë duket kështu:
#!/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-snapKujdesi për ionice -c3, në fakt kjo gjë është krejt e padobishme për pajisjet NVMe, pasi planifikuesi IO për to është vendosur si:
cat /sys/block/nvme0n1/queue/scheduler
[none] Megjithatë, ne kemi disa nyje të trashëguara me RAID SSD të zakonshme, për ta kjo është relevante, kështu që ajo po kalon AS IS. Në përgjithësi, ky është një copë interesante kodi që shpjegon kotësinë ionice në rast të tillë konfiguratash.
Vini re flamurin iflag=direct për DD. Ne përdorim direct IO përtej caches buffer, për të shmangur zëvendosje të panevojshme të bufferave IO gjatë leximit. Sidoqoftë, oflag=direct ne nuk e bëjmë këtë, pasi kemi hasur në probleme me performancën e ZFS kur e përdorim.
Ky skemë është përdorur me sukses prej disa vitesh pa probleme.
Dhe këtu filloi⊠Zbuluam se për një nga node-t kishte ndaluar kopjimi rezervë, ndërsa ai i mëparshmi ishte realizuar me një IOWAIT monstruoz prej 50%. Kur u përpoqëm të kuptonim pse nuk po ndodhte kopjimi, përballëm me fenomenin:
Grupi i volumit "images" nuk u gjetFilluam të mendonim për "fundin e erdhi Intel P4500", megjithatë, përpara se të mbyllnim serverin për të zëvendësuar diskun, duhej ende të bëhej kopjimi rezervë. Korrigjuam LVM2 duke rikuperuar metadatat nga backup i LVM2:
vgcfgrestore imagesNisa copën e kopjimit dhe pamë këtë pamje:
PĂ«rsĂ«ri u mĂ«rzitim shumĂ« â ishte e qartĂ« se nuk mund tĂ« jetonim kĂ«shtu, pasi tĂ« gjithĂ« VPS do tĂ« vuajnĂ«, dhe pĂ«r rrjedhojĂ« do tĂ« vuajmĂ« edhe ne. ĂfarĂ« po ndodhte, nuk ishte krejtĂ«sisht e qartĂ« â iostat tregonte IOPS shumĂ« tĂ« dobĂ«t dhe IOWAIT tĂ« lartĂ«. Ide tĂ« tjera, pĂ«rveç "le tĂ« zĂ«vendĂ«sojmĂ« NVMe", nuk kishte, por ndodhi momenti i ndriçimit nĂ« kohĂ«n e duhur.
Analiza e situatës hap pas hapi
Ditar historik. Disa ditë më parë në këtë server ndihmoi të krijohej një VPS e madhe me 128 GB RAM. Memoria dukej se ishte e mjaftueshme, por për siguri u ndanë edhe 32 GB për pjesën e swap-it. VPS u krijua, përmbushi qëllimin e saj dhe incidenti u harrua, ndërsa pjesa SWAP mbeti.
Karakteristikat e konfigurimit. Për të gjitha serverët e cloud-it, parametrin vm.swappiness u caktua te vlera e paracaktuar 60. Pjesa SWAP u krijua në SAS HDD RAID1.
ĂfarĂ« po ndodhte (sipas redaksisĂ«). GjatĂ« kopjimit rezervĂ« DD shkruante shumĂ« tĂ« dhĂ«na, tĂ« cilat vendoseshin nĂ« buffers RAM pĂ«rpara se tĂ« shkruheshin nĂ« NFS. BĂ«rthama e sistemit, duke u drejtuar nga politika swappiness, transferonte shumĂ« faqe tĂ« memories sĂ« VPS nĂ« zonĂ«n e swap-it, e cila ndodhej nĂ« volum tĂ« ngadalshĂ«m HDD RAID1. Kjo çonte nĂ« rritjen e madhe tĂ« IOWAIT, por jo pĂ«r shkak tĂ« IO NVMe, por pĂ«r shkak tĂ« IO HDD RAID1.
Si u zgjidh problemi. U çaktivizua pjesa e swap-it 32GB. Kjo zuri 16 orë, për mënyrën se si dhe pse SWAP çaktivizohet kaq ngadalë, mund të lexoni veçmas. U ndryshuan parametrat swappiness në një vlerë të barabartë 5 në gjithë cloud-in.
Si do tĂ« mund tĂ« ndodhte kjo. SĂ« pari, nĂ«se SWAP do tĂ« ishte nĂ« njĂ« SSD RAID ose pajisje NVMe, sĂ« dyti, nĂ«se nuk do tĂ« kishte njĂ« pajisje NVMe, por do tĂ« kishte njĂ« pajisje mĂ« tĂ« ngadaltĂ« qĂ« nuk do tĂ« jepte njĂ« volum tĂ« tillĂ« tĂ« dhĂ«nash â pĂ«r ironi, problemi ndodhi ngjashĂ«m pĂ«r shkak se NVMe ishte shumĂ« i shpejtĂ«.
Pas kĂ«saj, tĂ« gjitha filloi tĂ« punonte si mĂ« parĂ« â me IOWAIT zero.
Burimi: habr.com
