Compartir a través de

Interoperabilidad de funciones con AG y listener de DNN

Se aplica a:SQL Server en máquina virtual de Azure

Sugerencia

Hay muchos métodos para implementar un grupo de disponibilidad. Simplifique la implementación y elimine la necesidad de un nombre de red distribuida (DNN) o un equilibrador de carga de Azure para el grupo de disponibilidad Always On mediante la creación de las máquinas virtuales (VM) de SQL Server en varias subredes dentro de la misma red virtual de Azure. Si ya ha creado el grupo de disponibilidad en una sola subred, puede migrarlo a un entorno de varias subredes.

Algunas características de SQL Server se basan en un nombre de red virtual codificado de forma rígida (VNN). Al usar el agente de escucha de nombre de red distribuida (DNN) con el grupo de disponibilidad AlwaysOn y SQL Server en máquinas virtuales de Azure en una sola subred, es posible que encuentre algunas limitaciones.

En este artículo se describen las características y la interoperabilidad de SQL Server con el agente de escucha DNN del grupo de disponibilidad.

Diferencias de comportamiento

Tenga en cuenta las siguientes diferencias entre la funcionalidad del agente de escucha de VNN y el agente de escucha de DNN:

  • Tiempo de conmutación por error: el tiempo de conmutación por error es más rápido cuando se usa un agente de escucha de DNN, ya que no es necesario esperar a que el equilibrador de carga de red detecte el evento de error y cambie su enrutamiento.
  • Conexiones existentes: las conexiones a una base de datos específica dentro de un grupo de disponibilidad que está en proceso de conmutación por error se cierran, pero otras conexiones a la réplica principal permanecen abiertas, ya que el DNN permanece en línea durante el proceso de conmutación por error. Este comportamiento es diferente de un entorno de VNN tradicional en el que todas las conexiones a la réplica principal suelen cerrarse cuando el grupo de disponibilidad produce una conmutación por error, el agente de escucha se desconecta y la réplica principal pasa al rol secundario. Al usar un agente de escucha de DNN, es posible que tenga que ajustar las cadenas de conexión de la aplicación para asegurarse de que las conexiones se redirigen a la nueva réplica principal tras la conmutación por error.
  • Transacciones abiertas: Las transacciones abiertas contra una base de datos en un grupo de disponibilidad que está sufriendo una conmutación por error se cierran y revierten, y debe volver a conectarse manualmente. Por ejemplo, en SQL Server Management Studio, cierre la ventana de consulta y abra otra nueva.

Controladores cliente

Para los controladores ODBC, OLEDB, ADO.NET, JDBC, PHP y Node.js, especifique el nombre y el puerto del agente de escucha de DNN como nombre del servidor en la cadena de conexión. Para garantizar una conectividad rápida tras la conmutación por error, agregue MultiSubnetFailover=True a la cadena de conexión si el cliente SQL lo admite.

Herramientas

Los usuarios de SQL Server Management Studio, sqlcmd y SQL Server Data Tools deben especificar el nombre y el puerto del agente de escucha de DNN como nombre de servidor en la cadena de conexión para conectarse al agente de escucha.

Actualmente no se admite la creación del agente de escucha de DNN mediante la GUI de SQL Server Management Studio (SSMS).

Grupos de disponibilidad y FCI

Puede configurar un grupo de disponibilidad Always On usando una instancia de clúster de conmutación por error (FCI) como una de las réplicas. Para que esta configuración funcione con la escucha de DNN, la instancia del clúster de recuperación ante fallos también debe usar el DNN, ya que no hay ninguna manera de colocar la dirección IP virtual de FCI en la lista de direcciones IP de DNN del grupo de disponibilidad.

En esta configuración, la URL del punto de conexión de reflejo para la réplica de FCI debe utilizar el DNN de FCI. Del mismo modo, si se utiliza la FCI como réplica de solo lectura, el enrutamiento de solo lectura hacia la réplica FCI debe usar el DNN de la FCI.

El formato del punto de conexión de creación de reflejo es: ENDPOINT_URL = 'TCP://<FCI DNN DNS name>:<mirroring endpoint port>'.

Por ejemplo, si el nombre DNS de DNN de la FCI es dnnlsnr y 5022 es el puerto del punto de conexión de reflejo de la FCI, el fragmento de código de Transact-SQL (T-SQL) para crear la dirección URL del punto de conexión es el siguiente:

ENDPOINT_URL = 'TCP://dnnlsnr:5022'

Del mismo modo, el formato de la dirección URL de enrutamiento de solo lectura es: TCP://<FCI DNN DNS name>:<SQL Server instance port>.

Por ejemplo, si el nombre DNS del DNN es dnnlsnr y 1444 es el puerto que usa la FCI de SQL Server de destino de solo lectura, el fragmento de código de T-SQL para crear la dirección URL de enrutamiento de solo lectura tiene el siguiente aspecto:

READ_ONLY_ROUTING_URL = 'TCP://dnnlsnr:1444'

Puede omitir el puerto en la dirección URL si es el puerto predeterminado 1433. Para una instancia con nombre, configure un puerto estático para la instancia con nombre y especifíquelo en la dirección URL de enrutamiento de solo lectura.

Grupo de disponibilidad distribuido

Si configura el agente de escucha del grupo de disponibilidad mediante un nombre de red distribuido (DNN), no puede configurar un grupo de disponibilidad distribuido sobre el grupo de disponibilidad.

Replicación

La replicación transaccional, de mezcla y de instantáneas permiten reemplazar el cliente de escucha de VNN por el agente de escucha de DNN y el puerto en los objetos de replicación que se conectan al cliente de escucha.

Para más información sobre cómo usar la replicación con los grupos de disponibilidad, consulte las secciones sobre Publicador y grupos de disponibilidad, Suscriptor y grupos de disponibilidad y Distribuidor y grupos de disponibilidad.

MSDTC

Se admiten tanto MSDTC locales como en clúster, pero MSDTC utiliza un puerto dinámico. Este puerto dinámico requiere una instancia estándar de Azure Load Balancer para configurar el puerto de alta disponibilidad. Por lo tanto, la máquina virtual debe usar una reserva de IP estándar o no puede exponerla a Internet.

Defina dos reglas: una para el puerto asignador de puntos de conexión RPC 135 y otra para el puerto MSDTC real. Después de la conmutación por error, modifique la regla del equilibrador de carga para el nuevo puerto MSDTC una vez que este haya cambiado en el nuevo nodo.

Si el MSDTC (Coordinador de transacciones distribuidas) es local, asegúrese de permitir la comunicación de salida.

Consulta distribuida

La consulta distribuida se basa en un servidor vinculado, que puede configurar con el listener DNN del grupo de disponibilidad AG y el puerto. Si el puerto no es 1433, elija la opción Usar otro origen de datos en SQL Server Management Studio (SSMS) al configurar el servidor vinculado.

FILESTREAM

FILESTREAM se admite, pero no para escenarios en los que los usuarios acceden al recurso compartido de archivos con alcance definido mediante la Windows File API.

FileTable

FileTable se admite, pero no en escenarios en los que los usuarios acceden al recurso compartido de archivos con ámbito mediante Windows File API.

Servidores vinculados

Configure el servidor enlazado con el nombre y el puerto del agente de escucha AG DNN. Si el puerto no es 1433, elija la opción Usar otro origen de datos en SQL Server Management Studio (SSMS) al configurar el servidor vinculado.

Preguntas más frecuentes

¿Qué versión de SQL Server admite el agente de escucha DNN de AG?

SQL Server 2019 CU 8 y versiones posteriores.

¿Cuál es el tiempo de conmutación por error esperado cuando uso el agente de escucha DNN?

Para el escucha de DNN, el tiempo de conmutación por error es el mismo que el tiempo de conmutación por error del grupo de disponibilidad (AG), sin tiempo adicional (como el tiempo de sondeo al usar Azure Load Balancer).

¿Hay algún requisito de versión para que los clientes de SQL admitan DNN con OLEDB y ODBC?

Use la cadena de conexión MultiSubnetFailover=True para la compatibilidad con el agente de escucha de DNN. Está disponible a partir de SQL Server 2012 (11.x).

¿Hay algún cambio de configuración de SQL Server que necesite para utilizar el cliente de escucha de DNN?

SQL Server no requiere ningún cambio en la configuración para utilizar el DNN, pero es posible que algunas características de SQL Server requieran más atención.

¿Admite el DNN clústeres de varias subredes?

Sí. El clúster enlaza el DNN en DNS con las direcciones IP físicas de todas las réplicas del grupo de disponibilidad, independientemente de la subred. El cliente SQL prueba todas las direcciones IP del nombre DNS independientemente de la subred.

¿El agente de escucha DNN del grupo de disponibilidad admite el enrutamiento de solo lectura?

Sí. El enrutamiento de solo lectura se admite con la escucha de DNN.

Contenido relacionado

  • Last updated on