x

This is the recommended installation option and encompasses the following guidelines.

WebFOCUS Client

• Install the WebFOCUS Client separately on each cluster member.

ReportCaster

There are several options for installing the ReportCaster Distribution Server.

• 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 cluster member.
  • 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.

x

Similar to the separate installation option, there are advantages and disadvantages to a shared installation.

Advantages

• Single copy of the WebFOCUS Client product system files is installed and maintained.
• WebFOCUS Client files are immediately accessible by all cluster members.
• Avoid the possible pitfalls of changing files manually on each cluster member machine.
• Perform the WebFOCUS Client Service Pack, Hotfixes, and upgrade installation once.
• Configuration file changes are applied once.
• Eliminate the need to manually synchronize files or employ additional synchronization software.

Disadvantages

• 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.

x

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 process.

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

• approot
  • 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.
• edaprfu
  • 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.

Reporting Server/Configuration

• edaprfu
  • 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 every user.
  • 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_Approot_Directory
  • Specifies the location of images and static files used by the WebFOCUS Client, web tier, and App Studio.
  • The default value (ibi/apps) can be changed from WebFOCUS Administration Console/Configuration/Application Directories.
  • Note: The IBI_Approot_Directory parameter is different from the approot parameter on the Reporting Server.

    As a best practice and for security reasons, the value of the IBI_Approot_Directory and the approot parameters must be different.

• 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 Console/Configuration/Application Directories.

• IBI_Import_Directory
  • Change Management (CM) import packages are read from this location.
  • The default value (../cm/import) can be changed from WebFOCUS Administration Console/Configuration/Application Directories.

• IBI_Resource_Templates_Directory
  • Specifies directory where Domain Templates are stored.
  • The default value (../config/resource_templates) can be changed from WebFOCUS Administration Console/Configuration/Application Directories.

ReportCaster Configuration

• dserver.xml
  • Specifies ReportCaster configuration information.
  • 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

  The 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.

x

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 monitoring.

WebFOCUS 8 Client

• The WebFOCUS 8 Repository is required to have a case-sensitive collation sequence.
• 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.

Resource Analyzer

• 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.