Una vez que instalamos el disco duro de 50GB en el servidor proxmox y lo añadimos como directorio al ‘storage’ del sistema restauramos las máquinas virtuales (nos referimos a containers y no a kvm en este post) a partir de los archivos de copia de seguridad. El lugar elegido para el almacenamiento de estas máquinas virtuales fue el nuevo disco de 50GB.

El uso del sistema en estas condiciones nos ha llevado a ver que no es posible hacer copias de seguridad de las máquinas virtuales empleando el sistema de ‘Snapshot’ puesto que éstas no están corriendo en un lvm. Habría que hacer un backup mediante ‘Suspend’ de la máquina virtual. Las diferencias pueden parecer no tan grandes, pues en el caso de la copia mediante ‘Suspend’ el tiempo de inactividad de la máquina virtual es muy bajo (no hay tiempo de inactividad en el caso de la copia mediante ‘Snapshot’). Sin embargo si que hay diferencia en el tiempo que lleva realizar la copia en ambos casos. Mientras que en el caso de copia por ‘Snapshot’ copiar una máquina virtual ha llevado 1 minuto y 12 segundos, la copia de esta misma máquina empleanto el sistema ‘Suspend’ ha llevado 14 minutos y 24 segundos!!!

Cambiando de estrategia

Creamos un nuevo disco virtual y lo añadimos al servidor proxmox, pero esta vez como lvm (ver parte 1 de esta entrada). Al tratar de instalar las máquinas virtuales en el nuevo storage el sistema nos indica que no es posible instalar el almacenamiento de las máquinas virtuales en un sistema de almacenamiento ‘lvm’.

Al final resulta que lo más práctico es tener un volumen lvm de pve-data lo suficientemente grande para albergar todas máquinas virtuales. Sin embargo queremos poder restaurar el sistema de manera sencilla en caso de necesidad como comentábamos en el primer artículo.

lvm al rescate

Al final la solución nos la dió lvm. Podemos mantener el disco con el sistema operativo en 10GB y simultáneamente tener una partición pve-data de más de 50GB gracias a lvm. La idea es añadir un disco duro con 50GB y agregarlo al volumen lvm pve-data, que es donde proxmox almacena los containers.

Para llevar a cabo la instalación seguimos las instrucciones del siguiente enlace:

Extending Local Container Storage

En resumen lo que hicimos fue lo siguiente:

Crear una partición de tipo Linux LVM en el nuevo disco (partición /dev/vdc1)

Crear un volumen físico en la nueva partición:

# pvcreate /dev/vdc1

Extender el Volume Group pve a la partición /dev/vdc1:

# vgextend "pve" /dev/vdc1

Redimensionar el volumen lvm pve-data:

# lvresize -l 14175 /dev/mapper/pve-data

El número que va detrás de -l es la suma de:

Current LE de pve-data, que se puede ver al hacer # lvdisplay /dev/mapper/pve-data

Free PE del nuevo volumen añadido (/dev/vdc1) que se puede ver al hacer # pvdisplay /dev/vdc1

Al final del lvresize el volumen pve-data queda de la siguiente forma:

# lvdisplay /dev/mapper/pve-data
--- Logical volume ---
LV Path                /dev/pve/data
LV Name                data
VG Name                pve
LV UUID                kVrFhy-IGkO-RMcd-xXN1-0GIY-CbwA-uwYcre
LV Write Access        read/write
LV Creation host, time proxmox, 2015-09-23 12:21:25 +0200
LV Status              available
# open                 1
LV Size                55.37 GiB
Current LE             14175
Segments               2
Allocation             inherit
Read ahead sectors     auto
- currently set to     256
Block device           253:2

Una vez redimensionado el volumen lógico hay que extender el sistema, lo que se hace con:

# resize2fs /dev/mapper/pve-data

El resultado (tarda bastante rato en finalizar el proceso) es:
resize2fs 1.42.5 (29-Jul-2012)
Filesystem at /dev/mapper/pve-data is mounted on /var/lib/vz; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 4
Performing an on-line resize of /dev/mapper/pve-data to 14515200 (4k) blocks.
The filesystem on /dev/mapper/pve-data is now 14515200 blocks long.

El resultado

Una imagen vale más que mil palabras. Aquí está el resultado:

Captura de pantalla 2015-09-28 a las 10.17.10

Se puede ver como el tamaño del almacenamiento local ha pasado de menos de 10GB a unos 55GB

Lo siguiente que tenemos que hacer es migrar las máquinas virtuales que teníamos instaladas en el HDD1_50GB hasta el almacenamiento local. El proceso está explicado en el siguiente enlace:

En caso de fallo

Qué ocurre en caso de fallo con esta estrategia?

Lo podemos ver en la figura 1.

IMG_5478

Figura 1

Actualmente el sistema está montado en un disco duro de 10GB al que se ha añadido otro de 50GB y éste se ha empleado para agrandar el volumen lvm pve-data.

Antes de añadir el disco de 50GB al volumen pve-data hemos hecho una copia del disco de 10GB con el sistema operativo (cectmox4_3.4_20150928.tgz) y la hemos puesto en el servidor node1, en el directorio dumpdir del NFS del cluster.

Las máquinas virtuales se copian en el directorio correspondiente del NFS para cectmox4 del node1.

Si ocurre el desastre

Recuperaríamos la máquina virtual con el proxmox a partir del archivo cectmox4_3.4_20150928.tgz, crearíamos un nuevo disco duro virtual de 50GB y lo añadiríamos tal y como se explica en este post.

Restauramos las máquinas virtuales desde el directorio de backup

A funcionar!!!


Artículo anterior

Artículo siguiente