How takeover and giveback work

When takeovers occur

The conditions under which takeovers occur depend on how you configure the cluster. For more information about configuring a cluster for takeover, see Configuring when takeover occurs. Takeovers can be initiated when one of the following conditions occur:

A node is in a cluster that is configured for immediate takeover on panic and undergoes a software or system failure that leads to a panic.
A node that is in a cluster undergoes a system failure (for example, a loss of power) and cannot reboot.
Note
If the storage for a node also loses power at the same time, a standard takeover is not possible. For MetroClusters, you can initiate a forced takeover in this situation.
There is a mismatch between the disks that one node can see and the disks that the other node can see.
One or more network interfaces that are configured to support failover become unavailable.
A node cannot send heartbeat messages to its partner. This could happen if the node experienced a hardware or software failure that did not result in a panic but still prevented it from functioning correctly.
You halt one of the clustered nodes without using the -f flag.
You initiate a takeover manually.

What happens during takeover

When a takeover occurs, the unimpaired partner node in the cluster takes over the functions and disk drives of the failed node by creating an emulated storage system that

Assumes the identity of the failed node
Accesses the failed node's disks and serves its data to clients

The partner node maintains its own identity and its own primary functions, but also handles the added functionality of the failed node through the emulated node.

Note
When a takeover occurs, existing CIFS sessions are terminated. A graceful shutdown of the CIFS sessions is not possible, and some data loss could occur for CIFS users.

What happens after takeover

After a takeover occurs, you view the surviving partner as having two identities, its own and its partner's, that exist simultaneously on the same storage system. Each identity can access only the appropriate volumes and networks. You can send commands or log in to either storage system by using the rsh command, allowing remote scripts that invoke storage system commands through a Remote Shell connection to continue to operate normally.

Access with rsh

Commands sent to the failed node through a Remote Shell connection are serviced by the partner node, as are rsh command login requests.

Access with Telnet

If you log in to a failed node through a Telnet session, you see a message alerting you that your storage system failed and to log in to the partner node instead. If you are logged in to the partner node, you can access the failed node or its resources from the partner node by using the partner command.

What happens during a giveback

When the failed node is functioning again

You initiate a giveback command that terminates the emulated node on the partner
The failed node resumes normal operation, serving its own data
The cluster resumes normal operation, with each node ready to take over for its partner if the partner fails