Nuevo servidor: Edoras

Durante el curso 2019-2020 ha entrado en servicio Edoras, un nuevo servidor que reemplaza a nuestro venerable Rohan que ha sufrido la pérdida un disco.

Rohan entró en producción en mayo del 2016 y supuso nuestra primera experiencia con toda la infraestructura del centro virtualizada con libvirt/kvm. Desde entonces ha estado ejecutando infatigablemente nuestras MVs hasta que el 27 de septiembre de 2019 perdió uno de sus discos.

[vie sep 27 08:37:28 2019] sd 0:0:0:0: [sda] tag#23 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[vie sep 27 08:37:28 2019] sd 0:0:0:0: [sda] tag#23 Sense Key : Illegal Request [current] [descriptor] 
[vie sep 27 08:37:28 2019] sd 0:0:0:0: [sda] tag#23 Add. Sense: Unaligned write command
[vie sep 27 08:37:28 2019] sd 0:0:0:0: [sda] tag#23 CDB: Write(16) 8a 00 00 00 00 00 01 15 64 f8 00 00 00 08 00 00
[vie sep 27 08:37:28 2019] blk_update_request: I/O error, dev sda, sector 18179320
:

El disco en cuestión era un WD Red WD40EFRX de 4TB cuya pérdida —puesto que formaba parte de un mirror ZFS— no supuso ninguna pérdida de datos ni interrupción de servicio. Se pueden leer más detalles sobre el hardware de Rohan en un documento antiguo en el que explicaba sus características.

Pero no es cuestión de tentar a la suerte manteniendo en producción un servidor degradado. Así que se decidió montar un servidor nuevo en el que ejecutar las MVs y así Edoras —después de una tensa espera por el material necesario— entró en producción ejecutando todas nuestras MVs el 16 de noviembre de 2019.

Descripción de Edoras

Edoras es un servidor HPE ProLiant ML10 Gen9 del cual tenemos dos unidades disponibles. No se trata de una máquina grande ni moderna, pero el detalle de contar con dos unidades nos permitirá montar otro equipo que pueda ejecutar nuestros servicios cuando vuelva a ocurrir la próxima avería.

La gran novedad respecto a Rohan (que tenía dos discos SSD y dos discos convencionales) es que todo el almacenamiento es SSD. En concreto se utilizan:

• 2 discos Samsung SSD 860 PRO 512GB. Con una partición para montar un RAID1 con el SO y otra partición para actuar como SLOG ZFS.
• 2 discos Samsung SSD 860 EVO 4TB. Para formar el mirror ZFS en el que se guardará /var/lib/libvirt.

La placa base admite 64GiB de memoria ECC DDR4 2133MHz en 4 módulos. Se han instalado 32GiB de RAM en dos módulos, de los cuales 8GiB están destinados a la cache ARC de ZFS.

La CPU es probablemente el punto menos brillante pues se trata de un Intel Xeon E3-1225-v5 de 3.3GHz y 4 núcleos sin Hyper-threading.

Se ha añadido una tarjeta de red con dos puertos de 1Gbps y un SAI de 1400VA para proteger el servidor que proporciona una autonomía estimada de 96 minutos con el servidor a pleno rendimiento. Network UPS Tools está configurado para comenzar el apagado del equipo al agotar el 50% de la carga de la batería.

Como sistema operativo está instalado Ubuntu 18.04 server con arranque UEFI. Como se trata de un host para ejecutar máquinas virtuales todo está enfocado a ejecutar libvirt y kvm, al margen de ssh y alguna herramienta de monitorización poco más hay que destacar. Sí que hay un trabajo importante de configuración del SO: desde los puentes y las VLANs hasta la realización de los backups.

Se pueden consultar el estado de Edoras en: http://valinor.iespuigcastellar.xeill.net/elpuig.xeill.net/edoras.elpuig.xeill.net/index.html

Carga de trabajo

La carga de trabajo varía a medida que se montan servicios y se substituyen los antiguos. En la actualidad se ejecutan 12 máquinas virtuales, algunas para un solo servicio y otras con contenedores LXD en su interior.

Por tanto se están utilizando 17 vCPUs en una máquina con 4 núcleos, la ram comprometida por las MVs alcanza los 18 GiB y sus discos los 3292 GiB.

Pero además dos de las máquinas —matrioska y matrioska-1804— tienen por objetivo ejecutar contenedores LXD. Entre ambas ejecutan:

 Por supuesto los contenedores se limitan a compartir los recursos de la MV en la que están anidados.

Asignación de recursos

Como se puede ver varios de los recursos, por ejemplo las 17 vCPUs y las 12 CPUs de los contenedores que se ejecutan en 4 núcleos físicos, están sobreasignados. La 'magia' de la virtualización consiste en esto, en proporcionar recursos virtuales que con frecuencia superar al conjunto de los recursos físicos existentes.

Pero naturalmente esto solo tiene gracia mientras las aplicaciones que utilizan los recursos virtuales no perciban una caída de rendimiento al saturar los recursos reales.

Veamos algunas de las técnicas que ayudan a Edoras a ejecutar sus servicios con buen rendimiento.

CPU: 4 núcleos físicos, 29 CPUs virtuales

El µP de Edoras es un Intel Xeon E3-1225-v5 de 3.3GHz y 4 núcleos sin Hyper-threading. Una CPU de 2015 que cuenta con 4 núcleos que se disputan:

• Las aplicaciones instaladas en el host. Entre las que hay que contar el propio SO, ZFS, libvirt/kvm y cualquier aplicación utilizada en los backups como ssh, zstd y rclone.
• Las máquinas virtuales y los contenedores que implementan nuestra infraestructura.

Aquí por supuesto los más relevante es el grado de utilización de cada uno de los servicios. Teniendo tan pocos núcleos físicos para repartir hay que asegurar que ninguna aplicación —o probable utilización conjunta, por ejemplo el contenedor letsencrypt trabaja cuando se accede a cualquier servicio web— provoque congestión y degrade el rendimiento de otras aplicaciones.

Por eso la mayoría de MVs tienen asignada una sola vCPU y solo algunas especialmente importantes que pueden aprovechar otro núcleo tienen asignadas 2 vCPUs.

En el caso de los contenedores la asignación de CPU se realiza a dos niveles, primero se asignan 2vCPUs a la MV y después se limita el número máximo de núcleos que puede utilizar el contenedor.

Si fuera necesario aún se podrían asignar pesos en libvirt y lxd para actuar sobre el reparto de CPU en una situación de congestión.

En las gráficas se puede apreciar un día típico de trabajo de Edoras y un festivo en el que se están realizando los backups offsite (la carga de trabajo nice).

Los picos más altos de consumo de CPU corresponden a baba-yaga-1804-v2 (que ejecuta Ansible y ARA Records Ansible) y revisa los ordenadores del centro cada mañana y cada tarde. En segundo puesto y de un modo más sostenido durante el horario lectivo consumen CPU cirdan-1.04 (el gateway para cada vlan) y matrioska (que ejecuta Graphite y recibe muchas muestras por minuto).

RAM: 32GiB

Actualmente Edoras tiene instalados 32GiB de RAM ECC.

Esta memoria se utiliza para:

• Ejecutar el SO y aplicaciones que se ejecutan en el host.
• 8GiB están asignados para la cache de primer nivel de ZFS: ARC - Adaptive Replacement Cache.
• Ejecutar las diferentes máquinas KVM.

Resulta interesante observar:

• El servidor prácticamente no utiliza swap. De hecho tiene configurado un espacio de intercambio pero el valor swappiness está fijado a 0.
• El sistema operativo está instalado sobre un RAID 1 con EXT4. Pero una vez que ha arrancado allí no hay prácticamente actividad, así que la RAM dedicada a cache y buffers es mínima. Si hubiera actividad los buffers y cache de Linux tienden a crecer ocupando toda la memoria disponible a costa de la cache de ZFS ARC.
• Se ha configurado el tamaño mínimo de ARC (1GiB) y máximo (8GiB).
• El sistema de deduplicación de memoria KSM (Kernel Same-page Merging) ahorra unos 3GiB de RAM. Pero cuando al realizar el backup (a las 5:00) se guarda el estado de cada MV con virsh managed save se pierde la deduplicación.

Actualmente en el servidor no se utiliza memory overcommitment pues aún quedan disponibles unos 4GiB para utilizar en futuros servicios. Pero si se consideran los contenedores LXD que se están ejecutando en el interior de las dos MVs entonces queda clara la eficiencia de los contenedores.

Por ejemplo matrioska-1804 es una MV con 2GiB de RAM, pero en su interior se están ejecutando 7 contenedores que —sumando sus límites— creen disponer de 8GiB de RAM cuando de media sus procesos están utilizando 1.5GiB de la MV.

Almacenamiento

Tal y como se ha comentado anteriormente la novedad principal de Edoras es que todo su almacenamiento está formado por discos SSD, así se ha incrementado generosamente el número de operaciones de entrada salida que se pueden realizar por unidad de tiempo (IOPS) y se mantiene la capacidad del servidor anterior al ofrecer 4TB para los datos.

La función principal de los dos discos de 512GB es almacenar el SO y permitir el arranque, la de los dos discos de 4TB es almacenar los datos de las máquinas virtuales.

Los discos sda y sdb tienen las siguientes particiones:

• Partición ESP (EFI system partiton) de 953MB.
• Partición componente RAID de 46.6 GB.
• Partición para ZFS SLOG de 16 GB.
• El resto del disco está sin particionar.

Con las particiones sda2 y sdb2 se componer md0, el RAID1 en el que está instalado el sistema operativo.

Los discos sdc y sdd están completamente controlados por ZFS, configurados como un mirror para ofrecer 4TB de almacenamiento con tolerancia a fallos.

Así el pool queda configurado de la siguiente manera:

vcarceler@edoras:~$ zpool status
  pool: DATA
 state: ONLINE
  scan: scrub repaired 0B in 2h4m with 0 errors on Sun Jan 12 02:28:44 2020
config:

    NAME                                                     STATE     READ WRITE CKSUM
    DATA                                                     ONLINE       0     0     0
      mirror-0                                               ONLINE       0     0     0
        ata-Samsung_SSD_860_EVO_4TB_S3YPNB0M601864L          ONLINE       0     0     0
        ata-Samsung_SSD_860_EVO_4TB_S3YPNB0M601852V          ONLINE       0     0     0
    logs
      mirror-1                                               ONLINE       0     0     0
        ata-Samsung_SSD_860_PRO_512GB_S42YNX0MA11201J-part3  ONLINE       0     0     0
        ata-Samsung_SSD_860_PRO_512GB_S42YNX0MA11215P-part3  ONLINE       0     0     0

errors: No known data errors
vcarceler@edoras:~$

Y en este pool se crea el dataset que contiene /var/lib/libvirt

vcarceler@edoras:~$ zfs list
NAME           USED  AVAIL  REFER  MOUNTPOINT
DATA          1,93T  1,58T    96K  none
DATA/libvirt  1,93T  1,58T  1,79T  /var/lib/libvirt
vcarceler@edoras:~$

ZFS aporta muchísimas ventajas a Edoras entre las que podemos citar:

• Integridad de los datos: Cada bloque se guarda con un checksum, se comprueban los datos en cada operación de lectura y también de forma periódica. La memoria ECC mantiene la integridad de los datos en RAM.
• Tolerancia a fallos: El mirrror de Edoras tolera la pérdida de uno de sus discos.
• Rendimiento: La cache ARC, los dispositivos SLOG (aunque con una configuración en la que todo es SSD se notan menos) y la compresión LZ4 logran una gran eficiencia. Rohan mantenía además una cache L2ARC en una partición de los discos SSD del sistema operativo, pero en Edoras al ser todo el almacenamiento SSD ya no es necesaria.
• Gestionable: Los snapshots atómicos en los que se basan las copias de seguridad de las MVs y el envío eficiente de snapshots a otra máquina permiten los backups periódicos de las MVs, que son grandes, de una manera muy sencilla y eficiente.

Únicamente por fijarnos en la eficiencia en cuanto a la utilización del espacio de almacenamiento podemos listar el tamaño de las imágenes de disco de las máquinas virtuales y el espacio consumido en disco. Efectivamente la diferencia entre el tamaño de la imagen y el espacio consumido en disco corresponde sobre todo a que se trata de ficheros dispersos pero también a que está activada la compresión transparente con LZ4.

Copias de seguridad

Realizar las copias de seguridad de unas imágenes que suman 3293 GiB con cierta frecuencia plantea cuestiones:

• Espacio consumido por cada copia.
• Tiempo necesario para realizar la copia.
• Tiempo necesario para llevar la copia a otro lugar.

En el caso de Edoras todo el proceso de copias de seguridad comienza con las capacidades de ZFS, los snapshots atómicos y la capacidad de enviarlos de manera eficiente por la red.

El esquema de backup es:

1. Se guarda el estado de las MVs con virsh managed save.
2. Se toma una instantánea del dataset que las contiene (y en el que se han copiado la definición de las máquinas que está en /etc/libvirt/qemu).
3. Se vuelven a encender las MVs.
4. Se enciende mediante Wake on LAN el servidor que ha de recibir el nuevo snapshot.
5. Se utiliza zfs send y SSH para enviar el snapshot de manera incremental a otro servidor (en nuestro caso Gondolin que únicamente está encendido durante la recepción del snapshot).
6. Se apaga el servidor remoto y, si hay más de 20 snapshots en la máquina, se borran los antiguos.
7. Se realiza un backup off-site.

Se inicia una copia de seguridad cada viernes a las 5:00. Los datos de la última copia de seguridad han sido:

Snapshots

Una vez que se ha guardado el estado de las máquinas es posible realizar un nuevo snapshot. El script que realiza las copias de seguridad utiliza como nombre del snapshot la fecha en la que se realiza y mantiene los últimos 20 snapshots. Si hay alguno más antiguo lo elimina.

En el tiempo que Edoras ha estado en producción se han llegado a realizar 9 snapshots:

vcarceler@edoras:~$ zfs list -t all
NAME                               USED  AVAIL  REFER  MOUNTPOINT
DATA                              1,97T  1,54T    96K  none
DATA/libvirt                      1,97T  1,54T  1,81T  /var/lib/libvirt
DATA/libvirt@inicial              16,7G      -  1,77T  -
DATA/libvirt@2019-12-09_10:06:01  12,6G      -  1,79T  -
DATA/libvirt@2019-12-13_05:00:01  11,8G      -  1,79T  -
DATA/libvirt@2019-12-20_05:00:01  12,6G      -  1,79T  -
DATA/libvirt@2019-12-27_05:00:01  13,5G      -  1,79T  -
DATA/libvirt@2020-01-03_05:00:01  12,9G      -  1,80T  -
DATA/libvirt@2020-01-10_05:00:01  11,4G      -  1,80T  -
DATA/libvirt@2020-01-17_05:00:01  12,0G      -  1,80T  -
DATA/libvirt@2020-01-24_05:00:01  11,0G      -  1,80T  -
vcarceler@edoras:~$ 

Se puede comprobar que el dataset DATA/libvirt prácticamente utiliza 2TiB (1.93TiB) y que cada snapshot (los snapshots tienen una @ en el nombre) referencia cerca de 2TiB pues contiene las imágenes (unos 1.8TiB), el estado guardado de la RAM de la máquinas (unos 6GiB) y sus ficheros de definición .xml (unos pocos KBs) tal y como estaban cuando se tomó la instantánea.

Pero afortunadamente ZFS solo almacena una vez los bloques que están referenciados por cualquier dataset. Así que todos los bloques comunes están si duplicar y por eso cada snapshot solo consume algo más de 10GiB de almacenamiento aunque referencie cerca de 2TiB.

Cada uno de los snapshots mantiene disponible todos los ficheros del dataset tal y como estaban cuando se tomó la instantánea. Así resulta muy sencillo y rápido recuperar el estado de cualquier máquina virtual.

vcarceler@edoras:/var/lib/libvirt/.zfs/snapshot/2020-01-24_05:00:01/images$ ll -lh
total 1,8T
drwx--x--x 2 vcarceler root   15 nov 16 11:22 ./
drwxr-xr-x 7 root      root    7 ene 15 10:03 ../
-rw------- 1 root      root  21G ene 24 04:26 baba-yaga-1804-v2.img
-rw------- 1 root      root 8,0G ene 24 05:00 blog.img
-rw------- 1 root      root  25G ene 24 05:00 cirdan-1604.img
-rw------- 1 root      root  50G ene 24 05:00 elastix-2.5.img
-rw------- 1 root      root 251G ene 24 05:00 matrioska-1804.img
-rw------- 1 root      root 251G ene 24 05:00 matrioska.qcow2
-rw------- 1 root      root 251G ene 24 05:00 moodle-1804.img
-rw------- 1 root      root  51G ene 23 12:00 mp08-home.qcow2
-rw------- 1 root      root  11G ene 24 04:53 mp08.qcow2
-rw------- 1 root      root 2,0T ene 24 05:00 owncloud.img
-rw------- 1 root      root 250G ene 24 05:00 plone.img
-rw------- 1 root      root  51G ene 24 05:00 unifi-1804.img
-rw------- 1 root      root  25G ene 24 05:00 valinor.img
vcarceler@edoras:/var/lib/libvirt/.zfs/snapshot/2020-01-24_05:00:01/images$

Envío de snapshots

Pero no podemos considerar que hemos realizado una copia de seguridad hasta que no hemos llevado los datos a otra máquina, por eso Edoras envía una petición Wake-on-LAN a Gondolin y cuando ha arrancado transmite el nuevo snapshot utilizando zfs send y zfs receive en una conexión ssh.

Se puede comprobar que se han recibido todos los snapshots:

vcarceler@gondolin:~$ zfs list -t all
NAME                                 USED  AVAIL  REFER  MOUNTPOINT
BACKUP                              1,95T  1,56T    96K  /BACKUP
BACKUP/libvirt                      1,95T  1,56T  1,80T  /var/lib/libvirt
BACKUP/libvirt@inicial              16,7G      -  1,77T  -
BACKUP/libvirt@2019-12-09_10:06:01  12,6G      -  1,79T  -
BACKUP/libvirt@2019-12-13_05:00:01  11,8G      -  1,79T  -
BACKUP/libvirt@2019-12-20_05:00:01  12,6G      -  1,79T  -
BACKUP/libvirt@2019-12-27_05:00:01  13,5G      -  1,79T  -
BACKUP/libvirt@2020-01-03_05:00:01  12,9G      -  1,80T  -
BACKUP/libvirt@2020-01-10_05:00:01  11,4G      -  1,80T  -
BACKUP/libvirt@2020-01-17_05:00:01  12,0G      -  1,80T  -
BACKUP/libvirt@2020-01-24_05:00:01     0B      -  1,80T  -
vcarceler@gondolin:~$

El snapshot más reciente en Gondolin no consume ni 1 byte porque el dataset BACKUP/libvirt no ha sido modificado, pues en Gondolin se almacenan los snapshots pero no se ejecutan las máquinas virtuales.

Afortunadamente zfs puede transmitir un nuevo snapshot enviando únicamente los datos que faltan en el destino (es decir, de manera diferencial a partir del snapshot anterior). Esta es la razón por la que utilizando una LAN gigabit se puede transmitir en unos 10 minutos un snapshot que referencia aproximadamente 1.8TiB. Teniendo en cuenta además que Gondolin tiene un par de discos duros convencionales (no SSD).

En cada snapshot se puede acceder a los ficheros tal y como estaban cuando se tomó para poder recuperar cualquier MV rápidamente.

vcarceler@gondolin:/var/lib/libvirt/.zfs/snapshot/2020-01-24_05:00:01/images$ ll -lh
total 1,8T
drwx--x--x 2 vcarceler root   15 nov 16 11:22 ./
drwxr-xr-x 7 root      root    7 ene 15 10:03 ../
-rw------- 1 root      root  21G ene 24 04:26 baba-yaga-1804-v2.img
-rw------- 1 root      root 8,0G ene 24 05:00 blog.img
-rw------- 1 root      root  25G ene 24 05:00 cirdan-1604.img
-rw------- 1 root      root  50G ene 24 05:00 elastix-2.5.img
-rw------- 1 root      root 251G ene 24 05:00 matrioska-1804.img
-rw------- 1 root      root 251G ene 24 05:00 matrioska.qcow2
-rw------- 1 root      root 251G ene 24 05:00 moodle-1804.img
-rw------- 1 root      root  51G ene 23 12:00 mp08-home.qcow2
-rw------- 1 root      root  11G ene 24 04:53 mp08.qcow2
-rw------- 1 root      root 2,0T ene 24 05:00 owncloud.img
-rw------- 1 root      root 250G ene 24 05:00 plone.img
-rw------- 1 root      root  51G ene 24 05:00 unifi-1804.img
-rw------- 1 root      root  25G ene 24 05:00 valinor.img
vcarceler@gondolin:/var/lib/libvirt/.zfs/snapshot/2020-01-24_05:00:01/images$

Backup off-site

En el 2020 hacer backups offsite es sinónimo de subir los backups a algún proveedor de la nube. Hay muchos y muy variados —rclone sirve como cliente para muchos de ellos— pero que permitan subir 2TiB por backup sin incurrir en costos ya hay menos, en nuestro caso nos queda Google con su Drive de capacidad ilimitada en la edición educativa de las Google Apps.

Así que ya declaro desde el principio que estamos utilizando Google Drive porque es gratuito y lo tenemos a nuestra disposición, no porque sea la mejor opción.

Los servicios que permiten almacenar ficheros en la nube son parecidos a un disco duro remoto pero solo en el aspecto de que pueden guardar ficheros que después se recuperan. A estos servicios se accede con una interfaz web, una api, un cliente propio o un cliente políglota como rclone. En muchos de ellos incluso es posible montar el espacio de almacenamiento localmente, pero incluso en ese caso no debe perderse de vista una diferencia fundamental con un disco duro local o un sistema de ficheros en red tradicional.

Todos estos servicios permiten subir ficheros, eliminar ficheros y descargar ficheros. Pero no permiten sobreescribir unos pocos bytes de un fichero con datos nuevos, es necesario volverlo a subir.

Así que las aplicaciones de backup (restic, Borg) que pretenden modificar datos en el backup a priori no son una buena opción.

Además Google impone ciertos límites a su servicio:

• Tamaño máximo de un archivo: 5TB. No es un problema para nosotros, además si se quiere superar se puede fraccionar el archivo.
• Límite máximo de 750GB subidos por día. Esto nos limita la velocidad a la que podemos subir datos (unos 8.68MB/s) pues si se supera el límite se deniega la subida de los siguientes ficheros.

Con estos mimbres no se puede hacer más que este cesto:

• Comprimir los datos antes de transmitirlos.
• Utilizar un formato de archivo o imagen para subir 1 solo fichero para todos los discos duros en lugar de un fichero por disco duro.

Y es aquí donde hay que introducir Zstandard, un moderno algoritmo de compresión sin pérdida diseñado por Yann Collet —también autor del ultra veloz LZ4— que tiene la virtud de conseguir un asombroso ratio de compresión con muy poco uso de CPU. Además la herramienta pzstd implementa la versión paralela que utiliza varios núcleos para aumentar el rendimiento.

Como formato de archivo se utiliza el venerable tar que cumple a la perfección la función de archivar todas las imágenes en un solo fichero para que, aunque nos saltemos el límite de subida diaria de Drive, Google nos permita acabar de subir nuestro backup. Otra opción que se debe estudiar sería realizar una imagen SquashFS en lugar de un tarchivo tar de este modo podría agilizarse la recuperación de una máquina virtual.

Así Edoras acaba utilizando algo similir a la siguiente sentencia para subir las imágenes de disco a Drive. Eso sí, todo se ejecuta como un trabajo nice -n 19 para no robar CPU a otras tareas.

tar cf - $NEW_SNAPSHOT_DIR/images | pzstd -10 -c -p 4 | rclone rcat backup-drive:edoras-backup/$DATE_TIME/images.tar.zst --syslog

En Edoras rcloneademás utiliza otras opciones:

• --drive-impersonate. Para indicar la cuenta Gmail a utilizar.
• --config. Para indicare el fichero de configuración a utilizar.
• --syslog. Para que se utilice el log del sistema.
• --retries-sleep. Para indicar el tiempo de espera antes de un reintento tras un error.
• --tpslimit. Para limitar el número de transacciones por segundo (5).

Finalmente este es el aspecto de la subida del último backup a Drive (tráfico enviado los días 24 y 25) y podemos comprobar la interfaz web con nuestros datos.

Más información:

• SAI Back-UPS de APC 1400 VA: especificaciones y guía de usuario.