Managing HP Serviceguard A.11.20.10 for Linux, December 2012

A.2.7 Design for Replicated Data Sites
Replicated data sites are a benefit for both fast failover and disaster recovery. With replicated
data, data disks are not shared between systems. There is no data recovery that has to take place.
This makes the recovery time faster. However, there may be performance trade-offs associated
with replicating data. There are a number of ways to perform data replication, which should be
fully investigated by the application designer.
Many of the standard database products provide for data replication transparent to the client
application. By designing your application to use a standard database, the end-user can determine
if data replication is desired.
A.3 Designing Applications to Run on Multiple Systems
If an application can be failed to a backup node, how will it work on that different system?
The previous sections discussed methods to ensure that an application can be automatically restarted.
This section will discuss some ways to ensure the application can run on multiple systems. Topics
are as follows:
• Avoid Node Specific Information
• Assign Unique Names to Applications
• Use Uname(2) With Care
• Bind to a Fixed Port
• Bind to a Relocatable IP Addresses
• Give Each Application its Own Volume Group
• Use Multiple Destinations for SNA Applications
• Avoid File Locking
A.3.1 Avoid Node Specific Information
Typically, when a new system is installed, an IP address must be assigned to each active network
interface. This IP address is always associated with the node and is called a stationary IP address.
The use of packages containing highly available applications adds the requirement for an additional
set of IP addresses, which are assigned to the applications themselves. These are known as
relocatable application IP addresses. Serviceguard’s network sensor monitors the node’s access
to the subnet on which these relocatable application IP addresses reside. When packages are
configured in Serviceguard, the associated subnetwork address is specified as a package
dependency, and a list of nodes on which the package can run is also provided. When failing a
package over to a remote node, the subnetwork must already be active on the target node.
Each application or package should be given a unique name as well as a relocatable IP address.
Following this rule separates the application from the system on which it runs, thus removing the
need for user knowledge of which system the application runs on. It also makes it easier to move
the application among different systems in a cluster for load balancing or other reasons. If two
applications share a single IP address, they must move together. Instead, using independent names
and addresses allows them to move separately.
For external access to the cluster, clients must know how to refer to the application. One option is
to tell the client which relocatable IP address is associated with the application. Another option is
to think of the application name as a host, and configure a name-to-address mapping in the Domain
Name System (DNS). In either case, the client will ultimately be communicating via the application’s
relocatable IP address. If the application moves to another node, the IP address will move with it,
allowing the client to use the application without knowing its current location. Remember that each
network interface must have a stationary IP address associated with it. This IP address does not
move to a remote system in the event of a network failure.
A.3 Designing Applications to Run on Multiple Systems 261