Recuperación ante desastres: dos centros de datos activos

El modelo de implementación que se muestra a continuación puede implementarse para garantizar tanto la alta disponibilidad como la recuperación ante desastres. Aquí, ambos nodos de Orchestrator están activos y el equilibrador de carga dirige el tráfico hacia ellos utilizando un algoritmo específico, como Round Robin o una de sus variantes.

Esta configuración requiere una buena conexión de red entre los centros de datos, ubicados en diferentes áreas geográficas. El modelo puede implementarse en las instalaciones o basado en la nube. Para la implementación en la nube, deberás elegir diferentes regiones para las ubicaciones primaria y secundaria.

Nota:

Este modelo de implementación requiere lo siguiente:

• SQL Server 2012, o posterior, y High Availability Add-on para Orchestrator. Las versiones anteriores de SQL Server no son compatibles con AG, y Redis de código abierto no es compatible con una configuración activa-activa.
• Two .

Para proporcionar la alta disponibilidad para el equilibrador de carga de red (si el NLB está ubicado en el centro de datos primario), deberá proporcionarse un NLB secundario en el centro de datos de recuperación ante desastres. Los dos NLB deben colocarse en una configuración primaria-secundaria (o maestro-esclavo).

En el mismo centro de datos, puede utilizarse un NLB con diferentes servidores virtuales (VIP) para Ochestrator y Elasticsearch. Este mismo NLB puede utilizarse para distribuir las cargas de forma óptima entre los nodos de Orchestrator y Elasticsearch.

La característica del Grupo siempre disponible puede estar compuesta de un mínimo de 2 máquinas:

• BD primaria en el primer centro de datos;

• BD secundaria en el segundo centro de datos.

  Nota: Se necesita un mínimo de tres nodos tanto para HAA como para Elasticsearch en cada centro de datos, ambos configurados en diferentes grupos y sincronizados.

Consulta aquí los prerrequisitos, las restricciones y las recomendaciones para el Grupo siempre disponible.