第3章 インフラストラクチャーとシステム要件

• 事前プロビジョニング済みで稼働中の 3 ノードベアメタル RHOCP トクラスター、バージョン 4.18。

  注記

  専用のコントロールプレーンとワーカーノードを備えたマルチノード RHOCP クラスターを使用している場合は、高可用性を確保するために、3 つの専用 RHOCP コントロールプレーンノードと 3 つの専用ワーカーノードが必要です。

• クラスター内の各ワーカーノードには、次のリソースが必要です。

  • 64 GB RAM
  • 16 CPU コア

  • ルートディスク用の 120 GB NVMe または SSD と、250 GB のストレージ (NVMe または SSD を強く推奨)

    注記

    デプロイされた環境で実行される仮想マシンインスタンスのイメージ、ボリューム、およびルートディスクは、専用の外部ストレージノードでホストされます。ただし、サービスログ、データベース、メタデータは、RHOCP の永続ボリューム要求 (PVC) に保存されます。テストには最低 150 GB が必要です。

  • 2 つの物理 NIC

    注記

    3 つのコントローラーと 3 つのワーカーを持つ 6 ノードクラスターでは、ワーカーノードにのみ 2 つの物理 NIC が必要です。

  • RHEL システムのタイムゾーンと、各クラスターノードのシステムファームウェア (UEFI/BIOS) クロックの日付と時刻は UTC である必要があります。
• クラスター内の各コントロールプレーンノードには、RHOCP の 任意のプラットフォームへのインストール ガイドの クラスターインストールの最小リソース要件 で指定されているリソースが必要です。

• クラスターの永続ボリューム要求 (PVC) ストレージ:

  • サービスログ、データベース、ファイルインポート変換、メタデータ用の 150 GB の永続ボリューム (PV) プール。

    注記
    • RHOSO Pod に必要な PV プールのサイズは、RHOSO ワークロードに基づいて計画する必要があります。たとえば、Image サービスのイメージ変換 PVC は、最大のイメージと変換後のイメージ、およびその他の同時変換をホストするのに十分な大きさである必要があります。RHOSO デプロイメントで Object Storage サービス (swift) を使用する場合は、ストレージ要件についても同様の検討を行う必要があります。
    • Image サービスには PV プールが必要ですが、実際のイメージは Red Hat Ceph Storage や SAN などのイメージサービスバックエンドに保存されます。
  • 5 GB の使用可能な PV を、Galera、OVN、RabbitMQ データベースなどのコントロールプレーンサービス用のローカル SSD によって確保する必要があります。

• 仮想メディアブートを使用してベアメタルデータプレーンノードをプロビジョニングしており、ノードがプロビジョニングネットワークまたは RHOCP マシンネットワークに接続されていない場合は、ベースボード管理コントローラー (BMC) とノードが RHOCP マシンネットワークに到達するためのルートを設定する必要があります。マシンネットワークは、RHOCP クラスターノードが相互に通信するために使用するネットワークです。
• RHOCP クラスター内のすべてのノードを 1 つ以上の Network Time Protocol (NTP) サーバーと同期します。RHOCP ノードとデータプレーンノード間のクロックを同期することで、クラウド環境全体でタイミングの正確性が確保され、信頼性の高いサービス、ワークロード、タイムスタンプが実現します。

• クラスターノード間で次のポートが開いている必要があります。

  Expand

  ポート	説明
  67、68	プロビジョニングネットワークを使用する場合、クラスターノードは、ポート 67 および 68 を使用して、プロビジョニングネットワークインターフェイス経由で dnsmasq DHCP サーバーにアクセスします。
  69	プロビジョニングネットワークを使用する場合、クラスターノードはプロビジョニングネットワークインターフェイスを使用してポート 69 で TFTP サーバーと通信します。TFTP サーバーはブートストラップ仮想マシン上で実行されます。ブートストラップ仮想マシンはプロビジョナーノード上で実行されます。
  80	イメージキャッシュオプションを使用しない場合、または仮想メディアを使用する場合、プロビジョナーノードからクラスターノードに Red Hat Enterprise Linux CoreOS (RHCOS) イメージをストリーミングするには、プロビジョナーノードのポート 80 が baremetal マシンのネットワークインターフェイス上で開いている必要があります。
  123	クラスターノードは、baremetal マシンネットワークを使用して、ポート 123 の NTP サーバーにアクセスする必要があります。
  5050	Ironic Inspector API は、コントロールプレーンノード上で実行され、ポート 5050 でリッスンします。Inspector API は、ベアメタルノードのハードウェア特性に関する情報を収集するハードウェアイントロスペクションを担当します。
  5051	ポート 5050 はポート 5051 をプロキシーとして使用します。
  6180	仮想メディアを使用して TLS を使用せずにデプロイする場合、ワーカーノードのベースボード管理コントローラー (BMC) が RHCOS イメージにアクセスできるように、プロビジョナーノードとコントロールプレーンノードのポート 6180 は、baremetal マシンのネットワークインターフェイスで開いている必要があります。OpenShift Container Platform 4.13 以降、デフォルトの HTTP ポートは 6180 です。
  6183	仮想メディアを使用して TLS でデプロイする場合、ワーカーノードの BMC が RHCOS イメージにアクセスできるように、プロビジョナーノードとコントロールプレーンノードのポート 6183 は、baremetal マシンのネットワークインターフェイスで開いている必要があります。
  6190-6220	RHEL をインストールするには、OpenStackProvisionServer カスタムリソース (CR) が必要です。RHOCP マシンネットワークと RHOSO コントロールプレーンの間にファイアウォールがある場合は、ポート 6190 - 6220 を開く必要があります。OpenStackProvisionServer CR は、Red Hat OpenStack on OpenShift (RHOSO) 環境をインストールおよびデプロイする間にデフォルトで自動的に作成され、ポート範囲 6190 - 6220 を使用します。カスタム OpenStackProvisionServer CR を作成して、開く必要があるポートを制限できます。
  6385	Ironic API サーバーは、最初はブートストラップ仮想マシン上で実行され、その後はコントロールプレーンノード上で実行され、ポート 6385 でリッスンします。Ironic API を使用すると、クライアントは Ironic と対話して、新しいノードの登録、電源状態の管理、イメージのデプロイ、ハードウェアのクリーニングなどの操作を含むベアメタルノードのプロビジョニングと管理を行うことができます。
  6388	ポート 6385 はポート 6388 をプロキシーとして使用します。
  8080	TLS なしでイメージキャッシュを使用する場合、ポート 8080 がプロビジョナーノードで開いており、クラスターノードの BMC インターフェイスからアクセスできる必要があります。
  8083	TLS ありでイメージキャッシュオプションを使用する場合、ポート 8083 がプロビジョナーノードで開いており、クラスターノードの BMC インターフェイスからアクセスできる必要があります。
  9999	デフォルトでは、Ironic Python Agent (IPA) は、ポート 9999 で Ironic conductor サービスからの API 呼び出しを TCP リッスンします。IPA が実行されているベアメタルノードと Ironic conductor サービス間の通信には、このポートが使用されます。

  Show more

• ネットワークアーキテクチャーによっては、次のネットワーク機能が必要になる場合があります。

  • RHOSO 分離ネットワーク用の RHOCP ワーカーノード上の専用 NIC。
  • 必要な分離ネットワーク用の VLAN を備えたポートスイッチ。

  これらがデプロイメントに必要かどうかについては、RHOCP およびネットワーク管理者に問い合わせてください。必要な分離ネットワークの詳細は、Red Hat OpenStack Services on OpenShift のデプロイ ガイドの デフォルトの Red Hat OpenStack Platform ネットワーク を参照してください。

• RHOCP 環境が Multus CNI をサポートしている。

• RHOCP クラスターに次の Operator がインストールされている。

  • Kubernetes NMState Operator。この Operator は、nmstate インスタンスを作成して起動する必要があります。詳細は、RHOCP ネットワーク ガイドの Kubernetes NMState Operator のインストール を参照してください。

  • MetalLB Operator。この Operator は、metallb インスタンスを作成して起動する必要があります。詳細は、RHOCP ネットワーク ガイドの クラスターでの MetalLB の起動 を参照してください。

    注記

    MetalLB Operator を使用して MetalLB を起動すると、Operator がクラスター内の各ノードで speaker Pod のインスタンスを起動します。3 つの RHOCP マスターと 3 つの RHOCP ワーカーなどの拡張アーキテクチャーを使用している場合に、RHOCP マスターが ctlplane および internalapi ネットワークにアクセスできない場合は、speaker Pod を RHOCP ワーカーノードに制限する必要があります。speaker Pod の詳細は、speaker Pod の特定のノードへの限定 を参照してください。

  • cert-manager Operator。詳細は、RHOCP セキュリティーおよびコンプライアンス ガイドの cert-manager Operator for Red Hat OpenShift を参照してください。
  • Cluster Observability Operator。詳細は、Cluster Observability Operator のインストール を参照してください。
• Cluster Baremetal Operator (CBO) がプロビジョニング用に設定されている。CBO は、データプレーンデプロイメントプロセスの一部としてベアメタルノードをプロビジョニングするために必要な Bare Metal Operator (BMO) コンポーネントをデプロイします。ベアメタルプロビジョニングの計画の詳細は、ベアメタルデータプレーンノードのプロビジョニングの計画 を参照してください。

• クラスターワークステーションに次のツールがインストールされている。

  • oc コマンドラインツール。
  • podman コマンドラインツール。
• RHOCP ストレージバックエンドが設定されている。

• RHOCP ストレージクラスが定義されており、ReadWriteOnce タイプの永続ボリュームにアクセスできる。

  注記

  ローカルボリュームのみを提供する論理ボリュームマネージャー (LVM) ストレージを使用する場合、ノード障害が発生すると、接続されたボリュームは障害が発生したノードにすでに割り当てられているため、新しいノードにマウントされません。そのため、SNR Operator は LVMS PVC を使用して Pod を自動的に再スケジュールできません。したがって、ストレージに LVM を使用する場合は、ノードが正常にシャットダウンしなければボリュームをデタッチする必要があります。詳細は、正常でないノードシャットダウン後のボリュームのデタッチ を参照してください。

関連情報

• ベアメタルへのインストール ガイドの install-config.yaml ファイルの設定
• ネットワーク設定パラメーター
• ストレージ
• インストール後のストレージ設定
• MetalLB Operator のインストール
• Kubernetes NMState