Llegamos al final de esta serie de artículos sobre DRBD, y para esta última entrada teníamos pendiente ver (muy por encima) la configuración final que se adoptó para llevar a cabo el desarrollo solicitado.
Volvemos a entrar en materia, siguiendo justo donde lo habíamos dejado: Explicar la configuración final.
Bajo las premisas que comentábamos en los artículos anteriores, sobre todo en la tercera parte, se configura pues el clúster, con ambos nodos. La máquina virtual se crea como recurso del clúster y se le asigna un nodo preferido (el nodo que está en la misma planta). De todos modos, si este nodo falla y la máquina se migra (failover), una vez que el nodo principal se restablezca, la máquina no se vuelve a migrar (failback), sino que se queda en el secundario. Esto se hace para evitar mover la máquina 2 veces cuando hay un fallo. Así se migraría en el fallo y, cuando no se esté trabajando, se volvería a migrar a mano para minimizar los daños.
Las particiones de configuraciones replicadas por DRBD y montadas en ambos servidores.
Las particiones de discos duros virtuales, replicadas por DRBD y montadas a la vez en ambos servidores (para esto es necesario el OCFS2, sino no se pueden montar simultáneamente).
Dicha partición presentada al Linux como dispositivo iSCSI con una IP fija.
En la configuración del clúster, además, se fuerzan ciertas reglas como son:
- Para montar las particiones DRBD, es necesario que previamente se haya montado el sistema de archivos de Linux y los servicios de red. Si no funciona uno de los dos, no se montan las particiones.
- Para crear el dispositivo iSCSI y asignarle la dirección IP, previamente se han tenido que montar las particiones DRBD. Si no se han podido montar, no se crea el recurso iSCSI.
- Para arrancar la máquina virtual, previamente se ha tenido que montar las particiones DRBD, el recurso iSCSI y la IP. Si no se han podido montar, no se puede arrancar la máquina virtual.
- La máquina virtual, si no está corriendo en ningún nodo, por defecto arranca en el nodo que está en la propia planta. Si ya se ha migrado al secundario por algún fallo, se queda en el secundario y no realiza “failback”.
Respecto a la configuración del DRBD, tenemos:
- El método de réplica requiere confirmación. Es decir, un dato no se da por escrito en el segundo nodo, hasta que no está confirmado.
- Un dispositivo DRBD por recurso (así se pueden parar o arrancar independientemente uno del otro) y por puerto diferente, para separar tráfico por puertos.
- Si un nodo se desconecta, permite la reconexión del nodo y su sincronización automática durante 5 minutos. Si en 5 minutos no ha habido re-sincronización de los discos, se dejan desconectados, para evitar pérdidas de datos. La re-sincronización se realizará manualmente para tener control absoluto sobre la operación. Se hará cuando no se esté trabajando, al igual que el migrar la máquina nuevamente al nodo principal.
Con esta configuración es posible tener un entorno virtualizado de alta disponibilidad y con tolerancia a fallos a un precio muy económico, teniendo además un buen rendimiento.
Espero que os hayan gustado los artículos y que veáis que se pueden realizar cosas muy interesantes con software libre, y que no tienen nada que envidiar a según qué sistemas comerciales. Evidentemente, no estamos hablando de una potencia y características de ESX, pero para según qué instalaciones tendremos más que suficiente.
Como siempre, si alguien tiene algún comentario o quiere ampliar información, estoy a vuestra disposición.
Saludos.
Post publicado por: Oscar Navarrete
SEAS es el centro de formación online del Grupo San Valero, especializado en el ámbito técnico, industrial y de empresa. Visita www.seas.es para consultar nuestra oferta formativa de cursos y másteres. Formación profesional para el empleo de calidad y accesible para todos.
