Palju vabast RAM-i, NVMe Intel P4500 ja kõik tõrgub — lugu ebaõnnestunud vahetusruumi lisamisest.

Selles artiklis räägin olukorrast, mis hiljuti juhtus ühe meie VPS pilveserveriga, jättes mind paariks tunniks segadusse. Olen umbes 15 aastat tegelenud Linuxi serverite konfigureerimise ja tõrkeotsinguga, kuid see juhtum ei mahu absoluutselt minu praktikasse — tegin mitmeid valejäreldusi ja olin veidi meeleheitel, enne kui suutsin probleemi põhjuse õigesti tuvastada ja lahendada.

Eelõigus

Kasutame keskmise suurusega pilve, mille ehitame tüüpilistel serveritel, millel on järgmine konfiguratsioon — 32 tuuma, 256 GB RAM ja PCI-E Intel P4500 NVMe ketas mahuga 4TB. Meile meeldib see konfiguratsioon, kuna see ei lase IO puuduses muretseda, tagades õiged piirangud VM (virtuaalmasinate) instantside tasemel. Kuna NVMe Intel P4500 omab muljetavaldavat jõudlust, saame samal ajal tagada nii täis IOPS-i pakkumise masinatele kui ka andmete varundamise null IOWAIT-iga varukoopiaserveril.

Me oleme nagu need vanamoodsad, kes ei kasuta hüperkonvergeeruvaid SDN-e ega muid stiilseid, moekaid ja noortele suunatud lahendusi VM-i mahtude hoidmiseks, uskudes, et mida lihtsam on süsteem, seda lihtsam on seda tõrkeotsida tingimustes "peamine guru sõitis mägedesse". Seetõttu hoiame VM mahtusid QCOW2 formaadis XFS-is või EXT4-s, mis on paigaldatud LVM2 peale.

QCOW2 kasutamine on meil sunnitud ka toote poolt, mida me kasutame orkestreerimiseks — Apache CloudStack.

Varundamise tegemiseks võtame täieliku mahupiiri pildi LVM2 snapshot'ina (jah, me teame, et LVM2 snapshot'id on aeglased, aga Intel P4500 aitab meil ka siin). Me teeme lvmcreate -s .. ja kasutame dd saadame varukoopia kaugserverisse ZFS-hoidlas. Siin oleme siiski natukene progressiivsed — ZFS oskab ikkagi andmeid kompressitud kujul hoida ja me saame neid kiiresti taastada kasutades D või kätte saada eraldi VM-mahtusid kasutades mount -o loop ....

Tõepoolest, võime teha ka mitte täielikku LVM2 pildi, vaid monteerida failisüsteemi RO ja ja kopeerida QCOW2 pilte, kuid oleme kokku puutunud olukordadega, kus XFS muutus sellest halvaks, ja mitte kohe, vaid ettearvamatult. Me ei armasta, kui hüperviisori hostid "kinni jäävad" äkki nädalavahetustel, öösel või pühade ajal vigade tõttu, mis võivad juhtuda teadmata ajal. Seetõttu ei kasuta me XFS-i puhul jääkide mountimist. RO kogu LVM2 mahuti kopeerimise asemel.

Varundamise kiirus varuserveril sõltub meie puhul varuserveri töötlusvõimest, mis on umbes 600-800 MB/s mittekompressitavate andmete jaoks, järgmine piiraja on 10Gbit/s kanal, millega varuserver on ühendatud klastriga.

Samas laadivad ühe varuserveri peale varukoopiad 8 serverite hüperviisorit. Seega, varuserveri kettasüsteem ja võrgu süsteem, olles aeglasemad, ei lase üle koormata hüperviisorite kettasüsteeme, kuna nad lihtsalt ei suuda töödelda, ütleme, 8 GB/s, mida hüperviisorid võivad rahulikult anda.

Ülaltoodud kopeerimisprotsess on jutustamise jaoks äärmiselt oluline, sealhulgas detailide osas — Intel P4500 kiire mäluseadmestiku kasutamine, NFS kasutamine ja tõenäoliselt ZFS kasutamine.

Varundamise lugu

Igas hüperviisori sõlmes on meil väike 8 GB SWAP partitsioon, ja ise hüperviisori "ülevaatamine" toimub D standardpildist. Serverite süsteemipartitsiooniks kasutame 2xSATA SSD RAID1 või 2xSAS HDD RAID1 LSI või HP riistvarakontrolleril. Tegelikult ei oma me mingit tähtsust selle sisu suhtes, kuna meie süsteemipartitsioon töötab "peaaegu readonly" režiimis, välja arvatud SWAP. Kuna meil on serveris väga palju RAM-i ja see on 30-40% vabana, ei mõtle me SWAP-ile.

Varundamise loomise protsess. See ülesanne näeb välja umbes nii:

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

Pange tähele ionice -c3, tegelikult on see NVMe seadmete jaoks täiesti kasutud, kuna nende I/O-sihik on seadistatud nagu:

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

Kuid meil on rida pärandisõlmi tavaliste SSD RAID-idega, mille jaoks see on asjakohane, ja seetõttu AS IS. Ühesõnaga, see on lihtsalt huvitav koodilõik, mis selgitab selle konfiguratsiooni tühisust. ionice sellises konfiguratsioonis.

Pange tähele lippu iflag=direct kuna D. Kasutame otse IO-d vahemälu kaudu, et vältida liigseid IO-vahemälu asendusi lugemise ajal. Siiski, oflag=direct me ei tee seda, kuna oleme täheldanud ZFS-i jõudluse probleeme selle kasutamisel.

Seda skeemi oleme edukalt kasutanud juba mitu aastat ilma probleemideta.

Ja siis see algas… Avastasin, et ühe sõlme varukoopia ei toimi, samas kui eelmine tehti tohutu IOWAITiga peaaegu 50%. Püüdes mõista, miks ei toimu varukoopiat, sattusime nähtuse otsa:

Mahtgrupp "images" ei leitud

Käisime mõtlema "Intel P4500 lõpp on käes", kuid enne serveri väljalülitamist ketta asendamiseks oli siiski vajalik varukoopia teha. LVM2 taastati LVM2 varukoopiast metainformatsiooni taastamise abil:

vgcfgrestore images

Käivitame varukoopia ja näeme sellist pilti:

Taaskord muutusime väga kurvaks — oli selge, et nii elada ei saa, kuna kõik VPS-id kannatavad, mis tähendab, et kannatame ka meie. Mis toimus, jääb täiesti arusaamatuks — iostat näitas häid IOPS-e ja kõrgeimat IOWAIT-d. Ainus idee oli "kasutada NVMe"; õnneks tuli õige mõte õigel ajal.

Situatsiooni analüüs samm-sammult

Ajalooline ajakiri. Mõni päev tagasi oli sel serveril vaja luua suur VPS, millel on 128 GB RAM. Mälu tundus piisav, kuid igaks juhuks eraldati veel 32 GB vahetusfaili jaoks. VPS loodi, täitis oma eesmärki ja insident unustati, kuid SWAP-i osa jäi alles.

Konfiguratsiooni eripära. Kõikide pilveservere puhul oli parameeter vm.swappiness seadistatud vaikimisi väärtusele 60. Ja SWAP loodi SAS HDD RAID1-l.

Mis juhtus (ajakiri arvab). Varundamise ajal D pakkus palju kirjutamisandmeid, mis paigutati RAM-i puhvrisse enne NFS-i kirjutamist. Süsteemi südamik, järgides poliitikat swappiness, liikus palju VPS-i mälu lehti vahetusfaili alasse, mis asus aeglasel HDD RAID1 mahul. See põhjustas IOWAIT-i dramaatilise tõusu, kuid mitte NVMe IO arvelt, vaid HDD RAID1 IO arvelt.

Kuidas probleem lahendati. 32GB vahetusruum eemaldati. Selleks kulus 16 tundi; kuidas ja miks vahetusruum nii aeglaselt välja lülitatakse, saate lugeda eraldi. Parameetreid muudeti. swappiness väärtuseks 5 kogu pilves.

Kuidas see oleks saanud juhtuda. Esiteks, kui vahetusruum oleks SSD RAID-i või NVMe seadmes; teiseks, kui NVMe seadet ei oleks ja oleks aeglasem seade, mis ei suudaks sellist andmehulka välja anda — iroonia on, et probleem tekkis just sellest, et NVMe on liiga kiire.

Pärast seda hakkas kõik töötama nagu varem — null IOWAIT-iga.

Allikas: habr.com