Bloomreach Experience Manager Load Balancing Requirements

Server affinity required for running Bloomreach Experience Manager behind a load balancer

Running Bloomreach Experience Manager behind a load balancer requires server affinity to be configured in the load balancer.

Bloomreach Experience Manager supports two different load balancer server affinity strategies:

Source IP affinity

With this strategy the load balancer directs all client traffic from a specific source IP to the same backend server.
This is a robust solution, but has the disadvantage that the traffic can be unevenly distributed when a large group of users are accessing the CMS from behind a shared NAT.
For example from within a corporate network all users then might end up being served by a single backend server.

Injecting a dedicated server affinity cookie

With this strategy the load balancer injects a dedicated cookie which keeps track of the server affinity.
It is important to use a separate cookie and not (re)use the session cookies set by the application.

This is the recommended strategy.

As an illustration how to configure this, the following HAProxy backend configuration fragment will inject a SERVERID cookie to track the server affinity:

backend hippo 
  balance roundrobin
  cookie SERVERID insert nocache httponly maxidle 1h
  server node1 10.10.10.1:8080 check cookie node1
  server node2 10.10.10.2:8080 check cookie node2

No longer supported: session cookie prefixing

Previous versions of Bloomreach Experience Manager also supported application session based strategies, like session cookie prefixing, often in combination with (needed) setting the hippo.cluster.sso.key environment parameter.
This is no longer supported as of Bloomreach Experience Manager 7.9.15, 10.2.3 and 11.0 (GA).

Technical background

The CMS Channel Manager provides preview access to and management for the Delivery Tier (the site applications).

To be able to do so it now is required that both the CMS and Site web application(s) are hosted on the same appllication server (Tomcat) and that the client access is coordinated to be server from the same backend application server.

In previous versions the CMS and Site application used a secret-based SSO handshake to validate and ensure this communication, and even allowed for so called skewed coordination across multiple application servers through the use of a shared hippo.cluster.sso.key environment parameter.

For both functional and technical reasons skewed application coordination across multiple application servers no longer is possible as of Bloomreach Experience Manager 7.9.15, 10.2.3 and 11.0 (GA), and the secret-based SSO handshake no longer used nor needed.