Molta memòria RAM gratuïta, NVMe Intel P4500 i tot és extremadament lent: la història de l'addició infructuosa d'una partició d'intercanvi

En aquest article, parlaré d'una situació que es va produir recentment amb un dels servidors del nostre núvol VPS, que em va deixar perplex durant diverses hores. He estat configurant i resolent problemes de servidors Linux durant uns 15 anys, però aquest cas no encaixa gens a la meva pràctica: vaig fer diverses suposicions falses i em vaig desesperar una mica abans de poder determinar correctament la causa del problema i resoldre'l. .

Preàmbul

Operem un núvol de mida mitjana, que construïm en servidors estàndard amb la configuració següent: 32 nuclis, 256 GB de RAM i una unitat PCI-E Intel P4500 NVMe de 4 TB. Ens agrada molt aquesta configuració perquè elimina la necessitat de preocupar-se per la sobrecàrrega d'IO proporcionant la restricció correcta al nivell de tipus d'instància de VM. Perquè NVMe Intel P4500 té un rendiment impressionant, podem proporcionar simultàniament el subministrament complet d'IOPS a les màquines i l'emmagatzematge de còpia de seguretat a un servidor de còpia de seguretat amb zero IOWAIT.

Som d'aquells vells creients que no utilitzen SDN hiperconvergent i altres coses elegants, de moda i juvenils per emmagatzemar volums de VM, creient que com més senzill és el sistema, més fàcil és solucionar-lo en les condicions de "el guru principal ha marxat". a les muntanyes”. Com a resultat, emmagatzemem volums de VM en format QCOW2 en XFS o EXT4, que es desplega a sobre de LVM2.

També estem obligats a utilitzar QCOW2 pel producte que fem servir per a l'orquestració: Apache CloudStack.

Per fer una còpia de seguretat, fem una imatge completa del volum com a instantània LVM2 (sí, sabem que les instantànies LVM2 són lentes, però l'Intel P4500 també ens ajuda aquí). Nosaltres fem lvmcreate -s .. i amb l'ajuda dd enviem la còpia de seguretat a un servidor remot amb emmagatzematge ZFS. Aquí encara som una mica progressistes: després de tot, ZFS pot emmagatzemar dades en forma comprimida i les podem restaurar ràpidament mitjançant DD o obteniu volums de VM individuals mitjançant mount -o loop ....

Per descomptat, podeu eliminar no la imatge completa del volum LVM2, sinó muntar el sistema de fitxers al fitxer RO i copieu les mateixes imatges QCOW2, però, ens vam enfrontar al fet que XFS es va tornar malament a partir d'això, i no immediatament, sinó d'una manera imprevisible. Realment no ens agrada que l'hipervisor s'enganxi sobtadament els caps de setmana, a la nit o els dies festius a causa d'errors que no tenen clar quan passaran. Per tant, per a XFS no fem servir el muntatge d'instantànies RO per extreure volums, simplement copiem tot el volum LVM2.

La velocitat de còpia de seguretat al servidor de còpia de seguretat està determinada en el nostre cas pel rendiment del servidor de còpia de seguretat, que és d'uns 600-800 MB/s per a dades incompressibles; un altre limitador és el canal de 10 Gbit/s amb el qual està connectat el servidor de còpia de seguretat. al clúster.

En aquest cas, les còpies de seguretat de 8 servidors d'hipervisor es carreguen simultàniament a un servidor de còpia de seguretat. Així, els subsistemes de disc i xarxa del servidor de còpia de seguretat, sent més lents, no permeten que els subsistemes de disc dels hosts de l'hipervisor es sobrecarreguin, ja que simplement no poden processar, per exemple, 8 GB/s, que els hosts de l'hipervisor poden fàcilment. produir.

El procés de còpia anterior és molt important per a la història posterior, inclosos els detalls: utilitzar una unitat ràpida Intel P4500, utilitzar NFS i, probablement, utilitzar ZFS.

Història de còpia de seguretat

A cada node d'hipervisor tenim una petita partició SWAP de 8 GB de mida i "despleguem" el mateix node de l'hipervisor utilitzant DD de la imatge de referència. Per al volum del sistema als servidors, utilitzem 2xSATA SSD RAID1 o 2xSAS HDD RAID1 en un controlador de maquinari LSI o HP. En general, no ens importa gens el que hi ha dins, ja que el volum del nostre sistema funciona en mode "gairebé només de lectura", excepte SWAP. I com que tenim molta memòria RAM al servidor i és un 30-40% gratuït, no pensem en SWAP.

Procés de còpia de seguretat. Aquesta tasca s'assembla a això:

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

Preste atenció a ionice -c3, de fet, això és completament inútil per als dispositius NVMe, ja que el programador d'IO per a ells s'estableix com:

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

Tanmateix, tenim una sèrie de nodes heretats amb RAID SSD convencionals, per a ells això és rellevant, de manera que s'estan movent COM ÉS. En general, aquest és només un fragment de codi interessant que explica la inutilitat ionice en cas d'aquesta configuració.

Fixeu-vos en la bandera iflag=direct per DD. Utilitzem l'E/S directa sense passar per la memòria cau de la memòria intermèdia per evitar la substitució innecessària de la memòria intermèdia d'E/S durant la lectura. Malgrat això, oflag=direct no ho fem perquè hem trobat problemes de rendiment de ZFS quan l'utilitzem.

Hem estat utilitzant aquest esquema amb èxit durant diversos anys sense problemes.

I llavors va començar... Vam descobrir que un dels nodes ja no tenia una còpia de seguretat i l'anterior funcionava amb un IOWAIT monstruós del 50%. Quan intentem entendre per què no es produeix la còpia, ens trobem amb el fenomen següent:

Volume group "images" not found

Vam començar a pensar en "ha arribat el final per a l'Intel P4500", però, abans d'apagar el servidor per substituir la unitat, encara era necessari fer una còpia de seguretat. Hem arreglat LVM2 restaurant les metadades d'una còpia de seguretat de LVM2:

vgcfgrestore images

Hem llançat una còpia de seguretat i hem vist aquesta pintura a l'oli:

De nou estàvem molt tristos: estava clar que no podríem viure així, ja que tots els VPS patirien, és a dir, nosaltres també patiríem. El que va passar no està del tot clar... iostat va mostrar IOPS lamentable i el més alt IOWAIT. No hi havia cap altra idea que "substituïm NVMe", però es va produir una visió just a temps.

Anàlisi de la situació pas a pas

Revista històrica. Uns dies abans, en aquest servidor calia crear un gran VPS amb 128 GB de RAM. Semblava que hi havia prou memòria, però per estar segurs, vam assignar 32 GB més per a la partició d'intercanvi. El VPS es va crear, va completar amb èxit la seva tasca i l'incident es va oblidar, però la partició SWAP es va mantenir.

Característiques de configuració. Per a tots els servidors en núvol el paràmetre vm.swappiness estava establert per defecte 60. I SWAP es va crear a SAS HDD RAID1.

Què va passar (segons els editors). Quan feu una còpia de seguretat DD va produir moltes dades d'escriptura, que es van col·locar a la memòria intermèdia RAM abans d'escriure a NFS. Nucli del sistema, guiat per la política swappiness, estava movent moltes pàgines de memòria VPS a l'àrea d'intercanvi, que es trobava en un volum lent del HDD RAID1. Això va fer que IOWAIT creixia molt fort, però no a causa de IO NVMe, sinó a causa de IO HDD RAID1.

Com es va resoldre el problema. La partició d'intercanvi de 32 GB s'ha desactivat. Això va trigar 16 hores; podeu llegir per separat com i per què SWAP s'apaga tan lentament. S'ha canviat la configuració swappiness a un valor igual a 5 per tot el núvol.

Com podria no passar això?. En primer lloc, si SWAP es trobava en un dispositiu SSD RAID o NVMe i, en segon lloc, si no hi havia cap dispositiu NVMe, sinó un dispositiu més lent que no produiria aquest volum de dades, irònicament, el problema va passar perquè aquest NVMe és massa ràpid.

Després d'això, tot va començar a funcionar com abans, amb zero IOWAIT.

Font: www.habr.com