IBM Support

How to configure Controller 10.2.713 (or later) to have multiple application servers to provide Load Balancing (and Higher Availability) for the WSS portion of the Controller server architecture

Technote (troubleshooting)


Customer would like to have multiple Controller application servers working together to provide load balancing (for the WSS portion of the Controller server architecture).
* In other words, the work of the Controller server system is shared between two (or more) physically separate Windows servers.

How can they achieve this (with Controller 10.2 or later)?


There are many different individual components that comprise the Controller server system.

  • TIP: For more details, see separate IBM Technote #1364071.

This Technote *only* relates to the portion of the Controller architecture known as WSS (the Controller 'Web Services Server').

  • For the avoidance of doubt, the technique explained inside this document does not provide high availability for the Controller Web (WebSphere) component, which was introduced from Controller 10.3 onwards.


Some of the Controller application server architecture changed between versions 10.1.1 and 10.2.

  • Specifically, from version 10.2 onwards, the relevant portions of the system have been moved from COM+ to native .NET.
  • This means that the COM+ splitting techniques (used in Controller 10.1.1 and earlier) cannot be used for Controller 10.2 or later.
    This architecture change allows customers to benefit from better scalability via 'scaling up'.
    • In other words, from Controller 10.2 onwards, if you add more hardware (especially CPU cores, but also RAM) to a single Controller application server, then it has a better ability to utilise this improved hardware (compared with Controller 10.1.1 or earlier).

    Having said this, some customers may also want to scale out.
    • This is defined as adding more separate Controller application servers (e.g. having two in total) and spreading the load between these separate servers
    • This is the topic that is covered in this Technote.
  • Environment

    Customer wishes to have a design where they utilise multiple different Controller application servers, where some users use server #1 and others use server #2.

    • This is shown in the diagram below:
    • One application server acts as a 'Master'
      • This server hosts the active 'User Manager' portion of the system
    • The customer can have several (for example 1 or 2) other separate servers acting as 'Slaves'
      • Each of these utilises the User Manager which runs on the 'master' server

    Controller 10.2.713 (and later) allows this configuration, by utilising the parameter ' ccrRemoteServer' on each of the slave servers.
    • NOTE: The functionality does not work on early versions of Controller (for example 10.2.0 RTM = 10.2.705).

    Resolving the problem

    Use the new variable 'ccrRemoteServer' on all 'slave' Controller application servers.

    Steps for the application servers:
    1. Install the main 'Master' Controller application server, as normal.

    2. Before proceeding, test this master server (by running the Controller client)

    • In other words, make sure that the system works OK (using the master application server only, using the standard one-server configuration).

    3. Install the Controller server components on the 'slave' application server.

    • You must install/configure all the server pre-requisites (before installing Controller server), in the same way as you did for the 'master' application server.
    • The Controller server version (installed on the slave application server) must be exactly the same as the Master server's version
    • During the Controller server software installation wizard, there is no need to choose/select/install all of the components
      • As an example, there is no need to select/install the BI components on this 'slave' server
      • However, if you choose to install all optional components, this is not a problem - however, we shall typically leave those components (e.g. BI/FAP components) unconfigured, because typically the slave server is not intended to run these features.

    4. After Controller has been installed, launch Controller Configuration (on the slave server) and configure it to have the exact same settings as the 'master' server.

    Most importantly:
    • Inside 'Database Connections', all the settings ("UDL files") must exactly match
    • Inside 'Report Server', make sure that the 'Report Server' and 'Dispatcher URI' are configured to point to the same settings as used on the 'master' server
      • In most customer environments, this means that the 'slave' application server's 'Report Server' and 'Dispatcher URI' settings are configured to point to the 'master' Controller application server.

    5. On the Slave server:
    • Browse to the 'ControllerProxyServer' folder (by default, this is located here: C:\Program Files\ibm\cognos\ccr_64\ControllerProxyServer)
    • Open the file 'web.config' inside Notepad.exe
    • Locate the section '<appSettings>'
    • Add the following entry, inside that section:

    Naturally, modify the value 'MASTERSERVER' with the name of your 'master' application server.

    6. Save changes
    7. Repeat steps 3-6 for each different slave server in your environment
    8. Reboot all servers
    9. Test.

    Steps for the client PCs :
    1. Divide your users, so that some use the 'master' server, and some use the 'slave' servers
    • For example, if you have 2 servers (one master, one slave) then typically you would allocate half of your users to the 'master' and the other half to the 'slave' server

    2. Install the Controller client onto each end user's PC
    • For instructions, see separate IBM Technote #1965917.

    During the installation, configure some (for example half of your) users to connect to the ' master' server...

    ...and the other (the other half of your) users to connect to the 'slave' server(s):

    More Information:
    This load-balancing solution does not provide automatic redundancy (failover) capabilities.
    • For example, if the 'slave' server fails, then all the end users (who are currently connected to the slave server) will lose their Controller sessions, and not be able to connect again.

    In the scenario where a slave server fails, then the solution would be to manually reconfigure each of those ' slave' end user's client devices to point to the master slave instead.
    • Specifically, they need to perform the following on each end user's PC (who is currently configured to utilise a 'bad/failed' slave server):

    Related information

    1364071 - High Availability and fault tolerance options
    1697710 - "The value may not be accessed in message sta
    1965917 - How to install the Controller local client
    Controller 10.2.1 - Load balancing with multiple IBM Co

    Document information

    More support for: Cognos Controller

    Software version: 10.2.0, 10.2.1, 10.3

    Operating system(s): Windows

    Reference #: 1677206

    Modified date: 12 June 2017

    Translate this page: