Consideraciones de alta disponibilidad en AWS y Azure

108851

Created On 09/25/18 15:12 PM - Last Modified 06/15/23 22:35 PM

Resolution

A medida que los clientes empiezan a utilizar la serie VM para proteger sus aplicaciones y datos críticos del negocio en la nube pública, surge la pregunta "¿soporta alta disponibilidad en AWS o Azure?". El poste original del 2016 de noviembre (abajo) no contestó la pregunta claramente. La respuesta es sí, puede implementar una arquitectura con la serie VM en AWS y Azure que ofrece alta disponibilidad y resiliencia requerida para las implementaciones de aplicaciones empresariales. Sin embargo, el diablo está en los detalles de la implementación.

Alta disponibilidad activa-pasiva de la VM-series en AWS

En AWS, la serie VM admite alta disponibilidad activa-pasiva mediante dos cortafuegos de la serie VM (activos y pasivos) implementados en una única zona de disponibilidad de AWS. Si se produce un error, el Eni de AWS vinculado al cortafuegos de la serie VM activa se desplaza al cortafuegos de la serie VM pasiva. El movimiento ENI se realiza a través de una llamada API a AWS que típicamente toma hasta 60 segundos pero a veces más tiempo. El retraso es un subproducto de la forma en que funciona el tejido AWS y no está controlado por la serie VM. Durante ese tiempo, algunas sesiones pueden perderse, pero el estado se mantiene.

El uso de pasivo activo de esta manera ofrece alta disponibilidad en la definición tradicional. Además del tiempo de retardo de failover, esta ha no puede abarcar varias zonas de disponibilidad debido a la limitación de AWS de no permitir que Eni se mueva para abarcar AZS. Además, ambas licencias de la serie VM están activas al igual que los recursos de AWS necesarios para mantenerlos en ejecución, lo que resulta en consideraciones de gastos.

VM-series en la documentación de alta disponibilidad de AWS

Alta disponibilidad de la VM-series en AWS (entrada usando escalamiento auto y la integración ELB)

Un enfoque alternativo para proporcionar alta disponibilidad a nivel de centro de datos es utilizar el fabric de nube para construir ha que puede abarcar múltiples AZS en su implementación. El escalamiento automático de la serie VM y la integración de ELB le permiten lograr este objetivo final para el tráfico entrante.

La escala automática para la serie VM en AWS implementa varios cortafuegos en dos zonas de disponibilidad dentro de un VPC. Si falla alguno de los cortafuegos de la serie VM, suceden dos cosas: en primer lugar, el balanceador de carga de AWS detecta la falla y desvía el tráfico a los cortafuegos de la serie VM más sanos, lo que normalmente sucede en pocos segundos, dependiendo de la configuración de prueba de salud. En segundo lugar, los grupos de escala automática de AWS eliminarán automáticamente los cortafuegos no saludables y los reemplazarán con los nuevos cortafuegos de la serie VM de bootstrapped que se encuentran completamente configurados, con licencia y listos para manejar el tráfico.

Dependiendo del balance de rendimiento y de la sensibilidad de los costos, los controles de salud y los grupos de escalamiento automático se pueden afinar para ser muy agresivos o muy conservadores acerca de la detección y reemplazo de componentes fallidos. Esto le permite hacer su propia decisión de costo/beneficio al diseñar su despliegue. La VM-series no sólo se escala automáticamente dentro y fuera, sino que también es autoregenerable proporcionando una solución global y altamente disponible en varias zonas de disponibilidad.

Escalamiento automático de la serie VM en los recursos de implementación de AWS

Escalamiento automático de la serie VM para AWS Atamborado

Alta disponibilidad de la VM-series en AWS (multi-AZ usando funciones de la lambda)

Otra alternativa es utilizar una solución basada en lambda que sea compatible con la comunidad creada por Cloudticity para los clientes que necesitan ha que abarque varias zonas de disponibilidad. En este escenario de despliegue, una función lambda monitorea la salud de la serie VM desplegada en cada AZ. Cada AZ tiene un cortafuegos primario activo para manejar el tráfico. Si falla un cortafuegos de la serie VM, otra función lambda redireccionará el tráfico a un cortafuegos secundario de la serie VM desplegado en otro AZ.

Solución multi-AZ HA utilizando recursos lambda

VM-series en Azure alta disponibilidad

Para las VM-series en implementaciones de Microsoft Azure, se logra una alta disponibilidad utilizando varias instancias de la serie VM utilizando los recursos de Azure a continuación.

VM-series de alta disponibilidad en Azure (entrada con Application Gateway y la integración de balanceador de carga)

La alta disponibilidad de la serie VM en Azure se puede lograr utilizando conjuntos de disponibilidad Azure combinados con la integración de Application Gateway y balanceador de carga. Los conjuntos de disponibilidad abordan la necesidad de una alta disponibilidad y resiliencia al minimizar o eliminar el impacto negativo que puede tener el mantenimiento de la infraestructura Azure o los fallos del sistema en su negocio al distribuir las cargas de trabajo en diferentes hosts. Implementado como un sándwich de balanceador de carga, la pasarela de aplicaciones actúa como el Front balanceador de carga externo que termina la aplicación mientras el balanceador de carga actúa como mecanismo de distribución de tráfico interno, distribuyendo tráfico a su aplicación Web.

El tráfico se distribuye a los dos cortafuegos de la serie VM, cada uno asignado a un conjunto de disponibilidad diferente. Si falla un cortafuegos de la serie VM, el tráfico se redirige a los cortafuegos de la serie VM saludables restantes por el Azure App Gateway. Cuando se repara la VM-Series (por la funcionalidad del conjunto de disponibilidad), el tráfico se vuelve a distribuir. Esta arquitectura no sólo ofrece escalabilidad, sino que también ofrece resiliencia y alta disponibilidad mediante el soporte para los conjuntos de disponibilidad Azure.

Recursos de implementación de escalabilidad y resiliencia de la serie VM

Lea la escalabilidad y la resiliencia de la serie VM para Azure Tech Brief

VM-series de alta disponibilidad en Azure (entrada y salida usando la integración de Application Gateway & balanceador de carga)

Para hacer frente a la necesidad de una alta disponibilidad tanto entrante como saliente en Azure, la plantilla de ARM basada en la comunidad puede utilizarse para implementar cortafuegos balanceados de carga separados para el tráfico entrante y saliente. Cada cortafuegos consta de dos o más cortafuegos de la serie VM en un conjunto de disponibilidad para que puedan ser administrados independientemente y escalados dentro o fuera para acomodar la carga. El balanceo de carga entrante de la pasarela de aplicaciones recibe el tráfico entrante que distribuye la carga a una instancia del cortafuegos de la serie VM entrante. El cortafuegos aplica la Directiva de seguridad y enruta el tráfico seguro al balanceador de carga de backend que distribuye la carga a una instancia de la carga de trabajo Web de backend.

Cargas de trabajo web seguras que enfrentan Internet en los recursos de despliegue de Azure

Cargas de trabajo web seguras orientadas a Internet en el libro azul

-----------Original post: noviembre, 2016-----------

A medida que los clientes buscan trasladar sus aplicaciones y datos a la nube pública, no es raro escuchar preguntas sobre las construcciones tradicionales de Data Center, como la alta disponibilidad (ha). La pregunta es muchas veces planteada como "¿cómo apoyar a ha en AWS o Azure." Una forma más centrada en la nube para plantear la pregunta sería "¿necesitamos ha en la nube pública?"

Para responder a la pregunta, primero necesitamos definir con precisión lo que entendemos por ha. Si la pregunta es, ¿necesitamos una solución totalmente redundante y altamente disponible para proteger las aplicaciones de Cloud pública? Entonces la respuesta es definitivamente sí. Pero si la pregunta es, ¿necesitamos el failover stateful ha de pan-os tal como lo hicimos en la nube privada, entonces la respuesta probablemente no es .

La nube pública se trata de aprovechar recursos compartidos e implementar aplicaciones que pueden sobrevivir a un error en cualquier parte de la arquitectura. Esto incluye, pero no se limita a un fallo de:

un router virtual
un cortafuegos virtual
un conmutador de red
una instancia de aplicación
una instancia de balanceador de carga
un error de zona de disponibilidad
incluso el fracaso de toda una región

Es probable que los clientes utilicen docenas o incluso cientos de aplicaciones en su ordenador portátil, Tablet y smartphone que utilicen una infraestructura que haya tenido un fallo de algún tipo. Y el 99% de las veces, no tienen idea de que sucedió. Algún balanceador de carga o proceso de conmutación o enrutamiento omitió la falla y la aplicación intentó silenciosamente de nuevo con poca o ninguna interrupción al usuario. Por lo tanto, el enfoque para integrar nuestra seguridad de cortafuegos de la serie VM en aplicaciones de nube pública debe estar en servicios de nube nativos como grupos de escalamiento automático, balanceo de carga elástica, enrutamiento, etc. y no en pan-os ha.

La serie VM soporta ha para AWS, pero generalmente no es necesaria si el cliente utiliza la migración de la nube pública como una oportunidad para actualizar sus aplicaciones para aprovechar los servicios de nube nativos para construir una arquitectura resistente que maximice el tiempo de espera. Muchos clientes iniciarán su migración a la nube pública adhiriéndose a una lista tradicional de requisitos de hardware del centro de datos (switches redundantes, routers, cortafuegos, etc) que pueden limitar la capacidad de aprovechar el poder de la nube. El uso del requerimiento de redundancia como controlador y, a continuación, el aprovechamiento de la nube o lograrlo permitirá a los clientes: a) mejorar el tiempo de aplicación y b) reducir los costos. Sé que esto no siempre es posible, pero el intento de dejar ese equipaje detrás.

Para los clientes que no tienen otra opción que mover una aplicación heredada a la nube pública, tenemos ha para AWS y estamos investigando ha para Azure. Pero se trata de un costo. No sólo necesitarán un firewall pasivo funcionando en todo momento (y el proyecto de ley que va con eso), pero ha en la nube pública se basa en llamadas API que pueden tardar mucho más que lo que podemos hacer en hardware en la infraestructura de red dedicada. Por ejemplo, en AWS, nuestra solución ha se basa en una llamada de API para mover interfaces (ENI) desde un cortafuegos fallido hasta el cortafuegos pasivo. En la práctica, esto toma 30-45 segundos pero a veces más largo. Lo más probable es que las sesiones que ha destinado a salvar ya necesiten ser reestablecidas en ese período de tiempo.

En su lugar, enfoque en balanceo de carga y enrutamiento dinámico que puede converger debe más rápido y dejar que la aplicación tratar con reestablecimiento de sesión. Las nubes públicas están desarrollando nuevos patrones arquitectónicos que se alinean bien con las tendencias generales en las arquitecturas de aplicaciones de TI:

Uso del escalamiento horizontal (escala del aka hacia fuera) para tratar de cargas y de disponibilidad más grandes.
Crecimiento de arquitecturas basadas en Web/http que son menos estatales en general; cualquier información de estado como una cookie de sesión puede reconstruirse fácilmente o se hace redundante
Uso de arquitecturas orientadas al servicio (SOA) como micro-servicios, a menudo construidos en contenedores, para descomponer el. pila de aplicaciones en varios niveles que se escalan independientemente detrás de balanceadores de carga.

En estos entornos, los datos de sesión se almacenan en servicios de bases de datos fiables, como Amazon DynamoDB o Amazon ElastiCache, y se comparten con los servidores de aplicaciones. Por ejemplo, en un servicio de carrito de compras, la sesión de cookies del usuario se puede sync'ed/almacenar entre servidores web para que el fallo de un único servidor Web no afecte a la experiencia del usuario. El foco de las nuevas arquitecturas, en la nube pública y en las nubes privadas locales, está en la confiabilidad del servicio y no la confiabilidad de la sesión.

Uso del escalamiento automático para la serie VM en AWS para lograr HA

Como se mencionó anteriormente, cualquier despliegue de AWS debe ser diseñado para que la resiliencia elimine el impacto negativo que puede tener un fallo del componente de infraestructura. Si se produce un fallo, la solución debe ser capaz de detectar y recorrer un error. Esto es cierto también para la seguridad de la solución. La escala automática para la serie VM en AWS ofrece HA utilizando servicios de nube nativos.

La escala automática para la serie VM en AWS implementa varios cortafuegos en dos o más zonas de disponibilidad dentro de un VPC. Si falla alguno de los cortafuegos de la serie VM, suceden dos cosas: en primer lugar, el balanceador de carga de AWS detecta la falla y desvía el tráfico a los cortafuegos de la serie VM que quedan sanos. En segundo lugar, los grupos de escala automática de AWS eliminarán automáticamente los cortafuegos no saludables y los reemplazarán con los nuevos cortafuegos de la serie VM de bootstrapped que se encuentran completamente configurados y listos para manejar el tráfico.

Dependiendo del balance de rendimiento y de la sensibilidad de los costos, los controles de salud y los grupos de escalamiento automático se pueden afinar para ser muy agresivos o muy conservadores acerca de la detección y reemplazo de componentes fallidos. Esto le permite hacer su propia decisión de costo/beneficio al diseñar su despliegue. La serie VM no sólo se escala automáticamente dentro y fuera, independientemente de las cargas de trabajo, sino que también se autoregenera proporcionando una solución global y altamente disponible en varias zonas de disponibilidad.

Uso de la integración de la aplicación Azure de la serie VM y del balanceador
de carga para lograr ha

La serie VM permite implementar una solución de escalabilidad administrada para el tráfico de cargas de trabajo de aplicaciones Web entrantes mediante un "sandwich" de balanceador de carga. El gateway de la aplicación actúa como balanceador de carga externo, Front terminando la aplicación y sirviendo como Gateway de Internet para todo el servicio. Proporciona controlador de entrega de aplicaciones (ADC) como un servicio e incluye balanceo de carga de capa 7 para HTTP y HTTPS, junto con funciones como descarga de SSL y enrutamiento basado en contenido. Los cortafuegos de la serie VM desplegados detrás de Application Gateway proporcionarán la seguridad de próxima generación completa que protege las implementaciones de Azure de ataques de amenazas conocidas y desconocidas. Después de la inspección de seguridad por el firewall, el tráfico se envía al balanceador de carga Azure actuando como el balanceador de carga interno, que distribuye el tráfico a sus aplicaciones Web. Esta arquitectura no sólo ofrece escalabilidad, sino que también ofrece resiliencia y alta disponibilidad gracias a la compatibilidad con los conjuntos de disponibilidad Azure.

La pasarela de aplicaciones y el balanceador de carga se ocupan de cualquier interrupción del tráfico, los conjuntos de disponibilidad proporcionan protección contra el mantenimiento planificado y no planificado de la infraestructura Azure. Esto aborda la necesidad de resiliencia y disponibilidad al minimizar o eliminar el impacto negativo que puede tener el mantenimiento de la infraestructura Azure o los fallos del sistema en su negocio al distribuir las cargas de trabajo en diferentes hosts.

Referencias

Diapositiva 45-AWS re: invent 2013- arquitecturas de aplicaciones de alta disponibilidad en Amazon VPC (ARC202) |...
Página 11-Amazon Web Services-arquitectura para la nube: mejores prácticas- https://media.amazonwebservices.com/AWS_Cloud_Best_Practices.pdf