Information Console load balancing
Information Console supports two kinds of load balancing to ensure high availability and task distribution for efficient processing, as shown in Figure 1‑2.
Figure 1‑2 Load-balancing architecture for Information Console
*Actuate Message Distribution service (MDS) balances the request load among BIRT iHub machines in an BIRT iHub cluster.
The Message Distribution service eliminates the need for a third-party network load balancer in front of the BIRT iHub tier. iHub determines which machines in a cluster have MDS running and detects when the MDS machines go offline. MDS distributes the load among the available servers and does not attempt to send a request to an offline machine.
*Clustered Information Console machines can use a third-party application to balance the load among the application servers.
Deploying a load balancer for an BIRT iHub cluster
To deploy a load balancer or proxy layer in front of the BIRT iHub tier, disable the Actuate load-balancing support by setting the MDS_ENABLED configuration parameter to False in the web.xml Information Console configuration file. For EAR and WAR installations, set this value before deployment. When installing as a Windows service, you can make the configuration change after installing.
Using a cluster of application servers
If the application servers running Information Console support session state management, you can configure Information Console and the application servers to share and maintain a web browsing session state across a cluster of Information Console instances. Configuring the application servers to track the state of each Information Console instance supports reusing authentication information. In other words, you can log in to an Information Console instance and send a request using another Information Console instance without logging in again using the second instance.
Sharing session state information takes advantage of the application servers’ failover features. If a user is on a cluster application server running Information Console and that application server fails, another application server running Information Console can manage the user’s session.
If you do not use an application server to track session state information, managing the session state is fast, but you lose a user’s state information when you restart Information Console or your application server.
An application server works with one or more database servers to manage session state information. All application servers must have access to the database server to store and retrieve session state information. For specific information about configuring your installation, see your application server documentation.