Integration Guide

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
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
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.
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
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:
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
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...
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:
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.
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.
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
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.
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
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.
13
Chapter 1: Overview
Below is a sample page from the GeoCluster Web Interface:
14
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
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
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.
17
Chapter 2: Overview
18
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
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
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.
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)
Chapter 3: Overview
23
Chapter 3: Overview
24
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.
25
Chapter A: Overview
26

Integration Guide

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Integration Guide

Transféré par

Droits d'auteur :

Formats disponibles

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

Adobe and Acrobat ReaderAdobe Systems, Inc.

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

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

Microsoft and WindowsMicrosoft Corporation.

Mozilla and FirefoxMozilla Foundation.

NetscapeNetscape Communications Corporation.

Red HatRed Hat, Inc.

Symantec and NetBackupSymantec Corporation.

UNIX and UNIXWarethe Open Group.

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

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

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

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

Double-Take Availability v4.0.00.02 Integration Guide

GeoCluster automates the detection and recovery of applications and

RecoverNow provides a higher level of data protection from both

Double-Take Availability v4.0.01.00 Integration Guide

Production Server and Recovery Server Configuration. A single cluster

Highly Available Production Server Environment. A single cluster

Production Server and Recovery Server Configuration

Switching the Production and Recovery Node Roles

Double-Take Availability v4.0.01.00 Integration Guide

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

Production to Recovery Configuration

Double-Take Availability v4.0.01.00 Integration Guide

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

The Application started by GeoCluster on the Production Server writes

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

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

Highly Available Production Server Environment

RecoverNow Configuration Requirements

Configuring Highly Available Production Servers

Managing RecoverNow in a HA Production Server Environment

RecoverNow Configuration Requirements

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

RecoverNow File Containers must reside on a shared volume group that

Configuring Highly Available Production Servers

Double-Take Availability v4.0.01.00 Integration Guide

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

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

To configure a Service IP Address, change the Production Server

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

5. On the Recovery Server, initialize the context.

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

You must manually copy and load the RecoverNow configuration

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

Double-Take Availability v4.0.01.00 Integration Guide

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

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

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

Double-Take Availability v4.0.01.00 Integration Guide

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

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

For example, when you execute

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

For example, when you execute

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

Managing RecoverNow in a HA Production Server

Changing the RecoverNow Configuration

Managing Failover to the Recovery Server

Changing the RecoverNow Configuration