Data Center migration guides

No organization is the same and neither is your migration journey. The key to any good migration is planning.


Guide 4: Deploy in a clustered architecture

Now that you’ve reviewed the Getting Started and Planning guides, you are ready to deploy Data Center in a clustered environment.

Get the infrastructure you need for your cluster

To deploy Data Center in a cluster, you’ll want the following components:

  • Database
  • Load balancer
  • Application nodes
  • File system
  • ElasticSearch node (Bitbucket)

Load balancer

The load balancer is the first thing that your users’ requests hit if you’ve deployed in a cluster. Requests come into the load balancer and the load balancer then distributes each request to the application nodes. You can use either a hardware or software-based load balancer. For both software and hardware solutions, the load balancer should be linked to the application cluster using a high-speed LAN connection to ensure high bandwidth and low latency. All software load balancers should run on dedicated machines.

Data Center products assume that each user’s request will go to the same node during a session. If requests go to different nodes, users may be unexpectedly logged out, and they could even lose information stored in their session. Therefore, it is required to bind a session to the same node by enabling cookie-based “sticky sessions” (or session affinity) on the load balancer. When using cookie-based sticky sessions, you can use the cookie issued by the product, or you can use a cookie generated by the load balancer.

Add an extra layer of protection and prevent the load balancer from becoming a single point of failure by adding redundancy to your load balancing solution. You can do this by setting up two load balancers in an active-passive configuration, using a virtual IP address across both load balancers. If the active load balancer fails, it will failover to the passive load balancer.

For more information, see our load balancer configuration options.

What are application nodes?

Application nodes are where the actual product lives. Each node in your Data Center cluster must run on the same version of the product and be located together to keep latency to a minimum. However, you can enable a content delivery network (CDN) to support the performance of your geo-distributed teams. These nodes should be configured in a cluster, acting as one, to serve the product to your users. The number of nodes in your cluster depends on your needs and how you configure your product. Typically, we find that between 2-4 nodes are sufficient for most clusters, but use our node sizing guides to help you make the right decision.

Information icon

Important note: Bitbucket requires an additional application node specifically dedicated to ElasticSearch, which enables code search.

How does the file system work?

The shared file system is where all the underpinnings of the product are stored. This is where things like your attachments, icons, user information, apps, and source code live.

In a Data Center environment, you need to set up your shared file system as its own node. You can use any NFS based NAS or SAN program for your shared file system, but we recommend NFS3 to maintain your performance. Just be sure to stay away from distributed protocols like DFS, as these are not supported.

Build your cluster

It’s time to build your Data Center cluster. In addition to setting up each of the various components in your cluster (application nodes, load balancer, database, file system), you also need to size the application nodes in your cluster based on your performance requirements.

We’ve put together some sample configurations you can reference. Atlassian does not endorse, approve, or recommend any specific vendors or configurations. These are provided as a reference. If you’d like more hands on guidance around configuring your optimal environment, see if working with a Technical Account Manager, Premier Support, or a Partner is right for you.

Create a staging environment

To perform a successful migration, we recommend creating a staging environment to try out Data Center before going live in production.

Your staging environment should closely replicate your production environment, including any reverse proxies, SSL configuration, or load balancer (for Data Center). You may decide to use a different physical server or a virtualized solution. The main thing is to make sure it is an appropriate replica of your production environment.

Once you’ve created your environment, you’ll need to:

  • Replicate your database
  • Replicate your product
  • Copy your local home directory to your shared home directory
  • Replicate external user management (optional)
Information icon

For detailed instructions, see:

Review and upgrade your apps

Before you deploy non-clustered Data Center, you need to review you apps and upgrade to a Data Center version when possible. If you migrate to Data Center before you upgrade your apps, they may stop working.

Install Data Center

Once you’ve set up your clustered architecture, you’re now ready to install your Data Center products.

For detailed instructions, check out our documentation to help you deploy Data Center products in a cluster.

 

Jira Software
Jira Service Desk

Confluence

Bitbucket

Crowd

Your hardware

Jira Software
Jira Service Desk

Your hardware

Confluence

Your hardware

Bitbucket

Your hardware

Crowd

Your hardware

AWS

Jira Software
Jira Service Desk

AWS

Confluence

AWS

Bitbucket

AWS

Crowd

AWS

Azure

Jira Software
Jira Service Desk

Azure

Confluence

Azure

Bitbucket

Azure

Crowd

 

Do a dry run

The testing phase is a fundamental step in deploying Data Center and often the most intensive part of the migration process. In order to confidently deploy Data Center to production, the team should run through an iterative set of functional tests, integration tests, and performance tests to vet the Data Center installation. If you’re migrating from server, each test may span 1 to 2 weeks.

Don’t skimp - a thorough testing phase will expedite your production deployment and allow you to account for unforeseen circumstances. Run multiple User Acceptance Tests (UATs) if necessary until you’re fully confident with going live.

Learn about performance on Data Center products:

Information icon

If you have a Customer Success Manager, do a health check to identify known issues with configurations, compatibility, driver versions, performance conditions, memory settings, among other things.

Go live in production

Now that you've migrated your testing environment to Data Center, you're ready to go live in production. 

Before you complete your migration, check that your production environment matches your testing environment so that everything works correctly on production, as you'll be completing the same steps as you did during the testing phase.

Upgrade your production apps

Before you deploy Data Center in a clustered environment, you need to review you apps and upgrade to a Data Center version when possible. If you migrate to Data Center before you upgrade your apps, they may stop working.

Install Data Center in production

As you did during the testing phase of your migration, you will need to migrate your production environment to Data Center. For step-by-step instructions on how to do this, see the following pages:

 

Jira Software
Jira Service Desk

Confluence

Bitbucket

Crowd

Your hardware

Jira Software
Jira Service Desk

Your hardware

Confluence

Your hardware

Bitbucket

Your hardware

Crowd

Your hardware

AWS

Jira Software
Jira Service Desk

AWS

Confluence

AWS

Bitbucket

AWS

Crowd

AWS

Azure

Jira Software
Jira Service Desk

Azure

Confluence

Azure

Bitbucket

Azure

Crowd

 

You’ve deployed Data Center in a cluster!

To learn more about administering Data Center, check out the resources section