In this section:
High availability, failover, and load management can be implemented at several components:
There are two main types of schemes to support high availability, failover, and load management schemes:
In the following sections we will take a look at how these schemes can be implemented with WebFOCUS for the components listed earlier.
The following images illustrate how hardware can be configured to support the commonly used Active-Active load management schemes to support the clustered architecture models covered in Designing the WebFOCUS 8 Architecture.
We make reference to the Presentation Layer, which is comprised of the WebFOCUS Client and ReportCaster, and the Reporting and Metadata Layer, which is comprised of the Reporting Server.
This section is not intended to cover high availability and failover at the WebFOCUS Application Level. Later on we will cover how WebFOCUS Workload Distribution Facility (CLM) can be used to provide high availability and failover at the WebFOCUS Application Level.
Note: Third-party resources that are required to support the clustered architecture models must also support high-availability.
In the following Active-Active Single-Tier Clustered Architecture Model image:
In the following Active-Active Multi-Tier Clustered Architecture Model image:
Maintaining Performance When Cluster Members Become Unavailable
There must be adequate resources to support desired load in the event one or more cluster members become unavailable. Companies must establish policy as to what constitutes acceptable degradation.
For example, if you have a cluster of two Reporting Servers running at 75% capacity, and one goes offline, the workload of the remaining Reporting Server will be increased potentially resulting in performance degradation. To maintain the same performance of the system as when running at full capacity, consider increasing the capacity of the remaining Reporting Server or adding a third Reporting Server node.
Considerations for Web Servers and Java Application Servers
Web server farms can be fronted by load balancers to support load management and failover schemes, as shown in the following image.
In the Failover/Load Management image, a load balancer routes user requests to the web servers in the web server farm using a defined dispatch algorithm. Each web server in the Web Server Farm is installed with a web server plug-in to communicate to the application servers in the Application Server Farm that are hosting WebFOCUS. The web server plug-in has a default dispatch algorithm.
There are special considerations for web servers and application servers, which are described below.
Fronting the Application Server With a Web Server
Often, we are asked, "Do we need a web server and an application server?" While WebFOCUS will work with both a web server and application server, or only an application server that has a built-in HTTP server, it is best to design an architecture using web servers working in tandem with application servers for WebFOCUS usage.
A web server primarily serves up static and dynamic pages from HTTP requests. It does not support transactions, database connection pooling, servlet, or JavaServer™ Pages (JSP) files, and will typically pass such requests to a server-side program that can handle it, such as a servlet container. WebFOCUS consists of web applications that are comprised of related files, including HTML files, JavaServer Pages files, and servlets.
Some of the advantages in fronting a application server with a web server are outlined below:
In this section:
Customers can leverage the built-in failover and load management capabilities of WebFOCUS to minimize application downtime and distribute workload to maintain optimal performance. These capabilities are implemented for the following WebFOCUS components.
Let us first take a look at how these components are designed to work and how they can be best used to satisfy failover and workload distribution requirements using supported load-management schemes.
The Workload Distribution Facility (CLM) is an independent server component that manages one or more clusters of WebFOCUS Reporting Servers. You can have one CLM or a cluster of CLMs running at the same time in Active-Active mode. To leverage CLM, you need to configure the Presentation Layer to communicate to one or a cluster of CLMs. It is recommended to use a cluster of CLMs for high availability and failover.
The main functions of the CLM are to:
When a user submits a request to the Presentation Layer, the high-level workflow for processing that request is outlined, as shown in the following image.
When ReportCaster is configured for Workload Distribution, the Workload Manager is activated on the ReportCaster Distribution Server. The Workload Manager distributes scheduled jobs to a cluster of Workers for processing. This provides a scalable way to process a larger number of scheduled jobs. CLM and ReportCaster Workload Distribution can be configured to work in tandem to manage the workload.
Note: ReportCaster supports Active-Passive failover for the ReportCaster Distribution Servers. There can only be a single Primary ReportCaster Distribution Server in a WebFOCUS instance. If the Primary ReportCaster Distribution Server becomes unavailable, then the roles are switched and the Failover ReportCaster Distribution Server is automatically brought online and becomes the Primary ReportCaster Distribution Server. ReportCaster supports Active-Active failover and load management for the Workload Distribution Workers.
The following is the recommended order for configuring WebFOCUS to support high availability, failover, and load management.
Workload Distribution Facility (CLM)
As of WebFOCUS Release 8.1 Version 03, ReportCaster leverages the WebFOCUS Client communications file, odin.cfg. You no longer have to create Data Servers in the ReportCaster configuration GUI. Instead, when you click New from the ReportCaster configuration GUI, the list of Client, CLM Processing, and Cluster nodes defined on the WebFOCUS Client will display. You can then choose the appropriate nodes that are required for ReportCaster scheduling.
The recommendation is to select all listed nodes because at the time when the schedule is being created, a check is not done to ensure that the assigned server for the resource being scheduled is available to ReportCaster. If the assigned server is not available to the Primary ReportCaster Distribution Server, the scheduled job will fail when it is executed. This capability is being evaluated for a future release.