Chapter 2. Deploy OpenShift Data Foundation using local storage devices

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

   Copy to Clipboard Toggle word wrap

   For vault KV secret engine API, version 2:

   $ vault secrets enable -path=odf kv-v2

   Copy to Clipboard Toggle word wrap

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 -

   Copy to Clipboard Toggle word wrap

3. Create a token that matches the above policy:

   $ vault token create -policy=odf -format json

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a service account:

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

   Copy to Clipboard Toggle word wrap

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

   For example:

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

   Copy to Clipboard Toggle word wrap

2. Create clusterrolebindings and clusterroles:

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

   Copy to Clipboard Toggle word wrap

   For example:

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   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)

   Copy to Clipboard Toggle word wrap

5. Retrieve the OCP cluster endpoint.

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

   $ vault auth enable kubernetes

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap
   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"

   Copy to Clipboard Toggle word wrap

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

   For Vault KV secret engine API, version 1:

   $ vault secrets enable -path=odf kv

   Copy to Clipboard Toggle word wrap

   For Vault KV secret engine API, version 2:

   $ vault secrets enable -path=odf kv-v2

   Copy to Clipboard Toggle word wrap

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 -

   Copy to Clipboard Toggle word wrap

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

    Copy to Clipboard Toggle word wrap

    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

    Copy to Clipboard Toggle word wrap

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=

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

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>

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

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

       Note

       Once you select the initial storage capacity, cluster expansion is performed only using the selected usable capacity (three times of raw storage).

    2. The Selected nodes list shows the nodes based on the storage class.
    3. Optional: Select the Taint nodes checkbox to dedicate the selected nodes for OpenShift Data Foundation.

    4. Optional [Technology preview]: Select the Add replica-1 pool checkbox to deploy OpenShift Data Foundation with a single replica. This avoids redundant data copies and allows resiliency management on the application level. In order to enable replica-1 pool, atleast 2 storage disks should be attached to each of the storage nodes.

       Warning

       Enabling this feature creates a single replica pool without data replication, increasing the risk of data loss, data corruption, and potential system instability if your application does not have its own replication.

       Important

       Single replica deployment is a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

       For more information, see Technology Preview Features Support Scope.

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