Cluster Topology Overview 

Explains the concepts of the logical cluster topology model that underpins OpsCenter.

The Lifecycle Manager (LCM) topology model consists of cluster, datacenter, and node entities. The model facilitates installing and configuring DataStax Enterprise at the cluster, datacenter, and node levels. When installing and configuring DSE clusters, the model provides flexibility and powerful inheritance mechanisms.

LCM requires manually defining the cluster topology for new DataStax Enterprise clusters, or for clusters whose nodes do not use the same SSH credentials because the automatic cluster import process requires using a singular SSH credential. Automatically importing the cluster for existing DSE clusters imports the cluster topology and constructs the cluster model entities on your behalf in the Clusters workspace. The logical LCM model should reflect the actual physical topology of a cluster.

If someone manually changes cluster topology without using LCM, you must update the logical topology model in LCM to reflect those physical changes. For instance, when a node is decommissioned in OpsCenter, you must manually delete the node in the model. It is not currently possible to decommission systems directly using LCM.
Note: If you neglect to update the corresponding LCM model, when running the next configure or install job, LCM attempts to restore the old topology, with unpredictable results.

When deleting (that is, ceasing to manage) an entity from the topology model in LCM, you are simply removing management of the entity from LCM. Deleting a cluster, datacenter, or node in LCM does not affect the physical systems. Deleting entities from the LCM topology model causes LCM to stop managing and ignore them. The physical cluster, datacenters, nodes, and the corresponding entities in OpsCenter are not affected.

Note: The data (cluster topology models, configuration profiles, credentials, repositories, job history, and so forth) for Lifecycle Manager is stored in the lcm.db database. Your organization is responsible for backing up the lcm.db database. You must also configure failover to mirror the lcm.db.

Lifecycle Manager: Clusters Workspace 

Use the Clusters workspace to import existing clusters, provision new clusters, manage the cluster topology, and run configure jobs. Manually adding entities in the model must be performed in order:
  1. Add clusters
  2. Add datacenters
  3. Add nodes
Datacenters can inherit certain shared settings from a cluster. Nodes can inherit certain shared settings from a datacenter or a cluster.

The following graphic shows the fully expanded and populated Clusters, Datacenters, and Nodes panes prior to running an install and configure job:

Topology status legend
Status Icon Description
Not run
(red flag)
An install job has not been run on the topology entity. See running a job.
Import (unmanaged cluster)
(red plus sign)
An existing cluster is not being managed by Lifecycle Manager. Click Start Managing and follow instructions to automatically import the cluster.
Success
The job ran successfully on a topology entity (cluster, datacenter, or node).
Failure
(red universal no access symbol)
The job run on a topology entity (cluster, datacenter, or node) failed. Investigate the issue by drilling into the job details. Try running the job again.

lcm.db 

The location of the Lifecycle Manager database lcm.db depends on the type of installation:

  • Package installations: /var/lib/opscenter/lcm.db
  • Tarball installations: install_location/lcm.db
Note: The data (cluster topology models, configuration profiles, credentials, repositories, job history, and so forth) for Lifecycle Manager is stored in the lcm.db database. Your organization is responsible for backing up the database. You must also configure failover to mirror the lcm.db.