IBM Power Systems を使用した OpenShift Container Storage のデプロイおよび管理
インストールおよび管理方法
概要
はじめに
Red Hat OpenShift Container Storage 4.6 では、既存の Red Hat OpenShift Container Platform (RHOCP) IBM Power クラスターでのデプロイメントをサポートします。
IBM Power Systems では、内部の Openshift Container Storage クラスターのみがサポートされます。デプロイメントの要件についての詳細は、デプロイメントのプランニング を参照してください。
OpenShift Container Storage をデプロイするには、適切なデプロイメントプロセスを実行します。
内部モード
第1章 デプロイメントのプランニング
1.1. Red Hat OpenShift Container Storage の概要
Red Hat OpenShift Container Storage は、Red Hat OpenShift Container Platform のクラウドストレージおよびデータサービスの集合です。これは、単純なデプロイメントおよび管理を容易に実行するために Operator としてパッケージ化され、Red Hat OpenShift Container Platform サービスカタログの一部として利用できます。
Red Hat OpenShift Container Storage サービスは、主に以下のコンポーネントを表すストレージクラスを使用してアプリケーションで使用できます。
- ブロックストレージデバイス。主にデータベースのワークロードに対応します。主な例には、Red Hat OpenShift Container Platform のロギングおよびモニタリング、および PostgreSQL などがあります。
- 共有および分散ファイルシステム。主にソフトウェア開発、メッセージング、およびデータ集約のワークロードに対応します。これらの例には、Jenkins ビルドソースおよびアーティファクト、Wordpress のアップロードコンテンツ、Red Hat OpenShift Container Platform レジストリー、および JBoss AMQ を使用したメッセージングが含まれます。
- Multicloud オブジェクトストレージ。複数のクラウドオブジェクトストアからのデータの保存および取得を抽象化できる軽量 S3 API エンドポイントを特長としています。
- オンプレミスオブジェクトストレージ。主にデータ集約型アプリケーションをターゲットとする数十ペタバイトおよび数十億のオブジェクトにスケーリングする堅牢な S3 API エンドポイントを特長としています。これらの例には、Spark、Presto、Red Hat AMQ Streams (Kafka) などのアプリケーションや、TensorFlow や Pytorch などのマシンラーニングフレームワークを使用した行、列、および半構造化データの保存およびアクセスが含まれます。
IBM Power Systems の OpenShift Container Storage 4.6 は、オブジェクトストレージではなく、ブロックおよびファイルストレージのみをサポートします。
Red Hat OpenShift Container Storage バージョン 4.x は、以下を含むソフトウェアプロジェクトのコレクションを統合します。
- Ceph。ブロックストレージ、共有および分散ファイルシステム、およびオンプレミスのオブジェクトストレージを提供します。
- Ceph CSI。永続ボリュームおよび要求のプロビジョニングおよびライフサイクルを管理します。
- NooBaa。Multicloud Object Gateway を提供します。
- OpenShift Container Storage、Rook-Ceph、および NooBaa Operator。OpenShift Container Storage サービスを初期化し、管理します。
1.2. OpenShift Container Storage のアーキテクチャー
Red Hat OpenShift Container Storage は、Red Hat OpenShift Container Platform のサービスを提供し、Red Hat OpenShift Container Platform から内部で実行できます。
Red Hat OpenShift Container Storage アーキテクチャー
Red Hat OpenShift Container Storage は、インストーラーでプロビジョニングされるインフラストラクチャー、またはユーザーによってプロビジョニングされるインフラストラクチャー でデプロイされる Red Hat OpenShift Container Platform クラスターへのデプロイメントをサポートします。これら 2 つの方法については、OpenShift Container Platform のインストールプロセス について参照してください。
OpenShift Container Platform のアーキテクチャーおよびライフサイクルについての詳細は、OpenShift Container Platform アーキテクチャー を参照してください。
1.2.1. Operator
Red Hat OpenShift Container Storage は主に 3 つの Operator で設定されており、管理タスクとカスタムリソースをコード化し、タスクおよびリソースの特性をより簡単に自動化できるようにします。管理者はクラスターの必要な最終状態を定義し、OpenShift Container Storage Operator は管理者の介入を最小限に抑えてクラスターをその状態にするか、またはその状態に近づけるようにします。
OpenShift Container Storage Operator
他の Operator を特定のテストされた方法で利用してサポートされている Red Hat OpenShift Container Storage デプロイメントの推奨事項および要件を定め、実施するメタ Operator。この Operator は、Rook-Ceph および NooBaa Operator によって提供されるリソースをラップするストレージクラスターリソースを提供します。
Rook-Ceph Operator
この Operator は、永続ストレージおよびファイル、ブロックおよびオブジェクトサービスのパッケージ化、デプロイメント、管理、アップグレード、およびスケーリングを自動化します。これは、すべての環境用にブロックおよびファイルストレージクラスを作成し、オンプレミス環境でオブジェクトストレージクラスおよびサービスオブジェクトバケット要求を作成します。
さらに、内部モードクラスターの場合、以下を表すデプロイメントおよびサービスを管理する Ceph クラスターリソースを提供します。
- オブジェクトストレージデーモン (OSD)
- モニター (MON)
- マネージャー (MGR)
- メタデータサーバー (MDS)
- オブジェクトゲートウェイ (RGW): オンプレミスの場合のみ
NooBaa Operator
この Operator は、Multicloud Object Gateway オブジェクトサービスのパッケージ化、デプロイメント、管理、アップグレード、およびスケーリングを自動化します。これは、オブジェクトストレージクラスおよびサービスオブジェクトバケット要求を作成します。
さらに、これは NooBaa クラスターリソースを提供します。このクラスターリソースは、NooBaa コア、データベースおよびエンドポイントのデプロイメントとサービスを管理します。
1.2.2. ストレージクラスターのデプロイメントアプローチ
柔軟性は、複数モード (operating modalities) 一覧の拡張によって確認されるように Red Hat OpenShift Container Storage の中心的な特徴です。このセクションでは、OpenShift Container Platform での OpenShift Container Storage のデプロイメントを理解するのに役立つ情報を提供します。
Red Hat OpenShift Container Storage を Red Hat OpenShift Container Platform 内に完全にデプロイすると、Operator ベースのデプロイメントおよび管理によるすべての利点が得られます。Red Hat OpenShift Container Storage が完全に Red Hat OpenShift Container Platform 内で実行されている場合、以下の 2 つのデプロイメントモードを使用できます。
- Simple (単純)
- Optimized (最適化)
Simple (単純) デプロイメント
Red Hat OpenShift Container Storage サービスは、Red Hat OpenShift Container Platform の Operator によって管理されるアプリケーションと共存する形で実行されます。
Simple (単純) デプロイメントは、以下の状況で最適です。
- ストレージ要件が明確ではない。
- OpenShift Container Storage サービスは、アプリケーションと共存する形で実行される。
- 特定サイズのノードインスタンスの作成が容易ではない (ベアメタル)。
Red Hat OpenShift Container Storage がアプリケーションと共存する形で実行されるには、ローカルストレージデバイスまたはポータブルストレージデバイスがそれらに動的に接続される必要があります。たとえば、PowerVC により動的にプロビジョニングされる SAN ボリューム。
Optimized (最適化) デプロイメント
OpenShift Container Storage サービスは、Red Hat OpenShift Container Platform で管理される専用のインフラストラクチャーノードで実行されます。
最適化アプローチは、以下の場合に最も適しています。
- ストレージ要件が明確である
- OpenShift Container Storage サービスを専用のインフラストラクチャーノードで実行する
- 特定サイズのノードインスタンスの作成が容易である (クラウド、仮想化環境など)
1.2.3. ノードのタイプ
ノードはコンテナーランタイムとサービスを実行し、コンテナーが実行中の状態にし、Pod 間のネットワーク通信および分離を保ちます。OpenShift Container Storage には、3 種類のノードがあります。
表1.1 ノードの種類
ノードタイプ | 説明 |
---|---|
マスター | これらのノードは、Kubernetes API を公開し、新たに作成された Pod を監視およびスケジュールし、ノードの正常性および数量を維持し、基礎となるクラウドプロバイダーとの対話を制御するプロセスを実行します。 |
インフラストラクチャー (インフラ) | インフラストラクチャーノードは、ロギング、メトリクス、レジストリー、およびルーティングなどのクラスターレベルのインフラストラクチャーサービスを実行します。これらは OpenShift Container Platform クラスターでオプションになります。仮想化環境およびクラウド環境で OpenShift Container Storage 用に infra ノードを使用することが推奨されます。
|
ワーカー | ワーカーノードは、アプリケーションを実行するため、アプリケーションノードとしても知られています。 OpenShift Container Storage が内部モードでデプロイされる場合、3 つのワーカーノードで設定される最小クラスターが必要になります。ここで、可用性を確保するためにノードは 3 つの別々のラックまたはアベイラビリティーゾーンに分散することを推奨します。OpenShift Container Storage がワーカーノードで実行されるようにするには、ローカルストレージデバイスまたはポータブルストレージデバイスのいずれかがそれらに動的に接続される必要があります。 外部モードでデプロイされると、複数のノードで実行され、障害の発生時に利用可能なノードでの K8S による再スケジュールが可能になります。 ポータブルストレージデバイスの例には、EC2 の EBS ボリューム、または VMware の vSphere Virtual Volume があります。 |
ストレージワークロードのみを実行するノードには、Red Hat OpenShift Container Storage のサブスクリプションが必要です。ストレージワークロードに加えて他のワークロードを実行するノードには、Red Hat OpenShift Container Storage および Red Hat OpenShift Container Platform サブスクリプションの両方が必要です。詳細は、「サブスクリプション」 を参照してください。
1.3. セキュリティーに関する考慮事項
1.3.1. データ暗号化オプション
暗号化により、データをエンコードおよび難読化し、データが盗まれる場合に理解できないようにすることができます。Red Hat OpenShift Container Storage 4.6 は、ストレージクラスター内のすべてのディスクの保存データの暗号化 (at-rest encryption) のサポートを提供します。つまり、データはディスクに書き込まれる際に暗号化され、ディスクから読み取られる際に復号化されます。
OpenShift Container Storage 4.6 は、キーサイズが 512 ビットおよび aes-xts-plain64
暗号を使用して、Linux Unified Key System (LUKS) バージョン 2 ベースの暗号化を使用します。各デバイスには、Kubernetes シークレットとして保管される異なる暗号化キーが含まれます。
クラスターのデプロイメント時に、クラスター全体の暗号化を有効または無効にできます。これはデフォルトでは無効にされます。暗号化されたデータを使用すると、パフォーマンスに極めて小規模なペナルティーしか発生しません。
データの暗号化は、OpenShift Container Storage 4.6 を使用してデプロイされる新規クラスターでのみサポートされます。これは、バージョン 4.6 にアップグレードされた既存のクラスターではサポートされません。
1.4. サブスクリプション
1.4.1. サブスクリプションのオファリング
Red Hat OpenShift Container Storage のサブスクリプションは、OpenShift Container Platform と同様にコアのペアをベースとして提供されます。Red Hat OpenShift Container Storage 2 コアサブスクリプションは、OpenShift Container Platform が実行されるシステムの CPU 上の論理コア数をベースとしています。
以下の点は、OpenShift Container Platform と同様です。
- OpenShift Container Storage サブスクリプションは、大規模なホストに対応するようにスタック可能です。
- コアは、必要に応じて多数の仮想マシン (VM) に分散できます。たとえば、SMT レベル 8 の 2 コアのサブスクリプションの場合、任意の数の仮想マシンで使用できる 2 コアまたは 16 vCPU が提供されます。
- OpenShift Container Storage サブスクリプションは、Premium または Standard サポートで利用できます。
1.4.2. 障害復旧サブスクリプション
Red Hat OpenShift Container Storage は、障害復旧 (DR)、コールドバックアップその他のサブスクリプションタイプを提供しません。OpenShift Container Storage がインストールされたシステムでは、電源がオン/オフであるか、ワークロードを実行中かどうかにかかわらず、アクティブなサブスクリプションが必要になります。
1.4.3. コア対 vCPU および同時マルチスレッド (SMT)
現時点で特定のシステムが 1 つまたは複数のコアを消費するかどうかについての決定は、同時マルチスレッド (SMT) のレベルによって異なります。IBM Power システムは、同時マルチスレッドの 1、2、4、または 8 のレベルを提供します。
SMT が設定されるシステムでは、コアの計算は SMT のレベルによって異なります。したがって、2 コアサブスクリプションでは、SMT のレベル 1 では 2 vCPU、SMT のレベル 2 では 4 vCPU、SMT のレベル 4 では 8 vCPU、および SMT のレベル 8 では 16 の vCPU になります。大規模な仮想マシン (VM) には 16 の vCPU が含まれる場合などがありますが、2 サブスクリプションコアの SMT のレベル 8 に相当します。サブスクリプションは 2 コア単位で提供されるため、これらの 2 コアまたは 16 vCPU に対応するには 1 つの 2 コアサブスクリプションが必要になります。
1.4.4. 共用プロセッサープール
IBM Power Systems には、共用プロセッサープールの概念があります。共用プロセッサープール内のプロセッサーは、クラスター内のノード間で共有できます。OpenShift Container Storage に必要な集約コンピュート容量はコアのペアの倍数である必要があります。
1.4.5. サブスクリプションの要件
OpenShift Container Storage コンポーネントは、Red Hat CoreOS (RHCOS) または Red Hat Enterprise Linux (RHEL) 7 のいずれかをホストのオペレーティングシステムとして使用できる OpenShift Container Platform ワーカーまたはインフラストラクチャーノードのいずれかで実行できます。ワーカーノードが OpenShift Container Storage コンポーネントに使用される場合、それらのノードには OpenShift Container Platform と OpenShift Container Storage の両方のサブスクリプションが必要です。インフラストラクチャーノードが使用される場合、それらのノードには OpenShift Container Storage サブスクリプションのみが必要となります。ラベルは、ノードをワーカーノードまたはインフラストラクチャーノードとみなすべきかどうかを示すために使用されます。リソースの管理および割り当て ガイドの Red Hat OpenShift Container Storage の専用ワーカーノードの使用方法 を参照してください。
1.5. インフラストラクチャーの要件
1.5.1. プラットフォーム要件
Red Hat OpenShift Container Storage は、OpenShift Container Storage バージョンより 1 マイナーリリース前または先の OpenShift Container Platform リリースと組み合わせることができます。
OpenShift Container Storage 4.6 は以下で実行できます。
- OpenShift Container Platform 4.5 (1 バージョン前)(内部モードの場合のみ)
- OpenShift Container Platform 4.6 (同じバージョン)
サポートされているプラットフォームのバージョンについての詳細の一覧は、Red Hat OpenShift Container Storage and Red Hat OpenShift Container Platform interoperability matrix を参照してください。
Red Hat OpenShift Container Platform のアップグレード時に、ローカルストレージ Operator が Red Hat OpenShift Container Storage Storage と完全にサポートされるように、ローカルストレージ Operator のバージョンをアップグレードして Red Hat OpenShift Container Platform バージョンと一致させる必要があります。
1.5.1.1. IBM Power Systems [テクノロジープレビュー]
内部 Red Hat Openshift Container Storage クラスターのみをサポートします。
内部クラスターは、ストレージデバイスの要件 を満たし、ローカルストレージ Operator 経由でローカル SSD を提供するストレージクラスがなければなりません。
1.5.2. リソース要件
OpenShift Container Storage サービスは、ベースサービスの初期セットとこれに続く追加のデバイスセットで設定されます。これらの OpenShift Container Storage サービス Pod はすべて OpenShift Container Platform ノードの kubernetes によってスケジュールされます。
表1.2 最小リソース要件の集約
デプロイメントモード | ベースサービス |
---|---|
内部 |
|
外部 |
|
例: 内部接続デバイスモードのデプロイメントの 3 ノードクラスターの場合、最小の 3 x 16 = 48 ユニットの CPU、および 3 x 64 = 192 GB が必要です。
1.5.3. Pod の配置ルール
Kubernetes は、宣言型の配置ルールに基づいて Pod の配置を行います。内部クラスターの OpenShift Container Storage ベースサービスの配置ルールは、以下のように要約できます。
-
ノードには
cluster.ocs.openshift.io/openshift-storage
キーでラベルが付けられます。 - ノードは、擬似障害ドメインに分類されます (何も存在しない場合)。
- 高可用性が必要なコンポーネントは障害ドメインに分散されます。
- ストレージデバイスはそれぞれの障害ドメインでアクセスできる必要があります。
これにより、少なくとも 3 つのノードがあり、既存の トポロジーラベル が存在する場合にノードは 3 つの異なるラックまたはゾーン障害ドメインにある必要があります。
追加のデバイスセットについては、3 つの障害ドメインのそれぞれにストレージデバイスがあり、Pod が消費するのに十分なリソースが必要になります。手動の配置ルールはデフォルトの配置ルールを上書きするのに使用できますが、通常この方法はベアメタルのデプロイメントにのみ適しています。
1.5.4. ストレージデバイスの要件
このセクションでは、IBM Power Systems でのデプロイメントおよびアップグレードの計画時に考慮できる各種のストレージ容量の要件について説明します。
ローカルストレージデバイス
ローカルストレージのデプロイメントの場合、4 TiB 以下のディスクサイズを使用でき、すべてのディスクが同じサイズおよび種類である必要があります。ノードごとに実行できるローカルストレージデバイスの数は、ノードのサイズと リソース要件 の関数です。クラスターを (障害ドメインごとに 1 ノードの)3 の倍数に拡張する方法は、Pod 配置ルール に従うための簡単な方法です。
ディスクのパーティション設定はサポートされません。
容量のプランニング
使用する前に、利用可能なストレージ容量を必ず確保するようにしてください。利用可能なストレージ容量が完全に使い切られる場合はリカバリーが難しく、単に容量を追加したり、コンテンツを削除したり、移行したりするよりも多くの介入が必要になります。
容量アラートは、クラスターストレージ容量が合計容量の 75% (ほぼ一杯) および 85% (一杯) になると発行されます。容量についての警告に常に迅速に対応し、ストレージを定期的に確認して、ストレージ領域が不足しないようにします。ストレージ領域が不足する場合は、Red Hat カスタマーポータル にお問い合わせください。
以下の表は、動的なストレージデバイスを持つ Red Hat OpenShift Container Storage のノードの設定例を示しています。
表1.3 3 つのノードで設定される初期設定の例
ストレージデバイスのサイズ | ノードあたりのストレージデバイス | 合計容量 | 利用可能なストレージ容量 |
---|---|---|---|
0.5 TiB | 1 | 1.5 TiB | 0.5 TiB |
2 TiB | 1 | 6 TiB | 2 TiB |
4 TiB | 1 | 12 TiB | 4 TiB |
表1.4 30 ノード (N) で拡張された設定の例
ストレージデバイスのサイズ (D) | ノードごとのストレージデバイス (M) | 合計容量 (D * M * N) | 使用可能なストレージ容量 (D*M*N/3) |
---|---|---|---|
0.5 TiB | 3 | 45 TiB | 15 TiB |
2 TiB | 6 | 360 TiB | 120 TiB |
4 TiB | 9 | 1080 TiB | 360 TiB |
IBM Power Systems への OpenShift Container Storage のデプロイを開始するには、デプロイメントガイドを使用できます。
第2章 ローカルストレージデバイスを使用したデプロイメント
IBM Power Systems によって提供されるローカルストレージデバイスを使用して OpenShift Container Storage を OpenShift Container Platform にデプロイすると、内部クラスターリソースを作成することができます。これにより、ベースサービスの内部プロビジョニングが可能になり、追加のストレージクラスをアプリケーションで使用可能にすることができます。
IBM Power Systems では、内部の Openshift Container Storage クラスターのみがサポートされます。デプロイメントの要件についての詳細は、デプロイメントのプランニング を参照してください。
2.1. ローカルストレージデバイスを使用した OpenShift Container Storage のインストール要件
- OpenShift Container Platform 4.6 にアップグレードしてから OpenShift Container Storage 4.6 をデプロイする必要があります。詳細は、Updating OpenShift Container Platform clusters ガイドを参照してください。
- ローカルストレージ Operator が Red Hat OpenShift Container Storage で完全にサポートされるために、ローカルストレージ Operator のバージョンは Red Hat OpenShift Container Platform バージョンと一致する必要があります。ローカルストレージ Operator は、Red Hat OpenShift Container Platform のアップグレード時にアップグレードされません。
クラスターに、それぞれローカルに接続されたストレージデバイスを持つ OpenShift Container Platform ワーカーノードを 3 つ以上設定する必要があります。
- 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=''
2.2. Red Hat OpenShift Container Storage Operator のインストール
Red Hat OpenShift Container Storage は、Red Hat OpenShift Container Platform Operator Hub を使用してインストールできます。ハードウェアおよびソフトウェアの要件に関する詳細は、 デプロイメントのプランニング を参照してください。
前提条件
- OpenShift Container Platform (RHOCP) クラスターにログインしている必要があります。
- RHOCP クラスターにワーカーノードが少なくとも 3 つ必要です。
OpenShift Container Storage のクラスター全体でのデフォルトノードセレクターを上書きする必要がある場合は、コマンドラインインターフェイスで以下のコマンドを使用し、openshift-storage
namespace の空のノードセレクターを指定できます。
$ oc annotate namespace openshift-storage openshift.io/node-selector=
手順
OpenShift Web コンソールの左側のペインで、Operators → OperatorHub をクリックします。
図2.1 Operator Hub の Operator 一覧
OpenShift Container Storage をクリックします。
Filter by keyword テキストボックスまたはフィルター一覧を使用して、Operator の一覧から OpenShift Container Storage を検索できます。
OpenShift Container Storage Operator ページで、Install をクリックします。
図2.2 Install Operator ページ
Install ボタンをクリックすると、以下のページが表示されます。
Install Operator ページで、以下のオプションが選択されていることを確認します。
- Channel を stable-4.6として更新します。
- Installation Mode オプションに A specific namespace on the cluster を選択します。
-
Installed Namespace に Operator recommended namespace PR openshift-storage を選択します。namespace
openshift-storage
が存在しない場合、これは Operator のインストール時に作成されます。 - Enable operator recommended cluster monitoring on this namespace が選択されていることを確認します。これはクラスターのモニターリングに必要です。
- Approval Strategy に Automatic を選択します。
Install をクリックします。
図2.3 Installed Operators ダッシュボード
検証手順
- OpenShift Container Storage Operator の Status が Installed Operators ダッシュボードで Succeeded と表示されることを確認します。
2.3. ローカルストレージ Operator のインストール
以下の手順を使用して、OpenShift Container Storage クラスターをローカルストレージデバイスに作成する前に Operator Hub からローカルストレージ Operator をインストールします。
前提条件
次のように、
openshift-local-storage
という名前の namespace を作成します。- OpenShift Web コンソールの左側のペインで、Administration → Namespaces をクリックします。
- Create Namespace をクリックします。
-
Create Namespace ダイアログボックスで、Name に
openshift-local-storage
と入力します。 - Default Network Policy に No restrictions オプションを選択します。
- Create をクリックします。
手順
- OpenShift Web コンソールの左側のペインで、Operators → OperatorHub をクリックします。
- Operator の一覧から Local Storage Operator を検索し、これをクリックします。
Install をクリックします。
図2.4 Install Operator ページ
Install ボタンをクリックすると、以下のページが表示されます。
Install Operator ページで、以下のオプションが選択されていることを確認します。
- Channel を stable-4.6として更新します。
- Installation Mode オプションに A specific namespace on the cluster を選択します。
- Installed Namespace を openshift-local-storage に選択します。
- Approval Strategy に Automatic を選択します。
Install をクリックします。
図2.5 Installed Operators ダッシュボード
検証手順
-
Local Storage Operator のステータスが
Succeeded
と表示されていることを確認します。
2.4. 利用可能なストレージデバイスの検索
以下の手順を使用して、IBM Power Systems 用に PV を作成する前に、OpenShift Container Storage ラベル cluster.ocs.openshift.io/openshift-storage=''
でラベルを付けた 3 つ以上のワーカーノードのそれぞれのデバイス名を特定します。
手順
OpenShift Container Storage ラベルの付いたワーカーノードの名前の一覧を表示し、確認します。
$ oc get nodes -l cluster.ocs.openshift.io/openshift-storage=
出力例:
NAME STATUS ROLES AGE VERSION worker-0 Ready worker 39h v1.18.3+2cf11e2 worker-1 Ready worker 39h v1.18.3+2cf11e2 Worker-2 Ready worker 39h v1.18.3+2cf11e2
OpenShift Container Storage リソース、および利用可能な各 raw ブロックデバイスについて接続された追加ストレージのあるディスクに使用される各ワーカーノードにログインします。
$ oc debug node/<Nodename>
出力例:
$ oc debug node/worker-0 Starting pod/worker-0-debug ... To use host binaries, run `chroot /host` Pod IP: 192.168.88.11 If you don't see a command prompt, try pressing enter. sh-4.2# chroot /host sh-4.4# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 256GG 0 loop vda 252:0 0 40G 0 disk |-vda1 252:1 0 4M 0 part |-vda2 252:2 0 384M 0 part /boot `-vda4 252:4 0 39.6G 0 part `-coreos-luks-root-nocrypt 253:0 0 39.6G 0 dm /sysroot vdb 252:16 0 512B 1 disk vdc 252:32 0 256G 0 disk
この例では、worker-0 の利用可能なローカルデバイスは
vdc
です。- OpenShift Container Storage で使用されるストレージデバイスを持つその他のすべてのワーカーノードについてこの手順を繰り返します。詳細は、ナレッジベースアーティクル を参照してください。
2.5. IBM Power Systems での OpenShift Container Storage クラスターの作成
前提条件
- ローカルストレージデバイスを使用した OpenShift Container Storage のインストールの要件 についてのセクションにあるすべての要件を満たしていることを確認します。
- IBM Power Systems でローカルストレージデバイスを使用するために、同じストレージタイプおよびサイズが各ノードに接続された 3 つのワーカーノードが必要です (例: 200 GB)。
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-storage
namespace で、OpenShift Web コンソールの左ペインから Operators → Installed Operators をクリックして、インストールされている Operator を表示します。図2.6 Local Storage Operator ページ
- Local Storage のインストールされた Operator をクリックします。
Operator Details ページで、Local Volume Set リンクをクリックします。
図2.7 Local Volume Set タブ
Create Local Volume Set をクリックします。
- ボリュームセット名を入力します。デフォルトで、ストレージクラス名がボリュームセット名について表示されます。
利用可能なディスクを検出するには、以下のいずれかを選択できます。
- All nodes: すべてのノードでディスクを検出します。
- Select nodes: ノードの一覧からノードのサブセットを選択します。
- Disk type を選択します。
- Advanced オプションで、Disk モードに Block を選択し、追加で接続されたディスクのサイズに相当する最小のディスクサイズ、最大のディスクサイズを選択し、最大のディスク制限を設定できます。
Create をクリックします。
Create ボタンは、最低でも 3 つのノードを選択した後にのみ有効になります。ローカルボリュームセットは、利用可能なディスクを持つワーカーノードごとに 1 つのボリュームで作成されます。
openshift-storage
namespace で、OpenShift Web コンソールの左ペインから Operators → Installed Operators をクリックして、インストールされている Operator を表示します。図2.8 OpenShift Container Storage Operator ページ
- OpenShift Container Storage インストール Operator をクリックします。
Operator Details ページで、Storage Cluster リンクをクリックします。
図2.9 Storage Cluster タブ
Create Storage Cluster をクリックします。
- Select Mode に Internal-Attached devices を選択します。
- 必要なストレージクラスを選択します。
- 要件に応じて、ストレージクラスターのデータ暗号化を有効または無効にします。
- ストレージクラスに対応するノードは、ドロップダウンで選択したストレージクラスに基づいて表示されます。
Create をクリックします。
Create ボタンは、最低でも 3 つのノードを選択した後にのみ有効になります。3 つのボリュームからなる新規ストレージクラスターは、1 ワーカーノードごとに 1 つのボリュームを設定して作成されます。デフォルト設定では、レプリケーション係数 3 を使用します。
検証手順
Verifying your OpenShift Container Storage installation を参照してください。
第3章 内部モードの OpenShift Container Storage デプロイメントの確認
このセクションを使用して、OpenShift Container Storage が正常にデプロイされていることを確認します。
3.1. Pod の状態の確認
OpenShift Container Storage が正常にデプロイされているかどうかを判別するために、Pod の状態が Running
であることを確認できます。
手順
- OpenShift Web コンソールの左側のペインから Workloads → Pods をクリックします。
Project ドロップダウンリストから openshift-storage を選択します。
各コンポーネントについて予想される Pod 数や、これがノード数によってどのように異なるかについての詳細は、表3.1「OpenShift Container Storage クラスターに対応する Pod」 を参照してください。
注記OpenShift Container Storage のクラスター全体でのデフォルトノードセレクターを上書きする必要がある場合は、コマンドラインインターフェイスで以下の手順を実行できます。
openshift-storage
namespace の空のノードセレクターを指定します。$ oc annotate namespace openshift-storage openshift.io/node-selector=
DaemonSets
によって生成される元の Pod を削除します。oc delete pod -l app=csi-cephfsplugin -n openshift-storage oc delete pod -l app=csi-rbdplugin -n openshift-storage
Running および Completed タブをクリックして、以下の Pod が実行中および完了状態にあることを確認します。
表3.1 OpenShift Container Storage クラスターに対応する Pod
コンポーネント 対応する Pod OpenShift Container Storage Operator
ocs-operator-*
(任意のワーカーノードに 1 Pod)
Rook-ceph Operator
rook-ceph-operator-*
(任意のワーカーノードに 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-*
(ストレージノードに分散する 2 Pod)CSI
cephfs
-
csi-cephfsplugin-*
(各ワーカーノードに 1 Pod) -
csi-cephfsplugin-provisioner-*
(ストレージノードに分散する 2 Pod)
-
rbd
-
csi-rbdplugin-*
(各ワーカーノードに 1 Pod) -
csi-rbdplugin-provisioner-*
(ストレージノードに分散する 2 Pod)
-
rook-ceph-drain-canary
rook-ceph-drain-canary-*
(各ストレージノードに 1 Pod)
rook-ceph-crashcollector
rook-ceph-crashcollector-*
(各ストレージノードに 1 Pod)
OSD
-
rook-ceph-osd-*
(各デバイス用に 1 Pod) -
rook-ceph-osd-prepare-ocs-deviceset-*
(各デバイス用に 1 Pod)
3.2. OpenShift Container Storage クラスターが正常であることの確認
- OpenShift Web コンソールの左側のペインから Home → Overview をクリックし、Persistent Storage タブをクリックします。
Status カード で、以下のイメージのように OCS Cluster および Data Resiliency に緑色のチェックマークが表示されていることを確認します。
図3.1 Persistent Storage Overview ダッシュボードの Health status カード
Details カード で、以下のようにクラスター情報が表示されていることを確認します。
- サービス名
- OpenShift Container Storage
- クラスター名
- ocs-storagecluster-cephcluster
- プロバイダー
- なし
- モード
- 内部
- バージョン
- ocs-operator:v4.6.0
永続ストレージダッシュボードを使用して OpenShift Container Storage クラスターの正常性に関する詳細は、OpenShift Container Storage のモニターリング を参照してください。
3.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
-
第4章 OpenShift Container Storage のアンインストール
4.1. 内部モードでの OpenShift Container Storage のアンインストール
このセクションの手順に従って OpenShift Container Storage をアンインストールします。
アノテーションのアンインストール
Storage Cluster のアノテーションは、アンインストールプロセスの動作を変更するために使用されます。アンインストールの動作を定義するために、ストレージクラスターに以下の 2 つのアノテーションが導入されました。
-
uninstall.ocs.openshift.io/cleanup-policy: delete
-
uninstall.ocs.openshift.io/mode: graceful
以下の表は、これらのアノテーションで使用できる各種値に関する情報を示しています。
表4.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 annotate storagecluster ocs-storagecluster uninstall.ocs.openshift.io/cleanup-policy="retain" --overwrite storagecluster.ocs.openshift.io/ocs-storagecluster annotated
$ oc 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
を押して上記のコマンドを終了します。 スタックした
cryptsetup
プロセスの PID を検索します。$ ps
出力例:
PID TTY TIME CMD 778825 ? 00:00:00 cryptsetup
PID
番号を書き留めて強制終了します。この例では、PID
は778825
です。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
状態のままである場合は、Troubleshooting and deleting remaining resources during Uninstall の記事に記載の手順を実行して 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 storageclusterinitializations.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 タブの横に表示されなくなることを確認します。
4.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 pv
StorageClassName
を削除します。$ 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}/; done
LocalVolumeDiscovery
を削除します。$ 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 ...
-
4.2. OpenShift Container Storage からのモニターリングスタックの削除
このセクションでは、モニターリングスタックを OpenShift Container Storage からクリーンアップします。
モニターリングスタックの設定の一部として作成される PVC は openshift-monitoring
namespace に置かれます。
前提条件
PVC は OpenShift Container Platform モニタリングスタックを使用できるように設定されます。
詳細は、モニターリングスタックの設定 を参照してください。
手順
openshift-monitoring
namespace で現在実行されている 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
4.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
4.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-logging
namespace の PVC は安全に削除できます。PVC を削除します。
$ oc delete pvc <pvc-name> -n openshift-logging --wait=true --timeout=5m
第5章 ストレージノードのスケーリング
OpenShift Container Storage のストレージ容量を内部モードでスケーリングするには、以下のいずれかを実行できます。
- ストレージノードのスケールアップ: 既存の Red Hat OpenShift Container Storage ワーカーノードに対してストレージ容量を追加します。
- ストレージノードのスケールアウト: ストレージ容量を含む新規ワーカーノードを追加します。
5.1. ストレージノードのスケーリングの要件
ストレージノードをスケーリングする前に、以下のセクションを参照して、特定の Red Hat OpenShift Container Storage インスタンスのノード要件を把握してください。
- プラットフォーム要件
ストレージデバイスの要件
常にストレージ容量が十分にあることを確認してください。
ストレージが完全に一杯になると、容量を追加したり、ストレージからコンテンツを削除したり、コンテンツを移動して領域を解放することはできません。完全なストレージを復元することは非常に困難です。
容量アラートは、クラスターストレージ容量が合計容量の 75% (ほぼ一杯) および 85% (一杯) になると発行されます。容量についての警告に常に迅速に対応し、ストレージを定期的に確認して、ストレージ領域が不足しないようにします。
ストレージ領域が不足する場合は、Red Hat カスタマーポータルにお問い合わせください。
5.2. ローカルストレージデバイスを使用した OpenShift Container Storage ノードへの容量の追加によるストレージのスケールアップ
以下の手順を使用して、IBM Power Systems インフラストラクチャーで設定されたローカルストレージベースの OpenShift Container Storage ワーカーノードにストレージ容量 (追加のストレージデバイス) を追加します。
前提条件
- OpenShift Container Platform (RHOCP) クラスターにログインしている必要があります。
ローカルストレージ Operator がインストールされている必要があります。次の手順を使用します。以下を参照してください。
- 3 つの OpenShift Container Platform ワーカーノードが必要です。それらのノードには、元の OpenShift Container Storage の StorageCluster の作成に使用されたものと同じストレージタイプおよびサイズ (例: 0.5TB SSD) が割り当てられている必要があります。
手順
OpenShift Container Storage がインストールされている OpenShift Container Platform ノードにストレージ容量を追加するには、以下を実行する必要があります。
ワーカーノードごとに少なくとも 1 つのデバイスを追加するため、利用可能なデバイスを見つけます。各デプロイメントガイドで説明されている利用可能なストレージデバイスを検索する手順に従ってください。
注記このプロセスを、ストレージを追加する既存ノードのすべて (3 ノード以上) に対して実行するようにしてください。
ノード内で lsblk を実行して、新規ディスクがノードに追加されたかどうかを確認します。
$ oc debug node/worker-0 $lsblk
出力例:
Creating debug namespace/openshift-debug-node-ggrqr ... Starting pod/worker-2-debug ... To use host binaries, run `chroot /host` Pod IP: 192.168.88.23 If you don't see a command prompt, try pressing enter. sh-4.4# chroot /host sh-4.4# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 256G 0 loop vda 252:0 0 40G 0 disk |-vda1 252:1 0 4M 0 part |-vda2 252:2 0 384M 0 part /boot `-vda4 252:4 0 39.6G 0 part `-coreos-luks-root-nocrypt 253:0 0 39.6G 0 dm /sysroot vdb 252:16 0 512B 1 disk vdc 252:32 0 256G 0 disk vdd 252:48 0 256G 0 disk sh-4.4# sh-4.4# Removing debug pod ... Removing debug namespace/openshift-debug-node-ggrqr ...
- 新規に追加されたディスクは LocalVolumeSet によって自動的に検出されます。
新規に作成された PV を
localVolumeSet
CR で使用されるstorageclass
名前で表示します。$ oc get pv | grep localblock | grep Available
出力例:
local-pv-290020c2 256Gi RWO Delete Available localblock 2m35s local-pv-7702952c 256Gi RWO Delete Available localblock 2m27s local-pv-a7a567d 256Gi RWO Delete Available localblock 2m22s ...
新しい OSD に使用されるサイズと同じサイズの 3 つの PV が利用可能です。
- OpenShift Web コンソールに移動します。
- 左側のナビゲーションバーの Operators をクリックします。
- Installed Operators を選択します。
ウィンドウで、OpenShift Container Storage Operator をクリックします。
上部のナビゲーションバーで、右にスクロールし、Storage Cluster タブをクリックします。
- 表示されるリストには 1 つの項目のみが含まれます。右端の (⋮) をクリックして、オプションメニューを拡張します。
オプションメニューから Add Capacity を選択します。
このダイアログボックスで、Storage Class 名を
localVolumeset
CR で使用される名前に設定します。表示される利用可能な容量は、ストレージクラスで利用可能なローカルディスクをベースとしています。- 設定が終了したら、Add をクリックします。ストレージクラスターが Ready 状態になるまでに数分待機する必要がある場合があります。
3 つの新規 OSD およびそれらの対応する新規 PVC が作成されていることを確認します。
$ oc get -n openshift-storage pods -l app=rook-ceph-osd
出力例:
NAME READY STATUS RESTARTS AGE rook-ceph-osd-0-6f8655ff7b-gj226 1/1 Running 0 1h rook-ceph-osd-1-6c66d77f65-cfgfq 1/1 Running 0 1h rook-ceph-osd-2-69f6b4c597-mtsdv 1/1 Running 0 1h rook-ceph-osd-3-c784bdbd4-w4cmj 1/1 Running 0 5m rook-ceph-osd-4-6d99845f5b-k7f8n 1/1 Running 0 5m rook-ceph-osd-5-fdd9897c9-r9mgb 1/1 Running 0 5m
上記の例では、osd-3、osd-4、および osd-5 は、新たに OpenShift Container Storage クラスターに追加される Pod です。
$ oc get pvc -n openshift-storage |grep localblock
出力例:
ocs-deviceset-localblock-0-data-0-sfsgf Bound local-pv-8137c873 256Gi RWO localblock 1h ocs-deviceset-localblock-0-data-1-qhs9m Bound local-pv-290020c2 256Gi RWO localblock 10m ocs-deviceset-localblock-1-data-0-499r2 Bound local-pv-ec7f2b80 256Gi RWO localblock 1h ocs-deviceset-localblock-1-data-1-p9rth Bound local-pv-a7a567d 256Gi RWO localblock 10m ocs-deviceset-localblock-2-data-0-8pzjr Bound local-pv-1e31f771 256Gi RWO localblock 1h ocs-deviceset-localblock-2-data-1-7zwwn Bound local-pv-7702952c 256Gi RWO localblock 10m
上記の例では、3 つの新規 PVC が作成されています。
検証手順
Overview → Persistent Storage タブに移動してから、Capacity breakdown カードをチェックします。
容量は選択に応じて増大することに注意してください。
重要OpenShift Container Storage では、OSD またはノードの縮小によるクラスターの削減はサポートしていません。
5.3. ストレージ容量のスケールアウト
ストレージ容量をスケールアウトするには、以下の手順を実行する必要があります。
- 新規ノードを追加します。
- 新規ノードが正常に追加されたことを確認します。
- ストレージ容量をスケールアップします。
5.3.1. ノードの追加
既存のワーカーノードがサポートされる最大 OSD (初期設定で選択される容量の 3 OSD の増分) で実行されている場合には、ストレージの容量を増やすためにノードを追加できます。
IBM Power Systems のストレージノードを追加するには、「ローカルストレージデバイスを使用したノードの追加」 を参照してください。
5.3.1.1. ローカルストレージデバイスを使用したノードの追加
前提条件
- OpenShift Container Platform (RHOCP) クラスターにログインしている必要があります。
- 3 つの OpenShift Container Platform ワーカーノードが必要です。それらのノードには、元の OpenShift Container Storage の StorageCluster の作成に使用されたものと同じストレージタイプおよびサイズ (例: 2 TB SSD) が割り当てられている必要があります。
手順
以下の手順を実行します。
- 必要なインフラストラクチャーで新規の IBM Power マシンを取得します。プラットフォーム要件 を参照してください。
- 新規 IBM Power マシンを使用して新規 OpenShift Container Platform ノードを作成します。
Pending
状態の OpenShift Container Storage に関連する証明書署名要求 (CSR) の有無を確認します。$ oc get csr
新規ノードに必要なすべての OpenShift Container Storage CSR を承認します。
$ oc adm certificate approve <Certificate_Name>
- Compute → Nodes をクリックし、新規ノードが Ready 状態にあることを確認します。
以下のいずれかを使用して、OpenShift Container Storage ラベルを新規ノードに適用します。
- ユーザーインターフェイスを使用する場合
- 新規ノードについて、Action Menu (⋮) → Edit Labels をクリックします。
-
cluster.ocs.openshift.io/openshift-storage
を追加し、Save をクリックします。
- コマンドラインインターフェイスの使用
以下のコマンドを実行して、OpenS+hift Container Storage ラベルを新規ノードに適用します。
$ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""
OpenShift Web コンソールから、Operators → Installed Operators をクリックします。
Project ドロップダウンリストから、ローカルストレージ Operator がインストールされているプロジェクトを選択してください。
- Local Storage をクリックします。
- Local Volume Sets タブをクリックします。
-
LocalVolumeSet
の横にある Action メニュー (⋮) → Edit Local Volume Set をクリックします。 YAML で、
node selector
の下にあるvalues
フィールドに新規ノードのホスト名を追加します。図5.1 新規ホスト名の追加に関する YAML
- Save をクリックします。
異なるゾーンのそれぞれに 3 つのノードを追加することが推奨されます。3 つのノードを追加して、それらすべてのノードに対してこの手順を実行する必要があります。
検証手順
- 新規ノードが追加されていることを確認するには、 新規ノードの追加の確認 について参照してください。
5.3.2. 新規ノードの追加の確認
以下のコマンドを実行して、出力で新規ノードが表示されていることを確認します。
$ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1
Workloads → Pods をクリックし、新規ノード上の少なくとも以下の Pod が Running 状態にあることを確認します。
-
csi-cephfsplugin-*
-
csi-rbdplugin-*
-
5.4. ストレージ容量のスケールアップ
ストレージの容量をスケールアップするには、容量の増加によるストレージのスケールアップ について参照してください。
第6章 ノードの置き換え
OpenShift Container Storage 4.3 では、ノード置き換えを、IBM Power Systems 関連のデプロイメントで動作するノードについてプロアクティブに実行し、失敗したノードのそれぞれについてリアクティブに実行することができます。
6.1. IBM Power Systems で動作するストレージまたは障害のあるストレージノードの置き換え
前提条件
- Red Hat では、交換前のノードと同様のインフラストラクチャーおよびリソースで、交換後のノードを設定することを推奨します。
- OpenShift Container Platform (RHOCP) クラスターにログインしている必要があります。
手順
障害が発生したノードのラベルを確認し、ラックラベルをメモします。
$ oc get nodes --show-labels | grep failed-node-name
障害のあるノードで実行されている mon(ある場合) およびオブジェクトストレージデバイス (OSD) Pod を特定します。
$ oc get pods -n openshift-storage -o wide | grep -i failed-node-name
先の手順で特定された Pod のデプロイメントをスケールダウンします。
以下に例を示します。
$ oc scale deployment rook-ceph-mon-a --replicas=0 -n openshift-storage $ oc scale deployment rook-ceph-osd-1 --replicas=0 -n openshift-storage $ oc scale deployment --selector=app=rook-ceph-crashcollector,node_name=failed-node-name --replicas=0 -n openshift-storage
障害のあるノードにマークを付けて、これがスケジュールされないようにします。
$ oc adm cordon failed-node-name
既存の機能から障害のあるノードをドレイン (解放) します。
$ oc adm drain failed-node-name --force --delete-local-data --ignore-daemonsets
注記障害が発生したノードがネットワークに接続されていない場合には、以下のコマンドを使用してそのノードで実行されている Pod を削除します。
$ oc get pods -A -o wide | grep -i failed-node-name | awk '{if ($4 == "Terminating") system ("oc -n " $1 " delete pods " $2 " --grace-period=0 " " --force ")}' $ oc adm drain failed-node-name --force --delete-local-data --ignore-daemonsets
障害のあるノードを削除します。
$ oc delete node failed-node-name
- 必要なインフラストラクチャーで新規の IBM Power マシンを取得します。クラスターの IBM Power Systems へのインストール について参照してください。
- 新規 IBM Power Systems マシンを使用して新規 OpenShift Container Platform Systems ノードを作成します。
Pending
状態の OpenShift Container Storage に関連する証明書署名要求 (CSR) の有無を確認します。$ oc get csr
新規ノードに必要なすべての OpenShift Container Storage CSR を承認します。
$ oc adm certificate approve certificate-name
- OpenShift Web コンソールで Compute → Nodes をクリックし、新規ノードが Ready 状態にあることを確認します。
優先するインターフェイスを使用して、OpenShift Container Storage ラベルを新規ノードに適用します。
OpenShift Web コンソールの使用
- 新規ノードについて、Action Menu (⋮) → Edit Labels をクリックします。
-
cluster.ocs.openshift.io/openshift-storage
を追加し、Save をクリックします。
コマンドラインインターフェイスの使用
以下のコマンドを実行して、OpenS+hift Container Storage ラベルを新規ノードに適用します。
$ oc label node new-node-name cluster.ocs.openshift.io/openshift-storage=""
これらのワーカーノードで利用可能なローカルストレージデバイスを OpenShift Container Storage StorageCluster に追加します。
編集する
localVolumeSet
を決定します。以下のコマンドの local-storage-project は、ローカルストレージプロジェクトの名前に置き換えます。デフォルトのプロジェクト名は、OpenShift Container Storage 4.6 以降の
openshift-local-storage
です。以前のバージョンでは、デフォルトでlocal-storage
を使用します。# oc get -n local-storage-project localvolumeset NAME AGE localblock 25h
localVolumeSet
定義を更新して、新規ノードを追加し、障害が発生したノードを削除します。# oc edit -n local-storage-project localvolumeset localblock [...] nodeSelector: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: #- worker-0 - worker-1 - worker-2 - worker-3 [...]
エディターを終了する前に必ず保存します。
新規
localblock
PV が利用可能であることを確認します。$ oc get pv | grep localblock NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS AGE local-pv-3e8964d3 500Gi RWO Delete Bound ocs-deviceset-localblock-2-data-0-mdbg9 localblock 25h local-pv-414755e0 500Gi RWO Delete Bound ocs-deviceset-localblock-1-data-0-4cslf localblock 25h local-pv-b481410 500Gi RWO Delete Available localblock 3m24s local-pv-5c9b8982 500Gi RWO Delete Bound ocs-deviceset-localblock-0-data-0-g2mmc localblock 25h
openshift-storage
プロジェクトを変更します。$ oc project openshift-storage
失敗した OSD をクラスターから削除します。必要に応じて、複数の障害のある OSD を指定することができます。
PVC を特定します。後に、その特定の PVC に関連付けられた PV を削除する必要があるためです。
# osd_id_to_remove=1 # oc get -n openshift-storage -o yaml deployment rook-ceph-osd-${osd_id_to_remove} | grep ceph.rook.io/pvc
ここで、
osd_id_to_remove
はrook-ceph-osd
接頭辞の直後にくる Pod 名の整数です。この例では、デプロイメント名はrook-ceph-osd-1
です。出力例:
ceph.rook.io/pvc: ocs-deviceset-localblock-0-data-0-g2mmc ceph.rook.io/pvc: ocs-deviceset-localblock-0-data-0-g2mmc
この例では、PVC 名は
ocs-deviceset-localblock-0-data-0-g2mmc
です。失敗した OSD をクラスターから削除します。
# oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=${osd_id_to_remove},{osd_id_to_remove2} | oc create -f -
ocs-osd-removal
Pod のステータスをチェックして、OSD が正常に削除されたことを確認します。Completed
のステータスで、OSD の削除ジョブが正常に完了したことを確認します。# oc get pod -l job-name=ocs-osd-removal-${osd_id_to_remove} -n openshift-storage
注記ocs-osd-removal
が失敗し、Pod が予想されるCompleted
の状態にない場合、追加のデバッグのために Pod ログを確認します。以下に例を示します。# oc logs -l job-name=ocs-osd-removal-${osd_id_to_remove} -n openshift-storage --tail=-1
障害のあるノードに関連付けられた PV を削除します。
PVC に関連付けられた PV を特定します。
# oc get -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix>
ここで、
x
、y
、およびpvc-suffix
は、直前の手順で特定されたDeviceSet
の値です。以下に例を示します。
# oc get -n openshift-storage pvc ocs-deviceset-localblock-0-data-0-g2mmc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE ocs-deviceset-localblock-0-data-0-g2mmc Bound local-pv-5c9b8982 500Gi RWO localblock 24h
この例では、関連付けられた PV は
local-pv-5c9b8982
です。PV を削除します。
# oc delete pv <persistent-volume>
以下に例を示します。
# oc delete pv local-pv-5c9b8982 persistentvolume "local-pv-5c9b8982" deleted
crashcollector
Pod デプロイメントを削除します。$ oc delete deployment --selector=app=rook-ceph-crashcollector,node_name=failed-node-name -n openshift-storage
rook-ceph-operator
を再起動して Operator の調整を強制的に実行して新規 OSD をデプロイします。# oc get -n openshift-storage pod -l app=rook-ceph-operator
出力例:
NAME READY STATUS RESTARTS AGE rook-ceph-operator-77758ddc74-dlwn2 1/1 Running 0 1d20h
rook-ceph-operator
を削除します。# oc delete -n openshift-storage pod rook-ceph-operator-77758ddc74-dlwn2
出力例:
pod "rook-ceph-operator-77758ddc74-dlwn2" deleted
rook-ceph-operator
Pod が再起動していることを確認します。# oc get -n openshift-storage pod -l app=rook-ceph-operator
出力例:
NAME READY STATUS RESTARTS AGE rook-ceph-operator-77758ddc74-wqf25 1/1 Running 0 66s
新規 OSD および
mon
の作成には、Operator が再起動するまでに数分かかる場合があります。ocs-osd-removal
ジョブを削除します。# oc delete job ocs-osd-removal-${osd_id_to_remove}
以下に例を示します。
# oc delete job ocs-osd-removal-1 job.batch "ocs-osd-removal-1" deleted
検証手順
以下のコマンドを実行して、出力で新規ノードが表示されていることを確認します。
$ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1
Workloads → Pods をクリックし、新規ノード上の少なくとも以下の Pod が Running 状態にあることを確認します。
-
csi-cephfsplugin-*
-
csi-rbdplugin-*
-
他の必要なすべての OpenShift Container Storage Pod が Running 状態にあることを確認します。
増分の
mon
が新規に作成されており、Running
状態にあることを確認します。$ oc get pod -n openshift-storage | grep mon
出力例:
rook-ceph-mon-b-74f6dc9dd6-4llzq 1/1 Running 0 6h14m rook-ceph-mon-c-74948755c-h7wtx 1/1 Running 0 4h24m rook-ceph-mon-d-598f69869b-4bv49 1/1 Running 0 162m
OSD と Mon が
Running
状態になるまで数分かかる場合があります。
- 検証手順が失敗した場合は、Red Hat サポートにお問い合わせください。
第7章 ストレージデバイスの置き換え
7.1. IBM Power Systems で動作するストレージデバイスまたは障害のあるストレージデバイスの置き換え
IBM Power Systems でローカルストレージデバイスを使用してデプロイされた OpenShift Container Storage のオブジェクトストレージデバイス (OSD) を置き換えることができます。基礎となるストレージデバイスを置き換える必要がある場合は、この手順を使用します。
手順
置き換える必要がある OSD と、その OSD がスケジュールされている OpenShift Container Platform ノードを特定します。
# oc get -n openshift-storage pods -l app=rook-ceph-osd -o wide
出力例:
rook-ceph-osd-0-86bf8cdc8-4nb5t 0/1 crashLoopBackOff 0 24h 10.129.2.26 worker-0 <none> <none> rook-ceph-osd-1-7c99657cfb-jdzvz 1/1 Running 0 24h 10.128.2.46 worker-1 <none> <none> rook-ceph-osd-2-5f9f6dfb5b-2mnw9 1/1 Running 0 24h 10.131.0.33 worker-2 <none> <none>
この例では、
rook-ceph-osd-0-86bf8cdc8-4nb5t
を置き換える必要があり、worker-0
は OSD がスケジュールされる RHOCP ノードです。注記置き換える OSD が正常である場合、Pod のステータスは
Running
になります。置き換えられる OSD の OSD デプロイメントをスケールダウンします。
# osd_id_to_remove=0 # oc scale -n openshift-storage deployment rook-ceph-osd-${osd_id_to_remove} --replicas=0
ここで、
osd_id_to_remove
はrook-ceph-osd
接頭辞の直後にくる Pod 名の整数です。この例では、デプロイメント名はrook-ceph-osd-0
です。出力例:
deployment.apps/rook-ceph-osd-0 scaled
rook-ceph-osd
Pod が停止していることを確認します。# oc get -n openshift-storage pods -l ceph-osd-id=${osd_id_to_remove}
出力例:
No resources found in openshift-storage namespace.
注記rook-ceph-osd
Pod がterminating
状態にある場合は、force
オプションを使用して Pod を削除します。# oc delete pod rook-ceph-osd-0-86bf8cdc8-4nb5t --grace-period=0 --force
出力例:
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely. pod "rook-ceph-osd-0-86bf8cdc8-4nb5t" force deleted
新規 OSD を追加できるようにクラスターから古い OSD を削除します。
置き換える OSD に関連付けられた
DeviceSet
を特定します。# oc get -n openshift-storage -o yaml deployment rook-ceph-osd-${osd_id_to_remove} | grep ceph.rook.io/pvc
出力例:
ceph.rook.io/pvc: ocs-deviceset-localblock-0-data-0-64xjl ceph.rook.io/pvc: ocs-deviceset-localblock-0-data-0-64xjl
この例では、PVC 名は
ocs-deviceset-localblock-0-data-0-64xjl
です。クラスターから以前の OSD を削除します。
# oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=${osd_id_to_remove} | oc -n openshift-storage create -f -
出力例:
job.batch/ocs-osd-removal-0 created
警告この手順により、OSD はクラスターから完全に削除されます。
osd_id_to_remove
の正しい値が指定されていることを確認します。
ocs-osd-removal
Pod のステータスをチェックして、OSD が正常に削除されたことを確認します。Completed
のステータスで、OSD の削除ジョブが正常に完了したことを確認します。# oc get pod -l job-name=ocs-osd-removal-${osd_id_to_remove} -n openshift-storage
注記ocs-osd-removal
が失敗し、Pod が予想されるCompleted
の状態にない場合、追加のデバッグのために Pod ログを確認します。以下に例を示します。# oc logs ${osd_id_to_remove} -n openshift-storage --tail=-1
置き換える OSD に関連付けられた Persistent Volume Claim (永続ボリューム要求、PVC) リソースを削除します。
PVC に関連付けられた PV を特定します。
# oc get -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix>
ここで、
x
、y
、およびpvc-suffix
は、ステップ 4(a) で特定されたDeviceSet
の値です。出力例:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE ocs-deviceset-localblock-0-data-0-64xjl Bound local-pv-8137c873 256Gi RWO localblock 24h
この例では、関連付けられた PV は
local-pv-8137c873
です。置き換えるデバイスの名前を特定します。
# oc get pv local-pv-<pv-suffix> -o yaml | grep path
ここで、
pv-suffix
は、前のステップで特定された PV 名の値です。出力例:
path: /mnt/local-storage/localblock/vdc
この例では、デバイス名は
vdc
です。置き換える OSD に関連付けられた
prepare-pod
を特定します。# oc describe -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix> | grep Mounted
ここで、
x
、y
、およびpvc-suffix
は、直前の手順で特定されたDeviceSet
の値です。出力例:
Mounted By: rook-ceph-osd-prepare-ocs-deviceset-localblock-0-data-0-64knzkc
この例では、
prepare-pod
の名前はrook-ceph-osd-prepare-ocs-deviceset-localblock-0-data-0-64knzkc
です。関連付けられた PVC を削除する前に
osd-prepare
Pod を削除します。# oc delete -n openshift-storage pod rook-ceph-osd-prepare-ocs-deviceset-<x>-<y>-<pvc-suffix>-<pod-suffix>
ここで、
x
、y
、pvc-suffix
、およびpod-suffix
は、直前の手順で特定されたosd-prepare
Pod 名の値です。出力例:
pod "rook-ceph-osd-prepare-ocs-deviceset-localblock-0-data-0-64knzkc" deleted
置き換える OSD に関連付けられた PVC を削除します。
# oc delete -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix>
ここで、
x
、y
、およびpvc-suffix
は、直前の手順で特定されたDeviceSet
の値です。出力例:
persistentvolumeclaim "ocs-deviceset-localblock-0-data-0-64xjl" deleted
古いデバイスを置き換え、新規デバイスを使用して新規の OpenShift Container Platform PV を作成します。
置き換えるデバイスで OpenShift Container Platform ノードにログインします。この例では、OpenShift Container Platform ノードは
worker-0
です。# oc debug node/worker-0
出力例:
Starting pod/worker-0-debug ... To use host binaries, run `chroot /host` Pod IP: 192.168.88.21 If you don't see a command prompt, try pressing enter. # chroot /host
先に特定したデバイス名
vdc
を使用して置き換える/dev/disk
の内容を記録します。# ls -alh /mnt/local-storage/localblock
出力例:
total 0 drwxr-xr-x. 2 root root 17 Nov 18 15:23 . drwxr-xr-x. 3 root root 24 Nov 18 15:23 .. lrwxrwxrwx. 1 root root 8 Nov 18 15:23 vdc -> /dev/vdc
LocalVolumeSet
CR の名前を見つけ、置き換えるデバイス/dev/disk
を削除またはコメントアウトします。# oc get -n openshift-local-storage localvolumeset NAME AGE localblock 25h
置き換えるデバイスで OpenShift Container Platform ノードにログインし、古い
symlink
を削除します。# oc debug node/worker-0
出力例:
Starting pod/worker-0-debug ... To use host binaries, run `chroot /host` Pod IP: 192.168.88.21 If you don't see a command prompt, try pressing enter. # chroot /host
置き換えるデバイス名の古い
symlink
を特定します。この例では、デバイス名はvdc
です。# ls -alh /mnt/local-storage/localblock
出力例:
total 0 drwxr-xr-x. 2 root root 17 Nov 18 15:23 . drwxr-xr-x. 3 root root 24 Nov 18 15:23 .. lrwxrwxrwx. 1 root root 8 Nov 18 15:23 vdc -> /dev/vdc
symlink
を削除します。# rm /mnt/local-storage/localblock/vdc
symlink
が削除されていることを確認します。# ls -alh /mnt/local-storage/localblock
出力例:
total 0 drwxr-xr-x. 2 root root 6 Nov 18 17:11 . drwxr-xr-x. 3 root root 24 Nov 18 15:23 ..
重要OpenShift Container Storage 4.5 以降の新規デプロイメントでは、LVM が使用されていないため、
ceph-volume
raw モードが動作します。そのため、追加の検証は不要であり、次のステップに進むことができます。
先の手順で特定された、置き換えるデバイスに関連付けられた PV を削除します。この例では、PV 名は
local-pv-8137c873
です。# oc delete pv local-pv-8137c873
出力例:
persistentvolume "local-pv-8137c873" deleted
- デバイスを新しいデバイスに置き換えます。
正しい OpenShift Container Platform ノードにログインし、新規ドライブのデバイス名を特定します。同じデバイスを使用しない限り、デバイス名は変更する必要があります。
# lsblk
出力例:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 252:0 0 40G 0 disk |-vda1 252:1 0 4M 0 part |-vda2 252:2 0 384M 0 part /boot `-vda4 252:4 0 39.6G 0 part `-coreos-luks-root-nocrypt 253:0 0 39.6G 0 dm /sysroot vdb 252:16 0 512B 1 disk vdd 252:32 0 256G 0 disk
この例では、新しいデバイス名は
vdd
です。-
新しい
/dev/disk
が利用可能になると、localvolumeset によって自動検出されます。 新規 PV が
Available
状態にあり、正しいサイズであることを確認します。# oc get pv | grep 256Gi
出力例:
local-pv-1e31f771 256Gi RWO Delete Bound openshift-storage/ocs-deviceset-localblock-2-data-0-6xhkf localblock 24h local-pv-ec7f2b80 256Gi RWO Delete Bound openshift-storage/ocs-deviceset-localblock-1-data-0-hr2fx localblock 24h local-pv-8137c873 256Gi RWO Delete Available localblock 32m
新規デバイス用に新規 OSD を作成します。
rook-ceph-operator
を再起動して Operator の調整を強制的に実行して新規 OSD をデプロイします。rook-ceph-operator
の名前を特定します。# oc get -n openshift-storage pod -l app=rook-ceph-operator
出力例:
NAME READY STATUS RESTARTS AGE rook-ceph-operator-85f6494db4-sg62v 1/1 Running 0 1d20h
rook-ceph-operator
を削除します。# oc delete -n openshift-storage pod rook-ceph-operator-85f6494db4-sg62v
出力例:
pod "rook-ceph-operator-85f6494db4-sg62v" deleted
この例では、rook-ceph-operator Pod 名は
rook-ceph-operator-85f6494db4-sg62v
です。rook-ceph-operator
Pod が再起動していることを確認します。# oc get -n openshift-storage pod -l app=rook-ceph-operator
出力例:
NAME READY STATUS RESTARTS AGE rook-ceph-operator-85f6494db4-wx9xx 1/1 Running 0 50s
新規 OSD の作成には、Operator が再起動するまでに数分かかる場合があります。
検証手順
新しい OSD が実行されており、新規 PVC が作成されていることを確認します。
# oc get -n openshift-storage pods -l app=rook-ceph-osd
出力例:
rook-ceph-osd-0-76d8fb97f9-mn8qz 1/1 Running 0 23m rook-ceph-osd-1-7c99657cfb-jdzvz 1/1 Running 1 25h rook-ceph-osd-2-5f9f6dfb5b-2mnw9 1/1 Running 0 25h
# oc get -n openshift-storage pvc | grep localblock
出力例:
ocs-deviceset-localblock-0-data-0-q4q6b Bound local-pv-8137c873 256Gi RWO localblock 10m ocs-deviceset-localblock-1-data-0-hr2fx Bound local-pv-ec7f2b80 256Gi RWO localblock 1d20h ocs-deviceset-localblock-2-data-0-6xhkf Bound local-pv-1e31f771 256Gi RWO localblock 1d20h
OpenShift Web コンソールにログインし、ストレージダッシュボードを表示します。
図7.1 デバイスの置き換え後の OpenShift Container Platform ストレージダッシュボードの OSD ステータス