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



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?
NOTE: The functionality described in this Technote only works with Controller 10.2.713 (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.


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 'Primary'
    • If using Controller 10.3.1 (or earlier) then this server hosts the active 'User Manager' Windows service
    • If using Controller 10.4.0 (or later) then the Controller product no longer utilises a 'User Manager' Windows service. Instead, the user locking mechanism is stored inside the database.
  • The customer can have several (for example 1 or 2) other separate servers acting as 'Secondaries'
    • If using Controller 10.3.1 (or earlier) then each of these 'secondary' servers will utilise the User Manager which runs on the 'primary' server

Controller 10.2.713 (and later) allows this configuration, by utilising the parameter 'ccrRemoteServer' on each of the secondary servers.
  • NOTE: The functionality does not work on early versions of Controller (for example 10.2.0 RTM = 10.2.705).
Customer example:
In one real-life customer example (where their aim was to have as much redundancy built-into a Controller/CA system) the environment was as described below:
  • Controller 10.4.0
  • Two Controller application servers:
    • "WSS1" = Primary
    • "WSS2" = Secondary
  • Two CA (Cognos analytics) gateways:
    • "GW1"
    • "GW2"
  • Front-end Network Load Balancer ("NLB") configured to balance external client access to the gateways, using the following two rules:
    • VIP1 is directed to either GW1 or GW2, with separate rules based on number of active connections separately for port 9300 and 80
    • VIP2 is directed to either WSS1 or WSS2 on port 80 based on number of active connections
  • Cognos Configuration configured so that:
    • the Controller URL is set to VIP2
    • the gateway is set to the real DNS of each server, using the dispatcher version URL
      • However, in theory this could be to the VIP1 CA SSO URL
  • Controller Configuration configured so that:
    • Report Server settings: Using the VIP1 SSO gateway and dispatcher URLs
Testing (of that configuration above) proved that the architecture coped with all combinations of the following failure scenarios:
  • CA Gateways/Dispatchers:
    • Both available/working OK
    • One up (available), one down (problem)
  • Controller WSS servers:
    • Both servers up/OK
    • One up (available), one down (problem)
The above architecture achieves the following:
  • Cognos analytics (CA) deals with the content store redundancy
  • CA deals (to some extent) dispatcher allocation via gateway requests
  • The NLB/primary-secondary configuration solves the following two limitations of 'standard' Controller architecture:
    • Controller can only specify one dispatcher
    • Controller web can only specify one dispatcher.
NOTE: The system will not be fault-tolerant, because client affinity is also important on the NLB (to avoid dropped / confused packets)
  • In other words, there could drops when swapping.

Resolving The Problem

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

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

2. Before proceeding, test this primary server (by running the Controller client)
  • In other words, make sure that the system works OK (using the primary application server only, using the standard one-server configuration).

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

  • You must install/configure all the server pre-requisites (before installing Controller server), in the same way as you did for the 'primary' application server.
  • The Controller server version (installed on the secondary application server) must be exactly the same as the Primary 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 'secondary' 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 secondary server is not intended to run these features.

4. After Controller has been installed, launch Controller Configuration (on the secondary server) and configure it to have the exact same settings as the 'primary' 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 'primary' server
    • In most customer environments, this means that the 'secondary' application server's 'Report Server' and 'Dispatcher URI' settings are configured to point to the 'primary' Controller application server.

5. On the Secondary 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 'PRIMARYSERVER' with the name of your 'primary' application server.

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

Steps for the client PCs:
1. Divide your users, so that some use the 'primary' server, and some use the 'secondary' servers
  • For example, if you have 2 servers (one primary, one secondary) then typically you would allocate half of your users to the 'primary' and the other half to the 'secondary' 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 'primary' server...

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

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

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

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SS9S6B","label":"IBM Cognos Controller"},"Component":"Controller","Platform":[{"code":"PF033","label":"Windows"}],"Version":"10.4.1;10.4.0;10.3.1;10.3.0;10.2.1;10.2.0","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
22 July 2020