Jira Data Center Load Balancer examples

Load Balancing Stickiness Strategies

Jira requires sticky HTTP sessions. Using a cookie strategy approach for this will give you more control over user IP changes that occur due to network or VPN configuration.
At minimum, you want the user to become sticky to a server during a browser session. To get the best distribution/stickiness ratio, use a session cookie lifetime with absent expire or expire = -1. 

The following examples demonstrate session stickiness strategies using cookies with Apache 2.2.24 with mod_proxy_balancer, which is similar to other load balancer solutions. In the examples we use HTTP in backends, but the same applies for AJP connectors. 

1) Specific load balancing cookie

This is the less intrusive approach where your load balancer creates a specific cookie to route all the requests from the same session to the same backend server.
In this example, we will instruct Apache to create a cookie called ROUTEID, and use it for stickysession.

mod_proxy_balancer with specific cookie

Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED

<Proxy balancer://jira-cluster>

    BalancerMember http://backend1:8090 route=perftest1

    BalancerMember http://backend2:8090 route=perftest2

</Proxy>

ProxyPass / balancer://jira-cluster/ stickysession=ROUTEID

2) Tomcat JSESSIONID cookie

Tomcat supports routing information in the JSESSIONID cookie when you start with -DjvmRoute=<nodeName> parameter. This information is also used by Apache.

mod_proxy_balancer with JSESSIONID cookie

<Proxy balancer://jira-cluster>
    BalancerMember http://backend1:8090 route=perftest1
    BalancerMember http://backend2:8090 route=perftest2
</Proxy>
ProxyPass / balancer://jira-cluster/ stickysession=JSESSIONID

When a user accesses Jira, these cookies are created:

Note that the route information is added as a suffix on JSESSIONID value

2b) Example from HA Proxy*

The following example shows how the load balancer, not Tomcat, will change the JSESSIONID cookie to provide stickiness. HAProxy adds a prefix when sending the cookie to the user browser, and removes the prefix when routing to the backend server. With this approach, there is no need to add the jvmRoute parameter in Tomcat.

HAProxy cookie prefix configuration

frontend ft_web
  bind 0.0.0.0:80
  default_backend bk_web
  
backend bk_web
  balance roundrobin
  cookie JSESSIONID prefix nocache
  server s1 backend1:8090 check cookie s1
  server s2 backend2:8090 check cookie s2

When a user accesses Jira, these cookies are created:

Note that the route information is added as a prefix on JSESSIONID value

Load Balancing Health Check URL

Usually load balancers require a URL to constantly check the health of their backends in order to automatically remove them from the pool. It's important to use a stable and fast URL for this, but lightweight enough to not consume unnecessary resources.
Jira exposes a URL that returns the system status that can be used for this. 

{"state":"RUNNING"}

User experience when one node fails

If a node fails, the impact on a user depends on the size of the time interval your load balancer check, if the backend server is up.

If the check interval is one minute, and the user is sticky to the server that eventually goes down, they will get error messages until the load balancer removes the node from the pool and assigns a new one to the user. When a user session is moved from one server to another, all session information is lost, including login credentials. Unless 'Remember me' is selected, users will have to log in again (see Jira Cookies). There's only a handful of functions that rely on session data, and these are mostly multi-step wizards like bulk update and project import.