GCP: SQL Server AO-AG con una sola subred
Introducción
Los grupos de disponibilidad AlwaysOn de SQL Server (AOAG) permiten a los usuarios implementar una conmutación por error automatizada y de alta disponibilidad con bases de datos de SQL Server. Por lo general, se implementa mediante subredes múltiples en Google Cloud.
Sin embargo, a veces puede ser conveniente implementarlo en una sola configuración de subred. Lo cual podría deberse a que el diseño de la red se planeó solo para tener una subred por región y agregar nuevas subredes podría ser difícil.
Nota: La configuración de implementación de múltiples subredes es más simple (menos componentes) que la configuración de una sola subred. Por lo tanto, prefiera utilizar varias subredes si puede.
Comprender el problema con una sola subred
Por lo general, los grupos de disponibilidad dentro de una sola subred deben tener una IP flotante. En GCP, las IP flotantes verdaderas no están disponibles. Por lo tanto, la siguiente solución es una solución para imitar la ip flotante mediante el uso del componente de balanceador de carga interno (ILB) de GCP.
Arquitectura
Los nodos de SQL Server formarán parte del grupo de clúster de conmutación por error de Windows Server (WSFC), con siempre activado habilitado. La IP de AG-Listener coincide con la IP de ILB (balanceador de carga interno). Esto significa que cualquier tráfico enviado a ILB se enrutará a AG-Listener. Esto crea una ilusión (para SQL Server) de que Listener IP está flotando entre nodos. En realidad, esa IP (por ejemplo, 10.128.0.20 en el diagrama a continuación) solo se adjunta a ILB y NO a los nodos de SQL Server. Se crea una verificación de estado en la capa WSFC mediante la cual ILB puede enrutar el tráfico al primario actual.
La secuencia de implementación de recursos es importante aquí, AG-Listener debe crearse primero y ILB debe crearse solo después de eso. Cuando se crea AG-Listener, el servidor Windows / SQL comprueba automáticamente si esa IP ya está en uso o no. Por lo tanto, si se crea ILB primero, la creación de AG-Listener fallará.
La verificación de estado en WSFC se crea a través de la siguiente configuración de PowerShell en el clúster WSFC. Ejemplo de código de verificación de estado como se muestra a continuación. Permite que el puerto 59997 acepte conexiones en cualquier nodo del servidor SQL que sea primario.
$ cluster_network_name = 'Red de clúster 1'
$ ip_resource_name = 'sql-ag_10.128.0.20'
$ load_balancer_ip = '10 .128.0.20 '
[int] $ health_check_port = 59997
Get-ClusterResource $ ip_resource_name |
Set-ClusterParameter -Multiple @ {'Dirección' = $ load_balancer_ip;
'ProbePort' = $ health_check_port;
'SubnetMask' = '255.255.240.0';
'Red' = $ cluster_network_name;
'EnableDhcp' = 0; }
En correspondencia con lo anterior, se muestra la necesidad de configuración de verificación de estado en la capa ILB para sondear el puerto 59997 y determinar el nodo principal.
Las comprobaciones de estado de gcloud compute crean tcp sql-healthcheck \
--check-interval = "2s" \
- umbral-saludable = 1 \
- umbral-insalubre = 2 \
--puerto = 59997 \
--request = 10.128.0.20 \
--timeout = "1s"
Pasos de implementación detallados
https://cloud.google.com/community/tutorials/sql-server-ao-single-subnet
He publicado instrucciones detalladas paso a paso como las anteriores.
GCP - SQL Server AO-AG con una sola subred se publicó originalmente en Google Cloud - Community on Medium, donde las personas continúan la conversación destacando y respondiendo a esta historia.