Estableciendo escenarios de Alta Disponibilidad en las empresas de hoy con MS SQL Server 2012

Alta Disponibilidad con MS SQL Server 2012

José Redondo - @redondoj

CL SQL PASS Venezuela – DPA SolidQ – CA SynergyTPC – DAA Bits America

[email protected]

http://redondoj.wordpress.com

AGENDA

• Introducción

• Conceptos

• Arquitectura

• Failover del Cliente

• AlwaysOn Servidores Secundarios

• Conclusiones

Alta Disponibilidad conMS SQL Server 2012

INTRODUCCIÓN

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

INTRODUCCIÓN

Configuraciones:

• Windows Server 2012 Failover Cluster• Hyper-V

• Failover Clustering

• File and Storage Services

• Network Adapter Teaming

• Hyper-V Virtual Switch

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

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

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

INTRODUCCIÓN

AsincrónicoAsincrónico

Asincrónico

SincrónicoSincrónico

CONCEPTOS

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

Windows Server 2012Failover Cluster

SQL Server SMB Shares

SQL Server SQL Server SQL Server

Servidor de Archivos

Discos

Acceso a archivos (SMB)

Block Access

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

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

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

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

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

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

Availability Group Dashboard

ARQUITECTURA

ARQUITECTURA

Centro de Datos Primario

SQL Server

Principal

SQL Server

MirrorEspejo de Base de

Datos

Sincrónica

Centro de Datos de

Recuperación de Desastres

SQL Server

Warm Standby

SQL Server

Testigo

Log Shipping

Database Mirroring para Alta Disponibilidad y Log Shipping para recuperación de desastres

ARQUITECTURA


SQL Server

Principal

SQL Server

Secundario

Availability Group

Centro de Datos de

Recuperación de

Desastres

SQL Server

Secundario

Sincrónico

Usando Availability Group para alta Disponibilidad y Recuperación de Desastres

Asincrónico

Windows Server Failover Cluster (Uno sencillo cruzando dos Centros de Datos)

ARQUITECTURA


SQL Server

Principal

SQL Server

Secundario

Availability Group

Centro de Datos de


SQL Server

Secundario

Sincrónico

Asignación de nodos para el despliegue del Availability Group HA + DR (High Availability + Desaster Recovery)

con el Node Majority Quorum Model

Asincrónico


Servidor adicional para Node Majority Quorum Model

ARQUITECTURA


SQL Server

Principal

SQL Server

Secundario

Availability Group

Centro de Datos de


SQL Server

Secundario

Sincrónico

Asignación de nodos para el despliegue del Availability Group HA + DR (High Availability + Desaster Recovery)

con File Share

Asincrónico


File Share (Archivos compartidos)

ARQUITECTURA


SQL Server

Principal

Availability Group

Centro de Datos de


SQL Server

Secundario

Solución de HA-DR de Availability Groups usando 3 centros de datos

Sincrónico

Windows Server Failover Cluster

3er Centro de Datos

File Share

(Archivos compartidos)

FAILOVER DEL CLIENTE

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.

ALWAYSON SERVIDORES SECUNDARIOS

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)


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.


• Copias en la replica

• Conectividad de clientes Solo-Lectura

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’ ) )

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]}) )

Conectividad de clientesSolo-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.

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

PREGUNTAS & RESPUESTAS

CONTACTO

Sitio web:

http://venezuela.sqlpass.org/

Facebook:

https://www.facebook.com/sqlpassvzla

Twitter:

https://twitter.com/sqlpassve

Los Invitamos al

Muchas gracias por su participación

Estableciendo escenarios de Alta Disponibilidad en las empresas de hoy con MS SQL Server 2012

Technology

Transcript of Estableciendo escenarios de Alta Disponibilidad en las empresas de hoy con MS SQL Server 2012