Informatica Platform Disaster Recovery Setup

Challenge

There are many choices when setting up a Disaster Recovery (DR) environment. Is the DR environment an active or passive environment? Will the DR environment be part of the Production Domain or a separate Domain? These and other decisions to be made as the DR environment is planned and executed are discussed here.

Description

This article provides a brief overview of several scenarios and when they might be appropriate.

DR Setup Option 1 Non-Spanning Domain Active-Passive

1. The DR Domain is setup separately from the Primary Domain.
2. The DR Domain mimics the Primary Domain (Domain name, Services names, File system folder structure, etc.)
3. The Primary nodes are mounted with Primary File System.
4. The DR nodes are mounted with the DR File System.
5. The Primary File System Contents are copied over to the DR File System in near real-time.
6. The Informatica Metadata DB contents are copied over to the DR Metadata DB in near real-time.
7. The DR Nodes are kept off and not started unless there is a DR situation.

DR Scenario

Primary nodes or Metadata DB down

1. The Informatica Domain goes down.
2. The DR Metadata DB is started.
3. The DR nodes are started, and the DR Domain comes up connected to the DR Metadata DB.
4. The Application Services in the DR Domain come up.
5. The Users continue using Informatica connecting to the DR Domain.
6. The directions of replication (File System copy and the Metadata DB copy) are reversed.

DR Setup Option 2 Spanning Domain Active-Passive

1. The DR nodes are also configured as gateway nodes in the same Domain as the Primary nodes.
2. The Primary nodes are mounted with Primary File System.
3. The DR nodes are mounted with the DR File System.
4. The Primary File System contents are copied over to the DR File System in near real-time.
5. The Informatica Metadata DB contents are copied over to the DR Metadata DB in near real-time.
6. The DR Nodes are kept off and not started unless there is a DR situation.

Note: You can configure the DR Metadata DB as alternate server in the Informatica services connections. For example, in Oracle you can configure the JDBC connection string with DR Oracle DB server as the alternate server.

jdbc:informatica:oracle://<PrimaryDBServer>:<PortNumber>;ServiceName=<ServiceName>;AlternateServers=<DRDBServer>:<PortNumber>;LoadBalancing=true

DR Scenario 1

Primary nodes down, Metadata DB running

1. The Informatica Domain goes down.
2. The DR nodes are started, and the Domain comes up still connected to the same Primary Metadata DB.
3. The Application Services configured with HA come up on the DR nodes.
4. The Analyst Service is manually moved to the DR node.
5. The Users continue using Informatica.

DR Scenario 2

Primary nodes running, Metadata DB down

1. The Informatica Domain goes down.
2. The DR Metadata DB is started.
3. The Primary nodes are started and the Informatica Domain comes up connected to the DR Metadata DB.
4. The Users continue using Informatica.

DR Scenario 3

Primary nodes down, Metadata DB down

1. The Informatica Domain goes down.
2. The DR Metadata DB is started.
3. The DR nodes are started, and the Domain comes up connected to the DR Metadata DB.
4. The Application Services configured with HA come up on the DR nodes.
5. The Analyst Service is manually moved to the DR node.
6. The Users continue using Informatica.

Best Practices & Recommendations

• Make sure the DR nodes are not activated unless it is a DR situation.
• Make sure the total number of cores active in either option do not exceed the total number of cores licensed for to stay in compliance.
• Make sure the file system contents are copied to the DR setup in near real-time with minimal latency (using Data-sync for example).
• Make sure the DB contents are copied to the DR setup in near real-time with minimal latency (using Oracle Data Guard for example).
• Use Canonical Names or CNAMEs instead of actual server names so that the Users are oblivious to the changes during a DR situation.