Deploying OpenShift Data Foundation using IBM Z infrastructure

Procedure

1. 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

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

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

3. Create a token matching the above policy.

   $ vault token create -policy=odf -format json

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.9.
   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.

   4. 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.

   5. Ensure that the Enable option is selected for the Console plugin.
   6. Click Install.

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 either 4.9 or stable.
   2. Installation mode as A specific namespace on the cluster.
   3. Installed Namespace as Operator recommended namespace openshift-local-storage.
   4. Update approval as Automatic.
5. Click Install.

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
   bmworker01    Ready    worker   6h45m   v1.16.2
   bmworker02    Ready    worker   6h45m   v1.16.2
   bmworker03    Ready    worker   6h45m   v1.16.2

2. Log in to each worker node that is used for OpenShift Data Foundation resources and find the unique by-id device name for each available raw block device.

   $ oc debug node/<node name>

   Example output:

   $ oc debug node/bmworker01
   Starting pod/bmworker01-debug ...
   To use host binaries, run `chroot /host`
   Pod IP: 10.0.135.71
   If you don't see a command prompt, try pressing enter.
   sh-4.2# chroot /host
   sh-4.4# lsblk
   NAME                         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
   loop0                          7:0    0   500G  0 loop
   sda                            8:0    0   120G  0 disk
   |-sda1                         8:1    0   384M  0 part /boot
   `-sda4                         8:4    0 119.6G  0 part
   `-coreos-luks-root-nocrypt   253:0    0 119.6G  0 dm   /sysroot
   sdb                            8:16   0   500G  0 disk

   In this example, for bmworker01, the available local device is sdb.

3. Identify the unique ID for each of the devices selected in Step 2.

   sh-4.4#ls -l /dev/disk/by-id/  | grep sdb
   lrwxrwxrwx. 1 root root  9 Feb  3 16:49 scsi-360050763808104bc2800000000000259 -> ../../sdb
   lrwxrwxrwx. 1 root root  9 Feb  3 16:49 scsi-SIBM_2145_00e020412f0aXX00 -> ../../sdb
   lrwxrwxrwx. 1 root root  9 Feb  3 16:49 scsi-0x60050763808104bc2800000000000259 -> ../../sdb

   In the above example, the ID for the local device sdb

   scsi-0x60050763808104bc2800000000000259

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

Procedure

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

   Ensure that the Project selected is openshift-storage.

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

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

   1. Select the Create a new StorageClass using the local storage devices option.
   2. Expand Advanced and select Full Deployment for the Deployment type option.

   3. Click Next.

      Important

      You are prompted to install the Local Storage Operator if it is not already installed. Click Install, and follow the procedure as described in Installing Local Storage Operator.

4. In the Create local volume set page, provide the following information:

   1. Enter a name for the LocalVolumeSet and the StorageClass.

      By default, the local volume set name appears for the storage class name. You can change the name.

   2. Choose one of the following:

      • Disks on all nodes

        Uses the available disks that match the selected filters on all the nodes.

      • Disks on selected nodes

        Uses the available disks that match the selected filters only on the selected nodes.

        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 the Add capacity using YAML section in Scaling Storage guide.

        • If the nodes selected do not match the OpenShift Data Foundation cluster requirement of an aggregated 30 CPUs and 72 GiB of RAM, a minimal cluster is deployed.

          For minimum starting node requirements, see the Resource requirements section in the Planning guide.

   3. From the available list of Disk Type, select SSD/NVME.

   4. Expand the Advanced section and set the following options:

      Volume Mode	Block is selected by default.
      Device Type	Select one or more device type from the dropdown list.
      Disk Size	Set a minimum size of 100GB for the device and maximum available size of the device that needs to be included.
      Maximum Disks Limit	This indicates the maximum number of PVs that can be created on a node. If this field is left empty, then PVs are created for all the available disks on the matching nodes.

   5. Click Next.

      A pop-up to confirm the creation of LocalVolumeSet is displayed.

   6. Click Yes to continue.

5. 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. Click Next.

6. Optional: In the Security and network page, configure the following based on your requirement:

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

   2. Choose one or both of the following Encryption level:

      • Cluster-wide encryption

        Encrypts the entire cluster (block and file).

      • StorageClass encryption

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

   3. Select Connect to an external key management service checkbox. This is optional for cluster-wide encryption.

      1. Key Management Service Provider is set to Vault by default.
      2. Enter Vault Service Name, host Address of Vault server ('https://<hostname or ip>''), Port number and Token.

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

         1. Enter the Key Value secret path in Backend Path that is dedicated and unique to OpenShift Data Foundation.
         2. Optional: Enter TLS Server Name and Vault Enterprise Namespace.
         3. Upload the respective PEM encoded certificate file to provide CA Certificate, Client Certificate and Client Private Key.
         4. Click Save.
   4. Select Default (SDN) as Multus is not yet supported on OpenShift Data Foundation on IBM Z infrastructure.
   5. Click Next.

7. In the Review and create page::

   1. Review the configuration 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 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 about 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. Click the Running and Completed tabs to verify that the following pods are in Running and Completed state:

   Table 3.1. Pods corresponding to OpenShift Data Foundation cluster

   Component	Corresponding pods
   OpenShift Data Foundation Operator	ocs-operator-* (1 pod on any worker node) ocs-metrics-exporter-* (1 pod on any worker node) odf-operator-controller-manager-* (1 pod on any worker node) odf-console-* (1 pod on any worker node)
   Rook-ceph Operator	rook-ceph-operator-* (1 pod on any worker node)
   Multicloud Object Gateway	noobaa-operator-* (1 pod on any worker 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 distributed across storage nodes)
   MGR	rook-ceph-mgr-* (1 pod on any storage node)
   MDS	rook-ceph-mds-ocs-storagecluster-cephfilesystem-* (2 pods distributed across storage nodes)
   RGW	rook-ceph-rgw-ocs-storagecluster-cephobjectstore-* (1 pod on any storage node)
   CSI	cephfs csi-cephfsplugin-* (1 pod on each worker node) csi-cephfsplugin-provisioner-* (2 pods distributed across worker nodes) rbd csi-rbdplugin-* (1 pod on each worker node) csi-rbdplugin-provisioner-* (2 pods distributed across worker 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-ocs-deviceset-* (1 pod for each device)

Procedure

1. In the OpenShift Web Console, click Storage → OpenShift 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 → OpenShift 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

1. Delete the volume snapshots that are using OpenShift Data Foundation.

   1. List the volume snapshots from all the namespaces.

      $ oc get volumesnapshot --all-namespaces

   2. From the output of the previous command, identify and delete the volume snapshots that are using OpenShift Data Foundation.

      $ oc delete volumesnapshot <VOLUME-SNAPSHOT-NAME> -n <NAMESPACE>

      <VOLUME-SNAPSHOT-NAME>

      Is the name of the volume snapshot

      <NAMESPACE>

      Is the project namespace

2. Delete PVCs and OBCs that are using OpenShift Data Foundation.

   In the default uninstall mode (graceful), the uninstaller waits till all the PVCs and OBCs that use OpenShift Data Foundation are deleted.

   If you want to delete the Storage Cluster without deleting the PVCs, you can set the uninstall mode annotation to forced and skip this step. Doing so results in orphan PVCs and OBCs in the system.

   1. Delete OpenShift Container Platform monitoring stack PVCs using OpenShift Data Foundation.

      See Removing monitoring stack from OpenShift Data Foundation

   2. Delete OpenShift Container Platform Registry PVCs using OpenShift Data Foundation.

      Removing OpenShift Container Platform registry from OpenShift Data Foundation

   3. Delete OpenShift Container Platform logging PVCs using OpenShift Data Foundation.

      Removing the cluster logging operator from OpenShift Data Foundation

   4. Delete the other PVCs and OBCs provisioned using OpenShift Data Foundation.

      • Given below is a sample script to identify the PVCs and OBCs provisioned using OpenShift Data Foundation. The script ignores the PVCs that are used internally by OpenShift Data Foundation.

        #!/bin/bash
        
        RBD_PROVISIONER="openshift-storage.rbd.csi.ceph.com"
        CEPHFS_PROVISIONER="openshift-storage.cephfs.csi.ceph.com"
        NOOBAA_PROVISIONER="openshift-storage.noobaa.io/obc"
        RGW_PROVISIONER="openshift-storage.ceph.rook.io/bucket"
        
        NOOBAA_DB_PVC="noobaa-db"
        NOOBAA_BACKINGSTORE_PVC="noobaa-default-backing-store-noobaa-pvc"
        
        # Find all the OCS StorageClasses
        OCS_STORAGECLASSES=$(oc get storageclasses | grep -e "$RBD_PROVISIONER" -e "$CEPHFS_PROVISIONER" -e "$NOOBAA_PROVISIONER" -e "$RGW_PROVISIONER" | awk '{print $1}')
        
        # List PVCs in each of the StorageClasses
        for SC in $OCS_STORAGECLASSES
        do
                echo "======================================================================"
                echo "$SC StorageClass PVCs and OBCs"
                echo "======================================================================"
                oc get pvc  --all-namespaces --no-headers 2>/dev/null | grep $SC | grep -v -e "$NOOBAA_DB_PVC" -e "$NOOBAA_BACKINGSTORE_PVC"
                oc get obc  --all-namespaces --no-headers 2>/dev/null | grep $SC
                echo
        done

        Note

        Omit RGW_PROVISIONER for cloud platforms.

      • Delete the OBCs.

        $ oc delete obc <obc-name> -n <project-name>

        <obc-name>

        Is the name of the OBC

        <project-name>

        Is the name of the project

      • Delete the PVCs.

        $ oc delete pvc <pvc-name> -n <project-name>

        <pvc-name>

        Is the name of the PVC

        <project-name>

        Is the name of the project

        Note

        Ensure that you have removed any custom backing stores, bucket classes, etc., created in the cluster.

3. Delete the Storage System object and wait for the removal of the associated resources.

   $ oc delete -n openshift-storage storagesystem --all --wait=true

4. Check the cleanup pods if the uninstall.ocs.openshift.io/cleanup-policy was set to delete(default) and ensure that their status is Completed.

   $ oc get pods -n openshift-storage | grep -i cleanup

   Example output:

   NAME                                READY   STATUS      RESTARTS   AGE
   cluster-cleanup-job-<xx>        	0/1     Completed   0          8m35s
   cluster-cleanup-job-<yy>     		0/1     Completed   0          8m35s
   cluster-cleanup-job-<zz>     		0/1     Completed   0          8m35s

5. Confirm that the directory /var/lib/rook is now empty. This directory is empty only if the uninstall.ocs.openshift.io/cleanup-policy annotation was set to delete(default).

   $ for i in $(oc get node -l cluster.ocs.openshift.io/openshift-storage= -o jsonpath='{ .items[*].metadata.name }'); do oc debug node/${i} -- chroot /host  ls -l /var/lib/rook; done

6. If encryption was enabled at the time of install, remove dm-crypt managed device-mapper mapping from the OSD devices on all the OpenShift Data Foundation nodes.

   1. Create a debug pod and chroot to the host on the storage node.

      $ oc debug node/<node-name>

      $ chroot /host

      <node-name>

      Is the name of the node

   2. Get Device names and make note of the OpenShift Data Foundation devices.

      $ dmsetup ls

      Example output:

      ocs-deviceset-0-data-0-57snx-block-dmcrypt (253:1)

   3. Remove the mapped device.

      $ cryptsetup luksClose --debug --verbose ocs-deviceset-0-data-0-57snx-block-dmcrypt

      Important

      If the above command gets stuck due to insufficient privileges, run the following commands:

      • Press CTRL+Z to exit the above command.

      • Find PID of the process which was stuck.

        $ ps -ef | grep crypt

      • Terminate the process using kill command.

        $ kill -9 <PID>

        <PID>

        Is the process ID

      • Verify that the device name is removed.

        $ dmsetup ls

7. Delete the namespace and wait till the deletion is complete. You need to switch to another project if openshift-storage is the active project.

   For example:

   $ oc project default

   $ oc delete project openshift-storage --wait=true --timeout=5m

   The project is deleted if the following command returns a NotFound error.

   $ oc get project openshift-storage

   Note

   While uninstalling OpenShift Data Foundation, if namespace is not deleted completely and remains in Terminating state, perform the steps in Troubleshooting and deleting remaining resources during Uninstall to identify objects that are blocking the namespace from being terminated.

8. Delete local storage operator configurations if you have deployed OpenShift Data Foundation using local storage devices. See Removing local storage operator configurations.

9. Unlabel the storage nodes.

   $ oc label nodes  --all cluster.ocs.openshift.io/openshift-storage-

   $ oc label nodes  --all topology.rook.io/rack-

10. Remove the OpenShift Data Foundation taint if the nodes were tainted.

    $ oc adm taint nodes --all node.ocs.openshift.io/storage-

11. Confirm all the Persistent volumes (PVs) provisioned using OpenShift Data Foundation are deleted. If there is any PV left in the Released state, delete it.

    $ oc get pv

    $ oc delete pv <pv-name>

    <pv-name>

    Is the name of the PV

12. Remove the CustomResourceDefinitions.

    $ oc delete crd backingstores.noobaa.io bucketclasses.noobaa.io cephblockpools.ceph.rook.io cephclusters.ceph.rook.io cephfilesystems.ceph.rook.io cephnfses.ceph.rook.io cephobjectstores.ceph.rook.io cephobjectstoreusers.ceph.rook.io noobaas.noobaa.io ocsinitializations.ocs.openshift.io storageclusters.ocs.openshift.io cephclients.ceph.rook.io cephobjectrealms.ceph.rook.io cephobjectzonegroups.ceph.rook.io cephobjectzones.ceph.rook.io cephrbdmirrors.ceph.rook.io storagesystems.odf.openshift.io --wait=true --timeout=5m

13. To ensure that OpenShift Data Foundation is uninstalled completely, on the OpenShift Container Platform Web Console,

    1. Click Storage.
    2. Verify that OpenShift Data Foundation no longer appears under Storage.

Procedure

1. List the pods and PVCs that are currently running in the openshift-monitoring namespace.

   $ oc get pod,pvc -n openshift-monitoring

   Example output:

   NAME                           READY   STATUS    RESTARTS   AGE
   pod/alertmanager-main-0         3/3     Running   0          8d
   pod/alertmanager-main-1         3/3     Running   0          8d
   pod/alertmanager-main-2         3/3     Running   0          8d
   pod/cluster-monitoring-
   operator-84457656d-pkrxm        1/1     Running   0          8d
   pod/grafana-79ccf6689f-2ll28    2/2     Running   0          8d
   pod/kube-state-metrics-
   7d86fb966-rvd9w                 3/3     Running   0          8d
   pod/node-exporter-25894         2/2     Running   0          8d
   pod/node-exporter-4dsd7         2/2     Running   0          8d
   pod/node-exporter-6p4zc         2/2     Running   0          8d
   pod/node-exporter-jbjvg         2/2     Running   0          8d
   pod/node-exporter-jj4t5         2/2     Running   0          6d18h
   pod/node-exporter-k856s         2/2     Running   0          6d18h
   pod/node-exporter-rf8gn         2/2     Running   0          8d
   pod/node-exporter-rmb5m         2/2     Running   0          6d18h
   pod/node-exporter-zj7kx         2/2     Running   0          8d
   pod/openshift-state-metrics-
   59dbd4f654-4clng                3/3     Running   0          8d
   pod/prometheus-adapter-
   5df5865596-k8dzn                1/1     Running   0          7d23h
   pod/prometheus-adapter-
   5df5865596-n2gj9                1/1     Running   0          7d23h
   pod/prometheus-k8s-0            6/6     Running   1          8d
   pod/prometheus-k8s-1            6/6     Running   1          8d
   pod/prometheus-operator-
   55cfb858c9-c4zd9                1/1     Running   0          6d21h
   pod/telemeter-client-
   78fc8fc97d-2rgfp                3/3     Running   0          8d
   
   NAME                                                              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
   persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-0   Bound    pvc-0d519c4f-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-storagecluster-ceph-rbd   8d
   persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-1   Bound    pvc-0d5a9825-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-storagecluster-ceph-rbd   8d
   persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-2   Bound    pvc-0d6413dc-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-storagecluster-ceph-rbd   8d
   persistentvolumeclaim/my-prometheus-claim-prometheus-k8s-0        Bound    pvc-0b7c19b0-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-storagecluster-ceph-rbd   8d
   persistentvolumeclaim/my-prometheus-claim-prometheus-k8s-1        Bound    pvc-0b8aed3f-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-storagecluster-ceph-rbd   8d

2. Edit the monitoring configmap.

   $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

   Remove any config sections that reference the OpenShift Data Foundation storage classes as shown in the following example and save it.

   Before editing

   . . . apiVersion: v1 data: config.yaml: | alertmanagerMain: volumeClaimTemplate: metadata: name: my-alertmanager-claim spec: resources: requests: storage: 40Gi storageClassName: ocs-storagecluster-ceph-rbd prometheusK8s: volumeClaimTemplate: metadata: name: my-prometheus-claim spec: resources: requests: storage: 40Gi storageClassName: ocs-storagecluster-ceph-rbd kind: ConfigMap metadata: creationTimestamp: "2019-12-02T07:47:29Z" name: cluster-monitoring-config namespace: openshift-monitoring resourceVersion: "22110" selfLink: /api/v1/namespaces/openshift-monitoring/configmaps/cluster-monitoring-config uid: fd6d988b-14d7-11ea-84ff-066035b9efa8 . . .

   After editing

   . . . apiVersion: v1 data: config.yaml: | kind: ConfigMap metadata: creationTimestamp: "2019-11-21T13:07:05Z" name: cluster-monitoring-config namespace: openshift-monitoring resourceVersion: "404352" selfLink: /api/v1/namespaces/openshift-monitoring/configmaps/cluster-monitoring-config uid: d12c796a-0c5f-11ea-9832-063cd735b81c . . .

   In this example, alertmanagerMain and prometheusK8s monitoring components are using the OpenShift Data Foundation PVCs.

3. Delete the relevant PVCs. Make sure you delete all the PVCs that are consuming the storage classes.

   $ oc delete -n openshift-monitoring pvc <pvc-name> --wait=true --timeout=5m

   <pvc-name>

   Is the name of the PVC

Procedure

1. Edit the configs.imageregistry.operator.openshift.io object and remove the content in the storage section.

   $ oc edit configs.imageregistry.operator.openshift.io

   Before editing

   . . . storage: pvc: claim: registry-cephfs-rwx-pvc . . .

   After editing

   . . . storage: emptyDir: {} . . .

   In this example, the PVC is called registry-cephfs-rwx-pvc, which is now safe to delete.

2. Delete the PVC.

   $ oc delete pvc <pvc-name> -n openshift-image-registry --wait=true --timeout=5m

   <pvc-name>

   Is the name of the PVC

Procedure

1. Remove the ClusterLogging instance in the namespace.

   $ oc delete clusterlogging instance -n openshift-logging --wait=true --timeout=5m

   The PVCs in the openshift-logging namespace are now safe to delete.

2. Delete the PVCs.

   $ oc delete pvc <pvc-name> -n openshift-logging --wait=true --timeout=5m

   <pvc-name>

   Is the name of the PVC