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.

Organization-level Mission Control deployment

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.

Mission Control topology planes

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:

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.

Port Listing
Instance types Server-runtime installation Kubernetes installation


  • tcp:6443 - Runtime API services

  • tcp:30880 - UI service



  • tcp:30880 - UI service

  • tcp:30600 - Vector Aggregator

  • tcp:30880 - UI service

  • tcp:30600 - Vector Aggregator


  • tcp:30880 - UI service

  • tcp:9042 - Cassandra Native Protocol

  • tcp:7000 - Internode communications

  • tcp:7001 - Encrypted internode communications

  • tcp:8080 - Management API

  • tcp:30880 - UI service

  • tcp:9042 - Cassandra Native Protocol

  • tcp:7000 - Internode communications

  • tcp:7001 - Encrypted internode communications

  • tcp:8080 - Management API

What’s next?

Proceed to the instance configuration step based on your installation type.

Was this helpful?

Give Feedback

How can we improve the documentation?

© 2024 DataStax | Privacy policy | Terms of use

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries. Kubernetes is the registered trademark of the Linux Foundation.

General Inquiries: +1 (650) 389-6000,