Cluster de Alta Disponibilidad para Virtualizar los Servidores de Adquisición y Procesamiento de Datos del Instituto Geofísico

Full text

Wilson A. Acero, Jorge A. Aguilar, y R. David Mejía
wacero@igepn.edu.ec, jorge.aguilar@epn.edu.ec, david.mejia@epn.edu.ec
Resumen — Un cluster de alta disponibilidad permite
garantizar que los servicios que un sistema informático brinda
estén disponibles aunque un fallo de hardware o software
suceda. Este documento presenta de forma resumida el
diseño e implementación de una solución de alta
disponibilidad basada en Pacemaker para brindar alta
disponibilidad a los sistemas de adquisición y procesamiento
del Instituto Geofísico: SeisComp3, Earthworm y ShakeMap.
La solución está formada por dos clusters: el primero al
que se denomina clusterwa es un cluster de alta disponibilidad
del tipo activo/activo formado por tres servidores físicos. Este
cluster administra tres servidores virtuales KVM y los
módulos de los sistemas de adquisición y procesamiento que
fueron instalados y configurados en los servidores virtuales.
El segundo es un cluster de almacenamiento del tipo
activo/pasivo al que se denomina clusteralmawa formado por
dos servidores físicos. Este cluster administra un dispositivo
de almacenamiento replicado que utiliza tecnología DRBD;
este dispositivo contiene los discos duros de los tres
servidores virtuales KVM.
Pacemaker monitoriza y controla, mediante agentes de
recursos, el funcionamiento de los servidores físicos, de los
servidores virtuales y de los módulos que forman los sistemas
mencionados y en caso de detectar alguna falla de hardware
o software Pacemaker realiza las acciones necesarias, en base
a políticas y reglas configuradas por el administrador, para
que los sistemas operen sin interrupción. 1.
Index Terms — Cluster de alta disponibilidad, Pacemaker,
DRBD, virtualización.
I. INTRODUCCIÓN
Que un sistema esté disponible significa que el usuario
puede acceder a los servicios que el sistema brinda, dentro del
período de tiempo que se supone que el sistema esté en
funcionamiento [1]. Alta disponibilidad implica maximizar el
tiempo de funcionamiento del sistema, o lo que es lo mismo
disminuir el tiempo de caída y el tiempo de recuperación,
1W.A. Acero participó en el proyecto por el Instituto Geofísico de la
Escuela Politécnica Nacional (e-mail:wacero@igepn.edu.ec).
J.A. Aguilar trabaja en el Instituto Geofísico de de la Escuela Politécnica
Nacional en el área de sistemas (e-mail:jaguilar@igepn.edu.ec)
D.M. Mejía trabaja en la Escuela Politécnica Nacional en el Departamento
de Electrónica, Telecomunicaciones y Redes de Información (e-
mail:david.mejia@epn.edu.ec).
eliminando puntos únicos de falla mediante redundancia de
hardware, redundancia a nivel de red, planes de recuperación
ante desastres, entre otros [2].
Los servicios que los sistemas de adquisición y
procesamiento de datos que el Instituto Geofísico (IG) ofrece a
la comunidad, requieren alta disponibilidad ya que en caso de
una erupción volcánica o un evento sísmico, las alertas y
reportes generados por estos sistemas permitirían reducir el
impacto negativos de estos fenómenos en la población. Es
posible brindar alta disponibilidad a los sistemas del IG
instalándolos en un cluster de alta disponibilidad.
Un cluster de alta disponibilidad es un conjunto de
computadores o nodos que se comunican entre sí y trabajan
con el objetivo de hacer que los recursos que el cluster ejecuta
funcionen ininterrumpidamente , Pacemaker es una solución
de código abierto que permite implementar un clúster de alta
disponibilidad, este software se encarga de monitorizar el
estado de los nodos que forman el clúster y de los recursos que
el clúster ejecuta, para lo que utiliza programas conocidos
como agentes de recursos; en caso de detectar una falla en un
recurso o en un nodo Pacemaker coordina las acciones a
realizar de acuerdo a las políticas del clúster y a las reglas
configuradas para cada recurso [3].
Para tener redundancia a nivel de nodos físicos el clúster de
alta disponibilidad clusterwa cuenta con tres nodos físicos,
lo que permite que si uno de los nodos falla, los recursos que
éste ejecutaba puedan activarse en los dos nodos restantes.
El clúster de alta disponibilidad necesita de un
almacenamiento compartido que permita que todos los nodos
tengan acceso a los mismos datos de forma simultánea [4].
Para evitar que el almacenamiento se convierta en un punto
único de falla se ha utilizado la tecnología de replicación de
datos DRBD (Distributed Replication Block Device), la que
permite replicar los datos entre dos servidores físicos. Estos
servidores forman el clúster de almacenamiento
clusteralmawa.
A fin de evitar la corrupción del almacenamiento
compartido se ha utilizado un dispositivo de control de
alimentación eléctrica que permite apagar de forma remota los
nodos de un cluster, este procedimiento se conoce como
fencing, y Pacemaker lo utiliza para apagar un nodo si el
mismo pierde conectividad luego de un período de tiempo
determinado.
Cluster de Alta Disponibilidad para Virtualizar
los Servidores de Adquisición y Procesamiento
de Datos del Instituto Geofísico

II. CLUSTERS DE ALTA DISPONIBILIDAD
A fin de estudiar los componentes de un cluster de alta
disponibilidad se los agrupa en 4 capas que se presentan a
continuación [5]:
1. Almacenamiento compartido del cluster
Como se indicó anteriormente en un cluster de alta
disponibilidad es necesario que todos los nodos del cluster
tengan acceso a un almacenamiento común para que si falla
un nodo que ejecuta alguna aplicación, la misma pueda
levantarse en otro nodo del cluster y tenga acceso a los
mismos datos.
Para que el almacenamiento compartido del cluster de alta
disponibilidad no se convierta en un único punto de fallo, el
mismo debe ser del tipo replicado, en donde mediante
software los datos escritos en un almacenamiento primario se
replican a un almacenamiento secundario, en Linux es posible
utilizar la tecnología de código abierto DRBD para conseguir
este objetivo [6]. DRBD permite que los datos de un disco, al
que se denomina dispositivo drbd, se replican entre dos o
más servidores, uno de los cuales actúa como servidor
primario y el otro como secundario, pudiendo el secundario
tomar el lugar del primario en caso que éste falle, sin embargo
para que el cambio de roles sea automático la tecnología
DRBD debe implementarse sobre un cluster, es decir que para
que la capa de almacenamiento de un cluster de alta
disponibilidad no se convierta en un punto único de fallo, la
capa de almacenamiento debe ser un cluster de alta
disponibilidad del tipo activo/pasivo.
Adicionalmente para que el dispositivo drbd de cada
servidor DRBD no represente un único punto de falla, es
posible utilizar tecnología RAID (Redundant Array of
Independent Disk) la cual permite la replicación de datos entre
múltiples discos de un mismo computador. Es posible
implementar RAID a nivel de hardware o software; en los
sistemas operativos Linux es posible utilizar el programa md
para implementar RAID 1 el cual a más de brindar
redundancia tiene un buen desempeño en cuanto a velocidades
de lectura y escritura.
Para que los nodos del cluster de alta disponibilidad puedan
acceder al dispositivo drbd se utiliza la tecnología iSCSI
(internet Small Computer System Interface), la cual permite
que un dispositivo de almacenamiento de un servidor,
funcione como un dispositivo de almacenamiento local en otro
servidor conectado mediante una red de tipo Gigabit Ethernet
o fibra. iSCSI puede describirse como un protocolo
cliente/servidor, pero para evitar confusiones se emplea el
término target para el servidor e initiator para el cliente.
El target iSCSI es el computador que tiene un dispositivo
de almacenamiento, conocido como LUN (Logical Unit
Number), al que el cliente o initiator puede acceder y escribir
en este dispositivo como si se tratara de un disco local. El
software por defecto para implementar un target en Linux es
el del proyecto LIO (Linux-IO) [7].
El initiator iSCSI es el cliente que accede a la LUN iSCSI,
el software empleado por defecto como initiator en sistemas
Linux es el desarrollado por el proyecto Open-iSCSI.
En un cluster de alta disponibilidad el acceso al
almacenamiento compartido es del tipo activo/activo, es decir
que múltiples nodos acceden simultáneamente y de forma
ordenada al mismo, lo que posibilita que todos los nodos del
cluster ejecuten recursos simultáneamente. Un
almacenamiento de este tipo necesita contar con un sistema de
archivos de tipo cluster, como por Global File System (GFS2)
[4].
GFS2 es un sistema de archivos para cluster que tiene como
característica principal permitir el acceso coordinado de los
nodos de un cluster al mismo dispositivo de bloque. GFS2
ofrece compartición de datos entre los nodos GFS2 del cluster
con una vista consistente del sistema de archivos a lo largo de
todo el cluster, lo que permite que procesos ejecutándose en
diferentes nodos compartan archivos GFS2 como si fueran
archivos de un sistema local. Sus características más
importantes son [8]:
 Soporta dispositivos de hasta 100 TB en sistemas de
64 bits, y 16 TB en sistemas de 32 bits.
 Permite agregar nuevos nodos de forma dinámica.
 Soporta un máximo de 16 nodos.
Para garantizar la integridad del sistema de archivos se
recomienda utilizar GFS2 sobre un volumen lógico del tipo
cluster, empleando CLVM (Cluster Logical Volume Manager)
[8], la cual es una versión para cluster del sistema de
administración de volúmenes lógicos (LVM) que permite que
un volumen lógico de almacenamiento pueda ser utilizado
simultáneamente por varios nodos de un cluster.
2. Software de administración del cluster
Permite que un grupo de computadoras o nodos funcionen
como un cluster, sus tareas son enviar mensajes entre los
nodos que son parte del cluster, determinar si el número de
nodos de los que dispone el cluster es suficiente para
funcionar (quórum) y determinar si un nodo pertenece o no al
cluster (membership) [4].
Esta capa se implementa en Linux mediante el software de
código abierto Corosync el cual ofrece una forma segura y
confiable de enviar mensajes entre los nodos del cluster
enviando mensajes UDP desde uno de los nodos al resto de
computadores (multicast), permite además la utilización de
enlaces de red redundantes [3], lo que consiste en combinar
dos o más interfaces de red para formar una interfaz de red
lógica, con el objetivo de conseguir redundancia o aumentar el
rendimiento de la interfaz [9].
3. Software de administración de recursos del cluster
Como su nombre lo indica es el software encargado de
activar, detener y monitorizar el estado de los servicios que un
cluster ejecuta. En base al estado de los nodos del cluster y
políticas y reglas configuradas previamente, el software de
administración de recursos toma decisiones para garantizar el
funcionamiento continuo de los servicios. El administrador de
recursos por defecto en Linux es Pacemaker, sus principales
características son:

 Detección y recuperación de fallas a nivel de nodo o
servicio.
 No requiere que un recurso tenga características
especiales, si el servicio puede manejarse usando scripts
puede ser administrado por Pacemaker.
 Soporta dispositivos fencing para asegurar la
integridad de los datos.
 La configuración se replica de manera automática
desde cualquier nodo al resto de nodos del cluster.
 Permite realizar clonación de servicios, a fin de que un
recurso esté activo en múltiples nodos.
Pacemaker está formado por varios componentes [10]:
 Cluster Information Base (CIB): es un archivo que
contiene toda la información sobre el cluster:
configuración, estado de los nodos, el estado de los
recursos que se están ejecutando, etc.
 Policy Engine (PE): este módulo revisa el contenido
del CIB y determina que acciones hay que realizar para
que el cluster alcance el estado descrito en el CIB, como
por ejemplo migrar un recurso, apagar un nodo, etc.
 Cluster Resource Manager (CRM): este módulo
comunica las órdenes del PE a los módulos encargados de
la administración de recursos en cada nodo del cluster.
 Local Resource Manager (LRM): su trabajo es
controlar y monitorizar los recursos a nivel local, de
acuerdo a las órdenes que recibe del módulo CRM.
Entre otras tareas Pacemaker está encargado de revisar que
es seguro migrar los recursos que un nodo fallido ejecutaba
hacia otro nodo del cluster, para lo que emplea la tecnología
denominada fencing, también conocido como STONITH, que
consiste en utilizar un dispositivo que permite controlar de
forma remota la alimentación eléctrica de un computador,
cuando un nodo deja de responder a los mensajes del cluster
luego de un tiempo determinado Pacemaker decide asegurarse
que el nodo está apagado y corta su alimentación, para
después migrar sus recursos a otro nodo, evitando que exista
una posible corrupción de los datos del almacenamiento
compartido.
Pacemaker permite implementar varios tipos de clústers
[11], los que se utilizaron en el proyecto fueron el cluster de
alta disponibilidad activo/pasivo, el cual es el más sencillo de
implementar y consiste de dos nodos, denominados activo y
pasivo, el pasivo funciona como respaldo del nodo activo y
solo se activa si éste deja de funcionar. En este tipo de cluster
no es necesario que el almacenamiento compartido tenga un
sistema de archivos del tipo cluster, ya que los nodos no
necesitan acceder simultáneamente al almacenamiento [9].
El segundo tipo cluster utilizado se denomina cluster de alta
disponibilidad tipo activo/activo: en esta configuración dos o
más nodos ejecutan los recursos a los que el cluster da alta
disponibilidad, para este tipo de configuración es necesario
disponer de un almacenamiento compartido con un sistema de
archivos tipo cluster. Cuando se tienen más de dos nodos esta
configuración se conoce como cluster de alta disponibilidad N
a N, ya que los servicios se reparten entre los N nodos que
forman el cluster si un nodo falla cualquiera de los nodos
restantes puede tomar su lugar.
La instalación y configuración de un cluster Pacemaker
puede hacerse empleando una interfaz web o mediante el
programa pcs (Pacemaker Cluster Shell), el cual es una
interfaz de línea de comandos que permite crear un cluster,
agregar nodos, agregar recursos, configurar las reglas de
comportamiento del clúster y de los recursos, ver el estado del
clúster en tiempo real, etc.
4. Agente de recursos
En un cluster de alta disponibilidad un recurso es un
componente lógico o físico, como por ejemplo una dirección
IP, una base de datos o un sistema de archivos, etc., a los
recursos también se los conoce como servicios. En un cluster
de alta disponibilidad basado en Linux, es necesario que un
recurso pueda detenerse, activarse y monitorizarse mediante
programas conocidos como agentes, con el objetivo de
automatizar su administración. Un agente de recursos es un
script o programa que actúa como interfaz entre el recurso y
Pacemaker. Pueden escribirse en cualquier lenguaje de
programación, pero lo común es que sean scripts que se
ejecutan en la consola de Linux, y que permitan realizar
operaciones como start, stop, status, etc. sobre un programa.
Existen varios tipos de recursos que se presentan a
continuación:
 Recursos primitivos: son recursos que no están
agrupados, como por ejemplo un recurso de tipo dirección
IP, un recurso de tipo base de datos, etc.
 Recursos agrupados: son varios recursos primitivos
que deben cumplir un orden en su ejecución y hacerlo en
un mismo nodo, un ejemplo de un recurso de este tipo
podría ser un servidor web, que estaría formado por un
recurso de tipo dirección IP y por un recurso de tipo
servidor web.
 Recurso clon: es un tipo especial de recurso que puede
estar activo en más de un nodo a la vez, como por ejemplo
un sistema de archivos de tipo cluster.
 Recurso de tipo maestro/esclavo (master/slave): es un
tipo especial de recurso clon, en el que uno de los nodos
que ejecuta el recurso clon adquiere el rol activo, mientras
que el otro nodo que ejecuta el recurso se encuentra en
estado de espera y adquiere el rol activo solamente si el
otro nodo falla.
Pacemaker permite administrar adicionalmente recursos que
se ejecuten en un servidor virtual, lo que se consigue mediante
el programa Pacemaker Remote [4], este programa permite
instalar los componentes de Pacemaker en un computador
virtual, sin que el mismo forme parte del quórum del cluster,
pero con la posibilidad de ejecutar y monitorizar recursos que
el servidor virtual ejecuta.
La virtualización de servidores, es una tecnología que
permite ejecutar un sistema operativo sobre una plataforma de
hardware virtual, lo que permite que en un solo servidor físico
puedan ejecutarse simultáneamente varios computadores con
diferentes sistemas operativos [12]. Para implementar la
virtualización existen varias soluciones de código abierto, pero

al momento Pacemaker Remote es compatible solamente con
KVM (Kernel-based Virtual Machine) [4].
KVM es una solución de virtualización que convierte a un
sistema operativo Linux en un administrador de máquinas
virtuales, en las que es posible ejecutar sistemas operativos
Linux o Windows. KVM necesita ejecutarse en servidores con
procesadores que soporten tecnología de virtualización.
KVM permite mover un servidor virtual de un nodo físico a
otro, sin que sea necesario apagar el servidor virtual, esta
característica se denomina migración en caliente, y puede
implementarse solamente si el disco duro del servidor virtual
se encuentra en un almacenamiento compartido al que los dos
nodos físicos involucrados en la migración puedan acceder.
III. DISEÑO E IMPLEMENTACIÓN DE LA SOLUCIÓN
En esta sección se presentan los puntos principales del
diseño y la implementación realizados. En la Figura 1 se
presenta un diagrama del cluster de almacenamiento
clusteralmawa, como puede verse el cluster dispone de
redundancia a nivel de red, para lo que cuenta con dos
conmutadores y con interfaces de red enlazadas, sin embargo
en esta configuración solamente una de las interfaces está
activa mientras que la otra actúa como respaldo.
Figura 1. Diagrama del cluster de almacenamiento implementado. La
redundancia a nivel de red se obtuvo enlazando las interfaces de red y
empleando dos conmutadores Ethernet.
Cada nodo del clúster dispone de tres discos, en uno de
ellos se instala el sistema operativo CentOS versión 7, con los
otros dos discos duros de 500 GB se creó mediante software
un disco RAID 1, al que se denomina /dev/md1.
El disco RAID 1 se utilizó para crear un disco replicado
DRBD denominado /dev/drbd0, este disco se replica de
forma síncrona entre los dos nodos que forman el cluster de
almacenamiento, a través de las interfaces de red Gigabit
Ethernet enlazadas. La velocidad de sincronización del
dispositivo DRBD es de 31,792 K/s.
El dispositivo DRBD se utiliza para crear un target y una
LUN iSCSI. Una vez instalado el software del cluster,
Pacemaker y Corosync, se configura el cluster, en primer
lugar se agrega el dispositivo de fencing compatible con
Pacemaker [13], posteriormente se agrega el dispositivo
DRBD como un recurso del tipo maestro/esclavo, mientras
que el dispositivo iSCSI se agrega como un recurso agrupado
formado por el target iSCSI, la LUN iSCSI y una dirección IP
a la que los nodos del clúster de alta disponibilidad se
conectarán para acceder a dispositivo iSCSI.
En la Figura 2 se puede observar el estado del cluster de
almacenamiento y los recursos creados.
De acuerdo a las reglas configuradas si Pacemaker detecta
que el nodo con el rol maestro falla, sus recursos se activarán
en el nodo disponible.
Figura 2. Estado del cluster de almacenamiento, existen dos nodos y seis
recursos el dispositivo drbdwa se ejecuta con el rol máster en el nodo
iscs1, así como el recurso grupal grupiSCSI.
En la Figura 3 se presenta un diagrama del cluster de alta
disponibilidad clusterwa, el cluster consta de tres nodos,
en cada uno de ellos se instala el sistema operativo CentOS
versión 7; a fin de separar el tráfico del cluster y el tráfico de
los clientes que acceden a los sistemas de adquisición cada
nodo dispone de cuatro interfaces de red, las interfaces de red
se enlazan de dos en dos para formar interfaces del tipo bond,
una de las interfaces enlazadas se utilizan para la red de las
máquinas virtuales, mientras que la otra interfaz enlazada se
emplea para las comunicaciones del cluster y para acceder al
recurso iSCSI del cluster de almacenamiento.
Switch Ethernet 1
Clúster de Alta
Disponibilidad
Switch Ethernet 2
bond0 bond0
PACEMAKER + COROSYNC
iscs1
Disco
RAID 1
CentOS 7
iscs2
Disco
RAID 1 CentOS 7
DRBD activo
Target iSCSI
DRBD
secundario
LUN iSCSI

Cliente
nodo1 nodo2
Switch Ethernet 1
Clúster de Alta Disponibilidad
Switch Ethernet 2
nodo3
bond1 bond1 bond1
bond0 bond0 bond0
Almacenamiento
Compartido
Switch Ethernet 3
Switch Ethernet 4
Figura 3. Diagrama del cluster de alta disponibilidad implementado. Para
garantizar la redundancia de red cada nodo dispone de cuatro interfaces
de red, dos destinadas a la red interna del cluster y dos destinadas a la
conexión con los clientes.
Figura 4. Estado del cluster de alta disponibilidad, existen tres nodos
físicos y tres nodos remotos (máquinas virtuales) en los que se ejecutan
los recursos agrupados seiscomp, earthworm y shakemap que
corresponden a los sistemas de adquisición del IGEPN.
Luego de instalar y configurar el software del cluster, se
agregó el dispositivo de fencing y los recursos
correspondientes para agregar la capa del almacenamiento
compartido: se agregó la LUN iSCSI, la cual se utilizó para
crear un volumen LVM tipo cluster, el cual se usó para crear
un sistema de archivos GFS2, los tres dispositivos se
agregaron al cluster como recursos tipo clon, es decir, que
tanto la LUN iSCSI, el volumen LVM y el sistema de archivos
GFS2 están montados simultáneamente en los tres nodos del
cluster de alta disponibilidad.
Una vez terminado este procedimiento el cluster de alta
disponibilidad esta completo.
En los tres nodos se instaló la plataforma de virtualización
KVM, luego se crearon tres servidores virtuales
vmseiscomp, vmearth y vmshake en los que se
instalaron y configuraron los sistemas de adquisición y
procesamiento SeisComP3, Earthworm y ShakeMap,
respectivamente.
En el servidor vmshake se instalaron los tres sistemas de
adquisición de tal forma que sirva de respaldo de los otros dos
servidores. En la Figura 4 se presenta el estado del cluster y
los recursos configurados hasta el momento.
IV. PRUEBAS Y RESULTADOS
En esta sección se presentan las pruebas realizadas y los
resultados obtenidos.
Se realizaron pruebas a cada una de los componentes del
almacenamiento compartido. La primera prueba se realizó
sobre el disco RAID 1 virtual. Mediante el comando de
administración del RAID, mdadm, se simuló la falla de uno de
los discos físicos que forman el RAID [11]. Como se indica en
la Figura 5 el dispositivo RAID continúa con su
funcionamiento normal, sin que el resto de componentes que
dependen del disco RAID hayan sido afectados.
Figura 5. Estado del disco virtual RAID 1 luego de simular la falla de uno
de los discos físicos. Como puede verse el dispositivo continúa con su
funcionamiento normal.
A continuación se presenta la prueba de disponibilidad del
dispositivo DRBD y del target iSCSI, para simular el error del
nodo con el rol maestro se desconectó su fuente de
alimentación, el cluster al percatarse de la pérdida de uno de
los nodos aplica fencing al nodo caído y levanta los servicios
en el nodo disponible, como se indica en la Figura 6, mientras
que en los nodos del cluster de alta disponibilidad se detectó
una pérdida de conectividad que no afectó a las operaciones
del cluster, como se indica en la Figura 7.

Figura 6. Detección de la caída del nodo iscs1 y cambio de rol DRBD
secundario al rol DRBD primario del nodo iscs2.
Figura 7. Reporte de pérdida de conectividad con el target iSCSI y
recuperación en uno de los nodos del cluster de alta disponibilidad.
En la TABLA I se indican los resultados de las pruebas
realizadas para determinar la velocidad de escritura en los
niveles del almacenamiento compartido.
TABLA I
VELOCIDADES DE ESCRITURA EN LOS NIVELES DEL ALMACENAMIENTO
COMPARTIDO
Nivel del almacenamiento
compartido
Velocidad de escritura (MB/s)
Disco duro físico
85
Disco RAID 1 virtual
83
Disco DRBD
80
Disco iSCSI
64
Sistema de archives GFS2
58
Discos duros virtuales
32
Las pruebas que se realizaron en el cluster de alta
disponibilidad se realizaron para determinar la capacidad del
cluster de administrar los servidores virtuales y recuperarse
ante fallas de los nodos físicos o de los servidores virtuales.
Figura 8. Proceso de migración en caliente del servidor virtual vmearth,
entre del nodo1 al nodo2, el proceso de migración demora tres segundos
en completarse.
La primera prueba se realizó para determinar la capacidad
del cluster de migrar un servidor virtual en caliente, la prueba
se realizó utilizando la consola de administración pcs para
desconectar temporalmente a un nodo del cluster, lo que
genera que las máquina virtuales de ese nodo tengan que
migrar a los nodos restantes del cluster. En la Figura 8 se
presenta el procedimiento seguido por el cluster para mover el
servidor vmearth del nodo1 al nodo2.
En la siguiente prueba se simuló el fallo de uno de los
nodos del cluster, a fin de determinar la capacidad del cluster
para reiniciar los servicios que el nodo ejecutaba. Para simular
la falla se desconectó la fuente de alimentación del nodo que
ejecutaba el servidor virtual vmearth, cuando el cluster
detectó la ausencia del nodo3, notifica al resto de nodos y
mediante el dispositivo de fencing se asegura que el nodo esté
realmente apagado, tal como se indica en la Figura 9. En
cuanto al servidor virtual vmshake que se ejecutaba en el
nodo3, Pacemaker se da cuenta que el recurso no puede
ejecutarse en ese servidor, por lo que luego de que la
operación de fencing se ha completado ordena que la máquina
virtual vmshake arranque en uno de los nodos disponibles,
en este caso el nodo1, como se indica en la Figura 10.
Figura 9. Detección de la pérdida del nodo3. El cluster al detectar que el
nodo ha perdido conectividad cortará su alimentación para asegurarse
que el nodo está apagado.
Figura 10. Recuperación del servidor virtual vmshake luego del fallo del
nodo físico en el que se ejecutaba. Para evitar que el servidor virtual se
ejecute en dos nodos físicos, Pacemaker se asegura que el nodo en el que
el servidor virtual se ejecutaba está apagado mediante fencing, luego de
esto ya puede activar el servidor virtual en otro nodo sin que exista riesgo
de corromper los datos del almacenamiento compartido.

La última prueba se realizó con el sistema de adquisición y
procesamiento SeisComP3, para esto se detuvo el servidor
virtual vmseisc en el que el sistema SeisComP3 se
ejecutaba, lo que hizo que Pacemaker activara el recurso
agrupado seiscomp en el servidor virtual vmshake, en la
Figura 11 se presenta el proceso de migración del recurso
ipsc3, la migración del resto de recursos del grupo es
similar.
Figura 11. Migración del recurso ipsc3 del servidor virtual vmseisc al
servidor virtual vmshake. El recurso ipsc3 es el primero del recurso
agrupado seiscomp, una vez que este recurso migre el resto de recursos
del grupo migran automáticamente al servidor virtual vmshake.
Para comprobar que la pérdida de los servicios que
SeisComP3 brinda es mínima se utilizó el programa scrttv,
el cual es un cliente que se conecta a uno de los módulos de
SeisComP3 para solicitar formas de onda y graficarlas en
tiempo real. En la Figura 12 se indica que scrttv pierde
conectividad con el programa pero la recupera en tres
segundos, mientras que en la Figura 13 se presenta la captura
de pantalla del programa scrttv en la que la pérdida de
conectividad no es visible.
Figura 12. Pérdida y recuperación de la conexión del programa scrttv y el
sistema SeisComP3. Entre la detección del error y la recuperación
transcurren 3 segundos.
Figura 13. Captura de pantalla del programa scrttv durante la prueba de
alta disponibilidad. La pérdida de conectividad es tan pequeña que no se
percibe gráficamente.
Por último se presentan la pruebas realizada en la red del
cluster. La prueba consistió en desconectar uno de los
conmutadores de la red de comunicaciones para que los
enlaces pasivos del conmutador de respaldo se activen sin que
por esta falla el funcionamiento del cluster se vea afectado. En
la Figura 14 se presenta el resultado de esta prueba, como
puede verse el sistema operativo del nodo1 detecta que las
interfaz física em1, que formaba parte de la interfaz enlazada
bond0, dejó de funcionar, y de forma inmediata activa la
segunda interfaz física em2. El resto de nodos del cluster
realiza las mismas tareas sin que se haya perdido conectividad
en ningún instante, como se indica en la Figura 15 en la cual
se presentan los resultados de la ejecución del comando ping
realizado desde otro computador hacia el nodo1.
Figura 14. Resultado del test de redundancia del conmutador. El sistema
operativo del nodo1 detecta la falla y toma las acciones necesarias para
que el enlace bond0 continúe funcionando sin interrupciones.
Figura 15. Resultado de la ejecución del comando ping hacia el servidor
físico nodo1. Como puede verse no existió pérdida de conectividad en el
tiempo que le tomó al sistema operativo activar la interfaz de red de
respaldo.
V. CONCLUSIONES
La tecnología DRBD utilizada en el presente Proyecto, ha
sido fácil de instalar y de configurar, ha demostrado tener un

buen funcionamiento y una rápida recuperación ante fallas,
además ha permitido agregar una capa de redundancia a nivel
de almacenamiento, sin tener que emplear soluciones
propietarias similares en funcionalidad pero con costos
bastante elevados.
Las tecnologías DRBD y iSCSI junto con el administrador
de recursos de cluster Pacemaker constituyen el cluster de
almacenamiento. El servicio con alta disponibilidad que este
cluster brinda es un dispositivo de almacenamiento y garantiza
que aunque uno de los dos servidores DRBD falle, la LUN
iSCSI esté siempre disponible, lo que permite que las
operaciones del cluster de alta disponibilidad no se vean
afectadas y los servidores virtuales sigan brindando sus
servicios sin presentar ninguna interrupción, y en el caso de
situaciones más graves, minimizar los tiempos de caída.
El software de administración del cluster Pacemaker
permite, mediante la aplicación de reglas y políticas
configuradas por el administrador, automatizar la
monitorización y administración de los servicios que un
sistema brinda, es decir que en caso que un recurso falle, el
software del cluster se percata de este evento y hace lo
posible por levantar nuevamente el recurso. En los casos en
que no puede recuperarse ante un fallo, el software se encarga
de apagar el recurso con errores y aquellos que dependan del
mismo, pudiendo incluso apagar el nodo en el que el recurso
se ejecutaba a fin de evitar errores más graves como por
ejemplo la corrupción del sistema de archivos.
El dispositivo de fencing utilizado ha funcionado bastante
bien y cumplido con los requerimientos requeridos por el
cluster, el dispositivo es compartido por el cluster de alta
disponibilidad y el cluster de almacenamiento y permite
controlar el encendido o apagado de los nodos de ambos
clusters, este dispositivo es tan importante que sin el mismo no
sería posible implementar de forma segura el cluster de alta
disponibilidad ni el cluster de almacenamiento.
VI. TRABAJOS FUTUROS
Sería posible agregar recuperación ante desastres al cluster
de alta disponibilidad mediante la adición de un tercer servidor
al cluster de almacenamiento DRBD que se encuentre en un
área física alejada del Instituto Geofísico. La información se
replicaría al tercer nodo DRBD y en caso de un desastre en el
edificio en el que se encuentra el instituto, los datos de las
máquinas virtuales aún estarían disponibles para su posterior
recuperación
A fin de mejorar la velocidad de replicación de datos entre
los servidores DRBD sería posible emplear una red exclusiva
para este fin o inclusive emplear cable UTP categoría 5 o
superior, sin embargo cada nodo del cluster de
almacenamiento requeriría dos interfaces de red adicionales, a
fin de garantizar redundancia.
La implementación de un almacenamiento iSCSI
empleando una red Giga Ethernet tiene un desempeño que
cumple con los requerimientos del presente Proyecto, sin
embargo para aplicaciones que requieran mayores velocidades
de escritura sería necesario emplear iSCSI sobre enlaces
Infiniband o enlaces de fibra.
REFERENCIAS
[1]
K. Schmidt, High Availability and Disaster Recovery. Frackfurt:
Springer, 2006.
[2]
Red Hat, Inc. (2014) Red Hat Enterprise Linux 6 High Availability
Add-On Overview. [Online].
https://access.redhat.com/documentation/en-
US/Red_Hat_Enterprise_Linux/6/html/High_Availability_Add-
On_Overview/index.html
[3]
S. van Vugt, Pro Linux High Availability Clustering. USA: Apress,
2014.
[4]
Red Hat, Inc. (2015) Red Hat Enterprise Linux 7 High Availability
Add-On Overview. [Online].
https://access.redhat.com/documentation/en-
US/Red_Hat_Enterprise_Linux/7/pdf/High_Availability_Add-
On_Overview/Red_Hat_Enterprise_Linux-7-High_Availability_Add-
On_Overview-en-US.pdf
[5]
F. Haas, "Ahead of the Pack: The Pacemaker High-Availability Stack,"
Linux Journal, vol. 216, no. 04, pp. 98-107, Apr. 2012.
[6]
F. Haas, "Replicate Everything! Highly Available iSCSI Storage with
DRBD and Pacemaker," Linux Journal, vol. 217, no. 05, pp. 106-118,
May 2012.
[7]
T. Cameron. (2014, Apr.) Next-generation High Availabiltiy Linux
Clustering. [Online].
http://people.redhat.com/tcameron/Summit2014/cameron_t_120_next-
gen_HA_linux_clustering/cameron_t_120_next-
gen_HA_linux_clustering.pdf
[8]
Red Hat, Inc. (2015) Red Hat Enterprise Linux 7 Global File System 2.
[Online]. https://access.redhat.com/documentation/en-
US/Red_Hat_Enterprise_Linux/7/pdf/Global_File_System_2/Red_Hat
_Enterprise_Linux-7-Global_File_System_2-en-US.pdf
[9]
Red Hat, Inc, Red Hat Enterprise Linux 7 Networking Guide. EEUU,
2014.
[10]
T. Roth, SUSE Linux Enterprise High Availability Extension. EEUU:
Novell, Inc., 2013.
[11]
A. Beekhof. (2012) Pacemaker Clusters from Scratch. [Online].
http://clusterlabs.org/doc/Cluster_from_Scratch.pdf
[12]
M. Portnoy, Virtualization Essentials. EEUU: Sybex, 2012.
[13]
Red Hat, Inc. (2014) Fence Device and Agent Information for Red Hat
Enterprise Linux. [Online]. https://access.redhat.com/articles/28603
Wilson A. Acero
Egresado de la carrera en Ingeniería Electrónica y Redes de Información,
Escuela Politécnica Nacional (EPN) en Quito-Ecuador en 2016. Actualmente
trabaja en el Instituto Geofísico de la Escuela Politécnica Nacional.
Jorge. A. Aguilar
Físico por la Escuela Politécnica Nacional (EPN), Quito-Ecuador (1994).
Estudios de posgrado en Informática por la UASB (1996); Magister en SIG
por la USFQ (2006). Jefe Área de Tecnologías de la Información del
Instituto Geofísico; docente de la Facultad de Ingeniería de la PUCE y de
Geología de la EPN.
Raul. D. Mejía
Obtuvo el título de Ingeniero en Electrónica y Redes de Información, en la
Escuela Politécnica Nacional en Quito – Ecuador, en 2005. Obtuvo el título de
Magister en Multimedia y Comunicaciones en la Universidad Carlos III de
Madrid en España en 2011. Actualmente se desempeña como Profesor
Agregado a Tiempo Completo en el Departamento de Electrónica,
Telecomunicaciones y Redes de Información.