How can I have multiple IBM TRIRIGA application servers (user sessions) working on a Load Balancing and a High Availability implementation?

Answer

High availability (HA) is a characteristic of a system, which aims to ensure an agreed level of operational performance for a higher than normal period, it refers to a system that is continuously operational for a desirably long length of time. This is as well related to Scalability - the capability of a system to handle a growing amount of work, or its potential to be enlarged in order to accommodate that growth. This is because it may be key factor for business to get prepared for required (planned or unexpected) business growth and additional workload.

About IBM TRIRIGA application servers(users sessions), consider the following firstly in terms enhancing and tuning system resources usage:

(a) Make sure you are running with compatible versions for all components, as properly documented on :

i. For the most recent IBM TRIRIGA Platform version - Complete IBM TRIRIGA Support and Compatibility Matrix

ii. For the old IBM TRIRIGA Platform versions - Archive of IBM TRIRIGA Support Matrices - (click on the Attachments tab and open the respective version PDF file).

(b) Make sure you are running your servers following our IBM TRIRIGA Best Practices guide for System Performance recommendations. This is available on this IBM Wiki page: IBM TRIRIGA Best Practices for System Performance

So based on IBM TRIRIGA Best Practices, a JVM/server should have around 4 GB heap size memory. For determining the number of possible servers/JVMs you can host on a single box (physical server), you need to check, assess and review:

1. The available RAM memory on system;

2. The required RAM memory your Operating System needs for running fine;

3. The amount of disk space you have available for hosting more JVMs/servers. This needs to take into consideration:

3a. The WAR/EAR file size;
3b. The Operating System (OS), Application Server (WebSphere, WebLogic, JBoss) WAR/EAR TEMP cache area, log files, temporary files created for regular operation of system (report viewers, temp documents, etc);

4. The CPU power of processing multiple threads & operations;

5. The network channels speed and throughput;

6. The JVM heap size memory. See that Application Server & Operating System will require some additional RAM memory for caching temporary process information when working with the JVM. For instance, as just an example, you may have a 4 GB RAM JVM but this will require additional 0.5 RAM memory for the internal & temporary processes in Windows when working with WebSphere Application Server;

7. The business needs and resource restrictions that will validate the need of having additional JVMs on a physical server.

It is hard to say how many JVMs/Servers a physical server (box) can host, this is a sizing question IBM TRIRIGA support cannot assist. But see some more information on that provided by our IBM TRIRIGA development team on the following IBM Wiki page: System Sizing


You cannot simply calculate the amount of JVMs based on the available RAM memory (1), the OS required memory (2) and the JVM heap size (6). There will be other factors needing to be considered on such sizing matter. This is out of IBM TRIRIGA support scope to recommend or suggest on sizing decisions.

Once you are done with your sizing decisions, you are ready for preparing multiple installs of IBM TRIRIGA Platform on this physical server.

See that there is no difference among a IBM TRIRIGA application, a IBM TRIRIGA process server and a IBM TRIRIGA toll/reporting server. It is same code running for all, it is a logical approach & decision that will determine what it will be running on each one of these servers at end:

i. application servers host user session, users will be connecting to them. So you prevent agents from running here;
ii. process servers will be running the agents, including the integration ones. So you prevent users from connecting here;
iii. BIRT servers will be running the BIRT reports and send the output file to be viewed by the originator user session. So you prevent agents from running here and users from connecting here;

See that for each IBM TRIRIGA server you install, you may log in to it using specific URL address:

http://<Server Name>:<Port>/<Context>/index.html
https://<Server Name>:<Port>/<Context>/index.html

If you have multiple IBM TRIRIGA application servers running on the same physical box, if you don't have a way to load balance the HTTP requests fairly among them, you will need to have separate groups of users connecting to different login URL pages.

The way to prevent this from happening is to install a Web Server, that will handle the HTTP requests distribution and affinity among the JVMs/Servers in a way it makes possible the Internet Browser session path to be correctly found and used.

IBM TRIRIGA support cannot assist on installing and configuring a Web Server product, you need to open a support ticket for the respective vendor and product support team for getting such assistance.

IBM WebSphere Application Server (and Liberty) can interface and use IBM HTTP Server (IHS) Web Server product. It can then have a single pool URL address that all your end-users will access for connecting to IBM TRIRIGA product. On the background, IHS will distribute the HTTP requests and keep the affinity information, using a round-robin distribution approach.

This is called Vertical Cluster, meaning Web Server & Application Server have multiple servers/JVMs under the same physical server (box). If a server goes down, the next HTTP request goes to the next available one. But if the physical server goes down, system stops responding.

If a JVM/server goes down, users using it will be disconnected and if they log in back, IHS will manage the HTTP request to go to another up and running JVM/Server instead. This is a HA approach, but it requires users to log in back, since IBM TRIRIGA code does not support Session failover.

It is upon customer to install and configure Web Server, and make available to users the URL login page that will point to the servers in the Web Server pool for round robin distribution (or any other configured distribution methodology).

IBM TRIRIGA Development team has made available the following IBM Wiki page for a sample (provided as-is with no warranty or support) on how to implement HA availability on this sense: High Availability with Liberty


Customers can even go further into HA approach, and have a pool of Web Servers connected to a Load Balancer product. Case any Web Server goes down, next one is used for handling the HTTP request.

For the image above, High Availability environments / solutions will force all users through a single domain address which goes through a Load Balancer and that Load Balancer sprays a cluster of IHS servers connected to multiple Servers (JVMs).

The above implements what we call Horizontal Cluster, meaning you will have Web Servers (IHS, for instance) & Application Servers (WebSphere, for instance) instances running on separate physical servers (boxes), and the there is a HTTP request distribution performed by the Load Balancer agent into the Web Servers, that will do the same for the servers/JVMs they have under them. This implementation has better HA since if a entire box (physical server) goes down, the next one will take the workload and respond to the new HTTP requests.

For any scenario above, make sure the TRIRIGAWEB.properties FRONT_END_SERVER value is updated with the URL users typically connect to system (even it is the one coming from Web Server pool URL address). See more information here: Unable to navigate between tabs on IBM TRIRIGA Portfolio Data Manager (Application) and BIRT reports are not displaying any graph

But see, IBM TRIRIGA support cannot assist on such 3rd party HA solution implementation, that will comprehend installation and configuration of Web Servers, Application Servers and Load Balancer products.