Capacity planning and hardware selection for DSE deployments

A supported Java runtime is required.

If you install multiple Java versions, you must set $JAVA_HOME to the latest DSE-supported Java version that you have installed.

Familiarity with Linux command-line tools is important for managing and operating your DSE clusters. For example:

To keep the database healthy, the database periodically merges and rewrites SSTables while discarding old data through a process called compaction.

It is important that you choose an appropriate compaction strategy for your use case and data model. Misconfigured or unsuitable compaction strategies can degrade performance and overconsume system resources. The following table summarizes the supported compaction strategies and general configuration guidance for each strategy.

For more information about compaction strategy properties and tuning, see Configure compaction.

To estimate how much data your nodes can hold, calculate the usable disk capacity per node and then multiply that by the number of nodes in your cluster:

See Evaluate partitions.

Determining node density depends heavily on the environment and factors such as the following:

DataStax recommends no more than 2 TB of data per node.

Exceeding the recommended data density has the following effects:

High-capacity nodes work best with low to moderate write throughput and no indexing. An ideal use case is static data that is rarely accessed.

If you have time-series data, you can use the TimeWindowCompactionStrategy (TWCS) to scale larger than these limits if the following conditions are true for your cluster:

Solid state drives (SSDs) are recommended for all DSE nodes.

The NAND Flash chips that power SSDs provide extremely low-latency response times for random reads while supplying ample sequential write performance for compaction operations. In recent years, drive manufacturers have improved overall endurance, usually in conjunction with spare (unexposed) capacity. Additionally, because PBW/DWPD ratings are probabilistic estimates based on worst case scenarios, such as random write workloads, and because the database does only large sequential writes, drives significantly exceed their endurance ratings.

However, it is important to plan for drive failures and have spares available. A large variety of SSDs are available from server vendors and third-party drive manufacturers. Longevity is a key factor when purchasing SSDs. The best recommendation is to make the decision based on how difficult it is to change drives when they fail, not on workload of the drive. Remember, your data is protected because the database replicates data across the cluster. Buying strategies include:

When choosing disks for your nodes, consider capacity (how much data you plan to store) and I/O (the write/read throughput rate). Some workloads are best served by using less expensive SATA disks and scaling disk capacity and I/O by adding more nodes (with more RAM).

For more information about SSDs with DSE, see Storage engine and Optimize disk settings.

DataStax recommends placing commit logs and data directories on separate disks (at least two disks) for better performance and resiliency. If you cannot use separate disks, the commit log should be on its own partition.

For SSD, unlike spinning disks, performance doesn’t suffer as much when sharing commit logs and data directories as compared to HDD. However, separation is still recommended.

In a physical, on-premise deployment, Storage Area Network (SAN) storage is aggregated storage that is external to a server. In cloud deployments, virtual SAN storage is local to compute nodes.

Although used frequently in enterprise IT environments, traditional SAN storage is typically less performant and more expensive than other options when used with distributed databases:

Taken together, these factors can create problems that are difficult to resolve in production. In particular, deploying DSE clusters with an external SAN requires additional preparation and testing that isn’t common to other deployments. This can include development of specialized testing methods and additional personnel, time, and resource requirements for testing and reconfiguration cycles. For example, methods are needed for all key scaling factors, such as operational rates and SAN fiber saturation.

For more information about the disadvantages of traditional SAN storage, contact IBM Support.

Using a NAS device often results in network-related bottlenecks caused by high levels of I/O wait time on reads and writes. Examples of these bottlenecks include router latency and the Network Interface Cards (NICs) in the node and the NAS device.

Typically, you don’t need to use a Redundant Array of Independent Disks (RAID) on data disks for the following reasons:

Based on your data availability and consistency configuration, the database responds to disk failure by stopping the affected node or denylisting the failed drive. This means that you can deploy nodes with large disk arrays without the overhead of RAID-10. For more information, see Recover from a single disk failure using JBOD and the disk_failure_policy parameter in cassandra.yaml.

Generally, DataStax recommends the built-in JBOD configurations. If you need extra redundancy, use RAID-0, RAID-1, or RAID-10. For certain workloads, RAID-0 can provide better throughput because it splits every block onto another device, allowing parallel (instead of serial) writes on disk. Don’t use RAID-5, RAID-6, or variants like RAID-50 or RAID-60, which exhibit poor performance.

Additionally, you don’t typically need RAID for the commit log disk because built-in replication functionality adequately prevents data loss. If you need extra redundancy for the commit log disk, use RAID-1.

DataStax recommends that you deploy on XFS. If XFS is not available, use ext4.

Don’t use ext2 or ext3 because you can only use a maximum file size of 2 TB, even with a 64-bit kernel. In contrast, the XFS file system limitation is 16 TB with a 32-bit kernel and essentially unlimited with a 64-bit kernel.

Because the database can use almost half your disk space for a single file with SizeTieredCompactionStrategy (STCS), use XFS with large disks, especially with a 32-bit kernel.

Use a 4 KB block size for optimal performance.

If you use a firewall, make sure that nodes within a cluster can communicate with each other. For required ports, see Secure DataStax Enterprise ports.

If you are using other components with DSE, make sure the required ports for those components are open and not blocked by a firewall. For example, for DSE OpsCenter, see OpsCenter ports reference to set firewall rules.

DataStax strongly recommends that you configure peer-to-peer encryption and client-to-server encryption during the initial setup of your production cluster. Even if you don’t intend to use network encryption immediately, it is better to configure it during initial setup.

It is more difficult to enable this encryption after the cluster starts serving production traffic. Misconfiguration on a live cluster can result in cluster-wide downtime and data loss, such as missed writes.

For more information, see the following:

DSE was designed to avoid the need for load balancers. Putting load balancers between the database and clients can be harmful to performance, cost, availability, debugging, testing, and scaling.

All high-level clients implement load balancing directly. For example, see Load balancing in Cassandra drivers.

With Mission Control, you can use load balancers to support your Mission Control deployment, but they must not intersect database-client communication.

You cannot reconfigure or change racks after provisioning a cluster. This includes migrations from a single rack to multiple racks. These changes can result in data loss.

If racks are fundamentally misconfigured, you must redeploy your cluster with the correct configuration.

The following guidance applies to single-token architectures only; it doesn’t apply to virtual nodes. For more information, see Data distribution and replication.

In single-token architectures, defining one rack for the entire cluster is the simplest and most common implementation. Avoid multiple racks for the following reasons:

To set up racks correctly, plan to allocate the same number of nodes to each rack. Add nodes to the first rack, and then configure subsequent racks in an alternating pattern.

The rack feature benefits from quick and fully functional cluster expansions. Once the cluster is stable, you can swap nodes and make the appropriate node moves to ensure that nodes are placed in the ring in an alternating fashion with respect to the racks.

Capacity planning for DSE Search requires that you estimate how large the search index could become. To do this, you need to index documents on a single node, run typical user queries, and then examine the memory usage for heap allocation.

Repeat this process with more documents until you get a clear estimate of the size of the index for the maximum number of documents that a single node can handle. Then, you can determine how many servers to deploy for a cluster, as well as the optimal heap size.