Palju vaba RAM-i, NVMe Intel P4500 ja kõik tõmbab täiesti kinni — lugu ebaõnnestunud vahetusruumi jagamise lisamisest.

Selles artiklis räägin olukorrast, mis hiljuti juhtus ühe meie VPS-i pilveserveriga, mis pani mind mitu tundi auku. Olen umbes 15 aastat tegelenud Linuxi serverite seadistamise ja tõrkeotsinguga, kuid see juhtum ei mahtunud absoluutselt minu tavapärasesse praktikas — tegin mitmeid vale eeldusi ja olin veidi meeleheitel, enne kui suutsin õigesti tuvastada probleemi põhjuse ja selle lahendada.

Eesliide

Kasutame keskmise suurusega pilve, mille ehitame tüüpiliste serverite järgmise konfiguratsiooni peale — 32 tuuma, 256 GB RAM-i ja 4TB PCI-E Intel P4500 NVMe mäluseadet. Meile meeldib see konfiguratsioon väga, kuna see võimaldab meil mitte muretseda IO puudumise pärast, tagades õiged piirangud VM-i (virtuaalmasinate) tüübi tasemel. Kuna Intel NVMe P4500 omab muljetavaldavat jõudlust, saame samaaegselt pakkuda nii täielikku IOPS-i masinatele kui ka varundada andmeid varundusseeriale nulli IOWAIT-iga.

Me kuulusime nende seas, kes ei kasuta hüperkonvergeeritud SDN-e ja muid stiilseid, moodsaid, noortepäraseid vidinaid VM-i mahutamiseks, arvestades, et mida lihtsam on süsteem, seda lihtsam on seda tõrkeotsida olukordades "peamine guru läks mägedesse". Lõppkokkuvõttes salvestame VM-i mahud QCOW2 formaadis XFS või EXT4, mis on paigaldatud LVM2 peale.

QCOW2 kasutamine on meile hädavajalik ka orkestrimise toote tõttu — Apache CloudStack.

Varundamise teostamiseks teeme täieliku mahupildi LVM2 snapshot'ina (jah, me teame, et LVM2 snapshot'id on aeglased, kuid Intel P4500 aitab meid ka siin). Teeme lvmcreate -s .. ja saadame varukoopia kaugserverisse ZFS-i salvestusse. Siin oleme siiski veidi progressiivsed — ZFS suudab andmeid salvestada kokku pressitud kujul ja saame neid kiiresti taastada läbi dd või eraldada VM-i mahud läbi DD mount -o loop ... Muidugi saab teha ka mitte täielikke LVM2 mahtude pilte, vaid mountida failisüsteemi 'RO' režiimis..

RO RO ja kopeerida QCOW2 pilte, oleme silmitsi seisnud olukordadega, kus XFS hakkab toimima halvasti, ja seda mitte kohe, vaid ettearvamatult. Me ei meeldi, kui hüperviisorid "hanguvad" ootamatult nädalavahetustel, öösel või pühal, põhjustatud vigadest, mille toimumise aeg on teadmata. Seetõttu ei kasuta me XFS-i jaoks snapshotide mountimist. RO mahselt mahutite väljavõtmiseks, vaid kopeerime kogu LVM2 mahuti.

Varundamise kiirus varundusseerial määratakse meie puhul varundusseeria serveri jõudluse järgi, mis on umbes 600-800 MB/s mittekompressitud andmete jaoks, edasine piirang on 10Gbit/s kanal, millega varundusseeria server on klastriga ühendatud.

Selle juures laadivad ühele varundusseerial serverile korraga varukoopiad 8 serverid hüperviisorit. Seega, kuna varundusseeria serveri kettasüsteem ja võrgu süsteem on aeglasemad, ei võimalda nad ülekoormata hüperviisorite kettasüsteeme, kuna nad lihtsalt ei suuda töödelda näiteks 8 GB/s, mida hüperviisorid mureta suudavad anda.

Ülalnimetatud kopeerimisprotsess on edasise narratiivi jaoks väga oluline, sealhulgas üksikasjad — kiire Intel P4500 salvesti kasutamine, NFS-i kasutamine ja tõenäoliselt ka ZFS-i kasutamine.

Varundamise lugu.

Igal hüperviisori sõlmel on meil väike 8 GB SWAP partitsioon, ja ise hüperviisor jaotatakse meile DD standardpildist. Serverite süsteemide mahuti jaoks kasutame 2xSATA SSD RAID1 või 2xSAS HDD RAID1 LSI või HP riistvarakontrolleril. Üldiselt ei huvita meid, mis seal sees on, kuna meie süsteemide mahuti töötab peaaegu "readonly" režiimis, välja arvatud SWAP. Ja kuna meie serveris on väga palju RAM-i ja see on 30-40% vaba, ei mõtle me SWAP-ile.

Varundamise loomise protsess.. See ülesanne näeb välja umbes nii:

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

Pange tähele ionice -c3, tegelikult on see NVMe-de jaoks täiesti kasutu, kuna IO ajakava on nende jaoks seadistatud järgnevalt:

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

Kuid meil on rida pärandiga sõlmi tavapäraste SSD RAID-idega, nende jaoks on see asjakohane, seega kolib see AS IS. Üldiselt on see lihtsalt huvitav koodijupp, mis selgitab ionice püüdlusi sellise konfiguratsiooni korral.

Pöörake tähelepanu lipule iflag=direct jaoks DD. Me kasutame direct IO-d vahebufferist mööda, et vältida IO vahebufferite asendamise ülekoormust lugemise ajal. Kuid oflag=direct me ei tee seda, kuna oleme kohanud ZFS-iga seotud jõudlusprobleeme selle kasutamisel.

Oleme seda skeemi edukalt kasutanud juba mitu aastat probleemideta.

Ja siis see algas… Me avastasime, et ühe sõlme varundamine ei toiminud enam ning eelmine varundamine toimus kohutava 50% IOWAIT all.

Kogumite gruppi "images" ei leitud

Hakkasime mõtlema, et "Intel P4500 aeg on ümber", kuid enne serveri välja lülitamist kõvaketta vahetamiseks oli siiski vajalik varundamine lõpule viia. Parandame LVM2 metadata taastamise abil LVM2 varundusest:

vgcfgrestore images

Käivitasime varundamise ja nägime sellist joonist:

Jälle väga kurvaks – oli selge, et niimoodi ei saa elada, kuna kõik VPS-id kannatavad, ja seega kannatame ka meie. Mis juhtus, oli täiesti ebaselge – iostat näitas vaevu elujõulisi IOPS-e ja üli kõrget IOWAIT-i. Ideed, peale "asendame NVMe", ei olnud, kuid õigel ajal tuli äkki selgus.

Probleemi analüüs samm-sammult

Ajalugu. Mõned päevad tagasi oli sellel serveril vajalik luua suur VPS 128 GB RAM-iga. Mälu näis olevat piisavalt, kuid ettevaatusabinõuna eraldati veel 32 GB vahetusmälu jaoks. VPS loodi, lahendas oma ülesande ja juhtum unustati, kuid SWAP jaotis jäi.

Konfiguratsiooni omadused. Kõikide pilveserverite parameeter vm.swappiness oli seadistatud vaikeseadmestuseks 60. Ja SWAP loodi SAS HDD RAID1-l.

Mida arvatakse juhtunust (toimetuse arvates). Varundamise käigus DD edastas palju andmeid kirjutamiseks, mis paigutati RAM-i vahebufferitesse enne NFS-i kirjutamist. Süsteemi tuum, järgides swappinesspoliitikat, tõstis palju VPS-i mälulehti vahetusala, mis asus aeglasel HDD RAID1 mahutul. See põhjustas IOWAIT-i järsu suurenemise, kuid mitte NVMe IO tõttu, vaid HDD RAID1 IO tõttu.

Kuidas probleem lahendati. 32 GB vahetusala välja lülitamine võttis 16 tundi. Kuidas ja miks see SWAP nii aeglaselt välja lülitub, saab lugeda eraldi. Parameetrid swappiness muudeti väärtuseks, mis on 5 kogu pilves.

Kuidas see võis juhtudaEsiteks, kui SWAP oleks SSD RAID või NVMe seadmes, teiseks, kui NVMe seadet ei oleks, vaid mingi aeglasem seade, mis ei toodaks nii suurt andmevoogu — iroonia on selles, et probleem tekkis just sellest, et NVMe on liiga kiire.

Pärast seda hakkas kõik uuesti tööle nagu varem — null IOWAIT'iga.

Allikas: habr.com