Thank you Mostafa!
Assuming that only the OEM Oracle database instance is used in the appliance(s)....
>>>The RSA Identity Governance & Lifecycle Appliance clustering is not available in a Active-Passive setup for failover.
>>>Both nodes are available and working simultaneously.
>>>Note that the clustering does not include the database, i.e. all nodes point to one central database.
1. Is the RSA Identity Governance and Lifecycle appliance then available as an "Active-Active" cluster at the application server and web server level only? If this is correct, then; is the Oracle database in one of the appliances is sitting idle, or just switched off?
2. If two or more RSA IGL appliances are clustered, can all the appliances be pointed to a single "Central" Oracle OEM database in one of the appliances?
3. Can the Oracle instance in the appliance that DOES NOT contain the central database - be made a hot-standby (not Oracle HA, but a "hot standby") to the central database used by the cluster?
4. What is the recovery procedure (exact steps, and approximate time taken) if the appliance containing the "central database" used by two or more clustered appliances were to go down? Please assume that only the OEM Oracle database is being used.
5. Where does the configuration database (for the application servers) reside within the appliances? Is it a different table within the central (Oracle OEM) database used by the appliance, or some other database within the appliance?
6. If users are provisioned by the appliance to an LDAP, does (or can) the LDAP reside within the same OEM database inside the appliance(s)? Is there a run-time copy of the user identity store (user IDs and passwords) running within the appliance?
Hi Yajnavalkya,
The RSA Identity Governance & Lifecycle Appliance clustering is not available in a Active-Passive setup for failover. Both nodes are available and working simultaneously.
Note that the clustering does not include the database, i.e. all nodes point to one central database. You have one System Operations Node (SON), and one or more General Nodes.
Most stuff can be done from both nodes (Reviews, activities, submitting CRs ... etc) but only the SON can perform stuff like running collectors.
1. It is not recommended to be over different data centers. Cluster nodes communication is not designed to work over long (potentially unstable) WAN connections. It would work but could cause performance issues and require multiple ports to be open between data centers which is not ideal for most.
2. Since both nodes are working, all you need to do is Click one button on the UI to make one of the general Nodes the new SON, then restart this node. So it would take the time you need to restart the application.
3. Depending on why the node failed, but the worst case is that you would just need to reinstall the failed node from scratch and point it to the same database. So it would be the time needed to do a remote Database installation (i.e. an Application installation without installing a new DB).
4. It is available as both and clustering can be done on both as well.