Menu Close

デプロイメントのプランニング

Red Hat OpenShift Data Foundation 4.9

Red Hat OpenShift Data Foundation 4.9 をデプロイする際の重要な考慮事項

概要

本書は、Red Hat OpenShift Data Foundation のデプロイメントを計画する際の重要な考慮事項について説明します。

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

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 をクリックします。

第1章 OpenShift Data Foundation の紹介

Red Hat OpenShift Data Foundation は、Red Hat OpenShift Container Platform のクラウドストレージおよびデータサービスの集合です。これは、単純なデプロイメントおよび管理を容易に実行するために Operator としてパッケージ化され、Red Hat OpenShift Container Platform サービスカタログの一部として利用できます。

Red Hat OpenShift Data Foundation サービスは、主に以下のコンポーネントを表すストレージクラスを使用してアプリケーションで使用できます。

  • ブロックストレージデバイス。主にデータベースのワークロードに対応します。主な例には、Red Hat OpenShift Container Platform のロギングおよびモニタリング、および PostgreSQL などがあります。
  • 共有および分散ファイルシステム。主にソフトウェア開発、メッセージング、およびデータ集約のワークロードに対応します。これらの例には、Jenkins ビルドソースおよびアーティファクト、Wordpress のアップロードコンテンツ、Red Hat OpenShift Container Platform レジストリー、および JBoss AMQ を使用したメッセージングが含まれます。
  • Multicloud オブジェクトストレージ。複数のクラウドオブジェクトストアからのデータの保存および取得を抽象化できる軽量 S3 API エンドポイントを特長としています。
  • オンプレミスオブジェクトストレージ。主にデータ集約型アプリケーションをターゲットとする数十ペタバイトおよび数十億のオブジェクトにスケーリングする堅牢な S3 API エンドポイントを特長としています。これらの例には、Spark、Presto、Red Hat AMQ Streams (Kafka) などのアプリケーションや、TensorFlow や Pytorch などのマシンラーニングフレームワークを使用した行、列、および半構造化データの保存およびアクセスが含まれます。

Red Hat OpenShift Data Foundation バージョン 4.x は、以下を含むソフトウェアプロジェクトのコレクションを統合します。

  • Ceph。ブロックストレージ、共有および分散ファイルシステム、およびオンプレミスのオブジェクトストレージを提供します。
  • Ceph CSI。永続ボリュームおよび要求のプロビジョニングおよびライフサイクルを管理します。
  • NooBaa。Multicloud Object Gateway を提供します。
  • OpenShift Data Foundation サービスを初期化し、管理する OpenShift Data Foundation、Rook-Ceph、および NooBaa Operator。

第2章 OpenShift Data Foundation のアーキテクチャー

Red Hat OpenShift Data Foundation は、Red Hat OpenShift Container Platform のサービスを提供し、Red Hat OpenShift Container Platform から内部で実行できます。

図2.1 Red Hat OpenShift Data Foundation アーキテクチャー

Red Hat OpenShift Data Foundation architecture

Red Hat OpenShift Data Foundation は、インストーラーでプロビジョニングされるインフラストラクチャー、またはユーザーによってプロビジョニングされるインフラストラクチャー でデプロイされる Red Hat OpenShift Container Platform クラスターへのデプロイメントをサポートします。これら 2 つの方法については、OpenShift Container Platform のインストールプロセスについて参照してください。Red Hat OpenShift Data Foundation と Red Hat OpenShift Container Platform のコンポーネントの相互運用性についての詳細は、Red Hat OpenShift Data Foundation のサポート性および相互運用性チェッカー を参照してください。

OpenShift Container Platform のアーキテクチャーおよびライフサイクルについての詳細は、『OpenShift Container Platform architecture』を参照してください。

注記

IBM Power の場合は、「 OpenShift Container Platform - Installation process 」を参照してください。

2.1. Operator

Red Hat OpenShift Data Foundation は主に 3 つの Operator で構成されており、管理タスクとカスタムリソースをコード化し、タスクおよびリソースの特性をより簡単に自動化できるようにします。管理者はクラスターの必要な最終状態を定義し、OpenShift Data Foundation Operator は管理者の介入を最小限に抑えてクラスターをその状態にするか、またはその状態に近づけるようにします。

OpenShift Data Foundation Operator

他の Operator を特定のテストされた方法で利用してサポートされている Red Hat OpenShift Data Foundation デプロイメントの推奨事項および要件を定め、実施するメタ Operator。この Operator は、Rook-Ceph および NooBaa Operator によって提供されるリソースをラップするストレージクラスターリソースを提供します。

Rook-Ceph Operator

この Operator は、永続ストレージおよびファイル、ブロックおよびオブジェクトサービスのパッケージ化、デプロイメント、管理、アップグレード、およびスケーリングを自動化します。これは、すべての環境用にブロックおよびファイルストレージクラスを作成し、オンプレミス環境でオブジェクトストレージクラスおよびサービスオブジェクトバケット要求を作成します。

さらに、内部モードクラスターの場合、以下を表すデプロイメントおよびサービスを管理する Ceph クラスターリソースを提供します。

  • オブジェクトストレージデーモン (OSD)
  • モニター (MON)
  • マネージャー (MGR)
  • メタデータサーバー (MDS)
  • オブジェクトゲートウェイ (RGW): オンプレミスの場合のみ

MCG Operator

この Operator は、Multicloud Object Gateway オブジェクトサービスのパッケージ化、デプロイメント、管理、アップグレード、およびスケーリングを自動化します。これは、オブジェクトストレージクラスおよびサービスオブジェクトバケット要求を作成します。

さらに、これは NooBaa クラスターリソースを提供します。このクラスターリソースは、NooBaa コア、データベースおよびエンドポイントのデプロイメントとサービスを管理します。

2.2. ストレージクラスターのデプロイメントアプローチ

柔軟性は、複数モード (operating modalities) 一覧の拡張によって確認されるように Red Hat OpenShift Data Foundation の中心的な特徴です。本セクションでは、お使いの環境に最も適した方法を選択するのに役立つ情報を提供します。

Red Hat OpenShift Data Foundation は OpenShift Container Platform 内で完全にデプロイ (内部アプローチ) することも、OpenShift Container Platform 外で実行されるクラスターからサービスを利用可能する方法 (外部アプローチ) を実行することもできます。

2.2.1. 内部アプローチ

Red Hat OpenShift Data Foundation を Red Hat OpenShift Container Platform 内に完全にデプロイすると、Operator ベースのデプロイメントおよび管理によるすべての利点が得られます。グラフィカルユーザーインターフェースで、内部でアタッチされているデバイスのアプローチを使用して、ローカルストレージ Operator とローカルストレージデバイスで、Red Hat OpenShift Data Foundation を内部モードでデプロイできます。

デプロイメントおよび管理の容易性は、OpenShift Data Foundation サービスを OpenShift Container Platform の内部で実行することについての主な特長となっています。Red Hat OpenShift Data Foundation が完全に Red Hat OpenShift Container Platform 内で実行されている場合、以下の 2 つのデプロイメントモードを使用できます。

  • Simple (単純)
  • Optimized (最適化)

Simple (単純) デプロイメント

Red Hat OpenShift Data Foundation サービスは、Red Hat OpenShift Container Platform の Operator によって管理されるアプリケーションと共存する形で実行されます。

Simple (単純) デプロイメントは、以下の状況で最適です。

  • ストレージ要件が明確ではない。
  • Red Hat OpenShift Data Foundation サービスは、アプリケーションと共存する形で実行される。
  • 特定サイズのノードインスタンスの作成が容易ではない (ベアメタル)。

Red Hat OpenShift Data Foundation がアプリケーションと共存する形で実行されるには、EC2 の EBS ボリューム、VMware の vSphere Virtual Volume、または PowerVC によって動的にプロビジョニングされる SAN ボリュームのように、ローカルストレージデバイスまたはポータブルストレージデバイスがそれらに動的に接続される必要があります。

Optimized (最適化) デプロイメント

Red Hat OpenShift Data Foundation サービスは、Red Hat OpenShift Container Platform で管理される専用のインフラストラクチャーノードで実行されます。

最適化アプローチは、以下の場合に最も適しています。

  • ストレージ要件が明確である
  • Red Hat OpenShift Data Foundation サービスを専用のインフラストラクチャーノードで実行する
  • 特定サイズのノードインスタンスの作成が容易である (クラウド、仮想化環境など)

2.2.2. 外部アプローチ

Red Hat OpenShift Data Foundation は、OpenShift Container Platform クラスター外で実行されている Red Hat Ceph Storage サービスをストレージクラスとして公開します。

以下の場合に外部アプローチが最も適しています。

  • ストレージ要件の規模が大きい(600 以上のストレージデバイス)。
  • 複数の OpenShift Container Platform クラスターが共通の外部クラスターからストレージサービスを使用する必要がある
  • 別のチーム (SRE、ストレージなど) はストレージサービスを提供する外部クラスターを管理する必要がある(すでに存在している場合があります)

2.3. ノードのタイプ

ノードはコンテナーランタイムとサービスを実行し、コンテナーが実行中の状態にし、Pod 間のネットワーク通信および分離を保ちます。OpenShift Data Foundation には、3 種類のノードがあります。

表2.1 ノードの種類

ノードタイプ説明

マスター

これらのノードは、Kubernetes API を公開し、新たに作成された Pod を監視およびスケジュールし、ノードの正常性および数量を維持し、基礎となるクラウドプロバイダーとの対話を制御するプロセスを実行します。

インフラストラクチャー (インフラ)

インフラストラクチャーノードは、ロギング、メトリクス、レジストリー、およびルーティングなどのクラスターレベルのインフラストラクチャーサービスを実行します。これらは OpenShift Container Platform クラスターでオプションになります。OpenShift Data Foundation レイヤーワークロードをアプリケーションから分離するには、仮想化環境およびクラウド環境で OpenShift Data Foundation に infra ノードを使用することが推奨されます。

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

ワーカー

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

OpenShift Data Foundation が内部モードでデプロイされる場合、3 つのワーカーノードで構成される最小クラスターが必要になります。ここで、可用性を確保するためにノードは 3 つの別々のラックまたはアベイラビリティーゾーンに分散することを推奨します。OpenShift Data Foundation がワーカーノードで実行されるようにするには、ローカルストレージデバイスまたはポータブルストレージデバイスのいずれかがそれらに動的に接続される必要があります。

外部モードでデプロイされると、複数のノードで実行され、障害の発生時に利用可能なノードでの K8S による再スケジュールが可能になります。

注記

ストレージワークロードのみを実行するノードには、Red Hat OpenShift Data Foundation のサブスクリプションが必要です。ストレージワークロードに加えて他のワークロードを実行するノードには、Red Hat OpenShift Data Foundation および Red Hat OpenShift Container Platform サブスクリプションの両方が必要です。詳細は、6章サブスクリプション を参照してください。

第3章 内部ストレージサービス

Red Hat OpenShift Data Foundation サービスは、以下のインフラストラクチャーで実行されている Red Hat OpenShift Container Platform の内部で利用できます。

  • Amazon Web Services
  • ベアメタル
  • VMware vSphere
  • Microsoft Azure
  • Google Cloud [テクノロジープレビュー]
  • Red Hat Virtualization 4.4.x 以降 (IPI)
  • Red Hat OpenStack 13 以降 (IPI) [テクノロジープレビュー]
  • IBM Power
  • IBM Z および LinuxONE

内部クラスターリソースを作成すると、OpenShift Data Foundation ベースサービスの内部プロビジョニングが実行され、追加のストレージクラスがアプリケーションで使用可能になります。

第4章 外部ストレージサービス

Red Hat OpenShift Data Foundation は、IBM Flash Systems を使用するか、外部の Red Hat Ceph Storage クラスターからのサービスを以下のプラットフォームで実行されているOpenShift Container Platform クラスターを介して利用できるようにすることができます。

  • VMware vSphere
  • ベアメタル
  • Red Hat OpenStack Platform (テクノロジープレビュー)

OpenShift Data Foundation Operator は、外部サービスに対する永続ボリュームおよびオブジェクトバケット要求を満たすためにサービスを作成し、管理します。外部クラスターは、OpenShift Container Platform で実行されているアプリケーションのブロック、ファイル、およびオブジェクトストレージクラスを提供できます。外部クラスターは Operator によってデプロイされず、管理されません。

第5章 セキュリティーに関する考慮事項

5.1. FIPS-140-2

FIPS-140-2 (Federal Information Processing Standard Publication 140-2) は、暗号モジュールの使用についての一連のセキュリティー要件を定義する標準です。この標準は、米国の政府機関や請負業者に対して法律で義務付けられており、他の国際標準および業界固有の標準でも参照されています。

Red Hat OpenShift Data Foundation は、Red Hat Enterprise Linux OS/CoreOS (RHCOS) によって配信される FIPS で検証済みの暗号モジュールを使用するようになりました。

現時点で、暗号モジュールは Cryptographic Module Validation Program (CMVP) によって処理され、それらの状態は Modules in Process List で確認できます。最新の情報は、ナレッジベースのアーティクルを参照してください。

注記

OpenShift Data Foundation をインストールする前に、FIPS モードを OpenShift Container Platform で有効にする必要があります。OpenShift Container Platform は、この機能に対して RHEL 7 での OpenShift Data Foundation デプロイメントがサポートされていないため、RHCOS ノードで実行される必要があります。

詳細は、「installing a cluster in FIPS mode」および「support for FIPS cryptography」を参照してください。

5.2. プロキシー環境

プロキシー環境は、インターネットへの直接アクセスを拒否し、代わりに利用可能な HTTP または HTTPS プロキシーを提供する実稼働環境です。Red Hat Openshift Container Platform は、既存クラスターのプロキシーオブジェクトを変更するか、または新規クラスターについて install-config.yaml ファイルでプロキシーを設定してプロキシーを使用するように設定されます。

Red Hat では、OpenShift Container Platform がクラスター全体のプリキシーの設定に応じて設定されている場合に、プロキシー環境での Openshift Data Foundation のデプロイメントをサポートします。

5.3. データ暗号化オプション

暗号化により、データをエンコードし、必要な暗号化キーなしに読み取れないようにすることができます。このメカニズムは、物理メディアが手元から離れるような物理的なセキュリティー違反の発生時にもデータの機密性を保護できます。PV ごとの暗号化は、同じ Open Shift Container Platform クラスター内の他の namespace からのアクセス保護も提供します。データはディスクに書き込まれる際に暗号化され、ディスクから読み取られる際に復号化されます。暗号化されたデータを使用すると、パフォーマンスに小規模なペナルティーのみが発生する可能性があります。

暗号化は、Red Hat OpenShift Data Foundation 4.6 以降を使用してデプロイされる新規クラスターでのみサポートされます。外部鍵管理システム (KMS) を使用していない既存の暗号化されたクラスターは、外部 KMS を使用するように移行できません。

現時点で、HashiCorp Vault はクラスター全体の暗号化および永続ボリュームの暗号化で唯一サポートされている KMS です。OpenShift Data Foundation 4.7.0 および 4.7.1 では、HashiCorp Vault Key/Value (KV) シークレットエンジン API (バージョン 1) のみがサポートされます。OpenShift Data Foundation 4.7.2 以降では、HashiCorp Vault KV シークレットエンジン API (バージョン 1 および 2) がサポートされるようになりました。

重要
  • KMS は、永続ボリューム (PV) 暗号化に必要であり、クラスター全体の暗号化にはオプションです。
  • Red Hat はテクノロジーパートナーと連携して、本書をお客様へのサービスとして提供します。ただし、Red Hat では、Hashicorp 製品のサポートを提供していません。この製品に関するテクニカルサポートについては、Hashicorp にお問い合わせください。

5.3.1. クラスター全体の暗号化

Red Hat OpenShift Data Foundation は、ストレージクラスター内のディスクおよび Multicloud Object Gateway 操作のすべてに対して、クラスター全体の暗号化 (保存時の暗号化、encryption-at-rest) をサポートします。OpenShift Data Foundation は、キーのサイズが 512 ビットの Linux Unified Key System (LUKS) バージョン 2 ベースの暗号化と、各デバイスが異なる暗号化キーを持つ aes-xts-plain64 暗号を使用します。このキーは Kubernetes シークレットまたは外部 KMS を使用して保存されます。どちらのメソッドでも相互排他的であり、メソッド間の移行はできません。

暗号化はデフォルトでは無効にされます。デプロイメント時にクラスターの暗号化を有効にできます。詳細は、デプロイメントガイドを参照してください。

クラスター全体の暗号化は、キー管理システム (KMS) なしの Open Shift Data Foundation 4.6 でサポートされますが、Open Shift Data Foundation 4.7 以降では、KMS の有無にかかわらずサポートされます。

現時点で、HashiCorp Vault は唯一サポートされている KMS です。OpenShift Data Foundation 4.7.0 および 4.7.1 では、HashiCorp Vault KV シークレットエンジン API (バージョン 1) のみがサポートされます。OpenShift Data Foundation 4.7.2 以降では、HashiCorp Vault KV シークレットエンジン API (バージョン 1 および 2) がサポートされるようになりました。

重要

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

5.3.2. ストレージクラスの暗号化

デバイスの暗号化キーを保存するために外部の鍵管理システム (KMS) を使用して、ストレージクラスの暗号化で永続ボリューム (ブロックのみ) を暗号化できます。永続ボリュームの暗号化は RADOS Block Device (RBD) 永続ボリュームでのみ利用できます。永続ボリュームの暗号化を使用したストレージクラスの作成方法について参照してください。

ストレージクラスの暗号化は OpenShift Data Foundation 4.7 以降でサポートされます。

第6章 サブスクリプション

6.1. サブスクリプションのオファリング

Red Hat OpenShift Data Foundation のサブスクリプションは、OpenShift Container Platform と同様に「コアのペア」をベースとして提供されます。Red Hat OpenShift Data Foundation 2 コアサブスクリプションは、OpenShift Container Platform が実行されるシステムの CPU 上の論理コア数をベースとしています。

以下の点は、OpenShift Container Platform と同様です。

  • OpenShift Data Foundation サブスクリプションは、大規模なホストに対応するようにスタック可能です。
  • コアは、必要に応じて多数の仮想マシン (VM) に分散できます。たとえば、10 の 2 コアのサブスクリプションは 20 コアを提供し、IBM Power の場合、SMT レベル 8 の 2 コアのサブスクリプションは、任意の数の仮想マシンで使用できる 2 コアまたは 16 vCPU を提供します。
  • OpenShift Data Foundation サブスクリプションは、Premium または Standard サポートで利用できます。

6.2. 障害復旧サブスクリプション

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

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

ソースまたは宛先としてアクティブレプリケーションに参加している PV を含む Red Hat OpenShift Data Foundation クラスターには、OpenShift Data Foundation Advanced Subscription が必要です。このサブスクリプションは、ソースクラスターと宛先クラスターの両方でアクティブにする必要があります。

6.3. コア対 vCPU およびハイパースレッディング

現時点で特定のシステムが 1 つまたは複数のコアを消費するかどうかについての決定は、そのシステムでハイパースレッディング機能を利用できるかどうかによって異なります。ハイパースレッディングは Intel CPU のみの機能です。Red Hat カスタマーポータルにアクセスし、特定のシステムがハイパースレッディングをサポートしているかどうかを判断します。

ハイパースレッディングが有効にされており、1 つのハイパースレッドが 1 つの利用可能なシステムコアに等しいシステムの場合、コアの計算 は 2 コア対 4 vCPU の比率になります。したがって、2 コアのサブスクリプションは、ハイパースレッドシステムの 4 vCPU に対応します。大規模な仮想マシン (VM) には、4 サブスクリプションコアに相当する 8 vCPU がある場合があります。サブスクリプションは 2 コア単位で提供されるため、4 コアまたは 8 vCPU に対応するには 2 つの 2 コアサブスクリプションが必要になります。

ハイパースレッディングが有効にされていない場合や、表示される各システムのコアが基礎となる物理コアに直接相関する場合、コアの計算は 2 コア対 2 vCPU の比率になります。

6.3.1. IBM Power のコア対 vCPU および同時マルチスレッド(SMT)

現時点で特定のシステムが 1 つまたは複数のコアを消費するかどうかについての決定は、同時マルチスレッド (SMT) のレベルによって異なります。IBM Power は、以下の表にあるように、各コアに同時マルチスレッドレベル 1、2、4、または 8 を提供します。これは、vCPU の数に対応します。

表6.1 さまざまな SMT レベルとそれに対応する vCPU

SMT レベルSMT=1SMT=2SMT=4SMT=8

1 コア

# vCPU=1

# vCPU=2

# vCPU=4

# vCPU=8

2 コア

# vCPU=2

# vCPU=4

# vCPU=8

# vCPU=16

4 コア

# vCPU=4

# vCPU=8

# vCPU=16

# vCPU=32

SMT が設定されたシステムでは、サブスクリプションに必要なコア数の計算は SMT レベルによって異なります。したがって、2 コアのサブスクリプションは、上記の表に示すように SMT レベル 1 の 2 vCPU に対応し、SMT レベル 2 の 4 vCPU に、SMT レベル 4 では 8 vCPU に、SMT レベル 8 では 16 vCPU に対応します。大規模な仮想マシン (VM) には 16 vCPU が含まれる場合があります。この場合、SMT レベル 8 では SMT レベルで vCPU の # を除算した計算により 2 コアサブスクリプションが必要になります (SMT-8 の場合: 16 vCPU/8 = 2)。サブスクリプションは 2 コア単位で提供されるため、これらの 2 コアまたは 16 vCPU に対応するには 1 つの 2 コアサブスクリプションが必要になります。

6.4. コアの分割

奇数のコアを必要とするシステムの場合でも、2 コアのサブスクリプションを使用する必要があります。たとえば、1 コアのみを必要とするように計算されたシステムは、登録およびサブスクライブ後に 2 コアのサブスクリプションすべてを使用します。

2 vCPU を持つ単一の仮想マシン (VM) がハイパースレッディング機能を使用し、1 vCPU が計算される場合、2 コアサブスクリプションが必要になります。単一の 2 コアサブスクリプションは、ハイパースレッディングを使用する 2 vCPU を持つ 2 仮想マシン間で分割することはできません。詳細は、「Cores versus vCPUs and hyperthreading」のセクションを参照してください。

そのため、仮想インスタンスは偶数のコアを必要とするようにサイズ設定することが推奨されます。

6.4.1. IBM Power の共有プロセッサープール

IBM Power には、共有プロセッサープールの概念があります。共用プロセッサープール内のプロセッサーは、クラスター内のノード間で共有できます。Red Hat OpenShift Data Foundation に必要な集約コンピュート容量はコアのペアの倍数である必要があります。

6.5. サブスクリプションの要件

Red Hat OpenShift Data Foundation コンポーネントは、Red Hat CoreOS (RHCOS) または Red Hat Enterprise Linux (RHEL) 8.4 のいずれかをホストのオペレーティングシステムとして使用できる OpenShift Container Platform ワーカーまたはインフラストラクチャーノードのいずれかで実行できます。RHEL 7 は非推奨になりました。OpenShift Data Foundation サブスクリプションは、すべての OpenShift Container Platform をサブスクライブするコアに 1:1 の割合で必要です。

インフラストラクチャーノードを使用する場合、OpenShift Container Platform または OpenShift Data Foundation サブスクリプションが必要でなくても、OpenShift Data Foundation のすべての OpenShift ワーカーノードコアをサブスクライブするルールが適用されます。ラベルを使用して、ノードがワーカーノードまたはインフラストラクチャーノードであるかどうか示すことができます。

詳細は、『ストレージリソースの管理および割り当て』ガイドの「Red Hat OpenShift Data Foundation に専用のワーカーノードを使用する方法」を参照してください。

第7章 インフラストラクチャーの要件

7.1. プラットフォーム要件

Red Hat OpenShift Data Foundation 4.9 は、OpenShift Container Platform バージョン 4.9 およびその次のマイナーバージョンでのみサポートされます。

以前のバージョンの Red Hat OpenShift Data Foundation に関するバグ修正は、バグ修正バージョンとしてリリースされます。詳細は、「Red Hat OpenShift Container Platform ライフサイクルポリシー」を参照してください。

外部クラスターのサブスクリプション要件については、この Red Hat ナレッジベースアーティクルを参照してください。

サポートされているプラットフォームのバージョンについての詳細の一覧は、「Red Hat OpenShift Data Foundation and Red Hat OpenShift Container Platform interoperability matrix」を参照してください。

7.1.1. Amazon EC2

内部 Red Hat OpenShift Data Foundation クラスターのみをサポートします。

内部クラスターは、ストレージデバイスの要件を満たし、以下を提供するストレージクラスがなればなりません。

  • EBS ストレージ (aws-ebs プロビジョナー経由)

7.1.2. ベアメタル

内部クラスターをサポートし、外部クラスターの使用をサポートします。

内部クラスターは、ストレージデバイスの要件を満たし、ローカルストレージ Operator 経由でローカル SSD (NVMe/SATA/SAS、SAN) を提供するストレージクラスがなければなりません。

7.1.3. VMware vSphere

内部クラスターをサポートし、外部クラスターの使用をサポートします。

推奨されるバージョン:

  • vSphere 6.7、Update 2 以降
  • vSphere 7.0 以降

詳細は、「 VMware vSphere インフラストラクチャーの要件 」を参照してください。

注記

VMware ESXi がデバイスをフラッシュとして認識しない場合は、フラッシュデバイスとしてマークします。Red Hat OpenShift Data Foundation デプロイメントの前に、「 ストレージデバイスを Flash としてマーキング」を参照して ください。

さらに、内部クラスターはストレージデバイスの要件を満たし、以下のいずれかを提供するストレージクラスがなければなりません。

  • vSAN または VMFS データストア (vsphere-volume プロビジョナー経由)
  • VMDK、RDM、または DirectPath ストレージデバイス (Local Storage Operator 経由)

7.1.4. Microsoft Azure

内部 Red Hat OpenShift Data Foundation クラスターのみをサポートします。

内部クラスターは、ストレージデバイスの要件を満たし、以下を提供するストレージクラスがなればなりません。

  • Azure ディスク (azure-disk プロビジョナー経由)

7.1.5. Google Cloud [テクノロジープレビュー]

内部 Red Hat OpenShift Data Foundation クラスターのみをサポートします。

内部クラスターは、ストレージデバイスの要件を満たし、以下を提供するストレージクラスがなればなりません。

  • GCE Persistent Disk (gce-pd プロビジョナー経由)

7.1.6. Red Hat Virtualization プラットフォーム

内部 Red Hat OpenShift Data Foundation クラスターのみをサポートします。

内部クラスターは、ストレージデバイスの要件を満たし、ローカルストレージ Operator 経由でローカル SSD (NVMe/SATA/SAS、SAN) を提供するストレージクラスがなければなりません。

7.1.7. Red Hat OpenStack Platform [テクノロジープレビュー]

内部 Red Hat OpenShift Data Foundation クラスターをサポートし、外部クラスターを使用します。

内部クラスターは、ストレージデバイスの要件を満たし、以下を提供するストレージクラスがなればなりません。

  • Cinder プロビジョナーを使用した標準ディスク

7.1.8. IBM Power

内部 Red Hat OpenShift Data Foundation クラスターのみをサポートします。

内部クラスターは、ストレージデバイスの要件を満たし、ローカルストレージ Operator 経由でローカル SSD (NVMe/SATA/SAS、SAN) を提供するストレージクラスがなければなりません。

7.1.9. IBM Z および LinuxONE

内部 Red Hat OpenShift Data Foundation クラスターのみをサポートします。

内部クラスターは、ストレージデバイスの要件を満たし、ローカルストレージ Operator 経由でローカル SSD (NVMe/SATA/SAS、SAN) を提供するストレージクラスがなければなりません。

7.2. 外部モード要件

7.2.1. Red Hat Ceph Storage

Red Hat Ceph Storage (RHCS) バージョン 4.2z1 以降が必要です。サポートされるバージョンについては、この Red Hat Ceph Storage リリースおよび対応する Ceph パッケージバージョンについてのナレッジベースのアーティクルを参照してください。

RHCS 4 クラスターのインストール方法は、『 インストールガイド』を参照してください。

7.2.2. IBM FlashSystem

IBM FlashSystem を他のプロバイダーのプラグ可能な外部ストレージとして使用するには、最初に OpenShift Data Foundation をデプロイする必要があります。これは、IBM FlashSystem ストレージクラスをバッキングストレージとして使用します。

サポートされている最新の FlashSystem 製品およびバージョンについては、IBM ドキュメンテーション の Spectrum Virtualize ファミリー製品ドキュメンテーション内のリファレンス> Red Hat OpenShift Data Foundation サポートの要約を参照してください。

OpenShift Data Foundation のデプロイ方法については、「 Creating an OpenShift Data Foundation Cluster for external IBM FlashSystem storage 」を参照してください。

7.3. リソース要件

Red Hat OpenShift Data Foundation サービスは、ベースサービスの初期セットで構成され、追加のデバイスセットで拡張できます。これらすべての Red Hat OpenShift Data Foundation サービス Pod は、リソース要件に応じて OpenShift Container Platform ノードの kubernetes によってスケジュールされます。クラスターを (障害ドメインごとに 1 ノード) 3 の倍数に拡張する方法は、Pod の配置ルールを簡単に満たす方法です。

重要

これらの要件は OpenShift Data Foundation サービスにのみ関連しており、これらのノードで実行されている他のサービス、Operator、またはワークロードには関係ありません。

表7.1 Red Hat OpenShift Data Foundation でのみ利用可能なリソース要件を集約します

デプロイメントモードベースサービス追加のデバイスセット

内部

  • 30 個の CPU (論理)
  • 72 GiB メモリー
  • 3 ストレージデバイス
  • 6 個の CPU (論理)
  • 15 GiB メモリー
  • 3 ストレージデバイス

外部

  • 4 個の CPU (論理)
  • 16 GiB メモリー

該当なし

例: 単一デバイスセットを持つ内部モードデプロイメントの 3 ノードクラスターの場合、最小の 3 x 10 = 30 ユニットの CPU が必要です。

詳細は、6章サブスクリプション および「CPU ユニット」を参照してください。

Red Hat OpenShift Data Foundation クラスターの設計に関する追加のガイダンスは、「ODF Sizing Tool」を参照してください。

CPU ユニット

本セクションでは、1 CPU ユニットは Kubernetes コンセプトの 1 CPU ユニットにマップされます。

  • CPU の 1 ユニットは、ハイパースレッディングされていない CPU の 1 コアに相当します。
  • CPU の 2 ユニットは、ハイパースレッディングされている CPU の 1 コアに相当します。
  • Red Hat OpenShift Data Foundation コアベースのサブスクリプションは常にペア (2 コア) で提供されます。

表7.2 IBM Power の最小リソース要件の集約

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

内部

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

外部

  • 該当なし

例: 内部接続デバイスモードのデプロイメントの 3 ノードクラスターの場合、最小の 3 x 16 = 48 ユニットの CPU、および 3 x 64 = 192 GB が必要です。

7.3.1. IBM Z および LinuxONE インフラストラクチャーのリソース要件

Red Hat OpenShift Data Foundation サービスは、ベースサービスの初期セットで構成され、追加のデバイスセットで拡張できます。

これらすべての Red Hat OpenShift Data Foundation サービス Pod は、リソース要件に応じて OpenShift Container Platform ノードの kubernetes によってスケジュールされます。

クラスターを (障害ドメインごとに 1 ノード) 3 の倍数に拡張する方法は、Pod の配置ルールを簡単に満たす方法です。

表7.3 Red Hat OpenShift Data Foundation でのみ利用可能なリソース要件を集約(IBM Z および LinuxONE)

デプロイメントモードベースサービス追加のデバイスセットIBM Z および LinuxONE の最小ハードウェア要件

内部

  • 30 個の CPU (論理)

    • それぞれ 10 個の CPU (論理) を備えた 3 つのノード
  • 72 GiB メモリー
  • 3 ストレージデバイス
  • 6 個の CPU (論理)
  • 15 GiB メモリー
  • 3 ストレージデバイス

1 IFL

外部

  • 4 個の CPU (論理)
  • 16 GiB メモリー

該当なし

該当なし

CPU
ハイパーバイザー、IBM z/VM、カーネル仮想マシン (KVM)、またはその両方で定義されている仮想コアの数です。
IFL(Linux 向けの統合機能)
IBM Z および LinuxONE の物理コアです。

最小システム環境

  • 1 つの論理パーティション (LPAR) で最小クラスターを動作させるには、6 つの IFL の上に追加の IFL が必要です。OpenShift Container Platform は、これらの IFL を使用します。

7.3.2. デプロイメントリソースの最小要件 [テクノロジープレビュー]

OpenShift Data Foundation クラスターは、標準のデプロイメントリソース要件を満たしていない場合に、最小の設定でデプロイされます。

重要

これらの要件は OpenShift Data Foundation サービスにのみ関連しており、これらのノードで実行されている他のサービス、Operator、またはワークロードには関係ありません。

表7.4 OpenShift Data Foundation のみのリソース要件の集約

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

内部

  • 24 個の CPU (論理)
  • 72 GiB メモリー
  • 3 ストレージデバイス

デバイスセットを追加する場合は、最小デプロイメントを標準デプロイメントに変換することが推奨されます。

重要

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

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

7.3.3. コンパクトなデプロイメントリソース要件

Red Hat OpenShift Data Foundation は、3 ノードの OpenShift のコンパクトなベアメタルクラスターにインストールできます。ここでは、すべてのワークロードが 3 つの強力なマスターノードで実行されます。ワーカーノードまたはストレージノードは含まれません。

重要

これらの要件は OpenShift Data Foundation サービスにのみ関連しており、これらのノードで実行されている他のサービス、Operator、またはワークロードには関係ありません。

表7.5 OpenShift Data Foundation のみのリソース要件の集約

デプロイメントモードベースサービス追加のデバイスセット

内部

  • 24 個の CPU (論理)
  • 72 GiB メモリー
  • 3 ストレージデバイス
  • 6 個の CPU (論理)
  • 15 GiB メモリー
  • 3 ストレージデバイス

コンパクトのベアメタルクラスターで OpenShift Container Platform を設定する場合は、「Configuring a three-node cluster」および「Delivering a Three-node Architecture for Edge Deployments」を参照してください。

7.3.4. MCG のみのデプロイメントのリソース要件

Multicloud Object Gateway (MCG) コンポーネントのみを使用してデプロイされた OpenShift Data Foundation クラスターは、デプロイメントに柔軟性を提供し、リソース消費を削減するのに役立ちます。

表7.6 MCG のみのデプロイメントの総リソース要件

デプロイメントモードコアデータベース (DB)エンドポイント

内部

  • 1 CPU
  • 4 GiB メモリー
  • 0.5 CPU
  • 4 GiB メモリー
  • 1 CPU
  • 2 GiB メモリー
注記

デフォルトオートスケールは 1〜2 です。

7.4. Pod の配置ルール

Kubernetes は、宣言型の配置ルールに基づいて Pod の配置を行います。内部クラスターの Red Hat OpenShift Data Foundation ベースサービスの配置ルールは、以下のように要約できます。

  • ノードには cluster.ocs.openshift.io/openshift-storage キーでラベルが付けられます。
  • ノードは、擬似障害ドメインに分類されます (何も存在しない場合)。
  • 高可用性が必要なコンポーネントは障害ドメインに分散されます。
  • ストレージデバイスはそれぞれの障害ドメインでアクセスできる必要があります。

これにより、少なくとも 3 つのノードがあり、既存のトポロジーラベルが存在する場合にノードは 3 つの異なるラックまたはゾーン障害ドメインにある必要があります。

追加のデバイスセットについては、3 つの障害ドメインのそれぞれにストレージデバイスがあり、Pod が消費するのに十分なリソースが必要になります。手動の配置ルールはデフォルトの配置ルールを上書きするのに使用できますが、通常この方法はベアメタルのデプロイメントにのみ適しています。

7.5. ストレージデバイスの要件

このセクションでは、内部モードのデプロイメントおよびアップグレードの計画時に考慮できる各種のストレージ容量の要件について説明します。通常、ノードごとに 9 以下のデバイスが推奨されます。この推奨事項により、ノードがクラウドプロバイダーの動的ストレージデバイスの割り当て制限下にあり、ローカルストレージデバイスに関連してノードに障害が発生した後の復旧時間を制限することができます。クラスターを (障害ドメインごとに 1 ノード) 3 の倍数に拡張する方法は、Pod の配置ルールを簡単に満たす方法です。

注記

ストレージ容量は、インストール時に選択した容量の増分値でのみ拡張できます。

7.5.1. 動的ストレージデバイス

Red Hat OpenShift Data Foundation では、動的ストレージデバイスサイズの要求サイズとして 0.5 TiB、2 TiB または 4 TiB の容量を選択できます。ノードごとに実行できる動的ストレージデバイスの数は、ノードサイズ、基礎となるプロビジョナー制限、および リソース要件の関数です。

7.5.2. ローカルストレージデバイス

ローカルストレージのデプロイメントの場合、4 TiB 以下のディスクサイズを使用でき、すべてのディスクが同じサイズおよび種類である必要があります。ノードごとに実行できるローカルストレージデバイスの数は、ノードのサイズとリソース要件の関数です。クラスターを (障害ドメインごとに 1 ノード) 3 の倍数に拡張する方法は、Pod の配置ルールを簡単に満たす方法です。

注記

ディスクのパーティション設定はサポートされません。

7.5.3. 容量のプランニング

使用する前に、利用可能なストレージ容量を必ず確保するようにしてください。利用可能なストレージ容量が完全に使い切られる場合はリカバリーが難しく、単に容量を追加したり、コンテンツを削除したり、移行したりするよりも多くの介入が必要になります。

容量アラートは、クラスターストレージ容量が合計容量の 75% (ほぼ一杯) および 85% (一杯) になると発行されます。容量についての警告に常に迅速に対応し、ストレージを定期的に確認して、ストレージ領域が不足しないようにします。75% (ほぼフル) に達したら、スペースを解放するか、クラスターを拡張します。85% (フル) アラートに達すると、ストレージ領域が完全に不足していて、標準コマンドを使用して領域を解放できないことが示唆されます。この時点で、Red Hat カスタマーポータルにお問い合わせください。

以下の表は、動的なストレージデバイスを持つ Red Hat OpenShift Data Foundation のノードの設定例を示しています。

表7.7 3 つのノードで構成される初期設定の例

ストレージデバイスのサイズノードあたりのストレージデバイス合計容量利用可能なストレージ容量

0.5 TiB

1

1.5 TiB

0.5 TiB

2 TiB

1

6 TiB

2 TiB

4 TiB

1

12 TiB

4 TiB

表7.8 30 ノード (N) で拡張された設定の例

ストレージデバイスのサイズ (D)ノードごとのストレージデバイス (M)合計容量 (D * M * N)使用可能なストレージ容量 (D*M*N/3)

0.5 TiB

3

45 TiB

15 TiB

2 TiB

6

360 TiB

120 TiB

4 TiB

9

1080 TiB

360 TiB

7.6. マルチネットワークプラグイン(Multus)のサポート [テクノロジープレビュー]

デフォルトで、Red Hat OpenShift Data Foundation は Red Hat OpenShift Software Defined Network (SDN) を使用するように設定されています。このデフォルト設定では、SDN には以下のトラフィックタイプがあります。

  • Pod 対 Pod のトラフィック
  • OpenShift Data Foundation パブリックネットワークトラフィックとして知られる OpenShift Data Foundation トラフィックへの Pod
  • OpenShift Data Foundation クラスターネットワークトラフィックとして知られる OpenShift Data Foundation のレプリケーションおよびリバランス

ただし、OpenShift Data Foundation 4.8 以降では、テクノロジープレビューとして、さまざまな種類のネットワークトラフィックを分離することで、Multus を使用してセキュリティーやパフォーマンスを強化する機能がサポートされます。

重要

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

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

7.6.1. 複数ネットワークについて

Kubernetes では、コンテナーネットワークは Container Network Interface (CNI) を実装するネットワークプラグインに委任されます。

OpenShift Container Platform は、Multus CNI プラグインを使用して CNI プラグインのチェーンを許可します。クラスターのインストール時に、デフォルト の Pod ネットワークを設定します。デフォルトのネットワークは、クラスターのすべての通常のネットワークトラフィックを処理します。利用可能な CNI プラグインに基づいて 追加のネットワーク を定義し、1 つまたは複数のネットワークを Pod に割り当てることができます。必要に応じて、クラスターの複数のネットワークを追加で定義することができます。これは、スイッチまたはルーティングなどのネットワーク機能を提供する Pod を設定する場合に柔軟性を実現します。

7.6.1.1. 追加ネットワークの使用シナリオ

データプレーンとコントロールプレーンの分離など、ネットワークの分離が必要な状況で追加のネットワークを使用することができます。トラフィックの分離は、以下のようなパフォーマンスおよびセキュリティー関連の理由で必要になります。

パフォーマンス
各プレーンのトラフィック量を管理するために、2 つの異なるプレーンにトラフィックを送信できます。
セキュリティー
機密トラフィックは、セキュリティー上の考慮に基づいて管理されているネットワークに送信でき、テナントまたはカスタマー間で共有できないプライベートを分離することができます。

クラスターのすべての Pod はクラスター全体のデフォルトネットワークを依然として使用し、クラスター全体での接続性を維持します。すべての Pod には、クラスター全体の Pod ネットワークに割り当てられる eth0 インターフェースがあります。Pod のインターフェースは、oc exec -it <pod_name> -- ip a コマンドを使用して表示できます。Multus CNI を使用するネットワークを追加する場合、それらの名前は net1net2、…​、 netN になります。

追加のネットワークを Pod に割り当てるには、インターフェースの割り当て方法を定義する設定を作成する必要があります。それぞれのインターフェースは、NetworkAttachmentDefinition カスタムリソース (CR) を使用して指定します。これらの CR のそれぞれにある CNI 設定は、インターフェースの作成方法を定義します。

7.6.2. Multus を使用したストレージトラフィックの分離

Multus を使用するには、OpenShift Data Foundation クラスターをデプロイする前に、後にクラスターにアタッチされる Network attachment definition (NAD) を作成する必要があります。詳細は以下を参照してください。

Multus を使用すると、ハードウェアの設定や VMWare インスタンスのネットワーク設定に応じて、以下の設定が可能です。

  • デュアルネットワークインターフェースを持つノードの推奨設定

    • 分離されたストレージトラフィック

      • OpenShift SDN に 1 つのインターフェースを設定 (Pod 対 Pod のトラフィック)
      • すべての OpenShift Data Foundation トラフィックに対して 1 つのインターフェースを設定
  • トリプルネットワークインターフェースを持つノードの推奨設定

    • 完全なトラフィック分離

      • OpenShift SDN に 1 つのインターフェースを設定 (Pod 対 Pod のトラフィック)
      • OpenShift Data Foundation トラフィック (OpenShift Data Foundation public トラフィック) へのすべての Pod に 1 つのインターフェースを設定します。
      • すべての OpenShift Data Foundation レプリケーションおよびリバランストラフィックに 1 つのインターフェースを設定 (OpenShift Data Foundation クラスタートラフィック)

第8章 障害復旧

障害復旧 (DR) は、中断または障害が発生する場合に、組織がビジネスクリティカルな機能または通常の運用を回復し、再開するのに役立ちます。

Red Hat OpenShift Data Foundation は、2 つのオプションを提供します。

  • Red Hat Advanced Cluster Management (RHACM)を搭載する Regional-DR
  • Metro-DR (Stretched Cluster - Arbiter)

RHACM を搭載する Regional-DR

Regional-DR ソリューションは、地域の障害発生時に自動化された "one-click" リカバリーを提供します。保護されたアプリケーションは、別のリージョンで利用可能な OpenShift Data Foundation クラスターのある指定された OpenShift Container Platform に自動的に再デプロイされます。本リリースの Regional DR は、2 つの異なるリージョンまたはデータセンターにある 2 つのマネージドクラスターでの 2 方向のレプリケーションをサポートします。

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

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

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

重要

これは開発者プレビュー機能であり、開発者プレビューのサポート制限の対象となります。開発者プレビューリリースは、実稼働環境で実行することは意図されておらず、Red Hat カスタマーポータルのケース管理システムではサポートされません。開発者のプレビュー機能に関してサポートが必要な場合には、ocs-devpreview@redhat.com メーリングリストに連絡してください。Red Hat Development Team のメンバーが稼働状況とスケジュールに応じて可能な限り迅速に対応します。

Metro-DR (Stretched Cluster - Arbiter)

この例では、3 番目のゾーンを Arbiter の場所とした上で、単一クラスターが 2 つのゾーンに展開されます。これはテクノロジープレビュー機能であり、現時点では OpenShift Container Platform オンプレミスでのデプロイメント用とされています。

注記

このソリューションは、メインのオンプレミスデータセンターにある 2 つのゾーンの場所間の遅延が 4 ミリ秒のラウンドトリップ時間 (RTT) を超えない場合に展開するように設計されています。より高いレイテンシーでデプロイする予定がある場合は、Red Hat カスタマーサポートにお問い合わせください。

Arbiter ストレッチクラスターを使用するには、以下を実行します。

  • 3 つのゾーンには、最低でも 5 つのノードが必要です。ここでは、以下のようになります。

    • データセンターゾーンごとにゾーンごとに 2 つのノードが使用され、arbiter ゾーンには 1 つのノードを持つ 1 つの追加ゾーンが使用されます(arbiter はマスターノード上にある場合があります)。
  • すべてのノードには、クラスターの作成前にゾーンのラベルを手動で付ける必要があります。

    たとえば、ゾーンには以下のようにラベル付けできます。

    • topology.kubernetes.io/zone=arbiter (マスターまたはワーカーノード)
    • topology.kubernetes.io/zone=datacenter1 (2 つ以上のワーカーノード)
    • topology.kubernetes.io/zone=datacenter2 (2 つ以上のワーカーノード)

詳細は以下を参照してください。

重要

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

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

第9章 非接続環境

非接続環境は、Operator Lifecycle Manager (OLM) がインターネット接続が必要なデフォルトの Operator Hub およびイメージレジストリーにアクセスできないネットワークが制限された環境です。

Red Hat は、OpenShift Container Platform がネットワークが制限された環境にインストールされる非接続環境での OpenShift Data Foundation のデプロイメントをサポートします。

切断された環境に OpenShift Data Foundation をインストールするには、OpenShift Container Platform ドキュメントのオペレーターガイドの制限付きネットワークでの Operator Lifecycle Manager の使用 の章の手順を参照してください。

注記

OpenShift Data Foundation をネットワークが制限された環境でインストールする場合は、デフォルトでインターネット接続が OpenShift Container Platform で想定され、chronyd が *.rhel.pool.ntp.org サーバーを使用するように設定されるため、カスタム Network Time Protocol (NTP) 設定をノードに適用します。詳細は、Red Hat ナレッジベースの記事および「Configuring chrony time service」を参照してください。

OpenShift Data Foundation に含まれるパッケージ

redhat-operator インデックスイメージをプルーニングするときに、OpenShift Data Foundation デプロイメント用のパッケージの以下のリストを含めます。

  • ocs-operator
  • odf-operator
  • mcg-operator
  • (オプション) local-storage-operator (ローカルストレージ展開の場合のみ)
  • (オプション) odf-multicluster-orchestrator(地域の障害復旧構成の場合のみ)
重要

CatalogSource は redhat-operators として名前を付ける必要があります。

第10章 IBM Power および IBM Z インフラストラクチャーでサポートされない機能

表10.1 IBM Power および IBM Z インフラストラクチャーでサポートされない機能の一覧

機能IBM PowerIBM Z インフラストラクチャー

コンパクトなデプロイメント

Unsupported

Unsupported

動的ストレージデバイス

Unsupported

サポート対象

Metro-DR (Stretched Cluster - Arbiter)

Unsupported

Unsupported

外部モード

Unsupported

Unsupported

FIPS

Unsupported

Unsupported

プール圧縮メトリクスを表示する機能

サポート対象

Unsupported

Multicloud Object Gateway エンドポイント Pod の自動スケーリング

サポート対象

Unsupported

オーバープロビジョニングを制御するアラート

サポート対象

Unsupported

Ceph Monitor がスペースを使い果たしたときにアラート

サポート対象

Unsupported

スタンドアロンの Multicloud Object Gateway コンポーネントのデプロイメント

サポート対象

Unsupported

IBM Flashsystem などのプラグ可能な外部ストレージを可能にする拡張 OpenShift Data Foundation コントロールプレーン

Unsupported

Unsupported

IPV6 サポート

Unsupported

Unsupported

Multus

Unsupported

Unsupported

Multicloud Object Gateway バケットレプリケーション

サポート対象

Unsupported

オブジェクトデータのクォータサポート

サポート対象

Unsupported

Red Hat Advanced Cluster Management (RHACM)を搭載する Regional-DR

Unsupported

Unsupported

最小デプロイメント

Unsupported

Unsupported

第11章 次のステップ

OpenShift Data Foundation のデプロイを開始するには、OpenShift Container Platform 内で内部モードを使用するか、外部モードを使用して OpenShift Container Platform の外部で実行されているクラスターからサービスを使用できるようにします。

要件に応じて、それぞれのデプロイメントガイドを参照します。