Componenti VMware per un cloud privato
Un cloud privato è un ambiente 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 di stack VMware:
- VMware ESXi: hypervisor su nodi dedicati
- VMware vCenter: gestione centralizzata dell'ambiente vSphere nel cloud privato
- VMware vSAN: piattaforma di archiviazione iper-convergente e software-defined
- VMware NSX Data Center: software di sicurezza e virtualizzazione 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 del componente VMware
Uno stack VMware cloud privato ha le seguenti versioni software:
| Componente | Versione | Versione con licenza |
|---|---|---|
| ESX | 7.0 Aggiorna 2c | vSphere Enterprise Plus |
| vCenter | 7.0 Aggiorna 2d | Standard vCenter |
| vSAN (vSAN) | 7.0 Aggiorna 2c | Funzionalità avanzate + funzionalità vSAN Enterprise |
| Data center NSX | 3,1,2 | Seleziona le funzionalità disponibili. Per maggiori dettagli, consulta la sezione Data center NSX. |
| HCX | 4,2,1 | Enterprise |
ESX
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 (elaborazione e archiviazione) e fanno parte del cluster vSphere sul tuo cloud privato.
Ogni nodo dispone di quattro interfacce di rete fisica collegate alla rete sottostante. VMware Engine crea uno switch distribuito vSphere (VDS) su vCenter utilizzando queste interfacce di rete fisica come uplink. Le interfacce di rete sono configurate in modalità attiva per l'alta disponibilità.
Appliance server vCenter
vCenter Server Appliance (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 dispone della propria VCSA. L'aggiunta di nodi a un cloud privato aggiunge nodi alla 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 te
per accedere a vCenter. Puoi aggiungere le tue origini identità per on-premise/Active Directory per vCenter.
Spazio di archiviazione vSAN
I cloud privati dispongono di uno spazio di archiviazione vSAN all-flash completamente configurato che è locale nel cluster. L'archiviazione all-Flash è fornita da SSD locali forniti dal servizio disco permanente di Google Cloud. 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à.
VMware Engine consente la deduzione e la compressione nel datastore vSAN per impostazione predefinita. Ogni cluster nel cloud privato contiene un datastore vSAN. Se i dati della macchina virtuale archiviata non sono adatti all'efficienza dello spazio vSAN mediante la deduplicazione e la compressione o solo per compressione, puoi modificare l'efficienza dello spazio vSAN nella configurazione desiderata sul singolo datastore vSAN.
Oltre alle funzionalità avanzate di vSAN, VMware Engine fornisce anche l'accesso alla crittografia dei dati vSAN Enterprise per i dati at-rest e in transito.
Criteri di archiviazione vSAN
Un criterio di archiviazione vSAN definisce i errori di tolleranza (FTT) e il metodo di tolleranza degli errori. 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 25% sul datastore vSAN.
In ogni cluster vSphere esiste un criterio di archiviazione vSAN predefinito che si applica al datastore vSAN. Il criterio di archiviazione determina 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 predefiniti del criterio di archiviazione vSAN:
| FTS | Metodo di tolleranza per errori | 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:
| FTS | Metodo di tolleranza per errori | Numero minimo di nodi richiesto nel cluster vSphere |
|---|---|---|
| 1 | RAID 1 (mirroring) | 3 |
| 1 | RAID 5 (codifica cancellabile) | 4 |
| 2 | RAID 1 (mirroring) | 5 |
| 2 | RAID 6 (codifica cancellabile) | 6 |
| 3 | RAID 1 (mirroring) | 7 |
Data center NSX
Il data center NSX offre funzionalità di virtualizzazione di rete, microsegmentazione e sicurezza di rete sul 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:
- Cambio, DNS, DHCP e IPAM (DDI):
- Apprendimento ARP e apprendimento ARP ottimizzati
- Replica unicast
- Replica front-end
- SpoofGuard
- Gestione degli indirizzi IP
- Blocchi IP
- Subnet IP
- Pool di IP
- Server DHCP IPv4
- Inoltro DHCP IPv4
- Associazioni statiche/indirizzi fissi DHCP IPv4
- Inoltro DNS/proxy DNS IPv4
- Routing:
- Route null
- 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 firewall comune
- Sezioni firewall
- Logging dei firewall
- Regole firewall stateful di livello 2 e di livello 3
- Regole basate su tag
- IPFIX distribuito basato su firewall
- Criteri, tag e gruppi di firewall:
- Tag di oggetti/tag di sicurezza
- Raggruppamento incentrato sulla rete
- Raggruppamento incentrato 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 solo con Tanzu Kubernetes Grid (TKG)
- Servizio VMware Cloud Director
- vRealize automazione
- Insight di vRealize log
- Autenticazione e autorizzazione:
- Integrazione diretta di Active Directory tramite LDAP
- Autenticazione tramite OpenLDAP
- Controllo degli accessi basato sui ruoli (RBAC)
- Automazione:
- API REST
- SDK Java
- SDK Python
- Provider Terraform
- Moduli Ansible
- Specifiche OpenAPI/Swagger e documentazione dell'API generata automaticamente per l'API REST
- Ispezione:
- Mirroring della porta
- Flusso di traccia
- IPFIX basato su Switch
Limitazioni delle funzionalità
Alcune funzionalità del data center NSX hanno 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.
Nella tabella seguente sono descritte le funzionalità, i casi d'uso corrispondenti e le potenziali alternative:
| Funzionalità | Caso d'uso | Alternativa consigliata | Clienti di Google Cloud entro il 30 agosto 2022 | Clienti di Google Cloud dopo il 30 agosto 2022 |
|---|---|---|---|---|
| Multicast di livello 3 | Routing multicast hop multi-hop | Il multicast di livello 2 è supportato in una subnet NSX-T. Ciò consente di distribuire tutto il traffico multicast ai carichi di lavoro sulla stessa subnet NSX-T. | Supportato | Non supportato |
| Qualità del servizio (QoS) | Applicazione sensibile al VoIP e alla latenza in cui si verifica l'oversubscription di rete | Nessuno richiesto, poiché VMware Engine offre un'architettura di rete senza abbonamento. Inoltre, tutti i tag QoS che escono da un cloud privato vengono rimossi quando entrano nel VPC tramite una connessione in peering. | Supportato | Non supportato |
| Trap SNMP (Simple Network Management Protocol) | Protocollo di avviso precedente per la notifica degli eventi | Gli eventi e le sveglie possono essere configurati all'interno di NSX-T utilizzando protocolli moderni. | Supportato | Non supportato |
| Funzionalità di NAT come NAT stateless, logging e NAT64 | Utilizzato per NAT di tipo operatore in grandi deployment di telecomunicazioni | NSX-T supporta i protocolli NAT di origine/destinazione e N:N NAT sui router logici nord/sud e est/ovest. | Supportato | Non supportato |
| Criteri di sicurezza e networking basati sull'intenzione | Utilizzato in combinazione con VMware vRealize per creare criteri firewall aziendali in NSX-T | Le funzionalità del gateway NSX-T e del firewall distribuito possono essere utilizzate per creare e applicare forzatamente 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 un guest VDI specifico possono essere rilevati e ricevere un set personalizzato di regole firewall NSX-T | Agli utenti possono essere assegnate workstation specifiche utilizzando il pool di assegnazione dedicato. Utilizza i tag NSX-T per applicare regole firewall specifiche in base al 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 set di porte e servizi per semplificare la consultazione quando crei una o più regole firewall. | Supportato | Non supportato |
| Regole firewall stateless di livello 2 e 3 | Utilizzato per firewall ad alta velocità di livello operatore nei grandi deployment di telecomunicazioni | NSX-T supporta le regole stateful di livello 2 e 3 ad alte prestazioni. | Supportato | Non supportato |
| Inserimento di servizio NSX-T | Utilizzate 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 dei fornitori di servizi di sicurezza di terze parti, VMware Engine consiglia un modello instradato rispetto all'inserimento di un servizio 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 hai eseguito il deployment dall'interfaccia di HCX Cloud. Per trovare la data di fine dell'assistenza per una release di prodotto, consulta la Matrice del ciclo di vita dei prodotti 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.
Non è possibile eliminare il primo cluster per ridurre il cloud privato. Il cluster vSphere utilizza vSphere HA per fornire disponibilità elevata per le VM. L'errore di tolleranza (FTT) si basa sul numero di nodi disponibili nel cluster. La formula Number of nodes = 2N+1, dove N è FTT, descrive la relazione tra i nodi disponibili in un cluster e FTT.
Per i carichi di lavoro di produzione, utilizza un cloud privato che contenga almeno tre nodi.
Cloud privati a nodo singolo
Per i test e le proof of concept con VMware Engine, puoi creare un cloud privato che contiene un solo nodo e cluster. VMware Engine elimina i cloud privati che contengono solo 1 nodo dopo 60 giorni, insieme a eventuali VM e dati dei carichi di lavoro associati.
Puoi ridimensionare un singolo cloud privato per contenere 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 una replica dei dati vSAN completa per essere idoneo alla copertura in base allo SLA.
Le funzionalità o le operazioni che richiedono più di un nodo non funzionano con un singolo cloud privato. Ad esempio, non potrai utilizzare vSphere Distributed Resource Scheduler (DRS) o alta disponibilità (HA).
Limiti del cluster vSphere
La seguente tabella descrive i limiti dei cluster vSphere nei cloud privati che soddisfano i requisiti 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 | 64 |
| Numero massimo di cluster per cloud privato | 21 |
Assistenza per il 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à con VMware per il sistema operativo guest.
Manutenzione dell'infrastruttura VMware
A volte è 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 di solito può 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 e applicazioni VMware
- 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 alla versione secondaria di un componente stack VMware
- Upgrade: modifica alla versione principale di un componente stack VMware
Google testa una patch di sicurezza critica non appena diventa disponibile da VMware. In base allo SLA, Google implementa la patch di sicurezza negli ambienti cloud privati entro una settimana.
Google fornisce aggiornamenti di manutenzione trimestrali ai componenti software VMware. Per una nuova versione principale della versione software VMware, Google collabora con i clienti per coordinare un periodo di manutenzione adatto per l'upgrade.
Passaggi successivi
- Scopri di più sulla manutenzione e sugli aggiornamenti del cloud privato