Agrupación en clústeres de varias subredes de SQL Server (SQL Server)

Artículo
04/26/2023

Se aplica a:SQL Server

Un clúster de conmutación por error de múltiples subredes de SQL Server es una configuración donde cada nodo clúster se conecta a una subred diferente o un conjunto de subredes diferente. Estas subredes pueden estar en la misma ubicación o en sitios geográficamente dispersos. A veces se hace referencia a la agrupación en clústeres en sitios geográficamente dispersos como clústeres elásticos. Como no existe ningún almacenamiento compartido al que todos los nodos puedan tener acceso, los datos se deben replicar entre el almacenamiento de datos en las diversas subredes. Con la replicación de datos, hay más de una copia de los datos disponible. Por consiguiente, un clúster de conmutación por error de múltiples subredes proporciona una solución de recuperación ante desastres además de alta disponibilidad.

Clúster de conmutación por error de múltiples subredes de SQL Server (dos nodos, dos subredes)

La ilustración siguiente representa una instancia de clúster de conmutación por error (FCI) con dos nodos y dos subredes en SQL Server.

Arquitectura de múltiples subredes con MultiSubnetFailover

Configuraciones de instancias de clúster de conmutación por error de múltiples subredes.

Los siguientes son algunos ejemplos de configuraciones de clúster de conmutación por error (FCI) de SQL Server que usan múltiples subredes:

SQL Server SQLCLUST1 incluye Nodo1 y Nodo2. Nodo1 se conecta a Subred1. Nodo2 se conecta a Subred2. SQL Server El programa de instalación ve esta configuración como un clúster de múltiples subredes y establece la dependencia de recursos de la dirección IP en OR.
SQL Server SQLCLUST1 incluye Nodo1, Nodo2 y Node3. Nodo1 y Nodo2 se conectan a Subred1. Nodo 3 se conecta a Subred2. SQL Server El programa de instalación ve esta configuración como un clúster de múltiples subredes y establece la dependencia de recursos de la dirección IP en OR. Dado que Nodo1 y Nodo2 están en la misma subred, esta configuración proporciona alta disponibilidad local adicional.
SQL Server SQLCLUST1 incluye Nodo1 y Nodo2. Nodo1 están en Subred1. Nodo2 está conectado a Subred1 y Subred2. SQL Server El programa de instalación ve esta configuración como un clúster de múltiples subredes y establece la dependencia de recursos de la dirección IP en OR.
SQL Server SQLCLUST1 incluye Nodo1 y Nodo2. Nodo1 está conectado a Subred1 y Subred2. Nodo2 también está conectado a Subred1 y Subred2. La dependencia de recurso de dirección IP la establece en AND el programa de instalación de SQL Server .

Nota:

Esta configuración no se considera una configuración de clúster de conmutación por error de múltiples subredes porque los nodos clúster están en el mismo conjunto de subredes.

Consideraciones de recursos de dirección IP

En una configuración de clúster de conmutación por error de múltiples subredes, no todos los nodos clúster de conmutación por error poseen las direcciones IP y puede que no todos estén con conexión durante el inicio de SQL Server. A partir de SQL Server 2012 (11.x), se puede establecer la dependencia de recurso de dirección IP en OR. Esto permite que SQL Server esté con conexión cuando hay al menos una dirección IP válida a la que se puede enlazar.

Nota:

En las versiones de SQL Server anteriores a SQL Server 2012 (11.x), se utilizaba una tecnología de V-LAN elástica en las configuraciones de clúster de varios sitios para exponer una sola dirección IP para la conmutación por error entre sitios. Con la nueva capacidad de SQL Server para agrupar los nodos de clúster entre diferentes subredes, ahora se pueden configurar los clústeres de conmutación por error SQL Server entre varios sitios sin necesidad de implementar la tecnología de V-LAN elástica.

Consideraciones acerca de la dependencia OR del recurso de dirección IP

Es conveniente considerar el siguiente comportamiento de la conmutación por error si se establece en ORla dependencia de recurso de dirección IP:

Cuando se produce un error de una de las direcciones IP en el nodo que actualmente posee el grupo de recursos del clúster SQL Server , no se activa automáticamente una conmutación por error hasta que produzcan un error todas las direcciones IP válidas en ese nodo.
Cuando se produce una conmutación por error, SQL Server se pondrán con conexión si se puede enlazar al menos a una dirección IP que sea válida en el nodo actual. Las direcciones IP que no se enlazan a SQL Server en el inicio se enumerarán en el registro de errores.

Al instalar una instancia de clúster de conmutación por error de SQL Server en paralelo con una instancia independiente de Motor de base de datos de SQL Server, tenga cuidado para evitar conflictos de número de puerto TCP en las direcciones IP. Los conflictos suelen suceder cuando se configuran dos instancias de Motor de base de datos para usar el puerto TCP (1433). Para evitar conflictos, configure una instancia para que utilice un puerto fijo predeterminado. La configuración de un puerto fijo es normalmente lo más sencillo en el caso de la instancia independiente. La configuración del Motor de base de datos para usar puertos diferentes evitará un conflicto inesperado entre el puerto TCP y la dirección IP que bloquea la instancia cuando una instancia de clúster de conmutación por error de SQL Server produce un error en el nodo en espera.

Latencia de recuperación de cliente durante conmutaciones por error

Una instancia de clúster de conmutación por error de múltiples subredes habilita de forma predeterminada el recurso de clúster RegisterAllProvidersIP para el nombre de red. En una configuración de múltiples subredes, las direcciones IP en línea y sin conexión del nombre red se registra en el servidor DNS. La aplicación cliente recupera a continuación todas las direcciones IP registradas del servidor DNS e intenta la conexión con las direcciones en orden o en paralelo. Esto significa que el tiempo de recuperación de cliente en clústeres de conmutación por error de múltiples subredes deja de depender de las latencias de actualización de DNS. De forma predeterminada, el cliente intenta las direcciones IP en orden. Cuando el cliente usa el nuevo parámetro opcional MultiSubnetFailover=True en la cadena de conexión, intentará en su lugar las direcciones IP simultáneamente y las conexiones al primer servidor que responda. Esto puede ayudar a reducir al mínimo la latencia de recuperación de cliente cuando se produzcan conmutaciones por error. Para más información, consulte Conectividad de cliente de AlwaysOn (SQL Server) y Crear o configurar un agente de escucha de grupo de disponibilidad (SQL Server).

Con las bibliotecas de cliente heredadas o con proveedores de datos de terceros, no puede utilizar el parámetro MultiSubnetFailover en la cadena de conexión. Para asegurarse de que la aplicación cliente funcione de manera óptima con instancias de conmutación por error de múltiples subredes en SQL Server, intente ajustar el tiempo de espera de conexión en la cadena de conexión de cliente en 21 segundos para cada dirección IP adicional. Esto garantiza que el intento de reconexión del cliente no supere el tiempo de espera antes de poder recorrer todas las direcciones IP en la instancia de conmutación por error de múltiples subredes.

El período de tiempo de espera predeterminado de la conexión de cliente para SQL Server Management Studio y sqlcmd es de 15 segundos.