--- schema_version: "1" id: f072368625714b1797c325d2fe1d7603c9897bcc3b12e04f75410b6dc0bb6676 title: Self Managed Omni Gateway High Availability, Disaster Recovery, and Multi-Region Deployments collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/gateway/latest/gateway-architecture-multi-region.md canonical_url: https://docs.mulesoft.com/gateway/latest/gateway-architecture-multi-region source_site: docs.mulesoft.com content_type: documentation content_hash: fcfc6793e364fba2bc7e5da075ad328e4c1acb41407f3599c1a38fc679ccb5a1 description: MuleSoft Documentation Site release: "1.14" latest: true --- --- product: Omni Gateway version: 1.14 is-latest-version: true --- # Self Managed Omni Gateway High Availability, Disaster Recovery, and Multi-Region Deployments > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Install Omni Gateway in multiple regions to reduce latency and ensure live failover. You can configure most implementations with either multiple Omni Gateways or multiple Omni Replicas. Depending on which you choose, there are different considerations for Redis shared storage, policies, and logging. To learn more about Omni Replicas, see [Omni Replicas](https://docs.mulesoft.com/gateway/latest/#replicas). > [!NOTE] The implementations below discuss Redis shared storage considerations. You can also use > distributed shared storage, which doesn’t require cross-region synchronization. However, data is > lost when all replicas go down (scaled to zero replicas). All the following diagrams show Omni Gateway running in Connected Mode. For Omni Gateway running in Local Mode, the only difference is that Anypoint Platform isn’t present in the deployment model. This doesn’t affect how information flows between Omni Gateway and the upstream and downstream services. The implementation diagrams use Kubernetes terminology, but you can extend the architecture to other technology stacks that have the appropriate network controls applied. ## Implementation 1: High Availability with the Same APIs in Two Separate Regions Implementation 1 provides high availability for non-region-specific traffic. The DNS service is configured for active-active failover, meaning each region services traffic at all times. ### Implementation 1A: Cross-Regional Omni Gateway In this implementation: - A single Omni Gateway has Omni Replicas distributed across multiple regions. - Omni Gateway is registered once in Anypoint Platform and deployed across multiple regions and availability zones. - Logs and metrics for each Omni Gateway are consolidated in Anypoint Platform. - The DNS service is configured for active-active failover to direct traffic to any region at all times. - APIs deployed to the Gateway are available in all regions and availability zones. - API configurations, including upstream services and policies are the same for all regions. Upstream services must be region-agnostic, meaning either the DNS is local or it lacks any reference to the region. - If using Redis shared storage: The Redis cluster must be replicated across regions or Redis shared storage can’t be used. Redis replication is required when traffic isn’t region-specific. - If using Redis shared storage: The only cross-regional traffic is Redis synchronization. - If using distributed shared storage: No cross-region synchronization is needed. In the following diagram, Omni Replicas in different regions and availability zones have distinct Kubernetes deployments: ![A detailed view of implementation 1A, which contains the necessary services to support high availability in for Omni Replicas deployed in different regions](/mulesoft/current/en-us/gateway/latest/_images/high-availability-1a.png) ### Implementation 1B: Region-Specific Omni Gateway In this implementation: - Each region has a distinct Omni Gateway with all resources as independent entities. - A separate Omni Gateway is registered for each region. - Each region-specific API instance has distinct metrics, alerts, and logs in Anypoint Platform. - Policies are region specific even if the configuration is similar across regions. - The DNS service is configured for active-active failover to direct traffic to any region at all times. - API deployments are specific to each Omni Gateway. For each API a region supports, you must deploy an API instance to the region’s Omni Gateway. - API Groups can share contracts (access requests) across regions. An API Group might not be required for your configuration. - If using Redis shared storage: Redis does not require synchronization. - If using distributed shared storage: No cross-region synchronization is needed. - There is no cross-regional traffic. In the following diagram, all APIs are duplicated and don’t require identical configurations: ![A detailed view of implementation 1B, which contains the necessary services to support high availability for region-specific Omni Gateways](/mulesoft/current/en-us/gateway/latest/_images/high-availability-1b.png) ## Implementation 2: Disaster Recovery for APIs This implementation is similar to [Implementation 1A: Cross-Regional Omni Gateway](#implementation-1a). However, the DNS service is active-passive, so the standby region only receives traffic if the primary region becomes unhealthy. This implementation is less complex to configure than implementation 1A. If using Redis shared storage, Redis synchronization isn’t required if a cache loss during failover is acceptable. If using distributed shared storage, no synchronization is needed. In the following diagram, Omni Replicas in different availability zones have distinct Kubernetes deployments. Region B provides high availability but receives traffic only if region A is unhealthy: ![A detailed view of implementation 2, which contains the necessary services to enable disaster recovery for APIs on Omni Gateway](/mulesoft/current/en-us/gateway/latest/_images/high-availability-2.png) ## Implementation 3: Direct Traffic to the Closest Region In both [Implementation 3A: Direct Traffic to APIs With the Same Policies](#implementation-3a) and [Implementation 3B: Direct Traffic to APIs With the Different Policies](#implementation-3b), Omni Gateway directs traffic to the most convenient region to reduce latency. Choose which implementation according to your policy requirements. ### Implementation 3A: Direct Traffic to APIs With the Same Policies This implementation is similar to [Implementation 1A: Cross-Regional Omni Gateway](#implementation-1a) and has the same considerations. However, if using Redis shared storage, Redis replication is not required because requests are sent to specific regions. Configure high availability or disaster recovery zones in each region to ensure API availability: ![A detailed view of implementation 3A, which contains the necessary services to route customer requests to the closest region](/mulesoft/current/en-us/gateway/latest/_images/high-availability-3a.png) ### Implementation 3B: Direct Traffic to APIs With the Different Policies This implementation is similar to [Implementation 1B: Region-Specific Omni Gateway](#implementation-1b) and has the same considerations. Deploy region-specific gateways and apply the necessary policies to the different APIs. Configure high availability or disaster recovery zones in each region to ensure API availability: ![A detailed view of implementation 3B, which contains the necessary services to route customer requests to the closest region](/mulesoft/current/en-us/gateway/latest/_images/high-availability-3b.png) > [!NOTE] To apply SLA rate limiting across all regions, the rate limits must be the same for all > regions. Use API groups to consolidate the contracts.