En los clústeres de sustitución tras error N + I (activo/pasivo) con Windows Server 2003 R2 Enterprise Edition, algunos grupos de recursos pueden entrar en
conflicto con otros grupos si se ejecutan en el mismo nodo. Por ejemplo, ejecutar más de un servidor virtual de Microsoft Exchange en el mismo nodo puede
generar conflictos entre aplicaciones. Utilice Windows Server 2003 R2 Enterprise Edition para asignar una propiedad pública (o atributo) a una dependencia
entre grupos a fin de garantizar que éstos realizarán la sustitución tras error para nodos parecidos o separados. Esta propiedad pública se denomina afinidad
de grupo.
La afinidad de grupo utiliza la propiedad pública AntiAffinityClassNamesValues, que garantiza que los recursos designados se ejecuten en nodos distintos, si es
posible.
Por ejemplo, en la tabla 1-5, las cadenas AntiAffinityClassNamesValues para el grupo de recursos de clúster A y B son idénticas (AString), lo que indica que
estos grupos están asignados para ejecutarse en nodos distintos, si es posible. Si falla el nodo 1, el grupo de recursos A cederá las funciones al siguiente
nodo de reserva (nodo 4).
Para definir la propiedad pública para los grupos de clúster que se muestran en la tabla 1-5:
1. Abra un indicador de comandos.
2. Escriba lo siguiente:
cluster group "A" /prop AntiAffinityClassNames="AString"
3. Repita el
paso
2 para los demás grupos del clúster.
Utilice el Formulario de datos del clúster de este documento para especificar la afinidad de grupo en la configuración del clúster N + I.
Par de sustitución tras error
El par de sustitución tras error es una política en la que cada aplicación puede realizar la sustitución tras error entre dos nodos específicos en un clúster de
varios nodos. La lista Posibles propietarios del Administrador de clústeres determina en qué nodos se ejecutarán las aplicaciones después de la sustitución
tras error.
Es fácil planificar y administrar esta solución, y las aplicaciones que no funcionen bien en el mismo servidor pueden trasladarse fácilmente a pares separados
de sustitución tras error. Sin embargo, en los pares de sustitución tras error, las aplicaciones del par no pueden admitir dos errores del nodo.
En la ilustración 1-5 se muestra un ejemplo de una configuración de par de sustitución tras error. En la tabla 1-6 se ofrece una configuración de sustitución
tras error para el clúster que se muestra en la ilustración 1-5.
Ilustración 1-5. Ejemplo de una configuración de par de sustitución tras error
Tabla 1-6. Ejemplo de una configuración de par de sustitución tras error para un clúster de cuatro nodos
Grupo de recursos del clúster
Lista de posibles propietarios
Aplicación 1
1, 2
Aplicación 2
3, 4
Sustitución tras error multivía
La sustitución tras error multivía es una política activo/activo en que las aplicaciones que se estaban ejecutando en un nodo que ha fallado se migran a varios
nodos del clúster. Esta solución proporciona sustitución tras error y equilibrio de carga automáticos. Debe asegurarse de que los nodos de sustitución tras
error tienen recursos suficientes para soportar la carga de trabajo. En la ilustración 1-6 se muestra un ejemplo de una configuración de sustitución tras error
multivía de cuatro nodos.
En la tabla 1-7 se muestra una configuración de sustitución tras error multivía de cuatro nodos para el clúster de la ilustración 1-6. Para cada grupo de
recursos, el orden de la sustitución tras error en la lista Propietarios preferidos del Administrador de clústeres indica el orden en el que desea que los grupos
de recursos realicen la sustitución tras error. En este ejemplo, el nodo 1 es propietario de las aplicaciones A, B y C. Si el nodo 1 falla, las aplicaciones A, B y C
ceden sus funciones a los nodos del clúster 2, 3 y 4. Configure las aplicaciones de forma parecida en los nodos 2, 3 y 4.
Al implementar la sustitución tras error multivía, configure la recuperación tras error para evitar una disminución del rendimiento. Para obtener más
información, consulte Uso de
MSCS.
Ilustración 1-6. Ejemplo de una configuración de sustitución tras error multivía de cuatro nodos