Integration Guide

Double-Take Availabil i tyVersion 4.0 SP01Double-Take Avai labi l i ty Integrat ion Guide

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 WebSphereInternational 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:

CustomerCareVision Solutions, Inc.Telephone: 1.800.337.8214 or 1.949.724.5465Email: [email protected] Site: www.visionsolutions.com/Support/Contact-CustomerCare.aspx

Double-Take Availability v4.0.00.02 Integration Guide iii

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

Supported Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Production Server and Recovery Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Switching the Production and Recovery Node Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Production to Recovery Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Highly 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Setting RecoverNow Applications to Manual Failover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Network Bandwidth and CPU Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

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

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Installation and Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Step 1: Configure RecoverNow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Defining RecoverNow Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Step 2: Configure GeoCluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Contents

Contents

iv Double-Take Availability v4.0.00.02 Integration Guide

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

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

Appendix ADocumentation Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25Double-Take Availability Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Double-Take Availability v4.0.01.00 Integration Guide 1

Overview of Double-Take Availability 1

IntroductionA 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

2 Double-Take Availability v4.0.01.00 Integration Guide

Supported ConfigurationsVision 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 ConfigurationA 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 RolesYou 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 EnvironmentA 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 RequirementsReview 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 and /usr/scrt/run/c 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 and /usr/scrt/run/c on the shared volume group that will be used for the RecoverNow File Containers.

Configuring Highly Available Production ServersTo configure Highly Available Production Servers:

Chapter 1: Overview


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

mount /usr/scrt/run/c

mount /usr/scrt/run/c

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 -M

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

rtdr -C -F setup

5. On the Recovery Server, initialize the context.

scsetup -C -M

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

rtdr -C -F 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= SCCuObj SCCuAttr SCCuRel >/tmp/C.cfg

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

odmget -q ContextID= SCCuObj SCCuAttr SCCuRel >/tmp/C.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.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.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 /tmp/C.cfg

sccfgd_putcfg /tmp/C.cfg

14. On the Primary Production Server, use /usr/sbin/lvlstmajor to obtain a list of unused device major numbers:

lvlstmajor46,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:

lvlstmajor51,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 EnvironmentWhen 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 ConfigurationChanges 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 ServerThere 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 FailoverIn 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 -D

or

scrt_ra -C -t

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 -F [-t | -D | -S]

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

rtdr -C failover

4. On the Recovery Server, start the application.

Chapter 1: Overview


rtstart -C

5. On the Primary Production Server, ensure:

a. Power is restoredb. System boots upc. Cluster is stopped

6. On the Recovery server, execute resync:

rtdr -C resync

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

rtdr -C resync

8. On the Recovery Server, stop the application

rtstop -C -F

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

rtdr -fC failback

10. On the Production Server, execute failback

rtdr -fC failback

11. On the Production Server, start the application.

rtstart -C

Planned FailoverIn 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 failover

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

rtdr -fC resync

Chapter 1: Overview


4. On the Recovery Server start the LCA (scr_lca) and synchronize the data to the Production Server.

rtdr -fC resync

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

rtdr -fC failback

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

rtdr -fC failback

The figure below shows the behavior of a HA Production Server Configuration.

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:

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 ScenariosSeveral 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.

Chapter 1: Overview


Below is a sample page from the GeoCluster Web Interface:


Planning 2

This section describes planning considerations that are specific to configuring RecoverNow applications in GeoCluster.

StorageIn 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 SpaceIf 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

SettingsSpecify 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

Chapter 2: Overview


displayed using the lsfs 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 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 FailoverFor 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 ProcessingWhen 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

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.

Chapter 2: Overview



Installation and Setup 3

Installation and Setup

RequirementsRecoverNow 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.

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

Installation and Licensing4 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 RecoverNowThis 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

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 ContextsFor 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

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 GeoClusterThis 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 GeoClusterIn 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.

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 OperationsAfter 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:

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



Documentation Set A

Double-Take Availability DocumentationThe 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.

Chapter A: Overview


ContentsOverview of Double-Take AvailabilityIntroductionSupported ConfigurationsProduction Server and Recovery Server ConfigurationSwitching the Production and Recovery Node Roles

Production to Recovery ConfigurationHighly Available Production Server EnvironmentRecoverNow Configuration RequirementsConfiguring Highly Available Production Servers

Managing RecoverNow in a HA Production Server EnvironmentChanging the RecoverNow ConfigurationManaging Failover to the Recovery ServerUnplanned FailoverPlanned Failover

HA Production Server ConfigurationFailover Scenarios

PlanningStorageDisk SpaceSettingsSetting RecoverNow Applications to Manual FailoverNetwork Bandwidth and CPU Processing

Installation and SetupInstallation and SetupRequirementsSetupInstallation and Licensing

Step 1: Configure RecoverNowDefining RecoverNow Contexts

Step 2: Configure GeoClusterCreating a RecoverNow Application within GeoClusterMonitor the Application Properties in GeoCluster Operations

Documentation SetDouble-Take Availability Documentation

Date post:	08-Jan-2016
Category:	Documents
Upload:	syed-fahad-ali
View:	37 times
Download:	0 times

Integration Guide

Documents