Un saccu di RAM libera, NVMe Intel P4500 è tuttu hè estremamente lento - a storia di l'aghjunzione senza successu di una partizione swap

In questu articulu, parleraghju di una situazione chì hè accaduta recentemente cù unu di i servitori in u nostru nuvulu VPS, chì m'hà lasciatu stumped per parechje ore. Aghju cunfigurà è risolve i servitori Linux per circa 15 anni, ma questu casu ùn si mette in tuttu in a mo pratica - aghju fattu parechje ipotesi falsi è aghju un pocu disperatu prima di pudè determinà currettamente a causa di u prublema è risolve. .

Preamble

Operemu un nuvulu mediu, chì custruemu nantu à i servitori standard cù a cunfigurazione seguente - 32 core, 256 GB RAM è un drive 4500TB PCI-E Intel P4 NVMe. Ci piace assai sta cunfigurazione perchè elimina a necessità di preoccupassi di l'overhead IO fornendu a restrizione curretta à u livellu di u tipu d'istanza VM. Perchè NVMe Intel P4500 hà un rendimentu impressiunanti, pudemu furnisce simultaneamente un approvvigionamentu IOPS cumpletu à e macchine è un almacenamentu di salvezza à un servitore di salvezza cù zero IOWAIT.

Semu unu di quelli vechji credenti chì ùn utilizanu micca SDN iperconvergente è altre cose eleganti, di moda, di ghjuventù per almacenà volumi VM, crede chì u più simplice u sistema, più faciule hè di risolve u prublema in e cundizioni di "u guru principale hè andatu. à a muntagna". In u risultatu, almacenemu volumi VM in formatu QCOW2 in XFS o EXT4, chì hè implementatu nantu à LVM2.

Semu ancu furzati à aduprà QCOW2 da u pruduttu chì usemu per l'orchestrazione - Apache CloudStack.

Per fà una copia di salvezza, pigliemu una maghjina completa di u voluminu cum'è una snapshot LVM2 (sì, sapemu chì i snapshots LVM2 sò lenti, ma l'Intel P4500 ci aiuta ancu quì). Facemu lvmcreate -s .. è cù l'aiutu dd mandemu a copia di salvezza à un servitore remotu cù almacenamiento ZFS. Quì simu sempre ligeramente progressivi - dopu tuttu, ZFS pò almacenà dati in forma cumpressa, è pudemu risturà rapidamente usendu DD o uttene volumi VM individuali utilizendu mount -o loop ....

Pudete, sicuru, caccià micca l'imaghjini sanu di u voluminu LVM2, ma muntate u sistema di schedari in u RO è copià l'imaghjini QCOW2 stessi, però, avemu statu affruntatu cù u fattu chì XFS hè diventatu male da questu, è micca immediatamente, ma in modu imprevisible. Ùn ci piace micca veramente quandu l'ospiti di l'ipervisore "stick" di colpu in u weekend, di notte o di vacanze per via di errori chì ùn sò micca chjaru quandu succedenu. Per quessa, per XFS ùn avemu micca usatu snapshot mounting in RO per estrattà volumi, simpricimenti copiamu tuttu u voluminu LVM2.

A velocità di salvezza à u servitore di salvezza hè determinata in u nostru casu da a prestazione di u servitore di salvezza, chì hè di circa 600-800 MB / s per dati incompressible; un altru limitatore hè u canali 10Gbit / s cù quale u servitore di salvezza hè cunnessu. à u cluster.

In questu casu, e copie di salvezza di 8 servitori di ipervisori sò caricate simultaneamente in un servitore di salvezza. Cusì, i sottosistemi di discu è di rete di u servitore di salvezza, essendu più lento, ùn permettenu micca i sottosistemi di discu di l'ospiti di l'ipervisori per sopracarcà, postu chì ùn sò micca solu capaci di processà, per dì, 8 GB / sec, chì l'ospiti di l'ipervisore ponu facilmente. pruduce.

U prucessu di copia sopra hè assai impurtante per a storia ulteriore, cumpresi i dettagli - utilizendu un veloce Intel P4500 drive, usendu NFS è, probabilmente, usendu ZFS.

Storia di salvezza

Nantu à ogni nodu di ipervisore avemu una piccula partizione SWAP di 8 GB di dimensione, è "stendemu" u nodu di ipervisore stessu utilizendu DD da l'imagine di riferimentu. Per u voluminu di u sistema nantu à i servitori, usemu 2xSATA SSD RAID1 o 2xSAS HDD RAID1 in un controller di hardware LSI o HP. In generale, ùn ci importa micca ciò chì ci hè in l'internu, postu chì u nostru voluminu di u sistema opera in modu "quasi lettura", fora di SWAP. E postu chì avemu assai RAM in u servitore è hè 30-40% liberu, ùn pensemu micca à SWAP.

Prucessu di salvezza. Stu compitu s'assumiglia à questu:

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

attenti à ionice -c3, in fattu, sta cosa hè completamente inutile per i dispositi NVMe, postu chì u pianificatore IO per elli hè stabilitu cum'è:

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

In ogni casu, avemu una quantità di nodi legati cù RAID SSD convenzionali, per elli questu hè pertinenti, cusì si movenu. AS IS. In generale, questu hè solu un pezzu interessante di codice chì spiega a futilità ionice in casu di tali cunfigurazione.

Attenti à a bandiera iflag=direct di DD. Utilizemu l'IO direttu bypassendu u buffer cache per evità a sostituzione inutile di i buffer IO durante a lettura. Tuttavia, oflag=direct ùn avemu micca perchè avemu scontru prublemi di rendiment ZFS quandu l'utilizanu.

Avemu usatu stu schema cù successu per parechji anni senza prublemi.

E poi cuminciò... Avemu scupertu chì unu di i nodi ùn era più backed up, è u precedente era in esecuzione cù un IOWAIT monstruosu di 50%. Quandu circava di capisce perchè a copia ùn si faci micca, avemu scontru u fenomenu seguente:

Volume group "images" not found

Avemu cuminciatu à pensà à "a fine hè ghjunta per l'Intel P4500", però, prima di disattivà u servitore per rimpiazzà l'unità, era ancu necessariu di fà una copia di salvezza. Fixemu LVM2 restaurà i metadati da una copia di salvezza LVM2:

vgcfgrestore images

Avemu lanciatu una copia di salvezza è avemu vistu sta pittura à l'oliu:

Di novu eramu assai tristi - era chjaru chì ùn pudemu micca campà cusì, postu chì tutti i VPS soffrenu, chì significa chì avemu ancu soffrenu. Ciò chì hè accadutu ùn hè micca chjaru - iostat dimustrava IOPS pietosi è u più altu IOWAIT. Ùn ci era micca idee altru ch'è "sustituite NVMe", ma una intuizione hè accaduta ghjustu à tempu.

Analisi di a situazione passu à passu

Rivista storica. Uni pochi ghjorni prima, in questu servitore era necessariu di creà un grande VPS cù 128 GB RAM. Ci pareva esse abbastanza memoria, ma per esse in u latu sicuru, avemu attribuitu un altru 32 GB per a partizione swap. U VPS hè statu creatu, hà cumpletu cù successu u so compitu è ​​l'incidentu hè scurdatu, ma a partizione SWAP hè stata.

Funzioni di cunfigurazione. Per tutti i servitori cloud u paràmetru vm.swappiness hè stata stabilita per default 60. È SWAP hè statu creatu nantu à SAS HDD RAID1.

Ciò chì hè accadutu (sicondu l'editori). Quandu a copia di salvezza DD pruduciutu assai dati di scrittura, chì sò stati posti in buffer RAM prima di scrive à NFS. U core di u sistema, guidatu da a pulitica swappiness, si moveva parechje pagine di memoria VPS à l'area di swap, chì si trovava nantu à un voluminu lento HDD RAID1. Questu hà purtatu à IOWAIT crescente assai forte, ma micca per IO NVMe, ma per IO HDD RAID1.

Cumu u prublema hè stata risolta. A partizione swap 32GB hè stata disattivata. Questu hà pigliatu 16 ore; pudete leghje separatamente cumu è perchè SWAP si spegne cusì lentamente. I paràmetri sò stati cambiati swappiness à un valore uguale à 5 tutta a nuvola.

Cumu puderia micca succede questu?. Prima, se SWAP era in un SSD RAID o NVMe, è in segundu, s'ellu ùn ci era micca un dispositivu NVMe, ma un dispositivu più lento chì ùn pruduce micca un tali voluminu di dati - ironicamente, u prublema hè accadutu perchè chì NVMe hè troppu veloce.

Dopu quì, tuttu hà cuminciatu à travaglià cum'è prima - cù zero IOWAIT.

Source: www.habr.com