Continuidad empresarial y recuperación de bases de datos: SQL Server en Linux

Se aplica a: SQL Server

En este artículo, se ofrece una visión global de las soluciones de continuidad empresarial para alta disponibilidad y recuperación ante desastres en SQL Server, en Windows y Linux.

Una tarea habitual que todo usuario que implemente SQL Server debe tener en cuenta es la comprobación de que todas las instancias de SQL Server críticas y las bases de datos que contienen están disponibles en el momento en que el negocio y los usuarios finales las necesitan; ya sea de 9 a 5 o durante todo el día. El objetivo es mantener la empresa en funcionamiento con una interrupción mínima o inexistente. Este concepto se conoce también como continuidad empresarial.

SQL Server 2017 (14.x) introdujo muchas características nuevas o mejoras de las ya existentes, algunas de las cuales están relacionadas con la disponibilidad. La novedad más importante en SQL Server 2017 (14.x) es la compatibilidad con SQL Server en las distribuciones de Linux. Para obtener una lista completa de las nuevas características de SQL Server, vea los temas siguientes:

• Novedades de SQL Server 2017
• Novedades de SQL Server 2017 en Linux
• Novedades de SQL Server 2019
• Novedades de SQL Server 2019 en Linux
• Novedades de SQL Server 2022

En este artículo, se tratan principalmente los escenarios de disponibilidad de SQL Server 2017 (14.x) y versiones posteriores, así como las características de disponibilidad nuevas y mejoradas. Entre estos escenarios se encuentra los híbridos que pueden contener implementaciones de SQL Server en Windows Server y Linux, y los que pueden aumentar el número de copias que se pueden leer de una base de datos.

Si bien este artículo no trata las opciones de disponibilidad externas a SQL Server, como aquellas que proporciona la virtualización, todo lo que se analiza aquí se aplica a las instalaciones de SQL Server que se encuentran dentro de una máquina virtual invitada, ya sea en la nube pública u hospedada en un servidor hipervisor local.

Escenarios de SQL Server en los que se usan las características de disponibilidad

Los grupos de disponibilidad Always On, las instancias de clúster de conmutación por error Always On y el trasvase de registros se pueden usar de varias maneras y no necesariamente solo con fines de disponibilidad. Son cuatro las formas principales en que se pueden utilizar las características de disponibilidad:

• Alta disponibilidad
• Recuperación ante desastres
• Migraciones y actualizaciones
• Escalado horizontal de copias legibles de una o varias bases de datos

En las secciones siguientes, se describen las características pertinentes que se pueden usar para ese escenario concreto. La única característica que no se trata aquí es la replicación de SQL Server. Aunque oficialmente no se ha designado como una característica de disponibilidad bajo el concepto genérico AlwaysOn, la replicación de SQL Server se usa a menudo para hacer los datos redundantes en determinados escenarios. La replicación de mezcla no se admite para SQL Server en Linux. Para obtener más información, consulte Replicación de SQL Server en Linux.

Alta disponibilidad

Es importante asegurarse de que las instancias o la base de datos de SQL Server están disponibles en caso de que se produzca un problema local de un centro de datos o de una única región de la nube. En esta sección se explica cómo pueden ser de utilidad las características de disponibilidad para realizar esa tarea. Todas las características descritas están disponibles en Windows Server y en Linux.

Grupos de disponibilidad

Introducidos en SQL Server 2012 (11.x), los grupos de disponibilidad (AG) proporcionan protección a nivel de base de datos mediante el envío de cada transacción de una base de datos a otra instancia, conocida como réplica, que contiene una copia de esa base de datos en un estado especial. Es posible implementar un grupo de disponibilidad en las ediciones Estándar o Enterprise. Las instancias que participan en un grupo de disponibilidad pueden ser instancias independientes o instancias de clúster de conmutación por error (FCI, se describen en la siguiente sección). Puesto que las transacciones se envían a una réplica en el momento en que se producen, los grupos de disponibilidad están recomendados en aquellos casos en que se requiere un punto de recuperación y objetivos de tiempo de recuperación inferiores. El movimiento de datos entre las réplicas puede ser sincrónico o asincrónico; en el caso de la edición Enterprise, se permiten hasta tres réplicas (incluida la principal) como sincrónicas. Un grupo de disponibilidad tiene una copia de lectura y escritura completa de la base de datos que se encuentra en la réplica principal, mientras que todas las réplicas secundarias no pueden recibir transacciones directamente de los usuarios finales o las aplicaciones.

Antes de SQL Server 2022 (16.x), los grupos de disponibilidad solo proporcionan protección de nivel de base de datos y no de nivel de instancia. Cualquier elemento que no se capture en el registro de transacciones o que no se configure en la base de datos tendrá que sincronizarse manualmente para cada réplica secundaria. Algunos ejemplos de objetos que se deben sincronizar manualmente son los inicios de sesión a nivel de instancia, los servidores vinculados y los trabajos del Agente SQL Server.

A partir de SQL Server 2022 (16.x), puede administrar objetos de metadatos, incluidos usuarios, inicios de sesión, permisos y trabajos de Agente SQL Server en el nivel de grupo de disponibilidad, además del nivel de instancia. Para obtener más información, consulte Grupos de disponibilidad independientes.

Un grupo de disponibilidad también tiene otro componente denominado el cliente de escucha, que permite a las aplicaciones y los usuarios finales conectarse sin necesidad de conocer qué instancia de SQL Server hospeda la réplica principal. Cada grupo de disponibilidad tendrá su propio cliente de escucha. Si bien las implementaciones del cliente de escucha son ligeramente diferentes en Windows Server y Linux, la funcionalidad que ofrece y el modo en que se utiliza son iguales. En el diagrama siguiente, se muestra un grupo de disponibilidad basado en Windows Server que usa un clúster de conmutación por error de Windows Server (WSFC). Se requiere un clúster subyacente en el nivel de sistema operativo para la disponibilidad, ya sea en Linux o en Windows Server. En el ejemplo, se muestra una sencilla configuración de dos servidores, o nodos, en la que el WSCF es el clúster subyacente.

Las ediciones Estándar y Enterprise tienen valores máximos diferentes en lo relativo a las réplicas. Un grupo de disponibilidad en la edición Estándar, conocido como grupo de disponibilidad básica, admite dos réplicas (una principal y otra secundaria) con una sola base de datos en el grupo de disponibilidad. La edición Enterprise no solo permite que se configuren varias bases de datos en un solo grupo de disponibilidad, sino que también puede tener hasta nueve réplicas totales (una principal y ocho secundarias). Enterprise Edition también proporciona otras ventajas opcionales, como las réplicas secundarias legibles o la posibilidad de realizar copias de seguridad a partir de una réplica secundaria, entre otras.

En cuanto a la disponibilidad, los grupos de disponibilidad pueden proporcionar conmutación por error automática o manual. La conmutación automática por error puede producirse si se configura el movimiento de datos sincrónico y la base de datos en la réplica principal y secundaria se encuentra en un estado sincronizado. Siempre que se utilice el cliente de escucha y la aplicación haga uso de una versión posterior de .NET Framework (3.5 con una actualización, o 4.0 y versiones posteriores), la conmutación por error debe controlarse con un efecto mínimo o nulo en los usuarios finales en caso de que se utilice un cliente de escucha. La conmutación por error a una réplica secundaria para convertirla en la nueva réplica principal se puede configurar para que sea automática o manual, y generalmente se mide en segundos.

La lista siguiente resalta algunas diferencias con los grupos de disponibilidad en Windows Server y Linux:

• Debido a diferencias en el funcionamiento del clúster subyacente en Linux y Windows Server, todas las conmutaciones por error (manuales o automáticas) de los grupos de disponibilidad se realizan a través del clúster en Linux. En implementaciones de grupos de disponibilidad basadas en Windows Server, las conmutaciones por error manuales deben hacerse a través de SQL Server. Las conmutaciones automáticas por error se controlan mediante el clúster subyacente en Windows Server y Linux.
• Para SQL Server en Linux, la configuración recomendada para grupos de disponibilidad es un mínimo de tres réplicas. Esto se debe a la manera en que funciona la agrupación en clústeres subyacente.
• En Linux, el nombre común usado por cada agente de escucha se define en DNS y no en el clúster, como ocurre en Windows Server.

A partir de SQL Server 2017 (14.x), hay algunas nuevas características y mejoras para los grupos de disponibilidad:

• Tipos de clúster
• REQUIRED_SECONDARIES_TO_COMMIT
• Compatibilidad mejorada del Coordinador de transacciones distribuidas (DTC) para las configuraciones basadas en Windows Server
• Escenarios adicionales de escalado horizontal para bases de datos de solo lectura (se describen más adelante en este artículo)

Tipos de clúster de grupo de disponibilidad

La forma de disponibilidad integrada de agrupación en clústeres de Windows Server se habilita a través de una característica denominada Clústeres de conmutación por error. Permite crear un WSFC para su uso con un grupo de disponibilidad o FCI. La integración para los grupos de disponibilidad y las FCI se proporciona mediante archivos DLL de recursos dependientes del clúster proporcionados por SQL Server.

SQL Server en Linux admite varias tecnologías de agrupación en clústeres. Microsoft admite los componentes de SQL Server, mientras que nuestros asociados admiten la tecnología de agrupación en clústeres pertinente. Por ejemplo, además de Pacemaker, SQL Server en Linux admite HPE Serviceguard y DH2i DxEnterprise como solución de clúster.

Un clúster de conmutación por error basado en Windows y una solución de clúster de Linux son más similares que diferentes. Ambos proporcionan una manera de aprovechar los servidores individuales y combinarlos en una configuración para proporcionar disponibilidad, y tienen conceptos de elementos como recursos, restricciones (incluso si se implementan de manera diferente), conmutación por error, etc.

Por ejemplo, a fin de que Pacemaker se admita tanto en configuraciones de grupo de disponibilidad como de FCI, incluidos aspectos como la conmutación automática por error, Microsoft proporciona el paquete mssql-server-ha para Pacemaker que, aunque es parecido, no es exactamente igual a los DLL del recurso en un clúster WSFC. Una de las diferencias entre un clúster WSFC y Pacemaker es que no hay ningún recurso de nombre de red en Pacemaker, que es el componente que ayuda a tomar el nombre del agente de escucha (o el nombre de la FCI) en un clúster WSFC. DNS proporciona la resolución de nombres en Linux.

Debido a la diferencia en la pila de clúster, se necesitan algunos cambios para los grupos de disponibilidad porque SQL Server tiene que controlar algunos de los metadatos que se controlan de forma nativa por un clúster WSFC. Un cambio de tal importancia es la introducción de un tipo de clúster para un grupo de disponibilidad. Esto se almacena en sys.availability_groups en las columnas cluster_type y cluster_type_desc. Hay tres tipos de clústeres:

• WSFC
• Externo
• None

Todos los grupos de disponibilidad que necesitan una alta disponibilidad deben usar un clúster subyacente, lo que en el caso de SQL Server 2017 (14.x) y versiones posteriores significa un agente de clúster WSFC o Linux. Para los grupos de disponibilidad basados en Windows Server que usan un clúster WSFC subyacente, el tipo de clúster predeterminado es WSFC y no es necesario configurarlo. En el caso de los grupos de disponibilidad basados en Linux, al crear el grupo de disponibilidad, el tipo de clúster debe establecerse en Externo. La integración con una solución de clúster externa en Linux se configura después de crear el grupo de disponibilidad, mientras que en un clúster de WSFC esto se hace en el momento de la creación.

El tipo de clúster Ninguno puede utilizarse con grupos de disponibilidad de Windows Server y Linux. La configuración del tipo de clúster en Ninguno implica que el grupo de disponibilidad no requiere un clúster subyacente. Esto significa que SQL Server 2017 (14.x) es la primera versión de SQL Server que admite grupos de disponibilidad sin un clúster, pero el inconveniente es que esta configuración no se admite como solución de alta disponibilidad.

Para aquellos usuarios que simplemente quieren agregar otras copias de solo lectura de una base de datos o que quieren disfrutar de la misma funcionalidad que proporciona un grupo de disponibilidad para migración/actualizaciones, pero sin la complejidad adicional que implica un clúster subyacente o incluso una replicación, un grupo de disponibilidad con el tipo de clúster Ninguno es una solución perfecta. Para más información, vea las secciones Migraciones y actualizaciones y Escalado de lectura.

La captura de pantalla siguiente muestra la compatibilidad para los distintos tipos de clúster en SQL Server Management Studio (SSMS). Debe ejecutar la versión 17.1 o una posterior. La captura de pantalla siguiente es de la versión 17.2.

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

SQL Server 2016 (13.x) aumentó la compatibilidad para el número de réplicas sincrónicas de dos a tres en la edición Enterprise. Sin embargo, si se sincronizaba una réplica secundaria pero la otra experimentaba un problema, no existía ningún modo de controlar el comportamiento a fin de indicar a la principal que esperase a la réplica que tenía un comportamiento inadecuado o que le permitiera continuar. Esto significa que la réplica principal en algún momento seguiría recibiendo tráfico de escritura, incluso si la réplica secundaria no estuviera en estado sincronizado, con lo que se produciría una pérdida de datos en la réplica secundaria. A partir de SQL Server 2017 (14.x), puede controlar el comportamiento de lo que sucede cuando hay réplicas sincrónicas con REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. Esta opción funciona como se describe a continuación:

• Hay tres valores posibles: 0, 1 y 2
• El valor es el número de réplicas secundarias que deben sincronizarse, lo cual tiene implicaciones para la pérdida de datos, la disponibilidad del grupo de disponibilidad y la conmutación por error.
• En el caso de los clústeres WSFC y el tipo de clúster Ninguno, el valor predeterminado es 0 y se puede establecer manualmente en 1 o 2.
• Para un tipo de clúster Externo, el mecanismo del clúster configurará este valor de manera predeterminada, aunque puede reemplazarse manualmente. Para tres réplicas sincrónicas, el valor predeterminado será 1.

En Linux, el valor de REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT se configura en el recurso de grupo de disponibilidad del clúster. En Windows, se establece a través de Transact-SQL.

Un valor que sea mayor que 0 garantiza mayor protección de datos, porque si no está disponible el número necesario de réplicas secundarias, el servidor principal no estará disponible hasta que se resuelva. REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT afecta también al comportamiento de la conmutación por error, dado que la conmutación automática por error no podría realizarse si el número adecuado de réplicas secundarias no se encontrase en el estado correcto. En Linux, un valor de 0 no permitirá la conmutación automática por error; por tanto, en Linux, al usar la opción sincrónica con la conmutación automática por error, el valor debe ser mayor que 0 para que esta se realice. 0 en Windows Server es el comportamiento de SQL Server 2016 (13.x) y versiones anteriores.

Compatibilidad mejorada con el Coordinador de transacciones distribuidas de Microsoft

Antes de SQL Server 2016 (13.x), la única manera de obtener disponibilidad en SQL Server para las aplicaciones que requieren transacciones distribuidas que usan DTC interiormente era implementar FCI. Una transacción distribuida puede hacerse de dos maneras:

• Una transacción que abarca más de una base de datos en la misma instancia de SQL Server
• Una transacción que abarca más de una instancia de SQL Server o posiblemente implica un origen de datos diferente de SQL Server

SQL Server 2016 (13.x) introdujo la compatibilidad parcial para DTC con los grupos de disponibilidad incluidos en el segundo escenario. SQL Server 2017 (14.x) lo completa al hacer que ambos escenarios sean compatibles con DTC.

En SQL Server 2017 (14.x) y versiones posteriores, la compatibilidad con DTC también puede agregarse a un grupo de disponibilidad después de crearlo. En SQL Server 2016 (13.x), habilitar la compatibilidad con DTC en un grupo de disponibilidad solo se podía realizar en el momento de crear el grupo de disponibilidad.

Instancias de clúster de conmutación por error

Las instalaciones en clúster han sido una característica de SQL Server desde la versión 6.5. Las FCI han resultado ser un método de eficacia probada a la hora de proporcionar disponibilidad para toda la instalación de SQL Server, lo que se conoce como una instancia. Esto significa que todos los elementos de la instancia, incluidas las bases de datos, los trabajos del Agente SQL Server, los servidores vinculados y otros, se moverán a otro servidor en caso que el servidor subyacente encuentre un problema. Todas las FCI requieren algún tipo de almacenamiento compartido, incluso si se proporciona a través de redes. Los recursos de la FCI solo pueden estar en ejecución y ser propiedad de un solo nodo en un momento dado. En el diagrama siguiente, el primer nodo del clúster posee la FCI, lo que también significa que posee los recursos de almacenamiento compartido asociados, que se indican mediante la línea continua hacia el almacenamiento.

Después de una conmutación por error, la propiedad cambia tal y como se muestra en el diagrama siguiente.

Con una FCI no hay pérdida de datos, pero el almacenamiento compartido subyacente es un único punto de error porque hay una copia de los datos. Las FCI se combinan a menudo con otro método de disponibilidad, como un grupo de disponibilidad o el trasvase de registros, a fin de tener copias redundantes de las bases de datos. El método adicional implementado debe usar almacenamiento físicamente separado de la FCI. Cuando la FCI conmuta por error en otro nodo, se detiene en un nodo y se inicia en otro, en un proceso no muy diferente de apagar un servidor y encenderlo. Una FCI pasa por el proceso de recuperación normal, lo que significa que las transacciones que tengan que ponerse al día se pondrán al día, y las transacciones que estén incompletas se revertirán. Por lo tanto, la base de datos es coherente desde un punto de datos hasta el momento del error o la conmutación por error manual; por lo tanto, no hay pérdida de datos. Las bases de datos solo están disponibles una vez completada la recuperación, por lo que el tiempo de recuperación dependerá de muchos factores y, en general, será más largo que la conmutación por error en un grupo de disponibilidad. La contrapartida es que, cuando conmuta por error un grupo de disponibilidad, puede que sea necesario ocuparse de tareas adicionales para permitir que una base de datos se pueda usar, como habilitar un trabajo del Agente SQL Server.

Al igual que un grupo de disponibilidad, las FCI abstraen cuál es el nodo del clúster subyacente que las está hospedando. Una FCI siempre conserva el mismo nombre. Las aplicaciones y los usuarios finales nunca se conectan a los nodos; se utiliza el nombre único asignado a la FCI. Una FCI puede participar en un grupo de disponibilidad como una de las instancias que hospeda una réplica principal o secundaria.

La lista siguiente resalta algunas diferencias con las FCI en Windows Server y Linux:

• En Windows Server, una FCI es parte del proceso de instalación. Una FCI en Linux se configura después de instalar SQL Server.
• Linux solo admite una única instalación de SQL Server por host, por lo que todas las FCI serán una instancia predeterminada. Windows Server admite hasta 25 FCI por WSFC.
• El nombre común usado por las FCI en Linux se define en DNS, y debe ser el mismo que el recurso creado para la FCI.

Trasvase de registros

Si el punto de recuperación y los objetivos de tiempo de recuperación son más flexibles, o las bases de datos no se consideran muy críticas, el trasvase de registros es otra característica de eficacia probada en cuanto a disponibilidad en SQL Server. En función de las copias de seguridad nativas de SQL Server, el proceso para el trasvase de registros genera de forma automática copias de seguridad del registro de transacciones, las copia en una o varias instancias conocidas como estado de espera semiactiva y aplica automáticamente las copias de seguridad del registro de transacciones a dicho estado de espera. El trasvase de registros usa trabajos del Agente SQL Server para automatizar el proceso de copia de seguridad, copia y aplicación de las copias de seguridad del registro de transacciones.

Podría decirse que la mayor ventaja de utilizar el trasvase de registros en cierta manera es que tiene en cuenta el error humano. Es posible retrasar la aplicación de los registros de transacciones. Por lo tanto, si un usuario emite algo parecido a UPDATE sin una cláusula WHERE, el modo de espera podría no tener el cambio, así que podría cambiar a ese modo mientras repara el sistema principal. Aunque el trasvase de registros es fácil de configurar, el cambio desde el servidor principal al estado de espera semiactiva, proceso conocido como cambio de rol, siempre es manual. Un cambio de rol se inicia a través de Transact-SQL y, al igual que un grupo de disponibilidad, todos los objetos no capturados en el registro de transacciones se deben sincronizar manualmente. El trasvase de registros también debe configurarse para cada base de datos, mientras que un solo grupo de disponibilidad puede contener varias bases de datos.

A diferencia de un grupo de disponibilidad o FCI, el trasvase de registros no tiene abstracción para un cambio de rol, que las aplicaciones deben ser capaces de controlar. Se podrían emplear técnicas como un alias de DNS (CNAME), pero esto tiene ventajas y desventajas, como el tiempo necesario para que DNS se actualice después del cambio.

Recuperación ante desastres

Cuando la ubicación de disponibilidad principal experimenta un evento catastrófico, como un terremoto o una inundación, la empresa debe estar preparada para que sus sistemas se pongan a funcionar en cualquier otro lugar. En esta sección se explica cómo pueden ser de utilidad las características de disponibilidad de SQL Server para la continuidad empresarial.

Grupos de disponibilidad

Una de las ventajas de los grupos de disponibilidad es que tanto la alta disponibilidad como la recuperación ante desastres pueden configurarse con una sola característica. Sin necesidad de garantizar que el almacenamiento compartido tenga también una alta disponibilidad, es mucho más fácil tener réplicas que sean locales en un centro de datos para la alta disponibilidad y remotas en otros centros de datos para la recuperación ante desastres, cada una con almacenamiento independiente. El hecho de tener copias adicionales de la base de datos es la compensación para asegurar la redundancia. A continuación se muestra un ejemplo de un grupo de disponibilidad que abarca varios centros de datos. Una réplica principal es responsable de mantener todas las réplicas secundarias sincronizadas.

Fuera de un grupo de disponibilidad con un tipo de clúster Ninguno, un grupo de disponibilidad requiere que todas las réplicas formen parte del mismo clúster subyacente, ya sea WSFC o una solución de clúster externa. Esto significa que, en el diagrama anterior, el clúster WSFC se ajusta para funcionar en dos centros de datos diferentes, lo cual agrega complejidad, independientemente de la plataforma (Windows Server o Linux). El ajuste de clústeres a distancia aumenta la complejidad.

Introducido en SQL Server 2016 (13.x), un grupo de disponibilidad distribuido permite que un grupo de disponibilidad abarque grupos de disponibilidad configurados en clústeres diferentes. Esto elimina la necesidad de que todos los nodos participen en el mismo clúster, lo que facilita en gran medida la configuración de la recuperación ante desastres. Para obtener más información sobre los grupos de disponibilidad distribuidos, vea Grupos de disponibilidad distribuidos.

Instancias de clúster de conmutación por error

FCI puede usarse para la recuperación ante desastres. Al igual que con un grupo de disponibilidad normal, el mecanismo de clúster subyacente también se debe extender a todas las ubicaciones, lo cual incrementa la complejidad. Hay algo más que se debe tener en cuenta para FCI: el almacenamiento compartido. Los mismos discos deben estar disponibles en los sitios primarios y secundarios. Se requiere un método externo, como la funcionalidad proporcionada por el proveedor de almacenamiento a nivel de hardware o el uso de una réplica de almacenamiento en Windows Server, para asegurarse de que los discos usados por la FCI existen en otra parte.

Trasvase de registros

El trasvase de registros es uno de los métodos más antiguo de proporcionar recuperación ante desastres para bases de datos de SQL Server. El trasvase de registros suele usarse con grupos de disponibilidad y FCI para proporcionar una funcionalidad de recuperación ante desastres más sencilla y rentable, en comparación con otras opciones que pueden resultar complejas debido al entorno, las exigencias de tipo administrativo o el presupuesto. De forma similar al caso de alta disponibilidad para el trasvase de registros, muchos entornos retrasarán la carga de un registro de transacciones para tener en cuenta los errores humanos.

Migraciones y actualizaciones

Al implementar nuevas instancias o actualizar las antiguas, una empresa no puede asumir interrupciones prolongadas. En esta sección se analizará cómo se pueden utilizar las características de disponibilidad de SQL Server para minimizar el tiempo de inactividad en un cambio de arquitectura planeado, el paso de un servidor a otro o el cambio de plataforma (por ejemplo, de Windows Server a Linux o viceversa), o durante la aplicación de revisiones.

Grupos de disponibilidad

Una instancia existente que contenga uno o varios grupos de disponibilidad puede actualizarse in situ a versiones posteriores de SQL Server. Aunque esto requerirá cierta cantidad de tiempo de inactividad, es posible minimizarlo con una planeación correcta.

Si el objetivo es migrar a nuevos servidores y no cambiar la configuración (incluido el sistema operativo o la versión de SQL Server), esos servidores podrían agregarse como nodos al clúster subyacente existente y, de este modo, formarán parte del grupo de disponibilidad. Una vez que la réplica o las réplicas estén en el estado correcto, podría producirse una conmutación por error manual en un servidor nuevo de modo que las antiguas se quitarían del grupo de disponibilidad y, en última instancia, se retirarían.

Los grupos de disponibilidad distribuidos son también otro método para migrar a una configuración nueva o actualizar SQL Server. Dado que un grupo de disponibilidad distribuido admite diferentes grupos de disponibilidad en distintas arquitecturas, podría cambiar, por ejemplo, de una instancia de SQL Server 2016 (13.x) que se ejecute en Windows Server 2012 R2 a otra instancia de SQL Server 2017 (14.x) que se ejecute en Windows Server 2016.

Por último, los grupos de disponibilidad con un tipo de clúster Ninguno también pueden utilizarse para la migración o la actualización. No es posible mezclar y combinar tipos de clúster en una configuración de grupo de disponibilidad típica, por lo que todas las réplicas tendrían que ser de tipo Ninguno. Un grupo de disponibilidad distribuido se puede usar para abarcar grupos de disponibilidad configurados con diferentes tipos de clúster. Este método también se admite en todas las plataformas de sistema operativo diferentes.

Todas las variantes de los grupos de disponibilidad para las migraciones y las actualizaciones permiten que la parte más lenta del trabajo se realice a lo largo del tiempo (sincronización de datos). Cuando llegue el momento de iniciar el cambio a la nueva configuración, el corte será una breve interrupción y no un largo período de tiempo de inactividad en el que todo el trabajo, incluida la sincronización de datos, tenga que completarse.

Los grupos de disponibilidad pueden proporcionar un tiempo de inactividad mínimo durante la aplicación de revisiones del sistema operativo subyacente mediante la conmutación por error manual de la réplica principal a una réplica secundaria en tanto dure la aplicación de revisiones. Desde la perspectiva del sistema operativo, será más habitual hacer esto en Windows Server puesto que a menudo, pero no siempre, el mantenimiento del sistema operativo subyacente puede requerir un reinicio. Con la aplicación de revisiones en Linux a veces es necesario reiniciar, pero es algo poco frecuente.

La aplicación de revisiones a instancias de SQL Server que participan en un grupo de disponibilidad también puede minimizar el tiempo de inactividad, dependiendo de la complejidad de la arquitectura del grupo de disponibilidad. A la hora de aplicar revisiones a los servidores que participan en un grupo de disponibilidad, se aplican las revisiones en primer lugar a la réplica secundaria. Una vez que se han aplicado las revisiones al número adecuado de réplicas, la réplica principal conmuta por error manualmente a otro nodo para llevar a cabo la actualización. Toda réplica secundaria restante en ese momento se puede actualizar también.

Instancias de clúster de conmutación por error

Las FCI no pueden servirle de ayuda por sí misma en una migración o actualización tradicional; es necesario haber configurado un grupo de disponibilidad o un trasvase de registros para las bases de datos de la FCI y todos los demás objetos implicados. Sin embargo, las FCI en Windows Server siguen siendo una opción popular para aquellos casos en que es necesario aplicar una revisión a los servidores de Windows Server subyacentes. Puede iniciar una conmutación por error manual, lo que implica una breve interrupción en lugar de tener la instancia no disponible durante todo el tiempo en que se están aplicando las revisiones a Windows Server. Una FCI se puede actualizar in situ a versiones posteriores de SQL Server. Para obtener más información, consulte Actualizar una instancia de clúster de conmutación por error de SQL Server.

Trasvase de registros

El trasvase de registros sigue siendo una opción popular para migrar y actualizar bases de datos. De forma similar a los grupos de disponibilidad, pero esta vez utilizando el registro de transacciones como método de sincronización, la propagación de datos se puede iniciar antes del cambio de servidor. En el momento del cambio, una vez que se detiene todo el tráfico en el origen, será necesario tomar, copiar y aplicar un registro de transacciones final a la nueva configuración. En ese momento, la base de datos se puede poner en línea. El trasvase de registros suele ser más tolerante con las redes más lentas, y mientras que la conmutación puede ser ligeramente más larga que otra que se realice mediante un grupo de disponibilidad o un grupo de disponibilidad distribuido, normalmente se mide en minutos (no horas, días ni semanas).

Al igual que los grupos de disponibilidad, el trasvase de registros puede proporcionar un mecanismo que permite cambiar a otro servidor en caso de aplicación de revisiones.

Otros métodos de implementación de SQL Server y disponibilidad

Hay otros dos métodos de implementación para SQL Server en Linux: contenedores y uso de Azure (u otro proveedor de nube pública). La necesidad generalizada de disponibilidad, tal como se presenta en este documento, existe con independencia de cómo se implemente SQL Server. Estos dos métodos tienen algunas consideraciones especiales en lo relativo a hacer que SQL Server tenga alta disponibilidad.

Contenedores y opciones de alta disponibilidad y recuperación ante desastres de SQL Server

La implementación de contenedores de SQL Server es una nueva forma de implementar SQL Server en Linux. Un contenedor es una imagen completa de SQL Server que está lista para ejecutarse.

En función de la plataforma de contenedor que use, por ejemplo, al usar un orquestador de contenedores como Kubernetes, si se pierde el contenedor, se puede implementar de nuevo y adjuntar al almacenamiento compartido que se usó. Aunque esto proporciona cierta resistencia, habrá un determinado tiempo de inactividad asociado con la recuperación de la base de datos, y no tendría realmente la misma alta disponibilidad que si se utilizara un grupo de disponibilidad o una FCI.

Si desea configurar la alta disponibilidad para contenedores de SQL Server implementados en Kubernetes o plataformas que no son de Kubernetes, puede usar DH2i DxEnterprise como una de las soluciones de agrupación en clústeres, sobre la que puede configurar un grupo de disponibilidad en modo de alta disponibilidad. Esta opción proporciona el objetivo de punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO) esperados de una solución de alta disponibilidad.

Implementación de IaaS basada en Linux

Es posible implementar máquinas virtuales IaaS de Linux con SQL Server instalado utilizando Azure. Al igual que en las instalaciones basadas en un sistema local, una instalación compatible requiere el uso de STONITH (Shoot the Other Node in the Head), que es externo al propio agente de clúster. STONITH se proporciona a través de agentes de disponibilidad que actúan como barrera. Algunas distribuciones los incluyen como parte de la plataforma, mientras que otras dependen de los proveedores externos de hardware y software. Póngase en contacto con su distribuidor de Linux preferido para ver de qué manera se proporciona STONITH de modo que pueda implementar una solución admitida en la nube pública.

Hay disponibles guías para instalar SQL Server en Linux para las siguientes distribuciones:

• Inicio rápido: instalar SQL Server y crear una base de datos en Red Hat
• Inicio rápido: Instalación de SQL Server y creación de una base de datos en Ubuntu
• Inicio rápido: Instalación de SQL Server y creación de una base de datos en SUSE Linux Enterprise Server

Escalado de lectura de

Desde su introducción en SQL Server 2012 (11.x), las réplicas secundarias han podido utilizarse para consultas de solo lectura. Hay dos maneras de hacerlo con un grupo de disponibilidad: permitiendo el acceso directo a la secundaria, y configurando el enrutamiento de solo lectura, lo que requiere el uso del cliente de escucha. SQL Server 2016 (13.x) introdujo la posibilidad de equilibrar la carga de las conexiones de solo lectura a través del cliente de escucha mediante un algoritmo round robin, lo que permite a las solicitudes de solo lectura su expansión por todas las réplicas legibles.

El escalado de copias legibles de una base de datos a través de grupos de disponibilidad apareció por primera vez con los grupos de disponibilidad distribuidos en SQL Server 2016 (13.x). Esto permitió a las empresas contar con copias de solo lectura de la base de datos no solo localmente, sino también a nivel regional y mundial con una cantidad mínima de configuración, y reducir el tráfico de red y la latencia gracias a que las consultas se ejecutan localmente. Cada réplica principal de un grupo de disponibilidad puede inicializar dos otros grupos de disponibilidad, incluso si no es la copia de lectura/escritura completa, por lo que cada grupo de disponibilidad distribuido puede admitir hasta 27 copias de los datos que son legibles.

A partir de SQL Server 2017 (14.x), es posible crear una solución de solo lectura casi en tiempo real con la configuración de grupos de disponibilidad con un clúster de tipo Ninguno. Si el objetivo radica en utilizar grupos de disponibilidad para las réplicas secundarias legibles y no en la disponibilidad, esta opción elimina la complejidad de utilizar un clúster WSFC o una solución de clúster externa en Linux, y ofrece las ventajas legibles de un grupo de disponibilidad en un método de implementación más sencillo.

La única advertencia importante es que, como no hay ningún clúster subyacente con el tipo "Ninguno", la configuración del enrutamiento de solo lectura es un poco diferente. Desde una perspectiva de SQL Server, un cliente de escucha sigue siendo necesario para enrutar las solicitudes, incluso si no hay ningún clúster. En lugar de configurar un agente de escucha tradicional, se utiliza la dirección IP o el nombre de la réplica principal. Después, se usa la réplica principal para enrutar las solicitudes de solo lectura.

Técnicamente, se puede configurar un estado de espera semiactiva de trasvase de registros para el uso legible mediante la restauración de la base de datos WITH STANDBY. Sin embargo, dado que los registros de transacciones requieren el uso exclusivo de la base de datos para la restauración, los usuarios no podrán acceder a la base de datos mientras esto ocurre. Por ello, el trasvase de registros es una solución menos idónea, especialmente si se necesitan datos casi en tiempo real.

Un aspecto que debe tenerse en cuenta para todos los escenarios de escalado de lectura con grupos de disponibilidad es que, a diferencia de la replicación transaccional donde todos los datos están activos, cada réplica secundaria no está en un estado en el que se puedan aplicar los índices únicos: la réplica es una copia exacta de la principal. Si se requieren índices para la creación de informes o si es necesario manipular datos, deben crearse en las bases de datos de la réplica principal. Si necesita esa flexibilidad, la replicación es una mejor solución para datos legibles.

Interoperabilidad de distribución multiplataforma y Linux

Ahora que SQL Server se admite en Windows Server y Linux, en esta sección se tratan los escenarios en que ambas plataformas pueden funcionar juntas para ofrecer disponibilidad, además de para otros fines, así como el caso de las soluciones que incorporan más de una distribución de Linux.

Grupos de disponibilidad distribuidos

Los grupos de disponibilidad distribuidos están diseñados para abarcar las configuraciones de grupo de disponibilidad, con independencia de que los dos clústeres subyacentes debajo de los grupos de disponibilidad sean dos clústeres WSFC diferentes, distribuciones de Linux, o uno esté en un clúster WSFC y otro en Linux. Un grupo de disponibilidad distribuido será el método principal de contar con una solución multiplataforma. Un grupo de disponibilidad distribuido es también la solución principal para las migraciones del tipo de una conversión desde una infraestructura de SQL Server basada en Windows Server a otra basada en Linux, en caso de que sea esto lo que quiere hacer su empresa. Como se mencionó anteriormente, los grupos de disponibilidad, y especialmente los grupos de disponibilidad distribuidos, minimizarán el tiempo durante el que una aplicación podría no estar disponible para su uso. A continuación se muestra un ejemplo de un grupo de disponibilidad distribuido que abarca un clúster WSFC y Pacemaker.

Si se configura un grupo de disponibilidad con un clúster de tipo Ninguno, este puede abarcar Windows Server y Linux, así como varias distribuciones de Linux. Puesto que esta no es una auténtica configuración de alta disponibilidad, no debe utilizarse para las implementaciones críticas, sino para escenarios de escalado de lectura o de migración o actualización.

Trasvase de registros

Dado que el trasvase de registros se basa en la copia de seguridad y restauración, no existen diferencias en las bases de datos, las estructuras de archivos, etc., para SQL Server en Windows Server en comparación con SQL Server en Linux. Esto significa que se puede configurar el trasvase de registros entre una instalación de SQL Server basada en Windows Server y otra de Linux, así como entre distintas distribuciones de Linux. Todo lo demás permanece igual. La única advertencia es que el trasvase de registros, al igual que un grupo de disponibilidad, no puede funcionar cuando el origen se encuentra en una versión principal de SQL Server posterior en relación con un destino que está en una versión anterior de SQL Server.

Resumen

Las instancias y las bases de datos de SQL Server 2017 (14.x) y versiones posteriores pueden volverse de alta disponibilidad usando las mismas características en Windows Server y Linux. Además de los escenarios de disponibilidad estándar de alta disponibilidad y recuperación ante desastres local, se puede minimizar el tiempo de inactividad asociado a las actualizaciones y las migraciones con las características de disponibilidad de SQL Server. Los grupos de disponibilidad también pueden proporcionar copias adicionales de una base de datos como parte de la misma arquitectura para escalar horizontalmente copias legibles. Tanto si va a implementar una nueva solución como si está considerando la posibilidad de aplicar una actualización, SQL Server tiene la disponibilidad y confiabilidad que necesita.

Contenido relacionado

• Configuración de un grupo de disponibilidad AlwaysOn de SQL Server para alta disponibilidad en Linux
• Conmutación por error del grupo de disponibilidad Always On en Linux