Installing Jira Data Center

These instructions are applicable for installing Jira Software Data Center or Jira Service Desk Data Center on your own hardware. You can also install Data Center in Amazon Web Services.

Before you begin

Before you install Jira Data Center, you need to answer a few questions.

What is Jira Data Center?

Tell me more...

You should first understand what Jira Data Center is, and how it works. We've gathered some resources that will help you get to know the high-level overview of Data Center, and its architecture.

Take a look at Jira Data Center.

How do I get it?
Tell me more...

You'll need two things to get started – an installer, and a license.

If you're installing Jira from scratch, you'll first need to apply the evaluation license so make sure you create it.

What are the prerequisites?

Tell me more...

Supported platforms

Supported operating systems, databases, etc., are the same as for the Server installation, and you can see them here: Supported platforms.

Node requirements

Requirements specific to Data Center include requirements for nodes that create the cluster:

  • Each node is a separate machine (physical or virtual). They don't need to be identical, but should be as similar as possible for consistent performance.
  • All nodes are running the same version of Jira. You'll be copying JIRA from one node to another, so this shouldn't be a problem. They use the same timezone, and have the current time synced. You can use ntpd to set this up.
  • All nodes share a common database, also installed on a separate machine.
  • All nodes can access the shared home directory. You can set it up using NFS, or a similar solution. We'll mention it in this guide.
Do I need a load balancer?
Tell me more...

Yes. Jira Data Center relies on a load balancer to balance the traffic between the nodes, and this guide assumes that you already have one set up. You can use a load balancer of your choice, just make sure it meets these requirements:

  • Supports "cookie based session affinity", also known as "sticky sessions".
  • Can route HTTP/HTTPS traffic to one of the available nodes.
  • Can determine whether a node is available or not, and route requests to other nodes if needed.
  • All Atlassian applications and other REST clients must access your nodes through the load balancer.

Or you can just turn your proxy into a load balancer.

Many bigger installations of Jira already have a reverse proxy configured, and many reverse proxies can do load balancing as well. We've provided some examples on how to use your proxy as a load balancer. See Load balancer examples.

1. Install or upgrade your Jira instance

Jira Data Center is available for Jira 7.0, or later. If you're not on this version yet, install or upgrade your Jira instance. 

Jira installation and upgrade guide

Few things to know about:

  • If you're installing your instance from scratch, generate a non-Data Center evaluation license at the setup stage, and update to the Data Center license when you're adding the cluster.properties file at step 3.
  • If you're upgrading your instance, update to the Data Center license when you're adding the cluster.properties file at step 3.

2. Set up the shared directory

You'll need to create a remote directory that is readable and writable by all nodes in the cluster. There are multiple ways to do this, but the simplest is to use an NFS share.

  1. Create a remote directory, accessible by all nodes in the cluster, and name it e.g. sharedhome
  2. Stop your Jira instance.
  3. Copy the following directories from the Jira local home directory to the new sharedhome directory (some of them may be empty).

    • data
    • plugins
    • logos
    • import
    • export
    • caches

3. Configure your existing Jira instance to work in a cluster

  1. In the Jira local home directory, create a cluster.properties file, with contents as follows:

    Example cluster.properties file:

    # This ID must be unique across the cluster
    jira.node.id = node1
    # The location of the shared home directory for all Jira nodes
    jira.shared.home = /data/jira/sharedhome

    For more information and some additional parameters, see Cluster.properties file parameters.

  2. Start your instance, and apply the Data Center license.

4. Add the first node to the load balancer

The load balancer distributes the traffic between the nodes. If a node stops working, the remaining nodes will take over its workload, and your users won't even notice it.

  1. Add the first node to the load balancer.
  2. Restart the node, and then try opening different pages in Jira. If the load balancer is working properly, you should have no problems with accessing Jira.

5. Add the remaining nodes to the cluster

  1. Copy the Jira installation directory and the local home directory from the first node to this new node.

  2. Ensure the new node can access (read and write) the shared home directory.

  3. Edit the cluster.properties file, and change the node ID. All node IDs must be unique among nodes.

  4. Start Jira. It will read the configuration from the shared home directory, and start without any extra setup.

  5. Take a look around the new Jira instance. Ensure that issue creation, search, attachments, and customizations work as expected.

  6. If everything looks fine, you can configure your load balancer to start routing traffic to the new node. Once you do this, you can make a couple of changes in one Jira instance to see if they're visible in other instances as well.

While adding your nodes to the cluster, you can check their status by going to  > System > System info. Your nodes will be listed in the Cluster nodes section.

Cluster.properties file parameters

In addition to the required parameters, the cluster.properties file allows you to configure some additional options, mostly related to EhCache.

Tell me more...
Parameter Required Description/value
jira.node.id Yes This unique ID must match the username and the BalancerMember entry in the Apache configuration.
jira.shared.home Yes The location of the shared home directory for all JIRA nodes.
ehcache.peer.discovery No

Describes how nodes find each other:

default – JIRA will automatically discover nodes (recommended)
automatic – JIRA will use the EhCache's multicast discovery. This is the historical method used by EhCache, but it can be difficult to configure, and is not recommended by Atlassian.

If you choose automatic...

If you set ehcache.peer.discovery = automatic then you need to set the following parameters:

  • ehcache.multicast.address

  • ehcache.multicast.port

  • ehcache.multicast.timeToLive

  • ehcache.multicast.hostName

For more info on these parameters, see Ehcache documentation.

ehcache.listener.hostName No

The hostname of the current node for cache communication. JIRA Data Center will resolve this this internally if the parameter isn't set.
If you have problems resolving the hostname of the network you can set this parameter.

ehcache.listener.port No

The port that the node is going to be listening to (default is 40001).

If multiple nodes are on the same host, or if this port is unavailable, you might need to set this parameter manually.

ehcache.listener.socketTimeoutMillis No By default, this is set to the EhCache default.

Monitoring the health of your Data Center

Now that you got your Data Center up and running, we recommend that you keep monitoring its health right from the start. This will help you keep any problems from getting bigger and messing with your work, and you'll always know what's going on in the cluster. 

JIRA Data Center is equipped with a set of health checks tools that let you monitor the whole cluster and each node individually, including all important settings. To access the health check tools, go to  > System > Support Tools. All health checks are listed in the Instance health tab. 

Last modified on Jul 6, 2018

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.