Este documento describe las opciones actuales para implementar aplicaciones en CloudHub 2.0 para cumplir los requisitos de alta disponibilidad y recuperación de desastres. Utiliza la región de EE.UU. como ejemplo y se puede aplicar a otras regiones.

CloudHub 2.0 es una plataforma de integración nativa de la nube completamente gestionada que elimina los gastos generales de infraestructura automatizando la implementación, la ampliación y la gestión de las API de MuleSoft y las integraciones en la nube. Es la plataforma de implementación en la nube moderna de MuleSoft, que se ejecuta en la infraestructura de Amazon AWS.

En la mayoría de los casos, la Alta disponibilidad (HA) y la Recuperación de desastres (DR) predeterminadas proporcionadas por CloudHub 2.0 son suficientes. CloudHub 2.0 proporciona HA y DR a nivel regional (para obtener más detalles, consulte Escenarios de cortes de CloudHub 2.0). La sección Consideraciones clave de CloudHub 2.0 proporciona más detalles acerca de HA y DR compatibles con CloudHub-2.0.

Las condiciones que exigen un diseño más allá de la disponibilidad predeterminada de CloudHub 2.0 incluyen:

• Una aplicación necesita garantizar que no se produzca ninguna pérdida de datos en un escenario de desastre (por ejemplo, una región de Amazon fallida).
• Una aplicación depende del Almacén de objetos y necesita garantizar la continuidad si la región de implementación falla.

• Los sistemas backend están configurados para una disponibilidad equivalente. CloudHub 2.0 puede a veces proporcionar fiabilidad a través de colas o mecanismos similares, pero si la integración es en tiempo real o asíncrona, los sistemas backend deben admitir un nivel comparable de HA y DR.
• Cuando una interrupción a nivel de región de AWS afecta a sistemas backend, se supone que su recuperación se ejecuta en paralelo con la recuperación de CloudHub 2.0.
• La configuración del espacio privado está completa en múltiples regiones.

Las opciones de diseño en esta guía se centran en soluciones para la disponibilidad de aplicaciones en CloudHub 2.0 cuando una zona o región de disponibilidad de AWS completa deja de estar disponible.

Esta guía no aborda estos escenarios de recuperación, aunque sí señala implicaciones cuando procede:

• Recuperación de sistemas backend, aplicaciones, bases de datos, componentes de red y centros de datos gestionados y aprovisionados fuera de Anypoint CloudHub, ya sea en las instalaciones o en la nube.
• Recuperación de vínculos VPN entre CloudHub 2.0 y el centro de datos privado del cliente (por ejemplo, túneles IPsec y pasarelas VPN). Algunas opciones de DR en esta guía podrían solucionar parcialmente estos escenarios.
• Los cambios en MuleSoft generan direcciones IP durante la recuperación de desastres cuando se utiliza la lista de admisión de direcciones IP para integraciones. Algunas opciones de DR en esta guía podrían solucionar parcialmente estos escenarios.
• Sistemas de mensajería externos utilizados en soluciones de clientes, ya sean proporcionados por MuleSoft (como Anypoint MQ) u otros proveedores (como AWS MSK o Heroku Kafka).

Al evaluar CloudHub 2.0 para requisitos de recuperación de desastres, piense en estas consideraciones clave.

Dependencia de CloudHub 2.0 de la disponibilidad regional de AWS

• CloudHub 2.0 se ejecuta en AWS; su disponibilidad está vinculada a regiones de AWS.
• Las implementaciones y la disponibilidad de aplicaciones están organizadas por región. Estas regiones corresponden a regiones de AWS.

Si una región de AWS completa falla, las aplicaciones en esa región no están disponibles y no se replican automáticamente en otro lugar.

Alta disponibilidad de aplicaciones (HA) y Gestión de réplicas

• CloudHub 2.0 vuelve a implementar automáticamente aplicaciones en la misma región cuando falla el hardware, pero una aplicación con una única réplica puede experimentar tiempo de inactividad.
• Las aplicaciones con múltiples réplicas se implementan entre zonas de disponibilidad separadas de forma predeterminada, proporcionando HA entre zonas.
• Si la zona de disponibilidad para una aplicación de una sola réplica falla, la aplicación aparece automáticamente en otra zona de disponibilidad en la misma región.

Repercusión específica de la región este de EE.UU.

• En caso de un fallo de funcionamiento de la región Este de EE.UU.:
  • La interfaz de usuario de gestión de CloudHub 2.0 y los servicios de REST de implementación no están disponibles y no se pueden implementar nuevas aplicaciones.
  • Las solicitudes en otras regiones no se ven afectadas en la mayoría de los escenarios de fallo. Estas aplicaciones siguen funcionando normalmente; sin embargo, las funciones de monitoreo y gestión a través del plano de control no estarán disponibles durante el fallo.
  • Los módulos Core CloudHub 2.0 (como la configuración de la aplicación) se mantienen en el Este de EE.UU., de modo que no se pueden modificar los parámetros durante el fallo.

Monitoreo y alerta

• Configure alertas para fallos de zona de disponibilidad o nivel de región a través de status.mulesoft.com.
• Utilice un mecanismo de alerta y comprobación de estado separado fuera de CloudHub 2.0 de modo que se notifique a los equipos si las réplicas fallan o las aplicaciones dejan de responder.

Persistencia de datos (almacén de objetos V2)

• Establecimiento de objetos V2 está vinculado a la región donde se implementó la aplicación por primera vez.
• Si mueve la aplicación a otra región, Object Store V2 permanece en la región original para evitar la pérdida de datos.
• Si la región donde Almacén de objetos V2 está implementada falla, el almacén de objetos no está disponible.

Controladores de ingreso y espacios privados

• Los controladores de ingreso de CloudHub 2.0 están altamente disponibles a nivel de región.
• En un espacio compartido, si una región falla, un controlador de ingreso en otra región permanece disponible pero solo puede servir aplicaciones implementadas en esa región.
• En un espacio privado, si una región falla, los controladores de ingreso en otras regiones no están disponibles a menos que se configuraran allí con antelación.
• La configuración del espacio privado es regional; si una región falla, el espacio privado no estará disponible a menos que se haya configurado otra región.

Escenario descendente de Servicios de plataforma – Establecimiento de objetos

Alta disponibilidad (HA) es la medición de la capacidad de un sistema para permanecer accesible en caso de un fallo del componente del sistema. En general, HA se implementa incorporando múltiples niveles de tolerancia a fallos y/o funciones de equilibrio de carga en un sistema. Normalmente es una configuración Activo-Activo y da como resultado una repercusión limitada o nula en Servicios de negocio.

Recuperación de desastres (DR) es el proceso por el que un sistema se restaura a un estado aceptable anterior después de un escenario de desastre, ya sea natural (como inundaciones, tornados, terremotos o incendios) o provocado por el hombre (como fallos de energía, fallos de servidor o configuraciones incorrectas). DR es normalmente una configuración Activo-Pasivo y da como resultado alguna repercusión en Servicios de negocio.

Si se desea Alta disponibilidad regional o Recuperación de desastres regional para reducir el impacto de negocio en caso de un fallo regional de AWS, tenga en cuenta estos puntos al diseñar su solución en MuleSoft CloudHub 2.0:

• Las réplicas de CloudHub 2.0 y las funciones relacionadas (espacios privados, controladores de ingreso y destinos de Anypoint MQ) son específicas de la región.
• Si una región de AWS completa falla, todas las réplicas y los servicios asociados en esa región dejan de estar disponibles.
• Cuando se recupera una región, se restauran las configuraciones; debe reiniciar las aplicaciones.
• Si la región Este de EE.UU. falla, los servicios de Anypoint Platform (por ejemplo, Gestión de acceso y Gestor de tiempo de ejecución) tampoco están disponibles.
• MuleSoft proporciona un SLA del 99,95% de disponibilidad para Servicios de plataforma, incluyendo réplicas de CloudHub 2.0 en una configuración activo-activo dentro de una región; consulte el SLA de oferta de MuleSoft Cloud más reciente para obtener detalles actuales.
• CloudHub 2.0 no admite HA o DR de múltiples regiones listas para su uso; la disponibilidad solo se proporciona en una sola región.

Estas directrices de diseño se aplican independientemente de la configuración que seleccione.

Configuración de espacios privados de múltiples regiones

Todas las opciones descritas en las siguientes secciones requieren que las aplicaciones se implementen en regiones separadas. Eso solo es posible si la configuración del espacio privado se completa con antelación, antes de un desastre. Como la configuración de espacios privados es regional, una estrategia de DR requiere al menos dos espacios privados (uno por región) y un mecanismo para cambiar el tráfico al extremo VPN apropiado.

Configuración de espacio privado altamente disponible en una región

CloudHub 2.0 no proporciona conmutación por error automática cuando falla un espacio privado en una región. Una solución es una configuración activa-pasiva entre múltiples entornos, que requiere:

• Configuración de múltiples pasarelas VPN en el espacio privado.
• Establecimiento de entornos separados en la región CloudHub 2.0, cada uno con su propio espacio privado.
• Designación de uno de estos entornos como pasivo (donde las aplicaciones no se implementan inicialmente pero aparecen si falla el espacio privado principal).

Si una configuración de alta disponibilidad sin pasarela VPN siendo un único punto de fallo es un requisito difícil, la implementación en dos regiones es la mejor opción. Un fallo de pasarela VPN en este escenario podría resolverse fallando la región afectada a la región alternativa donde el espacio privado ya está configurado.

Pérdida de mensajes cero

Para alcanzar la pérdida cero de mensajes cuando falla una región completa, una aplicación debe evitar la pérdida de datos y solucionar estos puntos:

• Utilice mensajería externa para lograr la fiabilidad de los mensajes.
• Asegúrese de que Almacén de objetos no se utiliza para datos de transacciones en vuelo que son de naturaleza transaccional. Si la región de implementación donde se implementó por primera vez la aplicación MuleSoft se interrumpe, el Almacén de objetos no estará disponible.
• Envuelva todo el acceso a Establecimiento de objetos en un flujo o sección separados que sigan funcionando (tanto para la gestión de excepciones como para el comportamiento) cuando fallen las operaciones de lectura o escritura de Establecimiento de objetos.

Nota. En la mayoría de los casos, los requisitos de DR no tienen que garantizar una pérdida de mensajes cero en caso de un desastre y tienen que garantizar que la pérdida de datos es inferior al valor de datos de un periodo concreto (por ejemplo, 1 hora).

Mantener la integración sin estado

Como principio general de diseño, siempre es importante garantizar que las integraciones sean de naturaleza apátrida. Esto significa que no se comparte información de transacciones entre varias invocaciones o ejecuciones de clientes (en el caso de servicios programados). Si el middleware tiene que mantener algunos datos debido a una limitación del sistema, deben mantenerse en un establecimiento externo, como una base de datos o una cola de mensajería y no en la infraestructura o la memoria de MuleSoft. Es importante tener en cuenta que a medida que ampliamos, especialmente en la nube, el estado y los recursos utilizados por cada réplica deben ser independientes de otras réplicas. Este modelo garantiza un mejor desempeño, capacidad de ampliación y fiabilidad.

Gestión de redes y tráfico

• Los dominios de tocador son obligatorios para la disponibilidad regional; actúan como un DNS global para todos los controladores de entrada entre regiones.
• Un equilibrador de carga global enruta el tráfico entre los espacios privados de la región principal y de DR. Los clientes proporcionan este componente; utilice Ruta 53 de AWS o una CDN global con políticas de enrutamiento para enrutar el tráfico entre regiones.
• Configure controladores de ingreso en regiones principales y DR con un dominio de tocador personalizado.
• Planifique y mantenga reglas de cortafuegos y túneles VPN de modo que las aplicaciones locales sean accesibles desde los espacios privados de la región principal y de DR.
• El mantenimiento de certificados TLS debe cubrir espacios privados en regiones principales y DR para una recuperación sencilla.

Implementación y configuración de aplicaciones

• Los nombres de solicitud deben ser exclusivos entre regiones. Por ejemplo, una canalización de CI/CD puede anexar el nombre de región (o un código de región) a nombres de aplicación antes de la implementación para mantener la exclusividad entre regiones principales y de DR.
• Configure las oportunidades en curso de CI/CD para implementar aplicaciones en las regiones principal y DR de modo que todas las aplicaciones estén disponibles en ambas regiones.

Infraestructura y capacidad
El desempeño es mejor cuando todos los aspectos de la infraestructura tienen una capacidad de región principal y de DR idéntica. El desempeño se degrada cuando estos aspectos de infraestructura no son idénticos.

Almacenamiento y persistencia de datos

• El almacenamiento persistente debe sincronizarse periódicamente entre las dos regiones. Los clientes son responsables de la replicación del almacenamiento; MuleSoft no lo proporciona. Es posible un único establecimiento compartido entre VPC en las regiones principal y DR, pero el almacenamiento compartido debe estar altamente disponible o se convierte en un único punto de fallo para ambas regiones.
• Object Store V2 es regional y solo está disponible en la región donde se implementó por primera vez la aplicación Mule. Si la aplicación se traslada a otra región, Almacén de objetos V2 permanece en la región original para evitar la pérdida de datos. Utilice otro almacenamiento persistente para estrategias de DR de múltiples regiones.

Procedimientos de prueba y operación

Adopte una estrategia de prueba de DR formal y ejecute simulacros de DR periódicos. Para DR activo-activo, utilice una estrategia de implementación canaria para validar ambas regiones.

Acuerdos de desempeño y nivel de servicio (SLA)

Puede producirse cierta degradación del desempeño porque la región DR puede estar más lejos de los usuarios finales o sistemas backend que la región principal. Defina y comunique un SLA de DR a las partes interesadas.

Comportamiento del modo de recuperación (Nota contextual)

En modo activo-activo, la conmutación por error de la región principal al espacio privado de la región DR es rápida: el equilibrador de carga global detecta que la principal no es saludable y enruta el tráfico a la región saludable (DR). En modo activo-pasivo, debe implementar la aplicación en el espacio privado de la región DR cuando se produzca un desastre.

Existen 3 opciones para lograr una disponibilidad de nivel de DR superior:

Configuración activo-activo

Una configuración activo-activo se basa en trabajadores activos distribuidos entre regiones, utilizando un equilibrador de carga externo para enrutar el tráfico entre las dos instancias.

Configuración de Warm Standby
Una configuración activo-pasivo se basaría en un trabajador activo en una región y un trabajador pasivo en otra región. La Región pasiva se iniciaría cuando fuera necesario.

Algunos elementos de la región pasiva deben permanecer activos para la conmutación por error o configurarse de antemano, incluyendo espacios privados, VPN y archivos adjuntos de pasarelas de tránsito.

Configuración de espera fría

Como anteriormente, las réplicas y los controladores de ingreso se aprovisionan en una segunda región a través de un proceso de DevOps completamente automatizado en caso de fallo. Algunos elementos de la región pasiva deben permanecer activos para la conmutación por error, incluyendo espacios privados, VPN y Archivos adjuntos de pasarela de tránsito.

Los componentes básicos de la arquitectura de red CloudHub 2.0 son:

• Un equilibrador de carga HTTP
• Registros DNS de réplica de mula
• Espacios privados
• Servicios regionales

Para obtener más detalles, consulte Arquitectura de redes CloudHub 2.0.

Dominios de tocador

Cuando se crea un Espacio privado, recibe un nombre de destino DNS en el formato: <space-id>.<region>.cloudhub.io . En la implementación de una aplicación denominada test-api en ese Espacio privado, su extremo seguirá este formato:

CloudHub 2.0 también admite dominios personalizados, o de tocador, configurándolos en un Espacio privado utilizando contextos TLS y registros DNS. Para crear un contexto TLS en Gestor de tiempo de ejecución para un espacio privado, cargue el certificado público y la clave privada, luego agregue un extremo personalizado en la configuración de su aplicación para utilizar ese dominio. Cree un registro DNS (como un CNAME) que apunte su dominio de tocador al nombre de host predeterminado de su espacio privado.

Por ejemplo, una aplicación denominada test-api implementada en us-west-2 con DNS predeterminado 42y52r.usa-w2.cloudhub.io tiene un extremo de API de:

https://test-api-mwsklu-42y52r.usa-w2.cloudhub.io

Esta URL no utiliza un dominio vanidoso o personalizado. Para utilizar acme.com de modo que las URL de API aparezcan como https://test-api.acme.com, siga estos pasos.

1. Cree contexto TLS en Gestor de tiempo de ejecución con claves públicas y privadas.
2. Agregue un dominio de tocador en la configuración de la aplicación para utilizar ese dominio.
3. Cree un registro DNS en AWS Route 53 y configure una política de enrutamiento sencilla (por ejemplo, CNAME) de modo que el dominio de tocador se resuelva con el nombre de host predeterminado del espacio privado.

Para dominios personalizados, puede utilizar AWS Route 53 o cualquier otro servicio de CDN global con políticas de enrutamiento. En el siguiente diagrama, la Ruta 53 de AWS se utiliza con una política de enrutamiento “simple”. Cuando un consumidor de una red pública (externa) solicita acme.com, la Ruta 53 de AWS enruta la solicitud al controlador de entrada de espacio privado MuleSoft.

Utilice esta opción cuando las aplicaciones requieren conmutación por error: implemente una instancia en la región principal (por ejemplo, us-west-2) y otra en una región secundaria (por ejemplo, us-east-1).

Utilice un entorno existente en la región secundaria cuando sea posible; la creación de un nuevo entorno requiere esfuerzo adicional.

Ejemplo de aplicaciones implementadas en una región (EE.UU. Oeste 2) con una conmutación por error a otra región (EE.UU. Este 1)

En esta configuración, AWS Route 53 enruta el tráfico a los controladores de entrada para los espacios privados en US West 2 y US East 1. Una política de enrutamiento por error está configurada con una comprobación de estado.

Para una latencia más baja junto con una alta disponibilidad, utilice la estrategia de implementación descrita en el diagrama. Con esta estrategia, las aplicaciones se pueden implementar en dos regiones (us-west-2 y us-east-1 en este ejemplo).

Utilice la política de enrutamiento de latencia en Ruta 53 de AWS para enrutar solicitudes a la región que ofrece la latencia más baja manteniendo al mismo tiempo la alta disponibilidad. Política de enrutamiento de “latencia” en Ruta 53 de AWS para enrutar la solicitud de latencia más baja que aún tiene alta disponibilidad.

Aplicaciones implementadas en ambas regiones (EE.UU. Oeste 2 y EE.UU. Este 1) para una latencia más baja y alta disponibilidad

MuleSoft CloudHub 2.0 proporciona una base sólida para la resiliencia intrarregional, aprovechando principalmente la redundancia de réplicas automatizada y el equilibrio de carga inteligente. Dentro de una sola región de nube, la implementación de aplicaciones con múltiples réplicas garantiza que si una instancia falla, otras puedan asumir inmediatamente la carga de trabajo. El equilibrador de carga integrado distribuye de forma eficiente el tráfico entrante entre estas réplicas saludables, minimizando el tiempo de inactividad y garantizando la disponibilidad de servicio continua en condiciones de funcionamiento normales.

Sin embargo, depender exclusivamente de esta arquitectura de una sola región, incluso una con alta redundancia, presenta un riesgo significativo de un fallo generalizado y catastrófico en la región. La historia ha demostrado que incluso los proveedores de nube más fiables y tecnológicamente avanzados son susceptibles a incidentes perturbadores que pueden afectar a toda una región geográfica. Estos puntos únicos de fallo, aunque raros, pueden surgir de varios eventos, incluyendo:

• Incidentes de infraestructura a gran escala
• Fallos de energía importantes
• Interrupciones generalizadas de la red

Por lo tanto, para lograr una verdadera alta disponibilidad (HA) y recuperación de desastres (DR), una arquitectura debe diseñarse para trascender las limitaciones de un modelo de una sola región. La estrategia recomendada es la implementación entre múltiples regiones geográficamente distintas. Esta resistencia interregional garantiza que si una región de nube completa deja de estar disponible debido a un desastre inesperado, el tráfico puede fallar sin problemas en una instancia de aplicación que se ejecuta en una región separada y no afectada, garantizando una interrupción mínima del servicio y alcanzando objetivos de tiempo de disponibilidad máximo.

Arquitectura de redes CloudHub 2.0

Configuración de la conmutación por error entre regiones para colas estándar

Regiones de implementación de Object Store V2

Su región de implementación de establecimiento de objetos

Gulal Kumar es Arquitecto de Ingeniería de Software en Salesforce, con un enfoque en datos y arquitectura de integración. Con más de 20 años de experiencia en integración y API, programas de modernización, seguridad e iniciativas AIML, aporta una gran experiencia. Gulal se ha comprometido a avanzar en iniciativas de transformación de negocio, mejorando la seguridad y la resiliencia, promoviendo la excelencia de la arquitectura y liderando iniciativas de AIML entre varios dominios.

Ajay Nagaraju es Arquitecto de compañía y Director Senior de MuleSoft con más de 28 años de experiencia en arquitectura de compañía, integración de sistemas y transformación digital a gran escala. Ha liderado la arquitectura y la entrega de programas complejos y multimillonarios entre organizaciones Fortune 100 y Fortune 500, con una profunda experiencia en conectividad dirigida por API, SOA, tecnologías de nube y patrones de integración de negocio. Ajay se asoció estrechamente con el liderazgo ejecutivo para modernizar procesos de negocio, plataformas de datos y ecosistemas de integración, y es apasionado de la creación de arquitecturas ampliables, equipos de mentores e impulsar resultados de negocio mensurables a través de la tecnología.