Paljon ilmaista RAM-muistia, NVMe Intel P4500 ja kaikki on erittäin hidasta - tarina sivutusosion epäonnistuneesta lisäämisestä

Tässä artikkelissa puhun tilanteesta, joka äskettäin tapahtui yhden VPS-pilvemme palvelimen kanssa ja joka sai minut jumiin useiksi tunteiksi. Olen tehnyt Linux-palvelimien konfigurointia ja vianmääritystä noin 15 vuotta, mutta tämä tapaus ei sovi käytäntööni ollenkaan - tein useita vääriä oletuksia ja jouduin hieman epätoivoon ennen kuin pystyin määrittämään ongelman syyn oikein ja ratkaisemaan sen .

johdanto

Käytämme keskikokoista pilvipalvelua, jonka rakennamme vakiopalvelimille seuraavalla kokoonpanolla - 32 ydintä, 256 Gt RAM-muistia ja 4500 Tt PCI-E Intel P4 NVMe -asema. Pidämme todella tästä kokoonpanosta, koska se eliminoi tarpeen huolehtia IO-ylimääräisistä kustannuksista tarjoamalla oikean rajoituksen VM-ilmentymän tyyppitasolla. Koska NVMe Intel P4500 on vaikuttava suorituskyky, voimme tarjota samanaikaisesti sekä täyden IOPS-provisioinnin koneille että varmuuskopiotallennustilan varmuuskopiopalvelimelle ilman IOWAITia.

Olemme yksi niistä vanhoista uskovista, jotka eivät käytä hyperkonvergoitua SDN:ää ja muita tyylikkäitä, muodikkaita, nuorisoasioita VM-taltioiden tallentamiseen, koska uskovat, että mitä yksinkertaisempi järjestelmä, sitä helpompi on tehdä vianmääritys olosuhteissa "pääguru on mennyt". vuorille." Tämän seurauksena tallennamme VM-taltiot QCOW2-muodossa XFS- tai EXT4-muodossa, joka on otettu käyttöön LVM2:n päällä.

Myös orkestrointiin käyttämämme tuote - Apache CloudStack - pakottaa meidät käyttämään QCOW2:ta.

Varmuuskopiointia varten otamme täyden kuvan äänenvoimakkuudesta LVM2-vedoksena (kyllä, tiedämme, että LVM2:n tilannekuvat ovat hitaita, mutta Intel P4500 auttaa meitä myös tässä). Me teemme lvmcreate -s .. ja avustuksella dd Lähetämme varmuuskopion etäpalvelimelle, jossa on ZFS-tallennustila. Tässä ollaan edelleen hieman edistyksellisiä - loppujen lopuksi ZFS voi tallentaa tietoja pakatussa muodossa, ja voimme palauttaa sen nopeasti käyttämällä DD tai hanki yksittäisiä VM-taltioita käyttämällä mount -o loop ....

Et tietenkään voi poistaa LVM2-taltion koko kuvaa, vaan liittää tiedostojärjestelmän RO ja kopioida itse QCOW2-kuvat, mutta kohtasimme sen tosiasian, että XFS muuttui huonoksi tästä, eikä heti, vaan arvaamattomalla tavalla. Emme todellakaan pidä siitä, kun hypervisor-isännät "jäävät kiinni" yhtäkkiä viikonloppuisin, öisin tai pyhäpäivinä virheiden vuoksi, joista ei ole selvää, milloin ne tapahtuvat. Siksi XFS:ssä emme käytä snapshot-asennusta RO taltioiden poimimiseksi kopioimme yksinkertaisesti koko LVM2-taltion.

Varmuuskopiointinopeuden varmuuskopiopalvelimelle määrittää meidän tapauksessamme varmuuskopiopalvelimen suorituskyky, joka on noin 600-800 MB/s pakkaamattomalla tiedolla, lisärajoittimena on 10 Gbit/s kanava, johon varmuuskopiopalvelin on kytketty klusteriin.

Tässä tapauksessa 8 hypervisor-palvelimen varmuuskopiot ladataan samanaikaisesti yhdelle varmuuskopiopalvelimelle. Näin ollen varmuuskopiopalvelimen levy- ja verkkoalijärjestelmät, jotka ovat hitaampia, eivät salli hypervisor-isäntien levyalijärjestelmien ylikuormitusta, koska ne eivät yksinkertaisesti pysty käsittelemään esim. 8 Gt/s, jonka hypervisor-isännät voivat helposti. tuottaa.

Yllä oleva kopiointiprosessi on erittäin tärkeä jatkotarinalle, mukaan lukien yksityiskohdat - käyttämällä nopeaa Intel P4500 -asemaa, käyttämällä NFS:ää ja luultavasti ZFS:ää.

Varatarina

Jokaisessa hypervisor-solmussa on pieni SWAP-osio, jonka koko on 8 Gt, ja otamme itse hypervisor-solmun käyttöön käyttämällä DD referenssikuvasta. Palvelinten järjestelmätaltiolla käytämme 2xSATA SSD RAID1:tä tai 2xSAS HDD RAID1:tä LSI- tai HP-laitteistoohjaimessa. Yleensä emme välitä ollenkaan siitä, mitä sisällä on, koska järjestelmämme toimii "melkein luku" -tilassa, paitsi SWAP. Ja koska meillä on paljon RAM-muistia palvelimella ja se on 30-40% ilmaista, emme ajattele SWAPia.

Varmuuskopiointiprosessi. Tämä tehtävä näyttää suunnilleen tältä:

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

Kiinnitä huomiota ionice -c3Itse asiassa tämä asia on täysin hyödytön NVMe-laitteille, koska niiden IO-ajastin on asetettu seuraavasti:

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

Meillä on kuitenkin useita vanhoja solmuja, joissa on tavanomaiset SSD RAIDit, niille tämä on olennaista, joten ne ovat siirtymässä KUTEN ON. Kaiken kaikkiaan tämä on vain mielenkiintoinen koodinpala, joka selittää turhuuden ionice tällaisen kokoonpanon tapauksessa.

Kiinnitä huomiota lippuun iflag=direct varten DD. Käytämme suoraa IO:ta ohittamalla puskurivälimuisti, jotta vältetään IO-puskurien tarpeeton vaihtaminen luettaessa. Kuitenkin, oflag=direct emme, koska olemme kohdanneet ZFS-suorituskykyongelmia käyttäessämme sitä.

Olemme käyttäneet tätä järjestelmää menestyksekkäästi useiden vuosien ajan ilman ongelmia.

Ja sitten se alkoi... Havaitsimme, että yhtä solmuista ei enää varmuuskopioitu, ja edellinen oli käynnissä hirviömäisellä 50 %:n IOWAITilla. Kun yritimme ymmärtää, miksi kopiointia ei tapahdu, kohtasimme seuraavan ilmiön:

Volume group "images" not found

Aloimme ajatella "Intel P4500:n loppu on tullut", mutta ennen palvelimen sammuttamista aseman vaihtamiseksi oli silti tarpeen tehdä varmuuskopiointi. Korjasimme LVM2:n palauttamalla metatiedot LVM2-varmuuskopiosta:

vgcfgrestore images

Aloitimme varmuuskopion ja näimme tämän öljymaalauksen:

Olimme jälleen hyvin surullisia - oli selvää, ettemme voisi elää näin, koska kaikki VPS:t kärsisivät, mikä tarkoittaa, että kärsimme myös me. Mitä tapahtui, on täysin epäselvää - iostat osoitti säälittävää IOPS:ää ja korkeinta IOWAIT:ia. Ei ollut muita ideoita kuin "vaihdetaan NVMe", mutta oivallus tapahtui juuri ajoissa.

Tilanneanalyysi askel askeleelta

Historiallinen lehti. Muutamaa päivää aiemmin tälle palvelimelle oli tarpeen luoda suuri VPS, jossa oli 128 Gt RAM-muistia. Muistia näytti olevan tarpeeksi, mutta varmuuden vuoksi varasimme vielä 32 Gt swap-osiolle. VPS luotiin, suoritti tehtävänsä onnistuneesti ja tapaus unohtui, mutta SWAP-osio säilyi.

Asetusominaisuudet. Parametri kaikille pilvipalvelimille vm.swappiness asetettiin oletukseksi 60. Ja SWAP luotiin SAS HDD RAID1:lle.

Mitä tapahtui (toimittajien mukaan). Varmuuskopioinnin aikana DD tuotti paljon kirjoitusdataa, joka sijoitettiin RAM-puskureihin ennen NFS:ään kirjoittamista. Järjestelmän ydin, politiikan ohjaama swappiness, siirsi useita VPS-muistisivuja swap-alueelle, joka sijaitsi hitaalla HDD RAID1 -taltiolla. Tämä johti siihen, että IOWAIT kasvoi erittäin voimakkaasti, mutta ei IO NVMe:n vaan IO HDD RAID1:n takia.

Miten ongelma ratkesi. 32 Gt:n swap-osio poistettiin käytöstä. Tämä kesti 16 tuntia; voit lukea erikseen kuinka ja miksi SWAP sammuu niin hitaasti. Asetuksia on muutettu swappiness arvoon, joka on yhtä suuri kuin 5 kaikkialla pilvessä.

Miten näin ei voisi tapahtua?. Ensinnäkin, jos SWAP olisi SSD RAID- tai NVMe-laitteessa, ja toiseksi, jos NVMe-laitetta ei olisi, vaan hitaampi laite, joka ei tuota niin suurta datamäärää - ironista kyllä, ongelma johtui siitä, että NVMe on liian nopea.

Sen jälkeen kaikki alkoi toimia kuten ennenkin - nollalla IOWAITilla.

Lähde: will.com