Cuando los servidores están inactivos, puede provocar interrupciones en sus objetivos comerciales y provocar una pérdida de ingresos. Por ejemplo, es posible que una aerolínea no pueda reservar vuelos para los clientes si las instancias y las bases de datos no están disponibles. Los sistemas pueden fallar por una variedad de razones, como incendios, errores humanos, fallas de la computadora, fallas del disco y errores de programación.
Para evitar interrupciones y garantizar la continuidad de los servicios comerciales, es extremadamente importante contar con estrategias de alta disponibilidad (HA) y recuperación ante desastres (DR). HA y DR a menudo se discuten juntos. HA se preocupa por reducir el tiempo de inactividad del servidor tanto como sea posible, pero debido a que ningún sistema es perfecto, DR se enfoca en el proceso de usar los medios de respaldo para recuperar datos perdidos en caso de que el sistema de la base de datos se caiga.
AlwaysOn es un término de marketing/marca utilizado desde SQL Server 2012 para describir las características mejoradas de HADR de Microsoft. Antes de AlwaysOn, el motor de la base de datos admitía otras soluciones propietarias integradas, como la creación de reflejo de la base de datos, el clúster de conmutación por error y el trasvase de registros. Sin embargo, cada una de esas técnicas vino con beneficios y limitaciones. A menudo, según sus objetivos, una organización tenía que combinar varios métodos para lograr una estrategia HADR deseable.
Las características de AlwaysOn se introdujeron para que no tenga que lidiar con tiempo y recursos adicionales para implementar e introducir complejidad en la implementación para tener en cuenta la redundancia del servidor y la base de datos, tener problemas con el escalado o tener hardware en espera que no se utiliza de manera eficiente. Estas características combinan convenientemente muchas de las prácticas antiguas y mejoran las áreas en las que se quedaron cortas. Para comprender realmente el valor de las ofertas de AlwaysOn, es importante revisar los conceptos básicos iniciales de cómo el motor de base de datos aseguró HADR del sistema en el pasado.
Duplicación de base de datos
La redundancia de la base de datos se puede lograr mediante la duplicación. Por ejemplo, puede tener una aplicación de cliente frontal que genere ingresos y que permita a los estudiantes solicitar libros de texto en línea. Un cliente selecciona su compra y las solicitudes se realizan en la base de datos de PsychologyBooks en el back-end. En caso de un desastre que haga que la base de datos de PsychologyBooks no esté disponible, el estudiante no podrá completar su pedido.
Para evitar esta interrupción, puede implementar una instancia principal en producción que contenga la base de datos de PsychologyBooks y tener una copia adicional de esa base de datos de PsychologyBooks en un servidor duplicado en espera. Las aplicaciones cliente pueden volver a conectarse a la copia reflejada en lugar de experimentar una interrupción y tener que esperar a que concluya la recuperación en la principal. La copia se mantiene al día con los cambios realizados en el original al recibir registros de transacciones y luego rehacer esos cambios registrados.
Las sesiones de duplicación pueden operar en diferentes modos según el rendimiento o las justificaciones de alta seguridad. Convenientemente, se admite la conmutación por error automática cuando la sesión de duplicación se opera en modo síncrono de alta seguridad y se establece un consenso de quórum con la presencia de un servidor testigo opcional.
A pesar de los beneficios de la duplicación, se queda corto porque solo proporciona redundancia de base de datos, no redundancia de servidor. Eso significa que si la instancia del servidor principal se cae, ambas instancias se caerán y no importará que haya una copia de repuesto de los datos en el nivel de la base de datos. El standby no admite operaciones de usuario y se necesitarían instantáneas para obtener una copia de solo lectura de los datos en la instancia reflejada. La base de datos está protegida, pero los objetos de nivel de servidor, como la pertenencia a la función del servidor, la información de inicio de sesión y los trabajos del agente, no lo están.
Por ejemplo, si hubiera un gran equipo de marketing y cada miembro tuviera su propio inicio de sesión, tendrían que volver a pasar por el proceso de volver a crear los inicios de sesión para cada persona. Cuando ocurre la conmutación por error, es en base a una base de datos independiente y no como un grupo.
Clústeres de conmutación por error
La agrupación en clústeres de conmutación por error ofrece redundancia a nivel de instancia y brinda protección contra fallas de hardware y sistema operativo. Por ejemplo, digamos que un nodo en Queen Anne se incendia y provoca una falla en el equipo. Toda la instancia, que incluye objetos a nivel de instancia, como inicios de sesión o trabajos específicos que se crearon para realizar tareas específicas, estará protegida y podrá reiniciarse automáticamente en otro nodo que pertenezca al clúster. Las aplicaciones y los servicios de los clientes seguirán estando disponibles para los clientes.
El escenario anterior funciona porque el almacenamiento se comparte entre servidores físicos redundantes en un grupo de clústeres de conmutación por error de Windows Server (WSFC). Tanto el sistema operativo como SQL Server funcionan juntos para que solo un nodo sea propietario del grupo de recursos WSFC a la vez.
Lamentablemente, con un almacenamiento común, esta solución no proporciona la redundancia de la base de datos que proporcionaba la estrategia de duplicación anterior. Tener un almacenamiento compartido presenta un riesgo porque da como resultado un único punto de falla. Por ejemplo, los discos externos pueden contener la única copia de la base de datos importante de PsychologyBooks y, a pesar de que la instancia se conmutó con éxito al nodo de Ballard, todavía habría una interrupción de los objetivos comerciales si el único componente de almacenamiento se viera comprometido. La agrupación en clústeres de conmutación por error también propone restricciones en términos de escalabilidad porque las aplicaciones cliente no pueden manejar una cantidad creciente de trabajo que se expande más allá del clúster.
Envío de registros
Otro método para lograr la redundancia de la base de datos es mediante el envío de registros. Los registros de transacciones se respaldan en el servidor principal y se envían a uno o varios servidores secundarios para su restauración. A diferencia de la duplicación, las bases de datos secundarias pueden ser elegibles para actividad de solo lectura y la frecuencia de envío de registros se puede configurar para diferentes intervalos. Hay una ventaja de rendimiento en escenarios en los que las bases de datos secundarias no necesariamente tienen que estar sincronizadas con la base de datos principal en tiempo real.
Por ejemplo, ejecutar un informe de resumen estadístico al final de la noche para ver qué libros de psicología se venden durante el día no requiere que la base de datos de copia esté exactamente sincronizada con la base de datos principal. La actividad de lectura intensiva coloca bloqueos en los objetos de la base de datos y puede aumentar los tiempos de espera. Por lo tanto, ejecutar informes en un servidor secundario aliviaría la demanda de carga de trabajo en el servidor principal que genera ingresos.
El inconveniente es que el trasvase de registros no admite la conmutación por error automática. Por lo tanto, si el servidor de origen falla, la base de datos debe recuperarse manualmente. Al igual que la duplicación, el trasvase de registros no proporciona redundancia de servidor y es una solución a nivel de base de datos.
Comprensión de AlwaysOn
Las tecnologías antiguas tienen sus ventajas y desventajas. Pero la implementación de una solución HADR personalizada puede volverse complicada rápidamente y requerir más administración, ya que estas diferentes estrategias se mezclan y combinan arbitrariamente para satisfacer las necesidades comerciales. Por lo tanto, se introdujeron las características de AlwaysOn y proporcionan una versión mejorada y ya combinada de estrategias anteriores.
SQL Server ofrece dos funciones:Grupos de disponibilidad AlwaysOn (AG) e Instancias de clúster de conmutación por error (FCI) AlwaysOn. Ambos requieren la implementación de Windows Server Failover Clustering (WSFC).
Un AG es un grupo de bases de datos que se conmutarán por error juntas. Necesitará varios nodos físicos redundantes con una instancia de SQL Server instalada en cada uno de los nodos para hospedar las réplicas de disponibilidad. Cada réplica debe estar en un nodo diferente del mismo WSFC. En el esquema anterior, la réplica principal está alojada en el nodo 01 y todas las demás réplicas secundarias son aptas para la conmutación por error cuando WSFC detecta que hay un problema.
La forma en que las réplicas secundarias se mantienen sincronizadas con la principal es enviando registros de transacciones y rehaciendo los cambios. AG admite el modo de confirmación tanto asíncrono como síncrono. La réplica principal es elegible para lectura y escritura, mientras que las réplicas secundarias son elegibles para solo lectura. Las copias de seguridad se pueden realizar en la ubicación secundaria.
Inmediatamente, hay beneficios con AlwaysOn AG. Recuerde de lo anterior que algunos de los defectos de la creación de reflejo de la base de datos son que una base de datos solo se puede reflejar en un servidor secundario y que cuando se produce una conmutación por error, cada base de datos se refleja de forma independiente. Con AG, las bases de datos se vuelven redundantes en muchos lugares, como el Nodo 02, el Nodo 03, el Nodo 04 y el Nodo 05 en el ejemplo anterior. La compatibilidad con la disponibilidad de la base de datos permite hasta nueve réplicas de disponibilidad.
Además, el envío de registros sería necesario para lograr datos de solo lectura en el servidor secundario. Pero con AG, los datos de solo lectura ya se tienen en cuenta. Las actividades de lectura intensiva, como los informes, se pueden realizar en cualquiera de las réplicas secundarias. También tenga en cuenta que no hay una restricción de almacenamiento compartido.
Sin embargo, AG se puede combinar con AlwaysOn FCI para permitir la redundancia del servidor. Se puede usar una instancia de FCI para hospedar las réplicas de disponibilidad, de modo que los objetos de nivel de servidor, como los inicios de sesión y los trabajos de los agentes, también se puedan proteger. Este enfoque requerirá almacenamiento compartido. Sin embargo, se eliminarán inconvenientes como tener que realizar reconfiguraciones para las aplicaciones del cliente.
