Managing Serviceguard Eighteenth Edition, September 2010

Network applications can bind to a stationary IP address, a relocatable IP address, or
INADDR_ANY. If the stationary IP address is specified, then the application may fail
when restarted on another node, because the stationary IP address is not moved to the
new system. If an application binds to the relocatable IP address, then the application
will behave correctly when moved to another system.
Many server-style applications will bind to INADDR_ANY, meaning that they will receive
requests on any interface. This allows clients to send to the stationary or relocatable IP
addresses. However, in this case the networking code cannot determine which source
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.
If the application cannot be modified as recommended above, use the procedure under
“Using a Relocatable Address as the Source Address for an Application that is Bound
to INADDR_ANY” (page 435).
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
434 Designing Highly Available Cluster Applications