Rete di sottofondo

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.

Fine della commercializzazione: a partire dal 17 luglio 2025, non saranno più disponibili per i nuovi clienti nuove implementazioni di istanze VMware Regulated Workloads. Se siete un cliente esistente, potete ancora aggiungere o eliminare cluster, aggiungere o eliminare server ESXi™ VMware o storage NFS e aggiungere o rimuovere servizi per le istanze Regulated Workloads esistenti. Come cliente esistente, è possibile anche visualizzare o eliminare le istanze di Regulated Workloads.

IBM Cloud® per VMware® Regulated Workloads richiede una rete isolata tra i cluster dei carichi di lavoro e i cluster di gestione e gateway.

Cluster di gestione

Il cluster di gestione richiede due VLAN per supportare le funzioni di gestione.

Una VLAN comprende le sottoreti per la gestione di ESXi (vmk0) e i servizi di gestione come il server vCenter. L'appliance gateway stabilisce zone e criteri di sicurezza per controllare il flusso di traffico all'interno della VLAN tra le sottoreti. Il traffico non richiesto dagli host ESXi o bare metal non può raggiungere i sistemi di gestione. Il gateway perimetrale controlla il flusso di traffico da queste due sottoreti verso qualsiasi altra area esterna alla regione di gestione.

La seconda VLAN comprende le sottoreti dedicate a vMotion e vSAN. Non è consentito il routing tra queste sottoreti e la VLAN è isolata dal gateway perimetrale da tutte le altre zone e reti di sicurezza in un'implementazione a zona singola.

Cluster gateway

Il cluster gateway opzionale aggiunge alla soluzione due VLAN di rete di transito. Queste VLAN collegano il vSRX sia al router cliente back-end (BCR) per il traffico privato che al router cliente front-end (FCR) per i flussi di traffico pubblico (Internet). Se si desidera un'implementazione solo privata, la VLAN pubblica di transito non viene ordinata. La VLAN di gestione è collegata al cluster di gateway.

La progettazione della rete è fatta in questo modo per consentire al vSRX di controllare i flussi di traffico all'interno della zona di gestione e tra la zona di gestione e le IBM Cloud® reti private e pubbliche. Il design della rete di transito e della rete VLAN dell'appliance FortiGate è identico a quello utilizzato per il cluster di gateway.

Il vSRX in esecuzione sul cluster gateway collega la rete di gestione alle reti di transito private e pubbliche. Il vSRX è configurato per consentire solo il traffico in entrata o in uscita dalla regione di gestione necessario per il corretto funzionamento e monitoraggio dell'ambiente. Il vSRX isola anche tutto il traffico tra gli host ESXi e vCenter Server. Gli host ESXi all'interno di un cluster possono comunicare tra loro e con vCenter Server. Gli host ESXi di un cluster (carico di lavoro o gestione, ad esempio) non sono in grado di comunicare con gli host di altri cluster. La limitazione del traffico tra cluster viene applicata da vSRX e dalla configurazione dei firewall degli host ESXi.

Il cluster gateway è il punto di peering per il traffico tra il provider SaaS in sede e il Regulated Workloads. Serve anche come demarcazione per il traffico proveniente dal consumatore SaaS. Il provider SaaS utilizza il vSRX come endpoint del tunnel sicuro per la sua VPN.

Il traffico proveniente dal consumatore SaaS passa attraverso il vSRX in un tunnel crittografato, che arriva al dispositivo edge virtuale della rete overlay.

Cluster di carichi di lavoro

Il design della rete del cluster di carichi di lavoro è strettamente allineato a quello di un'implementazione tradizionale di vCenter Server. Le VLAN e le sottoreti vengono fornite per supportare vMotion, vSAN, le TEP per la rete Software-Defined Networking (SDN) e le funzioni di gestione degli host dei cluster di lavoro.

All'interno dei cluster di carichi di lavoro, NSX® fornisce una rete software-defined altamente sicura e flessibile per supportare i requisiti delle applicazioni. La gestione di NSX è esterna al cluster di carichi di lavoro, garantendo così che le modifiche alla rete e alla sicurezza non possano essere effettuate da persone diverse dagli amministratori designati. Tutti gli accessi di rete nord-sud nel cluster di carichi di lavoro avvengono tramite connessioni private e sicure utilizzando IPsec o IBM Direct Link. I cluster dei carichi di lavoro sono protetti dallo stesso cluster gateway con il vSRX o il FortiGate fisico che protegge il piano di gestione.

IBM Cloud in rete

La rete fisica di IBM Cloud è suddivisa in due reti distinte: pubblica e privata. La rete privata contiene anche il traffico IPMI (Intelligent Platform Management Interface) di gestione ai server fisici.

IBM Cloud rete di alto livello rete di alto livello rete di alto livello
IBM Cloud

Rete pubblica

IBM Cloud i data center e i punti di presenza della rete ( PoPs ) dispongono di connessioni multiple da 1 Gbps o 10 Gbps ai vettori di transito e di peering di alto livello. Il traffico di rete proveniente da qualsiasi parte del mondo si collega al PoP di rete più vicino e viaggia attraverso la rete direttamente verso il suo centro dati. In questo modo, il numero di salti di rete e di handoff tra i provider è ridotto al minimo.

All'interno del data center, IBM Cloud fornisce 1 Gbps o 10 Gbps di larghezza di banda di rete ai singoli server attraverso una coppia di switch front-end customer (FCS) separati e aggregati tra loro. Questi switch aggregati sono collegati a una coppia di router separati (FCR) per la rete L3.

Questo design multitier consente alla rete di scalare tra rack, file e pod all'interno di un data center IBM Cloud.

Rete privata

Tutti i data center di IBM Cloud e PoPs sono collegati dalla dorsale di rete privata. Questa rete privata è separata dalla rete pubblica e consente la connettività ai servizi dei data center IBM Cloud in tutto il mondo. Lo spostamento dei dati tra i data center di IBM Cloud avviene tramite connessioni multiple a 10 Gbps o 40 Gbps alla rete privata.

Analogamente alla rete pubblica, la rete privata è multilivello in quanto i server e gli altri componenti dell'infrastruttura sono collegati a switch cliente back-end aggregati (BCS). Questi switch aggregati sono collegati a una coppia di router BCR (back-end customer router) separati per la rete L3. La rete privata supporta anche la possibilità di utilizzare i frame Jumbo (MTU 9000) per connessioni all'host fisico.

Rete di gestione

Oltre alle reti pubbliche e private, ogni server IBM Cloud è connesso per la gestione alla sottorete della rete primaria privata. Questa connessione consente l'accesso IPMI (Intelligent Platform Management Interface) al server indipendentemente dalla CPU, dal firmware e dal sistema operativo per scopi di manutenzione e amministrazione.

Blocchi di IP primari e portatili

IBM Cloud assegna due tipi di indirizzi IP da utilizzare all'interno dell'infrastruttura IBM Cloud:

  • Gli indirizzi IP primari sono assegnati a dispositivi, server virtuali e Bare Metal forniti da IBM Cloud. Non assegnare manualmente alcun indirizzo IP in questi blocchi.
  • Gli indirizzi IP portatili ti vengono forniti per l'assegnazione e la gestione in base alle esigenze. L'automazione IBM Cloud per VMware Regulated Workloads prevede diversi intervalli IP portatili per il suo utilizzo. Utilizzare solo gli intervalli di indirizzi IP portatili assegnati a componenti NSX specifici e specificati per l'uso del provider SaaS.

Gli indirizzi IP primari o portatili possono essere resi instradabili a qualsiasi VLAN nel tuo account quando è configurato come un account VRF (Virtual Routing and Forwarding).

VRF (Virtual Routing and Forwarding)

L'account dell'infrastruttura IBM Cloud deve essere configurato come account VRF (Virtual Routing and Forwarding), che consente il routing globale automatico tra i blocchi IP della sottorete. Tutti gli account con connessioni Direct-Link devono essere convertiti o creati come account VRF.

Poiché varie opzioni di connettività e di instradamento della rete richiedono che l'account IBM Cloud sia in modalità VRF, si consiglia di farlo prima di eseguire il provisioning di Regulated Workloads.

Connessioni all'host fisico

Ogni host fisico in questa progettazione ha due coppie ridondanti di connessioni Ethernet da 10 Gbps in ogni switch (pubblico e privato) ToR (Top of Rack) di IBM Cloud. Gli adattatori sono configurati come connessioni individuali (non collegate) per un totale di 4 connessioni da 10 Gbps. Questa configurazione consente alle connessioni della scheda di interfaccia di rete (NIC) di funzionare indipendentemente l'una dall'altra.

La rimozione della connettività di rete fisica dalla rete privata o pubblica per i server bare metal utilizzati nell'offerta vCenter Server non è possibile. Le porte fisiche sulla NIC interna del bare metal possono essere disabilitate, ma non esiste un supporto per scollegare i cavi. Questa configurazione viene talvolta definita "air-gapped", abbreviazione delle azioni necessarie per garantire che le porte di rete pubbliche degli host ESXi siano disabilitate, che le porte ToR per tali connessioni siano disabilitate e che IBM Cloud IAM sia configurato in modo da impedire a chiunque non abbia privilegi sufficienti di abilitare le connessioni. Inoltre, la VLAN pubblica lato client viene assegnata al dispositivo gateway perimetrale e protetta per impedire il traffico da e verso la VLAN pubblica. Anche il gateway e le connessioni del gateway alla VLAN di transito pubblico (se presenti) sono amministrativamente disattivati (anziché scollegati), il che consente di monitorare qualsiasi tentativo di traffico in entrata o in uscita dalla VLAN di transito pubblico verso e dall'FCR.

Sebbene IBM Cloud offra un'opzione SSL VPN, questa opzione è sconsigliata e strettamente limitata a situazioni in cui l'accesso fuori banda ai carichi di lavoro regolamentati è essenziale.

Connessioni host fisiche
Connessioni host fisiche

VLAN e instradamento da quelle sottostanti a quelle di sovrapposizione

Le offerte VMware Solutions sono progettate con tre VLAN, una pubblica e due private, assegnate al momento della distribuzione. Come mostrato nella figura precedente, la VLAN pubblica è assegnata a eth1 e eth3 e le VLAN private sono assegnate a eth0 e eth2.

La VLAN pubblica e la prima VLAN privata create e assegnate in questa progettazione sono prive di tag per impostazione predefinita all'interno di IBM Cloud. Successivamente, la VLAN privata aggiuntiva viene collegata alle porte dello switch fisico e contrassegnata con tag all'interno dei gruppi di porte VMware che stanno utilizzando queste sottoreti.

![Connessioni](../../images/vrw-v2-net-physical-vlans.svg "" caption-side="bottom"}"){: caption="

In questa progettazione, la rete privata è composta da due VLAN. Alla prima di queste VLAN (indicata qui come VLAN privata A) sono assegnate tre sottoreti:

  • La prima sottorete è un intervallo di sottoreti di IP privati primari che IBM Cloud assegna agli host fisici.
  • La seconda subnet è utilizzata per le macchine virtuali (VM) di gestione, come vCenter Server Appliance e Platform Services Controller (PSC).
  • La terza subnet è utilizzata per i Tunnel Endpoint (TEP) della rete overlay incapsulata assegnati a ciascun host tramite NSX Manager.

Oltre alla VLAN privata A, esiste una seconda VLAN privata (qui denominata VLAN privata B) per supportare le funzioni di VMware come vSAN e vMotion. La VLAN viene quindi suddivisa in due o più sottoreti portatili:

  • La prima sottorete viene assegnata a un gruppo di porte kernel per il traffico vMotion.
  • La o le sottoreti rimanenti sono utilizzate per il traffico di archiviazione. Quando si utilizza vSAN,, una sottorete viene assegnata ai gruppi di porte del kernel che vengono utilizzati per il traffico di vSAN.

In questo progetto, la rete pubblica è costituita da una VLAN. Alla VLAN sono assegnate le seguenti sottoreti:

  • La prima subnet è un intervallo di subnet IP pubblico primario che IBM Cloud assegna agli host fisici.
  • Agli host viene assegnato un indirizzo IP pubblico ma questo indirizzo IP non è configurato sugli host, quindi non sono direttamente accessibili sulla rete pubblica.
  • La seconda subnet è utilizzata per l'accesso pubblico di componenti come un dispositivo gateway virtuale.
  • La VLAN pubblica è destinata all'accesso pubblico a Internet.

Tutte le sottoreti configurate come parte dell'implementazione automatica dei carichi di lavoro regolamentati utilizzano intervalli gestiti IBM Cloud per garantire che qualsiasi indirizzo IP possa essere instradato verso qualsiasi data center all'interno di IBM Cloud.

Rivedi la seguente tabella per un riepilogo

Riepilogo VLAN e subnet
VLAN Immettere Descrizione
Pubblico C Primario Assegnata agli host fisici per l'accesso alla rete pubblica.
Privata A Primario Sottorete singola assegnata agli host fisici assegnati da IBM Cloud. Utilizzata dall'interfaccia di gestione per il traffico di gestione vSphere.
Privata A Portatile Singola sottorete assegnata alle macchine virtuali che fungono da componenti di gestione
Privata A Portatile Singola subnet assegnata a NSX TEP
Privata B Portatile Sottorete singola assegnata per vSAN, se in uso
Privata B Portatile Sottorete singola assegnata per NAS, se in uso
Privata B Portatile Sottorete singola assegnata per vMotion

In questo progetto, tutti gli host e le macchine virtuali con supporto VLAN sono configurati per puntare al gateway perimetrale come percorso predefinito. Mentre le istanze Regulated Workloads consentono l'uso di SDN, le sovrapposizioni di rete create all'interno di un'istanza VMware che includono l'instradamento verso le sottoreti interne non sono conosciute dal gateway perimetrale a meno che non vengano configurati protocolli di instradamento dinamici o percorsi statici.

Le connessioni alla rete privata sono configurate per utilizzare una dimensione MTU dei frame Jumbo pari a 9000 per migliorare le prestazioni per trasferimenti di dati di grandi dimensioni, come archiviazione e vMotion. Questo valore è l'MTU massimo consentito da VMware e da IBM Cloud. Le connessioni alla rete pubblica utilizzano un MTU Ethernet standard di 1500, che deve essere mantenuto poiché qualsiasi modifica potrebbe causare la frammentazione dei pacchetti su Internet.