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 a container orchestrators. Critical Manufacturing MES supports the following container Orchestrators:

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 (Kubernetes only)

• Additional Required Software

  • Powershell 7.1 (On-Premises installations only)

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
connect-iot-repo	connectiot-manager, envmanager, host	RWX	Any	2 GB
grafana-share	grafana	RWX	Any	1 GB
installation-data	aggregation-engine, cube, data-manager, discoveryservices, envmanager, epf-alarm-mng-at, epf-alarm-mng-erh, epf-alarm-mng-mes-eh, grafana, help, host, housekeeper, messagebus, rasa-actions, securityportal, traefik-fwdauth, ui	RWX	Any	5 GB
mes-host-documents	host	RWX	Any	10 GB
ml-agent-folder	mlplatform-agent	RWX	Any	1 GB
ml-agent-folder	mlplatform-training	RWX	Any	1 GB
ml-export-folder	data-manager	RWX	Any	1 GB
ml-export-folder	mlplatform-training	RWX	Any	1 GB
ml-training-folder	mlplatform-training	RWX	Any	1 GB
redis-data	redis	RWO	Block Storage	1 GB
cube	cube	RWO	Any	5 GB

Table: Volumes required for persistent storage.

Optional Volume configuration#

Volume	Component	Access Mode	Storage Type	Minimum Size
dagster	dagster	RWO	Any	1 GB
kafka-data	kafka	RWO	Block Storage	100 GB (per broker)
clickhouse-data	clickHouse	RWO	Block Storage	100 GB
clickhouse-log	clickHouse	RWO	Block Storage	20 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
mes_logs_share	host, discoveryservices, envmanager, help, messagebus, UI	RWX	Any	20 GB

Table: Volumes of optional components or optional volumes.

Scalable Components#

The table below lists all the components along with the images that can be scalable.

Table: Components can be scalable.