Contact Us 1-800-596-4880
  1. Homepage
  2. Flex Gateway (1.11)
  3. Flex Gateway Reference Architecture
  4. High Availability and Disaster Recovery

  5. Managed Flex Gateway High Availability and Disaster Recovery Deployments

Managed Flex Gateway High Availability and Disaster Recovery Deployments

CloudHub 2.0 manages Managed Flex Gateway replica deployments and controls the gateway’s high availability and disaster recovery.

This documentation covers specific details of Managed Flex Gateway high availability and disaster recovery. To fully understand CloudHub 2.0 high availability and disaster recovery, familiarize yourself with CloudHub 2.0 High Availability and Disaster Recovery.

The following diagram shows how multiple Managed Flex Gateway replicas are deployed. External traffic entering through CloudHub 2.0 Ingress is distributed across a load-balanced cluster of Managed Flex Gateway instances. Object Store v2 stores the gateway configuration and shared state data (such as HTTP caching and rate limiting) used by the gateways:

Managed Flex Gateway High Availability

CloudHub 2.0 manages Managed Flex Gateway high availability by ensuring:

  • At least two Flex replicas are always available and distributed across different availability zones in the private space. Traffic is distributed to replicas and zones evenly using a round robin traffic distribution.

    • If a replica fails, a new replica is spawned. While respawning the replica, the outstanding replicas receive a temporary spike in traffic until the new replica can accept traffic. These short spikes in traffic are visible in monitoring as a temporary spike in CPU usage.

    • Overloaded gateways don’t abruptly stop incoming traffic processing as a result of overload. However, overloaded gateways show gradual degradation of response time for requests until CPU subsides.

  • Large Managed Flex Gateways have more capacity allocated per replica. Large gateways autoscale up to three replicas across three availability zones depending on CPU usage.

  • Managed Flex Gateway Replicas use Object Store v2 for HTTP Caching and distributed Rate Limiting policies.

Managed Flex Gateway Configuration Storage

Managed Flex gateway stores API configurations locally in the private space kubernetes service. Locally stored configurations enable the gateway to start faster than an equivalently configured Self Managed Flex Gateway (that needs to download the configuration from Anypoint upon start). Locally stored configurations provide a layer of resiliency in the unlikely event that the Anypoint control plane isn’t reachable during Managed Gateway startup.

Managed Flex Gateway does not store contracts locally. Upon starting, Managed Flex Gateway downloads contracts from Anypoint Platform. If an API uses contracts, for example if the client ID enforcement policy is applied, the gateway downloads the contracts before accepting traffic.