Chapter 2. Deploy OpenShift Data Foundation using local storage devices

Procedure

1. Log in to the OpenShift Web Console.
2. Click Ecosystem Software Catalog.
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 Ecosystem Software Catalog.
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.20.
   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)"
   $ AUDIENCE=$(echo '{"apiVersion": "authentication.k8s.io/v1", "kind": "TokenRequest"}' | kubectl create f --raw /api/v1/namespaces/default/serviceaccounts/default/token | jq -r '.spec.audiences' | jq -r .[0])
   $ kill $proxy_pid

   Or, for Vault version 1.21.0 and higher:

   $ oc proxy &
   $ proxy_pid=$!
   $ ISSUER=$(echo '{"apiVersion": "authentication.k8s.io/v1", "kind": "TokenRequest"}' \   | kubectl create f --raw /api/v1/namespaces/default/serviceaccounts/default/token \   | jq -r '.status.token' \   | cut -d . -f2 \   | base64 -d \   | jq '.iss')
   $ AUDIENCE=$(echo '{"apiVersion": "authentication.k8s.io/v1", "kind": "TokenRequest"}' | kubectl create f --raw /api/v1/namespaces/default/serviceaccounts/default/token | jq -r '.spec.audiences' | jq -r .[0])
   $ 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"

   Or, for Vault version 1.21.0 and higher:

   $ oc exec -n vault -ti vault-0 – \
       vault write auth/kubernetes/config \
       token_reviewer_jwt="$SA_JWT_TOKEN" \
       kubernetes_host="$OCP_HOST" \
       kubernetes_ca_cert="$SA_CA_CRT" \
       issuer="$ISSUER"\
       token_audience="$AUDIENCE"

   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 Ecosystem 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 Storage Data Foundation Storage Systems Create StorageSystem.

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

       Important

       OpenShift Data Foundation ships PostgreSQL images maintained by Red Hat, which are used to store metadata for the Multicloud Object Gateway. This PostgreSQL usage is at the application level.

       As a result, OpenShift Data Foundation does not perform database-level optimizations or in-depth insights.

       If customers have their own PostgreSQL that is well-maintained and optimized, we recommend using it. OpenShift Data Foundation supports external PostgreSQL instances.

       Any PostgreSQL-related issues requiring code changes or deep technical analysis may need to be addressed upstream. This could result in longer resolution times.

       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.

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

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

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