Application server clusters overview
A cluster groups similar functions on two or more Java™ virtual machines (JVMs) to process a single function, such as scheduled cron tasks. Clusters connect to the same database but operate independently. For example, if the cron task cluster fails, users can still connect to the user interface cluster.
Users who access applications through a browser typically expect immediate responses from the server. A clustered configuration can be scaled to support more concurrent users with faster response times. For example, when the number of concurrent users increases, you can add more JVMs to the user interface cluster.
Resource-intensive operations, such as reports, cron tasks, and the integration framework can be configured to run in separate clusters. You can configure processes that do not require user interaction to run on virtual machines that are separate from the virtual machines that provide user interaction. For example, scheduled cron task jobs and inbound messages from external systems (integration framework) can each run on separate JVMs. If the system load requires more resources, you can add JVMs to meet the increased need; hardware resource increase might be required as well. For example, if your integrated framework clustered environment routinely processes thousands of messages from external systems, you can add more JVMs to the cluster. The reliability of a system increases when the workload is distributed over multiple JVMs.
A typical deployment includes the following clusters:
- User interface cluster
- The user interface cluster is intended for users to access the system from a web browser.
- Integration framework cluster
- The integration framework cluster processes integration messages from message queues, and moves messages into the queues. This cluster uses Java Message Service (JMS), Hyper Text Transfer Protocol (HTTP) POST commands, web services, and Enterprise JavaBeans (EJB) technology.
- Cron task cluster
- The cron task cluster processes scheduled jobs. You can run scheduled jobs for integration tasks, escalations, Lightweight Directory Access Protocol (LDAP), or to run reports.
- Report cluster
- A dedicated reports cluster runs the Business Intelligence and Reporting Tools (BIRT) report engine. If you do not create a report cluster, then the BIRT report engine runs in each cluster, which can affect the performance of user interactive applications.
The process for creating a clustered environment involves the completion of tasks that are related to Maximo Asset Management and followed by the completion of tasks that are related to the application server, which is either WebSphere® Application Server or WebLogic Server. The following table outlines the process of creating clusters:
| Task | Purpose |
|---|---|
| Create a maximo.properties file for each cluster that you want to deploy. | You create separate properties files so that each cluster can have different settings. For example, you set properties to have all scheduled cron tasks run on the cron task cluster. |
| Create copies of the ejb-jar.xml file
for each cluster that you want to deploy. If your deployment includesWebSphere Application Server, you also need to create and edit copies of the ibm-ejb-jar-bnd.xmi file. If your deployment includes WebLogic Server, you also need to create and edit copies of the weblogic-ejb-jar.xml file. |
The ejb-jar.xml file and the ibm-ejb-jar-bnd.xmi file or the weblogic-ejb-jar.xml file are modified to configure message-driven beans for continuous queues. |
| Create copies of the buildmaximoear.cmd file for each cluster that you want to deploy. | The buildmaximoear.cmd files are used to create the individual EAR files for each cluster. |
| Build the EAR files. | The EAR files for each cluster are built based on the settings in the individual properties files, ejb-jar.xml files, and the ibm-ejb-jar-bnd.xmi or weblogic-ejb-jar.xml files. |
| Build the remote method invocation (RMI) registry file. | The rmireg.war file is used to create the RMI registry. |
| Deploy RMI. | RMI is deployed to the application server to create an independent RMI registry, which ensures that if a JVM fails, the RMI registry is still available. |
| Create the clusters. | The clusters are created by creating JVMs that are members of the cluster. |
| If you are setting up an environment with an integration framework cluster that is connected to an external system, configure the JMS. | JMS is used to communicate with external systems. |
| Deploy the EAR files for the clusters. | You deploy the EAR files on the application server so that each cluster supports its dedicated functions. |
The following diagram shows an example of a clustered configuration that is integrated with an external system. The user interface cluster consists of an application server that has a BIRT report engine, a product instance, and online help. The user interface cluster is accessed by a web browser, which sends the requests through a web server load balancer. The integration cluster and cron task cluster each consist of a separate application server that has a BIRT report engine and a product instance. All three clusters connect to a single instance of the product database. The external integration consists of the external system, an inbound queue, and an outbound queue. Both queues receive messages from the integration cluster and the user interface cluster and send messages to the cron task cluster.
