Comparación de técnicas de alta disponibilidad con SQL Server

Una de las implementaciones que estamos realizando con mayor frecuencia con mis clientes es el de esquemas de alta disponibilidad para servidores y bases de datos SQL Server. Al momento de realizar estas implementaciones, lo primero a considerar es que técnica o combinación de técnicas usaremos, en base a los requerimientos de la empresa y a los elementos de hardware y software disponibles.

En la siguiente tabla resumo las ventajas y desventajas para cada una de las técnicas existentes, indicando además en que versión del producto se pueden implementar.

Técnica	Ventajas y desventajas
Clúster (SQL 2005/2008/2012)	Ventajas Técnica tradicional y probadaRelativamente transparente para la aplicaciónSe paga licencia por el nodo activo Desventajas Requiere de hardware específico y su configuración es poco flexible. Es necesario contar con almacenamiento compartido. Nodo inactivo normalmente desperdiciado Punto de falla simple en el almacenamiento (única copia de la base de datos) En caso de failover las conexiones de las aplicaciones se caen Failover en alrededor de 30 segundos en el mejor de los casos. Se aplica a todo el motor SQL, no se pueden elegir bases de datos Los nodos de un clúster no pueden normalmente estar geográficamente separados.
Database Mirror (SQL 2005/2008/2012)	Ventajas No requiere hardware específicoSincronización sincrónica o asincrónicaFailover automático (con servidor witness) Soporta failover en las aplicaciones vía connection string Existen 2 copias físicas de la base de datos Desventajas La réplica secundaria no se puede leer (salvo usando snapshots, pero no es una forma normalmente apropiada) Solo una réplica que no posee uso alguno salvo al momento de realizar un failover Se debe implementar y administrar por cada base de datos El failover automático depende de la configuración y funcionamiento de un servidor witness.
Log shipping (SQL 2005/2008/2012)	Ventajas No requiere hardware específicoLa réplica puede ser leída por las aplicaciones (solo lectura)Es un proceso simple y eficiente Permite retrasar o detener la sincronización ante una falla en la base principal. Desventajas Se deben desconectar a los usuarios al momento de actualizar la réplica Posee en general un alto tiempo de latencia entre que se actualiza un dato y el cambio llega a la réplica. Dependiendo de la configuración pueden pasar horas para la actualización. Consume cantidades significativas de espacio en disco en bases de datos grandes o con alta actividad. Genera archivos de log muy voluminosos ante operaciones de mantenimiento, como reindexado. No provee un failover automático.
AlwaysOn Availability Groups (SQL 2012)	Ventajas Hasta 4 réplicas. Cada réplica puede funcionar en un modo distinto (sincrónico o asincrónico)Grupos de bases de datos permiten la administración y el failover de varias bases a la vez.Cualquiera de las réplicas puede ser leída. Se puede realizar backup desde una réplica Redireccionamiento automático de conexiones en caso de un failover autmático o manual (configurando el servicio de listener) Redireccionamiento automático de conexiones, distribuyendo la carga de escritura y lectura (requiere listener) No posee limitaciones geográficas ni de distancia entre nodos. Compresión y encriptación de datos en la comunicación. Desventajas Requiere versión enterpise de SQL Server en cada uno de los nodos de AO.

Analizando las distintas alternativas, la mejor opción disponible al momento es el uso de AlwaysOn Availability Groups, sobre SQL Server 2012. Esta técnica nos brinda prácticamente todas las funcionalidades que uno podría requerir, con la única contrapartida de que requiere para su funcionamiento la edición Enterprise de SQL Server.

Pueden encontrar más información sobre el uso y características de la tecnología de AlwaysOn y su opción de Availability Groups en mis siguientes post:

Alta disponibilidad con SQL Server 2012 – Always On, primera parte

SQL Server 2012: Requisitos para la implementación de alta disponibilidad con AlwaysOn

AlwaysOn Availability Groups de SQL Server 2012 vs. Database Mirror de SQL Server 2008

Experiencias en la implementación de Always On Availability Groups con SQL Server 2012