Product Comparisons: JIRA Clustering

See How JIRA Clustering Compares to:

Data Partitioning

• There are two types of data partitioning: (1) the partitioning of a single JIRA server and its database server into multiple JIRA implementations with no communication between the partitions; or (2) database partitioning that supports integration across multiple partitions.
• The first approach is only practical if user access requirements never go beyond the boundary of a single partition.
• The second approach, which relies on the underlying database vendor's implementation, introduces a coordinating node to handle user requests that span data from multiple servers (partitions). The coordinating node is used to route these requests to all of the servers in the cluster, so that each server can execute them and return its subset of data to the coordinating node. The coordinating node then merges the data from each server to provide the final result back to the client.
• The coordinating node and each partition's server can become single points of failure. Data partitioning solutions typically require the coordinating node, as well as each partition's server to be available to avoid returning incomplete results for requests that span multiple partitions. For this reason, many data partitioning solutions do not allow the cluster to remain available if one of the servers goes offline.
• The requirement that all servers in the cluster remain available in order to provide user access makes 24X7 operation impossible. In contrast, JIRA Clustering's shared nothing architecture means that there is no single point of failure. If one of the servers in the cluster goes down, or is taken offline for maintenance, users will automatically fail over to another available server. When a server is brought back online it resynchronizes automatically with the other servers in the cluster.

Back to Top

Terracotta Scarlet

• The Terracotta Scarlet solution allows JIRA to plug into Terracotta's DSO server. The Terracotta DSO server replicates a memory image of the JIRA application to a cluster of servers. There is still only a single database server, and there is no communication between the database server and Terracotta.
• The fundamental difficulty with Terracotta's architecture is that there are now two single points of failure: (1) the Terracotta DSO server; and (2) the database server. If either one of these fails, the entire cluster goes down. If the database server fails, there could be non-recoverable data loss.
• With JIRA Clustering's shared nothing architecture, there is no single point of failure. If one of the servers in the cluster goes down, or is taken offline for maintenance, users will automatically fail over to another available server. When a server is brought back online it resynchronizes automatically with the other servers in the cluster.
• Terracotta introduces additional network hops to support memory access between the clustered JIRA application servers and the Terracotta DSO node. This increases memory access latency, and places an additional burden on the network. The net result is that under heavy load, a standalone JIRA server may outperform a Terracotta cluster.
• JIRA's application caching approach, which in a standalone JIRA implementation is designed to make the application more scalable, can become a scalability bottleneck, since Terracotta must now replicate JIRA's numerous caches to all of the clustered JIRA application servers through its central server.
• With WANdisco's JIRA Clustering, even though the same write operations occur on every database server in the cluster, near linear scaling is achieved. This is the case because the vast majority of operations against a JIRA server are typically read operations (90% in most organizations), and JIRA Clustering distributes the load for read operations evenly across all of the servers in the cluster. This has the effect of freeing up resources in each server to support write operations, with the result that write performance also improves.

Back to Top