Microsoft Azure Availability Zones son ubicaciones físicas independientes dentro de una región de Azure, cada una con uno o varios centros de datos que tienen alimentación, refrigeración y redes independientes. La separación física de las zonas de disponibilidad dentro de una región limita el efecto de los errores de zona en las aplicaciones y los datos. La arquitectura de referencia presentada en este artículo muestra los procedimientos recomendados para una implementación zonal, una implementación que usa Availability Zones para aumentar la disponibilidad de la aplicación. Una implementación zonal es adecuada para muchos tipos de aplicaciones. El ejemplo concreto que se muestra aquí es la implementación zonal de una aplicación web que se ejecuta en máquinas virtuales (VM) y usa base de datos Microsoft SQL Server.
Este enfoque se usa en escenarios de alta disponibilidad donde la resistencia es muy importante. Con la arquitectura de alta disponibilidad, existe un equilibrio entre alta resistencia, baja latencia y costo. Esta arquitectura utiliza recursos redundantes distribuidos entre zonas para proporcionar una alta resistencia. El tráfico se puede enrutar entre las zonas para minimizar el impacto de un error de zona. Si se produce un error en una zona, los recursos de otras zonas absorben el tráfico hasta que se recupera la zona con error. Esto proporciona un alto nivel de resistencia.
Esta arquitectura proporciona un uso eficaz de los recursos ya que la mayoría de ellos se usan activamente. Todos los recursos, excepto la instancia pasiva de SQL Server, se utilizan para controlar las solicitudes. La instancia pasiva de SQL Server se activa solo si se produce un error en la instancia activa de SQL Server.
Azure Application Gateway y el equilibrador de carga, ambos con redundancia de zona, distribuyen el tráfico a los recursos disponibles.
Descargue un archivo Visio de esta arquitectura.
Architecture
La arquitectura utiliza recursos distribuidos en varias zonas para proporcionar alta disponibilidad a una infraestructura como servicio (IaaS) que usa una base de datos de SQL Server. Application Gateway con redundancia de zona enruta el tráfico a las máquinas virtuales del nivel web. Un equilibrador de carga con redundancia de zona enruta el tráfico de las máquinas virtuales del nivel web a la instancia activa de SQL Server. En caso de un error de zona, Application Gateway se enruta a las máquinas virtuales de otras zonas disponibles. El enrutamiento entre zonas tiene una latencia mayor que el enrutamiento dentro de la zona.
Si la instancia activa de SQL Server deja de estar disponible, ya sea debido a un error de zona o a un error local, una instancia pasiva de SQL Server pasará a estar activa. El equilibrador de carga con redundancia de zona detectará la conmutación por error de la nueva instancia activa de SQL Server y le enrutará el tráfico.
A continuación se muestra un error de la Zona 1.
Descargue un archivo Visio de esta arquitectura.
Application Gateway tiene redundancia de zona. No se ve afectado por el error de la Zona 1 y usa sondeos de estado para determinar las máquinas virtuales disponibles. Con la Zona 1 no disponible, solo enruta el tráfico a las dos zonas restantes. El equilibrador de carga con redundancia de zona tampoco se ve afectado por el error de la Zona 1 y usa sondeos de estado para determinar la ubicación de la instancia activa de SQL Server. En este ejemplo, el equilibrador de carga detecta que la instancia activa de SQL Server está en la Zona 3 y, a continuación, le enruta el tráfico.
La distribución de recursos entre zonas de disponibilidad también protege una aplicación frente al mantenimiento planeado. Cuando las máquinas virtuales se distribuyen en tres Availability Zones, de hecho, se distribuyen entre tres dominios de actualización. La plataforma Azure reconoce esta distribución entre dominios de actualización para asegurarse de que las máquinas virtuales de distintas zonas no se actualizan al mismo tiempo.
Al replicar las máquinas virtuales en Availability Zones, puede proteger sus aplicaciones y datos de un error de zona. Así es como Azure cumple el Acuerdo de Nivel de Servicio (SLA) de tiempo de actividad de la máquina virtual más adecuado para el 99,99 % del sector. Consulte Compilación de soluciones para alta disponibilidad mediante Availability Zones.
La arquitectura tiene los siguientes componentes.
General
Grupos de recursos. Los grupos de recursos se utilizan para agrupar los recursos de Azure con el fin de que puedan administrarse según su duración, su propietario u otros criterios.
Azure Availability Zones. Availability Zones son ubicaciones físicas independientes dentro de una región de Azure, cada una con uno o varios centros de datos que tienen alimentación, refrigeración y redes independientes. Si se colocan las máquinas virtuales a través de zonas, la aplicación se vuelve resistente a los errores dentro de una zona.
Redes y equilibrio de carga
- Red virtual y subredes. Todas las máquinas virtuales se implementan en una red virtual que se puede dividir en subredes, una para cada nivel.
- Application Gateway. Azure Application Gateway es un equilibrador de carga de nivel 7. En esta arquitectura, una instancia de Application Gateway con redundancia de zona enruta las solicitudes HTTP al front-end web. Application Gateway proporciona también un firewall de aplicaciones web que protege la aplicación contra puntos vulnerables de la seguridad comunes. La versión v2 de la SKU de Application Gateway admite la redundancia entre zonas. Una sola implementación de Application Gateway puede ejecutar varias instancias de la puerta de enlace. En el caso de cargas de trabajo de producción, ejecute al menos dos. Para más información, consulte Escalabilidad automática y Application Gateway con redundancia de zona v2 y ¿Cómo admite Application Gateway la alta disponibilidad y la escalabilidad?
- Azure Load Balancer. Azure Load Balancer es un equilibrador de carga de capa 4. En esta arquitectura, una instancia de Azure Standard Load Balancer dirige el tráfico de red desde el nivel web a SQL Server. Como un equilibrador la carga con redundancia de zona no está anclado a una zona específica, la aplicación seguirá distribuyendo el tráfico de red en caso de que se produzca un error de zona. Se usa un equilibrador de carga con redundancia de zona para proporcionar disponibilidad en caso de que el servidor SQL Server activo deje de estar disponible. La SKU estándar de Azure Load Balancer admite la redundancia entre zonas. Para más información, consulte Standard Load Balancer y Availability Zones.
- Grupos de seguridad de red (NSG) . Un grupo de seguridad de red se usa para restringir el tráfico de red dentro de la red virtual. En esta arquitectura, el nivel web solo acepta tráfico desde el punto de conexión de la dirección IP pública. Además, el nivel de base de datos no acepta tráfico de ninguna subred que no sea la subred del nivel web.
- DDoS Protection. La plataforma Azure proporciona protección frente a los ataques de denegación de servicio distribuido (DDoS). Para obtener protección adicional, se recomienda usar Azure DDoS Protection estándar, que tiene características mejoradas de mitigación de ataques de DDoS. Consulte Consideraciones sobre la seguridad.
- Azure Bastion. Azure Bastion proporciona acceso de protocolo de escritorio remoto y Secure Shell seguro y sin interrupción a las máquinas virtuales de la red virtual. Esto proporciona acceso al limitar las direcciones IP públicas expuestas de las máquinas virtuales en la red virtual. Azure Bastion proporciona una alternativa rentable a una máquina virtual aprovisionada para proporcionar acceso a todas las máquinas virtuales de la misma red virtual.
Microsoft SQL Server
Grupos de disponibilidad Always On de SQL Server. Un grupo de disponibilidad Always On de SQL Server proporciona alta disponibilidad en el nivel de datos, al habilitar la replicación y la conmutación por error. Usa la tecnología de clúster de conmutación por error de Windows Server (WSFC) para la conmutación por error.
Testigo en la nube. Un clúster de conmutación por error requiere que se ejecute más de la mitad de sus nodos, una condición conocida como cuórum. Si el clúster tiene solo dos nodos, una partición de la red podría provocar que cada uno de ellos creyera que es el principal. En ese caso, se necesita un testigo que sea quien dilucide cuál es el principal y establezca el cuórum. Un testigo es un recurso, como por ejemplo un disco compartido, que puede actuar como dilucidador para establecer el cuórum. Un testigo en la nube es un tipo de testigo que usa Azure Blob Storage. Azure Blob Storage debe usar el almacenamiento con redundancia de zona para que no se vea afectado por un error de zona.
Para más información acerca del concepto de quórum, consulte Descripción del cuórum de clúster y de grupo. Para más información acerca del testigo en la nube, consulte Implementación de un testigo en la nube en un clúster de conmutación por error.
Recomendaciones
Los requisitos pueden diferir de los de la arquitectura que se describe aquí. Use estas recomendaciones como punto de partida.
Para recomendaciones sobre cómo configurar las máquinas virtuales, consulte Ejecución de una máquina virtual Windows en Azure.
Para más información sobre cómo diseñar las redes virtuales y las subredes, consulte Planeamiento y diseño de Azure Virtual Networks.
Grupos de seguridad de red
Use reglas NSG para restringir el tráfico entre los niveles. En esta arquitectura, solo el nivel web se comunica directamente con el nivel de base de datos. Para aplicar esta regla, el nivel de base de datos debe bloquear todo el tráfico entrante excepto el de la subred del nivel web.
- Deniegue todo el tráfico entrante de la red virtual. (Use la etiqueta VIRTUAL_NETWORK en la regla).
- Permita el tráfico entrante de la subred del nivel web.
- Permita el tráfico entrante de la propia subred del nivel de la base de datos. Esta regla permite la comunicación entre las máquinas virtuales de la base de datos, lo cual es necesario para la replicación y la conmutación por error de esta.
Cree las reglas 2 y 3 con una prioridad más alta que la primera regla para que puedan invalidarla.
Grupos de disponibilidad Always On de SQL Server
Se recomiendan los grupos de disponibilidad Always On para conseguir una alta disponibilidad de Microsoft SQL Server. Otros niveles se conectan a la base de datos a través de una escucha de grupo de disponibilidad. La escucha permite a un cliente SQL conectarse sin conocer el nombre de la instancia física de SQL Server. Las máquinas virtuales que acceden a la base de datos deben estar unidas al dominio. El cliente (en este caso, otro nivel) utiliza DNS para resolver el nombre de la red virtual de la escucha en direcciones IP.
Configure el grupo de disponibilidad Always On de SQL Server como sigue:
- Cree un clúster de clústeres de conmutación por error de Windows Server, un grupo de disponibilidad Always On de SQL Server y una réplica principal. Para más información, consulte Introducción a Grupos de disponibilidad AlwaysOn.
- Cree un equilibrador de carga interno con una dirección IP privada estática.
- Cree una escucha de grupo de disponibilidad y asigne el nombre DNS de la escucha a la dirección IP del equilibrador de carga interno.
- Cree una regla del equilibrador de carga para el puerto de escucha de SQL Server (puerto TCP 1433 de forma predeterminada). La regla del equilibrador de carga debe habilitar la IP flotante, también denominada Direct Server Return. Esto causa que la máquina virtual responda directamente al cliente, lo que permite establecer una conexión directa con la réplica principal.
Nota
Cuando la IP flotante está habilitada, el número de puerto de front-end debe ser el mismo que el número de puerto de back-end en la regla del equilibrador de carga.
Cuando un cliente SQL intenta conectarse, el equilibrador de carga enruta la solicitud de conexión a la réplica principal. Si se produce una conmutación por error a otra réplica, el equilibrador de carga enruta automáticamente las nuevas solicitudes a una nueva réplica principal. Para más información, consulte Configuración de un equilibrador de carga para un grupo de disponibilidad en máquinas virtuales con SQL Server de Azure.
Una conmutación por error cierra las conexiones de cliente existentes. Una vez completada la conmutación por error, las conexiones nuevas se enrutan a la nueva réplica principal.
Si la aplicación lee mucho más de lo que escribe, redirija algunas de las consultas de solo lectura a una réplica secundaria. Consulte Conexión a una réplica de solo lectura.
Para probar la implementación, fuerce una conmutación por error manual del grupo de disponibilidad.
Consideraciones sobre disponibilidad
Availability Zones proporciona alta resistencia en una sola región. Si necesita incluso más disponibilidad, considere la replicación de la aplicación entre dos regiones y use Azure Traffic Manager para la conmutación por error. Para más información, consulte Ejecución de una aplicación de N niveles en varias regiones de Azure para lograr alta disponibilidad.
No todas las regiones admiten zonas de disponibilidad y no todos los tamaños de máquina virtual se admiten en todas las zonas. Ejecute el siguiente comando de la CLI de Azure para buscar las zonas admitidas para cada tamaño de máquina virtual dentro de una región:
az vm list-skus --resource-type virtualMachines --zone false --location eastus -o table
Virtual Machine Scale Sets usa automáticamente grupos de selección de ubicación, que actúan como un conjunto de disponibilidad implícito. Para más información, consulte Uso de grandes conjuntos de escalado de máquinas virtuales.
Sondeos de estado
Application Gateway y Azure Load Balancer usan sondeos de mantenimiento para supervisar la disponibilidad de las instancias de máquina virtual.
- Application Gateway siempre usa un sondeo HTTP.
- Load Balancer puede sondear con HTTP o TCP. Por lo general, si una máquina virtual ejecuta un servidor HTTP, use un sondeo HTTP. De lo contrario, use TCP.
Si un sondeo no puede acceder a una instancia dentro del período de tiempo de expiración, la puerta de enlace o el equilibrador de carga deja de enviar tráfico a esa máquina virtual. El sondeo continúa realizando comprobaciones y devuelve la máquina virtual al grupo de back-end si la máquina virtual vuelve a estar disponible.
Los sondeos HTTP envían una solicitud GET HTTP a una ruta de acceso determinada y escuchan una respuesta HTTP 200. Puede ser la ruta de acceso raíz ("/") o un punto de conexión de supervisión de mantenimiento que implementa lógica personalizada para comprobar el mantenimiento de la aplicación. El punto de conexión debe permitir solicitudes HTTP anónimas.
Para más información sobre los sondeos de estado, consulte:
- Sondeos de estado de Load Balancer
- Información general sobre la supervisión de estado de Application Gateway
Para conocer las consideraciones sobre el diseño de un punto de conexión de sondeo de estado, consulte Patrón Health Endpoint Monitoring.
Consideraciones sobre el costo
Puede usar la calculadora de precios de Azure para calcular los costos. Estas son algunas otras consideraciones.
Virtual Machine Scale Sets
Virtual Machine Scale Sets está disponible en todos los tamaños de máquina virtual Windows. Solo se le cobra por las máquinas virtuales de Azure que implemente y por los recursos de infraestructura subyacente adicionales que haya consumido, como el almacenamiento y las redes. No hay cargos incrementales por el servicio de Virtual Machine Scale Sets.
Para ver las opciones de precios de las máquinas virtuales únicas, consulte Precios de máquinas virtuales Windows.
SQL Server
Si elige Azure SQL DBaaS, puede reducir costos porque no es necesario configurar un grupo de disponibilidad Always On y máquinas de controlador de dominio. Hay varias opciones de implementación, desde una base de datos única hasta una instancia administrada o grupo elástico. Para más información, consulte Precios de Azure SQL.
Para ver las opciones de precios de las máquinas virtuales de SQL Server, consulte Precios de máquinas virtuales SQL.
Azure Load Balancer
Se le cobrará solo el número de reglas de equilibrio de carga y de salida configuradas. Las reglas NAT de entrada son gratuitas. Cuando no hay configurada ninguna regla, la instancia de Standard Load Balancer no se cobra por hora.
Para más información, consulte la sección acerca de los costos en Azure Architecture Framework.
Application Gateway
Application Gateway debe aprovisionarse con la SKU v2 y puede abarcar varias zonas de disponibilidad. Con la SKU de la versión 2, el modelo de precios está determinado por el consumo y tiene dos componentes: Precio fijo por hora y un costo basado en el consumo.
Para más información, consulte la sección de precios de Escalabilidad automática y Application Gateway v2 con redundancia de zona.
Consideraciones sobre la seguridad
Las redes virtuales son un límite de aislamiento del tráfico de Azure. De manera predeterminada, las máquinas virtuales de una red virtual no se pueden comunicar directamente con las máquinas virtuales de otra red virtual. Sin embargo, puede conectar explícitamente las redes virtuales mediante el emparejamiento de red virtual.
Restricción de tráfico
Use los grupos de seguridad de red (NSG) para restringir el tráfico desde y hacia Internet. Para más información, consulte Servicios en la nube de Microsoft y seguridad de red.
DMZ
Considere la posibilidad de agregar una aplicación virtual de red (NVA) para crear una red perimetral entre la red de Internet y la red virtual de Azure. NVA es un término genérico para una aplicación virtual que puede realizar tareas relacionadas con la red, como firewall, inspección de paquetes, auditoría y enrutamiento personalizado. Para más información, consulte Red perimetral entre Azure y un centro de datos local.
Cifrado
Cifre los datos confidenciales en reposo y use Azure Key Vault para administrar las claves de cifrado de la base de datos. Key Vault puede almacenar las claves de cifrado en módulos de seguridad de hardware (HSM). Para más información, consulte Configuración de la integración de Azure Key Vault para SQL Server en máquinas virtuales de Azure. También se recomienda almacenar los secretos de aplicación como, por ejemplo, las cadenas de conexión de base de datos, en Key Vault.
Protección contra DDOS
De forma predeterminada, la plataforma Azure proporciona protección básica contra DDoS. El objetivo de esta es proteger la infraestructura de Azure. Aunque la protección básica contra DDoS se habilita automáticamente, se recomienda usar Azure DDoS Protection estándar. Para detectar las amenazas, la protección estándar usa un ajuste que se puede adaptar en función de los patrones de tráfico de red de la aplicación, lo que le permite aplicar mitigaciones frente a ataques de denegación de servicio distribuido que podrían pasar desapercibidas para las directivas de DDoS para toda la infraestructura. La protección estándar también proporciona alertas, telemetría y análisis a través de Azure Monitor. Para más información, consulte Azure DDoS Protection: procedimientos recomendados y arquitecturas de referencia.