Servidor dedicado y backups off-site

Históricamente todos los servicios del centro se han estado ejecutando en el propio instituto. Edoras es la máquina que estaba ejecutando en producción todos los servicios virtualizados incluyendo web, blog y moodle. Además de otras MVs dedicadas a infraestructura.

Tener al alcance la máquina física en la que se ejecuta la infraestructura permite el máximo control y que los servicios estén en la propia LAN del centro permite acceder a ellos desde las aulas con el mayor rendimiento posible. Además, quizás, tenga cierto peso emocional conocer los detalles de esta instalación. Los inconvenientes son los cortes en el suministro eléctrico, los camiones que nos rompen las fibras del centro o cualquier otro detalle práctico que interfiera con la función de nuestro servidor.

Todo esto se puede complicar en el caso de que sea difícil acceder al instituto y de que los alumnos y profesores no puedan utilizar el servidor Moodle o la web.

Por estas razones recientemente se ha contratado un servidor dedicado en un centro de datos en el que poder ejecutar la web del centro, el servidor moodle y el blog.

Características del servidor dedicado

La función del servidor dedicado es ser un host KVM/libvirt en el que se ejecutan servicios virtualizados. El proveedor proporciona la instalación del sistema operativo Ubuntu 18.04 LTS y nosotros administramos la máquina mediante SSH.

El sistema operativo está instalado en los dos discos SATA utilizando RAID1. En estos discos también están la partición del sistema EFI, una partición para /boot, una partición para la raíz, la partición swap y una partición con el espacio libre para un pool zfs.

Así el particionado de los discos HDD tiene la siguiente estructura:

Hay que hacer notar que el esquema de sistema operativo sobre RAID1 es una de las opciones del proveedor y determina las 4 primeras particiones de estos discos. La última partición se ha creado de manera manual.

Las particiones swap no tienen redundancia así que la máquina cuenta con 8GiB de swap.

Los discos SSD no tienen ninguna partición predefinida y se han utilizado como componentes del zpool FAST.

Se pueden seguir el funcionamiento del servidor en: http://ovh.elpuig.xeill.net/

Dos pools zfs: FAST y SLOW

El rendimiento de los discos mecánicos y de los discos de estado sólido es muy diferente. Por esto se han utilizado las dos particiones con el espacio libre de los discos mecánicos en el pool zfs SLOW. Y se han utilizado los dos discos de estado sólido como componentes del pool zfs FAST. En ambos casos se utiliza un espejo para conseguir redundancia y tolerancia a la avería de uno de los discos del pool.

Así los pools zfs de la máquina son:

root@ns3084654:~# zpool list
NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
FAST   416G   197G   219G         -    33%    47%  1.00x  ONLINE  -
SLOW  1,70T   200G  1,51T         -     0%    11%  1.00x  ONLINE  -
root@ns3084654:~#

Y ambos están compuestos por un mirror con dos miembros:

root@ns3084654:~# zpool status
  pool: FAST
 state: ONLINE
  scan: scrub repaired 0B in 0h9m with 0 errors on Sun Jun 14 00:33:27 2020
config:

	NAME                                             STATE     READ WRITE CKSUM
	FAST                                             ONLINE       0     0     0
	  mirror-0                                       ONLINE       0     0     0
	    nvme-INTEL_SSDPE2MX450G7_BTPF80720DGJ450RGN  ONLINE       0     0     0
	    nvme-INTEL_SSDPE2MX450G7_BTPF8325026R450RGN  ONLINE       0     0     0

errors: No known data errors

  pool: SLOW
 state: ONLINE
  scan: scrub repaired 0B in 0h20m with 0 errors on Sun Jun 14 00:44:54 2020
config:

	NAME                                               STATE     READ WRITE CKSUM
	SLOW                                               ONLINE       0     0     0
	  mirror-0                                         ONLINE       0     0     0
	    ata-HGST_HUS724020ALA640_PN1134P6H7YA1N-part5  ONLINE       0     0     0
	    ata-HGST_HUS724020ALA640_PN2186P2G3B66J-part5  ONLINE       0     0     0

errors: No known data errors
root@ns3084654:~#

Se pueden leer detalles sobre el rendimiento de estos dispositivos en el artículo: Notas sobre el rendimiento de disco de un servidor.

En cuanto a la función de estos pools tenemos:

1. FAST contendrá el dataset FAST/libvirt que se encuentra montado en /var/lib/libvirt y almacena las máquinas virtuales.
2. SLOW servirá como espacio de backup, replicando los snapshots de FAST/libvirt en SLOW/backup-libvirt.

Así los datasets utilizados son:

root@ns3084654:~# zfs list
NAME                  USED  AVAIL  REFER  MOUNTPOINT
FAST                  197G   206G    96K  none
FAST/libvirt          197G   206G   159G  /var/lib/libvirt
SLOW                  200G  1,45T    96K  none
SLOW/backup-libvirt   197G  1,45T   161G  /opt/backup-libvirt
SLOW/cosas           3,65G  1,45T  3,65G  /opt/cosas
root@ns3084654:~#

Copias de seguridad

Está muy bien que las cosas funcionen pero aún es mejor tener una copia de seguridad reciente cuando sea necesario. Así que conviene hacer copias de seguridad de manera regular, guardando estas copias en algún otro sitio que no sea la misma máquina que se está respaldando.

En este caso hemos vuelvo a aplicar el mismo esquema de backups que en el servidor del centro. Es decir:

1. Se utiliza virsh managedsave <MV> para guardar el estado de cada una de las máquinas.
2. Se crea un nuevo snapshot de FAST/libvirt.
3. Se utiliza virsh start <MV> para restaurar cada una de las máquinas.
4. Se replica el snapshot de FAST/libvirt en SLOW/backup-libvirt.
5. Se borran los snapshots antiguos que excedan el número de snapshots que queremos conservar.
6. Se realiza un backup off-site con rclone a Drive.

Todo ello controlado por un script que se lanza desde crontab.

Un listado de los datasets incluyendo los snapshots tiene el siguiente aspecto:

root@ns3084654:~# zfs list -t all
NAME                                      USED  AVAIL  REFER  MOUNTPOINT
FAST                                      197G   206G    96K  none
FAST/libvirt                              197G   206G   159G  /var/lib/libvirt
FAST/libvirt@inicial                     4,45G      -   180G  -
FAST/libvirt@2020-07-04_23:56:27         2,51G      -   182G  -
FAST/libvirt@2020-07-05_00:10:37         2,51G      -   182G  -
FAST/libvirt@2020-07-06_16:22:06         2,23G      -   160G  -
FAST/libvirt@2020-07-07_05:00:01         2,84G      -   161G  -
SLOW                                      200G  1,45T    96K  none
SLOW/backup-libvirt                       197G  1,45T   161G  /opt/backup-libvirt
SLOW/backup-libvirt@inicial              4,45G      -   180G  -
SLOW/backup-libvirt@2020-07-04_23:56:27  2,51G      -   182G  -
SLOW/backup-libvirt@2020-07-05_00:10:37  2,51G      -   182G  -
SLOW/backup-libvirt@2020-07-06_16:22:06  2,23G      -   160G  -
SLOW/backup-libvirt@2020-07-07_05:00:01     0B      -   161G  -
SLOW/cosas                               3,65G  1,45T  3,65G  /opt/cosas
root@ns3084654:~#

Y una traza de la ejecución automática del proceso de backup queda así:

root@ns3084654:~# cat /var/log/syslog | grep backup
Jul  7 05:00:01 ns3084654 CRON[19169]: (root) CMD (/root/bin/backup)
Jul  7 05:00:01 ns3084654 backup: Start backup
Jul  7 05:00:01 ns3084654 backup: DOMAINS=moodle-1804#012plone5
Jul  7 05:00:01 ns3084654 backup: BASE_SNAPSHOT=FAST/libvirt@2020-07-06_16:22:06
Jul  7 05:00:01 ns3084654 backup: SRC_DATASET=FAST/libvirt
Jul  7 05:00:01 ns3084654 backup: DST_DATASET=SLOW/backup-libvirt
Jul  7 05:00:01 ns3084654 backup: DATE_TIME=2020-07-07_05:00:01
Jul  7 05:00:01 ns3084654 backup: NEW_SNAPSHOT=FAST/libvirt@2020-07-07_05:00:01
Jul  7 05:00:01 ns3084654 backup: MAX_SNAPSHOTS=20
Jul  7 05:00:01 ns3084654 backup: NEW_SNAPSHOT_DIR=/var/lib/libvirt/.zfs/snapshot/2020-07-07_05:00:01
Jul  7 05:00:01 ns3084654 backup: Copy .xml domain files to /var/lib/libvirt/backup-domains
Jul  7 05:00:01 ns3084654 backup: Ok
Jul  7 05:00:01 ns3084654 backup: Saving VMs:
Jul  7 05:00:01 ns3084654 backup:  Saving: moodle-1804
Jul  7 05:00:04 ns3084654 backup:  Saving: plone5
Jul  7 05:00:08 ns3084654 backup: All VMs saved.
Jul  7 05:00:08 ns3084654 backup: Creating snapshot FAST/libvirt@2020-07-07_05:00:01
Jul  7 05:00:08 ns3084654 backup: Created new snapshot: FAST/libvirt@2020-07-07_05:00:01
Jul  7 05:00:08 ns3084654 backup: Restoring VMs:
Jul  7 05:00:08 ns3084654 backup:  Restoring: moodle-1804
Jul  7 05:00:10 ns3084654 backup:  Restoring: plone5
Jul  7 05:00:14 ns3084654 backup: All VMs restored.
Jul  7 05:00:14 ns3084654 backup: Start zfs send to Gondolin
Jul  7 05:00:14 ns3084654 backup: BASE_SNAPSHOT=FAST/libvirt@2020-07-06_16:22:06 NEW_SNAPSHOT=FAST/libvirt@2020-07-07_05:00:01
Jul  7 05:01:09 ns3084654 backup: zfs send completed
Jul  7 05:01:09 ns3084654 backup: Starts backup off-site with rclone
Jul  7 05:01:09 ns3084654 backup: Starts rclone blog.xml
Jul  7 05:01:15 ns3084654 backup: blog.xml rcloned
Jul  7 05:01:15 ns3084654 backup: Starts rclone moodle-1804.xml
Jul  7 05:01:18 ns3084654 backup: moodle-1804.xml rcloned
Jul  7 05:01:18 ns3084654 backup: Starts rclone plone5.xml
Jul  7 05:01:21 ns3084654 backup: plone5.xml rcloned
Jul  7 05:01:21 ns3084654 backup: Starts rclone moodle-1804.save.zst
Jul  7 05:02:20 ns3084654 backup: moodle-1804.save.zst rcloned
Jul  7 05:02:20 ns3084654 backup: Starts rclone plone5.save.zst
Jul  7 05:05:33 ns3084654 backup: plone5.save.zst rcloned
Jul  7 05:05:33 ns3084654 backup: Starts rclone tar /var/lib/libvirt/.zfs/snapshot/2020-07-07_05:00:01/images
Jul  7 06:12:07 ns3084654 backup: tar /var/lib/libvirt/.zfs/snapshot/2020-07-07_05:00:01/images rcloned
Jul  7 06:12:07 ns3084654 backup: Backup off-site ended
Jul  7 06:12:07 ns3084654 backup: End backup
root@ns3084654:~#

Aquí se puede comprobar:

• Se han empleado 8 segundos en guardar el estado de las máquinas virtuales.
• La interrupción de servicio durante el backup es de 14 segundos.
• Replicar el snapshot de FAST/libvirt a SLOW/backup-libvirt lleva menos de un minuto.
• Realizar el backup off-site lleva algo más de 1h.

En esta ocasión el archivo .tar.zstd con las imágenes de las MVs ha llegado a los 134GiB.