U ovom članku ću govoriti o situaciji koja se nedavno dogodila s jednim od poslužitelja u našem VPS oblaku, a koja me ostavila u nedoumici nekoliko sati. Konfiguriram i rješavam probleme s Linux poslužiteljima oko 15 godina, ali ovaj se slučaj uopće ne uklapa u moju praksu - napravio sam nekoliko pogrešnih pretpostavki i malo sam očajavao prije nego što sam uspio točno utvrditi uzrok problema i riješiti ga .
uvod
Upravljamo oblakom srednje veličine, koji gradimo na standardnim poslužiteljima sa sljedećom konfiguracijom - 32 jezgre, 256 GB RAM-a i 4500TB PCI-E Intel P4 NVMe pogon. Stvarno nam se sviđa ova konfiguracija jer eliminira potrebu za brigom o IO dodatnim troškovima pružanjem ispravnog ograničenja na razini tipa VM instance. Jer NVMe Intel ima impresivnu izvedbu, možemo istovremeno osigurati i punu IOPS opskrbu za strojeve i sigurnosnu pohranu na rezervnom poslužitelju bez IOWAIT-a.
Mi smo jedni od onih starovjeraca koji ne koriste hiperkonvergirani SDN i druge moderne, moderne, mladenačke stvari za pohranjivanje VM volumena, vjerujući da što je sustav jednostavniji, to ga je lakše riješiti u uvjetima "glavni guru je otišao u planine." Kao rezultat toga, pohranjujemo VM volumene u QCOW2 formatu u XFS ili EXT4, koji je implementiran povrh LVM2.
Također smo prisiljeni koristiti QCOW2 zbog proizvoda koji koristimo za orkestraciju - Apache CloudStack.
Da bismo napravili sigurnosnu kopiju, uzimamo punu sliku volumena kao LVM2 snimku (da, znamo da su LVM2 snimke spore, ali Intel P4500 nam i tu pomaže). Radimo lvmcreate -s .. i uz pomoć dd šaljemo sigurnosnu kopiju na udaljeni poslužitelj sa ZFS pohranom. Ovdje smo još uvijek malo napredovali - uostalom, ZFS može pohraniti podatke u komprimiranom obliku, a mi ih možemo brzo vratiti pomoću DD ili dobiti pojedinačne VM volumene pomoću mount -o loop ....
Naravno, možete ukloniti ne cijelu sliku LVM2 volumena, već montirati datotečni sustav u
ROi kopirati same QCOW2 slike, međutim, suočili smo se s činjenicom da je XFS zbog toga postao loš, i to ne odmah, već na nepredvidiv način. Zaista nam se ne sviđa kada se hipervizorski hostovi iznenada "zalijepe" vikendom, noću ili praznicima zbog grešaka za koje nije jasno kada će se dogoditi. Stoga za XFS ne koristimo montiranje snimkeROza izdvajanje volumena jednostavno kopiramo cijeli LVM2 volumen.
Brzina backup-a na backup server određena je u našem slučaju performansama backup servera, što je oko 600-800 MB/s za nekompresibilne podatke; daljnji limitator je 10Gbit/s kanal s kojim je backup server povezan. u klaster.
U ovom slučaju, sigurnosne kopije 8 hipervizorskih poslužitelja istovremeno se učitavaju na jedan rezervni poslužitelj. Dakle, diskovni i mrežni podsustavi rezervnog poslužitelja, budući da su sporiji, ne dopuštaju preopterećenje diskovnih podsustava hostova hipervizora, jer jednostavno nisu u stanju obraditi, recimo, 8 GB/sec, što hostovi hipervizora lako mogu proizvoditi.
Gornji proces kopiranja vrlo je bitan za daljnju priču, uključujući i detalje - korištenje brzog pogona Intel P4500, korištenje NFS-a i, vjerojatno, korištenje ZFS-a.
Rezervna priča
Na svakom hipervizorskom čvoru imamo malu SWAP particiju veličine 8 GB, a sam hipervizorski čvor "razvijamo" pomoću DD iz referentne slike. Za sistemski volumen na poslužiteljima koristimo 2xSATA SSD RAID1 ili 2xSAS HDD RAID1 na LSI ili HP hardverskom kontroleru. Općenito, uopće nas nije briga što je unutra, budući da naš volumen sustava radi u načinu rada "gotovo samo za čitanje", osim za SWAP. A budući da imamo puno RAM-a na poslužitelju i 30-40% je besplatno, ne razmišljamo o SWAP-u.
Proces izrade sigurnosne kopije. Ovaj zadatak izgleda otprilike ovako:
#!/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-snapNapomena ionice -c3, zapravo, ova stvar je potpuno beskorisna za NVMe uređaje, budući da je IO planer za njih postavljen kao:
cat /sys/block/nvme0n1/queue/scheduler
[none] Međutim, imamo niz naslijeđenih čvorova s konvencionalnim SSD RAID-ovima, za njih je to relevantno, pa se sele KAO ŠTO JE. Sve u svemu, ovo je samo zanimljiv dio koda koji objašnjava uzaludnost ionice u slučaju takve konfiguracije.
Obratite pažnju na zastavu iflag=direct za DD. Koristimo izravni IO zaobilazeći predmemoriju međuspremnika kako bismo izbjegli nepotrebnu zamjenu IO međuspremnika prilikom čitanja. Međutim, oflag=direct nemamo jer smo naišli na probleme s performansama ZFS-a kada smo ga koristili.
Ovu shemu uspješno koristimo već nekoliko godina bez problema.
I onda je počelo... Otkrili smo da jedan od čvorova više nije sigurnosno kopiran, a prethodni je radio s monstruoznim IOWAIT-om od 50%. Pokušavajući shvatiti zašto se kopiranje ne događa, naišli smo na sljedeći fenomen:
Volume group "images" not foundPočeli smo razmišljati o "došao je kraj za Intel P4500", međutim, prije isključivanja poslužitelja radi zamjene pogona, još uvijek je bilo potrebno napraviti sigurnosnu kopiju. Popravili smo LVM2 vraćanjem metapodataka iz sigurnosne kopije LVM2:
vgcfgrestore imagesPokrenuli smo sigurnosnu kopiju i vidjeli ovu uljanu sliku:
Opet smo bili jako tužni - bilo je jasno da ne možemo ovako živjeti jer će svi VPS-ovi patiti, što znači da ćemo i mi patiti. Što se dogodilo potpuno je nejasno - iostat pokazao jadan IOPS i najveći IOWAIT. Nije bilo drugih ideja osim "zamijenimo NVMe", ali uvid se dogodio baš na vrijeme.
Analiza situacije korak po korak
Povijesni časopis. Nekoliko dana ranije, na ovom poslužitelju bilo je potrebno napraviti veliki VPS sa 128 GB RAM-a. Činilo se da ima dovoljno memorije, ali radi sigurnosti dodijelili smo još 32 GB za swap particiju. VPS je napravljen, uspješno obavio svoj zadatak i incident je zaboravljen, ali SWAP particija je ostala.
Značajke konfiguracije. Za sve poslužitelje u oblaku parametar vm.swappiness postavljeno je kao zadano 60. I SWAP je napravljen na SAS HDD RAID1.
Što se dogodilo (prema urednicima). Prilikom izrade sigurnosne kopije DD proizvodio je mnogo podataka za pisanje, koji su bili smješteni u RAM međuspremnike prije pisanja u NFS. Jezgra sustava, vođena politikom swappiness, premještao je mnogo stranica VPS memorije u swap područje, koje se nalazilo na sporom HDD RAID1 volumenu. To je dovelo do vrlo snažnog rasta IOWAIT-a, ali ne zbog IO NVMe, već zbog IO HDD RAID1.
Kako je problem riješen. Swap particija od 32 GB bila je onemogućena. To je trajalo 16 sati; možete zasebno pročitati kako i zašto se SWAP gasi tako sporo. Postavke su promijenjene swappiness na vrijednost jednaku 5 po cijelom oblaku.
Kako se to ne bi dogodilo?. Prvo, kad bi SWAP bio na SSD RAID ili NVMe uređaju, a drugo, ako ne postoji NVMe uređaj, nego sporiji uređaj koji ne bi proizvodio toliku količinu podataka – ironično, problem se dogodio jer je taj NVMe prebrz.
Nakon toga je sve počelo raditi kao i prije - s nula IOWAIT-a.
Izvor: www.habr.com