Menu Close

IBM Power Systems を使用した OpenShift Container Storage のデプロイおよび管理

Red Hat OpenShift Container Storage 4.6

インストールおよび管理方法

Red Hat Storage Documentation Team

概要

IBM Power Systems で Red Hat OpenShift Container Storage をインストールし、管理する方法については、本書をお読みください。
重要
IBM Power Systems での OpenShift Container Storage のデプロイおよび管理機能はテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

はじめに

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 architecture

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 ノードを使用することが推奨されます。

インフラストラクチャーノードを作成するには、 infra とラベルが付けられた新規ノードをプロビジョニングできます。Red Hat OpenShift Container Storage の専用ワーカーノードの使用方法について参照してください。

ワーカー

ワーカーノードは、アプリケーションを実行するため、アプリケーションノードとしても知られています。

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 最小リソース要件の集約

デプロイメントモードベースサービス

内部

  • 48 CPU (論理)
  • 192 GB メモリー
  • 3 つのストレージデバイス (それぞれに追加の 500GB ディスクが含まれる)

外部

  • 該当なし

例: 内部接続デバイスモードのデプロイメントの 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=

手順

  1. OpenShift Web コンソールの左側のペインで、Operators → OperatorHub をクリックします。

    図2.1 Operator Hub の Operator 一覧

    OpenShift Web コンソールの Operator Hub の Operator 一覧のスクリーンショット。
  2. OpenShift Container Storage をクリックします。

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

  3. OpenShift Container Storage Operator ページで、Install をクリックします。

    図2.2 Install Operator ページ

    Screenshot of Ocs Install Operator page.

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

    Screenshot of Install Operator page.
  4. Install Operator ページで、以下のオプションが選択されていることを確認します。

    1. Channel を stable-4.6として更新します。
    2. Installation Mode オプションに A specific namespace on the cluster を選択します。
    3. Installed Namespace に Operator recommended namespace PR openshift-storage を選択します。namespace openshift-storage が存在しない場合、これは Operator のインストール時に作成されます。
    4. Enable operator recommended cluster monitoring on this namespace が選択されていることを確認します。これはクラスターのモニタリングに必要です。
    5. Approval Strategy に Automatic を選択します。
  5. Install をクリックします。

    図2.3 Installed Operators ダッシュボード

    インストールされた Operator のスクリーンショット。

検証手順

  • OpenShift Container Storage Operator の Status が Installed Operators ダッシュボードで Succeeded と表示されることを確認します。

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

以下の手順を使用して、OpenShift Container Storage クラスターをローカルストレージデバイスに作成する前に Operator Hub からローカルストレージ Operator をインストールします。

前提条件

  • 以下のように openshift-local-storage という namespace を作成します。

    1. OpenShift Web コンソールの左側のペインで、Administration → Namespaces をクリックします。
    2. Create Namespace をクリックします。
    3. Create Namespace ダイアログボックスで、Name に openshift-local-storage と入力します。
    4. Default Network PolicyNo restrictions オプションを選択します。
    5. Create をクリックします。

手順

  1. OpenShift Web コンソールの左側のペインで、Operators → OperatorHub をクリックします。
  2. Operator の一覧から Local Storage Operator を検索し、これをクリックします。
  3. Install をクリックします。

    図2.4 Install Operator ページ

    Screenshot of Install Local storage Operator page.

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

    Screenshot of Install Operator page.
  4. Install Operator ページで、以下のオプションが選択されていることを確認します。

    1. Channel を stable-4.6として更新します。
    2. Installation Mode オプションに A specific namespace on the cluster を選択します。
    3. Installed Namespace を openshift-local-storage に選択します。
    4. Approval Strategy に Automatic を選択します。
  5. Install をクリックします。

    図2.5 Installed Operators ダッシュボード

    インストールされた Operator のスクリーンショット。

検証手順

  • ローカルストレージ Operator がステータス Succeeded を表示していることを確認します。

2.4. 利用可能なストレージデバイスの検索

以下の手順を使用して、IBM Power Systems の PV を作成する前に、OpenShift Container Storage ラベル cluster.ocs.openshift.io/openshift-storage='' でラベルを付けた 3 つ以上のワーカーノードのそれぞれのデバイス名を特定します。

手順

  1. 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
  2. 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 です。

  3. 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"}'

各ノードのストレージデバイスを特定するには、利用可能なストレージデバイスの検索について参照してください。

手順

  1. OpenShift Web コンソールにログインします。
  2. OpenShift Web コンソールの左側のペインで openshift-local-storage namespace から OperatorsInstalled Operators をクリックし、インストールされた Operator を表示します。

    図2.6 Local Storage Operator ページ

    Screenshot of Local Storage operator dashboard.
    1. Local Storage のインストールされた Operator をクリックします。
    2. Operator Details ページで、Local Volume Set リンクをクリックします。

      図2.7 Local Volume Set タブ

      Screenshot of Local Volume Set tab on Local Storage Operator dashboard.
  3. Create Local Volume Set をクリックします。

    Screenshot of Create Local Volume Set.
    1. ボリュームセット名を入力します。デフォルトで、ストレージクラス名がボリュームセット名について表示されます。
    2. 利用可能なディスクを検出するには、以下のいずれかを選択できます。

      • All nodes: すべてのノードでディスクを検出します。
      • Select nodes: ノードの一覧からノードのサブセットを選択します。
    3. Disk type を選択します。
    4. Advanced オプションで、Disk モードに Block を選択し、追加で接続されたディスクのサイズに相当する最小のディスクサイズ、最大のディスクサイズを選択し、最大のディスク制限を設定できます。
    5. Create をクリックします。

      Create ボタンは、最低でも 3 つのノードを選択した後にのみ有効になります。ローカルボリュームセットは、利用可能なディスクを持つワーカーノードごとに 1 つのボリュームで作成されます。

  4. OpenShift Web コンソールの左側のペインで openshift-storage namespace から OperatorsInstalled Operators をクリックし、インストールされた Operator を表示します。

    図2.8 OpenShift Container Storage Operator ページ

    Screenshot of OpenShift Container Storage operator dashboard.
    1. OpenShift Container Storage インストール Operator をクリックします。
    2. Operator Details ページで、Storage Cluster リンクをクリックします。

      図2.9 Storage Cluster タブ

      Screenshot of Storage Cluster tab on OpenShift Container Storage Operator dashboard.
  5. Create Storage Cluster をクリックします。

    Screenshot of Create Cluster Service page
  6. Select ModeInternal-Attached devices を選択します。
ストレージクラスター作成のスクリーンショット。
  1. 必要なストレージクラスを選択します。
  2. 要件に応じて、ストレージクラスターのデータ暗号化を有効または無効にします。
  3. ストレージクラスに対応するノードは、ドロップダウンで選択したストレージクラスに基づいて表示されます。
  4. 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 であることを確認できます。

手順

  1. OpenShift Web コンソールの左側のペインから Workloads → Pods をクリックします。
  2. Project ドロップダウンリストから openshift-storage を選択します。

    各コンポーネントについて予想される Pod 数や、これがノード数によってどのように異なるかについての詳細は、表3.1「OpenShift Container Storage クラスターに対応する Pod」 を参照してください。

    注記

    OpenShift Container Storage のクラスター全体でのデフォルトノードセレクターを上書きする必要がある場合は、コマンドラインインターフェースで以下の手順を実行できます。

    1. openshift-storage namespace の空のノードセレクターを指定します。

      $ oc annotate namespace openshift-storage openshift.io/node-selector=
    2. DaemonSets によって生成される元の Pod を削除します。

      oc delete pod -l app=csi-cephfsplugin -n openshift-storage
      oc delete pod -l app=csi-rbdplugin -n openshift-storage
  3. 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 カード

    永続ストレージダッシュボードの Health カードのスクリーンショット
  • 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 Platform のアンインストール

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 アンインストールアノテーションの説明

アノテーションデフォルト動作

クリーンアップポリシー

delete

Yes

Rook は物理ドライブと DataDirHostPath をクリーンアップします。

cleanup-policy

retain

No

Rook は、物理ドライブおよび DataDirHostPath をクリーンアップ しません

mode

graceful

Yes

Rook および NooBaa は PVC および OBC が管理者/ユーザーによって削除されるまでアンインストールプロセスを 一時停止 します。

mode

forced

No

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 など) が管理者によって作成された場合には、それらを消費したリソースを削除してから、該当の管理者により削除される必要があります。

手順

  1. OpenShift Container Storage を使用しているボリュームスナップショットを削除します。

    1. すべての namespace からボリュームスナップショットを一覧表示します。

      $ oc get volumesnapshot --all-namespaces
    2. 直前のコマンドの出力から、OpenShift Container Storage を使用しているボリュームスナップショットを特定し、削除します。

      $ oc delete volumesnapshot <VOLUME-SNAPSHOT-NAME> -n <NAMESPACE>
  2. OpenShift Container Storage を使用している PVC を削除します。

    デフォルトのアンインストールモード (graceful) では、アンインストーラーは OpenShift Container Storage を使用するすべての PVC が削除されるまで待機します。

    PVC を事前に削除せずに Storage Cluster を削除する場合は、アンインストールモードのアノテーションを「forced」に設定し、この手順を省略できます。これを実行すると、孤立した PVC がシステムに作成されます。

    1. OpenShift Container Storage を使用して、 OpenShift Container Platform モニタリングスタック PVC を削除します。

      「OpenShift Container Storage からのモニタリングスタックの削除」を参照してください。

    2. OpenShift Container Storage を使用して、 OpenShift Container Platform レジストリーを削除します。

      「OpenShift Container Storage からの OpenShift Container Platform レジストリーの削除」を参照してください。

    3. OpenShift Container Storage を使用して、 OpenShift Container Platform ロギング PVC を削除します。

      「OpenShift Container Storage からのクラスターロギング Operator の削除」を参照してください。

    4. 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>
        注記

        クラスターに作成されているカスタムバッキングストア、バケットクラスなどを削除していることを確認します。

  3. Storage Cluster オブジェクトを削除し、関連付けられたリソースが削除されるのを待機します。

    $ oc delete -n openshift-storage storagecluster --all --wait=true
  4. uninstall.ocs.openshift.io/cleanup-policydelete (デフォルト) に設定されている場合にクリーンアップ 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
  5. ディレクトリー /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
  6. 暗号化がインストール時に有効にされている場合、すべての OpenShift Container Storage ノードの OSD デバイスから dm-crypt で管理される device-mapper マッピングを削除します。

    1. debug Pod を作成し、ストレージノードのホストに対して chroot を実行します。

      $ oc debug node <node name>
      $ chroot /host
    2. デバイス名を取得し、OpenShift Container Storage デバイスについてメモします。

      $ dmsetup ls
      ocs-deviceset-0-data-0-57snx-block-dmcrypt (253:1)
    3. マップ済みデバイスを削除します。

      $ 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 番号を書き留めて強制終了します。この例では、PID778825 になります。

      • kill コマンドを使用してプロセスを終了します。

        $ kill -9 <PID>
      • デバイス名が削除されていることを確認します。

        $ dmsetup ls
  7. 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 の終了をブロックしているオブジェクトを特定します。

  8. ローカルストレージデバイスを使用して OpenShift Container Storage をデプロイした場合には、ローカルのストレージ Operator 設定を削除します。「ローカルストレージ Operator の設定の削除」を参照してください。
  9. ストレージノードのラベルを解除します。

    $ oc label nodes  --all cluster.ocs.openshift.io/openshift-storage-
    $ oc label nodes  --all topology.rook.io/rack-
  10. ノードにテイントのマークが付けられている場合に OpenShift Container Storage テイントを削除します。

    $ oc adm taint nodes --all node.ocs.openshift.io/storage-
  11. OpenShift Container Storage を使用してプロビジョニングした PV がすべて削除されていることを確認します。Released 状態のままの PV がある場合は、これを削除します。

    $ oc get pv
    $ oc delete pv <pv name>
  12. Multicloud Object Gateway storageclass を削除します。

    $ oc delete storageclass openshift-storage.noobaa.io --wait=true --timeout=5m
  13. 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
  14. OpenShift Container Platform Web コンソールで、OpenShift Container Storage が完全にアンインストールされていることを確認するには、以下を実行します。

    1. Home → Overview をクリックし、ダッシュボードにアクセスします。
    2. Persistent Storage タブが Cluster タブの横に表示されなくなることを確認します。

4.1.1. ローカルストレージ Operator の設定の削除

ローカルストレージデバイスを使用して OpenShift Container Storage をデプロイした場合にのみこのセクションの説明を使用します。

注記

OpenShift Container Storage デプロイメントで localvolume リソースのみを使用する場合は、直接、手順 8 に移動します。

手順

  1. LocalVolumeSet と、OpenShift Container Storage で使用される対応の StorageClassName を特定します。
  2. LocalVolumeSet を指定する StorageClass に、変数 SC を設定します。

    $ export SC="<StorageClassName>"
  3. LocalVolumeSet を削除します。

    $ oc delete localvolumesets.local.storage.openshift.io <name-of-volumeset> -n openshift-local-storage
  4. 指定の StorageClassName のローカルストレージ PV を削除します。

    $ oc get pv | grep $SC | awk '{print $1}'| xargs oc delete pv
  5. StorageClassName を削除します。

    $ oc delete sc $SC
  6. 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
  7. LocalVolumeDiscovery を削除します。

    $ oc delete localvolumediscovery.local.storage.openshift.io/auto-discover-devices -n openshift-local-storage
  8. LocalVolume リソースを削除します (ある場合)。

    以下の手順を使用して、現行または直前の OpenShift Container Storage バージョンで PV のプロビジョニングに使用した LocalVolume リソースを削除します。また、これらのリソースがクラスターの他のテナントで使用されていないことを確認します。

    ローカルボリュームごとに、以下を実行します。

    1. LocalVolume と、OpenShift Container Storage で使用される対応の StorageClassName を特定します。
    2. 変数 LV を LocalVolume の名前に設定し、変数 SC を StorageClass の名前に設定します。

      以下は例になります。

      $ LV=local-block
      $ SC=localblock
    3. ローカルボリュームリソースを削除します。

      $ oc delete localvolume -n local-storage --wait=true $LV
    4. 残りの PV および StorageClass が存在する場合はこれらを削除します。

      $ oc delete pv -l storage.openshift.com/local-volume-owner-name=${LV} --wait --timeout=5m
      $ oc delete storageclass $SC --wait --timeout=5m
    5. 該当するリソースのストレージノードからアーティファクトをクリーンアップします。

      $ [[ ! -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 モニタリングスタックを使用できるように設定されます。

    詳細は、「モニタリングスタックの設定」を参照してください。

手順

  1. 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
  2. モニタリング configmap を編集します。

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  3. 以下の例が示すように、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 を使用しています。

  4. 関連する 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 を使用するように設定されている必要があります。

手順

  1. 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 と呼ばれ、これは安全に削除することができます。

  2. 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 を使用するように設定されている必要があります。

手順

  1. namespace にある ClusterLogging インスタンスを削除します。

    $ oc delete clusterlogging instance -n openshift-logging --wait=true --timeout=5m

    openshift-logging namespace の PVC は安全に削除できます。

  2. 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) が割り当てられている必要があります。

手順

  1. OpenShift Container Storage がインストールされている OpenShift Container Platform ノードにストレージ容量を追加するには、以下を実行する必要があります。

    1. ワーカーノードごとに少なくとも 1 つのデバイスを追加するため、利用可能なデバイスを見つけます。各デプロイメントガイドで説明されている利用可能なストレージデバイスを検索する手順に従ってください。

      注記

      このプロセスを、ストレージを追加する既存ノードのすべて (3 ノード以上) に対して実行するようにしてください。

    2. ノード内で 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 ...
    3. 新規に追加されたディスクは LocalVolumeSet によって自動的に検出されます。
  2. 新規に作成された 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 が利用可能です。

  3. OpenShift Web コンソールに移動します。
  4. 左側のナビゲーションバーの Operators をクリックします。
  5. Installed Operators を選択します。
  6. ウィンドウで、OpenShift Container Storage Operator をクリックします。

    ocs installed operators ibm
  7. 上部のナビゲーションバーで、右にスクロールし、Storage Cluster タブをクリックします。

    Create OCS Cluster Service ibm
  8. 表示されるリストには 1 つの項目のみが含まれます。右端の (⋮) をクリックして、オプションメニューを拡張します。
  9. オプションメニューから Add Capacity を選択します。

    ocs add capacity dialog menu lso

    このダイアログボックスで、Storage Class 名を localVolumeset CR で使用される名前に設定します。表示される利用可能な容量は、ストレージクラスで利用可能なローカルディスクをベースとしています。

  10. 設定が終了したら、Add をクリックします。ストレージクラスターが Ready 状態になるまでに数分待機する必要がある場合があります。
  11. 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 が作成されています。

検証手順

  1. OverviewPersistent Storage タブに移動してから、Capacity breakdown カードをチェックします。

    ocs add capacity expansion verification capacity card ibm

    容量は選択に応じて増大することに注意してください。

    重要

    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) が割り当てられている必要があります。

手順

  1. 以下の手順を実行します。

    1. 必要なインフラストラクチャーで新規の IBM Power マシンを取得します。「プラットフォーム要件」を参照してください。
    2. 新規 IBM Power マシンを使用して新規 OpenShift Container Platform ノードを作成します。
  2. Pending 状態の OpenShift Container Storage に関連する証明書署名要求 (CSR) の有無を確認します。

    $ oc get csr
  3. 新規ノードに必要なすべての OpenShift Container Storage CSR を承認します。

    $ oc adm certificate approve <Certificate_Name>
  4. ComputeNodes をクリックし、新規ノードが Ready 状態にあることを確認します。
  5. 以下のいずれかを使用して、OpenShift Container Storage ラベルを新規ノードに適用します。

    ユーザーインターフェースを使用する場合
    1. 新規ノードについて、Action Menu (⋮)Edit Labels をクリックします。
    2. cluster.ocs.openshift.io/openshift-storage を追加し、Save をクリックします。
    コマンドラインインターフェースの使用
    • 以下のコマンドを実行して、OpenS+hift Container Storage ラベルを新規ノードに適用します。

      $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""
  6. OpenShift Web コンソールから、OperatorsInstalled Operators をクリックします。

    Project ドロップダウンリストから、ローカルストレージ Operator がインストールされているプロジェクトを選択してください。

  7. Local Storage をクリックします。
  8. Local Volume Sets タブをクリックします。
  9. LocalVolumeSet の横にあるアクションメニュー (⋮)Edit Local Volume Set をクリックします。
  10. YAML で、node selector の下にある values フィールドに新規ノードのホスト名を追加します。

    図5.1 新規ホスト名の追加に関する YAML

    新規ホスト名の追加を示す YAML のスクリーンショット。
  11. Save をクリックします。
注記

異なるゾーンのそれぞれに 3 つのノードを追加することが推奨されます。3 つのノードを追加して、それらすべてのノードに対してこの手順を実行する必要があります。

検証手順

5.3.2. 新規ノードの追加の確認

  1. 以下のコマンドを実行して、新規ノードが出力にあることを確認します。

    $ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1
  2. WorkloadsPods をクリックし、新規ノード上の少なくとも以下の 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) クラスターにログインしている必要があります。

手順

  1. 障害が発生したノードのラベルを確認し、ラックラベルをメモします。

    $ oc get nodes --show-labels | grep failed-node-name
  2. 障害のあるノードで実行されている mon(ある場合)およびオブジェクトストレージデバイス (OSD) Pod を特定します。

    $ oc get pods -n openshift-storage -o wide | grep -i failed-node-name
  3. 先の手順で特定された 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
  4. 障害のあるノードにマークを付けて、これがスケジュールされないようにします。

    $ oc adm cordon failed-node-name
  5. 既存の機能から障害のあるノードをドレイン(解放)します。

    $ 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
  6. 障害のあるノードを削除します。

    $ oc delete node failed-node-name
  7. 必要なインフラストラクチャーで新規の IBM Power マシンを取得します。クラスターの IBM Power Systems へのインストールについて参照してください。
  8. 新規 IBM Power Systems マシンを使用して新規 OpenShift Container Platform Systems ノードを作成します。
  9. Pending 状態の OpenShift Container Storage に関連する証明書署名要求 (CSR) の有無を確認します。

    $ oc get csr
  10. 新規ノードに必要なすべての OpenShift Container Storage CSR を承認します。

    $ oc adm certificate approve certificate-name
  11. OpenShift Web コンソールで ComputeNodes をクリックし、新規ノードが Ready 状態にあることを確認します。
  12. 優先するインターフェースを使用して、OpenShift Container Storage ラベルを新規ノードに適用します。

    • OpenShift Web コンソールの使用

      1. 新規ノードについて、Action Menu (⋮)Edit Labels をクリックします。
      2. cluster.ocs.openshift.io/openshift-storage を追加し、Save をクリックします。
    • コマンドラインインターフェースの使用

      1. 以下のコマンドを実行して、OpenS+hift Container Storage ラベルを新規ノードに適用します。

        $ oc label node new-node-name cluster.ocs.openshift.io/openshift-storage=""
  13. これらのワーカーノードで利用可能なローカルストレージデバイスを OpenShift Container Storage StorageCluster に追加します。

    1. 編集する 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
    2. 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
      [...]

      エディターを終了する前に必ず保存します。

  14. 新規 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
  15. openshift-storage プロジェクトに切り替えます。

    $ oc project openshift-storage
  16. 失敗した OSD をクラスターから削除します。

    1. 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_removerook-ceph-osd prefix の直後にくる 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 です。

    2. 失敗した OSD をクラスターから削除します。

      # oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=${osd_id_to_remove},{osd_id_to_remove2} | oc create -f -
  17. 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
  18. 障害のあるノードに関連付けられた PV を削除します。

    1. PVC に関連付けられた PV を特定します。

      # oc get -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix>

      ここで xy、および 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 です。

    2. PV を削除します。

      # oc delete pv <persistent-volume>

      以下は例になります。

      # oc delete pv local-pv-5c9b8982
      persistentvolume "local-pv-5c9b8982" deleted
  19. crashcollector Pod デプロイメントを削除します。

    $ oc delete deployment --selector=app=rook-ceph-crashcollector,node_name=failed-node-name -n openshift-storage
  20. 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
    1. rook-ceph-operator を削除します。

      # oc delete -n openshift-storage pod rook-ceph-operator-77758ddc74-dlwn2

      出力例:

      pod "rook-ceph-operator-77758ddc74-dlwn2" deleted
  21. 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 が再起動するまでに数分かかる場合があります。

  22. 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
  • WorkloadsPods をクリックし、新規ノード上の少なくとも以下の 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) を置き換えることができます。基礎となるストレージデバイスを置き換える必要がある場合は、この手順を使用します。

手順

  1. 置き換える必要がある 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 になります。

  2. 置き換えられる 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_removerook-ceph-osd プレフィックスの直後にくる Pod 名の整数です。この例では、デプロイメント名は rook-ceph-osd-0 です。

    出力例:

    deployment.apps/rook-ceph-osd-0 scaled
  3. 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
  4. 新規 OSD を追加できるようにクラスターから古い OSD を削除します。

    1. 置き換える 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 です。

    2. クラスターから以前の 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 の正しい値が指定されていることを確認します。

  5. 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
  6. 置き換える OSD に関連付けられた Persistent Volume Claim (永続ボリューム要求、PVC) リソースを削除します。

    1. PVC に関連付けられた PV を特定します。

      # oc get -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix>

      ここで、xy、および 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 です。

    2. 置き換えるデバイスの名前を特定します。

      # oc get pv local-pv-<pv-suffix> -o yaml | grep path

      ここで、pv-suffix は、前のステップで特定された PV 名の値です。

      出力例:

      path: /mnt/local-storage/localblock/vdc

      この例では、デバイス名は vdc です。

    3. 置き換える OSD に関連付けられた prepare-pod を特定します。

      # oc describe -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix> | grep Mounted

      ここで、xy、 および 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 です。

    4. 関連付けられた PVC を削除する前に osd-prepare Pod を削除します。

      # oc delete -n openshift-storage pod rook-ceph-osd-prepare-ocs-deviceset-<x>-<y>-<pvc-suffix>-<pod-suffix>

      ここで、xy, pvc-suffix、およびd pod-suffix は、先の手順で特定された osd-prepare Pod 名の値です。

      出力例:

      pod "rook-ceph-osd-prepare-ocs-deviceset-localblock-0-data-0-64knzkc" deleted
    5. 置き換える OSD に関連付けられた PVC を削除します。

      # oc delete -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix>

      ここで、xy、 および pvc-suffix は、先の手順で特定された DeviceSet の値です。

      出力例:

      persistentvolumeclaim "ocs-deviceset-localblock-0-data-0-64xjl" deleted
  7. 古いデバイスを置き換え、新規デバイスを使用して新規の OpenShift Container Platform PV を作成します。

    1. 置き換えるデバイスで 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
    2. 先に特定したデバイス名 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
    3. LocalVolumeSet CR の名前を見つけ、置き換えるデバイス /dev/disk を削除またはコメントアウトします。

      # oc get -n openshift-local-storage localvolumeset
      NAME          AGE
      localblock   25h
  8. 置き換えるデバイスで 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
    1. 置き換えるデバイス名の古い 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
    2. symlink を削除します。

      # rm /mnt/local-storage/localblock/vdc
    3. 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 モードが動作します。そのため、追加の検証は不要であり、次のステップに進むことができます。

  9. 先の手順で特定された、置き換えるデバイスに関連付けられた PV を削除します。この例では、PV 名は local-pv-8137c873 です。

    # oc delete pv local-pv-8137c873

    出力例:

    persistentvolume "local-pv-8137c873" deleted
  10. デバイスを新しいデバイスに置き換えます。
  11. 正しい 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 です。

  12. 新しい /dev/disk が利用可能になると、localvolumeset によって自動検出されます。
  13. 新規 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
  14. 新規デバイス用に新規 OSD を作成します。

    1. rook-ceph-operator を再起動して Operator の調整を強制的に実行して新規 OSD をデプロイします。

      1. 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
      2. 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 です。

      3. 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 ステータス

    正常な OSD を表示する RHOCP ストレージダッシュボード。

法律上の通知

Copyright © 2021 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.