Managing HP Serviceguard for Linux Ninth Edition, April 2009

IP address is most appropriate for responses, so it will always pick the stationary IP
address.
For TCP stream sockets, the TCP level of the protocol stack resolves this problem for
the client since it is a connection-based protocol. On the client, TCP ignores the stationary
IP address and continues to use the previously bound relocatable IP address originally
used by the client.
With UDP datagram sockets, however, there is a problem. The client may connect to
multiple servers utilizing the relocatable IP address and sort out the replies based on
the source IP address in the server’s response message. However, the source IP address
given in this response will be the stationary IP address rather than the relocatable
application IP address. Therefore, when creating a UDP socket for listening, the
application must always call bind(2) with the appropriate relocatable application IP
address rather than INADDR_ANY.
Call bind() before connect()
When an application initiates its own connection, it should first call bind(2), specifying
the application IP address before calling connect(2). Otherwise the connect request
will be sent using the stationary IP address of the system's outbound LAN interface
rather than the desired relocatable application IP address. The client will receive this
IP address from the accept(2) call, possibly confusing the client software and
preventing it from working correctly.
Give Each Application its Own Volume Group
Use separate volume groups for each application that uses data. If the application
doesn't use disk, it is not necessary to assign it a separate volume group. A volume
group (group of disks) is the unit of storage that can move between nodes. The greatest
flexibility for load balancing exists when each application is confined to its own volume
group, i.e., two applications do not share the same set of disk drives. If two applications
do use the same volume group to store their data, then the applications must move
together. If the applications’ data stores are in separate volume groups, they can switch
to different nodes in the event of a failover.
The application data should be set up on different disk drives and if applicable, different
mount points. The application should be designed to allow for different disks and
separate mount points. If possible, the application should not assume a specific mount
point.
Use Multiple Destinations for SNA Applications
SNA is point-to-point link-oriented; that is, the services cannot simply be moved to
another system, since that system has a different point-to-point link which originates
in the mainframe. Therefore, backup links in a node and/or backup links in other nodes
should be configured so that SNA does not become a single point of failure. Note that
only one configuration for an SNA link can be active at a time. Therefore, backup links
that are used for other purposes should be reconfigured for the primary mission-critical
purpose upon failover.
298 Designing Highly Available Cluster Applications