Considerations for Clustered Architecture Models
Outlined below are considerations for single-tier or
multi-tier clustered architecture models.
We begin with two options for installing WebFOCUS for use with
a clustered architecture model:
Separate WebFOCUS installation. Install WebFOCUS
separately on each cluster member and share certain files.
Shared WebFOCUS installation. Install WebFOCUS once and
directly onto the shared file system.
Separate WebFOCUS Installation
This is the recommended installation option and encompasses
the following guidelines.
- Install the WebFOCUS Client separately on each cluster member.
There are several options for installing the ReportCaster Distribution
- Install the Primary and Failover ReportCaster Distribution
Servers on each of the WebFOCUS Client machines. There can only
be one ReportCaster Primary and one ReportCaster Failover. If there
are more than two WebFOCUS Clients in the cluster, then install
ReportCaster on all instances of the WebFOCUS Client, but disable
ReportCaster on all but two instances of the WebFOCUS Client. This
is the recommended option.
- Install the Primary and Failover ReportCaster Distribution Servers
on separate WebFOCUS Client machines. Additional maintenance and
administration of WebFOCUS configuration files will be required.
- In WebFOCUS 7.x releases, the recommendation used to be that
the ReportCaster Distribution Server be installed on the Reporting
Server machine. However, the new WebFOCUS 8 design is more suited
to having the ReportCaster Distribution Server installed with the
WebFOCUS Client. There may be rare cases that warrant the ReportCaster
Distribution Server being installed on the same machine as the WebFOCUS
Reporting Server, but that need would require further discussion.
WebFOCUS Reporting Server
- Install the WebFOCUS Reporting Server separately on each
- The WebFOCUS Reporting Server should not
be installed on the same machine as the back-end database servers
in order to avoid resource contention problems.
- The WebFOCUS Reporting Server should not be installed on the
same machine as the WebFOCUS Client, unless working with a single-tier
clustered architecture model.
Stand-Alone WebFOCUS Hyperstage
- Install WebFOCUS Hyperstage on a separate machine from other
WebFOCUS software. The WebFOCUS Reporting Servers in the cluster
would each have to be configured to communicate to the stand-alone
WebFOCUS Hyperstage Server.
WebFOCUS Workload Distribution Facility (CLM)
- Install each cluster member of the WebFOCUS Workload Distribution
Facility (CLM) on its own machine. If there are company constraints
that do not allow for a separate installation, then CLM can also
be installed on the same machine as the WebFOCUS Client. For example,
some customers prohibit non-J2EE applications on the same machines
that are officially designated for hosting J2EE applications.
- CLM should not be installed on the same machine as the WebFOCUS
Reporting Server, since its main function is to poll those servers
to check their status.
- CLM should not be embedded with WebFOCUS Reporting Servers.
Considerations of a Separate Installation
- Presentation and Reporting and Metadata Layers must be installed
multiple times on each cluster member.
- It is highly recommended that the same WebFOCUS Client installation
directory and ports for each cluster member machine be identical
to allow for the installation of EAR or WAR modules to a cluster
deployment manager and not to the individual cluster members. For
example, with WebSphere, the EAR or WAR modules are installed using the
WebSphere Application Server Network Deployment. The Network Deployment
will then upload the files to each of the cluster member machines.
So, the directory structure cannot be different on each machine,
or the WebFOCUS Client will not work.
- Service Packs and Hotfixes will have to be applied on each cluster
member machine. The advantages outweigh the manual application of
Service Packs and Hotfixes, as previously explained.
Shared WebFOCUS Installation
Similar to the separate installation option, there are
advantages and disadvantages to a shared installation.
- Single copy of the WebFOCUS Client product system files
is installed and maintained.
- WebFOCUS Client files are immediately accessible by all cluster
- Avoid the possible pitfalls of changing files manually on each
cluster member machine.
- Perform the WebFOCUS Client Service Pack, Hotfixes, and upgrade
- Configuration file changes are applied once.
- Eliminate the need to manually synchronize files or employ additional synchronization
- Network latency may impact application performance since
the application has to access files over the network. Sometimes
hardware resources span many sites across multiple data centers
that are physically located in different states or countries.
- Lack of redundancy or fault-tolerance measures in place can
make the shared file system a single point of failure. For example,
on UNIX, one can share file systems across machines using Network
File Systems (NFS). First, the NFS file system will need to be mounted
across machines in Read/Write mode. Second, if for any reason that NFS
system becomes unavailable, the applications will become unavailable.
Unlike the separate WebFOCUS installation option, where moving a
small subset of shared files to the local file system can be done
to mitigate a shared file system failure, it is quite difficult
to move an entire WebFOCUS installation to another file system.
It will require a reinstallation.
- The shared file system has to be robust enough to handle the
volume of activity.
- Windows Program Folders and NT Registry entries. On Windows,
Program Folders are created only on the machine from which the installation
was done. On the other cluster members, there is no way to determine
that WebFOCUS was installed, since neither NT Registry entries or
Program Folders are created.
- Managing Logs
- On all platforms, installation logs are
created only on the machine from which the installation was done.
There will not be an installation log to indicate that software
was installed on any other machine.
- Application logs will be created by each cluster member in a
single directory, making it difficult to detect the origin of the
WebFOCUS Client generating the logs. This adds an unnecessary level
of difficulty to troubleshooting issues. It is better to keep the
log files separately on each cluster member.
- The WebFOCUS Client generates temporary files for certain types
of requests per user session. All temporary files will be created
by each cluster member in a single directory, making it difficult
to detect the origin of the WebFOCUS Client generating the temporary
files. Furthermore, in a clustered architecture model, session affinity
is enabled on the load balancer so a user request will always be processed
by the same Java Application Server instance.
In a clustered architecture model, members must have
the same view of configuration and application content at all times.
The most common way to do this is to place the files on a shared
device. The other way is to keep the files on the local file system
of each cluster member, but synchronize them through some external
Let us take a look at:
- Files that can be shared between cluster members.
- Sharing mechanisms for shared files.
- Keeping shared files
on a shared device.
- Keeping separate copies of files on the local file system.
Files that can be shared between cluster members
Files that can be shared between cluster
members are of the following two types:
- WebFOCUS application content files
- WebFOCUS configuration files
Reporting Server/Application Content
- Specifies the location of application directories.
- The default value (ibi/apps) can be changed from the Web Console/Workspace/Configuration
Files/edaserve.cfg to a shared file system.
- Specifies the location of private user content.
- The default value (ibi/homeapps) can be changed from the Web Console/Workspace/Configuration
Files/edaserve.cfg to a shared file system.
- Specifies the location of user and group
profiles and Access Control rules.
- The default value (ibi/profiles) can be changed from the Web Console/Workspace/Configuration
Files/edaserve.cfg to a shared file system.
- Run edastart -reload to apply changes to admin.cfg to all Reporting
Servers in the cluster.
- Hard-coded to look in EDACONF/etc (EDACONF/etc/edasprof.prf),
where EDACONF is the WebFOCUS Reporting Server configuration directory.
- Global profile for the Reporting Server. It is executed for
- It is not advisable to share the etc directory, only the edasprof.prf
using a symbolic link.
- On a cautionary note, new adapter configurations (not new connections)
would need a manual change to edaserve.cfg. If the new adapter is
being added to a cluster member, then a manual change would need
to be made to the remaining cluster members, requiring a recycle.
WebFOCUS Client/Application Content
- IBI_Export_Directory (../cm/export)
- Change Management
(CM) export packages are created in this location.
- The default value (../cm/export) can be changed from WebFOCUS Administration
- Change Management (CM) import
packages are read from this location.
- The default value (../cm/import) can be changed from WebFOCUS Administration
- Specifies directory
where Domain Templates are stored.
- The default value (../config/resource_templates) can be changed
from WebFOCUS Administration Console/Configuration/Application Directories.
- Specifies ReportCaster configuration
- Stored in the WebFOCUS Client repository so it is shared automatically between
all cluster members.
Sharing Mechanisms for Shared Files
There are two mechanisms for providing cluster members with the
same view of application content and configuration files.
- Keeping Files on a High Availability Shared File System
most common mechanism for sharing WebFOCUS files is with the use
of a high availability file system that can be accessed by all cluster
members for reading and writing.
- Keeping Files on a Local File System
When maintaining WebFOCUS
files on the local file system of each WebFOCUS installation, files
need to be synchronized so all cluster members have the same view.
WebFOCUS 8 requires two database repositories:
- For storing user content, security authorization information,
and scheduling and distribution information created by the Presentation
Layer, which is comprised of the WebFOCUS Client and ReportCaster.
- For storing collected statistics generated by Resource Analyzer
WebFOCUS 8 Client
- The WebFOCUS 8 Repository is required to have a case-sensitive
- In a clustered architecture model, the WebFOCUS 8 Repository
must be shared between all cluster members to allow users the same
view. Each cluster member must be configured identically to communicate
to the same repository.
- To support high availability, the WebFOCUS Repository must also
support high availability.
- In a clustered architecture model, this repository must
be shared between all WebFOCUS Reporting Server members for centralized
storage of collected statistics. If the repository is not shared,
then it becomes an administrative task to merge the data from each
Resource Analyzer database repository. Each Reporting Server cluster member
must be configured identically to communicate to the same Resource
Analyzer database repository.
- To support high availability, the Resource Analyzer Repository
must also support high availability.
Note: Some customers will need to keep both WebFOCUS 8
Repositories in a common database schema to conform to company policy.
This does not create any conflict between the two repositories because
they are logically separated and have different table names.