In protte frije RAM, NVMe Intel P4500 en alles is ekstreem stadich - it ferhaal fan 'e mislearre tafoeging fan in ruilferdieling

Yn dit artikel sil ik prate oer in situaasje dy't koartlyn barde mei ien fan 'e servers yn ús VPS-wolk, dy't my ferskate oeren stompe liet. Ik haw Linux-tsjinners sawat 15 jier konfigureare en problemen oplost, mar dit gefal past hielendal net yn myn praktyk - ik makke ferskate falske oannames en waard in bytsje wanhopich foardat ik de oarsaak fan it probleem goed koe bepale en it oplosse .

Foaropgong

Wy operearje in middelgrutte wolk, dy't wy bouwe op standert tsjinners mei de folgjende konfiguraasje - 32 kearnen, 256 GB RAM en in 4500TB PCI-E Intel P4 NVMe drive. Wy hâlde dizze konfiguraasje echt leuk, om't it de needsaak elimineert om soargen te meitsjen oer IO-overhead troch de juste beheining te leverjen op it nivo fan VM-eksimplaartype. Omdat NVMe Intel P4500 hat yndrukwekkende prestaasje, kinne wy ​​tagelyk foarsjen sawol folsleine IOPS foarsjenning oan masines en reservekopy opslach oan in reservekopy tsjinner mei nul IOWAIT.

Wy binne ien fan dy âlde leauwigen dy't gjin hyperconverged SDN en oare stylfolle, modieuze, jeugd dingen brûke om VM-voluminten op te slaan, en leauwe dat hoe ienfâldiger it systeem is, hoe makliker it is om it probleem op te lossen yn 'e betingsten fan "de wichtichste guru is fuort nei de bergen." As resultaat bewarje wy VM-voluminten yn QCOW2-formaat yn XFS of EXT4, dy't boppe op LVM2 wurdt ynset.

Wy binne ek twongen om QCOW2 te brûken troch it produkt dat wy brûke foar orkestraasje - Apache CloudStack.

Om in reservekopy út te fieren, nimme wy in folsleine ôfbylding fan it folume as in LVM2-snapshot (ja, wy witte dat LVM2-snapshots stadich binne, mar de Intel P4500 helpt ús hjir ek). Wy dogge lvmcreate -s .. en mei help dd wy stjoere de reservekopy nei in tsjinner op ôfstân mei ZFS opslach. Hjir binne wy ​​noch in bytsje foarútstribjend - ommers, ZFS kin gegevens opslaan yn komprimearre foarm, en wy kinne it fluch weromsette mei DD of krije yndividuele VM folumes mei help mount -o loop ....

Jo kinne, fansels, fuortsmite net de folsleine ôfbylding fan de LVM2 folume, mar mount it triemsysteem yn de RO en kopiearje de QCOW2 bylden sels, lykwols, wy waarden konfrontearre mei it feit dat XFS waard min út dit, en net fuortendaliks, mar yn in ûnfoarspelbere wize. Wy hawwe it echt net leuk as hypervisor-hosts yn it wykein, nachts of op feestdagen ynienen "plakke" troch flaters dy't net dúdlik binne wannear't se sille barre. Dêrom brûke wy foar XFS gjin snapshot-montage yn RO om folumes te ekstrahearjen, kopiearje wy gewoan it heule LVM2-volume.

De snelheid fan reservekopy nei de reservekopytsjinner wurdt yn ús gefal bepaald troch de prestaasjes fan 'e reservekopytsjinner, dy't sawat 600-800 MB / s is foar ynkompresjebere gegevens; in fierdere limiter is it 10Gbit / s-kanaal wêrmei't de reservekopytsjinner is ferbûn. nei it kluster.

Yn dit gefal wurde reservekopyen fan 8 hypervisor-tsjinners tagelyk opladen nei ien reservekopytsjinner. Sa litte de skiif- en netwurksubsystemen fan 'e reservekopytsjinner, dy't stadiger binne, de skiifsubsystemen fan' e hypervisor-hosts net oerladen, om't se gewoan net kinne ferwurkje, bygelyks, 8 GB / sek, wat de hypervisor-hosts maklik kinne produsearje.

It boppesteande kopiearjen is heul wichtich foar it fierdere ferhaal, ynklusyf de details - mei in rappe Intel P4500-drive, mei NFS en, wierskynlik, mei ZFS.

Reservekopy ferhaal

Op elke hypervisorknooppunt hawwe wy in lytse SWAP-partysje fan 8 GB yn grutte, en wy "rôlje" de hypervisorknoop sels út mei DD út de referinsje ôfbylding. Foar it systeem folume op tsjinners, wy brûke 2xSATA SSD RAID1 of 2xSAS HDD RAID1 op in LSI of HP hardware controller. Yn 't algemien skele wy ús hielendal net oer wat der binnen is, om't ús systeemvolumint wurket yn' hast allinich lêzen 'modus, útsein SWAP. En om't wy in protte RAM hawwe op 'e tsjinner en it is 30-40% fergees, tinke wy net oer SWAP.

Reservekopy proses. Dizze taak sjocht der sa ú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

Soarch omtinken ionice -c3Yn feite is dit ding folslein nutteloos foar NVMe-apparaten, om't de IO-planner foar har is ynsteld as:

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

Wy hawwe lykwols in oantal legacy-knooppunten mei konvinsjonele SSD RAID's, foar har is dit relevant, sadat se bewege SA'T IS. Oer it algemien is dit gewoan in nijsgjirrich stikje koade dy't de futiliteit ferklearret ionice yn gefal fan sa'n konfiguraasje.

Jou omtinken oan de flagge iflag=direct foar DD. Wy brûke direkte IO om de buffer-cache te omgean om ûnnedige ferfanging fan IO-buffers by it lêzen te foarkommen. Lykwols, oflag=direct wy dogge net om't wy ZFS-prestaasjesproblemen hawwe tsjinkaam by it brûken fan it.

Wy hawwe dit skema mei súkses brûkt foar ferskate jierren sûnder problemen.

En doe begûn it... Wy ûntdutsen dat ien fan 'e knopen net mear reservekopy waard, en de foarige rûn mei in meunsterlike IOWAIT fan 50%. By it besykjen om te begripen wêrom't kopiearjen net foarkomt, tsjinkamen wy it folgjende ferskynsel:

Volume group "images" not found

Wy begon te tinken oer "it ein is kommen foar de Intel P4500," lykwols, foardat jo de tsjinner útsette om it stasjon te ferfangen, wie it noch altyd nedich om in reservekopy út te fieren. Wy hawwe LVM2 reparearre troch metadata te herstellen fan in LVM2-backup:

vgcfgrestore images

Wy lansearre in reservekopy en seagen dit oaljeferve:

Nochris wiene wy ​​heul fertrietlik - it wie dúdlik dat wy sa net libje koene, om't alle VPS's lije soene, wat betsjut dat wy ek lije soene. Wat der bard is is folslein ûndúdlik - iostat toande jammerdearlik IOPS en de heechste IOWAIT. D'r wiene gjin oare ideeën as "litte wy NVMe ferfange", mar in ynsjoch kaam krekt op 'e tiid.

Analyse fan 'e situaasje stap foar stap

Histoarysk tydskrift. In pear dagen earder, op dizze server wie it nedich om in grutte VPS te meitsjen mei 128 GB RAM. D'r like genôch ûnthâld te wêzen, mar om oan 'e feilige kant te wêzen, hawwe wy in oare 32 GB tawiisd foar de ruilferdieling. De VPS waard makke, foltôge syn taak mei súkses en it ynsidint waard fergetten, mar de SWAP-dieling bleau.

Konfiguraasje Features. Foar alle wolk tsjinners de parameter vm.swappiness waard ynsteld op standert 60. En SWAP waard makke op SAS HDD RAID1.

Wat barde (neffens de redaksje). By it meitsjen fan reservekopy DD produsearre in protte skriuwgegevens, dy't yn RAM-buffers pleatst waarden foar it skriuwen nei NFS. Systeem kearn, begelaat troch belied swappiness, waard in protte siden fan VPS-ûnthâld ferpleatst nei it ruilgebiet, dat lei op in trage HDD RAID1-folume. Dit late ta dat IOWAIT tige sterk groeide, mar net troch IO NVMe, mar troch IO HDD RAID1.

Hoe't it probleem waard oplost. De 32GB ruilferdieling wie útskeakele. Dit duorre 16 oeren; jo kinne apart lêze oer hoe en wêrom SWAP sa stadich útskeakelt. Ynstellings binne feroare swappiness oan in wearde gelyk oan 5 oer de hiele wolk.

Hoe koe dit net barre?. As earste, as SWAP op in SSD RAID of NVMe-apparaat wie, en twad, as d'r gjin NVMe-apparaat wie, mar in stadiger apparaat dat net sa'n folume fan gegevens soe produsearje - iroanysk, it probleem barde om't dat NVMe te fluch is.

Dêrnei begon alles te wurkjen lykas earder - mei nul IOWAIT.

Boarne: www.habr.com