Cluster
Process Server supports clusters of Process Servers operating with a single persistent process store. Multiple process servers share a set of process instances and their deployments.
Two main features of a clustered environment are load balancing and fail over. Load balancing allows processes to be routed to the server in the process cluster with the least load. Fail over allows servers to pick up the load of a failed server in the process cluster.
The following figure shows the Cluster page and the Detail page that is displayed if you click on a link in the Cluster page.
Clicking either of an engine's links displays the Engine Detail page, which has the following information:
Field | Explanation |
|---|
ID | ID assigned to the cluster node by the Process Server engine |
Name | Computer IP address and port where the engine instance is running |
Start Time | Date and time the engine started |
Status | Statuses include Running and Stopped |
No. CPUs | Number that is based on licenses. Select the number of CPUs to view the Engine Detail page, where you can update the number. Then view the Admin > License page to verify that the number of licenses matches the number of CPUs. Process Server reports an estimated number of CPUs based on the information it gathers from the computer. The number may not be accurate if the computer is using CPU hyper-threading technology. |
Stopping this Engine
Press the Stop Engine button to stop this engine. To stop all engines in the cluster, stop the cluster on the Home page. For details, see Server Status
Updating the CPU Count
- 1. Click on a link within the Cluster page for the engine being updated.
- 2. Stop the engine.
- 3. Update the number of CPUs in your cluster.
- 4. Select Update.
- 5. Restart the engine.
WebSphere Cluster Properties
If you are using WebSphere, use the Cluster Properties page to set WebSphere Cluster properties. (Other engines will show different properties.)
The following are WebSphere cluster properties:
- • Cleanup Delay (seconds). This delay is the amount of time a node waits on startup before attempting to recover work from another engine. The default is 300 seconds.
You can increase this value if you notice that the startup of a cluster node is particularly slow. The slowness may be due to contention between nodes for recovering work. A larger value gives a node a chance to startup before another node contends for its recovery work.
- •Time Difference Tolerance Warning (seconds): The difference in seconds that nodes within a cluster can be out-of-sync with one another before a warning state is set. This lets you detect if the time setting is not in sync between cluster members.
- • Failover Delay (seconds). This delay is the amount of time Process Server waits before triggering failover after a node leaves the cluster. (Failover means that work that was in process when the node failed needs to be completed by another server that is currently online.)
After the timeout, Process Server confirms that the node did not rejoin the cluster and still needs failover. Additionally, Process Server issues a warning regarding a likely glitch in cluster communications if a node leaves and rejoins the cluster but the engine itself remained running the whole time. The default delay is 30 seconds.
- •Automatic Failover Enabled: When communications to a node are lost, failover occurs automatically.
- •Log Inbound Cluster Communication: The server logs all inbound cluster calls, along with relevant data it receives. This information is extremely useful when you are debugging cluster configurations issues.
- •Log Outbound Cluster Communication: The server logs all outbound cluster calls, along with relevant data being sent to nodes in cluster. This information is extremely useful when you are debugging cluster configurations issues.
- •Membership Update Interval: Indicates how often you want to poll engines in the cluster to ensure they are active. The default value is 30 seconds.
You can add the name of the WebSphere application server JAAS login for cluster communications.
If your WebSphere application server is running with global security enabled, you can provide or update the JAAS username. Process Server uses this name when performing cluster communications. You can choose from the following:
- •ActiveVOSProvidedUser. JAAS user created with Monitor rights
- •ActiveVOSIdentityAssertion. JAAS user created with Monitor rights and uses the user name and password of the requester to reassert the credentials
- •JAAS Custom Login. JAAS user that is available on the WebSphere application server that has at least Monitor rights
In WebSphere, you can also set a Communications Time Out value for Process Server to send and receive communications to and from engines in the cluster. The default value is 180 seconds.
Weblogic Properties
You can set a Membership Update Interval to indicate how often you want to poll engines in the cluster to ensure they are active. The default value is 30 seconds.
