Вы находитесь на странице: 1из 30

D o u b l e - Ta k e Ava i l a b i l i t y

Ver s i o n 4 . 0 S P 0 1
D o u b l e - Ta k e Av a i l a b i l i t y I n t e g r a t i o n G u i d e

July, 2012
Double-Take Availability Version 4.0 SP01 Integration Guide
Copyright Vision Solutions , Inc. 20032012
All rights reserved.
The information in this document is subject to change without notice and is furnished under a license agreement. This
document is proprietary to Vision Solutions, Inc., and may be used only as authorized in our license agreement. No portion of
this manual may be copied or otherwise reproduced without the express written consent of Vision Solutions, Inc.
Vision Solutions provides no expressed or implied warranty with this manual.
The following are trademarks or registered trademarks of their respective organizations or companies:

Vision Solutions is a registered trademark and ORION Solutions, Integrator, Director, Data Manager, Vision Suite,
ECS/400, OMS/400, ODS/400, SAM/400, Double-Take GeoCluster, Double-Take RecoverNow, Double-Take SHARE,
RecoverNow and iTERA HA are trademarks of Vision Solutions, Inc.

DB2, IBM, i5/OS, iSeries, System i, System i5, Informix, AIX 5L, System p, System x, and System z, and WebSphere
International Business Machines Corporation.

Adobe and Acrobat ReaderAdobe Systems, Inc.

Double-Take, GeoCluster, and NSINSI Software, Inc.

HP-UXHewlett-Packard Company.

TeradataTeradata Corporation.

IntelIntel Corporation.

Java, all Java-based trademarks, and Solaris-Oracle Corporation.

LinuxLinus Torvalds.

Microsoft and WindowsMicrosoft Corporation.

Mozilla and FirefoxMozilla Foundation.

NetscapeNetscape Communications Corporation.

OracleOracle Corporation.

Red HatRed Hat, Inc.

SybaseSybase, Inc.

Symantec and NetBackupSymantec Corporation.

UNIX and UNIXWarethe Open Group.

All other brands and product names are trademarks or registered trademarks of their respective owners.
If you need assistance, please contact Vision Solutions SCP Certified CustomerCare team at:
CustomerCare
Vision Solutions, Inc.
Telephone: 1.800.337.8214 or 1.949.724.5465
Email: support@visionsolutions.com
Web Site: www.visionsolutions.com/Support/Contact-CustomerCare.aspx

Contents

Chapter 1Overview of Double-Take Availability. . . . . . . . . . . . . . . . . . . . . . 1


Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Supported Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Production Server and Recovery Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Switching the Production and Recovery Node Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Production to Recovery Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Highly Available Production Server Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
RecoverNow Configuration Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Configuring Highly Available Production Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Managing RecoverNow in a HA Production Server Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Changing the RecoverNow Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Managing Failover to the Recovery Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
HA Production Server Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Failover Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Chapter 2Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Setting RecoverNow Applications to Manual Failover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Network Bandwidth and CPU Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Chapter 3Installation and Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19


Installation and Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Installation and Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Step 1: Configure RecoverNow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Defining RecoverNow Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Step 2: Configure GeoCluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Double-Take Availability v4.0.00.02 Integration Guide

iii

Contents

Creating a RecoverNow Application within GeoCluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21


Monitor the Application Properties in GeoCluster Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Appendix ADocumentation Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25


Double-Take Availability Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

iv

Double-Take Availability v4.0.00.02 Integration Guide

Overview of Double-Take
Availability

Introduction
A combination of High Availability Clustering and Data Replication
ensures an effective and efficient disaster recovery solution. Double-Take
GeoCluster (hereafter referred to as GeoCluster), is the clustering
component that automates the detection and recovery of applications and
their dependent resources from various system and human failures.
Double-Take RecoverNow (hereafter referred to as RecoverNow), is the
replication component that provides Continuous Data Protection (CDP)
and a high level of data protection from both disasters and data
corruption. The two components, GeoCluster and RecoverNow, working
together, comprise the Double-Take Availability solution.
GeoCluster and RecoverNow provide efficient disaster recovery:

GeoCluster automates the detection and recovery of applications and


their dependent resources from various system and human failures

RecoverNow provides a higher level of data protection from both


disasters and data corruption

Double-Take Availability v4.0.01.00 Integration Guide

Chapter 1: Overview

Supported Configurations
Vision Solutions supports two RecoverNow configurations:

Production Server and Recovery Server Configuration. A single cluster


consisting of a Production Server node and a Recovery Server node.

Highly Available Production Server Environment. A single cluster


consisting of two Production Server nodes. The Recovery Server node
resides outside the cluster.

Production Server and Recovery Server Configuration


A Production and Recovery server configuration is supported when you use
GeoCluster with RecoverNow. The Production Server is where the
production applications reside. The Recovery Server, maintains replicated
data, initializes rapid recoveries of production data, virtualizes Any
Point-In-Time recovery, and maintains Enterprise processes off-loaded
from the Production Server.
For a RecoverNow Primary Context, one RecoverNow and GeoCluster
node is configured to be the RecoverNow Production Server, and the other
RecoverNow and GeoCluster node to be the RecoverNow Recovery Server.
The Production and Recovery servers to RecoverNow and GeoCluster
nodes relationship remains fixed throughout the lifetime of the
configuration, although the roles of production and recovery may change.
The Production Server can take on the role of recovery, while the Recovery
Server can take on the role of production.
For this type of configuration, in addition to the Primary Context, you
associate a Failover Context with the Primary Context and create and
instantiate the Failover Context.
To avoid confusion with Context IDs, this document refers to Primary and
Failover Contexts as modes in which a Primary Context or its peer Failover
Context can exist. That is, when the nodes are using the Primary Context,
they are in Primary mode; when using the Failover Context, they are in
Failover mode. Both nodes must be in the same mode for replication to
occur. Under normal operation, both nodes are in the Primary mode, and
replication of data occurs from the Production server to the Recovery
server. When the Production server fails, and failover occurs, the Recovery
server switches to Failover mode. When the Production server recovers, it
too switches to Failover mode, and replication of data occurs from the
Recovery server to the Production server.

Switching the Production and Recovery Node Roles


You can switch the roles of the nodes; the node in the Production role is
now in the Recovery role, and vice-versa.

Double-Take Availability v4.0.01.00 Integration Guide

Chapter 1: Overview

In this configuration, the replicated data resides in non-shared storage; that


is, each server has its own storage relegated to replication. The application
runs on only one of the servers at any one time, accessing either the Primary
data store while running on the Production Server, or the Failover data store
while running on the Recovery Server.
Each Primary/Failover Context pair must have storage that is managed
independently of any other pair. Two or more Primary Contexts can not
contain storage (filesystems or logical volumes) on the same Volume
Group. A Volume Group can belong to only one Context, though a Context
can be composed of multiple Volume Groups.
RecoverNow and GeoCluster manage applications that run only on the
Production or Recovery servers at any one time. Using the unique
RecoverNow Primary and Failover Context IDs, which map to the data
store, RecoverNow and GeoCluster associate an application it is managing
with the applications data being replicated by RecoverNow. In addition,
RecoverNow and GeoCluster provide a RecoverNow-specific agent to
manage the starting, stopping, and monitoring of RecoverNow Contexts.
The resources managed by RecoverNow are not managed by GeoCluster
and RecoverNow, and vice-versa. RecoverNow and GeoCluster manage
complementary resources in a synchronous manner. A filesystem or logical
volume replicated by RecoverNow is managed by RecoverNow, not
GeoCluster and RecoverNow, even though that filesystem may be used by
the application managed by GeoCluster and RecoverNow.

Production to Recovery Configuration

Double-Take Availability v4.0.01.00 Integration Guide

Chapter 1: Overview

The figure above shows the normal operation of a Production to Recovery


Server configuration, the Primary Context is active on the Production and
Recovery Servers. In this mode:

The Application started by GeoCluster on the Production Server writes


data to the local storage

A RecoverNow Data Tap intercepts these writes as they are written to


the logical volume and additionally sends them to the Recovery Server

The Recovery Server writes the same, ordered data to another,


independent storage set. Note that these servers may be connected via a
LAN or WAN.

Highly Available Production Server Environment


A RecoverNow Highly Available (HA) Production server configuration is
supported with GeoCluster. This section describes how you configure
RecoverNow in a HA Production Server Environment.

RecoverNow Configuration Requirements

Configuring Highly Available Production Servers

Managing RecoverNow in a HA Production Server Environment

RecoverNow Configuration Requirements


Review these guidelines before you configure RecoverNow:

Do not enable automatic startup for RecoverNow in a HA environment

Install RecoverNow software on both GeoCluster nodes

The RecoverNow Production Volume Set (PVS) must reside on a


shared volume group

RecoverNow File Containers must reside on a shared volume group that


is part of the RecoverNow configuration. The RecoverNow
configuration files /usr/scrt/run/c<Primary Context ID> and
/usr/scrt/run/c<Failover Context ID> must also reside on a shared
volume group that is part of the RecoverNow configuration. These
filesystems need to be at least 128MB in size and must have a separate
jfslog, jfs2log, or jfs2 inline log since they will not be part of the PVS.
Create filesystems /usr/scrt/run/c<Primary Context ID> and
/usr/scrt/run/c<Failover Context ID> on the shared volume group that
will be used for the RecoverNow File Containers.

Configuring Highly Available Production Servers


To configure Highly Available Production Servers:

Double-Take Availability v4.0.01.00 Integration Guide

Chapter 1: Overview

1. On the Primary Production Server, mount the filesystems:


mount /usr/scrt/run/c<Primary Context ID>
mount /usr/scrt/run/c<Failover Context ID>

2. Use the RecoverNow to configure the Primary Context. Refer to the


Double-Take RecoverNow User Guide. Use GeoCluster to configure the
Service IP Address. Refer to the section Service IP Addresses in
Chapter 2 of the Double-Take GeoCluster User Guide.
IMPORTANT

To configure a Service IP Address, change the Production Server


Initial host adapter IP Address to the address you choose to use.
That address will be used as the Service IP Address. The
/etc/hosts file on all nodes must contain the Service IP
Address and associated IP label.
3. On the Primary Production Server, initialize the context.
scsetup -C <Primary Context ID> -M

4. On the Primary Production Server, create the Failover Context ID.


rtdr -C <Primary Context ID> -F <Failover Context ID> setup

5. On the Recovery Server, initialize the context.


scsetup -C <Primary Context ID> -M

6. On the Recovery Server, create the Failover Context ID.


rtdr -C <Primary Context ID> -F <Failover Context ID> setup

NOTE

You must manually copy and load the RecoverNow configuration


onto the Failover Production Server.
7. On the Primary Production Server, create a file with the Primary
Context ID configuration.
odmget -q ContextID=<Primary Context ID> SCCuObj
SCCuAttr SCCuRel >/tmp/C<Primary Context ID>.cfg

8. On the Primary Production Server, create a file with the Failover


Context ID configuration.
odmget -q ContextID=<Failover Context ID> SCCuObj
SCCuAttr SCCuRel >/tmp/C<Failover Context ID>.cfg

Double-Take Availability v4.0.01.00 Integration Guide

Chapter 1: Overview

9. Copy these configuration files to /tmp on the Failover Production


Server.
10. Run /usr/scrt/bin/rthostid on the Failover Production
Server to obtain the HostId.
11. Edit the stanza that is similar to the example stanza shown below in the
/tmp/C<Primary Context ID>.cfg file. Replace the contents of the
ObjectAttributeValue field with the output from the "rthostid" in
step 10.
SCCuAttr:
ObjectName = "production"
ConfigObjectSerial = 15
ObjectType = "SCRT/info/host"
ObjectAttributeName = "HostId"
ObjectAttributeValue = "6CABA7DF"
ObjectAttributeType = "ulong"
SerialNumber = 15006
ObjectNlsIndex = 0
SC_reserved = 0
ContextID = 1

12. Edit the stanza that is similar to the example stanza shown below in the
/tmp/C<Failover Context ID>.cfg file replacing the contents of the
ObjectAttributeValue field with the output from the rthostid
command.
SCCuAttr:
ObjectName = "backup"
ConfigObjectSerial = 4
ObjectType = "SCRT/info/host"
ObjectAttributeName = "HostId"
ObjectAttributeValue = "5FBBC3EF"
ObjectAttributeType = "ulong"
SerialNumber = 4006
ObjectNlsIndex = 0
SC_reserved = 0
ContextID = 11

13. On the Failover Production Server, use sccfgd_putcfg to load the


configurations onto the node.
sccfgd_putcfg <Primary Context ID> /tmp/C<Primary Context ID>.cfg
sccfgd_putcfg <Failover Context ID> /tmp/C<Failover Context ID>.cfg

14. On the Primary Production Server, use /usr/sbin/lvlstmajor to


obtain a list of unused device major numbers:
lvlstmajor
46,50,54,57,64,67,70,73..75,82..93,95...

Double-Take Availability v4.0.01.00 Integration Guide

Chapter 1: Overview

15. On the Failover Production Server, use /usr/sbin/lvlstmajor to


obtain a list of unused device major numbers:
lvlstmajor
51,54,57,61,65,69,82...

16. On the Primary Production Server, use es_ha_config to configure a


device major number for the Primary Context ID. Choose a device
major number, that is the same on both Production Servers.
Syntax:
es_ha_config ContextID [NewMajorNumber]

For example, when you execute


es_ha_config 1 82

the Primary Context ID is 1, and the new device major number 82 is


available on both Production Servers
17. On the Failover Production Server, use es_ha_config to configure a
device major number for the Primary Context ID. Choose a device
major number, that is the same on both Production Servers.
Syntax:
es_ha_config ContextID [NewMajorNumber]

For example, when you execute


es_ha_config 1 82

the Primary Context ID is 1, and the new device major number 82 is


available on both Production Servers.

Managing RecoverNow in a HA Production Server


Environment
When you manage RecoverNow in a HA Production Server environment
keep in mind:

Changing the RecoverNow Configuration

Managing Failover to the Recovery Server

Changing the RecoverNow Configuration


Changes that you make to an RecoverNow configuration do not
automatically propagate to the Failover Production Server. If you make any
changes to the configuration, you must:

Double-Take Availability v4.0.01.00 Integration Guide

Chapter 1: Overview

1. On the Primary Production Server, delete the Failover Context. Refer to


the section Deleting a Context in Chapter 9, of the Double-Take
RecoverNow User Guide.
2. On the Failover Production Server, delete the Production and Failover
Contexts. Refer to the section Deleting a Context in Chapter 9, of the
Double-Take RecoverNow User Guide.
3. Perform the steps in Configuring Highly Available Production Servers
to update the Primary and Failover Production Server with the current
configuration information.

Double-Take Availability v4.0.01.00 Integration Guide

Chapter 1: Overview

Managing Failover to the Recovery Server


There are two scenarios for Failover from a HA Production Server to the
Recovery Server:

Unplanned Failover

Planned Failover
NOTE

Both scenarios require that you manually perform Failover


operations.

Unplanned Failover
In this scenario, the Production server is unavailable due to a disaster. For
example, an entire site is lost due to a disaster such as a flood or hurricane.
Use the following procedures to restore data from the Recovery Server to
the Production Server. For complete details on these procedures refer to
Chapter 13, Double-Take RecoverNow Disaster Recovery Operations in
the Double-Take RecoverNow User Guide.
1. On the Recovery Server, create a Snapshot and validate the data
integrity:
scrt_ra -C <Context ID> -D <time>

or
scrt_ra -C <Context ID> -t <LFCID>

Once you create a snapshot of the replica, you can analyze the integrity
of the data. If analysis indicates data corruption, remove the snapshot
and use a virtual restore to locate and validate an optimal restore point.
2. On the Recovery Server, backup the data. This provides additional data
protection by keeping complete copies of the data on archive media
such as tape. Refer to Chapter 12, Working with Archived Data, in
the Double-Take RecoverNow User Guide
3. On the Recovery Server, execute Failover. Do one of the following:
Failover Restore: Roll back to the actual data replica.
scrt_ra -C <Primary Context ID> -F [-t | -D | -S]

On the Recovery Server, failover to the latest point in the data:


rtdr -C <Primary Context ID> failover

4. On the Recovery Server, start the application.

Double-Take Availability v4.0.01.00 Integration Guide

Chapter 1: Overview

rtstart -C <Context ID>

5. On the Primary Production Server, ensure:


a. Power is restored
b. System boots up
c. Cluster is stopped
6. On the Recovery server, execute resync:
rtdr -C <Failover Context ID> resync

7. On the Primary Production or Failover Production Servers, execute


resync:
rtdr -C <Primary Context ID> resync

8. On the Recovery Server, stop the application


rtstop -C <Context ID> -F

9. On the Recovery Server, initiate failback to the original Production


Server execute:
rtdr -fC <Primary Context ID> failback

10. On the Production Server, execute failback


rtdr -fC <Primary Context ID> failback

11. On the Production Server, start the application.


rtstart -C <Context ID>

Planned Failover
In this scenario, the administrator has a scheduled maintenance period and
switches operations that run on the Production Server to the designated
Recovery Server.
The data can be restored to the Production Server from the Recovery Server
using the following procedure:
1. On the Recovery Server stop the application.
2. On the Recovery Server failover to the Recovery Server:
rtdr -C <Primary Context ID> failover

3. On the Production Server start the ABA (scrt_aba):


rtdr -fC <failover context> resync

10

Double-Take Availability v4.0.01.00 Integration Guide

Chapter 1: Overview

4. On the Recovery Server start the LCA (scr_lca) and synchronize the
data to the Production Server.
rtdr -fC <failover context> resync

5. On the Recovery Server failback to the primary context:


rtdr -fC <failover context> failback

6. On the Production Server failback to the primary context:


rtdr -fC <failover context> failback

The figure below shows the behavior of a HA Production Server


Configuration.

Double-Take Availability v4.0.01.00 Integration Guide

11

Chapter 1: Overview

HA Production Server Configuration

The figure shows the operation of a HA Production Server configuration,


the Primary Context is active on the Production Servers. In this mode:

12

There are two production nodes with a shared disk between them

Replication is to a third node that lies outside the cluster

Application switching is performed between the two production nodes,


and the RecoverNow roles of the nodes never changes

Double-Take Availability v4.0.01.00 Integration Guide

Chapter 1: Overview

Failover Scenarios
Several failure scenarios are supported, these topics describe the most
significant failure, that of the Production Server. Vision Solutions highly
recommends, for a Production to Recovery configuration, that the
application whose data is being replicated by RecoverNow be configured in
GeoCluster does not automatically failover on failure. This is because, once
a failover is complete, the ability to use RecoverNows data roll-back
(CDP) recovery feature is lost. Switching from Primary mode to Failover
mode on the Recovery Server wipes clean its undo and redo logs.
Once you are notified of the failure, you should determine the cause of
failure and decide whether it is necessary to use the RecoverNow CDP
(roll-back) feature, or to proceed and manually initiate the failover
sequence. If you perform any roll-back, you can use GeoCluster to clear the
failure state, and resume normal operations. The latter (manual failover) is
done by switching the Application from the Production Server to the
Recovery Server via the GeoCluster Web Interface.
Upon failover, the mode for the Recovery Server changes from Primary to
Failover, thereby making accessible to the application (which had also
failed over from the Production to the Recovery Server) the replicated data,
by activating the logical volumes and filesystems associated with that
Context.
On recovery of the failed Production Server, in keeping with the GeoCluster
policy to not automatically fall back, the Production Server is also switched
to Failover mode, and replication is activated. Although the terminology
used by RecoverNow is that the Failover Context is in use, this is not a
degraded state; normal operations can occur indefinitely.
Once the Production servers data has been synchronized with the Recovery
server, the user can manually switch the Application from the Recovery
Server back to the Production Server. In this way, the user can initiate the
recovery sequence, which causes the mode of the Recovery Server to
change from Failover to Primary, thereby re-assuming the role of recovery,
while the Production Server changes to its Primary mode and re-initiates
replication.
For each Primary and Failover Context pair GeoCluster manages, the
GeoCluster Web Interface provides:

Status indicators for the Context IDs

Replication function on each server

Direction of replication

List of replicated filesystems, logical volumes, and volume groups


controlled by RecoverNow.

Double-Take Availability v4.0.01.00 Integration Guide

13

Chapter 1: Overview

Below is a sample page from the GeoCluster Web Interface:

14

Double-Take Availability v4.0.01.00 Integration Guide

Planning

This section describes planning considerations that are specific to


configuring RecoverNow applications in GeoCluster.

Storage
In RecoverNow, data to be replicated is kept in non-shared storage. Each
GeoCluster node has its own storage relegated to replication. That means
that the Production Server and the Recovery Server each have their own
storage.
An application runs on the Production server. When an application runs
on the Production server, it accesses only the primary data store. When an
application runs on the Recovery Server, it accesses the failover data
store.

Disk Space
If you are using RecoverNow in tandem with GeoCluster, the 64-bit
kernal version of RecoverNow uses approximately 24 MB in directory
/usr/scrt.
However, over time, information will be added to the following files:

/usr/scrt/log

/usr/scrt/archive

/usr/scrt/run

/usr/scrt/config

Settings
Specify the following settings:
Configuration 1For a Highly Available Production Server
configuration the AUTO ON: Volume Group parameter must be set to
"no" for the RecoverNow shared Volume Groups. The value can be

Double-Take Availability v4.0.01.00 Integration Guide

15

Chapter 2: Overview

displayed using the lsfs <filesystem> command. It can be changed using


smit chfs.
Configuration 2For a Production to Recovery configuration the AUTO
ON: Volume Group parameter must be set to "yes" for the RecoverNow
Volume Groups. The value can be displayed using the lsvg <VG name>
command. It can be changed using smit chvg.
For both configurations 1 and 2: The auto mount parameter is set in
/etc/filesystems using the AIX "chfs" command and must be "no" for all
RecoverNow PVS filesystems.
Once RecoverNow is properly configured, GeoCluster discovers the
configuration as part of the Discover Storage functionality.

Setting RecoverNow Applications to Manual Failover


For GeoCluster configurations that use RecoverNow, it is recommended
that failover not be set to automatically occur. Instead, it is recommended
that GeoCluster be configured to wait for the user to initiate a manual move
should a failure or recovery occur.
Note: Manual failover is recommended to preserve the information in the
redo and the undo logs.
If a failure occurs, then before GeoCluster performs a failover of the
application from the Production to the Recovery Server, the user may want
to take some action on the Recovery Server which involves Continuous
Data Protection (CDP), which relies on the existence of the redo and undo
logs. Once the failover occurs, the redo and undo logs are deleted. The user
must, therefore, perform any CDP actions prior to the failover.
For recovery to be successful, it is recommended that the user ensure the
data on the Production Server be in sync with the data on the Recovery
Server before fallback occurs. Configuring GeoCluster to wait for the user
to initiate a manual switch gives the user the opportunity to check the data
integrity. In addition, it gives the user the opportunity to choose when and
whether to perform a fallback, or to instead, start replication in the opposite
direction, keeping the application running on the Recover Server, thereby
having one less disruption in service.

Network Bandwidth and CPU Processing


When you run RecoverNow in tandem with GeoCluster, you must maintain
enough network bandwidth to replicate high volume/high transaction
environments. When bandwidth is low during peak periods of traffic, rather
than scaling back application performance to minimize network
bottlenecks, you should reduce the network load by temporarily stopping

16

Double-Take Availability v4.0.01.00 Integration Guide

Chapter 2: Overview

unnecessary use of the network by lower-priority applications. GeoCluster


can typically buffer the replication component by ensuring that a proper
environment is maintained such that the replication component can
successfully perform its duties
For example, replication requires at least one communication link, though
there is preferably a back-up link available. Although the replication
component itself might provide some amount of management of these links,
keeping the links highly available is within the purview of the clustering
component. Similarly, GeoCluster can provision additional resources as
required by replication, such as network bandwidth, storage capacity, or
CPU cycles.
When the demands placed on the system may increase for some length of
time, GeoCluster can provision additional CPU to the server
To enable load balancing, GeoCluster can concurrently replicate
independent sets of data in different directions to allow one or more
applications running on Server A replicating their data to Server B, while
simultaneously having applications running on Server B replicating their
data to Server A. As load requirements change, applications can then be
moved from one server to the other, with the direction of replication
automatically reversed.

Double-Take Availability v4.0.01.00 Integration Guide

17

Chapter 2: Overview

18

Double-Take Availability v4.0.01.00 Integration Guide

Installation and Setup

Installation and Setup


Requirements
RecoverNow and GeoCluster only support a two-node cluster
configuration in which each node is running the same or similar operating
systems within two release levels of each other.

Setup
This section is intended for customers who want to install and configure
RecoverNow and GeoCluster.

Installation and Licensing


4 licenses are required:

2 licenses for RecoverNow

2 licenses for GeoCluster

Refer to the Double-Take RecoverNow User Guide and the Double-Take


GeoCluster User Guide for installation and licensing information.

Step 1: Configure RecoverNow


This list provides the general steps for configuring RecoverNow. Refer to
the Double-Take RecoverNow User Guide for details:
1. Allocate space for RecoverNow logs and journals
2. Determine the size of the:
Production Journal
Recovery Journal
Volumes to be Protected
Snapshot Journal
Log file
Double-Take Availability v4.0.01.00 Integration Guide

19

Chapter 3: Overview

3. Determine overall storage requirements


4. Fill out checklist for:
Database information
Network information
Storage information
General information
5. Set up logical volumes and volume groups
6. Create Primary Context
7. Create Failover Context
8. Start RecoverNow and test
NOTE

Logical Volumes must be set to failover at the same time.

Defining RecoverNow Contexts


For each RecoverNow context that is managing data for one or more
applications in GeoCluster, define the applications for which RecoverNow
is protecting data and include the principal context ID. You are defining the
cluster using the same nodes.

If you are using GeoCluster, it is able to communicate with


RecoverNow

If you are using another HA tool, you must write your own script to
make it highly available

In GeoCluster and RecoverNow, application points to a command that


can start any number of processes and other applications. For example, an
application could be composed of Applications A, B, and C that would
reside on the following logical volumes:

Application A: LV 1-10

Application B: LV 11-20

Application C: LV 21-30

These logical volumes are part of a Volume Group that is active on only one
node. If an application fails over, all of the LVs must go with it so that a
logical volume is not active on more than one node at a time.
To set up this scenario, define your LVs and Volume Group in a
RecoverNow context using RecoverNow. Any context which uses

20

Double-Take Availability v4.0.01.00 Integration Guide

Chapter 3: Overview

GeoCluster to manage RecoverNow is limited to one context per


application. When GeoCluster fails over an application, you must make sure
that all the data from the application is included in the context ID that is part
of that application. When you configure your applications in GeoCluster,
you must ensure that the application contains all of the LVs and the Volume
Group.

Step 2: Configure GeoCluster


This list provides the general steps for configuring RecoverNow in
GeoCluster:

Create a two-node cluster. Refer to the GeoCluster User Guide for


details.

Create a RecoverNow Application within GeoCluster. Refer to Creating


a RecoverNow Application within GeoCluster.

Deploy cluster. Refer to the Double-Take GeoCluster User Guide.

Monitor the Application Properties in GeoCluster Operations mode


Refer to Monitor the Application Properties in GeoCluster Operations.

Creating a RecoverNow Application within GeoCluster


In this step you configure RecoverNow contexts (representing application
contexts defined in RecoverNow) as GeoCluster primary and failover
contexts.
1. Select New Application. The New Application page is displayed.
2. Enter the application name as Context-1. RecoverNow primary
applications are defined as C1, C2, C3, and so on. C represents a
RecoverNow context. RecoverNow Failover contexts are defined as
C11, C12, C13, and so on. Primary context C1 is associated with
Failover context C11, Primary context c2 is associated with Failover
context C12.
3. Enter a brief description of the GeoCluster application in the
Description box. For example, if the RecoverNow application is C1,
representing Context 1, then you might enter: ESVG1 primary context
ID 1 failover context ID 11. This indicates that this is for an
application that is defined in RecoverNow as Primary context 1 and
Failover context 11.
4. Select No for Start when cluster starts.
5. Select No for Automatically move on failure so that GeoCluster waits
for the user to initiate a manual switch should a failure or recovery
occur. The reason that manual failover and fallback is recommended is
to preserve the information in the redo and the undo logs.

Double-Take Availability v4.0.01.00 Integration Guide

21

Chapter 3: Overview

6. Select OK. The Application Properties screen is displayed with the


General tab selected.
7. Select the Processes tab. Enter the RecoverNow Start and Stop
command file paths and the name of the pathname of the RecoverNow
monitor process. You can set the Delay before starting and the Polling
interval or accept the RecoverNow defaults.
8. Select No for Attempt to restart on first failure.
9. Select OK.
10. Select the RecoverNow tab. From the Primary Context ID pull-down
menu, select 1 for the first application context. From the Failover
Context ID pull-down menu, select 11.
11. Select OK.
12. Repeat the process for each RecoverNow application context you want
to configure.
You can select Nodes from the panel on the left to show the GeoCluster
nodes, the status of the web host connection for each node, and license
expiration.

Monitor the Application Properties in GeoCluster Operations


After you deploy the GeoCluster, the Applications Properties page in
Operations mode displays information about the RecoverNow application
contexts you have defined.
The screen below shows a sample Application context configured in
GeoCluster displayed when you select the RecoverNow tab:

22

ApplicationThe RecoverNow application context name

Cluster NameThe name of the GeoCluster cluster

Primary Context IDThe RecoverNow Primary Context ID associated


with the RecoverNow application defined in GeoCluster

Failover Context IDThe RecoverNow Failover Context ID associated


with the RecoverNow application defined in GeoCluster

Production Server/Recovery Server replication directionShown by the


green arrow pointing from the Production Server to the Recovery
Server, the GeoCluster nodes and associated Primary Contexts

RecoverNow storageStorage for the application context (which


includes, Filesystems, Logical Volumes, Volume Group, and Nodes)

Double-Take Availability v4.0.01.00 Integration Guide

Chapter 3: Overview

Double-Take Availability v4.0.01.00 Integration Guide

23

Chapter 3: Overview

24

Double-Take Availability v4.0.01.00 Integration Guide

Documentation Set

Double-Take Availability Documentation


The documentation set for Double-Take Availability includes:

Title

Description

Double-Take Availability Integration


Guide

Use this guide to review installation, planning, and


set up considerations for using both products.

Double-Take GeoCluster Release Notes

Use this document to learn the latest information


about new and changed features of Double-Take
GeoCluster.

Double-Take GeoCluster User Guide

Use this guide to install, configure and administer


the Double-Take GeoCluster high availability
software.

Double-Take RecoverNow User Guide

Use this guide to install, configure and administer,


and maintain Double-Take RecoverNow data
replication software.

Double-Take RecoverNow Release Notes

Use this document to learn the latest information


about new and changed features of Double-Take
RecoverNow.

Double-Take Availability v4.0.01.00 Integration Guide

25

Chapter A: Overview

26

Double-Take Availability v4.0.01.00 Integration Guide