Mejora
El SQL Server de escucha de instancia de clúster de conmutación por error (FCI) de 2019 y 2016 se ha mejorado para trabajar en conjunto con el punto de acceso de nombre de red distribuido (DNN) del clúster de conmutación por error (WSFC) de Windows Server Failover Cluster (WSFC).
Más información
SQL Server Actualmente, el agente de escucha de instancia de clúster de conmutación por error (FCI) solo funciona junto con el Windows de red del clúster de conmutación por error de servidor (WSFC) y el punto de acceso IP virtual. Como la IP virtual no funciona en el entorno de Azure, tiene que configurar un Equilibrador de carga interno de Azure para evitar este problema (Vea cómo configurar un equilibrador de carga interno de Azure).
Esta actualización proporciona otra forma para que el cliente de SQL Server se conecte con FCI sin un equilibrador de carga con el recurso Nombre de red distribuida (DNN) en un clúster de conmutación por error Windows servidor. Cuando se crea un recurso DNN, WSFC enlaza el nombre DNS DNN a las direcciones IP de todos los nodos del clúster. El SQL Server intentará conectar cada dirección IP de esta lista para buscar el nodo en el que fci se está ejecutando actualmente. Este proceso de conexión se acelera aún más conectando todas las direcciones IP en paralelo si la propiedad SQL Server conexión MultiSubnetFailover es verdadera. Esto permite al cliente SQL Server conectarse a la FCI que se está ejecutando actualmente al instante.
En comparación con la solución alternativa anterior del uso del Equilibrador de carga interno de Azure, el método de escucha DNN evita la latencia de conmutación por error adicional que introduce el sondeo de estado de vida del equilibrador de carga. De forma predeterminada, ese proceso tarda entre 10 y 15 segundos. (Vea este documento de Azuresobre cómo calcular la latencia). No tiene que configurar y mantener los componentes del equilibrador de carga. Esto simplifica el proceso de aprovisionamiento. Al quitar el equilibrador de carga también se quita un componente que puede producir un posible error. Esto mejora la robustez general.
Se necesitan los pasos siguientes para usar esta característica:
-
Para una FCI instalada, debe crear un recurso DNN y establecer su nombre DNS. Ejecute los tres comandos de PowerShell siguientes como administrador:
-
Add-ClusterResource -Name <dnnResourceName> -ResourceType "Distributed Network Name" -Group "<WSFC role of SQL server instance>"
Get-ClusterResource -Name <dnnResourceName> | Set-ClusterParameter -Name DnsName -Value <DNSName>
Start-ClusterResource -Name <dnnResourceName>
Por ejemplo:
-
Add-ClusterResource -Name dnn-demo -ResourceType "Distributed Network Name" -Group "SQL Server (MSSQLSERVER)"
Get-ClusterResource -Name dnn-demo | Set-ClusterParameter -Name DnsName -Value dnnlsnr
Start-ClusterResource -Name dnn-demo
Explicación:
-
El primer comando agrega un recurso DNN al WSFC al tener un nombre de recurso de <dnnResourceName>. WSFC usa el nombre del recurso para identificar de forma exclusiva un recurso WSFC. Use una que tenga sentido para usted y que sea única en todo el clúster de WSFC. El tipo de recurso debe ser Nombre de red distribuida. El nombre del grupo al que pertenece este recurso DNN debe ser el grupo de recursos WSFC (rol) que corresponde a la FCI a la que desea agregar el recurso DNN. El formato típico de este nombre de grupo es "SQL Server (nombre de instancia)." Por lo tanto, para la instancia predeterminada, el nombre será "SQL Server (MSSQLSERVER)." También puede comprobar el nombre del grupo en la consola del Administrador de clústeres de conmutación por error.
-
El segundo comando establece el nombre DNS de este recurso DNN. El nombre DNS es importante porque es el nombre que usan los clientes para conectarse a la FCI.
-
El tercer comando inicia el recurso DNN.
De forma predeterminada, el nombre DNS DNN se enlaza a todos los nodos de WSFC. Configure el posible propietario del recurso DNN para incluir solo los nodos de esta FCI si no todos los nodos de WSFC participan en FCI.
-
-
Reinicie SQL Server instancia.
-
Reemplace el nombre de red virtual (VNN SQL) en una cadena de conexión de cliente con el nombre DNS DNN y establezca la propiedad MultiSubnetFailover en "true". Puede omitir esta configuración si la SQL de cliente es posterior a la 4.6.1.
Solución
Esta mejora se incluye en la siguiente actualización acumulativa para SQL Server:
Acerca de las actualizaciones acumulativas para SQL Server:
Cada nueva actualización acumulativa de SQL Server contiene todas las revisiones y todas las correcciones de seguridad que se incluyeron con la actualización acumulativa anterior. Consulte las actualizaciones acumulativas más recientes para SQL Server:
Información del Service Pack SQL Server 2016
Este problema se ha corregido en el siguiente service pack para SQL Server:
Los Service Pack son acumulativos. Cada nuevo Service Pack contiene todas las revisiones de Service Packs previos junto con revisiones nuevas. Le recomendamos que aplique el service pack más reciente y la última actualización acumulativa para ese service pack. No tiene que instalar un service pack anterior antes de instalar el service pack más reciente. Use la Tabla 1 en el siguiente artículo para obtener más información sobre el service pack más reciente y la última actualización acumulativa.
Determinar el nivel de versión, edición y actualización de SQL Server y sus componentes
Referencias
Obtenga información sobre la terminología que usa Microsoft para describir las actualizaciones de software.
