
Are you looking to deploy your WordPress CMS with a multi-region geographic distribution approach In this article, we'll explore how to distribute your WordPress application as clusters across several regions within our cloud platform to …

Are you looking to deploy your WordPress CMS with a multi-region geographic distribution approach? In this article, we’ll explore how to distribute your WordPress application as clusters across several regions within our cloud platform to ensure automatic fault-tolerance and low-latency for users based on their location.
Achieving High Availability and Business Continuity: This approach can bring high availability to the top level, allowing you to ensure business continuity even in case of a data center outage. By having several clusters in different locations across the globe, your website can handle large amounts of traffic without experiencing downtime.
Improved Website Ranking and Performance: Having multiple clusters in different regions can also significantly improve your website ranking on search engines by decreasing response time and attracting more customers worldwide. With low latency read operations, your website’s users will experience faster page load times, leading to improved user experience and ultimately, more conversions.
Multi-Region Cluster Topology
The WordPress geo-distributed service can be deployed using two different topologies depending on the database cluster replication scheme. This separation provides more flexibility and better cluster adaptation for projects.
Two recommended topologies are:
– MariaDB Asynchronous (Async) Primary/Replica Distribution, which requires a minimum of two regions and a maximum of five. This topology is efficient for projects where:
- Read operations outweigh write/update operations
- Connection latency between regions is more than a few tens of milliseconds
- Transaction time during the replication process is not critical and can take much longer compared to a single cluster
- Database requirements are free of known Galera cluster limitations.
– MariaDB Synchronous (Sync) Galera Cluster Distribution, which requires a minimum of three regions and a maximum of five. This topology is suitable for projects where:
- Instant data availability is required in all regions upon transaction completion
- Latency between regions is very low.
Next, we’ll examine the specifics of both approaches when three regions are selected. We’ll go through each component to gain a better understanding of how and why this solution operates as it does.
Premium CDN
A CDN Add-On that integrates with WordPress clusters and provides lightning-fast loading of static assets from the nearest point of presence (PoP) using a highly interconnected global network with advanced caching and acceleration strategies, HTTP/3 support, and massive bandwidth capacity. The network spans 6 continents with 165+ Super PoPs, and FullHost.Cloud customers get premium traffic for the same price across all locations with no unexpected bills based on geography.
Let’s Encrypt SSL
A provided Add-On that automates the issuance of trusted certificates, including custom domain validation and automatic certificate renewal, to ensure a secure connection.
LiteSpeed Web ADC
Short for LiteSpeed Web Application Delivery Controller, this is a new generation of high-performance load balancing software solution that supports the modern HTTP/3 protocol and flexible load balancing algorithm for optimal performance.
LiteSpeed Web Server
An auto-scalable, high-performance, and low-memory consumption web server with a wide feature set, including HTTP/3 support and a variety of unique add-ons for popular hosting platforms like WordPress CMS. The add-ons allow for even faster loading of dynamic content through ESI cache implementation, CSS and JavaScript optimization, image optimization, browser and object cache support, CDN support, built-in WAF, Geo-DNS, CAPTCHA, IP throttling, and even WordPress brute force protection.
Redis
A high-performance storage solution used as a high-speed caching solution for WordPress. It stores the results of previously loaded database queries in memory, serving them up faster the next time they’re requested and reducing the need to query the database again.
Database Cluster Topology
To select an appropriate database replication topology for a WordPress geo-distributed service, it is crucial to evaluate the latency between the regions. Latency is a measure of the average round trip time that it takes a package to travel to the destination host and back to the source. It is measured in milliseconds (ms), with higher values indicating longer wait times for database nodes to approve/apply requests from the source server.
To measure latency, follow these steps:
1. Create a new environment for each region you plan to use in the WordPress cluster using one of the available VPS templates.
2. Log in to the VPS node in each region via WebSSH and ping the other nodes using their private addresses. For example, if you have created two environments in Vancouver and Oregon, pinging shows that the average latency is 63.967 ms.
3. To get the latency between all the regions, perform cross-pinging among all of them.
4. If the average result is less than or equal to 20ms, we recommend using the Galera Cluster as the database topology. If the latency is greater than 20ms, use Primary/Replica distribution.
Galera Cluster for Synchronous Distribution
For dynamic content storage, the multi-data center topology uses MariaDB Galera Cluster as a single cluster with members grouped into segments located across remote data centers.
With a true multi-primary topology and automatic new node provisioning, Galera ensures zero data loss, no lost transactions, and supports multi-cloud and multi-region deployments.
The replication scheme is segmented as three nodes in Region 1, two nodes in Region 2, and two nodes in Region 3, ensuring a quorum at all times with an odd number of cluster members.
WordPress Async Primary/Replica Distribution
The Async Primary/Replica Distribution is a database topology that requires at least two destination regions. It involves creating a pre-configured replication scheme with two interconnected primary databases. The primary server at Region 1 is responsible for handling both reads and writes, while the primary server at Region 2 only handles reads.
In case the primary server at Region 1 goes down, the primary server at Region 2 starts accepting writes. If more than two regions are chosen, each of the other regions will have a replica database server.
For example, the topology may include nodes as follows:
- Primary node at Region 1 serves both write and read operations
- Primary node at Region 2 serves read operations only by default, but takes over write operations when the initial primary database becomes unavailable
- Replica node at Region 3 is used for read operations only.
GlusterFS Cluster Shared Storage
In order to store static assets in each region, a shared storage auto-cluster is utilized. This cluster is a redundant clustered storage array, also known as a distributed file system or GlusterFS trusted storage pool. This functionality is similar to RAID 1 configuration over the network, with each independent server containing its own copy of the data. WordPress can access any of these copies, balancing the read load.
Each region comprises a GlusterFS cluster with three nodes, which acts like a NAS server with a mirrored RAID array inside. Data synchronization between regions is ensured by the GlusterFS native Geo-Replication feature, which follows the Primary-Replica model. In this model, one GlusterFS cluster serves as the primary and accepts writes. The data is then replicated to the replicas, which serve reads operations only from the front-end.
In this scenario, since the available Regions are interconnected at the environment level as if they were in the same local area network, the GlusterFS Geo-Replication is deployed over a local area network. This means that the replication process between the Primary and Replica clusters can take place within the same network, allowing for faster and more efficient data transfer between the clusters. This deployment scenario takes advantage of the platform’s networking architecture to optimize the data replication process and improve the overall performance of the multi-Region WordPress cluster.
Multi-Region WordPress Deploy
Access the FullHost.Cloud Marketplace directly from the dashboard and look for the Multi-Region WordPress Cluster and select it.
Choose the desired destination Regions. With the multiregional functionality, WordPress can be distributed across multiple Regions to ensure maximum high availability and failover protection, even in the event of a data center failure.
Horizontal Auto Scaling Strategy
Select a Low Load, Medium Load, or High Load value to define an Automatic Horizontal Scaling Strategy.
To anticipate possible upcoming growth of cluster workload and scale in/out horizontally with specialized triggers in order to avoid WordPress application downtime, the Scaling Strategy feature has been implemented. We have selected three scaling scenarios for application servers to prevent overload:
Scaling Load Growth=Low Load:
- Adds 1 application server node if the workload is higher than 70%
- Removes 1 application server node if the workload goes below 20%
Multi-Region WordPress Low Load
Scaling Load Growth=Medium Load:
- adds 1 application server node if the workload is higher than 50%
- removes 1 application server node if the workload goes below 20%
Multi-Region WordPress Medium Load
Scaling Load Growth = High Load:
- Adds 2 application server nodes if the workload is higher than 30%
- Removes 1 application server node if the workload goes below 10%
Multi-Region WordPress High Load
Advanced Features Out-of-Box
Select the desired Advanced Features for your web site from the following list:
- WordPress Brute Force Attack Protection: This feature protects WordPress applications against large-scale brute force attacks that could potentially bring down entire servers. It prevents unauthorized access to the website by blocking repeated attempts to guess a valid username and password.
- Web Application Firewall (WAF): This secure feature is enabled by default in case LSADC is installed. It comes with Layer-7 Anti-DDoS Filtering and IP level bandwidth and request rate throttling. It can be configured to withstand dynamic requests only, without degrading the LSADC performance.
- Install Let’s Encrypt SSL with Auto-Renewal add-on: This feature enables you to issue and use a trusted SSL certificate for your custom domain for free. The add-on’s built-in functionality automatically renews the certificate periodically to prevent it from expiring. You will receive email notifications about the add-on actions.
- Install Lightning-Fast Premium CDN with 160+ PoPs: This add-on integrates Verizon Edgecast CDN into your WordPress application to provide high-speed content delivery with 160+ Points of Presence (PoPs).
- Install WordPress Multisite Network: This feature activates the built-in multisite capability of WordPress to create and run multiple websites using the same WordPress installation and manage them via a single dashboard. You can learn how to set up and configure WordPress Multisite Network in FullHost.Cloud PaaS.
Note: Keep in mind that enabling these advanced features may result in additional costs for increased web-site performance:
- With CDN add-on installed, you are charged for traffic.
- LSWS web server is licensed and charged hourly if the resource limit for the container exceeds 16 cloudlets.
- Billing for the usage of LSADC is based on the amount of traffic passed through, but not more than $65 per month, as per the developer’s license.
Cluster Installation Notification
Simply click on the Install button after selecting all the necessary options and wait a few minutes for the cluster to be created. Once the installation is successful, a notification window will appear that contains the URLs and credentials required to access the WordPress admin panel.
You will also receive an email with all the necessary information to manage the software stacks and the WordPress CMS.
Please note that if you change your domain, the URL for accessing the Admin Panel will also be updated accordingly.
Custom Domain Binding
To get your website ready for production, you’ll need to assign a custom domain (such as multiregion.jele.website) and bind it to all subclusters.
Follow these steps:
1. Create an A record at your domain registrar using the public IP address provisioned for each subcluster’s load balancer.
For our example we create three records in our DNS Manager.
2. Open the Load Balancer Add-Ons on your WordPress Cluster Primary environment and click the “Configure” button on the Let’s Encrypt Free SSL add-on.
3. Replace the domain name generated by the platform with your custom domain and click “Apply” to issue a valid SSL certificate for it.
4. Finally, update the WordPress Site Address URL setting using the WordPress Site URL add-on with your custom domain.
After completing these steps, you should be able to access your WordPress website and admin panel using your custom domain.