MOSK cluster hardware requirements

This section provides hardware requirements for the Mirantis OpenStack for Kubernetes (MOSK) management cluster with a MOSK cluster.

Important

A MOSK cluster is to be used for a deployment of an OpenStack cluster and its components. Deployment of third-party workloads on a MOSK cluster is neither allowed nor supported.

Note

One of the industry best practices is to verify every new update or configuration change in a non-customer-facing environment before applying it to production. Therefore, Mirantis recommends having a staging cloud, deployed and maintained along with the production clouds. The recommendation is especially applicable to the environments that:

• Receive updates often and use continuous delivery. For example, any non-isolated deployment of MOSK.

• Have significant deviations from the reference architecture or third party extensions installed.

• Are managed under the Mirantis OpsCare program.

• Run business-critical workloads where even the slightest application downtime is unacceptable.

A typical staging cloud is a complete copy of the production environment including the hardware and software configurations, but with a bare minimum of compute and storage capacity.

The table below describes the node types the MOSK reference architecture includes.

MOSK node types

Node type	Description
MOSK management cluster nodes	The MOSK management cluster architecture on bare metal requires three physical servers for manager nodes. On these hosts, we deploy a Kubernetes cluster with services that provide functions of the MOSK management control plane.
OpenStack control plane node and StackLight node	Host OpenStack control plane services such as database, messaging, API, schedulers conductors, and L3 and L2 agents, as well as the StackLight components. Note MOSK enables the cloud operator to collocate the OpenStack control plane with the MOSK cluster master nodes on the OpenStack deployments of a small size. This capability is available as technical preview. Use such configuration for testing and evaluation purposes only.
Tenant gateway node	Optional. Hosts OpenStack gateway services including L2, L3, and DHCP agents. The tenant gateway nodes are combined with OpenStack control plane nodes. The strict requirement is a dedicated physical network (bond) for tenant network traffic.
OpenSDN control plane node	Required only if OpenSDN is enabled as a backend for the OpenStack networking. These nodes host the TF control plane services such as Cassandra database, messaging, API, control, and configuration services.
Compute node	Hosts the OpenStack Compute services such as QEMU, L2 agents, and others.
Infrastructure nodes	Runs underlying Kubernetes cluster management services. The MOSK reference configuration requires minimum three infrastructure nodes.

The table below specifies the hardware resources the MOSK reference architecture recommends for each node type.

Hardware requirements

Node type	# of servers	CPU cores # per server	RAM per server, GB	Disk space per server, GB	NICs # per server
Management cluster node	3 [0]	32 min 16	128 min 64	1 NVME or SSD x 240 1 NVME or SSD x 960 [1]	2 or 1 x 2-port [2]
OpenStack control plane, gateway [3], and StackLight node	3 or more	32	128	1 SSD x 500 2 SSD x 1000 [5]	5
Tenant gateway node (optional)	0-3	32	128	1 SSD x 500	5
OpenSDN control plane node	3	16	64	1 SSD x 500	1
Compute node	3 (varies)	16	64	1 SSD x 500 [6]	5
Infrastructure node (Kubernetes cluster management)	3	16	64	1 SSD x 500	5
Infrastructure node (Ceph) [4]	3	16	64	1 SSD x 500 2 HDDs x 2000	5

Note

The exact hardware specifications and number of the control plane and gateway nodes depend on a cloud configuration and scaling needs. For example, for the clouds with more than 12,000 Neutron ports, Mirantis recommends increasing the number of gateway nodes.

[0]

Adding more than 3 nodes to a management cluster is not supported.

[1]

In total, at least 2 disks are required:

• disk0 - system storage, recommended - 240 GB, minimum - 120 GB.

• disk1 - management cluster services storage, recommended - 960 GB, minimum - 480 GB that must include 2 volumes for management services (total 50 GB). For details about required StackLight volumes, see the corresponding footnote below. The exact capacity requirements depend on configured volume sizes for StackLight, MariaDB, and mcc-cache.

For other storage details, see Management cluster storage.

[2]

Only one PXE port per node is allowed. The out-of-band management (IPMI) port is not included.

[3]

OpenStack gateway services can optionally be moved to separate nodes.

[4]

• A Ceph cluster with 3 Ceph nodes does not provide hardware fault tolerance and is not eligible for recovery operations, such as a disk or an entire node replacement. Therefore, a minimum of 5 Ceph nodes is recommended for production use.

• A Ceph cluster uses the replication factor that equals 3. If the number of Ceph OSDs is less than 3, a Ceph cluster moves to the degraded state with the write operations restriction until the number of alive Ceph OSDs equals the replication factor again.

[5]

• 1 SSD x 500 for operating system

• 1 SSD x 1000 for OpenStack LVP

• 1 SSD x 1000 for StackLight LVP that must include 4 volumes per node:

  • Alertmanager - 2 GB (hardcoded)

  • PostgreSQL - 10 GB (hardcoded)

  • Prometheus - 16 GB by default

  • OpenSearch - 30 GB by default

  For production deployments, Mirantis recommends increasing the default values for Prometheus and OpenSearch to store more metrics and logs, according to your needs.

[6]

When Nova is used with local folders, additional capacity is required depending on the VM images size.

Note

If you would like to evaluate the MOSK capabilities and do not have much hardware at your disposal, you can deploy it in a virtual environment. For example, on top of another OpenStack cloud using the sample Heat templates.

Please mind, the tooling is provided for reference only and is not a part of the product itself. Mirantis does not guarantee its interoperability with any MOSK version.

See also

OpenSearch and Prometheus storage sizing