[Fuente] Alta Disponibilidad en SQL Server (1) ---- una visión general de la alta disponibilidad

Desde SQL Server 2005, Microsoft ha proporcionado una variedad de tecnologías de alta disponibilidad para reducir los tiempos de inactividad y aumentar la protección de los datos empresariales, y con el lanzamiento continuo de SQL Server 2008, SQL Server 2008 R2 y SQL Server 2012, existen muchas tecnologías de alta disponibilidad en SQL Server para adaptarse a diferentes escenarios.

    Antes de comenzar este artículo, empezaré con un breve resumen de lo que determina qué tecnología de alta disponibilidad utilizar.

    Muchas empresas necesitan que todos o parte de sus datos estén altamente disponibles, como las páginas web de compras online, las bases de datos de productos en línea deben estar online las 24 horas del día, los 7 días de la semana; de lo contrario, en un entorno de mercado altamente competitivo, el tiempo de inactividad significa pérdida de clientes e ingresos. Por ejemplo, en un centro de llamadas que depende de SQL Server, si la base de datos cae, todos los llamantes solo pueden quedarse sentados y responder al cliente "Lo siento, fallo del sistema", lo cual también es inaceptable.

    Por supuesto, en un mundo ideal, todos los datos críticos estarían en línea en todo momento, pero en la vida real habría varias razones por las que la base de datos no estaría disponible, ya que es imposible predecir el momento y la forma del desastre, por lo que es necesario tomar medidas previas para prevenir diversas emergencias, por lo que SQL Server ofrece una variedad de tecnologías de alta disponibilidad, que incluyen principalmente: clustering, replicación, espejamiento, entrega de registros, grupos de disponibilidad AlwaysOn y otras como copia de seguridad y restauración de grupos de archivos, Tecnologías de alta disponibilidad de instancia única, como índices de reconstrucción en línea. El uso de tecnología de alta disponibilidad no es elegir una tecnología familiar para su uso directo, sino considerar el negocio y la tecnología de forma integral. Porque no existe una única tecnología que pueda cumplir todas las funciones. Cómo adoptar estas tecnologías en función de tu negocio y presupuesto específicos es lo que se conoce como una estrategia de alta disponibilidad.

Al diseñar una estrategia de alta disponibilidad, primero debes considerar los siguientes factores:

• RTO (Objetivo de Tiempo de Recuperación) - es decir, objetivo de tiempo de recuperación, significa cuánto tiempo de inactividad se permite, normalmente expresado por unos pocos 9s, por ejemplo, el 99,999% de disponibilidad significa no más de 5 minutos de inactividad al año, el 99,99% de disponibilidad significa no más de 52,5 minutos de inactividad al año, y el 99,9% de disponibilidad significa no más de 8,75 horas de inactividad al año. Cabe destacar que el método de cálculo de la RTO tiene en cuenta si el sistema es 24*365 o solo de 6 a 21 horas, etc. También debes prestar atención a si la ventana de mantenimiento cuenta como tiempo de inactividad, y es más fácil lograr una mayor disponibilidad si se permite el mantenimiento y el parche de la base de datos durante esa ventana.
• RPO (Objetivo de Punto de Recuperación) – También conocido como objetivo de punto de recuperación, significa cuánta pérdida de datos se permite. Normalmente, mientras hagas una buena copia de seguridad, puedes conseguir fácilmente una pérdida de datos cero. Pero cuando ocurre un desastre, dependiendo del grado de corrupción de la base de datos, el tiempo que tarda en restaurar los datos de una copia de seguridad hará que la base de datos deje de estar disponible, lo que afectará a la implementación del RTO. Un ejemplo temprano y más famoso es un sistema bancario en Europa y Estados Unidos, que solo tiene en cuenta el RPO, donde solo hay copias de seguridad completas y de registros en el sistema, copias de seguridad completas cada 3 meses, copias de seguridad de registro cada 15 minutos; cuando ocurre un desastre, solo mediante copias de seguridad completas y de registros pueden restaurar los datos, así que aunque no hay pérdida de datos, como tardaron dos días completos en restaurarse, el sistema bancario estuvo indisponible durante 2 días, por lo que se perdieron muchos clientes. Otro ejemplo opuesto es un sitio web de vídeo online doméstico, que utiliza SQL Server como base de datos relacional de back-end, el front-end usa No-SQL y regularmente importa datos No-SQL a la base de datos relacional como copia de seguridad.
  

    Presupuesto – RTO y RPO se conocen colectivamente como SLAs (Acuerdos de Nivel de Servicio), y al diseñar una estrategia de alta disponibilidad, necesitas medir qué tan bien cumples con los SLAs según tu negocio, dependiendo de tu presupuesto y midiendo el coste de diferentes SLAs en caso de fallo. En términos generales, es difícil lograr altos SLAs con un presupuesto limitado, y aunque los altos SLAs se logren mediante arquitecturas complejas, las arquitecturas complejas también implican altos costes de operación y mantenimiento, por lo que es necesario elegir la tecnología adecuada dentro del presupuesto para cumplir con los SLAs.

Por lo tanto, en general, el gran marco para una alta disponibilidad puede determinarse mediante varias preguntas de toma de pedidos:

• ¿Cuál es el tiempo muerto que los accionistas están dispuestos a aceptar?
• ¿Qué tiempo de inactividad es aceptable para los responsables?
• ¿Cuál es el presupuesto previsto para un escenario de alta disponibilidad?
• ¿Cuánto se pierde por hora debido al tiempo de inactividad?
  

• Copia de seguridad en frío: El servidor de espera está configurado para aceptar los datos del servidor principal y, cuando falla, restaurar manualmente los datos en la base de datos principal o reconfigurar la cadena de conexión o los permisos del programa para poner en línea la base de datos de respaldo.
• Copia de seguridad en caliente: Los datos del servidor principal transmitirán continuamente los registros al servidor de respaldo (a intervalos irregulares, pueden ser de 15 minutos, 30 minutos, 1 minuto, etc.), de este modo, el servidor principal al servidor de respaldo suele actualizarse de forma asíncrona, por lo que no se puede garantizar que los datos del servidor principal y del servidor de respaldo estén garantizados. Además, este esquema normalmente no implementa monitorización automática de fallos ni conmutación por error.
• Copia de seguridad en caliente: Los datos del servidor principal se sincronizan automáticamente en el servidor de copia de seguridad y, en la mayoría de los casos, se incluyen monitorización automática de fallos y conmutación por error, garantizando la consistencia de datos entre el servidor principal y el servidor de respaldo.
  

    A medida que las copias de seguridad de frío a caliente se disparan.

    Las funciones de alta disponibilidad soportadas en SQL Server están estrechamente relacionadas con la versión, y la edición Enterprise soporta todas las funciones de alta disponibilidad, incluyendo:

• Clúster de conmutación por error
• L Imagen de la base de datos
• L Transmisión del registro de transacciones
• L Instantáneas de bases de datos
• Actualizaciones de alta disponibilidad
• L Memoria de carga caliente
• L Operaciones de indexación en línea
• L Base de datos parcialmente online (solo se restauran el grupo maestro de archivos o grupo maestro y los archivos NDF adicionales)
  

    Para versiones específicas de las que se cuentan con alta disponibilidad, véase:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxCabe destacar que la versión gratuita Express puede servir como servidor testigo para el reflejo de bases de datos, lo que supone ahorros de costes.

Clúster de conmutación por error

    Los clústeres de conmutación por conmutación por error proporcionan soporte de alta disponibilidad para toda la instancia de SQL Server, lo que significa que una instancia de SQL Server en un nodo del clúster hace failover a otros nodos del clúster debido a errores de hardware, errores del sistema operativo, etc. La alta disponibilidad se logra mediante múltiples servidores (nodos) que comparten uno o más discos, y los clústeres de conmutación por error aparecen en la red de la misma manera que un solo ordenador, pero con características de alta disponibilidad. Es importante señalar que, dado que los clústeres de conmutación por error se basan en discos compartidos, existe un único punto de fallo de disco, por lo que se deben desplegar protecciones adicionales como la replicación de SAN a nivel de disco. El clúster de conmutación por error más común es un clúster de conmutación por error de dos nodos, incluyendo el maestro y el esclavo.

Transmisión de registros de transacciones

    El envío de registros de transacciones proporciona protección de alta disponibilidad a nivel de base de datos. El registro se utiliza para mantener una o más bases de datos de espera (llamadas "bases de datos secundarias") de la base de datos de producción correspondiente (llamada "base de datos primaria"). Antes de que ocurra una conmutación por error, la base de datos secundaria debe actualizarse completamente aplicando manualmente todas las copias de seguridad de los registros no restauradas. La entrega de registros tiene la flexibilidad de soportar múltiples bases de datos de espera. Si se requieren múltiples bases de datos alternativas, la entrega de registros puede usarse por separado o como complemento al espejado de bases de datos. Cuando estas soluciones se utilizan conjuntamente, la base de datos principal de la configuración actual de espejo de base de datos es también la base de datos principal de la configuración actual de envío de troncos.

    La entrega de registros de transacciones puede usarse para hacer copias de seguridad en frío y en caliente.

Espejo de bases de datos

    El reflejo de bases de datos es en realidad una solución de software que también proporciona protección a nivel de base de datos, proporcionando un failover casi instantáneo para mejorar la disponibilidad de la base de datos. Un espejo de base de datos puede usarse para mantener una única base de datos de reserva (o "base de datos espejo") para la base de datos de producción correspondiente (llamada "base de datos principal").
Como la base de datos espejo siempre está en estado de restauración, pero la base de datos no se restaura, no se puede acceder directamente a la base de datos espejo. Sin embargo, para cargas de solo lectura como los informes, puedes usar la base de datos espejada indirectamente creando una instantánea de la base de datos espejada. Las instantáneas de base de datos proporcionan a los clientes acceso de solo lectura a los datos de la base de datos cuando se crea la instantánea. Cada configuración de espejo de base de datos implica un "servidor principal" que contiene la base de datos principal, y también un servidor espejo que contiene la base de datos espejada. El servidor espejo actualiza continuamente la base de datos espejo con la base de datos principal.
    El reflejo de base de datos se ejecuta en operación síncrona en modo de alta seguridad o en operación asincrónica en modo de alto rendimiento. En modo de alto rendimiento, las transacciones no necesitan esperar a que el servidor espejo escriba los registros en disco antes de poder enviarse, lo que maximiza el rendimiento. En modo de alta seguridad, las transacciones comprometidas son comprometidas por ambos socios, pero el tiempo de retardo de la transacción se extiende. La configuración más sencilla de espejado de bases de datos implica únicamente al servidor principal y al servidor espejo. En esta configuración, si se pierde el servidor principal, el servidor espejo puede usarse como servidor de espera, pero puede causar pérdida de datos. El modo de alta seguridad soporta configuración en espera y modo de alta seguridad con conmutación automática. Esta configuración implica una instancia de servidor de terceros llamada "servidor testigo" que permite que el servidor espejo se utilice como servidor de copia de seguridad en caliente. La conmutación por error de la base de datos principal a la base de datos espejo suele tardar unos segundos.

    El reflejo de base de datos puede usarse tanto para copias de seguridad en caliente como en caliente.

copiar

    La replicación no es estrictamente una característica diseñada para alta disponibilidad, pero puede aplicarse a alta disponibilidad. La replicación proporciona protección a nivel de objeto de base de datos. La replicación utiliza un modelo de publicación-suscripción, donde los datos son publicados por el servidor principal, conocido como el editor, a uno o más secundarios o suscriptores. La replicación proporciona disponibilidad y escalabilidad en tiempo real entre estos servidores. Soporta filtrado para proporcionar un subconjunto de datos a los suscriptores, al tiempo que permite actualizaciones de particiones. El abonado está en línea y disponible para informes u otras funciones sin necesidad de recuperación por consulta. SQL Server ofrece cuatro tipos de replicación: replicación instantánea, replicación transaccional, replicación peer-to-peer y replicación por fusión.

AlwaysOnGrupo de usabilidad

    AlwaysOn Availability Groups es una nueva función introducida en SQL Server 2012. También se proporciona protección a nivel de base de datos. También amplía el límite de que el reflejo de bases de datos solo puede ser 1:1, de modo que una réplica primaria puede corresponder a hasta 4 réplicas secundarias (en SQL Server 2014, este límite se amplía a 8), de las cuales 2 réplicas secundarias pueden sincronizarse como copias de seguridad en caliente y réplicas primarias en tiempo real, y las otras dos réplicas secundarias asíncronas pueden usarse como copias de seguridad en caliente. Además, las réplicas secundarias pueden configurarse como solo lectura y pueden usarse para asumir la carga de copias de seguridad.

    Por ello, el reflejo de bases de datos está marcado como "obsoleto" en SQL Server 2012.

    Después de comprender los conceptos básicos de alta disponibilidad y las tecnologías de alta disponibilidad que ofrece SQL Server, echemos un vistazo al diseño de una estrategia de alta disponibilidad. La planificación de una estrategia de alta disponibilidad puede dividirse en cuatro fases:

Requisitos de recolección

    El primer paso para decidir una estrategia de alta disponibilidad es, sin duda, recopilar los requisitos empresariales para establecer SLAs. El RTO y el RPO son las partes más críticas y, sobre esta base, establecer expectativas realistas sobre los requisitos de disponibilidad y establecer una estrategia realista de alta disponibilidad basada en estas expectativas.

Límites de evaluación

    Los límites de evaluación no solo se limitan a las distintas tecnologías de alta disponibilidad en SQL Server, sino también a aquellas que no son técnicas. Si solo tienes un presupuesto de decenas de miles de yuanes, pero quieres hacer una solución de alta disponibilidad basada en centros de datos externos y replicación SAN, sin duda es un sueño ingenuo. Otra limitación no técnica es el nivel de personal de operaciones, y a menudo, las arquitecturas complejas implican más personal de operaciones cualificado. Otras limitaciones no técnicas incluyen la disponibilidad de espacio en disco en el centro de datos, si la fuente de alimentación y el aire acondicionado pueden cubrir las necesidades, y el tiempo requerido para implementar la estrategia de disponibilidad.

    Las limitaciones técnicas incluyen diferentes funciones y limitaciones de alta disponibilidad, funciones soportadas por distintas versiones de SQL Server, el número de CPUs y el tamaño de la memoria. Se recomienda encarecidamente que primero consultes las limitaciones de las diferentes versiones y funciones de SQL Server en la web MSDN de Microsoft antes de implementar una política de alta disponibilidad.

Tecnología seleccionada

    Tras recopilar los requisitos y evaluar las restricciones, el siguiente paso es seleccionar las tecnologías o la combinación de tecnologías descritas anteriormente en este artículo para cumplir con los requisitos de la SLA. Si la tecnología seleccionada no cumple con el SLA, es fácil informar de las limitaciones que no cumplen con el SLA, lo que te permite solicitar recursos faltantes o comprometer el SLA.

Prueba, valida y documenta

    Las políticas de alta disponibilidad deben ser rigurosamente probadas y validadas desde el principio para garantizar que las políticas actuales cumplan con los SLAs. Sin embargo, cuando se lanza una estrategia de alta disponibilidad, también es necesario probarla y validarla regularmente para asegurar que la política actual pueda seguir cumpliendo con los SLAs a pesar del crecimiento de datos, el negocio o los cambios en los requisitos. Al mismo tiempo, la configuración de la solución de disponibilidad, el método de conmutación por error y el plan de recuperación ante desastres deben documentarse al mismo tiempo para poder rastrearse en caso de fallo o ajuste futuro de la estrategia de alta disponibilidad.

Este artículo explica los conceptos básicos de alta disponibilidad, el concepto de SLAs, los diferentes tipos de características de alta disponibilidad soportadas en SQL Server y los pasos necesarios para diseñar una estrategia de alta disponibilidad. Cabe destacar que, aunque este artículo solo habla de alta disponibilidad a nivel de base de datos, la alta disponibilidad no es solo un asunto para DBA, sino que también incluye la colaboración de diferentes roles como personal de operación y mantenimiento de sistemas, administradores de red, desarrolladores y gestores para cumplir mejor con los SLAs.