ストレージリソースの管理および割り当て

手順

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. 次のコマンドを使用して単一レプリカ機能を有効にします。

   $ oc patch storagecluster ocs-storagecluster -n openshift-storage --type json --patch '[{ "op": "replace", "path": "/spec/managedResources/cephNonResilientPools/enable", "value": true }]'

2. storagecluster が Ready 状態であることを確認します。

   $ oc get storagecluster

   出力例:

   NAME                 AGE   PHASE   EXTERNAL   CREATED AT             VERSION
   ocs-storagecluster   10m   Ready              2024-02-05T13:56:15Z   4.15.0

3. 各障害ドメインに新しい cephblockpool が作成されます。cephblockpools が Ready 状態であることを確認します。

   $ oc get cephblockpools

   出力例:

   NAME                                          PHASE
   ocs-storagecluster-cephblockpool              Ready
   ocs-storagecluster-cephblockpool-us-east-1a   Ready
   ocs-storagecluster-cephblockpool-us-east-1b   Ready
   ocs-storagecluster-cephblockpool-us-east-1c   Ready

4. 新しいストレージクラスが作成されたことを確認します。

   $ oc get storageclass

   出力例:

   NAME                                        PROVISIONER                             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
   gp2 (default)                               kubernetes.io/aws-ebs                   Delete          WaitForFirstConsumer   true                   104m
   gp2-csi                                     ebs.csi.aws.com                         Delete          WaitForFirstConsumer   true                   104m
   gp3-csi                                     ebs.csi.aws.com                         Delete          WaitForFirstConsumer   true                   104m
   ocs-storagecluster-ceph-non-resilient-rbd   openshift-storage.rbd.csi.ceph.com      Delete          WaitForFirstConsumer   true                   46m
   ocs-storagecluster-ceph-rbd                 openshift-storage.rbd.csi.ceph.com      Delete          Immediate              true                   52m
   ocs-storagecluster-cephfs                   openshift-storage.cephfs.csi.ceph.com   Delete          Immediate              true                   52m
   openshift-storage.noobaa.io                 openshift-storage.noobaa.io/obc         Delete          Immediate              false                  50m

5. 新しい OSD Pod (3 つの osd-prepare Pod と 3 つの追加 Pod ) が作成されます。新しい OSD Pod が Running 状態であることを確認します。

   $ oc get pods | grep osd

   出力例:

   rook-ceph-osd-0-6dc76777bc-snhnm                                  2/2     Running     0               9m50s
   rook-ceph-osd-1-768bdfdc4-h5n7k                                   2/2     Running     0               9m48s
   rook-ceph-osd-2-69878645c4-bkdlq                                  2/2     Running     0               9m37s
   rook-ceph-osd-3-64c44d7d76-zfxq9                                  2/2     Running     0               5m23s
   rook-ceph-osd-4-654445b78f-nsgjb                                  2/2     Running     0               5m23s
   rook-ceph-osd-5-5775949f57-vz6jp                                  2/2     Running     0               5m22s
   rook-ceph-osd-prepare-ocs-deviceset-gp2-0-data-0x6t87-59swf       0/1     Completed   0               10m
   rook-ceph-osd-prepare-ocs-deviceset-gp2-1-data-0klwr7-bk45t       0/1     Completed   0               10m
   rook-ceph-osd-prepare-ocs-deviceset-gp2-2-data-0mk2cz-jx7zv       0/1     Completed   0               10m

手順

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. オブジェクトバケット要求の作成 の手順に従って、ObjectBucketClaim を作成します。

2. image-registry-private-configuration-user シークレットを作成します。

   1. OpenShift web-console に移動します。
   2. ObjectBucketClaim → ObjectBucketClaim Data をクリックします。
   3. ObjectBucketClaim data の openshift-image-registry namespace で MCG access key と MCG secret key を探します。

   4. 次のコマンドを使用してシークレットを作成します。

      $ oc create secret generic image-registry-private-configuration-user --from-literal=REGISTRY_STORAGE_S3_ACCESSKEY=<MCG Accesskey> --from-literal=REGISTRY_STORAGE_S3_SECRETKEY=<MCG Secretkey> --namespace openshift-image-registry

3. Image Registry Operator の managementState のステータスを Managed に変更します。

   $ oc patch configs.imageregistry.operator.openshift.io/cluster --type merge -p '{"spec": {"managementState": "Managed"}}'

4. Image Registry Operator 設定ファイルの spec.storage セクションを編集します。

   1. Web コンソールから Object Bucket Claim Data セクションの unique-bucket-name と regionEndpoint を取得します。または、次のコマンドから regionEndpoint と unique-bucket-name の情報を取得することもできます。

       $ oc describe  noobaa

   2. 以下の場合は、regionEndpoint を http://<Endpoint-name>:<port> として追加します。

      • storageclass が ceph-rgw storageclass、および
      • エンドポイントが、openshift-storage namespace からの内部 SVC を指している。

   3. Operator レジストリー設定ファイルに変更を加えた後、image-registry Pod が生成されます。

      $ oc edit configs.imageregistry.operator.openshift.io -n openshift-image-registry
      apiVersion: imageregistry.operator.openshift.io/v1
      kind: Config
      metadata:
      [..]
      name: cluster
      spec:
      [..]
      storage:
      s3:
      
        bucket: <Unique-bucket-name>
      
        region: us-east-1 (Use this region as default)
      
        regionEndpoint: https://<Endpoint-name>:<port>
      
        virtualHostedStyle: false

5. イメージレジストリー設定をデフォルトにリセットします。

   $ oc get pods -n openshift-image-registry

手順

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 に割り当てられていることを確認します。

      図4.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)。

      図4.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)。

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

      

手順

1. コマンドラインインターフェイスまたはユーザーインターフェイスのいずれかから storagecluster をデプロイします。

2. アプリケーションの namespace にラベルを付けます。

   apiVersion: v1
   kind: Namespace
   metadata:
        name: <desired_name>
        labels:
             storagequota: <desired_label>

   <desired_name>

   アプリケーション namespace の名前を指定します (例: quota-rbd)。

   <desired_label>

   ストレージクォータのラベルを指定します (例: storagequota1)。

3. storagecluster を編集して、ストレージクラスのクォータ制限を設定します。

   $ oc edit storagecluster -n openshift-storage <ocs_storagecluster_name>

   <ocs_storagecluster_name>

   ストレージクラスターの名前を指定します。

4. 必要なハード制限を持つオーバープロビジョニング制御のエントリーを StorageCluster.Spec に追加します。

   apiVersion: ocs.openshift.io/v1
   kind: StorageCluster
   spec:
    [...]
        overprovisionControl:
        - capacity: <desired_quota_limit>
             storageClassName: <storage_class_name>
             quotaName: <desired_quota_name>
             selector:
               labels:
                      matchLabels:
                       storagequota: <desired_label>
   [...]

   <desired_quota_limit>

   ストレージクラスに必要なクォータ制限を指定します (例: 27Ti)。

   <storage_class_name>

   クォータ制限を設定するストレージクラスの名前を指定します (例: ocs-storagecluster-ceph-rbd)。

   <desired_quota_name>

   ストレージクォータの名前を指定します (例: quota1)。

   <desired_label>

   ストレージクォータのラベルを指定します (例: storagequota1)。

5. 変更された storagecluster を保存します。

6. clusterresourcequota が定義されていることを確認します。

   注記

   前の手順で定義した quotaName (例: quota1) を持つ clusterresourcequota を想定します。

   $ oc get clusterresourcequota -A
   
   $ oc describe clusterresourcequota -A

手順

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

手順

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. 拡張する永続ボリューム要求の横にある Action メニュー (⋮) をクリックします。

3. Expand PVC をクリックします。

   

4. 永続ボリューム要求の新しいサイズを選択してから、Expand をクリックします。

   

5. 拡張を確認するには、PVC の詳細ページに移動し、Capacity フィールドでサイズが正しく要求されていることを確認します。

   注記

   Ceph RADOS Block Device (RBD) に基づいて PVC を拡張し、PVC がまだ Pod に割り当てられていない場合は、PVC の詳細ページで Condition type が FileSystemResizePending になります。ボリュームをマウントすると、ファイルシステムのサイズ変更が正常に実行し、新しいサイズが Capacity フィールドに反映されます。

手順

1. 永続ボリュームクレーム (PVC) の詳細を取得します。

   $ oc get pvc data-pvc

   NAME      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                          AGE
   data-pvc  Bound    pvc-f37b8582-4b04-4676-88dd-e1b95c6abf74   1Gi        RWO            ocs-storagecluster-ceph-rbd           20h

2. アノテーション reclaimspace.csiaddons.openshift.io/schedule=@monthly を PVC に追加して、reclaimspacecronjob を作成します。

   $ oc annotate pvc data-pvc "reclaimspace.csiaddons.openshift.io/schedule=@monthly"

   persistentvolumeclaim/data-pvc annotated

3. reclaimspacecronjob が "<pvc-name>-xxxxxxx" の形式で作成されていることを確認します。

   $ oc get reclaimspacecronjobs.csiaddons.openshift.io

   NAME                    SCHEDULE    SUSPEND   ACTIVE   LASTSCHEDULE   AGE
   data-pvc-1642663516     @monthly                                      3s

4. このジョブを自動的に実行するようにスケジュールを変更します。

   $ oc annotate pvc data-pvc "reclaimspace.csiaddons.openshift.io/schedule=@weekly" --overwrite=true

   persistentvolumeclaim/data-pvc annotated

5. reclaimspacecronjob のスケジュールが変更されていることを確認します。

   $ oc get reclaimspacecronjobs.csiaddons.openshift.io

   NAME                  SCHEDULE    SUSPEND   ACTIVE   LASTSCHEDULE   AGE
   data-pvc-1642664617   @weekly                                       3s

手順

1. スペースの回収操作用に次のカスタムリソースを作成して適用します。

   apiVersion: csiaddons.openshift.io/v1alpha1
   kind: ReclaimSpaceJob
   metadata:
     name: sample-1
   spec:
     target:
       persistentVolumeClaim: pvc-1
     timeout: 360

   詳細は以下のようになります。

   target

   操作が実行されるボリュームターゲットを示します。

   persistentVolumeClaim

   PersistentVolumeClaim の名前。

   backOfflimit

   スペース回収操作を failed としてマークするまでの最大再試行回数を指定します。デフォルト値は 6 です。許可される最大値と最小値はそれぞれ 60 と 0 です。

   retryDeadlineSeconds

   操作が終了するまでの期間を秒単位で指定します。これは開始時刻を基準とします。値は正の整数である必要があります。デフォルト値は 600 秒で、許容最大値は 1800 秒です。

   timeout

   CSI ドライバーに送信される grpc 要求のタイムアウトを秒単位で指定します。タイムアウト値が指定されていない場合、デフォルトは global reclaimspace timeout の値に設定されます。タイムアウトの最小許容値は 60 です。

2. 操作が完了したら、カスタムリソースを削除します。

手順

1. スペースの回収操作用に次のカスタムリソースを作成して適用します

   apiVersion: csiaddons.openshift.io/v1alpha1
   kind: ReclaimSpaceCronJob
   metadata:
     name: reclaimspacecronjob-sample
   spec:
     jobTemplate:
       spec:
         target:
           persistentVolumeClaim: data-pvc
         timeout: 360
     schedule: '@weekly'
     concurrencyPolicy: Forbid

   詳細は以下のようになります。

   concurrencyPolicy

   以前の ReclaimSpaceJob がまだ実行されている間に、新しい ReclaimSpaceJob が ReclaimSpaceCronJob によってスケジュールされた場合の変更を示します。デフォルトの Forbid は新しいジョブの開始を防ぎますが、Replace を使用すると、障害状態にある可能性のある実行中のジョブを削除して、新しいジョブを作成できます。

   failedJobsHistoryLimit

   トラブルシューティングのために保持される、失敗した ReclaimSpaceJobs の数を指定します。

   jobTemplate

   要求された ReclaimSpaceJob 操作の詳細を記述する ReclaimSpaceJob.spec 構造体を指定します。

   successfulJobsHistoryLimit

   成功した ReclaimSpaceJob 操作の数を指定します。

   schedule

   定期的な操作リクエストの間隔を指定します。Kubernetes CronJobs と同じ形式です。

2. スペース回収操作の実行が不要になった場合、またはターゲット PVC が削除された場合は、ReclaimSpaceCronJob カスタムリソースを削除します。

手順

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 コンソールで、Storage → Persistent Volume Claims をクリックします。
2. Project を openshift-storage に設定します。

3. Create PersistentVolumeClaim をクリックします。

   1. Storage Class、ocs-storagecluster-ceph-nfs を指定します。
   2. my-nfs-export などの PVC 名 を指定します。
   3. 必要な Access Mode を選択します。
   4. アプリケーション要件に応じて Size を指定します。

   5. Volume mode を Filesystem として選択します。

      注記: Block モードは、NFS PVC ではサポートされていません。

   6. Create をクリックし、PVC のステータスが Bound になるまで待機します。

手順

1. OpenShift Container Platform Web コンソールで、Workloads → Pods に移動します。
2. Create Pod をクリックして、新しいアプリケーション Pod を作成します。
3. metadata セクションの下に名前を追加します。たとえば、namespace のある nfs-export-example を openshift-storage として追加します。

4. spec: セクションの下に、image セクションと volumeMounts セクションを含む containers: セクションを追加します。

   apiVersion: v1
   kind: Pod
   metadata:
    name: nfs-export-example
    namespace: openshift-storage
   spec:
    containers:
      - name: web-server
        image: nginx
        volumeMounts:
          - name: <volume_name>
            mountPath: /var/lib/www/html

   以下に例を示します。

   apiVersion: v1
   kind: Pod
   metadata:
    name: nfs-export-example
    namespace: openshift-storage
   spec:
    containers:
      - name: web-server
        image: nginx
        volumeMounts:
          - name: nfs-export-pvc
            mountPath: /var/lib/www/html

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

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

   以下に例を示します。

   volumes:
     - name: nfs-export-pvc
       persistentVolumeClaim:
         claimName: my-nfs-export

手順

1. nfs フラグが有効になると、単一サーバーの CephNFS が Rook によってデプロイされます。次のステップで使用する nfs-ganesha サーバーの ceph_nfs フィールドの値を取得する必要があります。

   $ oc get pods -n openshift-storage | grep rook-ceph-nfs

   $ oc describe pod  <name of the rook-ceph-nfs pod> | grep ceph_nfs

   以下に例を示します。

   $ oc describe pod rook-ceph-nfs-ocs-storagecluster-cephnfs-a-7bb484b4bf-bbdhs | grep ceph_nfs
     ceph_nfs=my-nfs

2. Kubernetes LoadBalancer Service を作成して、OpenShift クラスターの外部に NFS サーバーを公開します。以下の例では、LoadBalancer Service を作成し、OpenShift Data Foundation によって作成された NFS サーバーを参照します。

   apiVersion: v1
   kind: Service
   metadata:
    name: rook-ceph-nfs-ocs-storagecluster-cephnfs-load-balancer
    namespace: openshift-storage
   spec:
    ports:
      - name: nfs
        port: 2049
    type: LoadBalancer
    externalTrafficPolicy: Local
    selector:
      app: rook-ceph-nfs
      ceph_nfs: <my-nfs>
      instance: a

   <my-nfs> を手順 1 で取得した値に置き換えます。

3. 接続情報を収集します。外部クライアントがエクスポートに接続するために必要な情報は、PVC 用に作成された永続ボリューム (PV) と、前の手順で作成された LoadBalancer Service のステータスから取得されます。

   1. PV から共有パスを取得します。

      1. NFS エクスポートの PVC に関連付けられた PV の名前を取得します。

         $ oc get pvc <pvc_name> --output jsonpath='{.spec.volumeName}'
         pvc-39c5c467-d9d3-4898-84f7-936ea52fd99d

         <pvc_name> を独自の PVC 名に置き換えます。以下に例を示します。

         oc get pvc pvc-39c5c467-d9d3-4898-84f7-936ea52fd99d --output jsonpath='{.spec.volumeName}'
         pvc-39c5c467-d9d3-4898-84f7-936ea52fd99d

      2. 前に取得した PV 名を使用して、NFS エクスポートの共有パスを取得します。

         $ oc get pv pvc-39c5c467-d9d3-4898-84f7-936ea52fd99d --output jsonpath='{.spec.csi.volumeAttributes.share}'
         /0001-0011-openshift-storage-0000000000000001-ba9426ab-d61b-11ec-9ffd-0a580a800215

   2. NFS サーバーの Ingress アドレスを取得します。サービスの Ingress ステータスには、複数のアドレスが存在する場合があります。外部クライアントに使用するアドレスを選択します。以下の例では、ホスト名 ingress-id.somedomain.com という 1 つのアドレスしかありません。

      $ oc -n openshift-storage get service rook-ceph-nfs-ocs-storagecluster-cephnfs-load-balancer --output jsonpath='{.status.loadBalancer.ingress}'
      [{"hostname":"ingress-id.somedomain.com"}]

4. 前の手順の共有パスと Ingress アドレスを使用して、外部クライアントを接続します。次の例では、エクスポートをクライアントのディレクトリーパス /export/mount/path にマウントします。

   $ mount -t nfs4 -o proto=tcp ingress-id.somedomain.com:/0001-0011-openshift-storage-0000000000000001-ba9426ab-d61b-11ec-9ffd-0a580a800215 /export/mount/path

   これがすぐに機能しない場合は、Kubernetes 環境が、NFS サーバーへの Ingress を許可するためのネットワークリソースの設定に、まだ時間がかかっている可能性があります。

1. すべての IO を停止します。

2. full の比率を 0.92 に増やします。

   $ odf set full 0.92

3. クラスターリバランスが発生するまで待ちます。クラスターのリバランスが完了したら、full の比率を元の値 0.85 に変更します。

   $ odf set full 0.85