En este artículo hablaré de una situación que ocurrió recientemente con uno de los servidores en nuestra nube VPS, que me dejó perplejo durante varias horas. He estado configurando y solucionando problemas de servidores Linux durante aproximadamente 15 años, pero este caso no encaja en mi práctica en absoluto: hice varias suposiciones falsas y me desesperé un poco antes de poder determinar correctamente la causa del problema y resolverlo. .
Preámbulo
Operamos una nube de tamaño mediano, que construimos en servidores estándar con la siguiente configuración: 32 núcleos, 256 GB de RAM y una unidad PCI-E Intel P4500 NVMe de 4 TB. Realmente nos gusta esta configuración porque elimina la necesidad de preocuparse por la sobrecarga de E/S al proporcionar la restricción correcta en el nivel del tipo de instancia de VM. Porque NVMe Intel tiene un rendimiento impresionante, podemos proporcionar simultáneamente aprovisionamiento completo de IOPS a las máquinas y almacenamiento de respaldo a un servidor de respaldo sin IOWAIT.
Somos uno de esos viejos creyentes que no usan SDN hiperconvergente y otras cosas elegantes, modernas y juveniles para almacenar volúmenes de VM, creyendo que cuanto más simple es el sistema, más fácil es solucionar problemas en las condiciones de "el gurú principal se ha ido". a las montañas." Como resultado, almacenamos volúmenes de VM en formato QCOW2 en XFS o EXT4, que se implementa sobre LVM2.
También nos vemos obligados a utilizar QCOW2 por el producto que utilizamos para la orquestación: Apache CloudStack.
Para realizar una copia de seguridad, tomamos una imagen completa del volumen como una instantánea LVM2 (sí, sabemos que las instantáneas LVM2 son lentas, pero el Intel P4500 también nos ayuda aquí). Hacemos lvmcreate -s .. y con la ayuda dd enviamos la copia de seguridad a un servidor remoto con almacenamiento ZFS. Aquí todavía somos un poco progresivos; después de todo, ZFS puede almacenar datos en forma comprimida y podemos restaurarlos rápidamente usando DD u obtener volúmenes de VM individuales usando mount -o loop ....
Por supuesto, no puede eliminar la imagen completa del volumen LVM2, sino montar el sistema de archivos en el
ROy copiar las imágenes QCOW2, sin embargo, nos enfrentamos al hecho de que XFS se volvió malo debido a esto, y no de inmediato, sino de manera impredecible. Realmente no nos gusta cuando los hosts del hipervisor se "pegan" repentinamente los fines de semana, por la noche o en días festivos debido a errores que no están claros cuando ocurrirán. Por lo tanto, para XFS no utilizamos el montaje de instantáneas enROPara extraer volúmenes, simplemente copiamos todo el volumen LVM2.
La velocidad de la copia de seguridad en el servidor de copia de seguridad está determinada en nuestro caso por el rendimiento del servidor de copia de seguridad, que es de aproximadamente 600-800 MB/s para datos no comprimibles; un limitante adicional es el canal de 10 Gbit/s al que está conectado el servidor de copia de seguridad. al cúmulo.
En este caso, las copias de seguridad de 8 servidores hipervisor se cargan simultáneamente en un servidor de copia de seguridad. Por lo tanto, los subsistemas de disco y de red del servidor de respaldo, al ser más lentos, no permiten que los subsistemas de disco de los hosts del hipervisor se sobrecarguen, ya que simplemente no pueden procesar, digamos, 8 GB/seg, que los hosts del hipervisor pueden procesar fácilmente. producir.
El proceso de copia anterior es muy importante para la historia adicional, incluidos los detalles: usar una unidad rápida Intel P4500, usar NFS y, probablemente, usar ZFS.
Historia de respaldo
En cada nodo del hipervisor tenemos una pequeña partición SWAP de 8 GB de tamaño y "desplegamos" el nodo del hipervisor usando DD de la imagen de referencia. Para el volumen del sistema en los servidores, utilizamos 2xSATA SSD RAID1 o 2xSAS HDD RAID1 en un controlador de hardware LSI o HP. En general, no nos importa en absoluto lo que hay dentro, ya que el volumen de nuestro sistema funciona en modo "casi de sólo lectura", excepto SWAP. Y como tenemos mucha RAM en el servidor y está libre en un 30-40%, no pensamos en SWAP.
Proceso de copia de seguridad. Esta tarea se parece a esto:
#!/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-snapTenga en cuenta la ionice -c3De hecho, esto es completamente inútil para dispositivos NVMe, ya que el programador de IO para ellos está configurado como:
cat /sys/block/nvme0n1/queue/scheduler
[none] Sin embargo, tenemos varios nodos heredados con RAID SSD convencionales, para ellos esto es relevante, por lo que se están moviendo COMO ES. En general, esto es sólo un fragmento de código interesante que explica la inutilidad ionice en caso de tal configuración.
Presta atención a la bandera. iflag=direct para DD. Utilizamos IO directa sin pasar por el caché del búfer para evitar el reemplazo innecesario de los búferes de IO durante la lectura. Sin embargo, oflag=direct No lo hacemos porque hemos encontrado problemas de rendimiento de ZFS al usarlo.
Hemos estado utilizando este esquema con éxito durante varios años sin problemas.
Y entonces empezó... Descubrimos que uno de los nodos ya no tenía respaldo y el anterior estaba funcionando con un monstruoso IOWAIT del 50%. Al intentar comprender por qué no se produce la copia, nos encontramos con el siguiente fenómeno:
Volume group "images" not foundEmpezamos a pensar en “el fin del Intel P4500 ha llegado”, sin embargo, antes de apagar el servidor para reemplazar el disco, aún era necesario realizar una copia de seguridad. Arreglamos LVM2 restaurando metadatos desde una copia de seguridad de LVM2:
vgcfgrestore imagesLanzamos una copia de seguridad y vimos esta pintura al óleo:
Nuevamente estábamos muy tristes: estaba claro que no podíamos vivir así, ya que todos los VPS sufrirían, lo que significa que nosotros también sufriríamos. Lo que pasó no está del todo claro. iostat mostró IOPS lamentables y el IOWAIT más alto. No había más ideas que “reemplacemos NVMe”, pero se produjo una idea justo a tiempo.
Análisis de la situación paso a paso.
revista historica. Unos días antes, en este servidor fue necesario crear un VPS grande con 128 GB de RAM. Parecía haber suficiente memoria, pero para estar seguros, asignamos otros 32 GB para la partición de intercambio. Se creó el VPS, completó exitosamente su tarea y se olvidó el incidente, pero la partición SWAP permaneció.
Funciones de configuración. Para todos los servidores en la nube el parámetro vm.swappiness estaba configurado por defecto 60. Y SWAP se creó en SAS HDD RAID1.
Qué pasó (según los editores). Al realizar una copia de seguridad DD produjo una gran cantidad de datos de escritura, que se colocaron en búferes RAM antes de escribir en NFS. Núcleo del sistema, guiado por la política swappiness, estaba moviendo muchas páginas de memoria VPS al área de intercambio, que estaba ubicada en un volumen HDD RAID1 lento. Esto llevó a que IOWAIT creciera con mucha fuerza, pero no debido a IO NVMe, sino a IO HDD RAID1.
Cómo se resolvió el problema. La partición de intercambio de 32 GB estaba deshabilitada. Esto tomó 16 horas; puedes leer por separado cómo y por qué SWAP se apaga tan lentamente. La configuración ha sido cambiada. swappiness a un valor igual a 5 por toda la nube.
¿Cómo podría esto no suceder?. En primer lugar, si SWAP estuviera en un dispositivo SSD RAID o NVMe y, en segundo lugar, si no hubiera un dispositivo NVMe, sino un dispositivo más lento que no produciría tal volumen de datos, irónicamente, el problema ocurrió porque ese NVMe es demasiado rápido.
Después de eso, todo empezó a funcionar como antes: con cero IOWAIT.
Fuente: habr.com