4.12. ローカルストレージを使用した永続ストレージ
4.12.1. ローカルボリュームを使用した永続ストレージ
OpenShift Container Platform は、ローカルボリュームを使用する永続ストレージでプロビジョニングすることが可能です。ローカルの永続ボリュームを使用すると、標準の永続ボリューム要求 (PVC) インターフェイスを使用して、ディスクやパーティションなどのローカルのストレージデバイスにアクセスできます。
ローカルボリュームは、Pod をノードに手動でスケジュールせずに使用できます。ボリュームのノード制約がシステムによって認識されるためです。ただし、ローカルボリュームは、依然として基礎となるノードの可用性に依存しており、すべてのアプリケーションに適している訳ではありません。
ローカルボリュームは、静的に作成された永続ボリュームとしてのみ使用できます。
4.12.1.1. ローカルストレージ Operator のインストール
ローカルストレージ Operator はデフォルトで OpenShift Container Platform にインストールされません。以下の手順を使用してこの Operator をインストールし、クラスター内でローカルボリュームを有効にできるように設定します。
前提条件
- OpenShift Container Platform Web コンソールまたはコマンドラインインターフェイス (CLI) へのアクセス。
手順
openshift-local-storageプロジェクトを作成します。$ oc adm new-project openshift-local-storage
オプション: インフラストラクチャーノードでのローカルストレージの作成を許可します。
ロギングやモニタリングなどのコンポーネントに対応するために、ローカルストレージ Operator を使用してインフラストラクチャーノードでボリュームを作成する必要がある場合があります。
ローカルストレージ Operator にワーカーノードだけでなくインフラストラクチャーノードが含まれるように、デフォルトのノードセレクターを調整する必要があります。
ローカルストレージ Operator がクラスター全体のデフォルトセレクターを継承しないようにするには、以下のコマンドを実行します。
$ oc annotate namespace openshift-local-storage openshift.io/node-selector=''
オプション: 単一ノードデプロイメントの CPU の管理プールでローカルストレージを実行できるようにします。
単一ノードデプロイメントで Local Storage Operator を使用し、
literalプールに属する CPU の使用を許可します。この手順は、管理ワークロードパーティショニングを使用する単一ノードインストールで実行します。Local Storage Operator が管理 CPU プールで実行できるようにするには、次のコマンドを実行します。
$ oc annotate namespace openshift-local-storage workload.openshift.io/allowed='management'
UI での操作
Web コンソールからローカルストレージ Operator をインストールするには、以下の手順を実行します。
- OpenShift Container Platform Web コンソールにログインします。
- Operators → OperatorHub に移動します。
- Local Storage をフィルターボックスに入力して、ローカルストレージ Operator を見つけます。
- Install をクリックします。
- Install Operator ページで、A specific namespace on the cluster を選択します。ドロップメニューから openshift-local-storage を選択します。
- Update Channel および Approval Strategy の値を必要な値に調整します。
- Install をクリックします。
これが完了すると、ローカルストレージ Operator は Web コンソールの Installed Operators セクションに一覧表示されます。
CLI からの操作
CLI からローカルストレージ Operator をインストールします。
ローカルストレージ 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
- インストール計画のユーザー承認ポリシー。
以下のコマンドを実行して、ローカルストレージ Operator オブジェクトを作成します。
$ oc apply -f openshift-local-storage.yaml
この時点で、Operator Lifecycle Manager (OLM) はローカルストレージ Operator を認識できるようになります。Operator の ClusterServiceVersion (CSV) はターゲット namespace に表示され、Operator で指定される API は作成用に利用可能になります。
すべての Pod およびローカルストレージ Operator が作成されていることを確認して、ローカルストレージのインストールを検証します。
必要な Pod すべてが作成されていることを確認します。
$ oc -n openshift-local-storage get pods
出力例
NAME READY STATUS RESTARTS AGE local-storage-operator-746bf599c9-vlt5t 1/1 Running 0 19m
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 がインストールされていること。
以下の条件を満たすローカルディスクがある。
- ノードに接続されている。
- マウントされていない。
- パーティションが含まれていない。
手順
ローカルボリュームリソースを作成します。このリソースは、ノードおよびローカルボリュームへのパスを定義する必要があります。
注記同じデバイスに別のストレージクラス名を使用しないでください。これを行うと、複数の永続ボリューム (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 を使用して IBM Z で 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: "localblock-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 を使用して IBM Z で OpenShift Container Platform を実行している場合は、VM ディスクにシリアル番号を割り当てる必要があります。そうしないと、再起動後に VM ディスクを識別できません。
virsh edit <VM>コマンドを使用して、<serial>mydisk</serial>定義を追加できます。OpenShift Container Platform クラスターにローカルボリュームリソースを作成します。作成したばかりのファイルを指定します。
$ oc create -f <local-volume>.yaml
プロビジョナーが作成され、対応するデーモンセットが作成されていることを確認します。
$ 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の場合、これはラベルセレクターが無効であることを示します。永続ボリュームが作成されていることを確認します。
$ 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 ノードに割り当てられていること。
手順
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-storage 2 local: path: /dev/xvdf 3 nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - example-node注記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-storage 2 local: path: /dev/xvdf 3 nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - example-nodeOpenShift Container Platform クラスターに PV リソースを作成します。作成したばかりのファイルを指定します。
$ oc create -f <example-pv>.yaml
ローカル PV が作成されていることを確認します。
$ oc get pv
出力例
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE example-pv-filesystem 100Gi RWO Delete Available local-storage 3m47s example-pv1 1Gi RWO Delete Bound local-storage/pvc1 local-storage 12h example-pv2 1Gi RWO Delete Bound local-storage/pvc2 local-storage 12h example-pv3 1Gi RWO Delete Bound local-storage/pvc3 local-storage 12h
4.12.1.4. ローカルボリュームの永続ボリューム要求 (PVC) の作成
ローカルボリュームは、Pod でアクセスされる永続ボリューム要求 (PVC) として静的に作成される必要があります。
前提条件
- 永続ボリュームがローカルボリュームプロビジョナーを使用して作成されていること。
手順
対応するストレージクラスを使用して 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
作成したファイルを指定して、PVC を OpenShift Container Platform クラスターに作成します。
$ oc create -f <local-pvc>.yaml
4.12.1.5. ローカル要求を割り当てます。
ローカルボリュームが永続ボリューム要求 (PVC) にマップされた後に、これをリソース内に指定できます。
前提条件
- 永続ボリューム要求 (PVC) が同じ namespace に存在する。
手順
定義された要求をリソースの仕様に追加します。以下の例では、Pod 内で永続ボリューム要求 (PVC) を宣言します。
apiVersion: v1 kind: Pod spec: ... containers: volumeMounts: - name: local-disks 1 mountPath: /data 2 volumes: - name: localpvc persistentVolumeClaim: claimName: local-pvc-name 3作成したファイルを指定して、OpenShift Container Platform クラスターにリソースを作成します。
$ oc create -f <local-pod>.yaml
4.12.1.6. 詳細は、ローカルストレージデバイスの自動検出およびプロビジョニングを参照してください。
ローカルストレージ Operator はローカルストレージ検出およびプロビジョニングを自動化します。この機能を使用すると、ベアメタル、VMware、または割り当てられたデバイスを持つ AWS ストアインスタンスなど、デプロイメント時に動的プロビジョニングが利用できない場合にインストールを単純化できます。
自動検出およびプロビジョニングはテクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
ただし、ベアメタル上に Red Hat OpenShift Data Foundation をデプロイするために使用される場合、自動検出とプロビジョニングは完全にサポートされます。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
ローカルデバイスを自動的に検出し、選択したデバイスのローカルボリュームを自動的にプロビジョニングするには、以下の手順を使用します。
LocalVolumeSet オブジェクトの使用には注意が必要です。ローカルディスクから永続ボリューム (PV) を自動的にプロビジョニングする場合、ローカル PV は一致するすべてのデバイスを要求する可能性があります。LocalVolumeSet オブジェクトを使用している場合、ローカルストレージ Operator がノードでローカルデバイスを管理する唯一のエンティティーであることを確認します。
前提条件
- クラスター管理者パーミッションがある。
- ローカルストレージ Operator がインストールされていること。
- ローカルディスクが OpenShift Container Platform ノードに割り当てられていること。
-
OpenShift Container Platform Web コンソールまたは
ocコマンドラインインターフェイス (CLI) へのアクセスがあること。
手順
Web コンソールからローカルデバイスの自動検出を有効にするには、以下を行います。
- Administrator パースペクティブで、Operators → Installed Operators に移動し、Local Volume Discovery タブをクリックします。
- Create Local Volume Discovery をクリックします。
利用可能なディスクをすべてのノードまたは特定のノードのどちらで検出する必要があるかに応じて、All nodes または Select nodes のいずれかを選択します。
注記All nodes または Select nodes を使用してフィルターするかどうかにかかわらず、ワーカーノードのみが利用可能になります。
- Create をクリックします。
auto-discover-devices という名前のローカルボリューム検出インスタンスが表示されます。
ノードで利用可能なデバイスの連続リストを表示するには、以下を実行します。
- OpenShift Container Platform Web コンソールにログインします。
- Compute → Nodes に移動します。
- 開くノードの名前をクリックします。Node Details ページが表示されます。
Disks タブを選択して、選択したデバイスの一覧を表示します。
ローカルディスクを追加または削除しても、デバイス一覧の更新が継続的に行われます。名前、ステータス、タイプ、モデル、容量、およびモードでデバイスをフィルターできます。
Web コンソールから検出されたデバイスのローカルボリュームを自動的にプロビジョニングするには、以下を実行します。
- Operators → Installed Operators に移動し、Operator の一覧から Local Storage を選択します。
- Local Volume Set → Create Local Volume Set を選択します。
- ボリュームセット名とストレージクラス名を入力します。
All nodes または Select nodes を選択し、適宜フィルターを適用します。
注記All nodes または Select nodes を使用してフィルターするかどうかにかかわらず、ワーカーノードのみが利用可能になります。
ローカルボリュームセットに適用するディスクタイプ、モード、サイズ、および制限を選択し、Create をクリックします。
メッセージが数分後に表示され、Operator reconciled successfully という Operator の調整が正常に行われたことが示唆されます。
または、CLI から検出されたデバイスのローカルボリュームをプロビジョニングするには、以下を実行します。
以下の例に示されるように、オブジェクト 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: example-storageclass 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ローカルボリュームセットオブジェクトを作成します。
$ oc apply -f local-volume-set.yaml
ローカル永続ボリュームがストレージクラスに基づいて動的にプロビジョニングされていることを確認します。
$ oc get pv
出力例
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE local-pv-1cec77cf 100Gi RWO Delete Available example-storageclass 88m local-pv-2ef7cd2a 100Gi RWO Delete Available example-storageclass 82m local-pv-3fa1c73 100Gi RWO Delete Available example-storageclass 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 ノードに割り当てられている。
- テイントのマークが付けられたノードがローカルストレージのプロビジョニングを行うことが想定されます。
手順
テイントのマークが付けられたノードでスケジュールするようにローカルボリュームを設定するには、以下を実行します。
以下の例に示されるように、
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: "localblock-sc" volumeMode: Block 4 devicePaths: 5 - /dev/xvdgオプション: テイントのマークが付けられたノードでのみローカル永続ボリュームを作成するには、以下の例のように 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である必要があります。警告使用中の永続ボリュームを削除すると、データの損失や破損につながる可能性があります。
手順
以前に作成したローカルボリュームを編集して、不要なディスクを削除します。
クラスターリソースを編集します。
$ oc edit localvolume <name> -n openshift-local-storage
-
devicePathsの下の行に移動し、不要なディスクを表すものを削除します。
作成した永続ボリュームを削除します。
$ oc delete pv <pv-name>
ノードのシンボリックリンクを削除します。
警告以下の手順では、root ユーザーとしてノードにアクセスする必要があります。この手順のステップ以外にノードの状態を変更すると、クラスターが不安定になる可能性があります。
ノードにデバッグ Pod を作成します。
$ oc debug node/<node-name>
ルートディレクトリーを
/hostに変更します。$ chroot /host
ローカルボリュームのシンボリックリンクを含むディレクトリーに移動します。
$ cd /mnt/openshift-local-storage/<sc-name> 1- 1
- ローカルボリュームの作成に使用されるストレージクラスの名前。
削除したデバイスに属するシンボリックリンクを削除します。
$ rm <symlink>
4.12.1.9.2. ローカルストレージ Operator のアンインストール
ローカルストレージ Operator をアンインストールするには、Operator および openshift-local-storage プロジェクトの作成されたすべてのリソースを削除する必要があります。
ローカルストレージ PV がまだ使用中の状態でローカルストレージ Operator をアンインストールすることは推奨されません。PV は Operator の削除後も残りますが、PV およびローカルストレージリソースを削除せずに Operator がアンインストールされ、再インストールされる場合に予測できない動作が生じる可能性があります。
前提条件
- OpenShift Container Platform Web コンソールにアクセスできる。
手順
プロジェクトにインストールされているローカルボリュームリソースを削除します (
localvolume、localvolumeset、localvolumediscovery等)。$ oc delete localvolume --all --all-namespaces $ oc delete localvolumeset --all --all-namespaces $ oc delete localvolumediscovery --all --all-namespaces
Web コンソールからローカルストレージ Operator をアンインストールします。
- OpenShift Container Platform Web コンソールにログインします。
- Operators → Installed Operators に移動します。
- Local Storage をフィルターボックスに入力して、ローカルストレージ Operator を見つけます。
-
ローカルストレージ Operator の末尾にある Options メニュー
をクリックします。
- Uninstall Operator をクリックします。
- 表示されるウィンドウで Remove をクリックします。
ローカルストレージ Operator で作成された PV は削除されるまでクラスターに残ります。これらのボリュームが使用されなくなったら、以下のコマンドを実行してこれらのボリュームを削除します。
$ oc delete pv <pv-name>
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/ubi9/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 は、手動の (静的) プロビジョニングで参照される必要があります。
手順
永続ボリューム (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ファイルから PV を作成します。
$ oc create -f pv.yaml
永続ボリューム要求 (PVC) を定義します。
PersistentVolumeClaimオブジェクト定義を使用して、ファイルpvc.yamlを作成します。apiVersion: v1 kind: PersistentVolumeClaim metadata: name: task-pvc-volume spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi storageClassName: manualファイルから 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
4.12.3. 論理ボリュームマネージャーストレージを使用した永続ストレージ
論理ボリュームマネージャーストレージ (LVM ストレージ) は、TopoLVM CSI ドライバーを使用して、シングルノード OpenShift クラスターでローカルストレージを動的にプロビジョニングします。
LVM ストレージは、論理ボリュームマネージャーを使用してシンプロビジョニングボリュームを作成し、限られたリソースのシングルノード OpenShift クラスターでブロックストレージの動的プロビジョニングを提供します。
4.12.3.1. シングルノード OpenShift クラスターへの LVM ストレージのデプロイ
シングルノード OpenShift ベアメタルまたはユーザーがプロビジョニングしたインフラストラクチャークラスターに LVM ストレージをデプロイし、ワークロード用にストレージを動的にプロビジョニングするように設定できます。
LVM ストレージは、使用可能な未使用ディスクをすべて使用してボリュームグループを作成し、ボリュームグループの 90% のサイズを持つ単一のシンプールを作成します。ボリュームグループの残りの 10% は、必要に応じてシンプールを拡張することにより、データ回復を可能にするために自由に使用できます。このようなリカバリーは手動で実行する必要がある場合があります。
永続ボリューム要求 (PVC) と LVM ストレージによってプロビジョニングされたボリュームスナップショットを使用して、ストレージを要求し、ボリュームスナップショットを作成できます。
LVM ストレージは、シンプロビジョニング機能を利用するために、デフォルトのオーバープロビジョニング制限を 10 に設定します。シングルノード OpenShift クラスターで作成できるボリュームおよびボリュームスナップショットの合計サイズは、シンプールのサイズの 10 倍です。
次のいずれかを使用して、シングルノード OpenShift クラスターに LVM ストレージをデプロイできます。
- Red Hat Advanced Cluster Management (RHACM)
- OpenShift Container Platform Web コンソール
4.12.3.1.1. 要件
シングルノード OpenShift クラスターで LVM ストレージのデプロイを開始する前に、次の要件が満たされていることを確認してください。
- OpenShift Container Platform クラスターに Red Hat Advanced Cluster Management (RHACM) をインストールしました。
- すべてのマネージドシングルノード OpenShift クラスターには、ストレージのプロビジョニングに使用される専用ディスクがあります。
シングルノード OpenShift クラスターに LVM ストレージをデプロイする前に、次の制限事項に注意してください。
-
OpenShift Container Platform クラスターでは、
LVMClusterカスタムリソース (CR) のインスタンスを 1 つだけ作成できます。 -
デバイスが
LVMClusterCR の一部になると、削除できなくなります。
4.12.3.1.2. 制限
シングルノードの OpenShift をデプロイする場合、LVM ストレージには次の制限があります。
- ストレージサイズの合計は、基礎となる論理ボリュームマネージャー (LVM) シンプールのサイズとオーバープロビジョニング係数によって制限されます。
論理ボリュームのサイズは、物理エクステント (PE) のサイズと論理エクステント (LE) のサイズによって異なります。
- 物理デバイスおよび論理デバイスの作成時に、PE と LE のサイズを定義できます。
- デフォルトの PE および LE サイズは 4 MB です。
- PE のサイズを大きくした場合、LVM の最大サイズは、カーネルの制限とディスク領域によって決定されます。
表4.1 デフォルトの PE および LE サイズを使用した各アーキテクチャーのサイズ制限
| アーキテクチャー | RHEL 5 | RHEL 6 | RHEL 7 | RHEL 8 |
|---|---|---|---|---|
| 32 ビット | 16 TB | 16 TB | - | - |
| 64 ビット | 8 EB [1] | 8 EB [1] 100 TB [2] | 8 EB [1] 500 TB [2] | 8 EB |
- 理論的サイズ。
- テスト済みサイズ。
4.12.3.1.3. CLI を使用した LVM ストレージのインストール
クラスター管理者は、CLI を使用して論理ボリュームマネージャーストレージ (LVM ストレージ) をインストールできます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
LVM Storage Operator の名前空間を作成します。
次の YAML を
lvms-namespace.yamlファイルに保存します。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-storagenamespaceCR を作成します。$ oc create -f lvms-namespace.yaml
LVM Storage Operator の Operator グループを作成します。
次の YAML を
lvms-operatorgroup.yamlファイルに保存します。apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: openshift-storage-operatorgroup namespace: openshift-storage spec: targetNamespaces: - openshift-storage
OperatorGroupCR を作成します。$ oc create -f lvms-operatorgroup.yaml
LVM Storage Operator にサブスクライブします。
次の YAML を
lvms-sub.yamlファイルに保存します。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
SubscriptionCR を作成します。$ oc create -f lvms-sub.yaml
LVMClusterリソースを作成します。次の YAML を
lvmcluster.yamlファイルに保存します。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 thinPoolConfig: name: thin-pool-1 sizePercent: 90 overprovisionRatio: 10 nodeSelector: nodeSelectorTerms: - matchExpressions: - key: app operator: In values: - test1LVMClusterCR を作成します。$ oc create -f lvmcluster.yaml
Operator がインストールされていることを確認するには、以下のコマンドを入力します。
$ oc get csv -n openshift-storage -o custom-columns=Name:.metadata.name,Phase:.status.phase
出力例
Name Phase 4.13.0-202301261535 Succeeded
4.12.3.1.4. Web コンソールを使用した LVM ストレージのインストール
Red Hat OpenShift Container Platform OperatorHub を使用して、論理ボリュームマネージャーストレージ (LVM ストレージ) をインストールできます。
前提条件
- シングルノード OpenShift クラスターにアクセスできます。
-
cluster-adminおよび Operator のインストール権限を持つアカウントを使用しています。
手順
- OpenShift Container Platform Web コンソールにログインします。
- Operators → OperatorHub をクリックします。
-
スクロールするか、
LVM Storageを Filter by keyword ボックスに入力して、LVM ストレージを見つけます。 - Install をクリックします。
Install Operator ページで、以下のオプションを設定します。
- Channel を stable-4.13 として更新します。
- クラスター上の特定の namespace としての Installation Mode。
-
Operator で推奨される namespace openshift-storage としての Installed Namespace。
openshift-storagenamespace が存在しない場合は、Operator のインストール中に作成されます。 承認ストラテジー を Automatic または Manual として選択します。
Automatic (自動) 更新を選択した場合、Operator Lifecycle Manager (OLM) は介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。
Manual 更新を選択した場合、OLM は更新要求を作成します。クラスター管理者は、Operator を新しいバージョンに更新できるように更新要求を手動で承認する必要があります。
- Install をクリックします。
検証手順
- インストールが成功したことを示す緑色のチェックマークが LVM ストレージに表示されていることを確認します。
4.12.3.1.5. OpenShift Web コンソールを使用してインストールされた LVM ストレージのアンインストール
Red Hat OpenShift Container Platform Web コンソールを使用して、LVM ストレージをアンインストールできます。
前提条件
- LVM ストレージによってプロビジョニングされたストレージを使用しているクラスター上のすべてのアプリケーションを削除しました。
- LVM ストレージを使用してプロビジョニングされた永続ボリューム要求 (PVC) と永続ボリューム (PV) を削除しました。
- LVM ストレージによってプロビジョニングされたすべてのボリュームスナップショットを削除しました。
-
oc get logicalvolumeコマンドを使用して、論理ボリュームリソースが存在しないことを確認しました。 -
cluster-admin権限を持つアカウントを使用して、シングルノード OpenShift クラスターにアクセスできます。
手順
-
Operators → Installed Operators ページから、LVM Storage にスクロールするか、
LVM Storageを Filter by name に入力して検索し、クリックします。 - LVMCluster タブをクリックします。
- LVMCluster ページの右側で、Actions ドロップダウンメニューから Delete LVMCluster を選択します。
- Details タブをクリックします。
- Operator Details ページの右側で、Actions ドロップダウンメニューから Uninstall Operator を選択します。
- Remove を選択します。LVM ストレージは実行を停止し、完全に削除されます。
4.12.3.1.6. 非接続環境での LVM ストレージのインストール
非接続環境の OpenShift Container Platform 4.13 に LVM Storage をインストールできます。この手順で参照されているすべてのセクションは、追加リソース にリンクされています。
前提条件
- 非接続インストールのミラーリングについて セクションを読みました。
- OpenShift Container Platform イメージリポジトリーにアクセスできる。
- ミラーレジストリーを作成しました。
手順
イメージセット設定の作成 手順の手順に従います。LVM ストレージの
ImageSetConfigurationリソースを作成するには、次のサンプル YAML ファイルを使用できます。LVM ストレージ用の ImageSetConfiguration ファイルの例
kind: ImageSetConfiguration apiVersion: mirror.openshift.io/v1alpha2 archiveSize: 4 1 storageConfig: 2 registry: imageURL: example.com/mirror/oc-mirror-metadata 3 skipTLS: false mirror: platform: channels: - name: stable-4.13 4 type: ocp graph: true 5 operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.13 6 packages: - name: lvms-operator 7 channels: - name: stable 8 additionalImages: - name: registry.redhat.io/ubi9/ubi:latest 9 helm: {}
- 1
archiveSizeを追加して、イメージセット内の各ファイルの最大サイズを GiB 単位で設定します。- 2
- イメージセットのメタデータを保存するバックエンドの場所を設定します。この場所は、レジストリーまたはローカルディレクトリーにすることができます。Technology Preview OCI 機能を使用していない場合は、
storageConfig値を指定する必要があります。 - 3
- ストレージバックエンドのレジストリー URL を設定します。
- 4
- OpenShift Container Platform イメージを取得するためのチャネルを設定します。
- 5
graph: trueを追加して OpenShift Update Service (OSUS) グラフイメージを生成し、Web コンソールを使用する際のクラスター更新エクスペリエンスを向上させます。詳細については、OpenShift Update Service について を参照してください。- 6
- OpenShift Container Platform イメージを取得するための Operator カタログを設定します。
- 7
- イメージセットに含める特定の Operator パッケージのみを指定します。カタログ内のすべてのパッケージを取得するには、このフィールドを削除してください。
- 8
- イメージセットに含める Operator パッケージの特定のチャネルのみを指定します。そのチャネルでバンドルを使用しない場合も、常に Operator パッケージのデフォルトチャネルを含める必要があります。コマンド
oc mirror list operators --catalog=<catalog_name> --package=<package_name>を実行すると、デフォルトチャネルを見つけることができます。 - 9
- イメージセットに含める追加のイメージを指定します。
- Mirroring an image set to a mirror registry セクションの手順に従います。
- Configuring image registry repository mirroring セクションの手順に従います。
4.12.3.1.7. RHACM を使用した LVM ストレージのインストール
LVM ストレージは、Red Hat Advanced Cluster Management (RHACM) を使用してシングルノード OpenShift クラスターにデプロイされます。RHACM に Policy オブジェクトを作成します。これは、PlacementRule リソースで指定されたセレクターに一致するマネージドクラスターに適用される際に Operator をデプロイおよび設定します。このポリシーは、後でインポートされ、配置ルールを満たすクラスターにも適用されます。
前提条件
-
cluster-adminおよび Operator インストール権限を持つアカウントを使用して、RHACM クラスターにアクセスします。 - LVM ストレージによって使用される各シングルノード OpenShift クラスターの専用ディスク。
- シングルノード OpenShift クラスターは、インポートまたは作成された RHACM によって管理される必要があります。
手順
- OpenShift Container Platform の認証情報を使用して RHACM CLI にログインします。
ポリシーを作成する namespace を作成します。
# oc create ns lvms-policy-ns
ポリシーを作成するには、次の 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 default: true 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
- ボリュームグループを優先ディスクに制御または制限するには、
LVMClusterYAML のdeviceSelectorセクションでディスクのローカルパスを手動で指定します。 - 3
- 追加のワーカーノードのサブセットであるノードフィルターを追加するには、
nodeSelectorセクションに必要なフィルターを指定します。LVM ストレージは、新しいノードが表示されると、追加のワーカーノードを検出して使用します。
重要この
nodeSelectorノードフィルターの一致は、Pod ラベルの一致と同じではありません。次のコマンドを実行して、namespace にポリシーを作成します。
# oc create -f policy-lvms-operator.yaml -n lvms-policy-ns 1- 1
policy-lvms-operator.yamlは、ポリシーが保存されるファイルの名前です。
これにより、
lvms-policy-nsnamespace にPolicy、PlacementRule、およびPlacementBindingオブジェクトが作成されます。このポリシーは、配置ルールに一致するクラスター上にNamespace、OperatorGroup、Subscription、およびLVMClusterリソースを作成します。これにより、選択基準に一致するシングルノード OpenShift クラスターに Operator がデプロイされ、ストレージをプロビジョニングするために必要なリソースをセットアップするように設定されます。Operator はLVMClusterCR で指定されたすべてのディスクを使用します。ディスクが指定されていない場合、Operator はシングルノード OpenShift ノード上の未使用のディスクをすべて使用します。重要LVMClusterに追加されたデバイスは削除できません。
4.12.3.1.8. RHACM を使用してインストールされた LVM ストレージのアンインストール
RHACM を使用してインストールした LVM ストレージをアンインストールするには、Operator のデプロイと設定のために作成した RHACM ポリシーを削除する必要があります。
RHACM ポリシーを削除しても、ポリシーが作成したリソースは削除されません。リソースを削除する追加のポリシーを作成する必要があります。
ポリシーを削除しても、作成されたリソースは削除されないため、次の手順を実行する必要があります。
- LVM ストレージによってプロビジョニングされたすべての永続ボリューム要求 (PVC) とボリュームスナップショットを削除します。
-
LVMClusterリソースを削除して、ディスク上に作成された論理ボリュームマネージャーリソースをクリーンアップします。 - Operator をアンインストールする追加のポリシーを作成します。
前提条件
ポリシーを削除する前に、以下が削除されていることを確認してください。
- LVM ストレージによってプロビジョニングされたストレージを使用しているマネージドクラスター上のすべてのアプリケーション。
- LVM ストレージを使用してプロビジョニングされた PVC および永続ボリューム (PV)。
- LVM ストレージによってプロビジョニングされたすべてのボリュームスナップショット。
-
cluster-adminロールを持つアカウントを使用して RHACM クラスターにアクセスできることを確認します。
手順
OpenShift CLI (
oc) で、次のコマンドを使用して、ハブクラスターに LVM ストレージをデプロイおよび設定するために作成した RHACM ポリシーを削除します。# oc delete -f policy-lvms-operator.yaml -n lvms-policy-ns 1- 1
policy-lvms-operator.yamlは、ポリシーが保存されたファイルの名前です。
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-
PlacementRule.spec.clusterSelectorフィールドの値を設定して、LVM ストレージをアンインストールするクラスターを選択します。 次のコマンドを実行してポリシーを作成します。
# oc create -f lvms-remove-policy.yaml -n lvms-policy-ns
LVMClusterCR が削除されたかどうかを確認するポリシーを作成するには、次の 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次のコマンドを実行してポリシーを作成します。
# oc create -f check-lvms-remove-policy.yaml -n lvms-policy-ns
次のコマンドを実行して、ポリシーのステータスを確認します。
# 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
両方のポリシーに準拠したら、次の YAML を
lvms-uninstall-policy.yamlなどの名前のファイルに保存して、LVM ストレージをアンインストールするポリシーを作成します。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次のコマンドを実行してポリシーを作成します。
# oc create -f lvms-uninstall-policy.yaml -ns lvms-policy-ns
4.12.3.2. 単一ノードの OpenShift ワーカーノードでの論理ボリュームマネージャークラスターの作成
単一ノードの OpenShift ワーカーノードを論理ボリュームマネージャークラスターとして設定できます。コントロールプレーンの単一ノード OpenShift ノードでは、LVM ストレージは、クラスター内で新しいノードがアクティブになると、追加のワーカーノードを検出して使用します。
Logical Volume Manager クラスターを作成すると、StorageClass と LVMVolumeGroup リソースが連携して、ストレージの動的プロビジョニングが提供されます。StorageClass CR は、動的にプロビジョニングできるストレージのプロパティーを定義します。LVMVolumeGroup は、LVM ボリュームグループによってサポートされる特定のタイプの永続ボリューム (PV) です。LVMVolumeGroup CR は、作成する永続ボリュームのバックエンドストレージを提供します。
以下の手順を実行して、単一ノードの OpenShift ワーカーノードに論理ボリュームマネージャークラスターを作成します。
OpenShift Container Platform Web コンソールを使用して同じタスクを実行することもできます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - 単一ノードの OpenShift クラスターに LVM ストレージをインストールし、単一ノードの OpenShift クラスターで使用するワーカーノードをインストールしました。
手順
LVMClusterカスタムリソース (CR) を作成します。次の YAML を
lvmcluster.yamlファイルに保存します。apiVersion: lvm.topolvm.io/v1alpha1 kind: LVMCluster metadata: name: lvmcluster spec: storage: deviceClasses: 1 - name: vg1 default: true 2 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 nodeSelector: 3 nodeSelectorTerms: - matchExpressions: - key: app operator: In values: - test1- 1
- クラスター内に複数のデバイスストレージクラスを作成するには、必要なストレージクラスごとに
deviceClassesの下に YAML 配列を作成します。ディスクのローカルデバイスパスをdeviceSelectorフィールドの値の配列として設定します。複数のデバイスクラスを設定する場合は、デバイスごとにデバイスパスを指定する必要があります。 - 2
- 必須:
LVMClusterリソースには、デフォルトのストレージクラスを 1 つ含める必要があります。セカンダリーデバイスストレージクラスのデフォルトを falseに設定します。LVMClusterリソースを以前のバージョンからアップグレードする場合は、デフォルトのデバイスクラスを 1 つ指定する必要があります。 - 3
- オプション:
LVMClusterCR が適用されるワーカーノードを制御するには、一連のノードセレクターラベルを指定します。ノードでLVMClusterをスケジュールするには、指定したラベルがノードに存在する必要があります。
LVMClusterCR を作成します。$ oc create -f lvmcluster.yaml
出力例
lvmcluster/lvmcluster created
LVMClusterリソースは、次のシステム管理 CR を作成します。LVMVolumeGroup- 複数のノードにわたって個々のボリュームグループを追跡します。
LVMVolumeGroupNodeStatus- ノード上のボリュームグループのステータスを追跡します。
検証
LVMCluster リソースが StorageClass、LVMVolumeGroup、および LVMVolumeGroupNodeStatus CR を作成したことを確認します。
LVMVolumeGroup と LVMVolumeGroupNodeStatus は、LVM Storage によって管理されます。これらの CR を直接編集しないでください。
次のコマンドを実行して、
LVMClusterCR が準備ready状態であることを確認します。$ oc get lvmclusters.lvm.topolvm.io -o jsonpath='{.items[*].status.deviceClassStatuses[*]}'出力例
{ "name": "vg1", "nodeStatus": [ { "devices": [ "/dev/nvme0n1", "/dev/nvme1n1", "/dev/nvme2n1" ], "node": "kube-node", "status": "Ready" } ] }ストレージクラスが作成されたことを確認します。
$ oc get storageclass
出力例
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE lvms-vg1 topolvm.io Delete WaitForFirstConsumer true 31m
ボリュームスナップショットクラスが作成されていることを確認します。
$ oc get volumesnapshotclass
出力例
NAME DRIVER DELETIONPOLICY AGE lvms-vg1 topolvm.io Delete 24h
LVMVolumeGroupリソースが作成されていることを確認します。$ oc get lvmvolumegroup vg1 -o yaml
出力例
apiVersion: lvm.topolvm.io/v1alpha1 kind: LVMVolumeGroup metadata: creationTimestamp: "2022-02-02T05:16:42Z" generation: 1 name: vg1 namespace: lvm-operator-system resourceVersion: "17242461" uid: 88e8ad7d-1544-41fb-9a8e-12b1a66ab157 spec: {}LVMVolumeGroupNodeStatusリソースが作成されていることを確認します。$ oc get lvmvolumegroupnodestatuses.lvm.topolvm.io kube-node -o yaml
出力例
apiVersion: lvm.topolvm.io/v1alpha1 kind: LVMVolumeGroupNodeStatus metadata: creationTimestamp: "2022-02-02T05:17:59Z" generation: 1 name: kube-node namespace: lvm-operator-system resourceVersion: "17242882" uid: 292de9bb-3a9b-4ee8-946a-9b587986dafd spec: nodeStatus: - devices: - /dev/nvme0n1 - /dev/nvme1n1 - /dev/nvme2n1 name: vg1 status: Ready
4.12.3.3. LVM ストレージを使用したストレージのプロビジョニング
Operator のインストール中に作成されたストレージクラスを使用して、永続ボリューム要求 (PVC) をプロビジョニングできます。ブロックおよびファイル PVC をプロビジョニングできますが、ストレージは、PVC を使用する Pod が作成された場合にのみ割り当てられます。
LVM ストレージは、PVC を 1 GiB 単位でプロビジョニングします。要求されたストレージは、最も近い GiB に切り上げられます。
手順
LVM ストレージのデプロイ時に作成される
StorageClassを特定します。StorageClass名の形式はlvms-<device-class-name>です。device-class-nameは、PolicyYAML のLVMClusterで指定したデバイスクラスの名前です。たとえば、deviceClassの名前がvg1の場合、storageClassの名前はlvms-vg1です。ストレージクラスの
volumeBindingModeはWaitForFirstConsumerに設定されます。アプリケーションがストレージを必要とする 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以下のコマンドを実行して PVC を作成します。
# oc create -f pvc.yaml -ns <application_namespace>
作成された PVC は、それらを使用する Pod をデプロイするまで
pending状態のままになります。
4.12.3.4. LVM ストレージの監視
OpenShift Container Platform Web コンソールを使用して LVM ストレージをインストールすると、デフォルトでコンソールの Block and File ダッシュボードを使用してクラスターを監視できます。ただし、RHACM を使用して LVM ストレージをインストールする場合は、RHACM Observability を設定して、すべてのシングルノード OpenShift クラスターを 1 か所から監視する必要があります。
4.12.3.4.1. メトリクス
RHACM ダッシュボードで Operator によってエクスポートされたメトリックとトリガーされたアラートを表示することで、LVM ストレージを監視できます。
次の
topolvmメトリックをallowリストに追加します。topolvm_thinpool_data_percent topolvm_thinpool_metadata_percent topolvm_thinpool_size_bytes
メトリックは、10 分ごとに更新されるか、新しい論理ボリュームの作成など、シンプールに変更があったときに更新されます。
4.12.3.4.2. アラート
シンプールとボリュームグループがいっぱいになると、それ以降の操作は失敗し、データが失われる可能性があります。LVM ストレージは、使用率が特定の値を超えると、シンプールとボリュームグループの使用率に関する次のアラートを送信します。
RHACM の論理ボリュームマネージャークラスターのアラート
| アラート | 説明 |
|---|---|
|
| このアラートは、ボリュームグループとシンプールの使用率の両方がノードで 75% を超えたときにトリガーされます。データの削除またはボリュームグループの拡張が必要です。 |
|
|
このアラートは、ボリュームグループとシンプールの両方の使用率がノードで 85% を超えるとトリガーされます。 |
|
| このアラートは、ボリュームグループのシンプールのデータ使用率がノード上で 75% を超えるとトリガーされます。データの削除またはシンプールの拡張が必要です。 |
|
| このアラートは、ボリュームグループのシンプールのデータ使用率がノード上で 85% を超えるとトリガーされます。データの削除またはシンプールの拡張が必要です。 |
|
| このアラートは、ボリュームグループのシンプールのメタデータ使用率がノードで 75% を超えると発生します。データの削除またはシンプールの拡張が必要です。 |
|
| このアラートは、ボリュームグループのシンプールのメタデータ使用率がノード上で 85% を超えるとトリガーされます。データの削除またはシンプールの拡張が必要です。 |
関連情報
4.12.3.5. シングルノード OpenShift クラスターのストレージのスケーリング
OpenShift Container Platform は、ユーザーがプロビジョニングしたベアメタルインフラストラクチャー上のシングルノード OpenShift クラスターの追加のワーカーノードをサポートします。LVM ストレージは、ノードが表示されると、新しい追加のワーカーノードを検出して使用します。
4.12.3.5.1. シングルノード OpenShift クラスターに容量を追加してストレージをスケールアップする
シングルノード OpenShift クラスターで設定済みのワーカーノードのストレージ容量をスケーリングするには、ディスクを追加して容量を増やすことができます。
前提条件
- シングルノード OpenShift クラスターごとに、LVM ストレージで使用される追加の未使用ディスクがあります。
手順
- シングルノード OpenShift クラスターの OpenShift Container Platform コンソールにログインします。
-
Operators → Installed Operators ページで、
openshift-storagenamespace の LVM Storage Operator をクリックします。 -
LVMCluster タブをクリックして、クラスターで作成された
LVMClusterCR を一覧表示します。 - Actions ドロップダウンメニューから Edit LVMCluster を選択します。
- YAML タブをクリックします。
LVMClusterCR YAML を編集して、deviceSelectorセクションに新しいデバイスパスを追加します。注記LVMClusterの作成中にdeviceSelectorフィールドが含まれていない場合、deviceSelectorセクションを CR に追加することはできません。LVMClusterを削除してから、新しい CR を作成する必要があります。apiVersion: lvm.topolvm.io/v1alpha1 kind: LVMCluster metadata: name: my-lvmcluster spec: storage: deviceClasses: - name: vg1 default: true 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
4.12.3.5.2. RHACM を使用してシングルノード OpenShift クラスターに容量を追加してストレージをスケールアップする
RHACM を使用して、シングルノード OpenShift クラスターで設定済みのワーカーノードのストレージ容量をスケーリングできます。
前提条件
-
cluster-admin権限を持つアカウントを使用して RHACM クラスターにアクセスできます。 - シングルノード OpenShift クラスターごとに、LVM ストレージで使用される追加の未使用ディスクがあります。
手順
- OpenShift Container Platform の認証情報を使用して RHACM CLI にログインします。
- 追加するディスクを見つけます。追加するディスクは、既存のディスクのデバイス名およびパスと一致するようにする必要があります。
シングルノード 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 default: true 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以下のコマンドを実行してポリシーを編集します。
# oc edit -f policy-lvms-operator.yaml -ns lvms-policy-ns 1- 1
policy-lvms-operator.yamlは既存のポリシーの名前です。
これは、
LVMClusterCR で指定された新しいディスクを使用してストレージをプロビジョニングします。
4.12.3.5.3. PVC の拡張
容量を追加した後、新しいストレージを活用するには、LVM ストレージで既存の永続ボリューム要求 (PVC) を拡張できます。
前提条件
- 動的プロビジョニングが使用される。
-
制御する側の
StorageClassオブジェクトにはallowVolumeExpansionがtrueに設定されている。
手順
次のコマンドを実行して、目的の PVC リソースの
.spec.resources.requests.storageフィールドを新しいサイズに変更します。oc patch <pvc_name> -n <application_namespace> -p '{ "spec": { "resources": { "requests": { "storage": "<desired_size>" }}}}'-
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 にアップグレードすることはできません。
このプロセス中、データは保持されません。
手順
- 永続ボリューム要求 (PVC) で保持するデータをバックアップします。
- OpenShift Data Foundation Logical Volume Manager Operator とその Pod によってプロビジョニングされたすべての PVC を削除します。
- OpenShift Container Platform 4.12 に LVM ストレージを再インストールします。
- ワークロードを再作成します。
- 4.12 へのアップグレード後に作成された PVC にバックアップデータをコピーします。
4.12.3.7. シングルノード OpenShift のボリュームスナップショット
LVM ストレージによってプロビジョニングされた永続ボリューム (PV) のボリュームスナップショットを取得できます。クローン作成されたボリュームのボリュームスナップショットを作成することもできます。ボリュームスナップショットは、次のことを行うのに役立ちます。
アプリケーションデータをバックアップします。
重要ボリュームスナップショットは元のデータと同じデバイスにあります。ボリュームスナップショットをバックアップとして使用するには、スナップショットをセキュアな場所に移動する必要があります。OpenShift API をデータ保護のバックアップおよび復元ソリューションに使用できます。
- ボリュームスナップショットが作成された状態に戻します。
関連情報
4.12.3.7.1. シングルノード OpenShift でのボリュームスナップショットの作成
シンプールの使用可能な容量とオーバープロビジョニングの制限に基づいて、ボリュームスナップショットを作成できます。LVM ストレージは、lvms-<deviceclass-name> という名前で VolumeSnapshotClass を作成します。
前提条件
-
永続ボリューム要求 (PVC) が
Bound状態であることを確認しました。これは、一貫性のあるスナップショットに必要です。 - スナップショットを作成する前に、PVC へのすべての I/O を停止しました。
手順
-
ocコマンドを実行する必要があるシングルノード OpenShift にログインします。 次の 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-1PVC と同じ namespace で次のコマンドを実行して、スナップショットを作成します。
# oc create -f lvms-vol-snapshot.yaml
PVC の読み取り専用コピーがボリュームスナップショットとして作成されます。
4.12.3.7.2. シングルノード OpenShift でのボリュームスナップショットの復元
ボリュームスナップショットを復元すると、新しい永続ボリューム要求 (PVC) が作成されます。復元される PVC はボリュームスナップショットおよびソース PVC とは切り離されています。
前提条件
- ストレージクラスは、ソース PVC のストレージクラスと同じである必要がある。
要求された PVC のサイズは、スナップショットのソースボリュームのサイズと同じである必要がある。
重要スナップショットは、スナップショットのソースボリュームと同じサイズの PVC に復元される必要があります。より大きな PVC が必要な場合は、スナップショットが正常に復元された後に PVC のサイズを変更できます。
手順
- ソース PVC のストレージクラス名とボリュームスナップショット名を特定します。
次の 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スナップショットと同じ namespace で次のコマンドを実行して、ポリシーを作成します。
# oc create -f lvms-vol-restore.yaml
4.12.3.7.3. シングルノード OpenShift でのボリュームスナップショットの削除
ボリュームスナップショットリソースと永続ボリューム要求 (PVC) を削除できます。
手順
次のコマンドを実行して、ボリュームスナップショットリソースを削除します。
# oc delete volumesnapshot <volume_snapshot_name> -n <namespace>
注記永続ボリューム要求 (PVC) を削除しても、PVC のスナップショットは削除されません。
復元されたボリュームスナップショットを削除するには、次のコマンドを実行して、ボリュームスナップショットを復元するために作成された PVC を削除します。
# oc delete pvc <pvc_name> -n <namespace>
4.12.3.8. シングルノード OpenShift のボリュームのクローン作成
クローンは、既存のストレージボリュームの複製であり、他の標準ボリュームと同じように使用できます。
4.12.3.8.1. シングルノード OpenShift でのボリュームクローンの作成
ボリュームのクローンを作成して、データのポイントインタイムコピーを作成します。永続ボリューム要求 (PVC) は別のサイズでクローンできません。
クローン作成された PVC には書き込みアクセス権限があります。
前提条件
-
PVC が
Bound状態であることを確認しました。これは、一貫性のあるスナップショットに必要です。 -
StorageClassがソース PVC のものと同じであることを確認しました。
手順
- ソース PVC のストレージクラスを特定します。
ボリュームクローンを作成するには、次の 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次のコマンドを実行して、ソース 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. must-gather を使用したログファイルおよび診断情報のダウンロード
LVM ストレージが問題を自動的に解決できない場合、must-gather ツールを使用してログファイルと診断情報を収集し、ユーザーまたは Red Hat サポートが問題を確認して解決策を決定できるようにします。
次のコマンドを実行して、LVM ストレージクラスターに接続されたクライアントから must-gather コマンドを実行します。
$ oc adm must-gather --image=registry.redhat.io/lvms4/lvms-must-gather-rhel8:v4.13 --dest-dir=<directory-name>
関連情報
4.12.3.10. 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
default: true
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 ボリュームグループ。現在、1 つの
deviceClassのみがサポートされています。 - 2
- ノード上に作成される LVM ボリュームグループの名前。
- 3
- LVM ボリュームグループを作成するノード。フィールドが空の場合、すべてのノードが考慮されます。
- 4
- ノードセレクター要件のリスト。
- 5
- 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)を単一プロジェクトに限定しないため、クラスター全体で共有でき、Persistent Volume Claim (永続ボリューム要求、PVC)を使用して任意のプロジェクトで要求できます。これにより、トラブルシューティングが必要な多くの問題が発生する可能性があります。
4.12.4.1. PVC が Pending 状態でスタックする調査
永続ボリューム要求(PVC)は、いくつかの理由で Pending 状態のままになる可能性があります。以下に例を示します。
- 不十分なコンピューティングリソース
- ネットワークの問題
- 一致しないストレージクラスまたはノードセレクター
- 利用可能なボリュームがありません
-
永続ボリューム(PV)を持つノードは
Not Ready状態にある。
oc describe コマンドを使用して、スタックしている PVC の詳細を確認して原因を特定します。
手順
以下のコマンドを実行して PVC の一覧を取得します。
$ oc get pvc
出力例
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE lvms-test Pending lvms-vg1 11s
以下のコマンドを実行して、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 コンポーネントの欠落からの復旧
ストレージクラス not found エラーが発生した場合は、LVMCluster リソースをチェックして、すべての論理ボリュームマネージャーストレージ(LVMS) Pod が実行していることを確認します。LVMCluster リソースが存在しない場合は作成できます。
手順
以下のコマンドを実行して、LVMCluster リソースが存在することを確認します。
$ oc get lvmcluster -n openshift-storage
出力例
NAME AGE my-lvmcluster 65m
クラスターに
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次のコマンドを実行して、LVMS のすべての Pod が
openshift-storagenamespace で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の実行中のインスタンスです。各ノードに、topolvm-controllerとtopolvm-nodeの 1 つのインスタンスが想定されています。topolvm-nodeがInit状態でスタックしている場合、LVMS が使用できるディスクを見つけることができません。トラブルシューティングに必要な情報を取得するには、以下のコマンドを実行してvg-managerPod のログを確認します。$ oc logs -l app.kubernetes.io/component=vg-manager -n openshift-storage
4.12.4.3. ノード障害からの復旧
クラスター内の特定のノードが失敗したために、永続ボリューム要求(PVC)が Pending 状態のままになることがあります。障害が発生したノードを特定するには、topolvm-node Pod の再起動数を調べます。再起動カウントを増やすと、基礎となるノードの潜在的な問題があることを示し、さらに調査とトラブルシューティングが必要になる場合があります。
手順
次のコマンドを実行して、
topolvm-nodePod インスタンスの再起動回数を調べます。$ 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)に関連付けられたイベントを検査する際に失敗メッセージが表示される場合は、基礎となるボリュームまたはディスクに問題がある可能性があります。ディスクとボリュームのプロビジョニングの問題は、StorageClass <storage_class_name> でボリュームのプロビジョニングの失敗など、最初に一般的なエラーになることがよくあり ます。2 番目の特定のエラーメッセージは通常、以下のようになります。
手順
以下のコマンドを実行して、PVC に関連付けられたイベントを検証します。
$ oc describe pvc <pvc_name> 1- 1
- <
;pvc_name> を PVC の名前に置き換えます。ディスクまたはボリューム障害のエラーメッセージとその原因の例を以下に示します。- ボリュームの 存在の確認に失敗しました:ボリューム がすでに存在しているかどうかを確認するための問題を示します。ボリューム検証の失敗は、ネットワーク接続の問題やその他の失敗によって引き起こされる可能性があります。
- ボリュームのバインドに失敗しました: 利用可能な永続ボリューム(PV)が PVC の要件と一致しない場合には、ボリュームのバインドに失敗する場合があります。
- FailedMount または FailedUnMount: このエラーは、ボリュームをノードにマウントしようとしたり、ノードからボリュームをアンマウントしたりする場合に問題を示します。ディスクが失敗している場合、Pod が PVC の使用を試行する際にこのエラーが表示される可能性があります。
-
ボリュームはすでに 1 つのノードにのみ割り当てられており、別のノードにアタッチすることはできません。このエラーは、
ReadWriteManyアクセスモードをサポートしないストレージソリューションに表示される可能性 があります。
- 問題が発生しているホストへの直接接続を確立します。
- ディスクの問題を解決します。
ディスクに関する問題を解決したら、エラーメッセージが持続または再発した場合に、強制クリーンアップ手順が必要になる場合があります。
関連情報
4.12.4.5. 強制クリーンアップの実行
トラブルシューティングの手順の完了後にディスクまたはノード関連の問題が解決しない場合は、強制クリーンアップ手順を実行する必要があります。強制クリーンアップは、永続的な問題を包括的に解決し、LVMS の適切な機能を確認するために使用されます。
前提条件
- 論理ボリュームマネージャーストレージ(LVMS)ドライバーを使用して作成されたすべての永続ボリューム要求(PVC)が削除されました。
- これらの PVC を使用する Pod が停止されている。
手順
次のコマンドを実行して、
openshift-storagenamespace を作成します。$ oc project openshift-storage
次のコマンドを実行して、
論理ボリュームカスタムリソース(CR)が残っていないことを確認します。$ oc get logicalvolume
出力例
No resources found
次のコマンドを実行して、
LVMVolumeGroupCR が残っていないことを確認します。$ oc get lvmvolumegroup
出力例
No resources found
次のコマンドを実行して、
LVMVolumeGroupNodeStatusCR を削除します。$ oc delete lvmvolumegroupnodestatus --all
次のコマンドを実行して、
LVMClusterCR を削除します。$ oc delete lvmcluster --all