Unos de los desafíos que ha querido afrontar Microsoft con Windows Server 20012, sobre el Servicio de Failover Cluster, ha sido los distintos estados que nos podemos encontrar que comprometían al Servicio Cluster. Algunos de estos estados pueden ser; que algún nodo pueda estar en estado offline por que tengamos que hacer algún proceso de actualización, y por tanto vamos a perder productividad a nivel del cluster. Se nos puede caer un nodo de forma inesperada por un fallo del sistema operativo, del hardware, o incluso por una interrupción del suministro eléctrico. Nos podemos encontrar también con la problemática de que nuestro sistema de comunicación entre los distintos nodos de un cluster se vea afectado. Otro problema que puede pasar es que el Quorum (disco testigo de la infraestructura) pueda caer. Puede que necesitamos añadir o eliminar un nodo a nuestro cluster, etc…
Todos estos estados que se van produciendo en lo largo de la vida de un cluster, van afectado de forma directa o indirecta a la infraestructura. Uno de los principales responsable del correcto funcionamiento de esta infraestructura es el Quorum. Y por esto Microsoft nos da varias modalidades de configuración o modo de trabajo con el Quorum, cada modalidad se adaptará a un escenario concreto.
En un Cluster, el Quorum es quien se va a encargar de que todos los nodos trabajen de forma controlada, y de que ninguno tome posesión o intente proporcionar un servicio para el cual no esta autorizado en cada momento.
El objetivo del Quorum en Windows Server 2012, es que nos sea mucho mas sencillo el decidir que tipo de Quorum vamos a utilizar o configurar. Otro objetivo que se ha conseguido, es que ha mejorado la disponibilidad del cluster, ya que el cluster puede sobrevivir con tan solo un nodo activo, gracias a la novedad de Quorum dinámico.
Podemos tener diferentes configuraciones de cluster:
Nos podemos encontrar una configuración de cluster basada en nodos única y exclusivamente, sin un disco testigo (sin elemento arbitrario que pueda tomar decisiones a parte de la de los propios nodos…) Con este tipo de configuración, en caso de caída de algún nodo, para que el servicio se siga dando, es necesario que continúen (o se tengan vivos) un número de nodos superior al 50% del total de los nodos. En el caso de tener 4 nodos, solo se permite la caída de 1 de ellos para que el servicio se mantenga, ya que si para este caso, cayesen más de 1 nodo, no se daría servicio…
Por el contrario, si trabajamos con una solución de testigo, no se necesita tener vivos un número de nodos superior al 50% del total de los nodos, para que el servicio continúe dándose. En el caso de tener 4 nodos, y ante la caída de dos nodos, el cluster sigue operativo.
¿Cuando usar Testigo?
La diferencia en usar testigo o no usarlo, es en el número de nodos que se necesitan activos, para que el servicio permanezca activo.
Cuando el número de nodos es pares, se aconseja usar testigo.
Cuando el número de nodos es impar, no se necesita usar testigo.
Si tenemos configurado un testigo, cuando el número de nodos es impar, no hay ningún tipo de problema, es total mente compatible.
¿Tipo de Testigos?
Hay dos tipos; de disco o de recurso de red. Son las dos tipos de modalidades que existen, y cada una nos exige unos requisitos, y nos dan unas ventajas e inconvenientes diferentes en los distintos tipos de escenarios que nos podemos encontrar…
Con un testigo de tipo DISCO, tenemos que tener una LUM (en cabina) dedicada para el Quorum, aquí se guardará una copia lo mas actualizada posible del estado del cluster. Cada equipo cuando balancea cualquier recurso, tiene que actualizarlo… Este DISCO, con 512 Mb de capacidad es suficiente (aunque no deja de ser recomendable poner un poco mas). El sistema de fichero que ha de tener, ha de ser NTFS o RFS (RFS es el nuevo sistema de archivos que proporciona Windows Server 2012). En Win2012 no necesariamente se necesita una unidad de letra asignada a este disco, con el objetivo de no quitar una letra posible a la infraestructura para las unidades… Cada nodo tendrá acceso a una copia actualizada de la bd del cluster, lo que hará posible, que en caso de que permanezca vivo un solo nodo y se caigan todos los demás, este único nodo sea capaz de tener la información del estado del cluster para recuperar los recursos. En caso de la caída de todos los nodos, el cluster se puede recuperar de forma automática, al arrancar cualquiera de los nodos…
Si lo que vamos, es a una solución de testigo, basada en una carpeta compartida, recurso compartido, tiene otro tipo de cosas a tener presentes, ya que es más fácil de implementar, y no necesitamos de solución de cabina para proporcionar este tipo de almacenamiento. Vamos a poder utilizar, un único servidor de archivos para distintos cluster que tengamos, y hay que tener presente que este recurso no puede estar ubicado en los nodos del mismo cluster, ha de estar en un servidor ajeno al mismo, (si es posible tener dos cluster y que cada uno sirva para albergar el testigo del otro cluster). No mantiene una copia actualizada de la base de datos del cluster, y se tiene que fiar de la copia que tiene cada uno de los nodos, no tiene por que haber problemas, pero en ocasiones tiene menos fiabilidad según para que recursos clusterizados. En caso de la caída de todos los nodos, el cluster no se puede recuperar de forma automática… Lógicamente, esta solución genera algo de más tráfico en la red, ya que tiene que estar accediendo al recurso compartido…
Configurar el Quorum del cluster
Para configurar el Quorum del cluster, podemos hacerlo mediante dos formas. Una de ellas es el asistente de la interface grafica, que nos hará 3 preguntas para definir el tipo de Quórum con el que se va ha trabajar
Y la otra forma, es hacerlo con PowerShell...
Apunte y recopilación por Norman M. Pardell
