In the previous post, I told you about the setup of making high-available cluster for Jira. In this post I will continue the same thing and tell you how to configure GlusterFS & HeartBeat to make that setup happen.

How it works

So we start with installing GlusterFS first. GlusterFs is a clustered File system which can be used for scaling the storage capacity by having distributed volumes or we can just use GlusterFS for providing high availability of storage using replicated volumes feature. In this we use multiple servers to maintain a replicated view of the main storage, so in case any one of them is down the other storage sever/node can be used.

So for our use case we would use the replicated volume to store JIRA_HOME directory and the tomcat application, which would imply that all the data is always present on more than one server at any given instance.

Before we can create replicated volumes, we should have GlusterFS server and the client which would be used by Jira to access GlusterFS setup on both the servers. In this setup we would use two servers of same configurations (memory,cpu), so that each of them can be used interchangebly as the master in case the original master crashes.

GlusterFS setup

1. Install GlusterFS on both the servers. Download latest debian package from http://www.gluster.org/download/ and run following commands:

   sudo apt-get install openssh-server wget nfs-common
   sudo dpkg -i glusterfs-3.2.0.deb

2. Install Gluster Native Client, because it provides high concurrency, performance and transparent failover compared to NFS or CIFS clients. For this we should have the fuse-utils packages installed

   sudo apt-get install fuse-utils

Continue reading →

JIRA is a great tool for Scrum/Kanban and it can actually be used as a tracking tool for any set of activities which have a defined workflow. Over a period of last 2-3 years atlassian has introduced lot of new features, latest been Rapid Board, Workflow designer and many more which are worth exploring for anyone who is looking for Ticketing/Bug-tracking/Project-managing tool. In this blog I would only be talking about one specific problem related to deployment and high-availability of JIRA as a service and how I solved it.

Problem

For one of my clients, I did the migration of their old JIRA 3.13 installation to JIRA 4.3.2 and during that period I investigated options of doing clustering of JIRA so as to provide high-availablity and scalability. And this is one thing really annoying thing about JIRA that they don’t provide any options for clustering of JIRA at both application level or Operating system level. So you can’t have a setup in which JIRA is installed on two servers and have a load balancer forward the request based on work load.

So only option for scalability is to scale vertically, but for high-availablity I tried some tricks using GlusterFS & HeartBeat, which allows me now to have a passive node on which I can start JIRA automatically when the active JIRA node goes down.

Solution

The trick was to use GlusterFS as a filesystem to provide data replication between two servers, so that all the attachments and other  application data is always replicated in real time on two physical servers.This approach is better then taking daily or hourly backup and using that data in case the server goes down and starting a new server with that data, because that would mean a downtime of atleast few hours and might also involve some data loss.

Continue reading →