Using SNAplus2 in a High Availability Environment

Using SNAplus2 with MC/ServiceGuard

start the node on the backup server until SNAplus2 recognizes that the primary server is down. This time period can be lengthy (up to 30 minutes).

Therefore, if the backup server is running SNAplus2, it is safest to completely stop the SNAplus2 software on the backup server before issuing the activation commands. The complete command set, then is:

function customer_defined_run_cmds

{

snap stop snap start snapadmin init_node

snapadmin start_port, port_name=HAPORT snapadmin start_ls, ls_name=HALS

}

With these commands specified in your Package Control Script, you will be able to start an SNAplus2 LS called HALS on a backup server when the primary server fails to keep the LS active. These commands work best in an SNAplus2 client/server environment where the applications run on client systems and automatically attempt to reestablish LU-LU sessions anytime a session outage occurs. For standalone environments, you will also have to consider how your applications will be impacted by various failures, including entire server system failures.

I/O Compatibility Constraints

The previous section described how to customize your Package Control Script for the best level of application transparency. To allow the same SNAplus2 node, port , and LS to run on multiple systems, it is important that they have compatible networking hardware. In a client/server configuration, SNAplus2 uses only one configuration file for all of the SNAplus2 systems defined to be part of the same logical network. To have more than one server capable of activating the same node, port and LS , the SNA networking hardware must be installed and configured similarly on each system. The requirements are different for each type of link.

LANS

For 802.3, Token Ring, and FDDI LANs, both servers must have the same type of LAN card installed. The LAN cards on both systems must be identified by the same SNAplus2 card number.

378

Appendix D