Menu Close

Google Cloud を使用した OpenShift Data Foundation のデプロイおよび管理

Red Hat OpenShift Data Foundation 4.9

既存の Red Hat OpenShift Container Platform Google Cloud クラスターへの OpenShift Data Foundation のデプロイおよび管理手順

概要

Google Cloud で Red Hat OpenShift Data Foundation をインストールし、管理する方法については、本書をお読みください。
重要
Deploying and managing OpenShift Data Foundation on Google Cloud 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 では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社 の CTO、Chris Wright のメッセージ を参照してください。

Red Hat ドキュメントへのフィードバック (英語のみ)

弊社のドキュメントについてのご意見をお聞かせください。ドキュメントの改善点があれば、ぜひお知らせください。フィードバックをお寄せいただくには、以下をご確認ください。

  • 特定の部分についての簡単なコメントをお寄せいただく場合は、以下をご確認ください。

    1. ドキュメントの表示が Multi-page HTML 形式になっていて、ドキュメントの右上端に Feedback ボタンがあることを確認してください。
    2. マウスカーソルで、コメントを追加する部分を強調表示します。
    3. そのテキストの下に表示される Add Feedback ポップアップをクリックします。
    4. 表示される手順に従ってください。
  • より詳細なフィードバックを行う場合は、Bugzilla のチケットを作成します。

    1. Bugzilla の Web サイトに移動します。
    2. Component で Documentation を選択します。
    3. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
    4. Submit Bug をクリックします。

前書き

Red Hat OpenShift Data Foundation 4.9 では、既存の Red Hat OpenShift Container Platform (RHOCP) Google Cloud クラスターでのデプロイメントをサポートします。

注記

Google Cloud では、内部の OpenShift Data Foundation クラスターのみがサポートされます。デプロイメントの要件についての詳細は、『Planning your deployment』を参照してください。

内部モードで OpenShift Data Foundation をデプロイするには、OpenShift Data Foundation のデプロイの準備についての章の要件を確認し、要件に応じて適切なデプロイメントプロセスを実行します。

第1章 OpenShift Data Foundation のデプロイの準備

動的ストレージデバイスを使用して OpenShift Data Foundation を OpenShift Container Platform にデプロイすると、内部クラスターリソースを作成するオプションが提供されます。これにより、ベースサービスの内部プロビジョニングが可能になり、追加のストレージクラスをアプリケーションで使用可能にすることができます。

OpenShift Data Foundation のデプロイを開始する前に、以下を実行します。

  1. オプション: 外部鍵管理システム(KMS)を使用してクラスター全体の暗号化を有効にするには、以下を実行します。

  2. ノードの最小要件 [テクノロジープレビュー]

    OpenShift Data Foundation クラスターは、標準のデプロイメントリソース要件を満たしていない場合に、最小の設定でデプロイされます。『プランニングガイド』の「リソース要件」のセクションを参照してください。

  3. Regional-DR 要件 [開発者プレビュー]

    Red Hat OpenShift Data Foundation でサポートされる障害復旧機能では、障害復旧ソリューションを正常に実装するために以下の前提条件がすべて必要になります。

    • 有効な Red Hat OpenShift Data Foundation Advanced サブスクリプション
    • 有効な Red Hat Advanced Cluster Management for Kubernetes サブスクリプション

      詳細な要件は、Regional-DR requirements および RHACM requirements を参照してください。

1.1. Vault でのキー値のバックエンドパスおよびポリシーの有効化

前提条件

  • Vault への管理者アクセス。
  • 注: 後に変更することはできないため、命名規則に基づいてバックエンド path として一意のパス名を選択します。

手順

  1. Vault で Key/Value (KV) バックエンドパスを有効にします。

    Vault KV シークレットエンジン API の場合は、バージョン 1 を使用します。

    $ vault secrets enable -path=ocs kv

    Vault KV シークレットエンジン API の場合は、バージョン 2 です。

    $ vault secrets enable -path=ocs kv-v2
  2. 以下のコマンドを使用して、シークレットでの書き込み操作または削除操作の実行をユーザーを制限するポリシーを作成します。

    echo '
    path "ocs/*" {
      capabilities = ["create", "read", "update", "delete", "list"]
    }
    path "sys/mounts" {
    capabilities = ["read"]
    }'| vault policy write ocs -
  3. 上記のポリシーに一致するトークンを作成します。

    $ vault token create -policy=ocs -format json

第2章 GoogleCloud への OpenShift Data Foundation のデプロイ

Google Cloud のインストーラーでプロビジョニングされるインフラストラクチャーによって提供される動的ストレージデバイスを使用して、OpenShift Data Foundation を OpenShift Container Platform にデプロイできます。これにより、内部クラスターリソースを作成でき、ベースサービスの内部プロビジョニングが可能になり、追加のストレージクラスをアプリケーションで使用可能にすることができます。

また、OpenShift Data Foundation で Multicloud Object Gateway (MCG) コンポーネントのみをデプロイすることもできます。詳細は、Deploy standalone Multicloud Object Gateway を参照してください。

注記

Google Cloud では、内部の OpenShift Data Foundation クラスターのみがサポートされます。デプロイメントの要件についての詳細は、『Planning your deployment』を参照してください。

OpenShift Data Foundation のデプロイの準備についての章にある要件に対応していることを確認してから、動的ストレージデバイスを使用したデプロイについて以下の手順を実行してください。

2.1. Red Hat OpenShift Data Foundation Operator のインストール

Red Hat OpenShift Data Foundation Operator は、Red Hat OpenShift Container Platform Operator Hub を使用してインストールできます。

前提条件

  • cluster-admin および Operator インストールのパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
  • Red Hat OpenShift Container Platform クラスターにワーカーノードが少なくとも 3 つある。
  • その他のリソース要件については、『デプロイメントのプランニング』ガイドを参照してください。
重要
  • OpenShift Data Foundation のクラスター全体でのデフォルトノードセレクターを上書きする必要がある場合は、コマンドラインインターフェースで以下のコマンドを使用し、openshift-storage namespace の空のノードセレクターを指定できます (この場合、openshift-storage namespace を作成します)。

    $ oc annotate namespace openshift-storage openshift.io/node-selector=
  • ノードに Red Hat OpenShift Data Foundation リソースのみがスケジュールされるように infra のテイントを設定します。これにより、サブスクリプションコストを節約できます。詳細は、ストレージリソースの管理および割り当てガイドのHow to use dedicated worker nodes for Red Hat OpenShift Data Foundationの章を参照してください。

手順

  1. OpenShift Web コンソールにログインします。
  2. Operators → OperatorHub をクリックします。
  3. スクロールするか、または OpenShift Data FoundationFilter by keyword ボックスに入力し、OpenShift Data Foundation Operator を検索します。
  4. Install をクリックします。
  5. Install Operator ページで、以下のオプションを設定します。

    1. Channel を stable-4.9 として更新します。
    2. Installation Mode オプションに A specific namespace on the cluster を選択します。
    3. Installed Namespace に Operator recommended namespace openshift-storage を選択します。namespace openshift-storage が存在しない場合、これは Operator のインストール時に作成されます。
    4. 承認ストラテジー を Automatic または Manual として選択します。

      Automatic (自動) 更新を選択した場合、Operator Lifecycle Manager (OLM) は介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。

      Manual 更新を選択した場合、OLM は更新要求を作成します。クラスター管理者は、Operator を新しいバージョンに更新できるように更新要求を手動で承認する必要があります。

    5. Console プラグインEnable オプションが選択されていることを確認します。
    6. Install をクリックします。
注記

すべてのデフォルト設定を使用することが推奨されます。これを変更すると、予期しない動作が発生する可能性があります。変更後にどうなるのかを認識している場合に限り変更します。

検証手順

  • OpenShift Data Foundation Operator に、インストールが正常に実行されたことを示す緑色のチェックマークが表示されていることを確認します。
  • Operator が正常にインストールされると、Web console update is available メッセージを含むポップアップがユーザーインターフェースに表示されます。このポップアップから Web コンソールのリフレッシュ をクリックして、反映するコンソールを変更します。

    • Web コンソールで、Operators に移動し、OpenShift Data Foundation が利用可能かどうかを確認します。
重要

OpenShift Data Foundation Operator のインストール後に console プラグインオプションが自動的に有効にされていない場合は、これを有効にする必要があります。

console プラグインを有効にする方法の詳細は、「 Red Hat OpenShift Data Foundation console プラグインの有効化 」を参照してください。

2.2. OpenShift Data Foundation クラスターの作成

OpenShift Data Foundation Operator のインストール後に OpenShift Data Foundation クラスターを作成します。

前提条件

  • OpenShift Data Foundation Operator は Operator Hub からインストールする必要があります。詳細は、Installing OpenShift Data Foundation Operatorを参照してください。
  • Google Cloud プラットフォームのデフォルトのストレージクラスはハードディスクドライブ (HDD) を使用することに注意してください。パフォーマンスを向上させるためにソリッドステートドライブ (SSD) ベースのディスクを使用するには、以下の ssd-storeageclass.yaml の例に示されるように pd-ssd を使用してストレージクラスを作成する必要があります。

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
     name: faster
    provisioner: kubernetes.io/gce-pd
    parameters:
     type: pd-ssd
    volumeBindingMode: WaitForFirstConsumer
    reclaimPolicy: Delete

手順

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

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

  2. OpenShift Data Foundation Operator をクリックした後、Create StorageSystem をクリックします。
  3. Backing storage ページで、以下を選択します。

    1. Use an existing StorageClass オプションを選択します。
    2. Storage Class を選択します。

      デフォルトでは、standard に設定されます。ただし、パフォーマンスを向上させるために SSD ベースのディスクを使用するようにストレージクラスを作成している場合は、ストレージクラスを選択する必要があります。

    3. Advanced を展開し、Deployment type オプションで Full Deployment を選択します。
    4. Next をクリックします。
  4. Capacity and nodes ページで、必要な情報を提供します。

    1. ドロップダウンリストから Requested Capacity の値を選択します。デフォルトで、これは 2 TiB に設定されます。

      注記

      初期ストレージ容量を選択すると、クラスターの拡張は、選択された使用可能な容量を使用してのみ実行されます(raw ストレージの 3 倍)。

    2. Select Nodes セクションで、少なくとも 3 つの利用可能なノードを選択します。

      複数のアベイラビリティーゾーンを持つクラウドプラットフォームの場合は、ノードが異なる場所/アベイラビリティーゾーンに分散されていることを確認します。

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

    3. Next をクリックします。
  5. 必要に応じて、Security and network ページで、要件に応じて以下を設定します。

    1. 暗号化を有効にするには、Enable data encryption for block and file storage を選択します。
    2. 暗号化レベルのいずれかまたは両方を選択します。

      • クラスター全体の暗号化

        クラスター全体を暗号化します(ブロックおよびファイル)。

      • StorageClass の暗号化

        暗号化対応のストレージクラスを使用して、暗号化された永続ボリューム(ブロックのみ)を作成します。

    3. Connect to an external key management service チェックボックスを選択します。これはクラスター全体の暗号化の場合はオプションになります。

      1. Key Management Service Provider はデフォルトで Vault に設定されます。
      2. Vault Service Name、Vault サーバーのホスト Address('https://<hostname または ip>')、Port 番号および Token を入力します。
      3. Advanced Settings を展開して、Vault 設定に基づいて追加の設定および証明書の詳細を入力します。

        1. OpenShift Data Foundation 専用かつ特有のキー値のシークレットパスを Backend Path に入力します。
        2. オプション: TLS Server Name および Vault Enterprise Namespace を入力します。
        3. それぞれの PEM でエンコードされた証明書ファイルをアップロードし、CA 証明書クライアント証明書、および クライアントの秘密鍵 を提供します。
        4. 保存 をクリックします。
    4. Next をクリックします。
  6. Review and create ページで、設定の詳細を確認します。

    構成設定を変更するには、Back をクリックします。

  7. Create StorageSystem をクリックします。

検証手順

  • インストールされたストレージクラスターの最終ステータスを確認するには、以下を実行します。

    1. OpenShift Web コンソールで、Installed OperatorsOpenShift Data FoundationStorage Systemocs-storagecluster-storagesystemResources の順に移動します。
    2. StorageClusterStatusReady になっており、それの横に緑色のチェックマークが表示されていることを確認します。

      1. OpenShift Data Foundation のすべてのコンポーネントが正常にインストールされていることを確認するには、Verifying your OpenShift Data Foundation deployment を参照してください。

関連情報

Overprovision Control アラートを有効にするには、モニタリングガイドの アラート を参照してください。

2.3. OpenShift Data Foundation デプロイメントの確認

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

2.3.1. Pod の状態の確認

手順

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

    注記

    Show default projects オプションが無効になっている場合は、切り替えボタンを使用して、すべてのデフォルトプロジェクトを一覧表示します。

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

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

    表2.1 OpenShift Data Foundation クラスターに対応する Pod

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

    OpenShift Data Foundation Operator

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

    Rook-ceph Operator

    rook-ceph-operator-*

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

    Multicloud Object Gateway

    • noobaa-operator-* (任意のワーカーノードに 1 Pod)
    • noobaa-core-* (任意のストレージノードに 1 Pod)
    • noobaa-db-pg-* (任意のストレージノードに 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)

    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.3.2. OpenShift Data Foundation クラスターの正常性の確認

手順

  1. OpenShift Web コンソールで、StorageOpenShift Data Foundation をクリックします。
  2. Overview タブの Status カードで Storage System をクリックし、表示されたポップアップからストレージシステムリンクをクリックします。
  3. Block and File タブの Status カードで、Storage Cluster に緑色のチェックマークが表示されていることを確認します。
  4. Details カードで、クラスター情報が表示されていることを確認します。

ブロックおよびファイルダッシュボードを使用した OpenShift Data Foundation クラスターの正常性については、「Monitoring OpenShift Data Foundation」を参照してください。

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

手順

  1. OpenShift Web コンソールで、StorageOpenShift Data Foundation をクリックします。
  2. Overview タブの Status カードで Storage System をクリックし、表示されたポップアップからストレージシステムリンクをクリックします。

    1. Object タブの Status カードでObject ServiceData Resiliency の両方に緑色のチェックマークが表示されていることを確認します。
    2. Details カードで、MCG 情報が表示されることを確認します。

オブジェクトサービスダッシュボードを使用した OpenShift Data Foundation クラスターの正常性については、「 Monitoring OpenShift Data Foundation 」を参照してください。

2.3.4. OpenShift Data Foundation 固有のストレージクラスが存在することの確認

手順

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

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

第3章 スタンドアロンの Multicloud Object Gateway のデプロイ

OpenShift Data Foundation で Multicloud Object Gateway コンポーネントのみをデプロイすると、デプロイメントで柔軟性が高まり、リソース消費を減らすことができます。このセクションでは、以下のステップで、スタンドアロンの Multicloud Object Gateway コンポーネントのみをデプロイします。

  • Red Hat OpenShift Data Foundation Operator のインストール
  • スタンドアロンの Multicloud Object Gateway の作成

3.1. Red Hat OpenShift Data Foundation Operator のインストール

Red Hat OpenShift Data Foundation Operator は、Red Hat OpenShift Container Platform Operator Hub を使用してインストールできます。

前提条件

  • cluster-admin および Operator インストールのパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
  • Red Hat OpenShift Container Platform クラスターにワーカーノードが少なくとも 3 つある。
  • その他のリソース要件については、『デプロイメントのプランニング』ガイドを参照してください。
重要
  • OpenShift Data Foundation のクラスター全体でのデフォルトノードセレクターを上書きする必要がある場合は、コマンドラインインターフェースで以下のコマンドを使用し、openshift-storage namespace の空のノードセレクターを指定できます (この場合、openshift-storage namespace を作成します)。

    $ oc annotate namespace openshift-storage openshift.io/node-selector=
  • ノードに Red Hat OpenShift Data Foundation リソースのみがスケジュールされるように infra のテイントを設定します。これにより、サブスクリプションコストを節約できます。詳細は、ストレージリソースの管理および割り当てガイドのHow to use dedicated worker nodes for Red Hat OpenShift Data Foundationの章を参照してください。

手順

  1. OpenShift Web コンソールにログインします。
  2. Operators → OperatorHub をクリックします。
  3. スクロールするか、または OpenShift Data FoundationFilter by keyword ボックスに入力し、OpenShift Data Foundation Operator を検索します。
  4. Install をクリックします。
  5. Install Operator ページで、以下のオプションを設定します。

    1. Channel を stable-4.9 として更新します。
    2. Installation Mode オプションに A specific namespace on the cluster を選択します。
    3. Installed Namespace に Operator recommended namespace openshift-storage を選択します。namespace openshift-storage が存在しない場合、これは Operator のインストール時に作成されます。
    4. 承認ストラテジー を Automatic または Manual として選択します。

      Automatic (自動) 更新を選択した場合、Operator Lifecycle Manager (OLM) は介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。

      Manual 更新を選択した場合、OLM は更新要求を作成します。クラスター管理者は、Operator を新しいバージョンに更新できるように更新要求を手動で承認する必要があります。

    5. Console プラグインEnable オプションが選択されていることを確認します。
    6. Install をクリックします。
注記

すべてのデフォルト設定を使用することが推奨されます。これを変更すると、予期しない動作が発生する可能性があります。変更後にどうなるのかを認識している場合に限り変更します。

検証手順

  • OpenShift Data Foundation Operator に、インストールが正常に実行されたことを示す緑色のチェックマークが表示されていることを確認します。
  • Operator が正常にインストールされると、Web console update is available メッセージを含むポップアップがユーザーインターフェースに表示されます。このポップアップから Web コンソールのリフレッシュ をクリックして、反映するコンソールを変更します。

    • Web コンソールで、Operators に移動し、OpenShift Data Foundation が利用可能かどうかを確認します。
重要

OpenShift Data Foundation Operator のインストール後に console プラグインオプションが自動的に有効にされていない場合は、これを有効にする必要があります。

console プラグインを有効にする方法の詳細は、「 Red Hat OpenShift Data Foundation console プラグインの有効化 」を参照してください。

3.2. スタンドアロンの Multicloud Object Gateway の作成

このセクションを使用して、OpenShift Data Foundation で Multicloud Object Gateway コンポーネントのみを作成します。

前提条件

  • OpenShift Data Foundation Operator がインストールされていることを確認します。
  • (ローカルストレージデバイスを使用したデプロイのみ)Local Storage Operator がインストールされていることを確認します。
  • ストレージクラスがあり、これがデフォルトとして設定されていることを確認します。

手順

  1. OpenShift Web コンソールで、OperatorsInstalled Operators をクリックし、インストールされた Operator を表示します。

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

  2. OpenShift Data Foundation Operator をクリックした後、Create StorageSystem をクリックします。
  3. Backing storage ページで、Advanced を展開します。
  4. Deployment typeMulticloud Object Gateway を選択します。
  5. Next をクリックします。
  6. 必要に応じて、Security ページで Connect to an external key management service を選択します。

    1. Key Management Service Provider はデフォルトで Vault に設定されます。
    2. Vault Service Name、Vault サーバーのホスト Address('https://<hostname or ip>')、Port number および Token を入力します。
    3. Advanced Settings を展開して、Vault 設定に基づいて追加の設定および証明書の詳細を入力します。

      1. OpenShift Data Foundation 専用で固有のキーバリューシークレットパスを Backend Path に入力します。
      2. オプション: TLS Server Name および Vault Enterprise Namespace を入力します。
      3. それぞれの PEM でエンコードされた証明書ファイルをアップロードし、CA 証明書クライアント証明書、および クライアントの秘密鍵 を提供します。
      4. 保存 をクリックします。
    4. Next をクリックします。
  7. Review and create ページで、設定の詳細を確認します。

    構成設定を変更するには、Back をクリックします。

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

検証手順

OpenShift Data Foundation クラスターが正常であることの確認
  1. OpenShift Web コンソールで、StorageOpenShift Data Foundation をクリックします。
  2. Overview タブの Status カードで Storage System をクリックし、表示されたポップアップからストレージシステムリンクをクリックします。

    1. Object タブの Status カードでObject ServiceData Resiliency の両方に緑色のチェックマークが表示されていることを確認します。
    2. Details カードで、MCG 情報が表示されることを確認します。
Pod の状態を確認します。
  1. OpenShift Web コンソールから Workloads → Pods をクリックします。
  2. Project ドロップダウンリストから openshift-storage を選択し、以下の Pod が Running 状態にあることを確認します。

    注記

    Show default projects オプションが無効になっている場合は、切り替えボタンを使用して、すべてのデフォルトプロジェクトを一覧表示します。

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

    OpenShift Data Foundation Operator

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

    Rook-ceph Operator

    rook-ceph-operator-*

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

    Multicloud Object Gateway

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

第4章 OpenShift Data Foundation のアンインストール

4.1. 内部モードでの OpenShift Data Foundation のアンインストール

OpenShift Data Foundation を Internal モードでアンインストールするには、knowledge base article on Uninstalling OpenShift Data Foundation を参照してください。

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

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

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

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

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

注記

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

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

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

前提条件

  • OpenShift Container Platform の Web コンソールにログインしており、OpenShift Data Foundation クラスターが Ready 状態にあることを確認します。

手順

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

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

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

    5. Create をクリックして新規ストレージプールを作成します。
    6. プールの作成後に Finish をクリックします。
  7. 必要に応じて、Enable Encryption チェックボックスを選択します。
  8. Create をクリックしてストレージクラスを作成します。

5.2. 永続ボリュームの暗号化用のストレージクラスの作成

永続ボリューム(PV)暗号化は、テナント(アプリケーション)の分離および機密性を保証します。PV 暗号化を使用する前に、PV 暗号化のストレージクラスを作成する必要があります。

OpenShift Data Foundation は、HashiCorp Vault での暗号化パスフレーズの保存をサポートします。以下の手順を使用して、永続ボリュームの暗号化用に外部の鍵管理システム (KMS) を使用して暗号化対応のストレージクラスを作成します。永続ボリュームの暗号化は RBD PV でのみ利用できます。KMS へのアクセスを設定するには、以下の 2 つの方法があります。

  • vaulttokens の使用: ユーザーはトークンを使用して認証できるようにします。
  • vaulttenantsa(テクノロジープレビュー): ユーザーは serviceaccount を使用して Vault で認証できるようにします。
重要

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

詳細は、「テクノロジープレビュー機能のサポート範囲」を参照してください。

ストレージクラスの作成手順を実行する前に、ユースケースに関連する前提条件のセクションを参照してください。

5.2.1. vaulttokens を使用するための前提条件

  • OpenShift Data Foundation クラスターは Ready 状態である。
  • 外部の鍵管理システム(KMS)で、以下を実行します。

    • トークンのあるポリシーが存在し、Vault のキー値のバックエンドパスが有効にされていることを確認します。詳細は、Enabling key value and policy in Vaultを参照してください。
    • Vault サーバーで署名済みの証明書を使用していることを確認します。
  • 以下のようにテナントの namespace にシークレットを作成します。

    • OpenShift Container Platform Web コンソールで、Workloads → Secrets に移動します。
    • Create → Key/value secret をクリックします。
    • Secret Nameceph-csi-kms-token として入力します。
    • Keytoken として入力します。
    • Value を入力します。これは Vault のトークンです。Browse をクリックしてトークンが含まれるファイルを選択し、アップロードするか、またはテキストボックスにトークンを直接入力します。
    • Create をクリックします。
注記

トークンは、ceph-csi-kms-token を使用するすべての暗号化された PVC が削除された後にのみ削除できます。

次に、「PV 暗号化のストレージクラスを作成する手順」 に記載の手順を実行します。

5.2.2. vaulttenantsaを使用するための前提条件

  • OpenShift Data Foundation クラスターは Ready 状態である。
  • 外部の鍵管理システム(KMS)で、以下を実行します。

    • ポリシーが存在し、Vault のキー値のバックエンドパスが有効になっていることを確認します。詳細は、Enabling key value and policy in Vaultを参照してください。
    • Vault サーバーで署名済みの証明書を使用していることを確認します。
  • 以下のようにテナント namespace に以下の serviceaccount を作成します。

    $ cat <<EOF | oc create -f -
    apiVersion: v1
    kind: ServiceAccount
    metadata:
        name: ceph-csi-vault-sa
    EOF
  • Kubernetes の認証方法は、OpenShift Data Foundation が Vault を使用して認証し、開始する前に設定する必要があります。以下の手順では、OpenShift Data Foundation が Vault で認証できるように、serviceAccountClusterRole、および ClusterRoleBinding を作成し、設定します。

    1. 以下の YAML を Openshift クラスターに適用します。

      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: rbd-csi-vault-token-review
      ---
      kind: ClusterRole
      apiVersion: rbac.authorization.k8s.io/v1
      metadata:
        name: rbd-csi-vault-token-review
      rules:
        - apiGroups: ["authentication.k8s.io"]
          resources: ["tokenreviews"]
          verbs: ["create", "get", "list"]
      
      ---
      kind: ClusterRoleBinding
      apiVersion: rbac.authorization.k8s.io/v1
      metadata:
        name: rbd-csi-vault-token-review
      subjects:
        - kind: ServiceAccount
          name: rbd-csi-vault-token-review
          namespace: openshift-storage
      roleRef:
        kind: ClusterRole
        name: rbd-csi-vault-token-review
        apiGroup: rbac.authorization.k8s.io
    2. 上記で作成された serviceaccount (SA) に関連付けられたシークレット名を特定します。

      $ oc -n openshift-storage get sa rbd-csi-vault-token-review -o jsonpath="{.secrets[*]['name']}"
    3. シークレットからトークンと CA 証明書を取得します。

      $ oc get secret <secret associated with SA> -o jsonpath="{.data['token']}" | base64 --decode; echo
      $ oc get secret <secret associated with SA> -o jsonpath="{.data['ca\.crt']}" | base64 --decode; echo
    4. OCP クラスターエンドポイントを取得します。

      $ oc config view --minify --flatten -o jsonpath="{.clusters[0].cluster.server}"
    5. 上記の手順で収集した情報を使用して、以下に示すように Vault で kubernetes 認証方法を設定します。

      $ vault auth enable kubernetes
      $ vault write auth/kubernetes/config token_reviewer_jwt=<SA token> kubernetes_host=<OCP cluster endpoint> kubernetes_ca_cert=<SA CA certificate>
    6. テナント namespace の Vault にロールを作成します。

      $ vault write "auth/kubernetes/role/csi-kubernetes" bound_service_account_names="ceph-csi-vault-sa" bound_service_account_namespaces=<tenant_namespace> policies=<policy_name_in_vault>

      csi-kubernetes は、OpenShift Data Foundation が Vault を検索するデフォルトのロール名です。Openshift Data Foundation クラスターのテナント namespace のデフォルトのサービスアカウント名は ceph-csi-vault-sa です。これらのデフォルト値は、テナント namespace に ConfigMap を作成して上書きできます。

      デフォルト名の上書きに関する詳細は、Overriding Vault connection details using tenant ConfigMap を参照してください。

  • PV 暗号化の vaulttenantsa メソッドを使用する storageclass を作成するには、既存の ConfigMap を編集するか、Vault との接続を確立するのに必要なすべての情報を保持する csi-kms-connection-details という名前の ConfigMap を作成する必要があります。

    以下の yaml のサンプルを使用して、csi-kms-connection-detail ConfigMap を更新または作成できます。

    apiVersion: v1
    data:
      vault-tenant-sa: |-
        {
          "encryptionKMSType": "vaulttenantsa",
          "vaultAddress": "<https://hostname_or_ip_of_vault_server:port>",
          "vaultTLSServerName": "<vault TLS server name>",
          "vaultAuthPath": "/v1/auth/kubernetes/login",
          "vaultAuthNamespace": "<vault auth namespace name>"
          "vaultNamespace": "<vault namespace name>",
          "vaultBackendPath": "<vault backend path name>",
          "vaultCAFromSecret": "<secret containing CA cert>",
          "vaultClientCertFromSecret": "<secret containing client cert>",
          "vaultClientCertKeyFromSecret": "<secret containing client private key>",
          "tenantSAName": "<service account name in the tenant namespace>"
        }
    metadata:
      name: csi-kms-connection-details
    • encryptionKMSType: vault との認証にサービスアカウントを使用するには、vaulttenantsa に設定する必要があります。
    • vaultAddress: ポート番号を持つ vault サーバーのホスト名または IP アドレス。
    • vaultTLSServerName:(オプション)vault TLS サーバー名
    • VaultAuthPath:(オプション)Vault で kubernetes 認証メソッドが有効になっているパス。デフォルトのパスは kubernetes です。auth メソッドが kubernetes 以外のパスで有効になっている場合は、この変数を "/v1/auth/<path>/login" として設定する必要があります。
    • VaultAuthNamespace:(オプション)kubernetes 認証メソッドが有効にされている Vault namespace。
    • vaultNamespace:(オプション)キーの保存に使用されるバックエンドパスが存在する Vault 名前空間
    • VaultBackendPath: 暗号化キーが保存される Vault のバックエンドパス
    • VaultCAFromSecret: Vault の CA 証明書が含まれる OpenShift Data Foundation クラスターのシークレット
    • vaultClientCertFromSecret: Vault からのクライアント証明書が含まれる OpenShift Data Foundation クラスターのシークレット
    • VaultClientCertKeyFromSecret: Vault からのクライアントの秘密鍵を含む OpenShift Data Foundation クラスターのシークレット
    • tenantSAName:(オプション)テナント namespace のサービスアカウント名。デフォルト値は ceph-csi-vault-sa です。別の名前を使用する場合は、この変数を適切に設定する必要があります。

次に、「PV 暗号化のストレージクラスを作成する手順」 に記載の手順を実行します。

5.2.3. PV 暗号化のストレージクラスを作成する手順

vaulttokens または vaulttenantsa のいずれかに必要な前提条件を実行した後に、以下の手順を実行し、暗号化を有効にして storageclass を作成します。

  1. StorageStorageClasses に移動します。
  2. Create Storage Class をクリックします。
  3. ストレージクラスの Name および Description を入力します。
  4. Reclaim Policy について Delete または Retain のいずれかを選択します。デフォルトでは、Delete が選択されます。
  5. Immediate または WaitForFirstConsumerVolume binding モード として選択します。WaitForConsumer はデフォルトオプションとして設定されます。
  6. 永続ボリュームをプロビジョニングするために使用されるプラグインである RBD Provisioner openshift-storage.rbd.csi.ceph.com を選択します。
  7. ボリュームデータが保存される Storage Pool をリストから選択するか、新規プールを作成します。
  8. Enable encryption チェックボックスを選択します。KMS 接続の詳細を設定するオプションは 2 つあります。

    • Select existing KMS connection : ドロップダウンリストから既存の KMS 接続を選択 します。この一覧は、csi-kms-connection-details ConfigMap で利用可能な接続の詳細から設定されます。
    • Create new KMS connection: これは vaulttokens のみに適用されます。

      1. Key Management Service Provider はデフォルトで Vault に設定されます。
      2. Vault サーバーの一意の Vault Service Name、ホスト Address (https://<hostname or ip>)、および Port 番号を入力します。
      3. Advanced Settings を展開して、Vault 設定に基づいて追加の設定および証明書の詳細を入力します。

        1. OpenShift Data Foundation 専用で固有のキーバリューシークレットパスを Backend Path に入力します。
        2. オプションTLS Server Name および Vault Enterprise Namespace を入力します。
        3. それぞれの PEM でエンコードされた証明書ファイルをアップロードして、CA CertificateClient Certificate、および Client Private Key を指定します。
        4. 保存 をクリックします。
      4. 保存 をクリックします。
  9. Create をクリックします。
  10. HashiCorp Vault 設定により、バックエンドパスによって使用されるキー/値 (KV) シークレットエンジン API バージョンの自動検出が許可されない場合は、ConfigMap を編集して VAULT_BACKEND パラメーターまたは vaultBackend パラメーターを追加します。

    注記

    VAULT_BACKEND または vaultBackend は、バックエンドパスに関連付けられた KV シークレットエンジン API のバージョンを指定するために configmap に追加されるオプションのパラメーターです。値がバックエンドパスに設定されている KV シークレットエンジン API バージョンと一致していることを確認します。一致しない場合には、永続ボリューム要求(PVC)の作成時に失敗する可能性があります。

    1. 新規に作成されたストレージクラスによって使用されている encryptionKMSID を特定します。

      1. OpenShift Web コンソールで、StorageStorage Classes に移動します。
      2. Storage class 名 → YAML タブをクリックします。
      3. ストレージクラスによって使用されている encryptionKMSID を取得します。

        例:

        encryptionKMSID: 1-vault
    2. OpenShift Web コンソールで WorkloadsConfigMaps に移動します。
    3. KMS 接続の詳細を表示するには、csi-kms-connection-details をクリックします。
    4. ConfigMap を編集します。

      1. アクションメニュー (⋮)Edit ConfigMap をクリックします。
      2. 以前に特定した encryptionKMSID に設定されるバックエンドに応じて、VAULT_BACKEND パラメーターまたは vaultBackend パラメーターを追加します。

        KV シークレットエンジン API バージョン 1 の場合は kv を、KV シークレットエンジン API バージョン 2 の場合は kv-v2 を、それぞれ割り当てることができます。

        例:

         kind: ConfigMap
         apiVersion: v1
         metadata:
           name: csi-kms-connection-details
         [...]
         data:
           1-vault: |-
             {
               "KMS_PROVIDER": "vaulttokens",
               "KMS_SERVICE_NAME": "1-vault",
               [...]
               "VAULT_BACKEND": "kv-v2"
             }
           2-vault: |-
             {
               "encryptionKMSType": "vaulttenantsa",
               [...]
               "vaultBackend": "kv-v2"
             }
      3. 保存をクリックします。

次のステップ

  • ストレージクラスを使用して、暗号化された永続ボリュームを作成できます。詳細は、「managing persistent volume claims」を参照してください。

    重要

    Red Hat はテクノロジーパートナーと連携して、本書をお客様へのサービスとして提供します。ただし、Red Hat では、HashiCorp 製品のサポートを提供していません。この製品に関するテクニカルサポートについては、HashiCorp にお問い合わせください。

5.2.3.1. テナント ConfigMap を使用した Vault 接続の詳細の上書き

Vault 接続の詳細は、openshift-storage namespace の csi-kms-connection-details ConfigMap で設定された値とは異なる設定オプションを使用して、OpenShift namespace に ConfigMap を作成することにより、テナントごとに再設定できます。ConfigMap はテナント namespace に配置する必要があります。テナント namespace の ConfigMap の値は、その namespace で作成される暗号化された永続ボリュームの csi-kms-connection-details ConfigMap に設定された値を上書きします。

手順

  1. テナント namespace にあることを確認します。
  2. Workloads → ConfigMaps をクリックします。
  3. Create ConfigMap をクリックします。
  4. yaml ファイルの例を以下に示します。指定のテナント namespace について過剰に使用される値は、以下に示すように data セクションで指定できます。

    ---
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: ceph-csi-kms-config
    data:
      vaultAddress: "<vault_address:port>"
      vaultBackendPath: "<backend_path>"
      vaultTLSServerName: "<vault_tls_server_name>"
      vaultNamespace: "<vault_namespace>"
  5. yaml を編集したら、Create をクリックします。

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

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

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

警告

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

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

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

6.1. OpenShift Data Foundation を使用するためのイメージレジストリーの設定

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

このセクションの手順に従って、OpenShift Data Foundation をコンテナーイメージレジストリーのストレージとして設定します。Google Cloud では、レジストリーのストレージを変更する必要はありません。

警告

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

前提条件

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

手順

  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) のアクセスモードを指定します。
      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. 保存 をクリックします。
  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)。

6.2. OpenShift Data Foundation を使用するためのモニタリングの設定

OpenShift Data Foundation は、Prometheus および Alert Manager で構成されるモニタリングスタックを提供します。

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

重要

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

Red Hat は、このサービスの保持期間を短く設定することを推奨します。詳細は、OpenShift Container Platform ドキュメントの『Monitoring guide』の「Modifying retention time for Prometheus metrics data」を参照してください。

前提条件

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

手順

  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 をクリックして Config Map を保存し、作成します。

検証手順

  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 に割り当てられていることを確認します。

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

      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)のいずれかに一致する Typeocs-alertmanager-claim があることを確認します(例: ocs-alertmanager-claim-alertmanager-main-0)

      図6.2 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)のいずれかに一致する Typeocs-prometheus-claim があることを確認します(例: ocs-prometheus-claim-prometheus-k8s-0)

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

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

6.3. OpenShift Data Foundation のクラスターロギング

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

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

重要

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

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

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

6.3.1. Configuring persistent storage

ストレージクラス名およびサイズパラメーターを使用して、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 レプリケーションポリシーについての詳細は、「About deploying and configuring cluster logging」の Elasticsearch レプリケーションポリシー について参照してください。

注記

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

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

詳細は、「Configuring cluster logging」を参照してください。

6.3.2. OpenShift Data Foundation を使用するためのクラスターロギングの設定

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

注記

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

前提条件

  • OpenShift Web コンソールへの管理者アクセスがある。
  • OpenShift Data Foundation 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 Data Foundation ノードにテイントのマークが付けられている場合、ロギング用に daemonset Pod のスケジューリングを有効にするために容認を追加する必要があります。

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

検証手順

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

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

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

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

    1. Workload → Pods をクリックします。
    2. Project を 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)の名前をクリックし、PersistentVolumeClaim Overview ページでストレージクラス名を確認します。
注記

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

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

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

詳細は、「Curation of Elasticsearch Data」を参照してください。

注記

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

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

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

前提条件

  • OpenShift Container Platform がインストールされており、OpenShift Web コンソールへの管理者アクセスがある。
  • OpenShift Data Foundation が 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. 保存 をクリックします。

検証手順

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

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

第8章 Red Hat OpenShift Data Foundation に専用のワーカーノードを使用する方法

Red Hat OpenShift Container Platform サブスクリプションには、OpenShift Data Foundation サブスクリプションが必要です。ただし、インフラストラクチャーノードを使用して OpenShift Data Foundation リソースをスケジュールする場合は、OpenShift Container Platform サブスクリプションコストを節約できます。

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

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

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

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

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

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

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

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

    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: ""

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

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

注記

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

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

  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: ""

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

マシン API が環境内でサポートされない場合にのみ、ラベルはノードに直接適用される必要があります。手動作成では、OpenShift Data Foundation サービスをスケジュールするために少なくとも 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 Data Foundation テイントを追加することも、infra ノードが OpenShift Data Foundation リソースのみをスケジュールし、その他の OpenShift Data Foundation ワークロードを拒否できるようにするために必要です。

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 Data Foundation テイントを追加するだけで、エンタイトルメント免除要件を満たすことができます。

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

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

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

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

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

警告

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

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

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

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

9.2. Google Cloud インフラストラクチャーの OpenShift Data Foundation ノードへの容量の追加によるストレージのスケールアップ

設定された Red Hat OpenShift Data Foundation ワーカーノードにストレージ容量およびパフォーマンスを追加できます。

前提条件

  • 実行中の OpenShift Data Foundation Platform。
  • OpenShift Web コンソールの管理者権限
  • デプロイメント時にプロビジョニングされたストレージクラス以外のストレージクラスを使用してスケーリングするには、最初に追加のストレージクラスを定義します。詳細は、「ストレージクラスの作成」を参照してください。

手順

  1. OpenShift Web コンソールにログインします。
  2. Operators → Installed Operators をクリックします。
  3. OpenShift Data Foundation Operator をクリックします。
  4. Storage Systems タブをクリックします。

    1. ストレージシステム名の右側にある Action Menu (⋮) をクリックし、オプションメニューを拡張します。
    2. オプションメニューから Add Capacity を選択します。
    3. Storage Class を選択します。

HDD を使用するデフォルトのストレージクラスを使用している場合は、ストレージクラスを standard に設定します。ただし、パフォーマンスを向上させるために SSD ベースのディスクを使用するようにストレージクラスを作成している場合は、ストレージクラスを選択する必要があります。

+ Raw Capacity フィールドには、ストレージクラスの作成時に設定されるサイズが表示されます。OpenShift Data Foundation はレプリカ数 3 を使用するため、消費されるストレージの合計量はこの量の 3 倍になります。

  1. Add をクリックします。

    1. ステータスを確認するには、StorageOpenShift Data Foundation に移動し、Status カードの Storage System に緑色のチェックマークが表示されていることを確認します。

検証手順

  • Raw Capacity カードを確認します。

    1. OpenShift Web コンソールで、StorageOpenShift Data Foundation をクリックします。
    2. Overview タブの Status カードで Storage System をクリックし、表示されたポップアップからストレージシステムリンクをクリックします。
    3. Block and File タブで、Raw Capacity カードを確認します。

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

      注記

      Raw 容量はレプリケーションを考慮せず、フル容量を表示します。

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

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

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

        注記

        Show default projects オプションが無効になっている場合は、切り替えボタンを使用して、すべてのデフォルトプロジェクトを一覧表示します。

    • PVC の状態を表示するには、以下を実行します。

      1. OpenShift Web コンソールから、StoragePersistent Volume Claims をクリックします。
      2. Project ドロップダウンリストから openshift-storage を選択します。

        注記

        Show default projects オプションが無効になっている場合は、切り替えボタンを使用して、すべてのデフォルトプロジェクトを一覧表示します。

  • オプション: クラスターでクラスター全体の暗号化が有効になっている場合は、新規 OSD デバイスが暗号化されていることを確認します。

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

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

      OSD Pod の名前です。

      以下は例になります。

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

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

        $ oc debug node/<node-name>
        <node-name>

        ノードの名前。

        $ chroot /host
      2. ocs-deviceset 名の横にある crypt キーワードを確認します。

        $ lsblk
重要

ノードまたは OSD を削除して削減するかどうかに関わらず、クラスターの削減は現時点でサポートされていません。

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

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

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

9.3.1. Google Cloud のインストーラーでプロビジョニングされるインフラストラクチャーへのノードの追加

前提条件

  • OpenShift Container Platform クラスターにログインしている必要があります。

手順

  1. ComputeMachine Sets に移動します。
  2. ノードを追加するマシンセットで、Edit Machine Count を選択します。

    1. ノード数を追加し、Save をクリックします。
    2. ComputeNodes をクリックし、新規ノードが Ready 状態にあることを確認します。
  3. OpenShift Data Foundation ラベルを新規ノードに適用します。

    1. 新規ノードについて、Action menu (⋮)Edit Labels をクリックします。
    2. cluster.ocs.openshift.io/openshift-storage を追加し、Save をクリックします。
注記

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

検証手順

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

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

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

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

第10章 Multicloud Object Gateway

10.1. Multicloud Object Gateway について

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

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

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

前提条件

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

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

    サブスクリプションマネージャーを使用してリポジトリーを有効にするための適切なアーキテクチャーを指定します。

    • IBM Power の場合は、次のコマンドを使用します。
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
    • IBM Z インフラストラクチャーの場合は、以下のコマンドを使用します。
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
  • または、MCG パッケージを、Download RedHat OpenShift Data Foundation ページにある OpenShift Data Foundation RPM からインストールできます。

    注記

    お使いのアーキテクチャーに応じて、正しい製品バリアントを選択します。

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

例10.1 例

仮想ホストのスタイルを使用した MCG バケットへのアクセス
クライアントアプリケーションが https://<bucket-name>.s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com にアクセスしようとする場合
<bucket-name>

MCG バケットの名前です。

たとえば、https://mcg-test-bucket.s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com になります。

DNS エントリーは、S3 サービスを参照するように、mcg-test-bucket.s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com が必要です。

重要

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

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

手順

describe コマンドを実行し、アクセスキー (AWS_ACCESS_KEY_ID 値) およびシークレットアクセスキー (AWS_SECRET_ACCESS_KEY 値) を含む Multicloud Object Gateway (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 時間あたりのコストがかかります。

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

前提条件

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

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

    サブスクリプションマネージャーを使用してリポジトリーを有効にするための適切なアーキテクチャーを指定します。

    • IBM Power の場合は、次のコマンドを使用します。
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
    • IBM Z インフラストラクチャーの場合は、以下のコマンドを使用します。
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms

手順

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
endpoint
2
アクセスキー
3
シークレットアクセスキー

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

例10.2 例

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

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

10.3. Multicloud Object Gateway コンソールへのユーザーアクセスの許可

ユーザーに Multicloud Object Gateway (MCG) コンソールへのアクセスを許可するには、ユーザーが以下の条件を満たしていることを確認してください。

  • ユーザーは cluster-admins グループに属する。
  • ユーザーは system:cluster-admins 仮想グループに属する。

前提条件

  • 実行中の OpenShift Data Foundation Platform。

手順

  1. MCG コンソールへのアクセスを有効にします。

    クラスターで以下の手順を実行します。

    1. cluster-admins グループを作成します。

      # oc adm groups new cluster-admins
    2. グループを cluster-admin ロールにバインドします。

      # oc adm policy add-cluster-role-to-group cluster-admin cluster-admins
  2. cluster-admins グループからユーザーを追加または削除して、MCG コンソールへのアクセスを制御します。

    • ユーザーのセットを cluster-admins グループに追加するには、以下を実行します。

      # oc adm groups add-users cluster-admins <user-name> <user-name> <user-name>...

      ここで、<user-name> は追加するユーザーの名前です。

      注記

      ユーザーのセットを cluster-admins グループに追加する場合、新たに追加されたユーザーを cluster-admin ロールにバインドし、OpenShift Data Foundation ダッシュボードへのアクセスを許可する必要はありません。

    • ユーザーのセットを cluster-admins グループから削除するには、以下を実行します。

      # oc adm groups remove-users cluster-admins <user-name> <user-name> <user-name>...

      ここで、<user-name> は削除するユーザーの名前です。

検証手順

  1. OpenShift Web コンソールで、Multicloud Object Gateway コンソールへのアクセスパーミッションを持つユーザーとしてログインします。
  2. StorageOpenShift Data Foundation に移動します。
  3. Storage Systems タブでストレージシステムを選択し、OverviewObject タブをクリックします。
  4. Multicloud Object Gateway のリンクをクリックします。
  5. Allow selected permissions をクリックします。

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

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

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

前提条件

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

手順

  1. OpenShift Web コンソールで、StorageOpenShift Data Foundation をクリックします。
  2. Backing Store タブをクリックします。
  3. Create Backing Store をクリックします。
  4. Create New Backing Store ページで、以下を実行します。

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

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

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

      注記

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

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

検証手順

  1. OpenShift Web コンソールで、StorageOpenShift Data Foundation をクリックします。
  2. Backing Store タブをクリックして、すべてのバッキングストアを表示します。

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

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

MCG で使用できるバッキングストレージを追加する必要があります。

デプロイメントのタイプに応じて、以下のいずれかの手順を選択してバッキングストレージを作成できます。

VMware デプロイメントの場合、「s3 と互換性のある Multicloud Object Gateway バッキングストアの作成」 に進み、詳細の手順を確認します。

10.4.2.1. AWS でサポートされるバッキングストアの作成

前提条件

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

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

    サブスクリプションマネージャーを使用してリポジトリーを有効にするための適切なアーキテクチャーを指定します。たとえば、IBM Z インフラストラクチャーの場合は、以下のコマンドを使用します。

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
  • または、MCG パッケージを、https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages にある OpenShift Data Foundation RPM からインストールできます。

    注記

    お使いのアーキテクチャーに応じて、正しい製品バリアントを選択します。

手順

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

    noobaa backingstore create aws-s3 <backingstore_name> --access-key=<AWS ACCESS KEY> --secret-key=<AWS SECRET ACCESS KEY> --target-bucket <bucket-name> -n openshift-storage
  1. <backingstore_name> を、バッキングストアの名前に置き換えます。
  2. <AWS ACCESS KEY> および <AWS SECRET ACCESS KEY> を、作成した AWS アクセスキー ID およびシークレットアクセスキーに置き換えます。
  3. <bucket-name> を既存の AWS バケット名に置き換えます。この引数は、MCG に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。

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

    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>
      namespace: openshift-storage
    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: openshift-storage
    spec:
      awsS3:
        secret:
          name: <backingstore-secret-name>
          namespace: openshift-storage
        targetBucket: <bucket-name>
      type: aws-s3
    1. <bucket-name> を既存の AWS バケット名に置き換えます。この引数は、MCG に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。
    2. <backingstore-secret-name> を、直前の手順で作成されたシークレットの名前に置き換えます。

10.4.2.2. IBM COS でサポートされるバッキングストアの作成

前提条件

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

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

    サブスクリプションマネージャーを使用してリポジトリーを有効にするための適切なアーキテクチャーを指定します。たとえば、以下のようになります。

    • IBM Power の場合は、次のコマンドを使用します。
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
    • IBM Z インフラストラクチャーの場合は、以下のコマンドを使用します。
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
  • または、MCG パッケージを、https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages にある OpenShift Data Foundation RPM からインストールできます。

    注記

    お使いのアーキテクチャーに応じて、正しい製品バリアントを選択します。

手順

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

    noobaa backingstore create ibm-cos <backingstore_name> --access-key=<IBM ACCESS KEY> --secret-key=<IBM SECRET ACCESS KEY> --endpoint=<IBM COS ENDPOINT> --target-bucket <bucket-name> -n openshift-storage
    1. <backingstore_name> を、バッキングストアの名前に置き換えます。
    2. <IBM ACCESS KEY>, <IBM SECRET ACCESS KEY>, <IBM COS ENDPOINT> を IBM アクセスキー ID、シークレットアクセスキー、および既存の IBM バケットの場所に対応する地域のエンドポイントに置き換えます。

      IBM クラウドで上記のキーを生成するには、ターゲットバケットのサービス認証情報を作成する際に HMAC 認証情報を含める必要があります。

    3. <bucket-name> を既存の IBM バケット名に置き換えます。この引数は、MCG に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。

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

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

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

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

    apiVersion: v1
    kind: Secret
    metadata:
      name: <backingstore-secret-name>
      namespace: openshift-storage
    type: Opaque
    data:
      IBM_COS_ACCESS_KEY_ID: <IBM COS ACCESS KEY ID ENCODED IN BASE64>
      IBM_COS_SECRET_ACCESS_KEY: <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>
    1. Base64 を使用して独自の IBM COSアクセスキー ID およびシークレットアクセスキーを指定し、エンコードし、その結果を <IBM COS ACCESS KEY ID ENCODED IN BASE64> および <IBM COS 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: openshift-storage
    spec:
      ibmCos:
        endpoint: <endpoint>
        secret:
          name: <backingstore-secret-name>
          namespace: openshift-storage
        targetBucket: <bucket-name>
      type: ibm-cos
    1. <bucket-name> を既存の IBM COS バケット名に置き換えます。この引数は、MCG に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。
    2. <endpoint> を、既存の IBM バケット名の場所に対応する地域のエンドポイントに置き換えます。この引数は、Multicloud Object Gateway に対して、バッキングストア、およびその後のデータストレージおよび管理に使用するエンドポイントについて指示します。
    3. <backingstore-secret-name> を、直前の手順で作成されたシークレットの名前に置き換えます。

10.4.2.3. Azure でサポートされるバッキングストアの作成

前提条件

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

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

    サブスクリプションマネージャーを使用してリポジトリーを有効にするための適切なアーキテクチャーを指定します。たとえば、IBM Z インフラストラクチャーの場合は、以下のコマンドを使用します。

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
  • または、MCG パッケージを、https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages にある OpenShift Data Foundation RPM からインストールできます。

    注記

    お使いのアーキテクチャーに応じて、正しい製品バリアントを選択します。

手順

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

    noobaa backingstore create azure-blob <backingstore_name> --account-key=<AZURE ACCOUNT KEY> --account-name=<AZURE ACCOUNT NAME> --target-blob-container <blob container name>
    1. <backingstore_name> を、バッキングストアの名前に置き換えます。
    2. <AZURE ACCOUNT KEY> および <AZURE ACCOUNT NAME> は、この目的のために作成した AZURE アカウントキーおよびアカウント名に置き換えます。
    3. <blob container name> を既存の Azure blob コンテナー名に置き換えます。この引数は、MCG に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。

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

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

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

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

    apiVersion: v1
    kind: Secret
    metadata:
      name: <backingstore-secret-name>
    type: Opaque
    data:
      AccountName: <AZURE ACCOUNT NAME ENCODED IN BASE64>
      AccountKey: <AZURE ACCOUNT KEY ENCODED IN BASE64>
    1. Base64 を使用して独自の Azure アカウント名およびアカウントキーを指定し、エンコードし、その結果を <AZURE ACCOUNT NAME ENCODED IN BASE64> および <AZURE ACCOUNT 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: openshift-storage
    spec:
      azureBlob:
        secret:
          name: <backingstore-secret-name>
          namespace: openshift-storage
        targetBlobContainer: <blob-container-name>
      type: azure-blob
    1. <blob-container-name> を既存の Azure blob コンテナー名に置き換えます。この引数は、MCG に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。
    2. <backingstore-secret-name> を、直前の手順で作成されたシークレットの名前に置き換えます。

10.4.2.4. GCP でサポートされるバッキングストアの作成

前提条件

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

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

    サブスクリプションマネージャーを使用してリポジトリーを有効にするための適切なアーキテクチャーを指定します。たとえば、IBM Z インフラストラクチャーの場合は、以下のコマンドを使用します。

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
  • または、MCG パッケージを、https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages にある OpenShift Data Foundation RPM からインストールできます。

    注記

    お使いのアーキテクチャーに応じて、正しい製品バリアントを選択します。

手順

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

    noobaa backingstore create google-cloud-storage <backingstore_name> --private-key-json-file=<PATH TO GCP PRIVATE KEY JSON FILE> --target-bucket <GCP bucket name>
    1. <backingstore_name> を、バッキングストアの名前に置き換えます。
    2. <PATH TO GCP PRIVATE KEY JSON FILE> を、この目的で作成された GCP プライベートキーへのパスに置き換えます。
    3. <GCP bucket name> を、既存の GCP オブジェクトストレージバケット名に置き換えます。この引数は、MCG に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。

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

      INFO[0001] ✅ Exists: NooBaa "noobaa"
      INFO[0002] ✅ Created: BackingStore "google-gcp"
      INFO[0002] ✅ Created: Secret "backing-store-google-cloud-storage-gcp"

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

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

    apiVersion: v1
    kind: Secret
    metadata:
      name: <backingstore-secret-name>
    type: Opaque
    data:
      GoogleServiceAccountPrivateKeyJson: <GCP PRIVATE KEY ENCODED IN BASE64>
    1. Base64 を使用して独自の GCP サービスアカウントプライベートキー ID を指定し、エンコードし、その結果を <GCP PRIVATE 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: openshift-storage
    spec:
      googleCloudStorage:
        secret:
          name: <backingstore-secret-name>
          namespace: openshift-storage
        targetBucket: <target bucket>
      type: google-cloud-storage
    1. <target bucket> を、既存の Google ストレージバケットに置き換えます。この引数は、MCG に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。
    2. <backingstore-secret-name> を、直前の手順で作成されたシークレットの名前に置き換えます。

10.4.2.5. ローカル永続ボリュームでサポートされるバッキングストアの作成

前提条件

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

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

    サブスクリプションマネージャーを使用してリポジトリーを有効にするための適切なアーキテクチャーを指定します。たとえば、IBM Z インフラストラクチャーの場合は、以下のコマンドを使用します。

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
  • または、MCG パッケージを、https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages にある OpenShift Data Foundation RPM からインストールできます。

    注記

    お使いのアーキテクチャーに応じて、正しい製品バリアントを選択します。

手順

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

    noobaa backingstore create  pv-pool <backingstore_name> --num-volumes=<NUMBER OF VOLUMES>  --pv-size-gb=<VOLUME SIZE> --storage-class=<LOCAL STORAGE CLASS>
    1. <backingstore_name> を、バッキングストアの名前に置き換えます。
    2. <NUMBER OF VOLUMES> を、作成するボリューム数に置き換えます。ボリュームの数を増やすと、ストレージが拡大することに注意してください。
    3. <VOLUME SIZE> を、各ボリュームに必要なサイズ (GB 単位) に置き換えます。
    4. <LOCAL STORAGE CLASS> をローカルストレージクラスに置き換えます。これは、ocs-storagecluster-ceph-rbd を使用する際に推奨されます。

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

      INFO[0001] ✅ Exists: NooBaa "noobaa"
      INFO[0002] ✅ Exists: BackingStore "local-mcg-storage"

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

  1. 特定のバッキングストアについて以下の YAML を適用します。

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: <backingstore_name>
      namespace: openshift-storage
    spec:
       pvPool:
        numVolumes: <NUMBER OF VOLUMES>
        resources:
          requests:
            storage: <VOLUME SIZE>
        storageClass: <LOCAL STORAGE CLASS>
      type: pv-pool
    1. <backingstore_name> を、バッキングストアの名前に置き換えます。
    2. <NUMBER OF VOLUMES> を、作成するボリューム数に置き換えます。ボリュームの数を増やすと、ストレージが拡大することに注意してください。
    3. <VOLUME SIZE> を、各ボリュームに必要なサイズ (GB 単位) に置き換えます。文字 G はそのままにする必要があることに注意してください。
    4. <LOCAL STORAGE CLASS> をローカルストレージクラスに置き換えます。これは、ocs-storagecluster-ceph-rbd を使用する際に推奨されます。

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

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

手順

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

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

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

手順

  1. OpenShift Web コンソールで、StorageOpenShift Data Foundation をクリックします。
  2. Storage Systems タブでストレージシステムを選択し、OverviewObject タブをクリックします。
  3. Multicloud Object Gateway のリンクをクリックします。
  1. 以下に強調表示されているように左側にある Resources タブを選択します。設定する一覧から、Add Cloud Resource を選択します。

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

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

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

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

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

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

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

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

手順

  1. OpenShift Web コンソールで、StorageOpenShift Data Foundation をクリックします。
  2. Bucket Class タブをクリックします。
  3. Create Bucket Class をクリックします。
  4. Create new Bucket Class ページで、以下を実行します。

    1. バケットクラスタイプを選択し、バケットクラス名を入力します。

      1. BucketClass タイプを選択します。以下のいずれかのオプションを選択します。

        • Standard: データは Multicloud Object Gateway (MCG) に使用され、重複排除、圧縮、および暗号化されます。
        • Namespace: データは、重複排除、圧縮、または暗号化を実行せずに NamespaceStores に保存されます。

          デフォルトでは、Standard が選択されます。

      2. Bucket Class Name 名を入力します。
      3. Next をクリックします。
    2. Placement PolicyTier 1 - Policy Type を選択し、Next をクリックします。要件に応じて、いずれかのオプションを選択できます。

      • 分散 により、選択したリソース全体にデータを分散できます。
      • mirror により、選択したリソース全体でデータが完全に複製されます。
      • Add Tier をクリックし、別のポリシー階層を追加します。
    3. Tier 1 - Policy TypeSpread を選択した場合は、利用可能な一覧から 1 つ以上の Backing Store リソースを選択してから、Next をクリックします。または、新しいバッキングストアを作成することもできます。

      注記

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

    4. Bucket Class 設定を確認し、確認します。
    5. Create Bucket Class をクリックします。

検証手順

  1. OpenShift Web コンソールで、StorageOpenShift Data Foundation をクリックします。
  2. Bucket Class タブをクリックし、新しい Bucket Class を検索します。

10.4.6. バケットクラスの編集

以下の手順に従って、Openshift Web コンソールの edit ボタンをクリックし、YAML ファイルを使用してバケットクラスコンポーネントを編集します。

前提条件

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

手順

  1. OpenShift Web コンソールで、StorageOpenShift Data Foundation をクリックします。
  2. Bucket Class タブをクリックします。
  3. 編集する Bucket クラスの横にあるアクションメニュー (⋮) をクリックします。
  4. Edit Bucket Class をクリックします。
  5. YAML ファイルにリダイレクトされ、このファイルで必要な変更を加え、Save をクリックします。

10.4.7. バケットクラスのバッキングストアの編集

以下の手順を使用して、既存の Multicloud Object Gateway (MCG) バケットクラスを編集し、バケットクラスで使用される基礎となるバッキングストアを変更します。

前提条件

  • OpenShift Web コンソールへの管理者アクセス。
  • バケットクラス。
  • バッキングストア。

手順

  1. OpenShift Web コンソールで、StorageOpenShift Data Foundation をクリックします。
  2. Bucket Class タブをクリックします。
  3. 編集する Bucket クラスの横にあるアクションメニュー (⋮) をクリックします。

    Edit bucket class resources
  4. Edit Bucket Class Resources をクリックします。
  5. Edit Bucket Class Resources ページで、バッキングストアをバケットクラスに追加するか、またはバケットクラスからバッキングストアを削除してバケットクラスリソースを編集します。1 つまたは 2 つの層で作成されたバケットクラスリソースや、異なる配置ポリシーで編集することもできます。

    • バッキングストアをバケットクラスに追加するには、バッキングストアの名前を選択します。
    • バケットクラスからバッキングストアを削除するには、バッキングストアの名前を消去します。

      Editing backing stores for the bucket class
  6. 保存 をクリックします。

10.5. namespace バケットの管理

namespace バケットを使用すると、異なるプロバイダーのデータリポジトリーを接続できるため、単一の統合ビューを使用してすべてのデータと対話できます。各プロバイダーに関連付けられたオブジェクトバケットを namespace バケットに追加し、namespace バケット経由でデータにアクセスし、一度にすべてのオブジェクトバケットを表示します。これにより、他の複数のストレージプロバイダーから読み取る間に、希望するストレージプロバイダーへの書き込みを行うことができ、新しいストレージプロバイダーへの移行コストが大幅に削減されます。

S3 API を使用して、namespace バケットのオブジェクトと対話できます。詳細は、「S3 API endpoints for objects in namespace buckets」について参照してください。

注記

namespace バケットは、書き込みターゲットが利用可能で機能している場合にのみ使用できます。

10.5.1. namespace バケットのオブジェクトの Amazon S3 API エンドポイント

Amazon Simple Storage Service (S3) API を使用して namespace バケットのオブジェクトと対話できます。

Red Hat OpenShift Data Foundation 4.6 以降では、以下の namespace バケット操作をサポートします。

これらの操作および使用方法に関する最新情報は、Amazon S3 API リファレンスのドキュメントを参照してください。

10.5.2. Multicloud Object Gateway CLI および YAML を使用した namespace バケットの追加

namespace バケットについての詳細は、namespace バケットの管理について参照してください。

デプロイメントのタイプに応じて、および YAML または Multicloud Object Gateway CLI を使用するかどうかに応じて、以下の手順のいずれかを選択して namespace バケットを追加します。

10.5.2.1. YAML を使用した AWS S3 namespace バケットの追加

前提条件

手順

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

    apiVersion: v1
    kind: Secret
    metadata:
      name: <namespacestore-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. <namespacestore-secret-name> を一意の名前に置き換えます。
  2. OpenShift カスタムリソース定義(CRD)を使用して NamespaceStore リソースを作成します。NamespaceStore は、MCG namespace バケットでデータの読み取りおよび書き込みターゲットとして使用される基礎となるストレージを表します。NamespaceStore リソースを作成するには、以下の YAML を適用します。

    apiVersion: noobaa.io/v1alpha1
    kind: NamespaceStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: <resource-name>
      namespace: openshift-storage
    spec:
      awsS3:
        secret:
          name: <namespacestore-secret-name>
          namespace: <namespace-secret>
        targetBucket: <target-bucket>
      type: aws-s3
    1. <resource-name> をリソースに指定する名前に置き換えます。
    2. <namespacestore-secret-name> を手順 1 で作成したシークレットに置き換えます。
    3. <namespace-secret> を、シークレットが含まれる namespace に置き換えます。
    4. <target-bucket> を NamespaceStore 用に作成したターゲットバケットに置き換えます。
  3. namespace バケットの namespace ポリシーを定義する namespace バケットクラスを作成します。Namespace ポリシーには、single または multi の タイプが必要です。

    • タイプ single の namespace ポリシーには、以下の設定が必要です。

      apiVersion: noobaa.io/v1alpha1
      kind: BucketClass
      metadata:
        labels:
          app: noobaa
        name: <my-bucket-class>
        namespace: openshift-storage
      spec:
        namespacePolicy:
          type:
          single:
            resource: <resource>
      • <my-bucket-class> を一意のバケットクラス名に置き換えます。
      • <resource> を namespace バケットの読み取りおよび書き込みターゲットを定義する単一の namespace-store の名前に置き換えます。
    • タイプが multi の namespace ポリシーには、以下の設定が必要です。

      apiVersion: noobaa.io/v1alpha1
      
      kind: BucketClass
      metadata:
        labels:
          app: noobaa
        name: <my-bucket-class>
        namespace: openshift-storage
      spec:
        namespacePolicy:
          type: Multi
          multi:
            writeResource: <write-resource>
            readResources:
            - <read-resources>
            - <read-resources>
      • <my-bucket-class> を一意のバケットクラス名に置き換えます。
      • <write-resource> を、namespace バケットの書き込みターゲットを定義する単一の namespace-store の名前に置き換えます。
      • <read-resources> を、namespace バケットの読み取りターゲットを定義する namespace-stores の名前の一覧に置き換えます。
  4. 以下の YAML を適用して、手順 2 に定義されたバケットクラスを使用する Object Bucket Class(OBC)リソースを使用してバケットを作成します。

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: <resource-name>
      namespace: openshift-storage
    spec:
      generateBucketName: <my-bucket>
      storageClassName: noobaa.noobaa.io
      additionalConfig:
        bucketclass: <my-bucket-class>
    注記

    IBM Power および IBM Z インフラストラクチャーの場合は、storageClassNameopenshift-storage.noobaa.io として使用します。

    1. <resource-name> をリソースに指定する名前に置き換えます。
    2. <my-bucket> をバケットに指定する名前に置き換えます。
    3. <my-bucket-class> を直前の手順で作成したバケットクラスに置き換えます。

OBC が Operator によってプロビジョニングされると、バケットが MCG で作成され、Operator は OBC の同じ namespace 上に同じ名前でシークレットおよび ConfigMap を作成します。

10.5.2.2. YAML を使用した IBM COS namespace バケットの追加

前提条件

手順

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

    apiVersion: v1
    kind: Secret
    metadata:
      name: <namespacestore-secret-name>
      type: Opaque
    data:
      IBM_COS_ACCESS_KEY_ID: <IBM COS ACCESS KEY ID ENCODED IN BASE64>
      IBM_COS_SECRET_ACCESS_KEY: <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>
    1. Base64 を使用して独自の IBM COSアクセスキー ID およびシークレットアクセスキーを指定し、エンコードし、その結果を <IBM COS ACCESS KEY ID ENCODED IN BASE64> および <IBM COS SECRET ACCESS KEY ENCODED IN BASE64> に使用する必要があります。
    2. <namespacestore-secret-name> を一意の名前に置き換えます。
  2. OpenShift カスタムリソース定義(CRD)を使用して NamespaceStore リソースを作成します。NamespaceStore は、MCG namespace バケットでデータの読み取りおよび書き込みターゲットとして使用される基礎となるストレージを表します。NamespaceStore リソースを作成するには、以下の YAML を適用します。

    apiVersion: noobaa.io/v1alpha1
    kind: NamespaceStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: bs
      namespace: openshift-storage
    spec:
      s3Compatible:
        endpoint: <IBM COS ENDPOINT>
        secret:
          name: <namespacestore-secret-name>
          namespace: <namespace-secret>
        signatureVersion: v2
        targetBucket: <target-bucket>
      type: ibm-cos
    1. <IBM COS ENDPOINT> を適切な IBM COS エンドポイントに置き換えます。
    2. <namespacestore-secret-name> を手順 1 で作成したシークレットに置き換えます。
    3. <namespace-secret> を、シークレットが含まれる namespace に置き換えます。
    4. <target-bucket> を NamespaceStore 用に作成したターゲットバケットに置き換えます。
  3. namespace バケットの namespace ポリシーを定義する namespace バケットクラスを作成します。Namespace ポリシーには、single または multi の タイプが必要です。

    • タイプ single の namespace ポリシーには、以下の設定が必要です。

      apiVersion: noobaa.io/v1alpha1
      kind: BucketClass
      metadata:
        labels:
          app: noobaa
        name: <my-bucket-class>
        namespace: openshift-storage
      spec:
        namespacePolicy:
          type:
          single:
            resource: <resource>
      • <my-bucket-class> を一意のバケットクラス名に置き換えます。
      • <resource> を namespace バケットの読み取りおよび書き込みターゲットを定義する単一の namespace-store の名前に置き換えます。
    • タイプが multi の namespace ポリシーには、以下の設定が必要です。

      apiVersion: noobaa.io/v1alpha1
      kind: BucketClass
      metadata:
        labels:
          app: noobaa
        name: <my-bucket-class>
        namespace: openshift-storage
      spec:
        namespacePolicy:
          type: Multi
          multi:
            writeResource: <write-resource>
            readResources:
            - <read-resources>
            - <read-resources>
      • <my-bucket-class> を一意のバケットクラス名に置き換えます。
      • <write-resource> を、namespace バケットの書き込みターゲットを定義する単一の namespace-store の名前に置き換えます。
      • <read-resources> を、namespace バケットの読み取りターゲットを定義する namespace-stores の名前の一覧に置き換えます。
  4. 以下の YAML を適用して、手順 2 に定義されたバケットクラスを使用する Object Bucket Class(OBC)リソースを使用してバケットを作成します。

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: <resource-name>
      namespace: openshift-storage
    spec:
      generateBucketName: <my-bucket>
      storageClassName: noobaa.noobaa.io
      additionalConfig:
        bucketclass: <my-bucket-class>
    注記

    IBM Power および IBM Z インフラストラクチャーの場合は、storageClassNameopenshift-storage.noobaa.io として使用します。

    1. <resource-name> をリソースに指定する名前に置き換えます。
    2. <my-bucket> をバケットに指定する名前に置き換えます。
    3. <my-bucket-class> を直前の手順で作成したバケットクラスに置き換えます。

OBC が Operator によってプロビジョニングされると、バケットが MCG で作成され、Operator は OBC の同じ namespace 上に同じ名前でシークレットおよび ConfigMap を作成します。

10.5.2.3. Multicloud Object Gateway CLI を使用した AWS S3 namespace バケットの追加

前提条件

  • 実行中の OpenShift Data Foundation Platform。
  • Multicloud Object Gateway (MCG) へのアクセスについては、第 2 章の Accessing the Multicloud Object Gateway with your applications を参照してください。
  • MCG コマンドラインインターフェースをダウンロードします。
# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms
# yum install mcg
注記

サブスクリプションマネージャーを使用してリポジトリーを有効にするための適切なアーキテクチャーを指定します。たとえば、IBM Z インフラストラクチャーの場合は、以下のコマンドを使用します。

# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms

または、MCG パッケージを、https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/package にある OpenShift Data Foundation RPM からインストールできます。

注記

お使いのアーキテクチャーに応じて、正しい製品バリアントを選択します。

手順

  1. NamespaceStore リソースを作成します。NamespaceStore は、MCG namespace バケットでデータの読み取りおよび書き込みターゲットとして使用される基礎となるストレージを表します。MCG コマンドラインインターフェースから、以下のコマンドを実行します。

    noobaa namespacestore create aws-s3 <namespacestore> --access-key <AWS ACCESS KEY> --secret-key <AWS SECRET ACCESS KEY> --target-bucket <bucket-name> -n openshift-storage
    1. <namespacestore> を NamespaceStore の名前に置き換えます。
    2. <AWS ACCESS KEY> および <AWS SECRET ACCESS KEY> を、作成した AWS アクセスキー ID およびシークレットアクセスキーに置き換えます。
    3. <bucket-name> を既存の AWS バケット名に置き換えます。この引数は、MCG に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。
  2. namespace バケットの namespace ポリシーを定義する namespace バケットクラスを作成します。Namespace ポリシーには、single または multi の タイプが必要です。

    • 以下のコマンドを実行して、タイプ single の namespace ポリシーで namespace バケットクラスを作成します。

      noobaa bucketclass create namespace-bucketclass single <my-bucket-class> --resource <resource> -n openshift-storage
      • <resource-name> をリソースに指定する名前に置き換えます。
      • <my-bucket-class> を一意のバケットクラス名に置き換えます。
      • <resource> を namespace バケットの読み取りおよび書き込みターゲットを定義する単一の namespace-store に置き換えます。
    • 以下のコマンドを実行して、タイプ multi の namespace ポリシーで namespace バケットクラスを作成します。

      noobaa bucketclass create namespace-bucketclass multi <my-bucket-class> --write-resource <write-resource> --read-resources <read-resources> -n openshift-storage
      • <resource-name> をリソースに指定する名前に置き換えます。
      • <my-bucket-class> を一意のバケットクラス名に置き換えます。
      • <write-resource> を、namespace バケットの書き込みターゲットを定義する単一の namespace-store に置き換えます。
      • <read-resources> を、namespace バケットの読み取りターゲットを定義する 、コンマで区切られた namespace-stores の一覧に置き換えます。
  3. 以下のコマンドを実行して、手順 2 に定義されたバケットクラスを使用する Object Bucket Class(OBC)リソースを使用してバケットを作成します。

    noobaa obc create my-bucket-claim -n openshift-storage --app-namespace my-app --bucketclass <custom-bucket-class>
    1. <bucket-name> を、選択するバケット名に置き換えます。
    2. <custom-bucket-class> を、手順 2 で作成したバケットクラスの名前に置き換えます。

OBC が Operator によってプロビジョニングされると、バケットが MCG で作成され、Operator は OBC の同じ namespace 上に同じ名前でシークレットおよび ConfigMap を作成します。

10.5.2.4. Multicloud Object Gateway CLI を使用した IBM COS namespace バケットの追加

前提条件

  • 実行中の OpenShift Data Foundation Platform。
  • Multicloud Object Gateway (MCG) へのアクセスについては、第 2 章の Accessing the Multicloud Object Gateway with your applications を参照してください。
  • MCG コマンドラインインターフェースをダウンロードします。

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

    サブスクリプションマネージャーを使用してリポジトリーを有効にするための適切なアーキテクチャーを指定します。

    • IBM Power の場合は、次のコマンドを使用します。
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
    • IBM Z インフラストラクチャーの場合は、以下のコマンドを使用します。
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms

    または、MCG パッケージを、https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/package にある OpenShift Data Foundation RPM からインストールできます。

    注記

    お使いのアーキテクチャーに応じて、正しい製品バリアントを選択します。

手順

  1. NamespaceStore リソースを作成します。NamespaceStore は、MCG namespace バケットでデータの読み取りおよび書き込みターゲットとして使用される基礎となるストレージを表します。MCG コマンドラインインターフェースから、以下のコマンドを実行します。

    noobaa namespacestore create ibm-cos <namespacestore> --endpoint <IBM COS ENDPOINT> --access-key <IBM ACCESS KEY> --secret-key <IBM SECRET ACCESS KEY> --target-bucket <bucket-name> -n openshift-storage
    1. <namespacestore> を NamespaceStore の名前に置き換えます。
    2. <IBM ACCESS KEY>, <IBM SECRET ACCESS KEY>, <IBM COS ENDPOINT> を IBM アクセスキー ID、シークレットアクセスキー、および既存の IBM バケットの場所に対応する地域のエンドポイントに置き換えます。
    3. <bucket-name> を既存の IBM バケット名に置き換えます。この引数は、MCG に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。
  2. namespace バケットの namespace ポリシーを定義する namespace バケットクラスを作成します。Namespace ポリシーには、single または multi の タイプが必要です。

    • 以下のコマンドを実行して、タイプ single の namespace ポリシーで namespace バケットクラスを作成します。

      noobaa bucketclass create namespace-bucketclass single <my-bucket-class> --resource <resource> -n openshift-storage
      • <resource-name> をリソースに指定する名前に置き換えます。
      • <my-bucket-class> を一意のバケットクラス名に置き換えます。
      • <resource> を namespace バケットの読み取りおよび書き込みターゲットを定義する単一の namespace-store に置き換えます。
    • 以下のコマンドを実行して、タイプ multi の namespace ポリシーで namespace バケットクラスを作成します。

      noobaa bucketclass create namespace-bucketclass multi <my-bucket-class> --write-resource <write-resource> --read-resources <read-resources> -n openshift-storage
      • <resource-name> をリソースに指定する名前に置き換えます。
      • <my-bucket-class> を一意のバケットクラス名に置き換えます。
      • <write-resource> を、namespace バケットの書き込みターゲットを定義する単一の namespace-store に置き換えます。
      • <read-resources> を、namespace バケットの読み取りターゲットを定義する 、コンマで区切られた namespace-stores の一覧に置き換えます。
  3. 以下のコマンドを実行して、手順 2 に定義されたバケットクラスを使用する Object Bucket Class(OBC)リソースを使用してバケットを作成します。

    noobaa obc create my-bucket-claim -n openshift-storage --app-namespace my-app --bucketclass <custom-bucket-class>
    1. <bucket-name> を、選択するバケット名に置き換えます。
    2. <custom-bucket-class> を、手順 2 で作成したバケットクラスの名前に置き換えます。

OBC が Operator によってプロビジョニングされると、バケットが MCG で作成され、Operator は OBC の同じ namespace 上に同じ名前でシークレットおよび ConfigMap を作成します。

10.5.3. OpenShift Container Platform ユーザーインターフェースを使用した namespace バケットの追加

OpenShift Data Foundation 4.8 のリリースでは、namespace バケットは OpenShift Container Platform ユーザーインターフェースを使用して追加できます。namespace バケットについての詳細は、「Managing namespace bukets」を参照してください。

前提条件

  • OpenShift Data Foundation Operator を使用した OpenShift Container Platform のインストール
  • Multicloud Object Gateway (MCG) へのアクセス。

手順

  1. OpenShift Web コンソールにログインします。
  2. Storage → OpenShift Data Foundation をクリックします。
  3. Namespace Store タブをクリックして、namespace バケットで使用される namespacestore リソースを作成します。

    1. Create namespace store をクリックします。
    2. namespacestore 名を入力します。
    3. プロバイダーを選択します。
    4. リージョンを選択します。
    5. 既存のシークレットを選択するか、Switch to credentials をクリックして秘密鍵とシークレットアクセスキーを入力してシークレットを作成します。
    6. ターゲットバケットを選択します。
    7. Create をクリックします。
    8. namespacestore が Ready 状態にあることを確認します。
    9. 必要なリソースが得られるまで、これらの手順を繰り返します。
  4. Bucket Class タブ → Create a new Bucket Class をクリックします。

    1. Namespace ラジオボタンを選択します。
    2. Bucket Class 名を入力します。
    3. 説明 (オプション) を追加します。
    4. Next をクリックします。
  5. namespace バケットの namespace ポリシータイプを選択し、Next をクリックします。
  6. ターゲットリソースを選択します。

    • Namespace ポリシータイプが Single の場合、読み取りリソースを選択する必要があります。
    • Namespace ポリシータイプが Multi の場合、読み取りリソースおよび書き込みリソースを選択する必要があります。
    • namespace ポリシータイプが Cache の場合は、namespace バケットの読み取りおよび書き込みターゲットを定義する Hub namespace ストアを選択する必要があります。
  7. Next をクリックします。
  8. 新しいバケットクラスを確認してから Create Bucketclass をクリックします。
  9. BucketClass ページで、新たに作成されたリソースが Created フェーズにあることを確認します。
  10. OpenShift Web コンソールで、StorageOpenShift Data Foundation をクリックします。
  11. Status カードで Storage System をクリックし、表示されるポップアップからストレージシステムリンクをクリックします。
  12. Object タブで、Multicloud Object GatewayBucketsNamespace Buckets タブをクリックします。
  13. Create Namespace Bucket をクリックします。

    1. Choose Name タブで、namespace バケットの Name を指定し、Next をクリックします。
    2. Set Placement タブで、以下を実行します。

      1. Read Policy で、namespace バケットがデータの読み取りに使用する、ステップ 5 で作成した各 namespace リソースのチェックボックスを選択します。
      2. 使用している namespace ポリシータイプが Multi の場合、Write Policy の場合は、namespace バケットがデータを書き込む namespace リソースを指定します。
      3. Next をクリックします。
    3. Create をクリックします。

検証

  • namespace バケットが State 列の緑色のチェックマークと共に、予想される読み取りリソースの数、および予想される書き込みリソース名と共に一覧表示されていることを確認します。

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

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

前提条件

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

手順

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

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

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

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

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

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

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

    apiVersion: noobaa.io/v1alpha1
    kind: BucketClass
    metadata:
      labels:
        app: noobaa
      name: <bucket-class-name>
      namespace: openshift-storage
    spec:
      placementPolicy:
        tiers:
        - backingStores:
          - <backing-store-1>
          - <backing-store-2>
          placement: Mirror
  2. 以下の行を標準の Object Bucket Claim(オブジェクトバケット要求、OBC)に追加します。

    additionalConfig:
      bucketclass: mirror-to-aws

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

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

  1. OpenShift Web コンソールで、StorageOpenShift Data Foundation をクリックします。
  2. Status カードで Storage System をクリックし、表示されるポップアップからストレージシステムリンクをクリックします。
  3. Object タブで、Multicloud Object Gateway リンクをクリックします。
  4. NooBaa ページの左側にある buckets アイコンをクリックします。バケットの一覧が表示されます。

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

    MCG edit tier 1 resources
  7. Mirror を選択し、このバケットに使用する関連リソースを確認します。次の例では、RGW にあるnoobaa-default-backing-storeと AWS にあるAWS-backingstore の間のデータがミラーリングされます。

    MCG mirror relevant resources
  8. 保存 をクリックします。
注記

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

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

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

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

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

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

前提条件

手順

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

  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 バケットポリシーの例 」を参照してください。

    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
    1. ENDPOINT を S3 エンドポイントに置き換えます。
    2. MyBucket を、ポリシーを設定するバケットに置き換えます。
    3. BucketPolicy をバケットポリシー JSON ファイルに置き換えます。
    4. デフォルトの自己署名証明書を使用している場合は、--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 」を参照してください。

      注記

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

      注記

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

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

前提条件

手順

  1. OpenShift Web コンソールで、StorageOpenShift Data Foundation をクリックします。
  2. Status カードで Storage System をクリックし、表示されるポップアップからストレージシステムリンクをクリックします。
  3. Object タブで、Multicloud Object Gateway リンクをクリックします。
  4. Accounts タブで、Create Account をクリックします。

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

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

    MCG create account s3 user2

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

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

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

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

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

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

手順

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

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

    これらの行は OBC 自体になります。

    1. <obc-name> を、一意の OBC の名前に置き換えます。
    2. <obc-bucket-name> を、OBC の一意のバケット名に置き換えます。
  2. YAML ファイルにさらに行を追加して、OBC の使用を自動化できます。以下の例は、バケット要求の結果のマッピングです。これは、データを含む設定マップおよび認証情報のあるシークレットです。この特定のジョブは 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> のすべてのインスタンスを、OBC の名前に置き換えます。
    2. <your application image> をアプリケーションイメージに置き換えます。
  3. 更新された YAML ファイルを適用します。

    # oc apply -f <yaml.file>

    <yaml.file> を YAML ファイルの名前に置き換えます。

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

    # oc get cm <obc-name> -o yaml

    obc-name を OBC の名前に置き換えます。

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

    • 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: 認証情報の一部であるシークレットのアクセスキー
重要

AWS_ACCESS_KEY_ID および AWS_SECRET_ACCESS_KEY を取得します。名前は AWS S3 API との互換性を確保するために使用されます。S3 操作の実行中にキーを指定する必要があります(特に Multicloud Object Gateway(MCG)バケットから読み取り、書き込み、または一覧する場合)。キーは Base64 でエンコードされます。鍵を使用する前にデコードします。

# oc get secret <obc_name> -o yaml
<obc_name>
Object Bucket Claim(オブジェクトバケット要求)の名前を指定します。

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

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

前提条件

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

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

    サブスクリプションマネージャーを使用してリポジトリーを有効にするための適切なアーキテクチャーを指定します。

    • IBM Power の場合は、次のコマンドを使用します。
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
    • IBM Z インフラストラクチャーの場合は、以下のコマンドを使用します。
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms

手順

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

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

    <obc-name> を一意の OBC 名に置き換えます(例: myappobc)。

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

    出力例:

    INFO[0001] ✅ Created: ObjectBucketClaim "test21obc"

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

  2. 以下のコマンドを実行してOBCを表示します。

    # oc get obc -n openshift-storage

    出力例:

    NAME        STORAGE-CLASS                 PHASE   AGE
    test21obc   openshift-storage.noobaa.io   Bound   38s
  3. 以下のコマンドを実行して、新規 OBC の 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 内で、設定マップおよびシークレットを見つけ、この OBC を使用することができます。CM とシークレットの名前はこの OBC の名前と同じです。以下のコマンドを実行してシークレットを表示します。

    # 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 エンドポイント情報が含まれます。

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

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

前提条件

手順

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

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

      内部モード
      Create Object Bucket Claim wizard

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

      • ocs-storagecluster-ceph-rgw は Ceph Object Gateway (RGW) を使用します。
      • openshift-storage.noobaa.io は Multicloud Object Gateway (MCG) を使用します。
      外部モード
      Create Object Bucket Claim wizard

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

      • ocs-external-storagecluster-ceph-rgw は RGW を使用します。
      • openshift-storage.noobaa.io は MCG を使用します。

        注記

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

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

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

      Object Bucket Claim Details page

10.8.4. Object Bucket Claim(オブジェクトバケット要求)のデプロイメントへの割り当て

作成されると、Object Bucket Claim(オブジェクトバケット要求、OBC)を特定のデプロイメントに割り当てることができます。

前提条件

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

手順

  1. 左側のナビゲーションバーで StorageObject Bucket Claims をクリックします。
  2. 作成した OBC の横にあるアクションメニュー (⋮) をクリックします。

    1. ドロップダウンメニューで、Attach to Deployment を選択します。

      Attach Object Bucket Claim to deployment
    2. Deployment Name 一覧から必要なデプロイメントを選択し、Attach をクリックします。

      Deployment Name list

10.8.5. OpenShift Web コンソールを使用したオブジェクトバケットの表示

OpenShift Web コンソールを使用して、Object Bucket Claim(オブジェクトバケット要求、OBC)用に作成されたオブジェクトバケットの詳細を表示できます。

前提条件

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

手順

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

    Object Buckets page

    また、特定の OBC の詳細ページに移動し、Resource リンクをクリックして、その OBC のオブジェクトバケットを表示します。

  3. 詳細を表示するオブジェクトバケットを選択します。Object Bucket Details ページに移動します。

10.8.6. Object Bucket Claim(オブジェクトバケット要求)の削除

前提条件

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

手順

  1. 左側のナビゲーションバーで StorageObject Bucket Claims をクリックします。
  2. 削除する Object Bucket Claim(オブジェクトバケット要求)の横にあるアクションメニュー (⋮) をクリックします。

    MCG OBC action menu attach to deployment
    1. Delete Object Bucket Claim を選択します。
    2. 削除 をクリックします。

10.9. オブジェクトバケットのキャッシュポリシー

キャッシュバケットは、ハブのターゲットとキャッシュターゲットが指定された namespace バケットです。ハブのターゲットは、S3 と互換性のある大規模なオブジェクトストレージバケットです。キャッシュバケットは、ローカルの Multicloud Object Gateway バケットです。AWS バケットまたは IBM COS バケットをキャッシュするキャッシュバケットを作成できます。

重要

キャッシュバケットはテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

詳細は、「テクノロジープレビュー機能のサポート範囲」を参照してください。

10.9.1. AWS キャッシュバケットの作成

前提条件

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

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

    サブスクリプションマネージャーを使用してリポジトリーを有効にするための適切なアーキテクチャーを指定します。IBM Z インフラストラクチャーの場合は、以下のコマンドを使用します。

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms

    または、MCG パッケージを、https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/package にある OpenShift Data Foundation RPM からインストールできます。

    注記

    お使いのアーキテクチャーに応じて、正しい製品バリアントを選択します。

手順

  1. NamespaceStore リソースを作成します。NamespaceStore は、MCG namespace バケットでデータの読み取りおよび書き込みターゲットとして使用される基礎となるストレージを表します。MCG コマンドラインインターフェースから、以下のコマンドを実行します。

    noobaa namespacestore create aws-s3 <namespacestore> --access-key <AWS ACCESS KEY> --secret-key <AWS SECRET ACCESS KEY> --target-bucket <bucket-name>
    1. <namespacestore> を NamespaceStore の名前に置き換えます。
    2. <AWS ACCESS KEY> および <AWS SECRET ACCESS KEY> を、作成した AWS アクセスキー ID およびシークレットアクセスキーに置き換えます。
    3. <bucket-name> を既存の AWS バケット名に置き換えます。この引数は、MCG に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。

      YAML を適用してストレージリソースを追加することもできます。まず、認証情報を使用してシークレットを作成します。

      apiVersion: v1
      kind: Secret
      metadata:
        name: <namespacestore-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>

      Base64 を使用して独自の AWS アクセスキー ID およびシークレットアクセスキーを指定し、エンコードし、その結果を <AWS ACCESS KEY ID ENCODED IN BASE64> および < AWS SECRET ACCESS KEY ENCODED IN BASE64> に使用する必要があります。

      <namespacestore-secret-name> を一意の名前に置き換えます。

      次に、以下の YAML を適用します。

      apiVersion: noobaa.io/v1alpha1
      kind: NamespaceStore
      metadata:
        finalizers:
        - noobaa.io/finalizer
        labels:
          app: noobaa
        name: <namespacestore>
        namespace: openshift-storage
      spec:
        awsS3:
          secret:
            name: <namespacestore-secret-name>
            namespace: <namespace-secret>
          targetBucket: <target-bucket>
        type: aws-s3
    4. <namespacestore> を一意の名前に置き換えます。
    5. <namespacestore-secret-name> を、直前の手順で作成されたシークレットに置き換えます。
    6. <namespace-secret> を、直前の手順でシークレットを作成するために使用された namespace に置き換えます。
    7. <target-bucket> を namespacestore 用に作成した AWS S3 バケットに置き換えます。
  2. 以下のコマンドを実行してバケットクラスを作成します。

    noobaa bucketclass create namespace-bucketclass cache <my-cache-bucket-class> --backingstores <backing-store> --hub-resource <namespacestore>
    1. <my-cache-bucket-class> を一意のバケットクラス名に置き換えます。
    2. <backing-store> を関連するバッキングストアに置き換えます。コンマで区切られた 1 つ以上のバッキングストアを一覧表示できます。
    3. <namespacestore> を、直前の手順で作成された namespacestore に置き換えます。
  3. 以下のコマンドを実行して、手順 2 に定義されたバケットクラスを使用する Object Bucket Claim (OBC) リソースを使用してバケットを作成します。

    noobaa obc create <my-bucket-claim> my-app --bucketclass <custom-bucket-class>
    1. <my-bucket-claim> を一意の名前に置き換えます。
    2. <custom-bucket-class> を、手順 2 で作成したバケットクラスの名前に置き換えます。

10.9.2. IBM COS キャッシュバケットの作成

前提条件

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

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

    サブスクリプションマネージャーを使用してリポジトリーを有効にするための適切なアーキテクチャーを指定します。

    • IBM Power の場合は、次のコマンドを使用します。
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
    • IBM Z インフラストラクチャーの場合は、以下のコマンドを使用します。
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms

    または、MCG パッケージを、https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/package にある OpenShift Data Foundation RPM からインストールできます。

    注記

    お使いのアーキテクチャーに応じて、正しい製品バリアントを選択します。

手順

  1. NamespaceStore リソースを作成します。NamespaceStore は、MCG namespace バケットでデータの読み取りおよび書き込みターゲットとして使用される基礎となるストレージを表します。MCG コマンドラインインターフェースから、以下のコマンドを実行します。

    noobaa namespacestore create ibm-cos <namespacestore> --endpoint <IBM COS ENDPOINT> --access-key <IBM ACCESS KEY> --secret-key <IBM SECRET ACCESS KEY> --target-bucket <bucket-name>
    1. <namespacestore> を NamespaceStore の名前に置き換えます。
    2. <IBM ACCESS KEY>, <IBM SECRET ACCESS KEY>, <IBM COS ENDPOINT> を IBM アクセスキー ID、シークレットアクセスキー、および既存の IBM バケットの場所に対応する地域のエンドポイントに置き換えます。
    3. <bucket-name> を既存の IBM バケット名に置き換えます。この引数は、MCG に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。

      YAML を適用してストレージリソースを追加することもできます。まず、認証情報を使用してシークレットを作成します。

      apiVersion: v1
      kind: Secret
      metadata:
        name: <namespacestore-secret-name>
      type: Opaque
      data:
        IBM_COS_ACCESS_KEY_ID: <IBM COS ACCESS KEY ID ENCODED IN BASE64>
        IBM_COS_SECRET_ACCESS_KEY: <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>

      Base64 を使用して独自の IBM COSアクセスキー ID およびシークレットアクセスキーを指定し、エンコードし、その結果を <IBM COS ACCESS KEY ID ENCODED IN BASE64> および <IBM COS SECRET ACCESS KEY ENCODED IN BASE64> に使用する必要があります。

      <namespacestore-secret-name> を一意の名前に置き換えます。

      次に、以下の YAML を適用します。

      apiVersion: noobaa.io/v1alpha1
      kind: NamespaceStore
      metadata:
        finalizers:
        - noobaa.io/finalizer
        labels:
          app: noobaa
        name: <namespacestore>
        namespace: openshift-storage
      spec:
        s3Compatible:
          endpoint: <IBM COS ENDPOINT>
          secret:
            name: <backingstore-secret-name>
            namespace: <namespace-secret>
          signatureVersion: v2
          targetBucket: <target-bucket>
        type: ibm-cos
    4. <namespacestore> を一意の名前に置き換えます。
    5. <IBM COS ENDPOINT> を適切な IBM COS エンドポイントに置き換えます。
    6. <backingstore-secret-name> を、直前の手順で作成されたシークレットに置き換えます。
    7. <namespace-secret> を、直前の手順でシークレットを作成するために使用された namespace に置き換えます。
    8. <target-bucket> を namespacestore 用に作成した AWS S3 バケットに置き換えます。
  2. 以下のコマンドを実行してバケットクラスを作成します。

    noobaa bucketclass create namespace-bucketclass cache <my-bucket-class> --backingstores <backing-store> --hubResource <namespacestore>
    1. <my-bucket-class> を一意のバケットクラス名に置き換えます。
    2. <backing-store> を関連するバッキングストアに置き換えます。コンマで区切られた 1 つ以上のバッキングストアを一覧表示できます。
    3. <namespacestore> を、直前の手順で作成された namespacestore に置き換えます。
  3. 以下のコマンドを実行して、手順 2 に定義されたバケットクラスを使用する Object Bucket Claim(オブジェクトバケット要求)リソースを使用してバケットを作成します。

    noobaa obc create <my-bucket-claim> my-app --bucketclass <custom-bucket-class>
    1. <my-bucket-claim> を一意の名前に置き換えます。
    2. <custom-bucket-class> を、手順 2 で作成したバケットクラスの名前に置き換えます。

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

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

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

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

10.10.1. ストレージノードを使用した Multicloud Object Gateway のスケーリング

前提条件

  • Multicloud Object Gateway (MCG) にアクセスできる OpenShift Container Platform で実行中の OpenShift Data Foundation クラスター。

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

手順

  1. OpenShift Web Console にログインします。
  2. MCG ユーザーインターフェースから OverviewAdd Storage Resources をクリックします。
  3. ウィンドウから Deploy Kubernetes Pool をクリックします。
  4. Create Pool ステップで、今後インストールされるノードのターゲットプールを作成します。
  5. Configure 手順で、要求される Pod の数と各 PV のサイズを設定します。新規 Pod ごとに、1 つの PV が作成されます。
  6. Review 手順で、新規プールの詳細を見つけ、ローカルまたは外部デプロイメントで使用するデプロイメント方法を選択します。ローカルデプロイメントが選択されている場合、Kubernetes ノードはクラスター内にデプロイされます。外部デプロイメントが選択されている場合、外部で実行する YAML ファイルが提供されます。
  7. すべてのノードは最初の手順で選択したプールに割り当てられ、ResourcesStorage resourcesResource name の下で確認できます。

10.11. MultiCloud Object Gateway エンドポイントの自動スケーリング

MultiCloud Object Gateway (MCG) の S3 サービスの負荷が増減すると、MCG エンドポイントの数が自動的にスケーリングされます。OpenShift Data Foundation クラスターは、アクティブな MCG エンドポイントを 1 つ使用してデプロイされます。デフォルトでは、MCG エンドポイント Pod はそれぞれ、CPU 1 つ、メモリー要求 2 Gi、要求に一致する制限で設定されます。エンドポイントの CPU 負荷が一貫した期間、使用率 80% のしきい値を超えると、2 番目のエンドポイントがデプロイされ、最初のエンドポイントの負荷を軽減します。両方のエンドポイントの平均 CPU 負荷が、一貫した期間 80% のしきい値を下回ると、エンドポイントの 1 つが削除されます。この機能により、MCG のパフォーマンスおよび保守性が向上します。

第11章 Persistent Volume Claim(永続ボリューム要求、PVC)の管理

重要

PVC の拡張は OpenShift Data Foundation がサポートする PVC ではサポートされません。

11.1. OpenShift Data Foundation を使用するためのアプリケーション Pod の設定

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

前提条件

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

手順

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

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

      1. OpenShift Data Foundation によって提供される Storage Class を指定します。
      2. PVC Name (例: myclaim )を指定します。
      3. 必要な Access Mode を選択します

        注記

        IBM FlashSystem では Access ModeShared access (RWX) はサポートされません。

      4. Rados Block Device (RBD) の場合、Access mode が ReadWriteOnce (RWO) であれば、必須の Volume mode を選択します。デフォルトのボリュームモードは、Filesystem です。
      5. Rados Block Device (RBD) の場合、Access mode が ReadWriteOnce (RWO) であれば、必須の Volume mode を選択します。デフォルトのボリュームモードは、Filesystem です。
      6. アプリケーション要件に応じて Size を指定します。
      7. Create をクリックし、PVC のステータスが Bound になるまで待機します。
  2. 新規または既存のアプリケーション Pod を新規 PVC を使用するように設定します。

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

      1. Workloads → Pods をクリックします。
      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 メニュー(⋮)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 Volume Claim(永続ボリューム要求、PVC)に一致する Type があることを確認します(例: myclaim )。

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

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

前提条件

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

手順

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

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

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

前提条件

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

手順

  1. OpenShift Web コンソールで、Storage → OpenShift Data Foundation をクリックします。
  2. Storage systems タブでストレージシステムを選択し、OverviewBlock and File タブをクリックします。
  3. Inventory カードを見つけ、エラーのある PVC の数を確認します。
  4. StoragePersistent Volume Claimsをクリックします。
  5. Filter テキストボックスを使用して、必要な PVC を検索します。
  6. PVC 名をクリックし、Eventsに移動します。
  7. 必要に応じて、または指示に応じてイベントに対応します。

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

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

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

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

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

11.4.2. OpenShift Data Foundation での動的プロビジョニング

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

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

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

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

OpenShift Data Foundation 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 ファイルのエントリーに基づいて行われます。

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

 

Red Hat Virtualization

csi.ovirt.org

 
重要

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

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

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

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

注記

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

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

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

前提条件

  • 一貫性のあるスナップショットを使用するには、PVC は Bound 状態にあり、使用されていない必要があります。スナップショットを作成する前に、必ずすべての IO を停止してください。
注記

Pod が使用している場合、OpenShift Data Foundation は 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 状態になるまで待機します。

12.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 メニュー(⋮)をクリックします。
  4. Restore as new PVC をクリックします。
  5. 新規 PVC の名前を入力します。
  6. Storage Class 名を選択します。

    注記

    Rados Block Device(RBD)の場合、親 PVC と同じプールを持つストレージクラスを選択する必要があります。暗号化が有効でないストレージクラスを使用して暗号化された PVC のスナップショットを復元することや、その逆はサポートされていません。

  7. 任意の Access Mode を選択します

    重要

    ReadOnlyMany(ROX)アクセスモードは Developer プレビュー機能であり、Developer プレビューのサポート制限の対象となります。Developer プレビューリリースは、実稼働環境で実行することは意図されておらず、Red Hat カスタマーポータルのケース管理システムではサポートされません。ReadOnlyMany 機能に関してサポートが必要な場合には 、ocs-devpreview@redhat.com メーリングリストに連絡してください。Red Hat Development Team のメンバーが稼働状況とスケジュールに応じて可能な限り迅速に対応します。ROX アクセスモードの使用については、「Creating a clone or restoring a snapshot with the new readonly access mode」について参照してください。

  8. オプション: RBD の場合は、ボリューム モード を選択します。
  9. Restore をクリックします。新規 PVC の詳細ページにリダイレクトされます。
Volume Snapshots ページの使用
  1. OpenShift Web コンソールで StorageVolume Snapshots をクリックします。
  2. Volume Snapshots タブで、復元するボリュームスナップショットの横にある Action メニュー(⋮)をクリックします。
  3. Restore as new PVC をクリックします。
  4. 新規 PVC の名前を入力します。
  5. Storage Class 名を選択します。

    注記

    Rados Block Device(RBD)の場合、親 PVC と同じプールを持つストレージクラスを選択する必要があります。暗号化が有効でないストレージクラスを使用して暗号化された PVC のスナップショットを復元することや、その逆はサポートされていません。

  6. 任意の Access Mode を選択します

    重要

    ReadOnlyMany(ROX)アクセスモードは Developer プレビュー機能であり、Developer プレビューのサポート制限の対象となります。Developer プレビューリリースは、実稼働環境で実行することは意図されておらず、Red Hat カスタマーポータルのケース管理システムではサポートされません。ReadOnlyMany 機能に関してサポートが必要な場合には 、ocs-devpreview@redhat.com メーリングリストに連絡してください。Red Hat Development Team のメンバーが稼働状況とスケジュールに応じて可能な限り迅速に対応します。ROX アクセスモードの使用については、「Creating a clone or restoring a snapshot with the new readonly access mode」について参照してください。

  7. オプション: RBD の場合は、ボリューム モード を選択します。
  8. Restore をクリックします。新規 PVC の詳細ページにリダイレクトされます。

検証手順

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

12.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 をクリックし、削除されたボリュームスナップショットが一覧表示されていないことを確認します。

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

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

13.1. クローンの作成

前提条件

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

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

手順

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

    • 必要な PVC の横にある Action メニュー (⋮)Clone PVC をクリックします。
    • クローンを作成する PVC をクリックし、ActionsClone PVC をクリックします。
  3. クローンの Name を入力します。
  4. 任意のアクセスモードを選択します。

    重要

    ReadOnlyMany(ROX)アクセスモードは Developer プレビュー機能であり、Developer プレビューのサポート制限の対象となります。Developer プレビューリリースは、実稼働環境で実行することは意図されておらず、Red Hat カスタマーポータルのケース管理システムではサポートされません。ReadOnlyMany 機能に関してサポートが必要な場合には 、ocs-devpreview@redhat.com メーリングリストに連絡してください。Red Hat Development Team のメンバーが稼働状況とスケジュールに応じて可能な限り迅速に対応します。ROX アクセスモードの使用については、「Creating a clone or restoring a snapshot with the new readonly access mode」について参照してください。

  5. Clone をクリックします。新規 PVC の詳細ページにリダイレクトされます。
  6. クローン作成された PVC のステータスが Bound になるまで待機します。

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

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

以下のいずれかの手順を選択して、ストレージノードを置き換えることができます。

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

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

手順

  1. OpenShift Web コンソールにログインし、ComputeNodes をクリックします。
  2. 置き換える必要のあるノードを特定します。その マシン名をメモします
  3. 以下のコマンドを実行して、ノードにスケジュール対象外(unschedulable)のマークを付けます。

    $ oc adm cordon <node_name>
  4. 以下のコマンドを使用してノードをドレイン(解放)します。

    $ oc adm drain <node_name> --force --delete-local-data --ignore-daemonsets
    重要

    このアクティビティーには少なくとも 5-10 分以上かかる場合があります。この期間に生成される Ceph のエラーは一時的なもので、新規ノードにラベルが付けられ、機能していれば自動的に解決されます。

  5. ComputeMachines をクリックします。必要なマシンを検索します。
  6. 必要なマシンの横にある Action メニュー(⋮)Delete Machine をクリックします。
  7. Delete をクリックしてマシンの削除を確認します。新しいマシンが自動的に作成されます。
  8. 新規マシンが起動し、Running 状態に移行するまで待機します

    重要

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

  9. ComputeNodes をクリックし、新規ノードが Ready 状態にあることを確認します。
  10. 以下のいずれかを使用して、OpenShift Data Foundation ラベルを新規ノードに適用します。

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

      $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""

検証手順

  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 Data Foundation Pod が 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.2. Google Cloud のインストーラーでプロビジョニングされるインフラストラクチャーでの失敗したノードの置き換え

以下の手順に従って、OpenShift Data Foundation の Google Cloud のインストーラーでプロビジョニングされるインフラストラクチャー (IPI) で動作しない障害のあるノードを置き換えます。

手順

  1. OpenShift Web コンソールにログインし、ComputeNodes をクリックします。
  2. 障害のあるノードを特定し、その Machine Name をクリックします。
  3. ActionsEdit Annotations をクリックし、Add More をクリックします。
  4. machine.openshift.io/exclude-node-draining を追加しSave をクリックします。
  5. ActionsDelete Machine の順にクリックし、Delete をクリックします。
  6. 新しいマシンが自動的に作成されます。新規マシンが起動するのを待機します。

    重要

    このアクティビティーには少なくとも 5-10 分以上かかる場合があります。この期間に生成される Ceph のエラーは一時的なもので、新規ノードにラベルが付けられ、機能していれば自動的に解決されます。

  7. ComputeNodes をクリックし、新規ノードが Ready 状態にあることを確認します。
  8. 以下のいずれかを使用して、OpenShift Data Foundation ラベルを新規ノードに適用します。

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

      $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""
  9. [オプション]: 失敗した Google Cloud インスタンスが自動的に削除されない場合、インスタンスを Google Cloud コンソールで終了します。

検証手順

  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 Data Foundation Pod が 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 サポートにお問い合わせください

第15章 ストレージデバイスの置き換え

15.1. Google Cloud のインストーラーでプロビジョニングされるインフラストラクチャーで動作するストレージデバイスまたは失敗したストレージデバイスの置き換え

Google Cloud のインストーラーでプロビジョニングされるインフラストラクチャーの動的に作成されたストレージクラスターのデバイスを置き換える必要がある場合は、ストレージノードを置き換える必要があります。ノードを置き換える方法は、以下を参照してください。

第16章 OpenShift Data Foundation へのアップグレード

16.1. OpenShift Data Foundation 更新プロセスの概要

オープンソースの Ceph テクノロジーに基づく OpenShift Container Storage では、導入以来、コンテナー化されたハイブリッドクラウド環境でのスコープおよび基本的なロールを拡大してきました。他のデータ関連のハードウェアやソフトウェアに加えて、既存のストレージを補完し、ハイブリッドクラウド環境ですぐにアタッチ、アクセス、および拡張できるようにします。これらの基本的なインフラストラクチャーの特徴をより適切に反映するために、OpenShift Container Storage は OpenShift Data Foundation になりました。

重要

OpenShift Container Platform OperatorHub から OpenShift Data Foundation Operator をインストールすることによってのみ、OpenShift Container Storage バージョン 4.8 から OpenShift Data Foundation バージョン 4.9 のアップグレードプロセスを実行できます。

今後のリリースでは、自動更新を有効にすることで、4.9 と 4.x などのマイナーリリース間、または 4.9.0 と 4.9.1 などのバッチ更新間で Red Hat OpenShift Data Foundation をアップグレードできます (Operatorのインストール中に行わない場合)。あるいは、手動更新を実行します。

また、内部および外部モードのデプロイメントの両方で、以下の順序で Red Hat OpenShift Data Foundation のさまざまな部分をアップグレードする必要もあります。

  1. OpenShift Container Platform の『クラスターの更新 』ドキュメントに 従って、OpenShift Container Platform を更新します。
  2. Red Hat OpenShift Data Foundation を更新します。

    1. 更新に非接続環境を準備する には、Operator Lifecycle Manager を制限されたネットワークで使用するための Operator ガイドを参照し、Red Hat OpenShift Data Foundation およびローカルストレージ Operator を使用している場合はこれらを更新できるようにします。
    2. OpenShift Container Platform Web コンソールの OperatorHub から Red Hat OpenShift Data Foundation Operator をインストールして、Red Hat OpenShift Container Storage Operator のバージョン 4.8 をバージョン 4.9 に更新しますUpdating Red Hat OpenShift Container Storage 4.8 to Red Hat OpenShift Data Foundation 4.9 を参照してください。
    3. Red Hat OpenShift Data Foundation を 4.9.x から 4.9.y に更新しますUpdating Red Hat OpenShift Data Foundation 4.9.x to 4.9.y を参照してください。
    4. 外部モードのデプロイメントを更新する場合はOpenShift Data Foundation 外部シークレットの更新 のセクションにある手順も実行する必要があります。
    5. ローカルストレージを使用する場合:

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

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

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

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

更新に関する考慮事項

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

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

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

  • ローカルストレージ Operator は、ローカルストレージ Operator バージョンが Red Hat OpenShift Container Platform バージョンと一致する場合にのみ完全にサポートされます。
  • 柔軟なスケーリング機能は、Red Hat OpenShift Data Foundation バージョン 4.7 以降の新規デプロイメントでのみ利用できます。以前のバージョンからバージョン 4.7 以降にアップグレードされたストレージクラスターは、柔軟なスケーリングをサポートしません。詳細は、New features section of 4.7 Release NotesFlexible scaling of OpenShift Container Storage cluster を参照してください。

16.2. Red Hat OpenShift Container Storage 4.8 の Red Hat OpenShift Data Foundation 4.9 への更新

本章では、すべての Red Hat OpenShift Data Foundation デプロイメント (Internal、Internal-Attached、および External) の z-stream リリース間でアップグレードする方法を説明します。アップグレードプロセスは、すべてのデプロイメントで引き続き同じとなります。唯一の違いは、アップグレードされるものとアップグレードされないものがあることです。

  • Internal および Internal-attached のデプロイメントの場合、OpenShift Container Storage をアップグレードすると、バックエンド Ceph Storage クラスターを含むすべての OpenShift Container Storage サービスがアップグレードされます。
  • 外部モードのデプロイメントの場合、OpenShift Container Storage をアップグレードすると、OpenShift Container Storageサービスのみがアップグレードされ、バックエンド Ceph ストレージクラスターは変更されないままとなり、個別にアップグレードする必要があります。

    新機能のサポート、セキュリティー修正、およびその他のバグ修正を取得するために、RHCS を OpenShift Container Storage と共にアップグレードすることが推奨されます。RHCS アップグレードに強く依存していないため、最初に OpenShift Data Foundation Operator をアップグレードしてから、RHCS をアップグレードするか、またはその逆を行うことができます。Red Hat Ceph Storage リリースの詳細は、solution を参照してください。

重要

4.8 よりも古いバージョンから 4.9 への直接のアップグレードはサポートされていません。

前提条件

  • OpenShift Container Platform クラスターがバージョン 4.9.X の最新の安定したリリースに更新されていることを確認します。Updating Clusters を参照してください。
  • OpenShift Container Storage クラスターが正常であること、およびデータに回復性があることを確認します。

    • Storage → Overview に移動しBlock and File および Object タブの両方のステータスカードの緑色のチェックマークを確認します。緑色のチェックマークは、ストレージクラスターオブジェクトサービス、および データ回復性 がすべて正常であることを示します。
  • Operator Pod を含むすべての OpenShift Container Storage Pod が openshift-storage namespace で Running 状態にあることを確認します。

    Pod の状態を表示するには、OpenShift Web コンソールで Workloads → Pods をクリックします。Project ドロップダウンリストから openshift-storage を選択します。

    注記

    Show default projects オプションが無効になっている場合は、切り替えボタンを使用して、すべてのデフォルトプロジェクトを一覧表示します。

  • 更新時間はクラスターで実行される OSD の数によって異なるため、OpenShift Data Foundation 更新プロセスを完了するのに十分な時間を確保してください。

手順

  1. OpenShift Web コンソールで、OperatorHub に移動します。
  2. Filter by keyword ボックスを使用して OpenShift Data Foundation を検索し、OpenShift Data Foundation タイルをクリックします。
  3. Install をクリックします。
  4. Operator のインストールページで、Install をクリックします。Operator のインストールが完了するまで待ちます。

    注記

    すべてのデフォルト設定を使用することが推奨されます。これを変更すると、予期しない動作が発生する可能性があります。変更後にどうなるのかを認識している場合に限り変更します。

検証手順

  1. このページに、Create StorageSystem のオプションと共に Succeeded メッセージが表示されることを確認します。

    注記

    アップグレードされたクラスターの場合、ストレージシステムは自動的に作成されるため、再度作成しないでください。

  2. 通知ポップアップで Refresh web console リンクをクリックし、OpenShift コンソールで OpenShift Data Foundation の変更を反映します。
  3. OpenShift Web コンソールの Pod の状態を確認します。

    • Workloads → Pods をクリックします。
    • Project ドロップダウンリストから openshift-storage を選択します。

      注記

      Show default projects オプションが無効になっている場合は、切り替えボタンを使用して、すべてのデフォルトプロジェクトを一覧表示します。

      openshift-storage namespace のすべての Pod が再起動し、Running 状態に達するまで待機します。

  4. OpenShift Data Foundation クラスターが正常であること、およびデータに回復性があることを確認します。

    • StorageOpenShift Data foundationStorage Systems タブに移動し、ストレージシステム名をクリックします。
    • Block and File および Object タブの両方のステータスカードの緑色のチェックマークを確認します。緑色のチェックマークは、ストレージクラスター、オブジェクトサービス、およびデータ回復性がすべて正常であることを示します。
重要

関連情報

OpenShift Data Foundation の更新中に問題が発生した場合は、『Troubleshooting guide』の「Commonly required logs for troubleshooting」セクションを参照してください。

16.3. Red Hat OpenShift Data Foundation 4.9.x を 4.9.y に更新

本章では、すべての Red Hat OpenShift Data Foundation デプロイメント (Internal、Internal-Attached、および External) の z-stream リリース間でアップグレードする方法を説明します。アップグレードプロセスは、すべてのデプロイメントで引き続き同じとなります。唯一の違いは、アップグレードされるものとアップグレードされないものがあることです。

  • Internal および Internal-attached のデプロイメントの場合、OpenShift Container Storage をアップグレードすると、バックエンド Ceph Storage クラスターを含むすべての OpenShift Container Storage サービスがアップグレードされます。
  • 外部モードのデプロイメントの場合、OpenShift Container Storage をアップグレードすると、OpenShift Container Storageサービスのみがアップグレードされ、バックエンド Ceph ストレージクラスターは変更されないままとなり、個別にアップグレードする必要があります。

    したがって、新機能のサポート、セキュリティー修正、およびその他のバグ修正を取得するために、RHCS を OpenShift Container Storage と共にアップグレードすることが推奨されます。RHCS アップグレードに強く依存していないため、最初に OpenShift Data Foundation Operator をアップグレードしてから、RHCS をアップグレードするか、またはその逆を行うことができます。Red Hat Ceph Storage リリースの詳細は、solution を参照してください。

z-stream の新規リリースが利用可能になると、更新ストラテジーが Automatic に設定されている場合、アップグレードプロセスが自動的にトリガーされます。更新ストラテジーが Manual に設定されている場合には、以下の手順を使用します。

前提条件

  • OpenShift Container Platform クラスターがバージョン 4.9.X の最新の安定したリリースに更新されていることを確認します。Updating Clusters を参照してください。
  • OpenShift Data Foundation クラスターが正常であり、データに回復性があることを確認します。

    • Storage → OpenShift Data Foundation → Storage Systems タブに移動してから、ストレージシステム名をクリックします。
    • Overview - Block and File および Object タブのステータスカードの緑色のチェックマークを確認します。緑色のチェックマークは、ストレージクラスター、オブジェクトサービス、およびデータの回復性が正常であることを示します。
  • Operator Pod を含むすべての OpenShift Data Foundation Pod が openshift-storage namespace で Running 状態にあることを確認します。

    Pod の状態を表示するには、OpenShift Web コンソールで Workloads → Pods をクリックします。Project ドロップダウンリストから openshift-storage を選択します。

    注記

    Show default projects オプションが無効になっている場合は、切り替えボタンを使用して、すべてのデフォルトプロジェクトを一覧表示します。

  • 更新時間はクラスターで実行される OSD の数によって異なるため、OpenShift Data Foundation 更新プロセスを完了するのに十分な時間を確保してください。

手順

  1. OpenShift Web コンソールで、Operators → Installed Operators に移動します。
  2. openshift-storage プロジェクトを選択します。

    注記

    Show default projects オプションが無効になっている場合は、切り替えボタンを使用して、すべてのデフォルトプロジェクトを一覧表示します。

  3. OpenShift Data Foundation Operator 名をクリックします。
  4. Subscription タブをクリックします。
  5. Upgrade Statusrequire approval が表示される場合は、requires approval リンクをクリックします。
  6. InstallPlan Details ページで、Preview Install Plan をクリックします。
  7. インストール計画を確認し、Approve をクリックします。
  8. Status が Unknown から Created に変更されるまで待機します。

検証手順

  • OpenShift Data Foundation の名前と Operator のステータスの下にある バージョン が、最新バージョンであることを確認します。

    • Operators → Installed Operators に移動し、openshift-storage プロジェクトを選択します。
    • アップグレードが完了すると、バージョンは OpenShift Data Foundation の新規バージョン番号に更新され、ステータスは緑色のチェックマークが付いて Succeeded に変わります。
  • OpenShift Data Foundation クラスターが正常であること、およびデータに回復性があることを確認します。

    • Storage → OpenShift Data Foundation → Storage Systems タブに移動してから、ストレージシステム名をクリックします。
    • Overview - Block and File および Object タブのステータスカードの緑色のチェックマークを確認します。緑色のチェックマークは、ストレージクラスター、オブジェクトサービス、およびデータ回復性が正常であることを示します。
重要

OpenShift Data Foundation Operator のインストール後に console プラグインオプションが自動的に有効にされていない場合は、これを有効にする必要があります。

console プラグインを有効にする方法の詳細は、「 Red Hat OpenShift Data Foundation console プラグインの有効化 」を参照してください。

16.4. 更新承認ストラテジーの変更

同じチャネルで新しい更新が利用可能になったときにストレージシステムが自動的に更新されるようにするには、更新承認ストラテジーを Automatic のままにしておくことをお勧めします。更新承認ストラテジーを Manual に変更すると、アップグレードごとに手動承認が必要になります。

手順

  1. Operators → Installed Operators に移動します。
  2. Project ドロップダウンリストから openshift-storage を選択します。

    注記

    Show default projects オプションが無効になっている場合は、切り替えボタンを使用して、すべてのデフォルトプロジェクトを一覧表示します。

  3. OpenShift Data Foundation Operator 名をクリックします。
  4. Subscription タブに移動します。
  5. 更新承認 を変更するには、鉛筆 アイコンをクリックします。
  6. 更新承認ストラテジーを選択し、Save をクリックします。

検証手順

  • 更新承認で、その下に新しく選択された承認ストラテジーが表示されていることを確認します。