Volver al Índice | Siguiente: Utilizando los servidores secundarios en AlwaysOn

AlwaysOn: Descripción y configuración

¿Qué es AlwaysOn?

Un mecanismo de alta disponibilidad, que permite el cambio de nodo automático, en el que no hay ningún recurso compartido y transparente para la aplicación.

Elementos y Configuración

Para activar AlwaysOn para una o varias bases de datos, se crea un grupo de disponibilidad (“Availability Group”). Vamos a ir siguiendo el asistente y explicando cada uno de los componentes

Antes de iniciar la configuración del grupo de disponibilidad, es necesario haber creado un clúster de Windows con los nodos que van a participar, y haber instalado una instancia de SQL en cada uno de los nodos. Sin embargo, estas instancias serán instancias no clusterizadas, cada una de ellas con su propio nombre.

Hay varias ventajas de tener instancias separadas frente a una única instancia clusterizada, para mí la más importante de ellas es que en el caso de un problema causado por la configuración de la instancia que provoque que uno de los nodos no levante, el resto de los nodos no se verán afectados, y nuestra aplicación no se verá afectada.

En este ejemplo, tendremos dos nodos (AON1 y AON2), cada uno de ellos con una instancia por defecto.

El primer paso para crear un grupo de disponibilidad es habilitar AlwaysOn en ambos nodos, para ello vamos al Configuration Manager y seleccionamos las propiedades del servicio, en la pestaña “AlwaysOn High Availability” activamos el siguiente check:

Es necesario reiniciar el servicio una vez habilitado. A continuación, abrimos Management Studio, y con botón derecho sobre la carpeta “AlwaysOn high Availability” y seleccionamos “New Availability Group Wizard”.

Una vez pasada la pantalla de bienvenida, pasaremos a definir un nombre para este grupo de alta disponibilidad. Este nombre se utilizará sólo para la gestión desde SQL.

El siguiente paso será seleccionar las bases de datos involucradas. Al tener más de una base de datos en el mismo grupo de disponibilidad, se consigue que todas las bases de datos estén disponibles en el mismo nodo, y con el mismo nombre virtual de servidor. De esta manera, si nuestra aplicación hace uso de dos bases de datos diferentes, conviene tener ambas en el mismo grupo. En nuestro caso tenemos una aplicación (App1) que utiliza dos bases de datos (App1_db1 y App1_db2), por lo tanto incluiremos ambas en las bases de datos a seleccionar.

Para poder seleccionar una base de datos, necesitamos haber hecho previamente un backup completo de la misma.

En la siguiente pantalla realizaremos varias configuraciones. En la pestaña “Replicas” elegiremos los servidores involucrados al seleccionar “Add replica”. Es necesario tener conectividad entre ambos servidores por lo que es interesante revisar que el firewall permite esta conectividad.

Una vez conectado, elegimos el tipo de secundario que queremos tener. En este caso hemos elegido síncrono, con failover automático y que permita lecturas en los nodos secundarios:

Otra pestaña importante es la pestaña de “Listener”. En esta pestaña podemos decidir el nombre virtual que vamos a utilizar para la conexión, en nuestro caso lo vamos a llamar App1_DBs. Podemos elegir tanto el puerto como la IP, y será necesario crear la correspondiente regla en el firewall en todos los nodos involucrados:

Una vez configuradas estas opciones, continuamos con el asistente, que nos pedirá una localización donde guardar el backup que se va a realizar (debe ser un share donde la cuenta tenga permisos), y se finalizará la configuración. A partir de este momento podremos observar el grupo de AlwaysOn en Management Studio:

Diferencias de AlwaysOn con otros mecanismos de alta disponibilidad

Diferencias con clúster:

No tenemos disco compartido, esto aumenta el porcentaje de tiempo disponible ya que un fallo de una cabina no provocará una pérdida de servicio.
Aislamiento de la configuración: Como he comentado en el apartado anterior, si al administrar la instancia provocamos un mal comportamiento de la misma, por una configuración no óptima, el resto de los nodos no se verán afectados.
La base de datos está disponible (en modo lectura) en el nodo secundario, por lo que podemos aprovechar la capacidad de la segunda máquina para realizar algunas tareas

Diferencias con database mirroring:

Database mirroring y AlwaysOn son muy parecidos, sin embargo hay dos diferencias fundamentales:

AlwaysOn es transparente para la aplicación, ya que esta se conecta al nombre virtual, y es éste el que la redirige al nodo adecuado.
Capacidad de enrutamiento automático al nodo secundario para consultas de sólo lectura; de esta manera no hay que reconfigurar las aplicaciones secundarias en caso de cambio de rol del nodo. Se puede encontrar más información de este tipo de enrutamiento en: http://msdn.microsoft.com/en-us/library/hh710054(v=sql.110).aspx
Con AlwaysOn se pueden tener hasta 4 secundarios
No es necesario crear snapshots para poder utilizar el nodo secundario como sólo-lectura

Está previsto que database mirroring sea eliminado en versiones futuras, y reemplazado completamente por AlwaysOn.

Diferencias con Logshipping:

Hay dos principales diferencias entre Log Shipping y AlwaysOn: el tiempo de latencia (considerablemente menor en el caso de AlwaysOn) y que no es necesaria la transmisión de ficheros entre nodos.

NOTA: Estas capturas de pantalla se han realizado utilizando la versión descargable de MSDN.