Componenti VMware per un cloud privato
Un cloud privato è uno stack VMware isolato (host ESXi, vCenter, vSAN e NSX) gestito da un server vCenter 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 iperconvergente e software-defined
- 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 cloud privato ha le seguenti versioni software:
| Componente | Versione | Versione con licenza |
|---|---|---|
| ESXi | 7.0 Update 3o | vSphere Enterprise Plus |
| vCenter | 7.0 Aggiornamento di terze parti | Standard vCenter |
| vSAN | 7.0 Update 3o | Funzionalità vSAN Enterprise avanzate e selezionate |
| Data center NSX | 3.2.3.1.hp | Alcune funzionalità disponibili. Per informazioni dettagliate, consulta la sezione Data center NSX. |
| HCX | 4.6.2 | Grandi aziende |
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 di 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) in vCenter utilizzando queste interfacce di rete fisiche come uplink. Le interfacce di rete sono configurate in modalità attiva per l'alta disponibilità.
Appliance vCenter Server
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 ha una propria VCSA. L'aggiunta di nodi a un cloud privato comporta l'aggiunta di nodi alla VCSA.
Single Sign-On vCenter
Il controller dei servizi di piattaforma incorporati 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 di identità per vCenter on-premise/di Active Directory.
Archiviazione vSAN
I cluster nei cloud privati hanno uno spazio di archiviazione vSAN all-flash completamente configurato. Lo spazio di archiviazione all-flash è fornito 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 [deduplicazione e compressione]della compressione deduplicazione VMware nel datastore vSAN in VMware Engine.Questo servizio abilita la compressione vSAN per impostazione predefinita quando viene creato un nuovo cluster. Ogni cluster sul cloud privato contiene un datastore vSAN. Se i dati di macchine virtuali archiviate non sono adatti per l'efficienza dello spazio vSAN mediante deduplicazione e compressione o solo mediante compressione, puoi modificare l'efficienza dello spazio vSAN impostandola sulla configurazione scelta per il singolo datastore vSAN.
Oltre alle funzionalità avanzate di vSAN, VMware Engine fornisce anche accesso alla crittografia dei dati aziendali di vSAN per i dati at-rest e in transito.
Criteri di archiviazione vSAN
Un criterio di archiviazione vSAN definisce gli attributi FTT (Failures to Tolerate, errori da tollerare) e Metodo di tolleranza degli errori. Puoi creare nuovi criteri di archiviazione e applicarli alle VM. Per mantenere lo SLA, devi mantenere il 20% della capacità di riserva sul datastore vSAN.
Su ogni cluster vSphere è presente un criterio di archiviazione vSAN predefinito che si applica al datastore vSAN. Il criterio di archiviazione determina come eseguire il provisioning e l'allocazione di oggetti di archiviazione delle VM all'interno del datastore per garantire un livello di servizio.
La tabella seguente mostra i parametri predefiniti dei criteri di archiviazione vSAN:
| TL | 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 necessario per abilitare il criterio:
| TL | Metodo di tolleranza di errore | Numero minimo di nodi richiesti 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
NSX Data Center fornisce funzionalità di virtualizzazione di rete, microsegmentazione e sicurezza di rete sul tuo cloud privato. Puoi configurare i servizi supportati da NSX Data Center sul tuo cloud privato utilizzando NSX.
Funzionalità disponibili
Nell'elenco seguente sono descritte le funzionalità di NSX-T supportate da VMware Engine, organizzate per categoria:
- Commutazione, DNS, DHCP e IPAM (DDI):
- Ottimizzazione dell'apprendimento ARP ed eliminazione 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 DHCP IPv4
- Relay DNS/proxy DNS IPv4
- Routing:
- Route null
- Routing statico
- Routing dei dispositivi
- Controlli delle 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
- NAT N:N
- Firewall:
- Firewall perimetrale
- Firewall distribuito
- Interfaccia utente firewall comune
- Sezioni del 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 incentrato sulla rete
- Raggruppamento incentrato sui carichi 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
- Automazione VMware Aria
- VMware Aria Operations per i log
- Autenticazione e autorizzazione:
- Integrazione diretta di Active Directory tramite LDAP
- Autenticazione con 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 NSX prevedono casi d'uso molto specifici in termini di networking e sicurezza. 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 potenziali alternative:
| Selezione delle | Caso d'uso | Alternativa consigliata | Clienti Google Cloud entro il 30 agosto 2022 | Clienti di Google Cloud dopo il 30 agosto 2022 |
|---|---|---|---|---|
| Multicast livello 3 | Routing multicast di livello 3 multi-hop | Il multicast di livello 2 è supportato all'interno di una subnet NSX-T. In questo modo, tutto il traffico multicast viene distribuito ai 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 l'oversubscription della rete | Non è richiesta, poiché VMware Engine fornisce un'architettura di rete con sottoscrizione non eccessiva. Inoltre, tutti i tag QoS che escono da un cloud privato vengono eliminati quando si entra nel VPC tramite una connessione in peering. | Supportato | Non supportato |
| Trap SNMP (Simple Network Management Protocol) | Protocollo di avviso legacy per informare gli utenti di eventi | Eventi e allarmi possono essere configurati all'interno di NSX-T utilizzando protocolli moderni. | Supportato | Non supportato |
| Funzionalità 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 NAT N:N sui router logici nord/sud e est/ovest. | Supportato | Non supportato |
| Criteri di rete e sicurezza basati sull'intent | Utilizzato in combinazione con VMware Aria per creare criteri firewall basati sull'azienda all'interno di NSX-T | Le funzionalità NSX-T Gateway e Distributed Firewall possono essere utilizzate per creare e applicare criteri di sicurezza. | Supportato | Non supportato |
| Gruppi basati sull'identità che utilizzano Active Directory | Deployment VDI in cui l'utente che ha eseguito l'accesso a un guest VDI specifico può essere rilevato e ricevere un set personalizzato di regole firewall NSX-T | Agli utenti possono essere assegnate workstation specifiche utilizzando il pool di compiti dedicato. Utilizza i tag NSX-T per applicare regole firewall specifiche in base al pool. | Supportato | Non supportato |
| Regole degli attributi 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 di riferimento durante la creazione di una o più regole firewall. | Supportato | Non supportato |
| Regole firewall stateless di livello 2 e livello 3 | Utilizzato per firewall ad alta velocità di livello operatore in grandi implementazioni di telecomunicazioni | NSX-T supporta le regole stateful di livello 2 e 3 ad alte prestazioni. | Supportato | Non supportato |
| Inserimento servizio NSX-T | Utilizzato per automatizzare il deployment nord/sud o est/ovest dei 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 del servizio per garantire che gli upgrade di routine dei servizi non influiscano sulla disponibilità della rete. | Contatta l'assistenza clienti Google Cloud | Non supportato |
Aggiornamenti e upgrade
Questa sezione descrive le considerazioni relative all'aggiornamento e all'upgrade e le responsabilità di gestione del ciclo di vita dei componenti software.
HCX
VMware Engine gestisce l'installazione, la configurazione e il monitoraggio iniziali di HCX nei cloud privati. Successivamente, 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 trovare la data di fine del supporto per il rilascio di un prodotto, consulta la matrice del ciclo di vita del prodotto VMware.
Altro software VMware
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 secondaria della versione di un componente dello 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 dei componenti software VMware. Per una nuova versione principale della versione software VMware, Google collabora con i clienti per coordinare un periodo di manutenzione adeguato per l'upgrade.
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 HA per fornire disponibilità elevata per le VM. I errori tollerati (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 il 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 un singolo cluster. VMware Engine elimina i cloud privati che contengono un solo nodo dopo 60 giorni, insieme a tutti i dati e le VM 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. Per essere idoneo alla copertura in base allo SLA, un cloud privato deve contenere almeno 3 nodi e completare la replica dei dati vSAN.
Le funzionalità o le operazioni che richiedono più di un nodo non funzioneranno con un cloud privato a singolo nodo. Ad esempio, non potrai utilizzare vSphere Distributed Resource Scheduler (DRS) o Highavailability (HA).
Limiti dei cluster vSphere
La tabella seguente 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 | 96 |
| 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à 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 si prevede che la frequenza diminuisca nel tempo. Questo tipo di manutenzione solitamente può essere eseguito senza interrompere il normale utilizzo dei servizi.
Durante un intervallo di manutenzione di VMware, i seguenti servizi continuano a funzionare senza alcun effetto:
- Piano di gestione e applicazioni VMware
- Accesso a vCenter
- Tutte le funzionalità di networking e archiviazione
- Tutto il traffico cloud
Spazio di archiviazione esterno
Puoi espandere la capacità di archiviazione di un cluster Google Cloud VMware Engine aggiungendo più nodi. In alternativa, puoi usare la memoria esterna se vuoi solo scalare l'archiviazione. La scalabilità dell'archiviazione aumenta la capacità di archiviazione senza aumentare la capacità di calcolo 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
- Scopri di più sulla manutenzione e sugli aggiornamenti del cloud privato