Specifications

Recovering from a LifeKeeper Server Failure
with "NU-" then LifeKeeper was unable to get a unique ID from the device.Without a unique ID
LifeKeeper cannot determine if the device is shared.
Possible Cause: The storage may require a specific LifeKeeper software to be installed before the
device can be used by LifeKeeper. Examples are the steeleye-lkRAW kit to enable Raw I/O support
and the steeleye-lkDR software to enable data replication.
Suggested Action: Verify that the necessary LifeKeeper packages are installed on each server. See
the SPSfor Linux Release Notes for software requirements.
Additional Tip:
Thetest_lk(1M)tool can be used to help debug storage and communication problems.
Recovering from a LifeKeeper Server Failure
If any server in your LifeKeeper cluster experiences a failure that causes re-installation of the
operating system (and thus LifeKeeper), you will have to re-extend the resource hierarchies from each
server in the cluster. If any server in the cluster has a shared equivalency relationship with the re-
installed server, however, LifeKeeper will not allow you to extend the existing resource hierarchy to
the re-installed server. LifeKeeper will also not allow you to unextend the hierarchy from the re-
installed server because the hierarchy does not really exist on the server that was re-installed.
Suggested Action:
1. On each server where the resource hierarchies are configured, use the eqv_list command to
obtain a list of all the shared equivalencies (seeLCDI-relationshipfor details).
The example below shows the command and resulting output for the IP resource iptag on
server1 and server2 where server2 is the server that was re-installed and server1 has the
hierarchy configured:
eqv_list -f:
server1:iptag:server2:iptag:SHARED:1:10
2. On each server where the resource hierarchies are configured, use eqv_remove to manually
remove the equivalency relationship for each resource in the hierarchy (seeLCDI-
relationshipfor details).
For example, execute the following command on server1 using the example from step 1
above:
eqv_remove -t iptag -S server2 -e SHARED
3. In clusters with more than two servers, steps 1-2 should be repeated on each server in the
cluster where equivalency relationships for these resource hierarchies are defined.
SteelEye Protection Suite for Linux251