Download Architecture and Server Sizing Guideline Product(s): Controller 8.3

1
Guideline
Architecture and Server Sizing
Product(s): Controller 8.3
Area of Interest: Infrastructure
Proprietary Information
Architecture and Server Sizing
2
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].
Proprietary Information
Architecture and Server Sizing
3
Contents
1
INTRODUCTION.............................................................................................4
1.1
1.2
1.3
PURPOSE ............................................................................................................ 4
APPLICABILITY ..................................................................................................... 4
EXCLUSIONS AND EXCEPTIONS .................................................................................. 4
2
INTRODUCTION.............................................................................................4
APPENDIX #1 – MICROSOFT SQL SERVER RECOMMENDATIONS .................................................... 20
APPENDIX #2 – DATABASE SIZE ......................................................................................... 21
APPENDIX #3 – DEPLOYING CONTROLLER 8 VIA CITRIX (OR MICROSOFT TERMINAL) SERVER(S) ............ 22
Proprietary Information
Architecture and Server Sizing
4
1 Introduction
1.1
Purpose
This document describes the architecture for Controller 8.3
1.2
Applicability
Controller 8.3
1.3
Exclusions and Exceptions
There are no known exclusions and exceptions at the time this document was created.
2 Introduction
This document describes the architecture of IBM Cognos Controller v8.3 (released February
2008).
This document describes the architecture of IBM Cognos Controller v8.3 (released February
2008).
Different customers will use Controller 8 in different ways. For example:
• Customer #1 uses all the Controller 8 functionality, to a very advanced level
o Customer#2 has a simple consolidation and simple reporting requirement
• Customer #3 has a small number (e.g. 10) of users, all located at head office (in the same
building)
o Customer #4 may have 10 or 20 users at head office, plus 150 more users in a
total of 40 remote sites around the world.
There are many factors which can impact the performance of a server based application. For the
purposes of this document (and for the sake of simplicity), user population is the main variable
that we shall consider.
However, best practices would be that any hardware sizing activity for a production environment
should also take into account:
• network connectivity (both LAN and WAN load)
• user location and usage profiles,
• processing overhead for third party software such as virus scanning and server
management
• is advanced system functionality going to be used?
o for example, is there going to be heavy use of advanced “budgeting” reports (e.g.
12+ periods of data) which would place a strain on the system (especially the
database server)
o or are the reports typically going to be “standard” managerial/statutory reports
(e.g. ~3 periods of data)
Proprietary Information
Architecture and Server Sizing
Proprietary Information
5
Architecture and Server Sizing
6
In general, this document will assume the most popular customer configuration:
• Using the “IBM Cognos 8 BI run-time” reporting components, which come bundled free
with Controller 8 itself
o This is as opposed to using a separate IBM Cognos 8 BI instance, from which to
host the reporting system
• Using Microsoft SQL 2000/2005
• Utilising a “centralised” architecture, where all servers are located at a central location (e.g.
head-office)
o This is opposed to using a “distributed” architecture, where there are separate
application and database servers at each site, and inter-site updates are sent via
email
• Optional use of Citrix/Terminal servers
o typically used to save bandwidth for remote users
However, where possible, information is given (in the form of appendices etc.) to describe the
differences for other configurations.
To Summarise: This is a simple guideline document which describes high level
recommendations for the sizing and deployment of Controller 8.3 servers based mainly upon
user population. It is designed to give a *starting point* for discussion around hardware
sizing. The author wishes to make it clear that every customer’s needs are different, and they
may find that their server architecture needs evolve during the use of Controller.
IMPORTANT: Again, I stress that this document should not be used entirely on its own. Instead,
a formal discussion between the customer and IBM Cognos Services (e.g. their technical
consultant) must always occur before the customer can make a proper informed decision (e.g. on
how many servers to purchase, their hardware specification and intended role etc.) on their
preferred architecture and method of deployment for Controller 8.
Proprietary Information
Architecture and Server Sizing
7
BASIC ARCHITECTURAL OVERVIEW
It is useful to first give a very simple high-level ‘overview’ explanation of the Controller 8
architecture:
IMPORTANT: The following diagram is based on the current (April 2008) officially supported
requirements. These may change over time, so please ensure that you check the most recent list
for your version of Controller (e.g.
http://support.cognos.com/en/support/products/controller83_software_environments.html).
Proprietary Information
Architecture and Server Sizing
8
Full Architecture Description
TIP: There is a full description of *all* the components/elements which form the Controller server
system/architecture inside the official document “Controller 8.3 Architecture and Deployment
Guide” (“ctrl_arch.pdf”)
This official document contains a vast amount of information, which the author thoroughly
recommends reading.
Below is graphical summary of the full architecture of Controller 8, expanded to show each main
component
Proprietary Information
Architecture and Server Sizing
9
NOTES:
• Controller 8 has many architectural similarities with IBM Cognos 8 BI. Therefore, some of the
elements (e.g. “Content Manager”, and “IBM Cognos Gateway”) are exactly the same as you
would see with an IBM Cognos 8 BI installation.
• The above diagram is a fairly complicated example of a customer’s configuration
o Most customers would have 1 or 2 application servers (not 4 or 5 as in the picture)
o Most customers would deploy over WAN links (e.g. VPN or MPLS), as opposed to
‘directly’ over the internet
Therefore, typically the extra (DMZ) gateway server in the diagram would
typically be unnecessary
EXAMPLES OF CUSTOMER ENVIRONMENTS
The following pages will give some examples of customer environments, based on the maximum
number of concurrent users:
NOTE: The maximum number of “concurrent” users is different from the ‘total’ number of
‘named’ users (which is the entire number of users that could ever possibly use the system)
• This maximum “concurrent” user number will be a proportion of the ‘named’ users
o this proportion will vary between customers, because of where its divisions are located
(time-zones etc.)
o typically, however, we often see that the maximum concurrent users is approximately
40% of the total ‘named’ users
o e.g. if had 100 ‘named’ users, then at most we could expect to see 40 users actively
using the system at any one time
• It is important to re-emphasise that all servers should be dedicated for Controller-only use
o This is to give the Controller system maximum performance/flexibility
The idea of these examples is simply to give a sensible (i.e. ballpark) suggestion for similar
customers. The starting suggestion can then be used as a basis of discussion with the customer
and their IBM Cognos Technical consultant.
Proprietary Information
Architecture and Server Sizing
10
SUGGESTED SERVER SPECIFICATIONS
For the sake of simplicity, the server has been split into two separate types:
• Typically, each individual “application” and Citrix server, would run on the same server
hardware power
• However, the Database (e.g. Microsoft SQL) server would often be different (typically more
powerful).
SERVER TYPE (1) APPLICATION/CITRIX/TERMINAL SERVER SPECIFICATION
At the time the document was created (April 2008) most customers would typically purchase
multiple servers, each based on the following specification:
TIP:
Older generations of servers were based on Intel Xeon CPUs, which were single-core, but with
HyperThreading
o HyperThreading makes it “appear” that there are two CPUs in each physical chip
o *However* HyperThreading is known to give poor performance (and stability problems)
with applications that give very high CPU load (such as Controller) therefore we have
always recommending disabling HyperThreading if using older Intel Xeon
chips
However, fairly recently both Intel and AMD have moved their CPU technology to dual-core
(and now quad-core!) technology
o Although no official tests have been performed, feedback from customers suggests that
dual-core CPUs (e.g. modern AMD and new Intel chips) can significantly outperform the
older Intel Xeon chips.
o Therefore, we 100% recommend that customers use the latest/fastest multicore chips on the market when they come to purchase new Controller servers
WARNING:
When reading this document, whenever the author recommends number of chips, I shall
generally refer to the number of separate “physical” chips
o e.g. we typically recommend a server containing 2 x separate physical CPUs (separate
chips)
since each of these are ‘dual-core’ chips/CPUs, this will give you a server with 4
separate cores
o Please do *not* assume that 1x quad-core CPU will perform as fast as 2x
dual-core CPUs !
Proprietary Information
Architecture and Server Sizing
11
SERVER TYPE (2) DATABASE SERVER SPECIFICATIONS
Typically, the only server which has a different recommended specification (from the above) is the
database server. This is because (inside a Controller server environment) often found the
database server which is single server and under the most load.
Typical general settings for Microsoft SQL database server
• Version
o For most customers, SQL 2000/2005 standard edition is sufficient for their needs
o For some advanced customers, enterprise editions may be useful/necessary.
• Patch level
o Recommend latest Microsoft patches, e.g. SQL 2000 SP4 and SQL 2005 SP2
• Operating system
o Any Microsoft-supported operating system, e.g. Windows 2000 or 2003 server
• Storage space
o Each Controller database will typically be approx 1Gb -> 10Gb
o Allowing for several databases (“live”, “test”, “training” etc.), plus “room to breath”
this suggests you should have a total of at least 144Gb storage
Drive configuration
o Some customers prefer a single RAID5 array
o However, the author suggests that ideally 3x RAID1 (144Gb+ each array) would be
faster/more flexible
[One array for each of “system/tempdb”, “data” and “transaction logs”]
o For optimal speed, ensure that each hard drive spins at 15k rpm (not cheaper 10k
rpm drives)
Proprietary Information
Architecture and Server Sizing
12
Typical CPU power and RAM for Microsoft SQL database server:
TIP:
Typically, memory is less of a performance bottleneck than CPU on the database server.
o However, if a customer is intending to host a large Controller system, we recommend
using the “Advanced/Enterprise” Microsoft software versions (which allow more
memory usage)
1
For small Controller systems, with limited reporting functionality:
o The SQL/database server should be based on dual-CPU (dual-core) => 4 cores in
total
o 4Gb RAM
For medium1 Controller systems, or smaller systems which have advanced reporting
functionality2:
o the SQL/database server should be based on quad-CPU (dual-CPU) => 8 cores in
total
o it may also be useful to have more RAM, therefore it would require Windows 200x
Enterprise Edition, and SQL 200x Enterprise edition
o 4Gb RAM for ‘standard’ editions, and more (e.g. 16Gb) RAM for ‘enterprise’ editions.
For larger3 Controller systems
o the database server would typically need to be based on 4/8-CPU, multi-core
CPUs, with Windows 200x Enterprise Edition, and SQL 200x Enterprise editions.
o Typically 16Gb RAM.
e.g. between approx 50 concurrent users and 100 concurrent users
2
e.g. multiple concurrent users using Controller reports to perform budgeting, which often means that 12+ periods of data are used
(instead of ‘typical’ reports with 1-3 months of data are used) in each report, causing high SQL CPU% usage
3
e.g. 100+ concurrent users
Proprietary Information
Architecture and Server Sizing
13
Oracle 9i or 10G database server
See below support link for the latest information:
https://support.cognos.com/en/support/products/controller83softwareenvironments.html
Software:
• Version
o Oracle 9i release 2 or 10G release 2
• Patch level
o There are some *minimum* patch levels that are 100% required – see website for
more details
o In addition, customer feedback means IBM Cognos Support UK also recommends latest
Oracle patches also
o The application server’s Oracle client needs similar Oracle patches too
TIP: See author’s separate document “07. Proven Practice - Step-by-Step guide to installing
Oracle 10G Client on a Controller 8.3 Application server.pdf” for full details.
Operating system
o Any Oracle-supported operating system, except:
Microsoft Windows is preferred (‘actively supported’)
UNIX is only ‘compatible’
LINUX is untested – to be used only at customer’s own risk
Hardware:
Since Oracle can be based on non-Windows (e.g. UNIX) operating systems, it is not
restricted to Intel/AMD chips
o Therefore, its hardware specification will typically need to be converted from Intelbased CPU specs, to UNIX specs (e.g. RISC CPU’s etc.)
Again, for larger number of concurrent users, ensure that the Oracle server is based on
higher spec hardware
o For example, modify the number of CPUs in a similar was as the SQL server
recommendations
Proprietary Information
Architecture and Server Sizing
14
ADDITIONAL NOTES:
•
Ideally you should be using gigabit network connections (as opposed to the minimum
requirement of 100Mb Full Duplex) between the Application server(s) and database (SQL)
server4
4
Especially for a very large system, where we have seen certain actions twice as fast using ‘gigabit’ instead of 100Mb.
Proprietary Information
Architecture and Server Sizing
15
IMPORTANT: The following examples are purely for illustrative purposes. They are generally
based on ‘standard’ implementations. It is possible that customer-specific needs require higherperformance servers for smaller-numbers of concurrent users.
For example, some customers may have 30 concurrent users but require 3 (or more!) separate
servers (Example 3) because they have advanced functionality needs, and require top
performance.
Please use the following guide *only* as a basis for your discussions, not as absolute
recommendations.
EXAMPLE #1 – UP TO APPROX 15 CONCURRENT USERS
For some customers, with very modest requirements (for example a test or demo system), it
may be possible to combine all the Controller 8 architecture on a single server.
However:
•
IBM *thoroughly* recommends that *as a best practice* you should have a separate
Application and SQL server (2 servers) as a bare minimum.
•
If customers choose to have a single all-in-one server, they must be prepared to add an
extra server (i.e. new database server, to create the same architecture as example #2) at a
later stage, should they find that they require the extra power
EXAMPLE #2 – UP TO APPROX 40 CONCURRENT USERS
In this scenario it is assumed that there is ‘standard’ usage of Controller (e.g. non-complex
consolidation requirements) for a limited number of end users.
Therefore, all Controller server components can be installed on a single “application” server:
Proprietary Information
Architecture and Server Sizing
16
EXAMPLE #3 – TYPICALLY UP TO APPROX 75 CONCURRENT USERS
In this scenario, there is too much workload for a single server to run all the Controller ‘application’
services. Therefore, we shall use two separate physical servers for our application layer.
The most resource-intensive tasks are running Reports and Consolidations. Therefore, we shall
split one of these roles off. Different customers may have different priorities – some may run many
consolidations, whilst others may have more of a reporting requirement.
In the example below, we have decided that the customer’s reporting requirement is more
intensive (than their consolidation requirement), so we have separated the IBM Cognos 8 BI ‘runtime’ reporting system onto a separate server:
However, in a different customer’s case, it may be a better idea to have a separate (new)
consolidating application server (and keep the reporting) services on the first shared web/app
server.
Proprietary Information
Architecture and Server Sizing
17
EXAMPLE #4 – TYPICALLY 75 TO 150 CONCURRENT USERS
In order to support the anticipated load of up to 150 ‘standard’ users it is necessary to install both
a separate IBM Cognos 8 reporting server and consolidation server:
Proprietary Information
Architecture and Server Sizing
18
EXAMPLE #5 – LARGE IMPLEMENTATIONS - 150+ CONCURRENT USERS
Large implementations of Controller 8.x will benefit from the distribution of the consolidation
functions of Controller to a separate server. This reduces CPU and I/O conflicts for Web Service
and Reporting users during consolidation tasks. Large IBM Cognos 8 implementations can also be
deployed in a fully redundant topology. Please refer to the IBM Cognos 8 Planning and
Architecture Guide for more information regarding the advanced deployment options for IBM
Cognos 8.
Proprietary Information
Architecture and Server Sizing
19
CLIENT PC HARDWARE/SOFTWARE REQUIREMENTS/RECOMMENDATIONS
SOFTWARE REQUIREMENTS:
•
Windows XP Pro SP1 or SP2 (recommended) or Windows 2000 Pro SP4
•
Office XP, 2003 or 2007
•
Adobe Acrobat Reader (v8 recommended)
•
Internet Explorer 6.0+(IE 7 recommended)
•
MDAC 2.8+
•
.NET Framework 2.0 SP1
HARDWARE RECOMMENDATIONS:
At the time of writing5, there is no official document for the client PC specifications. Instead, IBM
Cognos UK consulting/support experience gives the following guidelines:
CPU
RAM
minimum
P3 @ 1000MHz
256Mb
recommended
P4 @ 2GHz+
512Mb+
ideal
P4 @ 3GHz+
1Gb+
NOTE: Although it is possible to run Controller 8 using the “minimum” specifications, unless there
are exceptional circumstances all customers should use at least the recommended hardware
specifications for their client PCs.
5
July 2006
Proprietary Information
Architecture and Server Sizing
20
Appendix #1 – Microsoft SQL server recommendations
If you intend to use an existing Microsoft SQL server, please check server’s default
collation settings
Controller can work with almost6 any server collation setting. However, you cannot transfer a
database from one SQL 2000 server (to a different SQL server) if they have different server
default collation settings.
IBM’s standard is to use SQL_Latin1_General_CP1_CI_AS. If customer’s databases are based on
this, then it makes our consultancy and support as efficient as possible, thus giving the
customer the best service.
Therefore, you should make every attempt to ensure that your SQL 2000 server has the IBM
‘preferred’ collation setting of SQL_Latin1_General_CP1_CI_AS (also known as “dictionary
order, case-insensitive, for use with 1252 Character Set”):.
You can check this through SQL Enterprise Manager (right-click on server, and click
“properties”) – see below:
Incidentally, although SQL_Latin1_General_CP1_CI_AS is the most popular collation setting, the
second most popular is “Latin1_General_CI_AS”. This works fine, and would not present any
problems if a customer chose to use it. However, ideally, we recommend
SQL_Latin1_General_CP1_CI_AS, to give the customer maximum flexibility for their future
requirements.
6
No testing has been performed with collation settings which have “uppercase preference” (e.g.
SQL_Latin1_General_Pref_CP1_CI_AS). We do not recommend using "uppercase preference" because it can potentially cause errors
with alphanumeric keys and has never been tested.
Proprietary Information
Architecture and Server Sizing
21
Appendix #2 – Database size
As mentioned previously, the size of the database varies enormously between customers (e.g.
typically between 1 Gb -> 10Gb7). It is not generally related to how large the customer is, or how
many users, instead it is how much level of detail that the customer wants to store inside their
Controller system.
In addition, one example (see KB 1020388) of why a database might grow quite a lot is if the
customer chooses to lock the period by multi-period locking. In this scenario, the “period locks by
company” should be periodically deleted to reduce the size of the database.
7
Although the largest database that the author has seen is ~20Gb
Proprietary Information
Architecture and Server Sizing
22
Appendix #3 – Deploying Controller 8 via Citrix (or Microsoft Terminal) server(s)
IBM supports Controller v8, when deployed via Citrix and/or Microsoft Terminal
Services
The bandwidth requirement (client application server) for Controller v8 is approximately
256kbps, for “standard” usage of Controller.
NOTE:
• this (256kbps) is not an ‘absolute’ / ‘fixed’ value
• there will be performance benefits if you have a larger available bandwidth (e.g.
512kbps)
• however, from the tests that we have run, there is not a huge difference between
256kbps and 512kbps
o i.e. it’s not twice as fast when running with twice the available bandwidth!)
o instead, depending on what you are doing, you may see a 20% performance
increase with twice the bandwidth
• more complex tasks (in Controller) would certainly benefit from there being bandwidth
available >256kbps
Also, it is not just bandwidth size that is important – network latency is just as important. There
should be a quick (e.g. <80ms) round-trip (“ping”) network latency between client and server, for
best performance.
Even though remote network links (a.k.a. “WAN” links) are getting faster and cheaper every year,
many customers will want to try to make as efficient use of their remote network as possible. Since
Citrix gives extremely good (e.g. 10x) network bandwidth savings (over the traditional clientserver
deployment of Controller 8), they may choose to deploy via Citrix (or its ‘little-brother’ – Microsoft
Terminal Services).
In this case, the recommendation is to use Citrix/Terminal services of the same specification as the
main IBM Cognos 8 application server(s).
i.e.
Tests completed suggest that each Citrix/Terminal server could host approximately 15 to 20
concurrent Controller 8 users (depending on what functions they perform inside the application).
Proprietary Information
Architecture and Server Sizing
Proprietary Information
23