documentation.suse.com / SUSE Edgeドキュメント / SUSE Telco Cloudのドキュメント / 要件と前提

40 要件と前提

 

40.1 ハードウェア

 

SUSE Telco Cloudのハードウェア要件は次のとおりです。

  • 管理クラスタ: 管理クラスタには、SUSE Linux Micro、RKE2、SUSE Rancher Prime、Metal3などのコンポーネントが含まれ、管理クラスタを使用して複数のダウンストリームクラスタを管理します。管理するダウンストリームクラスタの数によっては、サーバのハードウェア要件は変わる場合があります。

    • サーバ(VMまたはベアメタル)の最小要件は次のとおりです。

      • RAM: 8GB以上(16GB以上を推奨)

      • CPU: 2個以上(4個以上を推奨)

  • ダウンストリームクラスタ: ダウンストリームクラスタは、通信ワークロードを実行するためにデプロイされるクラスタです。SR-IOV、CPUパフォーマンス最適化などの特定の通信機能を有効にするには、固有の要件が必要になります。

    • SR-IOV: VF (仮想機能)をCNF/VNFにパススルーモードでアタッチするには、NICがSR-IOVをサポートしていて、BIOSでVT-d/AMD-Viが有効化されている必要があります。

    • CPUプロセッサ: 特定の通信ワークロードを実行するには、こちらの参照表(第42章 「通信機能の設定」)に記載されているほとんどの機能を利用できるようにCPUプロセッサモデルを適応させる必要があります。

    • 仮想メディアでインストールするためのファームウェア要件:

      サーバハードウェアBMCモデル管理

      Dell製ハードウェア

      第15世代

      iDRAC9

      Supermicro製ハードウェア

      01.00.25

      Supermicro SMC - redfish

      HPE製ハードウェア

      1.50

      iLO6

40.2 ネットワーク

 

ネットワークアーキテクチャの参考として、次の図に、通信事業者環境の一般的なネットワークアーキテクチャを示します。

製品atip要件1

このネットワークアーキテクチャは次のコンポーネントに基づきます。

  • 管理ネットワーク: このネットワークは、ダウンストリームクラスタノードの管理や帯域外管理に使用されます。通常は独立した管理スイッチに接続しますが、同じサービススイッチに接続し、VLANを使ってトラフィックを分離することもできます。

  • コントロールプレーンネットワーク: このネットワークは、ダウンストリームクラスタノードと、そこで実行されているサービスとの間の通信に使用されます。また、ダウンストリームクラスタノードと外部サービス(DHCPサーバやDNSサーバなど)との間の通信にも使用されます。接続環境では、スイッチやルータでインターネット経由のトラフィックを処理できる場合もあります。

  • その他のネットワーク: 場合によっては、特定の目的に合わせてノードを他のネットワークに接続できます。

注記
注記

ダイレクトネットワークプロビジョニングワークフローを使用するには、管理クラスタがダウンストリームクラスタサーバのBaseboard Management Controller (BMC)とネットワークで接続されていて、ホストの準備とプロビジョニングを自動化できる必要があります。

40.3 ポート要件

 

SUSE Telco Cloudのデプロイメントが適切に動作するには、管理ノードおよびダウンストリームKubernetesクラスタノードにアクセス可能な複数のポートが必要です。

注記
注記

正確なリストは、デプロイされているオプションコンポーネントと選択したデプロイメントオプション(CNIプラグインなど)によって異なります。

40.3.1 管理ノード

 

次の表は、管理クラスタを実行しているノードで開いているポートをリストしています。

注記
注記

CNIプラグイン関連のポートについては、CNI固有のポート要件(40.3.3項 「CNI固有のポート要件」)を参照してください。

表 40.1: 管理ノードの受信ネットワークルール
 
プロトコルポートソース説明

TCP

22

SSHアクセスを必要とする任意のソース

管理クラスタノードへのSSHアクセス

TCP

80

外部TLS終端を行うロードバランサ/プロキシ

外部TLS終端が使用される場合はRancher UI/API

TCP

443

Rancher UI/APIへのTLSアクセスを必要とする任意のソース

Rancherエージェント、Rancher UI/API

TCP

2379

RKE2 (管理クラスタ)サーバノード

etcdクライアントポート

TCP

2380

RKE2 (管理クラスタ)サーバノード

etcdピアポート

TCP

6180

この公開ポート(非TLS)からIPA(2) ramdiskイメージをプルするように Metal3/ironicによって以前に指示された任意のBMC(1)

仮想メディアベースのブート用のIPA(2) ISOイメージを提供するIronic httpd非TLS Webサーバ。

このポートが有効な場合、機能的に同等だがTLS対応のポート(下記参照)は開かれません

TCP

6185

この公開ポート(TLS)からIPA(2) ramdiskイメージをプルするようにMetal3/ironicによって以前に指示された任意のBMC(1)


仮想メディアベースのブート用のIPA(2) ISOイメージを提供するIronic httpd TLS対応Webサーバ。

このポートが有効な場合、機能的には同等だがTLSが無効なポート(上記参照)は開かれません

TCP

6385

「登録済み」BareMetalHostインスタンスにデプロイされ実行されている任意のMetal3/ironic IPA(1) ramdiskイメージ

Ironic API

TCP

6443

任意の管理クラスタノード、(管理クラスタ)外部の任意のKubernetesクライアント

Kubernetes API

TCP

6545

任意の管理クラスタノード

OCI準拠レジストリ(Hauler)からアーティファクトをプルします

TCP

9345

RKE2サーバとエージェントノード(管理クラスタ)

ノード登録用のRKE2スーパーバイザAPI (すべてのRKE2サーバノードで開かれたポート)

TCP

10250

任意の管理クラスタノード

kubeletメトリクス

TCP/UDP/SCTP

30000～32767

spec.type: NodePortまたはspec.type: LoadBalancer Service APIオブジェクトを介してプライマリネットワークで公開されているサービスにアクセスする、(管理クラスタ)外部の任意のソース

使用可能な NodePort ポート範囲

(1) BMC: ベースボード管理コントローラ
(2) IPA: Ironic Python Agent

40.3.2 ダウンストリームノード

 

SUSE Telco Cloudでは、任意の(ダウンストリーム)サーバが実行中のダウンストリームKubernetesクラスタの一部となる前(または、それ自体が単一ノードのダウンストリームKubernetesクラスタとして実行される前)に、BaremetalHostのプロビジョニング状態のいくつかを経由する必要があります。

  • 宣言されたばかりのダウンストリームサーバのベースボード管理コントローラ(BMC)は、帯域外ネットワーク経由でアクセスできる必要があります。BMCは(管理クラスタ上で実行されているIronicサービスから)以下の初期実行手順について指示されます。

    1. BMCで提供される仮想メディア内の指定されたIPA ramdiskイメージをプルしてロードします。

    2. サーバの電源を入れます。

以下のポートは、BMCから公開される予定です(実際のハードウェアによって異なる可能性があります)。

表 40.2: ベースボード管理コントローラの受信ネットワークルール
 
プロトコルポートソース説明

TCP

80

Ironic Conductor (管理クラスタから)

Redfish APIアクセス(HTTP)

TCP

443

Ironic Conductor (管理クラスタから)

Redfish APIアクセス(HTTPS)

  • BMC 仮想メディア にロードされたIPA ramdiskイメージを使用してダウンストリームサーバイメージを起動すると、ハードウェア検査フェーズが開始されます。以下の表は、実行中のIPA ramdiskイメージによって公開されるポートをリストしています。

表 40.3: ダウンストリームノードの受信ネットワークルール - Metal3/Ironicプロビジョニングフェーズ
 
プロトコルポートソース説明

TCP

22

IPA ramdiskイメージへのSSHアクセスを必要とする任意のソース

検査対象のダウンストリームクラスタノードへのSSHアクセス

TCP

9999

Ironic Conductor (管理クラスタから)

実行中のramdiskイメージに対するIronicコマンド

  • ベアメタルホストが適切にプロビジョニングされ、ダウンストリームKubernetesクラスタに参加すると、以下のポートが公開されます。

注記
注記

CNIプラグイン関連のポートについては、CNI固有のポート要件(40.3.3項 「CNI固有のポート要件」)を参照してください。

表 40.4: ダウンストリームノードの受信ネットワークルール
 
プロトコルポートソース説明

TCP

22

SSHアクセスを必要とする任意のソース

ダウンストリームクラスタノードへのSSHアクセス

TCP

80

外部TLS終端を行うロードバランサ/プロキシ

外部TLS終端が使用される場合はRancher UI/API

TCP

443

Rancher UI/APIへのTLSアクセスを必要とする任意のソース

Rancherエージェント、Rancher UI/API

TCP

2379

RKE2 (ダウンストリームクラスタ)サーバノード

etcdクライアントポート

TCP

2380

RKE2 (ダウンストリームクラスタ)サーバノード

etcdピアポート

TCP

6443

任意のダウンストリームクラスタノード、(ダウンストリームクラスタ)外部の任意のKubernetesクライアント

Kubernetes API

TCP

9345

RKE2サーバおよびエージェントノード(ダウンストリームクラスタ)

ノード登録用のRKE2スーパーバイザAPI (すべてのRKE2サーバノードで開かれたポート)

TCP

10250

任意のダウンストリームクラスタノード

kubeletメトリクス

TCP

10255

任意のダウンストリームクラスタノード

kubelet読み取り専用アクセス

TCP/UDP/SCTP

30000～32767

spec.type: NodePortまたはspec.type: LoadBalancer Service APIオブジェクトを介してプライマリネットワークで公開されているサービスにアクセスする、(ダウンストリームクラスタ)外部の任意のソース

使用可能な NodePort ポート範囲

40.3.3 CNI固有のポート要件

 

サポートされている各CNIバリアントには、独自のポート要件が伴います。詳細については、RKE2ドキュメントの「CNI Specific Inbound Network Rules (CNI固有の受信ネットワークルール)」を参照してください。

ciliumがデフォルト/プライマリCNIプラグインとして設定されている場合、cilium-operatorワークロードが、デプロイされるKubernetesクラスタの外部にメトリクスを公開するように設定されると、以下のTCPポートが付加的に公開されます。これにより、そのKubernetesクラスタ外部で実行されている外部Prometheusサーバインスタンスが引き続きこれらのメトリクスを収集できるようになります。

注記
注記

これは、rke2-cilium Helmチャートを介してciliumをデプロイする際のデフォルトオプションです。

表 40.5: 管理/ダウンストリームノード用の受信ネットワークルール - cilium-operatorからの外部メトリクス公開が有効
 
プロトコルポートソース説明

TCP

9963

(Kubernetesクラスタ)外部のメトリクスコレクタ

cilium-operatorメトリクス公開

40.4 サービス(DHCP、DNSなど)

 

デプロイ先の環境の種類によっては、DHCP、DNSなどの外部サービスが必要な場合があります。

  • 接続環境: この場合、ノードはインターネットに接続され(L3ルーティングプロトコルを使用)、外部サービスはお客様が提供します。

  • 非接続/エアギャップ環境: この場合、ノードはインターネットにIPで接続されないため、サービスを追加して、ダイレクトネットワークプロビジョニングワークフローに必要なコンテンツをローカルにミラーリングする必要があります。

  • ファイルサーバ: ファイルサーバは、ダイレクトネットワークプロビジョニングワークフローの中で、ダウンストリームクラスタノードにプロビジョニングするOSイメージを保存するために使用されます。Metal3 HelmチャートでメディアサーバをデプロイしてOSイメージを保存できます。次のセクション(注記)を確認してください。ただし、既存のローカルWebサーバを使用することもできます。

40.5 systemdサービスの無効化

 

通信ワークロードの場合、ノード上で実行されているワークロードのパフォーマンス(レイテンシ)に影響を及ぼさないように、ノード上で実行されている一部のサービスを無効にしたり、適切に設定することが重要です。

  • rebootmgrは、システムに保留中の更新がある場合の再起動方針を設定できるサービスです。通信ワークロードでは、システムによってスケジュールされた更新がある場合、rebootmgrサービスを無効にするか正しく設定してノードの再起動を回避し、ノードで実行中のサービスへの影響を避けることが非常に重要です。

注記
注記

rebootmgrの詳細については、rebootmgrのGitHubリポジトリを参照してください。

次のコマンドを実行して、使用する方針を検証します。

cat /etc/rebootmgr.conf
[rebootmgr]
window-start=03:30
window-duration=1h30m
strategy=best-effort
lock-group=default

また、次のコマンドを実行すると無効にすることができます。

sed -i 's/strategy=best-effort/strategy=off/g' /etc/rebootmgr.conf

または、rebootmgrctlコマンドを次のように使用できます。

rebootmgrctl strategy off
注記
注記

rebootmgrの方針を設定するこの設定は、ダイレクトネットワークプロビジョニングワークフローを使用して自動化できます。詳細については、自動化されたプロビジョニングに関するドキュメント(第43章 「完全に自動化されたダイレクトネットワークプロビジョニング」)を確認してください。

  • transactional-updateは、システムによって制御される自動更新を可能にするサービスです。通信ワークロードの場合、ノードで実行中のサービスに影響を及ぼさないように、自動更新を無効にすることが重要です。

自動更新を無効にするには、次のコマンドを実行できます。

systemctl --now disable transactional-update.timer
systemctl --now disable transactional-update-cleanup.timer

  • fstrimは、ファイルシステムを毎週自動的にトリミングできるサービスです。通信ワークロードでは、ノードで実行中のサービスに影響を及ぼさないように、自動トリミングを無効にすることが重要です。

自動トリミングを無効にするには、次のコマンドを実行できます。

systemctl --now disable fstrim.timer