Veľa voľnej RAM, NVMe Intel P4500 a všetko je extrémne pomalé - príbeh neúspešného pridania odkladacieho oddielu

V tomto článku budem hovoriť o situácii, ktorá sa nedávno vyskytla na jednom zo serverov v našom cloude VPS a ktorá ma na niekoľko hodín zarazila. Konfigurácii a odstraňovaniu problémov s linuxovými servermi sa zaoberám asi 15 rokov, ale tento prípad vôbec nezapadá do mojej praxe - urobil som niekoľko nesprávnych predpokladov a bol som trochu zúfalý, kým som bol schopný správne určiť príčinu problému a vyriešiť ho .

preambuly

Prevádzkujeme stredne veľký cloud, ktorý staviame na štandardných serveroch s nasledovnou konfiguráciou - 32 jadier, 256 GB RAM a 4500TB PCI-E Intel P4 NVMe disk. Táto konfigurácia sa nám naozaj páči, pretože eliminuje potrebu obávať sa réžie IO poskytnutím správneho obmedzenia na úrovni typu inštancie VM. Pretože NVMe Intel P4500 má pôsobivý výkon, dokážeme súčasne poskytnúť plné poskytovanie IOPS počítačom a zálohovanie na záložný server s nulovým IOWAIT.

Sme jedným z tých starých veriacich, ktorí nepoužívajú hyperkonvergované SDN a iné štýlové, módne veci pre mládež na ukladanie zväzkov VM, pričom sme presvedčení, že čím je systém jednoduchší, tým ľahšie je odstraňovať problémy v podmienkach „hlavný guru odišiel do hôr." Výsledkom je, že zväzky VM ukladáme vo formáte QCOW2 v XFS alebo EXT4, ktorý je nasadený nad LVM2.

K používaniu QCOW2 nás núti aj produkt, ktorý používame na orchestráciu – Apache CloudStack.

Ak chcete vykonať zálohu, urobíme úplný obraz zväzku ako snímku LVM2 (áno, vieme, že snímky LVM2 sú pomalé, ale aj tu nám pomáha Intel P4500). Robíme lvmcreate -s .. a s pomocou dd záložnú kópiu posielame na vzdialený server s úložiskom ZFS. Tu sme stále mierne progresívni – napokon, ZFS dokáže ukladať dáta v komprimovanej podobe a vieme ich pomocou rýchlo obnoviť DD alebo získajte jednotlivé zväzky VM pomocou mount -o loop ....

Môžete samozrejme odstrániť nie celý obraz zväzku LVM2, ale pripojiť súborový systém do RO a skopírovať samotné obrázky QCOW2, boli sme však konfrontovaní so skutočnosťou, že XFS sa z toho stal zlým, a to nie okamžite, ale nepredvídateľným spôsobom. Naozaj sa nám nepáči, keď sa hostitelia hypervízora náhle „prilepia“ cez víkendy, v noci alebo počas sviatkov kvôli chybám, o ktorých nie je jasné, kedy k nim dôjde. Preto pre XFS nepoužívame snapshot montáž RO na extrahovanie zväzkov jednoducho skopírujeme celý zväzok LVM2.

Rýchlosť zálohovania na záložný server je v našom prípade daná výkonom záložného servera, ktorý je cca 600-800 MB/s pre nestlačiteľné dáta, ďalším limitom je 10Gbit/s kanál, ku ktorému je záložný server pripojený. do klastra.

V tomto prípade sa záložné kópie 8 serverov hypervízora súčasne nahrajú na jeden záložný server. Diskové a sieťové podsystémy záložného servera, keďže sú pomalšie, neumožňujú preťaženie diskových podsystémov hostiteľov hypervízora, pretože jednoducho nie sú schopné spracovať povedzme 8 GB/s, čo môžu hostitelia hypervízora ľahko produkovať.

Vyššie uvedený proces kopírovania je veľmi dôležitý pre ďalší príbeh, vrátane detailov - pomocou rýchleho disku Intel P4500, pomocou NFS a pravdepodobne pomocou ZFS.

Záložný príbeh

Na každom uzle hypervízora máme malý oddiel SWAP s veľkosťou 8 GB a samotný uzol hypervízora „rozvinieme“ pomocou DD z referenčného obrázku. Pre systémový zväzok na serveroch používame 2xSATA SSD RAID1 alebo 2xSAS HDD RAID1 na hardvérovom radiči LSI alebo HP. Vo všeobecnosti nás vôbec nezaujíma, čo je vo vnútri, pretože náš systémový zväzok funguje v režime „takmer len na čítanie“, s výnimkou SWAP. A keďže máme na serveri veľa pamäte RAM a je 30-40% zadarmo, nemyslíme na SWAP.

Proces zálohovania. Táto úloha vyzerá asi takto:

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

Venujte pozornosť ionice -c3, v skutočnosti je táto vec pre zariadenia NVMe úplne zbytočná, pretože plánovač IO je pre ne nastavený ako:

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

Máme však niekoľko starších uzlov s konvenčnými SSD RAID, pre ktoré je to relevantné, takže sa presúvajú AKO JE. Celkovo je to len zaujímavý kúsok kódu, ktorý vysvetľuje zbytočnosť ionice v prípade takejto konfigurácie.

Venujte pozornosť vlajke iflag=direct pre DD. Používame priame IO obchádzanie vyrovnávacej pamäte, aby sme sa vyhli zbytočnému nahrádzaniu IO vyrovnávacích pamätí pri čítaní. však oflag=direct nemáme, pretože sme sa pri používaní ZFS stretli s problémami s výkonom.

Túto schému úspešne používame už niekoľko rokov bez problémov.

A potom to začalo... Zistili sme, že jeden z uzlov už nie je zálohovaný a ten predchádzajúci bežal s obludným IOWAIT 50%. Keď sme sa snažili pochopiť, prečo nedochádza ku kopírovaniu, stretli sme sa s nasledujúcim javom:

Volume group "images" not found

Začali sme uvažovať o tom, že „pre Intel P4500 nastal koniec“, avšak pred vypnutím servera kvôli výmene disku bolo ešte potrebné vykonať zálohu. Opravili sme LVM2 obnovením metadát zo zálohy LVM2:

vgcfgrestore images

Spustili sme zálohu a videli sme túto olejomaľbu:

Opäť sme boli veľmi smutní - bolo jasné, že takto nemôžeme žiť, pretože by trpeli všetky VPS, čo znamená, že by sme trpeli aj my. Čo sa stalo, je úplne nejasné - iostat ukázal žalostný IOPS a najvyšší IOWAIT. Neexistovali žiadne iné nápady ako „poďme nahradiť NVMe“, ale práve včas došlo k poznaniu.

Analýza situácie krok za krokom

Historický časopis. Pár dní predtým bolo na tomto serveri potrebné vytvoriť veľké VPS so 128 GB RAM. Zdalo sa, že je dostatok pamäte, ale pre istotu sme pridelili ďalších 32 GB pre odkladací oddiel. VPS bol vytvorený, úspešne dokončil svoju úlohu a incident bol zabudnutý, ale oddiel SWAP zostal.

Funkcie konfigurácie. Pre všetky cloudové servery parameter vm.swappiness bola nastavená ako predvolená 60. A SWAP bol vytvorený na SAS HDD RAID1.

Čo sa stalo (podľa redakcie). Pri zálohovaní DD produkoval veľa zapisovacích údajov, ktoré boli umiestnené do vyrovnávacej pamäte RAM pred zápisom na NFS. Jadro systému, riadené politikou swappiness, presúval veľa stránok pamäte VPS do swapovacej oblasti, ktorá sa nachádzala na pomalom zväzku HDD RAID1. To viedlo k veľmi silnému rastu IOWAIT, ale nie vďaka IO NVMe, ale vďaka IO HDD RAID1.

Ako bol problém vyriešený. 32GB odkladací oddiel bol zakázaný. Trvalo to 16 hodín; o tom, ako a prečo sa SWAP vypína tak pomaly, si môžete prečítať samostatne. Nastavenia boli zmenené swappiness na hodnotu rovnajúcu sa 5 po celom oblaku.

Ako sa to nemohlo stať?. Po prvé, ak by bol SWAP na zariadení SSD RAID alebo NVMe, a po druhé, ak by tam nebolo zariadenie NVMe, ale pomalšie zariadenie, ktoré by neprodukovalo taký objem dát – ironicky problém nastal, pretože to NVMe je príliš rýchle.

Potom všetko začalo fungovať ako predtým - s nulovým IOWAIT.

Zdroj: hab.com