Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Lecciones aprendidas SQL Server AlwaryOn

presentación sobre métodos de recuperación de desastres en SQL Sever y algunas arquitecturas implementadas con Always On

  • Be the first to comment

  • Be the first to like this

Lecciones aprendidas SQL Server AlwaryOn

  1. 1. AlwaysOn Lecciones Aprendidas 16 de Marzo 2016 (12 pm GMT -5) Julian Castiblanco Resumen: Compartir con la audiencia algunas de mis lecciones aprendidas en la implementación de AlwaysOn Está por comenzar: Moderador: Kenneth Ureña Próximos Eventos Introducción a Polybase en SQL Server 2016 23 de Marzo Eladio Rincón Real-time Operational Analytic en SQL Server 2016 30 de Marzo Jose Luis Rivera Examinando una consulta problematica con XEvents y DMVs 06 de Abril Warner Chaves
  2. 2. Manténgase conectado a nosotros! Visítenos en http://globalspanish.sqlpass.org /SpanishPASSVC lnkd.in/dtYBzev /user/SpanishPASSVC /SpanishPASSVC
  3. 3. 3
  4. 4. 4 Oportunidades de Voluntariado PASS no pudiera existir sin personas apasionadas y dedicadas de todas partes del mundo que dan de su tiempo como voluntarios. Se un voluntario ahora!! Para identificar oportunidades locales visita volunteer.sqlpass.org Recuerda actualizar tu perfil en las secciones de “MyVolunteering” y MyPASS para mas detalles.
  5. 5. Sigan Participando! • Obtén tu membresía gratuita en sqlpass.org • Linked In: http://www.sqlpass.org/linkedin • Facebook: http://www.sqlpass.org/facebook • Twitter: @SQLPASS • PASS: http://www.sqlpass.org
  6. 6. AlwaysOn Lecciones Aprendidas 16 de Marzo de 2016 Julián Castiblanco MCSE SQL Server Data Platform Microsoft Data Platform MVP Moderador: Kenneth Ureña
  7. 7. Agenda • Conceptos básicos • AlwaysOn • Consideraciones 7
  8. 8. Conceptos Básicos http://amzn.to/1ValtU7 http://bit.ly/1M5VFqg Alta Disponibilidad
  9. 9. Conceptos Básicos http://bit.ly/1RkUpvr http://bit.ly/1UenpeM http://bit.ly/1UenMWz Recuperación de Desastres
  10. 10. Conceptos Básicos RTO y RPO Punto de Recuperación Objetivo: Es el punto del tiempo en el cual la data puede restaurarse después del fallo, o en otros términos la cantidad de datos que pueden perderse. Ejemplo, perdí las factura de la última hora de trabajo y debo reingresarlas al sistema. Tiempo de Recuperación Objetivo: Es el tiempo que toma volver a dejar operacional un sistema, después de un fallo planeado o improvisto. En otras palabras la cantidad de tiempo que la compañía puede permanecerá sin tener operable el sistema
  11. 11. Conceptos Básicos http://bit.ly/1R0bThg
  12. 12. Conceptos Básicos http://bit.ly/1Rk3vPc FULL Estrategias de Alta Disponibilidad y Recuperación de Desastres FULL DIFF LOG LOG LOG LOG Estrategia de generación de copias de seguridad programadas, con periodicidad semanal, diaria y horaria. PROS • Permite ajustar el PRO (punto de recuperación objetivo) • Relativamente fácil de implementar. • Económico en términos de licenciamiento. CONTRAS • El tiempo de Recuperación puede ser muy alto. • Es una estratégia de RD más que de AD, por lo cual si se daña el servidor no es mucho lo que se pueda hacer. • Requiere tener un buen espacio de almacenamiento para mantener las copias en VLDB’s
  13. 13. Conceptos Básicos http://bit.ly/1Vb4elz Estrategias de Alta Disponibilidad y Recuperación de Desastres DB db db Estrategia de “log Shipping”, una base principal genera copias, las mueve a los demás servidores y los restaura en estos automáticamente a través de SQL Agent Service. PROS • Permite ajustar el PRO (punto de recuperación objetivo) • Relativamente fácil de implementar. • Permite lecturas en las copias secundarias, si la base está en stand by. CONTRAS • El tiempo de Recuperación puede ser muy alto. • Requiere modificar la aplicación para re direccionar la base de datos. • En tarea de mantenimiento de índices o de datos, pueden llegar a encolarse las copias pendientes por restaurar. Primary DB copia copia
  14. 14. Conceptos Básicos http://bit.ly/1Vb4elz Estrategias de Alta Disponibilidad y Recuperación de Desastres Estrategia de “log Shipping”, con monitor. Un server se encarga de validar que tanto el primario, como los secundarios no sufran contratiempos en la actualización de información y emite alertas en caso de presentarse algo anormal.
  15. 15. Conceptos Básicos http://bit.ly/1YYk4Qw Estrategias de Alta Disponibilidad y Recuperación de Desastres DB db db Estrategia de “Replicación”, se tiene una base de distribución la cual se encarga de proveer las transacciones que van registrándose en la base publicadora. PROS • Permite lecturas en las bases secundarias. • Aumenta el costo de licenciamiento. • Permite filtrar los objetos que serán replicados. • Puede personalizar grupos de índices en las diferentes replicas (@Kenneth) CONTRAS • Requiere modificar la aplicación para re direccionar la base de datos. OTROS • Existe más de un tipo de replicación, pero el más utilizado para alta disponibilidad es la replicación transaccional. Primary DB Publicador SuscriptorSuscriptor Distribuidor DB
  16. 16. Conceptos Básicos http://bit.ly/1pKtqn4 Estrategias de Alta Disponibilidad y Recuperación de Desastres Estrategia de “Database mirroring” realiza una copia de log transaccional entre una base primaria y una espejo. El testigo permite validar que la sincronización de las bases está funcionando correctamente. PROS • Permite sincronización en tiempo real o cerca del tiempo real. • La aplicación puede redireccionar hacia el nuevo servidor de db automáticamente. CONTRAS • Cuando requiere más de una base las consultas debe asegurarse que todas estén replicando. • Tecnología que va de salida.
  17. 17. AlwaysOn http://bit.ly/1UeY3gV FCI Estrategia de “AlwaysOn Failover Cluster Instance”. Es una de las estrategias de alta disponibilidad más utilizadas. A diferencia con versiones anteriores del producto desde SS2012 es posible tener la tempdb de manera local en cada nodo, políticas de fallo flexible y multisite clustering. DB NODO 1 Datacenter BOG NODO 2 Datacenter BOG DB NODO 1 Datacenter BOG NODO 2 Datacenter MED DB REPLICACION A NIVEL DE ALMACENAMIENTO (SAN)
  18. 18. AlwaysOn FCI isAlive: ejecuta Select @@servername LooksAlive: valida que el servicio esté en ejecución No valida la salud de una base en particular.
  19. 19. AlwaysOn ALWAYSON AVAILABILITY GROUPS FAILOVER CLUSTER INSTANCE WINDOWS SERVER FAILOVER CLUSTERING (WSFC) Database Mirroring, no puede garantizar que ambas bases estén de primarias en el mismo servidor
  20. 20. AlwaysOn ALWAYSON AVAILABILITY GROUPS FAILOVER CLUSTER INSTANCE WINDOWS SERVER FAILOVER CLUSTERING (WSFC) Un grupo de disponibilidad garantiza que todas las bases relacionadas siempre estén en el mismo nodo. Grupos de disponibilidad
  21. 21. 21 AlwaysOn Grupos de disponibilidad SQL Server 2016 hasta 3 nodos con automatic failover, hasta 8 réplicas incluyendo réplicas hacia nodos en Azure
  22. 22. 22 AlwaysOn Grupos de disponibilidad
  23. 23. AlwaysOn Arquitecturas viables Primary Data Center Disaster Recovery Data Center SQL Server Primary SQL Server Secondary Windows Server Failover Cluster (single WSFC crossing two data centers) Availability Group SQL Server Secondary Synchronous Asynchronous Additional Server for Node Majority Quorum Model
  24. 24. AlwaysOn Arquitecturas viables Primary Data Center Disaster Recovery Data Center SQL Server Primary SQL Server Secondary Windows Server Failover Cluster (single WSFC crossing two data centers) Availability Group SQL Server Secondary Synchronous Asynchronous File Share
  25. 25. AlwaysOn Arquitecturas viables http://msdn.microsoft.com/library/hh923056.aspx
  26. 26. AlwaysOn Data Center Principal SQLDCPO4 Repl Syn Auto /SAN 2 SQLDCPO3 Primary Repl. SAN 1 SRDCP 01/02 SQLDCP Repl. Syn/ SAN 1 Data Center Recuperación De desastres SRVDCR 01/02 SQLDCR Repl. Asyn / SAN 3 WSFC CLUPRINCIPAL Granja Servidores De Aplicación WEB SUCURSALES SQLAG1: DBNEGOCIO1, DBNEGOCIO2 SQLAG2: DBMONITOREO, DBRRHH…. Clientes Internos Equipo de DBA’s Consideraciones Adicionales – Manejo de múltiples FCI dentro de un mismo AG
  27. 27. AlwaysOn Consideraciones Adicionales – Implementación sobre Azure Resource Manager Virtual Network - iHA Microsoft Azure - Suscripción Clientes WebAPP01-A4 Balanceador APP Controlador de dominio Availability Set - APP Resource group - HA Storage Standard-LRS Balanceador Listener AG Availability Set -Base de datos DB02-DS12 DB1 DB2 DB2 DB1 DB01-DS12 AlwaysOn Availability Group User
  28. 28. 28 AlwaysOn Consideraciones Adicionales – Manejo de multiples FCI dentro de un mismo AG En los Roles del WSFC debe configurarse solo los nodos que corresponden a cada FCI
  29. 29. 29 AlwaysOn Consideraciones Adicionales – Manejo de multiples FCI dentro de un mismo AG Debe modificarse el dueño de los discos para que solo sean accedidos por los nodos de cada FCI o de cada nodo stand alone según sea el caso.
  30. 30. 30 AlwaysOn Consideraciones Adicionales – Manejo de los Jobs de base de datos Muchas bases de negocio tienen implementados procesos de batch y/o depuración a través de Jobs, con AG esto se torna complicado porque todas las instancias están iniciadas pero solo una tiene la base de producción activa.
  31. 31. 31 AlwaysOn Consideraciones Adicionales – Manejo de los Jobs de base de datos
  32. 32. 32 AlwaysOn Consideraciones Adicionales – Creación de SQL Server AlwaysOn en Azure http://bit.ly/1S46ic8
  33. 33. 33 AlwaysOn Consideraciones Adicionales – Creación Balanceador para el Listener en Azure RM # Provide the IP address for the Listener or Load Balancer $ILBIP = '10.0.0.102' $vnet = Get-AzureRMVirtualNetwork -ResourceGroupName $ResourceGroupName|Get-AzureRMVirtualNetworkSubnetConfig –name $subnetname $FEConfig = New-AzureRMLoadBalancerFrontendIpConfig -Name $FrontEndConfigurationName -PrivateIpAddress $ILBIP -SubnetId $vnet.Id $BackendConfig = New-AzureRMLoadBalancerBackendAddressPoolConfig -Name $BackendConfiguratioName #create the ILB New-AzureRMLoadBalancer -Name $LoadBalancerName -ResourceGroupName $ResourceGroupName -Location $Location -FrontendIpConfiguration $FEConfig - BackendAddressPool $BackendConfig $healthProbe = New-AzureRmLoadBalancerProbeConfig -Name "Probe" -Protocol tcp -Port 1433 -IntervalInSeconds 5 -ProbeCount 2
  34. 34. 34 AlwaysOn Nuevo en 2016 SQL Server 2016 agrega un balanceador de cargar round-robin, para agregar uno o más grupos de lectura al balanceo
  35. 35. Referencias y Recomendaciones • http://www.amazon.com/Server-2012-Alwayson-Joes-Pros/dp/1939666236 • http://download.microsoft.com/download/D/2/0/D20E1C5F-72EA-4505-9F26- FEF9550EFD44/Building%20a%20High%20Availability%20and%20Disaster%20Recovery%20S olution%20using%20AlwaysOn%20Availability%20Groups.docx • http://download.microsoft.com/download/d/2/0/d20e1c5f-72ea-4505-9f26- fef9550efd44/microsoft%20sql%20server%20alwayson%20solutions%20guide%20for%20hig h%20availability%20and%20disaster%20recovery.docx • https://www.youtube.com/watch?v=ed-h7JhEwUo canal de Eduardo Castro • https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-sql-server- alwayson-availability-groups-gui-arm/ AG en Azure RM • http://msdn.microsoft.com/library/hh923056.aspx AG con 2 FCI 35
  36. 36. Introducción a Polybase en SQL Server 2016 23 de Marzo (12 pm GMT -5) Eladio Rincón Resumen: SQL Server 2016 da la posibilidad de gestionar datos no estructurados desde el motor relacional. En esta sesión verá cómo utilizar dicha integración para gestionar desde un motor relacional (SQL Server) datos no estructurados. Próximo Evento

×