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.
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
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.
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.
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.
A continuación tenemos una ventana en la que podemos revisar las opciones y confirmar pulsando en Finish para que se configure el grupo.
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.
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.
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.
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.
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
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.
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.
Las características y configuraciones descritas han sido evaluadas sobre SQL Server Denali CTP3.
Espero que lo encontréis de utilidad, ¡Hasta pronto!
