High Availability for Informatica Data Replication in a Cluster Environment

(1)

High Availability for Informatica Data

Replication in a Cluster Environment

(2)

Abstract

This article describes how to configure high availability for Data Replication in a cluster environment. With high availability, when the active cluster node fails, the Data Replication Server Manager and the source or target database can fail over to another node and continue processing. This article provides sample scripts and procedures for deploying Data Replication failover in the Red Hat Cluster Suite environment.

Supported Versions

• Informatica Data Replication 9.5.1 HotFix 2

Overview

In the replication environment, you can use cluster software to manage a group of nodes for high availability of the source or target database and the database applications. The database runs on a single cluster node and stores the database files and logs in shared storage. If that cluster node fails, the database and all of the database applications can fail over to another available node. The cluster provides a floating IP address that you can use to configure access to an active node.

To provide high availability for a database, you must configure the cluster for database failover. Then, if a node failure occurs, the cluster restarts the database on another available node. How you configure database failover depends on the cluster software that you use.

If you run replication jobs, such as InitialSync, the Extractor, and the Applier, on a source or target database system that is managed by cluster software, you can also configure high availability for Data Replication. To provide high availability for replication jobs, configure the cluster for Server Manager failover. Then, if a node failure occurs, the cluster restarts the Server Manager instance, in addition to the database instance, on another available node. The Server Manager then resumes all of the replication jobs.

This article describes a sample high availability scenario that includes an Oracle source and target, each in a two-node cluster managed by Red Hat Cluster Suite. This article also provides sample scripts for configuring database and Server Manager failover in this environment.

Data Replication Installation in a Cluster Environment

To provide high availability for Data Replication and support Server Manager failover, install Data Replication in shared storage that can be mounted to any cluster node. If an active node goes down, the cluster restarts the Server Manager instance from the Data Replication installation in shared storage. Because the replication configurations and

(3)

intermediate files are stored in the shared Data Replication installation, the Server Manager can accurately resume replication jobs after failover.

Informatica recommends that you use a shared storage solution, such as CFS, GFS, or DBFS, to mount the shared storage to all of the nodes in the cluster. Alternatively, you can mount the shared storage to the active node and configure the cluster to mount the shared storage to an available node during failover. All of the cluster nodes must use the same path to the mounted shared storage.

Order of Restarting Processes for Failover

To accurately fail over replication jobs to another cluster node, configure the cluster software to restart the processes in the following order:

1. Floating IP address 2. Mount points

You do not need to configure failover of the mount points if you use a shared storage solution that lets you mount the shared storage to all of the cluster nodes.

3. Database

4. Data Replication Server Manager

After the Server Manager restarts, it analyzes the schedules and tasks that were running before the failover and then resumes these tasks and schedules.

Typically, failover clusters provide mechanisms for defining dependencies between cluster resources to ensure that processes are restarted in the correct order.

Considerations for Configuring High Availability for Data

Replication

Consider the following information that pertains to configuring high availability for Data Replication:

• To define a connection to the source and target in the replication configuration, use the floating IP addresses rather than physical IP addresses.

• To connect to the Server Manager Main server and to define all of the subservers, use the floating IP addresses rather than physical IP addresses.

• Use the same path to mount the shared storage that contains the database files and Data Replication installation on all of the cluster nodes.

• Ensure that the environment settings are the same for all of the cluster nodes. Also ensure that you define the DBSYNC_HOME environment variable on all nodes.

(4)

Sample Cluster Topology

In the sample scenario, both the source and target Oracle databases are in a two-node cluster that is managed by Red Hat Cluster Suite. The following figure shows the replication topology:

Data Replication is installed in shared storage on both the source and target systems. The shared storage on both systems is mounted to the /idr path on nodes A and B. The shared storage on the source system uses CFS, and the shared storage on the target system uses GFS.

The Data Replication Server Manager runs in the following locations:

• The Server Manager Main server runs on the source system from the shared installation. This Server Manager instance manages the InitialSync and Extractor tasks.

• The Server Manager subserver runs on the target system from the shared installation. This Server Manager instance manages the Applier tasks.

The Data Replication Console runs on a standalone system.

Configuring High Availability for Data Replication in a Red Hat

Cluster Suite Environment

To configure high availability of the Oracle source or target database and Data Replication in the sample cluster topology, create resources that represent initialization scripts for the database and Data Replication.

Create a resource for the Oracle database as a child resource of the floating IP address resource. Then create a resource for Data Replication as a child resource of the Oracle resource. With this configuration, the cluster starts processes in the correct order when failover occurs.

Note: This procedure does not describe how to create a resource that mounts the shared storage because the CFS

and GFS storage solutions mount storage to all of the nodes in the cluster. If you use a shared storage solution that mounts storage to a single cluster node, create a child resource of the floating IP address resource that creates the mount points.

(5)

This procedure covers high availability configuration only for Data Replication failover. It does not cover cluster-specific configuration settings such as failover domains or recovery policy. This procedure assumes that you use cluster settings that correspond to your cluster environment and enterprise needs.

1. Create a service group and add a floating IP address resource as the root resource.

The Data Replication components use the IP address that is routed to an active cluster node to connect to the database.

2. Add a child resource of the floating IP address resource to represent an initialization script for the Oracle database.

a. Select Script as the resource type and enter a descriptive resource name. In this sample scenario, use the name "orcl" for this child resource.

b. Create an initialization script that stops and starts the Oracle database. For the sample script, see

“Sample Scripts for Database Failover” on page 5.

c. Specify a path to the initialization script for the orcl resource.

After the IP address fails over to another node, the cluster uses this initialization script to restart the Oracle database on another node.

3. Add a child resource of the orcl resource to represent an initialization script for the Server Manager Main server or subserver.

a. Select Script as the resource type and enter a descriptive resource name. In this sample scenario, use the name "idr" for this child resource.

b. Create an initialization script that stops and starts the Server Manager. For the sample script, see

“Sample Script for Server Manager Failover” on page 6. c. Specify a path to the initialization script for the idr resource.

After the Oracle database fails over to another node, the cluster uses this initialization script to restart the Server Manager on that node.

Sample Scripts for Database Failover

The following initialization script is associated with the orcl resource: #!/bin/sh

# chkconfig: 345 99 10

# description: Oracle auto start-stop script. #

# Set ORA_OWNER to the user id of the owner of the # Oracle database software.

ORA_OWNER=oracle case "$1" in 'start')

# Start the Oracle databases:

# The following command assumes that the oracle login # will not prompt the user for any values

# Ensure that you do not run the startup as a background # process to guarantee correct startup order of resources

su $ORA_OWNER -c "~/scripts/startup.sh >> ~/scripts/startup_shutdown.log 2>&1" touch /var/lock/subsys/dbora

;; 'stop')

# Stop the Oracle databases:

# The following command assumes that the oracle login # will not prompt the user for any values

su $ORA_OWNER -c "~/scripts/shutdown.sh >> ~/scripts/startup_shutdown.log 2>&1" rm -f /var/lock/subsys/dbora

;; Esac

The following script stops the Oracle database: #!/bin/bash

export TMP=/tmp export TMPDIR=$TMP

(6)

export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1 export PATH=$ORACLE_HOME/bin:/usr/sbin:/usr/local/bin:$PATH export ORACLE_UNQNAME=orcl1 export ORACLE_SID=orcl1 ORAENV_ASK=NO . oraenv ORAENV_ASK=YES # Stop Database

sqlplus / as sysdba << EOF SHUTDOWN IMMEDIATE; EXIT;

EOF

# Stop Listener lsnrctl stop

The following script starts the Oracle database: #!/bin/bash export TMP=/tmp export TMPDIR=$TMP export ORACLE_HOSTNAME=ha.cluster1.localdomain export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1 export PATH=$ORACLE_HOME/bin:/usr/sbin:/usr/local/bin:$PATH export ORACLE_UNQNAME=orcl1 export ORACLE_SID=orcl1 ORAENV_ASK=NO . oraenv ORAENV_ASK=YES # Start Listener lsnrctl start # Start Database

sqlplus / as sysdba << EOF STARTUP;

EXIT; EOF

Sample Script for Server Manager Failover

The following initialization script is associated with the idr resource:

#!/bin/sh

# chkconfig: 345 99 10

# description: Server Manager auto start-stop script. #

# Set ORA_OWNER to the user id of the owner of the # Oracle database software.

ORA_OWNER=oracle case "$1" in 'start')

# Start the Server Manager:

cd /idr/DataReplication.linux.x86_64/ ; ./server_manager.sh >> /idr/startup_shutdown.log 2>&1 touch /var/lock/subsys/idr

;; 'stop')

# Stop the Server Manager:

cd /idr/DataReplication.linux.x86_64/ ; ./server_manager.sh stop >> /idr/startup_shutdown.log 2>&1 rm -f /var/lock/subsys/idr

;; esac

Author

Anna Turukina

High Availability for Informatica Data Replication in a Cluster Environment