PI Cluster Proxmox 2 nodos HA

IES Gran Capitán Departamento de Informática Ciclo Formativo de Grado Superior de Administración de Sistemas Informáticos

Módulo de Proyecto Integrado Fernando Velázquez Gómez - 2ºASIR Proyecto: Clúster de Proxmox (Júpiter- Calisto) Curso 2014/2015 Índice de contenido 1.- Introducción.....................................................................................................................................................................2 2.- Objetivos y requisitos del proyecto.................................................................................................................................2 3.- Estudio previo.................................................................................................................................................................2 3.1.- Estado actual...........................................................................................................................................................2 3.2.- Estudio de soluciones existentes.............................................................................................................................4 4.- Plan de trabajo.................................................................................................................................................................6 5.- Diseño..............................................................................................................................................................................6 5.1.- Diseño general........................................................................................................................................................6 5.2.- Diseño detallado.....................................................................................................................................................7 6.- Implantación....................................................................................................................................................................8 7.- Recursos........................................................................................................................................................................21 7.1.- Herramientas hardware.........................................................................................................................................21 7.2.- Herramientas software..........................................................................................................................................23 7.3.- Personal................................................................................................................................................................23 7.4.- Presupuesto...........................................................................................................................................................23 8.- Conclusiones.................................................................................................................................................................23 8.1.- Grado de consecución de objetivos......................................................................................................................23 8.2.- Problemas encontrados.........................................................................................................................................24 8.3.- Futuras mejoras.....................................................................................................................................................25 9.- Referencias / bibliografía..............................................................................................................................................25 10.- Anexos.........................................................................................................................................................................25

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

1.- Introducción Uno de los problemas a tener en cuenta en todo sistema informático, sobretodo de una cierta amplitud y capacidad de acceso, son las caídas en los servicios que ofrece a los usuarios del mismo. Estas caídas son provocadas por los puntos únicos de fallos y la falta de redundancia y de Alta Disponibilidad en el sistema. El presente proyecto se encargará de la configuración y montaje de un sistema de Alta Disponibilidad dentro del sistema informático del instituto y en específico entre los servidores Júpiter y Calisto.

2.- Objetivos y requisitos del proyecto Sistema de Alta Disponibilidad Proxmox entre los servidores Júpiter y Calisto: •

Implementación de un Clúster formado por los nodos servidores.

•

Estudio de los dispositivos de almacenamiento.

•

Implementación del sistema de Alta Disponibilidad.

3.- Estudio previo 3.1.- Estado actual

Actualmente el servidor Calisto y Jupiter se encuentran conectados exclusivamente mediante cableado Ethernet desde el DACE hasta el armario de comunicaciones del departamento. En el servidor Calisto podemos encontrar un Proxmox instalado donde se encuentra el proxy inverso del sistema, mientras que en Júpiter podemos encontrar otro Proxmox con el grueso de las máquinas virtuales usadas por los ciclos de informática del instituto incluyendo un servidor IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

MySQL, el servicio DNS del dominio gcap.net, así como los proyectos integrados.

El problema surge en la posibilidad de caída del servidor Júpiter, lo cual conllevaría un fallo en todos los accesos producidos a las máquinas virtuales y a los servicios proporcionados por dicho servidor.

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

3.2.- Estudio de soluciones existentes Clúster de Alta Disponibilidad de Proxmox Proxmox es una solución de virtualización basada en Debian, ya instalada en los servidores Júpiter y Calisto como gestor de máquinas virtuales, contenedores, redes virtualizadas y clústeres HA (precisamente lo que vamos a usar). DRBD Es un software de almacenamiento replicado distribuido Open Source. Asimismo se denomina de esta forma a los dispositivos de bloques lógicos diseñados para ofrecer clústers de Alta Disponibilidad. Esto se produce replicando un dispositivo de bloque entero a través de la red como si se tratase de un RAID 1 por red.

Principales características de la integración de DRBD en Proxmox VE: •

LVM encima de DRBD

•

Todos los discos VM (volúmenes LVM del dispositivo DRBD) pueden ser replicados en tiempo real en ambos nodos Proxmox a través de la red. Alternativamente, todo el almacenamiento VM puede ser replicado casi en tiempo real a muchos otros servidores de backup.

Modo de operar: DRBD estratifica capas de dispositivos de bloques lógicos sobre dispositivos de bloques IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

locales existentes en los clústers participantes. Las escrituras realizadas sobre el nodo primario son transferidas al dispositivo de bloques de bajo nivel y se propaga simultáneamente al nodo secundario. El nodo secundario transfiere entonces los datos a su dispositivo de bloques correspondiente. Todas las lecturas de entrada/salida se producen localmente.

Comparación con sistema de almacenamiento compartido VENTAJAS •

Los recursos de almacenamiento compartido son accedidos a través de una red, la cual se puede sobrecargar mediante peticiones de lectura I/O. En DRBD todas las operaciones de lectura se llevan a cabo localmente.

•

El almacenamiento compartido es generalmente caro y consumen más espacio y energía.

INCONVENIENTES •

En un sistema de almacenamiento compartido, el tiempo de escritura es menor que el enrutar la escritura entre nodos.

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

4.- Plan de trabajo 23/03/15-31/03/15

Búsqueda de información sobre la implementación de un clúster en Proxmox y documentación de la misma.

07/03/15-11/03/15

Implementación de RAID por software. Implementación del clúster entre los 2 nodos

12/03/15-16/03/15

Búsqueda de información sobre dispositivos de almacenamiento compartido y DRBD

06/03/15-15/05/15

Implementación de sistema DRBD

18/04/15-20/04/15

Implementación de sistema HA

22/04/15-24/04/15

Testeo del sistema y resolución de problemas

27/04/15-30/04/15

Finalización de la documentación

5.- Diseño 5.1.- Diseño general Diseño General del proceso a implementar en los servidores proporcionados para el proyecto:

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

5.2.- Diseño detallado Nodo Júpiter IP Anfitrión Proxmox: 192.168.12.6 Fencing device: HP iLO

Nodo Calisto IP Anfitrión Proxmox: 192.168.12.8 Fencing device: HP iLO

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

6.- Implantación Creación del clúster Júpiter-Calisto: Teniendo en cuenta que en ambos servidores ya se encuentra instalado una versión de Proxmox, abrimos sesión en uno de ellos y procedemos a crear el clúster:

Abrimos sesión en el otro servidor mediante ssh y lo añadimos al clúster:

Vemos como ahora el clúster tiene 2 nodos y el estado del mismo:

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

Y en la interfaz web, cada uno con su almacenamiento propio:

No nos olvidemos de modificar el /etc/hosts de cada servidor:

Implementación del sistema de almacenamiento replicado DRBD Para poder implementar DRBD entre los 2 servidores, vamos a usar un disco en cada servidor, el cual es el que realmente va a almacenar las Mvs y el almacenamiento local de los servidores se quedará para albergar imágenes de sistemas operativos y demás recursos.

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

Instalamos en ambos servidores la utilidad drbd:

Modificamos el archivo de configuración /etc/drbd.d/global_common.conf en ambos servidores:

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

Y creamos un nuevo recurso de configuración al que llamaremos r0.res con la siguiente configuración adicional (se incluye automáticamente en la configuración):

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

NOTA: data-integrity-alg se usa solo para testeo, para uso normal es recomendable deshabilitarlo, debido a su uso de CPU y a que puede dar falsos positivos de sincronización. En su lugar se usarán verificaciones periódicas online mensualmente o semanalmente. Para ello crearemos una tarea en el cron que se encargue de realizar las verificaciones:

Iniciamos el servicio DRBD en ambos servidores, creamos el dispositivo de metadatos:

Y levantamos el dispositivo en ambos nodos:

Si ahora observamos el estado del sistema DRBD, veremos que se encuentra listo para sincronización:

Comenzamos la sincronización entre los dos nodos (el siguiente comando sólo se ejecuta en uno de los nodos):

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

Una vez sincronizado:

Como sigue apareciendo un disco como primario y otro como secundario, reiniciamos el servicio en ambos nodos para que autoajuste ambos discos a primario:

A continuación configuraremos la LVM que va a ir encima del dispositivo drbd0, para ello nos vamos al archivo de configuración /etc/lvm/lvm.conf para cambiar los filtros y especificar que particiones de que discos debe usar para la lvm (en ambos nodos):

En uno de los nodos creamos el volumen físico y el grupo:

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

Ya sólo nos queda añadir el grupo LVM a través de la interfaz web de Proxmox:

Y empezar a crear máquinas virtuales:

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

Dichas imágenes se quedarán almacenadas en el disco compartido, por lo cual, al sincronizarse se encontrarán disponibles en ambos nodos:

Si tratamos de migrar una de las Mvs, veremos que la tarea se realiza muy rápidamente, gracias a que la imagen del mismo se encuentra ya en el otro nodo:

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

Podemos ver como los archivos de configuración de las Mvs se han migrado igualmente:

Implementación de HA en el clúster: El siguiente paso será el de habilitar el servicio de Alta disponibilidad dentro del clúster, para ello debemos irnos al archivo /etc/cluster/cluster.conf el cual tiene toda la configuración del mismo, pero no podemos editar directamente el archivo. Tenemos que copiar el archivo a uno nuevo llamado cluster.conf.new y realizar los cambios que queramos, siempre acordándonos de aumentar el número de versión cada vez que realicemos una edición del archivo:

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

Habilitamos el fencing en ambos nodos:

Y activamos todos los cambios hechos a través de la interfaz web:

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

Añadimos las Mvs que queremos estén gestionadas con HA:

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

Y levantamos los servicios de gestión del clúster en dichas Mvs:

Para probar que el sistema HA funciona, vamos a parar el servicio en el servidor calisto:

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

Como vemos funciona, puesto que ha migrado automáticamente la MV al otro servidor al detectar que el servicio se ha caído en el primer servidor. Probamos, por último, con un reinicio del servidor, si funciona correctamente, las Mvs se migrarán al servidor calisto:

Con esto ya tenemos nuestro sistema HA habilitado correctamente en nuestro clúster, junto con el sistema de almacenamiento compartido DRBD.

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

7.- Recursos 7.1.- Herramientas hardware -Servidor Júpiter (Real):

-Servidor Calisto (Real):

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

-Servidor Júpiter (Usado en simulación):

DD Local:

-Servidor Calisto (Usado en simulación):

DD Local:

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

DD DRBD (Alberga las MVS):

7.2.- Herramientas software -Proxmox 3.4.1 -Debian GNU/Linux 7.8.0 -DRBD8-utils

7.3.- Personal Toda la investigación, desarrollo e implementación han sido llevadas a cabo por: Fernando Velázquez Gómez

7.4.- Presupuesto Tareas

Horas

Coste

Coste+IVA(21%)

Investigación

20H

700,00 €

847,00 €

Implementación en local

25H

875,00 €

1.058,75 €

Resolución de Problemas

5H

175,00 €

211,75 €

Total

50H

1.750,00 €

2.117,50 €

8.- Conclusiones 8.1.- Grado de consecución de objetivos •

Implementación de un Clúster formado por los nodos servidores. TOTALMENTE TERMINADO IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

•

Estudio de los dispositivos de almacenamiento. Implementación sistema DRBD. TOTALMENTE TERMINADO

•

Implementación del sistema de Alta Disponibilidad. TOTALMENTE TERMINADO

8.2.- Problemas encontrados El primer problema ante el que me he encontrado ha sido que al tener que realizar el proyecto sin acceso al hardware donde se piensa implementar, he tenido que realizar toda la simulación del mismo mediante software. Esto implicaba la implementación de RAID por software en cada uno de los servidores que iba a usar para el proyecto. Sin embargo, Proxmox no resulta compatible con el raid por software. Para esta solución la propia página de documentación de Proxmox ofrece ayuda en páginas externas para la implementación por software. Dicha implementación conlleva la configuración del array de RAID mediante mdadm, el uso de comandos sgdisk para la gestión de particiones en vez de fdisk (Proxmox usa GPT en vez de DOS), configuración del GRUB, creación y volcado de datos en LVM, etc. Otro de los problemas encontrados a lo largo del proyecto y que puede producirse durante el funcionamiento del sistema es la probabilidad de que se produzca un caso de split-brain. Esto se produce cuando el canal de comunicación entre los dos nodos DRBD falla y ambos continúan de forma independiente. Cuando la comunicación se reestablece los dos nodos ya no tienen la misma información en sus volúmenes DRBD y por lo tanto, es obligatorio una resincronización. En una configuración dual-primary como la que se ha usado en la implementación con Proxmox, ambos nodos puede que tengan cambios realizados sobre el mismo recurso, por lo que es necesario descartar la información de uno de los nodos, el cual suele ser el nodo con menos actividad. La información del disco virtual en dicho nodo puede preservarse usando la interfaz web para migrar las Mvs al nodo del cual se quiere preservar la información. Esto conlleva el dejar fuera de servicio dichas Mvs mientras se copia la información completa del disco virtual al otro nodo. Se recomienda por ello, dejar siempre las Mvs de uso más “crítico” en uno de los dos nodos y usar el otro a modo de “entorno de desarrollo”. De forma alternativa es posible crear 2 volúmenes DRBD, uno con las Mvs que suelen correr habitualmente en el nodo A y otro con las habituales del nodo B. Un problema relacionado con el anterior que puede surgir, es que si se crean Mvs mientras uno de los servidores se encuentra caído, no se actualizará en el disco DRBD hasta que no se sincronice entre ambos nodos. En el caso de que el estado del servicio DRBD nos devuelva un valor de datos inconsistentes, habría que realizar un overwrite-data-of-peer como cuando se realizó la sincronización inicial. Otra solución es realizar una recuperación de split-brain, para lo cual abría que tener apagadas todas IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

las Mvs del nodo del que queremos descartar los datos, realizar un backup de las Mvs y restaurarlas en el otro nodo. Tras lo cual eliminarlas del nodo fallido y ejecutar una serie de comandos para resincronizar información con el nodo activo. En el nodo fallido:

En el nodo activo:

A partir de entonces se sincronizarán ambos nodos. Una vez acabada la sincronización, cambiar de nuevo el nodo caído a modo primario:

Y se podrán de nuevo, volver a migrar las Mvs al nodo que se encontraba fallido. En caso de usar 2 volúmenes DRBD en vez de 1, el proceso sería bastante similar. Por último, hacer saber que si un nodo se encuentra caído, no se podrá acceder a las Mvs del mismo, ni migrarlas, pero si se pueden copiar los archivos de configuración de las mismas desde /etc/pve/qemu-server, aunque se haría dándoles otro nombre.

8.3.- Futuras mejoras Se ha optado por la opción menos costosa para la implementación del sistema, obviamente si se quiere mejorar se deberían usar sistemas de almacenamiento SAN en vez del sistema DRBD usado y la implementación de un RAID más fiable que el usado en la simulación (RAID 1). Todo dependiendo del presupuesto del que se disponga.

9.- Referencias / bibliografía https://pve.proxmox.com/wiki/Two-Node_High_Availability_Cluster https://pve.proxmox.com/wiki/DRBD http://kbdone.com/proxmox-ve-3-2-software-raid/ http://drbd.linbit.com/

10.- Anexos Tutorial sobre como implementar RAID por Software en Proxmox: IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

PASO 1: Instalación y Setup Lo primero y principal es habilitar los discos que vamos a usar para el RAID, en mi caso he usado 2 discos de 50GB en cada una de las máquinas:

Tras instalar Proxmox en uno de los discos, procedemos a actualizar el sistema:

Y a instalar el software que vamos a usar para configurar el RAID:

PASO 2: Mover /boot y el grub a un raid 1 por software. Nuestra tabla de particiones debería de ser originalmente algo asi:

Identificamos cuales van a ser las particiones que vamos a usar para el RAID y las etiquetas de los discos, en mi caso /dev/sda y /dev/sdb. Las particiones van a ser la 2 y 3, ya que en la 1º se encuentra el grub del disco. A continuación vamos a usar una serie de comandos sgdisk, ya que Proxmox usa GPT en vez de MSDOS. Preparamos el 2º disco:

El primer comando copia la tabla de particiones de sda a sdb, mientras que los otros dos comandos modifican los tipos de partición de /deb/sdb2 y /dev/sdb3 a RAID en vez de boot/lvm. IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

Lo siguiente es crear el array de RAID con mdadm:

Nos aparecerá un mensaje de advertencia, el cual aceptamos:

Al final /dev/md0 va a contener /boot mientras que /dev/md1 almacenará la partición LVM. Para ello, formateamos /dev/md0 como ext3, copiamos el grub en él y lo colocamos como nuestro montaje de /boot:

Ahora sólo tenemos que arreglar el /etc/fstab para que monte /boot desde md0 en vez de desde /dev/sda2:

Reiniciamos, y si el sistema bootea correctamente es que lo hemos hecho bien, sino tendremos que volver a hacerlo desde el principio. Para verificar que todo va correcto una vez reiniciado, podemos ejecutar el siguiente comando:

Si nos devuelve como resultado que ha booteado desde md0 es que es correcto.

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

Lo siguiente es realizar una serie de cambios en el grub y reinstalarlo:

Al igual que hicimos con /dev/sdb ahora convertimos /dev/sda2 al formato de partición RAID:

Y lo añadimos al array:

PASO 3: Mover la partición LVM encima de /dev/md1 La partición root de Proxmox se encuentra instalada en un disco lógico gestionado por LVM, por lo que moverlo conlleva una serie de pasos. Primero creamos un nuevo volumen LVM y movemos nuestro sistema de archivos LVM desde /dev/sda3 a /dev/md1. Este comando puede tardar bastante, dependiendo del tamaño del disco:

Una vez movido, borramos /dev/sda3 del volumen lo cual nos permitirá añadirlo al array /dev/md1:

Lo cual, hacemos a continuación: Una vez alcanzado este punto /dev/sda3 comenzará a convertirse poco a poco en un clon de /dev/sdb3 y nuestro RAID estará terminado y funcionando. Se recomienda no guardar las MV dentro del almacenaje del RAID, sino tenerlas separadas del SO. En nuestro caso nos da igual, porque las estamos guardando en un disco independiente para el DRBD. En el RAID, sólo guardamos el sistema y algunos recursos, como imágenes de SO para instalación.

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710 http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]