La tecnología AlwaysON fue una de las grandes novedades de SQL Server 2012. Debido a su facilidad de implementación, robustez y seguridad se ha vuelto una de las tecnologías de alta disponibilidad más extendidas junto con Failover Cluster Instances, con la que además se complementa a la perfección.En este post detallamos todas las novedades que vienen con SQL Server 2016 en materia de AlwaysON:
Mejoras en failover
Hasta SQL Server 2016, el failover de un grupo de disponibilidad venia dado principalmente por el estado de salud de la instancia SQL Server que alojaba el grupo de disponibilidad primario. Esto queria decir que si por ejemplo un fallo HW de disco afectaba a una BBDD en grupo de disponibilidad, pero no le afectaba al funcionamiento de la instancia, no se lanzaba un failover del grupo de disponibilidad, forzándonos a tener que hacerlo manualmente…esto por fin ha sido subsanado 🙂
[box type=”info”] Para más información sobre el failover https://msdn.microsoft.com/en-us/library/hh213151.aspx [/box]Soporte para DTC
Hasta SQL Server 2016 no habia soporte para transacciones distribuidas en aquellas bbdd que pertenecieran a grupos de disponibilidad. Es más…abrir una mera transacción que afectase dos BBDD, aunque ambas estuvieran dentro del mismo grupo de disponibilidad generaba un error puesto que no estaba soportado.
Con SQL Server 2016 ya se pueden hacer este tipo de operaciones, lo cual ha eliminado de un plumazo algunos de los stoppers típicos de la propia tecnologia a la hora de tratar de implantarla en algunas organizaciones.
Incrementado el nº de replicas síncronas para failover automático
SQL Server 2015 ha incrementado el nº de replicas síncronas a las que poder hacer failover hasta 3, lo cual implica que en caso de catástrofe y failover automático, realmente podremos disponer de 3 sitios a los que balancear de forma segura, transparente y sin pérdida de datos. Recordemos que SQL Server 2014 tenia como mucho 2 replicas síncronas capaces de recibir failover automático y que SQL Server 2012 solo tenía 1.
Mejora en transporte de operaciones del log
En entornos de alto rendimiento, con alta carga transaccional y cabinas con raid SSD donde la E/S física no es un problema debido a gran inversion tecnologica, la propia latencia de commit debido a configuraciones síncronas de grupos de disponibilidad era el problema generalmente. En esta versión de SQL Server, microsoft se ha centrado en optimizar el canal de comunicación para configuraciones síncronas de AlwaysON y lo ha hecho mejorando tanto los algoritmos de compresión como la forma de utilizarlos:
- Algoritmos de compresión mejorados
- Compresión en paralelo de bloques de datos de log
- Minimizando los cambios de contexto en envios de datos de log
La siguiente tabla ilustra levemente las mejoras introducidas:
Como vemos, mejora enormemente la cantidad de operaciones por segundo enviadas a los nodos de la réplica “simplemente” porque se utiliza mejor el HW disponible.
[box type=”info”]Para más información: https://blogs.msdn.microsoft.com/psssql/2016/05/03/sql-2016-it-just-runs-faster-alwayson-parallel-compression-improved-algorithms/ [/box]Además, en SQL Server 2016 se ha conseguido una mejora de transporte de operaciones de log de 4x-5x comparada con SQL Server 2016 debido a optimizaciones en el diseño de cómo se envían y reciben los mensajes entre el nodo primario y las réplicas
[box type=”info”]Para más información: https://blogs.msdn.microsoft.com/psssql/2016/04/28/sql-2016-it-just-runs-faster-alwayson-log-transport-reduced-context-switches/[/box]Balanceo de carga en operaciones de lectura sobre replicas secundarias
Por fin! SQL Server 2016 ya tiene un mecanismo para balancear la carga de operaciones de lectura sobre las replicas secundarias mas allá del simple round-robin que tenia en SQL Server 2014 🙂
Soporte de cifrado por HW para el canal de comunicacion
Si se utiliza Windows Server 2012 R2 y se dispone de hardware AES-NI, el cifrado de comunicación para el canal TCP-IP utilizado para enviar la información entre los pares de nodos de AlwaysON se beneficiarán de esta tecnologia, lo cual asegura un aumento de rendimiento dependiente de la mejora aportada por el HW de cifrado.
[box type=”info”]Para más información: https://blogs.msdn.microsoft.com/psssql/2016/05/05/sql-2016-it-just-runs-faster-alwayson-aes-ni-encryption/[/box]Soporte completo para Operational analytics
Dado que en SQL Server 2016 podemos tener una tabla en forma de B-Tree y además ponerle índices columnares noclustered de lectura-escritura…el uso de replicas secundarias de lectura para operaciones analíticas que exploten dichos índices abre una puerta más que interesante para entornos con separaciones de roles bien definidos. Ya es posible por tanto, disponer de una réplica de lectura que explote a traves de índices columnares las consultas mas pesadas de agregaciones para nuestros informes, mientras que otra replica secundaria de solo lectura se haga cargo de filtros mas selectivos que no requieran de dichos índices columnares.
Soporte para AlwaysON en entornos no clusterizados
Con Windows Server 2016 se abre la puerta a la creación de clusters que no utilicen cuentas de dominio Active Directory. Esto abre la puerta indirectamente a la creación de entornos AlwaysON sin controlador de dominio, pero sí con certificados…cosa que bueno…está por ver si va a convertirse en algo habitual pero desde luego que ya abre la puerta en sitios donde no es posible crear clusters de forma facil (entornos multisite complejos, sin confiabilidad de dominios…)
¿Qué debemos hacer si migramos nuestro AlwaysON a SQL Server 2016?
A priori todas las mejoras son transparentes, a excepción de la de Readable Secondary Replicas y operational analytics:
- Para hacer uso de las nuevas opciones de balanceo de carga, deberemos configurar el enrutamiento( https://msdn.microsoft.com/en-us/library/ff878253.aspx )
- Para hacer uso de operational analytics, deberemos planificar nuestra estrategia de indexación teniendo presente el uso de nuestro sistema por parte de entornos de inteligencia de negocio (https://msdn.microsoft.com/en-us/library/dn817827.aspx )
