Scaling Jira Data Center: Key Architecture and Infrastructure Considerations

While Atlassian Cloud is purpose-built from the ground up to scale from the smallest number of users to the largest enterprises, there are still some organizations that the Atlassian Data Center environment is currently a better fit for. The good news is that with some forethought, your Data Center instance can be architected to support long-term organizational growth and operations at scale. To do this, you will need to make several key decisions.

The first of these is defining the Jira node architecture—whether, like most organizations, you need more than one node and how those nodes should be clustered. You will also need to make key decisions about what types of environments to set up—development, stage, and production, for instance—as well as what types of data each of these instances should be populated with.

In this article, we will take an in-depth look at each of these key decisions, and what you need to consider before making them, to ensure your organization is set up to run Atlassian Data Center at scale.

Scaling Jira Data Center with Multi-Node, Clustered Architecture 

Data Center can be deployed in two ways: either on a non-clustered, single node or on multiple, clustered nodes. Smaller organizations with limited demands on their instance may find a single node is adequate—it is both more straightforward to set up and takes fewer resources to manage and maintain—but it has drawbacks in terms of performance, availability, and disaster recovery. Because of this, most organizations, and particularly those that plan to scale or are already operating at scale, will benefit from multiple, clustered nodes.

Clustering is more complex: it requires additional infrastructure and consequently more time and resources to manage, although deploying on public cloud infrastructure (such as AWS) can help minimize the impact. However, most companies find clustering is worth the effort for both scalability and performance. You can increase user capacity and improve response time by adding nodes to your cluster and/or deploying nodes dedicated to specific functions, and you can add new nodes to your cluster without downtime or additional licensing fees.

With clustering, you also benefit from higher availability and are better positioned from a failover perspective: if one node in your application cluster goes down, the others take on the load, ensuring your users have uninterrupted access to the application. You can also deploy an offsite Disaster Recovery system for business continuity, so even if there is a complete system outage, shared application indexes get you back up and running quickly.

Setting Up Your Node Clusters

It's common for companies that are experiencing performance issues due to high memory usage to respond by adding or beefing up the existing nodes instead of addressing core usage patterns. At Isos Technology, we recommend taking a comprehensive view of Jira usage patterns and defining node groups to handle different use cases. A common pattern for breaking up nodes into clusters is to have a three-node group that includes admin, API nodes, and general usage nodes.

• Admin Nodes

A separate cluster for admins’ functions allows them to work freely without impacting general usage or being impacted if a general usage cluster needs to be taken down. For example, many admin functions require reindexing once completed, which often takes a long time to run. By performing the reindex on a dedicated cluster and then pushing the indexes to the other nodes, you will minimize the impact on the main group of end users.

Also, note that since Jira admin functions are typically only performed by a small group of users, this will be one of the smaller node clusters.

• API Nodes

API calls to Jira can be resource-intensive operations. The benefit of having a dedicated API cluster is that you ensure uninterrupted access to Jira for your end users that a resource-intensive or runaway API call might otherwise disrupt. So for example, a third-party system (such as an accounting or HR platform) can make direct calls into Jira when needed without impacting general usage. Also, if API calls only happen during certain times of the day, it is very easy to scale this cluster up and down in anticipation of these planned events.

• General Usage Nodes

The final cluster of nodes should be for everyday Jira usage that the environment was built to support, and it will likely be the most used part of any scaled Jira environment. With the offloading of other functions, end users will see greater and more consistent performance. By monitoring usage patterns of these nodes over time, you will even be able to see when more nodes should be added to the cluster and scale to correspond with this usage.

Once your node clusters have been established, it’s worth the effort to monitor and periodically reevaluate how your organization is using Jira and adjust accordingly. The key tenet here is to not have one large cluster, but to define specific sets of nodes dedicated to Jira usage patterns, which will allow you to maximize resource utilization and scale up or down as needed.

Establishing Your Environments

Once you’ve figured out your initial node architecture, you will need to start planning how you are going to spin up your servers. There is not a general standard on how to architect your environment—it will vary from organization to organization. You may, for example, be forced to run bare metal servers, or perhaps you are fully ensconced in AWS or GCP. You may run Windows or Linux. Your organization might already be heavily invested in orchestration software or tools like Ansible.

Whatever the case, there are questions and considerations that should be considered before actually spinning up servers. First, since you are operating at scale, you will need dedicated environments. At a minimum, you should have development, stage, and production environments. While it is okay to have your development tier differ from your production tier, you should try to mimic production as closely as possible. Stage, on the other hand, should be as close as possible to your production environment. Remember, stage environments are your final sanity check before production. These are the minimum considerations for your Atlassian Data Center environments.

It is also a good idea to have the ability to instantiate multiple development environments in an ad hoc manner. One environment could be dedicated as a sandbox for your users to test out changes to Workflows, Schemes, Custom Fields, and other features that they are not able to directly modify in production due to permission restrictions. A second development environment could be dedicated to testing out API calls, third-party integrations, and apps. A final development environment could be reserved for testing out newer versions of Jira as dictated by your organization’s change management processes. You may also need to create instances for specific business units to test. Regardless of how many environments you choose to have, you should configure your orchestration with enough flexibility to add new environments in the future.

Populating Your Environments with Data

When working through creating environments, you will also need to consider how those environments are populated with data. The standard approach is to populate lower environments with copies of production data. While this seems like a straightforward approach, it can have unseen challenges. Often, development environments have looser restrictions on admin privileges, which allow users to experiment with Workflows, Schemes, and Custom Fields before requesting production changes. Unfortunately, this can easily lead to a scenario where users are able to access data they normally wouldn’t be allowed to see, such as HR tickets.

When copying data between environments, you must be very careful with permissions and not copy sensitive Projects into certain environments. Another common strategy for new environments is to only pull over a subset of Projects. There are several apps in the Atlassian Marketplace that not only make this process easier, but they also will help you promote Projects and Jira artifacts between environments. This is very useful when teams are testing out Workflows, Schemes, and Custom Fields in development environments. If you use one of these apps, you will need to wrap a change management process around promotion, leveraging your stage environment.

Disaster Recovery

Keep in mind that high availability is not the same as disaster recovery. While Jira Data Center can be configured to support both high availability and scalability, you will need to work through your own disaster recovery model. Fortunately, if you have figured out good orchestration strategies, you will be a step ahead. You can use these strategies along with regularly scheduled backups when disaster strikes. Regardless of how you are backing up Jira and orchestrating environment creation, test your backups regularly. While once a month may be too aggressive, doing this less than once per quarter significantly increases risk. Testing your disaster recovery should be more than just making sure servers come up and you are able to see the dashboard. You should approach testing the environment the same way you would handle any UAT, with multiple users and use cases verifying the system.

Documentation

While this may sound like common sense, we would be remiss if we did not mention how important it is that your orchestration processes are well documented. Far too often, documentation is overlooked completely or only partially done, with critical information retained in the head of an IT resource. From an organizational standpoint, this presents a significant risk that should be avoided whenever possible.

For organizations that are not yet able to make the transition to Atlassian Cloud, it is important to understand that Atlassian continues to invest in Data Center. Setting up the appropriate node clusters, establishing the right set of environments, and populating those environments with the right data are just some of the critical choices companies can make to ensure their Data Center instance supports long-term growth and operations at scale.

Additional Reading: Atlassian Data Center Architecture and Infrastructure Options