La disponibilidad continua de datos es un requisito fundamental en sistemas distribuidos, especialmente en el sector financiero, donde los RTO (Recovery Time Objective) y RPO (Recovery Point Objective) son estrictos. Este artículo aborda el desafío de lograr un failover rápido y consistente para bases de datos SQL Server en un entorno de nube, extendiendo las capacidades de gestión de datos de NetApp ONTAP.
Tradicionalmente, las soluciones de DR para bases de datos relacionales a gran escala implican complejos mecanismos de replicación y sincronización a nivel de aplicación o base de datos, que pueden ser costosos en términos de infraestructura y tiempo de recuperación. La propuesta de S&P Global demuestra cómo las capacidades de almacenamiento subyacentes, como los snapshots y la clonación eficiente de volúmenes, pueden desacoplar la recuperación de la base de datos de la replicación de datos, permitiendo un RTO significativamente menor para el acceso de solo lectura.
La relevancia de esta solución radica en su capacidad para ofrecer una continuidad de negocio robusta, cumpliendo con las exigencias regulatorias y operacionales, al tiempo que aprovecha la elasticidad y el modelo de pago por uso de la nube. Esto se logra mediante la integración de tecnologías maduras de almacenamiento (NetApp ONTAP) con la infraestructura de AWS, resolviendo un problema clásico de la computación distribuida: cómo mantener la disponibilidad y la durabilidad de los datos frente a fallos regionales con un impacto mínimo en el negocio.
Arquitectura del Sistema
La arquitectura de DR se basa en un clúster geo-distribuido de Windows Server Failover Cluster (WSFC) que abarca dos regiones de AWS. En cada región, se despliegan instancias de Microsoft SQL Server sobre Amazon EC2 y sistemas de archivos Amazon FSx para NetApp ONTAP.
La capa de almacenamiento utiliza dos sistemas FSx para NetApp ONTAP: uno en la región primaria (US-East-1) y otro en la región de DR (US-West-2). La replicación de datos entre estas regiones se gestiona mediante SnapMirror, una tecnología de NetApp que replica volúmenes completos de forma asíncrona con un intervalo de 15 minutos, asegurando un RPO bajo. Los datos en tránsito para SnapMirror se cifran con AES-256-GCM.
Para la recuperación rápida, se emplea la tecnología FlexClone de NetApp. Diariamente, un proceso automatizado identifica el snapshot más reciente de SnapMirror en la región de DR y crea un volumen FlexClone a partir de este. Un FlexClone es una copia "point-in-time" de un volumen que comparte bloques de datos con su volumen padre, lo que lo hace extremadamente eficiente en términos de almacenamiento y rápido de crear (menos de 2 minutos). Este volumen FlexClone se presenta a una instancia de SQL Server en modo de solo lectura en la región de DR. En caso de un desastre, el failover inmediato implica simplemente redirigir el tráfico de la aplicación a esta instancia pre-aprovisionada de solo lectura. La recuperación completa a modo de lectura/escritura implica detener SQL Server en la primaria, aplicar la última actualización de SnapMirror, romper la relación SnapMirror, revertir la dirección de replicación y hacer failover de los recursos de SQL Server a los nodos de DR.
Flujo de Recuperación Rápida (Solo Lectura)
- 1 DR Automation Identifica el snapshot SnapMirror más reciente en la región de DR.
- 2 NetApp ONTAP CLI Crea un volumen FlexClone a partir del snapshot identificado.
- 3 FlexClone Volume Se presenta a la instancia SQL Server de solo lectura en la región de DR.
- 4 Application Redirige el tráfico a la instancia SQL Server de solo lectura en DR.
Flujo de Recuperación Completa (Lectura/Escritura)
- 1 Primary Region Detiene SQL Server y congela escrituras.
- 2 SnapMirror Aplica la última actualización al volumen de DR.
- 3 SnapMirror Rompe la relación para hacer el volumen de DR lectura/escritura.
- 4 SnapMirror Invierte la dirección de replicación (DR a Primaria).
- 5 WSFC Hace failover de los recursos de SQL Server a los nodos de DR.
- 6 DR Region Reanuda operaciones normales en modo lectura/escritura.
| Capa | Tecnología | Justificación |
|---|---|---|
| storage | Amazon FSx for NetApp ONTAP | Provee almacenamiento de archivos gestionado con capacidades avanzadas de NetApp ONTAP, incluyendo snapshots y FlexClone, fundamentales para la estrategia de DR. vs Amazon EBS, Amazon EFS, SQL Server Always On Availability Groups Dos file systems desplegados en regiones AWS separadas, con conectividad VPC peering o Transit Gateway. |
| compute | Amazon EC2 | Aloja las instancias de Microsoft SQL Server y los nodos del Windows Server Failover Cluster (WSFC). vs Amazon RDS, SQL Server en máquinas virtuales on-premises Instancias EC2 configuradas para WSFC geo-distribuido. |
| data-processing | Microsoft SQL Server | Base de datos relacional crítica para la plataforma Capital IQ, que requiere alta disponibilidad y DR. Configurado en instancias EC2 con volúmenes FSx para NetApp ONTAP. |
| orchestration | Windows Server Failover Cluster (WSFC) | Gestiona la alta disponibilidad y el failover de los recursos de SQL Server entre nodos en la misma región y entre regiones. Clúster geo-distribuido abarcando dos regiones AWS. |
| networking | VPC Peering / AWS Transit Gateway | Provee conectividad de red segura y de baja latencia entre las VPCs de las regiones primaria y de DR, esencial para SnapMirror. |
Trade-offs
Ganancias
- ▲ Tiempo de Recuperación (RTO) para acceso de solo lectura
- ▲ Eficiencia de almacenamiento en DR
- △ Consistencia de datos (RPO)
- △ Resiliencia durante despliegues de código
Costes
- △ Complejidad de la configuración inicial
- △ Dependencia de tecnologías propietarias (NetApp ONTAP)
volume clone create \
-vserver dr-svm \
-flexclone ciq_data_readonly \
-parent-volume ciq_data_mirror \
-parent-snapshot snapmirror.latest \
-type RWFundamentos Teóricos
El concepto de "point-in-time snapshots" y la replicación eficiente de datos subyacen a muchos sistemas de almacenamiento distribuidos y bases de datos. La idea de clonación de volúmenes con copy-on-write, como FlexClone, se relaciona con los principios de inmutabilidad y eficiencia de espacio, similares a los utilizados en sistemas de archivos como ZFS o en la gestión de versiones de sistemas de control de código fuente. Estos mecanismos permiten crear copias lógicas de datos sin duplicar físicamente todos los bloques, optimizando el uso del almacenamiento y la velocidad de creación.
La implementación de un sistema de recuperación ante desastres que prioriza un RTO bajo para acceso de solo lectura y un RPO bajo para la consistencia de datos se alinea con los principios de disponibilidad y durabilidad en sistemas distribuidos. La replicación asíncrona de SnapMirror, con su compromiso entre latencia y consistencia, es un ejemplo práctico de los trade-offs discutidos en el teorema CAP, donde se prioriza la disponibilidad y la tolerancia a particiones sobre la consistencia estricta en el momento del failover, para luego converger a la consistencia total. La estrategia de dos fases (read-only rápido, luego read-write completo) es un patrón común para balancear estos trade-offs.