Conception d'un réseau VPC
Fin de la commercialisation: à compter du 31 octobre 2025, les nouveaux déploiements des offres « VMware Solutions » ne seront plus disponibles pour les nouveaux clients. Les clients existants peuvent continuer à utiliser et à développer leurs charges de travail VMware® actives sur IBM Cloud®. Pour plus d'informations, voir Fin de la commercialisation pour VMware sur IBM Cloud.
Les informations suivantes donnent un aperçu du déploiement IBM Cloud® Virtual Private Cloud pour un déploiement VMware®. Il est important de comprendre la séparation et l'intégration du réseau d'infrastructure VMware avec le VPC, ses exigences, comment intégrer et configurer la connectivité avec le trafic d'autres charges de travail.
Sous-réseaux de cloud privé virtuel
Dans IBM Cloud VPC, vous pouvez effectuer une segmentation ou une isolation logique de plusieurs façons. Cette architecture utilise une analogie de segmentation VLAN traditionnelle en suivant les VMware Cloud Foundation™ requirements, mais IBM Cloud VPC utilise des sous-réseaux au lieu de VLAN. Chaque type de trafic système possède son propre sous-réseau VPC et le trafic entre les interfaces réseau de l'adaptateur VMkernel peut être contrôlé à la fois par des IBM Cloud VPC groupes de sécurité (SG) et des listes de contrôle d'accès (ACL) au sous-réseau. Le diagramme suivant présente une vue d'ensemble de la conception du VPC consolidé.
Pour cette architecture, un nouveau VPC est créé pour chaque instance de VMware Cloud Foundation. Cette mesure est prise pour des raisons de simplicité et pour éviter les problèmes d'évolutivité et les exigences et principes architecturaux de la VMware Cloud Foundation. Pour vous connecter à d'autres charges de travail et à d'autres VPC, vous pouvez utiliser des IBM Cloud solutions d'interconnectivité, telles que Transit Gateway.
Le tableau suivant énumère les sous-réseaux qui sont créés dans le VPC. La conception du sous-réseau est basée sur l'exigence de la VMware Cloud Foundation de séparer logiquement les types de trafic du système et un sous-réseau VPC dédié pour chaque utilisateur utilisé. Les interfaces PCI des serveurs nus sont hébergées sur leur propre sous-réseau. Les interfaces et les appareils de gestion, tels que VMware vCenter®, VMware NSX® managers, SDDC manager et les interfaces de gestion NSX Edge™ sont provisionnés sur leur propre sous-réseau de gestion.
| Nom de sous-réseau | Type de trafic système | Conseils de dimensionnement de sous-réseau |
|---|---|---|
vpc-host-subnet |
Trafic de gestion d'hôte | Nombre d'hôtes x 2 (chaque carte PCI NIC nécessite une adresse IP) |
vpc-mgmt-subnet |
Trafic du dispositif de gestion | Nombre de VMware Cloud Foundation Management Appliances |
vpc-vmot-subnet |
Trafic vMotion | Nombre d'hôtes |
vpc-vsan-subnet |
Trafic vSAN | Nombre d'hôtes |
vpc-tep-subnet |
Trafic TEP pour les hôtes | Nombre d'hôtes x 2 (chaque hôte nécessite 2 TEP) |
Le trafic TEP périphérique NSX et les interfaces de passerelle logique NSX Tier-0 sont déployés sur leurs propres sous-réseaux dans les déploiements VMware Cloud Foundation. Les sous-réseaux VPC suivants sont nécessaires pour le cluster de périphérie.
| Nom de sous-réseau | Type de trafic système | Conseils de dimensionnement de sous-réseau |
|---|---|---|
vpc-edge-tep-subnet |
Trafic TEP pour les nœuds périphériques | Nombre de nœuds de bordure x 2 (chaque nœud de bordure nécessite 2 x TEP) |
vpc-t0-public-uplink-subnet |
Sous-réseau de liaison montante publique T0 | /29 ou plus |
vpc-t0-private-uplink-subnet |
Sous-réseau de liaison montante privée T0 | /29 ou plus |
Pour pouvoir créer des sous-réseaux dans le cloud privé virtuel (VPC), vous devez créer un préfixe VPC. Les préfixes VPC sont définis par zone. Pour simplifier le routage, vous devez attribuer les sous-réseaux recommandés à partir d'un seul
préfixe. Cela signifie que pour cinq sous-réseaux, il faut un préfixe /21 pour fournir des adresses à environ 120 hôtes par zone. Si vous souhaitez utiliser un préfixe avec /22, vous pouvez ajouter environ 60 hôtes
par zone. En choisissant un préfixe suffisamment grand, vous aurez une croissance pour l'évolutivité et les besoins futurs, tels que les VMK dédiés pour NFS, la réplication et les liaisons montantes NSX Tier-0.
Listes de contrôle d'accès et groupes de sécurité VPC
Les serveurs bare metal pour le cloud privé virtuel offre une prise en charge complète des fonctions réseau du cloud privé virtuel. Les fonctionnalités de sécurité réseau, telles que les groupes de sécurité et les listes de contrôle d'accès, peuvent être utilisées avec les interfaces PCI et VLAN des serveurs bare metal. Dans cette conception, les sous-réseaux de l'infrastructure VMware, qui sont utilisés pour transporter les types de trafic du système VMware, et les sous-réseaux VPC pour les charges de travail des VM partagent le domaine de routage. Cette conception permet d'utiliser les deux outils de sécurité du réseau VPC.
Liste de contrôle d'accès avec charges de travail VMware
Une liste de contrôle d'accès peut gérer en autorisant ou en refusant le trafic entrant et sortant pour un sous-réseau. Une liste de contrôle d'accès est sans état, ce qui signifie que les règles entrantes et sortantes doivent être spécifiées séparément et explicitement. Chaque liste de contrôle d'accès se compose de règles basées sur une adresse IP source, un port source, une adresse IP de destination, un port de destination et un protocole. Chaque VPC dispose d'une liste de contrôle par défaut qui autorise tout le trafic entrant et sortant. Vous pouvez éditer les règles de liste de contrôle d'accès par défaut ou créer une liste de contrôle d'accès personnalisée.
Lorsque les ACL sont appliquées à un sous-réseau, vous pouvez les utiliser comme serveurs virtuels pour contrôler le trafic à destination et en provenance des sous-réseaux VPC. Vous pouvez également créer des sous-réseaux isolés, par exemple, pour le trafic vSAN™, vMotion et TEP.
Le déploiement par défaut utilise un ACL par défaut (allow any) pour l'ensemble du VPC, mais vous pouvez le personnaliser après le déploiement initial.
Pour plus d'informations sur les listes de contrôle d'accès, voir Sécurité dans le cloud privé virtuel. Pour plus d'informations sur les listes de contrôle d'accès avec le serveur bare metal IBM Cloud, voir Introduction à la mise en réseau de serveurs bare metal IBM Cloud.
Groupes de sécurité avec charges de travail VMware
A security group acts as a virtual firewall that controls the traffic for one or more virtual server network interfaces and IBM Cloud bare metal server PCI or VLAN interfaces. Un groupe de sécurité est une collection de règles qui spécifient s'il faut autoriser ou refuser le trafic pour une interface associée. Vous pouvez associer une interface à un ou plusieurs groupes de sécurité et éditer les règles du groupe de sécurité. Vous pouvez également utiliser des groupes de sécurité comme source ou destination dans les règles pour créer des règles plus dynamiques sans spécifier d'adresses IP.
Dans cette conception, vos groupes de sécurité sont utilisés pour créer un regroupement logique des types de trafic Management, vSAN, vMotion et TEP, et appliquer des règles pour autoriser les flux de trafic requis. Les groupes de sécurité suivants sont créés :
| Nom de groupe de sécurité | Utilisation |
|---|---|
sg-mgmt |
Appareils de gestion et hôtes |
sg-vmot |
Adaptateurs VMkernel pour vMotion |
sg-vsan |
Adaptateurs VMkernel pour vSAN |
sg-tep |
Adaptateurs VMkernel pour TEP |
sg-uplink-pub |
Adaptateurs VMkernel pour les liaisons montantes publiques Tier-0 |
sg-uplink-priv |
Adaptateurs VMkernel pour les liaisons montantes privées Tier-0 |
sg-bastion |
Adaptateurs VMkernel pour les hôtes bastion (automatisation VSI) |
Le principe de base des règles par défaut est d'autoriser le minimum pratique. Par exemple, sg-vmot autorise le trafic entre les membres du groupe de sécurité et le trafic entrant icmp du groupe de sécurité sg-mgmt.
Le même principe s'applique à tous les groupes de sécurité utilisés pour les adaptateurs VMkernel. sg-mgmt permet la connectivité à partir de réseaux privés RFC 1918. Ces règles peuvent être personnalisées après le provisionnement
initial et les informations suivantes fournissent des conseils et des principes simplifiés.
Lorsque des groupes de sécurité sont utilisés avec des interfaces VLAN dans les machines virtuelles (VM) VMware, il est important, pour éviter les mauvaises configurations et les malentendus, de comprendre comment le trafic circule vers et depuis les sites standard et distribué vSwitches, et quand le trafic traverse les hôtes à l'intérieur de ces vSwitches.
Dans un environnement VMware, le trafic entre les interfaces réseau VLAN avec le même ID VLAN sur le même serveur bare metal est généralement transmis par vSwitches dans l'hôte ESXi. Si les machines virtuelles ou les interfaces VMkernel se trouvent sur le même hôte et utilisent le même groupe de ports et le même ID VLAN, le trafic n'atteint pas le réseau VPC.
Par exemple, sur un cluster VMware vSphere® composé de plusieurs serveurs bare metal, vous configurez un vSwitch distribué. Dans ce cas, vous pouvez créer un groupe de ports avec l'ID VLAN 1611 et l'ajouter au site spécifique
vSwitch. Le trafic entre les vNIC de deux machines virtuelles connectées au groupe de ports 1611 est contrôlé par le commutateur virtuel.
Dans cet exemple, cela a les conséquences suivantes dans les déploiements de VMware Cloud Foundation :
- Les règles du groupe de sécurité qui contrôlent le trafic entre les interfaces réseau du groupe de ports VLAN ID
1611ne sont pas appliquées si le trafic ne quitte pas le vSwitch.
En outre, lorsque vous travaillez avec des groupes de sécurité appliqués aux liaisons montantes de passerelle NSX de niveau 0 et au trafic de superposition NSX, vous devez définir des règles basées sur les adresses IP, par exemple :
- Lorsque vous accédez à une VM sur une superposition NSX avec une adresse IP de
192.168.45.10à partir d'une VMware VM (ou un VSI) sur le sous-réseau VPC et que vous souhaitez autoriser le trafic vers cette adresse IP, votre règle de groupe de sécurité source doit correspondre au trafic sortant, et le groupe de sécurité qui est attribué aux liaisons montantes de la passerelle de niveau 0 doit correspondre au trafic entrant. Dans ce cas, une adresse IP ou un CIDR doit être utilisé pour faire correspondre le trafic superposé. - Lorsqu'une VM sur une superposition NSX avec une adresse IP de
192.168.45.10doit communiquer avec un vCenter ou un gestionnaire SDDC, la règle de groupe de sécurité des liaisons montantes de la passerelle de niveau 0 doit correspondre au trafic sortant, et le groupe de sécurité attribué à l'interface VLAN du vCenter ou du gestionnaire SDDC doit correspondre à cette règle sur le trafic entrant. Dans ce cas, une adresse IP ou un CIDR doit être utilisé pour faire correspondre le trafic superposé.
Pour plus d'informations sur les groupes de sécurité, voir Sécurité dans votre VPC. Pour plus d'informations sur les groupes de sécurité avec le serveur bare metal IBM Cloud, voir Introduction à la mise en réseau de serveurs bare metal IBM Cloud.
Connectivité publique avec les machines virtuelles VMware sur le sous-réseau VPC
Le serveur bare metal pour cloud privé virtuel (VPC) offre une prise en charge complète des fonctions de réseau public VPC. La connectivité externe peut être obtenue soit en utilisant une adresse Public Gateway qui est attachée à un sous-réseau VPC, soit en utilisant une adresse IP flottante qui est attachée à une interface PCI ou VLAN d'un serveur bare metal. La passerelle publique utilise la traduction d'adresse de réseau source (SNAT) et une IP flottante utilise la traduction d'adresse de réseau destination (DNAT). Ces fonctions sont identiques à celles des serveurs virtuels VPC.
Les interfaces de réseau local virtuel qui sont connectées à un sous-réseau VPC avec une passerelle publique peuvent initier des connexions à Internet, mais elles ne peuvent pas recevoir de connexions à partir d'Internet. La passerelle publique fournit la connectivité pour tout un sous-réseau, et le trafic public provenant des machines virtuelles sur ce sous-réseau considère l'adresse IP de la passerelle publique comme la source. Si le sous-réseau n'est pas attaché à une passerelle publique, le trafic est entièrement privé. Dans cette conception, les sous-réseaux vSAN, vMotion ou TEP (programme de signalisation d'erreur de terminal) peuvent être des exemples.
Une interface de réseau local virtuel avec une adresse IP flottante peut initier ou recevoir des connexions vers ou depuis Internet. L'IP flottante fournit une connectivité pour une seule instance. Cette action remplace l'adresse Public Gateway de cette interface VLAN spécifique dans le sous-réseau VPC, si elle est fournie à un sous-réseau avec Public Gateway.
Dans les déploiements de VMware Cloud Foundation, vous devez ajouter un sous-réseau de gestion à une Public Gateway, ce qui permet, par exemple, au gestionnaire SDDC d'obtenir des mises à jour directement à partir des dépôts de logiciels publics de VMware.
Pour plus d'informations sur la superposition et la connectivité publique NSX, voir VMware routeurs logiques NSX sur les déploiements VPC et VMware routage logique NSX sur VPC.