Load-Balancing / Session Affinity / Sticky Sessions

Load-Balancing / Session Affinity / Sticky Sessions

Wenn das jadice web toolkit aufgrund der zu erwartenden Last (siehe hierzu Dimensionierung und Konfiguration des jadice web toolkit bei Inbetriebnahme) über mehrere Instanzen verteilt wird, sollte der Load-Balancer, der die Anfragen auf die jadice web toolkit Instanzen verteilt, so konfiguriert sein, dass Anfragen eines Benutzers stets auf derselben Instanz landen (Session Affinity).

Diese Architektur mag in einer Welt mit REST-Services nicht mehr modern wirken, es ist jedoch das performanteste Setup. Grundsätzlich würde das jadice web toolkit auch ohne Session Affinity funktionieren, denn ein Tile-Request enthält alle Informationen, die ein Server benötigt, um ein Tile zu rendern. Dieses Setup würde aber ein Recovery (siehe Wiederherstellung von Dokumenten) auf jedem Server auslösen. Als Ergebnis würde im schlechtesten Fall das entsprechende Dokument redundant in jedem Cache aller Server existieren.

Dieses Kapitel soll beispielhaft zeigen, wie per HAProxy ein Software-Load-Balancing mit Session Affinity erreicht werden kann.

Sticky Sessions per JSESSIONID-Cookie

Wenn die Integration die Http-Session (Teil der Java EE Spezifikation) verwendet, also z.B. request.getSession(), wird beim Client das JSESSIONID-Cookie gesetzt. Dieses kann von HAProxy verwendet werden, um einen Benutzer stets auf denselben Server zu leiten.

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 mit eigenem Cookie

Wenn die Anwendung keine Http-Session verwendet, existiert möglicherweise kein Cookie, um den Client eindeutig zu identifizieren. In diesem Fall kann HAProxy ein eigenes Cookie erzeugen und verwalten (in dem Beispiel ist der Name des Cookie 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