Veliko prostega RAM-a, NVMe Intel P4500 in vse je izjemno počasno - zgodba o neuspešnem dodajanju izmenjalne particije

V tem članku bom govoril o situaciji, ki se je nedavno zgodila z enim od strežnikov v našem oblaku VPS, zaradi katere sem bil kar nekaj ur obupan. Strežnike Linux konfiguriram in odpravljam težave že približno 15 let, vendar ta primer nikakor ne sodi v mojo prakso – naredil sem več napačnih predpostavk in postal malo obupan, preden mi je uspelo pravilno ugotoviti vzrok težave in jo rešiti .

Preambula

Upravljamo srednje velik oblak, ki ga gradimo na standardnih strežnikih z naslednjo konfiguracijo - 32 jeder, 256 GB RAM-a in 4500TB PCI-E disk Intel P4 NVMe. Ta konfiguracija nam je zelo všeč, ker odpravlja potrebo po skrbi za IO-stroške, saj zagotavlja pravilno omejitev na ravni tipa primerka VM. Ker NVMe Intel P4500 ima impresivno zmogljivost, lahko istočasno zagotovimo popolno oskrbo IOPS za stroje in rezervno shranjevanje v rezervnem strežniku z nič IOWAIT.

Smo eni tistih starovercev, ki ne uporabljajo hiperkonvergiranih SDN in drugih elegantnih, modnih, mladinskih stvari za shranjevanje količin VM, saj verjamejo, da enostavnejši kot je sistem, lažje ga je odpraviti v pogojih "glavni guru je odšel v gore." Posledično shranjujemo nosilce VM v formatu QCOW2 v XFS ali EXT4, ki je nameščen na vrhu LVM2.

V uporabo QCOW2 nas sili tudi izdelek, ki ga uporabljamo za orkestracijo - Apache CloudStack.

Za izvedbo varnostnega kopiranja posnamemo celotno sliko nosilca kot posnetek LVM2 (da, vemo, da so posnetki LVM2 počasni, vendar nam Intel P4500 pomaga tudi pri tem). Mi delamo lvmcreate -s .. in s pomočjo dd varnostno kopijo pošljemo na oddaljeni strežnik s shranjevanjem ZFS. Tukaj smo še vedno rahlo napredovali - navsezadnje lahko ZFS shranjuje podatke v stisnjeni obliki, mi pa jih lahko hitro obnovimo z DD ali pridobite posamezne količine VM z uporabo mount -o loop ....

Seveda lahko ne odstranite celotne slike nosilca LVM2, ampak namestite datotečni sistem v RO in kopirali same slike QCOW2, vendar smo bili soočeni z dejstvom, da je XFS zaradi tega postal slab, in to ne takoj, ampak na nepredvidljiv način. Resnično nam ni všeč, ko se hipervizorski gostitelji ob vikendih, ponoči ali praznikih nenadoma »prilepijo« zaradi napak, za katere ni jasno, kdaj se bodo zgodile. Zato za XFS ne uporabljamo namestitve posnetka RO za ekstrahiranje nosilcev preprosto kopiramo celoten nosilec LVM2.

Hitrost varnostnega kopiranja na rezervni strežnik je v našem primeru določena z zmogljivostjo rezervnega strežnika, ki znaša okoli 600-800 MB/s za nestisljive podatke, nadaljnji omejevalnik je 10Gbit/s kanal, s katerim je povezan rezervni strežnik. v grozd.

V tem primeru se varnostne kopije 8 hipervizorskih strežnikov hkrati naložijo na en rezervni strežnik. Tako diskovni in omrežni podsistem rezervnega strežnika, ki sta počasnejša, ne dopuščata preobremenitve diskovnih podsistemov gostiteljev hipervizorja, saj enostavno ne zmoreta obdelati recimo 8 GB/s, kar gostitelji hipervizorja brez težav zmorejo. proizvajajo.

Zgornji postopek kopiranja je zelo pomemben za nadaljnjo zgodbo, vključno s podrobnostmi - z uporabo hitrega pogona Intel P4500, z uporabo NFS in verjetno z uporabo ZFS.

Rezervna zgodba

Na vsakem vozlišču hipervizorja imamo majhno SWAP particijo velikosti 8 GB, samo vozlišče hipervizorja pa "razvijemo" z uporabo DD iz referenčne slike. Za sistemski nosilec na strežnikih uporabljamo 2xSATA SSD RAID1 ali 2xSAS HDD RAID1 na krmilniku strojne opreme LSI ali HP. Na splošno nas sploh ne zanima, kaj je notri, saj naš sistemski nosilec deluje v načinu »skoraj samo za branje«, razen za SWAP. In ker imamo na strežniku veliko RAM-a in je 30-40% brezplačnega, o SWAP-u ne razmišljamo.

Postopek varnostnega kopiranja. Ta naloga je videti nekako takole:

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

Bodite pozorni ionice -c3, pravzaprav je ta stvar popolnoma neuporabna za naprave NVMe, saj je IO planer zanje nastavljen kot:

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

Vendar pa imamo številna podedovana vozlišča z običajnimi SSD RAID, zanje je to pomembno, zato se selijo KOT JE. Na splošno je to samo zanimiv del kode, ki pojasnjuje nesmiselnost ionice v primeru takšne konfiguracije.

Bodite pozorni na zastavo iflag=direct za DD. Uporabljamo neposredni IO mimo predpomnilnika medpomnilnika, da se izognemo nepotrebni zamenjavi medpomnilnikov IO pri branju. vendar oflag=direct ne, ker smo pri uporabi naleteli na težave z zmogljivostjo ZFS.

To shemo uspešno uporabljamo že več let brez težav.

In potem se je začelo... Ugotovili smo, da eno od vozlišč ni bilo več varnostno kopirano, prejšnje pa je delovalo s pošastnim IOWAIT 50 %. Ko smo poskušali razumeti, zakaj do kopiranja ne pride, smo naleteli na naslednji pojav:

Volume group "images" not found

Začeli smo razmišljati o "prišel je konec za Intel P4500", vendar je bilo pred izklopom strežnika za zamenjavo diska še vedno potrebno narediti varnostno kopijo. LVM2 smo popravili z obnovitvijo metapodatkov iz varnostne kopije LVM2:

vgcfgrestore images

Zagnali smo varnostno kopijo in videli to oljno sliko:

Spet smo bili zelo žalostni - jasno je bilo, da tako ne moremo živeti, saj bi trpeli vsi VPS-ji, kar pomeni, da bi trpeli tudi mi. Kaj se je zgodilo, je popolnoma nejasno - iostat pokazal bedne IOPS in najvišji IOWAIT. Ni bilo drugih idej kot »zamenjajmo NVMe«, a vpogled se je zgodil ravno pravi čas.

Analiza situacije korak za korakom

Zgodovinska revija. Nekaj ​​dni prej je bilo na tem strežniku potrebno ustvariti velik VPS s 128 GB RAM-a. Zdelo se je, da je pomnilnika dovolj, vendar smo zaradi varnosti dodelili še 32 GB za izmenjalno particijo. VPS je bil ustvarjen, uspešno opravil svojo nalogo in incident je bil pozabljen, SWAP particija pa je ostala.

Značilnosti konfiguracije. Za vse strežnike v oblaku parameter vm.swappiness je bil nastavljen na privzeto 60. In SWAP je bil ustvarjen na SAS HDD RAID1.

Kaj se je zgodilo (po mnenju urednikov). Pri varnostnem kopiranju DD proizvedel veliko pisalnih podatkov, ki so bili postavljeni v medpomnilnike RAM pred zapisovanjem v NFS. Jedro sistema, ki ga vodi politika swappiness, je premaknil veliko strani pomnilnika VPS v območje izmenjave, ki je bilo na nosilcu počasnega trdega diska RAID1. To je povzročilo zelo močno rast IOWAIT, vendar ne zaradi IO NVMe, ampak zaradi IO HDD RAID1.

Kako je bil problem rešen. Izmenjalna particija 32 GB je bila onemogočena. To je trajalo 16 ur; o tem, kako in zakaj se SWAP izklopi tako počasi, lahko preberete posebej. Nastavitve so bile spremenjene swappiness na vrednost, ki je enaka 5 po celem oblaku.

Kako se to ne bi zgodilo?. Prvič, če bi bil SWAP na SSD RAID ali NVMe napravi, in drugič, če ni NVMe naprave, ampak počasnejša naprava, ki ne bi proizvedla tolikšne količine podatkov - ironično, do težave je prišlo, ker je ta NVMe prehiter.

Po tem je vse začelo delovati kot prej - z nič IOWAIT.

Vir: www.habr.com