Con éste concluyo mi serie de artículos sobre alta disponibilidad basado en unidades de disco de red, solo recordar que los este es el tercero de tres artículos que me había planteado, el primero explicaba la instalación de Windows Storage Server 2008 R2 y la creación de unidades de disco de red, en el segundo estábamos viendo como instalar un cluster de Windows Server 2008 R2 usando las unidades de red compartidas y por ultimo vamos a usar esa instalación de Failover cluster para instalar y probar los grupos de disponibilidad (Availability Groups), esta es una nueva característica de alta disponibilidad (High Availability) que incorpora  lo que parece que será SQL Server 2012 (Code Name Denali).

Introducción a los grupos de disponibilidad (AlwaysOn Availability Groups)

Se trata de una característica de alta disponibilidad alternativa a Database Mirroring que permite asegurar la disponibilidad de un conjunto de bases de datos.

Cada grupo de disponibilidad  que se defina podrá albergar varias bases de datos, en caso de fallo del principal todas las bases de datos del grupo se moverían a otro nodo.

Una característica destacable es la posibilidad de configurar algunas de las réplicas como consultables en modo solo lectura. La solución nos permite disponer de un primario y hasta 4  servidores secundarios, además cada una de las replicas debe residir en un nodo independiente de un failover cluster de Windows Server, otras características a tener en cuenta son los modos de sincronía permitidos y modos de acceso de la solución sobre los que puedes ampliar información  Aqui.

Configurando la solución

Partiendo de la base de que ya tenemos configurado nuestro servicio de failover cluster con dos nodos (nodo1 y Nodo2) el resumen de pasos a seguir es el siguiente:

  • Instalación de las instancias de SQL Serve Denali en cada nodo
  • Habilitado de la característica AlwaysOn Availability Groups
  • Creación del grupo de disponibilidad
  • Creación de listener del grupo de disponibilidad
  • Pruebas de conexión al listener y failover del grupo de disponibilidad

 

Instalación de las instancias de SQL Server Denali en cada nodo

No voy a detallar la instalación de SQL Server ya se trata de una instalación local sobre el nodo que no tiene ninguna dificultad, pero si voy a indicar algunas de las configuraciones que creo que son de utilidad post instalación.

Las cuentas de gestión de servicios las he establecido sobre un usuario de dominio, lo que me facilita controlar el acceso desde otros nodos a un recurso compartido que debemos proporcionar para compartir los backups de las bbdd a configurar en el grupo de disponibilidad.

Me he asegurado de que esta habilitado el acceso remoto y he habilitado el protocolo TCP/IP en cada una de las instancias. Requiere reinicio del servicio de SQL Server.

He compartido la carpeta de Backups configurada por defecto en la instancia de SQL Server (practica poco recomendable para entornos de producción), pero lo he hecho así por simplicidad, además he otorgado permisos de lectura al usuario que gestiona el servicio a dicha carpeta en el nodo1 que en mi caso ejercerá el rol de primario.

Habilitado de la caracteristica AlwaysOn Availability Groups

Se habilita la configuración de la característica de grupos de disponibilidad en SQL Server configuration Manager en las propiedades del servicio, pestaña AlwaysOn High Availability.

Destacar sobre la captura que la caja de texto Windows failover cluster name refleja el servicio de cluster en el que están el conjunto de nodos sobre el que queremos configurar las réplicas, sin la disponibilidad de un servicio de cluster esta opción no se encuentra disponible. Este cambio en la configuración requiere reinicio del servicio de SQL Server. Se deben habilitar todos los nodos del cluster que queramos que participen como réplicas.

Enable-AlwaysOn-Availilability-Groups_thumb_418EAF8A

 

 

Creación del grupo de disponibilidad

La configuración del Grupo de disponibilidad se puede realizar de forma manual y usando el asistente. En este caso he usado el asistente que se inicia usando SQL Server Management Studio conectado a la instancia que funcionara como primario(Nodo1).

En la carpeta de Management localizamos Availavility Groups y haciendo clic con el botón derecho del ratón elegimos New Availability Group Wizard

New-availability-group-Wizard_thumb_418EAF8A

 

Enseguida el asistente nos presenta la ventana de bienvenida en la que hacemos next.

Especificamos en nombre del grupo , en mi caso será TestGrupo1 y pulsamos sobre next.

La siguiente opción nos permite elegir las bases de datos a incluir en el grupo, para cada caso se evalúa si existe un backup completo que es necesario para restaurar en los secundarios para completar el asistente.

Select-databases4_thumb_418EAF8A

El siguiente paso nos permite elegir las instancias donde se replicara el grupo, tenemos un control que nos permite conectarnos a cada instancia a incluir, además contamos con una pestaña adicional en la que podemos configurar los endpoints que sirven para la comunicación entre nodos.

En este apartado podemos ver que por defecto se usa el puerto 5022 que tendremos que abrir en la configuración del firewall de cada nodo.

Select--Replicas_thumb_418EAF8A

El siguiente paso consiste en la configuración del Listener del Grupo, en mi caso marco la opción Skip para configurarla más adelante a mano, ya que el asistente solo proporciona la opción de usar una dirección DHCP y yo prefiero configurar el listener con  una dirección IP fija.  (Ver apartado Creación de listener del grupo de disponibilidad)

 

La siguiente ventana nos permite sincronizar inmediatamente las bases de datos  mediante backup/Restore, también podemos optar por realizar manualmente paso al finalizar el asistente, en mi caso opto por probar la configuración automática  durante la ejecución del asistente.

Select-data-Synchronization_thumb_418EAF8A

A continuación tenemos una ventana en la que podemos revisar las opciones y confirmar pulsando en Finish para que se configure el grupo.

Finish_thumb_418EAF8A

 

 

Al terminar la configuración el asistente nos presenta una ventana con el resumen de la configuración con un desglose de tareas, muy útil para identificar donde ha fallado el proceso.

Results_thumb_418EAF8A

 

Creación de listener del grupo de disponibilidad

El listener nos va permitir entre otras cosas especificar un nombre de instancia virtual para el grupo de disponibilidad.

Para configurar el listener tenemos dos opciones mediante script T-SQL o usando Management Studio conectado al nodo Principal, carpeta Management y expandimos Availability Groups, expandimos el grupo de disponibilidad TestGroup1 y sobre la carpeta Availability Group Listener hacemos clic derecho del ratón, elegimos New Listener.

Listener_thumb_418EAF8A

En la ventana  New Availability Group Listener, configuramos la dirección IP y nombre del listener en modo Static. En mi caso he dejado el nombre propuesto por defecto porque me parece bastante ilustrativo y lo he asociado a la IP fija 192.168.1.60 que sé que no se está usando en mi entorno.

New-Llistener-_thumb_418EAF8A

 

Pulsamos sobre Ok para crear el listener, al crear el listener realmente estamos configurando una aplicación nueva en nuestro cluster como se puede apreciar en la siguiente captura sobre la herramienta de gestión del cluster.

Configuracion-de-app-en-el-cluster-_thumb_418EAF8A

 

Pruebas de conexión al listener y failover del grupo de disponibilidad

Para comprobar si el listener está funcionando bien abro una conexión con Management Studio al nombre del listener TestGroup1_Listener

image_thumb_1_418EAF8A

En esta primera prueba el grupo de disponibilidad está siendo soportado por el nodo1 como demuestra lo siguiente: Le solicitamos a la instancia nos retorne el nombre del hostname donde está instalada.  Adicionalmente podemos ver bajo Management en los grupos de disponibilidad  las réplicas disponibles el NODO1 está actuando como Primario y el Nodo2 funciona como Secundario.

Test_1_thumb_418EAF8A

 

A continuación en el nodo1 deliberadamente apago el servicio de SQL Server, el resultado es que se produce un cambio de roles en el grupo de disponibilidad pasando a ser principal de forma automática en nodo2.

Volvemos a conectarnos al listener para volver a consultar que hostname sostiene ahora el grupo, lo primero que observamos es que el icono del nodo principal en el árbol del explorador ha cambiado mostrando ahora un icono de un cuadrado rojo.

Por otro lado en las réplicas disponibles bajo la configuración del grupo de disponibilidad observamos que los roles se han invertido siendo ahora NODO1 Secundario y NODO2 Primario y por ultimo re ejecutamos de nuevo la consulta y nos dice que el grupo está siendo soportado por el NODO2.

Test2_thumb_418EAF8A

 

 

Las características y configuraciones descritas han sido evaluadas sobre SQL Server Denali CTP3.

 

Espero que lo encontréis de utilidad, ¡Hasta pronto!

 

0 Shares:
Deja una respuesta

Tu dirección de correo electrónico no será publicada.

You May Also Like