Progettazione della rete VPC
Fine della commercializzazione: a partire dal 31 ottobre 2025, le nuove implementazioni delle offerte " VMware Solutions " non saranno più disponibili per i nuovi clienti. I clienti esistenti possono continuare a utilizzare e ampliare i propri carichi di lavoro attivi su VMware® all'indirizzo IBM Cloud®. Per ulteriori informazioni, vedere Fine della commercializzazione per VMware su IBM Cloud.
Le seguenti informazioni forniscono una panoramica dell'implementazione IBM Cloud® Virtual Private Cloud per un'implementazione VMware®. È importante comprendere la separazione e l'integrazione della rete dell'infrastruttura VMware con la VPC, i suoi requisiti, come integrare e configurare la connettività con il traffico di altri carichi di lavoro.
Sottoreti VPC
In IBM Cloud VPC, è possibile effettuare la segmentazione o l'isolamento logico in diversi modi. Questa architettura utilizza un'analogia di segmentazione VLAN tradizionale seguendo i requisiti di VMware Cloud Foundation™, ma IBM Cloud VPC utilizza le sottoreti invece delle VLAN. Ogni tipo di traffico di sistema ha una propria sottorete VPC e il traffico tra le interfacce di rete dell'adattatore VMkernel può essere controllato sia con IBM Cloud VPC gruppi di sicurezza (SG) che con liste di controllo degli accessi alla sottorete (ACL). Il diagramma seguente mostra una panoramica del progetto VPC consolidato.
Per questa architettura, viene creata una nuova VPC per ogni istanza di VMware Cloud Foundation. Quest'azione è stata eseguita per semplicità e per evitare problemi di scalabilità e di requisiti e principi architettonici di VMware Cloud Foundation. Per connettersi ad altri carichi di lavoro e ad altre VPC, è possibile utilizzare le soluzioni di interconnessione IBM Cloud, come Transit Gateway.
La tabella seguente elenca le sottoreti che vengono create nella VPC. La progettazione della sottorete si basa sul requisito di VMware Cloud Foundation di separare logicamente i tipi di traffico del sistema e su una sottorete VPC dedicata per ogni utente utilizzato. Le interfacce PCI dei server Bare Metal sono ospitate sulla propria sottorete. Le interfacce e le appliance di gestione, come VMware vCenter®, VMware NSX® manager, SDDC manager e le interfacce di gestione di NSX Edge™, sono allocate sulla propria subnet di gestione.
| Nome sottorete | Tipo di traffico del sistema | Guida al dimensionamento della sottorete |
|---|---|---|
vpc-host-subnet |
Traffico di gestione dell'host | Numero di host x 2 (ogni NIC PCI richiede un indirizzo IP) |
vpc-mgmt-subnet |
Traffico dell'apparecchio di gestione | Numero di appliance di gestione di VMware Cloud Foundation |
vpc-vmot-subnet |
Traffico vMotion | Numero di host |
vpc-vsan-subnet |
Traffico vSAN | Numero di host |
vpc-tep-subnet |
Traffico TEP per gli host | Numero di host x 2 (ogni host richiede 2 x TEP) |
Il traffico TEP dell'edge NSX e le interfacce del gateway logico NSX Tier-0 sono distribuite sulle proprie sottoreti nelle implementazioni di VMware Cloud Foundation. Per il cluster edge sono necessarie le seguenti sottoreti VPC.
| Nome sottorete | Tipo di traffico del sistema | Guida al dimensionamento della sottorete |
|---|---|---|
vpc-edge-tep-subnet |
Traffico TEP per i nodi edge | Numero di nodi bordo x 2 (ogni nodo bordo richiede 2 x TEP) |
vpc-t0-public-uplink-subnet |
T0 sottorete pubblica di uplink | /29 o più grande |
vpc-t0-private-uplink-subnet |
T0 subnet uplink privata | /29 o più grande |
Per poter creare sottoreti in VPC, è necessario creare un prefisso VPC. I prefissi VPC sono definiti per zona. Per semplificare l'instradamento, è necessario assegnare le sottoreti consigliate a partire da un unico prefisso. Ciò significa che
per ospitare cinque sottoreti, è necessario un prefisso /21 per fornire indirizzi a circa 120 host per zona. Se si vuole usare un prefisso con /22, si possono aggiungere circa 60 host per zona. Selezionando un prefisso
sufficientemente grande, si potrà disporre di una crescita per la scalabilità e le esigenze future, come ad esempio VMK dedicate per NFS, replica e uplink NSX Tier-0.
Elenchi di controllo degli accessi e gruppi di sicurezza VPC
Il server Bare Metal per VPC fornisce il supporto completo per le funzionalità di rete VPC. Le funzionalità di sicurezza di rete, come i gruppi di sicurezza e le liste di controllo degli accessi, possono essere utilizzate con le interfacce PCI e VLAN dei server bare metal. In questo progetto, sia le sottoreti dell'infrastruttura VMware, utilizzate per trasportare i VMware, sia le sottoreti VPC per le macchine virtuali dei carichi di lavoro condividono il dominio di routing. Questo progetto consente l'utilizzo di questi due strumenti di sicurezza di rete VPC.
Elenco di controllo degli accessi con carichi di lavoro VMware
Una lista di controllo degli accessi può gestire consentendo o negando il traffico in entrata e in uscita per una sottorete. Un ACL è senza stato, il che significa che devono essere specificate delle regole in entrata e in uscita separatamente e in modo esplicito. Ogni ACL è composta da regole basate su IP di origine, porta di origine, IP di destinazione, porta di destinazione e protocollo. Ogni VPC ha un ACL predefinito che consente tutto il traffico in entrata e in uscita. È possibile modificare le regole ACL predefinite o creare una ACL personalizzata.
Poiché le ACL vengono applicate a una sottorete, è possibile utilizzarle come server virtuali per controllare il traffico da e verso le sottoreti VPC. Inoltre, è possibile creare sottoreti isolate, ad esempio per il traffico vSAN™, vMotion e TEP.
L'installazione predefinita utilizza un ACL predefinito (allow any) per l'intera VPC, ma è possibile personalizzarlo dopo l'installazione iniziale.
Per ulteriori informazioni sulle ACL, vedere Sicurezza in VPC. Per ulteriori informazioni sulle ACL con IBM Cloud bare metal server, vedere Introduzione alla rete di IBM Cloud bare metal server.
Gruppi di sicurezza con VMware
Un gruppo di sicurezza agisce come un firewall virtuale che controlla il traffico per una o più interfacce di rete del server virtuale e IBM Cloud interfacce PCI o VLAN del server bare metal. Un gruppo di sicurezza è un insieme di regole che specificano se consentire o negare il traffico per un'interfaccia associata. È possibile associare un'interfaccia a uno o più gruppi di sicurezza e modificare le regole del gruppo di sicurezza. È inoltre possibile utilizzare i gruppi di sicurezza come origine o destinazione nelle regole per creare regole più dinamiche senza specificare gli indirizzi IP.
In questo progetto, i gruppi di sicurezza vengono utilizzati per creare un raggruppamento logico dei tipi di traffico management, vSAN, vMotion e TEP, e applicare le regole per consentire i flussi di traffico richiesti. Vengono creati i seguenti gruppi di sicurezza:
| Nome del gruppo di sicurezza | Utilizzo |
|---|---|
sg-mgmt |
Apparati di gestione e host |
sg-vmot |
Adattatori del VMkernel per vMotion |
sg-vsan |
Adattatori VMkernel per vSAN |
sg-tep |
Adattatori VMkernel per TEP |
sg-uplink-pub |
Adattatori VMkernel per Tier-0 uplink pubblici |
sg-uplink-priv |
Adattatori VMkernel per Tier-0 uplink privati |
sg-bastion |
Adattatori VMkernel per host bastion (automazione VSI) |
Il principio di base delle regole predefinite è quello di consentire un minimo di praticità. Ad esempio, sg-vmot consente il traffico tra i membri del gruppo di sicurezza e il traffico in entrata icmp dal gruppo di
sicurezza sg-mgmt. Lo stesso principio si applica a tutti i gruppi di sicurezza utilizzati per gli adattatori VMkernel. sg-mgmt consente la connettività da reti private RFC 1918. Queste regole possono essere personalizzate
dopo l'accantonamento iniziale e le seguenti informazioni forniscono indicazioni e principi semplificati.
Quando si utilizzano i gruppi di sicurezza con le interfacce VLAN nelle macchine virtuali (VM) VMware, per evitare configurazioni errate e malintesi, è importante capire come il traffico fluisce da e verso i vSwitches, e quando il traffico attraversa gli host all'interno di questi vSwitches.
In un ambiente VMware, il traffico tra le interfacce di rete VLAN con lo stesso ID VLAN sullo stesso server bare metal viene solitamente inoltrato dai vSwitches all'interno dell'host ESXi. Se le macchine virtuali o le interfacce VMkernel si trovano sullo stesso host e utilizzano lo stesso gruppo di porte e lo stesso ID VLAN, il traffico non raggiunge la rete VPC.
Ad esempio, in un cluster VMware vSphere® composto da più host server bare metal, si configura un vSwitch distribuito. In questo caso, è possibile creare un gruppo di porte con ID VLAN 1611 e aggiungerlo allo specifico vSwitch.
Il traffico tra le vNICs di due macchine virtuali collegate al gruppo di porte 1611 è controllato dal vSwitch.
In questo esempio, ciò ha le seguenti conseguenze nelle distribuzioni di VMware Cloud Foundation:
- Le regole del Gruppo di sicurezza che controllano il traffico tra le interfacce di rete del Gruppo di porte VLAN ID
1611non vengono applicate se il traffico non lascia il vSwitch.
Inoltre, quando si lavora con i gruppi di sicurezza applicati agli uplink dei gateway NSX Tier 0 e al traffico di overlay NSX, è necessario definire regole basate sugli indirizzi IP, ad esempio:
- Quando si accede a una macchina virtuale su un overlay NSX con un indirizzo IP di
192.168.45.10da una macchina virtuale VMware (o da un VSI) sulla subnet VPC e si desidera consentire il traffico verso questo indirizzo IP, la regola del gruppo di sicurezza di origine deve corrispondere al traffico in uscita e il gruppo di sicurezza assegnato agli uplink del gateway Tier 0 deve corrispondere a quello in entrata. In questo caso, è necessario utilizzare un indirizzo IP o un CIDR per abbinare il traffico di overlay. - Quando una macchina virtuale su un overlay NSX con un indirizzo IP di
192.168.45.10deve comunicare con un vCenter o un manager SDDC, la regola del gruppo di sicurezza dei gateway uplink di livello 0 deve corrispondere al traffico in uscita e il gruppo di sicurezza assegnato all'interfaccia VLAN del vCenter o del manager SDDC deve corrispondere a questo in entrata. In questo caso, è necessario utilizzare un indirizzo IP o un CIDR per abbinare il traffico di overlay.
Per ulteriori informazioni sui gruppi di sicurezza, vedere La sicurezza nella VPC. Per ulteriori informazioni sui gruppi di sicurezza con IBM Cloud bare metal server, vedere Introduzione alla rete di IBM Cloud bare metal server.
Connettività pubblica con VMware VM sulla sottorete VPC
Il server Bare Metal per VPC fornisce il supporto completo per le funzioni di rete pubblica VPC. La connettività esterna può essere ottenuta utilizzando un Public Gateway collegato a una sottorete VPC, oppure utilizzando un indirizzo IP flottante collegato a un'interfaccia PCI o VLAN di un server bare metal. Il gateway pubblico utilizza la traduzione dell'indirizzo di rete di origine (SNAT) e un IP flottante utilizza la traduzione dell'indirizzo di rete di destinazione (DNAT). Queste funzioni sono identiche a quelle dei server virtuali VPC.
Le interfacce VLAN collegate a una sottorete VPC con un Public Gateway possono avviare connessioni a Internet, ma non possono ricevere connessioni da Internet. Public Gateway fornisce la connettività per un'intera sottorete e il traffico pubblico che ha origine dalle macchine virtuali su questa sottorete considera l'indirizzo IP Public Gateway come sorgente. Se la sottorete non è collegata a un Public Gateway, il traffico è completamente privato. In questo progetto, le sottoreti vSAN, vMotion, o TEP possono essere degli esempi.
Un'interfaccia VLAN con un IP flottante può avviare o ricevere connessioni da o verso Internet. L'IP flottante fornisce la connettività per una singola istanza. Questa azione sostituisce il Public Gateway di quella specifica interfaccia VLAN nella sottorete VPC, se questa è fornita a una sottorete con annesso Public Gateway.
Nelle distribuzioni di VMware Cloud Foundation, è necessario aggiungere una sottorete di gestione a un Public Gateway, che consente, ad esempio, al gestore dell'SDDC di essere aggiornato direttamente dai repository software pubblici di VMware.
Per ulteriori informazioni sull'overlay e sulla connettività pubblica NSX, vedere VMware NSX logical routers on VPC deployments e VMware NSX logical routing on VPC.