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 dei cloud privati con il seguente stack VMware componenti:

  • VMware ESXi: hypervisor su nodi dedicati
  • VMware vCenter: gestione centralizzata di vSphere nel cloud privato ambiente
  • 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 i dati e cloud computing

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. Consulta le Sezione Data center NSX per maggiori dettagli.
HCX 4.6.2 Aziende
1 VMware Engine esegue il deployment di una versione di HCX resa disponibile a Google Cloud tramite VMware. Aggiorna HCX dopo la creazione del cloud privato a recupera l'ultima versione di HCX per il tuo ambiente.

ESXi

Quando crei un cloud privato, VMware ESXi viene installato su provisioning dei nodi di Google Cloud VMware Engine. ESXi fornisce l'hypervisor per il deployment del carico di lavoro di macchine virtuali (VM). 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 in ogni rete. VMware Engine crea uno switch distribuito vSphere (VDS) su su vCenter utilizzando queste interfacce di rete fisiche come uplink. Rete sono configurate in modalità attiva per l'alta disponibilità.

Appliance vCenter Server

vCenter Server Appliance (VCSA) fornisce le funzionalità di autenticazione, gestione e di orchestrazione per VMware Engine. Quando crei ed esegui il deployment tuo cloud privato, VMware Engine esegue il deployment di una VCSA con Platform Services Controller (PSC) sul 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 vCenter Single Sign-On (SSO). Il nome di dominio è gve.local. Per accedere a vCenter, utilizza l'utente predefinito, CloudOwner@gve.local, che è stato creato per consentirti di accedere vCenter. Puoi aggiungere le origini di identità on-premise/di Active Directory per vCenter.

Archiviazione vSAN

I cluster nei cloud privati hanno uno spazio di archiviazione vSAN all-flash completamente configurato. La l'archiviazione all-flash è fornita da SSD locali. Almeno tre nodi dello stesso Gli SKU sono necessari per creare un cluster vSphere con un datastore vSAN. Ogni nodo il cluster vSphere ha due gruppi di dischi. Ogni gruppo di dischi contiene un disco cache e tre dischi di capacità.

Puoi attivare [deduplicazione e compressione]della deduplicazione VMware compressione sul datastore vSAN in VMware Engine. abilita la compressione vSAN per impostazione predefinita quando viene creato un nuovo cluster. Ciascuna su un cloud privato contiene un datastore vSAN. Se lo spazio di archiviazione non sono adatti per l'efficienza dello spazio vSAN mediante la deduplicazione e o solo tramite compressione, puoi modificare l'efficienza dello spazio vSAN configurazione scelta sul singolo datastore vSAN.

Oltre alle funzionalità avanzate di vSAN, VMware Engine fornisce accesso alla crittografia dei dati aziendali vSAN per i dati at-rest e in transito.

Criteri di archiviazione vSAN

Un criterio di archiviazione vSAN definisce Failures to Tolerate (FTT) e Metodo di tolleranza di errore. Puoi creare nuovi criteri di archiviazione e applicarli alle VM. Per mantenere lo SLA, devi mantenere il 20% della capacità di riserva sulla Datastore vSAN.

Su ogni cluster vSphere, è presente un criterio di archiviazione vSAN predefinito che si applica il datastore vSAN. I criteri relativi allo spazio di archiviazione determinano come eseguire il provisioning e l'allocazione 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:

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 necessari per abilitare il criterio:

FTT 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

Il data center NSX offre virtualizzazione di rete, microsegmentazione e di sicurezza sul tuo cloud privato. Puoi configurare i servizi supportato da NSX Data Center sul tuo cloud privato tramite NSX.

Funzionalità disponibili

Nell'elenco che segue vengono descritte le funzionalità di NSX-T supportate da VMware Engine, organizzato per categoria:

  • Cambio, 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
  • Calcolo dei percorsi:
    • 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 API REST
  • Ispezione:
    • Mirroring della porta
    • Traceflow
    • IPFIX basato su switch

Limitazioni delle funzionalità

Alcune funzionalità dei data center NSX prevedono un uso molto specifico della sicurezza e del networking d'uso diversi. Clienti che hanno creato il proprio account Google Cloud entro agosto 30 del 2022, possono richiedere l'accesso alle funzionalità per questi casi d'uso contattando Assistenza clienti Google Cloud.

La tabella seguente descrive queste funzionalità, i relativi casi d'uso e possibili 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 livello 3 Routing multicast di livello 3 multi-hop Il multicast di livello 2 è supportato all'interno di una subnet NSX-T. Ciò consente tutto il traffico multicast da distribuire ai carichi di lavoro sullo stesso NSX-T una subnet. Supportato Non supportato
Qualità del servizio (QoS) Applicazione VoIP e sensibile alla latenza in caso di oversubscription di rete si verifica Non è richiesta, poiché VMware Engine fornisce un modello per utenti dell'architettura di rete. Inoltre, tutti i tag QoS che escono da un cloud privato viene rimosso durante l'ingresso 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 Gli eventi e le sveglie possono essere configurate in NSX-T usando 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 su nord/sud e router logici est/ovest. Supportato Non supportato
Criteri di rete e sicurezza basati sull'intent Utilizzato in combinazione con VMware Aria per creare modelli Criteri firewall 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 I deployment VDI in cui l'utente ha eseguito l'accesso a un determinato guest VDI può ha rilevato e riceve un set personalizzato di regole firewall NSX-T Agli utenti possono essere assegnate workstation specifiche utilizzando di un pool di compiti dedicato. Usa i tag NSX-T per applicare un firewall specifico e regole per ogni pool. Supportato Non supportato
Regole degli attributi di livello 7 (ID app) Utilizzato nelle regole firewall NSX-T Utilizza le funzionalità di Gruppi di servizi NSX-T per definire un insieme di porte e servizi per un facile riferimento durante la creazione 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 nelle telecomunicazioni di grandi dimensioni deployment 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 di terze parti di rete usando NSX-T per proteggere e ispezionare il traffico Per le distribuzioni di fornitori di servizi di sicurezza di terze parti, VMware Engine consiglia un modello con routing all'inserimento del servizio per garantire che gli upgrade dei servizi non influiscono sulla disponibilità della rete. Contatta l'assistenza clienti Google Cloud Non supportato

Aggiornamenti e upgrade

Questa sezione descrive le considerazioni relative ad aggiornamenti ed upgrade e al ciclo di vita delle responsabilità nella gestione dei componenti software.

HCX

VMware Engine gestisce l'installazione iniziale, il monitoraggio di HCX nei cloud privati. Successivamente, sei responsabile gestione del ciclo di vita di HCX Cloud e appliance di servizio come HCX-IX e Partner Interconnect L3.

VMware fornisce aggiornamenti per HCX Cloud tramite il suo servizio HCX. Puoi eseguire l'upgrade HCX Manager e le appliance di servizio HCX distribuite dall’interfaccia HCX Cloud. A per trovare la data di fine del supporto per il rilascio di un prodotto, consulta la sezione Informazioni sul prodotto VMware Matrice del ciclo di vita.

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 e VMware. In base allo SLA, Google implementa la patch di sicurezza sul cloud privato entro una settimana.

Google fornisce aggiornamenti di manutenzione trimestrali dei 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.

Cluster vSphere

Per garantire l'alta disponibilità del cloud privato, gli host ESXi sono configurati come in un cluster Kubernetes. 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 e ne esegue il deployment VM in questo pool di risorse.

Impossibile eliminare il primo cluster per ridurre il cloud privato. vSphere utilizza vSphere HA per fornire disponibilità elevata per le VM. Errori di tollerati (FTT) si basano sul numero di nodi disponibili nel cluster. La La formula Number of nodes = 2N+1, dove N è il FTT, descrive 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 un singolo cluster. VMware Engine elimina i cloud privati che contengono solo un nodo dopo 60 giorni, insieme alle VM e ai dati dei carichi di lavoro associati.

Puoi ridimensionare un cloud privato a nodo singolo in modo che contenga 3 o più nodi. Quando in questo modo, VMware Engine avvia la replica dei dati vSAN e non tenta di eliminare il cloud privato. Un cloud privato deve contenere almeno 3 nodi e la replica completa dei dati vSAN in modo che sia idonea alla copertura in base lo SLA.

Le funzionalità o le operazioni che richiedono più di un nodo non funzioneranno con un singolo e nel cloud privato dei nodi. Ad esempio, non potrai utilizzare vSphere Distributed Pianificazione delle risorse (DRS) o Disponibilità elevata (HA).

Limiti dei cluster vSphere

La tabella seguente descrive i limiti dei cluster vSphere nei cloud privati che soddisfano 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 Versione ESXi nel cloud privato. Per un elenco di operatori ospiti supportati consulta la Guida alla compatibilità con VMware per il sistema operativo guest.

Manutenzione dell’infrastruttura VMware

A volte è necessario apportare modifiche alla configurazione del VMware dell'infrastruttura. Attualmente, questi intervalli possono verificarsi ogni 1-2 mesi, ma si prevede che la frequenza diminuisca nel tempo. Questo tipo di manutenzione, di solito, può essere eseguita senza interrompere il normale utilizzo i servizi di machine learning.

Durante un intervallo di manutenzione di VMware, i seguenti servizi continuano 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 un'unità di archiviazione esterna se vuoi solo e 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 su usando un'unità di archiviazione esterna.

Passaggi successivi