Sok ingyenes RAM, NVMe Intel P4500 és minden rendkívül lassú – a swap partíció sikertelen hozzáadásának története

Ebben a cikkben egy olyan helyzetről fogok beszélni, amely a közelmúltban történt a VPS-felhőnk egyik szerverével, ami miatt több órán keresztül elakadtam. Körülbelül 15 éve foglalkozom Linux szerverek konfigurálásával és hibaelhárításával, de ez az eset egyáltalán nem illik a gyakorlatomba - több téves feltételezést tettem, és egy kicsit kétségbeestem, mielőtt sikerült helyesen meghatároznom a probléma okát és megoldani. .

bevezetés

Közepes méretű felhőt üzemeltetünk, amelyet szabványos szerverekre építünk az alábbi konfigurációval - 32 mag, 256 GB RAM és 4500TB PCI-E Intel P4 NVMe meghajtó. Nagyon szeretjük ezt a konfigurációt, mert kiküszöböli az IO-többlet miatti aggódást azáltal, hogy a megfelelő korlátozást biztosítja a virtuálisgép-példánytípus szintjén. Mivel az NVMe Intel P4500 Lenyűgöző teljesítménnyel rendelkezik, egyszerre tudjuk biztosítani a teljes IOPS-kiépítést a gépek számára, és a biztonsági mentési tárhelyet egy tartalék szerver számára nulla IOWAIT mellett.

Azon régi hívek közé tartozunk, akik nem használnak hiperkonvergens SDN-t és más stílusos, divatos, fiatalos dolgokat a VM-kötetek tárolására, mert úgy gondolják, hogy minél egyszerűbb a rendszer, annál könnyebb a hibaelhárítása „elment a főguru a hegyekhez." Ennek eredményeként a VM-köteteket QCOW2 formátumban tároljuk XFS vagy EXT4 formátumban, amely az LVM2 tetején van telepítve.

A hangszereléshez használt termék - Apache CloudStack - is kénytelen a QCOW2 használatára.

A biztonsági mentéshez teljes képet készítünk a kötetről LVM2 pillanatfelvételként (igen, tudjuk, hogy az LVM2 pillanatfelvételek lassúak, de az Intel P4500 itt is segít). Mi igen lvmcreate -s .. és a segítségével dd a biztonsági másolatot egy ZFS tárolóval rendelkező távoli szerverre küldjük. Itt még mindig enyhén haladunk - elvégre a ZFS képes tömörített formában tárolni az adatokat, és gyorsan visszaállíthatjuk DD vagy egyedi VM-köteteket szerezhet be mount -o loop ....

Természetesen nem az LVM2 kötet teljes képét távolíthatja el, hanem csatlakoztathatja a fájlrendszert a RO és magukat a QCOW2 képeket másolják, azonban szembesültünk azzal, hogy az XFS ettől lett rossz, és nem azonnal, hanem kiszámíthatatlan módon. Nagyon nem szeretjük, ha a hipervizor házigazdák hirtelen "kiragadnak" hétvégén, éjszaka vagy ünnepnapokon olyan hibák miatt, amelyek nem világosak, hogy mikor fognak bekövetkezni. Ezért az XFS-hez nem használunk pillanatfelvétel-beillesztést RO kötetek kinyeréséhez egyszerűen átmásoljuk a teljes LVM2 kötetet.

A biztonsági mentés sebességét esetünkben a biztonsági mentési szerver teljesítménye határozza meg, ami nem tömöríthető adatok esetén kb. 600-800 MB/s, további korlátozó tényező az a 10 Gbit/s-os csatorna, amelyre a tartalék szerver csatlakozik. a klaszterhez.

Ebben az esetben 8 hypervisor szerver biztonsági másolata kerül fel egyidejűleg egy tartalék szerverre. Így a backup szerver lemez- és hálózati alrendszerei, mivel lassabbak, nem engedik túlterhelni a hypervisor gazdagépek lemezalrendszereit, mivel egyszerűen nem képesek feldolgozni mondjuk 8 GB/sec-et, amit a hypervisor gazdagépek könnyen tudnak. előállítani.

A fenti másolási folyamat nagyon fontos a további történethez, beleértve a részleteket is - gyors Intel P4500 meghajtó, NFS és valószínűleg ZFS használatával.

Tartalék történet

Minden hypervisor csomóponton van egy kis, 8 GB méretű SWAP partíció, és magát a hypervisor csomópontot „kihelyezzük” DD a referencia képről. A szervereken lévő rendszerkötethez 2xSATA SSD RAID1 vagy 2xSAS HDD RAID1-et használunk LSI vagy HP hardvervezérlőn. Általában egyáltalán nem érdekel minket, hogy mi van benne, mivel rendszerkötetünk „majdnem csak olvasható” módban működik, kivéve a SWAP-ot. És mivel sok RAM van a szerveren és 30-40%-ban ingyenes, ezért nem gondolunk a SWAP-ra.

Biztonsági mentés folyamata. Ez a feladat valahogy így néz ki:

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

Ügyeljen rá ionice -c3, valójában ez a dolog teljesen használhatatlan az NVMe eszközök számára, mivel az IO ütemező a következőképpen van beállítva:

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

Azonban számos örökölt csomópontunk van hagyományos SSD RAID-ekkel, számukra ez lényeges, ezért költöznek. AMINT AZ. Összességében ez csak egy érdekes kódrészlet, amely megmagyarázza a hiábavalóságot ionice ilyen konfiguráció esetén.

Ügyeljen a zászlóra iflag=direct a DD. Közvetlen IO-t használunk a puffer-gyorsítótár megkerülésével, hogy elkerüljük az IO-pufferek szükségtelen cseréjét olvasás közben. Azonban, oflag=direct nem, mert a ZFS teljesítményével kapcsolatos problémákba ütköztünk a használata során.

Ezt a sémát több éve sikeresen alkalmazzuk probléma nélkül.

És akkor kezdődött... Felfedeztük, hogy az egyik csomópont már nincs mentve, az előző pedig szörnyű, 50%-os IOWAIT-tal futott. Amikor megpróbáltuk megérteni, hogy miért nem történik másolás, a következő jelenséggel találkoztunk:

Volume group "images" not found

Elkezdtünk azon gondolkodni, hogy „eljött a vége az Intel P4500-nak”, azonban a szerver kikapcsolása előtt a meghajtó cseréje érdekében még mindig szükség volt biztonsági mentésre. Az LVM2-t a metaadatok visszaállításával javítottuk egy LVM2 biztonsági másolatból:

vgcfgrestore images

Elindítottunk egy biztonsági mentést, és ezt az olajfestményt láttuk:

Ismét nagyon szomorúak voltunk – egyértelmű volt, hogy nem élhetünk így, mert az összes VPS szenvedni fog, ami azt jelenti, hogy mi is szenvedni fogunk. Hogy mi történt, az teljesen homályos... iostat szánalmas IOPS és a legmagasabb IOWAIT mutatott. Nem volt más ötlet, mint a „cseréljük le az NVMe-t”, de egy felismerés éppen időben történt.

A helyzet elemzése lépésről lépésre

Történelmi folyóirat. Néhány nappal korábban ezen a szerveren kellett létrehozni egy nagy VPS-t 128 GB RAM-mal. Úgy tűnt, van elég memória, de a biztonság kedvéért további 32 GB-ot különítettünk el a swap partíció számára. A VPS létrejött, sikeresen elvégezte a feladatát, és az incidens feledésbe merült, de a SWAP partíció megmaradt.

Konfigurációs funkciók. Minden felhőszervernél a paraméter vm.swappiness alapértelmezettre lett állítva 60. A SWAP pedig a SAS HDD RAID1-en jött létre.

Mi történt (a szerkesztők szerint). Biztonsági mentéskor DD sok írási adatot produkált, amelyeket a RAM puffereibe helyeztek, mielőtt NFS-be írták volna. Rendszermag, irányelvek vezérelve swappiness, sok oldalnyi VPS-memóriát áthelyezett a swap területre, amely egy lassú HDD RAID1 köteten volt. Ez az IOWAIT nagyon erőteljes növekedéséhez vezetett, de nem az IO NVMe, hanem az IO HDD RAID1 miatt.

Hogyan oldották meg a problémát. A 32 GB-os swap partíciót letiltották. Ez 16 órát vett igénybe; külön olvashat arról, hogyan és miért kapcsol ki ilyen lassan a SWAP. A beállítások módosultak swappiness egyenlő értékre 5 az egész felhőn.

Hogy nem történhetett ez meg?. Először is, ha a SWAP egy SSD RAID vagy NVMe eszközön lenne, másodszor, ha nem NVMe eszköz lenne, hanem egy lassabb eszköz, amely nem termel ekkora adatmennyiséget - ironikus módon a probléma azért történt, mert az NVMe túl gyors.

Ezt követően minden úgy kezdett működni, mint korábban - nulla IOWAIT-el.

Forrás: will.com