Continuidad empresarial y HADR para SQL Server en VM de Azure

Se aplica a:SQL Server en VM de Azure

En este artículo se comparan y contrastan las soluciones de continuidad empresarial híbrida y solo de Azure que puede usar para alta disponibilidad y recuperación ante desastres (HADR) con SQL Server en Azure Virtual Machines (VM).

La continuidad empresarial implica continuar el negocio en caso de desastre, planear la recuperación y asegurarse de que los datos tienen una alta disponibilidad. SQL Server en Azure Virtual Machines puede ayudar a disminuir el costo de una solución de base de datos de alta disponibilidad y recuperación ante desastres (HADR).

Nota:

Es posible migrar mediante lift and shift la solución de instancia de clúster de conmutación por error y grupo de disponibilidad a SQL Server en VM de Azure mediante Azure Migrate.

Información general

SQL Server en VM de Azure admite el siguiente tipo de soluciones:

• Solo para Azure: todo el sistema HADR se ejecuta en Azure.
• Configuración híbrida: una parte de la solución se ejecuta en Azure y la otra parte se ejecuta localmente en su organización.

La flexibilidad del entorno Azure permite migrar total o parcialmente a Azure a fin de satisfacer los requisitos de presupuesto y HADR de sus sistemas de bases de datos de SQL Server. Es necesario asegurarse de que los sistemas de base de datos tienen funcionalidades HADR que cumplen los requisitos empresariales para el objetivo de tiempo de recuperación (RTO), el objetivo de punto de recuperación (RPO) y el contrato de nivel de servicio (SLA).

Los mecanismos de alta disponibilidad integrados de Azure, como la recuperación del servicio en los servicios en la nube y la detección de recuperación de errores para máquinas virtuales, no garantiza por sí solo que pueda cumplir con el contrato de nivel de servicio, el RTO o el RPO. Si bien estos mecanismos ayudan a proteger la alta disponibilidad de la máquina virtual, no protegen la disponibilidad de la instancia de SQL Server que se ejecuta dentro de la máquina virtual. Es posible que la instancia de SQL Server no funcione a pesar de que la máquina virtual esté en línea y en buen estado. Incluso con los mecanismos de alta disponibilidad que proporciona Azure, es posible que se produzcan tiempos de inactividad de las máquinas virtuales debidos a eventos como la recuperación errores de software o hardware o las actualizaciones del sistema operativo.

Características de la continuidad del negocio

En la tabla siguiente se enumeran las características de SQL Server solo de Azure e híbridas que puede utilizar para alta disponibilidad (HA), recuperación ante desastres (DR) o ambas (alta disponibilidad/recuperación ante desastres):

Estas características de SQL Server se admiten para la continuidad empresarial tanto en una configuración híbrida como solo de Azure. Algunas de las opciones son ideales para la alta disponibilidad y la recuperación ante desastres (HA/DR), otras para la alta disponibilidad (HA) y otras para la recuperación ante desastres (DR).

características de SQL Server	Opción de alta disponibilidad/recuperación ante desastres	Detalles
Grupos de disponibilidad Always On	Alta disponibilidad y recuperación ante desastres	Proporciona protección a nivel de base de datos, y también aumento de la alta disponibilidad y la recuperación ante desastres mediante la adición de réplicas en diferentes zonas de disponibilidad o regiones.
Instancias de clúster de conmutación por error (FCI) de Always On	Alta disponibilidad	Utiliza almacenamiento compartido para proporcionar protección a nivel de instancia. Puede aumentar la protección tanto en la base de datos como a nivel de instancia por medio de la combinación con grupos de disponibilidad.
Trasvase de registros	Recuperación ante desastres	La protección a nivel de base de datos para la recuperación ante desastres implica enviar copias de seguridad del registro de transacciones desde un servidor principal y restaurarlas en un servidor secundario. Se necesita un recurso compartido de archivos de Azure.
Copia de seguridad y restauración de SQL Server con Azure Blob Storage	Recuperación ante desastres	Copias de seguridad de base de datos de producción almacenadas en Azure Blob Storage para la protección de la recuperación ante desastres.
Azure Site Recovery	Recuperación ante desastres	Una solución de recuperación ante desastres que replica máquinas virtuales de un sitio primario a un sitio secundario.

Es posible combinar las tecnologías para implementar una solución SQL Server que cuente con funcionalidades de alta disponibilidad y de recuperación ante desastres. Según la tecnología que se use, una implementación híbrida puede requerir un túnel VPN con la red virtual de Azure. Aunque las tecnologías son las mismas, puede haber algunas diferencias en la configuración de Azure o de un diseño híbrido.

Grupos de disponibilidad (HADR)

La protección de SQL Server en VM de Azure a nivel de base de datos se puede realizar mediante grupos de disponibilidad como una solución de alta disponibilidad y recuperación ante desastres (HADR). Las réplicas que se ejecutan en las VM de Azure de la misma región proporcionan alta disponibilidad. Se requiere una VM de controlador de dominio, ya que los clústeres de conmutación por error de Windows requieren un dominio de Active Directory.

Para comenzar, revise el tutorial del grupo de disponibilidad.

Para una mayor redundancia disponibilidad y protección de la recuperación ante desastres, las VM de Azure se pueden implementar en zonas de disponibilidad distintas, tal como se documenta en la información general sobre los grupos de disponibilidad. Expandir las réplicas de disponibilidad que se ejecutan en varios centros de datos en VM de Azure añade una mayor cobertura de la recuperación ante desastres. Una solución entre regiones ayuda a protegerse frente a interrupciones en todo el sitio.

Dentro de una región, todas las réplicas deben estar en el mismo servicio en la nube y la misma red virtual. Como cada región tiene una virtual network independiente, estas soluciones requieren conectividad de red a red. Para más información, consulte Configuración de una conexión de red a red mediante Azure Portal. Para instrucciones detalladas, consulte Configuración de un grupo de disponibilidad Always On de SQL Server en distintas regiones de Azure.

En una configuración híbrida, algunas réplicas de disponibilidad se ejecutan en VM de Azure y otras réplicas se ejecutan localmente para la recuperación ante desastres a través de sitios. El sitio de producción puede ser local o encontrarse en un centro de datos de Azure.

Dado que todas las réplicas de disponibilidad deben estar en el mismo clúster de conmutación por error, este debe abarcar ambas redes (un clúster de conmutación por error de varias subredes). Esta configuración requiere una conexión VPN entre Azure y la red local.

Para que se produzca una recuperación ante desastres correcta de las bases de datos, también debe instalar un controlador de dominio de réplica en el sitio de recuperación ante desastres. Para comenzar, revise el tutorial del grupo de disponibilidad.

Instancias de clúster de conmutación por error (alta disponibilidad)

SQL Server en VM de Azure admite instancias de clúster de conmutación por error (FCI) y esta solución proporciona alta disponibilidad a nivel de instancia. Si quiere obtener protección adicional, puede crear redundancia en ambos niveles de base de datos e instancias creando de grupos de disponibilidad además de instancias de clúster de conmutación por error. La característica de FCI requiere almacenamiento compartido y son cinco las soluciones que funcionarán con SQL Server en VM de Azure:

• Uso de discos compartidos de Azure para Windows Server 2019. Los discos administrados compartidos son un producto de Azure que permite conectar un disco administrado a varias máquinas virtuales de manera simultánea. Las VM del clúster pueden leer o escribir en el disco adjunto en función de la reserva elegida por la aplicación en clúster mediante las reservas persistentes de SCSI (SCSI PR). SCSI PR es una solución de almacenamiento estándar del sector que usan las aplicaciones que se ejecutan en el entorno local de una red de área de almacenamiento (SAN). La habilitación de SCSI PR en un disco administrado le permite migrar estas aplicaciones a Azure tal cual.

• Uso de Espacios de almacenamiento directo (S2D) para proporcionar una SAN virtual basada en software para Windows Server 2016 y versiones posteriores.

• Uso de un recurso compartido de archivos Premium para Windows Server 2012 y versiones posteriores. Los recursos compartidos de archivos Premium están respaldados por SSD, tienen una latencia constantemente baja y son completamente compatibles para usarlos con FCI.

• Uso de almacenamiento compatible con una solución de asociado para la agrupación en clústeres. Si quiere ver un ejemplo específico de uso de SIOS DataKeeper, consulte la entrada de blog sobre los clústeres de conmutación por error y SIOS DataKeeper.

• Uso de almacenamiento en bloque compartido para un destino iSCSI remoto a través de Azure ExpressRoute. Por ejemplo, NetApp Private Storage (NPS) expone un destino iSCSI a través de ExpressRoute con Equinix a las máquinas virtuales de Azure.

Para las soluciones de almacenamiento compartido y de replicación de datos de asociados de Microsoft, debe ponerse en contacto con el proveedor en caso de que surja algún problema relacionado con el acceso a los datos en la conmutación por error.

Para comenzar, prepare la VM para la FCI.

Trasvase de registros (DR)

Otra solución de recuperación ante desastres de Azure es el trasvase de registros, el cual permite enviar automáticamente copias de seguridad del registro de transacciones desde una base de datos principal del servidor principal a una o varias bases de datos secundarias de un servidor secundario diferente. La configuración del trasvase de registros utiliza un recurso compartido de archivos de Azure para almacenar las copias de seguridad del registro de transacciones.

Si necesita configurar el trasvase de registros en un entorno híbrido, un servidor se encuentra en una VM de Azure y el otro es local para la recuperación ante desastres entre sitios. El trasvase de registros depende del uso compartido de archivos de Windows, de modo que se requiere una conexión VPN entre la red virtual de Azure y la red local.

Para que se produzca una recuperación ante desastres correcta de las bases de datos, también debe instalar un controlador de dominio de réplica en el sitio de recuperación ante desastres.

Realizar una copia de seguridad y restauración (DR)

La copia de seguridad de las bases de datos de producción es necesaria para la recuperación ante desastres. En Azure, puede realizar una copia de seguridad de las bases de datos directamente en Blob Storage en otro centro de datos para la recuperación ante desastres.

En una solución híbrida, es posible realizar una copia de seguridad de las bases de datos de producción en el entorno local directamente en Azure Blob Storage para la recuperación ante desastres.

Para más información, consulte Copia de seguridad y restauración de SQL Server en Azure Virtual Machines.

Replicación con Azure Site Recovery (DR)

Azure Site Recovery se puede utilizar como solución de recuperación ante desastres en Azure y en una configuración híbrida.

Dentro de Azure, la instancia de SQL Server de producción de un centro de datos de Azure se replica directamente en una instancia de Azure Storage de un centro de datos de Azure distinto para la recuperación ante desastres.

En entornos híbridos, una instancia de SQL Server de producción en entorno local se replica directamente en Azure Storage para la recuperación ante desastres.

Para obtener más información, consulte Proteger SQL Server con la recuperación ante desastres de SQL Server y Azure Site Recovery.

Réplica de DR gratuita en Azure

Si tiene Software Assurance, puede implementar planes de recuperación ante desastres (DR) híbridos con SQL Server sin incurrir en costos de licencias adicionales para la instancia de recuperación ante desastres pasiva. También tiene derecho a réplicas DR sin licencia con licencias de pago por uso si todas las réplicas se hospedan en Azure.

Por ejemplo, puede tener dos instancias secundarias pasivas gratis si las tres réplicas se hospedan en Azure:

O bien, puede configurar un entorno de conmutación por error híbrido, con una instancia principal con licencia, una instancia pasiva para alta disponibilidad, una instancia pasiva gratis para la recuperación ante desastres local y otra instancia pasiva gratis para la recuperación ante desastres en Azure:

Para más información, consulte los términos de licencia del producto.

Para habilitar esta ventaja, vaya al recurso de máquina virtual de SQL Server. Seleccione Configurar en Configuración y, después, elija la opción HA/DR en Licencia de SQL Server. A continuación, seleccione Aplicar para guardar la configuración. Cuando las tres réplicas se hospedan en Azure, los clientes de pago por uso también tienen derecho a usar el tipo de licencia HA/DR.

Consideraciones importantes para HADR de SQL Server en Azure

Las VM de Azure, el almacenamiento y la conexión de red tienen características operativas diferentes de las de una infraestructura TI en entorno local y no virtualizada. Para implementar correctamente una solución HADR de SQL Server en Azure es necesario conocer estas diferencias y diseñar la solución adaptada a ellas.

Nodos de alta disponibilidad en un conjunto de disponibilidad

Los conjuntos de disponibilidad de Azure permiten colocar los nodos de alta disponibilidad en dominios de error y dominios de actualización independientes. La plataforma Azure asigna un dominio de actualización y un dominio de error a cada máquina virtual del conjunto de disponibilidad. Esta configuración en un centro de datos garantiza que, durante un evento de mantenimiento planeado o no planeado, hay al menos una máquina virtual disponible y cumple el contrato de nivel de servicio de Azure al 99,95 %.

Para configurar una alta disponibilidad, coloque todas las máquinas virtuales con SQL Server en el mismo conjunto de disponibilidad para evitar la pérdida de datos o de la aplicación durante un evento de mantenimiento. Tenga en cuenta que solo las máquinas virtuales del mismo servicio en la nube puede participar en el mismo conjunto de disponibilidad. Para más información, consulte Administración de la disponibilidad de las máquinas virtuales.

Nodos de alta disponibilidad en una zona de disponibilidad

Las zonas de disponibilidad son ubicaciones físicas exclusivas dentro de una región de Azure. Cada zona de disponibilidad consta de uno o varios centros de datos equipados con alimentación, refrigeración y redes independientes. La separación física de las zonas de disponibilidad dentro de una región ayuda a proteger las aplicaciones y los datos frente a los errores del centro de datos al garantizar que hay al menos una máquina virtual disponible y cumple el contrato de nivel de servicio de Azure al 99,99 %.

Para configurar la alta disponibilidad, coloque las máquinas virtuales con SQL Server participantes dispersas por las zonas de disponibilidad de la región. Habrá cargos adicionales por las transferencias de red a red entre las zonas de disponibilidad. Para más información, consulte Zonas de disponibilidad.

Latencia de red en TI híbrida

Implemente la solución HADR partiendo de la suposición de que podría haber períodos de tiempo con una alta latencia de red entre la red local y Azure. Al implementar réplicas en Azure, use la confirmación asincrónica en lugar de la confirmación sincrónica para el modo de sincronización. Al implementar servidores de creación de reflejo de la base de datos tanto en el entorno local como en Azure, use el modo de alto rendimiento en lugar del modo de alta seguridad.

Consulte los procedimientos recomendados para la configuración de alta disponibilidad y recuperación ante desastres para ver la configuración del clúster y de HADR que pueden ayudar a adaptarse al entorno en la nube.

Compatibilidad de la replicación geográfica

La replicación geográfica en discos de Azure no admite que el archivo de datos y el archivo de registro de la misma base de datos se almacenen en discos independientes. La GRS replica los cambios en cada disco independiente y asincrónicamente. Este mecanismo garantiza el orden de escritura en un único disco en la copia con replicación geográfica pero no a través de las copias con replicación geográfica de varios discos. Si configura una base de datos para almacenar su archivo de datos y su archivo de registro en discos independientes, los discos recuperados después de un desastre pueden contener una copia más actualizada del archivo de datos que el archivo de registro, lo que interrumpe el registro de escritura previa en SQL Server y las propiedades ACID (atomicidad, coherencia, aislamiento y durabilidad) de las transacciones.

Si no tiene la opción de deshabilitar la replicación geográfica en la cuenta de almacenamiento, conserve todos los archivos de registro y datos de una base de datos en el mismo disco. Si debe usar más de un disco debido al tamaño de la base de datos, implemente una de las soluciones de recuperación de desastres enumeradas anteriormente para garantizar la redundancia de datos.

Pasos siguientes

Decida si la mejor solución de continuidad empresarial para su negocio es un grupo de disponibilidad o una instancia de clúster de conmutación por error. Luego, revise los procedimientos recomendados para configurar el entorno para obtener alta disponibilidad y recuperación ante desastres.