Spousta volné RAM, NVMe Intel P4500 a všechno je extrémně pomalé - příběh neúspěšného přidání odkládacího oddílu

V tomto článku budu hovořit o situaci, která nedávno nastala s jedním ze serverů v našem cloudu VPS a která mě na několik hodin zarazila. Konfiguraci a řešení problémů na linuxových serverech se věnuji asi 15 let, ale tento případ vůbec nezapadá do mé praxe - udělal jsem několik nesprávných předpokladů a byl jsem trochu zoufalý, než jsem byl schopen správně určit příčinu problému a vyřešit jej .

Preambule

Provozujeme středně velký cloud, který stavíme na standardních serverech s následující konfigurací - 32 jader, 256 GB RAM a 4500TB PCI-E disk Intel P4 NVMe. Tato konfigurace se nám opravdu líbí, protože eliminuje potřebu starat se o režii IO tím, že poskytuje správné omezení na úrovni typu instance virtuálního počítače. Protože NVMe Intel P4500 má působivý výkon, můžeme současně poskytovat jak plné poskytování IOPS strojům, tak úložiště záloh na záložní server s nulovým IOWAIT.

Jsme jedním z těch starých věřících, kteří nepoužívají hyperkonvergované SDN a další stylové, módní věci pro mládež k ukládání svazků VM, věříce, že čím jednodušší je systém, tím snazší je odstraňovat problémy v podmínkách „hlavní guru odešel do hor." Výsledkem je, že ukládáme svazky VM ve formátu QCOW2 v XFS nebo EXT4, který je nasazen nad LVM2.

K používání QCOW2 nás nutí také produkt, který používáme pro orchestraci – Apache CloudStack.

Abychom provedli zálohu, pořídíme úplný obraz svazku jako snímek LVM2 (ano, víme, že snímky LVM2 jsou pomalé, ale i zde nám pomáhá Intel P4500). My ano lvmcreate -s .. a s pomocí dd odešleme záložní kopii na vzdálený server s úložištěm ZFS. Zde jsme stále mírně progresivní – přeci jen ZFS umí ukládat data v komprimované podobě a my je můžeme rychle obnovit pomocí DD nebo získat jednotlivé svazky virtuálních počítačů pomocí mount -o loop ....

Můžete samozřejmě odebrat ne celý obraz svazku LVM2, ale připojit souborový systém do RO a zkopírovat samotné obrázky QCOW2, byli jsme však konfrontováni se skutečností, že XFS se z toho stal špatným, a ne okamžitě, ale nepředvídatelným způsobem. Opravdu se nám nelíbí, když se hostitelé hypervizorů náhle „přilepí“ o víkendech, v noci nebo o svátcích kvůli chybám, u kterých není jasné, kdy k nim dojde. Proto pro XFS nepoužíváme snapshot montáž RO pro extrahování svazků jednoduše zkopírujeme celý svazek LVM2.

Rychlost zálohování na záložní server je v našem případě dána výkonem zálohovacího serveru, který je cca 600-800 MB/s pro nestlačitelná data, dalším limitem je 10Gbit/s kanál, ke kterému je záložní server připojen. do shluku.

V tomto případě jsou na jeden záložní server současně nahrány záložní kopie 8 hypervisorových serverů. Diskové a síťové subsystémy záložního serveru jsou pomalejší a neumožňují přetížení diskových subsystémů hostitelů hypervisoru, protože prostě nejsou schopny zpracovat řekněme 8 GB/s, což hostitelé hypervizoru mohou snadno vyrobit.

Výše uvedený proces kopírování je velmi důležitý pro další příběh, včetně detailů – pomocí rychlého disku Intel P4500, pomocí NFS a pravděpodobně i pomocí ZFS.

Záložní příběh

Na každém uzlu hypervisoru máme malý oddíl SWAP o velikosti 8 GB a samotný uzel hypervisoru „rozbalíme“ pomocí DD z referenčního obrázku. Pro systémový svazek na serverech používáme 2xSATA SSD RAID1 nebo 2xSAS HDD RAID1 na hardwarovém řadiči LSI nebo HP. Obecně nás vůbec nezajímá, co je uvnitř, protože náš systémový svazek funguje v režimu „téměř jen pro čtení“, s výjimkou SWAP. A protože máme na serveru hodně paměti RAM a je 30–40 % zdarma, o SWAPu nepřemýšlíme.

Proces zálohování. Tento úkol vypadá 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

Poznámka: ionice -c3, ve skutečnosti je tato věc pro zařízení NVMe zcela zbytečná, protože plánovač IO je pro ně nastaven jako:

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

Máme však řadu starších uzlů s konvenčními SSD RAID, pro ně je to relevantní, takže se přesouvají JAK JE. Celkově je to jen zajímavý kus kódu, který vysvětluje marnost ionice v případě takové konfigurace.

Věnujte pozornost vlajce iflag=direct pro DD. Používáme přímé IO obcházení mezipaměti, abychom se vyhnuli zbytečné výměně IO bufferů při čtení. Nicméně, oflag=direct nemáme, protože jsme při jeho používání narazili na problémy s výkonem ZFS.

Toto schéma úspěšně používáme již několik let bez problémů.

A pak to začalo... Zjistili jsme, že jeden z uzlů již není zálohován a ten předchozí běží s monstrózním IOWAIT 50%. Když jsme se snažili pochopit, proč ke kopírování nedochází, narazili jsme na následující jev:

Volume group "images" not found

Začali jsme přemýšlet o tom, že „konec přišel pro Intel P4500“, nicméně před vypnutím serveru kvůli výměně disku bylo ještě nutné provést zálohu. Opravili jsme LVM2 obnovením metadat ze zálohy LVM2:

vgcfgrestore images

Spustili jsme zálohu a viděli tuto olejomalbu:

Opět jsme byli velmi smutní - bylo jasné, že takhle nemůžeme žít, protože by tím trpěli všichni VPS, což znamená, že bychom trpěli i my. Co se stalo, je zcela nejasné - iostat ukázal žalostné IOPS a nejvyšší IOWAIT. Neexistovaly žádné jiné nápady než „pojďme nahradit NVMe“, ale právě včas došlo k pochopení.

Analýza situace krok za krokem

Historický časopis. O pár dní dříve bylo na tomto serveru nutné vytvořit velké VPS se 128 GB RAM. Zdálo se, že je dostatek paměti, ale pro jistotu jsme přidělili dalších 32 GB pro swapovací oddíl. VPS byl vytvořen, úspěšně dokončil svůj úkol a incident byl zapomenut, ale oddíl SWAP zůstal.

Funkce konfigurace. Pro všechny cloudové servery parametr vm.swappiness byla nastavena jako výchozí 60. A SWAP byl vytvořen na SAS HDD RAID1.

Co se stalo (podle redakce). Při zálohování DD produkovalo mnoho dat pro zápis, která byla před zápisem na NFS umístěna do vyrovnávací paměti RAM. Jádro systému, řízené politikou swappiness, přesouval mnoho stránek paměti VPS do swapovací oblasti, která byla umístěna na pomalém svazku HDD RAID1. To vedlo k velmi silnému růstu IOWAIT, ale ne díky IO NVMe, ale díky IO HDD RAID1.

Jak byl problém vyřešen. 32GB odkládací oddíl byl zakázán. Trvalo to 16 hodin; o tom, jak a proč se SWAP tak pomalu vypíná, si můžete přečíst samostatně. Nastavení byla změněna swappiness na hodnotu rovnou 5 po celém cloudu.

Jak se to mohlo stát?. Za prvé, pokud by byl SWAP na zařízení SSD RAID nebo NVMe, a za druhé, pokud by tam nebylo zařízení NVMe, ale pomalejší zařízení, které by neprodukovalo takový objem dat - ironicky problém nastal, protože to NVMe je příliš rychlé.

Poté začalo vše fungovat jako předtím - s nulovým IOWAIT.

Zdroj: www.habr.com