VPCネットワーク設計
次の情報では、IBM Cloud® Virtual Private Cloud の展開の概要について説明します。 VMware インフラストラクチャ ネットワークと VPC の分離と統合、その要件、および他のワークロード トラフィックとの接続をどのように統合し構成するかを理解することが重要です。
VPC サブネット
IBM Cloud VPC では、複数の方法で論理的なセグメント化や分離を行うことができます。 このアーキテクチャでは、VMware Cloud Foundation™ 要件に従って従来の VLAN セグメンテーションのアナロジーを使用しますが、IBM Cloud VPC では VLAN の代わりにサブネットを使用します。 各システム トラフィック タイプは独自の VPC サブネットを持ち、VMkernel アダプター ネットワーク インターフェイス間のトラフィックは、IBM Cloud VPC セキュリティ グループ (SG) とサブネット アクセス制御リスト (ACL) の両方で制御できます。 次の図は、統合VPC設計の概要を示している。
![クラウド・ファウンデーション統合展開VMwareのためのVPC設計VMwareクラウド・ファウンデーション統合展開*のための](../../images/vcf-vpc-v2-arch-net-cons.svg "設計VMwareクラウド・ファウンデーション統合" caption-side="bottom"}*のための"){: caption="ネットワーク設計
このアーキテクチャでは、VMware Cloud Foundation インスタンスごとに新しい VPC が作成されます。 このアクションは、シンプルにし、VMware Cloud Foundation のスケーラビリティとアーキテクチャ要件および原則との問題を回避するためです。 他のワークロードや他の VPC に接続するには、IBM Cloud 相互接続ソリューション (Transit Gateway など) を使用できます。
次の表は、VPCで作成されるサブネットの一覧です。 サブネットの設計は、 VMware Cloud Foundationの要件に基づき、システムトラフィックの種類を論理的に分離し、各ユーザーごとに専用のVPCサブネットを使用します。 ベアメタルサーバーのPCIインターフェースは、独自のサブネット上でホストされる。 VMware vCenter®、VMware NSX™ マネージャ、SDDC マネージャ、および NSX Edge™ 管理インターフェイスなどの管理インターフェイスとアプライアンスは、独自の管理サブネットにプロビジョニングされます。
| サブネット名 | システム・トラフィック・タイプ | サブネットのサイズ設定のガイダンス |
|---|---|---|
vpc-host-subnet |
ホスト管理トラフィック | ホスト数×2（各PCI NICにIPアドレスが必要） |
vpc-mgmt-subnet |
管理アプライアンス・トラフィック | VMware クラウド基盤管理アプライアンスの数 |
vpc-vmot-subnet |
vMotion トラフィック | ホストの数 |
vpc-vsan-subnet |
vSAN トラフィック | ホストの数 |
vpc-tep-subnet |
ホストのTEPトラフィック | ホスト数×2（各ホストにはTEP×2が必要） |
NSX エッジ TEP トラフィックと NSX Tier-0 論理ゲートウェイ インターフェイスは、VMware Cloud Foundation デプロイメントでは独自のサブネット上に展開されます。 エッジクラスタには以下のVPCサブネットが必要です。
| サブネット名 | システム・トラフィック・タイプ | サブネットのサイズ設定のガイダンス |
|---|---|---|
vpc-edge-tep-subnet |
エッジノードのTEPトラフィック | エッジ・ノード数×2（各エッジ・ノードには2×TEPが必要） |
vpc-t0-public-uplink-subnet |
T0 パブリック・アップリンク・サブネット | /29 以上 |
vpc-t0-private-uplink-subnet |
T0 プライベート・アップリンク・サブネット | /29 以上 |
VPC にサブネットを作成するには、VPC 接頭部を作成する必要があります。 VPC 接頭部はゾーンごとに定義されます。 ルーティングを簡単にするために、推奨するサブネットを単一のプレフィックスから割り当てる必要があります。 つまり、5つのサブネットに対応するには、ゾーンあたり約120ホストのアドレスに対応する /21 のプレフィックスが1つ必要です。 接頭部として/22を使用する場合は、ゾーンごとに約 60 個のホストを追加できます。
十分大きなプレフィックスを選択することで、 NFS、レプリケーション、NSX Tier-0 アップリンク用の専用 VMK など、将来のニーズや拡張性を考慮した成長が可能になります。
VPCアクセス・コントロール・リストとセキュリティ・グループ
VPC 用のベアメタル・サーバーは、VPC ネットワーキング機能を完全にサポートしています。 セキュリティグループやアクセス制御リストなどのネットワークセキュリティ機能は、ベアメタルサーバーのPCIおよびVLANインターフェースで使用できます。 この設計では、 VMware システムトラフィックタイプを伝送するために使用される VMware インフラストラクチャサブネットと、ワークロードVM用のVPCサブネットの両方がルーティングドメインを共有します。 この設計により、これら2つの構築済みネットワークVPCセキュリティ・ツールの使用が可能になる。
VMware ワークロードによるアクセス制御リスト
アクセス制御リストは、サブネットのインバウンド・トラフィックとアウトバウンド・トラフィックを許可または拒否することによって管理できます。 ACL はステートレスです。つまり、インバウンド・ルールおよびアウトバウンド・ルールは、別個に明示的に指定する必要があります。 各 ACL は、送信元 IP、送信元ポート、宛先 IP、宛先ポート、およびプロトコルに基づく規則で構成されます。 どの VPC にも、すべてのインバウンド・トラフィックおよびアウトバウンド・トラフィックを許可するデフォルトの ACL があります。 デフォルト ACL ルールを編集するか、カスタム ACL を作成することできます。
ACLはサブネットに適用されるため、VPCサブネットとのトラフィックを制御する仮想サーバとして使用できます。 また、例えば、vSAN™、vMotion、TEP のトラフィック用に分離されたサブネットを作成することもできます。
デフォルトのデプロイメントでは、VPC全体に対してデフォルトのACL（allow any）が使用されますが、最初のデプロイメント後にこれをカスタマイズすることができます。
ACL について詳しくは、VPC のセキュリティーを参照してください。 IBM Cloud ベアメタル・サーバーを使用する ACL について詳しくは、IBM Cloud ベアメタル・サーバー・ネットワーキングの概要を参照してください。
VMware ワークロードを使用するセキュリティー・グループ
セキュリティー・グループは、1 つ以上の仮想サーバー・ネットワーク・インターフェースおよび IBM Cloud ベアメタル・サーバー PCI または VLAN インターフェースのトラフィックを制御する仮想ファイアウォールとして機能します。 セキュリティー・グループは、関連付けられたインターフェースのトラフィックを許可するか拒否するかを指定するルールの集合です。 インターフェースを 1 つ以上のセキュリティー・グループに関連付け、セキュリティー・グループ・ルールを編集することができます。 セキュリティー・グループをルールのソースまたは宛先として使用して、IP アドレスを指定せずにより動的なルールを作成することもできます。
この設計では、セキュリティグループを使用して、管理、 vSAN, vMotion、TEPのトラフィックタイプを論理的にグループ化し、必要なトラフィックフローを許可するルールを適用します。 以下のセキュリティグループが作成されます
| セキュリティー・グループ名 | 使用法 |
|---|---|
sg-mgmt |
管理アプライアンスとホスト |
sg-vmot |
vMotion 用 VMkernel アダプター |
sg-vsan |
vSAN 用 VMkernel アダプター |
sg-tep |
TEP用VMkernelアダプタ |
sg-uplink-pub |
Tier-0 パブリックアップリンク用 VMkernel アダプタ |
sg-uplink-priv |
Tier-0 プライベートアップリンク用 VMkernel アダプタ |
sg-bastion |
要塞ホスト用VMkernelアダプタ（オートメーションVSI） |
デフォルト・ルールの基本原則は、実用的な最低限を認めることである。 例えば、sg-vmot はセキュリティグループのメンバー間のトラフィックと、セキュリティグループ sg-mgmt からのインバウンド icmp を許可します。 同じ原則が、VMkernelアダプタに使用されるすべてのセキュリティグループにも適用されます。sg-mgmt はプライベート RFC 1918 ネットワークからの接続を許可します。
これらのルールは初回プロビジョニング後にカスタマイズ可能であり、以下の情報は簡略化されたガイダンスと原則を提供するものである。
VMware 仮想マシン（VM）でセキュリティグループをVLANインターフェイスと併用する場合、誤った設定や誤解を避けるために、標準および分散 vSwitches, へのトラフィックの流れと、これらの vSwitches 内のホスト内部をトラフィックが横断するタイミングを理解することが重要です。
VMware 環境では、同じベアメタルサーバ上の同じVLAN IDを持つVLANネットワークインターフェース間のトラフィックは、通常、ESXiホスト内の vSwitches によって転送されます。 仮想マシンまたはVMkernelインターフェイスが同じホスト上にあり、同じポートグループとVLAN IDを使用している場合、トラフィックはVPCネットワークに到達しません。
たとえば、複数のベアメタル サーバー ホストで構成される VMware vSphere® クラスター上で、分散 vSwitch を構成します。 この場合、VLAN ID 1611 のポートグループを作成し、それを特定の vSwitch に追加することができます。 ポート・グループ 1611に接続されている 2 つの VM の vNIC 間のトラフィックは、vSwitch によって制御されます。
この例では、VMware Cloud Foundation のデプロイメントにおいて、これは次のような結果をもたらします：
- トラフィックがvSwitchから出ない場合、ポートグループVLAN ID
1611のネットワークインターフェイス間のトラフィックを制御するセキュリティグループルールは適用されません。
また、NSX Tier 0 ゲートウェイのアップリンクと NSX オーバーレイのトラフィックに適用されるセキュリティ グループを扱う場合、たとえば IP アドレスに基づいてルールを定義する必要があります：
- VPC サブネット上の VMware VM（または VSI）から
192.168.45.10の IP アドレスを持つ NSX オーバーレイ上の VM にアクセスし、この IP アドレスへのトラフィックを許可する場合、送信元のセキュリティ グループ ルールが送信トラフィックに一致し、Tier 0 ゲートウェイ アップリンクに割り当てられているセキュリティ グループが受信トラフィックに一致する必要があります。 この場合、IPアドレスまたはCIDRを使用してオーバーレイ・トラフィックをマッチさせる必要がある。 - IP アドレスが
192.168.45.10の NSX オーバーレイ上の VM が vCenter または SDDC マネージャに通信する必要がある場合、Tier 0 ゲートウェイ アップリンクのセキュリティ グループ ルールが送信トラフィックに一致し、vCenter または SDDC マネージャの VLAN インターフェイスに割り当てられているセキュリティ グループが受信トラフィックに一致する必要があります。 この場合、IPアドレスまたはCIDRを使用してオーバーレイ・トラフィックをマッチさせる必要がある。
セキュリティー・グループについて詳しくは、VPC のセキュリティーを参照してください。 IBM Cloud ベアメタル・サーバーを使用するセキュリティー・グループについて詳しくは、IBM Cloud ベアメタル・サーバー・ネットワーキングの概要を参照してください。
VPC サブネット上の VMware VM とのパブリック接続
VPC 用の ベアメタル・サーバー は、VPC パブリック・ネットワーキング機能を完全にサポートします。 外部接続は、VPCサブネットに接続された Public Gateway を使用するか、ベアメタルサーバーのPCIまたはVLANインターフェースに接続されたフローティングIPアドレスを使用することで実現できます。 パブリックゲートウェイは送信元ネットワークアドレス変換（SNAT）を使用し、フローティングIPは宛先ネットワークアドレス変換（DNAT）を使用します。 これらの機能は、VPCの仮想サーバーと同一です。
パブリック・ゲートウェイを使用して VPC サブネットに接続された VLAN インターフェースは、インターネットへの接続を開始できますが、インターネットから接続を受信することはできません。 パブリック・ゲートウェイはサブネット全体の接続を提供し、このサブネット上の VM から発信されるパブリック・トラフィックは、パブリック・ゲートウェイ IP アドレスをソースと見なします。 サブネットがパブリック・ゲートウェイに接続されていない場合、トラフィックは完全にプライベートになります。 この設計では、vSAN、vMotion、または TEP のサブネットを例として使用できます。
浮動 IP を使用する VLAN インターフェースは、インターネットとの間の接続を開始または受信できます。 浮動 IP は、単一インスタンスの接続を提供します。 このアクションは、 Public Gateway がアタッチされたサブネットにプロビジョニングされている場合、VPCサブネット内のその特定のVLANインターフェースの Public Gateway を上書きします。
VMware Cloud Foundation のデプロイメントでは、Public Gateway に管理サブネットを追加する必要があります。これにより、たとえば、SDDC マネージャが VMware パブリック ソフトウェア リポジトリから直接更新を取得できるようになります。
オーバーレイおよび NSX パブリック接続の詳細については、VMware NSX 論理ルーターの VPC 展開 および VMware NSX 論理ルーティングの VPC 展開 を参照してください。