Enabling application switchover

Start of change Cluster resource services supports a user configured takeover IP address when configuring application CRGs. End of change

The following manual configuration steps are required to enable the switchover environment. This set of instructions must be done on all the nodes in the recovery domain, and repeated for the other nodes in the cluster that will become nodes in the recovery domain for the given application CRG.

Select a takeover IP address to be used by the application CRG.
- To avoid confusion, this address should not overlap with any other existing addresses used by the cluster nodes or routers. For example, if choosing 19.19.19.19, ensure that 19.0.0.0 (19.19.0.0 or ...) are not routes known by the system routing tables.
- Add the takeover interface (for example, 19.19.19.19); create it with a line description of *VIRTUALIP, subnet mask of 255.255.255.255 (host route), Maximum Transmission Unit of 1500 (any number in the range 576-16388), and Autostart of *NO. This takeover address (for example, 19.19.19.19) does must exist as a *VIRTUALIP address before identifying it as an Associated Local Interface in next step. It does not, however, must be active.
Associate the intended takeover IP address with one or both of the IP addresses specified to be used by cluster communications when you create the cluster or add a node to the cluster.
- For example, this means making the 19.19.19.19 takeover address an Associated Local Interface on the IP address for the cluster node on the Ethernet bus to be used locally for clustering. This must be done for each cluster address on each cluster node.
  Note: The cluster addresses will must be ended to accomplish this change under CFGTCP.
Create the cluster and create any CRGs. For the application CRG specify QcstUserCfgsTakeoverIpAddr for the 'configure takeover IP address' field. Do not start any Application CRGs.
Using Configure TCP/IP Applications (option 20) under CFGTCP, then Configure RouteD (option 2), then Change RouteD attributes (option 1), ensure Supply is set to *YES. If not, set to *YES and start or re-start ROUTED (RIP or RIP-2) on each cluster node.
- NETSTAT option 3 will show ROUTED using a Local Port if currently running. ROUTED must be running and advertising routes (Supply = *YES) on every cluster node in the CRG recovery domain.
Ensure that all the commercial routers in the network interconnecting the recovery domain LANs are accepting and advertising host routes for RIP.
- This is not necessarily the default setting for routers. Language will vary with router manufacturer but under RIP Interfaces, expect to be sending Host Routes and receiving dynamic hosts.
- This also applies to both the router interfaces pointing to the iSeries™ servers as well as the router-to-router interfaces
Note: Do not use an iSeries server as the router in this scenario. Use a commercial router (IBM^® or otherwise) that is designed for routing purposes. iSeries routing cannot be configured to handle this function.
You now can manually activate the takeover address on one of the cluster nodes, allow RIP up to 5 minutes to propagate the routes, and ping the takeover address from all nodes in the CRG recovery domain and from selected clients on the LANs who will be using this address.
- After this verification test, ensure the takeover address is ended again.
- Clustering will start the address on the specified primary node when the CRGs are started.
Start the Application CRGs.
- The takeover address will now be started by clustering on the specified preferred node and RIP will advertise the routes throughout the recovery domain. RIP may take up to 5 minutes to update routes across the domain. The RIP function is independent from the start CRG function.

Important notes:

If the above procedure is not followed for all cluster nodes in the application CRG recovery domain, the cluster will hang during the switchover process.
Even though we do not failover to replica nodes, it is a good idea to perform the procedure on the replica nodes in the event that they may be changed at a later date in time to become a backup.
If you want to use multiple virtual IP addresses, then each one will require a separate application CRG and a separate IP address with which to be associated. This address may be another logical IP address on the same physical adapter or it may be another physical adapter altogether. Also, care must be taken to prevent ambiguities in the routing tables. This is best achieved by doing the following:
- Add a *DFTROUTE to the routing table for each virtual IP address.
- This can be done under CFGTCP (option 2).
- Set all parameters, including the next hop, the same to reach the router of choice, but the Preferred binding interface should be set to be the local system IP address associated with the virtual IP address that will be represented by this route.