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

Puede tener una solución de alta disponibilidad para sus bases de datos de SQL Server en Windows 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 Windows Azure para la alta disponibilidad en el mismo centro de datos de Windows Azure. Debe configurar un controlador de dominio además de las máquinas virtuales de SQL Server porque el clúster de conmutación por error (WSFC) de Windows Server requiere un dominio de Active Directory. Para obtener más información, vea Tutorial: Grupos de disponibilidad de AlwaysOn en Windows Azure.
Creación de reflejo de base de datos	Los servidores principal, de reflejo y testigo se ejecutan todos en el mismo centro de datos de Windows 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 Windows Azure.

Puede tener una solución de recuperación de desastres para las bases de datos de SQL Server en Windows Azure con creación de reflejo de la base de datos o copias de seguridad y restauración con blobs de almacenamiento.

No puede tener un grupo de disponibilidad solo de Windows Azure a través de centros de datos de Windows Azure porque las redes virtuales a través de centros de datos no se admiten actualmente en Windows Azure y un dominio de Active Directory no puede abarcar varios centros de datos de Windows Azure.

Tecnología	Arquitecturas de ejemplo
Creación de reflejo de base de datos	Los servidores principal, de reflejo y testigo se ejecutan en distintos centros de datos de Windows Azure 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 de Windows Azure. Para obtener más información, vea Tutorial: Creación de reflejo de la base de datos para la recuperación ante desastres en Windows Azure.
Copia de seguridad y restauración con el servicio de almacenamiento de blobs de Windows 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 de Windows 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 Windows 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 Windows Azure.

Tecnología	Arquitecturas de ejemplo
Grupos de disponibilidad AlwaysOn	Algunas réplicas de disponibilidad que se ejecutan en VM de Windows Azure y otras réplicas que se ejecutan en local para la recuperación de desastres a través de sitios. El sitio de producción puede estar en local o en un centro de datos de Windows 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 Windows Azure y la red en 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: Grupos de disponibilidad AlwaysOn en IT híbrida.
Creación de reflejo de base de datos	Un asociado ejecutándose en una VM de Windows Azure y otro en local 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 ejecutándose en una VM de Windows Azure y otro en local 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 Windows Azure y la red en 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 ejecutándose en una VM de Windows Azure y otro en local 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 Windows Azure y la red en 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 Windows Azure	Las bases de datos de producción en local de las que se realizó una copia de seguridad directamente en el almacenamiento de blobs de Windows 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 Windows Azure.

Al implementar una solución de alta disponibilidad en Windows Azure, el conjunto de disponibilidad establecido en Windows Azure permite colocar los nodos de alta disponibilidad en dominios de error diferentes y en dominios de actualización. Como aclaración, el conjunto de disponibilidad es un concepto de Windows Azure. Para obtener más información, vea Administrar la disponibilidad de las máquinas virtuales. Se recomienda asegurarse de que las bases de datos son en realidad de alta disponibilidad, tanto si usa grupos de disponibilidad AlwaysOn, la creación de reflejo de la base de datos u otros. Si no sigue esta recomendación, es posible que suponga falsamente que el sistema tiene una alta disponibilidad pero en realidad los nodos pueden dar error todos simultáneamente porque resulte que estén colocados en el mismo dominio de error en el centro de datos de Windows Azure. Esta recomendación no es tan aplicable al trasvase de registros ya que, como característica de recuperación de desastres, debe asegurarse de que los servidores se ejecutan en ubicaciones independientes del centro de datos de Windows Azure. Estas ubicaciones del centro de datos, por definición, son dominios de error independientes.

Para que las VM de Windows 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.

El servicio DHCP no compatible con RFC en Windows Azure puede hacer que la creación de determinadas configuraciones de clúster WSFC den error, debido al nombre de red en clúster asignó una dirección IP duplicada (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.
   
   

Diferentes configuraciones de clúster WSFC exhiben comportamientos distintos según el modo en que una configuración concreta interactúa con la red y el servicio DHCP de Windows Azure. Puede evitar los comportamientos 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 en clúster para poner en conexión el nombre de red en clúster. Posteriormente, el nombre de red en clúster se puede eliminar porque no los grupos de disponibilidad no la usan. Para simplificar el proceso, vea Configurar el clúster de conmutación por error de Windows en Windows Azure para grupos de disponibilidad AlwaysOn.

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

• Tutorial: Grupos de disponibilidad de AlwaysOn en Windows Azure
  
  
• Tutorial: Grupos de disponibilidad AlwaysOn en IT híbrida
  
  

Windows Azure no admite actualmente más de una dirección IP por cada VM, lo que el agente de escucha del grupo de disponibilidad requiere para resolver el nodo del propietario del grupo de disponibilidad. Aún puede crear el agente de escucha del grupo de disponibilidad pero las aplicaciones cliente no pueden usarlo para conectarse a sus bases de datos de disponibilidad. Sin embargo, todavía puede conectarse 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:

• Usar palabras clave de cadena de conexión con SQL Server Native Client
  
  
• Conectar clientes a una sesión de creación de reflejo de la base de datos (SQL Server)
  
  
• Conexión con el agente de escucha del grupo de disponibilidad en TI híbrida
  
  
• Agentes de escucha del grupo de disponibilidad, conectividad de cliente y conmutación por error de una aplicación (SQL Server)
  
  
• Utilizar cadenas de conexión de creación de reflejo de la base de datos con grupos de disponibilidad
  
  

Debería esperar una mayor latencia de red entre la red en local y Windows Azure, e implementar la solución HADR en consecuencia. Al implementar grupos de disponibilidad AlwaysOn, debe utilizar la confirmación asincrónica en lugar de la confirmación sincrónica para el modo de sincronización entre entornos. Al implementar servidores de creación de reflejo de la base de datos tanto en local como en Windows Azure, use el modo de alto rendimiento en lugar del modo de alta seguridad.

Una recomendación general para ejecutar SQL Server en VM de Windows Azure no es utilizar el disco del sistema operativo (C:) ni el disco temporal (D:). Lo anterior tiene un límite de 127 GB y se configura con almacenamiento en caché de lectura y de escritura de forma predeterminada, lo que puede afectar desfavorablemente al rendimiento del servidor. El último contiene los datos que no persisten después de un reinicio de la VM. Por tanto, la recomendación general es conectar un disco de datos independientes sin almacenamiento en caché de lectura ni de escritura y usarlo para los archivos de base de datos. Conectar discos independientes también le permite personalizar la capacidad de disco en hasta 1 terabyte.

Si tiene que almacenar archivos de base de datos en el disco del sistema operativo, se recomienda deshabilitar el almacenamiento en caché de escritura al aprovisionar la máquina virtual. No puede deshabilitar la memoria caché de lectura en el disco del sistema operativo.

La georreplicación en discos de Windows 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.