Molta RAM libera, NVMe Intel P4500 e tutto è estremamente lento: la storia dell'aggiunta infruttuosa di una partizione di swap

In questo articolo parlerò di una situazione verificatasi recentemente con uno dei server del nostro cloud VPS, che mi ha lasciato perplesso per diverse ore. Ho configurato e risolto i problemi dei server Linux per circa 15 anni, ma questo caso non rientra affatto nella mia pratica: ho fatto diverse false supposizioni e sono diventato un po' disperato prima di riuscire a determinare correttamente la causa del problema e risolverlo .

preambolo

Gestiamo un cloud di medie dimensioni, che costruiamo su server standard con la seguente configurazione: 32 core, 256 GB di RAM e un'unità PCI-E Intel P4500 NVMe da 4 TB. Questa configurazione ci piace molto perché elimina la necessità di preoccuparsi del sovraccarico di I/O fornendo la restrizione corretta a livello di tipo di istanza VM. Perché NVMe Intel P4500 ha prestazioni impressionanti, possiamo fornire contemporaneamente sia il provisioning IOPS completo alle macchine sia l'archiviazione di backup su un server di backup con zero IOWAIT.

Siamo uno di quei vecchi credenti che non utilizzano SDN iperconvergente e altre cose giovanili, alla moda e alla moda per archiviare volumi di VM, credendo che più semplice è il sistema, più facile sarà risolverlo nelle condizioni in cui "il guru principale se n'è andato" alle montagne." Di conseguenza, archiviamo i volumi VM nel formato QCOW2 in XFS o EXT4, che viene distribuito su LVM2.

Siamo anche costretti a utilizzare QCOW2 dal prodotto che utilizziamo per l'orchestrazione: Apache CloudStack.

Per eseguire un backup, acquisiamo un'immagine completa del volume come snapshot LVM2 (sì, sappiamo che gli snapshot LVM2 sono lenti, ma anche qui l'Intel P4500 ci aiuta). Noi facciamo lvmcreate -s .. e con l'aiuto dd inviamo la copia di backup a un server remoto con archiviazione ZFS. Qui siamo ancora leggermente progressisti: dopo tutto, ZFS può archiviare i dati in forma compressa e possiamo ripristinarli rapidamente utilizzando DD o ottenere volumi VM individuali utilizzando mount -o loop ....

Ovviamente non puoi rimuovere l'immagine completa del volume LVM2, ma montare il file system nel file RO e copiamo le stesse immagini QCOW2, tuttavia, ci siamo trovati di fronte al fatto che XFS è diventato cattivo a causa di ciò, e non immediatamente, ma in modo imprevedibile. Non ci piace davvero quando gli host hypervisor si bloccano improvvisamente nei fine settimana, di notte o nei giorni festivi a causa di errori che non è chiaro quando si verificheranno. Pertanto, per XFS non utilizziamo il montaggio degli snapshot RO per estrarre i volumi, copiamo semplicemente l'intero volume LVM2.

La velocità di backup sul server di backup è determinata nel nostro caso dalle prestazioni del server di backup, che è di circa 600-800 MB/s per i dati non comprimibili; un ulteriore limitatore è il canale 10Gbit/s con cui è collegato il server di backup al grappolo.

In questo caso, le copie di backup di 8 server hypervisor vengono caricate contemporaneamente su un server di backup. Pertanto, i sottosistemi disco e rete del server di backup, essendo più lenti, non consentono il sovraccarico dei sottosistemi disco degli host hypervisor, poiché semplicemente non sono in grado di elaborare, ad esempio, 8 GB/sec, che gli host hypervisor possono facilmente elaborare. produrre.

Il processo di copia di cui sopra è molto importante per il seguito della storia, compresi i dettagli: utilizzando un veloce disco Intel P4500, utilizzando NFS e, probabilmente, utilizzando ZFS.

Storia di backup

Su ogni nodo dell'hypervisor abbiamo una piccola partizione SWAP di 8 GB e "rilasciamo" il nodo dell'hypervisor stesso utilizzando DD dall'immagine di riferimento. Per il volume di sistema sui server utilizziamo 2xSATA SSD RAID1 o 2xSAS HDD RAID1 su un controller hardware LSI o HP. In generale, non ci interessa affatto cosa c'è dentro, poiché il nostro volume di sistema funziona in modalità "quasi di sola lettura", ad eccezione di SWAP. E poiché abbiamo molta RAM sul server ed è libera per il 30-40%, non pensiamo allo SWAP.

Processo di backup. Questa attività è simile a questa:

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

Notare la ionice -c3, in effetti, questa cosa è del tutto inutile per i dispositivi NVMe, poiché per essi lo scheduler IO è impostato come:

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

Tuttavia, abbiamo un numero di nodi legacy con RAID SSD convenzionali, per loro questo è rilevante, quindi si stanno spostando COME SONO. Nel complesso, questo è solo un pezzo di codice interessante che spiega l'inutilità ionice in caso di tale configurazione.

Presta attenzione alla bandiera iflag=direct per DD. Usiamo l'I/O diretto bypassando la cache del buffer per evitare sostituzioni non necessarie dei buffer di I/O durante la lettura. Tuttavia, oflag=direct non lo facciamo perché abbiamo riscontrato problemi di prestazioni ZFS durante l'utilizzo.

Utilizziamo questo schema con successo da diversi anni senza problemi.

E poi è iniziato... Abbiamo scoperto che di uno dei nodi non veniva più eseguito il backup e che quello precedente funzionava con un mostruoso IOWAIT del 50%. Nel tentativo di capire perché la copia non avviene, abbiamo riscontrato il seguente fenomeno:

Volume group "images" not found

Abbiamo iniziato a pensare che "è arrivata la fine per l'Intel P4500", tuttavia, prima di spegnere il server per sostituire l'unità, era comunque necessario eseguire un backup. Abbiamo corretto LVM2 ripristinando i metadati da un backup LVM2:

vgcfgrestore images

Abbiamo lanciato un backup e abbiamo visto questo dipinto ad olio:

Ancora una volta eravamo molto tristi: era chiaro che non potevamo vivere così, poiché tutti i VPS avrebbero sofferto, il che significa che avremmo sofferto anche noi. Quello che è successo non è del tutto chiaro - iostat ha mostrato IOPS pietosi e IOWAIT più alti. Non c’erano altre idee se non “sostituiamo NVMe”, ma un’intuizione è arrivata giusto in tempo.

Analisi della situazione passo dopo passo

Rivista storica. Pochi giorni prima, su questo server era stato necessario creare una grande VPS con 128 GB di RAM. Sembrava che la memoria fosse sufficiente, ma per sicurezza abbiamo allocato altri 32 GB per la partizione di swap. Il VPS è stato creato, ha completato con successo il suo compito e l'incidente è stato dimenticato, ma la partizione SWAP è rimasta.

Funzionalità di configurazione. Per tutti i server cloud il parametro vm.swappiness era impostato come predefinito 60. E SWAP è stato creato su SAS HDD RAID1.

Cosa è successo (secondo la redazione). Durante il backup DD ha prodotto molti dati di scrittura, che sono stati inseriti nei buffer RAM prima di scrivere su NFS. Nucleo del sistema, guidato dalla politica swappiness, stava spostando molte pagine di memoria VPS nell'area di scambio, che si trovava su un volume HDD RAID1 lento. Ciò ha portato IOWAIT a crescere molto fortemente, ma non grazie a IO NVMe, ma a causa di IO HDD RAID1.

Come è stato risolto il problema. La partizione di swap da 32 GB è stata disabilitata. Ci sono volute 16 ore; puoi leggere separatamente come e perché SWAP si spegne così lentamente. Le impostazioni sono state modificate swappiness ad un valore pari a 5 su tutta la nuvola.

Come potrebbe non accadere?. In primo luogo, se SWAP fosse su un dispositivo SSD RAID o NVMe e, in secondo luogo, se non ci fosse un dispositivo NVMe, ma un dispositivo più lento che non produrrebbe un tale volume di dati, ironicamente, il problema si sarebbe verificato perché NVMe è troppo veloce.

Successivamente, tutto ha iniziato a funzionare come prima, con zero IOWAIT.

Fonte: habr.com