Multiregion clusters
With DX Cloud, you can have a multiregion setup which improves Magnolia availability to 99.9% and is essential for a successful (and automated) disaster recovery process.
We accomplish this by configuring a multiregion setup for your project using an active/active approach.
An active/active multiregion setup focuses on distributing content across multiple clusters using a CDN while maintaining standalone, resilient clusters. Traffic is actively routed to multiple public instances based on location and availability.
-
The CDN handles routing, ensuring users access the closest available cluster. Using Fastly, we archive this by determining the nearest available cluster based on the request’s geolocation and routing traffic accordingly to the closest CDN Point of presence (POP).
-
Content is distributed from the Primary Cluster Author to both Primary Public Instances and Satellite Public Instances.
-
Beside Backup replication cross-region (magnolia-backup), no cluster configuration is automatically synced between the clusters to treat clusters as standalone entities and prevent error replication.
-
There is no Solr synchronization between clusters; each operates independently.
-
Sticky sessions or session sharing[1] (Redisson) is limited to instances within the same cluster and does not extend across multiple clusters.
-
This setup ensures high availability and improved performance by reducing latency through regional distribution.
CDN Routing
The CDN distributes traffic dynamically, ensuring users access the nearest available cluster.
Content distribution flow
Content is pushed from the Primary Cluster Author to all connected Public Instances, including both local and satellite clusters.
Advantages:
-
Reduces latency by serving users from the closest available public instance.
-
Ensures high availability even if one cluster experiences issues.
-
Eliminates dependencies on a single region for content delivery.
What is not synchronized across clusters?
In a multiregion setup, certain resources remain isolated per cluster and are not automatically synchronized. This means each cluster operates independently for these elements, ensuring security, stability, and fault isolation. Understanding these limitations helps teams design a resilient, secure, and well-managed multiregion architecture.
Resources that are not synced
The following resources must be managed separately in each cluster.
| Resource | Notes |
|---|---|
Search indexes (Solr) |
Each cluster maintains its own index, meaning searches may return different results if indexes are not manually aligned. |
Ingress configurations |
Custom domain routes and load balancer settings must be explicitly defined per cluster. This includes network routing rules. |
TLS/SSL certificates |
Certificates must be provisioned separately per cluster; they do not propagate automatically. |
Secrets |
Sensitive credentials such as environment variables and API keys remain local to each cluster and must be manually deployed or managed via a secure vault. |
Configuration maps (ConfigMaps) |
Cluster-specific application configurations do not sync between regions. |
Persistent storage |
Data storage is local to each cluster, preventing accidental cross-region data corruption. This includes PV/PVCs, databases and Magnolia-home. |
Kubernetes workloads |
Each cluster has its own independent workloads; there is no automatic cross-cluster replication. This includes Pods, StatefulSets, Deployments, and DaemonSets. |
CronJobs (scheduled tasks) |
Scheduled jobs run only in the cluster where they are defined. |
Why this matters
Keeping these resources isolated per cluster provides several key advantages:
-
Security: Secrets (API keys, credentials) do not automatically replicate across clusters, reducing risk in case of a security breach.
-
Stability: Workloads and databases are independent, preventing issues in one cluster from impacting another.
-
Compliance: Certain regulatory frameworks require strict separation of environments, which this approach enforces.
Setup
If you have opted for this feature, we set up everything in the backend for your multiregion cluster approach.
This can be for one additional remote satellite cluster or more.
That’s up to you.
However, we do need you to modify the values.yml file for your specific environments to accommodate the multiregion feature.
See how to configure the values.yml file for multiregion usage here.