Mikið af ókeypis vinnsluminni, NVMe Intel P4500 og allt er afar hægt - sagan um misheppnaða viðbót við skiptingarskiptingu

Í þessari grein mun ég tala um ástand sem átti sér stað nýlega með einum af netþjónunum í VPS skýinu okkar, sem varð til þess að ég var í rugli í nokkrar klukkustundir. Ég hef verið að stilla og leysa Linux netþjóna í um það bil 15 ár, en þetta tilfelli passar alls ekki inn í vinnuna mína - ég gerði nokkrar rangar forsendur og varð örvæntingarfullur áður en ég gat rétt greint orsök vandans og leyst það .

Formáli

Við rekum meðalstórt ský sem við byggjum á stöðluðum netþjónum með eftirfarandi uppsetningu - 32 kjarna, 256 GB vinnsluminni og 4500TB PCI-E Intel P4 NVMe drif. Okkur líkar mjög við þessa uppsetningu vegna þess að hún útilokar þörfina á að hafa áhyggjur af IO kostnaði með því að veita réttar takmörkun á tegund VM tilviks. Vegna þess að NVMe Intel P4500 hefur glæsilega frammistöðu, getum við samtímis veitt bæði fulla IOPS úthlutun til véla og öryggisafritunargeymslu á öryggisafritunarþjón með núll IOWAIT.

Við erum ein af þessum gömlu trúuðu sem notum ekki ofsamleitt SDN og annað stílhreint, smart ungmenni til að geyma VM bindi, og trúum því að því einfaldara sem kerfið er, því auðveldara er að leysa það við aðstæður „aðal sérfræðingur er farinn til fjalla." Fyrir vikið geymum við VM bindi á QCOW2 sniði í XFS eða EXT4, sem er sett ofan á LVM2.

Við neyðumst líka til að nota QCOW2 af vörunni sem við notum til hljómsveitar - Apache CloudStack.

Til að taka öryggisafrit, tökum við heildarmynd af hljóðstyrknum sem LVM2 skyndimynd (já, við vitum að LVM2 skyndimyndir eru hægar, en Intel P4500 hjálpar okkur líka hér). Við gerum lvmcreate -s .. og með hjálpinni dd við sendum öryggisafritið til ytri netþjóns með ZFS geymslu. Hér erum við enn örlítið framsækin - þegar allt kemur til alls getur ZFS geymt gögn í þjöppuðu formi og við getum endurheimt þau fljótt með því að nota DD eða fáðu einstök VM bindi með því að nota mount -o loop ....

Þú getur auðvitað fjarlægt ekki alla myndina af LVM2 bindi, heldur tengt skráarkerfið í RO og afritaðu sjálfar QCOW2 myndirnar, hins vegar stóðum við frammi fyrir því að XFS varð slæmt af þessu, og ekki strax, heldur á ófyrirsjáanlegan hátt. Okkur líkar í raun ekki þegar yfirsýndargestgjafar „fasta“ skyndilega um helgar, á nóttunni eða á frídögum vegna villna sem ekki er ljóst hvenær þær munu gerast. Þess vegna notum við ekki skyndimyndafestingu fyrir XFS RO til að draga út bindi afritum við einfaldlega allt LVM2 bindið.

Hraði öryggisafritunar á afritunarþjóninn ræðst í okkar tilviki af frammistöðu afritunarþjónsins, sem er um 600-800 MB/s fyrir ósamþjöppuð gögn; önnur takmörkun er 10Gbit/s rásin sem varaþjónninn er tengdur við. til klasans.

Í þessu tilviki er öryggisafrit af 8 hypervisor netþjónum samtímis hlaðið upp á einn varaþjón. Þannig að diskur og net undirkerfi öryggisafritunarþjónsins, þar sem þau eru hægari, leyfa ekki diskundirkerfi hýsingarhýsinganna að ofhlaða, þar sem þau eru einfaldlega ekki fær um að vinna úr, til dæmis, 8 GB/sek, sem hýsilinn getur auðveldlega framleiða.

Ofangreind afritunarferli er mjög mikilvægt fyrir frekari sögu, þar á meðal smáatriðin - með því að nota hraðvirkt Intel P4500 drif, nota NFS og líklega með ZFS.

Afritunarsaga

Á hverjum hypervisor hnút erum við með litla SWAP skipting sem er 8 GB að stærð og við „rúllum“ út hypervisor hnútinn sjálfan með því að nota DD úr tilvísunarmyndinni. Fyrir kerfismagnið á netþjónum notum við 2xSATA SSD RAID1 eða 2xSAS HDD RAID1 á LSI eða HP vélbúnaðarstýringu. Almennt er okkur alveg sama hvað er inni, þar sem hljóðstyrk kerfisins okkar starfar í „næstum skrifvarið“ ham, nema SWAP. Og þar sem við erum með mikið af vinnsluminni á þjóninum og það er 30-40% ókeypis, hugsum við ekki um SWAP.

Afritunarferli. Þetta verkefni lítur einhvern veginn svona út:

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

Athugið að ionice -c3, í raun er þessi hlutur algjörlega gagnslaus fyrir NVMe tæki, þar sem IO tímaáætlun fyrir þau er stillt sem:

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

Hins vegar erum við með fjölda eldri hnúta með hefðbundnum SSD RAID, fyrir þá skiptir þetta máli, svo þeir eru að flytja EINS OG ER. Á heildina litið er þetta bara áhugavert stykki af kóða sem útskýrir tilgangsleysið ionice ef um slíka uppsetningu er að ræða.

Gefðu gaum að fánanum iflag=direct í DD. Við notum beina IO framhjá biðminni skyndiminni til að forðast óþarfa endurnýjun á IO biðminni við lestur. Hins vegar, oflag=direct við gerum það ekki vegna þess að við höfum lent í ZFS frammistöðuvandamálum við notkun þess.

Við höfum notað þetta kerfi með góðum árangri í nokkur ár án vandræða.

Og svo byrjaði þetta... Við komumst að því að einn af hnútunum var ekki lengur afritaður og sá fyrri var í gangi með ógnvekjandi IOWAIT upp á 50%. Þegar við reyndum að skilja hvers vegna afritun á sér ekki stað, lentum við í eftirfarandi fyrirbæri:

Volume group "images" not found

Við byrjuðum að hugsa um „endirinn er kominn fyrir Intel P4500,“ en áður en slökkt var á þjóninum til að skipta um drif var samt nauðsynlegt að taka öryggisafrit. Við laguðum LVM2 með því að endurheimta lýsigögn úr LVM2 öryggisafriti:

vgcfgrestore images

Við settum af stað öryggisafrit og sáum þetta olíumálverk:

Aftur vorum við mjög sorgmædd - það var ljóst að við gætum ekki lifað svona, þar sem allir VPSs myndu þjást, sem þýðir að við myndum þjást líka. Hvað gerðist er algjörlega óljóst - iostat sýndi aumkunarverða IOPS og hæsta IOWAIT. Það voru engar hugmyndir aðrar en „við skulum skipta um NVMe,“ en innsýn kom fram rétt í þessu.

Greining á ástandinu skref fyrir skref

Söguleg tímarit. Nokkrum dögum áður, á þessum netþjóni, var nauðsynlegt að búa til stóran VPS með 128 GB vinnsluminni. Það virtist vera nóg minni, en til öryggis gáfum við 32 GB í viðbót fyrir skiptinguna. VPS var búið til, kláraði verkefnið með góðum árangri og atvikið gleymdist, en SWAP skiptingin var eftir.

Stillingareiginleikar. Fyrir alla skýjaþjóna er færibreytan vm.swappiness var stillt á sjálfgefið 60. Og SWAP var búið til á SAS HDD RAID1.

Hvað gerðist (samkvæmt ritstjórum). Við öryggisafrit DD framleitt mikið af skrifgögnum, sem voru sett í vinnsluminni biðminni áður en skrifað var í NFS. Kerfiskjarni, með stefnu að leiðarljósi swappiness, var að færa margar síður af VPS minni yfir á skiptisvæðið, sem var staðsett á hægum HDD RAID1 bindi. Þetta leiddi til þess að IOWAIT óx mjög mikið, en ekki vegna IO NVMe, heldur vegna IO HDD RAID1.

Hvernig vandamálið var leyst. 32GB skipti skiptingin var óvirk. Þetta tók 16 klukkustundir; þú getur lesið sérstaklega um hvernig og hvers vegna SWAP slokknar svona hægt. Stillingum hefur verið breytt swappiness að gildi sem jafngildir 5 um allt skýið.

Hvernig gat þetta ekki gerst?. Í fyrsta lagi, ef SWAP væri á SSD RAID eða NVMe tæki, og í öðru lagi, ef það væri ekkert NVMe tæki, heldur hægara tæki sem myndi ekki framleiða slíkt magn af gögnum - kaldhæðnislegt, vandamálið gerðist vegna þess að NVMe er of hratt.

Eftir það fór allt að virka eins og áður - með núll IOWAIT.

Heimild: www.habr.com