Deploy configuration changes to a cluster

To make a configuration change, modify and submit the MissionControlCluster manifest (object) that matches your release.

This section partially covers configuration options and their values. An example workflow and specific guidance for key configuration topics are provided.

Mission Control enables authentication and authorization by default. For Cassandra and Hyper-Converged Database (HCD) clusters, use the Cassandra default PasswordAuthenticator and CassandraAuthorizer functionality. For DataStax Enterprise (DSE) clusters, use com.datastax.bdp.cassandra.auth.DseAuthenticator and com.datastax.bdp.cassandra.auth.DseAuthorizer.

Explore topic-specific configuration:

Performance impact

Increasing the heap size parameter that is used by all objects in the cluster might increase the time it takes to find, process, and collect objects included in the heap.

Timeout settings are adjusted to increase throughput and maintain near ideal requests per second, yielding better performance.

Prerequisites

A prepared environment on either bare-metal/VM or an existing Kubernetes cluster.

Example of a configuration change

This example uses resource_name.kind.yaml as the filename of the Custom Resource (CR). See MissionControlCluster CRD definition file that matches your release. In the appropriate CRD file, increase the heap size and adjust both the write_request_timeout_in_ms and read_request_timeout_in_ms settings. Then deploy these configuration changes to a control plane Kubernetes cluster.

In this example a Kubernetes cluster exists with a certain number of nodes. The amount of memory allocated to the Java Virtual Machine (JVM) needs to increase. This memory is shared by instances of all the objects created during the runtime of an application.

The heap value is determined by the amount of memory available to the container and must be set to, at a maximum, half of the requested memory. See heap size parameter guidelines and recommendations.

Workflow of user and operators

User submits a modified MissionControlCluster to the control plane cluster.
Cluster-level operator detects change, modifies datacenter-level resource (CassandraDatacenter).
Datacenter-level operator detects change, modifies rack-level resource.
Datacenter-level operator terminates instance in rack.
Datacenter-level operator bootstraps replacement node.
Datacenter-level operator repeats steps 3-5 for all racks in the datacenter.
Cluster-level operator repeats steps 2-6 for all datacenters in the cluster.

Reconfigure a database cluster

Two Kubernetes clusters exist for this example, a control plane cluster and a data plane cluster.

Modify the resource_name.kind.yaml file to define the MissionControlCluster config specification. Set updated heap parameters for the jvmOptions key. Increase both the initial and the maximum heap sizes from 1Gi to 2Gi. Further modify the write_request_timeout_in_ms and read_request_timeout_in_ms properties for the cassandraYaml key as follows:

...
config:
    cassandraYaml:
      write_request_timeout_in_ms: 5000
      read_request_timeout_in_ms: 10000
    jvmOptions:
      heap_initial_size: 2Gi
      heap_max_size: 2Gi

The MissionControlCluster config: specification supports several configuration keys, including:

cassandraYaml: For Cassandra and HCD configuration properties
dseYaml: For DSE configuration properties
jvmOptions: For JVM configuration options

These are the most commonly used configuration keys. For a complete list of supported options, see the CRD reference documentation.

Submit the modified MissionControlCluster manifest, resource_name.kind.yaml, to the control plane Kubernetes cluster from a terminal window.
```
kubectl apply -f resource_name.cassandratask.yaml
```
Monitor the progress of the task from the data plane cluster by submitting the following command:
```
kubectl get cassandradatacenter dc1 -o yaml
```
Result
status: cassandraOperatorProgress: Updating conditions: - lastTransitionTime: "2022-10-19T19:08:09Z" message: "" reason: "" status: "True" type: Healthy - lastTransitionTime: "2022-10-19T19:08:10Z" message: "" reason: "" status: "False" type: Stopped ... - lastTransitionTime: "2022-10-19T19:10:43Z" message: "" reason: "" status: "True" type: Updating ...
The status field is set to "False" when the Updating operation completes.

Changes are applied in the same order in which the racks are declared in the MissionControlCluster manifest.

The configuration changes are applied in a rolling fashion, one rack at a time and one node at a time within each rack. The changes also trigger a rolling restart as part of the update. The configuration updates take effect as soon as the update is finished.

Submit the following command to check the cassandra.yaml file and verify that the update is complete:

kubectl exec -it demo-dc1-rack1-sts-0 -c cassandra -- cat resources/cassandra/conf/cassandra.yaml | grep ^'write\|read'_request_timeout_in_ms

Result

write_request_timeout_in_ms: 5000
read_request_timeout_in_ms: 10000

Submit the following command to check the jvm-server.options file and verify that it, too, reflects the update:
```
kubectl exec -it demo-dc1-rack1-sts-0 -c cassandra -- cat resources/cassandra/conf/jvm-server.options | grep ^'-Xmx\|-Xms'
```
Result
-Xms2147483648 -Xmx2147483648
The values are shown in bytes.

Mission Control operators perform the conversion from 2Gi to the appropriate number of bytes.

Deploy configuration changes to a cluster

Performance impact

Prerequisites

Example of a configuration change

Workflow of user and operators

Reconfigure a database cluster

See also

Was this helpful?

Give Feedback