HP Instant Capacity Version 10.x User Guide (762794-001, March 2014)

Example 21 Scavenging attempt on standby Group Manager
From: [e-mail]
Subject: cron
<?xml version="1.0" encoding="utf-8"?>
<CIM CIMVERSION="2.0" DTDVERSION="2.0">
<MESSAGE ID="" PROTOCOLVERSION="1.0">
<SIMPLERSP>
<METHODRESPONSE NAME="checkScavengedMember">
<ERROR CODE="1" DESCRIPTION="CIM_ERR_FAILED: This system is not an active Group
Manager.&#10;Only an active Group Manager can check to see if it can reconnect to
members&#10;from which usage rights were previously seized.&#10;"/>
</METHODRESPONSE>
</SIMPLERSP>
</MESSAGE>
</CIM>
*************************************************
Cron: The previous message is the standard output and standard error of one of your crontab commands:
/opt/wbem/bin/wbemexec /etc/opt/iCAP/GiCAP.checkScavengedMember.xml
The job is removed from crontab only if there is no member in any group from where active Group
Manager has seized rights.
Down partitions with powered-on cells
Partitions that are not running an iCAP daemon are assumed to be running another OS and using
all cores on cells configured in the partition. The iCAP software can avoid this assumption when
all cells configured in the partition are powered down. Unless an explicit restore operation is
performed, when the failed partition is rebooted it will have only the minimum number of core
usage rights left after the rights seizure. Because of this, cells in partitions from which usage rights
have been seized should be rebooted or made inactive within 12 hours. If this is not done, the
partition may begin to consume temporary capacity. If temporary capacity is not available, the
complex may no longer be in compliance with the iCAP contract. Cells can be made inactive by
removing them from the partition, shutting down the partition from within the OS by using
shutdown -R -H, or with the MP RR command.
TiCAP and rights seizure
iCAP is designed to stop using temporary capacity and instead take advantage of usage rights if
any become available. If temporary capacity is in use during a failover sequence, the activation
on the failover node might need to specify the use of temporary capacity. After the rights have
been seized and before the activation on the failover node, there is a window of time when the
iCAP daemons (on other partitions in the group) can wake up and start using the seized usage
rights to stop using temporary capacity. If this happens, the seized usage rights are no longer
available for the failover activation.
By specifying the use of temporary capacity on failover activation, you guarantee that the core
activations needed for failover will occur. The total temporary capacity consumption across the
group remains the same, even though the temporary capacity might be consumed on the failover
server instead of on the original server.
If, for some reason, it is important to keep the temporary capacity usage to a particular server,
you can manually deactivate the temporary capacity-consuming cores before doing the failover
activations, and then reactivate the temporary capacity usage after the failover activations. For
similar reasons, it might also be important to make sure other activations are not occurring
simultaneously during a failover sequence.
Other considerations
Rights seizure can be used as part of an automatic failover system, but be sure that resources are
seized appropriately and in a manner that does not cause problems when the problem is corrected.
The iCAP software determines that the partition is down based on whether the ping command is
unsuccessful for the partition. In some circumstances, ping might be unsuccessful but the system
82 GiCAP