Componenti VMware per un cloud privato

Un cloud privato è un ambiente stack VMware isolato (host ESXi, vCenter, vSAN e NSX) gestito da un vCenter Server in un dominio di gestione. Google Cloud VMware Engine esegue il deployment di cloud privati con i seguenti componenti stack VMware:

  • VMware ESXi: hypervisor su nodi dedicati
  • VMware vCenter: gestione centralizzata dell'ambiente vSphere del cloud privato
  • VMware vSAN: piattaforma di archiviazione software-defined iperconvergente
  • Data center VMware NSX: software di virtualizzazione e sicurezza di rete
  • VMware HCX: migrazione delle applicazioni e ribilanciamento dei carichi di lavoro tra data center e cloud

Puoi recuperare le credenziali di accesso generate per i componenti dello stack VMware dalla pagina dei dettagli del cloud privato.

Versioni dei componenti VMware

Uno stack VMware per il cloud privato ha le seguenti versioni software:

Componente Versione Versione con licenza
ESXi 7.0 Aggiornamento 2c vSphere Enterprise Plus
vCenter 7.0 Aggiornamento 2d Standard vCenter
vSAN 7.0 Aggiornamento 2c Avanzate + seleziona funzionalità vSAN Enterprise
Data center NSX 3.1.2 Seleziona le funzionalità disponibili. Per ulteriori dettagli, consulta la sezione Data center NSX.
HCX 4.5 Enterprise
1VMware Engine esegue il deployment di una versione di HCX resa disponibile in Google Cloud by VMware. Aggiorna HCX dopo la creazione del cloud privato per recuperare la versione più recente di HCX per il tuo ambiente.

ESXi

Quando crei un cloud privato, VMware ESXi viene installato sui nodi Google Cloud VMware Engine di cui è stato eseguito il provisioning. ESXi fornisce l'hypervisor per il deployment delle macchine virtuali (VM) dei carichi di lavoro. I nodi forniscono un'infrastruttura iperconvergente (computing e archiviazione) e fanno parte del cluster vSphere sul tuo cloud privato.

Ogni nodo ha quattro interfacce di rete fisiche collegate alla rete sottostante. VMware Engine crea uno switch distribuito vSphere (VDS) su vCenter utilizzando queste interfacce di rete fisiche come uplink. Le interfacce di rete sono configurate in modalità attiva per l'alta disponibilità.

Appliance server vCenter

L'appliance vCenter Server (VCSA) fornisce le funzioni di autenticazione, gestione e orchestrazione per VMware Engine. Quando crei ed esegui il deployment del tuo cloud privato, VMware Engine esegue il deployment di una VCSA con un Platform Services Controller (PSC) incorporato nel cluster vSphere. Ogni cloud privato ha una propria VCSA. L'aggiunta di nodi a un cloud privato comporta l'aggiunta di nodi a VCSA.

Single Sign-On vCenter

Il controller dei servizi della piattaforma incorporata su VCSA è associato a un Single Sign-On vCenter. Il nome di dominio è gve.local. Per accedere a vCenter, utilizza l'utente predefinito, CloudOwner@gve.local, creato per consentirti di accedere a vCenter. Puoi aggiungere le tue origini identità on-premise/Active Directory per vCenter.

Spazio di archiviazione vSAN

I cluster nei cloud privati hanno un'archiviazione vSAN all-Flash completamente configurata. L'archiviazione all-Flash è fornita da SSD locali. Per creare un cluster vSphere con un datastore vSAN, sono necessari almeno tre nodi dello stesso SKU. Ogni nodo del cluster vSphere ha due gruppi di dischi. Ogni gruppo di dischi contiene un disco cache e tre dischi di capacità.

Puoi abilitare la compressione per la deduplicazione e la compressione VMware sul datastore vSAN in VMware Engine.Questo servizio attiva la compressione vSAN per impostazione predefinita quando viene creato un nuovo cluster. Ogni cluster sul tuo cloud privato contiene un datastore vSAN. Se i dati delle macchine virtuali archiviate non sono adatti all'efficienza dello spazio vSAN tramite deduplicazione e compressione o solo per compressione, puoi modificare l'efficienza dello spazio vSAN nella configurazione desiderata sul singolo datastore vSAN.

Oltre alle funzionalità vSAN Advanced, VMware Engine fornisce anche l'accesso alla crittografia dei dati di vSAN Enterprise per i dati at-rest e in transito.

Criteri di archiviazione vSAN

Un criterio di archiviazione vSAN definisce i valori Failures to tolerate (FTT) e Failure sustainability method. Puoi creare nuovi criteri di archiviazione e applicarli alle VM. Per mantenere lo SLA (accordo sul livello del servizio), devi mantenere una capacità di riserva del 20% sul datastore vSAN.

Su ogni cluster vSphere, è presente un criterio di archiviazione vSAN predefinito che si applica al datastore vSAN. I criteri di archiviazione determinano come eseguire il provisioning e allocare gli oggetti di archiviazione delle VM all'interno del datastore per garantire un livello di servizio.

La tabella seguente mostra i parametri del criterio di archiviazione vSAN predefiniti:

FTT Metodo di tolleranza di errore Numero di nodi nel cluster vSphere
1 RAID 1 (Mirroring)
Crea 2 copie		 3 e 4 nodi
2 RAID 1 (Mirroring)
Crea 3 copie		 da 5 a 32 nodi

Criteri di archiviazione vSAN supportati

La tabella seguente mostra i criteri di archiviazione vSAN supportati e il numero minimo di nodi richiesti per abilitare il criterio:

FTT Metodo di tolleranza di errore Numero minimo di nodi richiesto nel cluster vSphere
1 RAID 1 (Mirroring) 3
1 RAID 5 (codifica della cancellazione) 4
2 RAID 1 (Mirroring) 5
2 RAID 6 (codifica della cancellazione) 6
3 RAID 1 (Mirroring) 7

Data center NSX

Il data center NSX offre funzionalità di virtualizzazione della rete, micro-segmentazione e sicurezza della rete sul tuo cloud privato. Puoi configurare i servizi supportati da NSX Data Center sul tuo cloud privato utilizzando NSX.

Funzionalità disponibili

Il seguente elenco descrive le funzionalità NSX-T supportate da VMware Engine, organizzate per categoria:

  • Passaggio, DNS, DHCP e IPAM (DDI):
    • Apprendimento ARP ottimizzato e soppressione delle trasmissioni
    • Replica Unicast
    • Replica head-end
    • SpoofGuard
    • Gestione degli indirizzi IP
    • Blocchi IP
    • Subnet IP
    • Pool IP
    • Server DHCP IPv4
    • Inoltro DHCP IPv4
    • Associazioni statiche/indirizzi fissi da DHCP IPv4
    • Relay DNS/proxy DNS IPv4
  • Routing:
    • Route nulle
    • Routing statico
    • Routing del dispositivo
    • Controlli di route BGP utilizzando mappe di route ed elenchi di prefissi
  • NAT:
    • NAT su router logici nord/sud e est/ovest
    • NAT di origine
    • NAT di destinazione
    • N:N NAT
  • Firewall:
    • Firewall perimetrale
    • Firewall distribuito
    • Interfaccia utente comune del firewall
    • Sezioni firewall
    • Logging dei firewall
    • Regole firewall di livello 2 e 3
    • Regole basate su tag
    • IPFIX distribuito basato su firewall
  • Criteri, tag e gruppi firewall:
    • Tagging degli oggetti/tag di sicurezza
    • Raggruppamento basato sulla rete
    • Raggruppamento basato sul carico di lavoro
    • Raggruppamento basato su IP
    • Raggruppamento basato su MAC
  • VPN:
    • VPN di livello 2
    • VPN di livello 3 (IPv4)
  • Integrazioni:
    • Networking e sicurezza dei container utilizzando solo la griglia Tanzu Kubernetes (TKG)
      • Servizio VMware Cloud Director
    • Automazione VMware Aria
    • Operazioni di VMware Aria per i log
  • Autenticazione e autorizzazione:
    • Integrazione diretta di Active Directory mediante LDAP
    • Autenticazione tramite OpenLDAP
    • Controllo degli accessi basato sui ruoli (RBAC)
  • Automation:
    • API REST
    • SDK Java
    • SDK Python
    • Provider Terraform
    • Moduli Ansible
    • Specifiche OpenAPI/Swagger e documentazione API generata automaticamente per l'API REST
  • Ispezione:
    • Mirroring della porta
    • Traceflow
    • IPFIX basato su switch

Limitazioni delle funzionalità

Alcune funzionalità dei data center di NSX presentano casi d'uso di networking e sicurezza molto specifici. I clienti che hanno creato il proprio account Google Cloud entro il 30 agosto 2022 possono richiedere l'accesso alle funzionalità per questi casi d'uso contattando l'assistenza clienti Google Cloud.

La seguente tabella descrive queste funzionalità, i relativi casi d'uso e le potenziali alternative:

Funzionalità Caso d'uso Alternativa consigliata Clienti Google Cloud entro il 30 agosto 2022 Clienti di Google Cloud dopo il 30 agosto 2022
Multicast di livello 3 Routing multicast di livello 3 con più hop Il multicast di livello 2 è supportato all'interno di una subnet NSX-T. In questo modo, tutto il traffico multicast può essere distribuito a carichi di lavoro sulla stessa subnet NSX-T. Supportato Non supportato
Qualità del servizio (QoS) Applicazione VoIP e sensibile alla latenza in cui si verifica una sottoscrizione eccessiva della rete Non è necessario, perché VMware Engine offre un'architettura di rete senza abbonamenti in eccesso. Inoltre, tutti i tag QoS in uscita da un cloud privato vengono rimossi quando si accede al VPC tramite una connessione in peering. Supportato Non supportato
Trap SNMP (Semplici Network Management Protocol) Protocollo di avviso legacy per la notifica agli utenti degli eventi Eventi e allarmi possono essere configurati all'interno di NSX-T utilizzando protocolli moderni. Supportato Non supportato
Funzionalità di NAT come NAT stateless, logging NAT e NAT64 Utilizzato per NAT di livello operatore in grandi implementazioni di telecomunicazioni NSX-T supporta NAT di origine/destinazione e N:N NAT su router logici Nord/Sud e Est/Ovest. Supportato Non supportato
Criteri di sicurezza e networking basati su intent Utilizzata in combinazione con VMware Aria per creare criteri firewall basati su business in NSX-T È possibile utilizzare le funzionalità gateway NSX-T e Distributed Firewall per creare e applicare i criteri di sicurezza. Supportato Non supportato
Gruppi basati sull'identità che utilizzano Active Directory I deployment VDI in cui l'utente ha eseguito l'accesso a uno specifico guest VDI possono essere rilevati e possono ricevere un set personalizzato di regole firewall NSX-T Agli utenti possono essere assegnate workstation specifiche utilizzando il pool di assegnazioni dedicato. Utilizza i tag NSX-T per applicare regole firewall specifiche per pool. Supportato Non supportato
Regole per l'attributo di livello 7 (ID app) Utilizzato nelle regole firewall NSX-T Utilizza i gruppi di servizi NSX-T per definire un insieme di porte e servizi di facile riferimento durante la creazione di una o più regole firewall. Supportato Non supportato
Regole firewall di livello 2 e 3 stateless Utilizzato per firewall ad alta velocità di livello operatore in grandi deployment di telecomunicazioni NSX-T supporta regole stateful di livello 2 e di livello 3 ad alte prestazioni. Supportato Non supportato
Inserimento servizio NSX-T Utilizzato per automatizzare il deployment nord/sud o est/ovest di servizi di rete di terze parti utilizzando NSX-T per proteggere e ispezionare il traffico Per i deployment di fornitori di sicurezza di terze parti, VMware Engine consiglia un modello con routing all'inserimento dei servizi per garantire che gli upgrade dei servizi di routine non influiscano sulla disponibilità della rete. Contatta l'assistenza clienti Google Cloud Non supportato

HCX

VMware Engine gestisce l'installazione iniziale, la configurazione e il monitoraggio di HCX nei cloud privati. Sei responsabile della gestione del ciclo di vita di HCX Cloud e delle appliance di servizio come HCX-IX Interconnect.

VMware fornisce aggiornamenti per HCX Cloud tramite il suo servizio HCX. Puoi eseguire l'upgrade di HCX Manager e delle appliance di servizio HCX di cui è stato eseguito il deployment dall'interfaccia HCX Cloud. Per conoscere la data di fine dell'assistenza per una release di prodotto, consulta la pagina Matrice del ciclo di vita del prodotto VMware.

Cluster vSphere

Per garantire l'alta disponibilità del cloud privato, gli host ESXi sono configurati come cluster. Quando crei un cloud privato, VMware Engine esegue il deployment dei componenti di gestione di vSphere sul primo cluster. VMware Engine crea un pool di risorse per i componenti di gestione ed esegue il deployment di tutte le VM di gestione in questo pool di risorse.

Impossibile eliminare il primo cluster per ridurre il cloud privato. Il cluster vSphere utilizza vSphere ad alta disponibilità per fornire alta disponibilità per le VM. Gli errori di tollerabilità (FTT) si basano sul numero di nodi disponibili nel cluster. La formula Number of nodes = 2N+1, dove N è il FTT, descrive la relazione tra i nodi disponibili in un cluster e in FTT.

Per i carichi di lavoro di produzione, utilizza un cloud privato che contenga almeno 3 nodi.

Cloud privati a nodo singolo

Per i test e i proof of concept con VMware Engine, puoi creare un cloud privato che contiene solo un singolo nodo e cluster. VMware Engine elimina i cloud privati che contengono solo un nodo dopo 60 giorni, insieme a eventuali VM e dati dei carichi di lavoro associati.

Puoi ridimensionare un cloud privato a nodo singolo in modo che contenga 3 o più nodi. In questo caso, VMware Engine avvia la replica dei dati vSAN e non tenta più di eliminare il cloud privato. Un cloud privato deve contenere almeno 3 nodi e completare la replica dei dati vSAN per essere idoneo alla copertura in base allo SLA.

Le funzionalità o le operazioni che richiedono più di un nodo non funzioneranno con un cloud privato a nodo singolo. Ad esempio, non potrai utilizzare vSphere Distributed Resource Scheduler (DRS) o l'alta disponibilità (HA).

Limiti dei cluster vSphere

La seguente tabella descrive i limiti dei cluster vSphere nei cloud privati che soddisfano i requisiti dello SLA:

Risorsa Limite
Numero minimo di nodi per creare un cloud privato (primo cluster) 3
Numero minimo di nodi per creare un cluster 3
Numero massimo di nodi per cluster 32
Numero massimo di nodi per cloud privato 110
Numero massimo di cluster per cloud privato 21

Supporto del sistema operativo guest

Puoi installare una VM con qualsiasi sistema operativo guest supportato da VMware per la versione ESXi nel tuo cloud privato. Per un elenco dei sistemi operativi guest supportati, consulta la Guida alla compatibilità di VMware per il sistema operativo guest.

Manutenzione dell'infrastruttura VMware

Occasionalmente è necessario apportare modifiche alla configurazione dell'infrastruttura VMware. Attualmente, questi intervalli possono verificarsi ogni 1-2 mesi, ma la frequenza dovrebbe diminuire nel tempo. Questo tipo di manutenzione può in genere essere eseguito senza interrompere il normale utilizzo dei servizi.

Durante un intervallo di manutenzione VMware, i seguenti servizi continuano a funzionare senza alcun effetto:

  • Piano di gestione VMware e applicazioni
  • Accesso a vCenter
  • Tutto il networking e lo spazio di archiviazione
  • Tutto il traffico cloud

Aggiornamenti e upgrade

Google è responsabile della gestione del ciclo di vita del software VMware (ESXi, vCenter, PSC e NSX) nel cloud privato.

Gli aggiornamenti software includono:

  • Patch:patch di sicurezza o correzioni di bug rilasciate da VMware
  • Aggiornamenti: modifica di minore entità alla versione di un componente stack VMware
  • Upgrade:modifica principale della versione di un componente dello stack VMware

Google testa una patch di sicurezza critica non appena diventa disponibile da VMware. In base allo SLA (accordo sul livello del servizio), Google implementa la patch di sicurezza negli ambienti cloud privato entro una settimana.

Google fornisce aggiornamenti di manutenzione trimestrali per i componenti software VMware. Per una nuova versione principale del software VMware, Google collabora con i clienti per coordinare un periodo di manutenzione adeguato per l'upgrade.

Spazio di archiviazione esterno

Puoi espandere la capacità di archiviazione di un cluster Google Cloud VMware Engine aggiungendo altri nodi. In alternativa, puoi usare l'unità di archiviazione esterna se vuoi solo scalare lo spazio di archiviazione. La scalabilità dell'archiviazione aumenta la capacità di archiviazione senza aumentare quella del cluster, consentendoti di scalare le risorse in modo indipendente.

Contatta l'Assistenza Google o il tuo rappresentante di vendita per ulteriori informazioni sull'utilizzo dell'unità di archiviazione esterna.

Passaggi successivi