Alta Disponibilidad en SQL Server Introducción (HA Parte 1)

Hoy iniciamos una nueva serie en la que vamos a hablar sobre las distintas soluciones de alta disponibilidad que existen para SQL Server. Antes de nada vamos a aclarar los conceptos básicos sobre los que profundizaremos tanto hoy como estos próximos días. A continuación, vamos a resumir brevemente las distintas soluciones de SQL Server que tenemos a nuestro alcance. Solo un breve resumen ya en los próximos artículos que las veremos más en profundidad.

¿Qué es la Alta Disponibilidad?

La alta disponibilidad se refiere a la capacidad de un sistema de seguir funcionando sin interrupciones ante posibles fallos o desastres, ya sean de hardware, software o de infraestructura. 

¿Por qué es importante? 

La alta disponibilidad es importante porque nos permite garantizar la continuidad del negocio, la satisfacción de los clientes y el cumplimiento de los acuerdos de nivel de servicio (SLA).

Aspectos clave para implementar una solución de Alta Disponibilidad

Para evaluar la adecuación de una solución de alta disponibilidad, es necesario tener en cuenta dos conceptos clave: el punto de recuperación objetivo (RPO) y el tiempo de recuperación objetivo (RTO). El RPO indica la cantidad máxima de datos que se pueden perder en caso de un fallo, mientras que el RTO indica el tiempo máximo que se puede tardar en restaurar el servicio. Estos valores dependen del nivel de criticidad del sistema y del presupuesto disponible, y pueden variar desde unos pocos segundos hasta varias horas o días.

Distintas soluciones de Alta Disponibilidad

SQL Server ofrece varias opciones para implementar la alta disponibilidad, dependiendo de las necesidades y los recursos de cada organización. Algunas de las más conocidas son:

Grupos de disponibilidad Always On

Esta es una solución replica datos de forma síncrona o asíncrona entre varias réplicas secundarias con una conmutación por error automática o manual. Los grupos de disponibilidad Always On tienen una réplica primaria que recibe las transacciones y las envía a las réplicas secundarias, que pueden estar en la misma red local o en ubicaciones remotas. Además, las réplicas secundarias pueden usarse para realizar consultas de solo lectura, copias de seguridad o restauraciones, lo que mejora el rendimiento y la escalabilidad de nuestro sistema.

Always On ofrece un RPO y un RTO muy bajos, ya que los datos se sincronizan casi en tiempo real y la conmutación por error se realiza en cuestión de segundos (incluso milisegundos). Los Always On requieren que las instancias de SQL Server pertenezcan a un clúster de conmutación por error de Windows Server (WSFC) para alta disponibilidad y recuperación ante desastres.

Instancia de clúster de conmutación por error

Consiste en tener varios nodos que comparten un almacenamiento común y que pueden asumir el rol de servidor activo en caso de que el nodo principal falle. Los clústeres de conmutación de instancia requieren una configuración especial del hardware, el software y la red, así como una coordinación entre los nodos mediante un testigo (witness). Los clústeres de conmutación de instancia garantizan la disponibilidad del servicio, pero no protegen contra la pérdida o corrupción de los datos al compartir el almacenamiento de los datos. Esta solución tiene un RPO y un RTO moderados, ya que dependen del tiempo que se tarde en detectar el fallo y en activar el nodo secundario. Los clústeres de conmutación de instancia requieren que las instancias de SQL Server estén instaladas en servidores miembros de un clúster WSFC

Database mirroring (Espejo de bases de datos)) 

Esta solución consiste en tener dos instancias de SQL Server que mantienen una copia idéntica de una base de datos mediante el envío del log de transacciones. El database mirroring puede operar en modo síncrono o asíncrono, y puede tener una instancia testigo que supervise el estado de las dos instancias y realice la conmutación por error automáticamente en caso necesario. Proporciona protección contra la pérdida o corrupción de los datos, pero solo se aplica a una base de datos a la vez. Tiene otras limitaciones como que no admite el cifrado transparente de datos (TDE) o los cambios de esquema en línea. Esta solución tiene un RPO y un RTO variables, dependiendo del modo elegido y del tamaño del log.

Log shipping (Envío de Log)

Tendremos una instancia primaria que realiza copias de seguridad periódicas del log de transacciones y las enviará a una o más instancias secundarias que las restauran. El log shipping permite tener varias copias actualizadas (o casi) de una base de datos en diferentes ubicaciones, lo que facilita la recuperación ante desastres. Sin embargo, no ofrece una conmutación por error automática ni una sincronización en tiempo real, por lo que puede haber una pérdida o inconsistencia de los datos. Esta solución tiene un RPO y un RTO altos, ya que dependen de la frecuencia y la duración de las copias de seguridad y las restauraciones.

Otras soluciones de alta disponibilidad

Estas son algunas de las soluciones más populares para lograr la alta disponibilidad en SQL Server, pero no son las únicas. También existen otras opciones como la replicación, el almacenamiento distribuido o los servicios en la nube. Lo importante es evaluar las ventajas y desventajas de cada una, así como los requisitos y objetivos del negocio, para elegir la más adecuada.

Conclusión

Como hemos podido ver SQL Server ofrece diversas soluciones de alta disponibilidad que se adaptan a diferentes escenarios y necesidades. Algunas de estas soluciones requieren un clúster WSFC, mientras que otras no. Es importante conocer las características, ventajas y limitaciones de cada opción, así como los conceptos de RPO y RTO, para tomar una decisión informada y optimizar el rendimiento y la seguridad de los datos.

Espero que os haya gustado este artículo y que os sirva para conocer mejor las opciones de alta disponibilidad que ofrece SQL Server. Como siempre, cualquier duda o comentario, podéis dejarla aquí abajo, por mail o en twitter,