4.12. ローカルストレージを使用した永続ストレージ
4.12.1. ローカルボリュームを使用した永続ストレージ
OpenShift Container Platform は、ローカルボリュームを使用する永続ストレージでプロビジョニングすることが可能です。ローカルの永続ボリュームを使用すると、標準の永続ボリューム要求インターフェイスを使用して、ディスクやパーティションなどのローカルのストレージデバイスにアクセスできます。
ローカルボリュームは、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 を使用して 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>
定義を追加できます。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-sc 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-sc 2 local: path: /dev/xvdf 3 nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - example-node
OpenShift 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-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. ローカルボリュームの永続ボリューム要求の作成
ローカルボリュームは、Pod でアクセスされる永続ボリューム要求として静的に作成される必要があります。
前提条件
- 永続ボリュームがローカルボリュームプロビジョナーを使用して作成されていること。
手順
対応するストレージクラスを使用して 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. ローカル要求を割り当てます。
ローカルボリュームが永続ボリューム要求にマップされた後に、これをリソース内に指定できます。
前提条件
- 永続ボリューム要求が同じ namespace に存在する。
手順
定義された要求をリソースの仕様に追加します。以下の例では、Pod 内で永続ボリューム要求を宣言します。
apiVersion: v1 kind: Pod spec: # ... containers: volumeMounts: - name: local-disks 1 mountPath: /data 2 volumes: - name: local-disks 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 のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
Red Hat OpenShift Data Foundation をオンプレミスでデプロイするために使用する場合、またはプラットフォームに依存しないデプロイメントで使用する場合、自動検出とプロビジョニングは完全にサポートされます。
ローカルデバイスを自動的に検出し、選択したデバイスのローカルボリュームを自動的にプロビジョニングするには、以下の手順を使用します。
LocalVolumeSet
オブジェクトの使用には注意が必要です。ローカルディスクから永続ボリューム (PV) を自動的にプロビジョニングする場合、ローカル PV は一致するすべてのデバイスを要求する可能性があります。LocalVolumeSet
オブジェクトを使用している場合、ローカルストレージ Operator がノードでローカルデバイスを管理する唯一のエンティティーであることを確認します。ノードを複数回ターゲットにする Local VolumeSet
のインスタンスを複数作成することはサポートされていません。
前提条件
- クラスター管理者パーミッションがある。
- ローカルストレージ Operator がインストールされていること。
- ローカルディスクが OpenShift Container Platform ノードに割り当てられていること。
-
OpenShift Container Platform Web コンソールまたは
oc
コマンドラインインターフェイス (CLI) へのアクセスがあること。
手順
Web コンソールからローカルデバイスの自動検出を有効にするには、以下を行います。
-
Operators
Installed Operators をクリックします。 -
openshift-local-storage
namespace で Local Storage をクリックします。 - Local Volume Discovery タブをクリックします。
- Create Local Volume Discovery をクリックし、Form view または YAML view のいずれかを選択します。
-
LocalVolumeDiscovery
オブジェクトパラメーターを設定します。 Create をクリックします。
Local Storage Operator は、
auto-discover-devices
という名前のローカルボリューム検出インスタンスを作成します。
-
Operators
ノードで利用可能なデバイスの連続リストを表示するには、以下を実行します。
- 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 の調整が正常に行われたことが示唆されます。
-
Operators
または、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: 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
ローカルボリュームセットオブジェクトを作成します。
$ 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 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 がそのノードでも実行されるようにできます。
taint および toleration は、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: "local-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 ユーザーとしてノードにアクセスする必要があります。この手順のステップ以外にノードの状態を変更すると、クラスターが不安定になる可能性があります。
$ 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 コンソールにアクセスできる。
手順
プロジェクトにインストールされているローカルボリュームリソースを削除します (
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 は、手動の (静的) プロビジョニングで参照される必要があります。
手順
PersistentVolume
オブジェクト定義を含むpv.yaml
ファイルを作成して、永続ボリューム (PV) を定義します。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
PersistentVolumeClaim
オブジェクト定義を含むpvc.yaml
ファイルを作成して PVC を定義します。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 共有のマウント
永続ボリューム要求の作成後に、これをアプリケーション内で使用できます。以下の例は、この共有を Pod 内にマウントする方法を示しています。
前提条件
- 基礎となる hostPath 共有にマップされる永続ボリューム要求があること。
手順
既存の永続ボリューム要求をマウントする特権付き 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. 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. CLI を使用した LVM Storage のインストール
クラスター管理者は、CLI を使用して Logical Volume Manager (LVM) ストレージをインストールできます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
LVM Storage Operator の namespace を作成します。
次の 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-storage
namespace
CR を作成します。$ 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
OperatorGroup
CR を作成します。$ 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
Subscription
CR を作成します。$ oc create -f lvms-sub.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.3. Web コンソールを使用した LVM Storage のインストール
Red Hat OpenShift Container Platform OperatorHub を使用して、Logical Volume Manager (LVM) Storage をインストールできます。
前提条件
- シングルノード OpenShift クラスターにアクセスできます。
-
cluster-admin
および Operator のインストール権限を持つアカウントを使用しています。
手順
- OpenShift Container Platform Web コンソールにログインします。
-
Operators
OperatorHub をクリックします。 -
スクロールするか、
LVM Storage
を Filter by keyword ボックスに入力して、LVM Storage を見つけます。 - Install をクリックします。
Install Operator ページで、以下のオプションを設定します。
- Channel を stable-4.13 として更新します。
- Installation Mode を A specific namespace on the cluster に設定します。
-
Installed Namespace を Operator recommended namespace openshift-storage に設定します。
openshift-storage
namespace が存在しない場合は、Operator のインストール中に作成されます。 Approval Strategy を Automatic または Manual に設定します。
Automatic (自動) 更新を選択すると、Operator Lifecycle Manager (OLM) は介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。
Manual 更新を選択すると、OLM は更新要求を作成します。クラスター管理者は、Operator を新しいバージョンに更新できるように更新要求を手動で承認する必要があります。
- Install をクリックします。
検証手順
- インストールが成功したことを示す緑色のチェックマークが LVM Storage に表示されていることを確認します。
4.12.3.1.4. CLI を使用した LVM Storage のインストール
OpenShift CLI (oc
) を使用して LVM ストレージをアンインストールできます。
前提条件
-
cluster-admin
権限を持つユーザーとしてoc
にログインしている。 - LVM Storage によってプロビジョニングされた永続ボリューム要求 (PVC)、ボリュームスナップショット、およびボリュームクローンが削除されている。これらのリソースを使用しているアプリケーションも削除されている。
-
LVMCluster
カスタムリソース (CR) が削除されている。
手順
次のコマンドを実行して、LVM Storage Operator の
currentCSV
の値を取得します。$ oc get subscription.operators.coreos.com lvms-operator -n <namespace> -o yaml | grep currentCSV
出力例
currentCSV: lvms-operator.v4.15.3
次のコマンドを実行して、サブスクリプションを削除します。
$ oc delete subscription.operators.coreos.com lvms-operator -n <namespace>
出力例
subscription.operators.coreos.com "lvms-operator" deleted
次のコマンドを実行して、ターゲット namespace 内の LVM Storage Operator の CSV を削除します。
$ oc delete clusterserviceversion <currentCSV> -n <namespace> 1
- 1
<currentCSV>
は、LVM Storage Operator のcurrentCSV
値に置き換えます。
出力例
clusterserviceversion.operators.coreos.com "lvms-operator.v4.15.3" deleted
検証
LVM Storage Operator がアンインストールされたことを確認するには、次のコマンドを実行します。
$ oc get csv -n <namespace>
LVM Storage Operator が正常にアンインストールされた場合、このコマンドの出力には表示されません。
4.12.3.1.5. OpenShift Web コンソールを使用してインストールされた LVM ストレージのアンインストール
Red Hat OpenShift Container Platform Web コンソールを使用して、LVM ストレージをアンインストールできます。
前提条件
- LVM Storage によってプロビジョニングされたストレージを使用しているクラスター上のすべてのアプリケーションを削除しました。
- LVM Storage を使用してプロビジョニングされた永続ボリューム要求 (PVC) と永続ボリューム (PV) を削除しました。
- LVM Storage によってプロビジョニングされたすべてのボリュームスナップショットを削除しました。
-
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 Storage は実行を停止し、完全に削除されます。
4.12.3.1.6. 非接続環境での LVM ストレージのインストール
非接続環境の OpenShift Container Platform 4.13 に LVM Storage をインストールできます。この手順で参照されているすべてのセクションは、追加リソース にリンクされています。
前提条件
- 非接続インストールミラーリングについて セクションを確認した。
- OpenShift Container Platform イメージリポジトリーにアクセスできる。
- ミラーレジストリーを作成した。
手順
イメージセット設定の作成 手順の手順に従います。LVM Storage の
ImageSetConfiguration
リソースを作成するには、次のサンプル YAML ファイルを使用できます。LVM Storage 用の 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 Storage のインストール
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
- ボリュームグループを優先ディスクに制御または制限するには、
LVMCluster
YAML のdeviceSelector
セクションでディスクのローカルパスを手動で指定します。 - 3
- 追加のワーカーノードのサブセットであるノードフィルターを追加するには、
nodeSelector
セクションに必要なフィルターを指定します。LVM Storage は、新しいノードが表示されると、追加のワーカーノードを検出して使用します。
重要この
nodeSelector
ノードフィルターの一致は、Pod ラベルの一致と同じではありません。次のコマンドを実行して、namespace にポリシーを作成します。
# oc create -f policy-lvms-operator.yaml -n lvms-policy-ns 1
- 1
policy-lvms-operator.yaml
は、ポリシーが保存されるファイルの名前です。
これにより、
lvms-policy-ns
namespace にPolicy
、PlacementRule
、およびPlacementBinding
オブジェクトが作成されます。このポリシーは、配置ルールに一致するクラスター上にNamespace
、OperatorGroup
、Subscription
、およびLVMCluster
リソースを作成します。これにより、選択基準に一致するシングルノード OpenShift クラスターに Operator がデプロイされ、ストレージをプロビジョニングするために必要なリソースをセットアップするように設定されます。Operator はLVMCluster
CR で指定されたすべてのディスクを使用します。ディスクが指定されていない場合、Operator はシングルノード OpenShift ノード上の未使用のディスクをすべて使用します。重要LVMCluster
に追加されたデバイスは削除できません。
4.12.3.1.8. RHACM を使用してインストールされた LVM ストレージのアンインストール
RHACM を使用してインストールした LVM Storage をアンインストールするには、Operator のデプロイと設定のために作成した RHACM ポリシーを削除する必要があります。
RHACM ポリシーを削除しても、ポリシーが作成したリソースは削除されません。リソースを削除する追加のポリシーを作成する必要があります。
ポリシーを削除しても、作成されたリソースは削除されないため、次の手順を実行する必要があります。
- LVM Storage によってプロビジョニングされたすべての永続ボリューム要求 (PVC) とボリュームスナップショットを削除します。
-
LVMCluster
リソースを削除して、ディスク上に作成された論理ボリュームマネージャーリソースをクリーンアップします。 - Operator をアンインストールする追加のポリシーを作成します。
前提条件
ポリシーを削除する前に、以下が削除されていることを確認してください。
- LVM Storage によってプロビジョニングされたストレージを使用しているマネージドクラスター上のすべてのアプリケーション。
- LVM Storage を使用してプロビジョニングされた PVC および永続ボリューム (PV)。
- LVM Storage によってプロビジョニングされたすべてのボリュームスナップショット。
-
cluster-admin
ロールを持つアカウントを使用して RHACM クラスターにアクセスできることを確認します。
手順
OpenShift CLI (
oc
) で、次のコマンドを使用して、ハブクラスターに LVM Storage をデプロイおよび設定するために作成した 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 Storage をアンインストールするクラスターを選択します。 次のコマンドを実行してポリシーを作成します。
# oc create -f lvms-remove-policy.yaml -n lvms-policy-ns
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
次のコマンドを実行してポリシーを作成します。
# 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 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
次のコマンドを実行してポリシーを作成します。
# 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 の最大サイズは、カーネルの制限とディスク領域によって決定されます。
アーキテクチャー | RHEL 6 | RHEL 7 | RHEL 8 | RHEL 9 |
---|---|---|---|---|
32 ビット | 16 TB | - | - | - |
64 ビット | 8 EB [1] 100 TB [2] | 8 EB [1] 500 TB [2] | 8 EB | 8 EB |
- 理論的サイズ。
- テスト済みサイズ。
4.12.3.3. 単一ノードの 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) を作成します。重要OpenShift Container Platform クラスターでは、
LVMCluster
カスタムリソース (CR) のインスタンスを 1 つだけ作成できます。次の 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 配列を作成します。deviceClass を追加または削除する場合、TopoLVM-Node
Pod を削除して再作成しなければ、更新はクラスターに反映されません。ディスクのローカルデバイスパスをdeviceSelector
フィールドの値の配列として設定します。複数のデバイスクラスを設定する場合は、デバイスごとにデバイスパスを指定する必要があります。 - 2
- 必須:
LVMCluster
リソースには、デフォルトのストレージクラスを 1 つ含める必要があります。セカンダリーデバイスストレージクラスのデフォルトを false
に設定します。LVMCluster
リソースを以前のバージョンからアップグレードする場合は、デフォルトのデバイスクラスを 1 つ指定する必要があります。 - 3
- オプション:
LVMCluster
CR が適用されるワーカーノードを制御するには、一連のノードセレクターラベルを指定します。ノードでLVMCluster
をスケジュールするには、指定したラベルがノードに存在する必要があります。
LVMCluster
CR を作成します。$ oc create -f lvmcluster.yaml
出力例
lvmcluster/lvmcluster created
LVMCluster
リソースは、次のシステム管理 CR を作成します。LVMVolumeGroup
- 複数のノードにわたって個々のボリュームグループを追跡します。
LVMVolumeGroupNodeStatus
- ノード上のボリュームグループのステータスを追跡します。
検証
LVMCluster
リソースが StorageClass
、LVMVolumeGroup
、および LVMVolumeGroupNodeStatus
CR を作成したことを確認します。
LVMVolumeGroup
と LVMVolumeGroupNodeStatus
は、LVM Storage によって管理されます。これらの CR を直接編集しないでください。
次のコマンドを実行して、
LVMCluster
CR が準備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.4. LVM ストレージを使用したストレージのプロビジョニング
Operator のインストール中に作成されたストレージクラスを使用して、永続ボリューム要求 (PVC) をプロビジョニングできます。ブロックおよびファイル PVC をプロビジョニングできますが、ストレージは、PVC を使用する Pod が作成された場合にのみ割り当てられます。
LVM Storage は、PVC を 1 GiB 単位でプロビジョニングします。要求されたストレージは、最も近い GiB に切り上げられます。
手順
LVM Storage のデプロイ時に作成される
StorageClass
を特定します。StorageClass
名の形式はlvms-<device-class-name>
です。device-class-name
は、Policy
YAML の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.5. シングルノード OpenShift クラスターのストレージのスケーリング
OpenShift Container Platform は、ユーザーがプロビジョニングしたベアメタルインフラストラクチャー上のシングルノード OpenShift クラスターの追加のワーカーノードをサポートします。LVM ストレージは、ノードが表示されると、新しい追加のワーカーノードを検出して使用します。
4.12.3.5.1. シングルノード OpenShift クラスターに容量を追加してストレージをスケールアップする
シングルノード OpenShift クラスターで設定済みのワーカーノードのストレージ容量をスケーリングするには、ディスクを追加して容量を増やすことができます。
前提条件
- シングルノード OpenShift クラスターごとに、LVM ストレージで使用される追加の未使用ディスクがあります。
手順
- シングルノード OpenShift クラスターの OpenShift Container Platform コンソールにログインします。
-
Operators
Installed Operators ページで、 openshift-storage
namespace の LVM Storage Operator をクリックします。 -
LVMCluster タブをクリックして、クラスターで作成された
LVMCluster
CR を一覧表示します。 - Actions ドロップダウンメニューから Edit LVMCluster を選択します。
- YAML タブをクリックします。
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 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
は既存のポリシーの名前です。
これは、
LVMCluster
CR で指定された新しいディスクを使用してストレージをプロビジョニングします。
4.12.3.5.3. PVC の拡張
容量を追加した後、新しいストレージを活用するには、LVM Storage で既存の永続ボリューム要求 (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 ストレージのアップグレード
論理ボリュームマネージャーストレージ (LVM ストレージ) Operator をアップグレードして、シングルノード OpenShift バージョンとの互換性を確保できます。
前提条件
- 単一ノードの OpenShift クラスターがアップグレードされている。
- 以前のバージョンの LVM Storage Operator がインストールされている。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
次のコマンドを実行して、LVM Storage Operator の
Subscription
リソースを更新します。$ oc patch subscription lvms-operator -n openshift-storage --type merge --patch '{"spec":{"channel":"<update-channel>"}}' 1
- 1
<update-channel>
を、インストールする LVM Storage Operator のバージョン (stable-4.15
など) に置き換えます。
次のコマンドを実行して、アップグレードイベントを表示し、インストールが完了していることを確認します。
$ oc get events -n openshift-storage
出力例
... 8m13s Normal RequirementsUnknown clusterserviceversion/lvms-operator.v4.13 requirements not yet checked 8m11s Normal RequirementsNotMet clusterserviceversion/lvms-operator.v4.13 one or more requirements couldn't be found 7m50s Normal AllRequirementsMet clusterserviceversion/lvms-operator.v4.13 all requirements found, attempting install 7m50s Normal InstallSucceeded clusterserviceversion/lvms-operator.v4.13 waiting for install components to report healthy 7m49s Normal InstallWaiting clusterserviceversion/lvms-operator.v4.13 installing: waiting for deployment lvms-operator to become ready: deployment "lvms-operator" waiting for 1 outdated replica(s) to be terminated 7m39s Normal InstallSucceeded clusterserviceversion/lvms-operator.v4.13 install strategy completed with no errors ...
検証
次のコマンドを実行して、LVM Storage Operator のバージョンを確認します。
$ oc get subscription lvms-operator -n openshift-storage -o jsonpath='{.status.installedCSV}'
出力例
lvms-operator.v4.13
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 を停止しました。
手順
-
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-1
PVC と同じ 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 が
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. LVM Storage の監視
クラスターモニタリングを有効にするには、LVM Storage をインストールした namespace に次のラベルを追加する必要があります。
openshift.io/cluster-monitoring=true
RHACM でクラスターモニタリングを有効化する方法の詳細は、可観測性 と カスタムメトリクスの追加 を参照してください。
4.12.3.9.1. メトリクス
メトリクスを表示することで、LVM Storage を監視できます。
次の表は、topolvm
メトリクスを説明しています。
アラート | 説明 |
---|---|
| LVM シンプールで使用されているデータ領域の割合を示します。 |
| LVM シンプールで使用されているメタデータ領域の割合を示します。 |
| LVM シンプールのサイズをバイト単位で示します。 |
| LVM ボリュームグループ内の利用可能な領域をバイト単位で示します。 |
| LVM ボリュームグループのサイズをバイト単位で示します。 |
| LVM シンプールの利用可能なオーバープロビジョニングサイズをバイト単位で示します。 |
メトリクスは 10 分ごとに、または変更 (シンプールに新しい論理ボリュームが作成されるなど) があったときに更新されます。
4.12.3.9.2. アラート
シンプールとボリュームグループが最大ストレージ容量に達すると、それ以降の操作は失敗します。これにより、データ損失が発生する可能性があります。
LVM Storage は、シンプールとボリュームグループの使用量が特定の値を超えると、次のアラートを送信します。
アラート | 説明 |
---|---|
| このアラートは、ボリュームグループとシンプールの両方の使用量がノード上で 75% を超えるとトリガーされます。データの削除またはボリュームグループの拡張が必要です。 |
| このアラートは、ボリュームグループとシンプールの両方の使用量がノード上で 85% を超えるとトリガーされます。この場合、ボリュームグループは、かなりいっぱいになっています。データの削除またはボリュームグループの拡張が必要です。 |
| このアラートは、ボリュームグループ内のシンプールのデータ使用量がノード上で 75% を超えるとトリガーされます。データの削除またはシンプールの拡張が必要です。 |
| このアラートは、ボリュームグループ内のシンプールのデータ使用量がノード上で 85% を超えるとトリガーされます。データの削除またはシンプールの拡張が必要です。 |
| このアラートは、ボリュームグループ内のシンプールのメタデータ使用量がノード上で 75% を超えるとトリガーされます。データの削除またはシンプールの拡張が必要です。 |
| このアラートは、ボリュームグループ内のシンプールのメタデータ使用量がノード上で 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.13 --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 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.3.12. 永続ストレージのトラブルシューティング
論理ボリュームマネージャー (LVM) ストレージを使用して永続ストレージを設定するときに、トラブルシューティングが必要ないくつかの問題が発生する可能性があります。
4.12.3.12.1. 保留状態でスタックしている PVC を調査する
永続ボリューム要求 (PVC) は、次の理由により Pending
状態のままになることがあります。
- コンピューティングリソースが足りない
- ネットワークの問題
- ストレージクラスまたはノードセレクターが一致していない
- 利用可能な永続ボリューム (PV) がない
-
PV を持つノードが
Not Ready
状態にある
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとして OpenShift CLI (oc
) にログインしている。
手順
次のコマンドを実行して、PVC のリストを取得します。
$ oc get pvc
出力例
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE lvms-test Pending lvms-vg1 11s
次のコマンドを実行して、
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.3.12.2. ストレージクラスがない状態からの回復
storage class not found
というエラーが発生した場合は、LVMCluster
カスタムリソース (CR) をチェックし、すべての論理ボリュームマネージャー (LVM) ストレージ Pod が Running
状態であることを確認します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとして OpenShift CLI (oc
) にログインしている。
手順
以下のコマンドを実行して、
LVMCluster
CR が存在することを確認します。$ oc get lvmcluster -n openshift-storage
出力例
NAME AGE my-lvmcluster 65m
-
LVMCluster
CR が存在しない場合は、LVMCluster
CR を作成します。詳細は、シングルノード OpenShift ワーカーノードでの論理ボリュームマネージャークラスターの作成を参照してください。 openshift-storage
namespace で、次のコマンドを実行して、すべての LVM ストレージ Pod が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
このコマンドの出力には、以下の Pod の実行中のインスタンスが含まれている必要があります。
-
lvms-operator
-
vg-manager
-
topolvm-controller
topolvm-node
topolvm-node
Pod がInit
状態のままになっている場合は、LVM ストレージが使用できるディスクが見つからないことが原因です。この問題のトラブルシューティングに必要な情報を取得するには、以下のコマンドを実行してvg-manager
Pod のログを確認します。$ oc logs -l app.kubernetes.io/component=vg-manager -n openshift-storage
-
4.12.3.12.3. ノード障害からの回復
クラスター内のノード障害が原因で、永続ボリューム要求 (PVC) が Pending
状態のままになることがあります。
障害が発生したノードを特定するには、topolvm-node
Pod の再起動回数を調べることができます。再起動回数の増加は、基礎となるノードに潜在的な問題があることを示しており、さらなる調査とトラブルシューティングが必要になる場合があります。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとして OpenShift CLI (oc
) にログインしている。
手順
次のコマンドを実行して、
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.3.12.4. ディスク障害からの回復
永続ボリューム要求 (PVC) に関連するイベントの検査中にエラーメッセージが表示された場合は、基になるボリュームまたはディスクに問題がある可能性があります。
ディスクおよびボリュームのプロビジョニングの問題が発生すると、Failed to provision volume with storage class <storage_class_name>
などの一般的なエラーメッセージが表示されます。一般的なエラーメッセージの後には、特定のボリューム障害のエラーメッセージが続きます。
以下の表は、ボリューム障害のエラーメッセージを説明しています。
エラーメッセージ | 説明 |
---|---|
| ボリュームがすでに存在するかどうかを確認する際に問題が発生したことを示します。ボリューム検証の失敗は、ネットワーク接続の問題やその他の障害によって発生する可能性があります。 |
| 使用可能な永続ボリューム (PV) が PVC の要件と一致しない場合、ボリュームのバインドに失敗する可能性があります。 |
| このエラーは、ボリュームをノードにマウントしようとしたときに問題が発生したことを示します。ディスクに障害が発生した場合、Pod が PVC を使用しようとしたときにこのエラーが表示されることがあります。 |
| このエラーは、ノードからボリュームをアンマウントしようとしたときに問題が発生したことを示します。ディスクに障害が発生した場合、Pod が PVC を使用しようとしたときにこのエラーが表示されることがあります。 |
|
このエラーは、 |
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとして OpenShift CLI (oc
) にログインしている。
手順
次のコマンドを実行して、PVC に関連付けられたイベントを検査します。
$ oc describe pvc <pvc_name> 1
- 1
<pvc_name>
を PVC の名前に置き換えます。
- 問題が発生しているホストへの直接接続を確立します。
- ディスクの問題を解決します。
次のステップ
- ディスクの問題を解決した後もボリューム障害メッセージが続く場合や再発する場合は、強制クリーンアップを実行する必要があります。詳細は、「強制クリーンアップの実行」を参照してください。
関連情報
4.12.3.12.5. 強制クリーンアップの実行
トラブルシューティング手順を完了した後もディスクまたはノード関連の問題が解決しない場合は、強制クリーンアップを実行する必要があります。強制クリーンアップは、永続的な問題に対処し、論理ボリュームマネージャー (LVM) ストレージが確実に適切に機能するために使用されます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとして OpenShift CLI (oc
) にログインしている。 - LVM ストレージを使用して作成されたすべての永続ボリューム要求 (PVC) が削除されている。
- LVM ストレージを使用して作成された PVC を使用している Pod を停止している。
手順
次のコマンドを実行して、
openshift-storage
namespace に切り替えます。$ oc project openshift-storage
以下のコマンドを実行して、
LogicalVolume
カスタムリソース (CR) が存在するか確認します。$ oc get logicalvolume
以下のコマンドを実行して、
LVMVolumeGroup
CR が存在するか確認します。$ oc get lvmvolumegroup
以下のコマンドを実行して、
LVMVolumeGroupNodeStatus
CR を削除します。$ oc delete lvmvolumegroupnodestatus --all
次のコマンドを実行して、
LVMCluster
CR を削除します。$ oc delete lvmcluster --all
LVMCluster
CR を削除した後、以下のコマンドを実行してファイナライザーを削除します。$ oc patch lvmcluster <name> -p '{"metadata":{"finalizers":[]}}' --type=merge 1
- 1
<name>
をLVMCluster
CR の名前に置き換えます。