Continuidad empresarial y HADR para SQL Server en Azure Virtual Machines

Se aplica a:SQL Server en VM de Azure

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).

La mayoría de las soluciones HADR de SQL Server son compatibles con las máquinas virtuales, bien como soluciones exclusivas de Azure o como soluciones híbridas. En una solución exclusiva de Azure, todo el sistema HADR se ejecuta en Azure. En una 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.

En este artículo se comparan y contrastan las soluciones de continuidad empresarial que hay disponibles para SQL Server en máquinas virtuales de Azure.

Información general

Depende de usted el garantizar que su sistema de base de datos tiene las funcionalidades de HADR que exige el contrato de nivel de servicio (SLA). El hecho de que Azure proporcione mecanismos de alta disponibilidad, como la recuperación del servicio en los servicios en la nube y la detección de recuperación de errores para las máquinas virtuales, no garantiza por sí solo que pueda cumplir con el contrato de nivel de servicio. 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.

El almacenamiento con redundancia geográfica (GRS) de Azure se implementa con una característica denominada replicación geográfica. Es posible que GRS no sea una solución de recuperación ante desastres adecuada para sus bases de datos. Dado que la replicación geográfica envía los datos de forma asincrónica, las actualizaciones recientes se pueden perder en caso de desastre. Encontrará más información sobre las limitaciones de la replicación geográfica en la sección Compatibilidad de la replicación geográfica.

Arquitecturas de implementación

Azure admite estas tecnologías de SQL Server para la continuidad empresarial:

• Grupos de disponibilidad Always On
• Instancias de clúster de conmutación por error (FCI) de Always On
• Trasvase de registros
• Copia de seguridad y restauración de SQL Server con Azure Blob Storage
• Creación de reflejo de la base de datos: en desuso en SQL Server 2016
• Azure Site Recovery

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. En las secciones siguientes se muestran algunas arquitecturas de implementación de ejemplo.

Solo Azure: soluciones de alta disponibilidad

Puede tener una solución de alta disponibilidad para SQL Server en un nivel de base de datos con grupos de disponibilidad Always On. También puede crear una solución de alta disponibilidad en un nivel de instancia con instancias de clúster de conmutación por error Always On. Si quiere obtener protección adicional, puede crear redundancia en ambos niveles creando de grupos de disponibilidad en instancias de clúster de conmutación por error.

Technology	Arquitecturas de ejemplo
Grupos de disponibilidad	Todas las réplicas de disponibilidad que se ejecutan en Azure Virtual Machines de la misma región proporcionan alta disponibilidad. Debe configurar una máquina virtual de controlador de dominio, ya que los clústeres de conmutación por error de Windows requieren un dominio de Active Directory. Para una mayor redundancia y disponibilidad, las máquinas virtuales de Azure se pueden implementar en zonas de disponibilidad distintas, tal como se documenta en la información general sobre los grupos de disponibilidad. Para comenzar, revise el tutorial del grupo de disponibilidad.
Instancias de clúster de conmutación por error	Las instancias de clúster de conmutación por error son compatibles con VM con SQL Server. Como la característica de FCI requiere almacenamiento compartido, son cinco las soluciones que funcionarán con SQL Server en VM de Azure: - El 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. - El uso de Espacios de almacenamiento directo (S2D) para proporcionar una SAN virtual basada en software para Windows Server 2016 y versiones posteriores. - El 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. - El 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. - El 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, póngase en contacto con el proveedor en caso de que surja cualquier problema relacionado con el acceso a datos en la conmutación por error. Para comenzar, prepare la VM para la FCI.

Solo Azure: Soluciones de recuperación ante desastres

Puede tener una solución de recuperación ante desastres para las bases de datos de SQL Server en Azure mediante el uso de grupos de disponibilidad, creación de reflejo de bases de datos o copias de seguridad y restauración con blobs de almacenamiento.

Technology	Arquitecturas de ejemplo
Grupos de disponibilidad	Réplicas de disponibilidad que se ejecutan en varios centros de datos en máquinas virtuales de Azure para la recuperación ante desastres. Esta 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 tendrá una red virtual 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.
Creación de reflejo de la base de datos	Los servidores principal y de reflejo se ejecutan en distintos centros de datos para la recuperación ante desastres. Debe implementarlos con certificados de servidor.
Copia de seguridad y restauración con Azure Blob Storage	Las bases de datos de producción de las que se realizó una copia de seguridad directamente en Blob Storage en otro centro de datos para la recuperación ante desastres. Para más información, consulte Copia de seguridad y restauración de SQL Server en VM de Azure.
Replicación y conmutación por error de SQL Server en Azure con Azure Site Recovery	La instancia de SQL Server de producción de un centro de datos de Azure replicado directamente en una instancia de Azure Storage de un centro de datos de Azure distinto 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.

TI híbrida: Soluciones de recuperación ante desastres

Puede tener una solución de recuperación ante desastres para las bases de datos de SQL Server en un entorno de TI híbrida mediante grupos de disponibilidad, creación de reflejo de base de datos, trasvase de registros y copia de seguridad y restauración con Azure Blob Storage.

Technology	Arquitecturas de ejemplo
Grupos de disponibilidad	Algunas réplicas de disponibilidad se ejecutan en máquinas virtuales de Azure y 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.
Creación de reflejo de la base de datos	Un asociado se ejecuta en una máquina virtual de Azure y otro en el entorno local para la recuperación ante desastres entre sitios mediante el uso de certificados de servidor. Los asociados no necesitan estar en el mismo dominio de Active Directory y no se requiere ninguna conexión VPN. Otro escenario de creación de reflejo de la base de datos implica a un asociado que se ejecuta en una máquina virtual de Azure y los demás que se ejecutan localmente en el mismo dominio de Active Directory para la recuperación ante desastres entre sitios. 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.
Trasvase de registros	Un servidor se ejecuta en una máquina virtual de Azure y otro localmente para la recuperación ante desastres a través de 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.
Copia de seguridad y restauración con Azure Blob Storage	Bases de datos de producción locales con copia de seguridad directa 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 y conmutación por error de SQL Server en Azure con Azure Site Recovery	Instancia de SQL Server de producción local replicada directamente en una instancia de 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. Active la casilla para confirmar que esta VM con SQL Server se usará como una réplica pasiva y, 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 máquinas virtuales de Azure, el almacenamiento y la conexión de red tienen características operativas diferentes de las de una infraestructura TI 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.