Copyright IBM Corporation 2010 Trademarks

Cognos cloud best practices: Moving from a single- to a

multiple-image topology
Page 1 of 12
Cognos cloud best practices: Moving from a
single- to a multiple-image topology
Best practices to help you manage multiple-image Cognos
cloud performance
Stephan Jou
Technical Architect
IBM
William Lee
Senior Software Consulting Engineer
IBM
Thanh Pham
Solution Architect
IBM
Biraj Saha
Advisory Software Developer
IBM
Skill Level: Intermediate
Date: 25 Aug 2010
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.
View more content in this series
Cloud Computing: Introduction to Software as a Service http://www.ibm.com/
developerworks/training/kp/cl-kp-cloudsaas/index.html
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.
developerWorks ibm.com/developerWorks/
Cognos cloud best practices: Moving from a single- to a
multiple-image topology
Page 2 of 12
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
ibm.com/developerWorks/ developerWorks
Cognos cloud best practices: Moving from a single- to a
multiple-image topology
Page 3 of 12
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
developerWorks ibm.com/developerWorks/
Cognos cloud best practices: Moving from a single- to a
multiple-image topology
Page 4 of 12
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 10.3.0.1,
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
ibm.com/developerWorks/ developerWorks
Cognos cloud best practices: Moving from a single- to a
multiple-image topology
Page 5 of 12
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.
developerWorks ibm.com/developerWorks/
Cognos cloud best practices: Moving from a single- to a
multiple-image topology
Page 6 of 12
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 URL Replace localhost with vm-gateway
Dispatcher URI Enter 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 gateway Replace localhost with myCognos
External dispatcher URI Replace localhost with myCognos
Internal dispatcher URI Replace localhost with myCognos
Dispatcher URI for external applications Replace localhost with myCognos
Content Manager Enter 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:
ibm.com/developerWorks/ developerWorks
Cognos cloud best practices: Moving from a single- to a
multiple-image topology
Page 7 of 12
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 alias The new setting
myCognos Instance 1 IP
vm-db2 Instance 1 IP
vm-gateway Instance 2 IP
vm-cognos1 ... vm-cognos10 Instance 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 alias The new setting
myCognos Instance 2 IP
vm-db2 Instance 1 IP
vm-gateway Instance 2 IP
vm-cognos1 ... vm-cognos10 Instance 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 alias The new setting
myCognos Instance 3 IP
vm-db2 Instance 1 IP
vm-gateway Instance 2 IP
vm-cognos1 ... vm-cognos10 Instance 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
developerWorks ibm.com/developerWorks/
Cognos cloud best practices: Moving from a single- to a
multiple-image topology
Page 8 of 12
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 alias The new setting
myCognos Instance n IP
vm-db2 Instance 1 IP
vm-gateway Instance 2 IP
vm-cognos1 Instance 3 IP
vm-cognos2 ... vm-cognos10 Instance 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
ibm.com/developerWorks/ developerWorks
Cognos cloud best practices: Moving from a single- to a
multiple-image topology
Page 9 of 12
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).
developerWorks ibm.com/developerWorks/
Cognos cloud best practices: Moving from a single- to a
multiple-image topology
Page 10 of 12
Resources
Learn
Find more information about Cognos Business Analytics.
Check out other IBM Business Analytics software.
The Cognos Proven Practices team delivers documentation of best practices
built from real-life customer experiences.
The Redbooks draft, "IBM Smart Analytics Cloud" details a lab implementation
of a smart analytics cloud.
In the developerWorks cloud developer resources, discover and share
knowledge and experience of application and services developers building their
projects for cloud deployment.
Get products and technologies
View online demos and try Cognos 8 Business Intelligence software.
Discuss
Join a cloud computing group on My developerWorks.
Read all the great cloud blogs on My developerWorks.
Join the My developerWorks community, a professional network and unified set
of community tools for connecting, sharing, and collaborating.
ibm.com/developerWorks/ developerWorks
Cognos cloud best practices: Moving from a single- to a
multiple-image topology
Page 11 of 12
About the authors
Stephan Jou
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
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
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
Biraj Saha is an advisory software developer at IBM Cognos,
specializing in metadata and algorithm design and development for
developerWorks ibm.com/developerWorks/
Cognos cloud best practices: Moving from a single- to a
multiple-image topology
Page 12 of 12
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.
Copyright IBM Corporation 2010
(www.ibm.com/legal/copytrade.shtml)
Trademarks
(www.ibm.com/developerworks/ibm/trademarks/)