carloscastilla - Fotolia
¿Qué hay de nuevo en los grupos de disponibilidad AlwaysOn de SQL Server 2016?
Microsoft ha añadido soporte coordinador de transacciones distribuidas, registros log de transporte optimizado y otras características a los grupos de disponibilidad AlwaysOn en SQL Server 2016.
Los grupos de disponibilidad AlwaysOn de SQL Server se introdujeron por primera vez en 2012 y continúan recibiendo mejoras a medida que se libera cada nueva versión de la base de datos. Para SQL Server 2016, Microsoft se centró en abordar los puntos débiles del cliente con la característica de alta disponibilidad y recuperación de desastres, en lugar de añadir nuevas funcionalidades.
He aquí un vistazo a las próximas mejoras a los grupos de disponibilidad AlwaysOn (AGS) de SQL Server, con base en la versión CTP 2.2 de SQL Server 2016 y otros materiales disponibles.
Conmutación por error en la salud de la base de datos: A pesar de que el foco de la conmutación por error de AG ha sido proporcionar redundancia a nivel de base de datos, o en un grupo de bases de datos relacionadas, la conmutación por error real ha sido provocada por la salud de la instancia de SQL Server en su conjunto. Por ejemplo, una base de datos en un grupo de disponibilidad podría estar fuera de línea, tal vez debido a un fallo en el disco, y el resto de la instancia está en marcha y funcionamiento. Con SQL Server 2014 y las implementaciones anteriores, la conmutación por error no se detonaría debido a que el estado general de salud de la instancia sigue siendo buena. En SQL Server 2016, todas las bases de datos dentro de la AG afectadas tendrían conmutación por error.
Este comportamiento es opcional. De manera predeterminada, no va a estar habilitado; el administrador de base de datos tendrá que habilitar la directiva con el fin de tener conmutación por error cada vez que una base de datos se vuelve poco saludable.
Soporte Coordinador de Transacciones Distribuidas: Una de las mejoras más solicitadas para los grupos de disponibilidad AlwaysOn de SQL Server era soportar el Coordinador de Transacciones Distribuidas (DTC) para gestionar las transacciones a través de múltiples bases de datos e instancias. El DTC no se admite en los grupos de disponibilidad en SQL Server 2014 y versiones anteriores, pero algunos clientes han decidido implementarlo en SQL Server 2014 a pesar de que existe la posibilidad de pérdida de datos.
Ya que el DTC es parte del sistema operativo Windows, Microsoft hizo modificaciones a Windows Server 2016 y a la API para que SQL Server 2016 pueda soportarlo plenamente. Por lo tanto, la instancia de SQL Server 2016 debe residir en un sistema operativo Windows Server 2016 con el fin de soportar el DTC. Esto también será compatible con Windows Server 2012 Release 2 después de instalar el parche KB3090973. En lo personal, me he encontrado con varios clientes que querían los beneficios de la tecnología AG, pero no podían avanzar debido a la falta de apoyo a la funcionalidad DTC.
Las réplicas síncronas: Hay dos tipos de réplicas secundarias dentro de una AG –síncronas y asíncronas. Con la replicación síncrona, la primera transacción debe ser registrada en el log de la réplica antes de que pueda enviar un acuse de recibo a la réplica principal. Con el fin de que una réplica secundaria sea un objetivo automático de conmutación por error, debe ser una réplica síncrona. En SQL Server 2014, puede haber tres réplicas síncronas, pero sólo dos de ellas pueden ser designadas como objetivos automáticos de conmutación por error. Esto significa que esas dos réplicas síncronas serían el principal destino de sustitución uno para el otro. En SQL Server 2016, las tres réplicas síncronas ahora pueden ser designadas como blancos de conmutación por error. Como resultado, si un problema se produjo durante o incluso después de una conmutación por error, la tercera réplica síncrona podría también participar como destino de sustitución.
Transporte optimizado de logs: Algunos clientes han implementado los AG en un ambiente de alto volumen, altamente transaccional con discos de estado sólido. En estos entornos, a veces ha sido un desafío para la comunicación sincrónica de los datos de registro entre réplicas mantenerse al día con el hardware de alta velocidad. Esto puede ser problemático en este tipo de medio ambiente conforme avanza el tiempo, y la latencia del proceso síncrono en compromiso puede comenzar a afectar al rendimiento de la primaria.
Microsoft ha trabajado para simplificar la tubería entre las réplicas síncronas para obtener un mejor rendimiento de los datos de registro cuando se utilizan los grupos de disponibilidad AlwaysOn de SQL Server. Pero, si la entrega es más rápida, habrá mucho más actividad de "reconstrucción" para ser procesada cuando se repliquen los registros log para fines de recuperación de bases de datos. Por lo tanto, Microsoft también está trabajando en habilitar la operación “redo” (hacer de nuevo) para que sea paralela con el fin de mantenerse al día. En lugar de una meta de porcentaje de mejora sobre el rendimiento en SQL Server 2014 contra SQL Server 2016, el objetivo es ser lo más cercano posible a una instancia independiente no-AG en términos de rendimiento.
Equilibrio de carga entre las réplicas secundarias legibles: En SQL Server 2014, utilizando el mecanismo de escucha de grupos de disponibilidad para descargar lecturas a las réplicas secundarias se soporta a través de la lista de sólo lectura de enrutamiento. Pero la primera réplica de la lista recibe la mayor actividad, ya que es la que siempre se intenta en primer lugar.
En SQL Server 2016, la lista de réplicas secundarias legibles ofrece información de conexión en una base de operación por turnos. Además, cada réplica tiene su propia lista de sólo lectura de enrutamiento de manera que el balanceo de sólo lectura a través de la escucha del grupo de disponibilidad podría enrutar el tráfico a las réplicas secundarias que pueden ser más "locales" que la réplica principal actual.
Grupo de Cuentas de Servicio Administradas: Un grupo de Cuentas de Servicio Administradas (gMSA) es un tipo de cuenta de seguridad lanzado en Windows Server 2012 que puede aprovechar plenamente SQL Server 2016 –especialmente con los AG. La cuenta de grupo proporciona capacidades de seguridad similares a las de una cuenta de servicio administrado localmente en un servidor individual, pero tiene un alcance de dominio. Cuando una instancia de SQL Server se instala con la configuración predeterminada, una cuenta de servicio local se utiliza para gestionar las contraseñas para las aplicaciones y servicios de procesamiento. Si la instancia es parte de una AG, configurar y mantener los permisos para acceder a recursos comunes, tales como recursos compartidos de archivos a menudo es más complejo conforme las disposiciones de seguridad necesitan ser establecidas para la cuenta de servicio de cada instancia dentro de la AG. Una gMSA aborda esta cuestión. Además, algunas organizaciones utilizan una cuenta de usuario de dominio regular para administrar las contraseñas de servicios –una práctica que podría ser marcada en una auditoría de seguridad, tal como si alguien que carece de autorización podría conectarse con esas credenciales. Al usar una gMSA se impide ello y también gestiona automáticamente la sincronización de contraseñas en todos los nodos.
AGs AlwaysOn frente a un almacén de datos
La separación de la carga de trabajo es otra faceta de la gestión de bases de datos en la que la combinación de SQL Server 2016 y los grupos de disponibilidad AlwaysOn pueden beneficiar a los usuarios. En un escenario tradicional, una organización ejecuta un sistema transaccional integrado para un rendimiento rápido de procesamiento de datos de misión crítica. Estos se refieren a menudo como sistemas operacionales, ya que principalmente apoyan las operaciones de la organización. En algún punto de la línea, estos datos se transforman y se cargan en otro tipo de sistema que funciona como un almacén de datos, que está diseñado para apoyar el análisis de datos. No es de extrañar que a menudo estos se denominen sistemas analíticos. Tradicionalmente, la colocación de una carga de trabajo de almacenamiento de datos en la parte superior de un sistema operativo condujo a un rendimiento deficiente en todos los ámbitos.
Hay un cambio que se avecina. Anteriormente había restricciones sobre el número y tipo de fila y columna para almacenar índices de una tabla. Con SQL Server 2016, una tabla con un índice tradicional de la línea B-Tree también puede tener un índice de almacén de columnas agrupadas, lo cual no era el caso en las versiones anteriores. Esa capacidad se traduce en las mismas estructuras de datos capaces de soportar eficientemente las cargas de trabajo tanto operativas como analíticas, o análisis operacionales. La nueva configuración no es la panacea, ya que todavía hay cuestiones a tratar, pero permite otra posibilidad para las empresas que buscan gestionar mejor sus datos y obtener el máximo provecho de ella.
Aunque esto no es realmente una mejora a los grupos de disponibilidad AlwaysOn de SQL Server, juegan un papel importante en permitir los análisis operacionales. La separación de las cargas de trabajo todavía se prefiere, aunque las estructuras de datos subyacentes soportan ambos tipos. Mediante el uso de los AG, una carga de trabajo de almacenamiento de datos se puede descargar a una sola réplica secundaria legible –o incluso a través de múltiples réplicas secundarias legibles– dejando a los recursos en la réplica principal para apoyar de manera eficiente los procesos de negocio de misión crítica. Otro beneficio adicional es que hay muy baja latencia en los datos que alimentan el almacén de datos, de modo que los análisis en tiempo real son una realidad.
En general, no hay un nuevo elemento llamativo para destacar entre las adiciones a los AG en SQL Server 2016. Pero las mejoras previstas proporcionan un valor real en términos de disponibilidad, compatibilidad, escalabilidad y capacidad de gestión. Estos son los tipos de mejoras que abordan las cuestiones de aplicación en el mundo real descubiertas en las aplicaciones de producción.
Sobre el autor: Rick Heiges es arquitecto principal de soluciones MVP y SQL Server en DB Best Technologies LLC. Trabaja con los clientes, educándolos acerca de la Plataforma de Datos de Microsoft para resolver problemas de negocio y maximizar el valor de sus datos. Rick está muy involucrado en la comunidad de SQL Server a través de PASS, donde pasó nueve años en el consejo de administración.
