On-premise

Some additional tasks need to be performed on the IBM Storage Scale storage cluster that runs on-premise.

IBM Storage Scale storage cluster

The operators of IBM Storage Scale container native and IBM Storage Scale CSI interact with the storage cluster through ReST API (which is part of the GUI stack). To enable the operator to interact with storage cluster, user IDs need to be created on the storage cluster GUI. Specific roles are used to grant those user IDs only the operations that are needed to provide their functionality. In addition, some settings on the cluster and the filesystem are required for interoperability with CSI.

If the storage cluster is running a GUI high availability configuration, for example, having 2 or more GUI nodes installed, ensure that the storage cluster is running IBM Storage Scale 5.1.6.1 or higher before use with IBM Storage Scale container native and IBM Storage Scale CSI.

Creating container operator and CSI users

Complete the following steps in the shell of the GUI node of the storage cluster:

To create container native operator GUI user, enter the following command:
```
/usr/lpp/mmfs/gui/cli/mkuser cnsa_storage_gui_user -p cnsa_storage_gui_password -g ContainerOperator
```
By default, user passwords expire after 90 days. If the security policy of your organization permits it, use the -e 1 option on the mkuser command to create a user with a password that does not expire.
To create the CSI GUI user, enter the following commands:
```
/usr/lpp/mmfs/gui/cli/mkuser csi_storage_gui_user -p  csi_storage_gui_password -g CsiAdmin
```
By default, user passwords expire after 90 days. If the security policy of your organization permits it, use the -e 1 option on the mkuser command to create a user with a password that does not expire.

To update the passwords, see Updating authentication to the storage cluster.

Storage cluster configuration for Container Storage Interface (CSI)

Complete the following steps on the storage cluster to ensure that the IBM Storage Scale CSI driver can operate successfully:

Ensure that the perfileset quota on the file systems that are used by IBM Storage Scale Container Storage Interface driver is set to No.

The IBM Storage Scale Container Storage Interface driver will create many filesets (one per PV). Tracking user and group quotas on a per-fileset basis will significantly increase the overhead of quota management. As a result, the file system performance can suffer.
```
mmlsfs fs1 --perfileset-quota
```
Enter the following command to enable the Quota in the file systems:

The IBM Storage Scale Container Storage Interface driver translates capacity of persistent volumes to fileset quotas. For this to work, quotas are required to be enabled in the file system.
```
mmchfs fs1 -Q yes
```
Enter the following command to verify quota is enabled:
```
mmlsfs fs1 -Q
```
Enable the quota for root user by entering the following command:

On Kubernetes, the containers may run as root, so ensure that quotas are enforced for the root user as well.
```
mmchconfig enforceFilesetQuotaOnRoot=yes -i
```
Ensure that the controlSetxattrImmutableSELinux parameter is set to "yes" by entering the following command:

Kubernetes does not honor immutability of files/directories when setting SELinux labels. This creates issues, for example, with the immutable .snapshot directory.
```
mmchconfig controlSetxattrImmutableSELinux=yes -i
```
Enable filesetdf of the file system by entering the following command:

IBM Storage Scale Container Storage Interface driver will only be able to report free space on persistant volumes if filesetdf is set correctly.
```
mmchfs fs1 --filesetdf
```
IBM Storage Scale Container Storage Interface driver has no information about the number of inodes a persistent volume will consume. Therefore, corresponding independent filesets are created with default values for maxIndoes. To enable automatic expansion of the inode space so persistent volumes do not run out of inodes, enter the following command:
```
mmchfs fs1 --auto-inode-limit
```
The --auto-inode-limit option is available only with filesystem format level 28.00 or later. Enable auto-inode-limit as soon as the filesystem format level is updated to 28.00 or later. On older filesystem levels the administrator of the storage cluster needs to manually increase the inode limit when warnings for low inodes are raised by the health monitoring.

For more information about auto-inode-limit parameter, see mmchfs command in IBM Storage Scale documentation.

Configure cluster profile with tscCmdAllowRemoteConnections

Starting with version IBM Storage Scale and IBM Storage Scale container native 5.1.3, the tscCmdAllowRemoteConnections configuration is recommended to be set to no. If the storage cluster and all client clusters (including IBM Storage Scale container native) are at versions >= 5.1.3, it is recommended to set this value to no. However, if any version is < 5.1.3, tscCmdAllowRemoteConnections must be set to yes on the storage cluster and client clusters to successfully communicate between the clusters.

Use the following table as a reference.

Table 1. tscCmdAllowRemoteConnections configuration
Storage cluster version	IBM Storage Scale container native version	`tscCmdAllowRemoteConnections`
< 5.1.3	< 5.1.3.0	yes
>= 5.1.3	< 5.1.3.0	yes
>= 5.1.3	>= 5.1.3.0	no

To change this value on the storage cluster, run: mmchconfig tscCmdAllowRemoteConnections='yes|no'.

To change this value on the IBM Storage Scale container native cluster, set tscCmdAllowRemoteConnections: yes|no in the clusterProfile section of the cluster spec:

 kind: Cluster
 metadata:
 name: ibm-spectrum-scale
 spec:
    ...
    daemon:
    ...
    ...
    clusterProfile:
       tscCmdAllowRemoteConnections: "yes"

For more information to configure the clusterProfile section of the cluster spec, see Cluster profile.

For more information about all IBM Storage Scale services, see Securing the IBM Storage Scale system using firewall in IBM Storage Scale documentation.