O mulțime de RAM liberă, NVMe Intel P4500 și totul este extrem de lent - povestea adăugării nereușite a unei partiții swap

În acest articol, voi vorbi despre o situație care s-a întâmplat recent cu unul dintre serverele din cloudul nostru VPS, care m-a lăsat nedumerit câteva ore. Am configurat și depanat serverele Linux de aproximativ 15 ani, dar acest caz nu se încadrează deloc în practica mea - am făcut câteva presupuneri false și am fost puțin disperat înainte de a putea determina corect cauza problemei și de a o rezolva. .

preambul

Operăm un cloud de dimensiuni medii, pe care îl construim pe servere standard cu următoarea configurație - 32 de nuclee, 256 GB RAM și o unitate PCI-E Intel P4500 NVMe de 4TB. Ne place foarte mult această configurație, deoarece elimină nevoia de a vă face griji cu privire la supraîncărcarea IO, oferind restricția corectă la nivel de tip de instanță VM. Pentru că NVMe Intel P4500 are performanțe impresionante, putem oferi simultan atât provizionarea IOPS completă pentru mașini, cât și stocarea de rezervă pe un server de rezervă cu zero IOWAIT.

Suntem unul dintre acei credincioși bătrâni care nu folosesc SDN hiperconvergent și alte lucruri stilate, la modă, pentru tineret pentru a stoca volumele VM, crezând că, cu cât sistemul este mai simplu, cu atât este mai ușor să-l depanați în condițiile „guru-ului principal a plecat. spre munti." Ca rezultat, stocăm volumele VM în format QCOW2 în XFS sau EXT4, care este implementat deasupra LVM2.

De asemenea, suntem forțați să folosim QCOW2 de produsul pe care îl folosim pentru orchestrare - Apache CloudStack.

Pentru a efectua o copie de rezervă, luăm o imagine completă a volumului ca un instantaneu LVM2 (da, știm că instantaneele LVM2 sunt lente, dar Intel P4500 ne ajută și aici). Noi facem lvmcreate -s .. si cu ajutorul dd trimitem copia de rezervă la un server la distanță cu stocare ZFS. Aici suntem încă puțin progresivi - la urma urmei, ZFS poate stoca date sub formă comprimată și le putem restaura rapid folosind DD sau obțineți volume individuale de VM folosind mount -o loop ....

Puteți, desigur, să eliminați nu întreaga imagine a volumului LVM2, ci să montați sistemul de fișiere în RO și copiați imaginile QCOW2 în sine, cu toate acestea, ne-am confruntat cu faptul că XFS a devenit rău din asta, și nu imediat, ci într-un mod imprevizibil. Chiar nu ne place când hypervisorul găzduiește „lipește” brusc în weekend, noaptea sau în vacanțe din cauza unor erori care nu sunt clare când se vor întâmpla. Prin urmare, pentru XFS nu folosim montarea instantanee RO pentru a extrage volume, pur și simplu copiam întregul volum LVM2.

Viteza de backup pe serverul de backup este determinată în cazul nostru de performanța serverului de backup, care este de aproximativ 600-800 MB/s pentru date incompresibile; un alt limitator este canalul de 10 Gbit/s cu care este conectat serverul de backup. la cluster.

În acest caz, copiile de rezervă ale 8 servere hypervisor sunt încărcate simultan pe un server de rezervă. Astfel, subsistemele de disc și de rețea ale serverului de rezervă, fiind mai lente, nu permit supraîncărcarea subsistemelor de disc ale gazdelor hipervizoare, deoarece pur și simplu nu sunt capabile să proceseze, să zicem, 8 GB/sec, pe care gazdele hipervizorului le pot cu ușurință. legume şi fructe.

Procesul de copiere de mai sus este foarte important pentru povestea ulterioară, inclusiv pentru detalii - folosind o unitate rapidă Intel P4500, folosind NFS și, probabil, folosind ZFS.

Povestea de rezervă

Pe fiecare nod de hipervizor avem o partiție SWAP mică de 8 GB în dimensiune și „dezvoltam” nodul hipervizor însuși folosind DD din imaginea de referință. Pentru volumul sistemului de pe servere, folosim 2xSATA SSD RAID1 sau 2xSAS HDD RAID1 pe un controler hardware LSI sau HP. În general, nu ne pasă deloc ce este înăuntru, deoarece volumul sistemului nostru funcționează în modul „aproape doar citire”, cu excepția SWAP. Și din moment ce avem multă memorie RAM pe server și este 30-40% gratuit, nu ne gândim la SWAP.

Proces de backup. Această sarcină arată cam așa:

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

Notă ionice -c3, de fapt, acest lucru este complet inutil pentru dispozitivele NVMe, deoarece planificatorul IO pentru acestea este setat ca:

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

Cu toate acestea, avem o serie de noduri moștenite cu RAID-uri SSD convenționale, pentru ei acest lucru este relevant, așa că se mută Aşa cum este. În general, aceasta este doar o bucată de cod interesantă care explică inutilitatea ionice în cazul unei astfel de configuraţii.

Atenție la steagul iflag=direct pentru DD. Folosim IO directă ocolind memoria cache a tamponului pentru a evita înlocuirea inutilă a tampoanelor IO la citire. In orice caz, oflag=direct nu o facem pentru că am întâlnit probleme de performanță ZFS când îl folosim.

Folosim această schemă cu succes de câțiva ani fără probleme.

Și apoi a început... Am descoperit că unul dintre noduri nu mai avea copii de rezervă, iar cel precedent rula cu un IOWAIT monstruos de 50%. Când am încercat să înțelegem de ce nu are loc copierea, am întâlnit următorul fenomen:

Volume group "images" not found

Am început să ne gândim la „a venit sfârșitul pentru Intel P4500”, cu toate acestea, înainte de a opri serverul pentru a înlocui unitatea, era încă necesar să facem o copie de rezervă. Am reparat LVM2 prin restaurarea metadatelor dintr-o copie de rezervă LVM2:

vgcfgrestore images

Am lansat o copie de rezervă și am văzut această pictură în ulei:

Din nou, eram foarte triști - era clar că nu putem trăi așa, deoarece toate VPS-urile ar avea de suferit, ceea ce înseamnă că vom suferi și noi. Ce s-a întâmplat este complet neclar - iostat a arătat IOPS jalnic și cel mai mare IOWAIT. Nu au existat alte idei decât „să înlocuim NVMe”, dar o perspectivă a apărut la timp.

Analiza situației pas cu pas

Revista istorica. Cu câteva zile mai devreme, pe acest server a fost necesară crearea unui VPS mare cu 128 GB RAM. Părea să fie suficientă memorie, dar pentru a fi sigur, am alocat încă 32 GB pentru partiția de swap. VPS-ul a fost creat, și-a finalizat cu succes sarcina și incidentul a fost uitat, dar partiția SWAP a rămas.

Caracteristici de configurare. Pentru toate serverele cloud parametrul vm.swappiness a fost setat la implicit 60. Și SWAP a fost creat pe SAS HDD RAID1.

Ce s-a întâmplat (conform editorilor). Când faceți back-up DD a produs o mulțime de date de scriere, care au fost plasate în memorie tampon RAM înainte de a scrie în NFS. Nucleul sistemului, ghidat de politică swappiness, muta multe pagini de memorie VPS în zona de swap, care se afla pe un volum lent HDD RAID1. Acest lucru a dus la creșterea foarte puternică a IOWAIT, dar nu datorită IO NVMe, ci datorită IO HDD RAID1.

Cum s-a rezolvat problema. Partiția de swap de 32 GB a fost dezactivată. Acest lucru a durat 16 ore; puteți citi separat despre cum și de ce SWAP se oprește atât de lent. Setările au fost modificate swappiness la o valoare egală cu 5 peste tot norul.

Cum sa nu se intample asta?. În primul rând, dacă SWAP ar fi pe un dispozitiv SSD RAID sau NVMe și, în al doilea rând, dacă nu ar exista un dispozitiv NVMe, ci un dispozitiv mai lent care nu ar produce un asemenea volum de date - în mod ironic, problema s-a întâmplat pentru că acel NVMe este prea rapid.

După aceea, totul a început să funcționeze ca înainte - cu zero IOWAIT.

Sursa: www.habr.com