Red Hat Virtualization プラットフォームを使用した OpenShift Container Storage のデプロイおよび管理

Red Hat OpenShift Container Storage 4.6

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

概要

Red Hat Virtualization プラットフォームで Red Hat OpenShift Container Storage をインストールし、管理する方法については、本書をお読みください。
重要
Deploying and managing OpenShift Container Storage on Red Hat Virtualization platform is a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

前書き

Red Hat OpenShift Container Storage 4.6 では、既存の Red Hat OpenShift Container Platform (RHOCP) Red Hat Virtualization プラットフォームクラスターでのデプロイメントをサポートします。

内部モードで OpenShift Container Storage をデプロイするには、Red Hat Virtualization での OpenShift Container Storage のデプロイ のデプロイメントプロセスを実行します。

第1章 Red Hat Virtualization での OpenShift Container Storage のデプロイ

Red Hat Virtualization のインストーラーでプロビジョニングされるインフラストラクチャー (IPI) によって提供される共有ストレージデバイスを使用して OpenShift Container Storage を OpenShift Container Platform にデプロイすると、内部クラスターリソースを作成できます。

注記

Red Hat Virtualization では、内部の Openshift Container Storage クラスターのみがサポートされます。デプロイメントの要件についての詳細は、デプロイメントのプランニング を参照してください。

このセクションを使用して、OpenShift Container Platform がすでにインストールされている Red Hat Virtualization インフラストラクチャーに OpenShift Container Storage をデプロイします。

ローカルストレージデバイスを使用した OpenShift Container Storage をデプロイするには、以下を実行します。

1.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) を含めないでください。
  • ノードの最小要件については、プランニングガイドの リソース要件 セクションを参照してください。

1.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=
  • ノードに Red Hat OpenShift Container Storage リソースのみがスケジュールされるように、そのノードに infra のテイントを設定します。これにより、サブスクリプションコストを節約できます。詳細は、ストレージリソースの管理および割り当てガイドの Red Hat OpenShift Container Storage の専用ワーカーノードを使用する方法 の章を参照してください。

手順

  1. OpenShift Web コンソールの左側のペインで、Operators → OperatorHub をクリックします。
  2. Filter by keyword テキストボックスまたはフィルター一覧を使用して、Operator の一覧から OpenShift Container Storage を検索します。
  3. OpenShift Container Storage をクリックします。
  4. OpenShift Container Storage Operator ページで、Install をクリックします。
  5. Install Operator ページで、以下のオプションがデフォルトで選択されていることを確認します。

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

      • Approval StrategyAutomatic を選択します。

        注記

        Approval Strategy を Automatic として選択すると、新規インストール時、または OpenShift Container Storage の最新バージョンへの更新時に承認は必要ありません。

        1. インストール をクリックします。
        2. インストールが開始するまで待機します。これには、最長 20 分の時間がかかる可能性があります。
        3. Operators → Installed Operators をクリックします。
        4. Projectopenshift-storage であることを確認します。デフォルトで、プロジェクトopenshift-storage です。
        5. OpenShift Container StorageStatusSucceeded に変更するまで待機します。
      • Approval StrategyManual を選択します。

        注記

        Approval Strategy を Manual として選択すると、新規インストール時、または OpenShift Container Storage の最新バージョンへの更新時に承認が必要になります。

        1. インストール をクリックします。
        2. Manual approval required ページで、Approve または View Installed Operators in namespace openshift-storage のいずれかをクリックし、Operator をインストールできます。

          重要

          オプションのいずれかをクリックする前に、Manual approval required ページで、インストール計画がウィンドウに読み込まれるまで数分待機します。

          重要

          Approve をクリックする場合は、続行する前にインストール計画を確認する必要があります。

          • Approve をクリックします。

            • OpenShift Container Storage Operator がインストールされている間に数分待機します。
            • Installed operator - ready for use ページで、View Operator をクリックします。
            • Projectopenshift-storage であることを確認します。デフォルトで、プロジェクトopenshift-storage です。
            • Operators → Installed Operators をクリックします。
            • OpenShift Container StorageStatusSucceeded に変更するまで待機します。
          • View Installed Operators in namespace openshift-storage をクリックします。

            • Installed Operators ページで、ocs-operator をクリックします。
            • Subscription Details ページで、Install Plan リンクをクリックします。
            • InstallPlan Details ページで、Preview Install Plan をクリックします。
            • インストール計画を確認し、Approve をクリックします。
            • ComponentsStatusUnknown から Created または Present のいずれかに変更するまで待機します。
            • Operators → Installed Operators をクリックします。
            • Projectopenshift-storage であることを確認します。デフォルトで、プロジェクトopenshift-storage です。
            • OpenShift Container StorageStatusSucceeded に変更するまで待機します。

検証手順

  • OpenShift Container Storage Operator に、インストールが正常に実行されたことを示す緑色のチェックマークが表示されていることを確認します。
  • View Installed Operators in namespace openshift-storage リンクをクリックし、OpenShift Container Storage Operator が Installed Operators ダッシュボードで StatusSucceeded として表示していることを確認します。

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

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

手順

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

    図1.1 Install Operator ページ

    Screenshot of Install Operator page.
  5. Install Operator ページで、以下のオプションを設定します。

    1. Channel を 4.6 に更新します。
    2. Installation Mode オプションに A specific namespace on the cluster を選択します。
    3. Installed Namespace に Operator recommended namespace openshift-local-storage を選択します。
    4. Approval Strategy に Automatic を選択します。
  6. Install をクリックします。
  7. Local Storage Operator のステータスが Succeeded と表示されていることを確認します。

1.4. Red Hat Virtualization プラットフォームでの OpenShift Container Storage クラスターの作成

ストレージクラスが存在しない場合には、以下の手順を使用して Red Hat Virtualization プラットフォームにストレージクラスターを作成します。

ストレージクラスがすでに作成されている場合には、ストレージクラスが ストレージクラスがすでに存在する場合の Red Hat Virtualization 上でのストレージクラスター作成 で説明されているように、ストレージクラスターを直接作成できます。

前提条件

手順

  1. OpenShift Web コンソールにログインします。
  2. Operators → Installed Operators をクリックし、インストールされた Operator をすべて表示します。

    選択された Projectopenshift-storage であることを確認します。

    図1.2 OpenShift Container Storage Operator ページ

    Screenshot of OpenShift Container Storage operator dashboard.
  3. OpenShift Container Storage をクリックします。

    図1.3 OpenShift Container Storage の Details タブ

    Screenshot of selected operator details tab.
  4. Storage Cluster の Create Instance リンクをクリックします。

    図1.4 Create Storage Cluster ページ

    Screenshot of Create Storage Cluster page
  5. Select ModeInternal-Attached devices を選択します。デフォルトでは、Internal が選択されます。
  6. ディスク検出、ストレージクラスの作成、およびストレージクラスの作成を含むウィザードを使用してストレージクラスターを作成します。

    ローカルストレージ Operator をインストールすることを求めるプロンプトが出されます。Install をクリックし、ローカルストレージ Operator で説明されているように Operator をインストールします。

    ディスクの検出

    選択したノードで使用可能になる可能性のあるディスクの一覧を検出することができます。使用されていないブロックディスクおよびパーティション、永続ボリューム (PV) のプロビジョニングに利用できるブロックディスクおよびパーティションが検出されます。

    図1.5 Discovery Disks ウィザードページ

    Screenshot of discovering disks in select nodes.
    1. 以下のいずれかを選択します。

      • All nodes: すべてのノードでディスクを検出します。
      • Select nodes: 一覧表示されるノードからノードのサブセットを選択します。

        クラスターで特定のワーカーノードを見つけるには、Name または Label に基づいてノードをフィルターできます。Name を使用するとノード名で検索でき、Label を使用すると事前に定義されたラベルを選択して検索できます。

        選択したノードが集約された 30 CPU および 72 GiB の RAM の OpenShift Container Storage クラスターの要件と一致しない場合は、最小クラスターがデプロイされます。ノードの最小要件については、プランニングガイドの リソース要件 セクションを参照してください。

        注記

        選択したノードにテイントのマークが付けられており、そのノードがウィザードで検出されない場合は、回避策として Red Hat ナレッジベースソリューション に記載されている手順に従ってください。

    2. Next をクリックします。
    ストレージクラスの作成

    ストレージボリュームのセットをフィルターすることにより、専用のストレージクラスを作成してストレージを消費できます。

    図1.6 Create Storage Class ウィザードページ

    Screenshot of entering the storage class details.
    1. Volume Set Name を入力します。
    2. Storage Class Name を入力します。デフォルトで、ボリュームセット名がストレージクラス名について表示されます。
    3. 先の手順でディスク検出で選択されたノードは Filter Disks セクションに表示されます。以下のいずれかを選択します。

      • All nodes: ディスクを検出したすべてのノードを選択します。
      • Select nodes: ディスクを検出したノードのサブセットを選択します。

        クラスターで特定のワーカーノードを見つけるには、Name または Label に基づいてノードをフィルターできます。Name を使用するとノード名で検索でき、Label を使用すると事前に定義されたラベルを選択して検索できます。

        高可用性を確保するために、ワーカーノードは 3 つの異なる物理ノード、ラック、障害ドメインに分散することが推奨されます。

        注記

        OpenShift Container Storage のラックラベルがデータセンターの物理ラックに合わせて調整されていることを確認し、障害ドメインのレベルで二重ノードに障害が発生しないようにします。

    4. 必要な Disk Type を選択します。以下のオプションが利用可能になります。

      All

      ノードに存在するすべての種類のディスクを選択します。デフォルトでは、このオプションは選択されます。

      SSD/NVME

      SSD または NVME タイプのディスクのみを選択します。

      HDD

      HDD タイプのディスクのみを選択します。

      注記

      ストレージの基本的な抽象化により SSD/NVME ディスクが HDD として検出される場合は、ディスクタイプを All または HDD として選択します。

    5. Advanced セクションでは、以下を設定できます。

      ディスクモード

      デフォルトではブロックが選択されます。

      ディスクサイズ

      含める必要のあるデバイスの最小および最大の許容サイズ。

      注記

      デバイスの最小サイズ 100GB を設定する必要があります。

      最大ディスク制限

      これは、ノードで作成可能な PV の最大数を示します。このフィールドが空のままの場合、PV は一致するノードで利用可能なすべてのディスクに作成されます。

    6. (オプション) Select Capacity チャートを使用して選択されたノードでディスクの選択した容量を表示できます。

      このチャートは、直前の手順で検出されたディスクを反映するのに数分かかる場合があります。

      チャートで Nodes および Disks リンクをクリックして、ノードおよびディスクの一覧を表示し、詳細情報を表示します。

      図1.7 選択したノードの一覧

      Screenshot of list of nodes displayed from the selected capacity chart.

      図1.8 選択したディスクの一覧

      Screenshot of list of disks displayed from the selected capacity chart.
    7. Next をクリックします。
    8. メッセージアラートで Yes をクリックし、ストレージクラスの作成を確認します。

      ローカルボリュームセットおよびストレージクラスの作成後に、この手順に戻ることはできません。

    ストレージクラスターの作成

    図1.9 Create Storage Cluster ウィザードページ

    Screenshot of storage cluster creation.
    1. 必要なストレージクラスを選択します。

      選択したストレージクラスに対応するストレージノードが追加されるまでに数分待機する必要がある場合があります。

    2. (オプション) Encryption セクションで、トグルを Enabled に設定して、クラスターでデータ暗号化を有効にします。
    3. ストレージクラスに対応するノードは、ドロップダウン一覧で選択したストレージクラスに基づいて表示されます。
    4. Create をクリックします。

      Create ボタンは、最低でも 3 つのノードを選択した場合にのみ有効になります。3 つのボリュームからなる新規ストレージクラスターは、1 ワーカーノードごとに 1 つのボリュームを設定して作成されます。デフォルト設定では、レプリケーション係数 3 を使用します。

初期クラスターの容量を拡張するには、ストレージノードのスケーリング について参照してください。

検証手順

Verifying your OpenShift Container Storage installation を参照してください。

1.5. ストレージクラスが存在する場合の Red Hat Virtualization プラットフォームでのストレージクラスターの作成

Openshift Container Storage Cluster は、ローカルストレージ Operator ページで作成される既存のストレージクラスを使用して作成できます。

前提条件

  • ローカルストレージデバイスを使用した OpenShift Container Storage のインストールの要件 についてのセクションにあるすべての要件を満たしていることを確認します。
  • ベアメタルでローカルストレージデバイスを使用するには、ワーカーノードが最低でも 3 つ必要で、各ノードに同じストレージタイプおよびサイズを割り当てる必要があります (例: 2TB NVMe ハードドライブ)。
  • 最低でも 3 つのノードで設定されるストレージクラスを作成し、このクラスにボリュームをアタッチしておく必要があります。

手順

  1. OpenShift Web コンソールにログインします。
  2. Operators → Installed Operators をクリックし、インストールされた Operator をすべて表示します。

    選択された Projectopenshift-storage であることを確認します。

    図1.10 OpenShift Container Storage Operator ページ

    Screenshot of OpenShift Container Storage operator dashboard.
  3. OpenShift Container Storage をクリックします。

    図1.11 OpenShift Container Storage の Details タブ

    Screenshot of selected operator details tab.
  4. Storage Cluster の Create Instance リンクをクリックします。

    図1.12 Create Storage Cluster ページ

    Screenshot of Create Cluster Service page
  5. Select ModeInternal-Attached devices を選択します。デフォルトでは、Internal が選択されます。

    図1.13 Create Storage Cluster ページ

    Screenshot of storage cluster creation page.
  6. (オプション) Encryption セクションで、トグルを Enabled に設定して、クラスターでデータ暗号化を有効にします。
  7. 選択したストレージクラスに対応するノードが表示されます。

    選択されたノードには、ラベルが指定されていない場合に cluster.ocs.openshift.io/openshift-storage='' のラベルが付けられます。選択されたノードの内の 3 つのノードは初期のデプロイメントに使用され、残りのノードは OpenShift Container Storage のスケーリングのスケジュールターゲットとして使用されます。

  8. Create をクリックします。

    Create ボタンは、最低でも 3 つのノードを選択した場合にのみ有効になります。

    3 つのボリュームからなる新規ストレージクラスターは、1 ワーカーノードごとに 1 つのボリュームを設定して作成されます。デフォルト設定では、レプリケーション係数 3 を使用します。

初期クラスターの容量を拡張するには、ストレージノードのスケーリング について参照してください。

検証手順

Verifying your OpenShift Container Storage installation を参照してください。

第2章 OpenShift Container Storage デプロイメントの検証

このセクションを使用して、OpenShift Container Storage が正常にデプロイされていることを確認します。

2.1. Pod の状態の確認

OpenShift Container Storage が正常にデプロイされているかどうかを判別するために、Pod の状態が Running であることを確認できます。

手順

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

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

  3. Running および Completed タブをクリックして、以下の Pod が実行中および完了状態にあることを確認します。

    表2.1 OpenShift Container Storage クラスターに対応する Pod

    コンポーネント対応する Pod

    OpenShift Container Storage Operator

    • ocs-operator-* (任意のワーカーノードに 1 Pod)
    • ocs-metrics-exporter-*

    Rook-ceph Operator

    rook-ceph-operator-*

    (任意のワーカーノードに 1 Pod)

    Multicloud Object Gateway

    • noobaa-operator-* (任意のワーカーノードに 1 Pod)
    • noobaa-core-* (任意のストレージノードに 1 Pod)
    • noobaa-db-* (任意のストレージノードに 1 Pod)
    • noobaa-endpoint-* (任意のストレージノードに 1 Pod)

    MON

    rook-ceph-mon-*

    (ストレージノードに分散する 3 Pod)

    MGR

    rook-ceph-mgr-*

    (任意のストレージノードに 1 Pod)

    MDS

    rook-ceph-mds-ocs-storagecluster-cephfilesystem-*

    (ストレージノードに分散する 2 Pod)

    RGW

    rook-ceph-rgw-ocs-storagecluster-cephobjectstore-* (ストレージノードに分散する 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-crashcollector

    rook-ceph-crashcollector-*

    (各ストレージノードに 1 Pod)

    OSD

    • rook-ceph-osd-* (各デバイス用に 1 Pod)
    • rook-ceph-osd-prepare-ocs-deviceset-* (各デバイス用に 1 Pod)

2.2. OpenShift Container Storage クラスターが正常であることの確認

  • OpenShift Web コンソールの左側のペインから Home → Overview をクリックし、Persistent Storage タブをクリックします。
  • Status カード で、以下のイメージのように OCS Cluster および Data Resiliency に緑色のチェックマークが表示されていることを確認します。

    図2.1 Persistent Storage Overview ダッシュボードの Health status カード

    Screenshot of Health card in persistent storage dashboard
  • Details カード で、以下のようにクラスター情報が表示されていることを確認します。

    サービス名
    OpenShift Container Storage
    クラスター名
    ocs-storagecluster-cephcluster
    プロバイダー
    oVirt
    モード
    内部
    バージョン
    ocs-operator-4.6.0

永続ストレージダッシュボードを使用して OpenShift Container Storage クラスターの正常性に関する詳細は、OpenShift Container Storage のモニターリング を参照してください。

2.3. Multicloud Object Gateway が正常であることの確認

  • OpenShift Web コンソールの左側のペインから Home → Overview をクリックし、Object Service タブをクリックします。
  • Status card で、Object ServiceData Resiliency の両方が Ready 状態 (緑のチェックマーク) にあることを確認します。

    図2.2 Object Service Overview ダッシュボードの Health status カード

    Screenshot of Health card in object service dashboard
  • Details カード で、MCG 情報が以下のように表示されることを確認します。

    サービス名
    OpenShift Container Storage
    システム名

    Multicloud Object Gateway

    RADOS Object Gateway

    プロバイダー
    oVirt
    バージョン
    ocs-operator-4.6.0

オブジェクトサービスダッシュボードを使用した OpenShift Container Storage クラスターの正常性については、OpenShift Container Storage のモニターリング を参照してください。

2.4. OpenShift Container Storage 固有のストレージクラスが存在することの確認

ストレージクラスがクラスターに存在することを確認するには、以下を実行します。

  • OpenShift Web コンソールの左側のペインから Storage → Storage Classes をクリックします。
  • 以下のストレージクラスが OpenShift Container Storage クラスターの作成時に作成されることを確認します。

    • ocs-storagecluster-ceph-rbd
    • ocs-storagecluster-cephfs
    • openshift-storage.noobaa.io
    • ocs-storagecluster-ceph-rgw

第3章 OpenShift Container Storage のアンインストール

3.1. 内部モードでの OpenShift Container Storage のアンインストール

このセクションの手順に従って OpenShift Container Storage をアンインストールします。

アノテーションのアンインストール

Storage Cluster のアノテーションは、アンインストールプロセスの動作を変更するために使用されます。アンインストールの動作を定義するために、ストレージクラスターに以下の 2 つのアノテーションが導入されました。

  • uninstall.ocs.openshift.io/cleanup-policy: delete
  • uninstall.ocs.openshift.io/mode: graceful

以下の表は、これらのアノテーションで使用できる各種値に関する情報を示しています。

表3.1 uninstall.ocs.openshift.io でアノテーションの説明をアンインストールする

Annotationデフォルト動作

cleanup-policy

delete

はい

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

cleanup-policy

Retain

いいえ

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

mode

graceful

はい

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

mode

forced

いいえ

Rook および NooBaa は、Rook および NooBaa を使用してプロビジョニングされた PVC/OBC がそれぞれ存在している場合でもアンインストールを続行します。

以下のコマンドを使用してアノテーションの値を編集し、クリーンアップポリシーまたはアンインストールモードを変更できます。

$ oc annotate storagecluster -n openshift-storage ocs-storagecluster uninstall.ocs.openshift.io/cleanup-policy="retain" --overwrite
storagecluster.ocs.openshift.io/ocs-storagecluster annotated
$ oc annotate storagecluster -n openshift-storage 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 によって提供されるストレージクラスを使用して永続ボリューム要求 (PVC) またはオブジェクトバケット要求 (OBC) を使用していないことを確認します。
  • カスタムリソース (カスタムストレージクラス、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 および OBC を削除します。

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

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

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

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

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

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

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

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

    4. OpenShift Container Storage を使用してプロビジョニングした PVC および OBC を削除します。

      • 以下に、OpenShift Container Storage を使用してプロビジョニングされる PVC および OBC を特定するサンプルスクリプトを示します。このスクリプトは、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 and OBCs"
                echo "======================================================================"
                oc get pvc  --all-namespaces --no-headers 2>/dev/null | grep $SC | grep -v -e "$NOOBAA_DB_PVC" -e "$NOOBAA_BACKINGSTORE_PVC"
                oc get obc  --all-namespaces --no-headers 2>/dev/null | grep $SC
                echo
        done
        注記

        クラウドプラットフォームの RGW_PROVISIONER を省略します。

      • OBC を削除します。

        $ oc delete obc <obc name> -n <project name>
      • 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 (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
  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. デバッグ 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 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 および Object Service タブが Cluster タブの横に表示されなくなることを確認します。

3.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 ...

3.2. OpenShift Container Storage からのモニターリングスタックの削除

このセクションでは、モニターリングスタックを OpenShift Container Storage からクリーンアップします。

モニターリングスタックの設定の一部として作成される PVC は openshift-monitoring namespace に置かれます。

前提条件

手順

  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

3.3. OpenShift Container Storage からの OpenShift Container Platform レジストリーの削除

このセクションを使用して、OpenShift Container Storage から OpenShift Container Platform レジストリーをクリーンアップします。代替ストレージを設定する必要がある場合は、イメージレジストリー を参照してください。

OpenShift Container Platform レジストリーの設定の一部として作成される PVC は openshift-image-registry namespace に置かれます。

前提条件

  • イメージレジストリーは OpenShift Container Storage PVC を使用するように設定されている必要があります。

手順

  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

3.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

第4章 ストレージクラスおよびストレージプール

OpenShift Container Storage Operator は、使用されるプラットフォームに応じてデフォルトのストレージクラスをインストールします。このデフォルトストレージクラスは Operator によって所有され、制御されるため、削除したり変更したりすることはできません。ただし、ストレージクラスの異なる動作が必要な場合は、カスタムストレージクラスを作成できます。

以下の機能を提供するストレージクラスにマップする複数のストレージプールを作成できます。

  • それぞれに高可用性のあるアプリケーションを有効にして、2 つのレプリカを持つ永続ボリュームを使用できるようにします。これにより、アプリケーションのパフォーマンスが向上する可能性があります。
  • 圧縮が有効にされているストレージクラスを使用して永続ボリューム要求の領域を節約します。
注記

複数のストレージクラスおよび複数のプールは、外部モード の OpenShift Container Storage クラスターではサポートされません。

注記

単一デバイスセットの最小クラスターで新規作成できるストレージクラスは、2 つだけです。ストレージクラスターを拡張するたびに、新規ストレージクラスを 2 つ追加できます。

4.1. ストレージクラスおよびプールの作成

既存のプールを使用してストレージクラスを作成するか、またはストレージクラスの作成中にストレージクラスの新規プールを作成できます。

前提条件

OpenShift Container Storage クラスターが Ready 状態にあることを確認します。

手順

  1. OpenShift Web コンソールにログインします。
  2. StorageStorage Classes をクリックします。
  3. Create Storage Class をクリックします。
  4. ストレージクラスの Name および Description を入力します。
  5. Reclaim Policy について Delete または Retain のいずれかを選択します。デフォルトでは、Delete が選択されます。
  6. 永続ボリュームのプロビジョニングに使用されるプラグインである RBD Provisioner を選択します。
  7. 新規プールを作成するか、または既存プールを使用できます。

    新規プールを作成します。
    1. プールの名前を入力します。
    2. Data Protection Policy として 2-way-Replication または 3-way-Replication を選択します。
    3. データを圧縮する必要がある場合は、Enable compression を選択します。

      圧縮を有効にするとアプリケーションのパフォーマンスに影響がある可能性があり、書き込まれるデータがすでに圧縮または暗号化されている場合は効果的ではない可能性があります。圧縮を有効にする前に書き込まれたデータは圧縮されません。

    4. Create をクリックしてストレージクラスを作成します。
    5. プールの作成後に Finish をクリックします。
    6. Create をクリックしてストレージクラスを作成します。
    既存プールを使用します。
    1. 一覧からプールを選択します。
    2. Create をクリックしてプールが選択されたストレージクラスを作成します。

第5章 OpenShift Container Platform サービスのストレージの設定

OpenShift Container Storage を使用して、イメージレジストリー、モニターリング、およびロギングなどの OpenShift Container Platform サービスのストレージを提供できます。

これらのサービスのストレージを設定するプロセスは、OpenShift Container Storage デプロイメントで使用されるインフラストラクチャーによって異なります。

警告

これらのサービスに十分なストレージ容量があることを常に確認してください。これらの重要なサービスのストレージ領域が不足すると、クラスターは動作しなくなり、復元が非常に困難になります。

Red Hat は、これらのサービスのキュレーションおよび保持期間を短く設定することを推奨します。詳細は、OpenShift Container Platform ドキュメントの Curator スケジュールの設定 および 永続ストレージの設定 Prometheus メトリクスデータの保持時間の変更サブセクションを参照してください。

これらのサービスのストレージ領域が不足する場合は、Red Hat カスタマーサポートにお問い合わせください。

5.1. OpenShift Container Storage を使用するためのイメージレジストリーの設定

OpenShift Container Platform は、クラスターで標準ワークロードとして実行される、組み込まれたコンテナーイメージレジストリーを提供します。通常、レジストリーはクラスター上にビルドされたイメージの公開ターゲットとして、またクラスター上で実行されるワークロードのイメージのソースとして使用されます。

警告

このプロセスでは、データを既存イメージレジストリーから新規イメージレジストリーに移行しません。既存のレジストリーにコンテナーイメージがある場合、このプロセスを完了する前にレジストリーのバックアップを作成し、このプロセスの完了時にイメージを再登録します。

前提条件

  • OpenShift Web コンソールへの管理者アクセスがある。
  • OpenShift Container Storage Operator が openshift-storage namespace にインストールされ、実行されている。OpenShift Web コンソールで、OperatorsInstalled Operators をクリックし、インストールされた Operator を表示します。
  • イメージレジストリー Operator が openshift-image-registry namespace にインストールされ、実行されている。OpenShift Web コンソールで、AdministrationCluster SettingsCluster Operators をクリックしてクラスター Operator を表示します。
  • プロビジョナー openshift-storage.cephfs.csi.ceph.com を持つストレージクラスが利用可能である。OpenShift Web コンソールで、Storage → Storage Classes をクリックし、利用可能なストレージクラスを表示します。

手順

  1. 使用するイメージレジストリーの Persistent Volume Claim(永続ボリューム要求、PVC) を作成します。

    1. OpenShift Web コンソールで、StoragePersistent Volume Claims をクリックします。
    2. Projectopenshift-image-registry に設定します。
    3. Create Persistent Volume Claim をクリックします。

      1. 上記で取得した利用可能なストレージクラス一覧から、プロビジョナー openshift-storage.cephfs.csi.ceph.comStorage Class を指定します。
      2. Persistent Volume Claim(永続ボリューム要求、PVC) の Name を指定します (例: ocs4registry)。
      3. Shared Access (RWX)Access Mode を指定します。
      4. 100 GB 以上の Size を指定します。
      5. Create をクリックします。

        新規 Persistent Volume Claim(永続ボリューム要求、PVC) のステータスが Bound として一覧表示されるまで待機します。

  2. クラスターのイメージレジストリーを、新規の Persistent Volume Claim(永続ボリューム要求、PVC) を使用するように設定します。

    1. AdministrationCustom Resource Definitions をクリックします。
    2. imageregistry.operator.openshift.io グループに関連付けられた Config カスタムリソース定義をクリックします。
    3. Instances タブをクリックします。
    4. クラスターインスタンスの横にある Action メニュー (⋮)Edit Config をクリックします。
    5. イメージレジストリーの新規 Persistent Volume Claim(永続ボリューム要求、PVC) を追加します。

      1. 以下を spec: の下に追加し、必要に応じて既存の storage: セクションを置き換えます。

          storage:
            pvc:
              claim: <new-pvc-name>

        以下に例を示します。

          storage:
            pvc:
              claim: ocs4registry
      2. Save をクリックします。
  3. 新しい設定が使用されていることを確認します。

    1. WorkloadsPods をクリックします。
    2. Projectopenshift-image-registry に設定します。
    3. 新規 image-registry-* Pod が Running のステータスと共に表示され、以前の image-registry-* Pod が終了していることを確認します。
    4. 新規の image-registry-* Pod をクリックし、Pod の詳細を表示します。
    5. Volumes までスクロールダウンし、registry-storage ボリュームに新規 Persistent Volume Claim (永続ボリューム要求、PVC) に一致する Type があることを確認します (例: ocs4registry)。

5.2. OpenShift Container Storage を使用するためのモニターリングの設定

OpenShift Container Storage は、Prometheus および AlertManager で設定されるモニターリングスタックを提供します。

このセクションの手順に従って、OpenShift Container Storage をモニターリングスタックのストレージとして設定します。

重要

ストレージ領域が不足すると、モニターリングは機能しません。モニタリング用に十分なストレージ容量があることを常に確認します。

Red Hat は、このサービスの保持期間を短く設定することを推奨します。詳細は、OpenShift Container Platform ドキュメントのモニターリングガイドの Prometheus メトリクスデータの保持期間の編集 を参照してください。

前提条件

  • OpenShift Web コンソールへの管理者アクセスがある。
  • OpenShift Container Storage Operator が openshift-storage namespace にインストールされ、実行されている。OpenShift Web コンソールで、OperatorsInstalled Operators をクリックし、インストールされた Operator を表示します。
  • モニターリング Operator が openshift-monitoring namespace にインストールされ、実行されている。OpenShift Web コンソールで、AdministrationCluster SettingsCluster Operators をクリックしてクラスター Operator を表示します。
  • プロビジョナー openshift-storage.rbd.csi.ceph.com を持つストレージクラスが利用可能である。OpenShift Web コンソールで、Storage → Storage Classes をクリックし、利用可能なストレージクラスを表示します。

手順

  1. OpenShift Web コンソールで、WorkloadsConfig Maps に移動します。
  2. Project ドロップダウンを openshift-monitoring に設定します。
  3. Create Config Map をクリックします。
  4. 以下の例を使用して新規の cluster-monitoring-config Config Map を定義します。

    山括弧 (<, >) 内の内容を独自の値に置き換えます (例: retention: 24h または storage: 40Gi)。

    storageClassName、をプロビジョナー openshift-storage.rbd.csi.ceph.com を使用する storageclass に置き換えます。以下の例では、storageclass の名前は ocs-storagecluster-ceph-rbd です。

    cluster-monitoring-config Config Map の例

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
          prometheusK8s:
            retention: <time to retain monitoring files, e.g. 24h>
            volumeClaimTemplate:
              metadata:
                name: ocs-prometheus-claim
              spec:
                storageClassName: ocs-storagecluster-ceph-rbd
                resources:
                  requests:
                    storage: <size of claim, e.g. 40Gi>
          alertmanagerMain:
            volumeClaimTemplate:
              metadata:
                name: ocs-alertmanager-claim
              spec:
                storageClassName: ocs-storagecluster-ceph-rbd
                resources:
                  requests:
                    storage: <size of claim, e.g. 40Gi>

  5. Create をクリックして、設定マップを保存し、作成します。

検証手順

  1. Persistent Volume Claim (永続ボリューム要求、PVC) が Pod にバインドされていることを確認します。

    1. StoragePersistent Volume Claims に移動します。
    2. Project ドロップダウンを openshift-monitoring に設定します。
    3. 5 つの Persistent Volume Claim(永続ボリューム要求、PVC) が Bound (バインド) の状態で表示され、3 つの alertmanager-main-* Pod および 2 つの prometheus-k8s-* Pod に割り当てられていることを確認します。

      作成済みのバインドされているストレージのモニタリング

      Screenshot of OpenShift Web Console showing five pods with persistent volume claims bound in the openshift-monitoring project

  2. 新規の alertmanager-main-* Pod が Running 状態で表示されることを確認します。

    1. Workloads → Pods に移動します。
    2. 新規の alertmanager-main-* Pod をクリックし、Pod の詳細を表示します。
    3. Volumes にスクロールダウンし、ボリュームに新規 Persistent Volume Claim(永続ボリューム要求、PVC) のいずれかに一致する Type ocs-alertmanager-claim があることを確認します (例: ocs-alertmanager-claim-alertmanager-main-0)。

      alertmanager-main-* Pod に割り当てられた Persistent Volume Claim (永続ボリューム要求、PVC)

      Screenshot of OpenShift Web Console showing persistent volume claim attached to the altermanager pod

  3. 新規 prometheus-k8s-* Pod が Running 状態で表示されることを確認します。

    1. 新規 prometheus-k8s-* Pod をクリックし、Pod の詳細を表示します。
    2. Volumes までスクロールダウンし、ボリュームに新規の Persistent Volume Claim (永続ボリューム要求、PVC) のいずれかに一致する Type ocs-prometheus-claim があることを確認します (例: ocs-prometheus-claim-prometheus-k8s-0)。

      prometheus-k8s-* Pod に割り当てられた Persistent Volume Claim(永続ボリューム要求、PVC)

      Screenshot of OpenShift Web Console showing persistent volume claim attached to the prometheus pod

5.3. OpenShift Container Storage のクラスターロギング

クラスターロギングをデプロイして、各種の OpenShift Container Platform サービスについてのログを集計できます。クラスターロギングのデプロイ方法については、クラスターロギングのデプロイ を参照してください。

OpenShift Container Platform の初回のデプロイメントでは、OpenShift Container Storage はデフォルトで設定されず、OpenShift Container Platform クラスターはノードから利用可能なデフォルトストレージのみに依存します。OpenShift ロギング (ElasticSearch) のデフォルト設定を OpenShift Container Storage で対応されるように編集し、OpenShift Container Storage でサポートされるロギング (Elasticsearch) を設定できます。

重要

これらのサービスに十分なストレージ容量があることを常に確認してください。これらの重要なサービスのストレージ領域が不足すると、ロギングアプリケーションは動作しなくなり、復元が非常に困難になります。

Red Hat は、これらのサービスのキュレーションおよび保持期間を短く設定することを推奨します。詳細は、OpenShift Container Platform ドキュメントで クラスターロギング Curator について参照してください。

これらのサービスのストレージ領域が不足している場合は、Red Hat カスタマーポータルにお問い合わせください。

5.3.1. 永続ストレージの設定

ストレージクラス名およびサイズパラメーターを使用して、 Elasticsearch クラスターの永続ストレージクラスおよびサイズを設定できます。Cluster Logging Operator は、これらのパラメーターに基づいて、Elasticsearch クラスターの各データノードについて Persistent Volume Claim (永続ボリューム要求、PVC) を作成します。以下に例を示します。

spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage:
          storageClassName: "ocs-storagecluster-ceph-rbd”
          size: "200G"

この例では、クラスター内の各データノードが 200GiBocs-storagecluster-ceph-rbd ストレージを要求する Persistent Volume Claim(永続ボリューム要求、PVC) にバインドされるように指定します。それぞれのプライマリーシャードは単一のレプリカによってサポートされます。シャードのコピーはすべてのノードにレプリケートされ、常に利用可能となり、冗長性ポリシーにより 2 つ以上のノードが存在する場合にコピーを復元できます。Elasticsearch レプリケーションポリシーについての詳細は、クラスターロギングのデプロイおよび設定についてElasticsearch レプリケーションポリシーについて参照してください。

注記

ストレージブロックを省略すると、デプロイメントはデフォルトのストレージでサポートされます。以下に例を示します。

spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage: {}

詳細は、クラスターロギングの設定 を参照してください。

5.3.2. OpenShift Container Storage を使用するためのクラスターロギングの設定

このセクションの手順に従って、OpenShift Container Storage を OpenShift クラスターロギングのストレージとして設定します。

注記

OpenShift Container Storage でロギングを初めて設定する際にすべてのログを取得できます。ただし、ロギングをアンインストールして再インストールすると、古いログが削除され、新しいログのみが処理されます。

前提条件

  • OpenShift Web コンソールへの管理者アクセスがある。
  • OpenShift Container Storage Operator が openshift-storage namespace にインストールされ、実行されている。
  • Cluster Logging Operator が openshift-logging namespace にインストールされ、実行されている。

手順

  1. OpenShift Web コンソールの左側のペインから Administration → Custom Resource Definitions をクリックします。
  2. Custom Resource Definitions ページで、ClusterLogging をクリックします。
  3. Custom Resource Definition Overview ページで、Actions メニューから View Instances を選択するか、または Instances タブをクリックします。
  4. Cluster Logging ページで、Create Cluster Logging をクリックします。

    データを読み込むためにページを更新する必要がある場合があります。

  5. YAML において、storageClassName、をプロビジョナー openshift-storage.rbd.csi.ceph.com を使用する storageclass に置き換えます。以下の例では、storageclass の名前は ocs-storagecluster-ceph-rbd です。

    apiVersion: "logging.openshift.io/v1"
    kind: "ClusterLogging"
    metadata:
      name: "instance"
      namespace: "openshift-logging"
    spec:
      managementState: "Managed"
      logStore:
        type: "elasticsearch"
        elasticsearch:
          nodeCount: 3
          storage:
            storageClassName: ocs-storagecluster-ceph-rbd
            size: 200G # Change as per your requirement
          redundancyPolicy: "SingleRedundancy"
      visualization:
        type: "kibana"
        kibana:
          replicas: 1
      curation:
        type: "curator"
        curator:
          schedule: "30 3 * * *"
      collection:
        logs:
          type: "fluentd"
          fluentd: {}

    OpenShift Container Storage ノードにテイントのマークが付けられている場合、ロギング用に daemonset Pod のスケジューリングを有効にするために容認を追加する必要があります。

    spec:
    [...]
      collection:
        logs:
          fluentd:
            tolerations:
            - effect: NoSchedule
              key: node.ocs.openshift.io/storage
              value: 'true'
          type: fluentd
  6. Save をクリックします。

検証手順

  1. Persistent Volume Claim(永続ボリューム要求、PVC) が elasticsearch Pod にバインドされていることを確認します。

    1. StoragePersistent Volume Claims に移動します。
    2. Project ドロップダウンを openshift-logging に設定します。
    3. Persistent Volume Claim(永続ボリューム要求、PVC) が elasticsearch-* Pod に割り当てられ、Bound (バインド) の状態で表示されることを確認します。

      図5.1 作成済みのバインドされたクラスターロギング

      Screenshot of Persistent Volume Claims with a bound state attached to elasticsearch pods
  2. 新規クラスターロギングが使用されていることを確認します。

    1. Workload → Pods をクリックします。
    2. プロジェクトを openshift-logging に設定します。
    3. 新規の elasticsearch-* Pod が Running 状態で表示されることを確認します。
    4. 新規の elasticsearch-* Pod をクリックし、Pod の詳細を表示します。
    5. Volumes までスクロールダウンし、elasticsearch ボリュームに新規 Persistent Volume Claim (永続ボリューム要求、PVC) に一致する Type があることを確認します (例: elasticsearch-elasticsearch-cdm-9r624biv-3)。
    6. Persistent Volume Claim(永続ボリューム要求、PVC) の名前をクリックし、PersistenVolumeClaim Overview ページでストレージクラス名を確認します。
注記

Elasticsearch Pod に割り当てられる PV の詳細シナリオを回避するために、キュレーターの時間を短くして使用するようにしてください。

Curator を、保持設定に基づいて Elasticsearch データを削除するように設定できます。以下の 5 日間のインデックスデータの保持期間をデフォルトとして設定することが推奨されます。

config.yaml: |
    openshift-storage:
      delete:
        days: 5

詳細は、Elasticsearch データのキュレーション を参照してください。

注記

Persistent Volume Claim(永続ボリューム要求、PVC) がサポートするクラスターロギングをアンインストールするには、それぞれのデプロイメントガイドのアンインストールについての章に記載されている、クラスターロギング Operator の OpenShift Container Storage からの削除についての手順を使用します。

第6章 OpenShift Container Storage を使用した OpenShift Container Platform アプリケーションのサポート

OpenShift Container Platform のインストール時に OpenShift Container Storage を直接インストールすることはできません。ただし、Operator Hub を使用して OpenShift Container Platform を既存の OpenShift Container Platform にインストールし、OpenShift Container Platform アプリケーションを OpenShift Container Storage でサポートされるように設定することができます。

前提条件

  • OpenShift Container Platform がインストールされ、OpenShift Web コンソールへの管理者アクセスがある。
  • OpenShift Container Storage が openshift-storage namespace にインストールされ、実行されている。

手順

  1. OpenShift Web コンソールで、以下のいずれかを実行します。

    • Workloads → Deployments をクリックします。

      Deployments ページで、以下のいずれかを実行できます。

      • 既存のデプロイメントを選択し、Action メニュー (⋮) から Add Storage オプションをクリックします。
      • 新規デプロイメントを作成してからストレージを追加します。

        1. Create Deployment をクリックして新規デプロイメントを作成します。
        2. 要件に応じて YAML を編集し、デプロイメントを作成します。
        3. Create をクリックします。
        4. ページ右上の Actions ドロップダウンメニューから Add Storage を選択します。
    • Workloads → Deployment Configs をクリックします。

      Deployment Configs ページで、以下のいずれかを実行できます。

      • 既存のデプロイメントを選択し、Action メニュー (⋮) から Add Storage オプションをクリックします。
      • 新規デプロイメントを作成してからストレージを追加します。

        1. Create Deployment Config をクリックし、新規デプロイメントを作成します。
        2. 要件に応じて YAML を編集し、デプロイメントを作成します。
        3. Create をクリックします。
        4. ページ右上の Actions ドロップダウンメニューから Add Storage を選択します。
  2. Add Storage ページで、以下のオプションのいずれかを選択できます。

    • Use existing claim オプションをクリックし、ドロップダウンリストから適切な PVC を選択します。
    • Create new claim オプションをクリックします。

      1. Storage Class ドロップダウンリストから適切な CephFS または RBD ストレージクラスを選択します。
      2. Persistent Volume Claim (永続ボリューム要求、PVC) の名前を指定します。
      3. ReadWriteOnce (RWO) または ReadWriteMany (RWX) アクセスモードを選択します。

        注記

        ReadOnlyMany (ROX) はサポートされないため、非アクティブになります。

      4. 必要なストレージ容量のサイズを選択します。

        注記

        ブロック PV を拡張することはできますが、Persistent Volume Claim (永続ボリューム要求: PVC) の作成後にストレージ容量のサイズを縮小することはできません。

  3. コンテナー内のマウントパスボリュームのマウントパスとサブパス (必要な場合) を指定します。
  4. Save をクリックします。

検証手順

  1. 設定に応じて、以下のいずれかを実行します。

    • Workloads → Deployments をクリックします。
    • Workloads → Deployment Configs をクリックします。
  2. 必要に応じてプロジェクトを設定します。
  3. ストレージを追加したデプロイメントをクリックして、デプロイメントの詳細を表示します。
  4. Volumes までスクロールダウンし、デプロイメントに、割り当てた Persistent Volume Claim(永続ボリューム要求、PVC) に一致する Type があることを確認します。
  5. Persistent Volume Claim(永続ボリューム要求、PVC) の名前をクリックし、Persistent Volume Claim Overview ページでストレージクラス名を確認します。

第7章 Red Hat OpenShift Container Storage に専用のワーカーノードを使用する方法

インフラストラクチャーノードを使用して Red Hat OpenShift Container Storage リソースをスケジュールすると、Red Hat OpenShift Container Platform サブスクリプションコストを節約できます。infra ノードロールのラベルのある Red Hat OpenShift Container Platform (RHOCP) ノードには OpenShift Container Storage サブスクリプションが必要ですが、RHOCP サブスクリプションは必要ありません。

マシン API サポートの有無にかかわらず複数の環境全体で一貫性を維持することが重要です。そのため、いずれの場合でも、worker または infra のいずれかのラベルが付けられたノードの特別なカテゴリーや、両方のロールを使用できるようにすることが強く推奨されます。詳細は、「インフラストラクチャーノードの手動作成」セクションを参照してください。

7.1. インフラストラクチャーノードの仕組み

OpenShift Container Storage で使用するインフラストラクチャーノードにはいくつかの属性があります。ノードが RHOCP エンタイトルメントを使用しないようにするには、infra ノードロールのラベルが必要です。infra ノードロールラベルは、OpenShift Container Storage を実行するノードには OpenShift Container Storage エンタイトルメントのみが必要となるようにします。

  • node-role.kubernetes.io/infra のラベル

infra ノードが OpenShift Container Storage リソースのみをスケジュールできるようにするには、NoSchedule effect のある OpenShift Container Storage テイントを追加する必要もあります。

  • node.ocs.openshift.io/storage="true" のテイント

RHOCP サブスクリプションコストが適用されないように、ラベルは RHOCP ノードを infra ノードとして識別します。テイントは、OpenShift Container Storage 以外のリソースがテイントのマークが付けられたノードでスケジュールされないようにします。

OpenShift Container Storage サービスの実行に使用されるインフラストラクチャーノードで必要なテイントおよびラベルの例:

    spec:
      taints:
      - effect: NoSchedule
        key: node.ocs.openshift.io/storage
        value: "true"
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/worker: ""
          node-role.kubernetes.io/infra: ""
          cluster.ocs.openshift.io/openshift-storage: ""

7.2. インフラストラクチャーノードを作成するためのマシンセット

マシン API が環境でサポートされている場合には、インフラストラクチャーノードのプロビジョニングを行うマシンセットのテンプレートにラベルを追加する必要があります。ラベルをマシン API によって作成されるノードに手動で追加するアンチパターンを回避します。これを実行することは、デプロイメントで作成される Pod にラベルを追加することに似ています。いずれの場合も、Pod/ノードが失敗する場合、置き換え用の Pod/ノードには適切なラベルがありません。

注記

EC2 環境では、3 つのマシンセットが必要です。それぞれは、異なるアベイラビリティーゾーン (us-east-2a、us-east-2b、us-east-2c など) でインフラストラクチャーノードをプロビジョニングするように設定されます。現時点で、OpenShift Container Storage は 4 つ以上のアベイラビリティーゾーンへのデプロイをサポートしていません。

以下の Machine Set テンプレートのサンプルは、インフラストラクチャーノードに必要な適切なテイントおよびラベルを持つノードを作成します。これは OpenShift Container Storage サービスを実行するために使用されます。

  template:
    metadata:
      creationTimestamp: null
      labels:
        machine.openshift.io/cluster-api-cluster: kb-s25vf
        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: kb-s25vf-infra-us-west-2a
    spec:
      taints:
      - effect: NoSchedule
        key: node.ocs.openshift.io/storage
        value: "true"
      metadata:
        creationTimestamp: null
        labels:
          node-role.kubernetes.io/infra: ""
          cluster.ocs.openshift.io/openshift-storage: ""

7.3. インフラストラクチャーノードの手動作成

マシン API が環境内でサポートされない場合にのみ、ラベルはノードに直接適用される必要があります。手動作成では、OpenShift Container Storage サービスをスケジュールするために少なくとも 3 つの RHOCP ワーカーノードが利用可能であり、これらのノードに CPU およびメモリーリソースが十分にある必要があります。RHOCP サブスクリプションコストの発生を防ぐには、以下が必要です。

oc label node <node> node-role.kubernetes.io/infra=""
oc label node <node> cluster.ocs.openshift.io/openshift-storage=""

また、NoSchedule OpenShift Container Storage テイントを追加することも、infra ノードが OpenShift Container Storage リソースのみをスケジュールし、その他の OpenShift Container Storage ワークロードを拒否できるようにするために必要です。

oc adm taint node <node> node.ocs.openshift.io/storage="true":NoSchedule
警告

ノードロール node-role.kubernetes.io/worker="" は削除しないでください。

node-role.kubernetes.io/worker="" ノードロールを削除すると、OpenShift スケジューラーおよび MachineConfig リソースの両方に変更が加えられない場合に問題が発生する可能性があります。

すでに削除されている場合は、各 infra ノードに再度追加する必要があります。node-role.kubernetes.io/infra="" ノードロールおよび OpenShift Container Storage テイントを追加するだけで、エンタイトルメント免除要件を満たすことができます。

第8章 ストレージノードのスケーリング

OpenShift Container Storage のストレージ容量をスケーリングするには、以下のいずれかを実行できます。

  • ストレージノードのスケールアップ: 既存の OpenShift Container Storage ワーカーノードに対してストレージ容量を追加します。
  • ストレージノードのスケールアウト: ストレージ容量を含む新規ワーカーノードを追加します。

8.1. ストレージノードのスケーリングの要件

ストレージノードをスケーリングする前に、以下のセクションを参照して、特定の Red Hat OpenShift Container Storage インスタンスのノード要件を把握してください。

警告

常にストレージ容量が十分にあることを確認してください。

ストレージが完全に一杯になると、容量を追加したり、ストレージからコンテンツを削除したり、コンテンツを移動して領域を解放することはできません。完全なストレージを復元することは非常に困難です。

容量アラートは、クラスターストレージ容量が合計容量の 75% (ほぼ一杯) および 85% (一杯) になると発行されます。容量についての警告に常に迅速に対応し、ストレージを定期的に確認して、ストレージ領域が不足しないようにします。

ストレージ領域が不足する場合は、Red Hat カスタマーポータルにお問い合わせください。

8.2. ローカルストレージデバイスを使用した OpenShift Container Storage ノードへの容量の追加によるストレージのスケールアップ

以下の手順を使用して、Red Hat Virtualization インフラストラクチャーで設定されたローカルストレージベースの OpenShift Container Storage ワーカーノードにストレージ容量 (追加のストレージデバイス) を追加します。

前提条件

  • OpenShift Container Platform クラスターにログインしている必要があります。
  • ローカルストレージ Operator がインストールされている必要があります。ローカルストレージ Operator のインストール を参照してください。
  • 以前のバージョンの OpenShift Container Storage からアップグレードした場合は、更新後の設定の変更 で説明されているように、LocalVolumeSet オブジェクトを作成し、デバイスの自動プロビジョニングを有効にします。
  • 以前のバージョンから OpenShift Container Storage 4.6 にアップグレードした場合、アップグレード後の手順に従って LocalVolumeDiscovery オブジェクトを作成していることを確認します。詳細は、更新後の設定の変更 について参照してください。
  • 3 つの OpenShift Container Platform ワーカーノードが必要です。それらのノードには、元の OpenShift Container Storage の StorageCluster の作成に使用されたものと同じストレージタイプおよびサイズ (例: 2 TB NVMe ドライブ) が割り当てられている必要があります。

手順

容量を追加するには、デプロイメント時にプロビジョニングしたストレージクラスか、フィルターと合致する他のストレージクラスを使用できます。

  1. OpenShift Web コンソールから、OperatorsInstalled Operators をクリックします。

    ocs installed operators
  2. OpenShift Container Storage Operator をクリックします。
  3. Storage Cluster タブをクリックします。

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

    ocs add capacity dialog menu lso
  6. 要件に応じてディスクを追加した Storage Class、または新規ストレージクラスを選択します。表示される利用可能な容量は、ストレージクラスで利用可能なローカルディスクをベースとしています。
  7. Add をクリックします。

    ストレージクラスターが Ready 状態になるまでに数分待機する必要がある場合があります。

検証手順

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

    ocs add capacity expansion verification capacity card bm

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

  • 3 つの新規 OSD およびそれらの対応する新規 PVC が作成されていることを確認します。

    • 新規作成された OSD の状態を表示するには、以下を実行します。

      1. OpenShift Web コンソールから WorkloadsPods をクリックします。
      2. Project ドロップダウンリストから openshift-storage を選択します。
    • Pod の状態を確認します。

      1. OpenShift Web コンソールで、StoragePersistent Volume Claims をクリックします。
      2. Project ドロップダウンリストから openshift-storage を選択します。
  • (オプション) クラスターでデータの暗号化が有効な場合には、新規 OSD デバイスが暗号化されていることを確認します。

    1. 新規 OSD Pod が実行しているノードを特定します。

      $ oc get -o=custom-columns=NODE:.spec.nodeName pod/<OSD pod name>

      以下に例を示します。

      oc get -o=custom-columns=NODE:.spec.nodeName pod/rook-ceph-osd-0-544db49d7f-qrgqm
    2. 直前の手順で特定されたノードごとに、以下を実行します。

      1. デバッグ Pod を作成し、選択したホストの chroot 環境を開きます。

        $ oc debug node/<node name>
        $ chroot /host
      2. lsblk を実行し、ocs-deviceset 名の横にある crypt キーワードを確認します。

        $ lsblk
重要

OpenShift Container Storage では、OSD またはノードの縮小によるクラスターの削減はサポートしていません。

8.3. 新規ノードの追加によるストレージ容量のスケールアウト

ストレージ容量をスケールアウトするには、以下を実行する必要があります。

  • 既存のワーカーノードがサポートされる最大 OSD (初期設定で選択される容量の 3 OSD の増分) で実行されている場合には、ストレージの容量を増やすために新規ノードを追加します。
  • 新規ノードが正常に追加されたことを確認します。
  • ノードが追加された後にストレージ容量をスケールアップします。

8.3.1. ローカルストレージデバイスを使用したノードの追加

以下の手順を使用して、Red Hat Virtualization インフラストラクチャーにノードを追加します。

前提条件

  • OpenShift Container Platform (RHOCP) クラスターにログインしている必要があります。
  • 以前のバージョンから OpenShift Container Storage 4.6 にアップグレードした場合、アップグレード後の手順に従って LocalVolumeDiscovery オブジェクトを作成していることを確認します。詳細は、更新後の設定の変更 について参照してください。
  • 3 つの OpenShift Container Platform ワーカーノードが必要です。それらのノードには、元の OpenShift Container Storage の StorageCluster の作成に使用されたものと同じストレージタイプおよびサイズ (例: 2TB SSD または 2TB NVMe) が割り当てられている必要があります。
  • 以前のバージョンの OpenShift Container Storage からアップグレードした場合は、更新後の設定の変更 で説明されているように、LocalVolumeSet オブジェクトを作成し、デバイスの自動プロビジョニングを有効にします。

手順

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

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

    $ oc adm certificate approve <Certificate_Name>
  5. ComputeNodes をクリックし、新規ノードが Ready 状態にあることを確認します。
  6. 以下のいずれかを使用して、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=""
  7. OpenShift Web コンソールから、OperatorsInstalled Operators をクリックします。

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

  8. Local Storage をクリックします。
  9. Local Volume Discovery タブをクリックします。
  10. LocalVolumeDiscovery の横にある Action メニュー (⋮) → Edit Local Volume Discovery をクリックします。
  11. YAML で、node selector の下にある values フィールドに新規ノードのホスト名を追加します。
  12. Save をクリックします。
  13. Local Volume Sets タブをクリックします。
  14. LocalVolumeSet の横にある Action メニュー (⋮)Edit Local Volume Set をクリックします。
  15. YAML で、node selector の下にある values フィールドに新規ノードのホスト名を追加します。

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

    Screenshot of YAML showing the addition of new hostnames.
  16. Save をクリックします。
注記

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

検証手順

8.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-*

8.3.3. ストレージ容量のスケールアップ

新規ノードを OpenShift Container Storage に追加した後に、容量の追加によるストレージのスケールアップ に説明されているようにストレージ容量をスケールアップする必要があります。

第9章 Multicloud Object Gateway

9.1. Multicloud Object Gateway について

Multicloud Object Gateway (MCG) は OpenShift の軽量オブジェクトストレージサービスであり、ユーザーは必要に応じて、複数のクラスター、およびクラウドネイティブストレージを使用して、オンプレミスで小規模に開始し、その後にスケーリングできます。

9.2. アプリケーションの使用による Multicloud Object Gateway へのアクセス

AWS S3 を対象とするアプリケーションまたは AWS S3 Software Development Kit(SDK) を使用するコードを使用して、オブジェクトサービスにアクセスできます。アプリケーションは、MCG エンドポイント、アクセスキー、およびシークレットアクセスキーを指定する必要があります。ターミナルまたは MCG CLI を使用して、この情報を取得できます。

前提条件

  • 実行中の OpenShift Container Storage Platform
  • MCG コマンドラインインターフェイスをダウンロードして、管理を容易にします。

    # subscription-manager repos --enable=rh-ocs-4-for-rhel-8-x86_64-rpms
    # yum install mcg
  • または、mcg パッケージを、Download RedHat OpenShift Container Storage ページにある OpenShift Container Storage RPM からインストールできます。

関連するエンドポイント、アクセスキー、およびシークレットアクセスキーには、以下の 2 つの方法でアクセスできます。

重要

仮想ホストスタイルを使用してクライアントアプリケーションを MCG バケットを参照するように、DNS エントリーがあることを確認します。

9.2.1. ターミナルから Multicloud Object Gateway へのアクセス

手順

describe コマンドを実行し、アクセスキー (AWS_ACCESS_KEY_ID 値) およびシークレットアクセスキー (AWS_SECRET_ACCESS_KEY 値) を含む MCG エンドポイントについての情報を表示します。

# oc describe noobaa -n openshift-storage

出力は以下のようになります。

Name:         noobaa
Namespace:    openshift-storage
Labels:       <none>
Annotations:  <none>
API Version:  noobaa.io/v1alpha1
Kind:         NooBaa
Metadata:
  Creation Timestamp:  2019-07-29T16:22:06Z
  Generation:          1
  Resource Version:    6718822
  Self Link:           /apis/noobaa.io/v1alpha1/namespaces/openshift-storage/noobaas/noobaa
  UID:                 019cfb4a-b21d-11e9-9a02-06c8de012f9e
Spec:
Status:
  Accounts:
    Admin:
      Secret Ref:
        Name:           noobaa-admin
        Namespace:      openshift-storage
  Actual Image:         noobaa/noobaa-core:4.0
  Observed Generation:  1
  Phase:                Ready
  Readme:

  Welcome to NooBaa!
  -----------------

  Welcome to NooBaa!
    -----------------
    NooBaa Core Version:
    NooBaa Operator Version:

    Lets get started:

    1. Connect to Management console:

      Read your mgmt console login information (email & password) from secret: "noobaa-admin".

        kubectl get secret noobaa-admin -n openshift-storage -o json | jq '.data|map_values(@base64d)'

      Open the management console service - take External IP/DNS or Node Port or use port forwarding:

        kubectl port-forward -n openshift-storage service/noobaa-mgmt 11443:443 &
        open https://localhost:11443

    2. Test S3 client:

      kubectl port-forward -n openshift-storage service/s3 10443:443 &
1
      NOOBAA_ACCESS_KEY=$(kubectl get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_ACCESS_KEY_ID|@base64d')
2
      NOOBAA_SECRET_KEY=$(kubectl get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_SECRET_ACCESS_KEY|@base64d')
      alias s3='AWS_ACCESS_KEY_ID=$NOOBAA_ACCESS_KEY AWS_SECRET_ACCESS_KEY=$NOOBAA_SECRET_KEY aws --endpoint https://localhost:10443 --no-verify-ssl s3'
      s3 ls


    Services:
      Service Mgmt:
        External DNS:
          https://noobaa-mgmt-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com
          https://a3406079515be11eaa3b70683061451e-1194613580.us-east-2.elb.amazonaws.com:443
        Internal DNS:
          https://noobaa-mgmt.openshift-storage.svc:443
        Internal IP:
          https://172.30.235.12:443
        Node Ports:
          https://10.0.142.103:31385
        Pod Ports:
          https://10.131.0.19:8443
      serviceS3:
        External DNS: 3
          https://s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com
          https://a340f4e1315be11eaa3b70683061451e-943168195.us-east-2.elb.amazonaws.com:443
        Internal DNS:
          https://s3.openshift-storage.svc:443
        Internal IP:
          https://172.30.86.41:443
        Node Ports:
          https://10.0.142.103:31011
        Pod Ports:
          https://10.131.0.19:6443
1
アクセスキー (AWS_ACCESS_KEY_ID 値)
2
シークレットアクセスキー (AWS_SECRET_ACCESS_KEY 値)
3
MCG エンドポイント
注記

oc describe noobaa コマンドには、利用可能な内部および外部 DNS 名が一覧表示されます。内部 DNS を使用する場合、トラフィックは無料になります。外部 DNS はロードバランシングを使用してトラフィックを処理するため、1 時間あたりのコストがかかります。

9.2.2. MCG コマンドラインインターフェイスからの Multicloud Object Gateway へのアクセス

前提条件

  • MCG コマンドラインインターフェイスをダウンロードします。

    # subscription-manager repos --enable=rh-ocs-4-for-rhel-8-x86_64-rpms
    # yum install mcg

手順

status コマンドを実行して、エンドポイント、アクセスキー、およびシークレットアクセスキーにアクセスします。

noobaa status -n openshift-storage

出力は以下のようになります。

INFO[0000] Namespace: openshift-storage
INFO[0000]
INFO[0000] CRD Status:
INFO[0003] ✅ Exists: CustomResourceDefinition "noobaas.noobaa.io"
INFO[0003] ✅ Exists: CustomResourceDefinition "backingstores.noobaa.io"
INFO[0003] ✅ Exists: CustomResourceDefinition "bucketclasses.noobaa.io"
INFO[0004] ✅ Exists: CustomResourceDefinition "objectbucketclaims.objectbucket.io"
INFO[0004] ✅ Exists: CustomResourceDefinition "objectbuckets.objectbucket.io"
INFO[0004]
INFO[0004] Operator Status:
INFO[0004] ✅ Exists: Namespace "openshift-storage"
INFO[0004] ✅ Exists: ServiceAccount "noobaa"
INFO[0005] ✅ Exists: Role "ocs-operator.v0.0.271-6g45f"
INFO[0005] ✅ Exists: RoleBinding "ocs-operator.v0.0.271-6g45f-noobaa-f9vpj"
INFO[0006] ✅ Exists: ClusterRole "ocs-operator.v0.0.271-fjhgh"
INFO[0006] ✅ Exists: ClusterRoleBinding "ocs-operator.v0.0.271-fjhgh-noobaa-pdxn5"
INFO[0006] ✅ Exists: Deployment "noobaa-operator"
INFO[0006]
INFO[0006] System Status:
INFO[0007] ✅ Exists: NooBaa "noobaa"
INFO[0007] ✅ Exists: StatefulSet "noobaa-core"
INFO[0007] ✅ Exists: Service "noobaa-mgmt"
INFO[0008] ✅ Exists: Service "s3"
INFO[0008] ✅ Exists: Secret "noobaa-server"
INFO[0008] ✅ Exists: Secret "noobaa-operator"
INFO[0008] ✅ Exists: Secret "noobaa-admin"
INFO[0009] ✅ Exists: StorageClass "openshift-storage.noobaa.io"
INFO[0009] ✅ Exists: BucketClass "noobaa-default-bucket-class"
INFO[0009] ✅ (Optional) Exists: BackingStore "noobaa-default-backing-store"
INFO[0010] ✅ (Optional) Exists: CredentialsRequest "noobaa-cloud-creds"
INFO[0010] ✅ (Optional) Exists: PrometheusRule "noobaa-prometheus-rules"
INFO[0010] ✅ (Optional) Exists: ServiceMonitor "noobaa-service-monitor"
INFO[0011] ✅ (Optional) Exists: Route "noobaa-mgmt"
INFO[0011] ✅ (Optional) Exists: Route "s3"
INFO[0011] ✅ Exists: PersistentVolumeClaim "db-noobaa-core-0"
INFO[0011] ✅ System Phase is "Ready"
INFO[0011] ✅ Exists:  "noobaa-admin"

#------------------#
#- Mgmt Addresses -#
#------------------#

ExternalDNS : [https://noobaa-mgmt-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com https://a3406079515be11eaa3b70683061451e-1194613580.us-east-2.elb.amazonaws.com:443]
ExternalIP  : []
NodePorts   : [https://10.0.142.103:31385]
InternalDNS : [https://noobaa-mgmt.openshift-storage.svc:443]
InternalIP  : [https://172.30.235.12:443]
PodPorts    : [https://10.131.0.19:8443]

#--------------------#
#- Mgmt Credentials -#
#--------------------#

email    : admin@noobaa.io
password : HKLbH1rSuVU0I/souIkSiA==

#----------------#
#- S3 Addresses -#
#----------------#

1
ExternalDNS : [https://s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com https://a340f4e1315be11eaa3b70683061451e-943168195.us-east-2.elb.amazonaws.com:443]
ExternalIP  : []
NodePorts   : [https://10.0.142.103:31011]
InternalDNS : [https://s3.openshift-storage.svc:443]
InternalIP  : [https://172.30.86.41:443]
PodPorts    : [https://10.131.0.19:6443]

#------------------#
#- S3 Credentials -#
#------------------#

2
AWS_ACCESS_KEY_ID     : jVmAsu9FsvRHYmfjTiHV
3
AWS_SECRET_ACCESS_KEY : E//420VNedJfATvVSmDz6FMtsSAzuBv6z180PT5c

#------------------#
#- Backing Stores -#
#------------------#

NAME                           TYPE     TARGET-BUCKET                                               PHASE   AGE
noobaa-default-backing-store   aws-s3   noobaa-backing-store-15dc896d-7fe0-4bed-9349-5942211b93c9   Ready   141h35m32s

#------------------#
#- Bucket Classes -#
#------------------#

NAME                          PLACEMENT                                                             PHASE   AGE
noobaa-default-bucket-class   {Tiers:[{Placement: BackingStores:[noobaa-default-backing-store]}]}   Ready   141h35m33s

#-----------------#
#- Bucket Claims -#
#-----------------#

No OBC's found.
1
エンドポイント
2
アクセスキー
3
シークレットアクセスキー

これで、アプリケーションに接続するための関連するエンドポイント、アクセスキー、およびシークレットアクセスキーを使用できます。

例9.2 例

AWS S3 CLI がアプリケーションである場合、以下のコマンドは OpenShift Container Storage のバケットを一覧表示します。

AWS_ACCESS_KEY_ID=<AWS_ACCESS_KEY_ID>
AWS_SECRET_ACCESS_KEY=<AWS_SECRET_ACCESS_KEY>
aws --endpoint <ENDPOINT> --no-verify-ssl s3 ls

9.3. ハイブリッドまたはマルチクラウド用のストレージリソースの追加

9.3.1. MCG コマンドラインインターフェイスを使用したハイブリッドまたはマルチクラウドのストレージリソースの追加

Multicloud Object Gateway (MCG) は、クラウドプロバイダーおよびクラスター全体にまたがるデータの処理を単純化します。

これを実行するには、MCG で使用できるバッキングストレージを追加します。

前提条件

  • MCG コマンドラインインターフェイスをダウンロードします。

    # subscription-manager repos --enable=rh-ocs-4-for-rhel-8-x86_64-rpms
    # yum install mcg
  • または、mcg パッケージを、Download RedHat OpenShift Container Storage ページにある OpenShift Container Storage RPM からインストールできます。

手順

  1. MCG コマンドラインインターフェイスから、以下のコマンドを実行します。

    noobaa backingstore create <backing-store-type> <backingstore_name> --access-key=<AWS ACCESS KEY> --secret-key=<AWS SECRET ACCESS KEY> --target-bucket <bucket-name>
    1. <backing-store-type> を、関連するバッキングストアタイプの aws-s3google-cloud-storeazure-blobs3-compatible、または ibm-cos に置き換えます。
    2. <backingstore_name> を、バッキングストアの名前に置き換えます。
    3. <AWS ACCESS KEY> および <AWS SECRET ACCESS KEY> を、作成した AWS アクセスキー ID およびシークレットアクセスキーに置き換えます。
    4. <bucket-name> を既存の AWS バケット名に置き換えます。この引数は、NooBaa に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。

      出力は次のようになります。

      INFO[0001] ✅ Exists: NooBaa "noobaa"
      INFO[0002] ✅ Created: BackingStore "aws-resource"
      INFO[0002] ✅ Created: Secret "backing-store-secret-aws-resource"

YAML を使用してストレージリソースを追加することもできます。

  1. 認証情報でシークレットを作成します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: <backingstore-secret-name>
    type: Opaque
    data:
      AWS_ACCESS_KEY_ID: <AWS ACCESS KEY ID ENCODED IN BASE64>
      AWS_SECRET_ACCESS_KEY: <AWS SECRET ACCESS KEY ENCODED IN BASE64>
    1. Base64 を使用して独自の AWS アクセスキー ID およびシークレットアクセスキーを指定し、エンコードし、その結果を <AWS ACCESS KEY ID ENCODED IN BASE64> および <AWS SECRET ACCESS KEY ENCODED IN BASE64> に使用する必要があります。
    2. <backingstore-secret-name> を一意の名前に置き換えます。
  2. 特定のバッキングストアについて以下の YAML を適用します。

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: bs
      namespace: noobaa
    spec:
      awsS3:
        secret:
          name: <backingstore-secret-name>
          namespace: noobaa
        targetBucket: <bucket-name>
      type: <backing-store-type>
    1. <bucket-name> を既存の AWS バケット名に置き換えます。この引数は、NooBaa に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。
    2. <backingstore-secret-name> を直前の手順で作成したシークレットの名前に置き換えます。
    3. <backing-store-type> を、関連するバッキングストアタイプの aws-s3google-cloud-storeazure-blobs3-compatible、または ibm-cos に置き換えます。

9.3.2. s3 と互換性のある Multicloud Object Gateway バッキングストアの作成

Multicloud Object Gateway は、任意の S3 と互換性のあるオブジェクトストレージをバッキングストアとして使用できます (例: Red Hat Ceph Storage の RADOS Gateway (RGW))。以下の手順では、Red Hat Ceph Storage の RADOS Gateway 用の S3 と互換性のある Multicloud Object Gateway バッキングストアを作成する方法を説明します。RGW がデプロイされると、OpenShift Container Storage Operator は Multicloud Object Gateway の S3 と互換性のあるバッキングストアを自動的に作成することに注意してください。

手順

  1. Multicloud Object Gateway (MCG) コマンドラインインターフェイスから、以下の NooBaa コマンドを実行します。

    noobaa backingstore create s3-compatible rgw-resource --access-key=<RGW ACCESS KEY> --secret-key=<RGW SECRET KEY> --target-bucket=<bucket-name> --endpoint=<RGW endpoint>
    1. <RGW ACCESS KEY> および <RGW SECRET KEY> を取得するには、RGW ユーザーシークレット名を使用して以下のコマンドを実行します。

      oc get secret <RGW USER SECRET NAME> -o yaml
    2. Base64 からアクセスキー ID とアクセスキーをデコードし、それらのキーを保持します。
    3. <RGW USER ACCESS KEY><RGW USER SECRET ACCESS KEY> を、直前の手順でデコードした適切なデータに置き換えます。
    4. <bucket-name> を既存の RGW バケット名に置き換えます。この引数は、Multicloud Object Gateway に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。
    5. <RGW endpoint> を取得するには、RADOS Object Gateway S3 エンドポイントへのアクセス を参照してください。

      出力は次のようになります。

      INFO[0001] ✅ Exists: NooBaa "noobaa"
      INFO[0002] ✅ Created: BackingStore "rgw-resource"
      INFO[0002] ✅ Created: Secret "backing-store-secret-rgw-resource"

YAML を使用してバッキングストアを作成することもできます。

  1. CephObjectStore ユーザーを作成します。これにより、RGW 認証情報が含まれるシークレットも作成されます。

    apiVersion: ceph.rook.io/v1
    kind: CephObjectStoreUser
    metadata:
      name: <RGW-Username>
      namespace: openshift-storage
    spec:
      store: ocs-storagecluster-cephobjectstore
      displayName: "<Display-name>"
    1. <RGW-Username><Display-name> を、一意のユーザー名および表示名に置き換えます。
  2. 以下の YAML を S3 と互換性のあるバッキングストアについて適用します。

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: <backingstore-name>
      namespace: openshift-storage
    spec:
      s3Compatible:
        endpoint: <RGW endpoint>
        secret:
          name: <backingstore-secret-name>
          namespace: openshift-storage
        signatureVersion: v4
        targetBucket: <RGW-bucket-name>
      type: s3-compatible
    1. <backingstore-secret-name> を、直前の手順で CephObjectStore で作成したシークレットの名前に置き換えます。
    2. <bucket-name> を既存の RGW バケット名に置き換えます。この引数は、Multicloud Object Gateway に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。
    3. <RGW endpoint> を取得するには、RADOS Object Gateway S3 エンドポイントへのアクセス を参照してください。

9.3.3. ユーザーインターフェイスを使用したハイブリッドおよびマルチクラウドのストレージリソースの追加

手順

  1. OpenShift Storage コンソールで、OverviewObject Service → に移動し、Multicloud Object Gateway リンクを選択します。

    MCG object service noobaa link
  2. 以下に強調表示されているように左側にある Resources タブを選択します。設定する一覧から、Add Cloud Resource を選択します。

    MCG add cloud resource
  3. Add new connection を選択します。

    MCG add new connection
  4. 関連するネイティブクラウドプロバイダーまたは S3 互換オプションを選択し、詳細を入力します。

    MCG add cloud connection
  5. 新規に作成された接続を選択し、これを既存バケットにマップします。

    MCG map to existing bucket
  6. これらの手順を繰り返して、必要な数のバッキングストアを作成します。
注記

NooBaa UI で作成されたリソースは、OpenShift UI または MCG CLI では使用できません。

9.3.4. 新規バケットクラスの作成

バケットクラスは、OBC (Object Bucket Class) の階層ポリシーおよびデータ配置を定義するバケットのクラスを表す CRD です。

以下の手順を使用して、OpenShift Container Storage でバケットクラスを作成します。

手順

  1. OpenShift Web コンソールの左側のペインで Operators → Installed Operators をクリックし、インストールされた Operator を表示します。
  2. OpenShift Container Storage Operator をクリックします。
  3. OpenShift Container Storage Operator ページで右側にスクロールし、Bucket Class タブをクリックします。

    図9.1 Bucket Class タブのある OpenShift Container Storage Operator ページ

    Screenshot of OpenShift Container Storage operator page with Bucket Class tab.
  4. Create Bucket Class をクリックします。
  5. Create new Bucket Class ページで、以下を実行します。

    1. Bucket Class Name を入力し、Next をクリックします。

      図9.2 Create Bucket Class ページ

      Screenshot of create new bucket class page.
    2. Placement Policy で Tier 1 - Policy Type を選択し、Next をクリックします。要件に応じて、いずれかのオプションを選択できます。

      • Spread により、選択したリソース全体にデータを分散できます。
      • Mirror により、選択したリソース全体でデータを完全に複製できます。
      • Add Tier をクリックし、別のポリシー階層を追加します。

        図9.3 階層 1 - Policy Type 選択ページ

        Screenshot of Tier 1 - Policy Type selection tab.
    3. Tier 1 - Policy Type で Spread を選択した場合、利用可能な一覧から 1 つ以上の Backing Store リソースを選択してから、Next をクリックします。または、新規バッキングストアを作成 することもできます。

      図9.4 階層 1 - Baking Store 選択ページ

      Screenshot of Tier 1 - Backing Store selection tab.
注記

直前の手順で Policy Type に Mirror を選択する場合、2 つ以上のバッキングストアを選択する必要があります。

  1. Bucket Class 設定を確認し、確認します。

    図9.5 バケットクラス設定の確認ページ

    Screenshot of bucket class settings review tab.
  2. Create Bucket Class をクリックします。

検証手順

  1. OperatorsInstalled Operators をクリックします。
  2. OpenShift Container Storage Operator をクリックします。
  3. 新しい Bucket Class を検索するか、または Bucket Class タブをクリックし、すべての Bucket Class を表示します。

9.3.5. 新規バッキングストアの作成

以下の手順を使用して、OpenShift Container Storage で新規のバッキングストアを作成します。

前提条件

  • OpenShift への管理者アクセス。

手順

  1. OpenShift Web コンソールの左側のペインで Operators → Installed Operators をクリックし、インストールされた Operator を表示します。
  2. OpenShift Container Storage Operator をクリックします。
  3. OpenShift Container Storage Operator ページで右側にスクロールし、Backing Store タブをクリックします。

    図9.6 バッキングストアタブのある OpenShift Container Storage Operator ページ

    Screenshot of OpenShift Container Storage operator page with backing store tab.
  4. Create Backing Store をクリックします。

    図9.7 Create Backing Store ページ

    Screenshot of create new backing store page.
  5. Create New Backing Store ページで、以下を実行します。

    1. Backing Store Name を入力します。
    2. Provider を選択します。
    3. Region を選択します。
    4. Endpoint を入力します。これはオプションです。
    5. ドロップダウンリストから Secret を選択するか、または独自のシークレットを作成します。オプションで、Switch to Credentials ビューを選択すると、必要なシークレットを入力できます。

      OCP シークレットの作成に関する詳細は、Openshift Container Platform ドキュメントの シークレットの作成 を参照してください。

      バッキングストアごとに異なるシークレットが必要です。特定のバッキングストアのシークレット作成についての詳細は 「MCG コマンドラインインターフェイスを使用したハイブリッドまたはマルチクラウドのストレージリソースの追加」 を参照して、YAML を使用したストレージリソースの追加についての手順を実行します。

      注記

      このメニューは、Google Cloud およびローカル PVC 以外のすべてのプロバイダーに関連します。

    6. Target bucket を入力します。ターゲットバケットは、リモートクラウドサービスでホストされるコンテナーストレージです。MCG に対してシステム用にこのバケットを使用できることを通知する接続を作成できます。
  6. Create Backing Store をクリックします。

検証手順

  1. OperatorsInstalled Operators をクリックします。
  2. OpenShift Container Storage Operator をクリックします。
  3. 新しいバッキングストアを検索するか、または Backing Store タブをクリックし、すべてのバッキングストアを表示します。

9.4. ハイブリッドおよびマルチクラウドバケットのデータのミラーリング

Multicloud Object Gateway (MCG) は、クラウドプロバイダーおよびクラスター全体にまたがるデータの処理を単純化します。

前提条件

次に、データ管理ポリシー (ミラーリング) を反映するバケットクラスを作成します。

手順

ミラーリングデータは、以下の 3 つの方法で設定できます。

9.4.1. MCG コマンドラインインターフェイスを使用したデータのミラーリング用のバケットクラスの作成

  1. MCG コマンドラインインターフェイスから以下のコマンドを実行し、ミラーリングポリシーでバケットクラスを作成します。

    $ noobaa bucketclass create mirror-to-aws --backingstores=azure-resource,aws-resource --placement Mirror
  2. 新たに作成されたバケットクラスを新規のバケット要求に設定し、2 つのロケーション間でミラーリングされる新規バケットを生成します。

    $ noobaa obc create  mirrored-bucket --bucketclass=mirror-to-aws

9.4.2. YAML を使用したデータのミラーリング用のバケットクラスの作成

  1. 以下の YAML を適用します。この YAML は、ローカル Ceph ストレージと AWS 間でデータをミラーリングするハイブリッドの例です。

    apiVersion: noobaa.io/v1alpha1
    kind: BucketClass
    metadata:
      name: hybrid-class
      labels:
        app: noobaa
    spec:
      placementPolicy:
        tiers:
          - tier:
              mirrors:
                - mirror:
                    spread:
                      - cos-east-us
                - mirror:
                    spread:
                      - noobaa-test-bucket-for-ocp201907291921-11247_resource
  2. 以下の行を標準の Object Bucket Claim (オブジェクトバケット要求、OBC) に追加します。

    additionalConfig:
      bucketclass: mirror-to-aws

    OBC についての詳細は、「Object Bucket Claim(オブジェクトバケット要求)」を参照してください。

9.4.3. ユーザーインターフェイスを使用したデータミラーリングを行うためのバケットの設定

  1. OpenShift Storage コンソールで、OverviewObject Service → に移動し、Multicloud Object Gateway リンクを選択します。

    MCG object service noobaa link
  2. 左側の buckets アイコンをクリックします。バケットの一覧が表示されます。

    MCG noobaa bucket icon
  3. 更新するバケットをクリックします。
  4. Edit Tier 1 Resources をクリックします。

    MCG edit tier 1 resources
  5. Mirror を選択し、このバケットに使用する関連リソースを確認します。以下の例では、prem Ceph RGW と AWS 間でデータのミラーリングをします。

    MCG mirror relevant resources
  6. Save をクリックします。
注記

NooBaa UI で作成されたリソースは、OpenShift UI または MCG CLI では使用できません。

9.5. Multicloud Object Gateway のバケットポリシー

OpenShift Container Storage は AWS S3 バケットポリシーをサポートします。バケットポリシーにより、ユーザーにバケットとそれらのオブジェクトのアクセスパーミッションを付与することができます。

9.5.1. バケットポリシーについて

バケットポリシーは、AWS S3 バケットおよびオブジェクトにパーミッションを付与するために利用できるアクセスポリシーオプションです。バケットポリシーは JSON ベースのアクセスポリシー言語を使用します。アクセスポリシー言語についての詳細は、AWS Access Policy Language Overview を参照してください。

9.5.2. バケットポリシーの使用

前提条件

手順

Multicloud Object Gateway でバケットポリシーを使用するには、以下を実行します。

  1. JSON 形式でバケットポリシーを作成します。以下の例を参照してください。

    {
        "Version": "NewVersion",
        "Statement": [
            {
                "Sid": "Example",
                "Effect": "Allow",
                "Principal": [
                        "john.doe@example.com"
                ],
                "Action": [
                    "s3:GetObject"
                ],
                "Resource": [
                    "arn:aws:s3:::john_bucket"
                ]
            }
        ]
    }

    バケットポリシーには数多くの利用可能な要素があります。それらの設定要素および使用方法についての詳細は、AWS Access Policy Language Overview を参照してください。

    バケットポリシーの他の例については、AWS Bucket Policy Examples を参照してください。

    S3 ユーザーの作成方法については、「Multicloud Object Gateway での AWS S3 ユーザーの作成」 を参照してください。

  2. AWS S3 クライアントを使用して put-bucket-policy コマンドを使用してバケットポリシーを S3 バケットに適用します。

    # aws --endpoint ENDPOINT --no-verify-ssl s3api put-bucket-policy --bucket MyBucket --policy BucketPolicy

    ENDPOINT を S3 エンドポイントに置き換えます。

    MyBucket を、ポリシーを設定するバケットに置き換えます。

    BucketPolicy をバケットポリシー JSON ファイルに置き換えます。

    デフォルトの自己署名証明書を使用している場合は、--no-verify-ssl を追加します。

    以下に例を示します。

    # aws --endpoint https://s3-openshift-storage.apps.gogo44.noobaa.org --no-verify-ssl s3api put-bucket-policy -bucket MyBucket --policy file://BucketPolicy

    put-bucket-policy コマンドについての詳細は、AWS CLI Command Reference for put-bucket-policy を参照してください。

注記

主となる要素では、リソース (バケットなど) へのアクセスを許可または拒否されるユーザーを指定します。現在、NooBaa アカウントのみがプリンシパルとして使用できます。Object Bucket Claim (オブジェクトバケット要求) の場合、NooBaa はアカウント obc-account.<generated bucket name>@noobaa.io を自動的に作成します。

注記

バケットポリシー条件はサポートされていません。

9.5.3. Multicloud Object Gateway での AWS S3 ユーザーの作成

前提条件

手順

  1. OpenShift Storage コンソールで、OverviewObject Service → に移動し、Multicloud Object Gateway リンクを選択します。

    MCG object service noobaa link
  2. Accounts タブで、Create Account をクリックします。

    MCG accounts create account button
  3. S3 Access Only を選択し、Account Name を指定します (例: john.doe@example.com)。Next をクリックします。

    MCG create account s3 user
  4. S3 default placement を選択します (例: noobaa-default-backing-store)。Buckets Permissions を選択します。特定のバケットまたはすべてのバケットを選択できます。Create をクリックします。

    MCG create account s3 user2

9.6. Object Bucket Claim(オブジェクトバケット要求)

Object Bucket Claim(オブジェクトバケット要求) は、ワークロードの S3 と互換性のあるバケットバックエンドを要求するために使用できます。

Object Bucket Claim(オブジェクトバケット要求) は 3 つの方法で作成できます。

Object Bucket Claim(オブジェクトバケット要求) は、新しいアクセスキーおよびシークレットアクセスキーを含む、バケットのパーミッションのある NooBaa の新しいバケットとアプリケーションアカウントを作成します。アプリケーションアカウントは単一バケットにのみアクセスでき、デフォルトで新しいバケットを作成することはできません。

9.6.1. 動的 Object Bucket Claim(オブジェクトバケット要求)

永続ボリュームと同様に、Object Bucket Claim (オブジェクトバケット要求) の詳細をアプリケーションの YAML に追加し、設定マップおよびシークレットで利用可能なオブジェクトサービスエンドポイント、アクセスキー、およびシークレットアクセスキーを取得できます。この情報をアプリケーションの環境変数に動的に読み込むことは容易に実行できます。

手順

  1. 以下の行をアプリケーション YAML に追加します。

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: <obc-name>
    spec:
      generateBucketName: <obc-bucket-name>
      storageClassName: openshift-storage.noobaa.io

    これらの行は Object Bucket Claim(オブジェクトバケット要求) 自体になります。

    1. <obc-name> を、一意の Object Bucket Claim(オブジェクトバケット要求) の名前に置き換えます。
    2. <obc-bucket-name> を、Object Bucket Claim(オブジェクトバケット要求) の一意のバケット名に置き換えます。
  2. YAML ファイルにさらに行を追加して、Object Bucket Claim(オブジェクトバケット要求) の使用を自動化できます。以下の例はバケット要求の結果のマッピングです。これは、データを含む設定マップおよび認証情報のあるシークレットです。この特定のジョブは NooBaa からオブジェクトバケットを要求し、バケットとアカウントを作成します。

    apiVersion: batch/v1
    kind: Job
    metadata:
      name: testjob
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - image: <your application image>
              name: test
              env:
                - name: BUCKET_NAME
                  valueFrom:
                    configMapKeyRef:
                      name: <obc-name>
                      key: BUCKET_NAME
                - name: BUCKET_HOST
                  valueFrom:
                    configMapKeyRef:
                      name: <obc-name>
                      key: BUCKET_HOST
                - name: BUCKET_PORT
                  valueFrom:
                    configMapKeyRef:
                      name: <obc-name>
                      key: BUCKET_PORT
                - name: AWS_ACCESS_KEY_ID
                  valueFrom:
                    secretKeyRef:
                      name: <obc-name>
                      key: AWS_ACCESS_KEY_ID
                - name: AWS_SECRET_ACCESS_KEY
                  valueFrom:
                    secretKeyRef:
                      name: <obc-name>
                      key: AWS_SECRET_ACCESS_KEY
    1. <obc-name> のすべてのインスタンスを、Object Bucket Claim(オブジェクトバケット要求) の名前に置き換えます。
    2. <your application image> をアプリケーションイメージに置き換えます。
  3. 更新された YAML ファイルを適用します。

    # oc apply -f <yaml.file>
    1. <yaml.file> を YAML ファイルの名前に置き換えます。
  4. 新しい設定マップを表示するには、以下を実行します。

    # oc get cm <obc-name>
    1. obc-name を、Object Bucket Claim(オブジェクトバケット要求) の名前に置き換えます。

      出力には、以下の環境変数が表示されることが予想されます。

      • BUCKET_HOST: アプリケーションで使用するエンドポイント
      • BUCKET_PORT: アプリケーションで利用できるポート

        • ポートは BUCKET_HOST に関連します。たとえば、BUCKET_HOSThttps://my.example.com で、BUCKET_PORT が 443 の場合、オブジェクトサービスのエンドポイントは https://my.example.com:443 になります。
      • BUCKET_NAME: 要求されるか、または生成されるバケット名
      • AWS_ACCESS_KEY_ID: 認証情報の一部であるアクセスキー
      • AWS_SECRET_ACCESS_KEY: 認証情報の一部であるシークレットのアクセスキー

9.6.2. コマンドラインインターフェイスを使用した Object Bucket Claim(オブジェクトバケット要求) の作成

コマンドラインインターフェイスを使用して Object Bucket Claim(オブジェクトバケット要求) を作成する場合、設定マップとシークレットを取得します。これらには、アプリケーションがオブジェクトストレージサービスを使用するために必要なすべての情報が含まれます。

前提条件

  • MCG コマンドラインインターフェイスをダウンロードします。

    # subscription-manager repos --enable=rh-ocs-4-for-rhel-8-x86_64-rpms
    # yum install mcg

手順

  1. コマンドラインインターフェイスを使用して、新規バケットおよび認証情報の詳細を生成します。以下のコマンドを実行します。

    # noobaa obc create <obc-name> -n openshift-storage

    <obc-name> を一意の Object Bucket Claim(オブジェクトバケット要求) の名前に置き換えます (例: myappobc)。

    さらに、--app-namespace オプションを使用して、Object Bucket Claim(オブジェクトバケット要求) 設定マップおよびシークレットが作成される namespace を指定できます (例: myapp-namespace)。

    出力例:

    INFO[0001] ✅ Created: ObjectBucketClaim "test21obc"

    MCG コマンドラインインターフェイスが必要な設定を作成し、新規 OBC について OpenShift に通知します。

  2. 以下のコマンドを実行して Object Bucket Claim(オブジェクトバケット要求) を表示します。

    # oc get obc -n openshift-storage

    出力例:

    NAME        STORAGE-CLASS                 PHASE   AGE
    test21obc   openshift-storage.noobaa.io   Bound   38s
  3. 以下のコマンドを実行して、新規 Object Bucket Claim(オブジェクトバケット要求) の YAML ファイルを表示します。

    # oc get obc test21obc -o yaml -n openshift-storage

    出力例:

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      creationTimestamp: "2019-10-24T13:30:07Z"
      finalizers:
      - objectbucket.io/finalizer
      generation: 2
      labels:
        app: noobaa
        bucket-provisioner: openshift-storage.noobaa.io-obc
        noobaa-domain: openshift-storage.noobaa.io
      name: test21obc
      namespace: openshift-storage
      resourceVersion: "40756"
      selfLink: /apis/objectbucket.io/v1alpha1/namespaces/openshift-storage/objectbucketclaims/test21obc
      uid: 64f04cba-f662-11e9-bc3c-0295250841af
    spec:
      ObjectBucketName: obc-openshift-storage-test21obc
      bucketName: test21obc-933348a6-e267-4f82-82f1-e59bf4fe3bb4
      generateBucketName: test21obc
      storageClassName: openshift-storage.noobaa.io
    status:
      phase: Bound
  4. openshift-storage namespace 内で、設定マップおよびシークレットを見つけ、この Object Bucket Claim(オブジェクトバケット要求) を使用することができます。CM とシークレットの名前はこの Object Bucket Claim(オブジェクトバケット要求) の名前と同じです。シークレットを表示するには、以下を実行します。

    # oc get -n openshift-storage secret test21obc -o yaml

    出力例:

    Example output:
    apiVersion: v1
    data:
      AWS_ACCESS_KEY_ID: c0M0R2xVanF3ODR3bHBkVW94cmY=
      AWS_SECRET_ACCESS_KEY: Wi9kcFluSWxHRzlWaFlzNk1hc0xma2JXcjM1MVhqa051SlBleXpmOQ==
    kind: Secret
    metadata:
      creationTimestamp: "2019-10-24T13:30:07Z"
      finalizers:
      - objectbucket.io/finalizer
      labels:
        app: noobaa
        bucket-provisioner: openshift-storage.noobaa.io-obc
        noobaa-domain: openshift-storage.noobaa.io
      name: test21obc
      namespace: openshift-storage
      ownerReferences:
      - apiVersion: objectbucket.io/v1alpha1
        blockOwnerDeletion: true
        controller: true
        kind: ObjectBucketClaim
        name: test21obc
        uid: 64f04cba-f662-11e9-bc3c-0295250841af
      resourceVersion: "40751"
      selfLink: /api/v1/namespaces/openshift-storage/secrets/test21obc
      uid: 65117c1c-f662-11e9-9094-0a5305de57bb
    type: Opaque

    シークレットは S3 アクセス認証情報を提供します。

  5. 設定マップを表示するには、以下を実行します。

    # oc get -n openshift-storage cm test21obc -o yaml

    出力例:

    apiVersion: v1
    data:
      BUCKET_HOST: 10.0.171.35
      BUCKET_NAME: test21obc-933348a6-e267-4f82-82f1-e59bf4fe3bb4
      BUCKET_PORT: "31242"
      BUCKET_REGION: ""
      BUCKET_SUBREGION: ""
    kind: ConfigMap
    metadata:
      creationTimestamp: "2019-10-24T13:30:07Z"
      finalizers:
      - objectbucket.io/finalizer
      labels:
        app: noobaa
        bucket-provisioner: openshift-storage.noobaa.io-obc
        noobaa-domain: openshift-storage.noobaa.io
      name: test21obc
      namespace: openshift-storage
      ownerReferences:
      - apiVersion: objectbucket.io/v1alpha1
        blockOwnerDeletion: true
        controller: true
        kind: ObjectBucketClaim
        name: test21obc
        uid: 64f04cba-f662-11e9-bc3c-0295250841af
      resourceVersion: "40752"
      selfLink: /api/v1/namespaces/openshift-storage/configmaps/test21obc
      uid: 651c6501-f662-11e9-9094-0a5305de57bb

    設定マップには、アプリケーションの S3 エンドポイント情報が含まれます。

9.6.3. OpenShift Web コンソールを使用した Object Bucket Claim(オブジェクトバケット要求) の作成

OpenShift Web コンソールを使用して Object Bucket Claim (オブジェクトバケット要求) を作成できます。

前提条件

手順

  1. OpenShift Web コンソールにログインします。
  2. 左側のナビゲーションバーで StorageObject Bucket Claims をクリックします。
  3. Create Object Bucket Claim をクリックします。

    Create Object Bucket Claims page
  4. Object Bucket Claim(オブジェクトバケット要求) の名前を入力し、ドロップダウンメニューから、内部または外部かのデプロイメントに応じて適切なストレージクラスとバケットクラスを選択します。

    内部モード

    Create Object Bucket Claim wizard

    デプロイメント後に作成された以下のストレージクラスを使用できます。

    • ocs-storagecluster-ceph-rgw は Ceph Object Gateway (RGW) を使用します。
    • openshift-storage.noobaa.io は Multicloud Object Gateway を使用します。

    外部モード

    Create Object Bucket Claim wizard

    デプロイメント後に作成された以下のストレージクラスを使用できます。

    • ocs-external-storagecluster-ceph-rgw は Ceph Object Gateway (RGW) を使用します。
    • openshift-storage.noobaa.io は Multicloud Object Gateway を使用します。

      注記

      RGW OBC ストレージクラスは、OpenShift Container Storage バージョン 4.5 の新規インストールでのみ利用できます。これは、以前の OpenShift Container Storage リリースからアップグレードされたクラスターには適用されません。

  5. Create をクリックします。

    OBC を作成すると、その詳細ページにリダイレクトされます。

    Object Bucket Claim Details page

9.7. エンドポイントの追加による Multicloud Object Gateway パフォーマンスのスケーリング

Multicloud Object Gateway のパフォーマンスは環境によって異なる場合があります。特定のアプリケーションでは、高速なパフォーマンスを必要とする場合があり、これは S3 エンドポイントをスケーリングして簡単に対応できます。

Multicloud Object Gateway リソースプールは、デフォルトで有効にされる 2 種類のサービスを提供する NooBaa デーモンコンテナーのグループです。

  • ストレージサービス
  • S3 エンドポイントサービス

9.7.1. Multicloud Object Gateway での S3 エンドポイント

S3 エンドポイントは、すべての Multicloud Object Gateway がデフォルトで提供するサービスであり、これは Multicloud Object Gateway で負荷の高いデータ消費タスクの大部分を処理します。エンドポイントサービスは、インラインのデータチャンク、重複排除、圧縮、および暗号化を処理し、Multicloud Object Gateway からのデータ配置の指示を受け入れます。

9.7.2. ストレージノードを使用したスケーリング

前提条件

  • Multicloud Object Gateway へのアクセスのある OpenShift Container Platform で実行中の OpenShift Container Storage Platform

Multicloud Object Gateway のストレージノードは 1 つ以上の永続ボリュームに割り当てられた NooBaa デーモンコンテナーであり、ローカルオブジェクトサービスデータストレージに使用されます。NooBaa デーモンは Kubernetes ノードにデプロイできます。これは、StatefulSet Pod で設定される Kubernetes プールを作成して実行できます。

手順

  1. Mult-Cloud Object Gateway ユーザーインターフェイスの Overview ページで、 Add Storage Resources をクリックします。

    MCG add storage resources button
  2. ウィンドウから Deploy Kubernetes Pool をクリックします。

    MCG deploy kubernetes pool
  3. Create Pool 手順で、今後インストールされるノードのターゲットプールを作成します。

    MCG deploy kubernetes pool create pool
  4. Configure 手順で、要求される Pod 数と各 PV のサイズを設定します。新規 Pod ごとに、1 つの PV が作成されます。

    MCG deploy kubernetes pool configure
  5. Review 手順で、新規プールの詳細を検索し、ローカルまたは外部デプロイメントのいずれかの使用するデプロイメント方法を選択します。ローカルデプロイメントが選択されている場合、Kubernetes ノードはクラスター内にデプロイされます。外部デプロイメントが選択されている場合、外部で実行するための YAML ファイルが提供されます。
  6. すべてのノードは最初の手順で選択したプールに割り当てられ、ResourcesStorage resourcesResource name の下で確認できます。

    MCG storage resources overview

第10章 永続ボリューム要求の管理

10.1. OpenShift Container Platform を使用するためのアプリケーション Pod の設定

このセクションの手順に従って、OpenShift Container Storage をアプリケーション Pod のストレージとして設定します。

前提条件

  • OpenShift Web コンソールへの管理者アクセスがある。
  • OpenShift Container Storage Operator が openshift-storage namespace にインストールされ、実行されている。OpenShift Web コンソールで、OperatorsInstalled Operators をクリックし、インストールされた Operator を表示します。
  • OpenShift Container Storage が提供するデフォルトのストレージクラスが利用可能である。OpenShift Web コンソールで StorageStorage Class をクリックし、デフォルトのストレージクラスを表示します。

手順

  1. 使用するアプリケーションの Persistent Volume Claim(永続ボリューム要求、PVC) を作成します。

    1. OpenShift Web コンソールで、StoragePersistent Volume Claims をクリックします。
    2. アプリケーション Pod の Project を設定します。
    3. Create Persistent Volume Claim をクリックします。

      1. OpenShift Container Storage によって提供される Storage Class を指定します。
      2. PVC Name (例: myclaim) を指定します。
      3. 必要な Access Mode を選択します。
      4. アプリケーション要件に応じて Size を指定します。
      5. Create をクリックし、PVC のステータスが Bound になるまで待機します。
  2. 新規または既存のアプリケーション Pod を新規 PVC を使用するように設定します。

    • 新規アプリケーション Pod の場合、以下の手順を実行します。

      1. WorkloadsPods をクリックします。
      2. 新規アプリケーション Pod を作成します。
      3. spec: セクションで、volume: セクションを追加し、新規 PVC をアプリケーション Pod のボリュームとして追加します。

        volumes:
          - name: <volume_name>
            persistentVolumeClaim:
              claimName: <pvc_name>

        以下に例を示します。

        volumes:
          - name: mypd
            persistentVolumeClaim:
              claimName: myclaim
    • 既存のアプリケーション Pod の場合、以下の手順を実行します。

      1. WorkloadsDeployment Configs をクリックします。
      2. アプリケーション Pod に関連付けられた必要なデプロイメント設定を検索します。
      3. Action menu (⋮)Edit Deployment Config をクリックします。
      4. spec: セクションで、volume: セクションを追加し、新規 PVC をアプリケーション Pod のボリュームとして追加し、Save をクリックします。

        volumes:
          - name: <volume_name>
            persistentVolumeClaim:
              claimName: <pvc_name>

        以下に例を示します。

        volumes:
          - name: mypd
            persistentVolumeClaim:
              claimName: myclaim
  3. 新しい設定が使用されていることを確認します。

    1. WorkloadsPods をクリックします。
    2. アプリケーション Pod の Project を設定します。
    3. アプリケーション Pod が Running ステータスで表示されていることを確認します。
    4. アプリケーション Pod 名をクリックし、Pod の詳細を表示します。
    5. Volumes セクションまでスクロールダウンし、ボリュームに新規 Persistent Vocume Claim (永続ボリューム要求、PVC) に一致する Type があることを確認します (例: myclaim)。

10.2. Persistent Volume Claim (永続ボリューム要求、PVC) 要求ステータスの表示

以下の手順を使用して、PVC 要求のステータスを表示します。

前提条件

  • OpenShift Container Storage への管理者アクセス。

手順

  1. OpenShift Web コンソールにログインします。
  2. StoragePersistent Volume Claims をクリックします。
  3. Filter テキストボックスを使用して、必要な PVC 名を検索します。また、一覧を絞り込むために Name または Label で PVC の一覧をフィルターすることもできます。
  4. 必要な PVC に対応する Status 列を確認します。
  5. 必要な Name をクリックして PVC の詳細を表示します。

10.3. Persistent Volume Claim (永続ボリューム要求、PVC) 要求イベントの確認

以下の手順を使用して、Persistent Volume Claim(永続ボリューム要求、PVC) 要求イベントを確認し、これに対応します。

前提条件

  • OpenShift Web コンソールへの管理者アクセス。

手順

  1. OpenShift Web コンソールにログインします。
  2. HomeOverviewPersistent Storage をクリックします。
  3. Inventory カードを見つけ、エラーのある PVC の数を確認します。
  4. StoragePersistent Volume Claims をクリックします。
  5. Filter テキストボックスを使用して、必要な PVC を検索します。
  6. PVC 名をクリックし、Events に移動します。
  7. 必要に応じて、または指示に応じてイベントに対応します。

10.4. Persistent Volume Claim (永続ボリューム要求、PVC) の拡張

OpenShift Container Storage 4.6 では、Persistent Volume Claim (永続ボリューム要求、PVC) を拡張する機能が導入され、永続ストレージリソース管理の柔軟性が向上します。

拡張は、以下の永続ボリュームでサポートされます。

  • ボリュームモードが Filesystem の Ceph File System (CephFS) をベースとする PVC (ReadWriteOnce (RWO) および ReadWriteMany (RWX) アクセス)。
  • ボリュームモードが Filesystem の Ceph RADOS Block Device (Ceph RBD) をベースとする PVC (ReadWriteOnce (RWO) アクセス)。
  • ボリュームモードが Block の Ceph RADOS Block Device (Ceph RBD) をベースとする PVC (ReadWriteOnce (RWO) アクセス)。
警告

OSD および MON PVC の拡張機能は Red Hat によってサポートされていません。

前提条件

  • OpenShift Web コンソールへの管理者アクセス。

手順

  1. OpenShift Web コンソールで、StoragePersistent Volume Claims に移動します。
  2. 拡張する Persistent Volume Claim(永続ボリューム要求、PVC) の横にある Action メニュー (⋮) をクリックします。
  3. Expand PVC をクリックします。

    Persistent Volume Claims Expand PVC menu item
  4. Persistent Volume Claim(永続ボリューム要求、PVC) の新しいサイズを選択してから、Expand をクリックします。

    Expand Persistent Volume Claim wizard
  5. 拡張を確認するには、PVC の詳細ページに移動し、Capacity フィールドでサイズが正しく要求されていることを確認します。

    注記

    Ceph RADOS Block Device (RBD) に基づいて PVC を拡張する場合、PVC がまだ Pod に割り当てられていない場合は、PVC の詳細ページで Condition typeFileSystemResizePending になります。ボリュームをマウントすると、ファイルシステムのサイズ変更が正常に実行され、新しいサイズが Capacity フィールドに反映されます。

10.5. 動的プロビジョニング

10.5.1. 動的プロビジョニングについて

StorageClass リソースオブジェクトは、要求可能なストレージを記述し、分類するほか、要求に応じて動的にプロビジョニングされるストレージのパラメーターを渡すための手段を提供します。StorageClass オブジェクトは、さまざまなレベルのストレージおよびストレージへのアクセスを制御するための管理メカニズムとしても機能します。クラスター管理者 (cluster-admin) またはストレージ管理者 (storage-admin) は、ユーザーが基礎となるストレージボリュームソースに関する詳しい知識なしに要求できる StorageClass オブジェクトを定義し、作成します。

OpenShift Container Platform の永続ボリュームフレームワークはこの機能を有効にし、管理者がクラスターに永続ストレージをプロビジョニングできるようにします。フレームワークにより、ユーザーは基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようになります。

OpenShift Container Platform では、数多くのストレージタイプを永続ボリュームとして使用することができます。これらはすべて管理者によって静的にプロビジョニングされますが、一部のストレージタイプは組み込みプロバイダーとプラグイン API を使用して動的に作成できます。

10.5.2. OpenShift Container Storage の動的プロビジョニング

Red Hat OpenShift Container Storage は、コンテナー環境向けに最適化されたソフトウェアで定義されるストレージです。これは OpenShift Container Platform の Operator として実行され、コンテナーの統合され、単純化された永続ストレージの管理を可能にします。

OpenShift Container Storage は、以下を含む各種のストレージタイプをサポートします。

  • データベースのブロックストレージ
  • 継続的な統合、メッセージングおよびデータ集約のための共有ファイルストレージ
  • アーカイブ、バックアップおよびメディアストレージのオブジェクトストレージ

バージョン 4 では、Red Hat Ceph Storage を使用して永続ボリュームをサポートするファイル、ブロック、およびオブジェクトストレージを提供し、Rook.io を使用して永続ボリュームおよび要求のプロビジョニングを管理し、オーケストレーションします。NooBaa はオブジェクトストレージを提供し、その Multicloud Gateway は複数のクラウド環境でのオブジェクトのフェデレーションを可能にします (テクノロジープレビューとしてご利用いただけます)。

OpenShift Container Storage 4 では、RADOS Block Device (RBD) および Ceph File System (CephFS) の Red Hat Ceph Storage Container Storage Interface (CSI) ドライバーが動的プロビジョニング要求を処理します。PVC 要求が動的に送信される場合、CSI ドライバーでは以下のオプションを使用できます。

  • ボリュームモードが Block の Ceph RBD をベースとする PVC (ReadWriteOnce (RWO) および ReadWriteMany (RWX) アクセス) を作成します。
  • ボリュームモードが Filesystem の Ceph RBD をベースとする PVC (ReadWriteOnce (RWO) アクセス) を作成します。
  • ボリュームモードが Filesystem の CephFS をベースとする PVC (ReadWriteOnce (RWO) および ReadWriteMany (RWX) アクセス) を作成します。

使用するドライバー (RBD または CephFS) の判断は、storageclass.yaml ファイルのエントリーに基づいて行われます。

10.5.3. 利用可能な動的プロビジョニングプラグイン

OpenShift Container Platform は、以下のプロビジョナープラグインを提供します。 これらには、クラスターの設定済みプロバイダーの API を使用して新規ストレージリソースを作成する動的プロビジョニング用の一般的な実装が含まれます。

ストレージタイププロビジョナープラグインの名前注記

OpenStack Cinder

kubernetes.io/cinder

 

AWS Elastic Block Store (EBS)

kubernetes.io/aws-ebs

複数クラスターを複数の異なるゾーンで使用する際の動的プロビジョニングの場合、各ノードに Key=kubernetes.io/cluster/<cluster_name>,Value=<cluster_id> のタグを付けます。ここで、<cluster_name> および <cluster_id> はクラスターごとに固有の値になります。

AWS Elastic File System (EFS)

 

動的プロビジョニングは、EFS プロビジョナー Pod で実行され、プロビジョナープラグインでは実行されません。

Azure Disk

kubernetes.io/azure-disk

 

Azure File

kubernetes.io/azure-file

persistent-volume-binder ServiceAccount では、Azure ストレージアカウントおよびキーを保存するためにシークレットを作成し、取得するためのパーミッションが必要です。

GCE Persistent Disk (gcePD)

kubernetes.io/gce-pd

マルチゾーン設定では、GCE プロジェクトごとに OpenShift Container Platform クラスターを実行し、現行クラスターのノードが存在しないゾーンで PV が作成されないようにすることが推奨されます。

VMware vSphere

kubernetes.io/vsphere-volume

 
重要

選択したプロビジョナープラグインでは、関連するクラウド、ホスト、またはサードパーティープロバイダーを、関連するドキュメントに従って設定する必要もあります。

第11章 ボリュームスナップショット

ボリュームスナップショットは、特定の時点におけるクラスター内のストレージボリュームの状態を表します。これらのスナップショットは、毎回フルコピーを作成する必要がないので、より効率的にストレージを使用するのに役立ち、アプリケーション開発のビルディングブロックとして使用できます。

同じ永続ボリューム要求 (PVC) の複数のスナップショットを作成できます。CephFS の場合、PVC ごとに最大 100 スナップショットを作成できます。RADOS Block Device (RBD) の場合、PVC ごとに最大 512 スナップショットを作成できます。

注記

スナップショットの定期的な作成をスケジュールすることはできません。

11.1. ボリュームスナップショットの作成

Persistent Volume Claim(永続ボリューム要求、PVC) ページまたは Volume Snapshots ページのいずれかからボリュームスナップショットを作成できます。

前提条件

  • PVC は Bound 状態にある必要があり、使用中の状態にすることはできません。
注記

Pod が使用している場合、OpenShift Container Storage は PVC のボリュームスナップショットのクラッシュの一貫性だけを提供します。アプリケーションの一貫性を保つために、まず実行中の Pod を破棄してスナップショットの一貫性を確保するか、またはアプリケーションが提供する静止メカニズムを使用してこれを確保します。

手順

Persistent Volume Claims ページで以下を実行します。
  1. OpenShift Web コンソールで、StoragePersistent Volume Claims をクリックします。
  2. ボリュームのスナップショットを作成するには、以下のいずれかを実行します。

    • 必要な PVC の横にある Action メニュー (⋮)Create Snapshot をクリックします。
    • スナップショットを作成する PVC をクリックし、ActionsCreate Snapshot をクリックします。
  3. ボリュームスナップショットの Name を入力します。
  4. ドロップダウンリストから Snapshot Class を選択します。
  5. Create をクリックします。作成されるボリュームスナップショットの Details ページにリダイレクトされます。
Volume Snapshots ページで以下を実行します。
  1. OpenShift Web コンソールで StorageVolume Snapshots をクリックします。
  2. Volume Snapshots ページで、Create Volume Snapshot をクリックします。
  3. ドロップダウンリストから必要な Project を選択します。
  4. ドロップダウンリストから Persistent Volume Claim を選択します。
  5. スナップショットの Name を入力します。
  6. ドロップダウンリストから Snapshot Class を選択します。
  7. Create をクリックします。作成されるボリュームスナップショットの Details ページにリダイレクトされます。

検証手順

  • PVC の Details ページに移動し、Volume Snapshots タブをクリックしてボリュームスナップショットの一覧を表示します。新規スナップショットが一覧表示されていることを確認します。
  • OpenShift Web コンソールで StorageVolume Snapshots をクリックします。新規スナップショットが一覧表示されていることを確認します。
  • ボリュームスナップショットが Ready 状態になるまで待機します。

11.2. ボリュームスナップショットの復元

ボリュームスナップショットを復元する際に、新規の Persistent Volume Claim(永続ボリューム要求、PVC) が作成されます。復元される PVC はボリュームスナップショットおよび親 PVC とは切り離されています。

Persistent Volume Claim ページまたは Volume Snapshots ページのいずれかからボリュームスナップショットを復元できます。

手順

Persistent Volume Claims ページで以下を実行します。

親 PVC が存在する場合に限り、Persistent Volume Claims ページからボリュームスナップショットを復元できます。

  1. OpenShift Web コンソールで、StoragePersistent Volume Claims をクリックします。
  2. 新規 PVC として復元する必要のあるボリュームスナップショットがある PVC 名をクリックします。
  3. Volume Snapshots タブで、必要なボリュームスナップショットの横にある Action メニュー (⋮) → Restore as new PVC をクリックします。
  4. 新規 PVC の名前を入力します。
  5. Storage Class 名を選択します。

    注記

    (Rados Block Device (RBD) の場合) 親 PVC と同じプールが指定されるストレージクラスを選択する必要があります。

  6. Restore をクリックします。新規 PVC の詳細ページにリダイレクトされます。
Volume Snapshots ページの使用
  1. OpenShift Web コンソールで StorageVolume Snapshots をクリックします。
  2. 必要なボリュームスナップショットの横にある Action Menu (⋮) → Restore as new PVC をクリックします。
  3. 新規 PVC の名前を入力します。
  4. Storage Class 名を選択します。

    注記

    (Rados Block Device (RBD) の場合) 親 PVC と同じプールが指定されるストレージクラスを選択する必要があります。

  5. Restore をクリックします。新規 PVC の詳細ページにリダイレクトされます。
注記

ボリュームスナップショットの復元時に、PVC は親 PVC が存在する場合にのみ、親 PVC のアクセスモードで作成されます。それ以外の場合は、PVC は ReadWriteOnce (RWO) アクセスモードでのみ作成されます。現時点で、OpenShift Web コンソールを使用してアクセスモードを指定することはできません。ただし、YAML を使用して CLI からアクセスモードを指定できます。詳細は、ボリュームスナップショットの復元 について参照してください。

検証手順

  • OpenShift Web コンソールから StoragePersistent Volume Claims をクリックし、新規 PVC が Persistent Volume Claims ページに一覧表示されていることを確認します。
  • 新規 PVC が Bound の状態になるまで待機します。

11.3. ボリュームスナップショットの削除

前提条件

  • ボリュームスナップショットを削除する場合は、その特定のボリュームスナップショットで使用されるボリュームスナップショットクラスが存在している必要があります。

手順

Persistent Volume Claims ページで以下を実行します。
  1. OpenShift Web コンソールで、StoragePersistent Volume Claims をクリックします。
  2. 削除する必要のあるボリュームスナップショットがある PVC 名をクリックします。
  3. Volume Snapshots タブで、必要なボリュームスナップショットの横にある Action メニュー (⋮)Delete Volume Snapshot をクリックします。
Volume Snapshots ページで以下を実行します。
  1. OpenShift Web コンソールで StorageVolume Snapshots をクリックします。
  2. Volume Snapshots ページで、必要なスナップショットの横にある Action メニュー (⋮)Delete Volume Snapshot をクリックします。

検証手順

  • 削除されたボリュームスナップショットが PVC の詳細ページの Volume Snapshots タブにないことを確認します。
  • StorageVolume Snapshots をクリックし、削除されたボリュームスナップショットが一覧表示されていないことを確認します。

第12章 ボリュームのクローン作成

クローンは、標準のボリュームとして使用される既存のストレージボリュームの複製です。ボリュームのクローンを作成し、データの特定の時点のコピーを作成します。永続ボリューム要求 (PVC) は別のサイズでクローンできません。CephFS および RADOS Block Device (RBD) の両方で、PVC ごとに最大 512 のクローンを作成できます。

12.1. クローンの作成

前提条件

  • ソース PVC は Bound 状態にある必要があり、使用中の状態にすることはできません。
注記

Pod が PVC を使用している場合は、PVC のクローンを作成しません。これを実行すると、PVC が一時停止 (停止) されないため、データが破損する可能性があります。

手順

  1. OpenShift Web コンソールで、StoragePersistent Volume Claims をクリックします。
  2. クローンを作成するには、以下のいずれかを実行します。

    • 必要な PVC の横にある Action メニュー (⋮)Clone PVC をクリックします。
    • クローンを作成する必要のある PVC をクリックし、ActionsClone PVC をクリックします。
  3. クローンの Name を入力します。
  4. Clone をクリックします。新規 PVC の詳細ページにリダイレクトされます。

    注記

    クローンは、親 PVC のアクセスモードで作成されます。現時点で、OpenShift Web コンソール UI を使用してアクセスモードを指定することはできません。ただし、YAML を使用して CLI からアクセスモードを指定できます。詳細は、CSI ボリュームクローンのプロビジョニング について参照してください。

  5. クローン作成された PVC のステータスが Bound になるまで待機します。

    クローン作成された PVC が Pod で使用できるようになります。このクローン作成された PVC は dataSource PVC とは切り離されています。

第13章 ストレージノードの置き換え

13.1. Red Hat Virtualization インストーラーでプロビジョニングされるインフラストラクチャーで動作するノードの置き換え

以下の手順を使用して、Red Hat Virtualization のインストーラーでプロビジョニングされるインフラストラクチャー (IPI) で動作するノードを置き換えます。

前提条件

  • Red Hat では、交換前のノードと同様のインフラストラクチャーおよびリソースで、交換後のノードを設定することを推奨します。
  • OpenShift Container Platform (RHOCP) クラスターにログインしている必要があります。

手順

  1. OpenShift Web コンソールにログインし、 Compute → Nodes をクリックします。
  2. 置き換える必要のあるノードを特定します。そのマシン名をメモします。
  3. 置き換えるノードのラベルを取得します。

    $ oc get nodes --show-labels | grep <node_name>
  4. 置き換えるノードで実行されている mon (ある場合) および OSD を特定します。

    $ oc get pods -n openshift-storage -o wide | grep -i <node_name>
  5. 先の手順で特定された Pod のデプロイメントをスケールダウンします。

    以下に例を示します。

    $ oc scale deployment rook-ceph-mon-c --replicas=0 -n openshift-storage
    $ oc scale deployment rook-ceph-osd-0 --replicas=0 -n openshift-storage
    $ oc scale deployment --selector=app=rook-ceph-crashcollector,node_name=<node_name>  --replicas=0 -n openshift-storage
  6. ノードにスケジュール対象外 (unschedulable) のマークを付けます。

    $ oc adm cordon <node_name>
  7. ノードをドレイン (解放) します。

    $ oc adm drain <node_name> --force --delete-local-data --ignore-daemonsets
  8. Compute → Machines をクリックします。必要なマシンを検索します。
  9. 必要なマシンの横にある Action menu (⋮) → Delete Machine をクリックします。
  10. Delete をクリックしてマシンの削除を確認します。新しいマシンが自動的に作成されます。
  11. 新規マシンが起動し、Running 状態に移行するまで待機します。

    重要

    このアクティビティーには少なくとも 5-10 分以上かかる場合があります。

  12. OpenShift Web コンソールで Compute → Nodes をクリックします。新規ノードが Ready 状態にあるかどうかを確認します。
  13. 以下のいずれかを使用して、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=""
  14. これらのワーカーノードで利用可能なローカルストレージデバイスを 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:
                  - server1.example.com
                  - server2.example.com
               #  - server3.example.com
                  - newnode.example.com
      [...]

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

  15. 新規 localblock PV が利用可能であることを確認します。

    $ oc get pv | grep localblock
              CAPA- ACCESS RECLAIM                                STORAGE
    NAME      CITY  MODES  POLICY  STATUS     CLAIM               CLASS       AGE
    local-pv- 931Gi  RWO   Delete  Bound      openshift-storage/  localblock  25h
    3e8964d3                                  ocs-deviceset-2-0
                                              -79j94
    local-pv- 931Gi  RWO   Delete  Bound      openshift-storage/  localblock  25h
    414755e0                                  ocs-deviceset-1-0
                                              -959rp
    local-pv- 931Gi RWO Delete Available localblock 3m24s b481410
    local-pv- 931Gi  RWO   Delete  Bound      openshift-storage/  localblock  25h
    d9c5cbd6                                  ocs-deviceset-0-0
                                              -nvs68
  16. openshift-storage プロジェクトを変更します。

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

    $ oc process -n openshift-storage ocs-osd-removal \
    -p FAILED_OSD_IDS=failed-osd-id1,failed-osd-id2 | oc create -f -
  18. ocs-osd-removal Pod のステータスをチェックして、OSD が正常に削除されたことを確認します。

    Completed のステータスで、OSD の削除ジョブが正常に完了したことを確認します。

    # oc get pod -l job-name=ocs-osd-removal-failed-osd-id -n openshift-storage
    注記

    ocs-osd-removal が失敗し、Pod が予想される Completed の状態にない場合、追加のデバッグのために Pod ログを確認します。以下に例を示します。

    # oc logs -l job-name=ocs-osd-removal-failed-osd_id -n openshift-storage --tail=-1
  19. 障害のあるノードに関連付けられた PV を削除します。

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

      # oc get -n openshift-storage pvc claim-name

      以下に例を示します。

      # oc get -n openshift-storage pvc ocs-deviceset-0-0-nvs68
                                                  ACCESS STORAGE
      NAME           STATUS    VOLUME    CAPACITY MODES  CLASS      AGE
      ocs-deviceset- Released  local-pv- 931Gi    RWO    localblock 24h
      0-0-nvs68                d9c5cbd6
    2. PV を削除します。

      # oc delete pv <persistent-volume>

      以下に例を示します。

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

    $ oc delete deployment --selector=app=rook-ceph-crashcollector,node_name=failed-node-name -n openshift-storage
  21. rook-ceph-operator を再起動して Operator の調整を強制的に実行して新規 OSD をデプロイします。

    # oc get -n openshift-storage pod -l app=rook-ceph-operator

    出力例:

    NAME                                  READY   STATUS    RESTARTS   AGE
    rook-ceph-operator-6f74fb5bff-2d982   1/1     Running   0          1d20h
    1. rook-ceph-operator を削除します。

      # oc delete -n openshift-storage pod rook-ceph-operator-6f74fb5bff-2d982

      出力例:

      pod "rook-ceph-operator-6f74fb5bff-2d982" deleted
    2. rook-ceph-operator Pod が再起動していることを確認します。

      # oc get -n openshift-storage pod -l app=rook-ceph-operator

      出力例:

      NAME                                  READY   STATUS    RESTARTS   AGE
      rook-ceph-operator-6f74fb5bff-7mvrq   1/1     Running   0          66s

      新規 OSD および mon の作成には、Operator が再起動するまでに数分かかる場合があります。

  22. ocs-osd-removal ジョブを削除します。

    # oc delete job ocs-osd-removal-${osd_id_to_remove}

    出力例:

    job.batch "ocs-osd-removal-0" deleted

検証手順

  1. 以下のコマンドを実行して、出力で新規ノードが表示されていることを確認します。

    $ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1
  2. Workloads → Pods をクリックし、新規ノード上の少なくとも以下の Pod が Running 状態にあることを確認します。

    • csi-cephfsplugin-*
    • csi-rbdplugin-*
  3. 他の必要なすべての OpenShift Container Storage Pod が Running 状態にあることを確認します。

    また、増分の mon が新規に作成されており、Running 状態にあることを確認します。

    $ oc get pod -n openshift-storage | grep mon

    出力例:

    rook-ceph-mon-c-64556f7659-c2ngc                                  1/1     Running     0          6h14m
    rook-ceph-mon-d-7c8b74dc4d-tt6hd                                  1/1     Running     0          4h24m
    rook-ceph-mon-e-57fb8c657-wg5f2                                   1/1     Running     0          162m

    OSD と Mon が Running 状態になるまで数分かかる場合があります。

  4. 新規 OSD Pod が交換後のノードで実行されていることを確認します。

    $ oc get pods -o wide -n openshift-storage| egrep -i new-node-name | egrep osd
  5. (オプション) クラスターでデータの暗号化が有効な場合には、新規 OSD デバイスが暗号化されていることを確認します。

    直前の手順で特定された新規ノードごとに、以下を実行します。

    1. デバッグ Pod を作成し、選択したホストの chroot 環境を開きます。

      $ oc debug node/<node name>
      $ chroot /host
    2. lsblk を実行し、ocs-deviceset 名の横にある crypt キーワードを確認します。

      $ lsblk
  6. 検証手順が失敗した場合は、Red Hat サポートにお問い合わせください

13.2. Red Hat Virtualization インストーラーでプロビジョニングされるインフラストラクチャーで障害のあるノードの置き換え

インスタンスの電源がオフになると、OpenShift Container Storage の Red Hat Virtualization の一時ストレージが原因でデータが失われる可能性があります。以下の手順を使用して、Red Hat Virtualization プラットフォームで電源オフになったインスタンスのリカバリーを行います。

前提条件

  • Red Hat では、交換前のノードと同様のインフラストラクチャーおよびリソースで、交換後のノードを設定することを推奨します。
  • OpenShift Container Platform (RHOCP) クラスターにログインしている必要があります。

手順

  1. OpenShift Web コンソールにログインし、 Compute → Nodes をクリックします。
  2. 置き換える必要のあるノードを特定します。そのマシン名をメモします。
  3. 置き換えるノードのラベルを取得します。

    $ oc get nodes --show-labels | grep <node_name>
  4. 置き換えるノードで実行されている mon (ある場合) および OSD を特定します。

    $ oc get pods -n openshift-storage -o wide | grep -i <node_name>
  5. 先の手順で特定された Pod のデプロイメントをスケールダウンします。

    以下に例を示します。

    $ oc scale deployment rook-ceph-mon-c --replicas=0 -n openshift-storage
    $ oc scale deployment rook-ceph-osd-0 --replicas=0 -n openshift-storage
    $ oc scale deployment --selector=app=rook-ceph-crashcollector,node_name=<node_name>  --replicas=0 -n openshift-storage
  6. ノードにスケジュール対象外 (unschedulable) のマークを付けます。

    $ oc adm cordon <node_name>
  7. Terminating 状態の Pod を削除します。

    $ oc get pods -A -o wide | grep -i <node_name> |  awk '{if ($4 == "Terminating") system ("oc -n " $1 " delete pods " $2  " --grace-period=0 " " --force ")}'
  8. ノードをドレイン (解放) します。

    $ oc adm drain <node_name> --force --delete-local-data --ignore-daemonsets
  9. Compute → Machines をクリックします。必要なマシンを検索します。
  10. 必要なマシンの横にある Action menu (⋮) → Delete Machine をクリックします。
  11. Delete をクリックしてマシンの削除を確認します。新しいマシンが自動的に作成されます。
  12. 新規マシンが起動し、Running 状態に移行するまで待機します。

    重要

    このアクティビティーには少なくとも 5-10 分以上かかる場合があります。

  13. OpenShift Web コンソールで Compute → Nodes をクリックします。新規ノードが Ready 状態にあるかどうかを確認します。
  14. 以下のいずれかを使用して、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=""
  15. 新規ワーカーノードで利用可能なローカルストレージデバイスを OpenShift Container Storage StorageCluster に追加します。
  16. これらのワーカーノードで利用可能なローカルストレージデバイスを 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:
                  - server1.example.com
                  - server2.example.com
               #  - server3.example.com
                  - newnode.example.com
      [...]

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

  17. 新規 localblock PV が利用可能であることを確認します。

    $ oc get pv | grep localblock
              CAPA- ACCESS RECLAIM                                STORAGE
    NAME      CITY  MODES  POLICY  STATUS     CLAIM               CLASS       AGE
    local-pv- 931Gi  RWO   Delete  Bound      openshift-storage/  localblock  25h
    3e8964d3                                  ocs-deviceset-2-0
                                              -79j94
    local-pv- 931Gi  RWO   Delete  Bound      openshift-storage/  localblock  25h
    414755e0                                  ocs-deviceset-1-0
                                              -959rp
    local-pv- 931Gi RWO Delete Available localblock 3m24s b481410
    local-pv- 931Gi  RWO   Delete  Bound      openshift-storage/  localblock  25h
    d9c5cbd6                                  ocs-deviceset-0-0
                                              -nvs68
  18. openshift-storage プロジェクトを変更します。

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

    $ oc process -n openshift-storage ocs-osd-removal \
    -p FAILED_OSD_IDS=failed-osd-id1,failed-osd-id2 | oc create -f -
  20. ocs-osd-removal Pod のステータスをチェックして、OSD が正常に削除されたことを確認します。

    Completed のステータスで、OSD の削除ジョブが正常に完了したことを確認します。

    # oc get pod -l job-name=ocs-osd-removal-failed-osd-id -n openshift-storage
    注記

    ocs-osd-removal が失敗し、Pod が予想される Completed の状態にない場合、追加のデバッグのために Pod ログを確認します。以下に例を示します。

    # oc logs -l job-name=ocs-osd-removal-failed-osd_id -n openshift-storage --tail=-1
  21. 障害のあるノードに関連付けられた PV を削除します。

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

      # oc get -n openshift-storage pvc claim-name

      以下に例を示します。

      # oc get -n openshift-storage pvc ocs-deviceset-0-0-nvs68
                                                  ACCESS STORAGE
      NAME           STATUS    VOLUME    CAPACITY MODES  CLASS      AGE
      ocs-deviceset- Released  local-pv- 931Gi    RWO    localblock 24h
      0-0-nvs68                d9c5cbd6
    2. PV を削除します。

      # oc delete pv <persistent-volume>

      以下に例を示します。

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

    $ oc delete deployment --selector=app=rook-ceph-crashcollector,node_name=failed-node-name -n openshift-storage
  23. rook-ceph-operator を再起動して Operator の調整を強制的に実行して新規 OSD をデプロイします。

    # oc get -n openshift-storage pod -l app=rook-ceph-operator

    出力例:

    NAME                                  READY   STATUS    RESTARTS   AGE
    rook-ceph-operator-6f74fb5bff-2d982   1/1     Running   0          1d20h
    1. rook-ceph-operator を削除します。

      # oc delete -n openshift-storage pod rook-ceph-operator-6f74fb5bff-2d982

      出力例:

      pod "rook-ceph-operator-6f74fb5bff-2d982" deleted
    2. rook-ceph-operator Pod が再起動していることを確認します。

      # oc get -n openshift-storage pod -l app=rook-ceph-operator

      出力例:

      NAME                                  READY   STATUS    RESTARTS   AGE
      rook-ceph-operator-6f74fb5bff-7mvrq   1/1     Running   0          66s

      新規 OSD および mon の作成には、Operator が再起動するまでに数分かかる場合があります。

  24. `ocs-osd-removal` ジョブを削除します。

    # oc delete job ocs-osd-removal-${osd_id_to_remove}

    出力例:

    job.batch "ocs-osd-removal-0" deleted

検証手順

  1. 以下のコマンドを実行して、出力で新規ノードが表示されていることを確認します。

    $ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1
  2. Workloads → Pods をクリックし、新規ノード上の少なくとも以下の Pod が Running 状態にあることを確認します。

    • csi-cephfsplugin-*
    • csi-rbdplugin-*
  3. 他の必要なすべての OpenShift Container Storage Pod が Running 状態にあることを確認します。

    また、増分の mon が新規に作成されており、Running 状態にあることを確認します。

    $ oc get pod -n openshift-storage | grep mon

    出力例:

    rook-ceph-mon-c-64556f7659-c2ngc                                  1/1     Running     0          6h14m
    rook-ceph-mon-d-7c8b74dc4d-tt6hd                                  1/1     Running     0          4h24m
    rook-ceph-mon-e-57fb8c657-wg5f2                                   1/1     Running     0          162m

    OSD と Mon が Running 状態になるまで数分かかる場合があります。

  4. 新規 OSD Pod が交換後のノードで実行されていることを確認します。

    $ oc get pods -o wide -n openshift-storage| egrep -i new-node-name | egrep osd
  5. (オプション) クラスターでデータの暗号化が有効な場合には、新規 OSD デバイスが暗号化されていることを確認します。

    直前の手順で特定された新規ノードごとに、以下を実行します。

    1. デバッグ Pod を作成し、選択したホストの chroot 環境を開きます。

      $ oc debug node/<node name>
      $ chroot /host
    2. lsblk を実行し、ocs-deviceset 名の横にある crypt キーワードを確認します。

      $ lsblk
  6. 検証手順が失敗した場合は、Red Hat サポートにお問い合わせください

第14章 Red Hat Virtualization プラットフォームでの障害のあるストレージデバイスの置き換え

Red Hat Virtualization プラットフォームのストレージデバイスを置き換える必要がある場合は、ストレージノードを置き換える必要があります。ノードを置き換える方法については、Red Hat Virtualization プラットフォームでの障害のあるストレージノードの置き換え を参照してください。

第15章 OpenShift Container Storage の更新

15.1. OpenShift Container Storage 更新プロセスの概要

Red Hat OpenShift Container Storage およびそのコンポーネントを (4.5 と 4.6 間などのマイナーリリース間、または 4.6.0 と 4.6.1 間などのバッチ更新間でアップグレードできます。

OpenShift Container Storage の異なる部分を特定の順序でアップグレードする必要があります。

  1. OpenShift Container Platform の クラスターの更新 ドキュメントに従って OpenShift Container Platform を更新します
  2. OpenShift Container Storage を更新します。

    1. お使いのセットアップに適したプロセスを使用して、OpenShift Container Storage Operator を更新します

    2. ローカルストレージを使用する場合:

      1. ローカルストレージ Operator を更新します

        不明な場合は、Checking for Local Storage Operator deployments を参照してください。

      2. ローカルストレージがサポートするクラスターの 更新後の設定変更を実行します

        詳細は、ローカルストレージでサポートされるクラスターについての更新後の設定 について参照してください。

更新に関する考慮事項

開始する前に、以下の重要な考慮事項を確認してください。

  • Red Hat では、Red Hat OpenShift Container Storage で同じバージョンの Red Hat OpenShift Container Platform を使用することを推奨しています。

    OpenShift Container Platform および OpenShift Container Storage のサポートされる組み合わせについての詳細は、相互運用性マトリックス を参照してください。

  • ローカルストレージ Operator は、ローカルストレージ Operator バージョンが Red Hat OpenShift Container Platform バージョンと一致する場合にのみ完全にサポートされます。

15.2. 非接続環境での更新の準備

Red Hat OpenShift Container Storage 環境がインターネットに直接接続されていない場合には、デフォルトの Operator Hub およびイメージレジストリーの代替オプションとして Operator Lifecycle Manager(OLM) を提供するために追加の設定が必要になります。

概要については OpenShift Container Platform ドキュメントを参照してください: Updating an Operator catalog image

クラスターで非接続更新を設定するには、以下を実行します。

これらの手順が完了したら、通常通りに 更新を継続 します。

15.2.1. ミラーレジストリーの認証情報の追加

前提条件

  • 既存の非接続クラスターが OpenShift Container Platform 4.3 以降を使用していることを確認します。
  • oc client がバージョン 4.4 以降であることを確認します。
  • ミラーレジストリーでミラーホストを準備します。詳細は、ミラーホストの準備 について参照してください。

手順

  1. cluster-admin ロールを使用して OpenShift Container Platform クラスターにログインします。
  2. auth.json ファイルを見つけます。

    このファイルは、podman または docker を使用してレジストリーにログインする際に生成されます。これは、以下のいずれかの場所にあります。

    • ~/.docker/auth.json
    • /run/user/<UID>/containers/auth.json
    • /var/run/containers/<UID>/auth.json
  3. 一意の Red Hat レジストリー プルシークレット を取得して auth.json ファイルに貼り付けます。以下のようになります。

    {
        "auths": {
            "cloud.openshift.com": {
                "auth": "*****************",
                "email": "user@example.com"
            },
            "quay.io": {
                "auth": "*****************",
                "email": "user@example.com"
            },
            "registry.connect.redhat.com": {
                "auth": "*****************",
                "email": "user@example.com"
            },
            "registry.redhat.io": {
                "auth": "*****************",
                "email": "user@example.com"
            }
        }
      }
  4. 設定に対応する詳細と共に環境変数をエクスポートします。

    $ export AUTH_FILE="<location_of_auth.json>"
    $ export MIRROR_REGISTRY_DNS="<your_registry_url>:<port>"
  5. podman を使用してミラーレジストリーにログインし、認証情報を ${AUTH_FILE} に保存します。

    $ podman login ${MIRROR_REGISTRY_DNS} --tls-verify=false --authfile ${AUTH_FILE}

    これにより、ミラーレジストリーが auth.json ファイルに追加されます。

    {
        "auths": {
            "cloud.openshift.com": {
                "auth": "*****************",
                "email": "user@example.com"
            },
            "quay.io": {
                "auth": "*****************",
                "email": "user@example.com"
            },
            "registry.connect.redhat.com": {
                "auth": "*****************",
                "email": "user@example.com"
            },
            "registry.redhat.io": {
                "auth": "*****************",
                "email": "user@example.com"
            },
            "<mirror_registry>": {
                "auth": "*****************",
            }
        }
      }

15.2.2. Red Hat Operator カタログのビルドおよびミラーリング

Red Hat レジストリーにアクセスできるホストでこのプロセスを実行し、それらのレジストリーのミラーを作成します。

前提条件

  • これらのコマンドをクラスター管理者として実行します。
  • redhat-operator カタログのミラーリングには完了するまでに時間がかかる場合があります。また、ミラーホストに大きなディスク領域が利用可能である必要があることに注意してください。

手順

  1. redhat-operators のカタログをビルドします。

    ターゲット OpenShift Container Platform クラスターのメジャーバージョンおよびマイナーバージョンに一致するタグを使用して、--fromose-operator-registry ベースイメージに設定します。

    $ oc adm catalog build --appregistry-org redhat-operators \
      --from=registry.redhat.io/openshift4/ose-operator-registry:v4.6 \
      --to=${MIRROR_REGISTRY_DNS}/olm/redhat-operators:v2 \
      --registry-config=${AUTH_FILE} \
      --filter-by-os="linux/amd64" --insecure
  2. redhat-operators のカタログをミラーリングします。

    これは長時間の操作となり、1-5 時間の時間がかかる場合があります。ミラーホストに 100 GB の空きディスク領域があることを確認します。

    $ oc adm catalog mirror ${MIRROR_REGISTRY_DNS}/olm/redhat-operators:v2 \
    ${MIRROR_REGISTRY_DNS} --registry-config=${AUTH_FILE} --insecure

15.2.3. Operator imageContentSourcePolicy を作成します。

oc adm catalog mirror コマンドが完了すると、imageContentSourcePolicy.yaml ファイルが作成されます。通常、このファイルの出力ディレクトリーは ./[catalog image name]-manifests) です。以下の手順を使用して、不足しているエントリーを .yaml ファイルに追加し、それらをクラスターに適用します。

手順

  1. このファイルの内容で、以下のようにミラーマッピングを確認します。

    spec:
      repositoryDigestMirrors:
        - mirrors:
          - <your_registry>/ocs4
          source: registry.redhat.io/ocs4
        - mirrors:
          - <your_registry>/rhceph
          source: registry.redhat.io/rhceph
        - mirrors:
          - <your_registry>/openshift4
          source: registry.redhat.io/openshift4
        - mirrors:
          - <your_registry>/rhscl
          source: registry.redhat.io/rhscl
  2. 不足しているエントリーを imageContentSourcePolicy.yaml ファイルの最後に追加します。
  3. imageContentSourcePolicy.yaml ファイルをクラスターに適用します。

    $ oc apply -f ./[output dir]/imageContentSourcePolicy.yaml

    Image Content Source Policy を更新したら、クラスター内のすべてのノード (マスター、インフラストラクチャー、およびワーカー) を更新し、再起動する必要があります。このプロセスは Machine Config Pool Operator で自動的に処理され、実際の経過時間は OpenShift クラスターのノード数によって異なる可能性がありますが、最長で 30 分の時間がかかります。oc get mcp コマンドまたは oc get node コマンドを使用して更新プロセスをモニターできます。

15.2.4. redhat-operator CatalogSource の更新

手順

  1. Red Hat Operator のカタログイメージを参照する CatalogSource オブジェクトを再作成します。

    注記

    正しいバージョン (v2) で正しいカタログソースをミラーリングしていることを確認します。

    以下を redhat-operator-catalogsource.yaml ファイルに保存し、<your_registry> をミラーレジストリー URL に必ず置き換えます。

    apiVersion: operators.coreos.com/v1alpha1
    kind: CatalogSource
    metadata:
      name: redhat-operators
      namespace: openshift-marketplace
    spec:
      sourceType: grpc
      icon:
        base64data: PHN2ZyBpZD0iTGF5ZXJfMSIgZGF0YS1uYW1lPSJMYXllciAxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZpZXdCb3g9IjAgMCAxOTIgMTQ1Ij48ZGVmcz48c3R5bGU+LmNscy0xe2ZpbGw6I2UwMDt9PC9zdHlsZT48L2RlZnM+PHRpdGxlPlJlZEhhdC1Mb2dvLUhhdC1Db2xvcjwvdGl0bGU+PHBhdGggZD0iTTE1Ny43Nyw2Mi42MWExNCwxNCwwLDAsMSwuMzEsMy40MmMwLDE0Ljg4LTE4LjEsMTcuNDYtMzAuNjEsMTcuNDZDNzguODMsODMuNDksNDIuNTMsNTMuMjYsNDIuNTMsNDRhNi40Myw2LjQzLDAsMCwxLC4yMi0xLjk0bC0zLjY2LDkuMDZhMTguNDUsMTguNDUsMCwwLDAtMS41MSw3LjMzYzAsMTguMTEsNDEsNDUuNDgsODcuNzQsNDUuNDgsMjAuNjksMCwzNi40My03Ljc2LDM2LjQzLTIxLjc3LDAtMS4wOCwwLTEuOTQtMS43My0xMC4xM1oiLz48cGF0aCBjbGFzcz0iY2xzLTEiIGQ9Ik0xMjcuNDcsODMuNDljMTIuNTEsMCwzMC42MS0yLjU4LDMwLjYxLTE3LjQ2YTE0LDE0LDAsMCwwLS4zMS0zLjQybC03LjQ1LTMyLjM2Yy0xLjcyLTcuMTItMy4yMy0xMC4zNS0xNS43My0xNi42QzEyNC44OSw4LjY5LDEwMy43Ni41LDk3LjUxLjUsOTEuNjkuNSw5MCw4LDgzLjA2LDhjLTYuNjgsMC0xMS42NC01LjYtMTcuODktNS42LTYsMC05LjkxLDQuMDktMTIuOTMsMTIuNSwwLDAtOC40MSwyMy43Mi05LjQ5LDI3LjE2QTYuNDMsNi40MywwLDAsMCw0Mi41Myw0NGMwLDkuMjIsMzYuMywzOS40NSw4NC45NCwzOS40NU0xNjAsNzIuMDdjMS43Myw4LjE5LDEuNzMsOS4wNSwxLjczLDEwLjEzLDAsMTQtMTUuNzQsMjEuNzctMzYuNDMsMjEuNzdDNzguNTQsMTA0LDM3LjU4LDc2LjYsMzcuNTgsNTguNDlhMTguNDUsMTguNDUsMCwwLDEsMS41MS03LjMzQzIyLjI3LDUyLC41LDU1LC41LDc0LjIyYzAsMzEuNDgsNzQuNTksNzAuMjgsMTMzLjY1LDcwLjI4LDQ1LjI4LDAsNTYuNy0yMC40OCw1Ni43LTM2LjY1LDAtMTIuNzItMTEtMjcuMTYtMzAuODMtMzUuNzgiLz48L3N2Zz4=
        mediatype: image/svg+xml
      image: <your_registry>/olm/redhat-operators:v2
      displayName: Redhat Operators Catalog
      publisher: Red Hat
  2. redhat-operator-catalogsource.yaml ファイルを使用してカタログソースを作成します。

    $ oc apply -f redhat-operator-catalogsource.yaml
  3. 新規の redhat-operator Pod が実行していることを確認します。

    $ oc get pod -n openshift-marketplace | grep redhat-operators

15.2.5. 更新の継続

代替カタログソースを設定した後も、適切な更新プロセスを続行できます。

15.3. 内部モードでの OpenShift Container Storage の更新

以下の手順に従って、内部モードでデプロイされた OpenShift Container Storage クラスターを更新します。

15.3.1. 内部モードでの OpenShift Container Storage Operator の自動更新の有効化

以下の手順を使用して、OpenShift Container Platform で OpenShift Container Storage Operator の自動の更新承認を有効にします。

前提条件

  • Status カードの Persistent Storage で、OCS Cluster および Data Resiliency に緑色のチェックマークが付いていることを確認します。
  • Status カードの Object Service で、Object Service および Data Resiliency の両方が Ready 状態 (緑のチェックマーク) にあることを確認します。
  • OpenShift Container Platform クラスターをバージョン 4.5.X または 4.6.Y に更新する場合、クラスターの更新 を参照してください。
  • Red Hat OpenShift Container Storage チャネルを stable-4.5 から stable-4.6 に切り替えます。チャネルの詳細は、OpenShift Container Storage を参照してください。

    注記

    マイナーバージョンを更新する場合 (例: 4.5 から 4.6 に更新) にのみチャネルを切り換える必要があり、4.6 のバッチの更新間に更新する場合 (例: 4.6.0 から 4.6.1 に更新) はチャネルを切り換える必要はありません。

  • Operator Pod を含むすべての OpenShift Container Storage Pod が openshift-storage namespaceRunning 状態にあることを確認します。

    Pod の状態を確認するには、OpenShift Web コンソールの左側のペインから WorkloadsPods をクリックします。Project ドロップダウンリストから openshift-storage を選択します。

  • 更新時間はクラスターで実行される OSD の数によって異なるため、Openshift Container Storage 更新プロセスを完了するのに十分な時間を確保してください。

手順

  1. OpenShift Web コンソールにログインします。
  2. OperatorsInstalled Operators をクリックします。
  3. openshift-storage プロジェクトを選択します。
  4. OpenShift Container Storage Operator 名をクリックします。
  5. Subscription タブをクリックしてから、Approval の下にあるリンクをクリックします。
  6. Automatic (default) を選択し、Save をクリックします。
  7. Upgrade Status に応じて以下ののいずれかを実行します。

    • Upgrade Status には、requires approval表示されます

      注記

      Upgrade status には、新規 OpenShift Container Storage バージョンがチャネルですでに検知され、承認ストラテジーが更新時に Manual から Automatic に変更されている場合に requires approval が表示されます。

      1. Install Plan リンクをクリックします。
      2. InstallPlan Details ページで、Preview Install Plan をクリックします。
      3. インストール計画を確認し、Approve をクリックします。
      4. StatusUnknown から Created に変更されるまで待機します。
      5. OperatorsInstalled Operators をクリックします。
      6. openshift-storage プロジェクトを選択します。
      7. StatusUp to date に変更するまで待機します。
    • Upgrade Status には、requires approval表示されません

      1. 更新が開始するまで待機します。これには、最長 20 分の時間がかかる可能性があります。
      2. OperatorsInstalled Operators をクリックします。
      3. openshift-storage プロジェクトを選択します。
      4. StatusUp to date に変更するまで待機します。

検証手順

  1. Status カードで Overview → Persistent Storage タブをクリックし、OCS Cluster および Data Resiliency で正常であることを示す緑色のチェックマークが表示されていることを確認します。
  2. Overview → Object Service タブをクリックし、Status カードで、Object ServiceData Resiliency の両方が正常なことを示す Ready 状態 (Green tick) であることを確認します。
  3. OperatorsInstalled OperatorsOpenShift Container Storage Operator をクリックします。Storage Cluster で、クラスターサービスのステータスが Ready であることを確認します。

    注記

    OpenShift Container Storage バージョン 4.5 から 4.6 に更新された後も、Version フィールドには依然として 4.5 が表示されます。これは、ocs-operator がこのフィールドで表示される文字列を更新しないためです。

  4. Operator Pod を含むすべての OpenShift Container Storage Pod が openshift-storage namespaceRunning 状態にあることを確認します。

    Pod の状態を表示するには、WorkloadsPods をクリックします。Project ドロップダウンリストから openshift-storage を選択します。

  5. 検証手順が失敗した場合は、Red Hat サポートにお問い合わせ ください。

関連情報

OpenShift Container Storage の更新中に問題が発生した場合は、トラブルシューティングガイドトラブルシューティングで一般に必要になるログ セクションを参照してください。

15.3.2. 内部モードでの OpenShift Container Storage Operator の手動による更新

以下の手順を使用して、インストール計画に手動の承認を指定し、OpenShift Container Storage Operator を更新します。

前提条件

  • Status カードの Persistent Storage で、OCS Cluster および Data Resiliency に緑色のチェックマークが付いていることを確認します。
  • Status カードの Object Service で、Object Service および Data Resiliency の両方が Ready 状態 (緑のチェックマーク) にあることを確認します。
  • OpenShift Container Platform クラスターをバージョン 4.5.X または 4.6.Y に更新する場合、クラスターの更新 を参照してください。
  • Red Hat OpenShift Container Storage チャネルを stable-4.5 から stable-4.6 に切り替えます。チャネルの詳細は、OpenShift Container Storage を参照してください。

    注記

    マイナーバージョンを更新する場合 (例: 4.5 から 4.6 に更新) にのみチャネルを切り換える必要があり、4.6 のバッチの更新間に更新する場合 (例: 4.6.0 から 4.6.1 に更新) はチャネルを切り換える必要はありません。

  • Operator Pod を含むすべての OpenShift Container Storage Pod が openshift-storage namespaceRunning 状態にあることを確認します。

    Pod の状態を確認するには、OpenShift Web コンソールの左側のペインから WorkloadsPods をクリックします。Project ドロップダウンリストから openshift-storage を選択します。

  • 更新時間はクラスターで実行される OSD の数によって異なるため、Openshift Container Storage 更新プロセスを完了するのに十分な時間を確保してください。

手順

  1. OpenShift Web コンソールにログインします。
  2. OperatorsInstalled Operators をクリックします。
  3. openshift-storage プロジェクトを選択します。
  4. OpenShift Container Storage Operator 名をクリックします。
  5. Subscription タブをクリックしてから、Approval の下にあるリンクをクリックします。
  6. Manual を選択し、Save をクリックします。
  7. Upgrade StatusUpgrading に変更するまで待機します。
  8. Upgrade Statusrequires approval が表示される場合は、requires approval をクリックします。
  9. InstallPlan Details ページで、Preview Install Plan をクリックします。
  10. インストール計画を確認し、Approve をクリックします。
  11. StatusUnknown から Created に変更されるまで待機します。
  12. OperatorsInstalled Operators をクリックします。
  13. openshift-storage プロジェクトを選択します。
  14. StatusUp to date に変更するまで待機します。

検証手順

  1. Status カードで Overview → Persistent Storage タブをクリックし、OCS Cluster および Data Resiliency で正常であることを示す緑色のチェックマークが表示されていることを確認します。
  2. Overview → Object Service タブをクリックし、Status カードで、Object ServiceData Resiliency の両方が正常なことを示す Ready 状態 (Green tick) であることを確認します。
  3. OperatorsInstalled OperatorsOpenShift Container Storage Operator をクリックします。Storage Cluster で、クラスターサービスのステータスが Ready であることを確認します。

    注記

    OpenShift Container Storage バージョン 4.5 から 4.6 に更新された後も、Version フィールドには依然として 4.5 が表示されます。これは、ocs-operator がこのフィールドで表示される文字列を更新しないためです。

  4. Operator Pod を含むすべての OpenShift Container Storage Pod が openshift-storage namespaceRunning 状態にあることを確認します。

    Pod の状態を確認するには、OpenShift Web コンソールの左側のペインから WorkloadsPods をクリックします。Project ドロップダウンリストから openshift-storage を選択します。

  5. 検証手順が失敗した場合は、Red Hat サポートにお問い合わせ ください。

関連情報

OpenShift Container Storage の更新中に問題が発生した場合は、トラブルシューティングガイドトラブルシューティングで一般に必要になるログ セクションを参照してください。

15.4. 更新後の設定の変更

すべての機能が予想通りに機能するように、更新後に追加の設定手順が必要になる場合があります。

15.4.1. ローカルストレージがサポートするクラスターの更新後の設定

Red Hat OpenShift Container Platform 4.6 以降で、ローカルストレージ Operator はローカルストレージを管理するための新規のカスタムリソースタイプを提供します。

  • LocalVolumeDiscovery
  • LocalVolumeSet

これらのリソースタイプは、以前のバージョンからの更新の一部として自動的に処理されないため、手動で作成する必要があります。

15.4.1.1. コマンドラインを使用した LocalVolumeDiscovery カスタムリソースの作成

LocalVolumeDiscovery カスタムリソースを作成し、デバイス管理ユーザーインターフェイスがローカルデバイスの状態を検知できるようにし、クラスターノードで利用可能なデバイスについての情報を提供します。

前提条件

  • OpenShift Container Platform クラスターへの管理者アクセス。

手順

  1. ローカルストレージ Operator がインストールされているプロジェクトに切り替えます。

    $ oc project local-storage-project

    local-storage-project はローカルストレージプロジェクトの名前に置き換えます。

    バージョン 4.5 以前では、デフォルトのローカルストレージプロジェクトの名前は local-storage です。バージョン 4.6 以降では、デフォルトのローカルストレージプロジェクトの名前は openshift-local-storage です。

  2. LocalVolumeDiscovery カスタムリソースを定義します。

    たとえば、local-volume-discovery.yaml ファイルで以下を定義します。

    apiVersion: local.storage.openshift.io/v1alpha1
    kind: LocalVolumeDiscovery
    metadata:
      name: auto-discover-devices
    spec:
      nodeSelector:
        nodeSelectorTerms:
          - matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                  - worker1.example.com
                  - worker2.example.com
                  - worker3.example.com
  3. LocalVolumeDiscovery カスタムリソースを作成します。

    $ oc create -f local-volume-discovery.yaml

検証手順

  1. OpenShift Web コンソールにログインします。
  2. ComputeNode をクリックし、ノードの名前をクリックします。
  3. Disks タブをクリックして、そのノードで利用可能なデバイスが表示されることを確認します。

15.4.1.2. コマンドラインを使用した LocalVolumeSet カスタムリソースの作成

LocalVolumeSet カスタムリソースを作成し、指定する条件に基づいて特定のストレージデバイスを永続ボリュームとして自動的にプロビジョニングします。永続ボリュームは、deviceInclusionSpec の条件に一致する任意のノードで nodeSelector の条件準に一致するデバイスについて作成されます。

前提条件

  • OpenShift Container Platform クラスターへの管理者アクセス。

手順

  1. local-volume-set.yaml ファイルで LocalVolumeSet カスタムリソースを定義します。

    apiVersion: local.storage.openshift.io/v1alpha1
    kind: LocalVolumeSet
    metadata:
      name: localblock
    spec:
      nodeSelector:
        nodeSelectorTerms:
          - matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                  - worker1.example.com
                  - worker2.example.com
                  - worker3.example.com
      storageClassName: localblock
      volumeMode: Block
      maxDeviceCount: 10 # optional, limit devices provisioned per node
      deviceInclusionSpec:
        deviceTypes: # list of types to allow
          - disk
          - part # omit this to use only whole devices
        deviceMechanicalProperty:
          - NonRotational
        minSize: 100Gi # optional, minimum size of device to allow
        maxSize: 100Ti # optional, maximum size of device to allow
        models: # (optional) list of models to allow
          - SAMSUNG
          - Crucial_CT525MX3
        vendors: # (optional) list of device vendors to allow
          - ATA
          - ST2000LM

    上記の定義では、worker1worker2worker3 から、ローテーションされないデバイスの特定モデルにあるディスク全体またはパーティションの内、サイズが 100 GB から 100 TB で、指定のベンダーが提供しているものを選択します。localblock ストレージクラスが作成され、永続ボリュームが検出されたデバイスからプロビジョニングされます。

    重要

    minSize に適切な値を選択し、システムパーティションが選択されないようにします。

  2. LocalVolumeSet を作成します。

    $ oc create -f local-volume-set.yaml

検証手順

  1. 以下のコマンドを使用して、deviceInclusionSpec に一致するデバイスの永続ボリュームのプロビジョニングを追跡します。永続ボリュームをプロビジョニングするのに数分かかる場合があります。

    $ oc describe localvolumeset localblock
    [...]
    Status:
      Conditions:
        Last Transition Time:          2020-11-17T05:03:32Z
        Message:                       DiskMaker: Available, LocalProvisioner: Available
        Status:                        True
        Type:                          DaemonSetsAvailable
        Last Transition Time:          2020-11-17T05:03:34Z
        Message:                       Operator reconciled successfully.
        Status:                        True
        Type:                          Available
      Observed Generation:             1
      Total Provisioned Device Count: 4
    Events:
    Type    Reason      Age          From                Message
    ----    ------      ----         ----                -------
    Normal  Discovered  2m30s (x4    localvolumeset-     ip-10-0-147-124.us-east-
            NewDevice   over 2m30s)  symlink-controller  2.compute.internal -
                                                         found possible matching
                                                         disk, waiting 1m to claim
    Normal  FoundMatch  89s (x4      localvolumeset-     ip-10-0-147-124.us-east-
            ingDisk     over 89s)    symlink-controller  2.compute.internal -
                                                         symlinking matching disk
  2. プロビジョニングされた永続ボリュームの状態を確認します。

    $ oc get pv
                         ACCESS   RECLAIM             STORAGE
    NAME       CAPACITY  MODES    POLICY   STATUS     CLASS       AGE
    local-pv-  500Gi     RWO      Delete   Available  localblock  7m48s
    3584969f
    local-pv-  500Gi     RWO      Delete   Available  localblock  7m48s
    3aee84fa
    local-pv-  500Gi     RWO      Delete   Available  localblock  7m48s
    644d09ac
    local-pv-  500Gi     RWO      Delete   Available  localblock  7m48s
    c73cee1

15.4.1.3. アノテーションの追加

以下の手順を使用して、以前のバージョンから OpenShift Container Storage 4.6 へのアップグレード時に、アノテーションをストレージクラスターに追加し、ユーザーインターフェイスを使用して、障害のあるストレージデバイスを交換できるようにします。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. HomeSearch をクリックします。
  3. ResourcesStorageCluster を検索し、それをクリックします。
  4. ocs-storagecluster の横にあるアクションメニュー (⋮)Edit annotations をクリックします。
  5. KEYVALUE にそれぞれ cluster.ocs.openshift.io/local-devicestrue を追加します。
  6. Save をクリックします。