IBM Power Systems を使用した OpenShift Container Storage のデプロイ
IBM Power Systems 環境のインストールおよび設定方法
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ を参照してください。
Red Hat ドキュメントへのフィードバック (英語のみ)
弊社のドキュメントについてのご意見をお聞かせください。ドキュメントの改善点があれば、ぜひお知らせください。フィードバックをお寄せいただくには、以下をご確認ください。
特定の部分についての簡単なコメントをお寄せいただく場合は、以下をご確認ください。
- ドキュメントの表示が Multi-page HTML 形式になっていていることを確認してください。ドキュメントの右上隅に Feedback ボタンがあることを確認してください。
- マウスカーソルを使用して、コメントを追加するテキストの部分を強調表示します。
- 強調表示されたテキストの下に表示される Add Feedback ポップアップをクリックします。
- 表示される指示に従ってください。
より詳細なフィードバックをお寄せいただく場合は、Bugzilla のチケットを作成してください。
- Bugzilla の Web サイトに移動します。
- Component (コンポーネント) として Documentation を使用します。
- Description フィールドに、ドキュメントの改善に向けたご提案を記入してください。ドキュメントの該当部分へのリンクも追加してください。
- Submit Bug をクリックします。
はじめに
Red Hat OpenShift Container Storage 4.7 は、接続環境での既存の Red Hat OpenShift Container Platform (RHOCP) IBM Power クラスターへのデプロイメントをサポートし、プロキシー環境に対する追加設定なしのサポートを提供します。
IBM Power Systems では、内部の Openshift Container Storage クラスターのみがサポートされます。デプロイメントの要件についての詳細は、デプロイメントのプランニング を参照してください。
OpenShift Container Storage をデプロイするには、適切なデプロイメントプロセスを実行します。
内部接続デバイスモード
第1章 ローカルストレージデバイスを使用したデプロイメント
IBM Power Systems によって提供されるローカルストレージデバイスを使用して OpenShift Container Storage を OpenShift Container Platform にデプロイすると、内部クラスターリソースを作成することができます。この方法では、ベースサービスを内部でプロビジョニングします。その後、すべてのアプリケーションは追加のストレージクラスにアクセスできます。
IBM Power Systems では、内部の Openshift Container Storage クラスターのみがサポートされます。デプロイメントの要件についての詳細は、デプロイメントのプランニング を参照してください。
1.1. ローカルストレージデバイスを使用した OpenShift Container Storage のインストール要件
クラスターは、それぞれローカルに接続されたストレージデバイスを持つクラスターの 3 つ以上の OpenShift Container Platform ワーカーノードで設定される必要があります。
- 3 つのノードのそれぞれには、OpenShift Container Storage で使用できる raw ブロックデバイスが少なくとも 1 つ必要です。
- 使用するデバイスは空である必要があります。つまり、ディスクには永続ボリューム (PV)、ボリュームグループ (VG)、または論理ボリューム (LV) がない状態でなければなりません。
3 つ以上のラベルが付けられたノードが必要です。
OpenShift Container Storage によって使用されるローカルストレージデバイスを持つ各ノードには、OpenShift Container Storage Pod をデプロイするための特定のラベルが必要です。ノードにラベルを付けるには、以下のコマンドを使用します。
$ oc label nodes <NodeNames> cluster.ocs.openshift.io/openshift-storage=''
ノードの最小要件
プランニングガイドの リソース要件 のセクションを参照してください。
ローカルストレージデバイスのアップグレード要件
- OpenShift Container Platform 4.7 にアップグレードしてから OpenShift Container Storage 4.7 をデプロイする必要があります。詳細は、Updating OpenShift Container Platform clusters ガイドを参照してください。
- ローカルストレージ Operator が Red Hat OpenShift Container Storage で完全にサポートされるために、ローカルストレージ Operator のバージョンは Red Hat OpenShift Container Platform バージョンと一致する必要があります。ローカルストレージ Operator は、Red Hat OpenShift Container Platform のアップグレード時にアップグレードされません。
1.2. Red Hat OpenShift Container Storage Operator のインストール
Red Hat OpenShift Container Storage は、Red Hat OpenShift Container Platform Operator Hub を使用してインストールできます。ハードウェアおよびソフトウェアの要件に関する詳細は、 デプロイメントのプランニング を参照してください。
前提条件
- cluster-admin および Operator インストールのパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできること。
- RHOCP クラスターにワーカーノードが少なくとも 3 つ必要です。
OpenShift Container Storage のクラスター全体でのデフォルトノードセレクターを上書きする必要がある場合は、コマンドラインインターフェイスで以下のコマンドを使用し、openshift-storage namespace の空のノードセレクターを指定できます。
$ oc annotate namespace openshift-storage openshift.io/node-selector=
手順
OpenShift Web コンソールの左側のペインに移動し、Operators → OperatorHub をクリックします。
図1.1 Operator Hub の Operator 一覧

OpenShift Container Storage をクリックします。
Filter by keyword テキストボックスまたはフィルター一覧を使用して、Operator の一覧から OpenShift Container Storage を検索できます。
OpenShift Container Storage Operator ページで、Install をクリックします。
図1.2 Install Operator ページ

Install ボタンをクリックすると、以下のページが表示されます。

Install Operator ページで、以下のオプションがデフォルトで選択されていることを確認します。
- Channel を stable-4.7として更新します。
- Installation Mode オプションに A specific namespace on the cluster を選択します。
-
Installed Namespace に Operator recommended namespace openshift-storage を選択します。namespace
openshift-storageが存在しない場合、これは Operator のインストール時に作成されます。 - 承認ストラテジー を Automatic または Manual として選択します。
Install をクリックします。
Automatic (自動) 更新を選択している場合、Operator Lifecycle Manager (OLM) は人の介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。Manual (手動) 更新を選択している場合、OLM は更新要求を作成します。クラスター管理者は、Operator が新規バージョンに更新されるように更新要求を手動で承認する必要があります。
検証手順
- OpenShift Container Storage Operator に、インストールが正常に実行されたことを示す緑色のチェックマークが表示されていることを確認します。
View Installed Operators in namespace openshift-storage リンクをクリックし、OpenShift Container Storage Operator が Installed Operators ダッシュボードで Status を
Succeededとして表示していることを確認します。図1.3 Installed Operators ダッシュボード

1.3. ローカルストレージ Operator のインストール
以下の手順を使用して、ローカルストレージデバイスに OpenShift Container Storage クラスターを作成する前に、Operator Hub からローカルストレージ Operator をインストールします。
手順
- OpenShift Web コンソールの左側のペインで、Operators → OperatorHub をクリックします。
- Operator の一覧から Local Storage Operator を検索し、これをクリックします。
Install をクリックします。
図1.4 Install Operator ページ

Install ボタンをクリックすると、以下のページが表示されます。

Install Operator ページで、以下のオプションを設定します。
- Channel を stable-4.7として更新します。
- Installation Mode オプションに A specific namespace on the cluster を選択します。
- Installed Namespace に Operator recommended namespace openshift-local-storage を選択します。
- Approval Strategy に Automatic を選択します。
Install をクリックします。
図1.5 Installed Operators ダッシュボード

検証手順
-
Local Storage Operator のステータスが
Succeededと表示されていることを確認します。
1.4. IBM Power Systems での OpenShift Container Storage クラスターの作成
前提条件
- ローカルストレージデバイスを使用した OpenShift Container Storage のインストールの要件 についてのセクションにあるすべての要件を満たしていることを確認します。
- IBM Power Systems でローカルストレージデバイスを使用するために、同じストレージタイプおよびサイズが各ノードに接続された 3 つ以上のワーカーノードが必要です (例: 200 GB SSD)。
OpenShift Container Platform ワーカーノードに OpenShift Contaner Storage ラベルを付けられていることを確認します。
oc get nodes -l cluster.ocs.openshift.io/openshift-storage -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}'
手順
- OpenShift Web コンソールにログインします。
openshift-local-storagenamespace で、OpenShift Web コンソールの左ペインから Operators → Installed Operators をクリックして、インストールされている Operator を表示します。図1.6 Local Storage Operator ページ

- Local Storage のインストールされた Operator をクリックします。
Operator Details ページで、Local Volume Set リンクをクリックします。
図1.7 Local Volume Set タブ

Create Local Volume Set をクリックします。

- ボリュームセット名を入力します。デフォルトで、ストレージクラス名がボリュームセット名について表示されます。
利用可能なディスクを検出するには、以下のいずれかを選択できます。
- All nodes: すべてのノードでディスクを検出します。
Select nodes: ノードの一覧からノードのサブセットを選択します。
クラスターで特定のワーカーノードを見つけるには、Name または Label に基づいてノードをフィルターできます。Name を使用するとノード名で検索でき、Label を使用すると事前に定義されたラベルを選択して検索できます。
Disk type を選択します。以下のオプションが利用可能になります。
All
ノードに存在するすべての種類のディスクを選択します。デフォルトでは、このオプションは選択されます。
SSD/NVME
SSD NVME タイプのディスクのみを選択します。
HDD
HDD タイプのディスクのみを選択します。
Advanced セクションでは、以下を設定できます。
ボリュームモード
デフォルトでは Block (ブロック) が選択されます。
ディスクサイズ
含める必要のあるデバイスの最小および最大の許容サイズ。
注記追加で割り当てられたディスクのサイズに相当する最小のディスクサイズを選択します。
最大ディスク制限
これは、ノードで作成可能な PV の最大数を示します。このフィールドが空のままの場合、PV は一致するノードで利用可能なすべてのディスクに作成されます。
Create をクリックします。
Create ボタンは、最低でも 3 つのノードを選択した後にのみ有効になります。ローカルボリュームセットは、利用可能なディスクを持つワーカーノードごとに 1 つのボリュームで作成されます。
openshift-storagenamespace で、OpenShift Web コンソールの左ペインから Operators → Installed Operators をクリックして、インストールされている Operator を表示します。図1.8 OpenShift Container Storage Operator ページ

- OpenShift Container Storage インストール Operator をクリックします。
Operator Details ページで、Storage Cluster リンクをクリックします。
図1.9 Storage Cluster タブ

Create Storage Cluster をクリックします。

Select Mode に Internal-Attached devices を選択します。

- 必要なストレージクラスを選択します。
- ストレージクラスに対応するノードは、ドロップダウンで選択したストレージクラスに基づいて表示されます。
- Next をクリックします。
Next を再度クリックすると、Review and Create ページにリダイレクトされます。
設定の詳細を確認します。設定を変更するには、Back をクリックして直前の設定ページに戻ります。

- Create をクリックします。
検証手順
OpenShift Container Storage インストールの検証 について参照してください。
追加リソース
初期クラスターの容量を拡張するには、Scaling Storage ガイドを参照してください。
第2章 内部モードの OpenShift Container Storage デプロイメントの確認
このセクションを使用して、OpenShift Container Storage が正常にデプロイされていることを確認します。
2.1. Pod の状態の確認
OpenShift Container Storage が正常にデプロイされているかどうかを判別するために、Pod の状態が Running であることを確認できます。
手順
- OpenShift Web コンソールの左側のペインから Workloads → Pods をクリックします。
Project ドロップダウンリストから openshift-storage を選択します。
各コンポーネントについて予想される Pod 数や、これがノード数によってどのように異なるかについての詳細は、表2.1「OpenShift Container Storage クラスターに対応する Pod」 を参照してください。
Running および Completed タブをクリックして、以下の Pod が実行中および完了状態にあることを確認します。
表2.1 OpenShift Container Storage クラスターに対応する Pod
コンポーネント 対応する Pod OpenShift Container Storage Operator
-
ocs-operator-*(任意のワーカーノードに 1 Pod) -
ocs-metrics-exporter-*
Rook-ceph Operator
rook-ceph-operator-*(任意のワーカーノードに 1 Pod)Multicloud Object Gateway
-
noobaa-operator-*(任意のワーカーノードに 1 Pod) -
noobaa-core-*(任意のストレージノードに 1 Pod) -
nooba-db-*(任意のストレージノードに 1 Pod) -
noobaa-endpoint-*(任意のストレージノードに 1 Pod)
MON
rook-ceph-mon-*(各ストレージノードに 3 Pod)MGR
rook-ceph-mgr-*(任意のストレージノードに 1 Pod)MDS
rook-ceph-mds-ocs-storagecluster-cephfilesystem-*(ストレージノードに分散する 2 Pod)RGW
rook-ceph-rgw-ocs-storagecluster-cephobjectstore-*(任意のストレージノードに 1 Pod)CSI
cephfs-
csi-cephfsplugin-*(各ワーカーノードに 1 Pod) -
csi-cephfsplugin-provisioner-*(ストレージノードに分散する 2 Pod)
-
rbd-
csi-rbdplugin-*(各ワーカーノードに 1 Pod) -
csi-rbdplugin-provisioner-*(ストレージノードに分散する 2 Pod)
-
rook-ceph-crashcollector
rook-ceph-crashcollector-*(各ストレージノードに 1 Pod)OSD
-
rook-ceph-osd-*(各デバイス用に 1 Pod) -
rook-ceph-osd-prepare-ocs-deviceset-*(各デバイス用に 1 Pod)
-
2.2. OpenShift Container Storage クラスターが正常であることの確認
- OpenShift Web コンソールの左側のペインから Home → Overview をクリックし、Persistent Storage タブをクリックします。
Status カード で、以下のイメージのように OCS Cluster および Data Resiliency に緑色のチェックマークが表示されていることを確認します。
図2.1 Persistent Storage Overview ダッシュボードの Health status カード

Details カード で、以下のようにクラスター情報が表示されていることを確認します。
- サービス名
- OpenShift Container Storage
- クラスター名
- ocs-storagecluster-cephcluster
- プロバイダー
- なし
- モード
- 内部
- バージョン
- ocs-operator:v4.7.0
永続ストレージダッシュボードを使用して OpenShift Container Storage クラスターの正常性に関する詳細は、OpenShift Container Storage のモニターリング を参照してください。
2.3. OpenShift Container Storage 固有のストレージクラスが存在することの確認
ストレージクラスがクラスターに存在することを確認するには、以下を実行します。
- OpenShift Web コンソールの左側のペインから Storage → Storage Classes をクリックします。
以下のストレージクラスが OpenShift Container Storage クラスターの作成時に作成されることを確認します。
-
ocs-storagecluster-ceph-rbd -
ocs-storagecluster-cephfs -
openshift-storage.noobaa.io -
ocs-storagecluster-ceph-rgw
-
第3章 OpenShift Container Storage のアンインストール
3.1. 内部モードでの OpenShift Container Storage のアンインストール
このセクションの手順に従って OpenShift Container Storage をアンインストールします。
アノテーションのアンインストール
Storage Cluster のアノテーションは、アンインストールプロセスの動作を変更するために使用されます。アンインストールの動作を定義するために、ストレージクラスターに以下の 2 つのアノテーションが導入されました。
-
uninstall.ocs.openshift.io/cleanup-policy: delete -
uninstall.ocs.openshift.io/mode: graceful
以下の表は、これらのアノテーションで使用できる各種値に関する情報を示しています。
表3.1 uninstall.ocs.openshift.io でアノテーションの説明をアンインストールする
| Annotation | 値 | デフォルト | 動作 |
|---|---|---|---|
| cleanup-policy | delete | はい |
Rook は物理ドライブおよび |
| cleanup-policy | Retain | いいえ |
Rook は物理ドライブおよび |
| mode | graceful | はい | Rook および NooBaa は PVC および OBC が管理者/ユーザーによって削除されるまでアンインストールプロセスを一時停止します。 |
| mode | forced | いいえ | Rook および NooBaa は、Rook および NooBaa を使用してプロビジョニングされた PVC/OBC がそれぞれ存在している場合でもアンインストールを続行します。 |
以下のコマンドを使用してアノテーションの値を編集し、クリーンアップポリシーまたはアンインストールモードを変更できます。
$ oc -n openshift-storage annotate storagecluster ocs-storagecluster uninstall.ocs.openshift.io/cleanup-policy="retain" --overwrite storagecluster.ocs.openshift.io/ocs-storagecluster annotated
$ oc -n openshift-storage annotate storagecluster ocs-storagecluster uninstall.ocs.openshift.io/mode="forced" --overwrite storagecluster.ocs.openshift.io/ocs-storagecluster annotated
前提条件
- OpenShift Container Storage クラスターの状態が正常であることを確認します。リソースまたはノードの不足により一部の Pod が正常に終了されないと、アンインストールプロセスに失敗する可能性があります。クラスターの状態が正常でない場合は、OpenShift Container Storage をアンインストールする前に Red Hat カスタマーサポートにお問い合わせください。
- アプリケーションが OpenShift Container Storage によって提供されるストレージクラスを使用して Persistent Volume Claim(永続ボリューム要求、PVC) を使用していないことを確認します。
- カスタムリソース (カスタムストレージクラス、cephblockpools など) が管理者によって作成された場合には、それらを消費したリソースを削除してから、該当の管理者により削除される必要があります。
手順
OpenShift Container Storage を使用しているボリュームスナップショットを削除します。
すべての namespace からボリュームスナップショットを一覧表示します。
$ oc get volumesnapshot --all-namespaces
直前のコマンドの出力から、OpenShift Container Storage を使用しているボリュームスナップショットを特定し、削除します。
$ oc delete volumesnapshot <VOLUME-SNAPSHOT-NAME> -n <NAMESPACE>
OpenShift Container Storage を使用している PVC を削除します。
デフォルトのアンインストールモード (graceful) では、アンインストーラーは OpenShift Container Storage を使用するすべての PVC が削除されるまで待機します。
PVC を事前に削除せずに Storage Cluster を削除する場合は、アンインストールモードのアノテーションを forced に設定し、この手順を省略できます。これを実行すると、孤立した PVC がシステムに作成されます。
OpenShift Container Storage を使用して、OpenShift Container Platform モニターリングスタック PVC を削除します。
OpenShift Container Storage を使用して、OpenShift Container Platform レジストリー PVC を削除します。
「OpenShift Container Storage からの OpenShift Container Platform レジストリーの削除」 を参照
OpenShift Container Storage を使用して、OpenShift Container Platform ロギング PVC を削除します。
OpenShift Container Storage を使用してプロビジョニングした他の PVC を削除します。
以下に、OpenShift Container Storage を使用してプロビジョニングされる PVC を特定するサンプルスクリプトを示します。このスクリプトは、OpenShift Container Storage によって内部で使用される PVC を無視します。
#!/bin/bash RBD_PROVISIONER="openshift-storage.rbd.csi.ceph.com" CEPHFS_PROVISIONER="openshift-storage.cephfs.csi.ceph.com" NOOBAA_PROVISIONER="openshift-storage.noobaa.io/obc" RGW_PROVISIONER="openshift-storage.ceph.rook.io/bucket" NOOBAA_DB_PVC="noobaa-db" NOOBAA_BACKINGSTORE_PVC="noobaa-default-backing-store-noobaa-pvc" # Find all the OCS StorageClasses OCS_STORAGECLASSES=$(oc get storageclasses | grep -e "$RBD_PROVISIONER" -e "$CEPHFS_PROVISIONER" -e "$NOOBAA_PROVISIONER" -e "$RGW_PROVISIONER" | awk '{print $1}') # List PVCs in each of the StorageClasses for SC in $OCS_STORAGECLASSES do echo "======================================================================" echo "$SC StorageClass PVCs" echo "======================================================================" oc get pvc --all-namespaces --no-headers 2>/dev/null | grep $SC | grep -v -e "$NOOBAA_DB_PVC" -e "$NOOBAA_BACKINGSTORE_PVC" echo done注記クラウドプラットフォームの
RGW_PROVISIONERを省略します。PVC を削除します。
$ oc delete pvc <pvc name> -n <project-name>
注記クラスターに作成されているカスタムバッキングストア、バケットクラスなどを削除していることを確認します。
Storage Cluster オブジェクトを削除し、関連付けられたリソースが削除されるのを待機します。
$ oc delete -n openshift-storage storagecluster --all --wait=true
uninstall.ocs.openshift.io/cleanup-policyがdelete(default) に設定されている場合にクリーンアップ Pod の有無を確認し、それらのステータスがCompletedしていることを確認します。$ oc get pods -n openshift-storage | grep -i cleanup NAME READY STATUS RESTARTS AGE cluster-cleanup-job-<xx> 0/1 Completed 0 8m35s cluster-cleanup-job-<yy> 0/1 Completed 0 8m35s cluster-cleanup-job-<zz> 0/1 Completed 0 8m35s
/var/lib/rookディレクトリーが空であることを確認します。このディレクトリーは空になるのは、uninstall.ocs.openshift.io/cleanup-policyアノテーションがdelete(デフォルト) に設定されている場合に限られます。$ for i in $(oc get node -l cluster.ocs.openshift.io/openshift-storage= -o jsonpath='{ .items[*].metadata.name }'); do oc debug node/${i} -- chroot /host ls -l /var/lib/rook; done暗号化がインストール時に有効にされている場合は、すべての OpenShift Container Storage ノードの OSD デバイスから
dm-cryptで管理されるdevice-mapperマッピングを削除します。デバッグPod を作成し、ストレージノードのホストに対してchrootを作成します。$ oc debug node/<node name> $ chroot /host
デバイス名を取得し、OpenShift Container Storage デバイスについてメモします。
$ dmsetup ls ocs-deviceset-0-data-0-57snx-block-dmcrypt (253:1)
マップ済みデバイスを削除します。
$ cryptsetup luksClose --debug --verbose ocs-deviceset-0-data-0-57snx-block-dmcrypt
注記権限が十分にないため、コマンドがスタックした場合には、以下のコマンドを実行します。
-
CTRL+Zを押して上記のコマンドを終了します。 スタックしたプロセスの PID を検索します。
$ ps -ef | grep crypt
killコマンドを使用してプロセスを終了します。$ kill -9 <PID>
デバイス名が削除されていることを確認します。
$ dmsetup ls
-
namespace を削除し、削除が完了するまで待機します。
openshift-storageがアクティブなプロジェクトである場合は、別のプロジェクトに切り替える必要があります。以下に例を示します。
$ oc project default $ oc delete project openshift-storage --wait=true --timeout=5m
以下のコマンドが
NotFoundエラーを返すと、プロジェクトが削除されます。$ oc get project openshift-storage
注記OpenShift Container Storage のアンインストール時に、
namespaceが完全に削除されず、Terminating状態のままである場合は、トラブルシューティングおよびアンインストール時の残りのリソースの削除 の記事に記載の手順を実行して namespace の終了をブロックしているオブジェクトを特定します。- ローカルストレージデバイスを使用して OpenShift Container Storage をデプロイした場合には、ローカルのストレージ Operator 設定を削除します。ローカルストレージ Operator の設定の削除 を参照してください。
ストレージノードのラベルを解除します。
$ oc label nodes --all cluster.ocs.openshift.io/openshift-storage- $ oc label nodes --all topology.rook.io/rack-
ノードにテイントのマークが付けられている場合に OpenShift Container Storage テイントを削除します。
$ oc adm taint nodes --all node.ocs.openshift.io/storage-
OpenShift Container Storage を使用してプロビジョニングした PV がすべて削除されていることを確認します。
Released状態のままの PV がある場合は、これを削除します。$ oc get pv $ oc delete pv <pv name>
Multicloud Object Gateway storageclass を削除します。
$ oc delete storageclass openshift-storage.noobaa.io --wait=true --timeout=5m
CustomResourceDefinitionsを削除します。$ oc delete crd backingstores.noobaa.io bucketclasses.noobaa.io cephblockpools.ceph.rook.io cephclusters.ceph.rook.io cephfilesystems.ceph.rook.io cephnfses.ceph.rook.io cephobjectstores.ceph.rook.io cephobjectstoreusers.ceph.rook.io noobaas.noobaa.io ocsinitializations.ocs.openshift.io storageclusters.ocs.openshift.io cephclients.ceph.rook.io cephobjectrealms.ceph.rook.io cephobjectzonegroups.ceph.rook.io cephobjectzones.ceph.rook.io cephrbdmirrors.ceph.rook.io --wait=true --timeout=5m
OpenShift Container Platform Web コンソールで、OpenShift Container Storage が完全にアンインストールされていることを確認するには、以下を実行します。
- Home → Overview をクリックし、ダッシュボードにアクセスします。
- Persistent Storage タブが Cluster タブの横に表示されなくなることを確認します。
3.1.1. ローカルストレージ Operator の設定の削除
ローカルストレージデバイスを使用して OpenShift Container Storage をデプロイした場合にのみ、本セクションの手順を使用します。
OpenShift Container Storage デプロイメントで localvolume リソースのみを使用する場合は、直接、手順 8 に移動します。
手順
-
LocalVolumeSetおよび OpenShift Container Storage で使用される対応するStorageClassNameを特定します。 LocalVolumeSetを提供するStorageClassに変数 SC を設定します。$ export SC="<StorageClassName>"
LocalVolumeSetを削除します。$ oc delete localvolumesets.local.storage.openshift.io <name-of-volumeset> -n openshift-local-storage
指定された
StorageClassNameのローカルストレージ PV を削除します。$ oc get pv | grep $SC | awk '{print $1}'| xargs oc delete pvStorageClassNameを削除します。$ oc delete sc $SC
LocalVolumeSetによって作成されるシンボリックリンクを削除します。[[ ! -z $SC ]] && for i in $(oc get node -l cluster.ocs.openshift.io/openshift-storage= -o jsonpath='{ .items[*].metadata.name }'); do oc debug node/${i} -- chroot /host rm -rfv /mnt/local-storage/${SC}/; doneLocalVolumeDiscoveryを削除します。$ oc delete localvolumediscovery.local.storage.openshift.io/auto-discover-devices -n openshift-local-storage
LocalVolumeリソースを削除します (ある場合)。以下の手順を使用して、現行または直前の OpenShift Container Storage バージョンで PV のプロビジョニングに使用した
LocalVolumeリソースを削除します。また、これらのリソースがクラスターの他のテナントで使用されていないことを確認します。ローカルボリュームごとに、以下を実行します。
-
LocalVolumeおよび OpenShift Container Storage で使用される対応するStorageClassNameを特定します。 変数 LV を LocalVolume の名前に設定し、変数 SC を StorageClass の名前に設定します。
以下に例を示します。
$ LV=local-block $ SC=localblock
ローカルボリュームリソースを削除します。
$ oc delete localvolume -n local-storage --wait=true $LV
残りの PV および StorageClass が存在する場合はこれらを削除します。
$ oc delete pv -l storage.openshift.com/local-volume-owner-name=${LV} --wait --timeout=5m $ oc delete storageclass $SC --wait --timeout=5mそのリソースのストレージノードからアーティファクトをクリーンアップします。
$ [[ ! -z $SC ]] && for i in $(oc get node -l cluster.ocs.openshift.io/openshift-storage= -o jsonpath='{ .items[*].metadata.name }'); do oc debug node/${i} -- chroot /host rm -rfv /mnt/local-storage/${SC}/; done出力例:
Starting pod/node-xxx-debug ... To use host binaries, run `chroot /host` removed '/mnt/local-storage/localblock/nvme2n1' removed directory '/mnt/local-storage/localblock' Removing debug pod ... Starting pod/node-yyy-debug ... To use host binaries, run `chroot /host` removed '/mnt/local-storage/localblock/nvme2n1' removed directory '/mnt/local-storage/localblock' Removing debug pod ... Starting pod/node-zzz-debug ... To use host binaries, run `chroot /host` removed '/mnt/local-storage/localblock/nvme2n1' removed directory '/mnt/local-storage/localblock' Removing debug pod ...
-
3.2. OpenShift Container Storage からのモニターリングスタックの削除
このセクションでは、モニターリングスタックを OpenShift Container Storage からクリーンアップします。
モニターリングスタックの設定の一部として作成される PVC は openshift-monitoring namespace に置かれます。
前提条件
PVC は OpenShift Container Platform モニタリングスタックを使用できるように設定されます。
詳細は、モニターリングスタックの設定 を参照してください。
手順
openshift-monitoringnamespace で現在実行されている Pod および PVC を一覧表示します。$ oc get pod,pvc -n openshift-monitoring NAME READY STATUS RESTARTS AGE pod/alertmanager-main-0 3/3 Running 0 8d pod/alertmanager-main-1 3/3 Running 0 8d pod/alertmanager-main-2 3/3 Running 0 8d pod/cluster-monitoring- operator-84457656d-pkrxm 1/1 Running 0 8d pod/grafana-79ccf6689f-2ll28 2/2 Running 0 8d pod/kube-state-metrics- 7d86fb966-rvd9w 3/3 Running 0 8d pod/node-exporter-25894 2/2 Running 0 8d pod/node-exporter-4dsd7 2/2 Running 0 8d pod/node-exporter-6p4zc 2/2 Running 0 8d pod/node-exporter-jbjvg 2/2 Running 0 8d pod/node-exporter-jj4t5 2/2 Running 0 6d18h pod/node-exporter-k856s 2/2 Running 0 6d18h pod/node-exporter-rf8gn 2/2 Running 0 8d pod/node-exporter-rmb5m 2/2 Running 0 6d18h pod/node-exporter-zj7kx 2/2 Running 0 8d pod/openshift-state-metrics- 59dbd4f654-4clng 3/3 Running 0 8d pod/prometheus-adapter- 5df5865596-k8dzn 1/1 Running 0 7d23h pod/prometheus-adapter- 5df5865596-n2gj9 1/1 Running 0 7d23h pod/prometheus-k8s-0 6/6 Running 1 8d pod/prometheus-k8s-1 6/6 Running 1 8d pod/prometheus-operator- 55cfb858c9-c4zd9 1/1 Running 0 6d21h pod/telemeter-client- 78fc8fc97d-2rgfp 3/3 Running 0 8d NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-0 Bound pvc-0d519c4f-15a5-11ea-baa0-026d231574aa 40Gi RWO ocs-storagecluster-ceph-rbd 8d persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-1 Bound pvc-0d5a9825-15a5-11ea-baa0-026d231574aa 40Gi RWO ocs-storagecluster-ceph-rbd 8d persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-2 Bound pvc-0d6413dc-15a5-11ea-baa0-026d231574aa 40Gi RWO ocs-storagecluster-ceph-rbd 8d persistentvolumeclaim/my-prometheus-claim-prometheus-k8s-0 Bound pvc-0b7c19b0-15a5-11ea-baa0-026d231574aa 40Gi RWO ocs-storagecluster-ceph-rbd 8d persistentvolumeclaim/my-prometheus-claim-prometheus-k8s-1 Bound pvc-0b8aed3f-15a5-11ea-baa0-026d231574aa 40Gi RWO ocs-storagecluster-ceph-rbd 8d
モニタリング
configmapを編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
以下の例が示すように、OpenShift Container Storage ストレージクラスを参照する
configセクションを削除し、これを保存します。編集前
. . . apiVersion: v1 data: config.yaml: | alertmanagerMain: volumeClaimTemplate: metadata: name: my-alertmanager-claim spec: resources: requests: storage: 40Gi storageClassName: ocs-storagecluster-ceph-rbd prometheusK8s: volumeClaimTemplate: metadata: name: my-prometheus-claim spec: resources: requests: storage: 40Gi storageClassName: ocs-storagecluster-ceph-rbd kind: ConfigMap metadata: creationTimestamp: "2019-12-02T07:47:29Z" name: cluster-monitoring-config namespace: openshift-monitoring resourceVersion: "22110" selfLink: /api/v1/namespaces/openshift-monitoring/configmaps/cluster-monitoring-config uid: fd6d988b-14d7-11ea-84ff-066035b9efa8 . . .編集後
. . . apiVersion: v1 data: config.yaml: | kind: ConfigMap metadata: creationTimestamp: "2019-11-21T13:07:05Z" name: cluster-monitoring-config namespace: openshift-monitoring resourceVersion: "404352" selfLink: /api/v1/namespaces/openshift-monitoring/configmaps/cluster-monitoring-config uid: d12c796a-0c5f-11ea-9832-063cd735b81c . . .
この例では、
alertmanagerMainおよびprometheusK8sモニターリングコンポーネントは OpenShift Container Storage PVC を使用しています。関連する PVC を削除します。ストレージクラスを使用するすべての PVC を削除してください。
$ oc delete -n openshift-monitoring pvc <pvc-name> --wait=true --timeout=5m
3.3. OpenShift Container Storage からの OpenShift Container Platform レジストリーの削除
このセクションを使用して、OpenShift Container Storage から OpenShift Container Platform レジストリーをクリーンアップします。代替ストレージを設定する必要がある場合は、イメージレジストリー を参照してください。
OpenShift Container Platform レジストリーの設定の一部として作成される PVC は openshift-image-registry namespace に置かれます。
前提条件
- イメージレジストリーは OpenShift Container Storage PVC を使用するように設定されている必要があります。
手順
configs.imageregistry.operator.openshift.ioオブジェクトを編集し、storage セクションのコンテンツを削除します。$ oc edit configs.imageregistry.operator.openshift.io
編集前
. . . storage: pvc: claim: registry-cephfs-rwx-pvc . . .編集後
. . . storage: emptyDir: {} . . .この例では、PVC は
registry-cephfs-rwx-pvcと呼ばれ、これは安全に削除できます。PVC を削除します。
$ oc delete pvc <pvc-name> -n openshift-image-registry --wait=true --timeout=5m
3.4. OpenShift Container Storage からのクラスターロギング Operator の削除
このセクションでは、クラスターロギング Operator を OpenShift Container Storage からクリーンアップします。
クラスターロギング Operator の設定の一部として作成される PVC は openshift-logging namespace にあります。
前提条件
- クラスターロギングインスタンスは、OpenShift Container Storage PVC を使用するように設定されている必要があります。
手順
namespace の
ClusterLoggingインスタンスを削除します。$ oc delete clusterlogging instance -n openshift-logging --wait=true --timeout=5m
openshift-loggingnamespace の PVC は安全に削除できます。PVC を削除します。
$ oc delete pvc <pvc-name> -n openshift-logging --wait=true --timeout=5m