Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Se aplica a:
SQL Server
En este artículo se explica cómo conectarse a un listener de grupo de disponibilidad Always On para SQL Server. Un listener de un grupo de disponibilidad es un nombre de red virtual que los clientes utilizan para conectarse a una base de datos que reside en un grupo de disponibilidad. El agente de escucha proporciona un punto de conexión coherente para las aplicaciones cliente, independientemente de la réplica de disponibilidad que hospeda actualmente la base de datos principal. El agente de escucha también permite la compatibilidad con el enrutamiento de solo lectura y la conmutación automática por error.
Después de configurar el agente de escucha, actualice las cadenas de conexión para que apunten al agente de escucha, de modo que el tráfico de la aplicación se enrute automáticamente a la réplica prevista sin tener que actualizar manualmente las cadenas de conexión después de cada conmutación por error.
Conexión a la réplica principal
Para conectarse a la réplica principal para acceso de lectura y escritura, especifique el nombre DNS de la escucha de grupo de disponibilidad en la cadena de conexión.
Por ejemplo, para conectarse a la réplica principal en SQL Server Management Studio a través del cliente de escucha, escriba el nombre DNS del cliente de escucha en el campo Nombre del servidor:
Durante una conmutación por error, cuando la réplica principal cambia, las conexiones existentes con el cliente de escucha se desconectan y las conexiones nuevas se enrutan a la nueva réplica principal.
Ejemplo de una cadena de conexión básica para el proveedor de ADO.NET (Microsoft.Data.SqlClient o System.Data.SqlClient):
Server=tcp: AGListener,1433;Database=MyDB;Integrated Security=SSPI
Nota:
Microsoft.Data.SqlClient es el proveedor de datos ADO.NET recomendado para el nuevo desarrollo de aplicaciones. Admite las mismas palabras clave de cadena de conexión que System.Data.SqlClient. Para obtener más información, vea Introducción al espacio de nombres Microsoft.Data.SqlClient.
Puede comprobar a qué réplica está conectado actualmente a través del cliente de escucha si ejecuta el siguiente comando de Transact-SQL (T-SQL):
SELECT @@SERVERNAME
Por ejemplo, cuando SQLVM1 es la réplica principal:
Todavía se puede conectar directamente a la instancia de SQL Server mediante el nombre de instancia de la réplica principal o secundaria en lugar de usar la escucha de grupo de disponibilidad. No obstante, perderá la ventaja de que las nuevas conexiones sean enrutadas automáticamente a la nueva réplica principal actual. Además, perderá la ventaja del enrutamiento de solo lectura, donde las conexiones especificadas con read-intent se enrutan de forma automática a la réplica secundaria legible.
Conexión a una réplica de solo lectura
El enrutamiento de solo lectura se refiere al enrutamiento automático de las conexiones de cliente de escucha entrantes a una réplica secundaria legible configurada para permitir cargas de trabajo de solo lectura.
Las conexiones se enrutan de forma automática a la réplica de solo lectura si se cumple lo siguiente:
Al menos una réplica secundaria se establece para acceso de solo lectura, y cada réplica secundaria de solo lectura y la réplica principal se configuran para admitir el enrutamiento de solo lectura.
La cadena de conexión hace referencia a una base de datos implicada en el grupo de disponibilidad. Una alternativa sería que el inicio de sesión utilizado para la conexión tenga configurada la base de datos como predeterminada. Para más información, consulte este artículo sobre cómo funciona el algoritmo con el enrutamiento de solo lectura.
La cadena de conexión hace referencia a un agente de escucha de grupo de disponibilidad y la intención de la aplicación de la conexión entrante se establece en de solo lectura (por ejemplo, al usar la palabra clave Application Intent=ReadOnly en las cadenas de conexión, los atributos de conexión o las propiedades de ODBC o OLEDB).
El atributo de intención de aplicación se almacena en la sesión del cliente durante el inicio de sesión. La instancia de SQL Server procesa la intención y determina qué hacer según la configuración del grupo de disponibilidad y el estado de lectura y escritura actual de la base de datos de destino en la réplica secundaria.
Por ejemplo, para conectarse a una réplica de solo lectura mediante SQL Server Management Studio, seleccione Opciones en el cuadro de diálogo Conectar al servidor , seleccione la pestaña Parámetros de conexión adicionales y, a continuación, especifique ApplicationIntent=ReadOnly en el cuadro de texto:
Ejemplo de una cadena de conexión para el proveedor de ADO.NET (Microsoft.Data.SqlClient o System.Data.SqlClient) que designa la intención de solo lectura de la aplicación:
Server=tcp:AGListener;Database=AdventureWorks;Integrated Security=SSPI;ApplicationIntent=ReadOnly
Para obtener más información, vea Configurar acceso de solo lectura en una réplica de disponibilidad (SQL Server)
Puerto no predeterminado
Al crear el cliente de escucha, debe designar un puerto para que lo use. Si el puerto es 1433 (el predeterminado), no es necesario especificar un número de puerto al conectarse al cliente de escucha. Pero si el puerto no es 1433, se debe especificar en la cadena de conexión en el formato listenername,port, por ejemplo:
Ejemplo de una cadena de conexión para el proveedor de ADO.NET (Microsoft.Data.SqlClient o System.Data.SqlClient) que especifica un puerto no predeterminado para el agente de escucha:
Server=tcp:AGListener,1445;Database=AdventureWorks;Integrated Security=SSPI
Anular escuchadores
Mientras que los escuchadores del grupo de disponibilidad habilitan la compatibilidad con la redirección de conmutación por error y el enrutamiento de solo lectura, no se requiere que las conexiones de cliente los utilicen. Una conexión de cliente puede hacer referencia directamente a la instancia de SQL Server en lugar de conectarse al agente de escucha del grupo de disponibilidad.
Para la instancia de SQL Server, es irrelevante si una conexión se realiza usando el listener del grupo de disponibilidad o utilizando otro punto de conexión de la instancia. La instancia de SQL Server comprueba el estado de la base de datos de destino y permite o no permite la conectividad en función de la configuración del grupo de disponibilidad y el estado actual de la base de datos en la instancia. Por ejemplo, si una aplicación cliente se conecta directamente a una instancia de puerto de SQL Server y se conecta a una base de datos de destino hospedada en un grupo de disponibilidad, y la base de datos de destino está en estado principal y en línea, la conectividad se realiza correctamente. Si la base de datos de destino está sin conexión o en un estado transitorio, se produce un error en la conectividad a la base de datos.
Alternativamente, en la migración de reflejo de base de datos a Grupos de disponibilidad Always On, las aplicaciones pueden especificar la cadena de conexión de reflejo de base de datos mientras solo exista una réplica secundaria y no permita conexiones de usuarios.
Cadenas de conexión para reflejo de base de datos
Si un grupo de disponibilidad posee solo una réplica secundaria y está configurado con ALLOW_CONNECTIONS = READ_ONLY o ALLOW_CONNECTIONS = NONE en la réplica secundaria, los clientes pueden conectarse a la réplica principal utilizando una cadena de conexión de reflejo de base de datos. Este enfoque puede ser útil cuando se migra una aplicación existente de reflejo de base de datos a un grupo de disponibilidad, siempre que se limite el grupo a dos réplicas (una principal y una secundaria). Si agrega réplicas secundarias adicionales, deberá crear un agente de escucha del grupo de disponibilidad y actualizar sus aplicaciones para que se utilice el nombre DNS del agente de escucha del grupo de disponibilidad.
Cuando se utilizan cadenas de conexión para el reflejo de base de datos, el cliente puede usar SQL Server Native Client o el proveedor de datos de .NET Framework para SQL Server. La cadena de conexión proporcionada por un cliente debe proporcionar como mínimo el nombre de una instancia del servidor, el nombre del asociado inicial, para identificar la instancia del servidor que hospeda inicialmente la réplica de disponibilidad con la que se desea establecer conexión. Opcionalmente, la cadena de conexión también puede proporcionar el nombre de otra instancia del servidor, nombre del asociado de conmutación por error, para identificar la instancia del servidor que hospeda inicialmente la réplica secundaria como nombre del asociado de conmutación por error.
Para obtener más información sobre las cadenas de conexión de creación de reflejo de la base de datos, vea Conectar clientes a una sesión de creación de reflejo de la base de datos (SQL Server).
Conmutación por error de varias subredes
Si va a usar bibliotecas de cliente que admiten la opción de conexión MultiSubnetFailover en la cadena de conexión, puede optimizar la conmutación por error del grupo de disponibilidad a otra subred si establece MultiSubnetFailover en True o Yes, según la sintaxis del proveedor que use.
Nota:
Se recomienda esta configuración para las conexiones de una red y de varias subredes a los agentes de escucha del grupo de disponibilidad y a los nombres de instancia de clúster de conmutación por error de SQL Server. La habilitación de esta opción agrega optimizaciones adicionales, incluso en escenarios de una sola subred.
La opción de conexión MultiSubnetFailover funciona únicamente con el protocolo de red TCP y solo se admite en la conexión a un agente de escucha del grupo de disponibilidad y para cualquier nombre de red virtual que se conecta a SQL Server.
Un ejemplo de la cadena de conexión del proveedor de ADO.NET (Microsoft.Data.SqlClient o System.Data.SqlClient) que habilita la conmutación por error entre subredes múltiples es el siguiente:
Server=tcp:AGListener,1433;Database=AdventureWorks;Integrated Security=SSPI; MultiSubnetFailover=True
La opción de conexión MultiSubnetFailover debe establecerse en True aunque el grupo de disponibilidad solo abarque una única subred. Esta opción permite preconfigurar nuevos clientes para admitir la expansión futura de subredes sin necesidad de realizar cambios futuros en la cadena de conexión del cliente y también optimiza el rendimiento de la conmutación por error para conmutaciones por error en una sola subred. Aunque la opción de conexión MultiSubnetFailover no es necesaria, proporciona la ventaja de una conmutación por error de subred más rápida. El controlador cliente intenta abrir un socket TCP para cada dirección IP en paralelo asociada al grupo de disponibilidad. El controlador cliente espera a que la primera dirección IP responda correctamente y, una vez que lo hace, la usa para la conexión.
Listeners y certificados TLS/SSL
Al conectarse a una escucha del grupo de disponibilidad, si las instancias participantes de SQL Server utilizan certificados TLS/SSL junto con el cifrado de sesión, el controlador de cliente de conexión debe admitir el Nombre Alternativo del Sujeto en el certificado TLS/SSL para forzar el cifrado.
Se debe configurar un certificado X.509 para cada nodo de servidor participante en el clúster de conmutación por error con una lista de todos los agentes de escucha del grupo de disponibilidad establecidos en el nombre alternativo del asunto del certificado.
El formato de los valores de certificado es:
CN = Server.FQDN
SAN = Server.FQDN,Listener1.FQDN,Listener2.FQDN
Por ejemplo, tiene los valores siguientes:
Servername: Win2019
Instance: SQL2019
AG: AG2019
Listener: Listener2019
Domain: contoso.com (which is also the FQDN)
En el caso de un WSFC que tenga un solo grupo de disponibilidad, el certificado debe tener el nombre de dominio completo (FQDN) del servidor y el FQDN del agente de escucha:
CN: Win2019.contoso.com
SAN: Win2019.contoso.com, Listener2019.contoso.com
Con esta configuración, la conexión se cifra al conectarse a la instancia (WIN2019\SQL2019) o al agente de escucha (Listener2019).
En función de cómo esté configurada la red, hay un pequeño subconjunto de clientes que es posible que tengan que agregar también el NetBIOS al SAN. En ese caso, los valores del certificado deben ser:
CN: Win2019.contoso.com
SAN: Win2019,Win2019.contoso.com,Listener2019,Listener2019.contoso.com
Si el WSFC tiene tres listeners del grupo de disponibilidad, por ejemplo: Listener1, Listener2, Listener3
Los valores del certificado deben ser:
CN: Win2019.contoso.com
SAN: Win2019.contoso.com,Listener1.contoso.com,Listener2.contoso.com,Listener3.contoso.com
Clientes de escucha y Kerberos (SPN)
Un administrador de dominio debe configurar un Nombre Principal de Servicio (SPN) en Active Directory para cada escucha de grupo de disponibilidad con el fin de habilitar Kerberos para las conexiones de cliente con el escucha. Al registrar el SPN, debe usar la cuenta de servicio de la instancia del servidor que hospeda la réplica de disponibilidad. Para que el SPN funcione en todas las réplicas, debe utilizarse la misma cuenta de servicio para todas las instancias del clúster de WSFC que hospeda el grupo de disponibilidad.
Utilice la herramienta de línea de comandos de Windows setspn para configurar el SPN. Por ejemplo, para configurar un SPN para un oyente de grupo de disponibilidad denominado AG1listener.Adventure-Works.com hospedado en un conjunto de instancias de SQL Server, todas configuradas para ejecutarse bajo la cuenta de dominio corp\svclogin2:
setspn -A MSSQLSvc/AG1listener.Adventure-Works.com:1433 corp\svclogin2
Para obtener más información acerca del registro manual de un SPN para SQL Server, vea Registrar un Nombre Principal de Servicio para las conexiones con Kerberos.