IBM Cloud Docs
VPCネットワーク設計

VPCネットワーク設計

マーケティング終了 ：2025年10月31日をもって、 VMware Solutions の新規導入は終了しました。 既存の顧客は、 IBM Cloud® 上のアクティブな VMware® ワークロードを引き続き使用し、拡張することができる。 詳細については、 IBM Cloud の VMware のマーケティング終了を 参照してください。

次の情報では、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で作成されるサブネットの一覧です。 サブネットの設計は、システム・トラフィック・タイプを論理的に分離し、使用するユーザーごとに専用のVPCサブネットを設定するという VMware Cloud Foundationの要件に基づいています。 ベアメタルサーバーのPCIインターフェースは、独自のサブネット上でホストされる。 VMware vCenter®、 VMware NSX® マネージャー、SDDC マネージャー、NSX Edge™ 管理インターフェイスなどの管理インターフェイスとアプライアンスは、独自の管理サブネットにプロビジョニングされます。

システムトラフィックタイプのVPCサブネット
サブネット名 システム・トラフィック・タイプ サブネットのサイズ設定のガイダンス
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サブネットが必要です。

NSXT0アップリンク用の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つのサブネットに対応するためには、 /21 プレフィックスが1つ必要で、1ゾーンあたり約120ホストのアドレスに対応することになる。 接頭部として/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 トラフィック・タイプの論理的なグループ化を作成し、必要なトラフィック・フローを許可するルールを適用します。 以下のセキュリティグループが作成される：

VPC セキュリティー・グループ
セキュリティー・グループ名 使用法
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 は、単一インスタンスの接続を提供します。 このアクションは、VPCサブネット内の特定のVLANインターフェイスの Public Gateway、それがアタッチされたサブネットにプロビジョニングされている場合、オーバーライド Public Gateway。

VMware Cloud Foundation のデプロイメントでは、Public Gateway に管理サブネットを追加する必要があります。これにより、たとえば、SDDC マネージャが VMware パブリック ソフトウェア リポジトリから直接更新を取得できるようになります。

オーバーレイおよび NSX パブリック接続の詳細については、VMware NSX 論理ルーターの VPC 展開 および VMware NSX 論理ルーティングの VPC 展開 を参照してください。