リファレンス アーキテクチャのバリエーション
このセクションでは、Contrail Cloud リファレンスアーキテクチャのバリエーションについて説明します。
Contrailクラウドリファレンスアーキテクチャのバリエーション
Contrailクラウドは、パフォーマンスと耐障害性の要件がより緩和されている環境に、よりシンプルなサーバーとネットワーク構成で導入できます。
このセクションでは、これらのアーキテクチャのバリエーションについて説明します。
- サポートされるリファレンスアーキテクチャのバリエーションの概要
- バリエーションアーキテクチャにおけるシングルボンド界面
- ラック間のレイヤー2ネットワーク
- シングルコントローラノード
- 高可用性の概念実証環境
- シングルコントローラノード
- リーフ スイッチ間のアンダーレイ ルーティング
サポートされるリファレンスアーキテクチャのバリエーションの概要
表 1 に、このリファレンスアーキテクチャでサポートされているバリエーションを示します。
| アーキテクチャのバリエーション | コメント |
同じラック内のコントローラホスト |
コントローラネットワークをラック間で拡張する必要はありませんが、停止のリスクが高まります。このバリエーションでは、構成ファイルを変更する必要はありません。 |
OpenStackコントローラホストとContrailコントローラホストを分離 |
このバリエーションは、ノード障害の影響を軽減したい環境で使用します。 |
コントローラと分析を分離し、AppFormix ホスト |
このバリエーションでパフォーマンスを向上させるには:
|
NUMA 0 および NUMA 1 での NIC の使用 |
Intel アーキテクチャは、DPDK コアから NIC へのクロス NUMA トラフィックに対してより柔軟になりましたが、これらの構成は、NUMA 0 での NIC と DPDK コアの両方の推奨よりもスループットが低くなります。 |
サーバー上のシングルボンドインターフェイス |
個別のストレージノードがない場合、またはネットワークトラフィックが少なく、競合によってパケットドロップが発生するリスクが低い場合に使用します。テナント ネットワークの DPDK はインターフェイスを共有できないため、この構成では DPDK モードを使用できないことに注意してください。 |
テナント、ストレージ、ストレージ管理、および内部APIトラフィック用のラック全体にわたる単一のサブネット |
ラック単位のアドレス指定が要件とならない小規模な環境での使用 |
外部、管理、およびイントラネットのトラフィックに同じネットワークを使用する |
ネットワーク共有は、ラボや POC などの非運用ネットワークで使用できますが、このバリエーションは運用環境では推奨されません。 |
バリエーションアーキテクチャにおけるシングルボンド界面
シングル・ボンド・インターフェースを持つサーバーを使用する場合は、ファイル内のovercloud-nics.yml各ネットワークが同じメモリー上に存在するように指定されます。設定は、 階層とcontroller_network_config、 および の各compute[leaf][h/w profile]storage[leaf][h/w profile]階層で実行されます。
リーフ スイッチ ポートは、各ノード タイプのボンディング インターフェイスに接続するために、次のように設定する必要があります。
| 接続されたノード | Vlan |
コント ローラー |
テナントストレージ内部 API外部 |
計算 |
テナントストレージ内部 API |
ストレージ |
ストレージ管理 |
次の図は、このアーキテクチャの接続を示しています。
ファイル内の overcloud-nics.yml コンピューティング ノードの完全な構成ネットワーク スニペットを次に示します。
#[role][leaf number][hardware profile tag]_network_config
# e.g.
ComputeDpdk0Hw1_network_config
# Provisioning interface definition
- type: interface
name: nic1 # br-eno1
dns_servers:
get_param: DnsServers
use_dhcp: false
mtu:
get_param: ControlPlaneNetworkMtu
addresses:
- ip_netmask:
list_join:
- '/'
- - get_param: ControlPlaneIp
- get_param: ControlPlaneSubnetCidr
routes:
-
ip_netmask: 169.254.169.254/32
next_hop:
get_param: EC2MetadataIp
-
default: True #Default route via provisioning, e.g. to access Satellite
next_hop:
get_param: ControlPlaneDefaultRoute
# Management interface definition
- type: interface
name: nic2 # br-eno2
mtu:
get_param: ManagementNetworkMtu
addresses:
- ip_netmask:
get_param: ManagementIpSubnet
routes:
-
ip_netmask: 10.0.0.0/8 #Address pool of corporate network that have access to
#servers via management network
next_hop: 192.168.0.1
# br-bond0 interface definition (for all networks except provision and management tagged)
- type: linux_bond
name: bond0 # br-bond0
use_dhcp: false
bonding_options: "mode=802.3ad xmit_hash_policy=layer3+4 lacp_rate=fast updelay=1000 miimon=100"
members:
- type: interface
name: nic3
mtu:
get_param: Tenant0NetworkMtu
primary: true
- type: interface
name: nic4
mtu:
get_param: Tenant0NetworkMtu
- type: vlan
vlan_id:
get_param: Tenant0NetworkVlanID
device: bond0
- type: contrail_vrouter
name: vhost0
use_dhcp: false
members:
-
type: interface
name:
str_replace:
template: vlanVLANID
params:
VLANID: {get_param: Tenant0NetworkVlanID}
use_dhcp: false
addresses:
- ip_netmask:
get_param: Tenant0IpSubnet
mtu:
get_param: Tenant0NetworkMtu
routes:
-
ip_netmask:
get_param: TenantSupernet
next_hop:
get_param: Tenant0InterfaceDefaultRoute
- type: vlan
device: bond0
vlan_id:
get_param: Storage0NetworkVlanID
mtu:
get_param: Storage0NetworkMtu
addresses:
- ip_netmask:
get_param: Storage0IpSubnet
routes:
-
ip_netmask:
get_param: StorageSupernet
next_hop:
get_param: Storage0InterfaceDefaultRoute
- type: vlan
device: bond0
vlan_id:
get_param: InternalApi0NetworkVlanID
mtu:
get_param: InternalApi0NetworkMtu
addresses:
- ip_netmask:
get_param: InternalApi0IpSubnet
routes:
-
ip_netmask:
get_param: InternalApiSupernet
next_hop:
get_param: InternalApi0InterfaceDefaultRoute
ラック間のレイヤー2ネットワーク
小規模なContrailクラウド導入において、ラック間で同じサブネットアドレスを使用できます。
図 3 は、Contrail Cloud 導入環境でレイヤー 2 を使用してラックにまたがる制御ホストのネットワークを示しています。 図 4 は、レイヤー 2 を使用してラックにまたがるコンピューティング ノードとストレージ ノードのネットワークを示しています。
によるネットワーキング
このレイヤー2アドレス指定スキームは、多数のデバイスがある環境には推奨されません。レイヤー 2 の拡張は、スイッチ間のトランキングを使用するか、追加のスケーラビリティが必要な場合は VXLAN を使用して実現できます。個別の管理スイッチの使用はオプションです。
このタイプの展開では、各タイプの単一のネットワークが定義され、スーパーネットは指定されません。
ファイルの次の構成スニペットは、 site.yml このデプロイを示しています。
network:
external:
cidr: "192.168.176.0/21"
vlan: 305
vip: "192.168.183.200"
pool:
start: "192.168.176.11"
end: "192.168.183.199"
mtu: 9100
internal_api:
vlan: 304
cidr: "192.168.168.0/21"
vip: "192.168.175.200"
pool:
start: "192.168.168.11"
end: "192.168.175.199"
mtu: 9100
tenant:
vlan: 301
cidr: "192.168.144.0/21"
pool:
start: "192.168.144.11"
end: "192.168.151.199"
mtu: 9100
storage:
vlan: 303
cidr: "192.168.160.0/21"
pool:
start: "192.168.160.11"
end: "192.168.167.199"
mtu: 9100
storage_management:
vlan: 302
cidr: "192.168.152.0/21"
pool:
start: "192.168.152.11"
end: "192.168.159.199"
mtu: 9100
management:
vlan: "0"
cidr: "192.168.72.0/21"
default_route: "192.168.79.254"
pool:
start: "192.168.72.11"
end: "192.168.79.199"
mtu: 9100
リーフ スイッチ ポートは、前のセクションで説明したのと同じ方法で VLAN を使用して設定されます。
シングルコントローラノード
小規模な実験およびラボでのContrailクラウドの導入では、単一のコントローラホストを持つことができます。これは、ファイル内のcontrol-host-nodes.yml階層に control_host_nodes: 1 つのエントリを持つことによって構成されます。
高可用性の概念実証環境
PoCトライアル環境の場合、高可用性サポートを使用して設定できる最小Contrailクラウド環境は次のとおりです。
ジャンプホスト
3 コントロール ホスト
ルーティングとトンネルの検証に使用できる 2 つのコンピューティングノード
3つのストレージノード(オプション)
簡素化されたネットワークは、次のコンポーネントで実装できます。
ジャンプホストからの IPMI 接続
各サーバーからスイッチへの単一のネットワーク接続
インターフェイスでタグなしとして設定されたネットワークをプロビジョニングする
インターフェイス上のVLANで設定された他のネットワーク
スイッチでサーバー間にまたがるように設定されたVLAN
この設定は、ほとんどの Contrail Networking 機能のテストに対応しています。
シングルコントローラノード
小規模なContrailクラウド環境(実験または制御されたラボ展開を含む)は、ジャンプホスト、単一の制御ホスト、1つ以上のコンピューティングノードで確立できます。
このタイプの小規模環境を構成するには、ファイルの階層に control_host_nodes: 1 つのエントリを含めます control-host-nodes.yml 。
リーフ スイッチ間のアンダーレイ ルーティング
アンダーレイ ファブリック ネットワークでリーフ スイッチ間のルーティングを設定し、リーフ スイッチの構成を簡素化することができます。
図 5 は、アンダーレイ ネットワークにおけるリーフ スイッチのルーティングを示しています。
内のリーフ スイッチ間のアンダーレイ ルーティング
リーフデバイスサブネットのIRBインターフェイスは設定されますが、VRFインスタンスには配置されません。そのため、トラフィックは、各スイッチのinet.0グローバルルーティングテーブル内のルートを使用してルーティングされます。各IRBインターフェイスへのルートは、iBGPを使用してリーフスイッチ間でアドバタイズされます。
追加の承認が必要なサポートされているバリエーション
以下のバリエーションは本番環境でサポートできますが、完全なカスタマーサポートを受けるには、ジュニパーネットワークスによる明示的に承認を受ける必要があります。これらのバリエーションを導入する前に 、メールで mailto:sre@juniper.net するか、ジュニパーの担当者にお問い合わせいただくか、Contrail Cloud環境がサポート契約に準拠していることをご確認ください。
これらのバリエーションを展開するには、通常、ジュニパーネットワークスのプロフェッショナルサービスチームとの協力が必要です。
承認が必要なバリエーションの概要
運用環境では、次のバリエーションをサポートできます。これらのバリエーションを導入する前に、メールで mailto:sre@juniper.net するか、ジュニパーネットワークスの担当者にお問い合わせいただくか、Contrail Cloud 環境がサポート契約に準拠していることをご確認ください。
表 3 に、これらのバリエーションを示します。
| バリエーション | 説明 |
EVPN VXLAN の代わりに VLAN を使用(サーバー接続に MC-LAG を使用するなど) |
スイッチのVLAN設定が管理しやすく、STPの制限が影響しないラボ、POC、小規模な実稼働環境で使用します。 |
折り畳み式スパイン/ゲートウェイ |
スパインが必要な機能と規模(外部接続されるVRFの数)をサポートしていれば、スパインスイッチでSDNゲートウェイ機能を設定することが可能 |
ラック当たり1つのリーフスイッチ |
インフラストラクチャの障害に対する耐障害性を備えた真のクラウドネイティブアプリケーション |
非 IP CLOS 接続 |
管理スイッチなし - ラボ環境のみ |
単一コントローラノード |
機能テストのラボやトレーニングに使用します。実稼働環境ではサポートされていません |
Contrail Cloud 13 リリースでは、1 つのノードでコントローラとコンピューティング機能の両方をサポートするオールインワンの導入はサポートされていません。ストレージノードも個別のデバイスにする必要があります。
以下のセクションでは、このようなアーキテクチャのバリエーションに対応するために Contrail Cloud の設定を変更する方法について説明します。