If you uninstall LifeKeeper on one of your systems, you will need to follow these steps. If a server in your LifeKeeper for Windows cluster experiences a failure that causes re-installation of the operating system (and thus LifeKeeper for Windows), you will have to re-extend the resource hierarchies from each server in the cluster. If a server in the cluster has a shared equivalency relationship with the re-installed server, however, LifeKeeper for Windowse will not allow you to extend the existing resource hierarchy to the re-installed server. LifeKeeper for Windows 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:

After reinstalling your operating systems and all related patches as well as LifeKeeper for Windows, begin the following steps for recovery (Note: The examples in the Suggested Action below are using test system names “BENHOGAN” and “GPLAYER”):

  1. On each server where the resource hierarchies are configured, use the eqv_list command to obtain a list of all the shared equivalencies.

eqv_list [-d destsys] [-s sys] [-t tag] [-e SHARED] [-fC]

This function prints strings to standard output describing equivalency relationships between resource instances.

Example:

c:\LK\Bin>eqv_list

BENHOGAN2008 LK1-BENHOGAN2K8 GPLAYER2008 LK1-BENHOGAN2K8 SHARED 1 10

BENHOGAN2008 Vol.E GPLAYER2008 Vol.E SHARED 1 10

See LifeKeeper GUI below of hierarchies, resources, etc.

  1. On each server where the resource hierarchies are configured, use eqv_remove to manually remove the equivalency relationship for each resource in the hierarchy.

This function removes equivalency from the configuration database on system destsys (local if not specified) of equivalency type, specified by the -e option, between the resources tag and othertag existing on systems sys and othersys respectively.

eqv_remove [-d destsys] [-s sys] -t tag [-S othersys]-o othertag [-e SHARED]

eqv_remove -s {this system} –t {TAGNAME} –S {othersys that has gone away} [-e SHARED]

Example:

c:\LK\Bin>eqv_remove -s BENHOGAN2008 -t LK1-BENHOGAN2K8 -S GPLAYER2008 -e SHARED

c:\LK\Bin>

  1. Execute the eqv_list command again. There should be “no” list of shared equivalencies, etc.

Notice on the LifeKeeper GUI below how the target resources have been removed:

  1. If there are any DataKeeper mirrored volumes configured in your cluster, clean up the LKDRInfo file for that volume.

LifeKeeper for Windows will create an LKDRInfo.<volume> file in the folder %LKROOT%\subsys\filesys\resources\volume for each mirrored volume resource. This file should be deleted.

C:\LK\BIN> cd %LKROOT%\subsys\filesys\resources\volume

C:\LK\subsys\filesys\resources\volume> dir LKDRInfo.E

05/23/2012 01:02 PM 39 LKDRInfo.E

C:\LK\subsys\filesys\resources\volume> del LKDRInfo.E

  1. If there are any DataKeeper mirrored volumes configured in your cluster, clean up the mirror and delete the DataKeeper job that contains that mirror.

DataKeeper mirrors and jobs must be recreated when the cluster is re-extended to the reinstalled server. Therefore, the local end of any mirrors that are configured must be deleted and any jobs that are configured with those mirrors must be deleted.

C:\LK\subsys\filesys\resources\volume> cd ExtMirrBase

C:\Program Files\SIOS\DataKeeper> emcmd . getjobinfoforvol E

ID = e829700c-27b0-447f-b852-1a3135da31a7

Name = E Vol

Description =

MirrorEndPoints = BENHOGAN2008;E;10.200.8.25;GPLAYER2008;E

;10.200.8.26;A

C:\Program Files\SIOS\DataKeeper> reg /delete HKLM\System\CurrentControlSet\Services\ExtMirr\Parameters\Jobs\e829700c-27b0-447f-b852-1a3135da31a7

Permanently delete the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ExtMirr\Parameters\Jobs\1b5e8715-a488-4030-8166-45c9232bc04e (Yes/No)? y

The operation completed successfully.

C:\Program Files\SIOS\DataKeeper> emcmd . getjobinfoforvol E

C:\Program Files\ SIOS\DataKeeper> emcmd . deletelocalmirroronly E

Status = 0

C:\Program Files\ SIOS\DataKeeper> emcmd . clearswitchover E

Status = 0

Repeat these steps for all mirrored volumes. The job must be deleted from the registry directly; attempting to delete the job using “emcmd . deletejob” will fail because DataKeeper tries to delete the job on all nodes. This will not work since one of the nodes no longer exists and the job will be left intact.

  1. You are now ready to remove the old system.

a. Display all systems that were in the LifeKeeper for Windows cluster:

sys_list [-d destsys]

Example:

c:\LK\Bin>sys_list

BENHOGAN2008

GPLAYER2008

b. Remove all old targets/systems.

sys_remove [-d destsys] -s sys

Example:

c:\LK\Bin>sys_remove -s GPLAYER2008

Do this for all systems participating in the LifeKeeper for Windows cluster

Note: If attempting to execute this command for the local/source system, the following error will be received:

c:\LK\Bin>sys_remove -s BENHOGAN2008

(null)Process: sys_remove(2728)

[File:sys.C Line:81]

ERROR (No. 424) can’t remove entry for local system “BENHOGAN2008”

  1. Remove communication paths.

a. Verify the comm paths that are present:

net_list

b. Remove these comm paths:

net_remove

  1. Write the changes.

lcdsync [-d destname]

Example:

c:\LK\Bin>lcdsync

This function checks to see if the LifeKeeper for Windows resource hierarchy configuration and communication path status data stored in shared memory has been modified. If it is different, the data is “synchronously” written to disk. Therefore, when this program returns, the data is guaranteed to be on disk properly.

Optional Note: To completely remove all resources, first generate a list of all resource instances:

ins_list [-d destsys] [-fC] [-R top] [-a appname] [-r typ][-t tag] [-i id]

then remove these instances:

ins_remove [-d destsys] [-R roottag] [-a appname] [-r restyp][-t tag] [-i id] [-v] [-I] [-N] [-G]

  1. Close the LifeKeeper GUI and reopen.

  1. Extend each resource hierarchy from the server where the resource hierarchy is in service to the re-installed server using the GUI.

a. Connect to your reinstalled server/target. Note: This may also require a re-creation of the comm paths.

b. Extend resource hierarchy.

c. Add/extend mirror resource.

Complete — All protected resources have been recovered and are protected once again.

Feedback

Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.

Post your comment on this topic.

Post Comment