Using HP Serviceguard for Linux to Provide High Availability for LAMP, December 2005

except where explicitly mentioned in this white paper. The instructions in this white paper
are based on the tests that were conducted on various configurations.
Audience
This document is for users of HP Serviceguard on Linux who want to take advantage of a
complete web based database solution in the form of the LAMP stack running on a
cluster which is highly available.
It is assumed that the reader has a general understanding of HP Serviceguard for Linux
and the LAMP components and features. Please see
http://www.hp.com/go/sglx ,
http://www.apache.org, and http://www.mysql.com/ for detailed information on each
solution. It will be necessary to download the toolkits to get the READMEs. A link is
available at the end of this document.
Providing high availability to the LAMP stack
Background
The LAMP stack can be deployed in various configurations. In one common configuration
the web front end runs on servers which are tuned to handle higher network loads and
the database runs on separate servers tuned for faster disk I/O. This separation allows
for overall better performance. In another common configuration the web server and the
database are consolidated on the same server. To provide high availability to the former
setup, the web service and the database service is packaged separately while the latter
requires that the consolidated LAMP application services be packaged as a single
Serviceguard for Linux package. The table below lists the differences between the two
configurations.
Separate LAMP
configuration
Consolidated LAMP
configuration
Package
Configuration
Simple and straightforward with
no modifications of existing
toolkits
Increased flexibility increases
complexity. User must modify
existing toolkit templates.
Package
Administration
More challenging with different
packages running on different
nodes
Simple administration with both
services run as part of the same
package on the same node
Tuning
Nodes can be tuned to handle
specific workloads thereby
improving performance
Since both, front-end and
database run on the same node,
there are fewer options available
for workload performance
tuning.
OS & HW Upgrades
Rolling upgrades of the database
and the web server can be done
independently and one after
another
Both the database and web
service have to be moved to an
alternate node before upgrades
can be carried out
Security
The database servers and the
web servers can be placed in
different security zones. This
would however require two
different clusters separated by a
firewall
Since the database and the web
server run on the same node,
protection via SElinux can be
used.
3