Technical Notes

lkstart

This program starts LifeKeeper on the current system if it is not currently running. lkstart modifies entries in the %LKROOT%\etc\LKinit.config file pertaining to the LifeKeeper daemons so that they will be respawned if they die.

The –w option, with waitperiod in seconds, can be used to change the timeout interval. Use the –w argument to specify a wait period before the startup.

The LifeKeeper service can also be started using the Microsoft Services MMC under Administrative Tools or from a command prompt using either “sc start LifeKeeper” or “net start LifeKeeper”.

Note: This program must be run from the console.

Running CHKDSK.EXE on LifeKeeper for Windows Protected Volume

Microsoft recommends running the utility chkdsk.exe to check and correct file system or disk errors on volumes that have not been cleanly shut down. However, depending on the extent of errors, the utility may take a very long time to complete. It may take several hours or even days for chkdsk to completely check the volume, or it may hang while checking the volume. Due to these reasons, LifeKeeper for Windows does not run the chkdsk utility on protected volumes. LifeKeeper for Windows does run the Microsoft utility chkntfs.exe to check whether a volume is dirty or not before bringing the volume in service. If a protected volume is found dirty, LifeKeeper for Windows will log an error to the event log.

It is recommended that administrators periodically run chkdsk on LifeKeeper for Windows protected volumes on the server where the volume resource(s) are in service. Administrators should take all the applications using the volume resource(s) out-of-service prior to running chkdsk.

Communication Paths Over Fibre Channel

When building a LifeKeeper for Windows cluster using shared storage, it is important to maintain working communication paths between the nodes in the cluster. Communication paths should be created using TCP communication protocols. Normally, TCP communication paths are built on Ethernet network devices. LifeKeeper for Windows, however, can use any type of connection on which the TCP protocol can run. If a shared storage cluster is being created using a Fibre Channel SAN, it is possible (and desirable) to use the Fibre Channel SAN as a LifeKeeper for Windows communication path.

QLogic provides a miniport driver and an IP driver for Windows that will allow a QLogic Fibre Channel storage adapter to also run the TCP/IP protocol. This, in effect, allows the QLogic Fibre Channel adapter to function both as a storage adapter and as a network adapter. Once this driver is in place, the QLogic card can be configured, as any network card would, using standard network configuration techniques.

QLogic’s driver can be downloaded from the following web site:

http://driverdownloads.qlogic.com/QLogicDriverDownloads_UI/DefaultNewSearch.aspx

Using iSCSI Storage with LifeKeeper for Windows

iSCSI storage can be used as shared storage and protected by LifeKeeper for Windows. For shared storage environments, the iSCSI target device must be configured so that all server initiators have access to the disk. The vendor of the iSCSI storage device provides the interface and commands needed to configure the iSCSI device. A dependency on the Microsoft iSCSI Initiator service (MSiSCSI) should be added to the LifeKeeper service. This will ensure that the shared volume is available before LifeKeeper attempts to access the volume.

To create a dependency on MSiSCSI for the LifeKeeper service, use the registry editor “regedt32.exe” and select the subkey representing the LifeKeeper service under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LifeKeeper. The service key has a value name “DependOnService” with one value “EISM”. Double-click the value name “DependOnService” to open for editing. When the dialog box appears, add the service name “MSiSCSI” for Microsoft iSCSI Initiator service on a new line and click OK.

To verify that the dependency was created, open Administrative Tools->Services MMC snap-in. Go to LifeKeeper service and double-click to bring up the “Properties” dialog. When the dialog box appears, go to “Dependencies” page and verify that “Microsoft iSCSI Initiator” service is listed along with “LifeKeeper External Interface” in the “depends on” field.

System Load Considerations for Quickcheck and Deepcheck

LifeKeeper for Windows launches a separate thread to monitor each protected resource in the system. These threads operate independently of one another. Typically, system load from Quickcheck and Deepcheck script execution will be randomly distributed. LifeKeeper for Windows also works to distribute resource monitoring load by skipping a Quickcheck execution whenever a Deepcheck for the same resource is scheduled to run at the same time. However, because the check load is randomly distributed, there will occasionally be peaks in system load from resource monitoring. The more protected resources in the system, the larger these peaks will be and the more often they may occur. The largest peak will occur when LifeKeeper is started and Deepcheck scripts for each active resource are first launched. If the server can handle this first load peak in a satisfactory way, then there should not be a performance problem later.

VSS Shadow Copy

LifeKeeper support for VSS Shadow Copy requires that shadow copies must NOT be stored on the LifeKeeper for Windows protected volumes. However, shadow copies may be saved on another non-protected volume.