High Availability Within the Application Tier

Proven Practice

High Availability in the Application Tier

Product(s): IBM Cognos 8

Area of Interest: Infrastructure

High Availability in the Application Tier 2

IBM Cognos Proprietary Information

Copyright Copyright © 2008 Cognos ULC (formerly Cognos Incorporated). Cognos ULC is an IBM Company. 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. Cognos does not accept responsibility for any kind of loss resulting from the use of information contained in this document. This document shows the publication date. The information contained in this document is subject to change without notice. Any improvements or changes to the information contained in this document will be documented in subsequent editions. This document contains proprietary information of Cognos. All rights are reserved. No part of this document may be copied, photocopied, reproduced, stored in a retrieval system, transmitted in any form or by any means, or translated into another language without the prior written consent of Cognos. Cognos and the Cognos logo are trademarks of Cognos ULC (formerly Cognos Incorporated) in the United States and/or other countries. IBM and the IBM logo are trademarks of International Business Machines Corporation in the United States, or other countries, or both. All other names are trademarks or registered trademarks of their respective companies. Information about Cognos products can be found at www.cognos.com This document is maintained by the Best Practices, Product and Technology team. You can send comments, suggestions, and additions to [email protected] .

mailto:[email protected]



Contents 1 INTRODUCTION............................................................................................ 4 1.1 PURPOSE ..............................................................................................................4 2 THE IBM COGNOS 8 APPLICATION TIER ...................................................... 5 2.1 CONTENT MANAGER ................................................................................................6 3 FAILOVER STRATEGIES ................................................................................ 6 3.1 SOFTWARE FAILOVER ...............................................................................................6 3.2 USING HARDWARE ..................................................................................................9 3.3 CLUSTER COMPATIBLE SETTING ................................................................................ 10


1 Introduction

1.1 Purpose When designing a IBM Cognos 8 implementation, consideration must be paid as to how important high availability is. For example, a system that prints marketing correspondence as scheduled batch jobs can probably afford to be off-line for a number of hours without unduly affecting business operations. Conversely, an on-line reporting system used by call centre staff to call up customer records while speaking with clients will require high availability. Every tier within a IBM Cognos 8 environment has the potential to be the point of failure for the system – accordingly each tier has strategies to enable operation to continue should a single component fail. This document is an overview to providing fail over capabilities for the application tier in IBM Cognos 8.

Web Tier

Application Tier

Data Tier



2 The IBM Cognos 8 Application Tier

The Application tier of IBM Cognos 8 is where the majority of the processing is performed. Components of the Application Tier receive user requests from the Web Server or external applications via the SDK and must fulfil them appropriately. In turn, the Application Tier will often have to query the data tier in the form of SQL requests in order to obtain data for prompts, reports etc. The services running in the Application tier are listed in IBM Cognos Configuration on each Server. Specific services can be enabled or disabled.

All the services are installed on each server that had Application Tier Components selected at install time and multiple versions can be running at the same time for failover and performance benefits. More details of the individual services are available in the Architecture and Planning Guide that comes with IBM Cognos 8.




2.1 Content Manager The one service that can be installed completely standalone is Content Manager. This differs from the other services in that multiple Content Managers cannot be running in an active state at the same time. Instead, any additional Content Manager services will be running in standby mode and will not become active unless the primary Content Manager is no longer available for some reason. This means there is no performance benefit to having multiple Content Managers running – all requests will always go to the single active Content Manager.

3 Failover Strategies

In order to ensure that the Application Tier is not the point of failure for a IBM Cognos 8 install, multiple servers running duplicate services are used to introduce redundancy into the system. This has the additional benefit of aiding performance as the duplicate services can be running concurrently, processing multiple requests in parallel (with the exception of Content Manager). As previously mentioned, the Application Tier will be carrying out much of the processing in a IBM Cognos 8 environment, so being able to load balance at this level is a fundamental requirement of the architecture. Accordingly, much of the complexity of handling multiple services is hidden from the IBM Cognos 8 administrator, with the services registering themselves with the Content Manager and automatically becoming available for use when coming on-line. However, some configuration changes may be required depending on the specific failover strategy chosen.

3.1 Software Failover IBM Cognos 8 is architected to enable failover with no specific hardware requirements. As mentioned above, running multiple services will cause them to automatically register themselves within the IBM Cognos 8 environment. Should one of the servers running IBM Cognos 8 become unavailable, requests will no longer be sent to it and the remaining servers will continue the work. This works well for routing requests inside the Application Tier, but at point new requests need to be made from outside – typically the IBM Cognos 8 gateway from the Web Tier. If the gateway is configured against a single Application Tier server (for example app1 in the diagram below) and this is the server that fails, then although the application still has the resources available to run, the gateway requests would fail because its entry point into the Application Tier is no longer available.


Web Tier

Application Tier

app4 app2

app3

app1

To get around this potential point of failure, any Gateway servers can be configured to be aware of any of the servers in the Application Tier by providing a list under Dispatcher URIs for gateway in IBM Cognos Configuration.



If the first Dispatcher in the list is not responding, the Gateway will move on to the next and so on. Providing redundancy at this level removes this as a point of failure.



3.2 Using Hardware The same point of failure between the Web tier and Application tier addressed above by providing a list of Dispatcher to the Gateway at configuration time may be addressed in a different way by utilizing a hardware router / load balancer. Instead of configuring a list of Dispatchers running on different servers, a single router’s address is specified. The router then passes the requests on the Application tier servers which it will have been configured to know should be available.

An advantage to using a hardware router is that they can often be configured to continuously poll the servers specified in the Application tier to ensure they are still active. At a basic level, this involves checking the server is still online. In addition to this, it is also possible to check a specific URI (<server>/p2pd/servlet/ping) within IBM Cognos 8 to ensure the Application is still running. In contrast, depending on the Gateway method implemented (.cgi, ISAPI, Apache Mod etc.), software only load-balancing may cause the gateway to not know that a Dispatcher is unavailable until a request has been generated.



3.3 Cluster Compatible Setting By default, software load balancing is enabled for requests within the Application tier. If a hardware router is being used that handles the load balancing then it may be preferred to turn this off. The setting is called Load balancing mode and is applied at the Dispatcher level. Two settings are available Weighted Round Robin (default) and Cluster Compatible.

Changing to Cluster Compatible will direct the Dispatcher to execute requests locally if the service is available (on the same server as the Dispatcher) and the request has not been directed to a specific server (high and absolute affinity requests). It should only be used where the load balancing has been performed already, for example by a hardware load-balancer or in software, such as the IBM WebSphere web server plug-in.


High Availability Within the Application Tier

Documents

Transcript of High Availability Within the Application Tier