Ahora que los grupos de disponibilidad se están generalizando, pensé en cubrir un tema que puede pasarse por alto durante la planificación inicial y la instalación de SQL Server en este tipo de entorno. Para tener realmente una configuración tolerante a fallas, se debe pensar y planificar la configuración de la conectividad de la base de datos.
No entraré en los detalles de la configuración de su entorno AlwaysOn en esta publicación, pero para obtener ayuda adicional, le sugiero que eche un vistazo a la publicación de Aaron Bertrand, "Resolución de problemas de AlwaysOn:a veces se necesitan muchos ojos". Una vez que su entorno esté configurado, el siguiente paso para proporcionar conectividad a la base de datos es crear un agente de escucha del grupo de disponibilidad mediante SQL Management Studio o T-SQL:
ALTER AVAILABILITY GROUP [GroupName] ADD LISTENER N'ListenerName' (WITH IP ((N'10.x.x.x', N'255.255.255.0')), PORT=1433);
Cadenas de conexión del oyente AG
Su nombre de red virtual (VNN) está registrado en DNS y siempre es propiedad de la instancia de SQL Server donde reside la réplica principal. Todas las direcciones IP que se proporcionan al configurar AG Listener se registran en DNS con el mismo nombre de red virtual.
Después de haber creado su AG Listener, debe asegurarse de que sus clientes puedan conectarse. La conexión de su aplicación funciona de la misma manera que siempre lo ha hecho, sin embargo, en lugar de apuntar hacia un servidor específico en su cadena de conexión, apunta hacia AG Listener.
Los agentes de escucha AG solo se pueden conectar mediante TCP y su DNS local los resuelve en la lista de direcciones IP y puertos TCP que se asignan a la VNN. Su cliente intentará conectarse a cada una de las direcciones IP hasta que obtenga una conexión o hasta que se agote el tiempo de espera de la conexión. Un parámetro de cadena de conexión importante a considerar es MultiSubnetFailover. Si este parámetro se establece en verdadero, el cliente intentará las conexiones en paralelo, lo que permitirá una conectividad más rápida y, si es necesario, una conmutación por error del cliente más rápida:
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True
Cuando se produce una conmutación por error, las conexiones de los clientes se restablecen y la propiedad de AG Listener pasa a la instancia de SQL Server que asume la función de réplica principal. Luego, el extremo de VNN se vincula a las nuevas direcciones IP y puertos TCP de la nueva instancia de réplica principal. Según el cliente, se producirá una reconexión automática al AG o es posible que el usuario deba reiniciar manualmente la aplicación o conexión afectada.
Intención de la aplicación
Una de las razones más importantes para implementar grupos de disponibilidad es brindar la capacidad de aprovechar sus entornos de copia de seguridad o recuperación ante desastres para descargar trabajo de su entorno de producción. Estos servidores ahora se pueden usar para copias de seguridad, análisis, consultas e informes ad-hoc, o cualquier otra operación en la que sea suficiente tener una copia de solo lectura de la base de datos.
Para proporcionar acceso de solo lectura a sus réplicas secundarias, se usa el parámetro de cadena de conexión ApplicationIntent. Se puede configurar una lista de enrutamiento opcional de solo lectura de puntos finales de SQL Server en cada réplica. Esta lista se utiliza para redirigir las solicitudes de conexión del cliente que utilizan el parámetro ApplicationIntent=ReadOnly a la primera réplica secundaria disponible que se ha configurado con un filtro de intención de aplicación adecuado.
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True;ApplicationIntent=ReadOnly;
Filtrado de intención de aplicación
Para facilitar la intención de aplicación de los clientes que se conectan a su grupo de disponibilidad, cada instancia de SQL Server en el grupo debe configurarse con un filtro de intención de aplicación adecuado. El filtro determina qué tipos de conexiones aceptará cada réplica.
Una réplica principal que esté configurada para tener Conexiones en el Rol principal de "Permitir todas las conexiones" aceptará cualquier conexión realizada a través de AG Listener. Una réplica principal configurada como "Permitir conexiones de lectura/escritura" rechazará cualquier conexión que especifique "ApplicationIntent=ReadOnly".
Al configurar réplicas, también debe definir si cada una será una Secundaria legible o no. Una réplica configurada como "No" rechazará todas las conexiones. Se supone que esta réplica se usa solo para conmutación por error en una situación de recuperación ante desastres. Si la réplica secundaria está configurada como "Sí", se permitirán todas las conexiones, pero solo para acceso de lectura, incluso si no se especifica "ApplicationIntent=ReadOnly". Finalmente, si el secundario está configurado como "Intención de solo lectura", solo los clientes que especifiquen "ApplicationIntent=ReadOnly" podrán conectarse.
Enrutamiento de solo lectura
Ahora que sabemos cómo configurar Application Intent en las instancias del servidor y crear las cadenas de conexión necesarias, debemos configurar el enrutamiento de solo lectura del grupo de disponibilidad. Cuando se conecta a AG Listener usando la cadena de conexión como se definió anteriormente, el listener consulta la instancia de réplica principal y determina si la conexión debe realizarse con la principal (lectura/escritura) o con una secundaria de solo lectura. Para lograr esto, se debe crear una lista de enrutamiento para CADA réplica de disponibilidad que se utilice siempre y cuando la réplica asuma el rol de principal. Por lo general, la mejor práctica es incluir cada URL de enrutamiento de solo lectura para cada réplica secundaria de solo lectura con la URL de la réplica local al final de la lista. Las solicitudes de conexión con intento de lectura se enrutan al primer secundario legible disponible en la lista de enrutamiento, no hay equilibrio de carga entre los secundarios.
Primero, modifique cada réplica para proporcionar la URL de enrutamiento de solo lectura:
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER01.mydomain.com:1433')); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER02.mydomain.com:1433'));
En segundo lugar, modifique cada réplica para proporcionar la lista de enrutamiento de solo lectura que se usará cuando la réplica dada tenga el rol principal:
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER02','COMPUTER01')));
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER01','COMPUTER02'))); La URL de enrutamiento debe tener la forma de "TCP://:". Para obtener ayuda para determinar su URL, consulte este blog y secuencia de comandos creados por Matt Neerincx.
Conclusión
Con su enrutamiento de solo lectura configurado, AG Listener creado y sus aplicaciones cliente usando las cadenas de conexión correctas, debe tener una conexión totalmente tolerante a fallas para su grupo de disponibilidad. Asegúrese de tomarse un tiempo para probar su conectividad y la capacidad de sus aplicaciones para seguir a sus servidores cuando fallan.
