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

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

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

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

モード数 (operating modalities) が増えていることからも、柔軟性が Red Hat OpenShift Data Foundation の主な特徴であることが分かります。本セクションでは、お使いの環境に最も適した方法を選択するのに役立つ情報を提供します。

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

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

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

Red Hat OpenShift Data Foundation は、FIPS 検証済みの暗号化モジュールを使用するようになりました。Red Hat Enterprise Linux OS/CoreOS(RHCOS) は、これらのモジュールを提供します。

現在、暗号化モジュール検証プログラム (CMVP) は暗号化モジュールを処理します。これらのモジュールの状態は、プロセスリストのモジュール で確認できます。最新情報は、Red Hat ナレッジベースソリューションの RHEL コア暗号化コンポーネント を参照してください。

詳細は、OpenShift Container Platform ドキュメントの インストールガイド に記載されている FIPS モードでのクラスターのインストール および FIPS 暗号化のサポートを参照してください。

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

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

暗号化を使用すると、必要な暗号化キーがなければデータを読み取ることができないようにデータをエンコードできます。このメカニズムは、物理メディアが手元から離れるような物理的なセキュリティー違反の発生時にもデータの機密性を保護できます。PV ごとの暗号化は、同じ OpenShift 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) がサポートされるようになりました。OpenShift Data Foundation 4.12 の時点で、サポートされる追加の KMS として Thales CipherTrust Manager が導入されました。

OVN-Kubernetes Container Network Interface (CNI) クラスターネットワーク上のノード間のすべてのネットワークトラフィックが暗号化されたトンネルを通過するように、IPsec を有効にする必要があります。

デフォルトでは、IPsec は無効になっています。クラスターのインストール中またはインストール後に有効化できます。クラスターのインストール後に IPsec を有効にする必要がある場合は、IPsec ESP IP ヘッダーのオーバーヘッドを考慮して、まずクラスター MTU のサイズを変更する必要があります。

IPsec 暗号化の設定方法の詳細は、OpenShift Container Platform ドキュメントの ネットワークガイド の IPsec 暗号化の設定 を参照してください。

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

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

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

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

OpenShift Data Foundation のサブスクリプションがどのように機能するかを知るには、OpenShift Data Foundation subscriptions に関するナレッジベースの記事 を参照してください。

現時点で特定のシステムが 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 の比率になります。

奇数のコアを必要とするシステムの場合でも、2 コアのサブスクリプションを使用する必要があります。たとえば、必要なコアが 1 つだけであると計算されたシステムは、登録およびサブスクライブされると、最終的に 2 コアのサブスクリプションを完全に消費することになります。

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

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

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 に専用のワーカーノードを使用する方法 を参照してください。

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

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

外部クラスターのサブスクリプション要件については、Red Hat ナレッジベースの記事 OpenShift Data Foundation Subscription Guide を参照してください。

サポートされているプラットフォームバージョンの完全なリストについては、Red Hat OpenShift Data Foundation Supportability and Interoperability Checker を参照してください。

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

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

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

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

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

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

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

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

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

ストレージノードには少なくとも 2 つのディスクが必要です。1 つはオペレーティングシステム用で、残りのディスクは OpenShift Data Foundation コンポーネント用です。

Red Hat OpenShift Data Foundation バージョン 4.12 では、IPv6 のサポートが導入されました。IPv6 はシングルスタックでのみサポートされ、IPv4 と同時に使用することはできません。Openshift Container Platform で IPv6 がオンになっている場合は、IPv6 が OpenShift Data Foundation のデフォルトの動作です。

Red Hat OpenShift Data Foundation バージョン 4.14 では、IPv6 の自動検出と設定が導入されています。IPv6 を使用するクラスターは、それに応じて自動的に設定されます。

Red Hat OpenShift Data Foundation IPv4 を使用した OpenShift Container Platform デュアルスタックは、バージョン 4.13 以降でサポートされます。Red Hat OpenShift Data Foundation IPv6 でのデュアルスタックはサポートされていません。

OpenShift Data Foundation は、ベアメタルインフラストラクチャー上でマルチネットワークプラグイン Multus を使用する機能をサポートし、さまざまなタイプのネットワークトラフィックを分離することでセキュリティーとパフォーマンスを向上させます。Multus を使用すると、OpenShift Data Foundation 専用に、ホスト上の 1 つ以上のネットワークインターフェイスを予約できますが、

Multus を使用するには、まず Multus 前提条件検証ツールを実行します。ツールの使用方法は、OpenShift Data Foundation - Multus 前提条件検証ツール を参照してください。Multus ネットワークの詳細は、複数のネットワーク を参照してください。

Metropolitan disaster recovery (Metro-DR) は、Red Hat Advanced Cluster Management for Kubernetes (RHACM)、Red Hat Ceph Storage、および OpenShift Data Foundation コンポーネントで設定され、OpenShift Container Platform クラスター全体でアプリケーションとデータのモビリティーを提供します。

このリリースの Metro-DR ソリューションは、地理的に分散しているサイト間でボリュームの永続的なデータとメタデータのレプリケーションを提供します。パブリッククラウドでは、これらはアベイラビリティーゾーンの障害からの保護に似ています。Metro-DR は、データセンターが利用できない場合でも、データを失うことなくビジネスの継続性を保証します。このソリューションには、Red Hat Advanced Cluster Management (RHACM) と OpenShift Data Foundation Advanced SKU および関連するバンドルが含まれています。

前提条件

詳細なソリューション要件は、Metro-DR 要件、arbiter を備えた Red Hat Ceph Storage ストレッチクラスターのデプロイメント要件 および RHACM 要件 を参照してください。

この例では、3 番目のゾーンを Arbiter の場所とした上で、単一クラスターが 2 つのゾーンにデプロイメントされます。この機能は現在、オンプレミスおよび同じ場所にある OpenShift Container Platform へのデプロイメントを目的としています。このソリューションは、複数のデータセンターにわたるデプロイメントには推奨できません。代わりに、複数のデータセンターにデプロイされており、ネットワークのレイテンシーが低く、データ損失がない DR ソリューションの 1 番のオプションとして、Metro-DR を検討してください。

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

詳細は、ストレッチクラスター用の OpenShift Data Foundation の設定 を参照してください。

OpenShift Data Foundation のサブスクリプションの仕組みを確認するには、OpenShift Data Foundation subscriptions に関するナレッジベースの記事 を参照してください。

Regional disaster recovery (Regional-DR) は、Red Hat Advanced Cluster Management for Kubernetes (RHACM) と OpenShift Data Foundation コンポーネントで設定され、OpenShift Container Platform クラスター全体でアプリケーションとデータのモビリティーを提供します。非同期データレプリケーションに基づいて構築されているため、データが失われる可能性がありますが、さまざまな障害に対する保護を提供します。

Red Hat OpenShift Data Foundation は、ストレージプロバイダーとして Ceph に支えられており、そのライフサイクルは Rook によって管理されており、次の機能で強化されています。

このリリースの Regional-DR は、さまざまなリージョンおよびデータセンターにデプロイメントされるマルチクラスター設定をサポートします。たとえば、2 つの異なるリージョンまたはデータセンターにある 2 つのマネージドクラスターでの 2 方向のレプリケーションをサポートします。このソリューションには、Red Hat Advanced Cluster Management (RHACM) と OpenShift Data Foundation Advanced SKU および関連するバンドルが含まれています。

前提条件

詳細なソリューション要件は、Regional-DR 要件 および RHACM 要件 を参照してください。