Plan a Mission Control installation
Review the following topics to identify the type of topology and deployment roles for each target cluster and to outline the steps to ensure a smooth installation experience. Guidance is given to help you determine the storage and networking requirements that you need to provision.
Plan your Mission Control deployment
Mission Control provides a platform and is a singular interface for the deployment and management of DataStax Enterprise (DSE) and Apache Cassandra® database clusters across logical and physical regions. Here are some examples of deployment topologies:
-
Deploy one instance of Mission Control for the entire organization.
-
Dedicate multiple targeted installations to specific groups.
-
Dedicate one instance per DEV, TEST, and PROD environments.
At the top-level Mission Control is composed of a centralized Control Plane and optional regionally deployed Data Planes.
- Control Plane
-
provides the core interface for Mission Control, and includes the top-level API service, user interface, and observability endpoints. The Control Plane manages coordination across each Data Plane’s region boundaries.
- Data Plane
-
each Data Plane that is deployed contains the individual DSE or C* nodes and provides a self-contained environment for the local management of DSE and C* resources.
|
The Control Plane can operate as a Data Plane because it includes all of the necessary components. Therefore a Data Plane is not required. Opt for a single Control Plane in the case of a simple deployment within a single region. |
Installation type
Mission Control covers your deployment in one of two environment types:
-
Dedicated bare-metal or Virtual Machines (VMs)
-
Invoke the Runtime Installer and set up an embedded runtime environment. Prerequisite services are set up on a cluster (or multiple clusters depending on the size of your deployment). See Server-based Runtime Installer.
-
-
Existing Kubernetes services within your organization (on-premises or cloud-based).
-
Invoke the Kubernetes KOTS plugin / Admin Console to configure and install Mission Control. See install on a Kubernetes cluster.
This type of installation requires additional capacity planning because more components are run as part of the Mission Control installation.
-
Either installation choice provides a unified interface for automated operations with Kubernetes handling the scheduling of containerized DSE or C* nodes across a fleet of servers deployed across multiple regions and providers. Reiterate the installation process to install Data Planes on each cluster where nodes are to be deployed. In environments involving multiple infrastructure regions, a separate Data Plane installation is required per geographic region or geo-distributed datacenter, with one installation per regional cluster. Data Plane clusters represent the locations where the database instances are provisioned and run.
The installation process is simple and handles all of the details.
Capacity planning
Installation of Mission Control involves different instance types and varied resource requirements. The suggested guidelines are the minimum required. You may need to increase CPU capacity, memory, and disk space beyond the recommended minimums.
Platform instances
Mission Control observability includes metrics and logging from all components within the platform. These are centralized, aggregated, then shipped out to an external object store (see Storage requirements). The vast majority of Mission Control metrics and logs are generated by the managed database instances. Therefore the values recommended are tightly coupled to the number of clusters deployed and their individual schemas because each table holds a number of metrics which are tracked. The following recommendations assume 2 regions, each with 30 database instances, and 500 tables across all clusters.
-
6 Instances (3 per region)
-
32 CPU cores
-
64 GB RAM
-
1 TB storage
Database instances
Database instances are where all DataStax Enterprise (DSE) and Apache Cassandra® nodes are scheduled to run. The sizing guidance below assumes a one-to-one relationship between nodes and Kubernetes workers. Alternatively you may co-locate multiple instances on a single worker. Adjust the values according to your expected database node resource requirements.
-
16 physical CPU cores (32 hyper-threaded cores)
-
64 GB RAM minimal
-
1.5 TB storage
DataStax benchmark testing shows that resource requirements and performance are similar between bare-metal VMs and Kubernetes install types. The recommendation for running C* in production is:
-
8 to 16 cores
-
32GB to 128GB RAM See Cassandra capacity planning for further details.
CPU and RAM setting concepts
The precise amount of RAM required depends on the workload and is usually tuned based on observation of Google Cloud (GC) metrics. For RAM, you should set the memory requirements to double the heap size. By default, the JVM allows processes to use as much off-heap memory as the configured on heap memory. So with a heap of 8GB, the JVM uses up to 16GB of RAM depending on the off-heap memory usage (C* uses that a lot). The following rule simpliflies this concept - set the heap size to a reasonable value that matches the available memory on the worker nodes. For example, given 32GB RAM per worker node and extra processes such as Kubernetes operators, Mimir, and Loki that need to run, you should set your heap size to 8GB, and memory requests to 16GB. If GC pressure is too high, you can raise those values to 12 and 24GB, respectively. During the installation process, allow the monitoring stack to run on the DSE nodes to enable scheduling Mimir and all on the same worker nodes (in production you’ll have to separate these into different node pools). You can set the CPU requests to a minimum (1 core, for example) to allow scheduling all components concurrently. Processes still use as many cores as possible. Note that in production, despite scheduling the monitoring stack and the C* pods on separate node pools, you still need to leave some RAM available for system pods that allow Kubernetes operations such as networking. For example, if you have 48GB RAM per worker, leave 1GB to 2GB for those extra pods by setting your resource requests to around 46GB.
See further considerations for database instance sizing in the DataStax Enterprise and Apache Cassandra planning guides.
Storage requirements
In addition to the local storage requirements for Database and Observability instances, Mission Control requires an S3-compatible Object Storage. Mission Control utilizes object storage for long-term retention of observability data and for database backups.
Load balancer
The Mission Control User Interface (UI) is accessed through a specific port on any of the cluster worker nodes. It is highly recommended to place this service behind a load balancer directing traffic of all worker nodes within the cluster on port 30880. This ensures that the UI remains available should an instance go down.
|
Load balancing in front of database instances is not supported. |
Runtime installs
Runtime installations embed their own Kubernetes environment and therefore additional requirements must be met. Mission Control utilizes Kurl for the installation and management of core Kubernetes runtime. See the Kurl system requirements for the supported operating systems, additional packages, and host-level configuration.
Kubernetes management instances
- Kubernetes Primary nodes
-
In addition to the number and types of instances determined during Capacity planning, you must account for the overhead of Kubernetes Primary nodes. These nodes contain metadata and services required to deploy workloads across all worker nodes. Mission Control requires three Primary Node instances, with each node set to:
-
4 AMD64 (x86_64) CPUs or equivalent
-
8 GB of RAM
-
256 GB of disk space
-
- Load balancers
-
To provide high-availability of services, Mission Control Runtime-based installations require an additional load balancer. Place it in front of the Primary Kubernetes nodes for core Kubernetes API traffic running on port 6443.
Required networking firewall ports
Open TCP and UDP ports 1024-65535 between all hosts within a given region, a given Control Plane, or a given Data Plane.
This allows for the seamless shifting of workloads between instances due to changing environments.
| Instance types | Server-runtime installation | Kubernetes installation |
|---|---|---|
Primary |
|
— |
Platform |
|
|
Database |
|
|
What’s next?
Proceed to the instance configuration step based on your installation type.
-
Kubernetes Installations - Online and Offline installation paths
-
Runtime Installations - Online and Offline installation paths
