Typical BBj Load Balanced and HA Cluster Deployment

Tier 1:  Presentation Layer

Tier 1 is the ‘Presentation Layer’ where the deployment interfaces with the end users.  This layer can be comprised of:

• Terminal Emulators – Used to log into UNIX server to run a CUI BBj® application
• Standard Thin Clients – Only the BBj Thin Client runs on the client machine where it arrives dynamically via .jnlp link and Web Start or is manually installed on the client system, but either way, has remote access to the application interpreter server
• Java Web Start Thin Clients – The Java Web Start client is configured on the application server; all of the files needed to run the Thin Client are sent automatically to the client via a URL. (As of this writing, this is the most popular method of BBj Thin Client deployment)
• Browser User Interface (BUI) Clients – The BBj application runs 100% within a browser, no files are installed on the client. The BUI application is configured to run on the application server and is served via BBj’s Jetty Web Server.

Tier 2:  Application Layer 

Tier 2 is the ‘Application Layer’, where the BBj interpreter sessions run.  BASIS recommends distributing the application workload across two or more load-balanced application servers, typically using one of the following four methods (from the Redhat website):

• Round robin – Distribute jobs equally among the real servers.
• Least-connections – Distribute more jobs to real servers with fewer active connections. 
• Weighted round robin – Distribute more jobs to servers with greater capacity. Capacity is indicated by the user-assigned weight, which is adjusted upward or downward by dynamic load information.
• Weighted least-connections – Distribute more jobs to servers with fewer active connections relative to their capacity. Capacity is indicated by the user-assigned weight, which is adjusted upward or downward by dynamic load information. 

BASIS recommends load balancing the following ports/services:

• BBj Thin Client, port 2003
• BBj Secure Thin Client, port 2103
• SSH/Telnet (for terminal emulators)
• HTTP, ports 8888 and 8443 (for BBj’s embedded Jetty Web Server)

Tier 3:  Data Layer

Tier 3 is the ‘Data Layer’; in BBj deployments, this layer is referred to as the Database Management Server(DBMS).
BASIS recommends a High-Availability (HA) Cluster of two or more identical servers, or ‘nodes’; one Primary or ‘live’ server and Secondary, Tertiary server(s) that can take over for the Primary in the event of a hardware failure.
HA clusters use a heartbeat to monitor the health and status of each cluster node.
Data integrity is ensured by either:

• Commonly-mounted file system – Mounting a common redundant file system – only one server node may have the file system mounted at any given time 
• Distributed Replicated Block Device (DRDB), or a similar service.  DRDB does block-level replication between HA cluster nodes.

BASIS also recommends storing all production-related configuration (application server config.bbx, BBj.properties, etc) and program files at this layer. For example, all application servers may mount an NFS share that is created on the DBMS server. The share might be included in the commonly-mounted file system or a directory replicated via DRDB to the secondary and tertiary HA nodes. The load balancer can either be a separate piece of hardware or it can be on the machine that houses the database. 

Upgrade Deployment Recommendations

If customers have traditionally run on single-tier PRO/5® deployments, it is recommended that you roll out your 3-tier deployments in a controlled and measured way to reduce unexpected shocks to the users that could occur if you do not have systems in place to thoroughly test full system loads on 3-tier load balanced application servers and HA Clustered databases. Following these steps will enable you to experience the new architecture with products that you are already familiar with (PRO/5) before adding new technology (BBj) to the mix. These steps keep the incremental variables to a minimum, reducing the risk and simplifying the debug process.

Step One
Start deployment with your PRO/5 applications running on the HA Cluster.

Step Two
Configure all of the applications to use data server syntax while running on the HA Cluster. This allows all of the users and batch jobs the chance to experience the latency introduced by inserting a layer between the interpreters and the database. If the latency is excessive for some batch jobs, this is the opportunity to run your batch jobs with settrace enabled, evaluate the results in Performance Analyzer, and modify the code to achieve the requisite batch job performance.

Step Three
Configure your load-balanced application servers to launch the PRO/5 applications, pulling the applications from the HA Cluster as well as accessing the data from the PRO/5 Data Server® on the HA Cluster. This allows all of the users and batch jobs to experience the latency introduced by inserting networking layer between the interpreters and the database running on separate machines. If the latency introduced by this step is excessive for some of the batch jobs, this is another opportunity to run your batch jobs with settrace turned on and evaluate the results in Performance Analyzer.   

Step Four
Change the data server syntax port number that PRO/5 applications use to access programs and data via the PRO/5 Data Server® (default is 1100) to access the BBj Filesystem Server instead (default is 2000). This step enables you to take advantage of key BBj features,such as:  Data replication, triggers, SPROCs, and a broad array of new file types that support more keys than the traditional MKEYED files.

At this point, you have all of the power and protection of a three-tiered architecture and the associated redundancy and robustness that give companies the 99.99% uptime, so important in organizations today.

Step Five
Change the load-balanced application servers to launch programs with BBj Services instead of PRO/5, while continuing to access files via data server syntax to BBjServices on the HA cluster. This allows you to begin using the new features that are only available to applications that use BBj Services interpreters, such as GUI, BUI, and object-oriented syntax.

Note: There is no maximum amount of time that you can run on each of the steps before moving on to the next step, but it does make sense to run each step for at least one month, so that the organization gets a chance to experience daily, weekly, and monthly batch jobs in each of the architectures, before moving on to the next step. Of course, the larger the organization the more important it is to take these steps in a slow and methodical way to make sure that all possibilities are thoroughly tested before moving to the next phase of the topology change.