Cognos cloud best practices: Moving from a single- to a multiple-image topology

Best practices to help you manage multiple-image Cognos cloud performance

Just like in a traditional data center, the deployment of Cognos into the cloud may require multiple machines, so your cloud solution may require multiple images. Criteria such as performance, scalability and high availability typically lead to a multi-image topology. The authors demonstrate the best practices for managing this type of multi-image topology.


Stephan Jou, Technical Architect, IBM China

Stephan Jou is a technical architect, research staff member, and Sr. technical staff member at IBM's Business Analytics division, in the Technology & Innovation group at the Office of the CTO. In his career at Cognos Software, he architected and led the development and productization of several initial release products in that enabled data mining, neural networks, visualization, mobile, dashboarding, and semantic search. His current role at IBM focuses on translating academic and IBM research into product strategies for Cognos and SPSS Software. Jou holds a M.Sc. in Computational Neuroscience and Biomedical Engineering and a dual B.Sc. in Computer Science and Human Physiology, all from the University of Toronto.

William Lee, Senior Software Consulting Engineer, IBM China

William Lee is a senior software consulting engineer at IBM through the Cognos acquisition. He is a member of the Technology and Innovation team for the Office of the CTO in IBM's Business Analytics division; he helps define the technical vision and direction for Cognos and SPSS software products. Lee has been with Cognos and IBM since 1992 and holds a Bachelor of Computer Science and Mathematics and a Masters of Computer Science, all from Carleton University, Ottawa, Canada.

Thanh Pham (, Solution Architect, I.B.M.

Thanh Pham is a Solution Architect in the IBM Information Management Advanced Technology. His current focus is to help customers build applications using IBM Mashup Center product and IBM cloud computing. Before this role, he was an architect for the ECM/Filenet Business Process Framework.

Biraj Saha, Advisory Software Developer, IBM China

Biraj Saha is an advisory software developer at IBM Cognos, specializing in metadata and algorithm design and development for Cognos modeling tools such as Framework Manager, Metrics Designer and Architect, as well as SOA and SDK development for Cognos 8 BI Server. Previous to 2000, he was a senior software engineer for EDS Systemhouse, serving in lead development roles for a wide array of customers on various RDBMS-related developments including ERP and RDBMS-vendor application conversions and custom Java™, C++, stored procedure, and 4GL applications. Saha has a Bachelors degree in Computer Science from the University of New Brunswick in Canada and a Masters degree in Computer Science, specializing in object-oriented database constraint theory, from the University of Waterloo, Canada.

25 August 2010

Also available in Chinese Russian Japanese Spanish

Just as a traditional data center deployment of Cognos may require multiple machines, so your cloud solution may require multiple images. Criteria such as performance, scalability, and high availability typically lead to a multiple-image topology. Some best practices for these multi-image topologies are described in this article.

This is the first in a series of best practices and installation and configuration tips for Cognos in the cloud. Cognos 8 is used in this series.

Before starting with best practices for using multiple software images, performance and scaling, and high availability issues, let's take a look at clouds, workloads, and how Cognos 8 can leverage the power of the cloud.

Cognos 8 BI: Fasten your seatbelts

First, a few words about IBM Cognos 8 BI for those of you not familiar with this product.

IBM® Cognos® 8 Business Intelligence (BI) is a member of IBM's Information Management brand which handles all kinds of software — besides Cognos BI, there's DB2®, Cloudscape, InfoSphere™, Optim™, FileNet®, Informix®, and OmniFind®— doing all kinds of tasks — analytics, data and database management, enterprise content and compliance management, messaging and collaboration, and portals and mashups. Cognos software and SPSS's statistical analysis software make up IBM's Business Analytics division.

IBM Cognos 8 BI is made up of four major task-oriented components:

  1. IBM Cognos 8 BI Reporting: Provides a set of reporting capabilities in a single, web-based solution for all components of the reporting life cycle, for example:
    • Self-service reporting that enables users to grab the info they need without bothering IT.
    • Author once, access anywhere reporting allows IT to create a single report that users can access on a multitude of devices; it includes support for more than 25 languages, can be issued in multiple formats, and can be accessed by other applications and processes.
  2. IBM Cognos 8 BI Analysis: Lets you interactively explore information regardless of where the data is stored (online analytical processing and dimensionally modeled relational sources). It provides quick analysis of complex issues, lets you slide between summary-level detail and transaction-level detail to find the critical piece of data, and has built-in customizable time series so you can construct detailed, sophisticated trend "photos" of what's happened in your company over time.
  3. IBM Cognos 8 BI Dashboards: Helps you monitor, measure, and manage performance by providing an at-a-glance view of what your data is trying to tell you; they are a key tool to help you spot a small anomaly before it becomes a big business problem. Dashboards can be personalized to produce the level of visualization you require and to provide output in multiple formats.
  4. IBM Cognos 8 BI Scorecarding: Helps you take the analysis from the reports you got through the dashboards, turn it into a metric, then generate a forward-looking strategy from the analysis. It also helps to communicate this strategy to others by creating metrics they can measure the results of their actions against. The component is like the central command for an operation:
    • Each metric in a scorecard can be assigned an owner.
    • Each scorecard can be ranked by priority within the entire strategy map.
    • Each scorecard can have BI capabilities embedded into it for on-going analysis in a fast-changing situation.
    • Each scorecard can be viewed within the overall strategy map, making it easier to determine how the scorecard fits as the overall plan evolves.

There are also various components available to extend Cognos 8 BI.

Cognos 8 BI: Into the clouds

We think it's obvious that the power of business analytics software and the scope of cloud computing are an exciting fit. Both concepts are about blasting past limitations that more traditional systems impose upon us:

  • Cloud computing attempts to beat both virtual and physical resource storage limitations by facilitating the ability to share data resources and by eliminating the need to have all data resources hosted on the same machine. It tries to eliminate the peak CPU-usage conundrum by balancing workloads across the various systems inside (and sometimes outside of) the cloud in question. It tries to solve the access-cost problem by making predefined application-testing systems and productivity applications available on a per-need basis.
  • Business analytics takes the labor-intensive work of trend- and anomaly-spotting out of the hands of humans and automates it; it creates "visualizations" of the data, turning data into information so people can easily perceive the trends and share the discoveries; it provides possible interpretation/solution combinations, turning the information into knowledge, allowing people to concentrate on the most important task of all — to answer the question "Where do I go from here?"

In this series

In this series we discuss best practices based on our own experiences including:

  • Managing a multi-image cloud topology of Cognos based on such criteria as performance, scalability, and high availability. We discuss using the existing Hosts file to manage multiple images, scaling out to different cluster sizes, creating snapshots using private images, and where you may want to store needed files.
  • Sizing your architecture for performance and scalability. We'll talk about how the user community and geographic distribution affect performance and how application complexity can affect performance. And we'll provide a general rule on post-deployment scalability.
  • Choosing the settings to enable high availability. We'll provide recommendations for setting up and maintaining Cognos in the cloud for high availability and for disaster recovery, including how to use Cognos gateways and Cognos application servers, Cognos Content Manager in both active and standby modes, and the IBM DB2 High Availability and Disaster Recovery (HADR).
  • General topology, security, and data considerations. We'll talk about where your data, query database, and authentication source should reside for various types of workloads and requirements.

We may address Cognos 8 BI/IBM Cloud-specific security best practices and installation variations in future articles if readers decide that it is necessary.

To kick off the series, we provide a simple (not exhaustive) list of considerations for designing and testing your topology.

Four tips to get started with the cloud

As you design and refine your topology:

  1. Begin simply; satisfy your requirements, but avoid unnecessary complexity.
  2. Always keep the number of cloud instances in your topology as low as possible; adding instances is easy so initially underestimate your requirements.
  3. #2 also applies when it comes to the number of unique cloud images. For example, it is easier to manage a single DB2 database image that customizes itself on startup rather than to create five different query database images.
  4. The process of designing and testing your topology should be iterative, something like this:
    1. Design/refine your topology.
    2. Create/customize the required instances.
    3. Install/configure the instances.
    4. Save image snapshots.
    5. Test for functionality and performance.
    6. Repeat.

Now let's look at the main article: Best practices for managing a multi-image cloud topology.

Best practices: Using the Hosts file to manage multiple images

When dealing with multiple cloud images, you have to deal with multiple and changing IP addresses associated with those images.

A hostname pairs a logical name to an IP address; hostnames are often stored by a DNS server to allow programs to map the hostname to an IP address or vice-versa. For example, the IP address for your standby Content Manager, version, may be mapped to the hostname cm_standby.

For complex solutions, it may be appropriate to deploy an internal DNS server to manage these hostnames. As a bonus, though, machines also have a file known as the hosts file which is used by the operating system to map hostnames to IP addresses. In many cases, it is easier to use the hosts file to manage your cluster of instances:

  • On UNIX®, the hosts file is located at /etc/hosts.
  • On Windows®, the hosts file is located at \Windows\System32\Drivers\etc\hosts.

For the purposes of this article, we assume that all your instances are in the same cloud region and therefore the same private class IP range. If you have cloud instances in different geographical regions, you may have the additional consideration of dealing with multiple class IP ranges.

Example: An elastic Cognos 8 cluster with a single image

Remember, it is always simpler to manage a cloud solution that has as few images as possible. For example, although a Cognos 8 cloud deployment may have instances with different roles (gateway, dispatcher, content manager, etc.), it is often easier to manage the deployment by creating a single generic image that can then be customized.

A Cognos 8 cluster can include three logical components:

  • Gateway
  • Dispatcher and content manager
  • Database.

One approach to building this cluster is through the use of three separate cloud images:

  • Gateway image (with Cognos and Apache)
  • Dispatcher cloud image
  • DB2 database image

Remember the rule: As few images as possible. Scaling the solution dynamically in this scenario also presents challenges that are not present when all the components are loaded on a single cloud image.

You can start with a single cloud image that includes all the software components (Cognos 8, Apache, and DB2). Then define a mechanism to dynamically start instances from this single image and configure it to dynamically grow.

The three main steps to do this are:

  1. Install all the required software into a single cloud image.
  2. Configure the solution cluster using hostname aliases.
  3. Map these aliases into an actual instance and its associated IP address using the hosts file.

Hostname aliases

Create a hosts file that contains the following entries:

  • myCognos. Alias to the current instance (similar to localhost).
  • vm-db2. Alias for the DB2 instance.
  • vm-gateway. Alias for the Cognos gateway instance.
  • vm-cognos1. Alias to the first Cognos dispatcher.
  • vm-cognos2 ... vm-cognos10. Aliases to the remaining nine potential Cognos dispatchers.

By default, all the aliases in the hosts file are mapped to localhost, the alias for the current machine instance.

From the Cognos 8 Configuration tool on the Environment tab, enter the settings from Table 1:

Table 1. Configuration settings
Gateway URLReplace localhost with vm-gateway
Dispatcher URIEnter the ten dispatchers: http://vm-cognos1:9080/p2pd/servlet/dispatcher/ext, http://vm-cognos2:9080/p2pd/servlet/dispatcher/ext, etc. for all ten dispatchers
Controller URI for gatewayReplace localhost with myCognos
External dispatcher URIReplace localhost with myCognos
Internal dispatcher URIReplace localhost with myCognos
Dispatcher URI for external applicationsReplace localhost with myCognos
Content ManagerEnter the ten dispatchers: http://vm-cognos1:9080/p2pd/servlet/dispatcher/ext, http://vm-cognos2:9080/p2pd/servlet/dispatcher/ext, etc. for all ten dispatchers

In the URIs in Table 1, replace the port 9080 (the default port used by the dispatcher when installed into Websphere® Application Server) with the appropriate port number in your environment. For example, 9300 if you are using Tomcat instead of the WebSphere Application Server.

These configuration settings allow you to scale out your cloud topology from a single-instance cluster to 12 instances simply by starting instances and making changes to the hosts file.

Now let's look at cluster size.

A cluster of size 1

Any instance can act as a single, standalone cluster of size 1. All the installed software (Cognos 8, Apache, and DB2) runs on the single instance.

A cluster of size 2

For a cluster of size 2, two instances play the following roles:

  • Instance 1 plays the DB2 role.
  • Instance 2 plays the gateway, dispatcher, and content manager role.

Assign Instance 1 to the DB2 role by making the following changes to the Instance 1 hosts file:

Instance 1 hostname aliasThe new setting
myCognosInstance 1 IP
vm-db2Instance 1 IP
vm-gatewayInstance 2 IP
vm-cognos1 ... vm-cognos10Instance 2 IP

Assign Instance 2 to the gateway, dispatcher, and content manager role by making the following changes to the Instance 2 hosts file:

Instance 2 hostname aliasThe new setting
myCognosInstance 2 IP
vm-db2Instance 1 IP
vm-gatewayInstance 2 IP
vm-cognos1 ... vm-cognos10Instance 2 IP

Notice that changes to the hosts file should take effect immediately; under most operating systems (including Windows and Linux), new and updated hosts entries do not require any services to be restarted. In addition, any Cognos 8 instances that are already running do not need to be restarted for these changes to take effect.

A cluster of size 3

Start your third instance and change the host files to assign the following roles:

  • Instance 1 to play the DB2 role.
  • Instance 2 to play the gateway role.
  • Instance 3 to play the dispatcher/content manager role.

For example, the Instance 3 host file is changed as follows:

Instance 3 hostname aliasThe new setting
myCognosInstance 3 IP
vm-db2Instance 1 IP
vm-gatewayInstance 2 IP
vm-cognos1 ... vm-cognos10Instance 3 IP

Scaling out to clusters of sizes 4 to 12

To scale out additional instances beyond size 3, repeat the steps we've outlined. Add a new instance and attach it to the topology as an additional dispatcher by assigning the remaining vm-cognos hostnames to the new instance's IP. For example, adding the fourth instance modifies instance 4's hosts file:

Instance 4 hostname aliasThe new setting
myCognosInstance n IP
vm-db2Instance 1 IP
vm-gatewayInstance 2 IP
vm-cognos1Instance 3 IP
vm-cognos2 ... vm-cognos10Instance 4 IP

Essentially you are dynamically scaling out your solution by adding cloud instances to the dispatcher list. The dispatcher list acts as a load balancer so that Cognos 8 will contact the dispatchers in the order they appear within Cognos configuration.

The limit of 10 dispatchers (for a total of 12 instances in this topology) was arbitrarily set for this example; it can be lowered or raised based on your requirements.

Creating snapshots using private images

As you develop your solution, be sure to snapshot your work by creating private images in the IBM Cloud. In addition to providing a backup, private images will save time by recording all the software installation and configuration for your image.

For example, by creating a private image of your operating system with any repository changes, security/firewall settings, and some common tools, you can create a starting point for other images without having to "start from scratch" each time. This kind of base image snapshot is a recommended best practice.

Changes to private images create a new private image, but only the differences between the first image and the second image are stored. This means that when you install, for example, Cognos 8 into your base image and then create a new private image, the result is a much smaller image. The image in this case only needs to persist the newly added Cognos 8 software.

You can not delete any intermediate private images because private images, as we explained earlier, only store the changes between images in order to save space (called delta changes). For example, if image C is based on image B which is based on image A, then you can not delete image B because C depends on it; the IBM Cloud generates C from A by applying changes to B.

Files in the cloud

Files in the IBM Cloud are stored in two places — on the file system associated with the cloud instance or on a mounted directory.

Files can be stored on the file system associated with the cloud instance. This local file system is analogous to a PC's hard drive. Files stored here should be considered temporary because each instance's file system is ephemeral. If the instance is shut down (or suffers some sort of failure), information persisted on the file system is lost. In addition, files stored within the cloud instance are not accessible to other instances.

Files can be stored on a mounted directory based on a file system from the IBM Cloud's storage instance. This cloud file system is analogous to a NAS (network addressable storage) unit connected to multiple PCs. Files stored here can be considered permanent thanks to the backup and redundancy guarantees of the IBM Smart Business Development and Test Cloud's storage.

Files stored in this mounted directory are accessible by and sharable among all your instances. Additional backup and recovery services of your storage can be purchased separately from the IBM Smart Business Development and Test Cloud.

If files need to be stored outside of your cloud images or shared between cloud instances, store the files in mounted directories from the IBM Storage Cloud. In a multi-image deployment of Cognos 8, consider storing the following in mounted directories rather than in your local instances:

  • File-based data sources
  • Common software
  • Common deployment scripts (allows you to update/tweak these scripts without modifying multiple private images)
  • Pre-built hosts files and other configuration files (to copy into your cloud instances)
  • Copies of important audit or log files (so they persist even if the originating instance is shut down)
  • Database backup files

In conclusion

We hope these best practices help you to better manage multiple-image cloud topologies so you can effectively run Cognos in the IBM Cloud. Combining the power of cloud computing with the ability of smart business analytics can give your applications a competitive edge.

Look for more information on running Cognos on the cloud at the Cognos site and on developerWorks (Resources).



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Big data and analytics on developerWorks

Zone=Big data and analytics, Cloud computing, Information Management
ArticleTitle=Cognos cloud best practices: Moving from a single- to a multiple-image topology