Configuring Load Balancing

This section describes how to configure ActivID CMS to work in a load-balancing environment.

About Load Balancing and Managing Server Pools

Load balancing requires peer servers, which are used to distribute (balance) the usage loads of the ActivID CMS servers. These multiple instances of servers (ActivID CMS Peer Servers) are referred to as a server pool. You can use a Web browser to connect your workstation to any of the servers in the pool.

Prerequisites

  • The SSL credentials (server, client and issuing CA certificate) must be the same for all ActivID CMS instances.

  • Before you can add peer servers to the server pool, you must install ActivID CMS on each peer server.

For more information, see Set Up the Server Pool and Add Servers to the Pool.

The configuration examples in this section use the following conventions:

  • Unique server name, such as “CMSPool” (used by each Operator Portal to connect to the ActivID CMS server pool, transparently through the load balancer).

  • Server S1, IP Address 200.0.0.1

  • Server S2, IP Address 200.0.0.2

  • Server S3, IP Address 200.0.0.3

  • Server Sn, IP Address 200.0.0.n, where n is the instance number

Warning! Load balancers need to support "sticky sessions" to be supported with ActivID CMS. The ActivID CMS session cookie is named CMS_SESSIDENT.

Rules for Issuance of Mobile App Certificates

When peer servers are used in conjunction with a load balancer, specific routing rules must be set for the Over-The-Air (OTA) and Simple Certificate Enrollment Protocol (SCEP) traffic that are used by mobile phones during mobile app certificate issuance.

Each peer server is referenced by its instance number (see Set Up the Server Pool). That instance number is part of the OTA and SCEP URIs.

The load balancer must be provided with each instance number and configured to route accordingly to the corresponding peer server, without “sticky sessions”. OTA and SCEP do not use extra cookies or URI parameters outside of those expected by the protocols. The routes have to be baked into the URIs. The individual peer servers expect the complete URI and request content to be transmitted with their query parameters without any alteration (the load balancer may still alter some headers if necessary).

The OTA URI pattern is /aims/mobile/n/action where n is the peer server instance number, and action is either profile or profileUpdate.

The SCEP URI pattern is /aims/scep/n where n is the peer server instance number.

For example, /aims/mobile/3/action and /aims/scep/3 must be routed to the peer server instance number 3.

Note: The /aims/mobile/enroll URI is the first one queried by the mobile phone at the start of mobile app certificate issuance. It does not contain any peer server instance number and may be routed to any peer server; however, the subsequent HTTP queries all contain a peer server instance number in their URIs and have to be routed as explained above.
Important: Auto-generated certificates must not be used for peer servers.

Topics in this section: