nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Can we run JIRA on multiple application servers?

dannhowa

Can we run JIRA on multiple application servers? It seems that one should be able to point multiple application servers at the same database system, then set up a load balancer with some session affinity. Has anyone done this? Right now we have a warm standby server, but given that JIRA is central to our operations, I'd like to remove a SPOF.

Accepted answers

Remon van G

Atlassian themselves are staying a bit away from this. See also this remark ont he roadmap. The issue seems to be that Jira does a lot of internal caching and this does not really work in al DB clustering solutions. (https://jira.atlassian.com/browse/CONF-19528)

But there are third parties who have setup sets and solutions in the past. Like the below.

WANdisco has solved this with JIRA Multisite (http://www.wandisco.com/jira)and JIRA Clustering (http://www.wandisco.com/jiraclustering)

"JIRA Clustering and JIRA MultiSite applies WANdisco's active-active replication technology to bring enterprise class scalability and reliability to JIRA's flexible and easy to use bug tracking, issue tracking, and project management solution. With JIRA Clustering, a central JIRA server is no longer a performance bottleneck.

Features:

* Provides clustering over a LAN to dynamically balance workload across multiple JIRA servers at a single location.
* Provides clustering over a WAN to dynamically balance workload across JIRA servers at multiple locations.
* Has no single point of failure whatsoever. JIRA Clustering's approach is truly shared nothing. There is no sharing of disk, CPU, or memory between servers with JIRA Clustering.
* Does not rely on a single shared database. Each server in the cluster has its own independent database replica that is kept in sync with all of the others by WANdisco's active-active replication technology.
* Provides failover and automated disaster recovery over a WAN or a LAN to insure business continuity, without any reliance on third party disk mirroring solutions.
* Can be implemented standalone or in conjunction with WANdisco's clustering solutions for Subversion and CVS to provide a complete, highly reliable and scalable application lifecycle management solution stack."

Solutions with Terracotta were also discussed in the past. Lead: http://blogs.reucon.com/srt/2007/11/07/clustering_jira_with_terracotta_dso.html<br< a=""> />

All comments

Remon van G

But there are third parties who have setup sets and solutions in the past. Like the below.

Solutions with Terracotta were also discussed in the past. Lead: http://blogs.reucon.com/srt/2007/11/07/clustering_jira_with_terracotta_dso.html<br< a=""> />

dannhowa

Those wandisco links shunt off to a splash page for ubersvn.com. It looks like the best thing to do today is register to vote for

dannhowa

Ugh. One link per comment? ... "register and vote for https://jira.atlassian.com/browse/CONF-19528 "

Beth Schaeferma

I, too, am highly interested in this topic. Here is what I have found so far:

(1) JIRA Clustering issue logged and conversation spanning the past seven years: https://jira.atlassian.com/browse/JRA-7330; In my opinion, it should be re-opened.

My current understanding is that out of the potential solutions available, they are all for older versions of JIRA and/ or dead:

(a) Sourcesense's Scarlet/ Teracotta - http://www.sourcesense.com/en/events/scarlet.html

(b) WANdisco - http://blogs.atlassian.com/2007/11/introducing_wan/,

http://confluence.atlassian.com/display/JIRA040/Deploying+JIRA+in+a+clustered+environment

http://confluence.atlassian.com/display/JIRA/Is+Clustering+or+Load+Balancing+JIRA+Possible

I hear that they worked for JIRA 3.1 but somewhere between then and now, this solution has dissolved/ disappeared. The demand/ need for a long term, reliable solution, though, has not gone away.

What happened here? Note: Atlassian needs to update their documentation in terms of recommended solutions.

(2) Commentary on what Enterprise users want from the Enterprise service: https://answers.atlassian.com/questions/38696/is-it-just-me-who-has-a-shocking-price-rise-for-jira-5?page=1#42511

Beth Schaeferma

More detail on an understanding of how to address the question: "How do we scale?":

There are three caching issues to address within JIRA:
1. caching JIRA data stored in the DB
2. caching JIRA's Lucene search indexes
3. caching attachments

1 & 2 are posited as the more critical problems from a performance and scalability perspective. For high availability and scalability, both types of caches need to be clusterable, which they are not OOTB. Infinispan offers a solution for both these needs.

Based on all publicly available information on Scarlet, it's readily possible to replace JIRA's OOTB cache implementation with Infinispan (since both are based on ConcurrentHashMap). This provides access to an extensible data grid.

Infinispan has also been provien as a distributed directory solution for Lucene: https://community.jboss.org/wiki/InfinispanAsADirectoryForLucene