Saludos nuevamente.
En estos días he estado viendo en las estadísticas del blog que algunos están buscando documentación sobre uso de DRBD como almacenamiento compartido en Proxmox VE. Mi intención siempre fue hacer el artículo correspondiente, pero utilizando Proxmox VE 4.0 porque consideré en su momento que no tenía sentido subir el que ya tenía porque la tendencia es migrar hacia la última versión.
No obstante, por la cantidad de búsquedas que he visto, he decidido desempolvar el mamotreto donde tengo impreso mi Manual de Proxmox VE 3.2 (en una carpeta amarilla guardada en casa) para agregar el artículo de cómo configurar un almacenamiento compartido con DRBD 8 (8.3 para ser exactos) en Proxmox VE.
Quiero añadir que esta parte fue el resultado de una ayuda que le di a un amigo porque tenía sendos servidores DELL PE T420 y quería sacarle el máximo provecho. Se me ocurrió hacer un pequeño Clúster HA de Proxmox VE con dos nodos utilizando DRBD como almacenamiento compartido, idea que me sugirió otro amigo de Estonia: Ivan Ilves. Me llevó un tiempo leer todo lo referente a esto en la Wiki de Proxmox y artículos diseminados en Internet, hacer los experimentos correspondientes y llevar a la práctica todo aquello. Al final, mi amigo se fue para otros lares y todo aquello lo abandoné, pero me quedó el pequeño manual que hice, el cual pongo a disposición de ustedes.
NOTA: Tengo que censurar las imágenes porque contienen el dominio real de la institución.
Aquí les va:
(…)
Configuración básica del Clúster Proxmox VE 3.2
Ya instalados los dos nodos, y antes de poner el clúster a funcionar, hay que realizar algunos pasos previos.
Configuración de red
Antes de hacer cualquier cosa, lo primero es configurar las interfaces de red de los nodos. Según el diseño de red que se hizo, la gestión de los nodos se encuentra en la subred o VLAN 2 llamada “Gestión de Hipervisores”, la cual tiene el direccionamiento IP 10.0.1.16/28 donde los nodos tienen la dirección IP siguiente:
Primera tarjeta de red (Interfaz de Gestión) del nodo PRX-C0-1 —> 10.0.1.18/28
Primera tarjeta de red (Interfaz de Gestión) del nodo PRX-C0-2 —> 10.0.1.19/28
Ahora bien, como los servidores supuestamente vienen con la interfaz de gestión remota iDRAC, hay que proporcionarles una dirección IP:
Tarjeta iDRAC del nodo PRX-C0-1 —> 10.0.1.20/28
Tarjeta iDRAC del nodo PRX-C0-2 —> 10.0.1.21/28
Hasta aquí todo bien en parte, porque también hay que establecerle una dirección IP a la segunda tarjeta de red que va a funcionar como enlace para la sincronización del DRBD. Para ello basta con una pequeña subred de 2 equipos (o sea, un enlace punto a punto con un cable cruzado entre los nodos): 10.0.0.0/30.
Segunda tarjeta de red (Interfaz para el DRBD) del nodo PRX-C0-1 —> 10.0.0.1/30
Segunda tarjeta de red (Interfaz para el DRBD) del nodo PRX-C0-1 —> 10.0.0.2/30
En fin, la configuración de las interfaces de red en cada nodo es la siguiente:
Nodo PRX-C0-1
auto lo
iface lo inet loopback
iface eth0 inet manual
auto vmbr1
iface vmbr1 inet manual
bridge_ports eth0.1
bridge_stp off
bridge_fd 0
auto vmbr2
iface vmbr2 inet static
address 10.0.1.18
netmask 255.255.255.240
gateway 10.0.1.17
bridge_ports eth0.2
bridge_stp off
bridge_fd 0
auto vmbr3
iface vmbr3 inet manual
bridge_ports eth0.3
bridge_stp off
bridge_fd 0
auto vmbr4
iface vmbr4 inet manual
bridge_ports eth0.4
bridge_stp off
bridge_fd 0
auto vmbr5
iface vmbr5 inet manual
bridge_ports eth0.5
bridge_stp off
bridge_fd 0
auto vmbr6
iface vmbr6 inet manual
bridge_ports eth0.6
bridge_stp off
bridge_fd 0
auto eth1
iface eth1 inet static
address 10.0.0.1
netmask 255.255.255.252
network 10.0.0.0
broadcast 10.0.0.3
pointtopoint 10.0.0.2
Nodo PRX-C0-2
auto lo
iface lo inet loopback
iface eth0 inet manual
auto vmbr1
iface vmbr1 inet manual
bridge_ports eth0.1
bridge_stp off
bridge_fd 0
auto vmbr2
iface vmbr2 inet static
address 10.0.1.19
netmask 255.255.255.240
gateway 10.0.1.17
bridge_ports eth0.2
bridge_stp off
bridge_fd 0
auto vmbr3
iface vmbr3 inet manual
bridge_ports eth0.3
bridge_stp off
bridge_fd 0
auto vmbr4
iface vmbr4 inet manual
bridge_ports eth0.4
bridge_stp off
bridge_fd 0
auto vmbr5
iface vmbr5 inet manual
bridge_ports eth0.5
bridge_stp off
bridge_fd 0
auto vmbr6
iface vmbr6 inet manual
bridge_ports eth0.6
bridge_stp off
bridge_fd 0
auto eth1
iface eth1 inet static
address 10.0.0.2
netmask 255.255.255.252
network 10.0.0.0
broadcast 10.0.0.3
pointtopoint 10.0.0.1
Actualización del sistema operativo
Primero que todo, se debe actualizar el sistema operativo de los nodos. El Proxmox, al estar basado en Debian, trae por defecto las URLs de los repositorios de la misma más los de él mismo, pero desgraciadamente hay que pagar una suscripción para poder actualizar.
Algo que sucede con frecuencia es que, inicialmente, no se dispone de un repo en línea actualizado de Debian, por lo que una opción válida es tener uno local en alguna ubicación e ir actualizándolo mientras se pueda. En este caso, el repo está ubicado dentro de un disco duro externo USB y solamente hay que modificar los archivos de configuración del APT para que lea los paquetes desde esa ubicación adicional (Ver Anexo 1).
Para el caso del repo de Proxmox, para los pobrecitos como nosotros, queda la opción de crear un repo local basado en el CD de instalación cada vez que se emita una nueva versión.
Ejemplo:
Ubicación del repo de Debian:
/media/flash/debian-repo/debian
/media/flash/debian-repo/debian-backports
/media/flash/debian-repo/debian-multimedia
/media/flash/debian-repo/debian-security
/media/flash/debian-repo/debian-updates
Ubicación del repo de Proxmox:
/media/flash/proxmox-repo/pve-cd-repository
/media/flash/proxmox-repo/pve-test-repository
Según el ejemplo anterior, los archivos de fuentes del APT de los dos nodos se configuran así:
/etc/apt/sources.list:
deb file:///media/flash/debian-repo/debian wheezy main contrib non-free
deb file:///media/flash/debian-repo/debian-security wheezy/updates main contrib non-free
/etc/apt/source.list.d/pve-enterprise:
#deb https://enterprise.proxmox.com/debian wheezy pve-enterprise
deb file://media/flash/proxmox-repo/pve-cd-repository wheezy pve-cd
NOTA: Existen otros repositorios aparte del de pago, pve-no-suscription y pvetest (alias del primero), los cuales son para los usuarios que no tienen una suscripción comprada, pero dichos repositorios [según la documentación de Proxmox] contienen paquetes que no están profundamente probados, o sea, dichos paquetes son para ser sometidos a pruebas por la comunidad y, por lo tanto, NO recomiendan su uso en entornos de producción. No obstante, hasta el momento no han presentado problemas.
Entonces, la copia local de que se dispone también está en el disco duro externo, por lo cual se añadiría la siguiente línea en el archivo /etc/apt/sources.list.d/pve-enterprise:
deb file://media/flash/proxmox-repo/pve-test-repository wheezy pvetest
Una vez modificados los archivos del gestor de paquetes APT solamente queda actualizar el sistema. En los dos nodos se debe ejecutar el siguiente comando:
# apt-get update && apt-get upgrade -y
Y esperar pacientemente a que termine para luego reiniciar los dos nodos.
Visibilidad de los nodos
Primero que todo, los nodos deben ser “visibles” entre sí. Para ello hay que editar el archivo /etc/hosts en los dos nodos:
Nodo PRX-C0-1
127.0.0.1 localhost.localdomain localhost
10.0.1.18 prx-c0-1.red.dominio.cu prx-c0-1 pvelocalhost
10.0.1.19 prx-c0-2.red.dominio.cu prx-c0-2
10.0.1.20 prx-c0-1_idrac.red.dominio.cu prx-c0-1_idrac
10.0.1.21 prx-c0-2_idrac.red.dominio.cu prx-c0-2_idrac
10.0.0.1 prx-c0-1.red.dominio.cu prx-c0-1
10.0.0.2 prx-c0-2.red.dominio.cu prx-c0-2
Nodo PRX-C0-2
127.0.0.1 localhost.localdomain localhost
10.0.1.19 prx-c0-2.red.dominio.cu prx-c0-2 pvelocalhost
10.0.1.18 prx-c0-1.red.dominio.cu prx-c0-1
10.0.1.21 prx-c0-2_idrac.red.dominio.cu prx-c0-2_idrac
10.0.1.20 prx-c0-1_idrac.red.dominio.cu prx-c0-1_idrac
10.0.0.2 prx-c0-2.red.dominio.cu prx-c0-2
10.0.0.1 prx-c0-1.red.dominio.cu prx-c0-1
Luego probar el PING entre los nodos tanto por el nombre FQDN como por el nombre NetBIOS. Si todo está bien, se pasa al siguiente paso.
Creación del clúster Proxmox
Ahora se procede a crear el clúster Proxmox con los dos nodos ya actualizados. Para ello en el primer nodo se ejecuta el comando siguiente:
root@prx-c0-1:# pvecm create cuba-pveclr
El cual dará como resultado la creación de clúster.
En este punto ya el clúster está creado y el primer nodo ya es miembro del mismo como se muestra en la imagen la salida del comando
root@prx-c0-1:# pvecm status
Ahora bien, se procede a añadir el segundo nodo al clúster, para ello en dicho nodo se debe ejecutar el siguiente comando:
root@prx-c0-2:# pvecm add prx-c0-1
Esto lo que hace por debajo es añadir la llave pública SSH del primer nodo al segundo nodo para luego establecer una autenticación basada en claves públicas entre los nodos. O sea:
Se acepta la clave pública del primer nodo para luego proporcionar la clave de root del mismo. Una vez hecho esto se obtiene este resultado:
Claro está que esto es posible porque entre las líneas del archivo de configuración del SSH ubicado en /etc/ssh/sshd_config están estas dos:
Port 22
PermitRootLogin yes
NOTA: Normalmente muchos administradores cambian el valor de estos parámetros (yo, por ejemplo, le establezco el valor 40497 al puerto y deniego el acceso mediante el root, o sea, me autentico con un usuario restringido para luego autenticar con root), pero esto afectaría la comunicación entre los Proxmoxes, así que, por el momento, se debe dejar tal y como vienen por defecto. No obstante, después veré cómo tunear el SSH para llevarlo al estado deseado sin afectar la comunicación entre los nodos.
Para verificar que el segundo nodo está incluido como miembro del clúster se ejecuta el siguiente comando:
root@prx-c0-2:# pvecm status
Como se puede ver, el clúster ya muestra que tiene dos nodos y cada uno tiene un voto.
NOTA: El nodo que se vaya a incluir en un clúster Proxmox tiene que ser un nodo virgen, o sea, no debe tener creadas máquinas virtuales, en caso contrario dará un error y no se añadirá al mismo.
Una vez que el clúster está activo, el directorio /etc/pve se sincroniza entre los nodos miembros. En otras palabras, cualquier archivo que se cree o modifique dentro de este directorio en uno de los nodos se replicará en el otro automáticamente.
Preparación de los discos duros
Este es un paso importante antes de la creación del(los) almacenamiento(s) compartido(s) entre los nodos miembros del clúster.
En este caso se dispone de un disco Seagate Barracuda de 500 GB, 7.2K RPM, SATA II para crear el almacenamiento compartido entre los nodos. Basta con crear una partición que abarque todo el disco. No importa el tipo de sistema de archivos de la partición, normalmente se deja el mismo ext3.
La herramienta básica de particionado de disco en GNU/Linux es el fdisk. Para ver la tabla de particiones de un disco hay que ejecutar fdisk usando como parámetro el enlace simbólico del mismo, o sea:
root@prx-c0-1:# fdisk /dev/sdb
NOTA: Los tamaños de discos mostrados acá son ejemplos. En un disco de 500 GB el proceso tardará más tiempo.
Como se ve, el disco no está particionado. Entonces procedemos a crear la nueva partición de la siguiente manera:
Ya creada la partición hay que escribir los cambios en el disco duro para que el sistema operativo lo vuelva a leer, pero con la nueva tabla de particiones.
Para ver nuevamente la tabla de particiones hay que ejecutar el mismo comando anterior:
root@prx-c0-1:# fdisk /dev/sdb
Ahora el disco ya está particionado.
Este mismo procedimiento hay que realizarlo en el segundo nodo, y una vez completado ya estamos en condiciones de ir al siguiente paso.
Configuración del DRBD 8.3
Según la documentación en línea del proyecto acerca de un Clúster HA de Proxmox con dos nodos, el almacenamiento compartido que se recomienda es el DRBD, que no es más que un RAID 1 por red.
DRBD es una opción barata a las caras cabinas de almacenamiento como HP EVA, NetApp, IBM, etc. El modo de funcionamiento es muy sencillo, se necesitan dos servidores conectados mediante un enlace de red con un ancho de banda suficientemente grande para soportar la replicación de datos, o sea, o un enlace de 10 GBps mediante Ethernet o Canal de Fibra Óptica (como también puede usarse enlaces de tipo Infiniband, muy usados en proveedores de servicios en su conectividad interna o externa, el cual no es más que otro tipo de enlace de Fibra Óptica) o en su defecto un enlace agregado (bonding) de 2, 4 o 6 GBps para garantizar que no haya fallos ni ralentizaciones ni cuellos de botella durante la sincronización; el software DRBD versión 8.3 o superior y muuuuuuuuuuuuucha paciencia porque durante el proceso pueden ocurrir algunos problemas.
En este caso el enlace se realiza mediante un cable cruzado o directo conectado a la segunda tarjeta de red de los servidores.
Bueno, para ir entrando en materia, lo primero que hay que hacer es montar el paquete del DRBD en los dos nodos:
# apt-get update
# apt-get install drbd8-utils
Una vez instalado el paquete se procede a configurar el servicio DRBD. Los archivos de configuración son los siguientes:
/etc/drbd.conf
/etc/drbd.d/global_common.conf
/etc/drbd.d/*.res
Donde
- /etc/drbd.conf
Contiene solamente vínculos a los archivos ubicados dentro del directorio /etc/drbd.d.
- /etc/drbd.d/global_common.conf
Contiene las configuraciones globales del servicio DRBD como el tipo de protocolo a usar, acciones ante fallos de conectividad (recuperación ante la detección de un estado de Split-Brain), tasa de transferencia de sincronización, etc.
- /etc/drbd.d/*.res
Contiene los recursos y dispositivos DRBD que se utilizarán como dispositivos base de particiones, grupo de volúmenes lógicos u otros.
De estos tres archivos solamente modificaremos las configuraciones globales y los recursos DRBD. Eso sí, antes de modificarlos hay que hacer una copia de seguridad del archivo original.
Entonces, en el primer nodo se modifica los archivos antes mancionados:
Archivo /etc/drbd.d/global_common.conf:
global {
usage-count no;
}
common {
protocolo C;
startup {
wfc-timeout 0;
degr-wfc-timeout 60;
become-primary-on both;
}
net {
cram-hmac-alg sha1;
shared-secret “<Contraseña de autenticación>”;
allow-two-primaries;
# Configuracion para la situacion de “Split-Brain” (aqui se recomienda # usar o un cable cruzado entre los dos nodos DRBD, o un enlace
# agregado [bonding] contra un enlace trunking de un switch L2 en cada
# uno de los nodos; claro, si el switch es Gigabit Ethernet o 10
# Gigabit Ethernet, mejor)
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
}
syncer {
rate 132M;
verify-alg md5;
}
}
Para recurso o dispositivo DRBD se debe crear archivos .res por separado. En este caso se utiliza solamente uno y se nombra storage0.res.
Archivo /etc/drbd.d/storage0.res:
resource storage0 {
on prx-c0-1 {
device /dev/drbd0;
disk /dev/sdb1;
address 10.0.0.1:7788;
meta-disk internal;
}
on prx-c0-2 {
device /dev/drbd0;
disk /dev/sdb1;
address 10.0.0.2:7788;
meta-disk internal;
}
}
Luego copiar estos archivos al segundo nodo para tener la misma configuración en los dos nodos (además de que es la mejor opción para evitar errores humanos) mediante el comando:
root@prx-c0-1:# scp /etc/drbd.d/* root@10.0.1.19:/etc/drbd.d/
Iniciar el servicio en los dos nodos
# service drbd start
No asustarse con los errores que saldrán en pantalla después que el servicio inicia. Eso es normal porque la información de metadatos no está creada.
Esto se puede confirmar chequeando el estado del DRBD mediante el comando en uno de los nodos:
root@prx-c0-1:# service drbd status
Ahora hay que crear los metadatos en los dos nodos:
root@prx-c0-1:# drbdadm create-md storage0
root@prx-c0-2:# drbdadm create-md storage0
Para posteriormente levantar el recurso:
root@prx-c0-1:# drbdadm up storage0
root@prx-c0-2:# drbdadm up storage0
Reiniciamos el servicio en los dos nodos para que los cambios tengan efecto
root@prx-c0-1:# service drbd restart
root@prx-c0-2:# service drbd restart
Claro, habrá otros errores, de los cuales no debemos preocuparnos, pero ya el estado del servicio es diferente:
En este punto el servicio está activo, los nodos están conectados, pero sin sincronizar. Para sincronizar los dispositivos DRBD se debe ejecutar el comando siguiente en uno de los nodos:
root@prx-c0-1:# drbdadm — –overwrite-data-of-peer primary storage0
Y se puede ver el estado de la sincronización todo el tiempo (cada 1 segundo) de esta manera:
root@prx-c0-1:# watch –n 1 “service drbd status” > /dev/tty9 &
En lo particular, a mí me gusta más de la otra manera:
root@prx-c0-1:# watch –n 1 “cat /proc/drbd” > /dev/tty9 &
Y ponerlo en el archivo /etc/rc.local para que se ejecute automáticamente durante el momento del arranque del sistema.
Una vez sincronizados los discos, el estado del servicio se ve así:
Finalmente para lograr el estado Primary en ambos nodos, basta con reiniciar el servicio DRBD en el segundo nodo, o sea:
root@prx-c0-2:# service drbd restart
Y todo se verá así:
En este punto ya tenemos todo lo necesario para crear el almacenamiento compartido que utilizará Proxmox para guardar los discos de las máquinas virtuales.
Almacenamiento compartido en el Clúster Proxmox
El tipo de almacenamiento que se utilizará será LVM, pero para eso hay que realizar algunos pasos previos:
1.- Crear el volumen físico:
root@prx-c0-1:# pvscan
(…) VG pve lvm2 (…)
root@prx-c0-1:# pvcreate /dev/drbd0
Physical volume “/dev/drbd0” successfully created
root@prx-c0-1:# pvscan
(…) VG pve lvm2 (…)
(…) /dev/drbd0 lvm2 (…)
NOTA: Los tamaños de discos mostrados acá son ejemplos. En un disco de 500 GB el proceso tardará más tiempo.
2.- Crear grupo de volúmenes
root@prx-c0-1:# vgcreate storage0 /dev/drbd0
Volume group “storage0” successfully created
root@prx-c0-1:# vgscan
Todas las condiciones necesarias están completadas. El siguiente paso es añadir el grupo de volúmenes creado a la lista de almacenamientos del clúster. El proceso es el siguiente:
Proxmox —> Datacenter —> Pestaña “Storage” —> Add —> LVM
En la nueva ventana que aparece, se deben especificar los siguientes datos:
ID: storage0
Base storage: Existing volumen groups
Volume group: storage0
Enable: Checked
Shared: Checked
Completado este paso aparecerá en los dos nodos del clúster el nuevo almacenamiento compartido, como se ve en la imagen:
Este nuevo almacenamiento solamente contendrá los discos duros de las máquinas virtuales KVM en forma de volúmenes lógicos.
NOTA IMPORTANTE: Una vez que se crea el grupo de volúmenes y todo esté funcionando bien, puede darse el caso en que el nodo se reinicie inesperadamente (por causa de una fluctuación fuerte de voltaje, apagón, agotamiento de la batería, etc.), cuando esto pase, se debe realizar los pasos descritos en el epígrafe de la página «Asegurarse de que el dispositivo de bloques DRBD que soporta el LVM inicie en el momento del arranque«.
NOTA: Mientras se vayan probando los otros tipos de almacenamiento compartido que soporta Proxmox, se irán añadiendo como anexos. No obstante, el proceso de creación de máquinas virtuales KVM sobre cualquier tipo de almacenamiento compartido es siempre el mismo.
Máquinas virtuales sobre el almacenamiento compartido
Ahora se crearán las máquinas virtuales KVM donde en la opción “Hard Disk” en el parámetro “Storage:”, en vez de usar el almacenamiento local, se utilizará el nuevo almacenamiento compartido. Ah, esto trae como consecuencia que se deshabilita el parámetro “Format:” y se establece por defecto el valor “Raw disk image (raw)”.
En fin, esta es la secuencia de creación de una máquina virtual KVM con las nuevas condiciones:
Opciones Generales
Tipo de Sistema Operativo que tendrá la máquina virtual
Imagen de instalación
NOTA 1: El nombre del archivo de imagen de CD/DVD de instalación NO DEBE CONTENER ESPACIOS, debido a que el Proxmox “desaparece” el dispositivo automáticamente una vez que crea la máquina virtual, aunque también ocurre en el momento en que se desee añadir otra imagen para uso posterior y su nombre tenga el mismo problema. 🙂
NOTA 2: En caso que se desee montar sistemas operativos de Microsoft del tipo Windows 7/Server 2008R2 o Windows 8/Server 2012, en la documentación se recomienda que se utilice los drivers VirtIO proporcionados por Red Hat. Esto se hace creando un nuevo dispositivo de medios de CD/DVD y especificarle la imagen de dichos drivers. Hasta el momento en que se estaba redactando este manual, la versión del VirtIO era la 0.1-81 y el archivo es virtio-win-0.1-81.iso. Una vez iniciada la máquina virtual, se le debe especificar donde va a cargar los drivers que faltan. Se deben seleccionar todos (para los dispositivos de almacenamiento, modificaciones en la asignación de la memoria RAM y la interfaz de red).
Disco duro de la máquina virtual
Cantidad de núcleos que utilizará la máquina virtual
Memoria RAM que utilizará la máquina virtual
NOTA 3: Si se tiene un sistema operativo basado en Windows (7/2008R2 u 8/2012) y se desee utilizar los drivers VirtIO, se recomienda la segunda opción, o sea, “Automatically allocate memory within this range” y especificar el valor mínimo y máximo de memoria a utilizar.
Tarjeta de Red Virtual que se utilizará
NOTA 4: Volviendo al tema de los drivers VirtIO en Windows 7/2008R2 y 8/2012, se recomienda en este caso, escoger la opción VirtIO (paravirtualized).
Chequear y confirmar los datos proporcionados para luego proceder con la creación definitiva de la máquina virtual
En este punto ya tenemos nuestra primera máquina virtual sobre el almacenamiento compartido. Aunque hay que hacer un ajuste posterior, dado que, al tratar de encenderla, nos da el siguiente error:
Error: No accelerator found!
Dicho ajuste consiste en deshabilitar la opción “KVM hardware virtualization” ubicada en la pestaña “Options”:
NOTA 5: Para sistemas con Windows esta opción no se debe modificar este parámetro, dado que el Windows hospedero explotará con un “Pantallazo Azul de la Muerte de Windows” con la palabra “STOP” y varios códigos hexadecimales.
Confirmar que no se necesita aceleración para la máquina virtual con GNU/Linux…
Y ya. Completado esto, se procede a encenderla
La “imagen” de disco duro de la máquina virtual recién creada no es más que un nuevo volumen lógico ubicado en grupo de volúmenes anteriormente creado. Esto se puede ver en la siguiente lista:
Y también el tamaño que ocupa:
Una vez instalada la máquina virtual se pueden crear otras con sistemas operativos diferentes o clonar las ya existentes (que para mí es una buena opción para no perder tiempo en instalar nuevas). Poe ejemplo, para clonar una máquina virtual primeramente se selecciona la misma, luego dar clic derecho y pinchar la opción “Clone”. Esto mostrará una nueva ventana donde se deben especificar algunos valores, los cuales son:
Target node: <Nodo del clúster adonde se migrará la máquina virtual>
VM ID: <El ID de la máquina virtual a migrar>
Name: <Nombre que se le dará a la máquina virtual>
Mode: <Modo de clonación, se escoge “Full Clone” para tener una copia completa de la máquina virtual original>
Snapshot: current
Target Storage: <Almacenamiento destino donde se guardará la máquina virtual>
NOTA 7: Recalcar que todos estos cambios que se realizan sobre el almacenamiento compartido se replican en ambos nodos del clúster gracias al DRBD, lo cual hace que se muestre lo mismo en ambos nodos independientemente de donde se origine la tarea.
Ajustes posteriores en esta parte de la infraestructura
Hasta aquí hemos visto cómo crear un almacenamiento compartido con DBRD 8 y crear máquinas virtuales KVM (hasta el momento las únicas que se pueden crear directamente en el grupo de volúmenes LVM sobre el DRBD, para el caso de los contenedores hay que hacer algunas cosas a mano).
Ahora toca el turno de hacerle algunos pequeños ajustes (tunear) a esta parte de la infraestructura. Dichos cambios son dos:
1.- Asegurarse de que el dispositivo de bloques DRBD base para el LVM se cargue en el momento del arranque
Mientras se está trabajando con el almacenamiento compartido (que no es más que un grupo de volúmenes sobre un dispositivo DRBD ubicado en el segundo disco), puede suceder que el nodo se reinicie por cualquier causa (reinicio forzado o deseado).
Al reiniciar el nodo el DRBD falla al cargar porque el LVM no encuentra el dispositivo base (underlining device) del DRBD. Esto trae como consecuencia que el DRBD no inicie adecuadamente y se pierda la sincronización de os discos a pesar de haber conexión entre los nodos. Esto se ve de la siguiente manera:
root@prx-c0-2:# cat /proc/drbd
(…)
0:storage0 Connected Primary/Primary Diskless/UpToDate C
(…)
Aquí se puede ver que falta el disco o la parte del DRBD a sincronizar.
Para resolver este problema hay que ir al archivo /etc/lvm/lvm.conf en los dos nodos y donde aparece la línea
filter = [ “a/.*/” ]
modificarla con lo siguiente
filter = [ “r|/dev/sdb1|” , “r|/dev/disk/|” , “a/.*/” ]
y luego reiniciarlos para que el dispositivo DRBD inicie adecuadamente.
NOTA: En toda la documentación que he leído sobre DRBD y LVM/cLVM recalcan que este cambio es estrictamente obligatorio, dado que en la configuración por defecto de este último no está incluida la detección de este tipo de particiones sobre dispositivos DRBD ubicados en otros discos o soportes externos.
Ya reiniciados los nodos se puede ver que todo está OK:
2.- La situación del Split-Brain del DRBD
El Split-Brain es un estado en que se pierde la conexión entre los nodos a pesar de haber conectividad entre los mismos. Cada uno cree que el otro está fuera del servicio y actúan como entidades separadas. Para resolver este problema hay que definir quién es el nodo víctima y quien es el sobreviviente. Una vez escogidos los roles se procede a resolver el problema:
- Nodo sobreviviente
Ejecutar el comando:
# drbdadm — –overwrite-data-of-peer primary storage0
Y luego chequear el estado del DRBD:
# cat /proc/drbd
- Nodo víctima
Reiniciar el servicio:
# service drbd restart
Y hasta aquí el artículo. Créanme que me fue difícil extraerlo, jejejeje. Cualquier error que encuentren o duda que tengan, sin problema, coméntenlo en el blog.
Y me voy, que mi esposa me va a matar porque quedé con ella en una «tarea de choque» (no sean mal pensados, es una sopa bien cargada que quedé en hacerle y aún tengo parte de los ingredientes acá en la oficina).:-D
Espero les sirva. Chao. Nos vemos el lunes.
🙂
P.D.: Ah, se me olvidaba, a partir del lunes salgo de vacaciones por 9 días. Así que puede que publique pocos posts o ninguno. 🙂
