JIRA Data Center Load Balancer examples

We do not officially support any specific Load Balancers, but most commonly see customers using Apache or F5.

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

 

When a user accesses JIRA, these cookies are created:

Cookie Name
Cookie Value
Domain
Path
Expires
Created by
JESESSIONID DDFACF910F0F807930AE2A382956018F backend1 /jira/ Session Backend Tomcat
ROUTEID .perftest1 backend1 / Session Apache

 

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:

Cookie Name
Cookie Value
Domain
Path
Expires
Created by
JSESSIONID 9CA086750138E6FC6965D1A82E652E96.perftest1 backend1 /jira/ Session Backend Tomcat

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
*Example from Load balancing, affinity, persistence, sticky sessions: What you need to knowUsing application session cookie for persistence section.

 

When a user accesses JIRA, these cookies are created:

Cookie Name
Cookie Value
Domain
Path
Expires
Created by
JSESSIONID 9CA086750138E6FC6965D1A82E652E96 backend1 /jira/ Session Backend Tomcat
JSESSIONID s1~9CA086750138E6FC6965D1A82E652E96 backend1 /jira/ Session Updated by HAproxy

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. 

URL
Expected content
Expected HTTP Status
http://backend1/status
{"state":"RUNNING"}
200 OK

 

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.

Last modified on Aug 24, 2017

Was this helpful?

Yes
No
Provide feedback about this article

Not finding the help you need?

Ask the community

Powered by Confluence and Scroll Viewport.