Una cosa diferente. Alta disponibilidad y virtualizacion.

Esta entrada que comienza aquí  es un tema aparte. Es un pequeño ejercicio de como hacer un modelo de negocio que debemos entre todos promover con el software libre que permite el mejor uso y provecho de las tecnologías.

Aquí comenzamos.
------------------------------------------------------------------------------------------------------------

1. Motivos.

Usamos el software de gestion de cluster de pve para la virtualizacion y alta disponibilidad de los servicios de monitorización ya que ofrece un entorno de desarrollo de maquetas optimo.

Tomamos esta opción por las siguientes razones:

• Nos permite crear máquinas virtuales de prueba con relativa sencillez y rapidez.
• Nos permite así mismo crear un entorno de alta disponibilidad con un coste irrisorio (no más de 600€).
• Permite exportar los resultados de una forma rápida y extremadamente sencilla a entornos más complejos y desarrollados tecnológicamente.

2. Descripción de la plataforma.

La plataforma busca dar con unos mínimos recursos dar la máxima capacidad de crecimiento y disponibilidad.

1. Descripción hardware

El hardware está compuesto por tres servidores físicos con:

• Dos servidores con procesadores multinúcleo(4) , en estos servidores se instalará el software de alta disponibilidad. Tienen dos tarjetas de red que intentaremos posteriomente poner en bonding para dar posibilidad a alta disponibilidad en caso de averia de alguna(sin realizar)
• Un servidor con procesador multinucleo(1), se trata del servidor de backend de datos, donde se guardarán todas los containers y máquinas virtuales del cluster de virtualización y alta disponibilidad. Tiene tres tarjetas de red, para poder realizar bonding entre ellas, y dar alta disponibilidad de conectividad de hardware.

2. Drescripción del software

El software elegido para el cluster es el de PROMOX VE 2.2. por las siguientes características:

• Proceso de instalación desde CD en el que deja un entorno pre-configuración del cluster completa
• Proceso de configuración del cluster rápida y sencilla.
• Gran documentación en internet

También se usa la distribución Debian 5.0.10 para la máquina de backend por ser una distribución completamente compatible con las PROMOX VE 2.2. anteriormente reseñada y por ser además una distribución estable y sobradamente constrastada,

3. Instalación de la plataforma de alta disponibilidad.

1. Descarga del software

Hemos descargado las imágenes ISO de la siguiente url:

http://www.proxmox.com/downloads/proxmox-ve/17-iso-images

Posteriormente hemos descargado la última versión existente en el proyecto, la 2.2 de fecha de 24 de Octubre de 2012, que consideramos estable.

Hemos creado un cd de instalación con la imagen ISO descargada.  Y hemos realizado la instalación del software en los dos servidores multinucleo de los que disponemos en el cluster.

En la máquina backend hemos instalado desde un cd la versión 5.0.10 de la distribución Debian.

2. Instalación en las máquinas del cluster.

En los equipos que conformarán el cluster, las dos máquinas con CPU de 4 nucleos, se instalará el software de cluster y virtualización PROMOX VE 2.2., son distribuciones basadas en debian de 64 bits.

Hemos seguido el instalador gráfico del cd en ambas máquinas de forma normal. Todos los servidores tienen como primer dispositivo de arranque el cd-rom

En el equipo de backend se ha instalado una distribución linux debian 5.0.10 y posteriormente hemos instalado el servicio nfs que tiene preconfigurado en la paqueteria de la distribución.

En este equipo se ha realizado la instalación del software nfs para exportación de FS de un disco de 250 GB donde se almacenarán todas las máquinas virtuales. y containers.

4. Configuración.

1. Datos iniciales

El cluster se denomina c1. Cada nodo del cluster se nombra con la nomenclatura siguiente:

    srv[num]c1.casa.serv

El direccionamiento IP es el de la subred : 192.168.1.0/24.

De tal modo que tendremos los siguientes nombres y direccionamiento IP:

    Nodos PVE/direcc IP:

        srv1c1.casa.serv    192.168.1.11

        srv2c1.casa.serv    192.168.1.12

    Nodo backend

        srv3c1.casa.serv    192.168.1.13

El nodo master del cluster es la máquina: srv1c1.casa.serv

El nodo esclavo del cluster es la máquina: srv2c1.casa.serv

El nodo backend del cluster, no incluido en el cluster, es:  srv3c1.casa.serv

Los servidores virtuales estarán su direccionamiento, estático, propuesto para el direccionamiento : 192.168.1.2xx / 24

2. Configuración del cluster.

Para la configuración del cluste realizamos las siguiente operaciones.

1. Creación del cluster.

Hemos seguido la guia que está en la siguiente url:

http://pve.proxmox.com/wiki/Proxmox_VE_2.0_Cluster#Proxmox_VE_Cluster

Para crear nuestro cluster primero ejecutamos la siguiente serie de comandos en la consola del servidor srv1c1.casa.serv , hay que hacerlo como permisos de administrador de la máquina. Nos hemos conectado como root en la misma y hemos ejecutado el comando siguiente:

:~# pvecm create c1
Generating public/private rsa key pair.
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
6f:21:bd:64:6c:02:02:a2:9f:13:0b:49:9b:93:97:b0 root@srv1c1
The key's randomart image is:
+--[ RSA 2048]----+
|.o.              |
|oo*..            |
|+E.o. .          |
| oo+ . . o       |
|  =     S B      |
|   .     B o     |
|          +      |
|         .       |
|                 |
+-----------------+
Restarting pve cluster filesystem: pve-cluster[dcdb] notice: wrote new cluster config '/etc/cluster/cluster.conf'
.
Starting cluster:
  Checking if cluster has been disabled at boot... [  OK  ]
  Checking Network Manager... [  OK  ]
  Global setup... [  OK  ]
  Loading kernel modules... [  OK  ]
  Mounting configfs... [  OK  ]
  Starting cman... [  OK  ]
  Waiting for quorum... [  OK  ]
  Starting fenced... [  OK  ]
  Starting dlm_controld... [  OK  ]
  Tuning DLM kernel config... [  OK  ]
  Unfencing self... [  OK  ]

Comprobamos el estado del cluster ejecutando el siguiente comando:

:~# pvecm status
Version: 6.2.0
Config Version: 1
Cluster Name: c1
Cluster Id: 247
Cluster Member: Yes
Cluster Generation: 4
Membership state: Cluster-Member
Nodes: 1
Expected votes: 1
Total votes: 1
Node votes: 1
Quorum: 1
Active subsystems: 5
Flags:
Ports Bound: 0
Node name: srv1c1
Node ID: 1
Multicast addresses: 239.192.0.247
Node addresses: 192.168.1.11

Ahora procedemos a añadir un segundo nodo al cluster que hemos montado.

2. Adición de elementos del cluster.

Según la guía que hemos localizado en la anterior url arriba indicada tenemos que conectarnos al servidor que queremos añadir.  Con ello comprobamos que es accesible desde el nodo maestro del actual cluster.

Una  vez nos hemos logeado en la máquina física ejecutamos el siguiente comando:

:~# pvecm add 192.168.1.11
Generating public/private rsa key pair.
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
a4:48:b6:2f:2b:15:4e:60:2b:b3:70:e0:f1:ef:1c:7c root@srv2c1
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|..o              |
|.oooo   .        |
|+.o+oo o         |
|.= o=.. S        |
|.   o= E         |
|   .+ +          |
|  .  =           |
|   ..            |
+-----------------+
The authenticity of host '192.168.1.11 (192.168.1.11)' can't be established.
RSA key fingerprint is 4d:87:77:0a:ca:ff:a3:54:d0:ec:69:ab:68:8c:61:38.
Are you sure you want to continue connecting (yes/no)? yes
root@192.168.1.11's password:
copy corosync auth key
stopping pve-cluster service
Stopping pve cluster filesystem: pve-cluster.
backup old database
Starting pve cluster filesystem : pve-cluster.
Starting cluster:
  Checking if cluster has been disabled at boot... [  OK  ]
  Checking Network Manager... [  OK  ]
  Global setup... [  OK  ]
  Loading kernel modules... [  OK  ]
  Mounting configfs... [  OK  ]
  Starting cman... [  OK  ]
  Waiting for quorum... [  OK  ]
  Starting fenced... [  OK  ]
  Starting dlm_controld... [  OK  ]
  Tuning DLM kernel config... [  OK  ]
  Unfencing self... [  OK  ]
generating node certificates
merge known_hosts file
restart services
Restarting PVE Daemon: pvedaemon.
Restarting web server: apache2 ... waiting .
successfully added node 'srv2c1' to cluster.

Comprobamos entonces el estado del cluster desde el servidor que hemos añadido al cluster:

:~# pvecm status
Version: 6.2.0
Config Version: 2
Cluster Name: c1
Cluster Id: 247
Cluster Member: Yes
Cluster Generation: 8
Membership state: Cluster-Member
Nodes: 2
Expected votes: 2
Total votes: 2
Node votes: 1
Quorum: 2
Active subsystems: 5
Flags:
Ports Bound: 0
Node name: srv2c1
Node ID: 2
Multicast addresses: 239.192.0.247
Node addresses: 192.168.1.12

Y ahora desde el nodo maestro:

~# pvecm status
Version: 6.2.0
Config Version: 2
Cluster Name: c1
Cluster Id: 247
Cluster Member: Yes
Cluster Generation: 8
Membership state: Cluster-Member
Nodes: 2
Expected votes: 2
Total votes: 2
Node votes: 1
Quorum: 2
Active subsystems: 5
Flags:
Ports Bound: 0
Node name: srv1c1
Node ID: 1
Multicast addresses: 239.192.0.247
Node addresses: 192.168.1.11

Y observamos cual es el número de nodos presente en el cluster desde el nodo maestro:

~# pvecm nodes
Node  Sts   Inc   Joined               Name
  1   M      4   2013-02-02 22:20:36  srv1c1
  2   M      8   2013-02-02 22:27:31  srv2c1

3. Conexión con servidor de backend.

Como paso previo a la alta disponibilidad, se debe de configurar en el cluster un elemento de almacenamiento común que nos permita poder almacenar los containers y máquinas virtuales y que estén disponibles para su acceso por parte de los diferentes servidores del cluster.

Este es el papel que tiene la tercera máquina del cluster, aunque por motivos de hardware (no es una máquina de 64 bits) no puede integrarse en el mismo. De todos modos es un punto de fallo del cluster y es posible redundarlo a través de DRBD y Linux_HA para el servicio de NFS.

Exportamos dos directorios del servidor mediante nfs permitiendo que en este caso ambas máquinas (srv1c1 y srv2c1) tengan acceso sin ningún tipo de problema al contenido de ambos directorios. Para ello configuramos el servicio NFS del siguiente modo. En el archivo /etc/exports completamos con esta información:

# /etc/exports: the access control list for filesystems which may be exported
#               to NFS clients.  See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes       hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes  gss/krb5i(rw,sync,no_subtree_check)
# Lineas de nuestra configuracion.
#
/nfs/mv srv1c1(rw,sync,no_subtree_check,no_root_squash)
/nfs/mv srv2c1(rw,sync,no_subtree_check,no_root_squash)
/nfs/plantillas srv1c1(rw,sync,no_subtree_check,all_squash)
/nfs/plantillas srv2c1(rw,sync,no_subtree_check,all_squash)

4. Activación de la alta disponibilidad.

La configuracion del entorno de alta disponibilidad se debe de retocar la configuracion del archivo siguiente:

/etc/default/red-hat-cluster

En dicho archivo hay que descomentar la siguiente linea:

fence=”yes”

Y lanzamos entonces el servicio, sino se ha lanzado automáticamente, rgmanager desde el front-end de administración del cluster, que se localiza en la dirección ip:

http://192.168.1.11:8006

Una vez lanzado podemos migrar los servidores virtuales entre las máquinas sin problema alguno y en caso de caida de uno de los servidores el otro las recupera.

5. Últimos retoques.

Nos conectamos al servidor de backend y preautorizamos la conexión desde los dos servidores miembros del cluster  mediante la siguiente serie de comandos:

Desde el servidor maestro:

:~# scp .ssh/id_rsa.pun 192.168.1.13:/tmp

Y posteriormente ejecutamos desde el servidor de backend:

:~# cat /tmp/id_rsa.pub > .ssh/authorized_keys

Realizamos la misma operativa desde el servidor esclavo del cluster.

Como segundo paso modificamos el archivo /etc/hosts para que tengan un contenido similar:

192.168.1.13 srv3c1.casa.serv srv3c1

192.168.1.11 srv1c1.casa.serv srv1c1

192.168.1.12 srv2c1.casa.serv srv2c1

1. Descarga de plantillas.

Hemos descargado a través de la web de administración varias plantillas para las diferentes  funciones que vamos a desarrollar en los servidores. Por un lado vamos descargar :

• plantilla para sevidores genéricos.
• plantilla para servidor de wiki, de documentación para documentar todo el proceso de instalación y configuracion.

6. Cuestiones pendientes.

Entre los varios elementos que quedan por hacer para que el servicio sea robusto queda:

1. por un lado crear un sistema de detección de la caida de los servidores (fencing) de modo que detecte correctamente una caida en uno de los dos elementos del cluster y permite que el arranque de los servidores virtuales en el nodo superviviente sea correcto y no genere problemas. Pudiera ser que por cualquier circunstancia el servidor maestro o esclavo pierden conectividad pero no caen las máquinas virtuales, es por ello que ambos servidores intentarian levantar las máquinas que el otro nodo estuvieran ejecutando. Ante este problema se plante el método de fencing que es un modo de detección de esta circunstancia. Se puede emplear por ello varios elementos entre los que me parecen más acertados es:

• Uso del paquete ipmi que nos permite conocer el estado del hardware de cualquier nodo a través de la red, mediante una red dedicada conexión física de los dos servidores, usarlo para la detección de la caida de cualquier nodo. Usando este método para la detección de que el servidor está activo. 

(Nota_28112014:Mi hardware no lo soporta)

• Uso del protocolo de snmp para la detección de los valores necesarios que nos confirmen que los nodos están o no activos dentro del cluster.

 (Nota_28112014: Mi hardware de red no es administrable)

2. Por otro lado aportar la configuración del bonding de modo que los servidores tengan redundancia de conectividad, estamos hablando del un hardware que ha costado en conjunto menos de 600€. Esta configuración puede entrañar alguna dificultad ya que es posterior a la instalación del software de promox ve 2.2 en los nodos del cluster. En el caso del servidor de backend, el que tenga 3 tarjetas de red no debe implicar problema alguno. Por un lado ganamos en ancho de banda, pasamos de 100 Mbits/s a 200 Mbits/s en los nodos del cluster, y en el backend pasamos a tener 300 Mbits/s, Estoy a la espera de hacerme con un hardware,: tarjetas de red de 1000 Mbits/s y de un switch de 8 puertos al menos que soporte esta velocidad para incrementar la velocidad, fiabilidad y escalabilidad.

Estoy dispuestos a que alguién me guié en cuanto al manejo del fence_device.