Cluster de Servidores Unix: la implementación

Una vez determinado que íbamos a implementar un cluster del tipo Activo – Pasivo con dos servidores Unix HP idénticos (ver blog) nos informamos sobre la solución de HP al respecto… se llama Service Guard, su filosofía me gustó mucho y funciona de la siguiente manera:

Service Guard de HP:

La idea de Service Guard es la de tener una red de servidores en la cual se definan los servicios necesarios (por ejemplo DNS, DHCP, Oracle, Apache, etc.) y en que servidores se desean que estén activos o pasivos.

Ejemplo:

Se desean tener los servicios de DNS, DHCP, Apache, Application Server, Oracle y MySQL bajo un esquema de Cluster Activo – Pasivo. Los servicios podrían estar distribuidos de la siguiente manera:

Servidor 1: DNS y DHCP

Servidor 2: Apache y Application Server

Servidor 3: Oracle

Servidor 4: MySQL

Pero también hay que definir que servidor tomaría las funciones de un servidor que se haya caído, así por ejemplo se podría tener:

Servidor 1:

Servicios Activos: DNS y DHCP

Servicios Pasivos: Oracle

Servidor 2:

Servicios Activos: Apache y Application Server

Servicios Pasivos: MySQL

Servidor 3:

Servicios Activos: Oracle

Servicios Pasivos: DNS y Apache

Servidor 4:

Servicios Activos:  MySQL

Servicios Pasivos: DHCP y Application Server

Así que si se cae el servidor número 2, los servicios de Apache levantarían en el servidor 3 y los de Application Server en el 4.

Con esta filosofía, siempre habría un servidor dispuesto a levantar servicios que se hayan caído del servidor que habitualmente los tiene. Esto Service Guard lo implementa mediante “paquetes” en los cuales se configura el servicio que tiene que vigilar, donde tiene que levantar en caso de caída, el script para arrancar un servicio dado, la IP relacionada, etc.

Claro está que, en caso de una caída, los servicios pueden tardar minutos en levantar en el servidor pasivo (dependerá de lo complicado de levantar esos servicios), por lo tanto este esquema es aceptable para el caso de negocios que pueden estar sin funcionar por un espacio de tiempo que se mida en minutos y no en segundos. Si la criticidad del negocio lo ameritara, claramente se tendrá que implementar un esquema Activo – Activo.

El caso nuestro fue bastante simple ya que los servicios a mantener eran tres únicamente: Oracle 10g, Oracle Application Server 10g y MySQL.

Se adquirieron dos servidores iguales:

·         HP rx3600 con un CPU Itanium cada uno (y posibilidad de un segundo)

·         8GBytes de memoria RAM (que tuvimos que ampliar al poco tiempo a 16)

·         4 discos SAS de 146GBytes cada uno

·         2 tarjetas de Fibra cada uno para acceder la SAN (un EVA4100)

·         4 tarjetas de red 10/100/1000 cada uno

·         HP UX 11i

La configuración de Service Guard fue:

Servidor 1:

Servicios Activos: Oracle AS 10g, MySQL

Servicios Pasivos: Oracle 10g

Servidor 2:

Servicios Activos: Oracle 10g

Servicios Pasivos: Oracle AS 10g, MySQL

La parte curiosa del asunto fue la relativa al acceso a la SAN, factor esencial ya que era necesario, obviamente, compartir los mismos datos entre los dos servidores: yo pensaba que la partición de la SAN a compartir simple­mente se vería por ambos servidores al mismo tiempo… algo parecido a cuando se comparte una carpeta en servidores Windows: en el momento que alguien crea un archivo en ella, inmediatamente el cambio es visto por los demás que la acceden. Eso es válido en una carpeta compartida en la red, pero no en una partición de la SAN que, para todos los efectos, es un disco local!

Total que aprendí que se definen las particiones en la SAN que serán usadas por cada servidor EN MOMENTO DISTINTOS es decir, cuando el servidor que la necesita está con el servicio en modalidad de “Activo”. El paquete de Service Guard es el que se encarga de activarla en el momento adecuado… de esta manera nunca hay dos servidores viendo la misma partición al mismo tiempo… hermoso!

Otra cosa interesante de los paquetes de Service Guard, es que tienen asociada una IP, con eso se logra que los clientes no tengan que ser reconfigurados: ellos siempre referencian a la misma IP (o idealmente a un nombre resuelto en un servidor DNS) y ésta es la que viaja de un servidor a otro de acuerdo a donde el servicio esté activo!

Claro que al tener una configuración como ésta, ya no se puede ser tan feliz a la hora de bajar un servicio ya que, a menos que se le indique lo contario a Service Guard, éste interpretará que se cayó el servicio y lo tratará de levantar en el otro servidor! Claro está que Service Guard viene con una batería de comandos para comunicarse y configurar los paquetes y evitar estos efectos dañinos.

Lo importante del caso es que se logró el objetivo propuesto: se pusieron en Alta Disponibilidad tres de los servicios más importantes de la organización, así las operaciones de manutención de los servidores fueron mucho más simples de llevar a cabo puesto que los servicios se detenían por tiempos muy cortos.