Deploying OpenShift Data Foundation using IBM Power

Procedure

1. Log in to the OpenShift Web Console.
2. Click Operators → OperatorHub.
3. Type local storage in the Filter by keyword…​ box to find the Local Storage Operator from the list of operators and click on it.

4. Set the following options on the Install Operator page:

   1. Update channel as stable.
   2. Installation Mode as A specific namespace on the cluster.
   3. Installed Namespace as Operator recommended namespace openshift-local-storage.
   4. Approval Strategy as Automatic.
5. Click Install.

Procedure

1. Log in to the OpenShift Web Console.
2. Click Operators → OperatorHub.
3. Scroll or type OpenShift Data Foundation into the Filter by keyword box to find the OpenShift Data Foundation Operator.
4. Click Install.

5. Set the following options on the Install Operator page:

   1. Update Channel as stable-4.15.
   2. Installation Mode as A specific namespace on the cluster.
   3. Installed Namespace as Operator recommended namespace openshift-storage. If Namespace openshift-storage does not exist, it is created during the operator installation.

6. Select Approval Strategy as Automatic or Manual.

   If you select Automatic updates, then the Operator Lifecycle Manager (OLM) automatically upgrades the running instance of your Operator without any intervention.

   If you select Manual updates, then the OLM creates an update request. As a cluster administrator, you must then manually approve that update request to update the Operator to a newer version.

7. Ensure that the Enable option is selected for the Console plugin.
8. Click Install.

Procedure

1. Enable the Key/Value (KV) backend path in the vault.

   For vault KV secret engine API, version 1:

   $ vault secrets enable -path=odf kv

   For vault KV secret engine API, version 2:

   $ vault secrets enable -path=odf kv-v2

2. Create a policy to restrict the users to perform a write or delete operation on the secret:

   echo '
   path "odf/*" {
     capabilities = ["create", "read", "update", "delete", "list"]
   }
   path "sys/mounts" {
   capabilities = ["read"]
   }'| vault policy write odf -

3. Create a token that matches the above policy:

   $ vault token create -policy=odf -format json

Procedure

1. Create a service account:

   $ oc -n openshift-storage create serviceaccount <serviceaccount_name>

   where, <serviceaccount_name> specifies the name of the service account.

   For example:

   $ oc -n openshift-storage create serviceaccount odf-vault-auth

2. Create clusterrolebindings and clusterroles:

   $ oc -n openshift-storage create clusterrolebinding vault-tokenreview-binding --clusterrole=system:auth-delegator --serviceaccount=openshift-storage:_<serviceaccount_name>_

   For example:

   $ oc -n openshift-storage create clusterrolebinding vault-tokenreview-binding --clusterrole=system:auth-delegator --serviceaccount=openshift-storage:odf-vault-auth

3. Create a secret for the serviceaccount token and CA certificate.

   $ cat <<EOF | oc create -f -
   apiVersion: v1
   kind: Secret
   metadata:
     name: odf-vault-auth-token
     namespace: openshift-storage
     annotations:
       kubernetes.io/service-account.name: <serviceaccount_name>
   type: kubernetes.io/service-account-token
   data: {}
   EOF

   where, <serviceaccount_name> is the service account created in the earlier step.

4. Get the token and the CA certificate from the secret.

   $ SA_JWT_TOKEN=$(oc -n openshift-storage get secret odf-vault-auth-token -o jsonpath="{.data['token']}" | base64 --decode; echo)
   $ SA_CA_CRT=$(oc -n openshift-storage get secret odf-vault-auth-token -o jsonpath="{.data['ca\.crt']}" | base64 --decode; echo)

5. Retrieve the OCP cluster endpoint.

   $ OCP_HOST=$(oc config view --minify --flatten -o jsonpath="{.clusters[0].cluster.server}")

6. Fetch the service account issuer:

   $ oc proxy &
   $ proxy_pid=$!
   $ issuer="$( curl --silent http://127.0.0.1:8001/.well-known/openid-configuration | jq -r .issuer)"
   $ kill $proxy_pid

7. Use the information collected in the previous step to setup the Kubernetes authentication method in Vault:

   $ vault auth enable kubernetes

   $ vault write auth/kubernetes/config \
             token_reviewer_jwt="$SA_JWT_TOKEN" \
             kubernetes_host="$OCP_HOST" \
             kubernetes_ca_cert="$SA_CA_CRT" \
             issuer="$issuer"

   Important

   To configure the Kubernetes authentication method in Vault when the issuer is empty:

   $ vault write auth/kubernetes/config \
             token_reviewer_jwt="$SA_JWT_TOKEN" \
             kubernetes_host="$OCP_HOST" \
             kubernetes_ca_cert="$SA_CA_CRT"

8. Enable the Key/Value (KV) backend path in Vault.

   For Vault KV secret engine API, version 1:

   $ vault secrets enable -path=odf kv

   For Vault KV secret engine API, version 2:

   $ vault secrets enable -path=odf kv-v2

9. Create a policy to restrict the users to perform a write or delete operation on the secret:

   echo '
   path "odf/*" {
     capabilities = ["create", "read", "update", "delete", "list"]
   }
   path "sys/mounts" {
   capabilities = ["read"]
   }'| vault policy write odf -

10. Generate the roles:

    $ vault write auth/kubernetes/role/odf-rook-ceph-op \
            bound_service_account_names=rook-ceph-system,rook-ceph-osd,noobaa \
            bound_service_account_namespaces=openshift-storage \
            policies=odf \
            ttl=1440h

    The role odf-rook-ceph-op is later used while you configure the KMS connection details during the creation of the storage system.

    $ vault write auth/kubernetes/role/odf-rook-ceph-osd \
            bound_service_account_names=rook-ceph-osd \
            bound_service_account_namespaces=openshift-storage \
            policies=odf \
            ttl=1440h

Procedure

1. List and verify the name of the worker nodes with the OpenShift Data Foundation label.

   $ oc get nodes -l cluster.ocs.openshift.io/openshift-storage=

   Example output:

   NAME       STATUS   ROLES    AGE     VERSION
   worker-0   Ready    worker   2d11h   v1.23.3+e419edf
   worker-1   Ready    worker   2d11h   v1.23.3+e419edf
   worker-2   Ready    worker   2d11h   v1.23.3+e419edf

2. Log in to each worker node that is used for OpenShift Data Foundation resources and find the name of the additional disk that you have attached while deploying Openshift Container Platform.

   $ oc debug node/<node name>

   Example output:

   $ oc debug node/worker-0
   Starting pod/worker-0-debug ...
   To use host binaries, run `chroot /host`
   Pod IP: 192.168.0.63
   If you don't see a command prompt, try pressing enter.
   sh-4.4#
   sh-4.4# chroot /host
   sh-4.4# lsblk
   NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
   loop1    7:1    0   500G  0 loop
   sda      8:0    0   500G  0 disk
   sdb      8:16   0   120G  0 disk
   |-sdb1   8:17   0     4M  0 part
   |-sdb3   8:19   0   384M  0 part
   `-sdb4   8:20   0 119.6G  0 part
   sdc      8:32   0   500G  0 disk
   sdd      8:48   0   120G  0 disk
   |-sdd1   8:49   0     4M  0 part
   |-sdd3   8:51   0   384M  0 part
   `-sdd4   8:52   0 119.6G  0 part
   sde      8:64   0   500G  0 disk
   sdf      8:80   0   120G  0 disk
   |-sdf1   8:81   0     4M  0 part
   |-sdf3   8:83   0   384M  0 part
   `-sdf4   8:84   0 119.6G  0 part
   sdg      8:96   0   500G  0 disk
   sdh      8:112  0   120G  0 disk
   |-sdh1   8:113  0     4M  0 part
   |-sdh3   8:115  0   384M  0 part
   `-sdh4   8:116  0 119.6G  0 part
   sdi      8:128  0   500G  0 disk
   sdj      8:144  0   120G  0 disk
   |-sdj1   8:145  0     4M  0 part
   |-sdj3   8:147  0   384M  0 part
   `-sdj4   8:148  0 119.6G  0 part
   sdk      8:160  0   500G  0 disk
   sdl      8:176  0   120G  0 disk
   |-sdl1   8:177  0     4M  0 part
   |-sdl3   8:179  0   384M  0 part
   `-sdl4   8:180  0 119.6G  0 part /sysroot
   sdm      8:192  0   500G  0 disk
   sdn      8:208  0   120G  0 disk
   |-sdn1   8:209  0     4M  0 part
   |-sdn3   8:211  0   384M  0 part /boot
   `-sdn4   8:212  0 119.6G  0 part
   sdo      8:224  0   500G  0 disk
   sdp      8:240  0   120G  0 disk
   |-sdp1   8:241  0     4M  0 part
   |-sdp3   8:243  0   384M  0 part
   `-sdp4   8:244  0 119.6G  0 part

   In this example, for worker-0, the available local devices of 500G are sda, sdc, sde,sdg, sdi, sdk, sdm,sdo.

3. Repeat the above step for all the other worker nodes that have the storage devices to be used by OpenShift Data Foundation. See this Knowledge Base article for more details.

Procedure

1. Log into the OpenShift Web Console.
2. In openshift-local-storage namespace Click Operators → Installed Operators to view the installed operators.
3. Click the Local Storage installed operator.
4. On the Operator Details page, click the Local Volume link.
5. Click Create Local Volume.
6. Click on YAML view for configuring Local Volume.

7. Define a LocalVolume custom resource for block PVs using the following YAML.

   apiVersion: local.storage.openshift.io/v1
   kind: LocalVolume
   metadata:
     name: localblock
     namespace: openshift-local-storage
   spec:
     logLevel: Normal
     managementState: Managed
     nodeSelector:
       nodeSelectorTerms:
         - matchExpressions:
             - key: kubernetes.io/hostname
               operator: In
               values:
                 - worker-0
                 - worker-1
                 - worker-2
     storageClassDevices:
       - devicePaths:
           - /dev/sda
         storageClassName: localblock
         volumeMode: Block

   The above definition selects sda local device from the worker-0, worker-1 and worker-2 nodes. The localblock storage class is created and persistent volumes are provisioned from sda.

   Important

   Specify appropriate values of nodeSelector as per your environment. The device name should be same on all the worker nodes. You can also specify more than one devicePaths.

8. Click Create.

9. Confirm whether diskmaker-manager pods and Persistent Volumes are created.

   1. For Pods

      1. Click Workloads → Pods from the left pane of the OpenShift Web Console.
      2. Select openshift-local-storage from the Project drop-down list.
      3. Check if there are diskmaker-manager pods for each of the worker node that you used while creating LocalVolume CR.

   2. For Persistent Volumes

      1. Click Storage → PersistentVolumes from the left pane of the OpenShift Web Console.

      2. Check the Persistent Volumes with the name local-pv-*. Number of Persistent Volumes will be equivalent to the product of number of worker nodes and number of storage devices provisioned while creating localVolume CR.

         Important

         • The flexible scaling feature is enabled only when the storage cluster that you created with three or more nodes are spread across fewer than the minimum requirement of three availability zones.

           For information about flexible scaling, see knowledgebase article on Scaling OpenShift Data Foundation cluster using YAML when flexible scaling is enabled.

         • Flexible scaling features get enabled at the time of deployment and can not be enabled or disabled later on.

10. In the OpenShift Web Console, click Operators → Installed Operators to view all the installed operators.

    Ensure that the Project selected is openshift-storage.

11. Click on the OpenShift Data Foundation operator and then click Create StorageSystem.

12. In the Backing storage page, perform the following:

    1. Select Full Deployment for the Deployment type option.
    2. Select the Use an existing StorageClass option.

    3. Select the required Storage Class that you used while installing LocalVolume.

       By default, it is set to none.

    4. Optional: Select Use Ceph RBD as the default StorageClass. This avoids having to manually annotate a StorageClass.

    5. Optional: Select Use external PostgreSQL checkbox to use an external PostgreSQL [Technology preview].

       This provides high availability solution for Multicloud Object Gateway where the PostgreSQL pod is a single point of failure.

       1. Provide the following connection details:

          • Username
          • Password
          • Server name and Port
          • Database name
       2. Select Enable TLS/SSL checkbox to enable encryption for the Postgres server.
    6. Click Next.

13. In the Capacity and nodes page, configure the following:

    1. Available raw capacity is populated with the capacity value based on all the attached disks associated with the storage class. This takes some time to show up. The Selected nodes list shows the nodes based on the storage class.

    2. In the Configure performance section, select one of the following performance profiles:

       • Lean

         Use this in a resource constrained environment with minimum resources that are lower than the recommended. This profile minimizes resource consumption by allocating fewer CPUs and less memory.

       • Balanced (default)

         Use this when recommended resources are available. This profile provides a balance between resource consumption and performance for diverse workloads.

       • Performance

         Use this in an environment with sufficient resources to get the best performance. This profile is tailored for high performance by allocating ample memory and CPUs to ensure optimal execution of demanding workloads.

         Note

         You have the option to configure the performance profile even after the deployment using the Configure performance option from the options menu of the StorageSystems tab.

         Important

         Before selecting a resource profile, make sure to check the current availability of resources within the cluster. Opting for a higher resource profile in a cluster with insufficient resources might lead to installation failures.

         For more information about resource requirements, see Resource requirement for performance profiles.

    3. Optional: Select the Taint nodes checkbox to dedicate the selected nodes for OpenShift Data Foundation.
    4. Click Next.

14. Optional: In the Security and network page, configure the following based on your requirements:

    1. To enable encryption, select Enable data encryption for block and file storage.

       1. Select either one or both the encryption levels:

          • Cluster-wide encryption

            Encrypts the entire cluster (block and file).

          • StorageClass encryption

            Creates encrypted persistent volume (block only) using encryption enabled storage class.

       2. Optional: Select the Connect to an external key management service checkbox. This is optional for cluster-wide encryption.

          1. From the Key Management Service Provider drop-down list, either select Vault or Thales CipherTrust Manager (using KMIP). If you selected Vault, go to the next step. If you selected Thales CipherTrust Manager (using KMIP), go to step iii.

          2. Select an Authentication Method.

             Using Token authentication method

             • Enter a unique Connection Name, host Address of the Vault server ('https://<hostname or ip>'), Port number and Token.

             • Expand Advanced Settings to enter additional settings and certificate details based on your Vault configuration:

               • Enter the Key Value secret path in Backend Path that is dedicated and unique to OpenShift Data Foundation.
               • Optional: Enter TLS Server Name and Vault Enterprise Namespace.
               • Upload the respective PEM encoded certificate file to provide the CA Certificate, Client Certificate and Client Private Key .
               • Click Save and skip to step iv.

             Using Kubernetes authentication method

             • Enter a unique Vault Connection Name, host Address of the Vault server ('https://<hostname or ip>'), Port number and Role name.

             • Expand Advanced Settings to enter additional settings and certificate details based on your Vault configuration:

               • Enter the Key Value secret path in Backend Path that is dedicated and unique to OpenShift Data Foundation.
               • Optional: Enter TLS Server Name and Authentication Path if applicable.
               • Upload the respective PEM encoded certificate file to provide the CA Certificate, Client Certificate and Client Private Key .
               • Click Save and skip to step iv.

          3. To use Thales CipherTrust Manager (using KMIP) as the KMS provider, follow the steps below:

             1. Enter a unique Connection Name for the Key Management service within the project.

             2. In the Address and Port sections, enter the IP of Thales CipherTrust Manager and the port where the KMIP interface is enabled. For example:

                • Address: 123.34.3.2
                • Port: 5696
             3. Upload the Client Certificate, CA certificate, and Client Private Key.
             4. If StorageClass encryption is enabled, enter the Unique Identifier to be used for encryption and decryption generated above.
             5. The TLS Server field is optional and used when there is no DNS entry for the KMIP endpoint. For example, kmip_all_<port>.ciphertrustmanager.local.

          4. Select a Network.

             1. Select Default (OVN) network as Multus is not yet supported on OpenShift Data Foundation on IBM Power.
          5. Click Next.

    2. To enable in-transit encryption, select In-transit encryption.

       1. Select a Network.
       2. Click Next.
15. In the Data Protection page, if you are configuring Regional-DR solution for Openshift Data Foundation then select the Prepare cluster for disaster recovery(Regional-DR only) checkbox, else click Next.

16. In the Review and create page::

    1. Review the configurations details. To modify any configuration settings, click Back to go back to the previous configuration page.
    2. Click Create StorageSystem.

Procedure

1. Click Workloads → Pods from the left pane of the OpenShift Web Console.

2. Select openshift-storage from the Project drop-down list.

   Note

   If the Show default projects option is disabled, use the toggle button to list all the default projects.

   For more information on the expected number of pods for each component and how it varies depending on the number of nodes, see Table 3.1, “Pods corresponding to OpenShift Data Foundation cluster”.

3. Verify that the following pods are in running and completed state by clicking the Running and the Completed tabs:

   Table 3.1. Pods corresponding to OpenShift Data Foundation cluster

   Component	Corresponding pods
   OpenShift Data Foundation Operator	ocs-operator-* (1 pod on any storage node) ocs-metrics-exporter-* (1 pod on any storage node) odf-operator-controller-manager-* (1 pod on any storage node) odf-console-* (1 pod on any storage node) csi-addons-controller-manager-* (1 pod on any storage node)
   Rook-ceph Operator	rook-ceph-operator-* (1  pod on any storage node)
   UX Backend	ux-backend-server-* (1  pod on any storage node)
   Multicloud Object Gateway	noobaa-operator-* (1 pod on any storage node) noobaa-core-* (1 pod on any storage node) noobaa-db-pg-* (1 pod on any storage node) noobaa-endpoint-* (1 pod on any storage node)
   MON	rook-ceph-mon-* (3  pods on each storage node)
   MGR	rook-ceph-mgr-* (1 pod on any storage node)
   MDS	rook-ceph-mds-ocs-storagecluster-cephfilesystem-* (2 pods distributed across storage node)
   RGW	rook-ceph-rgw-ocs-storagecluster-cephobjectstore-* (1 pod on any storage node)
   CSI	cephfs csi-cephfsplugin-* (1 pod on each storage node) csi-cephfsplugin-provisioner-* (2 pods distributed across storage nodes) rbd csi-rbdplugin-* (1 pod on each storage node) csi-rbdplugin-provisioner-* (2 pods distributed across storage nodes)
   rook-ceph-crashcollector	rook-ceph-crashcollector-* (1  pod on each storage node)
   OSD	rook-ceph-osd-* (1 pod for each device) rook-ceph-osd-prepare-* (1 pod for each device)

Procedure

1. In the OpenShift Web Console, click Storage → Data Foundation.
2. Click the Storage Systems tab and then click on ocs-storagecluster-storagesystem.
3. In the Status card of Block and File dashboard under Overview tab, verify that both Storage Cluster and Data Resiliency has a green tick mark.
4. In the Details card, verify that the cluster information is displayed.

Procedure

1. In the OpenShift Web Console, click Storage → Data Foundation.

2. In the Status card of the Overview tab, click Storage System and then click the storage system link from the pop up that appears.

   1. In the Status card of the Object tab, verify that both Object Service and Data Resiliency have a green tick.
   2. In the Details card, verify that the MCG information is displayed.

Procedure

1. Click Storage → Storage Classes from the left pane of the OpenShift Web Console.

2. Verify that the following storage classes are created with the OpenShift Data Foundation cluster creation:

   • ocs-storagecluster-ceph-rbd
   • ocs-storagecluster-cephfs
   • openshift-storage.noobaa.io
   • ocs-storagecluster-ceph-rgw

Procedure

1. Log in to the OpenShift Web Console.
2. Click Operators → OperatorHub.
3. Type local storage in the Filter by keyword…​ box to find the Local Storage Operator from the list of operators and click on it.

4. Set the following options on the Install Operator page:

   1. Update channel as stable.
   2. Installation Mode as A specific namespace on the cluster.
   3. Installed Namespace as Operator recommended namespace openshift-local-storage.
   4. Approval Strategy as Automatic.
5. Click Install.

Procedure

1. Log in to the OpenShift Web Console.
2. Click Operators → OperatorHub.
3. Scroll or type OpenShift Data Foundation into the Filter by keyword box to find the OpenShift Data Foundation Operator.
4. Click Install.

5. Set the following options on the Install Operator page:

   1. Update Channel as stable-4.15.
   2. Installation Mode as A specific namespace on the cluster.
   3. Installed Namespace as Operator recommended namespace openshift-storage. If Namespace openshift-storage does not exist, it is created during the operator installation.

6. Select Approval Strategy as Automatic or Manual.

   If you select Automatic updates, then the Operator Lifecycle Manager (OLM) automatically upgrades the running instance of your Operator without any intervention.

   If you select Manual updates, then the OLM creates an update request. As a cluster administrator, you must then manually approve that update request to update the Operator to a newer version.

7. Ensure that the Enable option is selected for the Console plugin.
8. Click Install.

Procedure

1. Log into the OpenShift Web Console.
2. In openshift-local-storage namespace, click Operators → Installed Operators to view the installed operators.
3. Click the Local Storage installed operator.
4. On the Operator Details page, click the Local Volume link.
5. Click Create Local Volume.
6. Click on YAML view for configuring Local Volume.

7. Define a LocalVolume custom resource for filesystem PVs using the following YAML.

   apiVersion: local.storage.openshift.io/v1
   kind: LocalVolume
   metadata:
     name: localblock
     namespace: openshift-local-storage
   spec:
     logLevel: Normal
     managementState: Managed
     nodeSelector:
       nodeSelectorTerms:
         - matchExpressions:
             - key: kubernetes.io/hostname
               operator: In
               values:
                 - worker-0
                 - worker-1
                 - worker-2
     storageClassDevices:
       - devicePaths:
           - /dev/sda
         storageClassName: localblock
         volumeMode: Filesystem

   The above definition selects sda local device from the worker-0, worker-1 and worker-2 nodes. The localblock storage class is created and persistent volumes are provisioned from sda.

   Important

   Specify appropriate values of nodeSelector as per your environment. The device name should be same on all the worker nodes. You can also specify more than one devicePaths.

8. Click Create.

9. In the OpenShift Web Console, click Operators → Installed Operators to view all the installed operators.

   Ensure that the Project selected is openshift-storage.

10. Click OpenShift Data Foundation operator and then click Create StorageSystem.
11. In the Backing storage page, select Multicloud Object Gateway for Deployment type.

12. Select the Use an existing StorageClass option for Backing storage type .

    1. Select the Storage Class that you used while installing LocalVolume.
13. Click Next.

14. Optional: In the Security page, select the Connect to an external key management service checkbox. This is optional for cluster-wide encryption.

    1. From the Key Management Service Provider drop down list, either select Vault or Thales CipherTrust Manager (using KMIP). If you selected Vault, go to the next step. If you selected Thales CipherTrust Manager (using KMIP), go to step iii.

    2. Select an Authentication Method.

       Using Token authentication method

       • Enter a unique Connection Name, host Address of the Vault server ('https://<hostname or ip>'), Port number and Token.

       • Expand Advanced Settings to enter additional settings and certificate details based on your Vault configuration:

         • Enter the Key Value secret path in Backend Path that is dedicated and unique to OpenShift Data Foundation.
         • Optional: Enter TLS Server Name and Vault Enterprise Namespace.
         • Upload the respective PEM encoded certificate file to provide the CA Certificate, Client Certificate and Client Private Key .
         • Click Save and skip to step iv.

       Using Kubernetes authentication method

       • Enter a unique Vault Connection Name, host Address of the Vault server ('https://<hostname or ip>'), Port number and Role name.

       • Expand Advanced Settings to enter additional settings and certificate details based on your Vault configuration:

         • Enter the Key Value secret path in the Backend Path that is dedicated and unique to OpenShift Data Foundation.
         • Optional: Enter TLS Server Name and Authentication Path if applicable.
         • Upload the respective PEM encoded certificate file to provide the CA Certificate, Client Certificate, and Client Private Key.
         • Click Save and skip to step iv.

    3. To use Thales CipherTrust Manager (using KMIP) as the KMS provider, follow the steps below:

       1. Enter a unique Connection Name for the Key Management service within the project.

       2. In the Address and Port sections, enter the IP of Thales CipherTrust Manager and the port where the KMIP interface is enabled. For example:

          • Address: 123.34.3.2
          • Port: 5696
       3. Upload the Client Certificate, CA certificate, and Client Private Key.
       4. If StorageClass encryption is enabled, enter the Unique Identifier to be used for encryption and decryption generated above.
       5. The TLS Server field is optional and used when there is no DNS entry for the KMIP endpoint. For example, kmip_all_<port>.ciphertrustmanager.local.
    4. Select a Network.
    5. Click Next.

15. In the Review and create page, review the configuration details:

    To modify any configuration settings, click Back.

16. Click Create StorageSystem.