In this article we cover a multi-region geographic distribution approach for WordPress CMS deployment. The application will be distributed as clusters across several regions within one cloud to ensure automatic fault-tolerance and low latency read operations for the users based on their location.
Such an approach brings high availability to the top level, allowing to ensure business continuity even in case of a data centre outage. On the other hand having several clusters in different locations over the globe can significantly improve website ranking from search engine side decreasing response time and consequently attracting more customers worldwide.
Multi-Region Cluster Topology
The WordPress geo distributed service here is represented with two topologies depending on the database cluster replication scheme. This separation provides more flexibility for better cluster adaptation to the project:
- MariaDB Asynchronous (Async) Primary / Replica Distribution with required number of regions from 2 to 5. This topology is more efficient for the cases where:
- read operations are significantly dominant over the write/update ones
- connection latency between Regions is more than few tens of milliseconds
- transaction time during replication process is not vital and may take a much more longer compared to a single cluster
- database requirements must be free of Galera cluster known limitations
- MariaDB Synchronous (Sync) Galera Cluster Distribution with required number of regions from 3 to 5. This topology may be considered as more suitable for the projects where:
- instant data availability is required in all Regions upon transaction complete
- latency between regions is very low
Below we’ll consider specifics for both approaches in case 3 Regions are chosen. And now let's walk through all of the components to get complete clarity into how and why this solution works the way it does.
WordPress Cluster Components
Premium CDN
CDN Add-On that provides CDN integration to WordPress clusters. It leverages a highly interconnected global network, featuring massive bandwidth capacity, advanced caching and acceleration strategies along with HTTP/3 support in order to provide lightning-fast WordPress static assets loading from the nearest PoP(point of presence).
This CDN network spans the globe, with 165+ Super PoPs located on 6 continents. CloudJiffy customers get premium traffic for the same price across all continents and countries with no surprising bills based on geographic locations.
Let’s Encrypt SSL
To ensure a secure connection the provided Let's Encrypt SSL Add-on automates trusted certificates issuing procedure, including custom domain validation and automatic certificate renewal.
LiteSpeed Web ADC
LiteSpeed Web ADC is an acronym of LiteSpeed Web Application Delivery Controller (LSADC) and related to a new generation of high-performance load balancing software solution.
It supports modern HTTP/3 protocol and flexible load balancing algorithm for optimal performance.
LiteSpeed Web Server
LiteSpeed Web Servser is a auto scalable, high performance and low memory consumption web server enriched with a wide feature set such as HTTP/3 support and variety of matchless addons for popular hosting platforms WordPress CMS allowing even dynamic content loading faster as a result of implementing of ESI cache, 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
Redis is high-performance storage used as a high speed caching solution. A WordPress object caching stores in memory the database query results that have been loaded. Then it serves them up faster the next time they are requested so the database doesn’t have to be queried again.
Database Cluster Topology
Latency Evaluation
Before considering database replication topologies, let's get a better understanding of such an important criteria as the latency between the regions, since it affects the database scheme choice.
Latency, measured and represented as “ping”, refers to the average round trip time that it takes a package to go to the destination host, and then back to the source. It is measured in milliseconds (ms), so if ping is “20ms” then it takes approximately minimum 20 milliseconds for the database nodes to approve/apply requests from the source server. I may easily evaluate the latency:
1. Create new environments one per each Region that are going to use for the WordPress cluster. Use one of the VPS templates available.
2. Log in to the VPS node in each Region via WebSSH and ping the others by their private addresses. For example, we have created two environments, one in US and one in the DE. The pinging shows that average latency is 0.061 ms
3. To get latency between all the Regions I should do cross-pinging among all of them.
4. In case the average result is less than or equal to 20ms we recommend using Galera Cluster as database topology and if the latency is more than 20ms use Primary/Replica distribution.
Sync Galera Cluster Distribution
As storage for dynamic content, the MariaDB Galera Cluster is employed as a multi-data center (DC) topology or in other words this is a single cluster with members grouped into segments and located across distant data centres.
Due to true multi-primary topology with automatic new node provisioning Galera ensures no data loss when one of the nodes crashes, no lost transactions, and supports multi-cloud and multi-region deployments.
It has a replication scheme segmented as 3 nodes in Region 1, 2 nodes in Region 2 and 2 nodes in Region 3. Having an odd number of cluster members the quorum is ensured all the time.
Async Primary/Replica Distribution
As it was mentioned above this database topology requires minimum two destination Regions. In this case a pre-configured replication scheme with two interconnected primary databases will be created. The primary server at Region 1 will be handling the reads/writes and primary at Region 2 will be handling the reads only. When primary at Region1 goes down, another one starts accepting the writes.
If the number of Regions chosen upon installation is more than two, all other Regions will have the replica database server in each.
So, as for our example the topology comprises nodes as follows:
- Primary node at Region 1 serves writes (red arrows) and reads (black arrows) operations
- Primary node at Region 2 by default serves reads operations but starts handling writes if initial primary database becomes unavailable
- Replica node at Region 3 is used for reads operations only
GlusterFS Cluster Shared Storage
A shared storage auto-cluster is used to keep static assets in each Region. This is a redundant clustered storage array, also known as a distributed file system or, as the GlusterFS documentation mentions, a trusted storage pool. It provides functionality similar to RAID 1 configuration over the network: where each independent server contains its own copy of the data, allowing WordPress to access any of these copies, thereby helping to balance the read load.
Thus, every Region comprises the GlusterFS cluster which consists of three nodes and acts like a NAS server with a mirrored RAID array inside.
To ensure data synchronization between regions the GlusterFS native Geo-Replication feature is used. It’s built by the Primary-Replica model (formerly known as Master-Slave) where one GlusterFS cluster serves as Primary and accepts the writes. Then it replicates data to the Replicas. With respect to the front-end the Replicas serve the reads operations only.
Due to platform networking architecture, all available Regions are transparently interconnected at the environment level like they are in the same LAN. So, the GlusterFS Geo-Replication over Local Area Network Deployment Scenario is implemented.
Multi-Region WordPress Cluster Installation
Using CloudJiffy Cloud Scripting functionality, we’ve automated the following actions within the offered package:
- Configure application servers and their scaling
- Set up load balancing for traffic distribution
- Clusterize databases, tune replication and connection
- Configure scalable network filesystem storage and cache server
- Deploy and configure WordPress application
- Add SSL certificate
- Enable add-ons for domain binding, CDN, file synchronization, etc.
- Control and perform updates of the servers
- Cluster overload prevention
- Custom domain binding
- Enable WordPress multisite network mode
Let’s take a walk via the installation steps.
Multi-Region WordPress Deploy
Open the CloudJiffy Marketplace directly at the dashboard, find Multi-Region WordPress Cluster.
Choose the destination Regions. According to the multiregional functionality, WordPress can be spread across several Regions to achieve a maximum high availability and outstanding failover, even in case of the data centre failure.
Horizontal Auto Scaling Strategy
Pick the Low Load, Medium Load or High Load value to define an Automatic Horizontal Scaling Strategy.
The Scaling Strategy feature aims to foresee possible upcoming growth of cluster workload and scale in/out horizontally with specially designed triggers in order to prevent WordPress application downtime. Based on our experience, we chose three scaling scenarios for application servers to prevent overload if any:
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%
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%
Scaling Load Growth=High Load:
- adds 2 application server node if the workload is higher than 30%
- removes 1 application server node if the workload goes below 10%
Advanced Features Out-of-Box
Choose the Advanced Features required for the web site:
- WordPress Brute Force Attack Protection protects WordPress applications from large-scale brute force attacks, which have the potential to bring down entire servers, trying to gain access to a website by repeatedly attempting to guess a valid username and password.
- The Web Application Firewall(WAF) secure feature will be enabled by default in case the LSADC will be installed. WAF comes with Layer-7 Anti-DDoS Filtering as well as IP level bandwidth and request rate throttling. It won't degrade the LSADC performance since it can be tuned to withstand dynamic requests only.
- Install Let’s Encrypt SSL with Auto-Renewal add-on allows me to issue and use a trusted certificate for a custom domain for free. Add-on’s built-in functionality employs automatic periodical certificate renewal in order to prevent certificate expiration. User is informed about add-on actions by email.
- Install Lightning-Fast Premium CDN with 160+ PoPs. This add-on integrates Verizon Edgecast CDN into WordPress application.
- Install WordPress Multisite Network. This option activates a multisite built-in feature to create and run multiple websites using the same WordPress installation and manage them via a single dashboard. Learn more how to set up and configure WordPress Multisite Network in CloudJiffy PaaS.
Note: Take into account the web-site increased performance costs money:
- With CDN add-on installed, that are charged for traffic
- LSWS web server is licensed and charged hourly if the resource limit for container is above 16 cloudlets
- Billing for usage of LSADC is based on the amount of traffic passed through, but not more than 65$ per month according to the developer’s license
Cluster Installation Notification
After choosing all required options, just click Install button and wait a few minutes for the cluster to be created. Afterwards, the successful installation window appears and contains WordPress application URLs and credentials to access the admin panel.
A corresponding email will be sent to the mailbox with all necessary information to manage the software stacks and WordPress CMS itself.
Keep in mind that after domain change the Admin Panel URL will be updated as well.
Custom Domain Binding
A final step to get the website ready for production is to come up with a custom domain (for example wpmultiregion01-demo.com) and bind it to all subclusters.
1. To do this create an A record using a public IP address provisioned for each subcluster’s load balancer at the domain registrar.
2. Open Load Balancer Add-Ons on WordPress Cluster Primary environment and press Configure button on Let’s Encrypt Free SSL add-on.
3. Replace domain name generated by platform with custom one and press Apply to issue valid SSL certificate for it.
4. Finally, it is required to apply a new domain name to the WordPress Site Address URL setting using the add-on with the same name.
From now on I should use the custom domain accessing WordPress web site and admin panel.
DNS Load Balancing
The geo distributed cluster requires traffic load balancing between subclusters. By default it is ensured via the DNS Round-Robin algorithm. But such a solution can be improved with:
- endpoints health checks
- smart routing based on clients geographic location
- latency evaluation to the endpoint
In case the CloudFlare Registration was chosen, I may go further and set up a DNS Load balancer at CloudFlare with smart Traffic Steering options. To do this create an Origin Pool for each subcluster and respective Monitors to perform health checking of the pools.
This option allows to define the load balancing algorithm based on current subscription. For example with the base $5 subscription plan that I may use:
- standard failover algorithm marked as Off, which routes traffic from unhealthy pool to the next healthy one
- Random: traffic is routed to a healthy pool at random
For the enterprise level subscription the other options are available:
- Dynamic steering - identifies the fastest pools, and directs user requests to the most responsive origins leveraging round trip time(latency) analysis.
- Geo steering - routes traffic to the pools based on the client’s Region or point of presence. Users specify the pools to which the load balancer should direct traffic for a given geographical Region or point of presence. Several pools can be specified to the same Region, and the balancer will use them in failover order.
Enterprise-level DNS load balancing can help significantly improve a site's search engine rankings. Get more details on how to set it up at CloudFlare in our tutorial: DNS Load Balancing for Highly Available Enterprise WordPress Cluster. Alternatively to the proposed load balancing solution at CloudFlare i may implement the own one.
Congratulations! Now I have fully-functional production clusters of WordPress distributed across several cloud regions for enterprise availability and uptime. Check this functionality at one of CloudJiffy service providers with several data centers and proven performance of WordPress hosting.