Editar

Aplicación web de varios niveles creada para alta disponibilidad y recuperación ante desastres

Azure
Azure Arc
SQL Server
Windows

Este escenario de ejemplo es aplicable a cualquier sector que necesite implementar aplicaciones resistentes de varios niveles creadas para obtener una alta disponibilidad y recuperación ante desastres. En este escenario, la aplicación consta de tres niveles.

  • Capa web: el nivel superior que incluye la interfaz de usuario. Este nivel analiza las interacciones del usuario y pasa las acciones al siguiente nivel para su procesamiento.
  • Capa de negocio: procesa las interacciones de usuario y toma decisiones lógicas sobre los pasos siguientes. Este nivel conecta el nivel web con el nivel de datos.
  • Capa de datos: almacena los datos de la aplicación. Normalmente se usa una base de datos, un almacenamiento de objetos o un almacenamiento de archivos.

Entre los escenarios de aplicación se incluye cualquier aplicación crítica que se ejecute en Windows o Linux. Puede tratarse de una aplicación estandarizada, como SAP y SharePoint o una aplicación de línea de negocio personalizada.

Posibles casos de uso

Otros casos de uso pertinentes incluyen:

  • Implementación de aplicaciones altamente resistentes, como SAP y SharePoint
  • Diseño de un plan de continuidad empresarial y recuperación ante desastres para aplicaciones de línea de negocio
  • Configuración de la recuperación ante desastres y realización de maniobras relacionadas con fines de cumplimiento normativo

Architecture

Diagram showing the architecture overview of a highly resilient multitier web application.

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

  • Distribuya las máquinas virtuales de cada nivel en dos zonas de disponibilidad de regiones que admitan zonas. En otras regiones, implemente las máquinas virtuales de cada nivel dentro de un conjunto de disponibilidad.
  • El nivel de base de datos se puede configurar para usar grupos de disponibilidad Always On. Con esta configuración de SQL Server, una réplica de lectura y escritura principal de un grupo de disponibilidad está configurada con un máximo de ocho réplicas secundarias de solo lectura. Si se produce un problema con la réplica principal, se realiza la conmutación por error de la actividad de lectura y escritura principal en una de las réplicas secundarias, lo que permite que la aplicación no deje de estar disponible en ningún momento. Para más información, consulte Información general de los grupos de disponibilidad AlwaysOn (SQL Server).
  • Para escenarios de recuperación ante desastres, puede configurar la replicación nativa asincrónica Always On de SQL en la región de destino que se usa para la recuperación ante desastres. También puede configurar la replicación de Azure Site Recovery en la región de destino si la frecuencia de cambio de datos está dentro de los límites que admite Azure Site Recovery.
  • Los usuarios acceden al nivel web de ASP.NET de front-end a través del punto de conexión de Traffic Manager.
  • Traffic Manager redirige el tráfico al punto de conexión de la dirección IP pública principal de la región de origen primaria.
  • La dirección IP pública redirige la llamada a una de las instancias de máquina virtual del nivel web a través de un equilibrador de carga público. Todas las instancias de máquina virtual de nivel web están en una subred.
  • Desde la máquina virtual del nivel web, cada llamada se enruta a una de las instancias de máquina virtual del nivel empresarial mediante un equilibrador de carga interno para su procesamiento. Todas las máquinas virtuales de nivel empresarial están en una subred independiente.
  • La operación se procesa en el nivel empresarial y la aplicación ASP.NET se conecta al clúster de Microsoft SQL Server en un nivel de back-end a través de un equilibrador de carga interno de Azure. Estas instancias de SQL Server de back-end están en una subred independiente.
  • El punto de conexión secundario de Traffic Manager se configura como la dirección IP pública en la región de destino que se usa para la recuperación ante desastres.
  • Si se produce una interrupción en la región primaria, puede invocar la conmutación por error de Azure Site Recovery y la aplicación se activará en la región de destino.
  • El punto de conexión de Traffic Manager redirige automáticamente el tráfico de cliente a la dirección IP pública en la región de destino.

Componentes

  • Los conjuntos de disponibilidad garantizan que las máquinas virtuales implementadas en Azure se distribuyan entre varios nodos de hardware aislados en un clúster. Si se produce un error de hardware o software en Azure, solo un subconjunto de las máquinas virtuales se verá afectado y toda la solución seguirá disponible y en funcionamiento.
  • Las zonas de disponibilidad protegen las aplicaciones y los datos de errores del centro de datos. Las zonas de disponibilidad son ubicaciones físicas independientes 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.
  • Azure Site Recovery le permite replicar las máquinas virtuales en otra región de Azure para satisfacer sus necesidades de continuidad empresarial y recuperación ante desastres. Puede realizar pruebas de recuperación ante desastres periódicas para asegurarse de que satisface los requisitos de cumplimiento. La máquina virtual se replicará en la región seleccionada con la configuración que especifique, de forma que podrá recuperar las aplicaciones en caso de interrupciones del servicio en la región de origen.
  • Azure Traffic Manager es un equilibrador de carga de tráfico basado en DNS que distribuye el tráfico de forma óptima a servicios de regiones de Azure globales, al tiempo que proporciona una alta disponibilidad y capacidad de respuesta.
  • Azure Load Balancer distribuye el tráfico entrante según reglas y sondeos de estado definidos. Una instancia de Load Balancer proporciona baja latencia y alto rendimiento, y puede escalar hasta millones de flujos para todas las aplicaciones TCP y UDP. Se utiliza un equilibrador de carga público en este escenario para distribuir el tráfico entrante del cliente en el nivel web. Se usa un equilibrador de carga interno en este escenario para distribuir el tráfico desde el nivel empresarial al clúster de SQL Server de back-end.

Alternativas

  • Windows se puede reemplazar fácilmente por otros sistemas operativos ya que nada en la infraestructura depende del sistema operativo.
  • SQL Server para Linux puede reemplazar el almacén de datos de back-end.
  • La base de datos puede sustituirse por cualquier aplicación estándar de base de datos disponible.

Detalles del escenario

Este escenario muestra una aplicación de varios niveles que usa ASP.NET y Microsoft SQL Server. En las regiones de Azure que admiten zonas de disponibilidad puede implementar las máquinas virtuales (VM) en una región de origen en distintas zonas de disponibilidad y replicarlas en la región de destino que se usa para la recuperación ante desastres. En las regiones de Azure que no admiten zonas de disponibilidad, puede implementar las máquinas virtuales dentro de un conjunto de disponibilidad y replicarlas en la región de destino.

Para enrutar el tráfico entre regiones, necesita un equilibrador de carga global. Hay dos ofertas principales de Azure:

  • Azure Front Door
  • Azure Traffic Manager

Al elegir un equilibrador de carga, tenga en cuenta sus requisitos y el conjunto de características de las dos ofertas. ¿Con qué rapidez desea realizar la conmutación por error? ¿Puede asumir la sobrecarga de la administración de TLS? ¿Existen restricciones de costos organizativos?

Front Door presenta funcionalidades de nivel 7: descarga SSL, enrutamiento basado en rutas, conmutación por error rápida, almacenamiento en caché, y otros, que mejoran el rendimiento y la alta disponibilidad de las aplicaciones. Es posible que experimente tiempos de desplazamiento de paquetes más rápidos porque la infraestructura se incorpora antes a la red de Azure.

Como Front Door agrega un nuevo salto, se agregan operaciones de seguridad. Si la arquitectura cumple los requisitos normativos, puede haber restricciones sobre el punto de terminación TLS de tráfico adicional. Los conjuntos de cifrado TLS seleccionados por Front Door deben cumplir la barra de seguridad de su organización. Además, Front Door espera que los servicios de back-end utilicen certificados usados por Microsoft.

Otra consideración importante es el costo. La arquitectura debe sacar partido del amplio conjunto de características (no solo de la conmutación por error) para justificar el costo agregado.

Azure Traffic Manager es un servicio global de equilibrio de carga basado en DNS. Equilibra y conmuta por error solo en el nivel DNS. Por ese motivo, no puede conmutar por error tan rápidamente como con Front Door, debido a los desafíos comunes relacionados con el almacenamiento en caché de DNS y a los sistemas que no respetan los TTL de DNS.

Si es necesario, puede combinar ambos equilibradores de carga. Por ejemplo, quiere la conmutación por error basada en DNS, pero también quiere agregar una experiencia POP delante de esa infraestructura administrada por tráfico.

Esta arquitectura usa Traffic Manager porque es ligero. El tiempo de conmutación por error es suficiente para fines ilustrativos.

Consideraciones

Escalabilidad

Puede agregar o quitar máquinas virtuales en cada nivel según sus requisitos de escalado. Dado que este escenario utiliza equilibradores de carga, puede agregar más máquinas virtuales a un nivel sin que afecte al tiempo de actividad de la aplicación.

Para ver otros temas sobre escalabilidad, consulte la lista de comprobación de eficiencia del rendimiento que encontrará en el Centro de arquitectura de Azure.

Seguridad

Los grupos de seguridad de red protegen todo el tráfico de la red virtual hacia la capa de aplicación de front-end. Las reglas limitan el flujo de tráfico de forma que solo las instancias de máquinas virtuales de la capa de aplicación de front-end pueden acceder al nivel de la base de datos de back-end. No se permite ningún tráfico de Internet saliente procedente del nivel empresarial o el nivel de base de datos. Para reducir la superficie de ataque, no hay ningún puerto de administración remota directa abierto. Para más información, consulte Grupos de seguridad de red de Azure.

Para obtener instrucciones generales sobre el diseño de escenarios seguros, consulte la documentación de seguridad de Azure.

Precios

La configuración de la recuperación ante desastres para las máquinas virtuales de Azure mediante Azure Site Recovery hará que se incurra en los siguientes gastos de forma continuada.

  • Costo de las licencias de Azure Site Recovery por máquina virtual.
  • Costos de salida de red para replicar los cambios de datos de los discos de máquina virtual de origen en otra región de Azure. Azure Site Recovery utiliza la compresión integrada para reducir los requisitos de transferencia de datos en un 50 % aproximadamente.
  • Costos de almacenamiento en el sitio de recuperación. Estos suelen ser iguales a los del almacenamiento en la región de origen más el almacenamiento adicional necesario para mantener los puntos de recuperación como instantáneas para la recuperación.

Se ha proporcionado una calculadora de costos de ejemplo para configurar la recuperación ante desastres de una aplicación de tres niveles que usa seis máquinas virtuales. Se han preconfigurado todos los servicios en la calculadora de costos. Para ver cómo cambiarían los precios en su caso concreto, cambie las variables adecuadas para estimar el costo.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Pasos siguientes

Para obtener arquitecturas de referencia de alta disponibilidad y recuperación ante desastres adicionales, consulte: