Using configuration profiles
Define configuration profiles to specify how DataStax Enterprise (DSE) is to be configured. A configuration profile enforces uniform configuration at the cluster, datacenter, or node level.
A configuration profile allows defining and centrally managing consistent configuration settings, which prevents configuration drift. Configuration drift happens over time as changes are made on a manual rather than an automated basis, and the changes are applied in an inconsistent manner. Configuration drift contributes to failures with high availability and disaster recovery efforts. If a configuration change is made outside of the Lifecycle Manager (not recommended), running a configuration job within LCM overwrites the configuration on the job targets, ensuring that the clusters, datacenters, and nodes are running as specified in the applied configuration profiles.
Inheritance and Precedence
Configuration profiles inherit intelligently within the cluster topology. The inheritance and precedence of configuration profiles allows keeping a cluster consistent by inheriting as much as possible from a cluster-level configuration profile, while also providing the flexibility of specifying only the granular settings that differ in higher precedence within configuration profiles applied at the lower, more granular datacenter and node levels.
For example, if a configuration profile is not explicitly specified at the datacenter or node level, the configuration profile is inherited from the cluster level. When creating the cluster topology model, defined configuration profiles can be applied at the cluster, datacenter, or node level. A configuration profile at the node level takes precedence over datacenter or cluster level profiles. Define configuration profiles that reflect the requirements of the workload node type in a datacenter.
|
When upgrading clusters that have nodes running different DSE versions, it is useful to create configuration profiles at the node or datacenter level. Because inheriting configuration profile values does not function across DSE versions, it is necessary to duplicate cluster-level settings at the datacenter or node level until the upgrade is complete. |
When a configuration job runs, configuration profiles specified at different topology levels are merged in a granular manner. For example, consider a cluster with a configuration profile defined and applied at the cluster level with the following specifications:
-
G1 Garbage Collector (g1gc)
-
Maximum heap size of 16 GB
-
Uses the default commit log directory of /var/lib/cassandra/commitlog.
The cluster has two datacenters: DC1 and DC2:
-
DC1 has no configuration profile of its own and therefore inherits its configuration profile from its cluster.
-
DC2 has a defined configuration profile at the datacenter level that specifies a maximum heap size of 32 GB, and a commit log directory of
/cassandra_data/commitlog.
When the configuration job runs, the following configuration results for each datacenter as shown in the table.
DC1 inherits all settings from the cluster because none are specified at the datacenter level.
However, DC2 uses a 32 GB max heap size and the /cassandra_data/commitlog commit log directory because the datacenter configuration profile takes precedence over the cluster configuration.
.Resulting configuration profiles for DC1 and DC2
| Cluster | DC1 | DC2 | |
|---|---|---|---|
Garbage collector |
g1gc |
g1gc |
g1gc |
Max heap size |
16 GB |
16 GB |
32 GB |
Commit log directory |
|
|
|
For further instructions, see Managing configuration profiles.
