Specifications

Intelligent Versus Automatic Switchback
A standby server can provide backup for more than one active server. For example in the figure
above, Server 2 is the standby server in three active/standby resource pairs. The LifeKeeper resource
definitions specify the following active/standby paired relationships:
l AppA on Server1 fails over to Server2.
l AppB on Server3 fails over to Server2.
l AppC on Server4 fails over to Server2.
Be aware of these three critical configuration concepts when you are considering configurations with
multiple active/standby groups:
l Disk ownership. Different active applications cannot use disk partitions on the same shared
disk or LUN from different servers. LifeKeeper applies locks at the disk or LUN level. When
the SCSI locks are applied, only one system on the shared SCSI bus can access partitions on
the disk or LUN. This requires that applications accessing different partitions on the same
disk be active on the same server. In the example, Server 3 has ownership of the AppB disk
resources and Server 4 owns the AppC resources.
l Processing capacity. Although it is unlikely that Servers 1, 3 and 4 would fail at the same
time, you must take care when designating a standby server to support multiple resource
relationships so that the standby server can handle all critical processing should multiple faults
occur.
l LifeKeeper administration. In the example, Server 2 provides backup for three other servers.
In general it is not desirable to administer the LifeKeeper database on the different logical
groups simultaneously. You should first create the resources between the spare and one
active system, then between the spare and another active system, and so on.
Intelligent Versus Automatic Switchback
By default, the switchback setting of a resource is intelligent. This means that once the failover
occurs for that resource from Server A to Server B, the resource remains on Server B until another
failure or until an administrator intelligently switches the resource to another server. Thus, the
resource continues to run on Server B even after Server A returns to service. Server A now serves as
a backup for the resource.
In some situations, it may be desirable for a resource to switch back automatically to the original
failed server when that server recovers. LifeKeeper offers an automatic switchback option as an
alternative to the default intelligent switchback behavior described above. This option can be
configured for individual resource hierarchies on individual servers. If automatic switchback is
selected for a resource hierarchy on a given server and that server fails, the resource hierarchy is
failed over to a backup system; when the failed server recovers, the hierarchy is automatically
switched back to the original server.
Notes:
l Checks for automatic switchback are made only when LifeKeeper starts or when a new server
is added to the cluster; they are not performed during normal cluster operation.
44SteelEye LifeKeeper for Linux