The Apache Tomcat cluster needs to know the unique runtime identifier for each node. Also, to use ActiveMQ in an Apache Tomcat cluster, Identity Governance needs the host name or IP address and port for each ActiveMQ server.
To run Identity Governance in an Apache Tomcat cluster, each node in the cluster must have a unique runtime identifier. Also, the Apache Tomcat instance should run on the same port as the port exposed by the load balancer. However, the instance might need to use a different port.
NOTE:It is possible for two clustered nodes to simultaneously attempt to claim a data processing task. When this occurs, one of the nodes will report a “stale object” exception, which you can ignore since the work will still be carried out.
For more information, see Section 2.3.4, Ensuring High Availability or Load Balancing for Identity Governance.
Stop Apache Tomcat, if the application server is running. For more information, see Section 3.4.3, Starting and Stopping Apache Tomcat.
To specify a unique runtime identifier, complete the following steps:
Log in to primary node in the cluster.
In a text editor, open the ism-configuration.properties file.
Linux: Default location in /opt/netiq/idm/apps/tomcat/conf
Windows: Default location in C:\netiq\idm\apps\tomcat\conf
Ensure that com.netiq.iac.runtime.id is a unique value that represents the node.
For example, node1 or ProdNode1.
Save and close the file.
Repeat this procedure for each node in the cluster.
To specify a different port for a node than the port exposed by the load balancer, complete the following steps:
Log in to the node where you want to change the port.
In a text editor, open the ism-configuration.properties file.
Linux: Default location in /opt/netiq/idm/apps/tomcat/conf
Windows: Default location in C:\netiq\idm\apps\tomcat\conf
For com.netiq.iac.url.local.port, specify the Apache Tomcat port for the local node.
Save and close the file.
When you have completed all configuration changes for the cluster, start Apache Tomcat. For more information, Section 3.4.3, Starting and Stopping Apache Tomcat.
To represent the host name and port for the ActiveMQ server, the installation process creates the JMS broker URI parameter in the Identity Governance Configuration utility. This parameter has a tcp:// prefix by default. However, in a clustered environment, the parameter needs a failover prefix and a comma-separated list of the ActiveMQ hosts.
For more information, see the ActiveMQ documentation, such as The Failover Transport and Introduction to Master/Slave.
For each instance of Identity Governance, run the Identity Governance Configuration utility.
Linux: Default location in /opt/netiq/idm/apps/idgov/bin/
Console mode: ./configutil.sh -password db_password -console
Guided mode: ./configutil.sh -password db_password
Windows: Default location in C:\netiq\idm\apps\idgov\bin\
Console mode: configutil.bat -password db_password -console
Guided mode: configutil.bat -password db_password
For more information, see Section 14.1.3, Using the Identity Governance Configuration Utility.
Select Workflow Settings.
(Conditional) Select Enable persistent notification message queue to ensure guaranteed message delivery.
If you specified ActiveMQ during installation, this setting should already be enabled.
For JMS broker URI, add failover: to the prefix, then add the host name or IP address and port for each ActiveMQ server.
Use commas to separate the server values. For example:
failover:tcp://amq1.mycompany.com:61616,tcp://amq2.mycompany.com:61616
Save the changes then close the utility.
When running IG in a clustered environment, a node could go down while a data production job is running on it. In some configurations, these jobs could become orphaned processes that do not complete. When this happens, you might need to clean up these processes to ensure the health and performance of your system.
Data production jobs are tied to specific runtime instances, identified by their runtime_identitifer. Do not use a host name or other identifier that might change if a runtime instance is restarted so that jobs do not become orphaned. When you start a new instance and control the identifier it is using, you can use a previously used identifier to make sure IG can clean up jobs correctly. If you do not have an option to start a new node with the same identifier, you can reassign data production jobs through the following manual process.
Find the node identifier from the local configuration property file on a node. Look for the line property key is: to locate the identifier.
Run a SQL statement against the igops database to retrieve the production records you want to clean up. For example:
select * from data_production where runtime_identifier = '<node runtime identifier>' and status != 'COMPLETED' and status != 'ERROR' For each production record from the SQL statement results do the following:
Execute a REST API call GET /dataprod/mgt/id using the production ID.
Modify the payload by setting the runtime identifier in the payload to the node identifier where you want to reassign the production process.
Execute a REST API call PUT /dataprod/mgt/id using the production ID and modified payload from step 3b.