Global WordPress High Availability Using Tungsten Clustering, Part 1

Introduction

Running highly-available WordPress is especially challenging, because WordPress is not by nature Active/Active-aware, and will refuse to run in an environment where database writes are active-active.

In this blog post Part 1, we will explore the design considerations for making WordPress highly-available at the database layer. We also cover some other WordPress HA architecture needs, like the need for a shared filesystem.

In Part 2 of this blog post, we will go step-by-step through the installation procedure resulting in an up-and-running WordPress HA installation backed by Tungsten Clustering in AWS by using a provided CloudFormation template.

Tungsten Clustering has multiple topologies designed to allow WordPress-friendly database deployments, namely:

• Standalone - STD - a single writable 3-node cluster, all nodes in the same site/region
• Composite Active-Passive - CAP - one active, writable cluster and one or more passive, read-only clusters in one or more sites/regions
• Dynamic Active-Active - DAA - two or more active, writable clusters in one or more sites/regions, configured to write to only one cluster at a time

The Problem

WordPress must have a shared database resource with a single writable Primary to avoid guaranteed conflicts if writes occur in more than one place from multiple WordPress web servers.

This is due to the fact that WordPress is not Active/Active-aware - in short, this means that any database clustering solution which relies upon a multi-write architecture will not fly in the WordPress world.

Additionally, a shared filesystem is required so that any changes to the website (i.e. uploads) are seen by all web servers.

Enter Tungsten Clustering!

Solution Summary

Let’s examine the solution architecture which will allow WordPress to be highly available.

For WordPress to be happy, all database writes from every Web/PHP server must be handled by a single MySQL Server instance, so there are zero write conflicts. Filesystem writes also need to be shared for the architecture to succeed. Essentially, every web server instance needs to see the exact same database and filesystem data at the same time.

Our solution architecture uses Tungsten Clustering to provide the highly-available database layer, and AWS EFS to provide the shared NFS filesystem.

A Simple, Static WordPress Architecture in AWS

The reference architecture for this blog post uses a very simple, static stack created in AWS using just EC2 instances for the web and database servers, one Elastic File System (EFS) for shared NFS, and one Elastic Load Balancer (ELB) to route WordPress requests to any available web server.

The architecture looks like this:

The ingress WordPress traffic is handled first by the ELB. The http/s requests are then sent to one of several Web/PHP EC2 servers running Apache 2.4, each in a different Availability Zone (AZ). Each web server is configured to communicate with the Tungsten Cluster database layer via the Tungsten Connector proxy, which is typically installed locally on each web server for the best availability. The shared NFS filesystem is provided by EFS.

Please note that the AWS ELB serves one region only. For a global WordPress service, either round-robin DNS or a Global Load Balancer will be required.

Please also note that NFS performance tends to degrade over long distances, so other file-sharing methods may also be used for this purpose, as long as all WordPress web servers share the same files.

Of course, there are MANY possible ways to create a viable WordPress architecture, and the one above is just for the purposes of demonstration. For a production-ready design, please contact us to work together on the correct solution for your particular use-case. As always, YMMV!

Solution Discussion

To solve the active-active write conflict problem immediately, Tungsten Clustering offers three different topologies (Standalone, Composite Active-Passive and Dynamic Active-Active) that send writes to a single Primary world-wide. These writes are then distributed to all nodes in all sites asynchronously by the Tungsten Replicator layer, allowing for a robust and resilient database layer.

The demo WordPress architecture shown above uses the most basic topology, Standalone, which has three EC2 instances running MySQL Server and Tungsten Cluster.

The secret sauce of this architecture using any topology offered is the Tungsten Connector installed on the web server EC2 instances. Tungsten Connector is an intelligent, cluster-aware proxy that routes MySQL queries to the appropriate database server, optionally automatically sending read-only requests to an available replica node.

This Connector knows when a failover (or a manual switch by a human) has occurred, and will route traffic to the new primary. This is due to the tight integration with the Tungsten Manager, which is responsible for the health checking and management of the cluster.

WordPress Implementation Facts

Database Host Configuration

To use the Tungsten Connector proxy once it is installed on the web server, WordPress/PHP must be configured to use TCP/IP by specifying the port along with the hostname/IP in the wp-config.php file. For example:

define('DB_HOST','127.0.0.1:3306’);

Database Table Engine Configuration

Tungsten Clusters require InnoDB tables to function properly. MyISAM is not ACID compliant, so manual intervention may be required in the event of a failover. Please set the default engine to InnoDB to limit exposure to this problem.

Older WordPress tables were almost all MyISAM, and should be converted to InnoDB.

The Topologies, Illustrated

Now let’s examine STD, CAP and DAA topologies in detail.

Standalone Cluster (STD)

For the most basic use-case where all of the nodes are in the same region or data center, a Standalone cluster is sufficient. This topology is pictured above.

Standalone features:

• 24x7 data access
• Off-the-shelf MySQL
• SQL load balancing
• Simple management
• Minimum 3 nodes
  • 1 Primary
  • 2 Replicas
• Odd number of nodes
• Single datacenter/region
• Lowest complexity

Composite Active-Passive (CAP)

When the use-case demands are more complex, requiring that the database be available in multiple regions for disaster recovery and maintenance purposes, the Composite Active-Passive topology provides that.

CAP features:

• Minimum 2 clusters
• Only one Cluster for read/write (Active)
• All other clusters read-only (Passive)
• Can be Cross-Region - span multiple regions and data centers in any combination
• Single, write-able Primary - all writes are sent to the single Primary node in the sole Active cluster, no conflicts
• Managed cross-site replication - able to move the Active site role/Primary node role to another site/node with a single command, either for maintenance or in the event of a site-wide failure in the Active cluster
• Optionally route read requests to local replicas for faster client response times
• Often used for Disaster Recovery
• Simple to use and implement

Dynamic Active-Active (DAA)

When the use-case requires that the database be available in multiple regions for active use purposes, the Dynamic Active-Active topology is the answer.

DAA features:

• Minimum 2 Clusters
• All clusters are read/write
• Multiple write-able primaries, but the connectors are configured to write to a single primary
  • the Connector is configured so that all writes are sent to the Primary node in the specified Active cluster, no conflicts
• The other sites remain writable, and one will be used if the original site is fully unavailable
• Can be Cross-Region - span multiple regions and data centers in any combination
• Managed cross-site replication – the managers now are aware of and control the cross-site Replication services
• all sites are writable with a local Primary node, no switch or failover needed
• optionally route read requests to local replicas for faster client response times
• Vastly simplified setup and control

Topology Comparison

For single-site or single-region WordPress, the Standalone (STD) topology is a great fit. This is the topology used for this blog post.

For situations where cross-site, one-step disaster recovery is needed, the Composite Active-Passive (CAP) topology fits the need.

When servicing users in multiple regions requiring both automatic local HA and automatic site-level HA, the Dynamic Active-Active topology (DAA) would work best.

WordPress works equally well on all three topologies, so the choice is up to you!

CAP and DAA topologies cover the MySQL database layer globally by placing a managed cluster in each site/region fronted by the Tungsten Connector proxy for proper query routing. You will also need a shared filesystem like NFS (i.e. AWS EFS or similar).

Wrap-Up

In this post we examined in depth how to implement high availability for global WordPress deployments using Tungsten Clustering for the database layer, allowing WordPress to span data centers and cloud regions world-wide. The next post, Part 2, will feature a step-by-step recipe for launching a WordPress HA deployment in AWS using a provided CloudFormation template.

Smooth sailing!