Can we run JIRA on multiple application servers?

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.

3 answers

1 accepted

1 vote
Accepted answer

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=""> />

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

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

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

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

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Feb 13, 2019 in Jira

Make your Atlassian Cloud products more secure: our NEW admin security guide

Hey admins! I’m Dave, Principal Product Manager here at Atlassian working on our cloud platform and security products. Cloud security is a moving target. As you adopt more products, employees consta...

514 views 0 12
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you