Din�mica HA

Se considera din�mica HA a todas las reconfiguraciones del cl�ster que garanticen la m�xima disponibilidad del servicio de datos. Esta din�mica esta orientada a los nodos integrantes del cl�ster y la forma en la cual el cl�ster responde. Se denomina de la siguiente manera:

Failover

Es un t�rmino gen�rico que se usa cuando un nodo debe asumir la responsabilidad de otro nodo, importar sus recursos y levantar el servicio de datos. Se ha de entender que una situaci�n de failover es una situaci�n excepcional, para cual la alta disponibilidad ha sido concebida, el fallo de un nodo. Si s�lo queda un nodo en el cluster, tras los fallos de los dem�s, estaremos en un SPOF hasta que el administrador del sistema, verifique y restaure el cl�ster. Tambi�n se ha de entender que el servicio de datos sigue levantado, que es el objetivo de la alta disponibilidad.

Takeover

Es un failover autom�tico se produce cuando un nodo nota un fallo en el servicio de datos. Para ello debe haber cierta monitorizaci�n con respecto al servicio de datos. El nodo que se declara fallido es forzado a ceder el servicio y recursos, o simplemente eliminado.

Switchover o Giveaway

Es un failover manual, consiste en ceder los recursos de un servicio de datos y este mismo, a otro nodo del cl�ster, mientras se realizan ciertas tareas administrativas. A este procedimiento se le denomina "Node outage".

Splitbrain

Para la gesti�n de un cl�ster HA es necesario un mecanismo de comunicaci�n y verificaci�n entre nodos integrantes. Por este mecanismo, cada nodo debe gestionar los recursos que corresponden a cada uno, segun el estado del cl�ster; a su vez cada nodo debe hacer chequeos o latidos (beats) a sus compa�eros.

Un Splitbrain (divisi�n de cerebros) es un caso especial de failover, en el cual falla el mecanismo de comunicaci�n y gesti�n de un cl�ster de dos nodos. Es una situaci�n en la cual cada nodo cree que es el �nico activo, y como no puede saber el estado de su nodo compa�ero, tomar� acciones en consecuencia, forzando un takeover.

Esta situaci�n es peligrosa, los dos nodos intentaran apropiarse de todos los recursos, incluyendo el servicio de datos. El peligro aumenta sobre todo cuando tenemos recursos delicados, como recursos de almacenamiento, ya que cada nodo podr�a tomar y escribir por su cuenta, y quebrar a integridad de datos.

Para evitar este problema, cada nodo debe actuar de una forma prudente, y utilizar los recursos compartidos como se�al de que se esta vivo. La forma de proceder de cada nodo es similar, ya que cada uno cree que su compa�ero ha desaparecido. Despu�s de que un nodo aprecia este problema, tiene indicado que reserve un recurso llamado quorum. Un recurso quorum, es un recurso compartido, que se ha preestablecido en ambos nodos como tal. Este recurso es un recurso exclusivo, s�lo un nodo del cluster puede reservarlo. Como este recurso s�lo puede ser reservado por un nodo, el nodo que llegue tarde a la reserva del recurso, entiende que debe abandonar el cl�ster y ceder todos sus recursos. El qu�rum es utilizado como simplemete, m�todo de decisi�n.

Otra forma de evitar esta situaci�n, un poco mas violenta, es que un nodo elimine a su compa�ero; el primero que apague a su compa�ero se queda con todos los recursos. Es un mecanismo muy brusco, pero muy eficaz. Para este caso existen tarjetas especializadas en esta tarea.

Grupos de recursos de un servicio de datos

Pensando en un servicio de datos cualquiera, se puede pensar en unas serie de recursos que va a utilizar. Por ejemplo, imaginemos un servicio de datos de servicio web como puede ser apache, este va a necesitar un nodo donde va a ser ejecutado (ciclos de CPU, memoria), un sistema de ficheros donde guardar toda la informaci�n web y por supuesto una red donde poder responder a las peticiones de servicio. Estos recursos deben atender a cierta flexibilidad, donde la flexibilidad es la capacidad del recurso de ser est�tico virtualmente y ser din�mico f�sicamente. A continuaci�n se enumeraran los distintos tipos de recursos que son interesantes en un cl�ster HA.

Recursos computacionales

Los recursos computacionales pueden ser considerados a nivel de CPU, nodo o cl�ster. Son los recursos que permiten que el programa que se encarga de ofrecer servicio de datos pueda ser ejecutado. Si tenemos varias CPU, varios nodos o varios cl�sters estos deber�n tener una copia del programa del servicio de datos en memoria.

En la HA para Linux este recurso se considera a nivel de nodo, donde el servicio de datos va a estar situado en un nodo determinado (como m�ster del servicio). El software de alta disponibilidad es quien decide que nodo va a alojar que servicio de datos dependiendo del estado del cl�ster.

Recursos de comunicaciones

Normalmente el servicio de datos va a ser accedido mediante una red de comunicaciones. Las interfaces de red as� como la pila de protocolos de red, deben ser capaces de responder a varias direcciones de red con el fin de dar flexibilidad al servicio de datos; es decir virtualizar el servicio. En el caso de redes TCP/IP el servicio de datos sera accedido mediante una direcci�n IP y un puerto; para que el servicio de datos pueda residir f�sicamente en cualquier nodo se debe utilizar IP's virtuales (IP aliasing) para que esto sea posible.

Si se utiliza una red Ethernet-TCP/IP y el NIC (network interface card) no es capaz de cambiar la direcci�n MAC (media access controler), se puede llegar aun problema con las tablas ARP de los dem�s elementos de red; ya que se debe obligar a los clientes o routers de la LAN a actualizar la nueva direcci�n MAC para la IP de servicio.

Recursos de almacenamiento

El almacenamiento de los datos del servicio de datos es quiz�s uno de los puntos mas delicados de la alta disponibilidad. Pues en ellos tendremos la aplicaci�n que se usar� para el servicio de datos junto con los datos.

El almacenamiento suele ser el recurso mas complicado de virtualizar en configuraciones cl�sicas; ya que suele ser un medio SCSI compartido con muchos discos y muchos elementos candidatos a SPOF. En configuraciones hardware m�s modernas no hay tanta problem�tica; las arquitecturas SAN (storage area network) permiten que los recursos de computaci�n accedan por red SAN a los recursos de almacenamiento. Los recursos de almacenamiento suelen ser servidores de archivos en con discos en RAID y backup integrado con interfaz FiberChannel. Al estar en un entorno SAN permite acceder a estos recursos a m�s de un nodo de forma muy flexible.

El recurso de almacenamiento adem�s de ser flexible debe ser independiente para las necesidades de cada servicio de datos. Surge el concepto de grupos de vol�menes; un grupo de vol�menes es un conjunto de vol�menes que pertenecen a un servicio de datos en concreto. Cada volumen es un espacio de almacenamiento que el servicio de datos utilizar� para sus prop�sitos con independencia de otros vol�menes.

Es vital que el recurso de almacenamiento sea capaz de mantener la integridad de los datos y el tiempo de recuperaci�n ante un fallo sea m�nimo. Ante estos problemas surge las t�cnicas de journaling para la gesti�n de los datos.