Mission Control Frequently Asked Questions (FAQs)
What is Mission Control?
Mission Control provides everything needed to run DataStax Enterprise (DSE) or Apache Cassandra® clusters of any scale with reduced complexity and integrations with centralized services within the enterprise.
Mission Control manages the entire operational surface of DSE across a diverse array of hosting options, from self-managed bare-metal to cloud-provided virtual machines. Mission Control provides always-on, automated operations of DSE and C* clusters based on expertise running DataStax Astra. It assists DataStax customers with their own on-premises deployments. It vastly simplifies lifecycle management, observability, best practice configuration, and advanced operations.
What are the main components of Mission Control?
- Lifecycle Management
-
Simplify deploying and configuring DataStax Enterprise (DSE) clusters in Kubernetes.
- Observability
-
Use monitoring tools to follow logs and metrics and to track the operations of your DSE system.
- Health & Best Practices
-
Kubernetes uses
kubelet
to probe the need to restart a container, while deployments use readiness probes to check a pod’s ability to receive traffic. - Security
-
Secure the build and restore processes from nodes to datacenters from the cloud.
- Advanced Operations
-
Perform node repairs, compaction, streaming, and backup & restore.
Who is the target audience?
Existing and new DataStax Enterprise (DSE) users.
- Browser-Based User Interface
-
Users connect to a web service running within the Mission Control environment. From here they are presented with an Astra-like experience for deploying and managing services running within their infrastructure. Based on user permissions multiple views are available for various parts of the system including connection and health information for developers, advanced observability and operations controls for database administrators, and hardware capacity and usage for infrastructure engineers.
- Kubernetes API Endpoints
-
Any task that can be run within the Mission Control user interface is also available via Kubernetes APIs and Custom Resource Definitions (CRDs). This allows any Kubernetes client or enabled project to automate and interface with Mission Control. From GitOps workflows with Flux and Argo to template-based Helm charts, Mission Control provides extreme flexibility for integration with existing systems.
What is the pricing model?
Pricing for Mission Control is included in the DSE or HCD license and all existing DSE customers will get a free download to replace OpsCenter. get a free download to replace OpsCenter.
Is there support available?
Yes. Contact your account team for a replacement or non-community license file. Ask troubleshooting questions through DataStax support.
What is a Control Plane
Cluster?
A Control Plane
is the management layer that establishes and controls all key operations related to management of database components, provides access to its functions via APIs, and handles the ongoing lifecycle of and health of the whole system.
What is a Data Plane
cluster?
While the Control Plane
establishes policies for all key operations, the Data Plane
is the remaining infrastructure architecture that carries out the operational policies.
In Kubernetes, worker nodes, along with their pods and containers, comprise the Data Plane
.
A Kubelet is a small application that runs on each node in the cluster and executes actions.
What is a Kubernetes cluster?
It is a set of nodes that run containerized applications. An application is packaged into a container along with its dependencies and necessary services. In Kubernetes, a pod is a wrapper around a single container, and that pod is what Kubernetes manages.
What is a DataStax Enterprise (DSE) cluster?
A cluster comprised of one or more nodes that exists as an always-on data platform for cloud applications that is powered by Apache Cassandra®. It uses the OpsCenter Web application to monitor and run administrative operations on the nodes. Mission Control is intended to supersede OpsCenter functionality as Kubernetes clusters move, in part or wholly, to the Cloud.
How does Mission Control support co-location of nodes?
Nodes from different DSE clusters can be co-located on the same host. However, to avoid availability issues, Mission Control doesn’t co-locate multiple nodes from the same cluster, whether multiple racks are used or not.
What is the mapping of Kubernetes terms to DataStax Enterprise (DSE) / Apache Cassandra® terms?
Term | Description | Kubernetes | Apache Cassandra®/DataStax Enterprise (DSE) |
---|---|---|---|
Container |
a way to package an application along with its libraries and its dependencies |
√ |
√ |
Docker |
most popular contnainer runtime software running containerization of applications |
√ |
√ |
Manifest |
typically either a JSON or YAML file that specifies a desired state of a Kubernetes API object such as a pod, deployment, or service. |
√ |
√ |
Namespace |
Equivalent with virtual cluster, providing a way to divide a physical cluster into multiple virtual clusters. It is also a way to provide organization to objects in a cluster. |
√ |
√ |
Node |
either physical or virtual machines in the cluster from which applications run |
√ controlled by the Kubernetes |
√ |
Logging |
Logs are the list of events that are recorded by a cluster or application. They help us understand how data is flowing through applications as well as spot when and where errors occur. |
√ In Kubernetes your application should output logs to |
√ |
Proxy |
A server that acts as an intermediary for a remote service, taking client requests and copying client data to the server, and sending the server replies to the client. |
√ kube-proxy is the network proxy that performs Kubernetes networking services in and out of the cluster |
√ |
RBAC |
Role-Based Access Control uses roles which grant the required level of access to sets of users in the cluster. |
√ Managed through the Kubernetes API |
√ |
Secret |
A kuberenetes object that stores sensitive information such as passwords, API keys, and ssh keys so that pods can use that information without the data being shown. Sensitive data is exposed to containers either as a file in a volume mount or through environment variables. |
√ |
√ |