Following a rigorous methodology is key to delivering customer satisfaction and expanding analytics use cases across the business.
In today’s world, businesses expect their production applications and supporting databases to be available 24/7. In order to minimize any unplanned outages, many companies have implemented the following for their databases in the Linux, UNIX, and Windows environments.
For the PowerCenter environment, they often will also implement PowerCenter Grid with High Availability (HA). With these precautions implemented, the failover is automatic with little to no disruption in service.
Unfortunately, PowerExchange does not provide an HA component. When Informatica Professional Services (IPS) is involved on a project that involves PowerExchange Change Data Capture (CDC), IPS will recommend an architecture that will provide failover capabilities, but the failover process will be a manual one. A script can always be created to automate this failover process if the PowerExchange primary or backup node becomes unavailable. It is important to minimize the amount of time that the PowerExchange Listeners and Loggers are not running.
The image below depicts a failover architecture that can be implemented for PowerExchange CDC. This architecture has two Linux servers, with an NFS shared mount point between each server. The PowerExchange environment resides on the NFS shared mount point and is hosting multiple PowerExchange Listeners/Loggers for Oracle and SQL Server. In addition, it is also hosting remote PowerExchange Listeners/Loggers for z/OS and i5/OS. If the PowerExchange CDC Publisher is being used, it can be placed on the same NFS shared mount point as PowerExchange CDC so that it also has failover capabilities.
Besides providing support for failover, another benefit of this failover architecture is that it will allow maintenance to be done on one of the Linux PowerExchange servers while the other continues to support the environment. Often, sites will implement this architecture and flip-flop between the primary server and backup server on a monthly basis.
Implementing the NFS shared mount point between the primary and backup server nodes, for the PowerExchange Listeners and Loggers, requires the following.
In this architecture, all of the PowerExchange binaries, configuration files, CDC change registration files, CDC extraction map files and CDC data files reside on the NFS shared mount point between the two Linux servers. Only the .bash_profile will need to be updated on each of the Linux servers.
Failover planning should also be done for the PowerExchange default dbmover.cfg configuration file and the PowerExchange Client dbmover.cfg configuration file being used by PowerCenter. The IP address or DNS name for each of the Linux servers hosting the PowerExchange Listeners and Loggers will be different. The PowerExchange default dbmover.cfg file and PowerExchange Client dbmover.cfg file should contain a NODE= statement for the primary server node and backup server node. The location name of the Listener should be the same in both of these NODE= statements. For PowerCenter, this eliminates the need to edit the Location attribute in the PowerCenter connections. Only one of these NODE= statements should be active and the other NODE= statement should be commented out as shown in the example below.
/* Primary Server Node for the Oracle Listener
NODE=(Oracle_Listener,TCPIP,123.456.789.012,2480)
/* Backup Server Node for the Oracle Listener
/*NODE=(Oracle_Listener,TCPIP,456.789.012.345,2480)
/* Primary Server Node for the SQL Server Listener
NODE=(MSSQL_Listener,TCPIP,123.456.789.012,2481)
/* Backup Server Node for the SQL Server Listener
/*NODE=(MSSQL_Listener,TCPIP,456.789.012.345,2481)
This will minimize the changes that need to be done in the PowerCenter Server environment when the primary Linux PowerExchange server becomes unavailable and the backup Linux PowerExchange server is activated.
If the primary Linux PowerExchange server becomes unavailable, all of the PowerExchange Listeners and Loggers will stop running. In addition, any of the PowerCenter CDC workflows using these PowerExchange Listeners will also stop along with any IICS CDC workflow tasks and the PowerExchange CDC Publisher processes. If the PowerCenter session properties are set up correctly so that advanced GMD recovery is in effect, any of the uncommitted updates to the target database will be rolled back. For more information on these settings, review Chapter 6 – Restart and Recovery in the PowerExchange Interfaces for PowerCenter manual.
When the primary Linux server node fails, the following steps will need to be completed to get the PowerExchange Listeners, PowerExchange Loggers, PowerCenter CDC workflows, IICS CDC workflow tasks, and PowerExchange CDC Publisher processes restarted.
When implementing this type of PowerExchange failover architecture it is always advisable to get Informatica Professional Services involved. The IPS resource will be able to implement this architecture and ensure that it will function correctly with minimal impact to the PowerExchange, PowerCenter, IICS, and PowerExchange CDC Publisher environments.
Success
Link Copied to Clipboard