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
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-asennustaRO
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 -c3
Itse 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