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 grupo de disponibilidad es un nombre de red virtual que utilizan los clientes para conectarse a una base de datos hospedada en un grupo de disponibilidad. El listener proporciona un punto de conexión de conexión coherente para las aplicaciones cliente, independientemente de qué réplica de disponibilidad hospede en ese momento la base de datos primaria. El listener también permite el enrutamiento de solo lectura y la conmutación por error automática.
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. Sin embargo, en ese caso se perderá la ventaja de que las nuevas conexiones se enruten automáticamente a la nueva réplica primaria actual. Además, perderás la ventaja del enrutamiento de solo lectura, en el que las conexiones especificadas con read-intent se enrutan automáticamente a la réplica secundaria de lectura.
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 para esto sería que el inicio de sesión usado en la conexión tenga la base de datos configurada como su base de datos 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 aplicaciones de la conexión entrante se establece en 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 u 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
Omisión de clientes de escucha
Aunque los oyentes de grupos de disponibilidad permiten la redirección de conmutación por error y el enrutamiento de solo lectura, las conexiones de los clientes no están obligadas a utilizarlos. 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 inicia sesión mediante el oyente del grupo de disponibilidad o mediante 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 creación de reflejo de la base de datos a Grupos de disponibilidad AlwaysOn, las aplicaciones pueden especificar la cadena de conexión de creación de reflejo de la base de datos mientras solo exista una réplica secundaria y no permita conexiones de usuario.
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 añade réplicas secundarias adicionales, deberá crear un oyente de grupo de disponibilidad para el grupo de disponibilidad y actualizar sus aplicaciones para que utilicen el nombre DNS del oyente de 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 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", en función de 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.
A continuación se muestra un ejemplo de la cadena de conexión del proveedor ADO.NET (Microsoft.Data.SqlClient o System.Data.SqlClient) que permite la conmutación por error entre varias subredes:
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 obligatoria, ofrece la ventaja de una conmutación por error entre subredes 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 un oyente de grupo de disponibilidad, si las instancias participantes de SQL Server utilizan certificados TLS/SSL junto con el cifrado de sesión, el controlador del cliente que se conecta debe admitir el Nombre alternativo del sujeto (Subject Alternate Name) 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 agentes de escucha 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 de entidad de seguridad de servicio (SPN) en Active Directory para cada escucha de grupo de disponibilidad a fin de habilitar Kerberos para las conexiones de cliente con el cliente de escucha. Al registrar el SPN, debe usar la cuenta de servicio de la instancia del servidor en el que se hospede 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.