At some point, you hit the performance limit of a single software stack on one physical server. That’s when you may load balance your WordPress site with one or more additional servers. It could be for scalability to handle more request, or as a failover precaution to increase the availability of your site. Whatever the reason, load balancing your site gets you both of these features, but it is a complex issue. We are just going to briefly discuss some the challenges you will encounter when attempting to load balance a dynamically generated site.
First and foremost, you need a means to load balance. Simply, you can use round-robin DNS and bounce between your servers as needed. This will cause problems, especially with session cookies. You will need a legitimate load balancer to handle this. The load balancer could be a software package like Pound (http://www.apsis.ch/pound/).
The second challenge is keeping your dynamic data in synchronization between your two (or more) web front ends. Consider that your site administrator could effectively log in to either web front end, post new content, and uploads a graphics asset to the uploads directory. However, the next request could be load balanced to other server, where this content may not exist.
Let’s look at the uploads directory first. This content is uploaded from the WordPress Dashboard to the uploads directory of that WordPress Installation. By default content is upload into /wp-content/uploads/. However, you can change the uploads directory in your Settings – Miscellaneous Dashboard. Depending on where you set your uploads folder, you could also reap the benefit of having shorter asset URLs.
At this point you have options. One options is to have shared folder that both web servers can access. Most likely this would be an NFS/Samba share on your third server, which server as your MySQL server. A second option is to use resync or similar tool to coordinate uploads between the two servers and make sure each jas the same assets in place.
The third challenge is your dynamic data that is store in the database. Assuming your database is not the bottleneck and the reason for load balancing, you could use a third server as your database server. Both web server can then read and write from the same source. This can be a more secure deployment architecture when your database server is not directly addressable on the public Internet, but it also creates a potential single point of failure. Technically, you are only load balancing the front-end web server situation.
Adding a second database server increase the redudancy the problem of keeping two MySQL database table in synchronization. MySQL server can be configured for replication in master-slave set up. Technically, this again, is not load balancing, because only one server is being accessed at a time, but this type of configuration does provide additional redundancy. Changes to the master MySQL database are replicated to the slave database in near time via a journaling log. Should the master database fail, the slave has a full set of data for manual cut over.
Finally, there is also a special WordPress-specific solution for multiple database servers. HyperDB was created by Automattic to handle the requirements of WordPress.com traffic. HyperDB is a full replacement for the built-in WordPress database access layer and includes functionality for using multiple databases, sharding or partitioning your database across multiple servers, and also replication and tiered failover. Unfortunately, the documentation is far from complete.
No comments:
Post a Comment