検索

4.12. ローカルストレージを使用した永続ストレージ

download PDF

4.12.1. ローカルボリュームを使用した永続ストレージ

OpenShift Container Platform は、ローカルボリュームを使用する永続ストレージでプロビジョニングすることが可能です。ローカルの永続ボリュームを使用すると、標準の永続ボリューム要求 (PVC) インターフェイスを使用して、ディスクやパーティションなどのローカルのストレージデバイスにアクセスできます。

ローカルボリュームは、Pod をノードに手動でスケジュールせずに使用できます。ボリュームのノード制約がシステムによって認識されるためです。ただし、ローカルボリュームは、依然として基礎となるノードの可用性に依存しており、すべてのアプリケーションに適している訳ではありません。

注記

ローカルボリュームは、静的に作成された永続ボリュームとしてのみ使用できます。

4.12.1.1. ローカルストレージ Operator のインストール

ローカルストレージ Operator はデフォルトで OpenShift Container Platform にインストールされません。以下の手順を使用してこの Operator をインストールし、クラスター内でローカルボリュームを有効にできるように設定します。

前提条件

  • OpenShift Container Platform Web コンソールまたはコマンドラインインターフェイス (CLI) へのアクセス。

手順

  1. openshift-local-storage プロジェクトを作成します。

    $ oc adm new-project openshift-local-storage
  2. オプション: インフラストラクチャーノードでのローカルストレージの作成を許可します。

    ロギングやモニタリングなどのコンポーネントに対応するために、ローカルストレージ Operator を使用してインフラストラクチャーノードでボリュームを作成する必要がある場合があります。

    ローカルストレージ Operator にワーカーノードだけでなくインフラストラクチャーノードが含まれるように、デフォルトのノードセレクターを調整する必要があります。

    ローカルストレージ Operator がクラスター全体のデフォルトセレクターを継承しないようにするには、以下のコマンドを実行します。

    $ oc annotate namespace openshift-local-storage openshift.io/node-selector=''
  3. オプション: 単一ノードデプロイメントの CPU の管理プールでローカルストレージを実行できるようにします。

    シングルノードデプロイメントで Local Storage Operator を使用し、literal プールに属する CPU の使用を許可します。この手順は、管理ワークロードパーティショニングを使用する単一ノードインストールで実行します。

    Local Storage Operator が管理 CPU プールで実行できるようにするには、次のコマンドを実行します。

    $ oc annotate namespace openshift-local-storage workload.openshift.io/allowed='management'

UI での操作

Web コンソールからローカルストレージ Operator をインストールするには、以下の手順を実行します。

  1. OpenShift Container Platform Web コンソールにログインします。
  2. Operators OperatorHub に移動します。
  3. Local Storage をフィルターボックスに入力して、ローカルストレージ Operator を見つけます。
  4. Install をクリックします。
  5. Install Operator ページで、A specific namespace on the cluster を選択します。ドロップメニューから openshift-local-storage を選択します。
  6. Update Channel および Approval Strategy の値を必要な値に調整します。
  7. Install をクリックします。

これが完了すると、ローカルストレージ Operator は Web コンソールの Installed Operators セクションにリスト表示されます。

CLI からの操作

  1. CLI からローカルストレージ Operator をインストールします。

    1. ローカルストレージ Operator の Operator グループおよびサブスクリプションを定義するために、オブジェクト YAML ファイル (例: openshift-local-storage.yaml) を作成します。

      例: openshift-local-storage.yaml

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: local-operator-group
        namespace: openshift-local-storage
      spec:
        targetNamespaces:
          - openshift-local-storage
      ---
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: local-storage-operator
        namespace: openshift-local-storage
      spec:
        channel: stable
        installPlanApproval: Automatic 1
        name: local-storage-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace

      1
      インストール計画のユーザー認可ポリシー。
  2. 以下のコマンドを実行して、ローカルストレージ Operator オブジェクトを作成します。

    $ oc apply -f openshift-local-storage.yaml

    この時点で、Operator Lifecycle Manager (OLM) はローカルストレージ Operator を認識できるようになります。Operator の ClusterServiceVersion (CSV) はターゲット namespace に表示され、Operator で指定される API は作成用に利用可能になります。

  3. すべての Pod およびローカルストレージ Operator が作成されていることを確認して、ローカルストレージのインストールを検証します。

    1. 必要な Pod すべてが作成されていることを確認します。

      $ oc -n openshift-local-storage get pods

      出力例

      NAME                                      READY   STATUS    RESTARTS   AGE
      local-storage-operator-746bf599c9-vlt5t   1/1     Running   0          19m

    2. ClusterServiceVersion (CSV) YAML マニフェストをチェックして、ローカルストレージ Operator が openshift-local-storage プロジェクトで利用できることを確認します。

      $ oc get csvs -n openshift-local-storage

      出力例

      NAME                                         DISPLAY         VERSION               REPLACES   PHASE
      local-storage-operator.4.2.26-202003230335   Local Storage   4.2.26-202003230335              Succeeded

すべてのチェックが渡されると、ローカルストレージ Operator が正常にインストールされます。

4.12.1.2. ローカルストレージ Operator を使用したローカルボリュームのプロビジョニング

ローカルボリュームは動的プロビジョニングで作成できません。代わりに、永続ボリュームがローカルストレージ Operator によって作成されることがあります。このローカルボリュームプロビジョナーは、定義されたリソースで指定されているパスでファイルシステムまたはブロックボリュームデバイスを検索します。

前提条件

  • ローカルストレージ Operator がインストールされていること。
  • 以下の条件を満たすローカルディスクがある。

    • ノードに接続されている。
    • マウントされていない。
    • パーティションが含まれていない。

手順

  1. ローカルボリュームリソースを作成します。このリソースは、ノードおよびローカルボリュームへのパスを定義する必要があります。

    注記

    同じデバイスに別のストレージクラス名を使用しないでください。これを行うと、複数の永続ボリューム (PV) が作成されます。

    例: ファイルシステム

    apiVersion: "local.storage.openshift.io/v1"
    kind: "LocalVolume"
    metadata:
      name: "local-disks"
      namespace: "openshift-local-storage" 1
    spec:
      nodeSelector: 2
        nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - ip-10-0-140-183
              - ip-10-0-158-139
              - ip-10-0-164-33
      storageClassDevices:
        - storageClassName: "local-sc" 3
          volumeMode: Filesystem 4
          fsType: xfs 5
          devicePaths: 6
            - /path/to/device 7

    1
    ローカルストレージ Operator がインストールされている namespace。
    2
    オプション: ローカルストレージボリュームが割り当てられているノードの一覧が含まれるノードセレクター。以下の例では、oc get node から取得したノードホスト名を使用します。値が定義されない場合、ローカルストレージ Operator は利用可能なすべてのノードで一致するディスクの検索を試行します。
    3
    永続ボリュームオブジェクトの作成時に使用するストレージクラスの名前。ローカルストレージ Operator は、ストレージクラスが存在しない場合にこれを自動的に作成します。このローカルボリュームのセットを一意に識別するストレージクラスを使用するようにしてください。
    4
    ローカルボリュームのタイプを定義するボリュームモード (Filesystem または Block)。
    注記

    raw ブロックボリューム (volumeMode: Block) はファイルシステムでフォーマットされません。このモードは、Pod で実行しているすべてのアプリケーションが raw ブロックデバイスを使用できる場合にのみ使用します。

    5
    ローカルボリュームの初回マウント時に作成されるファイルシステム。
    6
    選択するローカルストレージデバイスの一覧を含むパスです。
    7
    この値を、LocalVolume リソースby-idへの実際のローカルディスクのファイルパスに置き換えます (例: /dev/disk/by-id/wwn)。プロビジョナーが正常にデプロイされると、これらのローカルディスク用に PV が作成されます。
    注記

    RHEL KVM を使用して OpenShift Container Platform を実行している場合は、VM ディスクにシリアル番号を割り当てる必要があります。そうしないと、再起動後に VM ディスクを識別できません。virsh edit <VM> コマンドを使用して、<serial>mydisk</serial> 定義を追加できます。

    例: ブロック

    apiVersion: "local.storage.openshift.io/v1"
    kind: "LocalVolume"
    metadata:
      name: "local-disks"
      namespace: "openshift-local-storage" 1
    spec:
      nodeSelector: 2
        nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - ip-10-0-136-143
              - ip-10-0-140-255
              - ip-10-0-144-180
      storageClassDevices:
        - storageClassName: "local-sc" 3
          volumeMode: Block 4
          devicePaths: 5
            - /path/to/device 6

    1
    ローカルストレージ Operator がインストールされている namespace。
    2
    オプション: ローカルストレージボリュームが割り当てられているノードの一覧が含まれるノードセレクター。以下の例では、oc get node から取得したノードホスト名を使用します。値が定義されない場合、ローカルストレージ Operator は利用可能なすべてのノードで一致するディスクの検索を試行します。
    3
    永続ボリュームオブジェクトの作成時に使用するストレージクラスの名前。
    4
    ローカルボリュームのタイプを定義するボリュームモード (Filesystem または Block)。
    5
    選択するローカルストレージデバイスの一覧を含むパスです。
    6
    この値を、LocalVolume リソースby-idへの実際のローカルディスクのファイルパスに置き換えます (例: dev/disk/by-id/wwn)。プロビジョナーが正常にデプロイされると、これらのローカルディスク用に PV が作成されます。
    注記

    RHEL KVM を使用して OpenShift Container Platform を実行している場合は、VM ディスクにシリアル番号を割り当てる必要があります。そうしないと、再起動後に VM ディスクを識別できません。virsh edit <VM> コマンドを使用して、<serial>mydisk</serial> 定義を追加できます。

  2. OpenShift Container Platform クラスターにローカルボリュームリソースを作成します。作成したばかりのファイルを指定します。

    $ oc create -f <local-volume>.yaml
  3. プロビジョナーが作成され、対応するデーモンセットが作成されていることを確認します。

    $ oc get all -n openshift-local-storage

    出力例

    NAME                                          READY   STATUS    RESTARTS   AGE
    pod/diskmaker-manager-9wzms                   1/1     Running   0          5m43s
    pod/diskmaker-manager-jgvjp                   1/1     Running   0          5m43s
    pod/diskmaker-manager-tbdsj                   1/1     Running   0          5m43s
    pod/local-storage-operator-7db4bd9f79-t6k87   1/1     Running   0          14m
    
    NAME                                     TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
    service/local-storage-operator-metrics   ClusterIP   172.30.135.36   <none>        8383/TCP,8686/TCP   14m
    
    NAME                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/diskmaker-manager   3         3         3       3            3           <none>          5m43s
    
    NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/local-storage-operator   1/1     1            1           14m
    
    NAME                                                DESIRED   CURRENT   READY   AGE
    replicaset.apps/local-storage-operator-7db4bd9f79   1         1         1       14m

    デーモンセットプロセスの必要な数と現在の数に注意してください。必要な数が 0 の場合、これはラベルセレクターが無効であることを示します。

  4. 永続ボリュームが作成されていることを確認します。

    $ oc get pv

    出力例

    NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
    local-pv-1cec77cf   100Gi      RWO            Delete           Available           local-sc                88m
    local-pv-2ef7cd2a   100Gi      RWO            Delete           Available           local-sc                82m
    local-pv-3fa1c73    100Gi      RWO            Delete           Available           local-sc                48m

重要

LocalVolume オブジェクトを編集しても、既存の永続ボリュームの fsType または volumeMode は変更されません。これが破壊的な操作になる可能性があるためです。

4.12.1.3. ローカルストレージ Operator のないローカルボリュームのプロビジョニング

ローカルボリュームは動的プロビジョニングで作成できません。代わりに、永続ボリュームは、永続ボリューム (PV) をオブジェクト定義に定義して作成できます。このローカルボリュームプロビジョナーは、定義されたリソースで指定されているパスでファイルシステムまたはブロックボリュームデバイスを検索します。

重要

PV の手動プロビジョニングには、PVC の削除時に PV 全体でデータ漏洩が発生するリスクが含まれます。ローカルストレージ Operator は、ローカル PV のプロビジョニング時にデバイスのライフサイクルを自動化するために使用することが推奨されます。

前提条件

  • ローカルディスクが OpenShift Container Platform ノードに割り当てられていること。

手順

  1. PV を定義します。PersistentVolume オブジェクト定義を使用して、example-pv-filesystem.yaml または example-pv-block.yaml などのファイルを作成します。このリソースは、ノードおよびローカルボリュームへのパスを定義する必要があります。

    注記

    同じデバイスに別のストレージクラス名を使用しないでください。同じ名前を使用すると、複数の PV が作成されます。

    example-pv-filesystem.yaml

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: example-pv-filesystem
    spec:
      capacity:
        storage: 100Gi
      volumeMode: Filesystem 1
      accessModes:
      - ReadWriteOnce
      persistentVolumeReclaimPolicy: Delete
      storageClassName: local-sc 2
      local:
        path: /dev/xvdf 3
      nodeAffinity:
        required:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - example-node

    1
    PV のタイプを定義するボリュームモード (Filesystem または Block)。
    2
    PV リソースの作成時に使用するストレージクラスの名前。この PV のセットを一意に特定するストレージクラスを使用にしてください。
    3
    選択するローカルストレージデバイスのリスト、またはディレクトリーが含まれるパスです。Filesystem volumeMode のディレクトリーのみを指定できます。
    注記

    raw ブロックボリューム (volumeMode: block) はファイルシステムでフォーマットされません。このモードは、Pod で実行しているすべてのアプリケーションが raw ブロックデバイスを使用できる場合にのみ使用します。

    example-pv-block.yaml

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: example-pv-block
    spec:
      capacity:
        storage: 100Gi
      volumeMode: Block 1
      accessModes:
      - ReadWriteOnce
      persistentVolumeReclaimPolicy: Delete
      storageClassName: local-sc 2
      local:
        path: /dev/xvdf 3
      nodeAffinity:
        required:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - example-node

    1
    PV のタイプを定義するボリュームモード (Filesystem または Block)。
    2
    PV リソースの作成時に使用するストレージクラスの名前。この PV のセットを一意に特定するストレージクラスを使用するようにしてください。
    3
    選択するローカルストレージデバイスの一覧を含むパスです。
  2. OpenShift Container Platform クラスターに PV リソースを作成します。作成したばかりのファイルを指定します。

    $ oc create -f <example-pv>.yaml
  3. ローカル PV が作成されていることを確認します。

    $ oc get pv

    出力例

    NAME                    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                STORAGECLASS    REASON   AGE
    example-pv-filesystem   100Gi      RWO            Delete           Available                        local-sc            3m47s
    example-pv1             1Gi        RWO            Delete           Bound       local-storage/pvc1   local-sc            12h
    example-pv2             1Gi        RWO            Delete           Bound       local-storage/pvc2   local-sc            12h
    example-pv3             1Gi        RWO            Delete           Bound       local-storage/pvc3   local-sc            12h

4.12.1.4. ローカルボリュームの永続ボリューム要求 (PVC) の作成

ローカルボリュームは、Pod でアクセスされる永続ボリューム要求 (PVC) として静的に作成される必要があります。

前提条件

  • 永続ボリュームがローカルボリュームプロビジョナーを使用して作成されていること。

手順

  1. 対応するストレージクラスを使用して PVC を作成します。

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: local-pvc-name 1
    spec:
      accessModes:
      - ReadWriteOnce
      volumeMode: Filesystem 2
      resources:
        requests:
          storage: 100Gi 3
      storageClassName: local-sc 4
    1
    PVC の名前。
    2
    PVC のタイプ。デフォルトは Filesystem です。
    3
    PVC に利用できるストレージの量。
    4
    要求で必要になるストレージクラスの名前。
  2. 作成したファイルを指定して、PVC を OpenShift Container Platform クラスターに作成します。

    $ oc create -f <local-pvc>.yaml

4.12.1.5. ローカル要求を割り当てます。

ローカルボリュームが永続ボリューム要求 (PVC) にマップされた後に、これをリソース内に指定できます。

前提条件

  • 永続ボリューム要求 (PVC) が同じ namespace に存在する。

手順

  1. 定義された要求をリソースの仕様に追加します。以下の例では、Pod 内で永続ボリューム要求 (PVC) を宣言します。

    apiVersion: v1
    kind: Pod
    spec:
    # ...
      containers:
        volumeMounts:
        - name: local-disks 1
          mountPath: /data 2
      volumes:
      - name: local-disks
        persistentVolumeClaim:
          claimName: local-pvc-name 3
    # ...
    1
    マウントするボリュームの名前。
    2
    ボリュームがマウントされる Pod 内のパス。コンテナーのルート (/) や、ホストとコンテナーで同じパスにはマウントしないでください。これは、コンテナーに十分な特権が付与されている場合に、ホストシステムを破壊する可能性があります (例: ホストの /dev/pts ファイル)。ホストをマウントするには、/host を使用するのが安全です。
    3
    使用する既存の永続ボリューム要求 (PVC) の名前。
  2. 作成したファイルを指定して、OpenShift Container Platform クラスターにリソースを作成します。

    $ oc create -f <local-pod>.yaml

4.12.1.6. 詳細は、ローカルストレージデバイスの自動検出およびプロビジョニングを参照してください。

ローカルストレージ Operator はローカルストレージ検出およびプロビジョニングを自動化します。この機能を使用すると、ベアメタル、VMware、または割り当てられたデバイスを持つ AWS ストアインスタンスなど、デプロイメント時に動的プロビジョニングが利用できない場合にインストールを単純化できます。

重要

自動検出およびプロビジョニングはテクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

重要

Red Hat OpenShift Data Foundation をオンプレミスでデプロイするために使用する場合、またはプラットフォームに依存しないデプロイメントで使用する場合、自動検出とプロビジョニングは完全にサポートされます。

ローカルデバイスを自動的に検出し、選択したデバイスのローカルボリュームを自動的にプロビジョニングするには、以下の手順を使用します。

警告

LocalVolumeSet オブジェクトの使用には注意が必要です。ローカルディスクから永続ボリューム (PV) を自動的にプロビジョニングする場合、ローカル PV は一致するすべてのデバイスを要求する可能性があります。LocalVolumeSet オブジェクトを使用している場合、ローカルストレージ Operator がノードでローカルデバイスを管理する唯一のエンティティーであることを確認します。ノードを複数回ターゲットにする Local VolumeSet のインスタンスを複数作成することはサポートされていません。

前提条件

  • クラスター管理者パーミッションがある。
  • ローカルストレージ Operator がインストールされていること。
  • ローカルディスクが OpenShift Container Platform ノードに割り当てられていること。
  • OpenShift Container Platform Web コンソールまたは oc コマンドラインインターフェイス (CLI) へのアクセスがあること。

手順

  1. Web コンソールからローカルデバイスの自動検出を有効にするには、以下を行います。

    1. Operators Installed Operators をクリックします。
    2. openshift-local-storage namespace で Local Storage をクリックします。
    3. Local Volume Discovery タブをクリックします。
    4. Create Local Volume Discovery をクリックし、Form view または YAML view のいずれかを選択します。
    5. LocalVolumeDiscovery オブジェクトパラメーターを設定します。
    6. Create をクリックします。

      Local Storage Operator は、auto-discover-devices という名前のローカルボリューム検出インスタンスを作成します。

  2. ノードで利用可能なデバイスの連続リストを表示するには、以下を実行します。

    1. OpenShift Container Platform Web コンソールにログインします。
    2. Compute Nodes に移動します。
    3. 開くノードの名前をクリックします。「Node Details」ページが表示されます。
    4. Disks タブを選択して、選択したデバイスのリストを表示します。

      ローカルディスクを追加または削除しても、デバイスリストの更新が継続的に行われます。名前、ステータス、タイプ、モデル、容量、およびモードでデバイスをフィルターできます。

  3. Web コンソールから検出されたデバイスのローカルボリュームを自動的にプロビジョニングするには、以下を実行します。

    1. Operators Installed Operators に移動し、Operator のリストから Local Storage を選択します。
    2. Local Volume Set Create Local Volume Set を選択します。
    3. ボリュームセット名とストレージクラス名を入力します。
    4. All nodes または Select nodes を選択し、適宜フィルターを適用します。

      注記

      All nodes または Select nodes を使用してフィルターするかどうかにかかわらず、ワーカーノードのみが利用可能になります。

    5. ローカルボリュームセットに適用するディスクタイプ、モード、サイズ、および制限を選択し、Create をクリックします。

      メッセージが数分後に表示され、「Operator reconciled successfully」という Operator の調整が正常に行われたことが示唆されます。

  4. または、CLI から検出されたデバイスのローカルボリュームをプロビジョニングするには、以下を実行します。

    1. 以下の例に示されるように、オブジェクト YAML ファイルを作成し、local-volume-set.yaml などのローカルボリュームセットを定義します。

      apiVersion: local.storage.openshift.io/v1alpha1
      kind: LocalVolumeSet
      metadata:
        name: example-autodetect
      spec:
        nodeSelector:
          nodeSelectorTerms:
            - matchExpressions:
                - key: kubernetes.io/hostname
                  operator: In
                  values:
                    - worker-0
                    - worker-1
        storageClassName: local-sc 1
        volumeMode: Filesystem
        fsType: ext4
        maxDeviceCount: 10
        deviceInclusionSpec:
          deviceTypes: 2
            - disk
            - part
          deviceMechanicalProperties:
            - NonRotational
          minSize: 10G
          maxSize: 100G
          models:
            - SAMSUNG
            - Crucial_CT525MX3
          vendors:
            - ATA
            - ST2000LM
      1
      検出されたデバイスからプロビジョニングされる永続ボリューム用に作成されるストレージクラスを判別します。ローカルストレージ Operator は、ストレージクラスが存在しない場合にこれを自動的に作成します。このローカルボリュームのセットを一意に識別するストレージクラスを使用するようにしてください。
      2
      ローカルボリュームセット機能を使用する場合、ローカルストレージ Operator は論理ボリューム管理 (LVM) デバイスの使用をサポートしません。
    2. ローカルボリュームセットオブジェクトを作成します。

      $ oc apply -f local-volume-set.yaml
    3. ローカル永続ボリュームがストレージクラスに基づいて動的にプロビジョニングされていることを確認します。

      $ oc get pv

      出力例

      NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
      local-pv-1cec77cf   100Gi      RWO            Delete           Available           local-sc                88m
      local-pv-2ef7cd2a   100Gi      RWO            Delete           Available           local-sc                82m
      local-pv-3fa1c73    100Gi      RWO            Delete           Available           local-sc                48m

注記

結果は、ノードから削除された後に削除されます。シンボリックリンクは手動で削除する必要があります。

4.12.1.7. ローカルストレージ Operator Pod での容認の使用

テイントはノードに適用し、それらが一般的なワークロードを実行しないようにすることができます。ローカルストレージ Operator がテイントのマークが付けられたノードを使用できるようにするには、容認を Pod または DaemonSet 定義に追加する必要があります。これにより、作成されたリソースをこれらのテイントのマークが付けられたノードで実行できるようになります。

容認を LocalVolume リソースでローカルストレージ Operator Pod に適用し、テイントをノード仕様でノードに適用します。ノードのテイントはノードに対し、テイントを容認しないすべての Pod を拒否するよう指示します。他の Pod にはない特定のテイントを使用することで、ローカルストレージ Operator Pod がそのノードでも実行されるようにできます。

重要

テイントおよび容認は、key、value、および effect で設定されています。引数として、これは key=value:effect として表現されます。演算子により、これらの 3 つのパラメーターのいずれかを空のままにすることができます。

前提条件

  • ローカルストレージ Operator がインストールされていること。
  • ローカルディスクがテイントを持つ OpenShift Container Platform ノードに割り当てられている。
  • テイントのマークが付けられたノードがローカルストレージのプロビジョニングを行うことが想定されます。

手順

テイントのマークが付けられたノードでスケジュールするようにローカルボリュームを設定するには、以下を実行します。

  1. 以下の例に示されるように、Pod を定義する YAML ファイルを変更し、LocalVolume 仕様を追加します。

      apiVersion: "local.storage.openshift.io/v1"
      kind: "LocalVolume"
      metadata:
        name: "local-disks"
        namespace: "openshift-local-storage"
      spec:
        tolerations:
          - key: localstorage 1
            operator: Equal 2
            value: "localstorage" 3
        storageClassDevices:
            - storageClassName: "local-sc"
              volumeMode: Block 4
              devicePaths: 5
                - /dev/xvdg
    1
    ノードに追加したキーを指定します。
    2
    Equal Operator を指定して、key/value パラメーターが一致するようにします。Operator が Exists の場合、システムはキーが存在することを確認し、値を無視します。Operator が Equal の場合、キーと値が一致する必要があります。
    3
    テイントのマークが付けられたノードの値 local を指定します。
    4
    ボリュームモード (Filesystem または Block) で、ローカルボリュームのタイプを定義します。
    5
    選択するローカルストレージデバイスの一覧を含むパスです。
  2. オプション: テイントのマークが付けられたノードでのみローカル永続ボリュームを作成するには、以下の例のように YAML ファイルを変更し、LocalVolume 仕様を追加します。

    spec:
      tolerations:
        - key: node-role.kubernetes.io/master
          operator: Exists

定義された容認は結果として作成されるデーモンセットに渡されます。これにより、diskmaker およびプロビジョナー Pod を指定されたテイントが含まれるノード用に作成できます。

4.12.1.8. ローカルストレージ Operator メトリクス

OpenShift Container Platform は、ローカルストレージ Operator の以下のメトリクスを提供します。

  • lso_discovery_disk_count: 各ノードで検出されたデバイスの合計数
  • lso_lvset_provisioned_PV_count: LocalVolumeSet オブジェクトによって作成される PV の合計数
  • lso_lvset_unmatched_disk_count: 条件の不一致により、ローカルストレージ Operator がプロビジョニング用に選択しなかったディスクの合計数
  • lso_lvset_orphaned_symlink_count: LocalVolumeSet オブジェクト基準に一致しなくなった PV のあるデバイスの数
  • lso_lv_orphaned_symlink_count: LocalVolume オブジェクト基準に一致しなくなった PV のあるデバイスの数
  • lso_lv_provisioned_PV_count: LocalVolume のプロビジョニングされた PV の合計数

これらのメトリクスを使用するには、以下の点を確認してください。

  • ローカルストレージ Operator のインストール時に、モニタリングのサポートを有効にする。
  • OpenShift Container Platform 4.9 以降にアップグレードする場合は、namespace に operator-metering=true ラベルを追加してメトリクスサポートを手動で有効にしてください。

メトリクスの詳細は、メトリクスの管理 を参照してください。

4.12.1.9. ローカルストレージ Operator のリソースの削除

4.12.1.9.1. ローカルボリュームまたはローカルボリュームセットの削除

ローカルボリュームおよびローカルボリュームセットを削除する必要がある場合があります。リソースのエントリーを削除し、永続ボリュームを削除することで通常は十分ですが、同じデバイスパスを再使用する場合や別のストレージクラスでこれを管理する必要がある場合には、追加の手順が必要になります。

注記

以下の手順では、ローカルボリュームを削除する例の概要を説明します。同じ手順を使用して、ローカルボリュームセットのカスタムリソースのシンボリックリンクを削除することもできます。

前提条件

  • 永続ボリュームの状態は Released または Available である必要があります。

    警告

    使用中の永続ボリュームを削除すると、データの損失や破損につながる可能性があります。

手順

  1. 以前に作成したローカルボリュームを編集して、不要なディスクを削除します。

    1. クラスターリソースを編集します。

      $ oc edit localvolume <name> -n openshift-local-storage
    2. devicePaths の下の行に移動し、不要なディスクを表すものを削除します。
  2. 作成した永続ボリュームを削除します。

    $ oc delete pv <pv-name>
  3. ノード上のディレクトリーと含まれるシンボリックリンクを削除します。

    警告

    以下の手順では、root ユーザーとしてノードにアクセスする必要があります。この手順のステップ以外にノードの状態を変更すると、クラスターが不安定になる可能性があります。

    $ oc debug node/<node-name> -- chroot /host rm -rf /mnt/local-storage/<sc-name> 1
    1
    ローカルボリュームの作成に使用されるストレージクラスの名前。
4.12.1.9.2. ローカルストレージ Operator のアンインストール

ローカルストレージ Operator をアンインストールするには、Operator および openshift-local-storage プロジェクトの作成されたすべてのリソースを削除する必要があります。

警告

ローカルストレージ PV がまだ使用中の状態でローカルストレージ Operator をアンインストールすることは推奨されません。PV は Operator の削除後も残りますが、PV およびローカルストレージリソースを削除せずに Operator がアンインストールされ、再インストールされる場合に予測できない動作が生じる可能性があります。

前提条件

  • OpenShift Container Platform Web コンソールにアクセスできる。

手順

  1. プロジェクトにインストールされているローカルボリュームリソースを削除します (localvolumelocalvolumesetlocalvolumediscovery等)。

    $ oc delete localvolume --all --all-namespaces
    $ oc delete localvolumeset --all --all-namespaces
    $ oc delete localvolumediscovery --all --all-namespaces
  2. Web コンソールからローカルストレージ Operator をアンインストールします。

    1. OpenShift Container Platform Web コンソールにログインします。
    2. Operators Installed Operators に移動します。
    3. Local Storage をフィルターボックスに入力して、ローカルストレージ Operator を見つけます。
    4. ローカルストレージ Operator の末尾にある Options メニュー kebab をクリックします。
    5. Uninstall Operator をクリックします。
    6. 表示されるウィンドウで Remove をクリックします。
  3. ローカルストレージ Operator で作成された PV は削除されるまでクラスターに残ります。これらのボリュームが使用されなくなったら、以下のコマンドを実行してこれらのボリュームを削除します。

    $ oc delete pv <pv-name>
  4. openshift-local-storage プロジェクトを削除します。

    $ oc delete project openshift-local-storage

4.12.2. hostPath を使用した永続ストレージ

OpenShift Container Platform クラスター内の hostPath ボリュームは、ファイルまたはディレクトリーをホストノードのファイルシステムから Pod にマウントします。ほとんどの Pod には hostPath ボリュームは必要ありませんが、アプリケーションが必要とする場合は、テスト用のクイックオプションが提供されます。

重要

クラスター管理者は、特権付き Pod として実行するように Pod を設定する必要があります。これにより、同じノードの Pod へのアクセスが付与されます。

4.12.2.1. 概要

OpenShift Container Platform はシングルノードクラスターでの開発およびテスト用の hostPath マウントをサポートします。

実稼働クラスターでは、hostPath を使用しません。代わりにクラスター管理者は、GCE Persistent Disk ボリューム、NFS 共有、Amazon EBS ボリュームなどのネットワークリソースをプロビジョニングします。ネットワークリソースは、ストレージクラスを使用した動的プロビジョニングの設定をサポートします。

hostPath ボリュームは静的にプロビジョニングする必要があります。

重要

コンテナーのルート (/) や、ホストとコンテナーで同じパスにはマウントしないでください。これは、コンテナーに十分な特権が付与されている場合、ホストシステムを破壊する可能性があります。ホストをマウントするには、/host を使用するのが安全です。以下の例では、ホストの / ディレクトリーが /host でコンテナーにマウントされています。

apiVersion: v1
kind: Pod
metadata:
  name: test-host-mount
spec:
  containers:
  - image: registry.access.redhat.com/ubi8/ubi
    name: test-container
    command: ['sh', '-c', 'sleep 3600']
    volumeMounts:
    - mountPath: /host
      name: host-slash
  volumes:
   - name: host-slash
     hostPath:
       path: /
       type: ''

4.12.2.2. hostPath ボリュームの静的なプロビジョニング

hostPath ボリュームを使用する Pod は、手動の (静的) プロビジョニングで参照される必要があります。

手順

  1. 永続ボリューム (PV) を定義します。PersistentVolume オブジェクト定義を使用して pv.yaml ファイルを作成します。

      apiVersion: v1
      kind: PersistentVolume
      metadata:
        name: task-pv-volume 1
        labels:
          type: local
      spec:
        storageClassName: manual 2
        capacity:
          storage: 5Gi
        accessModes:
          - ReadWriteOnce 3
        persistentVolumeReclaimPolicy: Retain
        hostPath:
          path: "/mnt/data" 4
    1
    ボリュームの名前。この名前は永続ボリューム要求 (PVC) または Pod で識別されるものです。
    2
    永続ボリューム要求 (PVC) をこの永続ボリュームにバインドするために使用されます。
    3
    ボリュームはシングルノードで read-write としてマウントできます。
    4
    設定ファイルでは、ボリュームがクラスターのノードの /mnt/data にあるように指定します。コンテナーのルート (/) や、ホストとコンテナーで同じパスにはマウントしないでください。これにより、ホストシステムを破壊する可能性があります。ホストをマウントするには、/host を使用するのが安全です。
  2. ファイルから PV を作成します。

    $ oc create -f pv.yaml
  3. 永続ボリューム要求 (PVC) を定義します。PersistentVolumeClaim オブジェクト定義を使用して、ファイル pvc.yaml を作成します。

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: task-pvc-volume
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi
      storageClassName: manual
  4. ファイルから PVC を作成します。

    $ oc create -f pvc.yaml

4.12.2.3. 特権付き Pod での hostPath 共有のマウント

永続ボリューム要求 (PVC) の作成後に、これをアプリケーション内で使用できます。以下の例は、この共有を Pod 内にマウントする方法を示しています。

前提条件

  • 基礎となる hostPath 共有にマップされる永続ボリューム要求 (PVC) があること。

手順

  • 既存の永続ボリューム要求 (PVC) をマウントする特権付き Pod を作成します。

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-name 1
    spec:
      containers:
        ...
        securityContext:
          privileged: true 2
        volumeMounts:
        - mountPath: /data 3
          name: hostpath-privileged
      ...
      securityContext: {}
      volumes:
        - name: hostpath-privileged
          persistentVolumeClaim:
            claimName: task-pvc-volume 4
    1
    Pod の名前。
    2
    Pod は、ノードのストレージにアクセスするために特権付き Pod として実行される必要があります。
    3
    特権付き Pod 内にホストパス共有をマウントするパス。コンテナーのルート (/) や、ホストとコンテナーで同じパスにはマウントしないでください。これは、コンテナーに十分な特権が付与されている場合に、ホストシステムを破壊する可能性があります (例: ホストの /dev/pts ファイル)。ホストをマウントするには、/host を使用するのが安全です。
    4
    以前に作成された PersistentVolumeClaim オブジェクトの名前。

4.12.3. Logical Volume Manager Storage を使用した永続ストレージ

論理ボリュームマネージャーストレージ (LVM ストレージ) は、TopoLVM CSI ドライバーを使用して、シングルノード OpenShift クラスターでローカルストレージを動的にプロビジョニングします。

LVM ストレージは、論理ボリュームマネージャーを使用してシンプロビジョニングボリュームを作成し、限られたリソースのシングルノード OpenShift クラスターでブロックストレージの動的プロビジョニングを提供します。

LVM Storage を使用すると、ボリュームグループ、永続ボリューム要求 (PVC)、ボリュームスナップショット、およびボリュームクローンを作成できます。

4.12.3.1. Logical Volume Manager Storage のインストール

単一ノードの OpenShift クラスターに論理ボリュームマネージャー(LVM)ストレージをインストールし、ワークロードのストレージを動的にプロビジョニングするように設定できます。

OpenShift Container Platform CLI (oc)、OpenShift Container Platform Web コンソール、または Red Hat Advanced Cluster Management (RHACM)を使用して、シングルノード OpenShift クラスターに LVM ストレージをデプロイできます。

4.12.3.1.1. LVM Storage をインストールするための前提条件

LVM Storage をインストールするための前提条件は次のとおりです。

  • 最低でも 10 ミリの CPU と 100 MiB の RAM があることを確認してください。
  • すべてのマネージドクラスターに、ストレージのプロビジョニングに使用される専用のディスクがあることを確認してください。LVM Storage は、ファイルシステム署名が含まれていない空のディスクのみを使用します。確実にディスクが空で、ファイルシステム署名が含まれていないようにするには、使用する前にディスクを消去します。
  • 以前の LVM Storage のインストールで設定したストレージデバイスを再利用できるプライベート CI 環境に LVM Storage をインストールする前に、使用されていないディスクが消去されていることを確認してください。LVM Storage をインストールする前にディスクをワイプしないと、ディスクを再利用するのに手動による介入が必要になります。

    注記

    使用中のディスクは消去できません。

  • Red Hat Advanced Cluster Management (RHACM) を使用して LVM Storage をインストールする場合は、RHACM が OpenShift Container Platform クラスターにインストールされていることを確認してください。RHACM を使用した LVM Storage のインストール セクションを参照してください。
4.12.3.1.2. OpenShift Container Platform Web コンソールを使用した LVM ストレージのインストール

Red Hat OpenShift Container Platform OperatorHub を使用して LVM ストレージをインストールできます。

前提条件

  • シングルノード OpenShift クラスターにアクセスできます。
  • cluster-admin および Operator のインストール権限を持つアカウントを使用しています。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. Operators OperatorHub をクリックします。
  3. スクロールするか、LVM StorageFilter by keyword ボックスに入力して、LVM Storage を見つけます。
  4. Install をクリックします。
  5. Install Operator ページで、以下のオプションを設定します。

    1. stable-4.12 としての Update Channel
    2. クラスター上の特定の namespace としての Installation Mode
    3. Installed NamespaceOperator recommended namespace openshift-storage に設定します。openshift-storage namespace が存在しない場合は、Operator のインストール中に作成されます。
    4. Approval StrategyAutomatic または Manual に設定します。

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

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

  6. Install をクリックします。

検証手順

  • インストールが成功したことを示す緑色のチェックマークが LVM ストレージに表示されていることを確認します。
4.12.3.1.3. OpenShift Web コンソールを使用してインストールされた LVM ストレージのアンインストール

Red Hat OpenShift Container Platform Web コンソールを使用して、LVM ストレージをアンインストールできます。

前提条件

  • LVM Storage によってプロビジョニングされたストレージを使用しているクラスター上のすべてのアプリケーションを削除しました。
  • LVM Storage を使用してプロビジョニングされた永続ボリューム要求 (PVC) と永続ボリューム (PV) を削除しました。
  • LVM Storage によってプロビジョニングされたすべてのボリュームスナップショットを削除しました。
  • oc get logicalvolume コマンドを使用して、論理ボリュームリソースが存在しないことを確認しました。
  • cluster-admin 権限を持つアカウントを使用して、シングルノード OpenShift クラスターにアクセスできます。

手順

  1. Operators Installed Operators ページから、LVM Storage にスクロールするか、LVM StorageFilter by name に入力して検索し、クリックします。
  2. LVMCluster タブをクリックします。
  3. LVMCluster ページの右側で、Actions ドロップダウンメニューから Delete LVMCluster を選択します。
  4. Details タブをクリックします。
  5. Operator Details ページの右側で、Actions ドロップダウンメニューから Uninstall Operator を選択します。
  6. Remove を選択します。LVM ストレージは実行を停止し、完全に削除されます。
4.12.3.1.4. RHACM を使用した LVM ストレージのインストール

LVM ストレージは、Red Hat Advanced Cluster Management (RHACM) を使用してシングルノード OpenShift クラスターにデプロイされます。RHACM に Policy オブジェクトを作成します。これは、PlacementRule リソースで指定されたセレクターに一致するマネージドクラスターに適用される際に Operator をデプロイおよび設定します。このポリシーは、後でインポートされ、配置ルールを満たすクラスターにも適用されます。

前提条件

  • cluster-admin および Operator インストール権限を持つアカウントを使用して、RHACM クラスターにアクセスします。
  • LVM ストレージによって使用される各シングルノード OpenShift クラスターの専用ディスク。
  • シングルノード OpenShift クラスターは、インポートまたは作成された RHACM によって管理される必要があります。

手順

  1. OpenShift Container Platform の認証情報を使用して RHACM CLI にログインします。
  2. ポリシーを作成する namespace を作成します。

    # oc create ns lvms-policy-ns
  3. ポリシーを作成するには、次の YAML を policy-lvms-operator.yaml などの名前でファイルに保存します。

    apiVersion: apps.open-cluster-management.io/v1
    kind: PlacementRule
    metadata:
      name: placement-install-lvms
    spec:
      clusterConditions:
      - status: "True"
        type: ManagedClusterConditionAvailable
      clusterSelector: 1
        matchExpressions:
        - key: mykey
          operator: In
          values:
          - myvalue
    ---
    apiVersion: policy.open-cluster-management.io/v1
    kind: PlacementBinding
    metadata:
      name: binding-install-lvms
    placementRef:
      apiGroup: apps.open-cluster-management.io
      kind: PlacementRule
      name: placement-install-lvms
    subjects:
    - apiGroup: policy.open-cluster-management.io
      kind: Policy
      name: install-lvms
    ---
    apiVersion: policy.open-cluster-management.io/v1
    kind: Policy
    metadata:
      annotations:
        policy.open-cluster-management.io/categories: CM Configuration Management
        policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
        policy.open-cluster-management.io/standards: NIST SP 800-53
      name: install-lvms
    spec:
      disabled: false
      remediationAction: enforce
      policy-templates:
      - objectDefinition:
          apiVersion: policy.open-cluster-management.io/v1
          kind: ConfigurationPolicy
          metadata:
            name: install-lvms
          spec:
            object-templates:
            - complianceType: musthave
              objectDefinition:
                apiVersion: v1
                kind: Namespace
                metadata:
                  labels:
                    openshift.io/cluster-monitoring: "true"
                    pod-security.kubernetes.io/enforce: privileged
                    pod-security.kubernetes.io/audit: privileged
                    pod-security.kubernetes.io/warn: privileged
                  name: openshift-storage
            - complianceType: musthave
              objectDefinition:
                apiVersion: operators.coreos.com/v1
                kind: OperatorGroup
                metadata:
                  name: openshift-storage-operatorgroup
                  namespace: openshift-storage
                spec:
                  targetNamespaces:
                  - openshift-storage
            - complianceType: musthave
              objectDefinition:
                apiVersion: operators.coreos.com/v1alpha1
                kind: Subscription
                metadata:
                  name: lvms
                  namespace: openshift-storage
                spec:
                  installPlanApproval: Automatic
                  name: lvms-operator
                  source: redhat-operators
                  sourceNamespace: openshift-marketplace
            remediationAction: enforce
            severity: low
      - objectDefinition:
          apiVersion: policy.open-cluster-management.io/v1
          kind: ConfigurationPolicy
          metadata:
            name: lvms
          spec:
            object-templates:
               - complianceType: musthave
                 objectDefinition:
                   apiVersion: lvm.topolvm.io/v1alpha1
                   kind: LVMCluster
                   metadata:
                     name: my-lvmcluster
                     namespace: openshift-storage
                   spec:
                     storage:
                       deviceClasses:
                       - name: vg1
                         deviceSelector: 2
                           paths:
                           - /dev/disk/by-path/pci-0000:87:00.0-nvme-1
                           - /dev/disk/by-path/pci-0000:88:00.0-nvme-1
                         thinPoolConfig:
                           name: thin-pool-1
                           sizePercent: 90
                           overprovisionRatio: 10
                         nodeSelector: 3
                           nodeSelectorTerms:
                           - matchExpressions:
                               - key: app
                                 operator: In
                                 values:
                                 - test1
            remediationAction: enforce
            severity: low
    1
    LVM ストレージをインストールするシングルノード OpenShift クラスターに設定されたラベルと一致するように、PlacementRule.spec.clusterSelector のキーと値を置き換えます。
    2
    ボリュームグループを優先ディスクに制御または制限するには、LVMCluster YAML の deviceSelector セクションでディスクのローカルパスを手動で指定します。
    3
    追加のワーカーノードのサブセットであるノードフィルターを追加するには、nodeSelector セクションに必要なフィルターを指定します。LVM Storage は、新しいノードが表示されると、追加のワーカーノードを検出して使用します。
    重要

    この nodeSelector ノードフィルターの一致は、Pod ラベルの一致と同じではありません。

  4. 次のコマンドを実行して、namespace にポリシーを作成します。

    # oc create -f policy-lvms-operator.yaml -n lvms-policy-ns 1
    1
    policy-lvms-operator.yaml は、ポリシーが保存されるファイルの名前です。

    これにより、lvms-policy-ns namespace に PolicyPlacementRule、および PlacementBinding オブジェクトが作成されます。このポリシーは、配置ルールに一致するクラスター上に NamespaceOperatorGroupSubscription、および LVMCluster リソースを作成します。これにより、選択基準に一致するシングルノード OpenShift クラスターに Operator がデプロイされ、ストレージをプロビジョニングするために必要なリソースをセットアップするように設定されます。Operator は LVMCluster CR で指定されたすべてのディスクを使用します。ディスクが指定されていない場合、Operator はシングルノード OpenShift ノード上の未使用のディスクをすべて使用します。

    重要

    LVMCluster に追加されたデバイスは削除できません。

4.12.3.1.5. RHACM を使用してインストールされた LVM ストレージのアンインストール

RHACM を使用してインストールした LVM Storage をアンインストールするには、Operator のデプロイと設定のために作成した RHACM ポリシーを削除する必要があります。

RHACM ポリシーを削除しても、ポリシーが作成したリソースは削除されません。リソースを削除する追加のポリシーを作成する必要があります。

ポリシーを削除しても、作成されたリソースは削除されないため、次の手順を実行する必要があります。

  1. LVM Storage によってプロビジョニングされたすべての永続ボリューム要求 (PVC) とボリュームスナップショットを削除します。
  2. LVMCluster リソースを削除して、ディスク上に作成された論理ボリュームマネージャーリソースをクリーンアップします。
  3. Operator をアンインストールする追加のポリシーを作成します。

前提条件

  • ポリシーを削除する前に、以下が削除されていることを確認してください。

    • LVM Storage によってプロビジョニングされたストレージを使用しているマネージドクラスター上のすべてのアプリケーション。
    • LVM Storage を使用してプロビジョニングされた PVC および永続ボリューム (PV)。
    • LVM Storage によってプロビジョニングされたすべてのボリュームスナップショット。
  • cluster-admin ロールを持つアカウントを使用して RHACM クラスターにアクセスできることを確認します。

手順

  1. OpenShift CLI (oc) で、次のコマンドを使用して、ハブクラスターに LVM Storage をデプロイおよび設定するために作成した RHACM ポリシーを削除します。

    # oc delete -f policy-lvms-operator.yaml -n lvms-policy-ns 1
    1
    policy-lvms-operator.yaml は、ポリシーが保存されたファイルの名前です。
  2. LVMCluster リソースを削除するためのポリシーを作成するには、次の YAML を lvms-remove-policy.yaml などの名前でファイルに保存します。これにより、Operator はクラスター上で作成したすべての論理ボリュームマネージャーリソースをクリーンアップできます。

    apiVersion: policy.open-cluster-management.io/v1
    kind: Policy
    metadata:
      name: policy-lvmcluster-delete
      annotations:
        policy.open-cluster-management.io/standards: NIST SP 800-53
        policy.open-cluster-management.io/categories: CM Configuration Management
        policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
    spec:
      remediationAction: enforce
      disabled: false
      policy-templates:
        - objectDefinition:
            apiVersion: policy.open-cluster-management.io/v1
            kind: ConfigurationPolicy
            metadata:
              name: policy-lvmcluster-removal
            spec:
              remediationAction: enforce 1
              severity: low
              object-templates:
                - complianceType: mustnothave
                  objectDefinition:
                    kind: LVMCluster
                    apiVersion: lvm.topolvm.io/v1alpha1
                    metadata:
                      name: my-lvmcluster
                      namespace: openshift-storage 2
    ---
    apiVersion: policy.open-cluster-management.io/v1
    kind: PlacementBinding
    metadata:
      name: binding-policy-lvmcluster-delete
    placementRef:
      apiGroup: apps.open-cluster-management.io
      kind: PlacementRule
      name: placement-policy-lvmcluster-delete
    subjects:
      - apiGroup: policy.open-cluster-management.io
        kind: Policy
        name: policy-lvmcluster-delete
    ---
    apiVersion: apps.open-cluster-management.io/v1
    kind: PlacementRule
    metadata:
      name: placement-policy-lvmcluster-delete
    spec:
      clusterConditions:
        - status: "True"
          type: ManagedClusterConditionAvailable
      clusterSelector:
        matchExpressions:
          - key: mykey
            operator: In
            values:
              - myvalue
    1
    policy-templatespec.remediationAction は、spec.remediationAction の前のパラメーター値によってオーバーライドされます。
    2
    この namespace フィールドには openshift-storage 値が必要です。
  3. PlacementRule.spec.clusterSelector フィールドの値を設定して、LVM Storage をアンインストールするクラスターを選択します。
  4. 次のコマンドを実行してポリシーを作成します。

    # oc create -f lvms-remove-policy.yaml -n lvms-policy-ns
  5. LVMCluster CR が削除されたかどうかを確認するポリシーを作成するには、次の YAML を check-lvms-remove-policy.yaml などの名前でファイルに保存します。

    apiVersion: policy.open-cluster-management.io/v1
    kind: Policy
    metadata:
      name: policy-lvmcluster-inform
      annotations:
        policy.open-cluster-management.io/standards: NIST SP 800-53
        policy.open-cluster-management.io/categories: CM Configuration Management
        policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
    spec:
      remediationAction: inform
      disabled: false
      policy-templates:
        - objectDefinition:
            apiVersion: policy.open-cluster-management.io/v1
            kind: ConfigurationPolicy
            metadata:
              name: policy-lvmcluster-removal-inform
            spec:
              remediationAction: inform 1
              severity: low
              object-templates:
                - complianceType: mustnothave
                  objectDefinition:
                    kind: LVMCluster
                    apiVersion: lvm.topolvm.io/v1alpha1
                    metadata:
                      name: my-lvmcluster
                      namespace: openshift-storage 2
    ---
    apiVersion: policy.open-cluster-management.io/v1
    kind: PlacementBinding
    metadata:
      name: binding-policy-lvmcluster-check
    placementRef:
      apiGroup: apps.open-cluster-management.io
      kind: PlacementRule
      name: placement-policy-lvmcluster-check
    subjects:
      - apiGroup: policy.open-cluster-management.io
        kind: Policy
        name: policy-lvmcluster-inform
    ---
    apiVersion: apps.open-cluster-management.io/v1
    kind: PlacementRule
    metadata:
      name: placement-policy-lvmcluster-check
    spec:
      clusterConditions:
        - status: "True"
          type: ManagedClusterConditionAvailable
      clusterSelector:
        matchExpressions:
          - key: mykey
            operator: In
            values:
              - myvalue
    1
    policy-templatespec.remediationAction は、spec.remediationAction の前のパラメーター値によってオーバーライドされます。
    2
    namespace フィールドには openshift-storage 値が必要です。
  6. 次のコマンドを実行してポリシーを作成します。

    # oc create -f check-lvms-remove-policy.yaml -n lvms-policy-ns
  7. 次のコマンドを実行して、ポリシーのステータスを確認します。

    # oc get policy -n lvms-policy-ns

    出力例

    NAME                       REMEDIATION ACTION   COMPLIANCE STATE   AGE
    policy-lvmcluster-delete   enforce              Compliant          15m
    policy-lvmcluster-inform   inform               Compliant          15m

  8. 両方のポリシーに準拠したら、次の YAML を lvms-uninstall-policy.yaml などの名前のファイルに保存して、LVM Storage をアンインストールするポリシーを作成します。

    apiVersion: apps.open-cluster-management.io/v1
    kind: PlacementRule
    metadata:
      name: placement-uninstall-lvms
    spec:
      clusterConditions:
      - status: "True"
        type: ManagedClusterConditionAvailable
      clusterSelector:
        matchExpressions:
        - key: mykey
          operator: In
          values:
          - myvalue
    ---
    apiVersion: policy.open-cluster-management.io/v1
    kind: PlacementBinding
    metadata:
      name: binding-uninstall-lvms
    placementRef:
      apiGroup: apps.open-cluster-management.io
      kind: PlacementRule
      name: placement-uninstall-lvms
    subjects:
    - apiGroup: policy.open-cluster-management.io
      kind: Policy
      name: uninstall-lvms
    ---
    apiVersion: policy.open-cluster-management.io/v1
    kind: Policy
    metadata:
      annotations:
        policy.open-cluster-management.io/categories: CM Configuration Management
        policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
        policy.open-cluster-management.io/standards: NIST SP 800-53
      name: uninstall-lvms
    spec:
      disabled: false
      policy-templates:
      - objectDefinition:
          apiVersion: policy.open-cluster-management.io/v1
          kind: ConfigurationPolicy
          metadata:
            name: uninstall-lvms
          spec:
            object-templates:
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: v1
                kind: Namespace
                metadata:
                  name: openshift-storage
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: operators.coreos.com/v1
                kind: OperatorGroup
                metadata:
                  name: openshift-storage-operatorgroup
                  namespace: openshift-storage
                spec:
                  targetNamespaces:
                  - openshift-storage
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: operators.coreos.com/v1alpha1
                kind: Subscription
                metadata:
                  name: lvms-operator
                  namespace: openshift-storage
            remediationAction: enforce
            severity: low
      - objectDefinition:
          apiVersion: policy.open-cluster-management.io/v1
          kind: ConfigurationPolicy
          metadata:
            name: policy-remove-lvms-crds
          spec:
            object-templates:
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: apiextensions.k8s.io/v1
                kind: CustomResourceDefinition
                metadata:
                  name: logicalvolumes.topolvm.io
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: apiextensions.k8s.io/v1
                kind: CustomResourceDefinition
                metadata:
                  name: lvmclusters.lvm.topolvm.io
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: apiextensions.k8s.io/v1
                kind: CustomResourceDefinition
                metadata:
                  name: lvmvolumegroupnodestatuses.lvm.topolvm.io
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: apiextensions.k8s.io/v1
                kind: CustomResourceDefinition
                metadata:
                  name: lvmvolumegroups.lvm.topolvm.io
            remediationAction: enforce
            severity: high
  9. 次のコマンドを実行してポリシーを作成します。

    # oc create -f lvms-uninstall-policy.yaml -ns lvms-policy-ns

4.12.3.2. LVM Storage で使用するデバイスのサイズを設定する際の制限事項

LVM Storage を使用したストレージのプロビジョニングで使用できるデバイスのサイズを設定する際の制限は、次のとおりです。

  • プロビジョニングできる合計ストレージサイズは、基礎となる論理ボリュームマネージャー (LVM) シンプールのサイズとオーバープロビジョニング係数によって制限されます。
  • 論理ボリュームのサイズは、物理エクステント (PE) のサイズと論理エクステント (LE) のサイズによって異なります。

    • PE および LE のサイズは、物理デバイスおよび論理デバイスの作成時に定義できます。
    • デフォルトの PE および LE サイズは 4 MB です。
    • PE のサイズを大きくした場合、LVM の最大サイズは、カーネルの制限とディスク領域によって決定されます。
表4.1 デフォルトの PE および LE サイズを使用した各アーキテクチャーのサイズ制限
アーキテクチャーRHEL 6RHEL 7RHEL 8RHEL 9

32 ビット

16 TB

-

-

-

64 ビット

8 EB [1]

100 TB [2]

8 EB [1]

500 TB [2]

8 EB

8 EB

  1. 理論的サイズ。
  2. テスト済みサイズ。

4.12.3.3. 論理ボリュームマネージャークラスターの作成

LVM ストレージをインストールした後、論理ボリュームマネージャークラスターを作成できます。

OpenShift Container Platform は、ユーザーがプロビジョニングしたベアメタルインフラストラクチャー上のシングルノード OpenShift クラスターの追加のワーカーノードをサポートします。LVM ストレージは、新しいノードが表示されると、追加のワーカーノードを検出して使用します。追加のワーカーノードにノードフィルターを設定する必要がある場合は、クラスターの作成中に YAML ビューを使用できます。

OpenShift Container Platform クラスターでは、LVMCluster カスタムリソース (CR) のインスタンスを 1 つだけ作成できます。

重要

このノードフィルターの一致は、Pod ラベルの一致と同じではありません。

前提条件

  • OperatorHub から LVM Storage をインストールしました。

手順

  1. OpenShift Container Platform Web コンソールで、Operators Installed Operators をクリックして、インストールされているすべての Operator を表示します。

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

  2. LVM Storage をクリックし、LVMCluster の下の Create LVMCluster をクリックします。
  3. Create LVMCluster ページで、Form view または YAML view のいずれかを選択します。
  4. クラスターの名前を入力します。
  5. Create をクリックします。
  6. オプション: ノードフィルターを追加するには、YAML view をクリックし、nodeSelector セクションでフィルターを指定します。

    apiVersion: lvm.topolvm.io/v1alpha1
    kind: LVMCluster
    metadata:
      name: my-lvmcluster
    spec:
      storage:
        deviceClasses:
          - name: vg1
            thinPoolConfig:
              name: thin-pool-1
              sizePercent: 90
              overprovisionRatio: 10
            nodeSelector:
              nodeSelectorTerms:
                - matchExpressions:
                  - key: app
                    operator: In
                    values:
                    - test1
  7. オプション: ディスクのローカルデバイスパスを編集するには、YAML view をクリックし、deviceSelector セクションでデバイスパスを指定します。

    spec:
      storage:
        deviceClasses:
          - name: vg1
            deviceSelector:
              paths:
              - /dev/disk/by-path/pci-0000:87:00.0-nvme-1
              - /dev/disk/by-path/pci-0000:88:00.0-nvme-1
            thinPoolConfig:
              name: thin-pool-1
              sizePercent: 90
              overprovisionRatio: 10

検証手順

  1. OpenShift Container Platform Web コンソールの左ペインから Storage Storage Classes をクリックします。
  2. LVMCluster の作成で lvms-<device-class-name> ストレージクラスが作成されていることを確認します。デフォルトでは、vg1device-class-name です。

4.12.3.4. LVM ストレージを使用したストレージのプロビジョニング

Operator のインストール中に作成されたストレージクラスを使用して、永続ボリューム要求 (PVC) をプロビジョニングできます。ブロックおよびファイル PVC をプロビジョニングできますが、ストレージは、PVC を使用する Pod が作成された場合にのみ割り当てられます。

注記

LVM Storage は、PVC を 1 GiB 単位でプロビジョニングします。要求されたストレージは、最も近い GiB に切り上げられます。

手順

  1. LVM Storage のデプロイ時に作成される StorageClass を特定します。

    StorageClass 名の形式は lvms-<device-class-name> です。device-class-name は、Policy YAML の LVMCluster で指定したデバイスクラスの名前です。たとえば、deviceClass の名前が vg1 の場合、storageClass の名前は lvms-vg1 です。

    ストレージクラスの volumeBindingModeWaitForFirstConsumer に設定されます。

  2. アプリケーションがストレージを必要とする PVC を作成するには、次の YAML を pvc.yaml などの名前でファイルに保存します。

    PVC を作成する YAML の例

    # block pvc
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: lvm-block-1
      namespace: default
    spec:
      accessModes:
        - ReadWriteOnce
      volumeMode: Block
      resources:
        requests:
          storage: 10Gi
      storageClassName: lvms-vg1
    ---
    # file pvc
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: lvm-file-1
      namespace: default
    spec:
      accessModes:
        - ReadWriteOnce
      volumeMode: Filesystem
      resources:
        requests:
          storage: 10Gi
      storageClassName: lvms-vg1

  3. 以下のコマンドを実行して PVC を作成します。

    # oc create -f pvc.yaml -ns <application_namespace>

    作成された PVC は、それらを使用する Pod をデプロイするまで pending 状態のままになります。

4.12.3.5. シングルノード OpenShift クラスターのストレージのスケーリング

OpenShift Container Platform は、ユーザーがプロビジョニングしたベアメタルインフラストラクチャー上のシングルノード OpenShift クラスターの追加のワーカーノードをサポートします。LVM ストレージは、ノードが表示されると、新しい追加のワーカーノードを検出して使用します。

4.12.3.5.1. シングルノード OpenShift クラスターに容量を追加してストレージをスケールアップする

シングルノード OpenShift クラスターで設定済みのワーカーノードのストレージ容量をスケーリングするには、ディスクを追加して容量を増やすことができます。

前提条件

  • シングルノード OpenShift クラスターごとに、LVM ストレージで使用される追加の未使用ディスクがあります。

手順

  1. シングルノード OpenShift クラスターの OpenShift Container Platform コンソールにログインします。
  2. Operators Installed Operators ページで、openshift-storage namespace の LVM Storage Operator をクリックします。
  3. LVMCluster タブをクリックして、クラスターで作成された LVMCluster CR を一覧表示します。
  4. Actions ドロップダウンメニューから Edit LVMCluster を選択します。
  5. YAML タブをクリックします。
  6. LVMCluster CR YAML を編集して、deviceSelector セクションに新しいデバイスパスを追加します。

    注記

    LVMCluster の作成中に deviceSelector フィールドが含まれていない場合、deviceSelector セクションを CR に追加することはできません。LVMCluster を削除してから、新しい CR を作成する必要があります。

    apiVersion: lvm.topolvm.io/v1alpha1
    kind: LVMCluster
    metadata:
      name: my-lvmcluster
    spec:
      storage:
        deviceClasses:
        - name: vg1
          deviceSelector:
            paths:
            - /dev/disk/by-path/pci-0000:87:00.0-nvme-1 1
            - /dev/disk/by-path/pci-0000:88:00.0-nvme-1
            - /dev/disk/by-path/pci-0000:89:00.0-nvme-1 2
          thinPoolConfig:
            name: thin-pool-1
            sizePercent: 90
            overprovisionRatio: 10
    1
    パスは、名前 (/dev/sdb) またはパスで追加できます。
    2
    新しいディスクが追加されます。
4.12.3.5.2. RHACM を使用してシングルノード OpenShift クラスターに容量を追加してストレージをスケールアップする

RHACM を使用して、シングルノード OpenShift クラスターで設定済みのワーカーノードのストレージ容量をスケーリングできます。

前提条件

  • cluster-admin 権限を持つアカウントを使用して RHACM クラスターにアクセスできます。
  • シングルノード OpenShift クラスターごとに、LVM ストレージで使用される追加の未使用ディスクがあります。

手順

  1. OpenShift Container Platform の認証情報を使用して RHACM CLI にログインします。
  2. 追加するディスクを見つけます。追加するディスクは、既存のディスクのデバイス名およびパスと一致するようにする必要があります。
  3. シングルノード OpenShift クラスターに容量を追加するには、既存のポリシー YAML の deviceSelector セクション (policy-lvms-operator.yaml など) を編集します。

    注記

    LVMCluster の作成中に deviceSelector フィールドが含まれていない場合、deviceSelector セクションを CR に追加することはできません。LVMCluster を削除してから、新しい CR から再作成する必要があります。

    apiVersion: apps.open-cluster-management.io/v1
    kind: PlacementRule
    metadata:
      name: placement-install-lvms
    spec:
      clusterConditions:
      - status: "True"
        type: ManagedClusterConditionAvailable
      clusterSelector:
        matchExpressions:
        - key: mykey
          operator: In
          values:
          - myvalue
    ---
    apiVersion: policy.open-cluster-management.io/v1
    kind: PlacementBinding
    metadata:
      name: binding-install-lvms
    placementRef:
      apiGroup: apps.open-cluster-management.io
      kind: PlacementRule
      name: placement-install-lvms
    subjects:
    - apiGroup: policy.open-cluster-management.io
      kind: Policy
      name: install-lvms
    ---
    apiVersion: policy.open-cluster-management.io/v1
    kind: Policy
    metadata:
      annotations:
        policy.open-cluster-management.io/categories: CM Configuration Management
        policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
        policy.open-cluster-management.io/standards: NIST SP 800-53
      name: install-lvms
    spec:
      disabled: false
      remediationAction: enforce
      policy-templates:
      - objectDefinition:
          apiVersion: policy.open-cluster-management.io/v1
          kind: ConfigurationPolicy
          metadata:
            name: install-lvms
          spec:
            object-templates:
            - complianceType: musthave
              objectDefinition:
                apiVersion: v1
                kind: Namespace
                metadata:
                  labels:
                    openshift.io/cluster-monitoring: "true"
                    pod-security.kubernetes.io/enforce: privileged
                    pod-security.kubernetes.io/audit: privileged
                    pod-security.kubernetes.io/warn: privileged
                  name: openshift-storage
            - complianceType: musthave
              objectDefinition:
                apiVersion: operators.coreos.com/v1
                kind: OperatorGroup
                metadata:
                  name: openshift-storage-operatorgroup
                  namespace: openshift-storage
                spec:
                  targetNamespaces:
                  - openshift-storage
            - complianceType: musthave
              objectDefinition:
                apiVersion: operators.coreos.com/v1alpha1
                kind: Subscription
                metadata:
                  name: lvms
                  namespace: openshift-storage
                spec:
                  installPlanApproval: Automatic
                  name: lvms-operator
                  source: redhat-operators
                  sourceNamespace: openshift-marketplace
            remediationAction: enforce
            severity: low
      - objectDefinition:
          apiVersion: policy.open-cluster-management.io/v1
          kind: ConfigurationPolicy
          metadata:
            name: lvms
          spec:
            object-templates:
               - complianceType: musthave
                 objectDefinition:
                   apiVersion: lvm.topolvm.io/v1alpha1
                   kind: LVMCluster
                   metadata:
                     name: my-lvmcluster
                     namespace: openshift-storage
                   spec:
                     storage:
                       deviceClasses:
                       - name: vg1
                         deviceSelector:
                           paths:
                           - /dev/disk/by-path/pci-0000:87:00.0-nvme-1
                           - /dev/disk/by-path/pci-0000:88:00.0-nvme-1
                           - /dev/disk/by-path/pci-0000:89:00.0-nvme-1 # new disk is added
                         thinPoolConfig:
                           name: thin-pool-1
                           sizePercent: 90
                           overprovisionRatio: 10
                         nodeSelector:
                           nodeSelectorTerms:
                           - matchExpressions:
                               - key: app
                                 operator: In
                                 values:
                                 - test1
            remediationAction: enforce
            severity: low
  4. 以下のコマンドを実行してポリシーを編集します。

    # oc edit -f policy-lvms-operator.yaml -ns lvms-policy-ns 1
    1
    policy-lvms-operator.yaml は既存のポリシーの名前です。

    これは、LVMCluster CR で指定された新しいディスクを使用してストレージをプロビジョニングします。

4.12.3.5.3. PVC の拡張

容量を追加した後、新しいストレージを活用するには、LVM Storage で既存の永続ボリューム要求 (PVC) を拡張できます。

前提条件

  • 動的プロビジョニングが使用される。
  • 制御する側の StorageClass オブジェクトには allowVolumeExpansiontrue に設定されている。

手順

  1. 次のコマンドを実行して、目的の PVC リソースの .spec.resources.requests.storage フィールドを新しいサイズに変更します。

    oc patch <pvc_name> -n <application_namespace> -p '{ "spec": { "resources": { "requests": { "storage": "<desired_size>" }}}}'
  2. PVC の status.conditions フィールドを監視し、サイズ変更が完了したかどうかを確認します。OpenShift Container Platform は、拡張中に Resizing 条件を PVC に追加します。これは、拡張の完了後、削除されます。

4.12.3.6. シングルノード OpenShift クラスターでの LVM ストレージのアップグレード

現在、シングルノード OpenShift クラスターで、OpenShift Data Foundation Logical Volume Manager Operator 4.11 から LVM Storage 4.12 にアップグレードすることはできません。

重要

このプロセス中、データは保持されません。

手順

  1. 永続ボリューム要求 (PVC) で保持するデータをバックアップします。
  2. OpenShift Data Foundation Logical Volume Manager Operator とその Pod によってプロビジョニングされたすべての PVC を削除します。
  3. OpenShift Container Platform 4.12 に LVM ストレージを再インストールします。
  4. ワークロードを再作成します。
  5. 4.12 へのアップグレード後に作成された PVC にバックアップデータをコピーします。

4.12.3.7. シングルノード OpenShift のボリュームスナップショット

LVM ストレージによってプロビジョニングされた永続ボリューム (PV) のボリュームスナップショットを取得できます。クローン作成されたボリュームのボリュームスナップショットを作成することもできます。ボリュームスナップショットは、次のことを行うのに役立ちます。

  • アプリケーションデータをバックアップします。

    重要

    ボリュームスナップショットは元のデータと同じデバイスにあります。ボリュームスナップショットをバックアップとして使用するには、スナップショットをセキュアな場所に移動する必要があります。OpenShift API をデータ保護のバックアップおよび復元ソリューションに使用できます。

  • ボリュームスナップショットが作成された状態に戻します。

関連情報

4.12.3.7.1. シングルノード OpenShift でのボリュームスナップショットの作成

シンプールの使用可能な容量とオーバープロビジョニングの制限に基づいて、ボリュームスナップショットを作成できます。LVM Storage は、lvms-<deviceclass-name> という名前で VolumeSnapshotClass を作成します。

前提条件

  • 永続ボリューム要求 (PVC) が Bound 状態であることを確認しました。これは、一貫性のあるスナップショットに必要です。
  • スナップショットを作成する前に、PVC へのすべての I/O を停止しました。

手順

  1. oc コマンドを実行する必要があるシングルノード OpenShift にログインします。
  2. 次の YAML を lvms-vol-snapshot.yaml などの名前でファイルに保存します。

    ボリュームスナップショットを作成する YAML の例

    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshot
    metadata:
        name: lvm-block-1-snap
    spec:
        volumeSnapshotClassName: lvms-vg1
        source:
            persistentVolumeClaimName: lvm-block-1

  3. PVC と同じ namespace で次のコマンドを実行して、スナップショットを作成します。

    # oc create -f lvms-vol-snapshot.yaml

PVC の読み取り専用コピーがボリュームスナップショットとして作成されます。

4.12.3.7.2. シングルノード OpenShift でのボリュームスナップショットの復元

ボリュームスナップショットを復元すると、新しい永続ボリューム要求 (PVC) が作成されます。復元される PVC はボリュームスナップショットおよびソース PVC とは切り離されています。

前提条件

  • ストレージクラスは、ソース PVC のストレージクラスと同じである必要がある。
  • 要求された PVC のサイズは、スナップショットのソースボリュームのサイズと同じである必要がある。

    重要

    スナップショットは、スナップショットのソースボリュームと同じサイズの PVC に復元される必要があります。より大きな PVC が必要な場合は、スナップショットが正常に復元された後に PVC のサイズを変更できます。

手順

  1. ソース PVC のストレージクラス名とボリュームスナップショット名を特定します。
  2. 次の YAML を lvms-vol-restore.yaml などの名前でファイルに保存して、スナップショットを復元します。

    PVC を復元する YAML の例。

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: lvm-block-1-restore
    spec:
      accessModes:
      - ReadWriteOnce
      volumeMode: Block
      Resources:
        Requests:
          storage: 2Gi
      storageClassName: lvms-vg1
      dataSource:
        name: lvm-block-1-snap
        kind: VolumeSnapshot
        apiGroup: snapshot.storage.k8s.io

  3. スナップショットと同じ namespace で次のコマンドを実行して、ポリシーを作成します。

    # oc create -f lvms-vol-restore.yaml
4.12.3.7.3. シングルノード OpenShift でのボリュームスナップショットの削除

ボリュームスナップショットリソースと永続ボリューム要求 (PVC) を削除できます。

手順

  1. 次のコマンドを実行して、ボリュームスナップショットリソースを削除します。

    # oc delete volumesnapshot <volume_snapshot_name> -n <namespace>
    注記

    永続ボリューム要求 (PVC) を削除しても、PVC のスナップショットは削除されません。

  2. 復元されたボリュームスナップショットを削除するには、次のコマンドを実行して、ボリュームスナップショットを復元するために作成された PVC を削除します。

    # oc delete pvc <pvc_name> -n <namespace>

4.12.3.8. シングルノード OpenShift のボリュームのクローン作成

クローンは、既存のストレージボリュームの複製であり、他の標準ボリュームと同じように使用できます。

4.12.3.8.1. シングルノード OpenShift でのボリュームクローンの作成

ボリュームのクローンを作成して、データのポイントインタイムコピーを作成します。永続ボリューム要求は別のサイズでクローンできません。

重要

クローン作成された PVC には書き込みアクセス権限があります。

前提条件

  • PVC が Bound 状態であることを確認しました。これは、一貫性のあるスナップショットに必要です。
  • StorageClass がソース PVC のものと同じであることを確認しました。

手順

  1. ソース PVC のストレージクラスを特定します。
  2. ボリュームクローンを作成するには、次の YAML を lvms-vol-clone.yaml などの名前でファイルに保存します。

    ボリュームをクローン作成する YAML の例

    apiVersion: v1
    kind: PersistentVolumeClaim
    Metadata:
      name: lvm-block-1-clone
    Spec:
      storageClassName: lvms-vg1
      dataSource:
        name: lvm-block-1
        kind: PersistentVolumeClaim
      accessModes:
       - ReadWriteOnce
      volumeMode: Block
      Resources:
        Requests:
          storage: 2Gi

  3. 次のコマンドを実行して、ソース PVC と同じ namespace にポリシーを作成します。

    # oc create -f lvms-vol-clone.yaml
4.12.3.8.2. シングルノード OpenShift でのクローンボリュームの削除

クローン作成されたボリュームを削除できます。

手順

  • クローン作成されたボリュームを削除するには、次のコマンドを実行して、クローン作成された PVC を削除します。

    # oc delete pvc <clone_pvc_name> -n <namespace>

4.12.3.9. LVM Storage の監視

クラスターモニタリングを有効にするには、LVM Storage をインストールした namespace に次のラベルを追加する必要があります。

openshift.io/cluster-monitoring=true
重要

RHACM でクラスターモニタリングを有効化する方法の詳細は、可観測性カスタムメトリクスの追加 を参照してください。

4.12.3.9.1. メトリクス

メトリクスを表示することで、LVM Storage を監視できます。

次の表は、topolvm メトリクスについて説明しています。

表4.2 topolvm メトリクス
アラート説明

topolvm_thinpool_data_percent

LVM シンプールで使用されているデータ領域の割合を示します。

topolvm_thinpool_metadata_percent

LVM シンプールで使用されているメタデータ領域の割合を示します。

topolvm_thinpool_size_bytes

LVM シンプールのサイズをバイト単位で示します。

topolvm_volumegroup_available_bytes

LVM ボリュームグループ内の利用可能な領域をバイト単位で示します。

topolvm_volumegroup_size_bytes

LVM ボリュームグループのサイズをバイト単位で示します。

topolvm_thinpool_overprovisioned_available

LVM シンプールの利用可能なオーバープロビジョニングサイズをバイト単位で示します。

注記

メトリクスは 10 分ごとに、または変更 (シンプールに新しい論理ボリュームが作成されるなど) があったときに更新されます。

4.12.3.9.2. アラート

シンプールとボリュームグループが最大ストレージ容量に達すると、それ以降の操作は失敗します。これにより、データ損失が発生する可能性があります。

LVM Storage は、シンプールとボリュームグループの使用量が特定の値を超えると、次のアラートを送信します。

表4.3 LVM Storage アラート
アラート説明

VolumeGroupUsageAtThresholdNearFull

このアラートは、ボリュームグループとシンプールの両方の使用量がノード上で 75% を超えるとトリガーされます。データの削除またはボリュームグループの拡張が必要です。

VolumeGroupUsageAtThresholdCritical

このアラートは、ボリュームグループとシンプールの両方の使用量がノード上で 85% を超えるとトリガーされます。この場合、ボリュームグループは、かなりいっぱいになっています。データの削除またはボリュームグループの拡張が必要です。

ThinPoolDataUsageAtThresholdNearFull

このアラートは、ボリュームグループ内のシンプールのデータ使用量がノード上で 75% を超えるとトリガーされます。データの削除またはシンプールの拡張が必要です。

ThinPoolDataUsageAtThresholdCritical

このアラートは、ボリュームグループ内のシンプールのデータ使用量がノード上で 85% を超えるとトリガーされます。データの削除またはシンプールの拡張が必要です。

ThinPoolMetaDataUsageAtThresholdNearFull

このアラートは、ボリュームグループ内のシンプールのメタデータ使用量がノード上で 75% を超えるとトリガーされます。データの削除またはシンプールの拡張が必要です。

ThinPoolMetaDataUsageAtThresholdCritical

このアラートは、ボリュームグループ内のシンプールのメタデータ使用量がノード上で 85% を超えるとトリガーされます。データの削除またはシンプールの拡張が必要です。

4.12.3.10. must-gather を使用したログファイルおよび診断情報のダウンロード

LVM Storage が問題を自動的に解決できない場合、must-gather ツールを使用してログファイルと診断情報を収集し、ユーザーまたは Red Hat サポートが問題を確認して解決策を決定できるようにします。

手順

  • LVM Storage クラスターに接続されているクライアントから must-gather コマンドを実行します。

    $ oc adm must-gather --image=registry.redhat.io/lvms4/lvms-must-gather-rhel9:v4.12 --dest-dir=<directory_name>

4.12.3.11. LVM ストレージ参照 YAML ファイル

サンプルの LVMCluster カスタムリソース (CR) では、YAML ファイルのすべてのフィールドについて説明しています。

LVMCluster CR の例

apiVersion: lvm.topolvm.io/v1alpha1
kind: LVMCluster
metadata:
  name: my-lvmcluster
spec:
  tolerations:
  - effect: NoSchedule
    key: xyz
    operator: Equal
    value: "true"
  storage:
    deviceClasses: 1
    - name: vg1  2
      nodeSelector: 3
        nodeSelectorTerms: 4
        - matchExpressions:
          - key: mykey
            operator: In
            values:
            - ssd
      deviceSelector: 5
        paths:
        - /dev/disk/by-path/pci-0000:87:00.0-nvme-1
        - /dev/disk/by-path/pci-0000:88:00.0-nvme-1
        - /dev/disk/by-path/pci-0000:89:00.0-nvme-1
      thinPoolConfig: 6
        name: thin-pool-1 7
        sizePercent: 90 8
        overprovisionRatio: 10 9
status:
    deviceClassStatuses: 10
    - name: vg1
      nodeStatus: 11
      - devices: 12
        - /dev/nvme0n1
        - /dev/nvme1n1
        - /dev/nvme2n1
        node: my-node.example.com 13
        status: Ready 14
    ready: true 15
    state: Ready 16

1
クラスター上に作成される LVM ボリュームグループ。deviceClass を 1 つだけ作成できます。
2
ノード上に作成される LVM ボリュームグループの名前。
3
LVM ボリュームグループを作成するノード。フィールドが空の場合、すべてのノードが考慮されます。
4
ノードセレクター要件のリスト。
5
LVM ボリュームグループの作成に使用されるデバイスパスのリスト。このフィールドが空の場合、ノード上のすべての未使用ディスクが使用されます。デバイスが LVM ボリュームグループに追加された後は、デバイスを削除できません。
6
LVM シンプールの設定。
7
LVM ボリュームグループに作成されるシンプールの名前。
8
シンプールの作成に使用する LVM ボリュームグループの残りの領域の割合。
9
シンプールで使用可能なストレージと比較して、追加のストレージをプロビジョニングできる係数。
10
deviceClass のステータス。
11
各ノードの LVM ボリュームグループのステータス。
12
LVM ボリュームグループの作成に使用されるデバイスのリスト。
13
deviceClass が作成されたノード。
14
ノード上の LVM ボリュームグループのステータス。
15
このフィールドは非推奨です。
16
LVMCluster のステータス。

4.12.4. LVMS を使用したローカル永続ストレージのトラブルシューティング

OpenShift Container Platform は永続ボリューム (PV) の範囲を単一のプロジェクトに限定しないため、クラスター全体で共有し、永続ボリューム要求 (PVC) を使用して任意のプロジェクトで要求することができます。これにより、トラブルシューティングが必要な多くの問題が発生する可能性があります。

4.12.4.1. 保留状態でスタックしている PVC を調査する

Persistent Volume Claim (PVC) は、さまざまな理由で Pending 状態になることがあります。以下に例を示します。

  • コンピューティングリソースが不十分
  • ネットワークの問題
  • ストレージクラスまたはノードセレクターが一致していない
  • 利用可能なボリュームがない
  • 永続ボリューム (PV) を持つノードは Not Ready 状態です

oc description コマンドを使用してスタック PVC の詳細を確認し、原因を特定します。

手順

  1. 次のコマンドを実行して、PVC のリストを取得します。

    $ oc get pvc

    出力例

    NAME        STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    lvms-test   Pending                                      lvms-vg1       11s

  2. 次のコマンドを実行して、Pending 状態のままになっている PVC に関連するイベントを検査します。

    $ oc describe pvc <pvc_name> 1
    1
    <pvc_name> を PVC の名前に置き換えます。たとえば、lvms-vg1 です。

    出力例

    Type     Reason              Age               From                         Message
    ----     ------              ----              ----                         -------
    Warning  ProvisioningFailed  4s (x2 over 17s)  persistentvolume-controller  storageclass.storage.k8s.io "lvms-vg1" not found

4.12.4.2. 不足している LVMS または Operator コンポーネントからの回復

ストレージクラスが「見つからない」エラーが発生した場合は、LVMCluster リソースをチェックし、すべての論理ボリュームマネージャーストレージ (LVMS) Pod が実行していることを確認してください。LVMCluster リソースが存在しない場合は作成できます。

手順

  1. 次のコマンドを実行して、LVMCluster リソースの存在を確認します。

    $ oc get lvmcluster -n openshift-storage

    出力例

    NAME            AGE
    my-lvmcluster   65m

  2. クラスターに LVMCluster リソースがない場合は、次のコマンドを実行して LVMCluster リソースを作成します。

    $ oc create -n openshift-storage -f <custom_resource> 1
    1
    <custom_resource> を、要件に合わせたカスタムリソース URL またはファイルに置き換えます。

    カスタムリソースの例

    apiVersion: lvm.topolvm.io/v1alpha1
    kind: LVMCluster
    metadata:
      name: my-lvmcluster
    spec:
      storage:
        deviceClasses:
        - name: vg1
          default: true
          thinPoolConfig:
            name: thin-pool-1
            sizePercent: 90
            overprovisionRatio: 10

  3. 次のコマンドを実行して、LVMS のすべての Pod が openshift-storage namespace で Running 状態であることを確認します。

    $ oc get pods -n openshift-storage

    出力例

    NAME                                  READY   STATUS    RESTARTS      AGE
    lvms-operator-7b9fb858cb-6nsml        3/3     Running   0             70m
    topolvm-controller-5dd9cf78b5-7wwr2   5/5     Running   0             66m
    topolvm-node-dr26h                    4/4     Running   0             66m
    vg-manager-r6zdv                      1/1     Running   0             66m

    予期される出力は、lvms-operator および vg-manager の 1 つの実行インスタンスです。各ノードには、topolvm-controller および topolvm-node のインスタンスが 1 つ必要です。

    topolvm-nodeInit 状態でスタックしている場合は、LVMS が使用できるディスクを見つけることができません。トラブルシューティングに必要な情報を取得するには、次のコマンドを実行して vg-manager Pod のログを確認します。

    $ oc logs -l app.kubernetes.io/component=vg-manager -n openshift-storage

4.12.4.3. ノード障害からの回復

クラスター内の特定のノードに障害が発生したために、永続ボリューム要求 (PVC) が Pending 状態のままになることがあります。障害が発生したノードを特定するには、topolvm-node Pod の再起動回数を調べることができます。再起動回数の増加は、基礎となるノードに潜在的な問題があることを示しており、さらなる調査とトラブルシューティングが必要になる場合があります。

手順

  • 次のコマンドを実行して、topolvm-node Pod インスタンスの再起動回数を調べます。

    $ oc get pods -n openshift-storage

    出力例

    NAME                                  READY   STATUS    RESTARTS      AGE
    lvms-operator-7b9fb858cb-6nsml        3/3     Running   0             70m
    topolvm-controller-5dd9cf78b5-7wwr2   5/5     Running   0             66m
    topolvm-node-dr26h                    4/4     Running   0             66m
    topolvm-node-54as8                    4/4     Running   0             66m
    topolvm-node-78fft                    4/4     Running   17 (8s ago)   66m
    vg-manager-r6zdv                      1/1     Running   0             66m
    vg-manager-990ut                      1/1     Running   0             66m
    vg-manager-an118                      1/1     Running   0             66m

    ノードの問題を解決した後、PVC がまだ Pending 状態のままである場合は、強制クリーンアップ手順を実行する必要がある場合があります。

4.12.4.4. ディスク障害からの回復

Persistent Volume Claim (PVC) に関連するイベントの検査中にエラーメッセージが表示された場合は、基になるボリュームまたはディスクに問題がある可能性があります。ディスクとボリュームのプロビジョニングの問題は、多くの場合、最初に Failed to provision volume with StorageClass <storage_class_name> などの一般的なエラーが発生します。通常、2 番目のより具体的なエラーメッセージが続きます。

手順

  1. 次のコマンドを実行して、PVC に関連付けられたイベントを検査します。

    $ oc describe pvc <pvc_name> 1
    1
    <pvc_name> を PVC の名前に置き換えます。ディスクまたはボリューム障害のエラーメッセージとその原因の例をいくつか示します。
    • ボリュームの存在を確認できない: ボリュームがすでに存在するかどうかの確認で問題が発生したことを示します。ボリューム検証の失敗は、ネットワーク接続の問題やその他の障害によって発生する可能性があります。
    • バインドボリュームへの失敗: 利用可能な永続ボリューム (PV) が PVC の要件と一致しない場合、ボリュームのバインドに失敗する可能性があります。
    • FailedMount または FailedUnMount: このエラーは、ボリュームをノードにマウントしようとしたとき、またはノードからボリュームをアンマウントしようとしたときの問題を示します。ディスクに障害が発生した場合、Pod が PVC を使用しようとしたときにこのエラーが表示されることがあります。
    • ボリュームはすでに 1 つのノードに排他的に接続されており、別のノードには接続できない: このエラーは、ReadWriteMany アクセスモードをサポートしていないストレージソリューションで発生する可能性があります。
  2. 問題が発生しているホストへの直接接続を確立します。
  3. ディスクの問題を解決します。

ディスクの問題を解決した後、エラーメッセージが続くか再発する場合は、強制クリーンアップ手順の実行が必要になる場合があります。

4.12.4.5. 強制クリーンアップの実行

トラブルシューティング手順を完了した後もディスクまたはノード関連の問題が解決しない場合は、強制クリーンアップ手順の実行が必要になる場合があります。強制クリーンアップは、永続的な問題に包括的に対処し、LVMS が適切に機能することを保証するために使用されます。

前提条件

  1. 論理ボリュームマネージャーストレージ (LVMS) ドライバーを使用して作成された永続ボリュームクレーム (PVC) はすべて削除されました。
  2. これらの PVC を使用する Pod は停止されました。

手順

  1. 次のコマンドを実行して、openshift-storage namespace に切り替えます。

    $ oc project openshift-storage
  2. 次のコマンドを実行して、Logical Volume のカスタムリソース (CR) が残っていないことを確認します。

    $ oc get logicalvolume

    出力例

    No resources found

    1. LogicalVolume CR が残っている場合は、次のコマンドを実行してファイナライザーを削除します。

      $ oc patch logicalvolume <name> -p '{"metadata":{"finalizers":[]}}' --type=merge 1
      1
      <name> を CR の名前に置き換えます。
    2. ファイナライザーを削除した後、次のコマンドを実行して CR を削除します。

      $ oc delete logicalvolume <name> 1
      1
      <name> を CR の名前に置き換えます。
  3. 次のコマンドを実行して、LVMVolumeGroup CR が残っていないことを確認します。

    $ oc get lvmvolumegroup

    出力例

    No resources found

    1. LVMVolumeGroup CR が残っている場合は、次のコマンドを実行してファイナライザーを削除します。

      $ oc patch lvmvolumegroup <name> -p '{"metadata":{"finalizers":[]}}' --type=merge 1
      1
      <name> を CR の名前に置き換えます。
    2. ファイナライザーを削除した後、次のコマンドを実行して CR を削除します。

      $ oc delete lvmvolumegroup <name> 1
      1
      <name> を CR の名前に置き換えます。
  4. 次のコマンドを実行して、LVMVolumeGroupNodeStatus CR を削除します。

    $ oc delete lvmvolumegroupnodestatus --all
  5. 次のコマンドを実行して、LVMCluster CR を削除します。

    $ oc delete lvmcluster --all
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.