VENTAS: 1-800-867-1389

Alta disponibilidad y recuperación ante desastres para SQL Server en máquinas virtuales de Azure

Actualizado: junio de 2014

Las máquinas virtuales (VM) de Microsoft Azure con SQL Server pueden ayudar a reducir el coste de una solución de alta disponibilidad y recuperación de desastres (HADR). La mayor parte de las soluciones HADR SQL Server son compatibles con las máquinas virtuales de Azure, bien como soluciones exclusivas de Azure o híbridas. En una solución exclusiva de Azure, todo el sistema HADR se ejecuta en Azure. En las configuraciones híbridas, 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 le 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.

Depende de usted el garantizar que su sistema de base de datos cuenta con las capacidades 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 errores para las máquinas virtuales, no garantiza por sí solo que pueda cumplir con el SLA. Estos mecanismos protegen la alta disponibilidad de las VM, pero no la alta disponibilidad de SQL Server que se ejecutan en ellas. Es posible que la instancia de SQL Server no funcione a pesar de que la VM esté en línea y en buen estado. Además, incluso con los mecanismos de alta disponibilidad proporcionados por Azure, es posible que se produzcan tiempos de inactividad de las VM debidos a eventos como la recuperación errores de software o hardware o las actualizaciones del sistema operativo.

Además, el almacenamiento con redundancia geográfica (GRS) de Azure, que se implementa con una característica llamada replicación geográfica, podría no ser una solución para recuperación de 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. En la sección La georreplicación no se admite para los archivos de datos y de registro en discos independientes se ofrece más información relativa a las limitaciones de la replicación geográfica.

Entre las tecnologías HADR SQL Server compatibles con Azure se incluyen:

Es posible combinar las tecnologías para implementar una solución SQL Server que posea alta disponibilidad y, al mismo tiempo, capacidades de recuperación de desastres. Según la tecnología que se utilice, una implementación híbrida puede requerir un túnel VPN con la red virtual de Azure. Las secciones siguientes muestran algunas de las arquitecturas de implementación de ejemplo.

Puede tener una solución de alta disponibilidad para sus bases de datos SQL Server en Azure con grupos de disponibilidad AlwaysOn o creación de reflejo de la base de datos.

 

Tecnología Arquitecturas de ejemplo

Grupos de disponibilidad AlwaysOn

Todas las réplicas de disponibilidad que se ejecutan en VM de Azure para lograr alta disponibilidad en la misma región. Debe configurar un controlador de dominio además de las máquinas virtuales de SQL Server porque los clústeres de conmutación por error de Windows Server (WSFC) requieren un dominio de Active Directory.

Para obtener más información, vea Tutorial: Grupos de disponibilidad de AlwaysOn en Azure (GUI).

Creación de reflejo de la base de datos

Los servidores principal, de reflejo y testigo se ejecutan todos en el mismo centro de datos de Azure para lograr una alta disponibilidad. Puede realizar la implementación con un controlador de dominio.

También puede implementar la misma configuración de creación de reflejo de la base de datos sin un controlador de dominio con certificados de servidor en su lugar.

Para obtener más información, vea Tutorial: Creación de reflejo de la base de datos para alta disponibilidad en Azure.

Puede tener una solución de recuperación de desastres para las bases de datos de SQL Server en Azure con grupos de disponibilidad AlwaysOn, reflejos de bases de datos o copias de seguridad y restauración con blobs de almacenamiento.

 

Tecnología Arquitecturas de ejemplo

Grupos de disponibilidad AlwaysOn

Réplicas de disponibilidad que se ejecutan en varios centros de datos en VM Azure para recuperación de desastres. Esta solución en varias regiones protege frente a interrupciones completas de los sitios.

Dentro de una región, todas las réplicas deben hallarse en el mismo servicio en la nube y la misma red virtual. Dado que cada región tendrá una red virtual distinta, estas soluciones precisan de conectividad entre estas redes. Para obtener más información, vea Configurar la conectividad de VNet a VNet.

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 de desastres. Debe realizar la implementación con certificados de servidor porque un dominio de Active Directory no puede abarcar varios centros de datos.

Para obtener más información, vea Tutorial: Creación de reflejo de la base de datos para la recuperación ante desastres en Azure.

Copia de seguridad y restauración con el servicio de almacenamiento de blobs de Azure

Las bases de datos de producción de las que se realizó una copia de seguridad directamente en el almacenamiento de blobs en otro centro de datos para la recuperación de desastres.

Para obtener más información, vea Copias de seguridad y restauración para SQL Server en máquinas virtuales de Azure.

Puede tener una solución de recuperación de desastres para las bases de datos de SQL Server en un entorno TI híbrido con grupos de disponibilidad AlwaysOn, creación de reflejo de la base de datos, trasvase de registros y copias de seguridad y restauración con almacenamiento de blobs de Azure.

 

Tecnología Arquitecturas de ejemplo

Grupos de disponibilidad AlwaysOn

Algunas réplicas de disponibilidad se ejecutan en VM de Azure y otras réplicas se ejecutan localmente para la recuperación de 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 WSFC, este debe abarcar ambas redes (un clúster WSFC de varias subredes). Esta configuración requiere una conexión VPN entre Azure y la red local.

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

Para obtener más información, vea Tutorial: AlwaysOn Availability Groups in Hybrid IT.

Creación de reflejo de la base de datos

  • Un asociado se ejecuta en una VM de Azure y otro localmente para la recuperación de desastres a través de sitios con certificados de servidor. Los asociados no necesitan estar en el mismo dominio de Active Directory y no se requiere ninguna conexión VPN.



    Para obtener más información, vea Tutorial: Creación de reflejo de la base de datos para la recuperación ante desastres en entornos informáticos híbridos.

  • Un asociado se ejecuta en una VM de Azure y otro localmente en el mismo dominio de Active Directory para la recuperación de desastres a través de sitios. Se requiere una conexión VPN entre la red virtual de Azure y la red local.

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

Trasvase de registros

Un servidor se ejecuta en una VM de Azure y otro localmente para la recuperación de 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 de desastres correcta de las bases de datos, también debe instalar un controlador de dominio de réplica en el sitio de recuperación de desastres.

Para obtener más información, vea Tutorial: Trasvase de registros para la recuperación ante desastres en entornos informáticos híbridos.

Copia de seguridad y restauración con el servicio de almacenamiento de blobs de Azure

Bases de datos de producción locales con copia de seguridad directa en el almacenamiento de blobs de Azure para la recuperación de desastres.

Para obtener más información, vea Copias de seguridad y restauración para SQL Server en máquinas virtuales de Azure.

Las VM 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 de SQL Server HADR en Azure es necesario conoce estas diferencias y diseñar la solución para tenerlas en cuenta.

Los conjuntos de disponibilidad de Azure le permiten colocar los nodos de alta disponibilidad en dominios de error (FD) y dominios de actualización (UD) distintos. Para que las VM de Azure se coloquen en el mismo conjunto de disponibilidad, debe implementarlas en el mismo servicio en la nube. Solo los nodos del mismo servicio en la nube pueden participar en el mismo conjunto de disponibilidad. Para obtener más información, vea Administrar la disponibilidad de las máquinas virtuales.

El servicio DHCP no compatible con RFC en Azure puede hacer que la creación de determinadas configuraciones de clúster WSFC produzcan errores al asignarle una dirección IP duplicada al nombre de red del clúster como, por ejemplo, la misma dirección IP que una de los nodos de clúster. Se trata de un problema al implementar grupos de disponibilidad AlwaysOn que depende de la característica WSFC.

Considere un escenario en el que se crea un clúster de dos nodos y se pone en conexión:

  1. El clúster se pone en conexión, NODE1 solicita una dirección IP asignada dinámicamente para el nombre de red en clúster.

  2. El servicio DHCP no otorga ninguna dirección IP a excepción de la propia de NODE1, ya que el servicio DHCP reconoce que la solicitud procede del propio NODE1.

  3. Windows detecta que se asigna una dirección duplicada tanto a NODE1 como al nombre de red en clúster y el grupo de clústeres predeterminado no puede ponerse en conexión.

  4. El grupo de clústeres predeterminado se pasa a NODE2, que trata la dirección IP de NODE1 como la dirección IP del clúster y pone en conexión el grupo de clústeres predeterminado.

  5. Cuando NODE2 intenta establecer conectividad con NODE1, los paquetes dirigidos a NODE1 nunca abandonan NODE2 porque resuelve la dirección IP de NODE1 en sí mismo. NODE2 no puede establecer conectividad con NODE1, pierde el cuórum y cierra el clúster.

  6. Mientras tanto, NODE1 puede enviar paquetes a NODE2 pero NODE2 no puede responder. NODE1 pierde el cuórum y cierra el clúster.

Puede evitar esta situación asignando una dirección IP estática no utilizada, por ejemplo una dirección IP de vínculo local como 169.254.1.1, al nombre de red del clúster a fin de poner en conexión dicho nombre. Para simplificar el proceso, vea Configurar el clúster de conmutación por error de Windows en Azure para grupos de disponibilidad AlwaysOn.

Los siguientes tutoriales para los grupos de disponibilidad AlwaysOn muestran cómo configurar un grupo de disponibilidad en diferentes escenarios.

Los agentes de escucha de los grupos de disponibilidad son compatibles con las VM de Azure que ejecutan Windows Server 2008 R2, Windows Server 2012 y Windows Server 2012 R2. Esta compatibilidad es posible mediante el uso de extremos de carga equilibrada en las VM de Azure que tengan habilitado Direct Server Return (DSR) y sean nodos de grupo de disponibilidad. Debe seguir pasos de configuración especiales para que los agentes de escucha funcionen tanto con las aplicaciones de cliente que se ejecutan en Azure como con las que se ejecutan localmente. Para obtener instrucciones sobre la forma de configurar un agente de escucha, vea Tutorial: Configuración del agente de escucha de los Grupos de disponibilidad AlwaysOn.

Puede seguir conectándose a cada réplica de disponibilidad por separado conectándose directamente a la instancia del servicio. Además, puesto que los grupos de disponibilidad AlwaysOn son compatibles con las versiones anteriores de los clientes de creación de reflejo de la base de datos, puede conectarse a las réplicas de disponibilidad como asociados de creación de reflejo de la base de datos siempre y cuando las réplicas estén configuradas de forma similar a la creación de reflejo de la base de datos:

  • Una réplica principal y una réplica secundaria

  • La réplica secundaria está configurada como no legible (la opción Secundaria legible está establecida en No)

A continuación se muestra una cadena de conexión de cliente de ejemplo correspondiente a esta configuración similar a la creación de reflejo de la base de datos que usa ADO.NET o SQL Server Native Client:

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

Para obtener más información sobre la conectividad del cliente, vea:

Es recomendable que implemente la solución HADR partiendo de la suposición de que podría haber periodos de tiempo con una alta latencia de red entre la red local y Azure. Al implementar réplicas en Azure, debe utilizar 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 local como en Azure, use el modo de alto rendimiento en lugar del modo de alta seguridad.

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 georreplicada pero no a través de las copias georreplicadas 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 de las transacciones. Si no tiene la opción de deshabilitar la georreplicación en la cuenta de almacenamiento, debe conservar todos los archivos de datos y de registro de una base de datos dada en el mismo disco. Si debe utilizar más de un disco debido al tamaño de la base de datos, debe implementar una de las soluciones de recuperación de desastres enumeradas anteriormente para garantizar la redundancia de datos.

Vea también

¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios
Mostrar:
© 2014 Microsoft