Amazon Web サービスを使用した OpenShift Data Foundation のデプロイ


Red Hat OpenShift Data Foundation 4.18

クラウドストレージの Amazon Web Services を使用した OpenShift Data Foundation のデプロイ手順

Red Hat Storage Documentation Team

概要

Amazon Web Services で Red Hat OpenShift Container Platform を使用して Red Hat OpenShift Data Foundation をインストールする方法は、このドキュメントをご覧ください。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、用語の置き換えは、今後の複数のリリースにわたって段階的に実施されます。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。

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

Red Hat ドキュメントに対するご意見をお聞かせください。ドキュメントの改善点があれば、ぜひお知らせください。

フィードバックを送信するには、Jira チケットを作成します。

  1. Jira にログインします。
  2. 上部のナビゲーションバーで Create をクリックします。
  3. Summary フィールドにわかりやすいタイトルを入力します。
  4. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも追加してください。
  5. Components フィールドで Documentation を選択します。
  6. ダイアログの下部にある Create をクリックします。

はじめに

Red Hat OpenShift Data Foundation は、接続環境または非接続環境での既存の Red Hat OpenShift Container Platform (RHOCP) AWS クラスターへのデプロイメントをサポートし、プロキシー環境に対する追加設定なしのサポートを提供します。

注記

AWS では、内部の OpenShift Data Foundation クラスターのみがサポートされます。デプロイメントの要件の詳細は、デプロイメントのプランニング および OpenShift Data Foundation のデプロイの準備 を参照してください。

OpenShift Data Foundation をデプロイするには、OpenShift Data Foundation のデプロイの準備の章の要件を確認し、要件に基づいた環境のデプロイメントプロセスを実行します。

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

動的ストレージデバイスを使用して OpenShift Data Foundation を OpenShift Container Platform にデプロイすると、内部クラスターリソースを作成するオプションが提供されます。

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

  1. オプション: 外部の鍵管理システム (KMS) HashiCorp Vault を使用してクラスター全体の暗号化を有効にする場合は、次の手順に従います。

  2. オプション: 外部の鍵管理システム (KMS) Thales CipherTrust Manager を使用してクラスター全体の暗号化を有効にする場合は、まず Key Management Interoperability Protocol (KMIP) を有効にして、サーバーで署名付き証明書を使用する必要があります。

    1. KMIP クライアントが存在しない場合は作成します。ユーザーインターフェイスから、KMIPClient ProfileAdd Profile を選択します。

      1. プロファイルの作成中に、CipherTrust のユーザー名を Common Name フィールドに追加します。
    2. KMIPRegistration TokenNew Registration Token に移動してトークンを作成します。次のステップのためにトークンをコピーしておきます。
    3. クライアントを登録するために、KMIPRegistered ClientsAdd Client に移動します。Name を指定します。前のステップの Registration Token を貼り付けて、Save をクリックします。
    4. Save Private KeySave Certificate をクリックして、それぞれ秘密鍵とクライアント証明書をダウンロードします。
    5. 新しい KMIP インターフェイスを作成するために、Admin SettingsInterfacesAdd Interface に移動します。

      1. KMIP Key Management Interoperability Protocol を選択し、Next をクリックします。
      2. 空いている Port を選択します。
      3. Network Interfaceall を選択します。
      4. Interface ModeTLS, verify client cert, user name taken from client cert, auth request is optional を選択します。
      5. (オプション) 物理削除を有効にして、鍵が削除されたときにメタデータとマテリアルの両方を削除することができます。これはデフォルトでは無効になっています。
      6. 使用する認証局 (CA) を選択し、Save をクリックします。
    6. サーバー CA 証明書を取得するために、新しく作成されたインターフェイスの右側にあるアクションメニュー (⋮) をクリックし、Download Certificate をクリックします。
    7. オプション: デプロイ時に StorageClass 暗号化を有効にする場合は、キー暗号化キー (KEK) として機能するキーを作成します。

      1. KeysAdd Key に移動します。
      2. Key Name を入力します。
      3. AlgorithmSize をそれぞれ AES256 に設定します。
      4. Create a key in Pre-Active state を有効にして、アクティベーションの日時を設定します。
      5. Key UsageEncryptDecrypt が有効になっていることを確認します。
      6. 新しく作成した鍵の ID をコピーして、デプロイメント中に一意の識別子として使用します。
  3. ノードの最小要件

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

  4. 障害復旧の要件

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

    詳細な要件は、OpenShift ワークロード用の OpenShift Data Foundation Disaster Recovery の設定 ガイド、および Red Hat Advanced Cluster Management for Kubernetes ドキュメントの インストールガイド要件と推奨事項 セクションを参照してください。

第2章 動的ストレージデバイスを使用した OpenShift Data Foundation のデプロイ

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

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

注記

AWS では、内部の 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 を作成します)。

    $ oc annotate namespace openshift-storage openshift.io/node-selector=
  • ノードに Red Hat OpenShift Data Foundation リソースのみがスケジュールされるように infra のテイントを設定します。これにより、サブスクリプションコストを節約できます。詳細は、ストレージリソースの管理と割り当て ガイドの 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.18 として更新します。
    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 をクリックします。

検証手順

  • Operator が正常にインストールされると、Web console update is available メッセージを含むポップアップがユーザーインターフェイスに表示されます。このポップアップから Refresh web console をクリックして、反映するコンソールを変更します。
  • Web コンソールに移動します。

    • Installed Operators に移動し、OpenShift Data Foundation Operator に、インストールが正常に実行されたことを示す緑色のチェックマークが表示されていることを確認します。
    • Storage に移動し、Data Foundation ダッシュボードが使用可能かどうかを確認します。

2.2. トークン認証方式を使用した KMS でのクラスター全体の暗号化の有効化

トークン認証のために、Vault でキーと値のバックエンドパスおよびポリシーを有効にできます。

前提条件

手順

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

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

    $ vault secrets enable -path=odf kv

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

    $ vault secrets enable -path=odf kv-v2
  2. シークレットに対して書き込み操作または削除操作を実行するようにユーザーを制限するポリシーを作成します。

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

    $ vault token create -policy=odf -format json

2.3. Kubernetes 認証方式を使用した KMS でのクラスター全体の暗号化の有効化

キー管理システム (KMS) を使用して、クラスター全体の暗号化に対して Kubernetes 認証方式を有効にできます。

前提条件

  • Vault への管理者アクセス。
  • 有効な Red Hat OpenShift Data Foundation Advanced サブスクリプション。詳細は、OpenShift Data Foundation サブスクリプションに関するナレッジベースの記事 を参照してください。
  • OpenShift Data Foundation Operator が Operator Hub からインストールされている。
  • バックエンド path として一意のパス名を選択する。これは命名規則に厳密に準拠する必要があります。このパス名は後で変更できません。

手順

  1. サービスアカウントを作成します。

    $ oc -n openshift-storage create serviceaccount <serviceaccount_name>

    ここで、<serviceaccount_name> はサービスアカウントの名前を指定します。

    以下に例を示します。

    $ oc -n openshift-storage create serviceaccount odf-vault-auth
  2. clusterrolebindingsclusterroles を作成します。

    $ oc -n openshift-storage create clusterrolebinding vault-tokenreview-binding --clusterrole=system:auth-delegator --serviceaccount=openshift-storage:_<serviceaccount_name>_

    以下に例を示します。

    $ oc -n openshift-storage create clusterrolebinding vault-tokenreview-binding --clusterrole=system:auth-delegator --serviceaccount=openshift-storage:odf-vault-auth
  3. serviceaccount トークンおよび CA 証明書のシークレットを作成します。

    $ cat <<EOF | oc create -f -
    apiVersion: v1
    kind: Secret
    metadata:
      name: odf-vault-auth-token
      namespace: openshift-storage
      annotations:
        kubernetes.io/service-account.name: <serviceaccount_name>
    type: kubernetes.io/service-account-token
    data: {}
    EOF

    ここで、<serviceaccount_name> は、前の手順で作成したサービスアカウントです。

  4. シークレットからトークンと CA 証明書を取得します。

    $ SA_JWT_TOKEN=$(oc -n openshift-storage get secret odf-vault-auth-token -o jsonpath="{.data['token']}" | base64 --decode; echo)
    $ SA_CA_CRT=$(oc -n openshift-storage get secret odf-vault-auth-token -o jsonpath="{.data['ca\.crt']}" | base64 --decode; echo)
  5. OCP クラスターエンドポイントを取得します。

    $ OCP_HOST=$(oc config view --minify --flatten -o jsonpath="{.clusters[0].cluster.server}")
  6. サービスアカウントの発行者を取得します。

    $ oc proxy &
    $ proxy_pid=$!
    $ issuer="$( curl --silent http://127.0.0.1:8001/.well-known/openid-configuration | jq -r .issuer)"
    $ kill $proxy_pid
  7. 前の手順で収集した情報を使用して、Vault で Kubernetes 認証方法を設定します。

    $ vault auth enable kubernetes
    $ vault write auth/kubernetes/config \
              token_reviewer_jwt="$SA_JWT_TOKEN" \
              kubernetes_host="$OCP_HOST" \
              kubernetes_ca_cert="$SA_CA_CRT" \
              issuer="$issuer"
    重要

    発行者が空の場合は Vault で Kubernetes 認証方法を設定します。

    $ vault write auth/kubernetes/config \
              token_reviewer_jwt="$SA_JWT_TOKEN" \
              kubernetes_host="$OCP_HOST" \
              kubernetes_ca_cert="$SA_CA_CRT"
  8. Vault で Key/Value (KV) バックエンドパスを有効にします。

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

    $ vault secrets enable -path=odf kv

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

    $ vault secrets enable -path=odf kv-v2
  9. シークレットに対して write または delete 操作を実行するようにユーザーを制限するポリシーを作成します。

    echo '
    path "odf/*" {
      capabilities = ["create", "read", "update", "delete", "list"]
    }
    path "sys/mounts" {
    capabilities = ["read"]
    }'| vault policy write odf -
  10. ロールを作成します。

    $ vault write auth/kubernetes/role/odf-rook-ceph-op \
            bound_service_account_names=rook-ceph-system,rook-ceph-osd,noobaa \
            bound_service_account_namespaces=openshift-storage \
            policies=odf \
            ttl=1440h

    ロール odf-rook-ceph-op は、後でストレージシステムの作成中に KMS 接続の詳細を設定するときに使用されます。

    $ vault write auth/kubernetes/role/odf-rook-ceph-osd \
            bound_service_account_names=rook-ceph-osd \
            bound_service_account_namespaces=openshift-storage \
            policies=odf \
            ttl=1440h

2.3.1. KMS 使用時の鍵のローテーションの有効化と無効化

一般的なセキュリティープラクティスでは、定期的な暗号鍵のローテーションが求められます。KMS を使用する場合、鍵のローテーションを有効または無効にできます。

2.3.1.1. キーローテーションの有効化

鍵のローテーションを有効にするには、PersistentVolumeClaimsNamespace、または StorageClass (優先順位の降順) に keyrotation.csiaddons.openshift.io/schedule: <value> アノテーションを追加します。

<value>@hourly@daily@weekly@monthly、または @yearly のいずれかになります。<value> が空の場合、デフォルトは @weekly になります。以下の例では @weekly を使用しています。

重要

キーのローテーションは、RBD バックアップボリュームでのみサポートされます。

名前空間のアノテーション

$ oc get namespace default
NAME      STATUS   AGE
default   Active   5d2h
$ oc annotate namespace default "keyrotation.csiaddons.openshift.io/schedule=@weekly"
namespace/default annotated

StorageClass のアノテーション

$ oc get storageclass rbd-sc
NAME       PROVISIONER        RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
rbd-sc     rbd.csi.ceph.com   Delete          Immediate           true                   5d2h
$ oc annotate storageclass rbd-sc "keyrotation.csiaddons.openshift.io/schedule=@weekly"
storageclass.storage.k8s.io/rbd-sc annotated

PersistentVolumeClaims のアノテーション

$ oc get pvc data-pvc
NAME      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
data-pvc  Bound    pvc-f37b8582-4b04-4676-88dd-e1b95c6abf74   1Gi        RWO            default           20h
$ oc annotate pvc data-pvc "keyrotation.csiaddons.openshift.io/schedule=@weekly"
persistentvolumeclaim/data-pvc annotated
$ oc get encryptionkeyrotationcronjobs.csiaddons.openshift.io
NAME                    SCHEDULE    SUSPEND   ACTIVE   LASTSCHEDULE   AGE
data-pvc-1642663516   @weekly                                     3s
$ oc annotate pvc data-pvc "keyrotation.csiaddons.openshift.io/schedule=*/1 * * * *" --overwrite=true
persistentvolumeclaim/data-pvc annotated
$ oc get encryptionkeyrotationcronjobs.csiaddons.openshift.io
NAME                  SCHEDULE    SUSPEND   ACTIVE   LASTSCHEDULE   AGE
data-pvc-1642664617   */1 * * * *                                   3s
2.3.1.2. 鍵のローテーションの無効化

次の鍵のローテーションを無効にできます。

  • ストレージクラスのすべての永続ボリューム要求 (PVC)
  • 特定の PVC

ストレージクラスのすべての PVC の鍵ローテーションを無効にする

すべての PVC の鍵ローテーションを無効にするには、ストレージクラスのアノテーションを更新します。

$ oc get storageclass rbd-sc
NAME       PROVISIONER        RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
rbd-sc     rbd.csi.ceph.com   Delete          Immediate           true                   5d2h
$ oc annotate storageclass rbd-sc "keyrotation.csiaddons.openshift.io/enable: false"
storageclass.storage.k8s.io/rbd-sc annotated

特定の永続ボリューム要求の鍵ローテーションを無効にする

  1. 鍵のローテーションを無効にする PVC の EncryptionKeyRotationCronJob CR を特定します。

    $ oc get encryptionkeyrotationcronjob -o jsonpath='{range .items[?(@.spec.jobTemplate.spec.target.persistentVolumeClaim=="<PVC_NAME>")]}{.metadata.name}{"\n"}{end}'

    <PVC_NAME> は、無効にする PVC の名前です。

  2. 鍵のローテーションを無効にするには、前の手順の EncryptionKeyRotationCronJob CR に以下を適用します。

    1. csiaddons.openshift.io/state アノテーションを managed から unmanaged に更新します。

      $ oc annotate encryptionkeyrotationcronjob <encryptionkeyrotationcronjob_name> "csiaddons.openshift.io/state=unmanaged" --overwrite=true

      ここで、<encryptionkeyrotationcronjob_name> は EncryptionKeyRotationCronJob CR の名前です。

    2. spec フィールドの下に suspend: true を追加します。

      $ oc patch encryptionkeyrotationcronjob <encryptionkeyrotationcronjob_name> -p '{"spec": {"suspend": true}}' --type=merge.
  3. 保存して終了します。PVC の鍵のローテーションは無効になります。

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

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

前提条件

手順

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

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

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

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

      OpenShift Data Foundation バージョン 4.12 以降、ストレージクラスとして gp2-csi または gp3-csi を選択できます。

    4. オプション: 外部 PostgreSQL を使用するには、Use external PostgreSQL チェックボックスを選択します [テクノロジープレビュー]

      これにより、PostgreSQL Pod が単一障害点となるマルチクラウドオブジェクトゲートウェイの高可用性ソリューションが提供されます。

      1. 以下の接続の詳細を指定します。

        • ユーザー名
        • パスワード
        • サーバー名ポート
        • データベース名
      2. Enable TLS/SSL チェックボックスを選択して、Postgres サーバーの暗号化を有効にします。
    5. Next をクリックします。
  4. Capacity and nodes ページで、必要な情報を提供します。

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

      注記

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

    2. Select Nodes セクションで、少なくとも 3 つの利用可能なノードを選択します。
    3. Configure performance セクションで、以下のパフォーマンスプロファイルのいずれかを選択します。

      • Lean

        これは、最小リソースが推奨値よりも少ない、リソースに制約のある環境で使用します。このプロファイルでは、割り当てられる CPU とメモリーの数が少なくなり、リソースの消費が最小限に抑えられます。

      • balanced (デフォルト)

        推奨リソースが利用可能な場合にこれを使用します。このプロファイルは、さまざまなワークロードのリソース消費とパフォーマンスのバランスを提供します。

      • パフォーマンス

        最高のパフォーマンスを得るために十分なリソースがある環境でこれを使用してください。このプロファイルは、負荷の高いワークロードを最適に実行できるように十分なメモリーと CPU を割り当てることで、高いパフォーマンスを実現するように調整されています。

        注記

        StorageSystems タブのオプションメニューから Configure performance オプションを使用して、デプロイメント後にパフォーマンスプロファイルを設定するオプションがあります。

        重要

        リソースプロファイルを選択する前に、クラスター内のリソースの現在の可用性を必ず確認してください。リソースが不十分なクラスターでより高いリソースプロファイルを選択すると、インストールが失敗する可能性があります。

        リソース要件の詳細は、パフォーマンスプロファイルのリソース要件 を参照してください。

    4. オプション: 選択したノードを OpenShift Data Foundation 専用にする場合は、Taint nodes チェックボックスを選択します。

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

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

    5. Next をクリックします。
  5. オプション: Security and network ページで、要件に応じて以下を設定します。

    1. 暗号化を有効にするには、Enable data encryption for block and file storage を選択します。

      1. 暗号化レベルのいずれかまたは両方を選択します。

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

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

        • StorageClass の暗号化

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

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

        1. Key Management Service Provider ドロップダウンリストから、次のいずれかのプロバイダーを選択し、必要な詳細情報を入力します。

          • Vault

            1. Authentication Method を選択します。

              • トークン認証方式の使用

                • Vault ('https://<hostname or ip>') サーバーの一意の Connection Name、ホストの AddressPort 番号および Token を入力します。
                • Advanced Settings をデプロイメントして、Vault 設定に基づいて追加の設定および証明書の詳細を入力します。

                  • OpenShift Data Foundation 専用かつ特有のキーと値のシークレットパスを Backend Path に入力します。
                • オプション: TLS Server Name および Vault Enterprise Namespace を入力します。
                • それぞれの PEM でエンコードされた証明書ファイルをアップロードし、CA 証明書クライアント証明書、および クライアントの秘密鍵 を提供します。
                • Save をクリックします。
              • Kubernetes 認証方式の使用

                • Vault ('https://<hostname or ip>') サーバーの一意の Connection Name、ホストの AddressPort 番号、および Role 名を入力します。
                • Advanced Settings をデプロイメントして、Vault 設定に基づいて追加の設定および証明書の詳細を入力します。

                  • OpenShift Data Foundation 専用かつ特有のキーと値のシークレットパスを Backend Path に入力します。
                  • 該当する場合は、TLS Server Name および Authentication Path を入力します。
                  • PEM でエンコードされた、該当の証明書ファイルをアップロードし、CA CertificateClient Certificate、および Client Private Key を指定します。
                • Save をクリックします。

                  注記

                  Vault KMS のキーローテーションを有効にする必要がある場合は、ストレージクラスターの作成後に OpenShift Web コンソールで以下のコマンドを実行します。

                  oc patch storagecluster ocs-storagecluster -n openshift-storage --type=json -p '[{"op": "add", "path":"/spec/encryption/keyRotation/enable", "value": true}]'
          • Thales CipherTrust Manager (KMIP を使用)

            1. プロジェクト内のキー管理サービスの一意の Connection Name を入力します。
            2. Address および Port セクションで、Thales CipherTrust Manager の IP と、KMIP インターフェイスが有効になっているポートを入力します。以下に例を示します。

              • Address: 123.34.3.2
              • Port: 5696
            3. Client CertificateCA certificate、および Client Private Key をアップロードします。
            4. StorageClass 暗号化が有効になっている場合は、上記で生成された暗号化および復号化に使用する一意の識別子を入力します。
            5. TLS Server フィールドはオプションであり、KMIP エンドポイントの DNS エントリーがない場合に使用します。たとえば、kmip_all_<port>.ciphertrustmanager.local などです。
    2. 転送中の暗号化を有効にするには、In-transit encryption を選択します。

      1. Network を選択します。
      2. Next をクリックします。
  6. Review and create ページで、設定の詳細を確認します。

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

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

デプロイメントに 5 つ以上のノード、ラック、またはルームがあり、デプロイメント内に 5 つ以上の障害ドメインが存在する場合、ラックまたはゾーンの数に基づいて Ceph モニター数を設定できます。OpenShift Web コンソールの通知パネルまたはアラートセンターにアラートが表示され、Ceph モニター数を増やすオプションが示されます。アラートで Configure オプションを使用して、Ceph モニター数を設定できます。詳細は、Ceph モニター数が少ないというアラートの解決 を参照してください。

検証手順

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

    1. OpenShift Web コンソールで、Installed OperatorsOpenShift Data FoundationStorage Systemocs-storagecluster-storagesystemResources の順に移動します。
    2. StorageClusterStatusReady になっており、それの横に緑色のチェックマークが表示されていることを確認します。
  • OpenShift Data Foundation のすべてのコンポーネントが正常にインストールされていることを確認するには、Verifying your OpenShift Data Foundation deployment を参照してください。

関連情報

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

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

OpenShift Data Foundation が正常にデプロイされていることを確認するには、以下を実行します。

2.5.1. Pod の状態の確認

手順

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

    注記

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

    各コンポーネントの予想される Pod 数と、それがノード数によってどのように変化するかは、次の表を参照してください。

  1. 実行中および完了した Pod のフィルターを設定して、次の Pod が Running および Completed 状態であることを確認します。

コンポーネント

対応する Pod

OpenShift Data Foundation Operator

  • ocs-operator-* (任意のストレージノードに 1 Pod)
  • ocs-metrics-exporter-* (任意のストレージノードに 1 Pod)
  • odf-operator-controller-manager-* (任意のストレージノードに 1 Pod)
  • odf-console-* (任意のストレージノードに 1 Pod)
  • csi-addons-controller-manager-* (任意のストレージノードに 1 Pod)
  • ux-backend-server-* (任意のストレージノードに 1 Pod)
  • * ocs-client-operator-* (任意のストレージノードに 1 Pod)
  • ocs-client-operator-console-* (任意のストレージノードに 1 Pod)
  • ocs-provider-server-* (任意のストレージノードに 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)

ceph-csi-operator

ceph-csi-controller-manager-* (デバイスごとに 1 つの Pod)

2.5.2. OpenShift Data Foundation クラスターが正常であることを確認

手順

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

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

2.5.3. Multicloud Object Gateway が正常であることを確認

手順

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

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

ブロックおよびファイルダッシュボードを使用した OpenShift Data Foundation クラスターの健全性は、OpenShift Data Foundation の監視 を参照してください。

重要

Multicloud Object Gateway には、データベースのコピー (NooBaa DB) が 1 つだけあります。つまり、NooBaa DB PVC が破損し、回復できない場合は、Multicloud Object Gateway に存在するアプリケーションデータが完全に失われる可能性があります。このため、Red Hat では NooBaa DB PVC のバックアップを定期的に取ることを推奨しています。NooBaa DB に障害が発生して回復できない場合は、最新のバックアップバージョンに戻すことができます。NooBaa DB をバックアップする手順は、こちらのナレッジベースの記事 の手順に従ってください。

2.5.4. 特定のストレージクラスが存在することを確認

手順

  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 コンポーネントのみをデプロイすると、デプロイメントで柔軟性が高まり、リソース消費を減らすことができます。コンポーネントをデプロイした後、MCG オブジェクトブラウザーを使用してバケットを作成および管理できます。詳細は、MCG オブジェクトブラウザーを使用したバケットの作成と管理 を参照してください。

このセクションには、次の手順が含まれており、スタンドアロンの Multicloud Object Gateway コンポーネントのみをデプロイする場合に使用します。

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

Multicloud Object Gateway には、データベースのコピー (NooBaa DB) が 1 つだけあります。つまり、NooBaa DB PVC が破損し、回復できない場合は、Multicloud Object Gateway に存在するアプリケーションデータが完全に失われる可能性があります。このため、Red Hat では NooBaa DB PVC のバックアップを定期的に取ることを推奨しています。NooBaa DB に障害が発生して回復できない場合は、最新のバックアップバージョンに戻すことができます。NooBaa DB をバックアップする手順は、こちらのナレッジベースの記事 の手順に従ってください。

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 を作成します)。

    $ oc annotate namespace openshift-storage openshift.io/node-selector=
  • ノードに Red Hat OpenShift Data Foundation リソースのみがスケジュールされるように infra のテイントを設定します。これにより、サブスクリプションコストを節約できます。詳細は、ストレージリソースの管理と割り当て ガイドの 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.18 として更新します。
    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 をクリックします。

検証手順

  • Operator が正常にインストールされると、Web console update is available メッセージを含むポップアップがユーザーインターフェイスに表示されます。このポップアップから Refresh web console をクリックして、反映するコンソールを変更します。
  • Web コンソールに移動します。

    • Installed Operators に移動し、OpenShift Data Foundation Operator に、インストールが正常に実行されたことを示す緑色のチェックマークが表示されていることを確認します。
    • Storage に移動し、Data Foundation ダッシュボードが使用可能かどうかを確認します。

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

OpenShift Data Foundation のデプロイ時には、スタンドアロンの Multicloud Object Gateway (MCG) コンポーネントのみを作成できます。MCG コンポーネントを作成したら、MCG オブジェクトブラウザーを使用してバケットを作成および管理できます。詳細は、MCG オブジェクトブラウザーを使用したバケットの作成と管理 を参照してください。

前提条件

  • OpenShift Data Foundation Operator がインストールされている。

手順

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

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

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

    1. Deployment typeMulticloud Object Gateway を選択します。
    2. Use an existing StorageClass オプションを選択します。
    3. Next をクリックします。
  4. オプション: Connect to an external key management service チェックボックスを選択します。これはクラスター全体の暗号化の場合はオプションになります。

    1. Key Management Service Provider ドロップダウンリストから、Vault または Thales CipherTrust Manager (using KMIP) を選択します。Vault を選択した場合は、次の手順に進みます。Thales CipherTrust Manager (using KMIP) を選択した場合は、手順 iii に進みます。
    2. Authentication Method を選択します。

      トークン認証方式の使用
      • Vault ('https://<hostname or ip>') サーバーの一意の Connection Name、ホストの AddressPort 番号および Token を入力します。
      • Advanced Settings をデプロイメントして、Vault 設定に基づいて追加の設定および証明書の詳細を入力します。

        • OpenShift Data Foundation 専用かつ特有のキーと値のシークレットパスを Backend Path に入力します。
        • オプション: TLS Server Name および Vault Enterprise Namespace を入力します。
        • PEM でエンコードされた、該当の証明書ファイルをアップロードし、CA CertificateClient Certificate、および Client Private Key を指定します。
        • Save をクリックして、手順 iv に進みます。
      Kubernetes 認証方式の使用
      • Vault ('https://<hostname or ip>') サーバーの一意の Connection Name、ホストの AddressPort 番号、および Role 名を入力します。
      • Advanced Settings をデプロイメントして、Vault 設定に基づいて追加の設定および証明書の詳細を入力します。

        • OpenShift Data Foundation 専用かつ特有のキーと値のシークレットパスを Backend Path に入力します。
        • 該当する場合は、TLS Server Name および Authentication Path を入力します。
        • PEM でエンコードされた、該当の証明書ファイルをアップロードし、CA CertificateClient Certificate、および Client Private Key を指定します。
        • Save をクリックして、手順 iv に進みます。
    3. Thales CipherTrust Manager (using KMIP) を KMS プロバイダーとして使用するには、次の手順に従います。

      1. プロジェクト内のキー管理サービスの一意の Connection Name を入力します。
      2. Address および Port セクションで、Thales CipherTrust Manager の IP と、KMIP インターフェイスが有効になっているポートを入力します。以下に例を示します。

        • Address: 123.34.3.2
        • Port: 5696
      3. Client CertificateCA certificate、および Client Private Key をアップロードします。
      4. StorageClass 暗号化が有効になっている場合は、上記で生成された暗号化および復号化に使用する一意の識別子を入力します。
      5. TLS Server フィールドはオプションであり、KMIP エンドポイントの DNS エントリーがない場合に使用します。たとえば、kmip_all_<port>.ciphertrustmanager.local などです。
    4. Network を選択します。
    5. Next をクリックします。
  5. Review and create ページで、設定の詳細を確認します。

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

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

検証手順

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

    1. Object タブの Status card で、Object ServiceData Resiliency の両方に緑色のチェックマークが表示されていることを確認します。
    2. Details カードで、MCG 情報が表示されることを確認します。
Pod の状態の確認
  1. OpenShift Web コンソールから WorkloadsPods をクリックします。
  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)
    • csi-addons-controller-manager-* (任意のストレージノードに 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章 AWS-STS でサポートされるバッキングストアの作成

Amazon Web Services セキュリティートークンサービス (AWS STS) は AWS の機能であり、有効期間の短い認証情報を使用して認証する方法です。AWS-STS がサポートするバッキングストアを作成するには、次の作業が必要です。

  • スクリプトを使用して AWS ロールを作成し、ロールセッションの一時的なセキュリティー認証情報を取得
  • AWS STS OpenShift クラスターへの OpenShift Data Foundation Operator のインストール
  • AWS STS OpenShift クラスターでのバッキングストアの作成

4.1. スクリプトを使用した AWS ロールの作成

OpenShift Data Foundation Operator のインストール中に、ロールを作成し、ロール Amazon リソース名 (ARN) を指定する必要があります。

前提条件

手順

  • OpenShift Data Foundation 上の Multicloud Object Gateway (MCG) の OpenID Connect (OIDC) 設定に一致するスクリプトを使用して、AWS ロールを作成します。

    以下の例は、ロールの作成に必要な詳細を示しています。

    {
        “Version”: “2012-10-17",
        “Statement”: [
            {
                “Effect”: “Allow”,
                “Principal”: {
                    “Federated”: “arn:aws:iam::123456789123:oidc-provider/mybucket-oidc.s3.us-east-2.amazonaws.com”
                },
                “Action”: “sts:AssumeRoleWithWebIdentity”,
                “Condition”: {
                    “StringEquals”: {
                        “mybucket-oidc.s3.us-east-2.amazonaws.com:sub”: [
                            “system:serviceaccount:openshift-storage:noobaa”,
                            "system:serviceaccount:openshift-storage:noobaa-core",
                            “system:serviceaccount:openshift-storage:noobaa-endpoint”
                        ]
                    }
                }
            }
        ]
    }

    ここでは、以下のようになります。

    123456789123
    AWS アカウント ID です。
    mybucket
    バケット名です (パブリックバケット設定を使用)。
    us-east-2
    AWS リージョンです。
    openshift-storage
    namespace 名

サンプルスクリプト

#!/bin/bash
set -x

# This is a sample script to help you deploy MCG on AWS STS cluster.
# This script shows how to create role-policy and then create the role in AWS.
# For more information see: https://docs.openshift.com/rosa/authentication/assuming-an-aws-iam-role-for-a-service-account.html

# WARNING: This is a sample script. You need to adjust the variables based on your requirement.

# Variables :
# user variables - REPLACE these variables with your values:
ROLE_NAME="<role-name>" # role name that you pick in your AWS account
NAMESPACE="<namespace>" # namespace name where MCG is running. For OpenShift Data Foundation, it is openshift-storage.

# MCG variables
SERVICE_ACCOUNT_NAME_1="noobaa" # The service account name of deployment operator
SERVICE_ACCOUNT_NAME_2="noobaa-endpoint" # The service account name of deployment endpoint
SERVICE_ACCOUNT_NAME_3="noobaa-core" # The service account name of statefulset core

# AWS variables
# Make sure these values are not empty (AWS_ACCOUNT_ID, OIDC_PROVIDER)
# AWS_ACCOUNT_ID is your AWS account number
AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query "Account" --output text)
# If you want to create the role before using the cluster, replace this field too.
# The OIDC provider is in the structure:
# 1) <OIDC-bucket>.s3.<aws-region>.amazonaws.com. for OIDC bucket configurations are in an S3 public bucket
# 2) `<characters>.cloudfront.net` for OIDC bucket configurations in an S3 private bucket with a public CloudFront distribution URL
OIDC_PROVIDER=$(oc get authentication cluster -ojson | jq -r .spec.serviceAccountIssuer | sed -e "s/^https:\/\///")
# the permission (S3 full access)
POLICY_ARN_STRINGS="arn:aws:iam::aws:policy/AmazonS3FullAccess"

# Creating the role (with AWS command line interface)

read -r -d '' TRUST_RELATIONSHIP <<EOF
{
 "Version": "2012-10-17",
 "Statement": [
   {
 	"Effect": "Allow",
 	"Principal": {
   	"Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/${OIDC_PROVIDER}"
 	},
 	"Action": "sts:AssumeRoleWithWebIdentity",
 	"Condition": {
   	"StringEquals": {
    	"${OIDC_PROVIDER}:sub": [
      	"system:serviceaccount:${NAMESPACE}:${SERVICE_ACCOUNT_NAME_1}",
      	"system:serviceaccount:${NAMESPACE}:${SERVICE_ACCOUNT_NAME_2}",
        "system:serviceaccount:${NAMESPACE}:${SERVICE_ACCOUNT_NAME_3}"
      	]
   	}
 	}
   }
 ]
}
EOF

echo "${TRUST_RELATIONSHIP}" > trust.json

aws iam create-role --role-name "$ROLE_NAME" --assume-role-policy-document file://trust.json --description "role for demo"

while IFS= read -r POLICY_ARN; do
   echo -n "Attaching $POLICY_ARN ... "
   aws iam attach-role-policy \
   	--role-name "$ROLE_NAME" \
   	--policy-arn "${POLICY_ARN}"
   echo "ok."
done <<< "$POLICY_ARN_STRINGS"

4.1.1. AWS STS OpenShift クラスターへの OpenShift Data Foundation Operator のインストール

前提条件

手順

  • Operator Hub から OpenShift Data Foundation Operator をインストールします。

    • インストール中に、ロール ARN を ARN Details フィールドに追加します。
    • Update approval フィールドが Manual に設定されていることを確認します。

4.1.2. 新規 AWS STS バッキングストアの作成

前提条件

手順

  1. Multicloud Object Gateway (MCG) をインストールします。

    これは、有効期間の短い認証情報を使用して、デフォルトのバッキングストアとともにインストールされます。

  2. MCG システムの準備ができたら、次の MCG コマンドラインインターフェイスコマンドを使用して、aws-sts-s3 タイプのバッキングストアをさらに作成できます。

    $ noobaa backingstore create aws-sts-s3 <backingstore-name> --aws-sts-arn=<aws-sts-role-arn> --region=<region> --target-bucket=<target-bucket>

    ここでは、以下のようになります。

    backingstore-name
    バッキングストアの名前
    aws-sts-role-arn
    ロールを引き受ける AWS STS ロール ARN
    region
    AWS バケットリージョン
    target-bucket
    クラウド上のターゲットバケット名

第5章 OpenShift Data Foundation トポロジーの表示

トポロジーは、OpenShift Data Foundation ストレージクラスターをマップしたた視覚情報をさまざまな抽象化レベルで示し、このような階層の操作も可能にします。このビューでは、ストレージクラスターがさまざまな要素でどのように構成されているかがわかります。

手順

  1. OpenShift Web コンソールで、StorageData FoundationTopology に移動します。

    このビューには、ストレージクラスターとその内部のゾーンが表示されます。ノードがゾーン内 (点線で示されている) にある円形のエンティティーで表示されていることが分かります。各アイテムまたはリソースのラベルには、ステータスやヘルス、アラートの状態などの基本情報が含まれています。

  2. ノードを選択すると、右側のパネルにノードの詳細が表示されます。検索/プレビューデコレーターアイコンをクリックして、ノード内のリソースまたはデプロイメントにアクセスすることもできます。
  3. デプロイメントの詳細を表示します。

    1. ノード上のプレビューデコレーターをクリックします。ノードの上にモーダルウィンドウが表示され、そのノードに関連付けられているすべてのデプロイメントとそのステータスが表示されます。
    2. モデルの左上隅にある Back to main view ボタンをクリックしてモデルを閉じ、前のビューに戻ります。
    3. 特定のデプロイメントを選択すると、そのデプロイメントに関する詳細が表示されます。関連するデータがすべてサイドパネルに表示されます。
  4. Resources タブをクリックして Pod 情報を表示します。このタブを使用すると、問題の理解を深めることができるだけでなく、複数の詳細レベルが提供されるので適切にトラブルシューティングができるようになります。
  5. Pod のリンクをクリックして、OpenShift Container Platform の Pod 情報ページを表示します。リンクは新しいウィンドウで開きます。

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

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

内部モードで OpenShift Data Foundation をアンインストールするには、OpenShift Data Foundation のアンインストールに関するナレッジベース記事 を参照してください。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.