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

Se aplica a:SQL Server

Un clúster de conmutación por error de varias subredes de SQL Server es una configuración en la que cada nodo de clúster de conmutación por error está conectado a una subred diferente o a un conjunto diferente de subredes. Estas subredes pueden estar en la misma ubicación o en sitios geográficamente dispersos. A veces, los clústeres de sitios dispersos geográficamente se conocen como clústeres extendidos. Dado que no hay almacenamiento compartido al que pueden acceder todos los nodos, los datos deben replicarse entre el almacenamiento de datos en las varias subredes. Al replicar datos, hay más de una copia de los datos disponibles. 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 varias subredes de SQL Server (dos nodos, dos subredes)

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

Configuraciones de instancia de clúster de conmutación por error de varias subredes

A continuación se muestran algunos ejemplos de FCI de SQL Server que usan varias subredes:

• SQL Server SQLCLUST1 incluye Nodo1 y Nodo2. Nodo1 se conecta a Subred1. Nodo2 se conecta a Subred2. El programa de instalación de SQL Server ve esta configuración como un clúster de varias subredes y establece la dependencia de recursos de dirección IP en OR.

• El SQLCLUST2 de FCI de SQL Server incluye Node1, Node2 y Node3. Nodo1 y Nodo2 se conectan a Subred1. Nodo 3 se conecta a Subred2. El programa de instalación de SQL Server ve esta configuración como un clúster de varias subredes y establece la dependencia de recursos de dirección IP en OR. Dado que Nodo1 y Nodo2 están en la misma subred, esta configuración proporciona alta disponibilidad local adicional.

• El SQLCLUST3 de FCI de SQL Server incluye Node1 y Node2. Nodo1 están en Subred1. Nodo2 está conectado a Subred1 y Subred2. El programa de instalación de SQL Server ve esta configuración como un clúster de varias subredes y establece la dependencia de recursos de dirección IP en OR.

• La SQLCLUST4 FCI de SQL Server incluye Node1 y Node2. Nodo1 está conectado a Subred1 y Subred2. Nodo2 también está conectado a Subred1 y Subred2. El programa de instalación de SQL Server establece la dependencia de recursos de dirección IP en AND.

  Nota:

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

Consideraciones sobre los recursos de dirección IP

En una configuración de clúster de conmutación por error de varias subredes, las direcciones IP no pertenecen a todos los nodos del clúster de conmutación por error y es posible que no estén en línea durante el inicio de SQL Server. A partir de SQL Server 2012 (11.x), puede establecer la dependencia de recursos de ORdirección IP en . Esto permite que SQL Server esté en línea cuando haya al menos una dirección IP válida a la que se pueda enlazar.

Nota:

En las versiones de SQL Server anteriores a SQL Server 2012 (11.x), se usaba una tecnología de V-LAN stretch en configuraciones de clúster de varios sitios para exponer una única dirección IP para la conmutación por error entre sitios. Ahora que SQL Server puede agrupar nodos en clústeres en distintas subredes, puede configurar clústeres de conmutación por error de SQL Server en varios sitios sin implementar la tecnología stretch V-LAN.

Consideraciones de dependencia o recurso de dirección IP

Es posible que desee tener en cuenta el siguiente comportamiento de conmutación por error si establece la dependencia de recursos de dirección IP en OR:

• Cuando se produce un error en una de las direcciones IP del nodo que posee actualmente el grupo de recursos del clúster de SQL Server, una conmutación por error no se desencadena automáticamente hasta que se produzca un error en todas las direcciones IP válidas en ese nodo.

• Cuando se produce una conmutación por error, SQL Server se conecta si puede enlazar a al menos una dirección IP válida en el nodo actual. Las direcciones IP que no se enlazaron a SQL Server al iniciarse se mostrarán en el registro de errores.

Cuando se instala una FCI de SQL Server en paralelo con una instancia independiente del motor de base de datos de SQL Server, tenga cuidado de evitar conflictos de números de puerto TCP en las direcciones IP. Los conflictos suelen producirse cuando se configuran dos instancias del motor de base de datos para usar el puerto TCP predeterminado (1433). Para evitar conflictos, configure una instancia para que use un puerto fijo no predeterminado. La configuración de un puerto fijo suele ser más fácil en la instancia independiente. La configuración del motor de base de datos para usar puertos diferentes impide un conflicto de puerto TCP o dirección IP inesperado que bloquea el inicio de una instancia cuando una FCI de SQL Server no puede llegar al nodo en espera.

Latencia de recuperación del cliente durante la conmutación por error

De forma predeterminada, una FCI de varias subredes habilita el recurso de clúster RegisterAllProvidersIP para su nombre de red. En una configuración de varias subredes, las direcciones IP en línea y sin conexión del nombre de red se registran en el servidor DNS. A continuación, la aplicación cliente recupera todas las direcciones IP registradas del servidor DNS e intenta conectarse a las direcciones, ya sea en orden o en paralelo. Esto significa que el tiempo de recuperación del cliente en las conmutaciones por error de varias subredes ya no depende de las latencias de actualización de DNS. De forma predeterminada, el cliente intenta las direcciones IP en orden. Cuando el cliente usa el parámetro opcional MultiSubnetFailover=True en su cadena de conexión, en su lugar intenta las direcciones IP simultáneamente y se conecta al primer servidor que responde. Esta configuración puede ayudar a minimizar la latencia de recuperación del cliente cuando se producen conmutaciones por error. Para obtener más información, vea Conectividad de cliente AlwaysOn (SQL Server) y Creación o configuración de un agente de escucha de grupo de disponibilidad (SQL Server).

Con bibliotecas de cliente heredadas o proveedores de datos que no son de Microsoft, no puede usar 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. Esta configuración garantiza que el intento de reconexión del cliente no agote el tiempo de espera antes de que pueda recorrer todas las direcciones IP de la FCI de varias subredes.

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

Nota:

Si usa varias subredes y tiene un DNS estático, debe tener un proceso implementado para actualizar el registro DNS asociado al agente de escucha antes de realizar una conmutación por error. De lo contrario, el nombre de red no se conectará.

Contenido relacionado

Description	Artículo
Instalación de un clúster de conmutación por error de SQL Server	Creación de un nuevo clúster de conmutación por error de SQL Server (programa de instalación)
Actualización local del clúster de conmutación por error de SQL Server existente	Actualización de una instancia de clúster de conmutación por error de SQL Server (programa de instalación)
Mantenimiento del clúster de conmutación por error de SQL Server	Agregar o quitar nodos en un clúster de conmutación por error de SQL Server (programa de instalación)
Usar el complemento Administración de clústeres de conmutación por error para ver los eventos y registros del clúster de conmutación por error de Windows Server	Visualización de eventos y registros de un clúster de conmutación por error
Usar Windows PowerShell para crear un archivo de registro para todos los nodos (o un nodo específico) en un clúster de conmutación por error de Windows Server	cmdlet de clúster de conmutación por error deGet-ClusterLog