Skip to content

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

15/07/2013
SQLServerLogo

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

From → Microsoft, SQL Server

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: