Application Layer - Container Stack#

The Critical Manufacturing MES application tier is deployed in a containerized environment, providing solid gains in terms of configuration and usability by taking advantage of a mature containerization architecture such as the one supplied by the Kubernetes or Docker engines.

The application tier takes advantage of a container orchestrator in order to ensure almost boundless horizontal scalability. Additional worker nodes can be added to the cluster and additional instances of specific components can be launched to accommodate extra load on a particular installation.

Software Requirements#

Containerized deployments rely on container orchestrators. Critical Manufacturing MES supports the following configurations:

On-Premises#

Table: Supported On-Premises Kubernetes Orchestrators

Cloud#

Table: Supported Cloud Kubernetes Orchestrators

Restrictions#

When using these container orchestrators, keep in mind the following restrictions:

• Operating System

  • Any Linux distribution compatible with the selected container orchestrator.
  • Recommended: Ubuntu Server 20.04 LTS or Red Hat Enterprise Linux 9.
  • Only x64 architecture is supported. (Container images for x86 or ARM architectures are not available).

• Container Engine

  • CRI-O
  • or containerd

• Additional Required Software

  • Powershell 7.1 (On-Premises installations only).

Container User IDs#

All containers run as a non-root user. Most Critical Manufacturing containers run with any non-root user ID (UID), as long as the user belongs to the root group (GID 0):

• They default to UID 1001, so they work with no changes on orchestrators that do not assign a UID, such as Canonical Kubernetes, Portainer Business + Talos, Vanilla Kubernetes, Amazon EKS, and Azure AKS.
• On Red Hat OpenShift, they run with the UID assigned to the project under the default restricted-v2 Security Context Constraint (SCC) ↗. OpenShift already runs these containers in the root group.

The following containers require a specific UID:

• Critical Manufacturing containers use UID 1001 when they write to persistent storage.
• Third-party containers use the UID required by their image.

Table: Containers That Require a Specific User ID

Folders mapped to the volumes in the table, such as hostPath folders, must grant read and write permissions to the UID of the container. On Red Hat OpenShift, DevOps Center deployments always request the nonroot ↗ SCC (v1) as a base, which allows the UID that the container sets.

Workload characterization#

Due to the flexibility offered by container orchestrators, Critical Manufacturing does not recommend specific hardware configurations, but provides an adequate description of the expected workload generated by the MES system. With this information, system administrators can provision and adequately size a cluster to run the MES application tier, considering high-availability and scalability requirements.

This section offers a description of the MES workload in different example configurations.

Similarly to what happens in the more traditional approach, the exact hardware requirements depend ultimately on the specific customer environment. Please consult with Critical Manufacturing for more specific recommendations adapted to specific deployments.

Hardware requirements for computational resources#

The following table describes the approximate requirements for some sample configurations, depending on their purpose. All examples assume no workloads related with equipment integration.

• Development: Development sandbox with no significant system load.
• Training / Staging: System with a similar configuration to a productive deployment, with higher resource demands.
• Production (MES only): Productive MES deployment with low to medium volume, without significant usage of Data Platform or Machine Learning capabilities. This configuration includes adequate overhead to support a new MES deployment during an upgrade process.
• Production (MES with Data Platform and Machine Learning): Productive MES deployment with medium to high volume, considering usage of Data Platform and Machine Learning features. This configuration includes adequate overhead to support a new MES deployment during an upgrade process.

Table: Hardware requirements for computational resources

For example, if you want to host two Development Systems (one Staging and one MES-only production system) in the same cluster, the resource requirements will add up, as shown below:

Table: Hardware requirements example for cluster

If several environments are deployed to the same cluster, Critical Manufacturing recommends resource quotas to be defined for each environment in order to prevent resource starvation on other environments or applications hosted on the same cluster. Usually, this is only possible on Kubernetes clusters.

Persistent Storage#

The application layer requires access to persistent storage volumes to hold object attachments, documents, installation packages, and other application files. The storage requirements depend heavily on the expected usage of the system.

Persistent volumes can be provisioned in different ways, depending on the deployment target platform. At the time of release of this version, Critical Manufacturing MES supports the following volumes types:

Table: Support for persistent volume types

The table below lists all the required volumes along with the component that requires it. Please note that, especially for Kubernetes deployments, there are different requirements for access modes. Some volumes require Read-Write-Many (RWX) access mode.

Volume	Component	Access Mode	Storage Type	Minimum Size
installation-data	envmanager and the BinaryFormatter migration job that runs once during an upgrade	RWX	Any	10 GB
connect-iot-repo	host, envmanager, connectiot-manager (Connect IoT license)	RWX	Any	2 GB
connect-iot-persistency	connectiot-manager, one per Automation Manager (Connect IoT license)	RWO	Any	Deployment default
connect-iot-logs	connectiot-manager, one per Automation Manager (Connect IoT license)	RWO	Any	Deployment default
cube	cube, cube-playground (IoT Data Platform Standard license)	RWO	Any	5 GB
postgres-storage	postgres (Grafana database)	RWO	Any	Deployment default

Table: Volumes required for persistent storage.

Optional Volume configuration#

Volume	Component	Access Mode	Storage Type	Minimum Size
mssqlserver-data	mssql	RWO	Block Storage	200 GB
kafka-data	kafka	RWO	Block Storage	100 GB (per broker)
clickhouse-data	clickhouse	RWO	Block Storage	100 GB
rabbit-data	rabbit	RWO	Block Storage	1 GB
rabbit-log	rabbit	RWO	Block Storage	1 GB
storage-data	storage	RWO	Block Storage	25 GB
ferret-data	ferretdb (GenAI)	RWO	Any	Deployment default
postgres-data	postgres (GenAI)	RWO	Any	Deployment default
mes_logs_share	envmanager, host, help, discoveryservices, messagebus	RWX	Any	20 GB

Table: Volumes of optional components or optional volumes.

Scalable Components#

The table below lists the components that can run with more than one replica, along with their images.

Table: Components that can be scaled.

The following components run as a single replica: envmanager, discoveryservices, lbogenerator, mes-scheduler, mcad, automationmanagercontroller, connectiot-manager, ioteventprocessor, ioteventrules, uns-connector, aggregation-engine, cube-playground, cubestore, mlplatform-agent, mlplatform-training, and the in-cluster infrastructure services (SQL Server, ClickHouse, Kafka, RabbitMQ, storage, FerretDB, and PostgreSQL).

Container Inventory#

The table below lists every container of the MES v12 stack, the package that deploys it, and the condition under which it is deployed. Components marked as optional infrastructure run inside the cluster for development and testing only; staging and production environments must use external services. See Customer Environment MES Stack for the purpose and configuration of each container.

Table: MES v12 container inventory.