Palju vaba RAM-i, NVMe Intel P4500 ja kõik on äärmiselt aeglane - vahetuspartitsiooni ebaõnnestunud lisamise lugu

Selles artiklis räägin olukorrast, mis hiljuti juhtus ühe meie VPS-i pilves oleva serveriga, mis jättis mind mitmeks tunniks jänni. Olen Linuxi servereid konfigureerinud ja tõrkeotsingut teinud umbes 15 aastat, kuid see juhtum ei sobi üldse minu praktikasse - tegin mitmeid valeeeldusi ja sattusin pisut meeleheitesse, enne kui suutsin probleemi põhjuse õigesti kindlaks teha ja selle lahendada .

Preambul

Tegutseme keskmise suurusega pilvega, mille ehitame standardserveritele järgmise konfiguratsiooniga - 32 tuuma, 256 GB RAM ja 4500TB PCI-E Intel P4 NVMe draiv. Meile väga meeldib see konfiguratsioon, kuna see välistab vajaduse muretseda IO üldkulude pärast, pakkudes VM-i eksemplari tüübi tasemel õigeid piiranguid. Kuna NVMe Intel P4500 millel on muljetavaldav jõudlus, suudame samaaegselt pakkuda nii täielikku IOPS-i varustamist masinatele kui ka varuserverisse varusalvestust ilma IOWAIT-i nulliga.

Oleme üks neist vanausulistest, kes ei kasuta VM-i köidete salvestamiseks hüperkonvergeeritud SDN-i ja muid stiilseid, moodsaid, noorte asju, uskudes, et mida lihtsam on süsteem, seda lihtsam on selle tõrkeotsing olukorras, kus “peaguru on läinud. mägedesse." Selle tulemusena salvestame VM-i köiteid QCOW2-vormingus XFS- või EXT4-vormingus, mis on juurutatud LVM2-le.

QCOW2 sunnib meid kasutama ka orkestreerimiseks kasutatav toode - Apache CloudStack.

Varunduse tegemiseks teeme helitugevusest täispildi LVM2 hetktõmmisena (jah, me teame, et LVM2 hetktõmmised on aeglased, kuid Intel P4500 aitab meid ka siin). Me teeme lvmcreate -s .. ja abiga dd saadame varukoopia ZFS-i salvestusruumiga kaugserverisse. Siin oleme endiselt pisut progressiivsed - lõppude lõpuks saab ZFS salvestada andmeid tihendatud kujul ja me saame need kiiresti taastada, kasutades DD või hankige kasutades üksikuid VM-i köiteid mount -o loop ....

Loomulikult saate eemaldada mitte LVM2 köite täielikku pilti, vaid ühendada failisüsteemi RO ja kopeerida QCOW2 pilte ise, aga seisime silmitsi tõsiasjaga, et XFS muutus sellest halvaks ja mitte kohe, vaid ettearvamatult. Meile väga ei meeldi, kui hüperviisori hostid nädalavahetustel, öösiti või pühade ajal äkitselt „kleepuvad” vigade tõttu, mis pole selged, millal need juhtuvad. Seetõttu ei kasuta me XFS-i puhul hetktõmmise paigaldamist RO köidete eraldamiseks kopeerime lihtsalt kogu LVM2 köite.

Varundusserverisse varundamise kiiruse määrab meie puhul varuserveri jõudlus, mis on tihendamatute andmete puhul ca 600-800 MB/s, täiendavaks piirajaks on 10Gbit/s kanal, millega varuserver on ühendatud. klastrisse.

Sel juhul laaditakse ühte varuserverisse korraga üles 8 hüperviisori serveri varukoopiad. Seega ei lase varuserveri ketta- ja võrgu alamsüsteemid, olles aeglasemad, hüperviisori hostide ketta alamsüsteeme üle koormata, kuna nad lihtsalt ei suuda töödelda näiteks 8 GB/sek, mida hüperviisori hostid saavad hõlpsasti töödelda. toota.

Ülaltoodud kopeerimisprotsess on edasise loo jaoks väga oluline, sealhulgas detailid - kasutades kiiret Intel P4500 draivi, kasutades NFS-i ja tõenäoliselt ka ZFS-i.

Varulugu

Igas hüperviisori sõlmes on meil väike 8 GB suurune SWAP-partitsioon ja me "rullime välja" hüperviisori sõlme enda DD võrdluspildilt. Serverite süsteemimahu jaoks kasutame LSI või HP riistvarakontrolleril 2xSATA SSD RAID1 või 2xSAS HDD RAID1. Üldiselt ei huvita meid üldse, mis sees on, kuna meie süsteemi maht töötab peaaegu kirjutuskaitstud režiimis, välja arvatud SWAP. Ja kuna meil on serveris palju RAM-i ja see on 30-40% tasuta, ei mõtle me SWAP-ile.

Varundusprotsess. See ülesanne näeb välja umbes selline:

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

Märkus ionice -c3Tegelikult on see asi NVMe-seadmete jaoks täiesti kasutu, kuna nende IO-plaanija on seatud järgmiselt:

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

Meil on aga mitmeid tavapäraste SSD RAID-idega pärandsõlmi, nende jaoks on see asjakohane, nii et nad liiguvad NAGU ON. Üldiselt on see lihtsalt huvitav kooditükk, mis selgitab mõttetust ionice sellise konfiguratsiooni korral.

Pöörake tähelepanu lipule iflag=direct eest DD. Kasutame otsest IO-d, jättes mööda puhvri vahemälust, et vältida lugemisel IO puhvrite asjatut asendamist. Kuid, oflag=direct me ei tee seda, sest oleme selle kasutamisel kokku puutunud ZFS-i jõudlusprobleemidega.

Oleme seda skeemi edukalt kasutanud mitu aastat ilma probleemideta.

Ja siis see algas... Avastasime, et ühte sõlmedest enam ei varundatud ja eelmine töötas koletu 50% IOWAIT-iga. Püüdes mõista, miks kopeerimist ei toimu, kohtasime järgmist nähtust:

Volume group "images" not found

Hakkasime mõtlema, et "Intel P4500 jaoks on lõpp käes", kuid enne serveri väljalülitamist draivi vahetamiseks oli siiski vaja teha varukoopia. Parandasime LVM2, taastades metaandmed LVM2 varukoopiast:

vgcfgrestore images

Käivitasime varukoopia ja nägime seda õlimaali:

Jällegi olime väga kurvad – oli selge, et me ei saa niimoodi elada, sest kõik VPS-id kannatavad, mis tähendab, et kannatame ka meie. Mis juhtus, on täiesti ebaselge - iostat näitas haletsusväärset IOPS-i ja kõrgeimat IOWAIT-i. Polnud muid ideid peale "asendame NVMe", kuid arusaam tekkis õigel ajal.

Olukorra analüüs samm-sammult

Ajalooline ajakiri. Mõni päev varem oli selles serveris vaja luua suur VPS 128 GB muutmäluga. Mälu näis olevat piisavalt, kuid kindluse mõttes eraldasime vahetuspartitsiooni jaoks veel 32 GB. VPS loodi, täitis oma ülesande edukalt ja juhtum unustati, kuid SWAP-i partitsioon jäi alles.

Konfiguratsioonifunktsioonid. Kõigi pilveserverite jaoks parameeter vm.swappiness määrati vaikimisi 60. Ja SWAP loodi SAS HDD RAID1-le.

Mis juhtus (toimetuse sõnul). Varundamisel DD tootis palju kirjutamisandmeid, mis paigutati enne NFS-i kirjutamist RAM-i puhvritesse. Süsteemi tuum, juhindub poliitikast swappiness, teisaldas palju VPS-mälu lehti vahetusalasse, mis asus aeglasel HDD RAID1 köitel. See tõi kaasa IOWAITi väga tugeva kasvu, kuid mitte tänu IO NVMe-le, vaid tänu IO HDD RAID1-le.

Kuidas probleem lahenes. 32 GB vahetussektsioon keelati. Selleks kulus 16 tundi; saate eraldi lugeda, kuidas ja miks SWAP nii aeglaselt välja lülitub. Seadistused on muudetud swappiness väärtusele, mis on võrdne 5 üle kogu pilve.

Kuidas see ei juhtunud?. Esiteks, kui SWAP oleks SSD RAID või NVMe seadmel ja teiseks, kui poleks NVMe seadet, vaid aeglasem seade, mis sellist andmemahtu ei toodaks – raudselt tekkis probleem seetõttu, et too NVMe on liiga kiire.

Pärast seda hakkas kõik toimima nagu varem - nulliga IOWAIT.

Allikas: www.habr.com