Adding a second node to Data Center

Sometimes customers get stuck after deployment of the first node in their Data Center environment. Maybe a second node wasn't deployed due to uncertainty about added value, or there was a technical issue during the process. This article helps you to review the benefits of adding a second node using examples from other customers, to better prepare you for getting your multi-node Data Center cluster up and running.

Why do we need more than one node?

Data Center provides the ability to scale your application with the growth of your organization, by providing high availability and horizontal scalability. At least two nodes are needed to provide high availability via Data Center's active/active clustering. If one node fails, your Data Center application is still available for your users. Data Center handles all the communication between each node, as well as automating and facilitating the failover process in the event of a node failure.

If your system experiences performance issues due to high concurrent usage, having a second node available provides more concurrent usage capacity, giving your users a better experience.The studies below detail some test results, showing performance increases for three of our products after adding additional application nodes:

Cost

We price Data Center based on the number of users, and not the number of nodes in your cluster, so you don't pay additional licensing fees when you add a node. More information regarding pricing can be found at our Data Center licensing and pricing page.

Adding a node

You can review the steps for how to add a node to your cluster, in the following links:

Common issues

While customers are typically able to add a node without any issue, we have observed a few instances when they experienced a problem. Here are some of the most common issues our customers have had, when adding a second node.

Misconfigured load balancer

A common reason for experiencing an error when adding a node is not enabling cookie-based "sticky sessions" on your load balancer. Data Center applications assume that each user's request will go to the same node during a session, so you need to enable sticky sessions if you want to bind a session to the same node, on the load balancer. Another mistake we've seen is not configuring the load balancer to check the node's status using the /status endpoint to ensure that the node is ready for traffic.

For more information on using load balancers with Data Center, see the following links:

Incorrect configurations and processes

The following are common configuration issues for customers trying to add a second node on their Data Center application:

  • The permissions for the shared home directory are not correct. Ensure that your new node can access the shared home directory.
  • The new node has a different CPU or memory configuration than the first node. We recommend configuring each node to be as similar as possible to each other.
  • The new node is running a different version of the application than the first node.
  • Adding a new node and performing an application upgrade at the same time. We recommend against this approach. If you're doing an application upgrade at the same time, you can upgrade the application on your first node and then add a new node after testing the upgrade.

Incorrect Bitbucket Data Center configurations

The following configurations have caused issues when trying to add a second Bitbucket Data Center node:

  • The bitbucket.properties file, which configures Hazelcast for multicast by default, is not edited when the network doesn't support multicast. You can find more information about configuring Hazelcast in the Bitbucket Data Center installation guide.

  • The application is configured to run ElasticSearch on a Bitbucket application node, instead of configuring a remote Elasticsearch node. Read this guide for setting up a remote Elasticsearch node.

  • The load balancer is configured to use a balancing algorithm other than Round Robin or Least Connections, which are the ones we recommend for Bitbucket Data Center.

Not adding the new node's ID for Jira Data Center

One of the steps for adding a new node to Jira Data Center requires copying the home directory from the first node to the new node. You'll have to edit the cluster.properties file to reference the new node identifier as the system doesn't do this automatically. You can find more information about the cluster.properties file in the Jira Data Center installation guide.

Incorrect node discovery in Confluence Data Center

When installing Confluence Data Center, you configure node discovery to use either multicast or TCP/IP. However, if your network does not support multicast traffic, you'll need to edit the confluence.cfg.xml to reference the new node's IP address. You can find more information about switching to TCP/IP node discovery in this guide.

We're here to help

We are eager to help you get up and running on a full Data Center deployment so that you can benefit from all the features. If you need help adding your second node, please file a support ticket. A support engineer will be happy to assist you.

Last modified on Jan 12, 2018

Was this helpful?

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