I Virtual Private Cloud (VPC) NSX costituiscono un livello di astrazione che semplifica la configurazione di reti cloud private virtuali autonome all'interno di un progetto NSX definito dall'utente per utilizzare i servizi di rete e sicurezza in un modello di consumo self-service.
I VPC di NSX rappresentano un ulteriore livello di multi-tenancy all'interno di un progetto. Forniscono un modello di consumo semplificato dei servizi di rete e sicurezza, che è allineato all'esperienza che si avrebbe in un ambiente cloud pubblico.
Un VPC NSX nasconde ai proprietari delle applicazioni la complessità dell'infrastruttura NSX sottostante, la topologia di rete, gli oggetti di rete e la gestione degli indirizzi IP, offrendo loro un modello di consumo self-service per eseguire le applicazioni nel proprio spazio privato.
I proprietari delle applicazioni o gli ingegneri DevOps non devono conoscere l'infrastruttura di NSX sottostante per poter eseguire le applicazioni all'interno del proprio spazio isolato. Possono aggiungere subnet (reti) nel VPC NSX loro assegnato e configurare criteri di sicurezza che soddisfino i requisiti delle applicazioni senza dover dipendere dall'amministratore aziendale.
I VPC NSX sono facoltativi in un progetto. Il diagramma seguente illustra due progetti nell'organizzazione. Il progetto 1 contiene VPC NSX, mentre il progetto 2 non contiene alcun VPC NSX.
Il diagramma seguente mostra una vista logica di esempio di un VPC NSX all'interno del progetto 1. Entrambi i progetti 1 e 2 sono connessi allo stesso gateway VRF di livello 0 o di livello 0.
- Subnet app (privata)
- Subnet Web (pubblica)
- Subnet di prova (isolata)
- Amministratore della sicurezza
- Operatore di rete
- Operatore della sicurezza
Quando viene creato un VPC NSX, l'amministratore del progetto specifica i blocchi di IP esterni e i blocchi di IP privati da utilizzare per la creazione delle subnet nel VPC. Le modalità di accesso alla subnet supportate sono Privato, Pubblico e Isolato. Per ulteriori informazioni sulle modalità di accesso alla subnet, vedere la sezione Modalità d accesso per le subnet VPC NSX più avanti in questa documentazione.
Quando un VPC NSX viene creato correttamente, il sistema crea implicitamente un gateway. Tuttavia, questo gateway implicito viene esposto all'amministratore del progetto in modalità di sola lettura e non è visibile per gli utenti di VPC NSX.
Il ciclo di vita di questo gateway implicito viene gestito dal sistema. Quando si elimina un VPC NSX, il gateway implicito viene eliminato automaticamente.
Nel modello di dati del criterio NSX, gli oggetti VPC NSX vengono creati nei progetti nel percorso seguente:
/orgs/default/projects/<project_id>/vpcs/<vpc-id>
Il gateway implicito realizzato si trova nel percorso seguente:
/orgs/default/projects/<project_id>/infra/tier-1s/
Esempio di un VPC NSX
Si supponga che l'organizzazione abbia creato un progetto denominato "Vendite" nel proprio ambiente NSX. L'obiettivo dell'amministratore del progetto è fornire un ambiente di rete e sicurezza isolato per gli sviluppatori delle applicazioni "Gestione ordini" e "Analisi" nella BU Vendite.
Gli sviluppatori di applicazioni richiedono la possibilità di eseguire il provisioning delle reti e configurare i criteri di sicurezza per queste due applicazioni in un modello di consumo self-service e senza alcuna dipendenza dall'amministratore aziendale o dall'amministratore del progetto.
Per raggiungere questo obiettivo, l'amministratore del progetto può creare due VPC NSX all'interno del progetto "Vendite" e assegnare questi VPC NSX agli sviluppatori delle applicazioni.
Ad esempio:
| Nome VPC | Utenti VPC | Blocchi indirizzi IP |
|---|---|---|
| Gestione ordini | Jim: amministratore VPC Bob: operatore di rete Carol: operatore della sicurezza |
Blocco IPv4 privato: 172.16.0.0/24 Blocco IPv4 esterno: 192.168.1.0/24 |
| Analisi | Mike: amministratore VPC Steve: operatore di rete Maria: operatore della sicurezza |
Blocco IPv4 privato: 172.18.0.0/24 Blocco IPv4 esterno: 192.168.1.0/24 |
Dopo aver assegnato i ruoli agli utenti VPC NSX, questi utenti possono aggiungere subnet all'interno del VPC NSX e configurare criteri di protezione per questi carichi di lavoro. I criteri di sicurezza influiscono solo sui carichi di lavoro all'interno del VPC NSX e non all'esterno del VPC NSX.
Ad esempio, il diagramma seguente mostra tre subnet denominate Sviluppo, Test e Produzione all'interno del VPC NSX di Gestione ordini e tre subnet denominate App, Web e DB nel VPC NSX di Analisi. Le macchine virtuali del carico di lavoro sono collegate a tutte le subnet. I VPC NSX sono collegati allo stesso gateway VRF di livello 0 o di livello 0 del progetto Vendite.
Workflow di VPC NSX di alto livello
- Amministratore del progetto: aggiunge VPC NSX all'interno di un progetto e definisce le impostazioni di VPC NSX di base, ad esempio l'assegnazione di IP, la configurazione DHCP, il cluster Edge e così via.
- Amministratore del progetto: assegna ruoli agli utenti nel VPC NSX.
- Amministratore del progetto: definisce la quota o i limiti per il numero di oggetti che gli utenti possono creare all'interno del VPC NSX.
- Amministratore VPC o amministratore di rete: aggiunge subnet nel VPC NSX. Connette i carichi di lavoro a queste subnet in base ai requisiti aziendali.
- Amministratore VPC o amministratore della sicurezza: aggiunge criteri di sicurezza nel VPC NSX per soddisfare i requisiti di sicurezza dei carichi di lavoro connessi alle subnet nel VPC.
Modalità di accesso per le subnet VPC NSX
- Privato
-
Una subnet privata è accessibile solo all'interno del VPC NSX. I carichi di lavoro collegati a una subnet privata possono comunicare con i carichi di lavoro in altre subnet private o pubbliche all'interno dello stesso VPC NSX.
Se l'assegnazione IP per la subnet privata è impostata su "automatica", i blocchi di IP della subnet (CIDR della subnet) vengono assegnati automaticamente dai blocchi di IPv4 privati assegnati al VPC NSX. Se l'assegnazione IP per la subnet privata è impostata su "manuale", l'amministratore VPC può assegnare manualmente il CIDR della subnet.
Il CIDR di una subnet del VPC non può sovrapporsi al CIDR di un'altra subnet del VPC nello stesso VPC NSX. Tuttavia, gli IP della subnet possono sovrapporsi alla subnet in un altro VPC NSX. È possibile eseguire questa configurazione allocando diversi blocchi di IP privati con gli stessi intervalli di IP a VPC NSX diversi.
Più VPC NSX in un progetto possono condividere lo stesso blocco di IPv4 privato. In questo caso, le subnet private saranno univoche tra i diversi VPC che condividono lo stesso blocco di IP privati.
Se l'opzione NAT in uscita predefinita è attivata per il VPC NSX, viene creata una regola SNAT predefinita per il VPC NSX per consentire il routing del traffico dai carichi di lavoro nelle subnet private all'esterno del VPC NSX. In righe simili, se questa opzione è disattivata, il traffico proveniente dalla subnet privata non può essere instradato all'esterno del VPC NSX.
- Pubblico
-
Una subnet pubblica è accessibile dall'esterno del VPC NSX. Questa subnet viene annunciata automaticamente fino al gateway di livello 0 del progetto e usufruisce della connettività esterna diretta per impostazione predefinita. In altre parole, gli indirizzi IPv4 nelle subnet pubbliche sono raggiungibili sia dal progetto che dall'esterno del progetto.
Se l'assegnazione IP per la subnet pubblica è impostata su "automatica", i blocchi di IP della subnet (CIDR della subnet) vengono assegnati automaticamente dai blocchi IPv4 esterni specificati per il progetto. Se l'assegnazione IP per la subnet pubblica è impostata su "manuale", l'amministratore VPC può assegnare manualmente il CIDR della subnet.
- Isolato
-
Una subnet isolata non è connessa internamente al gateway implicito realizzato. I carichi di lavoro in una subnet isolata possono comunicare tra loro ma non possono comunicare con i carichi di lavoro su subnet private o pubbliche all'interno dello stesso VPC NSX. Inoltre, i pacchetti provenienti da subnet isolate non possono passare al di fuori del VPC NSX.
Un amministratore VPC deve specificare manualmente l'indirizzo CIDR di una subnet isolata.
