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 🙂

Para más información sobre el failover https://msdn.microsoft.com/en-us/library/hh213151.aspx

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:

throughput sql 2016 AO

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.

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

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.

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:

 

Enrique Catalá

Microsoft Data Platform MVP & Mentor at SolidQ
I am Mentor and Microsoft Data Platform MVP at SolidQ. I am Microsoft Certified Trainer (MCT) andfocused in SQL Server motor relation, where i have successfully led more than 100 projects, not just in Spain, but also in EEUU,Mexico, Austria, etc.

I am the main architect of SolidQ Solutions called HealthCheck, SQL2Cloud, SCODA and SolidQ SSIS Generator. Appart from that, I am regular speaker of SolidQ Summit.
Enrique Catalá