Un clúster failover es un grupo independiente de servidores que trabajan de forma conjunta para incrementar la disponibilidad de las aplicaciones y servicios.
Si se produce un fallo en uno de los servidores se transfiere a otro el control del software para que el servicio continúe siendo ofrecido a los usuarios.
Recordemos que en el caso del clúster NLB teníamos unos clientes que conectaban a una IP virtual e iban balanceando hacia distintos servidores - estos servidores eran los nodos del clúster - estando todos estos nodos activos siempre.
En cambio, en el caso del clúster failover, esto cambia de forma radical, ya que solo uno de los nodos estará levantado. Así, al conectarse un cliente a una IP virtual, ésta será la puerta para que el clúster failover les redirija siempre al mismo nodo (el que está activo) ya que los demás nodos estarán de forma pasiva (no van a responder).
En el caso de que el nodo activo se caiga, cualquiera de los otros nodos del clúster (que están de forma pasiva) se levantarán y atenderán las peticiones.
Por ello un clúster failover diremos que dará alta disponibilidad, pero no escalabilidad.
Componentes del clúster failover
- Dirección IP virtual: será a la que accedan los clientes.
- Nodos: cada uno de los servidores que compongan el clúster failover.
- Clúster storage: Repositorio de información. Es donde se almacena la información necesaria para que cuando se transfiera de un nodo a otro el servicio de aplicaciones en caso de caída, pueda acceder el nuevo nodo a la información de manera que siempre la tenga actualizada.
- Servicio o aplicación: Es el servicio o aplicación que se va a ejecutar en el clúster.
- Redes: Serán las que interconecten los distintos nodos, para diagnosticar si estos están activos. También las que conecten a los clientes así como las que conectan al clúster storage.
Debemos tener en cuenta dos acciones:
- Failover: Se produce cuando uno de los nodos (el activo) falla, y los servicios y recursos pasan a otro (que estaba pasivo) quedando el caído a la espera de recuperarse del fallo.
El failover puede producirse por fallo en el hardware, porque falle un recurso o bien porque un administrador lo fuerce (failover programado).
- Failback: Se produce cuando la maquina que se había caído se recupera y vuelve a estar activa.
Redes del clúster failover:
- Publica: Los clientes usarán esta red para conectarse al servicio que le ofrece el clúster.
- Privada: Los nodos usarán esta red para comunicarse entre ellos. Tiene dos finalidades, una, saber si el nodo que está activo ha sufrido alguna caída y en segundo lugar, hacer la transferencia de servicios y aplicaciones a los nodos pasivos.
- Almacenes externos: usada para comunicarse con los sistemas de almacén externos, que es donde se almacena la información necesaria para que, en caso de haber failover, el nodo que pasa a ser activo, encuentre toda la información necesaria y actualizada, tal y como lo dejó el nodo que provocó la caída.
Debemos tener en cuenta distintos aspectos respecto a las redes del clúster failover. uno de ellos es que podemos utilizar la misma red a nivel físico y enlace tanto para la red externa como para la interna, es decir, podemos usar la misma red para comunicarnos con los clientes y los nodos entre si, pero es muy recomendable que esto no sea así, si no que se usen dos redes distintas, una externa para comunicarnos con los clientes y la interna para que los nodos se comuniquen entre si (por ello es necesario al menos dos tarjetas de red por nodo).
Además deberíamos tener una tercera tarjeta de red si usásemos ISCSI en la comunicación de los nodos con el clúster storage (red de almacenes de datos) y debería ser también una red independiente a nivel físico y enlace.
Almacenamiento externo del clúster failover.
Un clúster failover necesita de un almacenamiento externo en el que exista la información con la suficiente consistencia de datos, de manera que el servidor virtual después de que realice la acción de failover (pasivo a activo) encuentre la información necesaria y actualizada, para ello usamos el clúster storage.
Hay distintas opciones para configurar el clúster storage:
- Interfaz de transferencia de datos en serie SCSI (SAS). No es muy recomendable ya que deberemos tener tarjetas SCSI así como discos externos que soporten esta tecnología y, además los nodos deben estar próximos entre si como marca el estándar SCSI.
- ISCSI: SCSI bajo IP. Funciona bastante bien en sistemas Windows ya que tenemos la parte servidora (el ISCSI target) como la parte cliente (ISCSI initiator).
- Fiber Channel: Quizá sea la más recomendada pero también la más cara y además requiere de personal especializado en este tipo de almacenamientos a la hora de la instalación, lo que hace que se dispare el coste.
- Discos duros virtuales compartidos (VHDX): A partir de Windows Server 2012 es posible tener discos duros virtuales.
El Quorum.
El servicio de clusterización debe saber cuando un clúster es capaz de dar los servicios para los que se diseñó. Es una especie de "consenso" y en función de los recursos que tiene el clúster (nodos, carpetas compartidas, clúster storage) saber en todo momento si es capaz o no de dar el servicio.
Es una especie de sistema de votos. Cada miembro (cada nodo) tiene un voto, si está activo, se le asignará un voto positivo, si por el contrario no está activo, no tendrá voto. La suma de todos los votos tendrá que ser la suficiente para que el sistema determine que le puede suministrar los servicios al cliente.
CSVs (Cluster Shared Volumes)
Los CSVs permiten que más de un nodo, (incluso los pasivos) accedan a la vez a los discos compartidos.
Beneficios:
- Se requieren menos discos, ya que los discos compartidos pueden ser accedidos incluso estando en modo pasivo.
- Mejor uso del espacio de discos.
- Podemos centralizar todos los recursos respecto a discos en una sola localización física y ya no tendríamos la necesidad de tener varios discos para guardar los recursos que necesita cada uno de los nodos.
- No se requiere hardware adicional, es decir, no necesitamos más discos.
Roberto García (@1GbDeInfo)
