NĂ« kĂ«tĂ« artikull do tĂ« flas pĂ«r situatĂ«n qĂ« ndodhi sĂ« fundi me njĂ« nga serverat e cloud VPS tonĂ«, e cila mĂ« la tĂ« bllokuar pĂ«r disa orĂ«. Kam rreth 15 vjet qĂ« merrem me konfigurimin dhe troubleshootimin e serverave Linux, por ky rast nuk pĂ«rputhet fare me praktikĂ«n time â bĂ«ra disa supozime tĂ« gabuara dhe pak deshperohem para se tĂ« isha nĂ« gjendje tĂ« pĂ«rcaktoja saktĂ« shkakun e problemit dhe ta zgjidhja atĂ«.
Preambula
Ne operojmĂ« njĂ« cloud me madhĂ«si mesatare, tĂ« cilin e ndĂ«rtojmĂ« nĂ« serverĂ« standardĂ« me konfigurimin e mĂ«poshtĂ«m â 32 bĂ«rthama, 256 GB RAM dhe njĂ« disk NVMe PCI-E Intel P4500 me kapacitet prej 4TB. Na pĂ«lqen shumĂ« kjo konfigurim, sepse na lejon tĂ« mos mendojmĂ« pĂ«r mungesĂ«n e I/O, duke siguruar njĂ« kufizim korrekt nĂ« nivelin e llojeve tĂ« instancave (ekspozitave) VM. Duke qenĂ« se NVMe Intel ka njĂ« performancĂ« mbresĂ«lĂ«nĂ«se, ne mund tĂ« ofrojmĂ« njĂ«kohĂ«sisht si plotĂ«simin e plotĂ« tĂ« IOPS pĂ«r makinat, ashtu edhe kopjimin e rezervĂ«s tĂ« ruajtjes nĂ« serverin e kopjimit me IOWAIT zero.
Ne i përkasim atyre të vjetërve që nuk përdorin SDN hiperkonvergjente dhe gjëra të tjera moderne, të modës, për ruajtjen e volumesh VM, duke menduar se sa më e thjeshtë të jetë sistemi, aq më e lehtë është për t'u diagnostikuar në kushte "guruja kryesor iku në male". Më në fund, ne ruajmë volumet VM në formatin QCOW2 në XFS ose EXT4, të cilat janë të instaluara mbi LVM2.
PĂ«rdorimi i QCOW2 na detyron gjithashtu produkti qĂ« pĂ«rdorim pĂ«r orkestrimin â Apache CloudStack.
PĂ«r tĂ« kryer backup, ne marrim njĂ« imazh tĂ« plotĂ« tĂ« volumit, si njĂ« snapshot LVM2 (po, e dimĂ« qĂ« snapshotet 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Ă« backup-in nĂ« serverin tĂ« largĂ«t me ruajtjen ZFS. KĂ«tu jemi pak progresivĂ« â ZFS di tĂ« ruajĂ« tĂ« dhĂ«nat nĂ« format tĂ« kompresuar, dhe ne mund t'i rikthejmĂ« ato shpejt me DD ose tĂ« marrim volumet e veçanta VM me mount -o loop ....
Natyrisht, mund të marrim edhe një imazh tjetër të plotë të volumit LVM2, por të bëjmë montimin e sistemit të dosjeve në modalitetin
ROdhe kopjoni vetë imazhet QCOW2, megjithatë, kemi hasur se XFS bëhej i pavlefshëm për këtë, ndonjëherë jo menjëherë, por në mënyrë të paparashikueshme. Ne nuk na pëlqen kur hostet-hypervizor 'ngjiten' papritur gjatë fundjavave, natën ose festave për shkak të gabimeve që nuk është e qartë kur ndodhin. Prandaj, për XFS, nuk përdorim montimin e kopjeve në modalitetinROe nxjerrjes së volumeve, por thjesht kopjojmë të gjithë volume LVM2.
Shpejtësia e kopjimit në serverin e kopjeve përcaktohet në rastin tonë nga performanca e serverit të kopjeve, e cila është rreth 600-800 MB/s për të dhënat që nuk mund të kompresohen, dhe një tjetër kufi është kanali 10Gbit/s, me të cilin serveri i kopjeve është i lidhur me klasterin.
Në këtë mënyrë, një server i vetëm kopjimi ngarkon njëkohësisht kopjet e 8 serverëve hypervizorëve. Kështu, sistemet e diskut dhe rrjetit të serverit të kopjeve, duke qenë më të ngadalta, nuk lejojnë mbingarkesën e sistemeve të diskut të hosteve-hypervizor, pasi thjesht nuk janë në gjendje të përballojnë, le të themi, 8 GB/sek, të cilat mund të ofrojnë pa ndjenja hostet-hypervizor.
Procesi i përshkruar më sipër i kopjimit është shumë i rëndësishëm për vazhdimin e rrëfimit, duke përfshirë detajet - përdorimin e disku të shpejtë Intel P4500, përdorimin e NFS dhe, me shumë gjasë, përdorimin e ZFS.
Historia e backup-it
Në çdo nod-hypervisor kemi një seksion të vogël SWAP me madhësi 8 GB, ndërsa nod-hypervisor e "instalojmë" me DD nga imazhi standard. Për volumet sistemike në servera ne përdorim 2xSATA SSD RAID1 ose 2xSAS HDD RAID1 në kontrolluesin harduerik LSI ose HP. Në përgjithësi, nuk na intereson shumë çfarë është aty brenda, pasi volumi sistemik funksionon në modalitetin "gati lexim", përveç SWAP-it. Dhe, përqindja e RAM-it në server është shumë e lartë dhe 30-40% e saj është e lirë, kështu që për SWAP-in nuk mendojmë.
Procesi i krijimit të backup-it. Kjo 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-snapVini re 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ë, kemi disa nod-e legacy me SSD RAID të zakonshme, për ta kjo është relevante, dhe për këtë arsye po kalon AS IS. Në përgjithësi, kjo është një copëz interesante kod që shpjegon kotësinë ionice në rastin e tillë të konfigurimit.
Kujdesi për flamurin iflag=direct për DD. Ne përdorim IO direkt pa cache buffer për të shmangur zëvendësimet e tepërta të bufferave IO gjatë leximit. Megjithatë, oflag=direct ne nuk e bëjmë këtë, pasi kemi hasur probleme me performancën e ZFS gjatë përdorimit të tij.
Ky skemë është përdorur me sukses prej disa vitesh pa probleme.
Dhe këtu filloi⊠Ne zbuluam se për një nga nyjet kishte ndaluar kopjimi, dhe kopjimi i mëparshëm ishte kryer me një IOWAIT të tmerrshëm prej 50%. Kur përpiqeshim të kuptonim pse nuk po ndodhte kopjimi, u përballëm me fenomenin:
Grupi i volumit "imazhe" nuk u gjetFilluam të mendojmë për "fundin që i erdhi Intel P4500", megjithatë, para se të ndalonim serverin për të zëvendësuar disku, ishte e nevojshme të kryejmë ende kopjimin. E rimëkëmbëm LVM2 duke rikuperuar metadatat nga backup-i i LVM2:
vgcfgrestore imagesNisim kopjimin dhe shohim këtë pamje:
PĂ«rsĂ«ri filluam tĂ« jemi shumĂ« tĂ« trishtuar â ishte e qartĂ« qĂ« kĂ«shtu nuk mund tĂ« jetonim, pasi tĂ« gjitha VPS-tĂ« do tĂ« vuajtĂ«n, dhe kĂ«shtu do tĂ« vuajmĂ« edhe ne. ĂfarĂ« ndodhi, nuk ishte e qartĂ« â iostat tregoi tregtie IOPS dhe IOWAIT tĂ« lartĂ«. Nuk kishte ndonjĂ« ide pĂ«rveç "le tĂ« zĂ«vendĂ«sojmĂ« NVMe", por ndodhi njĂ« zbulim nĂ« kohĂ«.
Analiza e situatës hap pas hapi
Dita historike. Disa ditë më parë, në këtë server u kërkua të krijohej një VPS e madhe me 128 GB RAM. Memorja duket se ishte e mjaftueshme, por për siguri u ndan edhe 32 GB për ndarjen e swap-it. VPS u krijua, zgjidh problemi e saj dhe incidenti u harrua, ndërsa ndarja SWAP mbeti.
Veçoritë e konfigurimit. Për të gjitha serverët në re, parametri vm.swappiness u vendos në vlerën e paracaktuar 60. Ndërsa SWAP u krijua në SAS HDD RAID1.
ĂfarĂ« ndodhi (sipĂ«r mendimit tĂ« redaksisĂ«). GjatĂ« kopjimit tĂ« rezervave DD jepte shumĂ« tĂ« dhĂ«na pĂ«r shkrim, tĂ« cilat u vendosĂ«n nĂ« buferat e RAM para se tĂ« shkruheshin nĂ« NFS. BĂ«rthama e sistemit, duke u drejtuar nga politika e swappiness, transferonte shumĂ« faqe memorjeje VPS nĂ« zonĂ«n e swap-it, e cila ishte nĂ« vĂ«llimin e ngadaltĂ« HDD RAID1. Kjo bĂ«ri qĂ« IOWAIT tĂ« rritej shumĂ«, por jo pĂ«r shkak tĂ« IO NVMe, por pĂ«r shkak tĂ« IO HDD RAID1.
Si u zgjidh problemi. U ndal 32GB e ndarjes së të dhënave. Kjo zgjati 16 orë; përsa i përket arsyeve pse SWAP u çaktivizua kaq ngadalë, mund të lexoni veçmas. Janë ndryshuar parametrat swappiness në një vlerë të barabartë me 5 në të gjithë cloud-in.
Si mund tĂ« ndodhte kjo. SĂ« pari, po tĂ« ishte SWAP nĂ« SSD RAID ose nĂ« njĂ« pajisje NVMe, sĂ« dyti, po tĂ« mos kishte pajisje NVMe, por njĂ« pajisje mĂ« tĂ« ngadalshme qĂ« nuk do tĂ« jepte kaq shumĂ« tĂ« dhĂ«na â pĂ«r ironi, problemi ndodhi pikĂ«risht sepse NVMe Ă«shtĂ« shumĂ« i shpejtĂ«.
Pas kĂ«saj, gjithçka filloi tĂ« funksiononte si mĂ« parĂ« â me IOWAIT zero.
Burimi: habr.com
