Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページの目次
 

Contrailクラウドの設定

この章では、Contrailクラウドの設定について説明します。

Contrailクラウド構成ファイルの構造の概要

ContrailクラウドはYAMLファイルを使用して設定されます。事前設定された一連の YAML ファイル テンプレートが、Contrail Cloud インストールの一部として提供されます。これらのユーザー設定可能な YAML ファイルは、Contrail Cloud インストールの初期段階で jumphost サーバーにダウンロードされます。YAMLファイルは、ジャンプホスト内からユーザーがアクセスおよび編集できます。

Contrailクラウドの設定変更は、Contrailクラウドバンドルの一部としても提供されるAnsibleプレイブックスクリプトを使用して適用されます。Ansible プレイブックは、YAML ファイルで提供される構成を読み取ります。Ansibleプレイブックスクリプトは、YAMLファイルのパラメーターを、RedHat Openstack DirectorがサーバーのプロビジョニングとContrailクラウドのコンポーネントの設定に使用する2番目の設定ファイルセットに入力します。

YAML ファイルの場所と設定の更新手順の詳細については、「 Contrail クラウドの導入 」を参照してください。

表 1 に、Contrail Cloud でよく使用される YAML ファイル パラメーターと、各パラメーターの目的の概要を示します。

表 1: YAML ファイル パラメーター

YAML File Parameter

Purpose
サイト.yml

グローバル：

デプロイメント環境の DNS、NTP、ドメイン名、タイム・ゾーン、サテライト URL、およびプロキシー構成。

ジャンプホスト:

ジャンプホストの NIC 名定義と PXE ブート インターフェイスをプロビジョニングします。

control_hosts:

ホスト パラメータを制御します。ベア メタル サーバーのディスク マッピングと、分析などの機能の役割ごとのコントロール プレーン VM のサイズ設定が含まれます。

compute_hosts:

コンピューティング ノードの SR-IOV、DPDK、TSN のパラメーター。ハードウェア プロファイルごとのルート ディスク構成。

storage_hosts:

ストレージノードのCephおよびブロックストレージプロファイルの定義。

アンダークラウド:

役割のためのノヴァフレーバー。追加のハードウェアプロファイルを使用する場合に適用されます。

オーバークラウド:

ハードウェアプロファイルとリーフ番号ベース:

  • ディスク マッピング

  • ネットワーク定義—名前、サブネット、VLAN、DHCPプール、ネットワークのロール。その他のネットワーク定義(TLS証明書、キーストーンLDAPバックエンドの有効化、導入後の追加アクション、tripleOの追加設定など)

セフ:

ストレージノードでのCephの有効化とディスク割り当て(プール、OSD)。

ceph_external:

外部に展開されたCeph統合パラメータ。

AppFormix:

AppFormix の HA、VIP IP、ネットワーク デバイスの監視を有効にします。
インベントリ.yml

inventory_nodes:

すべてのContrailクラスターノードのLCM、ルートディスク、およびその他の関連機能に使用される名前、IPMI IP、Ironicドライバー。
control-host-nodes.yml

control_host_nodes:

制御ホストと制御プレーンの内部IPとDNS(制御ノードごと)。コントローラー用に静的に追加される IP は、それらを使用するネットワークの DHCP プールの外部にある必要があります。

control_host_nodes_network_設定:

制御ホスト用のブリッジ、ボンディング、DHCP/IP、MTU

control_hosts:

制御とホストのマッピングでブリッジする VM インターフェイス。
overcloud-nics.yml

contrail_network_config:controller_network_config:appformixController_network_config:computeKernel_network_config:compute_dpdk_network_config:cephStorage_network_config:

インターフェイスからネットワークへのマッピング、ルート、DHCP-IP割り当て、ボンド、VLANからインターフェイスへのマップ、制御、ストレージ、計算ノードのボンドオプション。
compute-nodes.yml

compute_nodes_kernel:compute_nodes_dpdk: compute_nodes_sriov:

インベントリからコンピューティング ノードのコンピューティング ロールとプロファイルにホストをマッピングする。
storage-nodes.yml

storage_nodes:

ストレージ・ノードの名前。
vault-data.yml

グローバル：

Red Hat Open Stack Vault 機能用のサテライトキーと Contrail ユーザーパスワード。

アンダークラウド: オーバークラウド: control_hosts:

Red Hat Open Stack Vault 機能を使用する場合の Contrail Cluster ノードとアンダークラウドの VM & Bare Metal Server(BMS)パスワード

AppFormix:

Red Hat Open Stack Vault 関数を使用する場合の Appformix 用の MySQL および RabbitMQ パスワード。

ceph_external:

Red Hat Open Stack Vault機能を持つCeph Outsideが使用するクライアントキー。

inventory_nodes:

Red Hat Open Stack Vault機能を使用する場合のContrailクラスターノードのIPMI認証情報。

Ansibleプレイブックは、最初にファイルから変数を読み取ります default.yml 。構成ファイルは、 表 1 に示す順序で読み込まれます。変数は、スクリプトの実行時にファイルに格納され default.yml 、更新されます。同じ変数の構成設定が異なる YAML ファイルで異なる場合、構成ファイルの処理順序で後で読み取られる YAML ファイル内の設定が実装されます。

サンプル YAML ファイルは、 /var/lib/contrail_cloud/samples ディレクトリからディレクトリに /var/lib/contrail_cloud/config コピーし、現在のデプロイの要件に従って更新する必要があります。ディレクトリ内のファイル内の /var/lib/contrail_cloud/samples パラメーター値は、このドキュメントで値を設定するためのガイダンスが示されていないほとんどの場合、既定値として使用できます。 Contrailクラウド導入ガイドを参照してください。

ハードウェアプロファイル

ハードウェアプロファイルを使用すると、管理者は、計算ノードまたはストレージノードとして機能するサーバーのグループに同じ構成を適用できます。

新しいサーバーが配置に追加されると、各サーバーのディスクとネットワーク ハードウェアが異なる場合があります。ネットワークとストレージの構成方法は、サーバーによって異なる場合があります。

サーバーは、ファイル内の compute-nodes.yml ハードウェア プロファイルに関連付けられます。リーフ番号もこのファイルで設定されます。ファイルの次のサンプル構成スニペット compute-nodes.yml は、ハードウェア プロファイルの構成を示しています。

ハードウェア プロファイルの構成は、次のセマンティクスを使用するファイルのセクションを使用して、 および overcloud-nics.yml ファイルを使用してsite.ymlサーバーに適用されます。

どこ：

  • ロールは、ComputeKernel、ComputeDPDK、ComputeSriov、CephStorage のいずれかの値です。

  • リーフ番号はリーフの番号です。たとえば、 0.

  • ハードウェア プロファイル タグは、大文字で始まる任意の英数字文字列です。この Hw[number] 規則を使用することを強くお勧めします。

たとえば、次のサンプル名は、リーフ 0 のさまざまな種類の計算ノードに使用できます。

  • ComputeKernel0Hw1 カーネルモードの場合

  • ComputeDpdk0Hw1 DPDK用

  • ComputeSriov0Hw1 SR-IOV用

ファイル内の 2 つのハードウェア プロファイル構成の例を以下に示します site.yml 。この例では、変数 HCTL を使用して、ローカル VM エフェメラル ストレージに異なる SCSI ディスクを割り当てます。

ファイル内のハードウェア プロファイルの例については、 overcloud-nics.yml このリファレンス アーキテクチャの後半で説明します。

ネットワーク構成

このセクションでは、Contrail クラウドでのネットワークの設定方法について説明します。IPMI および [ネットワークのプロビジョニング] を除く、ネットワークのすべてのプロパティは、ファイル内の セクションで指定 network: されます site.yml 。

IPMIネットワーク

IPMI ネットワークは、通常、データセンター内のハードウェア管理用に予約されたネットワークアドレスのセットです。管理スイッチは、IPMI ネットワークのデフォルトゲートウェイにアクセスできるように設定する必要があります。環境内のサーバーは、IPMI に静的に割り当てられた IP アドレスを持つか、アドレス割り当てのキーとして MAC アドレスを使用して DHCP 経由で送信される IP アドレスを持つ必要があります。

ネットワークのプロビジョニング

プロビジョニング ネットワークのプロパティは、ファイルのセクションでundercloud:site.yml設定します。

ファイルのサンプル構成スニペット site.yml :

メモ：

オーバークラウド内の制御ネットワークは、アンダークラウド内のプロビジョニングネットワークと同じです。
メモ：

この構成例では、制御ノードとストレージ ノードに最大 200 のコンピューティング ノードと 15 の IP アドレスが用意されています。
メモ：

検査ブロックは、インストーラーのイントロスペクション サービスが PXE ブートおよびプロビジョニング プロセス中に使用する IP アドレスの範囲を指定します。 ip_range 変数を使用して、この範囲内の開始値と終了値を定義します。バッチ プロビジョニングを使用する場合 (このリファレンス アーキテクチャで推奨されています)、その時点で使用されているこれらのアドレスはごくわずかです。したがって、範囲はDHCPの範囲よりもはるかに小さくすることができます。

サーバー PXE はプロビジョニング ネットワークから起動し、プロビジョニング時に DHCP 経由で IP アドレスを受け取ります。次に、ブート設定がディスクに変更され、IronicサービスによってIPアドレスがオペレーティングシステムに構成され、サーバーは同じIPアドレスを使用してディスクから起動します。

外部ネットワーク

外部ネットワークは、クラウド ユーザーが制御ホストのパブリック API アドレスにアクセスするために使用されます。VIP IP アドレスと、DHCP で使用できる IP アドレスのプールを指定します。

外部ネットワーク パラメーターはファイルで設定されます site.yml 。

ファイルの外部ネットワーク構成スニペット site.yml のサンプル:

制御ホストの数は限られています。したがって、外部ネットワークは、IP アドレスの小さなサブネットにすることができます。

外部ネットワークは、ファイル内の制御ホスト上のインターフェイスに関連付け control-host-nodes.yml られています。

管理

管理ネットワークのプロパティは、ファイルの セクションでsite.yml設定しますnetwork:。

ファイルからの管理ネットワーク設定スニペット site.yml のサンプル:

内部API、テナント、ストレージ、ストレージ管理ネットワーク

Red Hat Openstack 13 (RHOSP 13) では、ラックごとに個別のサブネットを使用する機能がサポートされています。この機能は、このリファレンスアーキテクチャのIPファブリックに接続されているネットワークに使用されます。これらは、内部API、テナント、ストレージ、およびストレージ管理ネットワークです。これらの各ネットワークには、そのネットワークのすべてのラック サブネット(/24)を含むスーパーネット IP アドレス範囲(/16)が割り当てられます。

TripleOにおけるスパインリーフネットワーキングの概念については、

Red Hat OpenStack Platform 13:スパインリーフネットワーキング

TripleO では、リーフという用語を使用して、接続を共有するサーバーをグループ化します。このContrailクラウドリファレンスアーキテクチャでは、TripleOのコンテキストでのリーブは、同じラック内のグループ化されたサーバーを指します。このリファレンスアーキテクチャでは、Red Hat リーフは管理スイッチと一対のトップオブラックスイッチ (ToR スイッチ) によって実装されます。

構成ファイル内のネットワークの名前は、ラックまたはリーフのコンピューティング ノードとストレージ ノードで確立された規則に従います。名前は、ベースネットワーク名とリーフ番号を連結したものです。リーフ番号は、ファイル内のノードに割り当てられます compute_nodes.yml 。ベース ネットワーク名には、InternalApi、Storage、StorageMgmt、テナント ネットワークが含まれます。

リーフ 0 の計算ノードでは、次のようにネットワークを使用する必要があります。

  • 内部API0

  • ストレージ容量0

  • テナント0

リーフ 1 のコンピューティング ノードには、ネットワークが定義されている必要があります。

  • 内部API1

  • ストレージ容量1

  • テナント1

リーフ N の計算ノードには、ネットワークが定義されている必要があります。

  • InternalApiN

  • ストレージN

  • テナントN

スーパーネットを分割する例については、内部 API とテナント ネットワークについて以下の例を参照してください。コンピューティング ノードとストレージ ノード (ストレージ、ストレージ管理) に使用される残りのネットワークについても、同じ手順を実行する必要があります。

次の構成スニペットでは、これらのパラメーターがすべてのネットワークに対して設定されています。

  • スーパーネット - スーパーネットの定義。

  • CIDR - コントローラーに使用される最初のサブネットを持つリーフのサブネット構成。

  • default_route - bond1、vhost0、その他のインターフェイスなど、特定のオペレーティングシステムインターフェイスを介して「スーパーネット」を指すスタティックルート定義。

  • vrouter_gateway - オーバーレイネットワーク内のvRouterカプセル化トラフィックのデフォルトルート定義。この変数は、ファイル内で /etc/contrail/contrail-vrouter-agent.conf ゲートウェイ パラメーターとして定義されます。このゲートウェイIPアドレスは、DCゲートウェイ(MPLSoUDPまたはその他のオーバーレイを設定するためのMXルーターやその他のvRouter)に到達するために使用されます。

  • 役割 - サブネットを割り当てる役割またはハードウェア プロファイル。最初のサブネットは常にコントローラ用で、残りのサブネットはリーフ識別子に基づいてコンピューティングノードとストレージノードに割り当てられます。

ファイル内の role_network_config.yml インターフェイスを共有するネットワークを指定すると、そのネットワークにはVLANが割り当てられます。VXLANを使用すると、すべてのラックでVLANを同一にすることができ、このリファレンスアーキテクチャではVLANがどのようにラベル付けされるかがこれです。

このリファレンスアーキテクチャで使用されるネットワーク例

表 2 は、4 つのラックを持つ Contrail クラウド環境でのアドレス指定スキームの例を示しています。このアドレス指定スキームは、このリファレンスアーキテクチャの構成ファイルの例で使用されています。

表 2: アドレス指定スキーム
ネットワーク スーパーネット サブネット

提供

192.168.212.0/23

外部

10.10.10.0/25

internal_api

172.16.0.0/16

172.16.0.0/24

internal_api[0-3]

172.16.1-4.0/24

管理

192.168.0.0/23

ストレージ

172.19.0.0/16

172.19.0.0/24

ストレージ[0-3]

172.19.1-4.0/24

storage_mgmt

172.20.0.0/16

172.20.0.0/24

storage_mgmt[0-3]

172.20.1-4.0/24

テナント

172.18.0.0/16

172.18.0.0/24

テナント[0-3]

172.18.1-4./24
メモ：

site.ymlこのファイルでは、プロビジョニング ネットワークは、PXE ブート中に使用されるアドレスを持つインスペクション ブロックに分割されます。これらのアドレスは、プロビジョニング中にサーバーで構成されます。

スーパーネット・アドレスは、別個のサブネットを持つラックを含むネットワークに対して指定されます。スーパーネットアドレスは、正しいインターフェイスと対応するVLANを介してラック間トラフィックを送信するために、サーバー上の静的ルートで使用されます。

バッチ展開の構成

ジュニパーネットワークスでは、コンピューティングノードとストレージノードの導入を5〜10ノードのバッチで実行することを推奨しています。この推奨事項は、大規模な展開中の Triple0 Heat 自動化プロセス中にタイムアウトが発生する可能性に基づいて行われます。

バッチ展開は、 site.yml ファイルで構成されます。ファイルのサンプル バッチ展開構成スニペット site.yml :

この構成では、openstack-deploy.sh スクリプトの実行時に、5つのCephStorage、5つのComputeDPDK、および5つのComputeSriovノードが展開されます。スクリプトは、デプロイするノードがなくなったことを報告するまで、繰り返し実行する必要があります。

ジャンプホスト

jumphost は、管理者が Contrail クラウド環境のプロビジョニングを開始するホストです。このセクションでは、jumphost 構成オプションについて説明します。

ジャンプホストの概要

ジャンプホスト:

  • アンダークラウドをホストします。アンダークラウドは、Contrail クラウド内のすべての制御ホスト、ストレージノード、コンピューティングノードのプロビジョニングと管理を担当する VM です。Contrail関連のすべての設定と設定は、Contrailクラウドのアンダークラウドから実行されます。

  • Contrail Cloud の設定関連ファイルが保存されます。Contrail Cloud を設定する YAML ファイルは、jumphost に保存されます。YAMLファイルで作成された設定をContrailクラウドノードに適用するAnsibleスクリプトも、jumphostに保存されます。

    Contrail Cloud スクリプトは /var/lib/contrail_cloud ディレクトリに保存されます。

  • Contrail Command Web ユーザー インターフェイス仮想マシンをホストします。

  • ベースパッケージのみがインストールされた状態で Red Hat Enterprise Linux を実行します。

  • プロビジョニング ネットワークからイントラネットおよび外部ネットワークへのトラフィックに SNAT を提供します。

  • 管理ネットワークが存在しない場合に、Contrail クラウド環境のサーバーへのアクセスを提供します

ジャンプホストは、Contrail Cloud インストールの前提条件として動作している必要があります。jumphost は、アンダークラウドと Contrail Command VM 以外の仮想マシンを実行しないでください。

図 1 は、jumphost ネットワーク接続を示しています。

図 1: ジャンプホスト ネットワーク接続 Jumphost Network Connections

イントラネットネットワークは、Contrail Cloud 13 パッケージをダウンロードする前に手動で設定したネットワークです。このネットワークは、Contrailクラウドがパッケージをダウンロードしたり、Contrailクラウド環境内のノードが外部ネットワークに到達するための外部接続を提供するために使用します。イントラネット ネットワークの IP アドレスは、外部ネットワークの IP アドレスにすることができます。

jumphost は、プロビジョニング ネットワークに接続されたホストからの送信トラフィックの SNAT に IP マスカレードを使用するように、インストール プロセス中に構成されます。jumphost の "パブリック" IP アドレス ("イントラネット" ポートの IP アドレス) は、プロビジョニング中にクラウドから出るトラフィックの送信元アドレスとして使用されます。このIPアドレスは、パブリックリポジトリ、Juniper Satelliteサーバー、Red Hatサブスクリプションマネージャーへのアクセスを許可するため、ファイアウォールで許可する必要があります。セキュリティ上の理由から jumphost からの外部アクセスが許可されていない場合は、「カプセルの構成」の説明に従って Capsule プロキシサーバーを使用できます。「 その他」を参照してください。

プロキシを構成することもできますが、その場合、「イントラネット」ポートはプロキシにアクセスできる必要があります。Openstack、Appformix、Contrail APIの外部からアクセス可能なVIPアドレスは、(プロビジョニング中の問題を回避するため)プロキシから除外する必要があることに注意してください。

ファイルのプロキシ構成スニペット site.yml のサンプル:

10.10.100.50、10.10.10.51、10.10.10.52 は外部ネットワークの VIP です。

プロビジョニングネットワークへの Jumphost の IP アドレスの追加

ジャンプホストには、Contrailクラウド環境内の他のホストへのSSHを有効にするために、プロビジョニングネットワーク内のIPアドレスを割り当てる必要があります。この IP アドレスの割り当ては、jumphost からのトラブルシューティングを有効にする場合に便利です。

この IP アドレスは、次の構成スニペットに示すように、 site.yml ファイル内の jumphost に追加されます。

Contrailコマンドの設定

Contrail コマンドは、contrail_command と ccontrail_psql の 2 つのコンテナをベースにしたスタンドアロン ソリューションです。Contrail コマンドには HA 機能はなく、新しい UI サービスのみが提供されます。Contrail コマンド VM がジャンプホスト上に作成されます。

Contrail Cloud 環境では、Contrail Command Web UI にアクセスするには、Web ブラウザーに URL を入力します。 https://[jumphost-IP-address]:9091

Contrail コマンドは、Contrail クラウドの導入後にユーザー設定なしでアクセスできます。ファイル内の site.yml Contrailクラウドの設定パラメーターが更新されます。

Contrail コマンド パラメーターが更新されたサンプル site.yml ファイル設定スニペット:

Contrail コマンドの認証の詳細は、ファイルに記載されています vault-data.yml 。

Contrail コマンド属性を変更したサンプル vault-data.yml ファイル設定スニペット:

コントローラノードの設定

このセクションでは、Contrail クラウドでのコントローラーノードの設定について説明します。また、コントローラー ノードの VM リソースとネットワークに関連するセクションも含まれています。

ノード VM リソースの制御

このリファレンスアーキテクチャは、大規模なContrailクラウド環境をサポートするように設計されています。このアーキテクチャをサポートするには、次のメモリ リソースをコントローラ VM に割り当てる必要があります。

表 3: コントローラ VM の要件

役割

vCPU(スレッド)

メモリ(GB)

ディスク (GB)

アンダークラウドVM

28

128

500

OpenStack Controller VM*

8

48

500

Contrail Analytics DB VM

12

48

500 & 1000

Contrail Analytics VM

12

48

250

Contrail Controller VM

16

64

250

AppFormix VM

16

32

500

TSN(Contrail Service Node)

4

8

100

ホストOSの制御

4

8

100

* Openstack Controller VM サイズは、Red Hat が推奨する Openstack Controller VM サイズよりも大幅に小さくなっています。複数のネットワーク機能はContrail Networkingで処理され、テレメトリ機能はAppformixで実行されるため、VMはContrailクラウドで使用するリソースが少なくなります。推奨される VM サイズについては、 Red Hat OpenStack Platform 13: 大規模デプロイメントの推奨事項 を参照してください。

メモ：

オペレーティング システム リソースは、コントローラ VM に割り当てられたリソースに追い越されないように予約する必要があります(コントローラ ホストにオーバーサブスクリプションがないことを前提としています)。オペレーティング システムのリソースを構成するための構成ファイル オプションはありません。

ファイルのセクションにある control_hosts:vm: 次の構成スニペットは、 site.yml 制御ホスト オプションを構成します。

コントローラ ホストのネットワーク設定

コントローラホストの対応するインターフェイスは同じL2ネットワーク内にあり、異なるラックに導入し、EVPN-VXLAN IPファブリックのリーフデバイスに接続することを推奨します。 図 2 に、これらの接続を示します。

図 2: ホスト ネットワーク接続 Control Host Network Connectionsの制御

次の VM が制御ホストで実行されています。

  • OS - OpenStackコントローラ

  • CC - Contrail Controller

  • CA - Contrail Analytics

  • CADB - Contrail Analytics DB

  • AFX - Appformix

  • TSN - ToRサービスノード(オプション)

    TSN は、ファイル内のsite.yml階層でcontrol_hosts: vm: contrail-tsn:有効になります。この機能はContrail NetworkingでCSN(Contrail Service Node)に名前が変更されましたが、tripleOマニフェストでは引き続きTSNという用語が使用されます。

図3 は、制御ホスト上の物理インターフェイスと論理インターフェイスが、管理スイッチおよびリーフスイッチに接続する方法を示しています。

図3: 制御ホスト—物理および論理インターフェイス Control Host—Physical and Logical Interfaces
メモ：

物理 NIC には通常、複数の物理インターフェイスが含まれています。ただし、Red Hat 設定ファイルでは、命名規則はサーバー上の N 番目の物理インターフェイスを示すために使用します nicN 。イントロスペクション・コマンドを使用してインターフェースの順序を見つける方法については、 その他を参照してください。

図 4 は、ネットワークとポートがコントローラノードのブリッジにどのように割り当てられるかを示しています。

図4: 制御ホスト—物理インターフェイスからブリッジへの割り当て Control Host—Physical Interface to Bridge Allocation

物理 NIC には通常、最初の物理 NIC に nic3 と nic4 という名前の 2 つのポートが含まれています。

表 4 に、各ネットワークの設定に使用されるファイルを示します。

表 4: 制御ホスト ネットワークを構成するためのファイル
ポート/NIC 構成

Ipmi

アドレスは、ファイルへの入力として入力されます inventory.yml 。

BR-EN1

1 x 1G/10G NIC- プロビジョニングネットワークプールから自動的に生成されたアドレスを持つタグなしインターフェイス(組み込みの銅線インターフェイスなど)。

BR-EN2

1 x 1G/10G NIC- 管理ネットワーク、ファイルのセクションでsite.yml定義されたovercloud: network:アドレスを持つタグなしインターフェイス。

BR-ボンド0

両方のNICの最初のポートで構成された2 x 10G/25G/40G NIC。ネットワークとのタグ付きインターフェイス:テナント、内部API、外部ネットワーク。

ボンドの物理的な割り当ては、ファイルで定義されますcontrol-host-nodes.yml。アドレス指定は、ファイルのセクションでsite.yml設定されますovercloud: network:。

BRボンド1

両方のNICからの2番目のポートで構成された2 x 10G/25G/40G NIC。ネットワークとのタグ付きインターフェイス:ストレージとストレージ管理ネットワーク。

ボンドの物理的な割り当ては、ファイルで定義されますcontrol-host-nodes.yml。アドレス指定は、ファイルのセクションでsite.yml設定されますovercloud: network:。

ボンドインターフェースの設定は、ファイルの階層control-hosts-nodes.ymlでcontrol_host_nodes_network_config:実行されます。ボンドインターフェイスは、次のパラメータで設定する必要があります。

  • Linux ボンド - モード 4/LACP(802.3ad)

  • ハッシュポリシー - レイヤー3+4

  • ovs-bridge と linux_bond を使用します。OVS ブリッジ Linux ブリッジは設定可能ですが、Red Hat では推奨していません

このファイルからのコンフィギュレーションスニペットは control-hosts.nodes.yml 、ボンドインターフェイスコンフィギュレーションを含む様々なコントロールホストコンフィギュレーションを示しています。

メモ：

検証ツールを使用して、名前付き NIC への番号付き割り当てを確認します。「 その他」を参照してください。

ホスト ブリッジへのコントローラ VM インターフェイスのマッピング

コントローラ ホストのネットワーク設定で設定されたブリッジへの制御ホスト VM インターフェイス接続は、ファイルの階層control-host-nodes.ymlで行われますcontrol_hosts:。

構成スニペットの例を次に示します。

最初のインターフェイス (eth0) は、VM が PXE ブートできるようにするために、プロビジョニング ネットワークのブリッジに接続する必要があります。その他のインターフェイス名は、サンプルの設定スニペットと一致する連続したものでなければなりません。ブリッジごとに 1 つのインターフェイスを設定する必要があります。

Appformix VM Configuration

AppFormix には Contrail Cloud バンドルが付属しています。AppFormix は、Contrail クラウドのネットワークとサーバー インフラストラクチャの監視とトラブルシューティングを提供します。Appformix は、Contrail Cloud で実行されるワークロードに同じサービスを提供します。Appformix の詳細については、 Appformix テクニカル ライブラリのページを参照してください。

Appformix は WebUI と REST API を提供します。WebUI と REST API は、内部 API と外部ネットワークに公開されます。

推奨される Appformix デプロイメント (デフォルトのデプロイメントでもあります) は、高可用性のために 3 ノード構成でデプロイされます。

ContrailクラウドのAppformixノード設定は、ファイルで site.yml 定義されます。構成スニペットの例を次に示します。

Appformix のネットワーク構成は、 overcloud-nics.yml ファイルで定義されます。

構成スニペットの例を次に示します。

AppFormix を Contrail クラウドにインストールすると、以下のリソースが自動的に監視されます。

  • Openstack APIのエンドポイントとプロセス

  • Contrail API エンドポイントとプロセス

  • Openstack MySQL

  • ウサギのクラスターの状態

  • vRouter、Novaコンピューティング、オペレーティングシステムの正常性とメトリックを含むコンピューティングノード

Appformix が物理ネットワーク インフラストラクチャを監視するように自動的に構成されるわけではありませんが、ネットワーク デバイスを監視するためのアダプター(構成なし)は、Contrail Cloud の導入時にインストールできます。AppFormix は、導入後にネットワーク デバイスを監視するように手動で設定する必要があります。Appformix ユーザー ガイドの「ネットワーク デバイス」セクションを参照してください。

ネットワーク関連のアダプタは、Contrailクラウドの導入時に、 ファイル内で site.yml Appformixにインストールできます。

構成スニペットの例を次に示します。

カスタム Appformix プラグインは、Contrail クラウドがファイル内にデプロイする際にインストールすることもできます site.yml 。

構成スニペットの例を次に示します。

詳細については、『Appformix ユーザ ガイド』の「プラグインを使用した拡張性」を参照してください。

Contrail Service Node(CSN) - オプション

Contrail Service Node(CSN)は、OS のプロビジョニングを含むベアメタル サーバーのライフサイクル全体をContrail が管理している場合、DHCP、ARP、マルチキャスト サービスを提供します。ベアメタル サーバーを使用していない Contrail Cloud 展開では、CSN は必要ありません。

Contrail Cloud 13 リリースの triple-O テンプレートでは、Contrail Cloud の CSN 機能を指すものとして、引き続き Red Hat の用語 ToR Service Node(TSN)を使用します。したがって、このリファレンスアーキテクチャでは両方の用語を使用します。

ContrailクラウドでCSNサポートを有効にするには、ファイル内のsite.yml階層compute_hosts:を編集します。

構成スニペットの例を次に示します。

TSN VM は、デフォルトですべてのコントローラ ホスト上に作成されます。TSNは、少なくとも1台のベアメタルサーバー(BMS)を含むContrailクラウド環境の2つのコントロールホストで実行することをお勧めします。TSN VM は、BMS を使用していない Contrail Cloud 環境では実行しないでください。ファイル内の階層内の control_hosts: site.yml TSN インスタンスの数を変更できます。

コンピューティング ノードの構成

Contrailクラウドのコンピューティングノードはラックに設置され、ToR(トップオブラック)スイッチと管理スイッチのペアに接続されます。ToR スイッチは、EVPN-VXLAN IP ファブリックのリーフ ノードです。

コンピューティング ノードのネットワークは、個別のレイヤー 3 サブネットを構成するラックにコンピューティング ノードを配置するように構成されています。各ラックは、テナント ワークロードによって使用されるネットワーク用の個別のレイヤー 3 です。 図 5 に、このコンピューティング ノードのネットワーク構造を示します。

図 5: 計算ノードのネットワーク接続 Compute Node Network Connections

図 6 は、コンピューティング ノードの物理インターフェイスと論理インターフェイスによって、コンピューティング ノードを管理スイッチおよび IP ファブリック リーフ スイッチに接続する方法を示しています。

図 6: 計算ノードのネットワーク インターフェイス Compute Node Network Interfaces

図 7 は、計算ノード上のブリッジへのネットワークとポートの割り当てを示しています。

図 7: コンピューティング ノードとブリッジの接続 Compute Node to Bridge Connections

表 5 は、計算ノード上の各ネットワーク接続を構成するために使用されるファイルを示しています。

表 5: 計算ノードのネットワークを構成するためのファイル
ポート/NIC 構成

Ipmi

ファイルへの inventory.yml 入力にアドレスが入力されます。

BR-EN1

1 x 1G/10G NIC- プロビジョニングネットワークプールから自動的に生成されたアドレスを持つタグなしインターフェイス(組み込みの銅線インターフェイスなど)。

BR-EN2

1 x 1G/10G NIC - オプションの管理ネットワーク、ファイル内のsite.yml階層でovercloud: network:定義されたアドレスを持つタグなしインターフェイス。

BR-ボンド0

両方のNICの最初のポートで構成された2 x 10G/25G NIC。テナントネットワークとのタグなしインターフェイス。ボンドの物理割り振りはファイルで定義overcloud-nics.ymlされ、アドレッシングはファイル内のsite.yml階層でovercloud: network:設定されます。

BRボンド1

両方のNICからの2番目のポートで構成された2 x 10G/25G NIC。リーフの内部APIおよびストレージネットワークを備えたタグ付きインターフェイス。ボンドの物理割り振りはファイルで定義overcloud-nics.ymlされ、アドレッシングはファイル内のsite.yml階層でovercloud: network:設定されます。

プロビジョニングおよびオプションの管理ネットワークは、アウトオブバンド管理スイッチを介して接続され、管理スイッチ間のレイヤー 2 ストレッチとして構成する必要があります。

コンピューティング ノード ネットワーキング

コンピューティング ノードのデータ プレーン インターフェイスは、次の転送方法をサポートするように構成できます。

表 6: コンピューティング ノードの転送方法

カーネル モード

vRouter 転送機能は、Linux カーネルでデフォルトの Linux ブリッジ コードを Contrail Networking コードに置き換えることで実行されます。

ティッカー

vRouter は、指定されたコア数のユーザースペースで実行されます。

SR-IOV

VM またはコンテナ インターフェイスは、vRouter をバイパスして NIC に直接接続します。

トラフィック転送方法の選択は、個々のコンピューティング ノードのトラフィック プロファイルの期待値によって異なります。Contrail Cloud 環境では、さまざまなコンピューティングノードを異なるインターフェイスタイプで構成することができ、OpenStack アベイラビリティゾーンなどのさまざまなテクノロジーを使用して、ワークロードを最適なコンピューティングノードに配置できます。

管理インターフェイスのIPアドレスと、ボンドインターフェイスのアドレス指定と設定は、ファイル内で overcloud-nics.yml 設定されます。

カーネル モード vRouter の構成

vRouter vhost0 インターフェイスは、カーネルモードで vRouter を実行するコンピューティングノードの br-bond0 ブリッジに接続されています。br-bond0 ブリッジは、ボンド インターフェイスを介してテナント ネットワークに接続されます。

図 8 に、これらの接続を示します。

図 8: カーネル モードの vRouter Kernel Mode vRouter

コンピュートリソース

vRouter のパフォーマンスを最適化するには、次のガイドラインに従う必要があります。

  • ホストオペレーティングシステム用に最低4コアを保証し、そのうち最低2コアをvRouterカーネルモジュールで使用できます。コアを割り当てるメカニズムはありませんが、ホスト OS プロセスが消費するコアは 2 つ以下で、残りの 2 つはカーネル スケジューラが vRouter に割り当てると想定しています。

  • 4GBがvRouterに使用されるホストオペレーティングシステム用に最低8GBのRAMを保証します。

カーネルモードで実行されているvRouterは、これらのガイドラインに従えば、vRouterあたり最大500kpps(テーブル内で<1000フロー)を達成する必要があります。

ボンドインターフェイス設定

カーネルモードを使用する場合、ボンドインターフェイスに次のオプションを設定する必要があります。

  • bond_mode: 4 (IEEE 802.3ad)

  • bond_policy: レイヤー 3+4

ボンド構成は、ファイル内の overcloud-nics.yml プロファイル定義で定義されます。

最適化

パフォーマンスとスケーリングを向上させるために、vRouter あたりのフローの最大数をデフォルト値の 500,000 から 200 万フローに増やすことをお勧めします。また、フロー処理に 4 つのスレッドを割り当てることもお勧めします。

これらの構成パラメーターは、 site.yml ファイルで指定されます。構成スニペット:

カーネル モード計算ノードの追加

計算ノードは、ファイル内の階層に追加 compute_nodes_kernel: されると、 compute-nodes.yml カーネル モードで動作します。

構成スニペットの例を次に示します。

完全なリーフ/プロファイル構成スニペット

このセクションでは、計算ノードのファイルからの完全な構成ネットワーク スニペット overcloud-nics.yml を示します。

ファイル内の overcloud-nics.yml ネットワーク構成のプロファイルは、次の形式で書き込まれます。

どこ：

  • role は、次のいずれかのオプションです。

    • コンピューティングカーネル - カーネルモードの vRouter 用

    • ComputeDpdk

    • ComputeSriov

    • セフストレージ

  • リーフ番号 - リーフデバイスの番号または名前。たとえば、"0" や "leaf0" などです。

  • ハードウェア プロファイル タグ - プロファイル タグを定義する任意の名前。ハードウェア プロファイル タグには、この Hw[number] 形式を使用することを強くお勧めします。

例：

ハードウェアプロファイル「hw1」のリーフ「0」にある計算ノードDPDK

ハードウェアプロファイル「hw1」を使用してリーフ「0」でSR-IOVを計算します

リーフ "0" でハードウェア プロファイル "hw1" でカーネル モードを計算する

サンプル compute-nodes.yml ファイルの内容は次のとおりです。

メモ：

MTU 設定は、ファイル内のネットワーク設定から継承されます site.yml 。名前は「ヒート」表記(キャメルケース)で、最後にMTU値が付加されています。

メモ：

検証ツールを使用して、名前付き NIC への番号付き割り当てを確認します。「 その他」を参照してください。

上記の例では、管理ネットワークを使用して既定のルートを構成し、管理者が外部リソースにアクセスできると仮定しています。管理ネットワークが存在しない場合、既定のルートは、イントラネットへの SNAT がジャンプホストで構成されているプロビジョニング ネットワーク経由である必要があります。このシナリオでは、default: true ステートメントがファイルのセクションcompute-nodes.ymlにあるprovision:必要があります。テナント ネットワークに既定のルートを配置することもでき、テナント ネットワークで SNAT を使用する場合に便利です。

DPDKモードvRouterの設定

DPDK モードの vRouter は、コンピューティング ノードのユーザー空間で実行されます。ネットワーク トラフィックは、VLAN とボンドを処理する特別な DPDK 専用インターフェイスによって処理されます。vRouter 転送機能を実行するために、指定された数のコアが割り当てられます。

図 9 は、DPDK モードの vRouter を示しています。

図 9: DPDK vRouter DPDK vRouter

DPDK vRouterは、カーネルvRouterよりも高いスループットを提供します。Contrail ネットワークにおける DPDK の詳細については、 Contrail vRouter と統合されたデータ プレーン開発キット(DPDK)の設定 を参照してください。

DPDKボンドのインターフェイス設定

vRouter が DPDK モードの場合、LACP ボンディングは DPDK の制御下にあります。Linuxボンドはありません。

LACP ボンディングはファイルで定義され、 overcloud-nics.yml 次のオプションを使用して設定されます。

  • bond_mode: 4 (IEEE 802.3ad)

  • bond_policy: レイヤー 3+4

ボンド構成のサンプル overcloud-nics.yml ファイル:

DPDKを使用したLACPレートは、LACPパートナーとして機能するスイッチ間のLACPネゴシエーションプロセス中に取得され、スイッチに設定されているものに適用されます。ほとんどのジュニパースイッチはデフォルトで高速LACPモードで設定されており、vRouterがその設定を適用します。

LACP を強制的に高速 LACP モードにする場合は、ファイル内のsite.ymlフィールドを 1 に設定しますLACP_RATE:。

DPDKのパフォーマンスチューニング

DPDK モードで vRouter のスループットを最大化するには、以下のパラメータを設定します。

  • vRouter エージェントでのフロー処理に 4 つのスレッドを割り当てます。

  • 巨大なページを割り当てます。

  • DPDK、ホストOS、NovaにCPUを割り当てます。

  • フローテーブルのサイズをデフォルト設定の 500,000 から 200 万に増やします。

  • バッファー サイズを 2048 に増やして、マイクロバーストによるパケット ドロップを減らします。

  • vrouter のメモリ プール サイズを 2 倍の 131072 にします。

  • CPU スケーリング ガバナーをパフォーマンス モードに設定します。

CPU パフォーマンス・モードの使用可能化

CPU 周波数スケーリングを使用すると、オペレーティング システムは CPU 周波数をスケーリングして電力を節約できます。CPU 周波数は、システムの負荷に応じて、ACPI イベントに応じて自動的にスケーリングすることも、ユーザー スペース プログラムによって手動でスケーリングすることもできます。CPU を最大周波数で実行するには、scaling_governor パラメーターを performance に設定します。

BIOSでは、電力パフォーマンスチューニング、CPU Pステート、CPU C3レポート、CPU C6レポートなど、すべての省電力オプションを無効にする必要があります。ポリシーとしてCPU Power and Performance選択しますPerformance。

構成は、 site.yml (配置後アクション) パラメーターとして extra_action ファイルで定義できます。

ファイルのサンプル構成スニペット site.yml :

フロー・スレッドとヒュージ・ページの設定

オペレーティングシステムで使用する必要のないメモリは、効率を最大化するために巨大なページにセグメント化する必要があります。たとえば、256GBのRAMを搭載したサーバーにはOS(vRouterを含む)に8GBが必要なため、他の機能用に248GBが残っているとします。このサーバーは、メモリ使用量を最大化するために、残りのメモリを1GBのヒュージページに割り当てる必要があります。

さらに、vRouterのメモリ使用量を最大化するために、約2MBのヒュージページを設定する必要があります。

フロー処理と巨大ページ割り振りに使用されるスレッドの数は、 site.yml ファイル内で設定されます。

ファイルのサンプル構成スニペット site.yml :

CPU 割り当て

CPU のパーティション分割は、パフォーマンスを最適化するために適切に定義および構成する必要があります。CPU のパーティション分割の問題により、中程度および高スループットの環境で一時的なパケット ドロップが発生する可能性があります。

物理 CPU コアの割り当てを計画する際には、以下のパラメーターを考慮してください。

  • 沼トポロジ

  • ハイパースレッディング(HT)の使用法

  • vrouter DPDK に割り当てられたコアの数

  • VM に割り当てられたコアの数

  • システム プロセス用に残っているコアの数(vRouter エージェントを含む)

次のコア マッピングは、2 つの NUMA を持つ CPU の NUMA トポロジを示しています。各 NUMA には 18 個の物理コアがあり、ハイパースレッディングがサポートされています。

出力キー:

  • 青:DPDKに割り当てられています

  • 赤: VM 用に Nova に割り当てられます

  • 緑: 割り当てるべきではありません。

  • 黒:オペレーティングシステムに使用される残り

メモ：

コア 0 および 1 とそれに対応する HT 兄弟は、DPDK または Nova に割り当てることはできません。

ハイパースレッディングなしの 6 つのコアが vRouter に割り当てられ、スニペットの例では青色で示されています。テスト結果、マルチキュー virtio はより大きなコア数を効果的に処理しないため、この環境では 6 コアが割り当てられるべき最大数であることがわかりました。最大スループットを提供するコアの数は、ハードウェアの仕様によって異なる場合があります。DPDK にハイパースレッディングを使用すると、スループットが低下することが示されています。

DPDK にさらに多くのコアを使用する場合は、次の式に従って、vr_mempool__sz パラメーターを以下に示す値から変更する必要があります。

vr_mempool_sz = 2 * (dpdk_rxd_sz + dpdk_txd_sz) * (num_cores) * (num_ports)

どこ：

  • num_cores は、DPDK に割り当てられたコアの数です(HT 兄弟を含むが、これは推奨されません)

  • num_ports は、DPDKボンディング インターフェイスの物理ポート数です

  • dpdk_rxd_sz は、受信バッファー記述子の数です

  • dpdk_txd_sz は、送信バッファー記述子の数です

および dpdk_rxd_sz のdpdk_txd_szデフォルト値は 128 記述子に設定されていますが、インテルではマイクロバーストを処理するためにこれらの値を 2048 記述子に設定することを推奨しています。設定を大きくすると予期しない待機時間が発生する可能性があるため、2048 記述子の設定を超えないようにすることをお勧めします。

仮想マシンのワークロードに使用されるコアは、スニペット例で赤で示されている Nova CPU ピン留めを使用して設定されます。

オペレーティング システムには、スニペット例の黒で示されているように、この設定でハイパースレッディングを備えた 4 つの物理コアが割り当てられます。各 NUMA の最初のコアをオペレーティング システムに割り当てる必要があります。これらのオペレーティング システム コア予約は、ユーザーによって明示的に設定されません。予約は、NUMA が DPDK または Nova に割り当てられていない場合に暗黙的に指定されます。

このアーキテクチャでは、DPDK コアはすべて NUMA0 にあり、対応する NIC が配置されています。ネットワーク パフォーマンスが最大化される NUMA0 で実行される VM ワークロードの割合が高くなる環境を作成するには、できるだけ多くの OS コアを NUMA1 に配置することをお勧めします。

DPDK コアの割り当ては、ハードウェア プロファイルを使用してファイルで定義されます overcloud-nics.yml 。

ファイルのサンプル構成スニペット overcloud-nics.yml :

DPDK パラメータ(フローの最大数やバッファ サイズ、Nova ピン留めと一般的な Nova 機能に関連するパラメータなど)は、ファイルの階層site.ymlでextra-config:定義されます。

ファイルのサンプル構成スニペット site.yml :

メモ：

チューニング プロファイルcpu-partitioningを指定すると、cpu_affinitytuned.confファイル内の値が、IsolCpusList. にないコアのセットに設定されます。

DPDK 計算ノードの追加

DPDK モードで実行される計算ノードは、ファイルのcompute_nodes_dpdk階層で識別されます compute-nodes.yml 。

ファイルのサンプル構成スニペット compute-nodes.yml :

SR-IOV モードのコンピューティング ノード

SR-IOV モードのコンピューティング ノードは、NIC から VM への直接アクセスを提供します。ネットワーク トラフィックは SR-IOV モードで vRouter をバイパスするため、トラフィックに対してネットワーク ポリシーやフロー管理は実行されません。Contrail NetworkingのSR-IOVの詳細については、「 シングルルートI/O仮想化の設定(SR-IOV)」 を参照してください。

図 10 は、SR-IOV モードを使用したコンピューティング ノードの VM 接続を示しています。

図 10: コンピューティング ノード - SR-IOV モードで Compute Node—VM and vRouter Connections in SR-IOV Modeの VM と vRouter の接続

SR-IOV の用語では、NIC は物理機能 (PF) で表され、NIC の仮想バージョンと見なされる VM は仮想機能 (VF) と呼ばれます。複数のインターフェイスを持つ VM は、一部のインターフェイスでオーバーレイ ネットワークを使用し、他のインターフェイスで SR-IOV を使用して接続できます。

VM は、オーバーレイ ネットワークを使用することも、SR-IOV を使用して VFs を介してアンダーレイ ネットワークに直接移動することもできます。この設定は、ファイル内の compute-nodes.yml 階層でcompute_nodes_sriov:実行されます。

ファイルからの構成スニペット compute-nodes.yml 。

メモ：

SR-IOV は BIOS で有効にする必要があります。

SR-IOV の 2 種類の vRouter 展開:

  • SR-IOV 上のカーネル モードの vRouter

  • SR-IOV 上での DPDK モードの vRouter

図 11 に、両方のモードでの vrouter を示します。

図 11: SR-IOV - カーネル モードと DPDK モード SR-IOV—Kernel Mode and DPDK Mode

コンピューティングノードでSR-IOVが有効になっている場合、各vRouterはSR-IOV物理機能(PF)から設定されたボンディングインターフェイスに接続されます。SR-IOV が有効になっているネットワーク内の VM インターフェイスは、NIC 仮想機能 (VF) に接続され、Nova PCI パススルーによってファブリックアンダーレイネットワークに公開されます。

ファイルで SR-IOV モードのカーネルまたは dpdk モード site.yml を選択できます。

ファイルからの設定スニペット site.yml :

メモ：

インターフェイス名は、ファイル内のsite.yml階層sriov:で使用する必要があります。サーバーの名前付けの詳細については、インターフェースの命名規則を参照してください。

ボンドはファイルで設定 overcloud-nics.yml する必要があります。

ファイルのサンプル構成スニペット overcloud-nic.yml :

compute_hosts:ファイルのセクションでsite.yml、SR-IOV を有効にし、モードをカーネルまたは dpdk に設定する必要があります。

ファイルの num_vf セクションで site.yml 、オペレーティング システムによって NIC インターフェイスに割り当てられる仮想関数 (VF) の数を設定します。このサンプル構成スニペットでは、7 つの VF が割り当てられています。ens7f1 および ens7ens2 からの VF0 は、Nova PCI パススルー (sriov1 と sriov2 という名前のプロバイダーネットワーク) に割り当てられます。インターフェイス名は、IPMI を使用してサーバーにログインするときに表示されるものです。ネットワーク名は任意であり、SR-IOV 構成内でのみ使用されます。

次のスニペットは、SR-IOV が有効になっている場合の ip link ホストからのコマンド出力を示しています。

ストレージノード(Ceph OSD)

ストレージノードはContrailクラウドでCephソフトウェアを実行します。Red Hat Ceph ストレージソフトウェアの使用に関する追加情報については、 Red Hat Ceph Storage の製品ドキュメントを参照してください。

Contrailクラウドの導入でCephソフトウェアのパフォーマンスを最適化するために、次のガイドラインに従うことを推奨します。

  • ストレージ ノードは、Contrail クラウド環境のコンピューティング ノードから分離する必要があります。ハイパーコンバージド ノードはサポートされていません。

  • Cephが動作するには、最低3つのストレージノードが必要です。

Contrailクラウドで設定したCeph以外のストレージを導入に必要とする場合、契約上のサポートを確保するために、導入設計に追加のサポートとエンゲージメントが必要になることがあります。Ceph以外のストレージプロバイダと先に進む前に 、mailto:sre@juniper.net に電子メールを送信して、導入がサポート契約に準拠していることを確認します。

Cephの設定

Cephストレージ構成はファイルで site.yml 定義されています。

Cephストレージノードのディスクマッピングは、各ストレージノードのオーバークラウド:disk_mapping:階層で定義する必要があります。推奨されるディスク設定は、4 つの OSD ディスク + 1 つの SSD ジャーナル ディスクです。この構成は適切にスケーリングできます。たとえば、大規模な環境の場合は、8つのOSDディスク+ 2つのSSDジャーナルディスクです。複数の4つのOSD + 1ジャーナルバンドルを使用する場合は、CPU、RAM、およびストレージトラフィックを考慮する必要があります。

ファイルのマッピング セクションでは、 site.yml デバイス ID ではなく名前でディスクを参照できます。

ディスクマッピングを設定するための設定ファイルスニペットの例を次に示します site.yml 。

このサンプル site.yml 構成ファイルスニペットは、4つのOSDディスク+ 1つのSSDジャーナルバンドル用にCephストレージを構成します。

ディスクレイアウトは、特にハードウェアプロファイルごとです。

Cephサービス設定は、デフォルトで配置グループのコンピューティングの複雑さを隠します。この設定は、OSDの数が少ない環境の場合など、必要に応じて手動でファイルに指定できます site.yml 。

ストレージ・ノードのネットワーク構成

このリファレンス・アーキテクチャでは、ストレージ管理(レプリケーション)ネットワークとストレージ(ユーザー・アクセス)ネットワークのストレージ・ノードで別々のボンドが使用されます。

図 12 に、これらの接続を示します。

図 12: ストレージノードネットワーク Storage Node Networks

図 13 は、ストレージ ノードの物理インターフェイスと論理インターフェイスが、管理スイッチおよびリーフ スイッチに接続する方法を示しています。

図 13: ストレージ ノード - 物理インターフェイスと論理インターフェイス Storage Node—Physical and Logical Interfaces

図 14 は、ストレージ・ホストの物理インターフェースが、その上に構成されたブリッジに接続する方法を示しています。

図 14: ストレージ ノード - インターフェイス Storage Node—Interfaces

表 7 は、ストレージ・ノード上の各ネットワーク接続の構成に使用されるファイルを示しています。

ストレージノード上の管理インターフェイスのIPアドレス、およびボンドインターフェイスのアドレス指定と設定は、Contrailクラウドプロビジョニングシステムで使用される設定ファイルに従って設定されます。各ストレージ・ホストのポートは、以下のように構成されています。

表 7: ストレージ・ノード・インタフェースの命名構成ファイル
ポート/NIC 構成

Ipmi

アドレスは、ファイルへの入力として入力されます inventory.yml 。

BR-EN1

1 x 1G/10G NIC- プロビジョニングネットワークプールから自動的に生成されたアドレスを持つタグなしインターフェイス(組み込みの銅線インターフェイスなど)。

BR-EN2

1 x 1G/10G NIC - オプションで管理ネットワーク、ファイルのセクションでsite.yml定義されたovercloud: network:アドレスを持つタグなしインターフェイス。

BR-ボンド0

両方のNICの最初のポートで構成された2 x 10G/25G NIC。ストレージネットワークとのタグなしインターフェイス。ファイルに定義されているovercloud-nics.yml物理的な割り当てを結合します。アドレス指定は、ファイルのセクションでsite.yml設定されますovercloud: network:。

BRボンド1

両方のNICからの2番目のポートで構成された2 x 10G/25G NIC。ストレージ管理ネットワークとのタグなしインターフェイス。債券の物理的な割り当ては、ファイルで定義されますovercloud-nics.yml。アドレス指定は、ファイルのセクションでsite.yml設定されますovercloud: network:。

Linuxボンド構成は、ファイル内の overcloud-nics.yml ストレージホストごとに定義され、

ファイルのサンプル構成スニペット overcloud-nics.yml :

どこ：

  • NIC-0 - オンボード銅線 NIC 1/10G

  • NIC-1 および NIC-2 - NUMA0 に接続された PCI スロットに 2 ポート 10G/25G/40G Intel Fortville ファミリー NIC

関連ドキュメント