Microsoft Cluster MSCS 2003 - Conceptos típicos de Microsoft Cluster

A continuación comentamos los conceptos que utilizaremos habitualmente al trabajar con un Cluster MSCS, conceptos con los que debemos familiarizarnos:

• Nodo (Node). ¿Qué es un Nodo en Microsoft Cluster (MSCS)? Denominaremos Nodo a cada uno de los servidores miembros del Cluster. Deben ser miembros del mismo domino, ejecutar la misma versión de Sistema Operativo, y a poder ser, idénticos en lo relacionado al Hardware (mismos modelos de servidor con mismas prestaciones y características). Es posible tener un Cluster de un Nodo, por ejemplo, para ofrecer un servicio con independencia de la máquina subyacente, o también para pruebas. También es posible agregar Nodos y quitar nodos (Evict Node) del Cluster, si en un futuro nos resulta necesario. Por ejemplo, en caso de desastre y ante la pérdida de un nodo que no podemos recuperar, le hechamos de cluster (Evict Node) y agregamos un nuevo Nodo (esto lo he probado con máquinas reales y funciona... palabrita de MCSE !! ;-).
• Recurso (Resource). ¿Qué es un Recurso en Microsoft Cluster (MSCS)? Denominaremos Recurso a cualquier componente Hardware (ej: Disco) o Software (ej: Dirección IP, Nombre de Red, Servicio, etc.) que nos interese "clusterizar" (coño con el spanglish ! ;-). Cada Recurso tendrá disponible unas propiedades u otras, dependiendo del qué tipo de recurso de trate.
• Grupo de Recursos (Resource Group). ¿Qué es un Grupo de Recursos en Microsoft Cluster (MSCS)? ¿Qué es una Dependencia en Microsoft Cluster (MSCS)? Los Recursos como tal, no tienen vida propia. Necesitamos crear un Grupo de Recursos, dónde agregar los Recursos que necesitemos, y configurar sus Dependencias. Por ejemplo, habitualmente un Recurso de tipo Nombre de Red (Network Name) siempre tiene una dependencia con un Recurso de tipo Dirección IP. Una vez que tenemos un Grupo de Recurso, podremos instalar la aplicación que deseemos (ej: Microsoft SQL Server o Microsoft Exchange) y configurar en dicho Grupo de Recursos el resto de Recursos de la nueva Aplicación (ej: los servicios de Windows). Realizado todo esto, podremos poner Online (Bring Online) el Grupo de Recursos, con lo que se pondrán en marcha todos sus Recursos (y en consecuencia se iniciarán los servicios de nuestra Aplicación). Se debe tener en cuenta, que un Grupo de Recursos es la únidad básica de ejecución en Microsoft Cluster (MSCS), de tal modo que un Grupo de Recursos se puede ejecutar en un Nodo del Cluster o en otro Nodo del Cluster, pero sólo en un Nodo a la vez. Por ésto, suele interesar crear múltiples Grupos de Recursos para distribuir los servicios de nuestro Cluster, y así poder distribuir la carga de trabajo entre los distintos Nodos y rentabilizar mejor nuestro hardware y software. Un Grupo de Recursos, es el equivalente al concepto de Paquete de HP ServiceGuard.
• Servidor Virtual (Virtual Server). ¿Qué es un Servidor Virtual en Microsoft Cluster (MSCS)? Habitualmente, en cada Grupo de Recursos, agregamos un Recursos de tipo Dirección IP u otro de tipo Nombre de Red con una dependencia al anterior. Luego, agregamos discos, servicios, etc. Al final, conseguimos construir un Servidor Virtual, ya que el Recurso de tipo Nombre de Red, nos permite acceder a dicho nombre a través de la red como si se tratarse de un Servidor Físico, y no es así, pues depende en qué Nodo del Cluster se esté ejecutando el Grupo de Recursos, las peticiones serán servidas por una máquina u otra (perdón, por un Nodo u otro). El problema de este concepto, es que puede provocar confusión con el mismo térmiso en otras tecnologías (Virtual Server, IIS, etc.).
• Quorum. ¿Qué es el Disco de Quorum? ¿Para qué sirve el Disco de Quorum? Todos los Clusters utilizan un Grupo de Recursos para el Quorum. Aquí encontraremos el Disco de Quorum, vital para el funcionamiento de Microsoft Cluster. Este disco, contiene el directorio MSCS, que contiene un Log interno para el funcionamiento del Cluster (cambios de configuraciones, etc.), y que realiza un papel muy importante dentro del Cluster, evitando que se produzca el Síndrome del Cerebro Partido (Split Brain), etc. Con vistas a configurar el Disco de Quorum, en Windows Server 2003 tenemos varias posibilidades:
  • Shared Quorum. Configuración habitual, dónde todos los Nodos pueden acceder a un único disco compartido (shared disk) utilizado para Quorum. Se utiliza en los entornos Microsoft Cluster convencionales, dónde existe una almacenamiento compartido conectado físicamente a todos los nodos del Cluster, ya sea a través de una red de almacenamiento SAN por fibra o por Ethernet (iSCSI), o una cabina de discos compartida (de esas antiguas SCSI, ahora dignas de museo). Suele implicar que todos los Nodos del Cluster se encuentran físicamente en la misma ubicación, o bien, en ubicaciones separadas pero comunicadas por redes rápidas de comunicaciones y almacenamiento SAN.
  • Local Quorum. Se utiliza un almacenamiento local para el Quorum (por defecto, %SystemRoot%\Cluster\MSCS), en lugar de un disco compartido. Esta solución, se utiliza en Clusters de un sólo Nodo, propios de Laboratorios de Pruebas, o como mecanismo de abstracción de los nombres físicos de las máquina (se ofrecen los servicios a través del Cluster: abstracción de las máquinas subyacentes, aunque sin Alta Disponibilidad). No requiere de Discos Compartidos (Shared Disks) ni de complicados sistemas de replicación.
  • MNS - Majority Node Set (Quorum basado en Mayorías). Nuevo en Windows Server 2003, basado en la disponibilidad de Mayorías o mayoría absoluta de Nodos. En este caso, no existe una ubicación centralizada para el almacenamiento de la información de Quorum. Por el contrario, cada nodo del cluster almacena localmente una copia del contenido del Quorum (por defecto, en %systemroot%\cluster\ResourceGUID), es decir, existe un Quorum físicamente distribuido, de tal modo que el servicio de Cluster garantiza que la información de Quorum se mantiene consistentemente en todos los Nodos del Cluster: si la configuración del Cluster cambia, dichos cambios son replicados a todos los Nodos del Cluster, considerando que dicho cambio se ha aplicado con éxito cuando esté aplicado en la mayoría de los Nodos del Cluster, que matemáticamente toma el valor de (número de Nodos del Cluster / 2) + 1 (de aquí el término de MNS: Quorum basado en Mayorías) . Algo similar ocurre durante el inicio del Cluster: el servicio de Cluster no se levantará hasta que estén disponible la mayoría de los Nodos. Esto implica, que sea necesario un mínimo de 3 Nodos en un Cluster con Quorum MNS, excepto que se instale el hotfix 921181 y se habilita FSW (File Share Witness), de tal modo, que se pueda utilizar un recurso compartido adicional (por ejemplo, ofrecido por una tercera máquina ajena a dicho Cluster) que permita arbitrar y así soportar una configuración de Quorum MNS sobre un Cluster de 2 Nodos. En cualquier caso, la utilización del Quorum MNS sólo tiene sentido cuando los discos compartidos del Cluster se utilizan sobre soluciones de replicación, como es el caso de sistemas de almacenamiento SAN con replicación síncrona que muestren los discos replicados como discos compartidos (ej: SRDF/CE de EMC u otras soluciones propietarias de fabricantes), o el conocido caso de la solución CCR (Cluster Continuous Replication) incluída en Exchange Server 2007 y basada en sincronización asíncrona por medio de entrega del Log (Log Shipping). Este tipo de soluciones de Quorum MNS y replicación de datos suele emplearse en entornos de GeoCluster ó Cluster Geográficamente Distribuidos, al tratarse de entornos dónde las soluciones Cluster basadas en discos compartidos resultan inviables o problemáticas.

Ahora podemos entender mejor el hecho de que en un Cluster MSCS siempre existe al menos un Grupo de Recursos para el Quorum. Del mismo modo, para cada Servicio que deseemos ofrecer, será interesante crear un nuevo Grupo de Recursos, y así podamos tener múltiples Grupos de Recursos para distribuirlos entre los distintos Nodos, evitando con esto tener un Nodo vago (un Nodo que no hace nada, pero que representa un coste económico para la empresa).