Grupo de trabajo

Con este grupo de trabajo andamos buscando varias cosas. La excusa principal es conocer la tecnología de virtualización de vSphere 5. Pero de paso, vamos a hacer algunas cosas que van a venir muy bien al departamento y al instituto, como son centralizar de una vez por todas la lógica de red del instituto y consolidar los diferentes servidores en forma de máquinas virtuales, ya que hoy por hoy son un desperdicio de máquinas. Y por último, vamos a poner en práctica algunas tecnologías de HA, como DRBD, HeartBeat y PaceMaker.

Otra cuestión también importante es que tomando como excusa el grupo de trabajo, vamos a contar por fin con un Rack en condiciones. Digo yo que un ciclo superior de informática tiene que tener uno por lo menos.

Hace ya unos meses, nuestra compañera Eva estuvo en Alemania, y nos contó como allí los ciclos formativos tienen equipamiento bastante bueno, cedido por empresas y organismos locales. Probablemente eso es mucho pedir por estos lares, pero bueno, al menos hagamos el esfuerzo por acercarnos a eso.

Sesión 1

En nuestra primera sesión nos dedicamos a montar nuestro rack, recibido unos días antes.

Aquí podemos ver las cajas aún sin abrir. Se trata de un rack de marca Rackmatic (comprado en www.rackmatic.com) de 19", 32U y 800 mm de fondo.

Lo primero fue buscar las instrucciones de montaje. Así que abrimos todas las cajas en su busca.

Tengo que decir, que de la imagen anterior a esta, pasó al menos una hora y media, porque las instrucciones estaban en un par de páginas, con imágenes en blanco y negro de baja resolución.

Aquí está Víctor Rodríguez, un manitas, durante el proceso de montaje.

Los ventiladores del rack, que se ven en la siguiente imagen, son efectivos y un poco ruidosos. Pero...

José Luís Fernández, jefe de departamento, está aquí montando las ruedas del rack.

En la siguiente imagen, José Luís está atornillando la parte superior del rack.

En estas que apareció nuestro compañero Francisco Cantos, un forofo de la tecnología, y meritorio trabajador público a los 66 años. En esta imagen nos está contando su experiencia en el montaje de racks cedidos por la OTAN en un trabajo anterior.

Ya casi estamos. Víctor monta los paneles laterales.

Y este es el flamante resultado. Nuestro rack montado

De momento, el rack está vacío, pero en la siguiente sesión lo llenaremos de cosas.

Sesión 2

En esta sesión, nos dedicamos a llenar el rack de trastos. Compramos dos cajas enracables de 4 pulgadas, por un precio muy asequible, y las llenamos con los componentes de ordenadores que estaban sin usar, y que nos servirán como servidores de almacenamiento para las máquinas virtuales. En la siguiente imagen, está una de estas cajas recién abierta.

Los componentes provienen de PCs de perfil bajo que teníamos sin usar.

Nuestra compañera Manuela Sarmiento aparece en las siguientes fotos, destripando los PCs, para dar vida a las cajas enracables.

Durante el montaje de las cajas, hemos tenido que sustituir las pletinas posteriores para los puertos integrados en la placa.

La placa que venía con el rack, lo usamos para colocar los servidores ESXi, en cajas de PC.

En la siguiente foto aparece nuestra compañera Eva Rodríguez terminando uno de los servidores enracables.

Entre otras cosas, compramos un switch kvm de 4 puertos. Cuando abrimos la caja, nos dimos cuenta de que solo traía los cables para dos equipos. Así que hemos tenido que ingeniárnoslas comprando otros 4 cables PS/2 macho-macho y 2 cables VGA.

Por fortuna, hace unos años un compañero se confundió al comprar una bandeja de 19", ya que tenía un fondo de 600mm, demasiado para un armario de 400mm. Ha estado dando tumbos varios años, hasta que al final ya sabemos para lo que en realidad se compró: soportar nuestra consola kvm.

Aquí podemos ver ya como va quedando el rack. Vemos los dos servidores ESXi y nuestra consola kvm casera.

El switch que hemos comprado (un TP-Link TL-SG3216) tiene factor de forma enracable de 1U, lo que nos viene muy bien para nuestro rack.

En nuestra búsqueda por una fuente de alimentación que funcionase para las cajas enracables, testeamos unas cuantas hasta que dimos con dos fuentes válidas.

En la siguiente imagen, se ve como se coloca la tornillería en los perfiles para el enracado del switch.

La consola kvm quedó inacabada, ya que como hemos dicho, solo traía dos cables. Después tuvimos que comprar el cableado comentado anteriormente.

Aquí se puede ver el aspecto del rack tras la sesión 2. Las sesiones siguientes andarán más en el campo del software.

Sesión 3.

En la tercera sesión, hemos montado la siguiente infraestructura:

Para llevar a cabo esta sesión, ha sido necesario la puesta en común de lo leido en:

  • Mastering VMware vSphere 5 de Scott Lowe
  • La documentación del switch TL-SG3216
  • www.freenas.org

Los componentes del grupo, han probado la solución mediante software mediante virtualización con VirtualBox antes de ponerla en práctica en el rack.

Las tareas iniciales han sido las siguientes:

  1. Añadir el cableado de red y etiquetarlo
  2. Añadir el cableado que faltaba en el switch kvm
  3. Instalar ESXi 5.0 en el servidor ESXi
  4. Añadir un pequeño disco IDE en la NAS donde se alojará el sistema operativo FreeNAS (la NAS ya contaba con un gran disco SATA que se empleará para el datastore de vSphere.

Los componentes son los siguientes:

  • Una NAS creada mediante FreeNAS
  • Un servidor ESXi
  • 3 VLAN
  • Un cliente Windows 7 para la administración del conjunto
  • El software vSphere Client

Los pasos seguidos son:

Paso 1. Configuración del switch.

Para el switch se han crado 3 VLAN:

  • VLAN 1 "System". Esta VLAN es la VLAN Nativa. En principio se va a emplear para la configuración del switch.
  • VLAN 2 "Administration". Esta VLAN se va a emplear para el tráfico de administración de vSphere y de almacenamiento (entre los ESXi y la NAS).
  • VLAN 3 "Machines". Esta VLAN es para el tráfico de las máquinas virtuales.

Asignamos las IP 10.0.0.1 al switch para administrarlo a través de la interfaz web. El switch tiene 16 puertos, y las VLAN asignadas son las siguientes:

VLAN 1: Puertos 7-14 VLAN 2: Puertos 1-6 VLAN 3: Puertos 3-4,15-16 Los puertos 3 y 4 son troncales.

Paso 2. Configuración de los parámetros de red de administración:

Para la red de administración se va a emplear la red 172.16.0.0/24. En concreto:

  • ESXi -> 172.16.0.1
  • FreeNAS -> 172.16.0.2
  • Cliente Windows 7 -> 172.16.0.3

Comprobamos que los 3 host (FreeNAS, ESXi y Windows 7) pueden comunicarse entre sí.


NOTA: El servidor ESXi está conectado a un puerto configurado como "VLAN Trunk". Por ello, el servidor inicialmente no responde si solamente configuramos el direccionamiento de red. También es necesario configurar la VLAN empleado para administración.


Paso 3. Crear la nueva compartición NFS en FreeNAS

  1. Nos conectamos desde el navegador web a la consola de FreeNAS desde el cliente W7 (http://172.16.0.2)
  2. Creamos un nuevo volumen con sistema de archivos ZFS cuya extensión es todo el disco SATA del servidor, ubicado en /mnt/ESXi-datastore.
  3. Creamos una nueva compartición NFS del volumen.
  4. Activamos el servicio NFS

Paso 4. Creamos en el servidor ESXi un nuevo Datastore ubicado en la compartición NFS.

  1. Nos conectamos mediante vSphere Client al servidor ESXi
  2. En la sección de almacenamiento, creamos un nuevo Datastore, eligiendo la opción "Network File System".
  3. La unidad NFS estará en 172.16.0.2:/mnt/ESXi-datastore, y será nombrada como FreeNAS.
  4. Después abrimos el explorador del datastore y creamos una carpeta llamada "images", donde guardaremos las imágenes ISO de instalación de cada sistema operativo.

Paso 5. Copiamos la imagen ISO de Windows Server 2008 en la NAS.

Para esto hemos usado una cuarta máquina (un portátil) que contenía la imagen ISO de Windows Server 2008. Mediante ssh hemos copiado la imagen de Windows Server 2008 en 172.16.0.0:/mnt/ESXi-datastore/images

Paso 6. Añadir un nuevo "Virtual Machine Port Group" dedicado para las máquinas que vamos a crear en el servidor ESXi.

  1. Nos vamos a la sección de networking
  2. Añadimos un nuevo "Virtual Machine Port Group"
  3. Lo ubicamos en el vswitch existente (de momento el servidor ESXi solamente tiene una interfaz de red, por lo que se empleará el único vswitch existente).
  4. Asociamos el Port Group a la VLAN 3.

Paso 7. Creamos una nueva máquina virtual.

Creamos una nueva máquina virtual desde vSphere Client del mismo modo que lo haríamos con Vmware Player. En este proceso hay dos apartados destacables:

  • El disco duro está ubicado en el datastore "FreeNAS"
  • La unidad de CD/DVD utiliza el archivo ISO copiado anteriormente en la NAS.
  • Arrancamos la máquina virtual comenzamos el proceso de instalación.

Con esto, completamos nuestro objetivo de la sesión.

Sesión 4

En la sesión 4 hemos conectado dos servidores ESXi contra la misma NAS, y los hemos puesto a trabajar simultáneamente con máquinas virtuales independientes. El esquema planteado ha sido el siguiente:

El proceso fue similar al seguido con el servidor ESXi primero:

  1. Se instaló ESXi en el servidor
  2. Una vez instalado se inició vSphere Cliente contra el nuevo servidor ESXi
  3. Una vez dentro, se creó un nuevo datastore eligiendo la opción "Network File System" (NFS), y se seleccionó la unidad NFS exitente en FreeNAS (creada en la sesión anterior).
  4. En la sección de networking, se creó un nuevo "Virtual Machine Port Group" y lo ubicamos en el vswitch existente.
  5. Asociamos el Port Group a la VLAN 3.

Finalmente, procedimos a crear una nueva máquina virtual, en la que instalamos un servidor "Ubuntu Server"

En las siguientes imágenes, se puede ver la caja de la NAS y los dos servidores ESXi conectados simultáneamente a la unidad NFS, cada uno con una máquina virtual diferente.

Aun no hemos hecho pruebas de carga planificadas, debido a que los servidores ESXi tienen de momento poca RAM. En breve compraremos más memoria, para tener un servidor ESXi con 16GB y otro con 8GB. Sin embargo podemos decir que el rendimiento del sistema ha sido óptimo durante la instalación (momento en que hay un uso intensivo de la NAS).

Sesiones 5 y 6

Las sesiones 5 y 6 se centran en construir una infraestructura de alta disponibilidad para el datastore donde se almacenan los archivos .vmdk de las máquinas virtuales. Queda más o menos descrito en la siguiente imagen:

En el gráfico anterior, se pueden apreciar dos nodos, llamados NFS1 y NFS2. Estos nodos forman un cluster de alta disponibilidad. Ofrecen un servicio NFS a los servidores ESXi, de modo que estos almacenarán los archivos de las máquinas virtuales. Cuando uno de los nodos del cluster queda fuera de servicio, el otro nodo asume todas las funciones, de forma que el servicio está fuera de servicio solo unos segundos.

Para esta infraestructura, hemos elegido sistemas Debian (Squeeze), dada la estabilidad de esta distribución.

Los componentes que vamos a utilizar para configurar esta infraestructura, son los siguientes:

  • DRBD - Servicio para la replicación de discos en red.
  • Heartbeat - Servicio de comunicación del cluster.
  • Pacemaker - Servicio que proporciona la infraestructura de clusterización.
  • NFS - Servicio de archivos en red, que emplearán los servidores ESXi para almacenar las máquina virtuales.

Los pasos seguidos son los siguientes:

Direccionamiento

Los nodos deberían tener tarjetas de red dedicadas para el control del cluster. Además, cada nodo debe poder ser accesible desde la red de almacenamiento. Por ejemplo, la siguiente configuración es la que emplearemos en nuestro grupo de trabajo:

Asignamos a los nodos las siguientes IPs para el control del cluster:

  • nodo 1 (nfs1): 10.10.10.1
  • nodo 2 (nfs2): 10.10.10.2

Asignamos a los nodos las siguientes IPs para la red de almacenamiento:

  • nodo 1 (nfs1): 172.16.0.101
  • nodo 2 (nfs2): 172.16.0.102

Hardware de red

Para las comunicaciones de almacenamiento y comunicación del cluster se debería usar hardware de al menos 1Gbps.

El archivo hosts

Cada nodo debe conocer su nombre y el del otro nodo. No vamos a utilizar un servicio de DNS para la red de almacenamiento, por ello se debe agregar el siguiente contenido al archivo /etc/hosts del nodo 1:

127.0.0.1 nfs1.guadalpin.es nfs1 10.10.10.2 nfs2.guadalpin.es nfs2

En el caso del nodo 2, el archivo /etc/hosts debe contener lo siguiente:

127.0.0.1 nfs2.guadalpin.es nfs2 10.10.10.1 nfs1.guadalpin.es nfs1

Además, es preciso comprobar que el archivo /etc/hostname contiene el nombre correcto del nodo. Por ejemplo, en el nodo 1, deberíamos obtener el siguiente resultado:

nfs1:/> cat /etc/hostname nfs1

Del mismo modo, en el nodo 2, el resultado sería el siguiente:

nfs2:/> cat /etc/hostname nfs2

Instalación de software

Vamos a instalar el software necesario en ambos nodos. Es necesario que tengan acceso a Internet. Los siguientes comandos se deben ejecutar en ambos nodos:

nfs1:/> apt-get update nfs1:/> apt-get upgrade -y nfs1:/> apt-get install -y heartbeat pacemaker nfs-kernel-server

Debemos detener los servicios NFS y DRBD, e indicar al sistema que no los inicie en el arranque, ya que esta es una labor que debe hacer Pacemaker cuando decida que nodo debe iniciar.

service nfs-kernel-server stop update-rc.d -f nfs-kernel-server remove update-rc.d -f drbd remove

DRBD

Ahora vamos a configurar DRBD.

DRBD se puede definir como un RAID1 en red. Su funcionamiento es el siguiente:

DRBD permite mantener replicados los sistemas de archivos de dos o más servidores diferentes (en nuestro caso dos servidores). Solo uno de los servidores puede montar la partición DRBD al mismo tiempo. El servidor secundario no puede montar la partición mientras esté montada en el primario. Cada cambio que se produce sobre la partición DRBD del servidor primario, es replicado a través de la red sobre la partición DRBD sobre el servidor secundario.

Cuando el servidor primario queda fuera de servicio, el secundario se convierte en primario.

DRBD por sí mismo no sirve como solución de cluster de alta disponibilidad. Para ello, lo combinaremos con otra tecnología de la que hablaremos posteriormente.

Para que DRBD funcione se necesita al menos una partición dedicada a los datos a replicar. El tamaño debe ser idéntico en ambos nodos. También se puede dedicar una partición para los metadatos de DRBD. Lo ideal es tener discos duros separados para cada cosa. Por ejemplo:

  • Un disco para el sistema (No más de 15-20 GB)
  • Un disco para datos replicados (Tantos GB como se necesite)
  • Un disco para metadatos de DRBD (No más de 1 GB)

En el laboratorio vamos a emplear un particionado muy sencillo, debido a que el escenario es para pruebas y no requerirá un rendimiento excesivo. Por simplicidad, hemos dedicido guardar los metadatos de DRBD en la misma partición que los datos. Hay que tener en cuenta que el hardware es "reciclado":

  • /dev/sda1 (10 GB) ==> /
  • /dev/sda2 (498 GB) ==> drbd
  • /dev/sda3 (2 GB) ==> swap

Para la implementación definitiva se utilizará un disco dedicado para DRBD, con mayor capacidad.

NOTA: Finalmente, nos hemos decatando por descartar una unidad dedicada para los metadatos. La razón se puede ver en http://www.drbd.org/users-guide-emb/ch-internals.html#s-metadata.

  • Advantage. Since the meta data are inextricably linked with the actual data, no special action is required from the administrator in case of a hard disk failure. The meta data are lost together with the actual data and are also restored together.
  • Disadvantage. In case of the lower-level device being a single physical hard disk (as opposed to a RAID set), internal meta data may negatively div>affect write throughput. The performance of write requests by the application may trigger an update of the meta data in DRBD. If the meta data are stored on the same magnetic disk of a hard disk, the write operation may result in two additional movements of the write/read head of the hard disk.

La complejidad introducida y la posible corrupción de metadatos (teniendo en cuenta que nuestro hardware es viejo y barato) no se ve compensada por la mejora de rendimiento. En nuestro caso resulta más interesante la simplicidad que el rendimiento, especialmente teniendo en cuenta que el sistema estará en pruebas una buena temporada.

Configuración de DRBD

Ya instalamos DRBD con anterioridad. Ahora vamos cargar el módulo DRBD. Estos comandos se ejecutarán en ambos nodos:

Primero en el nodo 1:

nfs1:/> modprobe drbd nfs1:/> lsmod | grep drbd drbd 193312 0 lru_cache 5042 1 drbd cn 4563 1 drbd

Después en el nodo 2:

nfs2:/> modprobe drbd nfs2:/> lsmod | grep drbd drbd 193312 0 lru_cache 5042 1 drbd cn 4563 1 drbd

Debemos crear un archivo llamado /etc/drbd.d/nfs.res donde se indica qué unidades serán replicadas por DRBD. nfs.res tiene el siguiente contenido:

resource nfs { device /dev/drbd0; disk /dev/sda2; meta-disk internal; on nodo1 { address 10.10.10.1:7790; } on nodo2 { address 10.10.10.2:7790; } }

Este archivo debe está presente en ambos nodos, nfs1 y nfs2.

Por defecto, la velocidad de sincronización de DRBD es de 250KB/s, una velicidad muy baja para lo que necesitamos. Por ello debemos cambiarla. Para ello, vamos a añadir en el apartado syncer de /etc/drbd.d/global-common.conf lo siguiente (en ambos nodos):

syncer { rate 50M; }

NOTA: 50M = 50MBps. El valor que se debe expresar en rate es el menor de los siguientes:

  • Tarjeta de red.
  • Transferencia de disco

Al valor elegido, hay que multiplicarlo por 0.3, como medida para evitar la desconexión de los nodos.

Si modificamos este u otro parámetro una vez que DRBD ha sido configurado, debemos reconfigurar el recurso afectado (en nuestro caso "nfs"), ejecutamos el siguiente comando:

drbdadm adjust nfs

Inicilizar los metadatos de DRBD (en ambos nodos)

Para crear los metadatos en las unidades replicadas, debemos asegurarnos de que DRBD está iniciado (en ambos nodos):

nfs1:/> sudo /etc/init.d/drbd start
nfs2:/> sudo /etc/init.d/drbd start

En segundo lugar vamos a crear los metadatos de DRBD (en ambos nodos):

nfs1:/> drbdadm create-md nfs
nfs2:/> drbdadm create-md nfs

Iniciar DRBD (en ambos nodos)

nfs1:/> /etc/init.d/drbd start
nfs2:/> /etc/init.d/drbd start

Sincronizar los datos en las unidades replicadas

Convertir al nodo 1 en primario y sincronizar datos con nodo 2 (solo en nodo 1)

nfs1:/> drbdadm -- --overwrite-data-of-peer primary all

Para comprobar el estado de la sincronización, ejecutamos lo siguiente en el nodo 2:

nfs2:/> cat /proc/drbd version: 8.3.7 (api:88/proto:86-91) srcversion: EE47D8BF18AC166BE219757 0: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r---- ns:0 nr:15790400 dw:15790144 dr:0 al:0 bm:963 lo:9 pe:29622 ua:8 ap:0 ep:1 wo:b oos:15664096 [=========>..........] sync'ed: 50.3% (15296/30716)M finish: 0:02:44 speed: 95,212 (85,352) K/sec

Al terminar, veremos algo como esto al ejecutar el comando anterior:

nfs2:/> cat /proc/drbd version: 8.3.7 (api:88/proto:86-91) srcversion: EE47D8BF18AC166BE219757 0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r---- ns:0 nr:31454240 dw:31454240 dr:0 al:0 bm:1920 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

Y así debería seguir. En el otro nodo, veremos lo siguiente:

version: 8.3.7 (api:88/proto:86-91) srcversion: EE47D8BF18AC166BE219757 0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r---- ns:0 nr:31454240 dw:31454240 dr:0 al:0 bm:1920 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

NOTA: En ocasiones, el nodo pierde la sincronización. Esto puede ocurrir, por ejemplo, tras microcaidas de heartbeat. En tal caso, ambos nodos intentan el montaje de la unidad DRBD y pueden perder la sincronía. Poremos ver entonces un rol Primary/Unknown o Secondary/Unknown; un estado WFConnection o StandAlone

Para solucionar esto, debería funcionar el siguiente código:

En el nodo primario:

nfs1:/> drbdadm connect all

Y en el nodo secundario:

nfs2:/>drbdadm -- --discard-my-data connect all

Configuración de NFS

Para el servicio NFS me limito a exportar los directorios copartidos. De este modo, cuando Pacemaker inicie el servicio, exportará dichos directorios. Ejecutamos lo siguiente en ambos nodos:

Primero en el nodo 1:

nfs1:/> mkdir /datastore nfs2:/> vi /etc/exports ### Añadimos la línea siguiente al final ### /datastore 172.16.0.0/24(rw,sync,no_subtree_check)

Y después en el nodo 2:

nfs2:/> mkdir /datastore nfs2:/> vi /etc/exports ### Añadimos la línea siguiente al final ### /datastore 172.16.0.0/24(rw,sync,no_subtree_check)

Heartbeat (en ambos modos)

Las siguientes acciones se harán en un único nodo. Se debe crear un archivo llamado /etc/ha.d/ha.cf:

autojoin none bcast eth2 warntime 5 deadtime 15 initdead 60 keepalive 2 node drbd1 node drbd2 crm yes

Después instalamos el programa pwgen para generar contraseñas:

nfs1:/> apt-get install pwgen

Además, se debe crear un segundo archivo, llamado /etc/ha.d/authkeys:

nfs1:/> cat </etc/ha.d/authkeys auth 1 1 sha1 $(pwgen 30 | openssl sha1) EOF

Ahora hay que copiar dichos archivos en el otro nodo (mediante ssh):

nfs2:/> scp administrador@nfs1:/etc/ha.d/ha.cf /etc/ha.d/ nfs2:/> scp administrador@nfs1:/etc/ha.d/authkeys /etc/ha.d/

En ambos servidores iniciamos heartbeat:

nfs1:/> /etc/init.d/heartbeat start nfs2:/> /etc/init.d/heartbeat start

Configuración de pacemaker

Por último vamos configurar Pacemaker. Las acciones siguientes se ejecutan en el nodo 1. El nodo 2 recibirá la configuración via heartbeat.

Para empezar ejecutamos el siguiente comando para iniciar la consola de configuración de Pacemaker:

crm configure

entonces se abre la consola de configuración de pacemaker:

crm(live)configure#

Lo primero, es configurar que todo está bien. Ejecutamos el comando siguiente:

crm(live)configure# edit

Deberíamos obtener una respuesta similar a la siguiente:

node $id="0492ddb7-127f-4f96-beaf-7ce0a28e70b1" ha1-db node $id="4c898f53-5b12-4e8b-866c-d67542411961" ha2-db property $id="cib-bootstrap-options" \ dc-version="1.0.8-042548a451fce8400660f6031f4da6f0223dd5dd" \ cluster-infrastructure="Heartbeat"

A continuación, hacemos lo siguiente:

  • Desactivar STONITH, una característica que permite a un nodo forzar el apagado del otro para evitar corrupción de datos.
  • Desactivar la opción "no quorum policy" para evitar que cuando un nodo caiga, el otro no detenga los servicios.
  • Poner la opción stickiness a 200, para evitar que los servicios vayan de un nodo a otro y vuelta al caer y recuperarse un nodo.
crm(live)configure# property stonith-enabled="false" crm(live)configure# property no-quorum-policy="ignore" crm(live)configure# rsc_defaults resource-stickiness="200" crm(live)configure# property expected-quorum-votes="1" crm(live)configure# commit

Tras esto, vamos a configurar el cluster (recursos, acciones, dependencias cliente-servidor, y orden en los recursos).

crm(live)configure #primitive drbd_nfs ocf:linbit:drbd params drbd_resource="nfs" op monitor interval="15s" crm(live)configure# primitive fs_nfs ocf:heartbeat:Filesystem params device="/dev/drbd/by-res/nfs" directory="/datastore" fstype="ext3" op start interval="0" timeout="60" op stop interval="0" timeout="120" crm(live)configure# primitive ip1 ocf:heartbeat:IPaddr2 params ip="172.16.0.100" nic="eth1:1" op monitor interval="5s" crm(live)configure# primitive ip1arp ocf:heartbeat:SendArp params ip="172.16.0.100" nic="eth1:1" primitive nfs lsb:nfs-kernel-server op monitor interval="5s" crm(live)configure# primitive nfs lsb:nfs-kernel-server op monitor interval="5s" crm(live)configure# group HAServices ip1 ip1arp fs_nfs nfs meta target-role="Started" crm(live)configure# ms ms_drbd_nfs drbd_nfs meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true" crm(live)configure# colocation ms-drbd-nfs-with-haservices inf: ms_drbd_nfs:Master HAServices crm(live)configure# order ip-before-arp mandatory: ip1:start ip1arp:start crm(live)configure# order ip-before-ms-drbd-nfs mandatory: ip1:start ms_drbd_nfs:promote crm(live)configure# order ms-drbd-nfs-before-fs-nfs mandatory: ms_drbd_nfs:promote fs_nfs:start crm(live)configure# order fs-nfs-before-nfs mandatory: fs_nfs:start nfs:start crm(live)configure# commit

Tras esto el cluster está configurado. Solo queda monitorizar que todo se produce correctamente. El cualquiera de los nodos, ejecutamos:

nfs1:/> crm_mon

Capturas del cluster

La siguiente secuencia muestra el comportamiento del cluster al arrancar cada nodo por separado. Encenderemos primero el nodo 1 (nfs1), y después del nodo 2 (nfs2).

Las capturas siguientes corresponden a un modelo idéntico al construido en el rack. Este modelo utiliza VirtualBox para simular las máquinas virtuales. La razón para mostrar estas capturas es que nos resulta más fácil capturar estas imágenes en máquinas virtuales que en rack.

Arrancando el nodo 1. La primera captura muestra el nodo ya arrancado. Al consultar el estado de DRBD, podemos comprobar que el estado es Secondary/Unknown, lo que significa que el volumen DRBD no ha sido montado y no hay sincronización con el otro nodo (ya que el otro nodo no ha sido iniciado aun).

También podemos ver como el heartbeat tampoco ha conseguido sincronizarse con el otro nodo del cluster. Lo que se puede ver a continuación, se obtiene tras ejecutar el comando crm_mon:

Arrancamos el nodo 2. Ahora podemos ver el nodo 2 arrancado. Si comprobamos el estado de DRBD, podemos ver que ambos nodos aparecen como Secondary y el estado del cluster es Connected. De momento ninguno de los dos nodos ha asumido el rol de maestro (Primary), ya que es Pacemaker quien realiza dicha tarea:

Al comprobar el estado del cluster (mediante el comando crm_mon) podemos ver que Heartbeat ha conseguido conectar con el cluster. Sin embargo, los dos nodos aparecen OFFLINE todavía:

Pasados unos segundos, podemos ver como todos los recursos del cluster han sido iniciados (según el orden especificado a Pacemaker):

Podemos ver una ip virtual (ip1), el envío de un paquete ARP informando de la MAC correspondiente a dicha ip virtual (ip1arp), el montaje del volúmen DRBD (fs_nfs) y el servicio NFS (nfs). También podemos ver que el nodo 1 ha asumido el rol de maestro del cluster, y el nodo 2 de esclavo.

En las siguientes dos capturas, podemos ver el estado de DRBD en cada uno de los nodos:

Sesión 6

En la sesión 6, hemos configurado los servidores ESXi para que puedan conectarse contra el cluster NFS. Tras ello, utilizando el almacenamiento compartido NFS, hemos creado máquinas virtuales e instalado sistemas operativos en ellas, de forma que pueden funcionar simultáneamente. A continuación, podemos ver algunas capturas donde se muestra.

En la siguiente imagen podemos ver un cliente vSphere client a punto de conectar contra un servidor ESXi.

Durante la conexión, el servidor ESXi muestra su certificado, que ignoramos:

Una vez nos hemos conectado, hemos configurado un datastore NFS en el cluster NFS creado en la sesión anterior. Podemos aquí ver el datastore ya creado:

En la siguiente imagen se puede ver la configuración de un disco duro de una máquina virtual. Podemos observar como el disco duro reside en el datastore ClusterNFS creado anteriormente.

Después de crear la máquina virtual, hemos instalado Windows XP (por sus pocos requerimientos). En la siguiente imagen se puede observar la máquina virtual arrancada.

Sesiones 7 y 8

Las sesiones 7 y 8 las hemos dedicado a las siguientes tareas:

  1. Instalar un segundo servidor ESXi, al que llamaremos servidor ESXi-2.
  2. Crear una instancia del datastore NFS que creamos en las sesiones anteriores en este nuevo servidor.
  3. NOTA: tanto el servidor ESXi-1 y el servidor ESXi-2 tienen configurada una instancia del datastore NFS que hay en el cluster de servidores Debian.

  4. Instalar máquinas virtuales en ambos servidores ESXi.

Estas tareas no son diferentes a las que ya hemos hecho con anterioridad, aunque sí consumen tiempo (de ahí las sesiones). El gráfico siguiente (mostrado anteriormente) describe el objetivo de dichas sesiones:

Además, vamos a mostrar algunas imágenes del rack en este punto.

Sesiones 9 y 10

Las sesiones 9 y 10 han consistido en la instalación de vCenter Server, importación de los servidores ESXi y ejecución de vMotion, para mover máquinas de un servidor a otro sin pérdida se servicio.

Lo primero es instalar el vCenter Server. VMware ofrece dos alternativas. Una es utilizar un apliance virtual, basado en SUSE, que incorpora todo lo necesario (servicio vCenter y base de datos). La otra es utilizar un servicio instalable sobre Windows Server 2008 64 bits.

vCenter Server requiere licencia para su uso. La licencia de prueba es de 60 días. Nuestro centro no podrá asumir el coste de un servidor vCenter, pero podemos usar la licencia de 60 días para poder comprobar como funciona.

Instalación de vCenter Servar

Nuestra decisión, ha sido utilizar una máquina virtual con Windows Server 2008 R2 (que ya está corriendo en el cluster) para instalar sobre ella el software de vCenter Server. En definitiva, para ilustrar lo que vamos a hacer, exponemos el siguiente gráfico:

NOTA: Hay que tener en cuenta que el vCenter Server no va a estar en la misma VLAN que las otras máquinas virtuales, ya que debe poder comunicarse directamente con los servidores ESXi. Por eso, hemos creado un nuevo portgroup en los servidores ESXi que opera en la VLAN "VManagement", como se puede ver en la siguiente imagen.

Las siguientes imágenes corresponden a la instalación de vCenter Server sobre una máquina virtual con Windows Server 2008 R2. Las imágenes muestran el escritorio de dicha máquina.

Introducimos la imagen iso de vCenter Server en la unidad de CD/DVD de la máquina virtual.

Se abre el instaladir de vCenter Server.

Tras hacer clic sobre la opción "vCenter Server", elegimos el idioma. El español no está entre ellos, así que elegimos el inglés.

El software comienza a instalarse.

Se muestra el acuerdo de patentes y de licencia, que leemos "cuidadosamente".

Agregamos la información de cliente. De momento no hemos comprado una licencia, así que no introduciremos una clave, Esto implica que se instala en modo de evaluación.

vCenter Server soporte diferentes bases de datos, como Oracle 10g, 11g, IBM DB2 y SQL Server 2008. Sin emgargo ofrece la opción de instalar una instancia de SQL Server 2008 Express, que nos evita tener que usar un SGBD externo. Se recomienda utilizar esta última opción cuando se utilice una instalación pequeña, como en nuestro caso, que tenemos solamente dos servidores ESXi.

Es importante destacar que el inicio de sesión contra vCenter Server es ligeramente diferente al inicio de sesión contra un servidor ESXi. En este caso, se utilizará un usuario del sistema. Por eso, hay que identificar el FQDN de la máquina. En nuestro caso, se trata de una red aislada (en la VLAN 2), por lo que no es necesario utilizar un nombre de dominio real. Este nombre deberemos recordarlo, puesto que al iniciar sesión, lo haremos con el usuario vcenter\Administrador.

Como ya he comentado, en nuestra red aislada llamada VManagement no contamos con una DNS. El sistema, al intentar comprobar su nombre FQDN no puede resolver. Esto era de esperar. En cualquier caso, y como ya he comentado, dado que se trata de una red aislada, utilizaremos el archivo C:\Windows\system32\drivers\etc\hosts para la resolución de nombres.

Puesto que no contamos con otros servidores vCenter (ni los vamos a necesitar, puesto que nuestra instalación es muy pequeña), elegimos crear una instancia aislada.

Aceptamos los puertos que usará vCenter, salvo que tengamos otros servicios corriendo en dicho puerto. En nuestro caso, no hay ninguno de estos puestos ocupados, por lo que aceptamos.

Elegimos la opción que más se ajuste a nuestra instalación, para definir la cantidad de memoria que utilizará el servidor Tomcat para los servicio web de vCenter Server.

Comienza la instalación de vCenter.

Usando vCenter Server

Los pasos siguientes muestran la conexión contra vCenter Server y la importación de servidores ESXi.

Una vez instalado vCenter Server, podemos iniciar sesión contra el servidor vCenter Server. La IP del servidor Windows 2008 R2 que aloja el vCenter Server es 172.16.0.10. Como credenciales utilizamos el usuario local vcenter\Administrador y como contraseña la misma del usuario.

Una vez que nos hemos conectado, el asistente "Getting Started" nos ofrece un conjunto de sencillos pasos para configurar nuestra infraestructura, a saber:

  1. Crear un datacenter: asignaremos un nombre al datacenter para agrupar en él los servidores ESXi. La sugerencia de nuestro alumno Alberto Arenas fue "Odisea".
  2. Añadir hosts: añadiremos varios hosts ESXi, indicando su IP, usuario y contraseña especificados en la ESXi DCUI (Direct Console User Interface), es decir, en el mismo servidor ESXi.
  3. Añadir máquinas virtuales: en realidad, el servidor vCenter Server mostrará las máquinas que se ejecutan en cada servidor ESXi.

En esta imagen se puede ver como se añade uno de los nodos al servidor vCenter.

Una vez que se han añadido los nodos, vCenter Server muestra las máquinas en ejecución en cada nodo. En el instante de la captura, no había ninguna máquina en el servidor ESXi-2.

Activando vMotion

Lo último que nos habíamos propuesto en el grupo de trabajo era emplear con éxito la característica vMotion, para mover máquinas virtuales de un servidor ESXi a otro. Existen más características a probar, como FT y DVS, pero eso lo dejamos para otro grupo de trabajo, que este con "40 horas" ya dio de sí bastante.

Para que vMotion sea posible, es preciso activar dicha opción en un puerto de tipo VMkernel. En la documentación de vCenter Server se recomienda que se dedique una VLAN a esta característica. En nuestro caso, con una instalación tan pequeña no va a ser neceario. Por ello, solo es neceario activar vMotion en el puerto Management Network en ambos servidores ESXi.

Usando vMotion

Para mover una máquina de un nodo ESXi a otro mediante vMotion (migración), hay que seleccionar la opción "Migrate" del menú contextual de la máquina.

Después indicamos el nodo al que debe de moverse la máquina virtual. En nuestro caso, la máquina estaba ejecutándose en el nodo ESXi-1 (172.16.0.1), y lo vamos a mover al nodo ESXi-2 (172.16.0.2).

La documentación de vCenter Server recomienda dar alta prioridad a la migración vMotion.

vCenter Server muestra una barra de desplazamiento con el proceso de migración.

Y finalmente podemos ver como la máquina se está ejecutando en el nodo ESXi-2.

Y ya hemos terminado

Bueno, esto es todo. Este ha sido un grupo de trabajo muy ambicioso, teniendo en cuenta que lo hemos hecho todo en 10 sesiones de 4 horas cada una (con tropiezos incluidos), con mucha bibliografía que leer, y el poco tiempo que las clases dejan para el trabajo extra. Sin duda, lo mejor del grupo de trabajo será el uso que se le dará en el instituto, para consolidar todos los servidores que tenemos desperdigados, así como futuras aplicaciones, como virtualización de escritorio con LTSP. Pero esa es otra historia.

La bibliografía principal, ha sido la siguiente:

  • Manual de usuario del switch TL-SG3216_DS
  • VMware vSphere Basics. Editado por WMware
  • Highly Available NFS/MySQL/PostgreSQL Server on Ubuntu 10.04 LTS. http://library.linode.com
  • Intro to pacemaker on heartbeat. http://blog.foaa.de
  • A "Multivendor Post" to help our mutual NFS customers using VMware. http://communities.netapp.com.
  • Highly Available NFS Server Using DRBD And Heartbeat On Debian 5.0 (Lenny). http://www.howtoforge.com
  • [Guide] Configuring FreeNAS 8 NFS Share on VMware vSphere 5 (ESXi 5). http://www.mytricks.in
  • Pro Ubuntu Server Administration. 2009. Sander van Vugt. Ed. Apress.
  • Mastering VMware vSphere 5. Scott Lowe. 2011. John Wiley & Sons.
  • vSphere Installation and Setup. Editado por VMware
  • Highly available storage width DRBD and Pacemaker. 2011. Florian Haas. Editado por LINBIT.