El proceso perimetral de acceso múltiple (MEC) público de Azure es una excelente plataforma para hospedar aplicaciones en el perímetro y puede hacer que respondan mejor, pero actualmente no admite características de alta disponibilidad. En este artículo se describe cómo implementar cargas de trabajo en modo activo/en espera para lograr una alta disponibilidad y recuperación ante desastres.
Apache®, Apache Ignite, Ignite y el logotipo de la llama son marcas registradas o marcas comerciales de Apache Software Foundation en Estados Unidos y otros países. El uso de estas marcas no implica la aprobación de Apache Software Foundation.
Architecture
Descargue un archivo Visio de esta arquitectura.
Flujo de trabajo
Azure Traffic Manager. Configure Traffic Manager para usar el enrutamiento por prioridad. Establezca la dirección IP del equilibrador de carga en MEC público de Azure (principal) en Prioridad 1. Establezca el de la región secundaria en Prioridad 2. Esta configuración envía todo el tráfico en caso de no conmutación por error al MEC público de Azure.
Nota:
Traffic Manager para MEC público de Azure no admite actualmente el enrutamiento de rendimiento, lo que podría determinar dinámicamente el enrutamiento descrito anteriormente en función de la latencia más baja para el punto de conexión.
En esta arquitectura, la conmutación por recuperación se logra automáticamente después de que las máquinas virtuales (VM) o el equilibrador de carga estándar vuelvan a estar en línea. Traffic Manager determina que las cargas de trabajo están en marcha y vuelve a enrutar el tráfico a la región principal de MEC pública de Azure.
Equilibrador de carga público. Este equilibrador de carga se encuentra delante de la capa de aplicación y equilibra el tráfico al grupo de máquinas virtuales del conjunto de escalado de máquinas virtuales.
Equilibrador de carga interno. Este equilibrador de carga se usa para acceder a la capa de base de datos. En función del tipo de base de datos que use para la aplicación, es posible que no necesite un equilibrador de carga aquí, suponiendo que otros servicios de plataforma como servicio (PaaS) tengan su propio equilibrador de carga.
Microsoft Azure Virtual Machine Scale Sets de Azure. La mayoría de las implementaciones de producción Virtual Machine Scale Sets para escalar dinámicamente sus cargas de trabajo en función de la carga de tráfico. MEC público de Azure también admite Azure Kubernetes Service para aplicaciones nativas en la nube y basadas en contenedores.
Capa de datos. Actualmente, MEC público de Azure no admite servicios PaaS de base de datos de SQL como SQL Server en Azure Virtual Machines y Azure SQL Managed Instance. Actualmente tampoco admite servicios NoSQL PaaS como Azure Cosmos DB y Azure Instance for Azure Managed Instance for Apache Cassandra. Puede implementar soluciones de terceros que admitan servicios SQL o NoSQL y replicación de datos en sus clústeres distribuidos geográficamente.
Componentes
- MEC público de Azure es una solución de proceso perimetral que reúne una cartera de servicios de proceso, redes y aplicaciones de Microsoft que se administran desde la nube.
- Azure Traffic Manager es un equilibrador de carga de tráfico basado en DNS. Puede usarlo para dirigir las solicitudes DNS entrantes en función del método de enrutamiento que elija.
- Azure Load Balancer proporciona alta disponibilidad y alto rendimiento para las aplicaciones.
- Azure Virtual Machine Scale Sets permite administrar y escalar verticalmente hasta miles de máquinas virtuales.
Alternativas
Copia de seguridad y recuperación ante desastres de Azure, que proporciona características de copia de seguridad y recuperación del Azure Site Recovery:
- Replica de forma activa las máquinas virtuales desde el MEC público de Azure a la región primaria y las pone a disposición para la conmutación por error y la conmutación por recuperación en caso de interrupción.
- Hace una copia de seguridad de máquinas virtuales para evitar datos dañados o perdidos.
Este enfoque cuesta menos que el descrito anteriormente porque no hay recursos inactivos. Esta alternativa solo es adecuada para las aplicaciones que permiten más RTO.
Nota:
La copia de seguridad y recuperación ante desastres de Azure para MEC público de Azure actualmente solo admite máquinas virtuales.
Detalles del escenario
Posibles casos de uso
Use esta arquitectura cuando desee implementar cargas de trabajo en modo activo/en espera para lograr una alta disponibilidad y recuperación ante desastres. Este escenario es ideal para el sector de las telecomunicaciones.
Consideraciones
Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.
Contrato de nivel de servicio
Microsoft admite contratos de nivel de servicio (SLA) para una infraestructura de mayor tamaño, como Azure y regiones de Azure. MEC público de Azure es una extensión de superficie más pequeña de Azure y, por tanto, no tiene compatibilidad con el contrato de nivel de servicio.
Rendimiento
MEC público de Azure está diseñado para hospedar aplicaciones críticas para la latencia. Dado que la conmutación por error a una región secundaria aumenta la latencia de las cargas de trabajo, es posible que no proporcione el mismo nivel de rendimiento. En función de la aplicación y de su sensibilidad a esta mayor latencia, debe decidir cuál de los servicios, si los hay, debe conmutar por error a la región.
Bases de datos
La replicación de datos y la copia de seguridad son importantes cuando se confía en conmutaciones por error de base de datos. La mayoría de los servicios PaaS de Azure tienen compatibilidad integrada con la replicación geográfica y la creación de réplicas de lectura entre regiones y zonas geográficas.
Nota:
Actualmente, MEC público de Azure no admite servicios PaaS como SQL Managed Instance, SQL Server en Azure Virtual Machines, Azure Database for MySQL o Azure Database for PostgreSQL. Las ofertas de terceros como Couchbase, MongoDB y Apache Cassandra pueden proporcionar servicios de infraestructura como servicio (IaaS) que admiten la replicación geográfica.
Traffic Manager
Opciones de conmutación por error
Traffic Manager admite varios métodos de enrutamiento: rendimiento, geográfico, prioridad, etc. Para admitir mejor las aplicaciones de baja latencia, envíe dinámicamente datos a la región o MEC público de Azure más cercano al usuario. El enrutamiento de rendimiento no se admite actualmente en MEC público de Azure. La siguiente mejor opción es priorizar estáticamente la mejor ubicación para una aplicación.
Para una aplicación distribuida globalmente que tenga cargas de trabajo distribuidas entre varias regiones y MEC públicos de Azure, use un método de enrutamiento anidado. Use el enrutamiento geográfico para dividir el tráfico en la región correcta y, a continuación, use el enrutamiento por prioridad para dividir aún más el tráfico.
Conmutación por recuperación
Una vez que se realiza una copia de seguridad de las cargas de trabajo en MEC público de Azure, los sondeos de Traffic Manager detectan que puede tomar solicitudes y volver a enrutar automáticamente el tráfico a MEC público de Azure.
Optimización de costos
La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.
MEC público de Azure se usa principalmente para escenarios de cálculo en tiempo real y baja latencia. Los datos los procesan las instancias de proceso que se ejecutan en MEC público de Azure. Esta arquitectura usa activo/en espera con un servidor en espera activa. Es decir, las cargas de trabajo de la región secundaria no se usan a menos que haya una conmutación por error.
Este enfoque para implementar cargas de trabajo como en espera incurre en costos de implementación de Azure aunque no se utilicen.
Para más información sobre precios:
- Consulte los precios de Azure.
- Use la calculadora de precios de Azure para estimar el costo de la implementación de esta solución.
Para obtener información sobre cómo crear una carga de trabajo rentable, consulte Introducción al pilar de optimización de costos en la documentación de Azure Well-Architected Framework.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
- Adhip Gupta | Jefe de programa senior
Pasos siguientes
- MEC público de Azure
- ¿Qué es Traffic Manager?
- ¿Qué es Azure Load Balancer?
- ¿Qué son los conjuntos de escalado de máquinas virtuales?