The steps to deploy each, single IIQ instance depend upon the specific app server env. Each IIQ instance runs inside a separate JVM from the application server(s) context.
When repeating these steps for multiple IIQ instances, apply the app server's system engineering and performance sizing rules/guidelines to deploy each IIQ instance with sufficient resources.
In most environments, multiple IIQ instances (of the same version) share the same underlying repository. Every IIQ instance uses a "iiq.properties" startup file with the repository connection info. The actual repository must provide sufficient throughput/resources to handle all requests.
The iiq.properties file also contains two properties, "taskSchedulerHosts" and "requestSchedulerHosts", that contain hostnames (CSV with values formatted as from InetAddress.getHostName method). When set, then task and request schedulers only start on the (listed) hostnames:
The task scheduler manages threads for scheduled tasks. The request scheduler processes emails, provisioning, and other events. Neither of these settings impact the UI requests from
users/browsers (via HTTP session).
While IIQ's hostname defaults to the string returned by JDK's "InetAddress.getLocalHost().getHostName()" method, the JVM system property "iiq.hostname" can be used to override the value. This allows running multiple instances on the same "box" to take advantage of multiple cores/cpus. The configured string then appears as the hostname in the result from "about" (console or debug UI) along with other scheduler info.
As a best practice, assign unique names among all IIQ instances. For example, WebSphere's admin tool offers an UI for instance-specific generic JVM arguments (such as "-Diiq.hostname=foo1"):
Lastly, in same "box" environments, IIQ instances also share the same filesystem(s). This impacts the IIQ logging feature when IIQ instances even share the "log4j.properties" file. To avoid concurrent logging to the same file, either direct messages to the instance's stdout (then cfg app server to save instance's stdout to unique file) or start each instance separately (then modify "log4j.properties" output file).
The only thing version specific I see in this post is the ability to control which instances run the task processor and request processor. That capability was introduced in IdentityIQ 3.0, for all practical purposes for most, it has always been like this.
Just wanted to confirm that these steps remain the same for the recent versions as well? We are installing 7.0p2 and would like to know if there is anything additional that needs to be done for clustered deployment. The iiq.properties file does not have those two environment properties, i believe i just need to add those two and specify the hostnames?
