Estableciendo escenarios de Alta Disponibilidad en las empresas de hoy con MS SQL Server 2012
Descargar como PPTX, PDF•3 recomendaciones•2,951 vistas
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.
![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]}) )](https://image.slidesharecdn.com/estableciendoescenariosdealtadisponibilidadenlasempresasdehoyconmssqlserver2012-131110201705-phpapp02/85/Estableciendo-escenarios-de-Alta-Disponibilidad-en-las-empresas-de-hoy-con-MS-SQL-Server-2012-35-320.jpg)
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 [email protected] http://redondoj.wordpress.com
- 2. AGENDA • Introducción • Conceptos • Arquitectura • Failover del Cliente • AlwaysOn Servidores Secundarios • Conclusiones
- 3. Alta Disponibilidad con MS SQL Server 2012
- 4. INTRODUCCIÓN
- 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
- 6. INTRODUCCIÓN Configuraciones: • Windows Server 2012 Failover Cluster • • • • • Hyper-V Failover Clustering File and Storage Services Network Adapter Teaming Hyper-V Virtual Switch
- 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
- 11. CONCEPTOS
- 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
- 13. Windows Server 2012 Failover Cluster
- 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
- 22. ARQUITECTURA
- 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.
- 33. AlwaysOn Servidores Secundarios • Copias en la replica • Conectividad de clientes Solo-Lectura
- 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.
- 37. DEMO
- 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
- 41. Los Invitamos al
- 42. Muchas gracias por su participación
Notas del editor
- #14: INFRAESTRUCTURA DE LA NUBE PRIVADA1.- System Center: Admin nube privada2.- Hyper V: Plataforma de nube privada3.- WS Failover Clustering: Infraestructura Privada
- #26: 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.