In the Cluster area of OpsCenter, you select different views of the nodes comprising your Cassandra cluster, and then, perform node management and cluster rebalancing operations.
OpsCenter Enterprise Edition 2.1.3 can monitor and administer Cassandra 1.2 as described in these procedures unless you enable virtual nodes. When you enable virtual nodes, OpsCenter chooses a single token for each node for operations, such as collecting metrics. Attempting to move nodes, rebalance nodes, and perform other tasks involving token ranges is not supported.
Each of the cluster views--ring, physical, and list--has an Actions button.
Click the Actions button to access a drop-down list of node management operations. To avoid impacting cluster performance, perform actions that move data between nodes at low-usage times. Examples of such actions are move, decommission, and repair.
This table describes actions on the drop-down list:
| Action | Description |
|---|---|
| View Metrics | Redirects you to the Performance area of OpsCenter where you can select metrics graphs and configure performance views for the selected node. |
| View Replication | Shows the replication relationships between the selected node and other nodes in the cluster. Visible in Ring View and Physical View. |
| Cleanup | Removes rows that the node is no longer responsible for. This is usually done after changing the partitioner tokens or the replication options for a cluster. |
| Compact | Performs a major compaction, which is not a recommended procedure in most Cassandra clusters. |
| Flush | Causes the recent writes currently stored in memory (memtables) to be flushed to disk as persistent SSTables. |
| Repair | Makes a node consistent with its replicas by doing an in-memory comparison of all the rows of a column family, and resolving any discrepancies between replicas by updating outdated rows with the current data. |
| Perform GC | Forces the Java Virtual Machine (JVM) on the selected node to perform a garbage collection (GC). This reclaims physical disk space occupied by obsolete SSTables, such as those that have been truncated or compacted (merged) into new SSTables. |
| Decommission | Removes a node from the cluster and streams its data to neighboring replicas. |
| Drain | Causes the recent writes currently stored in memory (memtables) to be flushed to disk as persistent SSTables, and then makes the node read-only (the node will stop accepting new writes). This is usually done when upgrading a node. |
| Move | Changes the partitioner token assignment for the node, thus changing the range of data that the node is responsible for. |
Cluster rebalancing is a process that makes sure each node in a Cassandra cluster is managing an equal amount of data. Currently, OpsCenter only supports rebalancing on clusters using the random partitioner or murmur 3 partitioner. Ordered partitioners are not supported. When using the random partitioner or murmur 3 partitioner, a rebalance is usually required only when you have changed the cluster topology in some way, such as adding or removing nodes or changing the replica placement strategy.
A cluster is considered balanced when each node is responsible for an equal range of data. This is done by evaluating the partitioner tokens assigned to each node to make sure that the data ranges each node is responsible for are even. Even though a cluster is considered balanced, it is still possible that one or more nodes have more data than the others. This is because the size of the rows is not taken into account, only the number of rows managed by each node.
To rebalance a cluster: