Shumë RAM të lirë, NVMe Intel P4500 dhe gjithçka është duke ngecur — një histori mbi një shtesë të dështuar të ndarjes së shkarkimit.

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 P4500 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 RO dhe 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ë modalitetin RO e 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 servera 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-snap

Vini 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 gjet

Filluam 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 images

Nisim 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