RSA Identity Governance & Lifecycle can be configured to offer business continuity and availability. Other commonly used terms, such as primary, secondary, standby, failover, active/active, active/passive, disaster recovery, database synchronization, replication, clustering, high availability, and redundancy describe essential functionality in a business continuity plan. The purpose of this RSA Knowledge Base Article is to describe the resources available to achieve business continuity and the level of support available from RSA for such solutions.
RSA Identity Governance & Lifecycle can be configured to offer business continuity and availability that is consistent with a customer's business requirements. Listed below are some examples of components that could be part of a business continuity plan. As with any major RSA Identity Governance & Lifecycle implementation, the recommended approach to designing and implementing a business continuity plan for your specific business needs is to engage with RSA Professional Services.
IMPORTANT: Before proceeding with any of the examples below, please validate the plans with your account team to ensure proper licensing and design restrictions before implementation.
Disaster Recovery Option for a Standalone Deployment
Engage RSA Professional Services to evaluate your business requirements and recommend a viable disaster recovery option for your RSA Identity Governance & Lifecycle deployment. Listed below is an example of high-level steps to implement a manual failover for a standalone deployment of RSA Identity Governance & Lifecycle:
- Dedicate a separate system for disaster recovery.
- Install RSA Identity Governance & Lifecycle.
- Maintain the same RSA Identity Governance & Lifecycle version, patch level, and customizations as the system for which disaster recovery needs to be implemented.
- Take regular backups (database and keys) of the system for which disaster recovery needs to be implemented.
- If the system fails, restore the last good backup to the disaster recovery system.
- Download the server archive to install AFX.
- Restart RSA Identity Governance & Lifecycle and AFX.
Disaster Recovery Option for a WildFly Cluster Deployment
The purpose of a WildFly cluster with regards to RSA Identity Governance & Lifecycle is to provide client load balancing. A front-end load balancer setup is required. The load balancer must send a client to the same WildFly server during a session. RSA does NOT provide information about configuring a front-end load balancer.
RSA Identity Governance and Lifecycle does not provide automatic failover capability for nodes. For example, you must explicitly change a general node type to a SON or a SON to a general node. The setup of the WildFly application servers in a cluster configuration does not provide high availability load balancing.
As with a standalone deployment, it is recommended to engage RSA Professional Services to evaluate your business requirements and recommend a viable disaster recovery option for your RSA Identity Governance & Lifecycle deployment.
To maintain a separate disaster recovery system for a cluster environment, the high level steps are the same as for a standalone deployment. For recommendations on which node of a cluster should be the SON for maximum availability please see RSA Knowledge Base Article
000038664 -- How to determine which node of a WildFly cluster should be designated as the Systems Operation Node (SON) in RSA Identity Governance & Lifecycle.
WebSphere and WebLogic Clusters
Enterprise software customers on WebSphere and WebLogic platforms may implement redundancy/failover per their vendor instructions. In these scenarios, RSA only provides support for RSA Identity Governance & Lifecycle on Websphere/Weblogic within the defined functionality of the RSA product. Configuration guidance in regards to Websphere/Weblogic is strictly confined to the attributes necessary for proper deployment and operation of RSA Identity Governance & Lifecycle.
Database Redundancy or Failover
Customers that supply their own Oracle database and want to implement some level of data replication can choose to implement an Oracle data-level replication technique such as Oracle Data Guard, Active Data Guard, GoldenGate, Oracle RAC, etc. for their business continuity purposes. The configuration and maintenance is solely the responsibility of the customer. RSA will only support RSA Identity Governance & Lifecycle in those configurations, and will NOT support the advanced database replication options such as Data Guard, RAC etc.
These advanced Oracle data level replication techniques are NOT available and NOT supported by RSA with an RSA-provided database in RSA Identity Governance & Lifecycle deployments such as the Hardware Appliance, Software Bundle or Virtual Application.
To contact RSA Professional Services, please contact your RSA Sales Representative/Account Team or open a Support Case with
RSA Identity Governance & Lifecycle Customer Support.