Managing HP Serviceguard for Linux, Tenth Edition, September 2012

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.
Designing Applications to Run on Multiple Systems 315