Ante la preocupación de que existen fallos “demasiado frecuentes en Azure” podríamos montar grupo de disponibilidad de 2 réplicas, estilo activo-pasivo, sobre cluster geográfico entre 2 CPDs de Azure (por ejemplo uno en USA y otro en Europa). Habría que configurar una red VNET a VNET entre los dos CPD y luego configurar una aplicación que, usando las cadenas de conexión de mirroring, apunte a los dos nodos directamente (sin listener de grupos de disponibilidad, ya que no soportaría la caída del CPD al ser solo 1 IP).



  1. 1. #SQSummit 26, 27 y 28 de Mayo Rubén Garrigós rgarrigos@solidq.com Mentor Alta Disponibilidad ante fallos de CPD en Azure
  2. 2. #SQSummit Agenda 1. Introducción 2. Conceptos 3. Implementación infraestructura 4. Conectividad desde clientes 5. Escenarios de DR
  3. 3. #SQSummit Los CPD Azure aplican buenas prácticas ante un desastre • Almacenamiento geo-replicado • Conectividad redundante • Actualizaciones de software por región • Incidencias “reconocidas” en Azure de los últimos tres meses • Total = 169 • globales =13 (<8%) • globales excluyendo Application Insights”= 8 (<5%) Introducción
  4. 4. #SQSummit Los CPD Azure ante un desastre • Secundarios fijos y estáticos • Incidencia local vs incidencia global • Incidencia local parcial vs local total • Fallos de conectividad Introducción
  5. 5. #SQSummit Storage geo-replicado GRS y SQL Server • No garantiza consistencia entre discos • Limitaciones importantes • No separar datos y log en distintos discos • No utilizar storage spaces/software raid • No utilizar Azure Blobs para ficheros de datos • No válido con Premium Storage • RTO de horas o incluso días • RPO no garantizado, ~15 minutos Conceptos
  6. 6. #SQSummit Conectividad redundante • Fibras independientes en la entrada • No circuitos punto a punto • Refrescos de DNS y enrutados • Impacto en latencias • Ancho banda disponible Conceptos
  7. 7. #SQSummit Desde Alicante a… países bajos • 1833 vs 1852 km • 42 kms entre ambos Ancho de banda
  8. 8. #SQSummit Existe una “pequeña” diferencia en el ancho de banda de bajada Situaciones similares pueden ocurrirnos también en la latencia por congestión, mayor número de saltos, etc. Ancho de banda
  9. 9. #SQSummit Nuestra solución para SQL Server debe ser independiente del DR a nivel de datacenter • Basada en availability groups/db mirroring • Elegir los CPD (incluso fuera de Azure…) • Tests de failover entre CPD periódicos • Mantener el control de un escenario de DR dentro del negocio Implementación de infraestructura
  10. 10. #SQSummit • http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-60-33/4213.3.png Implementación infraestructura Traffic Manager
  11. 11. #SQSummit Implementación de infraestructura VNET-VNET VPN • Sin conflictos de rangos de direcciones Región VNET Rango IPs LocalNet Europa Summit2015 172.16.0.0/26 Summit2015DR USA Summit2015DR 172.17.0.0/26 Summit2015 Región LocalNet Rango IPs GW a configurar Europa Summit2015 172.16.0.0/26 GW VNET Summit2015 USA Summit2015DR 172.17.0.0/26 GW VNET Summit2015DR
  12. 12. #SQSummit Implementación de infraestructura VNET-VNET VPN • Configurar IPSEC después de crear los GW Set-AzureVNetGatewayKey -VNetName «Summit2015» -LocalNetworksiteName «Summit2015DR» -sharedKey YdjSnGatFyNeDBZESfsITKgWdPw4iGcI Set-AzureVNetGatewayKey -VNetName «Summit2015DR» -LocalNetworksiteName «Summit2015» -sharedKey YdjSnGatFyNeDBZESfsITKgWdPw4iGcI
  13. 13. #SQSummit DEMO VNET-VNET para DR con Availability groups
  14. 14. #SQSummit No es posible configurar un listener “global” • Lo ideal es que el driver nos redireccione al sitio principal o al secundario • Usar el partner de database mirroring • La aplicación dispone de doble cadena de conexión • Más control del paso a DR • Política de reintentos en acceso a datos Conectividad desde clientes
  15. 15. #SQSummit DEMO Utilizar el partner de la conexión para DR
  16. 16. #SQSummit Balanceo con Traffic manager • Failover (primer endpoint online) • Round robin (entre los online) • Performance (más cercano entre los online) Azure site recovery (ASR) • Orquestar escenarios de DR • Enfocado a on-premise to cloud Azure Automation • Tareas específicas de nuestro entorno Escenarios de DR en Azure
  17. 17. #SQSummit ASR + Traffic Manager
  18. 18. #SQSummit CPDs activo-activo vs activo-pasivo • Si los dos están en Azure/Cloud • Si uno es on-premise y el otro Cloud Activo-activo • Escalado automático/manual Activo-pasivo • Intercambio de roles Escenarios de DR
  19. 19. #SQSummit Menores RPO y RTO en caso de DR • Mayor dependencia de la tecnología • Automatismos vs DR manuales Más escalabilidad vs planificación crecimientos • Crecimiento futuro • Acciones comerciales puntuales Integración con la nube • Escenarios híbridos son ya bastante habituales Retos tecnológicos
  20. 20. #SQSummit Un entorno de DR es cada vez más necesario Azure tiene RTO/RPOs elevados para DR Availability groups es una pieza importante • No es la única alternativa • Analizar en cada caso las necesidades Un entorno DR confiable puede marcar la diferencia entre quebrar y no hacerlo Conclusiones
  21. 21. #SQSummit ¡Gracias! ¿Te has quedado con alguna duda? Consúltanos. SolidQ Flex Services es un servicio que asegura al cliente la estabilidad de sus sistemas SQL Server, desde una solución sencilla de monitorización hasta un servicio 100% 24/7 subcontratado. Combina todos los servicios y expertise de SolidQ añadiendo valor a los entornos SQL Server del cliente. www.solidqflexservices.com