Atlassian Data Center architecture and infrastructure options
This guide outlines the architecture and infrastructure options available when deploying the Data Center editions of Jira Software, Jira Service Desk, Confluence, and Bitbucket.
There are two architecture options available when you install the Data Center editions of Jira, Confluence or Bitbucket:
|Option||Description||Recommended use cases|
|Non-clustered (single node)|
Your application (Jira, Confluence, or Bitbucket) runs on a single server or node.
Your application (Jira, Confluence, or Bitbucket) runs on multiple application nodes configured in a cluster. This architecture requires specialized components, such as a load balancer.
When studying the performance of your instance, it's important to know the size of your data and volume of your usage.
To help you out, we came up with reference profiles for each product (Small, Medium, Large, and XLarge). These references list what metrics to collect, along with what their values say about your instance's size.
Atlassian’s Server products only support non-clustered architecture. Data Center supports both non-clustered and clustered options.
The right Data Center architecture for you depends largely on which features and capabilities your organization needs. Data Center comes with exclusive security, compliance, and administration features, many of which are available on non-clustered architecture. Our feature guides provide a detailed overview of what’s included for each option:
- Jira Server and Data Center feature comparison
- Confluence Server and Data Center feature comparison
- Bitbucket Server and Data Center feature comparison
Non-clustered (single node)
In this setup, your Data Center application runs on a single server – just like a Server installation.
Diagram: example non-clustered Data Center architecture
As you can see, Data Center deployed on a single node looks just as a Server installation, and consists of:
- Jira, Confluence or Bitbucket running on a single node
- A database that Jira, Confluence or Bitbucket reads and writes to
If you’re deploying new infrastructure with your Data Center product, you can use the same architecture used for Server installations.
Is a non-clustered architecture right for you?
In general, we recommend considering a non-clustered Data Center deployment if:
- you only need Data Center features that don't rely on clustering
- you’re happy with your current Server infrastructure, and want to upgrade to Data Center without provisioning new infrastructure
- high availability isn’t a strict requirement
- you don’t immediately need the performance and scale benefits of clustered architecture
Non-clustered Data Center is the simplest setup, but it has some limitations. Just like a Server installation, you’ll still have the application server as a single point of failure, so it can’t support high availability or disaster recovery strategies.
Some deployments start to experience performance or stability issues once their size profile hits Large or XLarge. Most clustered deployments provide you the flexibility to scale up your infrastructure to address heavy loads (or even scale down to save costs during light loads). On AWS or Azure, you can also quickly address most stability issues by replacing misbehaving nodes with fresh ones.
Switch to clustering when you need it
If you choose non-clustered Data Center, you still have the flexibility to change your architecture later. You can configure clustering at any time with the same Data Center license – no reinstallation required.
Data Center allows you to run your application in a cluster with multiple nodes, and a load balancer to direct traffic. This is important for organizations where high availability and performance at scale are essential for every team to be productive.
Diagram: example clustered Data Center architecture
A clustered setup includes:
- Multiple identical application nodes
- A load balancer to distribute traffic to all of your application nodes
- A shared file system
- A shared database that all nodes read and write to
- For Bitbucket, you’ll also need a dedicated node for ElasticSearch that all nodes read and write to.
Clustering has a number of benefits:
- High availability and failover: If one node in your application cluster goes down, the others take on the load, ensuring your users have uninterrupted access to the application.
- Performance at scale: each node added to your cluster increases concurrent user capacity, and improves response time as user activity grows. You can also deploy nodes dedicated to specific functions.
- Instant scalability: add new nodes to your cluster without downtime or additional licensing fees. Indexes and apps are automatically synced.
- Disaster recovery: deploy an offsite Disaster Recovery system for business continuity, even in the event of a complete system outage. Shared application indexes get you back up and running quickly.
Compared to non-clustered Data Center, clustering requires additional infrastructure, and a more complex deployment topology, which can take more time and resources to manage. You can help mitigate this complexity by deploying on public cloud infrastructure such as AWS (Amazon Web Services) or Azure.
You can choose to deploy Atlassian Data Center applications on the infrastructure of your choice:
- your own physical hardware (on premises) or virtual machines
- a public cloud provider like AWS (Amazon Web Services) and Azure. This is also known as infrastructure as a service (IaaS).
Which infrastructure option is right for you?
We leave it up to you to choose which infrastructure option best suits your organization’s requirements and existing investments.
More and more customers are choosing to deploy Atlassian Data Center products using a cloud provider like AWS because it can be more cost effective and flexible than physical hardware.
Quickly deploy using a public cloud provider
To help you design and deploy Data Center infrastructure in a matter of minutes, we provide the following:
- AWS Quick Starts
- Azure Resource Manager (ARM) templates
These tools use sensible defaults and settings for a wide variety of customer deployments. They also apply many of our infrastructure recommendations automatically. They’re designed to deploy cluster-ready architecture, starting with a single node that you can scale up as you need.
Head to our product guides to find out what’s involved with each option.
These resources (published and hosted on AWS Quick Starts) use AWS CloudFormation templates to deploy Atlassian Data Center applications on AWS, following AWS best practices.
These resources (published and hosted on Azure Marketplace) use Microsoft Azure Resource Manager templates to deploy Atlassian Data Center applications on Azure.
Highly customized deployments on public cloud
You can also directly customize the templates used by our AWS Quick Starts or Azure Marketplace Templates. These templates allow you to deploy Data Center for your organization in public cloud infrastructure. Clone either of the following Bitbucket repositories (published and supported by Atlassian) to get started: