Steps to Create Resources by Defining Your Own Recovery Kit

Note: Use the GUI to create resources if using the existing Recovery Kit.

LifeKeeper provides two mechanisms for defining an application resource hierarchy:

  • LifeKeeper GUI
  • LifeKeeper Configuration Database Interface (LCDI) commands

The LCDI is a set of interface commands provided by LifeKeeper that you can use to create and customize resource hierarchy configurations to meet your application needs. You use the command interface when an application depends upon multiple resources (such as two or more file systems).

For a description of the commands, see the LCDI manual pages. This topic provides a development scenario that demonstrates the way you can use both the GUI and command functions to create a resource hierarchy.

Scenario Situation

The example application, ProjectPlan, has data stored in SCSI file systems shared by Servers 1 and 2. Server 1 will be the primary hierarchy for the application. The application has two file systems:_ /project-data_ and /schedule. The first step in the hierarchy definition is to determine the dependencies.

The example application has these dependencies:

  • Shared file systems. The application depends upon its file systems: /project-data and /schedule.
  • SCSI disk subsystem. The file systems in turn depend upon the SCSI disk subsystem, which includes the device, disk and host adapter resources.

As a result, the task is to create a hierarchy that looks like the following diagram.

Hierarchy Definition

These are the tasks required to construct the example application hierarchy:

  1. Create file system resources. The LifeKeeper GUI provides menus to create file system resources. See Creating File System Resource Hierarchies.

At the end of this definition task, the LCD has two filesys resources defined as follows:

ID
Tag
Server
/project-data

/project-data

project-data-on-Server1

project-data-from-Server1

Server1

Server2

/schedule

/schedule

schedule-on-Server1

schedule-from-Server1

Server1

Server2

Note: LifeKeeper does not place any significance on the tag names used; they are simply labels. The tag names shown are the LifeKeeper defaults.

  1. Define resources. The example requires the following definitions:
Application: projectapp
Resource Type: plan
Instance ID: 1yrplan
Tag: the-project-plan

Note: Although you can create much of the definition using the LifeKeeper GUI, the rest of this example demonstrates the command interface.

  1. Create directories. On each system, you create the necessary application recovery directories under the directory /opt/LifeKeeper/subsys with the command:

mkdir -p /opt/LifeKeeper/subsys/projectapp/Resources/plan/actions

  1. Define application. The following commands create the application named projectapp:

app_create -d Server1 -a projectapp

app_create -d Server2 -a projectapp

  1. Define the resource type. The following commands create the resource type named plan:

typ_create -d Server1 -a projectapp -r plan

typ_create -d Server2 -a projectapp -r plan

  1. Install recovery scripts. Copy your restore and remove scripts to the following directory on each server:

/opt/LifeKeeper/subsys/projectapp/Resources/plan/actions

  1. Define instance. The following commands define an instance of resource type plan with the id 1yrplan:

ins_create -d Server1 -a projectapp -r plan -I\

AUTORES_ISP -t the-project-plan -i 1yrplan

ins_create -d Server2 -a projectapp -r plan -I\

SEC_ISP -t the-project-plan -i 1yrplan

The -I AUTORES_ISP instruction for the instance created on Server1 tells LifeKeeper to automatically bring the resource in service when LifeKeeper is restarted. In this case, the resource’s restore script is run and, if successful, the resource is placed in the ISP state. This operation is not performed if the paired resource is already in service.

The -I SEC_ISP instruction for the instance created on Server2 tells LifeKeeper that this resource instance should not be brought into service when LifeKeeper is restarted. Instead, Server2 will serve as the backup for the resource on Server1, and the local resource will be brought in service upon failure of the primary resource or server.

  1. Define dependencies. The following commands define the dependencies between the application and the file systems:

dep_create -d Server1 -p the-project-plan -c project-data-on-System1

dep_create -d Server2 -p the-project-plan -c project-data-from-Server1

dep_create -d Server1 -p the-project-plan -c schedule-on-Server1

dep_create -d Server2 -p the-project-plan -cschedule-from-Server1

  1. Execute lcdsync. Execute the following lcdsync commands to inform LifeKeeper to update its copy of the configuration:

lcdsync -d Server1

lcdsync -d Server2

  1. Set the resources to “In Service”. Access LifeKeeper GUI on the primary server, select [Edit] > [Resource] > [In-Service] and set the resource “In Service”, or execute the following command on the primary server:

perform_action -t the-project-plan -a restore

  1. Create equivalency. Create equivalency of resources registered for each node with the following commands to switch resources:

eqv_create -d Server1 -t the-project-plan -p 1 -S Server2 -o the-project-plan -r 10 -e SHARED

eqv_create -d Server2 -t the-project-plan -p 10 -S Server1 -o the-project-plan -r 1 -e SHARED

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