Red Hat OpenStack Platform を使用した OpenShift Data Foundation のデプロイおよび管理

手順

1. OpenShift Web コンソールにログインします。
2. Operators → OperatorHub をクリックします。
3. スクロールするか、OpenShift Data Foundation を Filter by keyword ボックスに入力し、OpenShift Data Foundation Operator を検索します。
4. Install をクリックします。

5. Install Operator ページで、以下のオプションを設定します。

   1. Channel を stable-4.18 として更新します。
   2. Installation Mode オプションで A specific namespace on the cluster を選択します。
   3. Installed Namespace に Operator recommended namespace openshift-storage を選択します。namespace openshift-storage が存在しない場合は、Operator のインストール時に作成されます。

   4. 承認ストラテジーを Automatic または Manual として選択します。

      Automatic (自動) 更新を選択すると、Operator Lifecycle Manager (OLM) は介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。

      Manual 更新を選択すると、OLM は更新要求を作成します。クラスター管理者は、Operator を新しいバージョンに更新できるように更新要求を手動で承認する必要があります。

   5. Console プラグイン に Enable オプションが選択されていることを確認します。
   6. Install をクリックします。

手順

1. Vault で Key/Value (KV) バックエンドパスを有効にします。

   Vault KV シークレットエンジン API の場合は、バージョン 1 です。

   $ vault secrets enable -path=odf kv

   Vault KV シークレットエンジン API の場合は、バージョン 2 を使用します。

   $ vault secrets enable -path=odf kv-v2

2. シークレットに対して書き込み操作または削除操作を実行するようにユーザーを制限するポリシーを作成します。

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

3. 上記のポリシーに一致するトークンを作成します。

   $ vault token create -policy=odf -format json

手順

1. サービスアカウントを作成します。

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

   ここで、<serviceaccount_name> はサービスアカウントの名前を指定します。

   以下に例を示します。

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

2. clusterrolebindings と clusterroles を作成します。

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

   以下に例を示します。

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

3. serviceaccount トークンおよび CA 証明書のシークレットを作成します。

   $ 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

   ここで、<serviceaccount_name> は、前の手順で作成したサービスアカウントです。

4. シークレットからトークンと CA 証明書を取得します。

   $ 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. OCP クラスターエンドポイントを取得します。

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

6. サービスアカウントの発行者を取得します。

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

7. 前の手順で収集した情報を使用して、Vault で Kubernetes 認証方法を設定します。

   $ 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"

   重要

   発行者が空の場合は Vault で Kubernetes 認証方法を設定します。

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

8. Vault で Key/Value (KV) バックエンドパスを有効にします。

   Vault KV シークレットエンジン API の場合は、バージョン 1 を使用します。

   $ vault secrets enable -path=odf kv

   Vault KV シークレットエンジン API の場合は、バージョン 2 を使用します。

   $ vault secrets enable -path=odf kv-v2

9. シークレットに対して write または delete 操作を実行するようにユーザーを制限するポリシーを作成します。

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

10. ロールを作成します。

    $ 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

    ロール odf-rook-ceph-op は、後でストレージシステムの作成中に KMS 接続の詳細を設定するときに使用されます。

    $ 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

手順

1. OpenShift Web コンソールで、Operators → Installed Operators をクリックし、インストールされた Operator を表示します。

   選択された Project が openshift-storage であることを確認します。

2. OpenShift Data Foundation Operator をクリックした後、Create StorageSystem をクリックします。

3. Backing storage ページで、以下を選択します。

   1. Deployment type オプションで Full Deployment を選択します。
   2. Use an existing StorageClass オプションを選択します。

   3. Storage Class を選択します。

      デフォルトでは standard に設定されます。

   4. オプション: 外部 PostgreSQL を使用するには、Use external PostgreSQL チェックボックスを選択します [テクノロジープレビュー]。

      これにより、PostgreSQL Pod が単一障害点となるマルチクラウドオブジェクトゲートウェイの高可用性ソリューションが提供されます。

      1. 以下の接続の詳細を指定します。

         • ユーザー名
         • パスワード
         • サーバー名 と ポート
         • データベース名
      2. Enable TLS/SSL チェックボックスを選択して、Postgres サーバーの暗号化を有効にします。
   5. Next をクリックします。

4. Capacity and nodes ページで、必要な情報を提供します。

   1. ドロップダウンリストから Requested Capacity の値を選択します。デフォルトで、これは 2 TiB に設定されます。

      注記

      初期ストレージ容量を選択すると、クラスターの拡張は、選択された使用可能な容量を使用してのみ実行されます (raw ストレージの 3 倍)。

   2. Select Nodes セクションで、少なくとも 3 つの利用可能なノードを選択します。

   3. Configure performance セクションで、以下のパフォーマンスプロファイルのいずれかを選択します。

      • Lean

        これは、最小リソースが推奨値よりも少ない、リソースに制約のある環境で使用します。このプロファイルでは、割り当てられる CPU とメモリーの数が少なくなり、リソースの消費が最小限に抑えられます。

      • balanced (デフォルト)

        推奨リソースが利用可能な場合にこれを使用します。このプロファイルは、さまざまなワークロードのリソース消費とパフォーマンスのバランスを提供します。

      • パフォーマンス

        最高のパフォーマンスを得るために十分なリソースがある環境でこれを使用してください。このプロファイルは、負荷の高いワークロードを最適に実行できるように十分なメモリーと CPU を割り当てることで、高いパフォーマンスを実現するように調整されています。

        注記

        StorageSystems タブのオプションメニューから Configure performance オプションを使用して、デプロイメント後にパフォーマンスプロファイルを設定するオプションがあります。

        重要

        リソースプロファイルを選択する前に、クラスター内のリソースの現在の可用性を必ず確認してください。リソースが不十分なクラスターでより高いリソースプロファイルを選択すると、インストールが失敗する可能性があります。

        リソース要件の詳細は、パフォーマンスプロファイルのリソース要件 を参照してください。

   4. オプション: 選択したノードを OpenShift Data Foundation 専用にする場合は、Taint nodes チェックボックスを選択します。

      複数のアベイラビリティーゾーンを持つクラウドプラットフォームの場合は、ノードが異なる場所/アベイラビリティーゾーンに分散されていることを確認します。

      選択したノードが集約された 30 CPU および 72 GiB の RAM の OpenShift Data Foundation クラスターの要件と一致しない場合は、最小クラスターがデプロイされます。ノードの最小要件は、プランニング ガイドの リソース要件 セクションを参照してください。

   5. Next をクリックします。

5. オプション: Security and network ページで、要件に応じて以下を設定します。

   1. 暗号化を有効にするには、Enable data encryption for block and file storage を選択します。

      1. 暗号化レベルのいずれかまたは両方を選択します。

         • クラスター全体の暗号化

           クラスター全体を暗号化します (ブロックおよびファイル)。

         • StorageClass の暗号化

           暗号化対応のストレージクラスを使用して、暗号化された永続ボリューム (ブロックのみ) を作成します。

      2. オプション: Connect to an external key management service チェックボックスを選択します。これはクラスター全体の暗号化の場合はオプションになります。

         1. Key Management Service Provider ドロップダウンリストから、次のいずれかのプロバイダーを選択し、必要な詳細情報を入力します。

            • Vault

              1. Authentication Method を選択します。

                 • トークン認証方式の使用

                   • Vault ('https://<hostname or ip>') サーバーの一意の Connection Name、ホストの Address、Port 番号および Token を入力します。

                   • Advanced Settings をデプロイメントして、Vault 設定に基づいて追加の設定および証明書の詳細を入力します。

                     • OpenShift Data Foundation 専用かつ特有のキーと値のシークレットパスを Backend Path に入力します。
                   • オプション: TLS Server Name および Vault Enterprise Namespace を入力します。
                   • それぞれの PEM でエンコードされた証明書ファイルをアップロードし、CA 証明書、クライアント証明書、および クライアントの秘密鍵 を提供します。
                   • Save をクリックします。

                 • Kubernetes 認証方式の使用

                   • Vault ('https://<hostname or ip>') サーバーの一意の Connection Name、ホストの Address、Port 番号、および Role 名を入力します。

                   • Advanced Settings をデプロイメントして、Vault 設定に基づいて追加の設定および証明書の詳細を入力します。

                     • OpenShift Data Foundation 専用かつ特有のキーと値のシークレットパスを Backend Path に入力します。
                     • 該当する場合は、TLS Server Name および Authentication Path を入力します。
                     • PEM でエンコードされた、該当の証明書ファイルをアップロードし、CA Certificate、Client Certificate、および Client Private Key を指定します。

                   • Save をクリックします。

                     注記

                     Vault KMS のキーローテーションを有効にする必要がある場合は、ストレージクラスターの作成後に OpenShift Web コンソールで以下のコマンドを実行します。

                     oc patch storagecluster ocs-storagecluster -n openshift-storage --type=json -p '[{"op": "add", "path":"/spec/encryption/keyRotation/enable", "value": true}]'

            • Thales CipherTrust Manager (KMIP を使用)

              1. プロジェクト内のキー管理サービスの一意の Connection Name を入力します。

              2. Address および Port セクションで、Thales CipherTrust Manager の IP と、KMIP インターフェイスが有効になっているポートを入力します。以下に例を示します。

                 • Address: 123.34.3.2
                 • Port: 5696
              3. Client Certificate、CA certificate、および Client Private Key をアップロードします。
              4. StorageClass 暗号化が有効になっている場合は、上記で生成された暗号化および復号化に使用する一意の識別子を入力します。
              5. TLS Server フィールドはオプションであり、KMIP エンドポイントの DNS エントリーがない場合に使用します。たとえば、kmip_all_<port>.ciphertrustmanager.local などです。

   2. 転送中の暗号化を有効にするには、In-transit encryption を選択します。

      1. Network を選択します。
      2. Next をクリックします。

6. Review and create ページで、設定の詳細を確認します。

   設定を変更するには、Back をクリックします。

7. Create StorageSystem をクリックします。

手順

1. OpenShift Web コンソールにログインします。
2. Operators → OperatorHub をクリックします。
3. スクロールするか、OpenShift Data Foundation を Filter by keyword ボックスに入力し、OpenShift Data Foundation Operator を検索します。
4. Install をクリックします。

5. Install Operator ページで、以下のオプションを設定します。

   1. Channel を stable-4.18 として更新します。
   2. Installation Mode オプションで A specific namespace on the cluster を選択します。
   3. Installed Namespace に Operator recommended namespace openshift-storage を選択します。namespace openshift-storage が存在しない場合は、Operator のインストール時に作成されます。

   4. 承認ストラテジーを Automatic または Manual として選択します。

      Automatic (自動) 更新を選択すると、Operator Lifecycle Manager (OLM) は介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。

      Manual 更新を選択すると、OLM は更新要求を作成します。クラスター管理者は、Operator を新しいバージョンに更新できるように更新要求を手動で承認する必要があります。

   5. Console プラグイン に Enable オプションが選択されていることを確認します。
   6. Install をクリックします。

手順

1. Operators → Installed Operators をクリックし、インストールされた Operator をすべて表示します。

   選択された Project が openshift-storage であることを確認します。

2. Storage Cluster の OpenShift Data Foundation → Create Instance リンクをクリックします。

3. Mode を External に選択します。デフォルトでは、Internal はデプロイメントモードとして選択されます。

   図3.1 Create Storage Cluster 形式の外部クラスターへの接続

   
4. Connect to external cluster セクションで、Download Script リンクをクリックして、Ceph クラスターの詳細を抽出するために python スクリプトをダウンロードします。

5. Red Hat Ceph Storage (RHCS) クラスターの詳細を抽出するには、RHCS 管理者に問い合わせた上で Red Hat Ceph Storage でダウンロードした python スクリプトを admin key を使用して実行します。

   1. RHCS ノードで以下のコマンドを実行し、利用可能な引数のリストを表示します。

      # python3 ceph-external-cluster-details-exporter.py --help

      重要

      Red Hat Ceph Storage 4.x クラスターが Red Hat Enterprise Linux 7.x (RHEL 7.x) クラスターにデプロイされている場合は、python3 ではなく python を使用します。

      注記

      MON コンテナー内 (コンテナー化されたデプロイメント) または MON ノード (rpm デプロイメント) からスクリプトを実行することもできます。

   2. RHCS クラスターから外部クラスターの詳細を取得するには、以下のコマンドを実行します。

      # python3 ceph-external-cluster-details-exporter.py \
      --rbd-data-pool-name <rbd block pool name>  [optional arguments]

      以下に例を示します。

      # python3 ceph-external-cluster-details-exporter.py --rbd-data-pool-name ceph-rbd --monitoring-endpoint xxx.xxx.xxx.xxx --monitoring-endpoint-port xxxx --rgw-endpoint xxx.xxx.xxx.xxx:xxxx --run-as-user client.ocs

      上記の例は、以下のようになります。

      • --rbd-data-pool-name は、OpenShift Data Foundation でブロックストレージを提供するために使用される必須のパラメーターです。
      • --rgw-endpoint は任意です。OpenShift Data Foundation の Ceph Rados Gateway でオブジェクトストレージをプロビジョニングする場合に、このパラメーターを指定します。<ip_address>:<port> の形式でエンドポイントを指定します。
      • --monitoring-endpoint は任意です。これは、OpenShift Container Platform クラスターから到達できるアクティブな ceph-mgr の IP アドレスです。指定しないと、値が自動的に入力されます。
      • --monitoring-endpoint-port は任意です。これは --monitoring-endpoint で指定された ceph-mgr Prometheus エクスポーターに関連付けられるポートです。指定しないと、値が自動的に入力されます。

      • -- run-as-user は、スクリプトで作成される Ceph ユーザーの名前を指定するために使用されるオプションのパラメーターです。このパラメーターを指定しないと、デフォルトのユーザー名 client.healthchecker が作成されます。新規ユーザーのパーミッションは以下のように設定されます。

        • caps: [mgr] はコマンド設定を許可します。
        • caps: [mon] は r を許可し、コマンド quorum_status を許可し、コマンド version を許可します。

        • caps: [osd] allow rwx pool=RGW_POOL_PREFIX.rgw.meta, allow r pool=.rgw.root, allow rw pool=RGW_POOL_PREFIX.rgw.control, allow rx pool=RGW_POOL_PREFIX.rgw.log, allow x pool=RGW_POOL_PREFIX.rgw.buckets.index

          python スクリプトを使用して生成された JSON 出力の例:

          [{"name": "rook-ceph-mon-endpoints", "kind": "ConfigMap", "data": {"data": "xxx.xxx.xxx.xxx:xxxx", "maxMonId": "0", "mapping": "{}"}}, {"name": "rook-ceph-mon", "kind": "Secret", "data": {"admin-secret": "admin-secret", "fsid": "<fs-id>", "mon-secret": "mon-secret"}}, {"name": "rook-ceph-operator-creds", "kind": "Secret", "data": {"userID": "client.healthchecker", "userKey": "<user-key>"}}, {"name": "rook-csi-rbd-node", "kind": "Secret", "data": {"userID": "csi-rbd-node", "userKey": "<user-key>"}}, {"name": "ceph-rbd", "kind": "StorageClass", "data": {"pool": "ceph-rbd"}}, {"name": "monitoring-endpoint", "kind": "CephCluster", "data": {"MonitoringEndpoint": "xxx.xxx.xxx.xxx", "MonitoringPort": "xxxx"}}, {"name": "rook-csi-rbd-provisioner", "kind": "Secret", "data": {"userID": "csi-rbd-provisioner", "userKey": "<user-key>"}}, {"name": "rook-csi-cephfs-provisioner", "kind": "Secret", "data": {"adminID": "csi-cephfs-provisioner", "adminKey": "<admin-key>"}}, {"name": "rook-csi-cephfs-node", "kind": "Secret", "data": {"adminID": "csi-cephfs-node", "adminKey": "<admin-key>"}}, {"name": "cephfs", "kind": "StorageClass", "data": {"fsName": "cephfs", "pool": "cephfs_data"}}, {"name": "ceph-rgw", "kind": "StorageClass", "data": {"endpoint": "xxx.xxx.xxx.xxx:xxxx", "poolPrefix": "default"}}]

   3. JSON 出力を .json 拡張のあるファイルに保存します。

      注記

      OpenShift Data Foundation がシームレスに機能するには、JSON ファイルを使用してアップロードされるパラメーター (RGW エンドポイント、CephFS の詳細、RBD プールなど) が、ストレージクラスターの作成後も RHCS 外部クラスターで変更されないままであることを確認します。

6. External cluster metadata → Browse をクリックして、JSON ファイルを選択し、アップロードします。

   JSON ファイルの内容が入力され、テキストボックスに表示されます。

   図3.2 JSON ファイルの内容

   

7. Create をクリックします。

   Create ボタンは、.json ファイルのアップロード後にのみ有効になります。

検証手順

1. インストールされたストレージクラスターの最後の Status が緑色のチェックマークと共に Phase: Ready と表示されていることを確認します。

   • Operators → Installed Operators → Storage Cluster のリンクをクリックして、ストレージクラスターのインストールのステータスを表示します。
   • または、Operator Details タブで、Storage Cluster タブをクリックしてステータスを表示できます。
2. OpenShift Data Foundation、Pod および StorageClass が正常にインストールされていることを確認するには、外部モードの OpenShift Data Foundation インストールの確認 を参照してください。

手順

1. OpenShift Web コンソールにログインします。
2. Operators → OperatorHub をクリックします。
3. スクロールするか、OpenShift Data Foundation を Filter by keyword ボックスに入力し、OpenShift Data Foundation Operator を検索します。
4. Install をクリックします。

5. Install Operator ページで、以下のオプションを設定します。

   1. Channel を stable-4.18 として更新します。
   2. Installation Mode オプションで A specific namespace on the cluster を選択します。
   3. Installed Namespace に Operator recommended namespace openshift-storage を選択します。namespace openshift-storage が存在しない場合は、Operator のインストール時に作成されます。

   4. 承認ストラテジーを Automatic または Manual として選択します。

      Automatic (自動) 更新を選択すると、Operator Lifecycle Manager (OLM) は介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。

      Manual 更新を選択すると、OLM は更新要求を作成します。クラスター管理者は、Operator を新しいバージョンに更新できるように更新要求を手動で承認する必要があります。

   5. Console プラグイン に Enable オプションが選択されていることを確認します。
   6. Install をクリックします。

手順

1. OpenShift Web コンソールで、Operators → Installed Operators をクリックし、インストールされた Operator を表示します。

   選択された Project が openshift-storage であることを確認します。

2. OpenShift Data Foundation Operator をクリックした後、Create StorageSystem をクリックします。

3. Backing storage ページで、以下を選択します。

   1. Deployment type の Multicloud Object Gateway を選択します。
   2. Use an existing StorageClass オプションを選択します。
   3. Next をクリックします。

4. オプション: Connect to an external key management service チェックボックスを選択します。これはクラスター全体の暗号化の場合はオプションになります。

   1. Key Management Service Provider ドロップダウンリストから、Vault または Thales CipherTrust Manager (using KMIP) を選択します。Vault を選択した場合は、次の手順に進みます。Thales CipherTrust Manager (using KMIP) を選択した場合は、手順 iii に進みます。

   2. Authentication Method を選択します。

      トークン認証方式の使用

      • Vault ('https://<hostname or ip>') サーバーの一意の Connection Name、ホストの Address、Port 番号および Token を入力します。

      • Advanced Settings をデプロイメントして、Vault 設定に基づいて追加の設定および証明書の詳細を入力します。

        • OpenShift Data Foundation 専用かつ特有のキーと値のシークレットパスを Backend Path に入力します。
        • オプション: TLS Server Name および Vault Enterprise Namespace を入力します。
        • PEM でエンコードされた、該当の証明書ファイルをアップロードし、CA Certificate、Client Certificate、および Client Private Key を指定します。
        • Save をクリックして、手順 iv に進みます。

      Kubernetes 認証方式の使用

      • Vault ('https://<hostname or ip>') サーバーの一意の Connection Name、ホストの Address、Port 番号、および Role 名を入力します。

      • Advanced Settings をデプロイメントして、Vault 設定に基づいて追加の設定および証明書の詳細を入力します。

        • OpenShift Data Foundation 専用かつ特有のキーと値のシークレットパスを Backend Path に入力します。
        • 該当する場合は、TLS Server Name および Authentication Path を入力します。
        • PEM でエンコードされた、該当の証明書ファイルをアップロードし、CA Certificate、Client Certificate、および Client Private Key を指定します。
        • Save をクリックして、手順 iv に進みます。

   3. Thales CipherTrust Manager (using KMIP) を KMS プロバイダーとして使用するには、次の手順に従います。

      1. プロジェクト内のキー管理サービスの一意の Connection Name を入力します。

      2. Address および Port セクションで、Thales CipherTrust Manager の IP と、KMIP インターフェイスが有効になっているポートを入力します。以下に例を示します。

         • Address: 123.34.3.2
         • Port: 5696
      3. Client Certificate、CA certificate、および Client Private Key をアップロードします。
      4. StorageClass 暗号化が有効になっている場合は、上記で生成された暗号化および復号化に使用する一意の識別子を入力します。
      5. TLS Server フィールドはオプションであり、KMIP エンドポイントの DNS エントリーがない場合に使用します。たとえば、kmip_all_<port>.ciphertrustmanager.local などです。
   4. Network を選択します。
   5. Next をクリックします。

5. Review and create ページで、設定の詳細を確認します。

   設定を変更するには、Back をクリックします。

6. Create StorageSystem をクリックします。

手順

1. Storage → StorageClasses をクリックします。
2. Create Storage Class をクリックします。
3. ストレージクラスの Name および Description を入力します。

4. Reclaim Policy は、デフォルトオプションとして Delete に設定されています。この設定を使用します。

   回収ポリシーをストレージクラスで Retain に変更すると、永続ボリューム要求 (PVC) を削除した後でも、永続ボリューム (PV) は Released 状態のままになります。

5. ボリュームバインディングモード は、デフォルトオプションとして WaitForConsumer に設定されています。

   Immediate オプションを選択すると、PVC の作成時に PV がすぐに作成されます。

6. 永続ボリュームをプロビジョニングするためのプラグインとして、RBD または CephFS Provisioner を選択します。
7. ワークロードの Storage system を選択します。

8. 一覧から既存の ストレージプール を選択するか、新規プールを作成します。

   注記

   双方向レプリケーションデータ保護ポリシーは、デフォルト以外の RBD プールでのみサポートされます。追加のプールを作成することで双方向レプリケーションを使用できます。replica 2 プールのデータの可用性と整合性に関する考慮事項は、ナレッジベースのカスタマーソリューション記事 を参照してください。

   新規プールの作成

   1. Create New Pool をクリックします。
   2. Pool name を入力します。
   3. Data Protection Policy として 2-way-Replication または 3-way-Replication を選択します。

   4. データを圧縮する必要がある場合は、Enable compression を選択します。

      圧縮を有効にするとアプリケーションのパフォーマンスに影響がある可能性があり、書き込まれるデータがすでに圧縮または暗号化されている場合は効果的ではない可能性があります。圧縮を有効にする前に書き込まれたデータは圧縮されません。

   5. Create をクリックして新規ストレージプールを作成します。
   6. プールの作成後に Finish をクリックします。

9. オプション: Enable Encryption のチェックボックスを選択します。
10. Create をクリックしてストレージクラスを作成します。

手順

1. OpenShift Web コンソールで、Storage → StorageClasses に移動します。
2. Create Storage Class をクリックします。
3. ストレージクラスの Name および Description を入力します。
4. Reclaim Policy は Delete または Retain のいずれかを選択します。デフォルトでは、Delete が選択されます。
5. Volume binding モード に Immediate または WaitForFirstConsumer を選択します。WaitForConsumer はデフォルトオプションとして設定されます。
6. 永続ボリュームをプロビジョニングするのに使用されるプラグインである RBD Provisioner openshift-storage.rbd.csi.ceph.com を選択します。
7. ボリュームデータが保存される Storage Pool をリストから選択するか、新規プールを作成します。

8. Enable encryption チェックボックスを選択します。

   • 次のいずれかのオプションを選択し、KMS 接続の詳細を設定します。

     • Choose existing KMS connection: ドロップダウンリストから既存の KMS 接続を選択します。このリストは、csi-kms-connection-details ConfigMap で利用可能な接続の詳細から設定されます。

       1. ドロップダウンから Provider を選択します。
       2. リストから特定のプロバイダーの Key service を選択します。

     • Create new KMS connection: これは、vaulttoken と Thales CipherTrust Manager (using KMIP) にのみ適用されます。

       1. 次のいずれかの Key Management Service Provider を選択し、必要な詳細情報を入力します。

          • Vault

            1. 一意の Connection Name、Vault サーバーのホストの Address ('https://<ホスト名または IP>')、ポート番号、および Token を入力します。

            2. Advanced Settings をデプロイメントして、Vault 設定に基づいて追加の設定および証明書の詳細を入力します。

               1. OpenShift Data Foundation 専用かつ特有のキーと値のシークレットパスを Backend Path に入力します。
               2. オプション: TLS Server Name および Vault Enterprise Namespace を入力します。
               3. PEM でエンコードされた、該当の証明書ファイルをアップロードし、CA Certificate、Client Certificate、および Client Private Key を指定します。
               4. Save をクリックします。

          • Thales CipherTrust Manager (KMIP を使用)

            1. 一意の Connection Name を入力します。
            2. Address および Port セクションで、Thales CipherTrust Manager の IP と、KMIP インターフェイスが有効になっているポートを入力します。たとえば、Address: 123.34.3.2、Port: 5696 などです。
            3. Client Certificate、CA certificate、および Client Private Key をアップロードします。
            4. 上記で生成された暗号化および復号化に使用する鍵の Unique Identifier を入力します。
            5. TLS Server フィールドはオプションであり、KMIP エンドポイントの DNS エントリーがない場合に使用します。たとえば、kmip_all_<port>.ciphertrustmanager.local などです。

          • Azure Key Vault (Azure プラットフォーム上の Azure ユーザーのみ)

            クライアント認証の設定とクライアント認証情報の取得は、Microsoft Azure を使用した OpenShift Data Foundation のデプロイ ガイドの OpenShift Data Foundation クラスターの作成 セクションの「前提条件」を参照してください。

            1. プロジェクト内のキー管理サービスの一意の Connection name を入力します。
            2. Azure Vault URL を入力します。
            3. Client ID を入力します。
            4. Tenant ID を入力します。
            5. Certificate ファイルを .PEM 形式でアップロードします。証明書ファイルには、クライアント証明書と秘密鍵が含まれている必要があります。
       2. Save をクリックします。
       3. Create をクリックします。

9. HashiCorp Vault 設定により、バックエンドパスによって使用されるキー/値 (KV) シークレットエンジン API バージョンの自動検出が許可されない場合は、ConfigMap を編集して vaultBackend パラメーターを追加します。

   注記

   vaultBackend は、バックエンドパスに関連付けられた KV シークレットエンジン API のバージョンを指定するために configmap に追加されるオプションのパラメーターです。値がバックエンドパスに設定されている KV シークレットエンジン API バージョンと一致していることを確認します。一致しない場合は、永続ボリューム要求 (PVC) の作成時に失敗する可能性があります。

   1. 新規に作成されたストレージクラスによって使用されている encryptionKMSID を特定します。

      1. OpenShift Web コンソールで、Storage → Storage Classes に移動します。
      2. Storage class 名 → YAML タブをクリックします。

      3. ストレージクラスによって使用されている encryptionKMSID を取得します。

         以下に例を示します。

         encryptionKMSID: 1-vault

   2. OpenShift Web コンソールで Workloads → ConfigMaps に移動します。
   3. KMS 接続の詳細を表示するには、csi-kms-connection-details をクリックします。

   4. ConfigMap を編集します。

      1. アクションメニュー (⋮) → Edit ConfigMap をクリックします。

      2. 以前に特定した encryptionKMSID に設定されるバックエンドに応じて、vaultBackend パラメーターを追加します。

         KV シークレットエンジン API バージョン 1 の場合は kv を、KV シークレットエンジン API バージョン 2 の場合は kv-v2 を、それぞれ割り当てることができます。

         以下に例を示します。

          kind: ConfigMap
          apiVersion: v1
          metadata:
            name: csi-kms-connection-details
          [...]
          data:
            1-vault: |-
              {
                "encryptionKMSType": "vaulttokens",
                "kmsServiceName": "1-vault",
                [...]
                "vaultBackend": "kv-v2"
              }
            2-vault: |-
              {
                "encryptionKMSType": "vaulttenantsa",
                [...]
                "vaultBackend": "kv"
              }

      3. 保存をクリックします。

手順

1. 使用するイメージレジストリーの永続ボリューム要求を作成します。

   1. OpenShift Web コンソールで、Storage → Persistent Volume Claims をクリックします。
   2. Project を openshift-image-registry に設定します。

   3. Create Persistent Volume Claim をクリックします。

      1. 上記で取得した利用可能なストレージクラスリストから、プロビジョナー openshift-storage.cephfs.csi.ceph.com で Storage Class を指定します。
      2. 永続ボリューム要求の Name を指定します (例: ocs4registry)。
      3. Shared Access (RWX) の Access Mode を指定します。
      4. 100 GB 以上の Size を指定します。

      5. Create をクリックします。

         新規永続ボリューム要求のステータスが Bound としてリスト表示されるまで待機します。

2. クラスターのイメージレジストリーを、新規の永続ボリューム要求を使用するように設定します。

   1. Administration → Custom Resource Definitions をクリックします。
   2. imageregistry.operator.openshift.io グループに関連付けられた Config カスタムリソース定義をクリックします。
   3. Instances タブをクリックします。
   4. クラスターインスタンスの横にある Action メニュー (⋮) → Edit Config をクリックします。

   5. イメージレジストリーの新規永続ボリューム要求を追加します。

      1. 以下を spec: の下に追加し、必要に応じて既存の storage: セクションを置き換えます。

           storage:
             pvc:
               claim: <new-pvc-name>

         以下に例を示します。

           storage:
             pvc:
               claim: ocs4registry

      2. Save をクリックします。

3. 新しい設定が使用されていることを確認します。

   1. Workloads → Pods をクリックします。
   2. Project を openshift-image-registry に設定します。
   3. 新規 image-registry-* Pod が Running のステータスと共に表示され、以前の image-registry-* Pod が終了していることを確認します。
   4. 新規の image-registry-* Pod をクリックし、Pod の詳細を表示します。
   5. Volumes までスクロールダウンし、registry-storage ボリュームに新規永続ボリューム要求に一致する Type があることを確認します (例: ocs4registry)。

手順

1. OpenShift Web コンソールで、Workloads → Config Maps に移動します。
2. Project ドロップダウンを openshift-monitoring に設定します。
3. Create Config Map をクリックします。

4. 以下の例を使用して新規の cluster-monitoring-config config map を定義します。

   山括弧 (<、>) 内の内容を独自の値に置き換えます (例: retention: 24h または storage: 40Gi)。

   storageClassName、をプロビジョナー openshift-storage.rbd.csi.ceph.com を使用する storageclass に置き換えます。以下の例では、storageclass の名前は ocs-storagecluster-ceph-rbd です。

   cluster-monitoring-config config map の例

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |
         prometheusK8s:
           retention: <time to retain monitoring files, for example 24h>
           volumeClaimTemplate:
             metadata:
               name: ocs-prometheus-claim
             spec:
               storageClassName: ocs-storagecluster-ceph-rbd
               resources:
                 requests:
                   storage: <size of claim, e.g. 40Gi>
         alertmanagerMain:
           volumeClaimTemplate:
             metadata:
               name: ocs-alertmanager-claim
             spec:
               storageClassName: ocs-storagecluster-ceph-rbd
               resources:
                 requests:
                   storage: <size of claim, e.g. 40Gi>

5. Create をクリックして、config map を保存し、作成します。

検証手順

1. 永続ボリューム要求が Pod にバインドされていることを確認します。

   1. Storage → Persistent Volume Claims に移動します。
   2. Project ドロップダウンを openshift-monitoring に設定します。

   3. 5 つの永続ボリューム要求が Bound (バインド) の状態で表示され、3 つの alertmanager-main-* Pod および 2 つの prometheus-k8s-* Pod に割り当てられていることを確認します。

      図7.1 作成済みのバインドされているストレージのモニタリング

      

2. 新規の alertmanager-main-* Pod が Running 状態で表示されることを確認します。

   1. Workloads → Pods に移動します。
   2. 新規の alertmanager-main-* Pod をクリックし、Pod の詳細を表示します。

   3. Volumes にスクロールダウンし、ボリュームに新規永続ボリューム要求のいずれかに一致する Type ocs-alertmanager-claim があることを確認します (例: ocs-alertmanager-claim-alertmanager-main-0)。

      図7.2 alertmanager-main-* Pod に割り当てられた永続ボリューム要求

      

3. 新規 prometheus-k8s-* Pod が Running 状態で表示されることを確認します。

   1. 新規 prometheus-k8s-* Pod をクリックし、Pod の詳細を表示します。

   2. Volumes までスクロールダウンし、ボリュームに新規の永続ボリューム要求のいずれかに一致する Type ocs-prometheus-claim があることを確認します (例: ocs-prometheus-claim-prometheus-k8s-0)。

      図7.3 prometheus-k8s-* Pod に割り当てられた永続ボリューム要求

      

手順

1. OpenShift Web Console で、Compute → Nodes をクリックし、テイントする必要のあるノードを選択します。
2. Details ページで、Edit taints をクリックします。
3. Key <nodes.openshift.ocs.io/storage>、Value <true>、および Effect<Noschedule> フィールドに値を入力します。
4. Save をクリックします。

手順

1. OpenShift Web コンソールにログインします。
2. Operators → Installed Operators をクリックします。
3. OpenShift Data Foundation Operator をクリックします。

4. Storage Systems タブをクリックします。

   1. ストレージシステム名の右側にある Action Menu (⋮) をクリックし、オプションメニューを拡張します。
   2. オプションメニューから Add Capacity を選択します。
   3. Storage Class を選択します。新しいストレージデバイスのプロビジョニングに使用するストレージクラスを選択します。

1. Add をクリックします。

   1. ステータスを確認するには、Storage → Data Foundation に移動し、Status カードの Storage System に緑色のチェックマークが表示されていることを確認します。

手順

1. 使用するアプリケーションの永続ボリューム要求を作成します。

   1. OpenShift Web コンソールで、Storage → Persistent Volume Claims をクリックします。
   2. アプリケーション Pod の Project を設定します。

   3. Create Persistent Volume Claim をクリックします。

      1. OpenShift Data Foundation によって提供される Storage Class を指定します。
      2. PVC Name (例: myclaim) を指定します。

      3. 必要な Access Mode を選択します。

         注記

         IBM FlashSystem では Access Mode の Shared access (RWX) はサポートされません。

      4. Rados Block Device (RBD) の場合は、Access mode が ReadWriteOnce (RWO) であれば、必須の Volume mode を選択します。デフォルトのボリュームモードは、Filesystem です。
      5. アプリケーション要件に応じて Size を指定します。
      6. Create をクリックし、PVC のステータスが Bound になるまで待機します。

2. 新規または既存のアプリケーション Pod を新規 PVC を使用するように設定します。

   • 新規アプリケーション Pod の場合は、以下の手順を実行します。

     1. Workloads →Pods をクリックします。
     2. 新規アプリケーション Pod を作成します。

     3. spec: セクションの下に volumes: セクションを追加し、新規 PVC をアプリケーション Pod のボリュームとして追加します。

        volumes:
          - name: <volume_name>
            persistentVolumeClaim:
              claimName: <pvc_name>

        以下に例を示します。

        volumes:
          - name: mypd
            persistentVolumeClaim:
              claimName: myclaim

   • 既存のアプリケーション Pod の場合、以下の手順を実行します。

     1. Workloads →Deployment Configs をクリックします。
     2. アプリケーション Pod に関連付けられた必要なデプロイメント設定を検索します。
     3. Action メニュー (⋮) → Edit Deployment Config をクリックします。

     4. spec: セクションの下に volumes: セクションを追加し、新規 PVC をアプリケーション Pod のボリュームとして追加し、Save をクリックします。

        volumes:
          - name: <volume_name>
            persistentVolumeClaim:
              claimName: <pvc_name>

        以下に例を示します。

        volumes:
          - name: mypd
            persistentVolumeClaim:
              claimName: myclaim

3. 新しい設定が使用されていることを確認します。

   1. Workloads → Pods をクリックします。
   2. アプリケーション Pod の Project を設定します。
   3. アプリケーション Pod が Running ステータスで表示されていることを確認します。
   4. アプリケーション Pod 名をクリックし、Pod の詳細を表示します。
   5. Volumes セクションまでスクロールダウンし、ボリュームに新規永続ボリューム要求に一致する Type があることを確認します (例: myclaim)。

手順

1. OpenShift Web コンソールにログインします。
2. Storage → Persistent Volume Claims をクリックします。
3. Filter テキストボックスを使用して、必要な PVC 名を検索します。また、リストを絞り込むために Name または Label で PVC のリストをフィルターすることもできます。
4. 必要な PVC に対応する Status 列を確認します。
5. 必要な Name をクリックして PVC の詳細を表示します。

手順

1. OpenShift Web Console で、Storage → Data Foundation をクリックします。
2. Storage systems タブでストレージシステムを選択し、Overview → Block and File タブをクリックします。
3. Inventory カードを見つけ、エラーのある PVC の数を確認します。
4. Storage → Persistent Volume Claims をクリックします。
5. Filter テキストボックスを使用して、必要な PVC を検索します。
6. PVC 名をクリックし、Events に移動します。
7. 必要に応じて、または指示に応じてイベントに対応します。

手順

1. OpenShift Web コンソールで、Storage → Persistent Volume Claims をクリックします。

2. クローンを作成するには、以下のいずれかを実行します。

   • 必要な PVC の横にある Action メニュー (⋮) → Clone PVC をクリックします。
   • クローンを作成する必要のある PVC をクリックし、Actions → Clone PVC をクリックします。
3. クローンの Name を入力します。

4. 任意のアクセスモードを選択します。

   重要

   ReadOnlyMany (ROX) アクセスモードは開発者プレビュー機能であり、開発者プレビューのサポート制限の対象となります。開発者プレビューリリースは、実稼働環境で実行することは意図されておらず、Red Hat カスタマーポータルのケース管理システムではサポートされません。ReadOnlyMany 機能に関してサポートが必要な場合は、ocs-devpreview@redhat.com メーリングリストに連絡してください。Red Hat Development Team のメンバーが稼働状況とスケジュールに応じて可能な限り迅速に対応します。ROX アクセスモードの使用は、Creating a clone or restoring a snapshot with the new readonly access mode を参照してください。

5. 必要なクローンのサイズを入力します。

6. クローンを作成するストレージクラスを選択します。

   ストレージクラスは任意の RBD ストレージクラスにすることができ、必ずしも親 PVC と同じである必要はありません。

7. Clone をクリックします。新規 PVC の詳細ページにリダイレクトされます。

8. クローン作成された PVC のステータスが Bound になるまで待機します。

   クローン作成された PVC が Pod で使用できるようになります。このクローン作成された PVC は dataSource PVC とは切り離されています。

手順

1. OpenShift Web コンソールにログインし、Compute → Nodes をクリックします。
2. 置き換える必要のあるノードを特定します。その マシン名 をメモします。

3. ノードにスケジュール対象外 (unschedulable) のマークを付けます。

   $ oc adm cordon <node_name>

   <node_name>

   置き換える必要のあるノードの名前を指定します。

4. ノードをドレイン (解放) します。

   $ oc adm drain <node_name> --force --delete-emptydir-data=true --ignore-daemonsets

   重要

   このアクティビティーには、少なくとも 5〜10 分以上かかる場合があります。この期間中に生成された Ceph エラーは一時的なものであり、新しいノードにラベルを付けると自動的に解決され、機能します。

5. Compute → Machines をクリックします。必要なマシンを検索します。
6. 必要なマシンの横にある Action menu (⋮) → Delete Machine をクリックします。
7. Delete をクリックして、マシンが削除されたことを確認します。新しいマシンが自動的に作成されます。

8. 新規マシンが起動し、Running 状態に移行するまで待機します。

   重要

   このアクティビティーには、少なくとも 5〜10 分以上かかる場合があります。

9. Compute → Nodes をクリックします。新しいノードが Ready 状態にあることを確認します。

10. OpenShift Data Foundation ラベルを新規ノードに適用します。

    ユーザーインターフェイスから

    1. 新規ノードで、Action Menu (⋮) → Edit Labels をクリックします。
    2. cluster.ocs.openshift.io/openshift-storage を追加し、Save をクリックします。

    コマンドラインインターフェイスの使用

    • OpenShift Data Foundation ラベルを新規ノードに適用します。

    $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""

    <new_node_name>

    新しいノードの名前を指定します。

検証手順

1. 新しいノードが出力に存在することを確認します。

   $ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1

2. Workloads → Pods をクリックします。新しいノードの少なくとも次の Pod が Running 状態になっていることを確認します。

   • csi-cephfsplugin-*
   • csi-rbdplugin-*
3. 他の必要なすべての OpenShift Data Foundation Pod が Running 状態にあることを確認します。

4. 新しいオブジェクトストレージデバイス (OSD) Pod が置き換えるノードで実行されていることを確認します。

   $ oc get pods -o wide -n openshift-storage| egrep -i <new_node_name> | egrep osd

5. (オプション) クラスターでクラスター全体の暗号化が有効な場合は、新規 OSD デバイスが暗号化されていることを確認します。

   直前の手順で特定された新しい各ノードに以下を実行します。

   1. デバッグ Pod を作成し、選択した 1 つ以上のホストの chroot 環境を開きます。

      $ oc debug node/<node_name>

      $ chroot /host

   2. 使用可能なブロックデバイスのリストを表示します。

      $ lsblk

      1 つ以上の ocs-deviceset 名の横にある crypt キーワードを確認します。

6. 検証手順が失敗した場合は、Red Hat サポートにお問い合わせください。

手順

1. OpenShift Web コンソールにログインし、Compute → Nodes をクリックします。
2. 障害のあるノードを特定し、その Machine Name をクリックします。
3. Actions → Edit Annotations をクリックし、Add More をクリックします。
4. machine.openshift.io/exclude-node-draining を追加し、Save をクリックします。
5. Actions → Delete Machine をクリックしてから、Delete をクリックします。

6. 新しいマシンが自動的に作成されます。新規マシンが起動するのを待機します。

   重要

   このアクティビティーには、少なくとも 5〜10 分以上かかる場合があります。この期間中に生成された Ceph エラーは一時的なものであり、新しいノードにラベルを付けると自動的に解決され、機能します。

7. Compute → Nodes をクリックします。新しいノードが Ready 状態にあることを確認します。

8. 以下のいずれかを使用して、OpenShift Data Foundation ラベルを新規ノードに適用します。

   ユーザーインターフェイスから

   1. 新規ノードで、Action Menu (⋮) → Edit Labels をクリックします。
   2. cluster.ocs.openshift.io/openshift-storage を追加し、Save をクリックします。

   コマンドラインインターフェイスの使用

   • OpenShift Data Foundation ラベルを新規ノードに適用します。

   $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""

   <new_node_name>

   新しいノードの名前を指定します。

9. オプション: 障害のある Red Hat OpenStack Platform インスタンスが自動的に削除されない場合は、Red Hat OpenStack Platform コンソールからインスタンスを終了します。

検証手順

1. 新しいノードが出力に存在することを確認します。

   $ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1

2. Workloads → Pods をクリックします。新しいノードの少なくとも次の Pod が Running 状態になっていることを確認します。

   • csi-cephfsplugin-*
   • csi-rbdplugin-*
3. 他の必要なすべての OpenShift Data Foundation Pod が Running 状態にあることを確認します。

4. 新しいオブジェクトストレージデバイス (OSD) Pod が置き換えるノードで実行されていることを確認します。

   $ oc get pods -o wide -n openshift-storage| egrep -i <new_node_name> | egrep osd

5. (オプション) クラスターでクラスター全体の暗号化が有効な場合は、新規 OSD デバイスが暗号化されていることを確認します。

   直前の手順で特定された新しい各ノードに以下を実行します。

   1. デバッグ Pod を作成し、選択した 1 つ以上のホストの chroot 環境を開きます。

      $ oc debug node/<node_name>

      $ chroot /host

   2. 使用可能なブロックデバイスのリストを表示します。

      $ lsblk

      1 つ以上の ocs-deviceset 名の横にある crypt キーワードを確認します。

6. 検証手順が失敗した場合は、Red Hat サポートにお問い合わせください。

手順

1. 置き換える必要がある OSD と、その OSD がスケジュールされている OpenShift Container Platform ノードを特定します。

   $ oc get -n openshift-storage pods -l app=rook-ceph-osd -o wide

   出力例:

   rook-ceph-osd-0-6d77d6c7c6-m8xj6    0/1    CrashLoopBackOff    0    24h   10.129.0.16   compute-2   <none>           <none>
   rook-ceph-osd-1-85d99fb95f-2svc7    1/1    Running             0    24h   10.128.2.24   compute-0   <none>           <none>
   rook-ceph-osd-2-6c66cdb977-jp542    1/1    Running             0    24h   10.130.0.18   compute-1   <none>           <none>

   この例では、rook-ceph-osd-0-6d77d6c7c6-m8xj6 を置き換える必要があり、compute-2 は OSD がスケジュールされる OpenShift Container platform ノードです。

   注記

   置き換える OSD が正常である場合、Pod のステータスは Running になります。

2. 置き換えられる OSD の OSD デプロイメントをスケールダウンします。

   $ osd_id_to_remove=0
   $ oc scale -n openshift-storage deployment rook-ceph-osd-${osd_id_to_remove} --replicas=0

   ここで、osd_id_to_remove は Pod 名の rook-ceph-osd 接頭辞の直後にくる整数です。この例では、デプロイメント名は rook-ceph-osd-0 です。

   出力例:

   deployment.extensions/rook-ceph-osd-0 scaled

3. rook-ceph-osd Pod が停止していることを確認します。

   $ oc get -n openshift-storage pods -l ceph-osd-id=${osd_id_to_remove}

   出力例:

   No resources found.

   注記

   rook-ceph-osd Pod が terminating 状態にある場合は、force オプションを使用して Pod を削除します。

   $ oc delete pod rook-ceph-osd-0-6d77d6c7c6-m8xj6 --force --grace-period=0

   出力例:

   warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
     pod "rook-ceph-osd-0-6d77d6c7c6-m8xj6" force deleted

4. 障害の発生した OSD に関連付けられた永続ボリュームが失敗する場合、失敗した永続ボリュームの詳細を取得し、以下のコマンドを使用してそれらを削除します。

   $ oc get pv
   $ oc delete pv <failed-pv-name>

5. 新規 OSD を追加できるようにクラスターから古い OSD を削除します。

   1. 古い ocs-osd-removal ジョブを削除します。

      $ oc delete -n openshift-storage job ocs-osd-removal-${osd_id_to_remove}

      出力例:

      job.batch "ocs-osd-removal-0" deleted

   2. openshift-storage プロジェクトを変更します。

      $ oc project openshift-storage

   3. クラスターから以前の OSD を削除します。

      $ oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=${osd_id_to_remove} FORCE_OSD_REMOVAL=false |oc create -n openshift-storage -f -

      コマンドでコンマ区切りの OSD ID を追加して、複数の OSD を削除できます。(例: FAILED_OSD_IDS=0,1,2)

      3 つの OSD しかないクラスター、または OSD が削除された後にデータの 3 つのレプリカすべてを復元するのに十分なスペースがないクラスターでは、FORCE_OSD_REMOVAL 値を “true” に変更する必要があります。

      警告

      この手順により、OSD はクラスターから完全に削除されます。osd_id_to_remove の正しい値が指定されていることを確認します。

6. ocs-osd-removal-job Pod のステータスをチェックして、OSD が正常に削除されたことを確認します。

   Completed のステータスで、OSD の削除ジョブが正常に完了したことを確認します。

   # oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage

7. OSD の取り外しが完了したことを確認します。

   $ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 | egrep -i 'completed removal'

   出力例:

   2022-05-10 06:50:04.501511 I | cephosd: completed removal of OSD 0

   重要

   ocs-osd-removal-job が失敗し、Pod が予想される Completed の状態にない場合、追加のデバッグのために Pod ログを確認します。

   以下に例を示します。

   # oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1

8. 暗号化がインストール時に有効にされている場合は、それぞれの OpenShift Data Foundation ノードから削除された OSD デバイスから dm-crypt で管理される device-mapper マッピングを削除します。

   1. ocs-osd-removal-job Pod のログから、置き換えられた OSD の PVC 名を取得します。

      $ oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1  |egrep -i ‘pvc|deviceset’

      以下に例を示します。

      2021-05-12 14:31:34.666000 I | cephosd: removing the OSD PVC "ocs-deviceset-xxxx-xxx-xxx-xxx"

   2. 手順 #1 で特定されたノードごとに、以下を実行します。

      1. debug Pod を作成し、ストレージノードのホストに対して chroot を作成します。

         $ oc debug node/<node name>
         $ chroot /host

      2. 直前の手順で特定された PVC 名に基づいて関連するデバイス名を検索します。

         sh-4.4# dmsetup ls| grep <pvc name>
         ocs-deviceset-xxx-xxx-xxx-xxx-block-dmcrypt (253:0)

      3. マップ済みデバイスを削除します。

         $ cryptsetup luksClose --debug --verbose ocs-deviceset-xxx-xxx-xxx-xxx-block-dmcrypt

         注記

         権限が十分にないため、コマンドがスタックした場合には、以下のコマンドを実行します。

         • CTRL+Z を押して上記のコマンドを終了します。

         • スタックしたプロセスの PID を検索します。

           $ ps -ef | grep crypt

         • kill コマンドを使用してプロセスを終了します。

           $ kill -9 <PID>

         • デバイス名が削除されていることを確認します。

           $ dmsetup ls

9. ocs-osd-removal ジョブを削除します。

   $ oc delete -n openshift-storage job ocs-osd-removal-${osd_id_to_remove}

   出力例:

   job.batch "ocs-osd-removal-0" deleted

検証手順

1. 新しい OSD が実行されていることを確認します。

   $ oc get -n openshift-storage pods -l app=rook-ceph-osd

   出力例:

   rook-ceph-osd-0-5f7f4747d4-snshw                                  1/1     Running     0          4m47s
   rook-ceph-osd-1-85d99fb95f-2svc7                                  1/1     Running     0          1d20h
   rook-ceph-osd-2-6c66cdb977-jp542                                  1/1     Running     0          1d20h

2. Bound 状態の新しい PVC が作成されていることを確認します。

   $ oc get -n openshift-storage pvc

   出力例:

   NAME                           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
   db-noobaa-db-0                 Bound    pvc-b44ebb5e-3c67-4000-998e-304752deb5a7   50Gi       RWO            ocs-storagecluster-ceph-rbd   6d
   ocs-deviceset-0-data-0-gwb5l   Bound    pvc-bea680cd-7278-463d-a4f6-3eb5d3d0defe   512Gi      RWO            standard                      94s
   ocs-deviceset-1-data-0-w9pjm   Bound    pvc-01aded83-6ef1-42d1-a32e-6ca0964b96d4   512Gi      RWO            standard                      6d
   ocs-deviceset-2-data-0-7bxcq   Bound    pvc-5d07cd6c-23cb-468c-89c1-72d07040e308   512Gi      RWO            standard                      6d

3. (オプション) クラスターでクラスター全体の暗号化が有効な場合は、新規 OSD デバイスが暗号化されていることを確認します。

   1. 新規 OSD Pod が実行しているノードを特定します。

      $ oc get -n openshift-storage -o=custom-columns=NODE:.spec.nodeName pod/_<OSD-pod-name>_

      <OSD-pod-name>

      これは OSD Pod の名前です。

      以下に例を示します。

      $ oc get -n openshift-storage -o=custom-columns=NODE:.spec.nodeName pod/rook-ceph-osd-0-544db49d7f-qrgqm

      出力例:

      NODE
      compute-1

   2. 直前の手順で特定されたノードごとに、以下を実行します。

      1. デバッグ Pod を作成し、選択したホストの chroot 環境を開きます。

         $ oc debug node/<node name>
         $ chroot /host

      2. “lsblk” を実行し、ocs-deviceset 名の横にある “crypt” キーワードを確認します。

         $ lsblk

4. OpenShift Web コンソールにログインし、ストレージダッシュボードを表示します。

   図16.1 デバイスの置き換え後の OpenShift Container Platform ストレージダッシュボードの OSD ステータス

   

EUS アップグレードのワークフローの例:

1. ワーカーマシンプールを一時停止します。
2. OpenShift <4.y> → OpenShift <4.y+1> を更新します。
3. OpenShift Data Foundation <4.y> → OpenShift Data Foundation <4.y+1> を更新します。
4. OpenShift <4.y+1> → OpenShift <4.y+2> を更新します。
5. OpenShift Data Foundation <4.y+2> に更新します。
6. ワーカーマシンプールの一時停止を解除します。

1. OpenShift Container Platform の クラスターの更新 ドキュメントに従って OpenShift Container Platform を更新します。

2. Red Hat OpenShift Data Foundation を更新します。

   1. 更新に非接続環境を準備する には、Operator Lifecycle Manager を制限されたネットワークで使用するための Operator ガイドを参照し、OpenShift Data Foundation およびローカルストレージ Operator を使用している場合はこれらを更新できるようにします。
   2. マイナーリリース間の更新 は、Red Hat OpenShift Data Foundation 4.14 から 4.15 への更新 を参照してください。
   3. z-stream リリース間の更新 は、Red Hat OpenShift Data Foundation 4.15.x の 4.15.y への更新 を参照してください。
   4. 外部モードのデプロイメントを更新する場合 は、Red Hat OpenShift Data Foundation 外部シークレットの更新 のセクションにある手順も実行する必要があります。
   5. ローカルストレージを使用する場合は、Local Storage Operator を更新します。不明な場合は、Local Storage Operator デプロイメントの確認 を参照してください。

手順

1. OpenShift Web コンソールで、Operators → Installed Operators に移動します。
2. openshift-storage プロジェクトを選択します。
3. OpenShift Data Foundation Operator 名をクリックします。
4. Subscription タブをクリックしてから、Update Channel の下にあるリンクをクリックします。
5. stable-4.18 更新チャネルを選択して、Save をクリックします。

6. Upgrade status に requires approval が表示される場合は、requires approval をクリックします。

   1. Install Plan Details ページで、Preview Install Plan をクリックします。

   2. インストール計画を確認し、Approve をクリックします。

      Status が Unknown から Created に変更されるまで待機します。

7. Operators → Installed Operators に移動します。

8. openshift-storage プロジェクトを選択します。

   OpenShift Data Foundation Operator の Status が Up to date に変わるのを待ちます。

9. Operator が正常にアップグレードされると、Web console update is available メッセージを含むポップアップがユーザーインターフェイスに表示されます。このポップアップから Refresh web console をクリックして、反映するコンソールを変更します。

手順

1. OpenShift Web コンソールで、Operators → Installed Operators に移動します。

2. openshift-storage プロジェクトを選択します。

   注記

   Show default projects オプションが無効になっている場合は、切り替えボタンを使用して、すべてのデフォルトプロジェクトをリスト表示します。

3. OpenShift Data Foundation Operator 名をクリックします。
4. Subscription タブをクリックします。
5. Upgrade Status に require approval が表示される場合は、requires approval リンクをクリックします。
6. InstallPlan Details ページで、Preview Install Plan をクリックします。
7. インストール計画を確認し、Approve をクリックします。
8. Status が Unknown から Created に変更されるまで待機します。
9. Operator が正常にアップグレードされると、Web console update is available メッセージを含むポップアップがユーザーインターフェイスに表示されます。このポップアップから Refresh web console をクリックして、反映するコンソールを変更します。

手順

1. Operators → Installed Operators に移動します。

2. Project ドロップダウンリストから openshift-storage を選択します。

   注記

   Show default projects オプションが無効になっている場合は、切り替えボタンを使用して、すべてのデフォルトプロジェクトをリスト表示します。

3. OpenShift Data Foundation Operator 名をクリックします。
4. Subscription タブに移動します。
5. Update approval を変更するには、鉛筆 アイコンをクリックします。
6. 更新承認ストラテジーを選択し、Save をクリックします。