I am creating a true load balancer topography for a WordPress hosting server, if it needs to scale up beyond what the current system can handle.
Scaling Levels
The current system is the “admin” path shown in the diagram, with no CDN or Load Balancing. It will handle a lot of traffic, but it is somewhat vulnerable to failure and overload. A simple and inexpensive extension of this system is to add CloudFront CDN, the “beta users” path.
For ultimate reliability and speed, I propose the “users” path: This will take most load off of the Virtualmin/Apache and Webmin/MySQL servers, because the user will be interacting only with CloudFront CDN and Varnish Caching Servers.
Load Balancing
The Load Balancing layer can be deployed separate from the current configuration, with DNS change to Route 53 for domains that require Load Balancing. If DNS routing for a domain goes to the Elastic IP, that traffic will interact directly with the primary Virtualmin/Apache server, which is OK for beta stage.
Traffic via Route 53 will be served from the Varnish instances, which will be load balanced, in multiple Availability Zones, and will serve cached WordPress pages as static HTML.
W3 Total Cache coordinates Apache and Varnish to provide updated disk-cached pages, and some data objects. CloudFront CDN pulls linked images, css, js, etc. from Apache via the W3 disk and opcode caches.
Redundancy and Fault Tolerance
More fault tolerance, speed and redundancy can be created via RAID10 arrays of multiple EBS Volumes, attached to the Virtualmin and Webmin instances. Creating a Storage Area Network for these volumes will provide shared /home and /var for the primary and slave instances.
Slave Server pairs for Virtualmin/Apache and Webmin/MySQL can be created to respond in round-robin fashion to the Varnish requests. With AWS Auto-scaling, more instances can be created on-demand if load on the backend servers is too great.
EBS snapshots of primary database server and web server will provide speedy recovery from catastrophic failure.
S3 backups of virtual domains on the primary Virtualmin/Apache server will provide speedy restoration of broken code or loss of files.
Be aware that creating a system with all of the elements I have described could be very expensive, and probably not necessary unless traffic is in the millions.
Website Workflow
WordPress sites:
- Create Virtual Domain, which automatically provisions WordPress with database and custom plugins/templates
- Build WordPress site via the Elastic IP (spoof DNS on your local machine to do this)
At Soft Launch (client approval or beta):
- Point A record to Elastic IP
- Set up W3 Total Cache with CloudFront and Varnish, but do not deploy
At Public Launch:
- Deploy W3TC
- Point A record to Route 53, or set name servers to Route 53














