Cognos 8 & WebSphere Clusteringpublic.dhe.ibm.com/.../application...clustering.pdf · Proven...

Proven Practice

Application Servers - IBM Cognos 8 & WebSphere Clustering

Product(s): IBM Cognos 8.4, IBM WebSphere

Area of Interest: Infrastructure

DOC ID: AS03 Version 8.4.0.0

Application Servers – IBM Cognos 8 & WebSphere Clustering

Copyright and Trademarks

Licensed Materials - Property of IBM. © Copyright IBM Corp. 2009 IBM, the IBM logo, and Cognos are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml

While every attempt has been made to ensure that the information in this document is accurate and complete, some typographical errors or technical inaccuracies may exist. IBM does not accept responsibility for any kind of loss resulting from the use of information contained in this document. The information contained in this document is subject to change without notice. This document is maintained by the Best Practices, Product and Technology team. You can send comments, suggestions, and additions to [email protected].

Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

http://www.ibm.com/legal/copytrade.shtml

mailto:[email protected]

Application Servers – IBM Cognos 8 & WebSphere Clustering

TABLE OF CONTENT 1 Introduction ...........................................................................................................................................1

1.1 Purpose..............................................................................................................................................1 1.2 Scope.................................................................................................................................................1 1.3 Definitions, Acronyms, and Abbreviations.......................................................................................1 1.4 References.........................................................................................................................................1 1.5 Assumptions......................................................................................................................................1

2 WAS Clustering.....................................................................................................................................2 2.1 Overview...........................................................................................................................................2 2.2 Software Requirements .....................................................................................................................2 2.3 Clusters .............................................................................................................................................3 2.4 Cluster Types: Vertical & Horizontal ...............................................................................................4 2.5 Workload Management.....................................................................................................................6 2.6 Static Web Content Files...................................................................................................................6 2.7 Failover .............................................................................................................................................8

3 Clustering and the IBM Cognos Application......................................................................................8 3.1 General..............................................................................................................................................8 3.2 Clustering without WLM..................................................................................................................9 3.3 Clustering with WLM .......................................................................................................................9 3.4 IBM Cognos Component Types......................................................................................................10 3.5 IBM Cognos Content Manager .......................................................................................................11 3.6 IBM Cognos Report Server / Application Tier Components ..........................................................12 3.7 IBM Cognos Servlet Gateway ........................................................................................................13 3.8 Drawbacks.......................................................................................................................................13

4 Scenarios ..............................................................................................................................................14 4.1 Vertical Clustering by Component Type ........................................................................................14 4.2 Horizontal Clustering by Component Type ....................................................................................16 4.3 Web Server Farming .......................................................................................................................18 4.4 Clustering for Scalability ................................................................................................................20 4.5 IBM Cognos Servlet Gateway Clustering.......................................................................................22

5 Clustering & IBM Cognos Setup .......................................................................................................24 5.1 Install and Configure the Software .................................................................................................24

5.1.1 IBM WebSphere....................................................................................................................24 5.1.2 IBM Cognos Applicaiton ......................................................................................................25 5.1.3 Web Server ............................................................................................................................26

5.2 IBM Cognos Setup Steps ................................................................................................................27 5.2.1 Install Order...........................................................................................................................27 5.2.2 General Setup ........................................................................................................................28 5.2.3 IBM Cognos Configuration ...................................................................................................28 5.2.4 IBM WebSphere....................................................................................................................28

5.3 Additional Notes .............................................................................................................................31 6 IBM Web Site Information.................................................................................................................32

6.1 WebSphere Web server plug-in connections ..................................................................................32

Cognos 8 & WebSphere Clustering 1

1 Introduction

1.1 Purpose

Provide an understanding of how IBM WebSphere clustering works and provide a list of advantages and disadvantages as it relates to IBM Cognos ReportNet and IBM Cognos 8.

1.2 Scope

IBM WebSphere clustering only. Other Application Servers are not covered by this document although the same principles and concepts may apply.

WebSphere clustering with failover assumes the inclusion of plugin support and therefore also entails communicating directly to the IBM Cognos ReportNet / IBM Cognos 8 dispatcher.

This document is not intended to be an architectural design paper. The clustering concept will be used and IBM Cognos ReportNet / IBM Cognos 8 will be discussed at a component level (Content Manager, Application Tier and Servlet Gateway). Individual services may be further replicated or distributed in a client environment. Similarly, sizing and performance will not be discussed in this paper but may be indirectly referenced.

1.3 Definitions, Acronyms, and Abbreviations

Term Definition WAS IBM WebSphere Application Server IHS IBM HTTP Server (Apache) WLM IBM WebSphere Work Load Management

1.4 References Ref. ID Author/Paper Location WebSphere Multi-Server Setup Configuring WebSphere for ReportNet

1.5 Assumptions

That the consumer of this document has prior knowledge of IBM WebSphere, IBM WebSphere Network Deployment, IBM HTTP Server, IBM WebSphere Plugins.


2 WAS Clustering

2.1 Overview

Clustering provides the client with the ability to group together server instances either on the same physical system, different physical systems, or a combination of both. The cluster can be managed (started, stopped, etc) as a single entity reducing the overhead of an administrator and making the environment easier to manage.

Deployment of an application into a cluster automatically deploys (the java components only) across the cluster and onto the physical systems, also reducing the administrative work required to install IBM Cognos ReportNet / IBM Cognos 8.

Coupled with other technologies such as Work Load Management (WLM) and Plugins, robustness and failover can be added into the client environment.

Clustering is not mandatory. Most, but not all, of the functionality and capabilities discussed in this paper may be achieved simply through distributed installs and deployment into standalone server instances. However, deployment into a cluster can simplify, to some extent as identified later in this document, some of the steps and reduce some of the overhead associated with managing individual server instances.

Throughout this document the term “server instance” is used. This term references the Java process that will be instantiated by WebSphere and used for deployment of the IBM Cognos ReportNet / IBM Cognos 8 (java) application. Each server instance equates to a JVM process that can have its properties set on an individual basis. Since clustering implies multiple server instances, and IBM Cognos ReportNet / IBM Cognos 8 must have a one-to-one installation per server instance, it is critical that each server instance, whether part of a cluster or not, be configurable independently.

2.2 Software Requirements

The technologies discussed in this paper are available to clients that have all the following software packages available to them:

• IBM WebSphere Application Server v5.1 or higher

• IBM WebSphere Application Server Network Deployment v5.1 or higher or;

• IBM WebSphere Application Server Enterprise Edition v5.1 or higher

• IBM WebSphere Application Server web server plug-in

• A web server supported by IBM WebSphere Application Server and IBM Cognos ReportNet / IBM Cognos 8

• IBM Cognos ReportNet / IBM Cognos 8

Note that the Network Deployment version of IBM WebSphere may require the client to obtain additional licensing from IBM. The IBM WebSphere Application Server Enterprise Edition should also provide the functionality required for clustering support since it is a superset package to the Network Deployment version. All the IBM software should be acquired from IBM or an authorized dealer.

Both the IBM WebSphere Application Server and the IBM WebSphere Application Server Network Deployment (or Enterprise Edition) are required to be installed and operational. These are two separate packages that must be installed into two different locations.

From a software setup point of view, it should be noted that in order to get to a supported base platform, or a current release of WebSphere, it may be necessary to perform multiple software installs and updates.


For example, to install an up-to-date WebSphere platform, the following packages are necessary:

• IBM WebSphere Application Server v5.1.0.0

• IBM WebSphere Application Server v5.1.1.0 Fix Pack

• IBM WebSphere Application Server v5.1.1.2 Cumulative Fix

• IBM WebSphere Application Server Network Deployment v5.1.0.0

• IBM WebSphere Application Server Network Deployment v5.1.1.0 Fix Pack

• IBM WebSphere Application Server Network Deployment v5.1.1.2 Cumulative Fix

• IBM WebSphere v5.1 JRE Updates

• IBM WebSphere v5.1 Plug-in Updates

Note: WebSphere 5.1.x is used in this example, but clustering applies to any supported release of IBM WebSphere.

2.3 Clusters

The IBM website states:

“Clusters are sets of servers that are managed together and participate in workload management. The servers that are members of a cluster can be on different host machines, as opposed to the servers that are part of the same node and must be located on the same host machine. A cell can have no clusters, one cluster, or multiple clusters.”

“Servers that belong to a cluster are members of that cluster set and must all have identical application components deployed on them. Other than the applications configured to run on them, cluster members do not have to share any other configuration data. One cluster member might be running on a huge multi-processor enterprise server system, while another member of that same cluster might be running on a smaller system. The server configuration settings for each of these two cluster members are very different, except in the area of application components assigned to them. In that area of configuration, they are identical. This allows client work to be distributed across all the members of a cluster instead of all workload being handled by a single application server.”

The Network Deployment version or the Enterprise Edition of WebSphere is required to implement clustering.

Note: “Clusters” in this document refer to static clusters only. New versions of WebSphere are introducing static clusters which are not supported at this time.


2.4 Cluster Types: Vertical & Horizontal

A vertical cluster has cluster members on the same node, or physical machine as represented by the image below.

A horizontal cluster has cluster members on multiple nodes across many (2+) physical systems.

Either type of cluster can be configured. A cluster can also be configured as a combination of vertical and horizontal clusters.


The type of cluster is entirely dependant upon the members that are added to the cluster. It is not “defined” or set in any way when a cluster is setup or configured, it is simply a referential term used to describe the cluster. I.e. you do not create a “Vertical Cluster” any differently from a “Horizontal Cluster” other than the selection of the members to be included.

From a work load point of view, whether or not a cluster is vertical or horizontal is irrelevant. The work is handled by whichever cluster member is available.

From a failover point of view, a horizontal cluster can be used to completely take over should a single member of the cluster fail for any reason.

Additional, non-clustered server instance may of course also be present in the WebSphere environment.

Similarly, multiple clusters may be configured within a single WebSphere instance should that be desired.

The architectural design of the IBM WebSphere environment should be given careful consideration and planned for scalability, redundancy, failover, capacity and growth based on the client requirements. This document will help to clarify how a WebSphere cluster may be part of that solution.


2.5 Workload Management

Inbound client requests from the web server can be distributed, according to the configurable capacities, across the members of a cluster. A WebSphere web server plug-in routes application requests amongst cluster members by server-weighting.

Important: It is critical to note that, specifically in the case of IBM Cognos ReportNet / IBM Cognos 8, the workload balancing only applies to the client requests. This will be more evident in the diagrams that follow. Only requests that pass through the web server plug-in are load balanced (if enabled in the configuration file).

If workload balancing or workload management is enabled and implemented at the WebSphere level, then the IBM Cognos dispatchers should be configured to “Cluster Compatible” mode so that the workload distribution is not being performed more than once as this is likely to degrade performance.

WebSphere workload balancing currently employs two techniques, a weighted round robin mechanism (default) and a random selection which should ultimately balance the requests evenly across all members given a large enough sampling.

The example above illustrates requests coming into the IBM HTTP Server on port 80. These requests are then load balanced to the WebSphere vertical cluster members based on the default round robin mechanism.

2.6 Static Web Content Files

Static web content (portal style sheets, javascripts, images, etc) can be provided as part of the Report Server / Application Tier or from the web server tier. The recommended and most efficient way to service these requests is to service static content requests at the web server layer so that the application server is left for java code processing only.


If static content is being serviced by the application server rather than the web server then no changes to the plug-in file are required. No additional web server alias definitions are required. Simply include the webcontent in the application archive file when it is built (Report Server / Application Tier install and Gateway install are required).


If static content is to be serviced by the web server, which is recommended in most cases for performance reasons, then it is necessary to modify the plug-in configuration file or modify default WebSphere parameters and set appropriate web aliases in the web server to accomplish the desired results.

2.7 Failover

In addition to the failover support already built into IBM Cognos ReportNet / IBM Cognos 8, with clustering implemented using the WebSphere web server plug-in additional failover capabilities are now realized. The web server plug-in is application aware, due to a configuration file, and is also WebSphere server aware. If a single member of a cluster becomes unavailable, the plug-in will route all requests to the remaining members. If the failing member returns to live status, then requests will once again be routed to that member. As long as at least one cluster member is running, client requests can continue to be serviced.

A Backup Cluster feature allows the client to continue functioning when all cluster members of the primary cluster are not available but this applies (currently) only to EJB functions, which are not used by IBM Cognos ReportNet.

3 Clustering and the IBM Cognos Application

3.1 General

Running under Tomcat, IBM Cognos ReportNet / IBM Cognos 8 provides flexibility in design to allow for both failover and scalability. Multiple instances can be installed and configured to address either or both requirement.

When installed and run under an Application Server, the same end results can be achieved. Although possible, it is typically not desired to perform multiple Application Server installations on a single physical machine. This significantly increases the administrative overhead and potentially the license cost of a deployment.

The optimal scenario therefore allows for a single Application Server installation per physical system with multiple servers instances created within each WebSphere install. Within that architecture, it is therefore possible to define server and/or cluster instances into which the various IBM Cognos ReportNet components will be deployed. This provides for the highest level of flexibility, failover and scalability while keeping the administrative work at a minimum.

Note: setting the IBM Cognos application to “Cluster Compatible” mode turns off the load balancing mechanism within the IBM Cognos dispatcher but does not affect request affinity. These special cases are handled through rules in the dispatcher to ensure proper operation and maintain a high performance level.


3.2 Clustering without WLM

It is possible to install, configure and deploy IBM Cognos software into a cluster without implementing the WLM for failover and simply use a standard gateway.

In this case, the advantage is simply administrative. There is no built in failover (IBM CRN 1.x only – newer releases do include failover capabilities) at the web server and IBM Cognos Gateway tier since a Gateway is aware of a single IBM Cognos dispatcher. No load balancing at the web server tier is available unless multiple IBM Cognos gateways are configured to send requests to different dispatcher, but this requires load balancing of requests coming into the web server. In these scenarios the load balancing mechanism designed with IBM Cognos ReportNet must still be used to balance request loads at the Application Server tier. The primary install (System A in this example) will act as a load balancer and requests will get serviced by both installs, except for Content Manager requests which are serviced only by the active instance. There are architectural designs that do provide load balancing and failover for all versions of ReportNet at the web server level, but this entails installing a gateway and dispatcher on each web server.

Note that only one Content Manager instance may be active at a time. Any available instance may be selected as the active Content Manager, this example shows System A. Other services may also be configured independently for each instance. Any additional instances must be in standby mode.

3.3 Clustering with WLM

It is possible to install, configure and deploy the IBM Cognos application into a cluster implementing the WLM for failover. Ultimately, load distribution only applies to requests between the web server and the dispatcher. Internal requests to Content Manager for example do not pass through this load balancing mechanism.

As seen in the following diagram, a simple 2-member cluster can be setup with full IBM Cognos ReportNet / IBM Cognos 8 installs to provide failover and load balancing.


3.4 IBM Cognos Component Types

It is very important to understand the layout of the IBM Cognos application and how it is built in order to map it onto the WebSphere infrastructure.

Application Server clustering only applies to the Java components of the IBM Cognos application. These components are bundled into application archive files (.war or .ear) and are deployed into a WebSphere server or cluster.

IBM Cognos ReportNet / IBM Cognos 8 must therefore be installed on a one-to-one basis for each server instance within WebSphere so that the C++ code, the configuration files, and so on are available to the Java component.

If you deploy into a cluster with ‘x’ members, local or remote, then there must be ‘x’ matching IBM Cognos installs.

Each IBM Cognos install must also be properly configured to be unique, using the IBM Cognos Configuration tool.

You can see this Java <-> C++ relationship in the diagram above using IBM Cognos ReportNet report server as an example.


3.5 IBM Cognos Content Manager

The IBM Cognos Content Manager is designed as a single robust entity. Failover support is available using the Active / Standby concept.

Content Manager can be deployed into a WebSphere Cluster, but only one instance within that cluster can be active at any given time. The remaining instances must therefore be in standby mode. All requests will be routed to and handled by the active Content Manager instance only. This routing occurs internally within the IBM Cognos application and is not done by the WLM portion of WebSphere.

A standby Content Manager will become active through an election process should one other instance be shutdown either due to a failure or a manual override.

There are a number of advantages that can be gained by deploying Content Manager into a WebSphere cluster:

• Reduced administration. The cluster can be managed as an entity. For example, multiple server instances can be started or stopped as a group by starting or stopping a cluster rather than individual server instances.

• Easier installation. The Content Manager component can be deployed once into the cluster and the Java code will be deployed to all members of the cluster.

• Maintenance / Update. Selective members of the cluster can be shut off and the load will automatically shift to a standby Content Manager (which will become active) should an active one be disabled. This can be achieved by installing multiple independent server instances rather than a cluster.

The following items are NOT directly addressed by Content Manager clustering:

• C++ code distribution

• Content Manager configuration

• Load Balancing

• Failover (although clustering may play a role)

In the example above, all requests will be handled by System A and System B is available as a backup.


3.6 IBM Cognos Report Server / Application Tier Components

The IBM Cognos ReportNet Report Server application and IBM Cognos 8 Application Tier Components can also be deployed into a WebSphere cluster.

There are a number of advantages that can be gained by deploying this component into a cluster:


• Easier installation. The Report Server / ATC component can be deployed once into the cluster and the Java code will be deployed to all members of the cluster.

WebSphere WLM and the WAS plug-in may be optionally implemented to obtain further gains:

• Failover. Complete failover support can be achieved. The plug-in will only route requests to active members of the cluster. This is the most likely reason why a client would even consider running in a cluster.

• Load Balancing. An alternative load balancing mechanism can be employed, and the Cognos internal mechanism should be disabled in this case.

• Maintenance / Update. Selective members of the cluster can be shut off and the load will automatically shift to any remaining and active members.

The following items are NOT addressed by Report Server / Application Tier component clustering:


• Report Server / Application Tier Component configuration

Scalability must still be addressed via the manual addition and configuration of Report Server / ATC instances. The administrative work involved in this task will be reduced slightly since the Java components may be automatically deployed if the new server instance is a created as a cluster member.

In the example above, requests may be serviced by either instance depending on how the environment is configured.


3.7 IBM Cognos Servlet Gateway

The Servlet Gateway component of the IBM Cognos application may also be deployed to a clustered environment.

There are a number of advantages that can be gained by deploying this component into a WebSphere cluster:


• Easier installation. The Servlet Gateway component can be deployed once into the cluster and the Java code will be deployed to all members of the cluster.

• Maintenance / Update. Selective members of the cluster can be shut off and the load will automatically shift to any remaining and active members.

WebSphere WLM and the WAS plug-in may be optionally implemented to obtain further gains:

• Load Balancing. An alternative load balancing mechanism can be employed, and the IBM Cognos ReportNet internal mechanism should be disabled in this case.

• Failover. With the addition of other 3rd party components, such as WLM and the WAS plug-in, complete failover support can be achieved.

Fully implemented, with the web server plug-in in place for both the Servlet Gateway and the Report Server / ATC, there is additional overhead that may impact performance. Complete failover support will however be made available.

The following items are NOT addressed by Servlet Gateway clustering:


• Servlet Gateway configuration

3.8 Drawbacks

There are a few items worth noting that need to be considered when clustering is implemented.

IBM Cognos gateways encrypt passwords between the web server gateway and the remaining IBM Cognos components. If WLM is used, and therefore the WebSphere web server plug-in is used, the IBM Cognos gateways are not used and therefore password encryption is not taking place. The HTTPS protocol can be used to communicate from the web server to the application server tier to compensate, but this will require additional configuration. It would also be possible to setup and configure the IBM Cognos Servlet Gateway application to protect password information from being sent in the clear, but caution should be used and the WebSphere architecture carefully planned to ensure that additional overhead due to request routing is not introduce or at least kept to a minimum.

IBM Cognos gateways allow for a default namespace to be presented and used in a multi-namespace environment. This capability would be lost if WLM and clustering is used at the web server level.


4 Scenarios

The following scenarios are provided as examples of what can potentially be done in a client environment. They are not meant as representations of the only way to accomplish a particular environment, but should be used solely as illustrations that portray concepts. Portions should be extracted to build a proper environment for a client that matches their requirements. For instance, it may be more appropriate, given particular clients needs, to implement clustering only for the Report Server / ATC component and run Content Manager as a standalone application.

4.1 Vertical Clustering by Component Type

Conceptually it may help to start with a simple scenario. This scenario does not help with system failover, but does provide resiliency for software failure and also allows for scalability.

All the web server processes, plug-ins etc can be located on one system, IBM Cognos Application Tier (Report Server) can be run on the first WebSphere cluster on a second system and a third system can host another WebSphere cluster where the Content Manager services (Active and Standby) will be hosted.

The web server is shown separately only to clarify the modularity. It can co-exist with either or both WebSphere installs.

Also of note, the diagrams show that inbound requests that come into the web server are first parsed by the WebSphere web server plug-in and then the alias mappings are parsed. This, as noted elsewhere in this document, is the current default behaviour of the plug-in module. As a result, the subdirectories within <Cognos8>/webcontent must be mapped as individual alias mappings as a safeguard in case this behaviour is changed (and there have been a few implementations where the behaviour does seem to be reversed).

With the Application Tier Components and the Content Manager components running in different clusters you can see the separation and effect of the load balancing where only the initial requests coming from the web server are balanced to IBM Cognos ReportNet dispatchers.

The request flow in this case would be:

1. The browser initiates the request using the host and port of the web server and the context root of the IBM Cognos Dispatcher.

2. The web server parses the request using the plug-in module and passes the request to the application server. An application server is picked using the round robin mechanism and a new host and port value are inserted into the URI maintaining the context root and alias path values.

3. The application server accepts the request and parses the context root to determine which application to send the request to.

4. The application, IBM Cognos dispatcher in this case, accepts and processes the request.

5. Subsequent requests are made within the Cognos infrastructure to the BIBTKServerMain process, the Content Manager, etc. based on the user action.

In this example the following software components were installed:

• (5) IBM Cognos ReportNet / IBM Cognos 8

• (2) WebSphere Application Server v5.1.1.2

• (1) WebSphere Application Server Network Deployment v5.1.1.2

• (1) IBM HTTP Server v1.3.28



4.2 Horizontal Clustering by Component Type

This scenario demonstrates a simple redundant setup where IBM Cognos Application Tier Components are duplicated on two physical systems and IBM Cognos Content Manager is similarly duplicated, with only one instance being active at any given time. Additional systems could easily be added to increase capacity of provide further redundancy.

This scenario would allow for one system to fail partially or completely and the remaining system would be given all requests. This may be desirable from a failover point of view, but each system must be able to carry full client load for it to be feasible. By using this approach and scaling it upwards to 3 or more systems, each individual system would be required to support a lesser load.

The initial request flow will be the same path as followed in the first scenario.








4.3 Web Server Farming

This scenario is identical to the previous example except a web farm has been introduced.

It is important to note that every web server instance must have the IBM Cognos Gateway installed on it if it is to service the static content.

If the web farm is also performing load balancing then the WebSphere web server plug-in must also be installed and configured on each web server instance.

This is likely a good representative scenario for a standard install into a WebSphere cluster since it exercises the failover and load balancing capabilities.








4.4 Clustering for Scalability

This scenario demonstrates an environment where is may be necessary to add additional Application Tier Components for performance or scalability reasons. The main purpose here is to show that scaling can occur vertically as well as horizontally.

Requests in this case will be routed to all three Report Server instances.

Content Manager is not replicated to a standby Content Manager in this example, but of course it is possible to do so and depending on the importance of the application to the client, this may be desired. It was removed to reduce the size of the illustration.








4.5 IBM Cognos Servlet Gateway Clustering

Similar to IBM Cognos Report Server / ATC clustering, it is also possible to cluster the IBM Cognos Servlet Gateway application.

In this case though the request path is different since the request will go initially through the load balance mechanism attached to the web server to load balance to a servlet gateway cluster and must then pass back up to the web server for load balancing at the IBM Cognos ReportNet report server level.

This scenario will cover both failover and scalability.








5 Clustering & IBM Cognos Setup

5.1 Install and Configure the Software

5.1.1 IBM WebSphere

Install the IBM WebSphere platform and all applicable updates including updates to the plug-in module and JRE.

Install:

• IBM WebSphere Application Server, one install per physical system

o If the web server plugin is to be used, ensure that the appropriate install options are selected to include this component.

• IBM WebSphere Application Server Network Deployment (or Enterprise Edition), one install per managed domain

• IBM WebSphere web server plug-in and any available updates

• IBM WebSphere JRE updates

Configuration:

• Federate any nodes that you intend to make part of a WebSphere Cluster

• Create the appropriate clusters for your environment and add members to make a vertical, horizontal or combination cluster

The following example shows a list of available servers that have been federated into a WebSphere Network Deployment install. CRN-CM1 and CRN-CM2 will become members of the CRN-CM-Cluster cluster and CRN-RS1 and CRN-RS2 will become members of the CRN-RS-Remote-Cluster cluster.

Example showing the creation of two clusters with members as listed above:


5.1.2 IBM Cognos Applicaiton

Install an appropriate version of IBM Cognos ReportNet / IBM Cognos 8:

• One install per WebSphere server instance. Distributed IBM Cognos installs will reduce the overhead by removing unused components and should be selected where appropriate.

The following task should be completed if you intend to service static content via the web server (recommended) as opposed to servicing the static content via the application server. There are two ways that this can be accomplished:

5.1.2.1 Option 1: Disable WebSphere File Serving (Recommended)

Note: This step must be performed prior to building the application archive file or it will have no effect.

WebSphere provides a facility to distinguish between the requests that the web server plugin will route to the application server for processing versus the requests that the web server will handle itself. This facility is called File Serving.

The IBM WebSphere documentation should be consulted for more information on this subject since this behaviour is under their control. File Serving is globally enabled by default and it can be globally disabled, or disabled on an application by application basis.

When enabled, unless manually modified, all requests that enter the web server and match the base context root will be routed to the application server. This means that all application server requests (java) and static content requests will be sent to the application server. The WebSphere web server plug-in is designed such that inbound requests are run through this module first before any other alias mapping is performed.

When file serving is disabled, only requests that match a specific servlet context root pattern will be routed to the application server. The remaining requests will be processed by the web server.

To disable file serving:

Create a file named: ibm-web-ext.xmi

This file must be in the following location: <Cognos8>/webapps/p2pd/WEB-INF

Copy the following text into the file using a text editor or xml editor of your choice:


The key entry in this file is ‘name="fileServingEnabled" value="false"’ which disables the File Serving option for the application.

Once the file is in place and saved it will be included in the application archive file automatically and will override the value for this feature within WebSphere when it is deployed.

Should you wish to change this behaviour any time in the future, then the file can be put in place or removed to disable or enable the option respectively. Note though that the application archive file must be regenerated, the application must be uninstalled and reinstalled, and the plugin configuration file must be updated for the change to take effect.

5.1.2.2 Option 2: Manually edit the plugin-cfg.xml file

The WebSphere setup section of this document will outline the steps necessary to manually edit the WebSphere web server plugin-cfg.xml file which controls the behaviour of the plugin. As this would be required every time the plugin configuration file is regenerated, it is not the recommended solution. However, the steps can easily be scripted for an automated solution.

5.1.3 Web Server

Install the web server of your choice that is supported by both IBM WebSphere and IBM Cognos.

Install:

• Web server software

• Web server plugin, if appropriate

Configuration:

• Configure the plug-in module following the documentation from IBM

IBM WebSphere has an option to install the plug-in module for all web servers that IBM Cognos supports. The IBM documentation must be consulted for the correct procedure for the specific platform and web server in question. As an example though, the following 2 lines could be added to an IBM HTTP Server (Apache) web server to enable the plug-in:

The “LoadModule” directive loads the plug-in module and the “WebSpherePluginConfig” directive includes the full path to the plug-in configuration file which can be automatically generated by WebSphere.

The context root element of the URI is used by the WebSphere web server plug-in to route requests to the appropriate application server and associated application. The URI to access the IBM Cognos dispatcher will be formatted as follows:

<webappext:WebAppExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:webappext="webappext.xmi" xmlns:webapplication="webapplication.xmi" xmi:id="WebAppExtension_1" fileServingEnabled="false"> <webApp href="WEB-INF/web.xml#WebApp_1"/> <jspAttributes xmi:id="JSPAttribute_1" name="fileServingEnabled" value="false"/> </webappext:WebAppExtension>

LoadModule ibm_app_server_http_module "e:/was51/bin/mod_ibm_app_server_http.dll" WebSpherePluginConfig "e:/was51nd/config/cells/plugin-cfg.xml"

<protocol>://<host or ip address>:<web server port>/<Context Root>/<alias path>


An example, using the standard HTTP protocol to connect to a local system running on the default web server port and using the default context root, would be:

You will note that this URI is very similar to accessing the dispatcher directly from a browser except it is passing through the web server in this case. The only difference is often the port value.

• Configure an IBM Cognos alias for the static content if required. The alias must use the same context root as the application.

If the web server is to be used for servicing the static content, then the <Cognos8>/webcontent directory must be copied (or mounted) to the web server and an alias defined.

Here is an example of a web alias using the default context root of /p2pd for Apache on a Windows system:

A single web alias mapping “/p2pd” to the <Cognos8>/webcontent directory should work but the behaviour is dependant on the precedence that the plug-in module runs within the web server. This is controlled by IBM and/or the web server vendor.

Technical note:

Important: If a single web alias does not work, then each subdirectory under the <Cognos8>/webcontent directory must be individually mapped in the web server configuration so that only the static content requests are processed by the web server and all other requests go to the plug-in module.

5.2 IBM Cognos Setup Steps

5.2.1 Install Order

• In a distributed environment, configure and start the Cognos components in the following order:

1. (Active) Content Manager

2. (Standby) Content Manager

3. Report Server / Application Tier Components

4. Cognos Gateway (including Cognos Servlet Gateway)

Follow the documented procedure (IBM Cognos customer documentation) if setting up an active and standby IBM Cognos Content Manager instances.

http://localhost/p2pd/servlet/dispatch

Alias /p2pd "e:/cognos/crn-gw/webcontent" <Directory "e:/cognos/crn-gw/webcontent"> Options Indexes FollowSymLinks +ExecCGI AllowOverride None Order allow,deny Allow from all </Directory>


5.2.2 General Setup

• Follow the documentation in the IBM Cognos installation guide for setting general parameters under an application server

Key items to remember:

• Copy the Java security provider files from the IBM Cognos install to the WebSphere Java directory (<was>/java/jre/lib/ext) as indicated in the IBM Cognos customer documentation

• Ensure that the JAVA_HOME variable is set to the JRE that ships with WebSphere Application Server prior to running IBM Cognos Configuration (<was>/java)

• Ensure variables are set at an appropriate scope, such as the server instance, particularly for the CRN_ROOT [ReportNet] or COG_ROOT [Cognos 8] variable (if required) and PATH (or Unix equivalent). Although the IBM Cognos application will be distributed automatically to each cluster member, each may have a unique install directory as referenced by these variables. ReportNet versions require that CRN_ROOT be set both for C++ (Application Servers -> <server name> -> Process Definition -> Custom Properties) and Java (Application Servers -> <server name> -> Process Definition -> Java Virtual Machine -> Custom Properties), while Cognos 8 versions only require this parameter passed to the JVM (Application Servers -> <server name> -> Process Definition -> Java Virtual Machine -> Custom Properties).

5.2.3 IBM Cognos Configuration

• Run IBM Cognos Configuration for each instance, starting with the Content Manager installs, and set appropriate values for your environment. As is the case with any distributed install, Content Manager must be running prior to configuring report server instances so that the encryption keys may be accessed. Similarly, the gateway installs, if present in the environment, must be done last since they reference the report server dispatcher that must be available during configuration.

• Create the IBM Cognos application archive file using the wizard in IBM Cognos Configuration or the build scripts depending on the version of the IBM Cognos product that you are installing. Keep in mind that if you wish to disable the file serving option in WebSphere for this application only that you must create the ibm-web-ext.xmi file as mentioned previously in this document prior to building the application archive file.

5.2.4 IBM WebSphere

• Modify any parameters for the server instances into which the application will be installed following the directions outlined in the IBM Cognos installation guide. In particular, the maximum heap size will likely require increasing.

• Deploy the IBM Cognos application archive file to the server instance or cluster instance

• Generate a WebSphere web server plugin configuration file.

WebSphere will generate a default plugin-cfg.xml file based on all servers, clusters and applications that have been configured and deployed at the time the file is generated. This will include IBM Cognos applications if they have been deployed.

If WebSphere file serving is enabled (default) pattern matching against the URI inbound into the web server is performed using the context root which by default is “/p2pd” for IBM Cognos applications. If this behaviour is not disabled as described previously in this document, then the plugin configuration must be changed so that only IBM Cognos dispatcher requests are forwarded to the application server and the IBM Cognos application for processing.


The file plugin-cfg.xml is located under the WebSphere install <was>/config/cells directory.

Some of the key entries in this file contain references to the available server or clusters. For example, here is an abbreviated section that defines a cluster with 2 members and indicates the load balance type (round robin), default weighting values, ports that are used, etc:

The servlet mappings associate a URI pattern to a server or cluster instance.

If WebSphere file serving is disabled, WebSphere expects that the static content will be serviced by the web server. The configuration file for the plugin will map the individual servlets and manual editing of the file will not be required.

Example of an IBM Cognos application mapping (file serving disabled):

(Note: “AffinityURLIdentifier="jsessionid"” entries have been removed for presentation purposes)

If WebSphere file serving is enabled, WebSphere expects that the static content will be serviced by WebSphere.

To modify the request mapping criteria such that only dispatcher requests are load balanced and routed to the application server, search for and replace “/p2pd/*” with “/p2pd/servlet/dispatch/*”.

Example of an IBM Cognos application mapping (file serving enabled):

would become:

<UriGroup Name="default_host_CRN-RS-Cluster_URIs"> <Uri AffinityCookie="JSESSIONID" Name="/p2pd/jcgi/cgib"/> <Uri AffinityCookie="JSESSIONID" Name="/p2pd/servlet/dispatch/*"/> <Uri AffinityCookie="JSESSIONID" Name="/p2pd/servlet/gc"/> <Uri AffinityCookie="JSESSIONID" Name="/p2pd/*.jsp"/> <Uri AffinityCookie="JSESSIONID" Name="/p2pd/*.jsv"/> <Uri AffinityCookie="JSESSIONID" Name="/p2pd/*.jsw"/> <Uri AffinityCookie="JSESSIONID" Name="/p2pd/j_security_check"/> <Uri AffinityCookie="JSESSIONID" Name="/p2pd/ibm_security_logout"/> <Uri AffinityCookie="JSESSIONID" Name="/p2pd/servlet/*"/> </UriGroup>

<UriGroup Name="default_host_CRN-RS-Cluster_URIs"> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/p2pd/servlet/dispatch/*"/>

<UriGroup Name="default_host_CRN-RS-Cluster_URIs"> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/p2pd/*"/> </UriGroup>

<ServerCluster LoadBalance="Round Robin" Name="CRN-RS-Cluster"> <Server LoadBalanceWeight="2" Name="NODE_CRN-RS1"> <Transport Hostname="host1.cognos.com" Port="9081" Protocol="http"/> <Transport Hostname="host1.cognos.com" Port="9444" Protocol="https"/> </Server> <Server LoadBalanceWeight="2" Name="NODE_CRN-RS2"> <Transport Hostname="host1.cognos.com" Port="9082" Protocol="http"/> <Transport Hostname="host1.cognos.com" Port="9445" Protocol="https"/> </Server> <PrimaryServers> <Server Name="NODE_CRN-RS1"/> <Server Name="NODE_CRN-RS2"/> </PrimaryServers> </ServerCluster>


If there are separate clusters or entries for IBM Cognos Application Tier and IBM Cognos Content Manager requests, then the entry or entries for IBM Cognos Content Manager requests must be removed so that requests are only forwarded to Application Tier dispatchers for increased performance.

Any time the configuration file is regenerated using the IBM WebSphere admin console or the scripts provided with WebSphere this manual edit must take place. It is possible to automate the change using a variety of tools.

One such tool available on most Unix platforms (also available as an add on for Windows) is SED.

The following is a sample SED script that will replace the default context root (ex: /p2pd) value in the WAS plugin-cfg.xml file to <context root>/servlet/dispatch. This can be used as part of an automated plugin update process.

• If the WebSphere WLM module is used, IBM Cognos ReportNet must be set to Cluster Compatible mode using the Server Administration page within IBM Cognos Connection.

@echo off rem Windows script to modify the context root alias in rem the WebSphere plugin configuration file. Note: this rem would not be necessary except that IHS passes all rem requests through the WAS module first before rem performing any other pattern matching. rem Enter the full path and name of the input file set SEDInputFile=plugin-cfg.xml.tmp rem Enter the full path and name of the output file set SEDOutputFile=plugin-cfg.xml rem Parametrize the Context Root element in case the client rem has changed it from the default of "p2pd" set CRNContext_Root=p2pd rem This script assumes that the WebSphere script rem named GenPluginCfg.bat (.sh) was run and created rem an output file named plugin-cfg.xml.tmp rem Note for Unix: Replace %var_name% with $var_name rem throughout the script. @echo Running sed against %SEDInputFile% and overwriting %SEDOutputFile% @echo Pattern match and replace "%CRNContext_Root%/*" with "%CRNContext_Root%/servlet/dispatch/*" rem sed -e 's/\/%CRNContext_Root%\/\*/\/%CRNContext_Root%\/servlet\/\*/g' %SEDInputFile% >%SEDOutputFile% rem Optionally remove the original file. rem if exist %SEDInputFile% (del %SEDInputFile% ) rem Clear the environment variables set by this script set SEDInputFile= set SEDOutputFile= set CRNContext_Root= echo Run complete


5.3 Additional Notes

• The administrative console for the WebSphere Network Deployment install should be used to manage the environment rather than the administrative console for individual WebSphere server installs. This will ensure that all available servers and clusters may be managed, that the plugin configuration file will represent all applications and that the appropriate options are available to the client. The node manager must also be running on each individual server instance.

• The IBM Cognos Active Content Manager instance should be installed, configured and started as a standalone server (it may still be a cluster member) prior to bringing a standby Content Manager online to ensure that the Content Store is created properly.

• It may be desirable to start the IBM Cognos Content Manager instances separately, even if they are members of a cluster, to reduce the startup time by avoiding the Content Manager election process. The cluster start or cluster Ripplestart option may be used if desired.

• IBM Cognos Report Server or Application Tier Component instances may be managed as a cluster. The Ripplestart option in WebSphere will reduce the initial impact of starting the cluster, but will also delay the startup process.

• Ensure that the Virtual Host entries in WebSphere accept requests for any additional servers that you may have defined as well as the port that your web server is running on.

• Reminder, in a multi-server setup, unique log ports must be configured for each instance of the IBM Cognos application using IBM Cognos Configuration.


6 IBM Web Site Information

6.1 WebSphere Web server plug-in connections

The WebSphere Web server plug-in is used to establish and maintain persistent connections to the Application Server HTTP and HTTPS transports.

When the plug-in is ready to send a request to the Application Server, it first checks its connection pool for existing connections. If an existing connection is available the plug-in checks its connection status. If the status is still good, the plug-in uses that connection to send the request. If a connection does not exist, the plug-in creates one. If a connection exists but has been closed by the Application Server, the plug-in closes that connection and opens a new one.

Once a connection is established between a plug-in and the Application Server, it will not be closed unless the Application Server closes it for one of the following reasons:

• The time limit specified on the ConnectionKeepAliveTimeout HTTP transport custom property has expired.

• The maximum number of requests which can be processed on a single keep alive has been exceeded. (This number is set using the connectionMaxKeepAliveRequests HTTP transport custom property.)

• The maximum number of concurrent keep alive (persistent) connections across all HTTP transports has been exceeded. (This number is set using the MaxKeepAliveConnections HTTP transport custom property.)

• The Application Server is shutting down.

Even if the Application Server closes a connection, the plug-in will not know that it has been closed until it tries to use it again. The connection will be closed if one of the following events occur:

• The plug-in receives a new HTTP request and tries to reuse the existing connection. • The number of httpd processes drop because the Web server is not receiving any new HTTP requests.

(For the IHS Web server, the number of httpd processes that are kept alive depends on the value specified on the Web server's MinSpareServers directive.)

• The Web server is stopped and all httpd processes are terminated, and their corresponding sockets are closed.

Note: Sometimes, if a heavy request load is stopped or decreased abruptly on a particular Application Server, a lot of the plug-in's connections to that Application Server will be in CLOSE_WAIT state. Because these connections will be closed the first time the plug-in tries to reuse them, having a large number of connections in CLOSE-WAIT state should not affect performance

Date post:	06-Aug-2020
Category:	Documents
Upload:	others
View:	8 times
Download:	0 times

Cognos 8 & WebSphere Clusteringpublic.dhe.ibm.com/.../application...clustering.pdf · Proven...

Documents