Información general sobre clústeres extendidos

  • Artículo

Se aplica a: Azure Stack HCI, versiones 22H2 y 21H2

Una solución de clúster extendido de Azure Stack HCI para la recuperación ante desastres proporciona conmutación automática por error para restaurar la producción rápidamente y sin necesidad de intervención manual. La réplica de almacenamiento proporciona la replicación de volúmenes entre sitios para la recuperación ante desastres y mantiene todos los servidores sincronizados.

La réplica de almacenamiento admite la replicación sincrónica y asincrónica:

  • La replicación sincrónica refleja los datos entre sitios en una red de baja latencia con volúmenes coherentes frente a bloqueos para garantizar que no se pierdan datos en el nivel del sistema de archivos durante un error.
  • La replicación asincrónica refleja los datos en sitios más allá de los intervalos metropolitanos a través de vínculos de red con latencias más altas, pero sin una garantía de que ambos sitios tienen copias idénticas de los datos en el momento de un error. Si la replicación se completa antes del error, el volumen de destino se conecta automáticamente después de la conmutación por error. Si la replicación está en proceso en el momento del error, debe conectar manualmente el volumen de destino.

Hay dos tipos de clústeres extendidos: activo-pasivo y activo-activo. Puede configurar la replicación del sitio activo-pasivo, donde hay un sitio y una dirección preferidos para la replicación. La replicación activa-activa es donde la replicación puede producirse de forma bidireccional desde cualquier sitio. En este artículo solo se trata la configuración activa-pasiva.

En términos simples, un sitio activo es uno que tiene recursos y proporciona roles y cargas de trabajo con los que los clientes se conectan. Un sitio pasivo es el que no proporciona roles o cargas de trabajo para clientes y está esperando una conmutación por error del sitio activo para la recuperación ante desastres.

Los sitios pueden estar en dos estados, ciudades, plantas o salas diferentes. Los clústeres extendidos que usan dos sitios proporcionan recuperación ante desastres y continuidad empresarial si un sitio sufre una interrupción o un error.

Dedique unos minutos a ver el vídeo sobre el clúster extendido de Azure Stack HCI:

Clúster extendido activo-pasivo

En el diagrama siguiente se muestra el sitio 1 como el sitio activo con replicación en el sitio 2, una replicación unidireccional.

Escenario de clúster extendido activo/pasivo.

Clúster extendido activo-activo

En el diagrama siguiente se muestran el sitio 1 y el sitio 2 como sitios activos, con replicación bidireccional en el otro sitio.

Escenario del clúster extendido activo-activo

Consideraciones sobre la conmutación por error de IP de invitado

Al hablar de la agrupación en clústeres extendida, una de las consideraciones que se deben tener en cuenta son las máquinas virtuales y las direcciones IP que se usan. Los centros de datos que residen en ubicaciones diferentes suelen tener subredes IP diferentes. Las direcciones IP que usan las máquinas virtuales podrían ser buenas para un centro de datos, pero inaccesibles para otro. Por lo tanto, se debe tener en cuenta el planeamiento de cómo tratar los cambios de dirección IP. En su mayor parte, hay cuatro maneras diferentes de controlar el cambio de la dirección IP en la máquina virtual durante la conmutación por error. Puede haber otros, pero en este documento se tratarán los cuatro primeros.

El primero y más sencillo es el uso de DHCP. Al mover una máquina virtual de un sitio a otro, un paso que realizará es solicitar una dirección DHCP. Con ello, obtendrá la dirección IP adecuada para el sitio adecuado en el que se encuentra, siempre y cuando haya un servidor DHCP disponible.

Luego, está el uso de una dirección estática. Sin embargo, a diferencia de la réplica de Hyper-V, no hay ninguna manera de especificar una dirección IP alternativa. Por lo tanto, será necesario crear un script para asignar la dirección IP adecuada para la máquina virtual en función del sitio en el que se encuentra. Por ejemplo, SiteA usa una red 1.x y SiteB usa una red 156.x. Este script tendría que detectar la red en la que se encuentra la máquina virtual y establecer un esquema de direcciones IP 1.x si está en SiteA o un esquema de direcciones IP 156.x si está en SiteB. Los Servicios de nombres de dominio (DNS) también deberán recibir alertas sobre el cambio y la replicación entre los sitios.

Otra opción es el uso de un dispositivo de red intermedio que proporcionará una única dirección IP a la máquina virtual para la conectividad del cliente, que puede enrutar el tráfico que va a la máquina virtual al sitio en el que se encuentra actualmente. Los clientes y DNS siempre tendrán la misma dirección de la máquina virtual y el dispositivo intermedio tendrá que realizar un seguimiento de la dirección IP y la ubicación reales de la máquina virtual para que los clientes se dirijan a la máquina virtual correctamente.

La última opción es el uso de una vLAN extendida. Con una vLAN extendida, las máquinas virtuales pueden mantener la misma dirección IP sin importar el sitio en el que se encuentra. Sin embargo, debido a algunas de las complejidades de configurar y mantener una vLAN extendida, Microsoft no recomienda esta opción.

Con cualquiera de las opciones anteriores, se deben tener en cuenta consideraciones adicionales (DNS, cachés ARP, TTL, etc.) en lo que respecta a la conectividad del cliente y se debe planificar a conciencia. Trabaje con el equipo de redes para identificar la mejor opción que satisfaga sus necesidades.

Pasos siguientes