Configurar un clúster SQL Servers con AlwaysOn Availability Group. Parte 2

Si en anteriores publicaciones os explicamos un poco que eran los AlwaysOn Availability Group y cómo empezábamos a construir el entorno, en esta entrada os daremos los pasos para configurar el clúster.

Configuración SQL Server

Antes de crear el grupo de disponibilidad, debemos tener unos pasos previos. Primero, habilitaremos AlwaysOn Availability Groups usando el “Configuration Manager” del SQL Server 2019:

Hacemos clic derecho en el servicio “SQL SERVER” y seleccionamos “properties”:

Ya que estamos en las propiedades del SQL server, podemos hacer dos cosas. La primera es marcar el check de “Enable Always On Availbility Groups” en la pestaña “Always On Availability Groups”.

La otra es añadir el usuario que hemos comentado al inicio del tutorial, para que inicie el SQL Server y haga las conexiones entre servers:

Create Availability Group AlwaysOn

Para crear un nuevo grupo de disponibilidad accedemos al “SQL Server Managment Studio” y hacemos clic derecho en la carpeta Availability Groups para iniciar el wizard de creación:

Con el wizard abierto, le asignamos un nombre al grupo y comprobamos que el tipo de clúster es “Windows server Failover Cluster”:

Seleccionamos la base de datos que queremos que esté en el grupo:

En la siguiente pantalla solo nos aparecerá el nodo primario. Así, añadiremos un nuevo nodo y hacemos check en “Automatic Failover”:

En nuestro caso, los dos servidores que conforman el clúster son exactamente iguales, por lo que podemos dejar la opción por defecto:

Cambiamos a la pestaña “Listener” y creamos un listener para el grupo de disponibilidad, dándole un nombre que añadiremos a DNS, asignar un puerto de escucha y una IP:

Validamos que todo está correcto:

Comprobamos en el sumario que todos los datos que hemos introducido son correctos:

Ya tenemos el Availability Group creado y en funcionamiento:

Connection String

Para poder conectarnos a nuestra nueva estructura y sacar provecho a la alta disponibilidad que ofrece los AG, ya no es necesario realizar la petición de forma directa al servidor SQL principal. Usaremos el “listener” que configuramos en el paso anterior. Para ponernos en situación, un connection string sin AG tendría una estructura como la siguiente:

       Server=ServerName;Database=dbName;User Id=user;Password=***;

Nuestra estructura el connection string sería el siguiente:

     Server=icm-lab02.testing2.icm;Database=Test;User Id=user;Password=***;

Como vemos, la petición va directa al servidor y eso ya no es la forma correcta de operar con los AG. Debería tener la estructura siguiente:

   Server=tcp:AGlistener_name,AGlistener_port;Database=dbName;User       Id=user;Password=***;

Para que funcionara con lo visto en este tutorial, el connection string quedaría de la siguiente forma:

   Server=tcp:AG_listener,5504;Database=Test;User Id=user;Password=***;

En el caso de que tuviéramos X nodos que solo atendiera peticiones de lectura, podríamos indicarlo en el string de conexión:

   Server=tcp:AG_listener,5504;Database=Test;User     Id=user;Password=***;ApplicationIntent=ReadOnly

Conclusión

La herramienta que propuso Microsoft con los Availability Groups AlwaysON es muy útil. Permite que el servicio esté inactivo el menor tiempo posible antes de que balancee toda la carga al nodo secundario, que se convertirá en primario para aceptar nuevas peticiones de lectura y de escritura.

En el entorno que hemos creado no se aprovecha del todo el Quorum. El Quorum permite que no haya un error de “Split Brain”, ya que los nodos que forman parte del Availability Group se ponen de acuerdo sobre qué datos son los correctos en caso de algún fallo, por lo que a más nodos más difícil que haya este error. Además, cuenta con una buena escalabilidad en caso de que queramos poner más nodos a la estructura.