The load balancer is a single point of failure. If it starts pining for the fjords, the web servers behind it will become inaccessible. To make the system more reliable, you can install a second load balancer in an HA configuration with the first. Detailed instructions, which use the Ultra Monkey package that you’ve already installed, can be found in “How To Set Up A Loadbalanced High-Availability Apache Cluster,” (http://www.howtoforge.com/ high_availability_loadbalanced_apache_cluster).
You may not need HA for the Apache servers themselves, because ldirectord is already prodding them everycheckintervalseconds for status and adjusting weights, which is similar in effect to the heartbeat of HA.
Adding Other LB Services
We’ve used Apache web servers as this chapter’s example because they’re the most likely to be part of a server farm. Other services that could benefit from LB/HA include MySQL, email servers, or LDAP servers. See “How To Set Up A Load-Balanced MySQL Cluster” (http://www.howtoforge.com/ loadbalanced_mysql_cluster_debian) for a MySQL example.
Scaling Without LB and HA
If you offered a wonderful service, would your server survive a Slashdotting (i.e., a huge activity spike)? If not, your credibility could suffer and many visitors might never return. But because implementing LB and HA requires significant effort and hardware investments, it’s worth considering other solutions. There are ways to get more from your present server. For instance, you can disable .htaccess files in your Apache configuration (AllowOverride None), and use mod_expires to avoid stat calls for infrequently changed files such as images. Apache books and web sites contain many such optimization tips.
Once you reach the limits of your web server software, consider alternatives. In many cases, web servers such as lighttpd (http://www.lighttpd.net), Zeus (http://www. zeustech.net), and litespeed (http://litespeedtech.com) are faster than Apache and use less memory.
You can also get huge boosts from caching. Code caches, which include PHP accelerators such as e-accelerator (http://eaccelerator.net) and APC (http://apc.communityconnect.com), save PHP bytecode and avoid parsing overhead on each page access. Data caches such as MySQL’s query cache save the results of identical queries. Replication is a form of LB. memcached (http://danga.com/memcached) is a fast way to cache data such as database lookup results. Squid (http://www.squid-cache.org), when used as a caching reverse proxy, is a page cache that can bypass the web server entirely.
When servers are in separate tiers (e.g., MySQL -> PHP -> Apache), improvements are multiplicative; for example, the presentation “Getting Rich with PHP 5” (http:// talks.php.net/show/oscon06) combines many small fixes to scale a PHP application from 17 calls/second to 1,100 calls/second on a single machine.
If you’re already using these techniques and are still straining to meet demand, definitely try LB, and provide HA if stability is critical.
Further Reading
More details on the software used in this chapter are available via the products’ web pages:
The Linux Virtual Server Project (http://www.linuxvirtualserver.org)
Ultra Monkey (http://www.ultramonkey.org)
Heartbeat/The High-Availability Linux Project (http://linux-ha.org)
You may also want to check out the Red Hat Cluster Suite (http://www.redhat.com/software/rha/cluster), a commercial LB/HA product for Linux built on LVS. The same software is freely available (but without support) in CentOS.
Site Administration 
