Moita memoria RAM gratuíta, NVMe Intel P4500 e todo é extremadamente lento: a historia da adición sen éxito dunha partición de intercambio

Neste artigo, falarei dunha situación que ocorreu recentemente cun dos servidores da nosa nube VPS, que me deixou perplexo durante varias horas. Levo uns 15 anos configurando e solucionando problemas de servidores Linux, pero este caso non encaixa en absoluto na miña práctica: fixen varias suposicións falsas e desespero un pouco antes de poder determinar correctamente a causa do problema e solucionalo. .

Preámbulo

Operamos unha nube de tamaño medio, que construímos en servidores estándar coa seguinte configuración: 32 núcleos, 256 GB de RAM e unha unidade PCI-E Intel P4500 NVMe de 4 TB. Gústanos moito esta configuración porque elimina a necesidade de preocuparse pola sobrecarga de IO proporcionando a restrición correcta a nivel de tipo de instancia de VM. Porque NVMe Intel P4500 ten un rendemento impresionante, podemos proporcionar simultaneamente aprovisionamento completo de IOPS ás máquinas e almacenamento de copia de seguridade nun servidor de copia de seguridade sen IOWAIT.

Somos un deses vellos crentes que non usan SDN hiperconverxentes e outras cousas elegantes, de moda e xuvenís para almacenar volumes de VM, crendo que canto máis sinxelo é o sistema, máis fácil é solucionalo nas condicións de que "o gurú principal pasou". ás montañas”. Como resultado, almacenamos volumes de VM en formato QCOW2 en XFS ou EXT4, que se desprega enriba de LVM2.

Tamén estamos obrigados a usar QCOW2 polo produto que usamos para a orquestración: Apache CloudStack.

Para realizar unha copia de seguridade, tomamos unha imaxe completa do volume como unha instantánea LVM2 (si, sabemos que as instantáneas LVM2 son lentas, pero o Intel P4500 tamén nos axuda). Facemos lvmcreate -s .. e coa axuda dd enviamos a copia de seguridade a un servidor remoto con almacenamento ZFS. Aquí aínda estamos lixeiramente progresivos: despois de todo, ZFS pode almacenar datos en forma comprimida e podemos restauralos rapidamente usando DD ou obtén volumes de VM individuais usando mount -o loop ....

Por suposto, podes eliminar non a imaxe completa do volume LVM2, senón montar o sistema de ficheiros no ficheiro RO e copiar as propias imaxes QCOW2, con todo, enfrontámonos ao feito de que XFS se volveu mal a partir diso, e non inmediatamente, senón dun xeito imprevisible. Realmente non nos gusta cando os anfitrións do hipervisor "pegan" de súpeto os fins de semana, pola noite ou os festivos debido a erros que non están claros cando ocorrerán. Polo tanto, para XFS non usamos montaxe de instantáneas RO para extraer volumes, simplemente copiamos todo o volume LVM2.

A velocidade de copia de seguridade do servidor de copia de seguridade está determinada no noso caso polo rendemento do servidor de copia de seguridade, que é duns 600-800 MB/s para datos incompresibles; outro limitador é a canle de 10 Gbit/s coa que está conectado o servidor de copia de seguridade. ao clúster.

Neste caso, as copias de seguridade de 8 servidores de hipervisor cárganse simultáneamente nun servidor de copia de seguridade. Así, os subsistemas de disco e rede do servidor de copia de seguridade, sendo máis lentos, non permiten que os subsistemas de disco dos anfitrións do hipervisor se sobrecarguen, xa que simplemente non son capaces de procesar, digamos, 8 GB/s, que os anfitrións do hipervisor poden facilmente procesar. producir.

O proceso de copia anterior é moi importante para a historia posterior, incluídos os detalles: usando unha unidade Intel P4500 rápida, usando NFS e, probablemente, usando ZFS.

Historia de copia de seguridade

En cada nodo do hipervisor temos unha pequena partición SWAP de 8 GB de tamaño e "despegamos" o propio nodo do hipervisor usando DD a partir da imaxe de referencia. Para o volume do sistema en servidores, usamos 2xSATA SSD RAID1 ou 2xSAS HDD RAID1 nun controlador de hardware LSI ou HP. En xeral, non nos importa nada o que hai dentro, xa que o volume do noso sistema funciona en modo "case só lectura", agás o SWAP. E como temos moita memoria RAM no servidor e é un 30-40% gratuíto, non pensamos en SWAP.

Proceso de copia de seguridade. Esta tarefa parece algo así:

#!/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ón a ionice -c3, de feito, isto é completamente inútil para os dispositivos NVMe, xa que o programador de IO para eles está configurado como:

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

Non obstante, temos unha serie de nodos legados con RAID SSD convencionais, para eles isto é relevante, polo que se están movendo COMO É. En xeral, este é só un anaco de código interesante que explica a inutilidade ionice en caso de tal configuración.

Presta atención á bandeira iflag=direct para DD. Usamos IO directo evitando a caché do búfer para evitar a substitución innecesaria dos búfers de IO durante a lectura. Porén, oflag=direct non o facemos porque atopamos problemas de rendemento de ZFS ao usalo.

Levamos varios anos usando este esquema con éxito sen problemas.

E entón comezou... Descubrimos que un dos nodos xa non tiña unha copia de seguranza e o anterior estaba a executarse cun monstruoso IOWAIT do 50%. Ao tentar entender por que non se produce a copia, atopamos o seguinte fenómeno:

Volume group "images" not found

Comezamos a pensar en "chegou o final para o Intel P4500", non obstante, antes de apagar o servidor para substituír a unidade, aínda era necesario realizar unha copia de seguridade. Resolvemos LVM2 restaurando os metadatos dunha copia de seguridade de LVM2:

vgcfgrestore images

Lanzamos unha copia de seguridade e vimos esta pintura ao óleo:

De novo estabamos moi tristes: estaba claro que non podíamos vivir así, xa que todos os VPS sufrirían, o que significa que nós tamén sufriríamos. O que pasou non está completamente claro - iostat mostrou IOPS lamentable e o IOWAIT máis alto. Non había outras ideas que "substituímos NVMe", pero xusto a tempo produciuse unha idea.

Análise da situación paso a paso

Revista histórica. Uns días antes, neste servidor era necesario crear un VPS grande con 128 GB de RAM. Parecía que había memoria suficiente, pero para estar seguros, asignamos outros 32 GB para a partición de intercambio. O VPS foi creado, completou con éxito a súa tarefa e o incidente foi esquecido, pero a partición SWAP permaneceu.

Características de configuración. Para todos os servidores na nube o parámetro vm.swappiness estaba configurado como predeterminado 60. E SWAP creouse en SAS HDD RAID1.

Que pasou (segundo os editores). Ao facer unha copia de seguridade DD produciu moitos datos de escritura, que foron colocados nos búfers da RAM antes de escribir en NFS. Núcleo do sistema, guiado pola política swappiness, estaba movendo moitas páxinas de memoria VPS á área de intercambio, que estaba situada nun volume RAID1 do disco duro lento. Isto levou a que IOWAIT crecese moito, pero non debido a IO NVMe, senón a IO HDD RAID1.

Como se solucionou o problema. Desactivouse a partición de intercambio de 32 GB. Isto levou 16 horas; podes ler por separado como e por que SWAP se desactiva tan lentamente. Cambiouse a configuración swappiness a un valor igual a 5 por toda a nube.

Como non puido pasar isto?. En primeiro lugar, se SWAP estivese nun dispositivo SSD RAID ou NVMe e, en segundo lugar, se non houbese ningún dispositivo NVMe, senón un dispositivo máis lento que non produciría tal volume de datos; irónicamente, o problema ocorreu porque ese NVMe é demasiado rápido.

Despois diso, todo comezou a funcionar como antes, con cero IOWAIT.

Fonte: www.habr.com