Load-Balancing / Session Affinity / Sticky Sessions

Load-Balancing / Session Affinity / Sticky Sessions

If the jadice web viewer is distributed across multiple instances due to expected load (see Sizing and Configuration of the jadice web toolkit at Commissioning), the load balancer distributing requests to the jadice web viewer instances should be configured to ensure that a user's requests always land on the same instance (Session Affinity).

This architecture may no longer seem modern in a world of REST services, but it is the most performant setup. Fundamentally, the jadice web viewer would also function without Session Affinity, as a tile request contains all the information a server needs to render a tile. However, this setup would trigger a recovery on every server. As a result, in the worst case, the corresponding document would redundantly exist in every cache of all servers.

This chapter provides an example of how to achieve software load balancing with Session Affinity using HAProxy.

Sticky Sessions via JSESSIONID Cookie

If the integration uses the Http-Session (part of the Java EE specification), e.g., request.getSession(), the JSESSIONID cookie is set on the client. This can be used by HAProxy to route a user consistently to the same server.

defaults
  mode http
  log global
  option httplog
  option http-server-close
  option dontlognull
  retries 3
  timeout client          25s
  timeout connect          5s
  timeout server          25s
  timeout tunnel        3600s
  timeout http-keep-alive  1s
  timeout http-request    15s
  timeout queue           30s
  timeout tarpit          60s
  default-server inter 3s rise 2 fall 3
  option forwardfor

frontend jwt_web
  bind *:8000
  mode http
  default_backend jwt_back

backend jwt_back
  option httpchk HEAD /enterprise/
  balance roundrobin
  cookie JSESSIONID prefix nocache
  server websrv1 192.168.0.2:8080 check cookie s1
  server websrv2 192.168.0.3:8080 check cookie s2

Sticky Sessions with a Custom Cookie

If the application does not use an Http-Session, there may be no existing cookie to uniquely identify the client. In this case, HAProxy can generate and manage its own cookie (in this example, the cookie name is SERVERID).

defaults
  mode http
  log global
  option httplog
  option http-server-close
  option dontlognull
  retries 3
  timeout client          25s
  timeout connect          5s
  timeout server          25s
  timeout tunnel        3600s
  timeout http-keep-alive  1s
  timeout http-request    15s
  timeout queue           30s
  timeout tarpit          60s
  default-server inter 3s rise 2 fall 3
  option forwardfor

frontend jwt_web
  bind *:8000
  mode http
  default_backend jwt_back

backend jwt_back
  option httpchk HEAD /enterprise/
  balance roundrobin
  cookie SERVERID insert indirect nocache
  server websrv1 192.168.0.2:8080 check cookie s1
  server websrv2 192.168.0.3:8080 check cookie s2