Hardware requirements

The following sections describe hardware requirements to consider to deploy an IBM Storage Scale container native.

Network

All nodes in the compute cluster must be able to communicate with all nodes in the storage cluster.
A minimum of 10 Gb network is needed but 40 - 100 Gb is recommended.
RDMA over Converged Ethernet (RoCE) for Ethernet is not supported.

Worker node requirements

IBM Storage Scale container native supports x86_64, ppc64le, and s390x CPU architectures. All nodes in a Red Hat OpenShift or Kubernetes cluster must have the same architecture. The ARM architecture is not supported.

Starting with IBM Storage Scale container native v5.1.9, the UBI 9 base image is used and it is based on RHEL 9. And as RHEL 9 no longer supports Power8, IBM Storage Scale container native also no longer supports Power8. For more information, see Minimum IBM Power requirements.

IBM Storage Scale container native deploys several pods in the cluster. The following table shows the resource consumption of those pods.

Table 1. Hardware requirements
Pod	Where deployed	CPU request	Memory request	Storage	Notes
core (created with the k8s Node shortname)	Nodes that are labeled with nodeSelector in cluster CR	Minimum 1000mCPU. The sample CR sets 2000mCPU.	Minimum 4GiB (2 GiB on s390). The sample CR sets 4GiB for client role.	config in `/var` (~25 GiB)	This is the pod that provides the file system service for the node. It must be deployed on all nodes where PVs are accessed from application pods. The CPU and memory requests and limits can be customized in the cluster CR.
operator	Single Node	500mCPU	200 MiB		The controller runtime that manages all custom resources
gui	Two Nodes	630mCPU	1.4 GiB		The graphical user interface and ReST API
pmcollector	Two Nodes	120 mCPU	5.2GiB	Local PV/Dynamic provisioned PV for DB	The performance collector database
grafana-bridge	Single Node	100mCPU	1GiB		The bridge for accessing pmcollector from grafana

The shown values are requests. For more information, see Kubernetes resource management. The limits are higher. This means that for CPU the pods might have bursts with more CPU usage at times where the CPU has free cycles. For memory the pods should not exceed their request significantly. By default the core pods take 25% of the worker node capacity. 25% might be oversized in many applications. For more information about configuring the requests for both CPU and memory, see Cluster custom resource.

* Allocating more resources to IBM Storage Scale results in better storage performance.
* Allocating less allows more applications to be scheduled on a node.

For CPU, allocation can be reduced if the core fs pods consistently stay under the request. The CPU allocation can be monitored on the Red Hat OpenShift console. When going too low the file system daemon might starve on CPU cycles that destabilizes the whole cluster and can result in outages. For memory, there is no real monitoring, allocating more results in more data is cached which can boost performance. But this will be only seen indirectly by observing application performance.

The CPU request can be reduced under the 1000mCPU minimum. Your system might run fine with, for example, a 100mCPU. But, if a service ticket is opened for an issue that might be in any way that is related to this setting you will be asked to go up to 1000mCPU. The ticket is accepted only if the problem keeps showing up. Examples for related issues are, node expels, lag on PV creation in CSI, slow policy runs, bad performance, long servers, and so on. The Red Hat OpenShift console reports all worker nodes as overcommitted. The reason is that the CPU and memory limits of the pods add up to more than then total capacity of the node. This is normal and no reason for concern. Pods are scheduled based on their requests and the scheduler ensures that nodes will not be overcommitted in this regard. Higher limits allow pods to use resources that are free at the moment, but only the requested resources are guaranteed to them by Kubernetes. For more information about pod scheduling, see Kubernetes resource management

Pod memory request and limits

The following table shows the memory requests and limits configuration for each pod created.

Table 2. Pod memory requests and limits
Namespace	Pod name	Container	Memory request \	limit	CPU request \	limit
`ibm-spectrum-scale`	Grafana Bridge	`grafanabridge`	1000Mi \	4000Mi	100 m \	500 m
`ibm-spectrum-scale`	GUI	`liberty`	750Mi \	1000Mi	500 m \	2
`ibm-spectrum-scale`	GUI	`postgres`	400Mi \	1Gi	100 m \	1
`ibm-spectrum-scale`	GUI	`sysmon`	200Mi \	500Mi	20 m \	100 m
`ibm-spectrum-scale`	GUI	`logs`	20Mi \	60Mi	10 m \	100 m
`ibm-spectrum-scale`	PM Collector	`pmcollector`	5000Mi \	10000Mi	100 m \	500 m
`ibm-spectrum-scale`	PM Collector	`sysmon`	200Mi \	500Mi	20 m \	100 m
`ibm-spectrum-scale`	Core	`gpfs`	4Gi \	8Gi¹	2 \	4²
`ibm-spectrum-scale`	Core	`logs`	20Mi \	60Mi	10 m \	100 m
`ibm-spectrum-scale-operator`	controller-manager	`manager`	200Mi \	400Mi	500 m \	1500 m
`ibm-spectrum-scale-dns`	CoreDNS	`coredns`	70Mi \	140Mi	50 m \	100 m

For more information, see Requests and limits in the Kubernetes documentation.

Local file system

The Red Hat OpenShift nodes can provide disks or volumes to be used as local storage for creating PVs. These disks or volumes serve as storage for a local file system. A disk or volume can be a single drive, a partition of a single drive, or a volume from a RAID controller. Disks must be attached to the Red Hat OpenShift nodes as shared disks or SANs, each disk must have a connection to at least 2 nodes.

The storage device that provides the disks must protect against losing data, for example by using replication, RAID or erasure coding.

VMware³ thin provisioned virtual disks are not supported. For more information, see the "Disk Questions" section in IBM Storage Scale FAQ.

The memory limit is set to double of request memory by default. It can be set to another custom value into the Cluster custom resource. The new custom value must be at least twice as the memory request value.↩
The CPU limit is set to double of the CPUs of request by default. This can also be modified into the Cluster custom resource, but the new custom value must be at least twice as the CPU requested value.↩
VMware, the VMware logo, VMware Cloud Foundation, VMware Cloud Foundation Service, VMware vCenter Server, and VMware vSphere are registered trademarks or trademarks of VMware, Inc. or its subsidiaries in the United States and/or other jurisdictions. ↩