O lo que es lo mismo, cómo evitar que dos máquinas virtuales coincidan en el mismo nodo de un cluster. Esto puede tener ciertas aplicaciones para aumentar la alta disponibilidad y la tolerancia a fallos de lo que quiera que sea que este corriendo por encima. Por ejemplo:

• Controladores de dominio. No queremos que, por ejemplo, los dos que tenemos se caigan juntos si lo hace el nodo sobre el que están corriendo.
• Nodos de clusteres virtuales. Tampoco queremos que los dos nodos de un cluster virtual corran sobre le mismo nodo del cluster físico. De este modo, un fallo de un nodo físico
• Nodos de granjas NLB. Puede interesarnos que los frontales de una granja estén siempre los más repartidos posible entre los nodos físicos, de modo que la caída de uno de ellos afecte lo menos posible a la carga de trabajo que pude asumir el conjunto.
• Reparto de la carga de trabajo (CPU, IO, red…). Puede que tengamos algunas VMs muy pesadas, y queremos que no lleguen a coincidir en un mismo nodo en la medida de lo posible.
• Etc.

Esto obviamente se puede hacer solo si tenemos más de dos nodos en el cluster, y generalmente se logra mediante la configuración de los “Possible Owners” del grupo. A mayor número de nodos, más podemos confiar en que de este modo disminuya la probabilidad de que ciertos grupos coincidan en el mismo host.

Si queremos un mayor grado de control podemos usar una propiedad pública que puede tener todo grupo de cluster llamada AntiAffinityClasNames. Dicha propiedad puede almacenar un cierto numero de cadenas de caracteres que actúan a modo de etiquetas de modo que si en ese nodo está corriendo un grupo con una etiqueta coincidente, pasaremos al siguiente “possible owner”. Se especifica mediante este simple comando:

• cluster group "<group name> /prop AntiAffinityClassNames="<value1>"," <value2>"

Siguiendo los ejemplos anteriores supongamos que en un cluster tenemos dos VMs que son dos controladores de dominio, que están definidas en dos grupos de cluster llamados DC1 y DC2. Además, DC2 es también a su vez un nodo de un cluster virtual de tres nodos, nodo1, nodo2 y DC2 (estupenda mala idea, pero si no no me sale el ejemplo). Entonces:

• cluster group "DC1" /property AntiAffinityClassNames="NoAjuntoAOtroDC"
• cluster group "DC2" /property AntiAffinityClassNames="NoAjuntoAOtroDC",”NoAjuntoAOtroNodo”
• cluster group "nodo1" /property AntiAffinityClassNames=”NoAjuntoAOtroNodo”
• cluster group "nodo2" /property AntiAffinityClassNames=”NoAjuntoAOtroNodo”

De este modo, DC1 y DC2 evitarán coincidir porque tienen "NoAjuntoAOtroDC" y nodo1, nodo2 y DC2 también se evitarán porque tienen ”NoAjuntoAOtroNodo”.

Es importante mencionar que aquí la palabra evitar no significa una prohibición total. Es decir, en caso de ser necesario, en última instancia los grupos pueden acabar por levantarse en el mismo nodo. Basta con probarlo en un cluster con solo dos nodos. La propiedad no evita el failover en ningún caso al no existir mas posibles propietarios que el único nodo que queda vivo.

La descripción exacta del comportamiento del sistema de failover, un artículo un poco más extenso sobre todo esto, y la descripción de la propiedad AntiAffinityClasNames se pueden encontrar en estos enlaces:

• http://support.microsoft.com/kb/296799/en-us
• http://support.microsoft.com/kb/299631/en-us
• http://windowsitpro.com/articles/print.cfm?articleid=101276
• http://msdn.microsoft.com/en-us/library/aa369651(VS.85).aspx

Como reza el título, esto vale para cualquier tipo de grupo de recursos de cluster, y no solamente para VMs en HA. Huelga decir que estamos hablando de tolerancia a fallos. Los movimientos de maquinas virtuales entre nodos, manuales o automáticos, pueden llegar a tener una riqueza en su control mucho más fina.

Saludos

David Cervigón