Este documento presenta una introducción a la alta disponibilidad con SQL Server 2012. Explica conceptos clave como Windows Server Failover Clustering, SQL Server SMB Shares y AlwaysOn Availability Groups. Detalla la arquitectura de alta disponibilidad y recuperación de desastres usando estas características. También cubre temas como el failover del cliente y el uso de servidores secundarios activos.
Estableciendo escenarios de Alta Disponibilidad en las empresas de hoy con MS SQL Server 2012
1. Alta Disponibilidad con
MS SQL Server 2012
José Redondo - @redondoj
CL SQL PASS Venezuela – DPA SolidQ – CA SynergyTPC – DAA Bits America
jredondo@solidq.com
http://redondoj.wordpress.com
5. INTRODUCCIÓN
Que es?
MS SQL Server 2012 incluye nuevas características de alta disponibilidad que
mejora y combina la capacidades de:
• Database Mirroring
• Log Shipping
• Failover Clustering
Proveyendo con esto una solución de Alta Disponibilidad y Recuperación de
desastres para aplicaciones criticas de bases de datos y también para toda la
instancia de SQL completa
7. INTRODUCCIÓN
Configuraciones:
• SQL Server SMB (Server Message Block) Shares
• Antes
• Direct Attached Storage (DAS)
• Storage Area Network (SAN)
• Ahora
• Red compartida (Almacenamiento remoto consolidado)
• Alto desempeño
• Administración simple
• Archivos compartidos SMB <> LUNs
• Ejecución dinámica de ubicaciones (Server | Servicios)
• Minimiza lo complejo
• Directorio compartido SMB
8. INTRODUCCIÓN
Configuraciones:
• AlwaysOn Availability Group
• Es una nueva capacidad que ayuda a proteger las bases de datos de tiempos fuera de
línea planificados y no planificados.
• AlwaysOn Failover Cluster Instance
• Provee protección para toda la instalación y es una mejora a las funcionalidades
actuales de SQL Server Failover Cluster Instance.
Tanto AlwaysOn Availability Group y AlwaysOn Failover Cluster Instance
utilizan el Windows Server Failover Clustering
9. INTRODUCCIÓN
INTEGRACIÓN
•
•
•
•
•
•
•
Simplificación y Unificación
Fácil de Implementar y manejar
Failover de la aplicación usando un
Nombre Lógico
Wizard de Configuración
Dashboard
Integración con System Center
Rica infraestructura de diagnostico
FLEXIBLE
•
•
•
•
•
•
•
Failover de multiples bases de datos
Multiples Secundarios:
• Total de 4 secundarios:
• 2 secundarios Síncronos
• 1 par para Failover
Automatic
Movimiento de data Síncronos y
Asíncronos
Compresión y Encriptación innata
Failover automatic y manual
Política de Failover Flexible
Reparación Automática de Paginas
EFICIENTE
•
•
•
•
Costo-efectivo:
• Uso del Hardware
• No sistemas idle
Mejora de la eficiencia IT
Secundarios Activos:
• Secundarios Solo-Lectura
• Backup desde Secundarios
Automatización usando Power-Shell
12. CONCEPTOS
• Windows Server 2012 Failover Cluster
• SQL Server SMB Shares
• AlwaysOn Availability Groups
•
•
•
•
Replicas y Roles (Availability)
Modos de Sincronización de Data y Failover
Availability Listeners
Availability Group Dashboard
14. SQL Server SMB Shares
SQL Server
SQL Server
Acceso a archivos (SMB)
Servidor de Archivos
Block Access
Discos
SQL Server
15. AlwaysOn Availability Groups
• Unidad de Alta disponibilidad
• Un grupo de base de datos que hacen Failover como una
unidad
• Define la localidad de las replicas
• Define la configuración para cada replica
• Para empezar a usar los Availability Groups, debe ser habilitado
en el SQL Configuration Manager o vía Windows PowerShell
• Cada Availability Groups crea una aplicación (grupo) en el
Windows Server cluster
16. Replicas y Roles (Availability)
• Sobre instancias clusterizadas o no clusterizadas
• Cada copia es llamada una replica
• La replica active es llamado "Primary", y cualquier otra replica es
llamado "Secondary"
• Dado un grupo de disponibilidad normalmente cada réplica
debe estar en una instancia distinta
• Colisión nombres bases de datos, ficheros, etc
• Si es posible en instancias clusterizadas
• Es viable también en máquinas virtuales en el mismo host
17. Replicas y Roles (Availability)
• Se puede configurar hasta cuatro replicas secundarias:
• Pueden ser síncronas o asíncronas
• Un máximo de 2 replicas secundarias síncronas
• Las replicas no sustituyen a las instancias clusterizadas
• Bases de datos de sistema independientes
• Seguridad, Jobs, Configuración, Servidores enlazados
• Estados de las replicas secundarias:
• Not Readable
• Readable
• Read-Intent
18. Modos de Sincronización de Data y
Failover
• Modo síncrono con Failover automático:
•
•
•
•
No hay perdida de datos
Solo es posible en un par (replica primaria y 1 replica secundaria)
Failover cluster detecta y controla el Failover
Solo las bases de datos en el Availability Group hacen Failover. Todas
las demás bases de datos continúan corriendo en la instancia actual
• Modo síncrono con Failover manual:
• No hay perdida de datos
• Si un Failover es necesario, se deberá ejecutar manualmente
19. Modos de Sincronización de Data y
Failover
• Modo Asíncrono:
• Alto rendimiento, porque la replica primaria no espera por el log
hardering de las replicas secundarias
• Posible perdida de datos
• Si un Failover es necesario, se debe forzar manualmente, y puede que
pierdas data que no ha sido replicada
20. Availability Listeners
• Similar al Network Name en SQL Server clustering
• Necesario utilizar el protocolo TCP para conectar
• Server=tcp:MiServidor;Database=db1;IntegratedSecurity=SSPI
• Redirección en función del valor de ApplicationIntent
• ReadWrite - Réplica principal (Por defecto)
• ReadOnly - A una de las replicas read-only disponibles
• Define un endpoint donde los clientes pueden conectarse a la
instancia:
•
Incluye un nombre de red, dirección IP y puerto
•
Define los parámetros
23. ARQUITECTURA
Database Mirroring para Alta Disponibilidad y Log Shipping para recuperación de desastres
Centro de Datos Primario
SQL Server
Principal
Espejo de Base de
Datos
Sincrónica
SQL Server
Mirror
Centro de Datos de
Recuperación de Desastres
SQL Server
Warm Standby
Log Shipping
SQL Server
Testigo
24. ARQUITECTURA
Usando Availability Group para alta Disponibilidad y Recuperación de Desastres
Centro de Datos de
Recuperación de
Desastres
Centro de Datos Primario
Windows Server Failover Cluster (Uno sencillo cruzando dos Centros de Datos)
SQL Server
Principal
SQL Server
Secundario
SQL Server
Secundario
Sincrónico
Asincrónico
Availability Group
25. ARQUITECTURA
Asignación de nodos para el despliegue del Availability Group HA + DR (High Availability + Desaster Recovery)
con el Node Majority Quorum Model
Centro de Datos de
Recuperación de Desastres
Centro de Datos Primario
Windows Server Failover Cluster (Uno sencillo cruzando dos Centros de Datos)
SQL Server
Principal
SQL Server
Secundario
SQL Server
Secundario
Sincrónico
Asincrónico
Availability Group
Servidor adicional para Node Majority Quorum Model
26. ARQUITECTURA
Asignación de nodos para el despliegue del Availability Group HA + DR (High Availability + Desaster Recovery)
con File Share
Centro de Datos de
Recuperación de Desastres
Centro de Datos Primario
Windows Server Failover Cluster (Uno sencillo cruzando dos Centros de Datos)
SQL Server
Principal
SQL Server
Secundario
SQL Server
Secundario
Sincrónico
Asincrónico
Availability Group
File Share (Archivos compartidos)
27. ARQUITECTURA
Solución de HA-DR de Availability Groups usando 3 centros de datos
Centro de Datos Primario
Centro de Datos de
Recuperación de Desastres
3er Centro de Datos
Windows Server Failover Cluster
SQL Server
Secundario
SQL Server
Principal
Sincrónico
File Share
(Archivos compartidos)
Availability Group
29. Failover del Cliente
• Availability Group Listener
• Define un Endpoint donde los clientes
pueden conectarse a la instancia:
• Incluye un nombre de red, dirección IP y
puerto.
• Define los parámetros para el recurso del
cluster (Dirección IP y Nombre)
• Permite el Failover transparente a
cualquier secundario:
• La Aplicación se reconecta usando un
nombre lógico después de un Failover a
una replica secundaria.
-server HR_Listener;-catalog HRDB
La aplicación debe tener lógica de reintento de conexión,
para conectarse al nuevo primario una vez que el Failover
halla completado y el Listener este en línea.
31. AlwaysOn Servidores Secundarios
• La eficiencia de IT y la relación costo-beneficio es critica para un
negocio:
• Idle hardware ya no es una opción
• AlwaysOn Active Secondary habilita el uso eficiente de los recursos
de hardware proveídos para la alta disponibilidad, y por tanto
proveyendo eficiencia en IT.
• Active Secondary puede ser usado para:
• Balancear cargas de trabajo de solo lectura
• Realizar operación de Backup
• Chequeos de Integridad de la base de datos (DBCC CHECKDB)
32. AlwaysOn Servidores Secundarios
Active Secondary: Habilitando el Backup en la replica Secundaria
• Los Backups pueden hacerse en cualquier replica de la base de datos
• Los Backups en la replica primaria aun funcionan
• Los Backups de los log de transacciones hechos en cualquier replica
crean un único log chain
• Database Recovery Advisor hace la restauración mucho mas
simple.
34. Copias en la replica
Configurar el Routing URL para cada secundaria
Endpoint para conexiones de solo-lectura
ALTER AVAILABILITY GROUP nombre_AG
MODIFY REPLICA ON ‘nombre_servidor'
WITH (
SECONDARY_ROLE (
READ_ONLY_ROUTING_URL = ‘TCP://direccion:puerto’ ) )
35. Copias en la replica
Crear el Routing List para cada replica que debe ser Primaria
- Lista de secundarias de Lectura
- La Primary retorna el primer valor disponible
- Carga balanceada no disponible (Es implementable)
ALTER AVAILABILITY GROUP ag_nombre
MODIFY REPLICA ON ‘nombre_servidor'
WITH (
PRIMARY_ROLE (
READ_ONLY_ROUTING_LIST = {‘server_name’ [, . . n]}) )
36. Conectividad de clientes
Solo-Lectura
• El comportamiento de la conexiones clientes de Solo-Lectura es
determinado por la opción de configuración de la Availability
Replica + la característica ApplicationIntent de la aplicación
• ApplicationIntent es una propiedad a nivel de la conexión.
• La opción de la Replica determina si la replica esta habilitada para
acceso de lectura cuando posee un rol secundario.
• El Read-Only Routing habilita la redirección de conexiones de
clientes hacia un Nuevo Secundario cuando su rol cambia:
• Habilita una redirección transparente de las conexiones de aplicaciones
de solo lectura, entre las replicas secundarias sin intervención manual.
38. CONCLUSIONES
• Imprescindible implementar un Windows Cluster
• No es recomendable instalar un Instancia de SQL Server en
dicho cluster
• Activar la opción de AlwaysOn en SQL Server Configuration
Manager
• Las aplicaciones deben manejar una lógica de reintento de
conexión
• Aprovechar e incrementar el uso de recursos con Secundarios
Activos
INFRAESTRUCTURA DE LA NUBE PRIVADA1.- System Center: Admin nube privada2.- Hyper V: Plataforma de nube privada3.- WS Failover Clustering: Infraestructura Privada
Por qué es necesario el quórumLos problemas de red pueden interferir en la comunicación entre los nodos de un clúster. Es posible que un grupo reducido de nodos pueda comunicarse entre sí a través de una parte en funcionamiento de la red, pero que no pueda comunicarse con un grupo de nodos diferente en otra parte de la red. Esto puede causar problemas graves. En esta situación de "división", al menos uno de los conjuntos de nodos debe dejar de ejecutarse como un clúster.Para prevenir los problemas ocasionados por una división en el clúster, el software del clúster requiere que cualquier conjunto de nodos que se ejecute como un clúster debe usar un algoritmo de voto para determinar si, en un momento dado, ese conjunto dispone de quórum. Puesto que el clúster especificado tiene un conjunto específico de nodos y una configuración de quórum específica, el clúster sabrá la cantidad de "votos" necesaria para constituir una mayoría (es decir, quórum). Si el número cae por debajo de la mayoría, el clúster deja de funcionar. Los nodos seguirán detectando la presencia de otros nodos, en el caso de que otro nodo aparezca de nuevo en la red, pero no empezarán a funcionar como un clúster hasta que vuelva a existir quórum.Por ejemplo, en un clúster de cinco nodos que usa una mayoría de nodos, tenga en consideración lo que ocurriría si los nodos 1, 2 y 3 pudieran comunicarse entre sí pero no con los nodos 4 y 5. Los nodos 1, 2 y 3 constituyen una mayoría y siguen ejecutándose como un clúster. Los nodos 4 y 5, al ser minoría, dejan de ejecutarse como un clúster. Si el nodo 3 pierde la comunicación con el resto de nodos, todos los nodos dejan de ejecutarse como un clúster. Sin embargo, todos los nodos en funcionamiento continuarán recibiendo comunicación, por lo que, cuando la red vuelve a funcionar, el clúster puede formarse y empezar a ejecutarse.