Questo obiettivo mette insieme quattro attività che nella pratica appartengono a due persone diverse: l’amministratore provider, che prepara il substrato di rete, e l’amministratore di organizzazione, che lo consuma e ci scrive sopra le regole. Tenere separati i due punti di vista è metà del lavoro, perché l’esame gioca esattamente su quel confine.

Cosa prepara il provider prima che l’organizzazione veda una rete

Nel VCF Automation provider management portal si va in Infrastructure > Organizations, si seleziona un’organizzazione All Apps (quelle etichettate «VM Apps» seguono un altro modello) e si apre Networking. Sotto General si può impostare un log name che identifica le voci syslog in NSX; sotto Regional Networking si clicca New e si scelgono tre cose: la region, il provider gateway che collega la rete dell’organizzazione verso l’esterno, e l’edge cluster su cui gireranno i servizi VPC dell’organizzazione.

Vale la pena sapere cosa produce quel «Create», perché è la risposta a metà delle domande su questo tema: la configurazione crea un NSX Project, un NSX Transit Gateway, un VPC predefinito, un connectivity profile predefinito e una regola SNAT in uscita che porta la connettività fino al gateway tier-0.

Il provider gateway non è un oggetto nuovo di NSX: è un tier-0 gateway (o un tier-0 VRF) in modalità Active Standby, integrato con uno o più IP space per gestire la connettività esterna. Un provider gateway va associato ad almeno uno e fino a cinque IP space, con un massimo di cinque CIDR complessivi: se si usano cinque IP space, resta un solo CIDR per ciascuno. Gli IP space li crea il provider per allocare indirizzi pubblici alle organizzazioni, sono solo IPv4, e lo stesso IP space può servire più organizzazioni contemporaneamente.

Il lato organizzazione: VPC, connectivity profile, IP management

Nel portale dell’organizzazione tutto vive sotto Manage & Govern > Networking. Un VPC è un dominio isolato di risorse di rete che può essere associato a uno o più namespace — cioè un VPC può essere condiviso, non serve uno per namespace. Si crea da Virtual Private Clouds > New VPC indicando nome, region, connectivity profile (esistente o creato al volo) e i private CIDR IPv4 del VPC; opzionalmente si applicano le quote IP.

I tre tipi di blocco IP vanno tenuti distinti: i private CIDR sono locali al VPC e richiedono NAT per uscire; i private TGW IP block sono raggiungibili nell’organizzazione e attraverso il suo transit gateway; gli external IP block li assegna l’amministratore provider e servono al SNAT in uscita. Il connectivity profile (Virtual Private Clouds > Connectivity Profiles > New Connectivity Profile) è il template che tiene insieme region, external IPv4 block e private TGW IPv4 block, con un tetto di cinque blocchi per tipo; modificarlo cambia la connettività di tutti i VPC che lo usano, il che è la ragione per cui conviene non lavorare sul profilo di default.

In IP Management si creano i blocchi privati (IP Address Blocks > New Private - TGW IP Block, con nome, CIDR e region) e le IP Quotas, dove si definiscono scope (External o Private-TGW), blocchi IPv4, numero di single IP, numero di CIDR, dimensione massima della subnet e i VPC bersaglio. Il blocco private TGW di default non si modifica: o se ne crea uno nuovo, o lo si rimuove dal profilo, lo si edita e lo si rimette.

Sul transit gateway (Manage & Govern > Networking > Transit Gateways) l’unica regola davvero discriminante è questa: un NSX Project ha un solo TGW, e il TGW si collega all’esterno tramite external connection che possono essere centralizzate (una sola, via tier-0 su nodi Edge, con servizi stateful e routing dinamico BGP) oppure distribuite (più di una, direttamente su VLAN eseguite sugli host ESX, senza Edge, con external IP in NAT 1:1 e DHCP distribuito). Le due modalità non convivono sullo stesso TGW.

Il namespace è il punto in cui la rete diventa consumabile: si crea solo dentro un progetto, da Manage & Govern > Projects > [progetto] > Namespaces > New Namespace, scegliendo namespace class, region, VPC e fino a tre zone.

Estensibilità: agganciare processi al ciclo di vita

L’estensibilità in VCF Automation si fa con le event subscription (Build & Deploy > Subscriptions > New), che al verificarsi di un event topic eseguono un workflow di VCF Operations Orchestrator. Le condizioni si scrivono in sintassi JavaScript e leggono il payload via event.data più header come sourceType, eventType, userName, orgId; lo scope di default è Any Project e si può restringere.

La distinzione che conta è fra non-blocking — asincrone, senza ordine garantito — e blocking, che sono sincrone, impediscono alle altre di ricevere il messaggio finché il runnable item non è finito, si ordinano per priorità (0 è la più alta, a parità si va in ordine alfabetico inverso) e ammettono un recovery runnable item che parte se il primario fallisce, con la proprietà ebs.recover.continuation a decidere se la catena prosegue. La scheda Event Log serve a vedere cosa è realmente passato.

Accanto alle subscription ci sono altre due leve. Le custom resource estendono la palette dei blueprint: possono nascere da inventory type dell’Orchestrator oppure da uno schema nuovo costruito sugli input e output di workflow; il tipo deve iniziare con Custom., e le azioni di ciclo di vita sono Create, Read e Destroy — con il Read obbligatorio nelle custom resource schema-based, perché viene eseguito ogni pochi minuti per aggiornare lo stato. Infine c’è Terraform, con tre provider distinti: quello per VCF Automation (namespace, content library), quello Kubernetes (progetti, VPC, subnet) e quello per VMware Aria Automation, che copre ciò che non è ancora esposto via API Kubernetes, cioè blueprint e cataloghi. I workflow si portano agli utenti pubblicandoli da Build & Deploy > Content Hub > Workflows > Publish to Catalog.

Governance: quattro tipi di policy e una gerarchia sola

Le policy si definiscono da Manage & Govern > Policies > Definitions > New Policy e sono di quattro tipi. La lease policy governa maximum lease, maximum total lease e grace period (un giorno se non specificato): allo scadere il deployment viene programmato per l’eliminazione, le VM si spengono, e una macchina spenta non si riaccende finché il lease non viene esteso. La day 2 actions policy è una lista di inclusione, non di esclusione: senza nessuna policy tutti possono tutto, ma appena ne esiste una la governance si attiva per tutta l’organizzazione e gli altri utenti vanno abilitati esplicitamente. La approval policy blocca richieste e azioni day-2 in attesa di approvazione, con approvatori scelti per utente o per ruolo, modalità All o Any, e un’auto expiry decision (Reject o Approve) che scatta dopo un numero di giorni. La IaaS resource policy valida cosa i deployment possono consumare nei namespace: numero di nodi worker e control plane, versione minima di Kubernetes, sottoinsiemi di servizi.

Il meccanismo di combinazione è il punto d’esame: il sistema individua le policy applicabili, le ordina e le fonde in una effective policy. L’ordine è enforcement type prima di tutto — se coesistono hard e soft, si considerano solo le hard — poi lo scope, dove l’organizzazione batte il progetto, e infine la data di creazione, dove la più vecchia vince. Chi è in conflitto viene scartata. Le IaaS resource policy fanno eccezione: non vengono fuse, si applicano entrambe, e i limiti sono dieci per organizzazione e cinquanta per Supervisor. I deployment criteria restringono l’ambito con espressioni costruite a menu su blueprint, catalog item, Created By, Owned By, Name e risorse; l’ordine di valutazione è parentesi, poi AND, poi OR.

Supervisor Services: due passi, non uno

Un Supervisor Service è un operatore Kubernetes certificato per vSphere che porta componenti IaaS sul Supervisor: alcuni servono direttamente i workload (Harbor), altri espongono CRD per gestire istanze (MinIO). Il ciclo di vita sta nel vSphere Client, Supervisor Management > Services, e si fa in due tappe che l’esame ama separare.

Prima si registra il servizio su vCenter, trascinando il file YAML nel riquadro Add New Service, accettando l’eventuale EULA e confermando: da quel momento la versione è Active. Poi lo si installa sui Supervisor, dal riquadro del servizio con Actions > Manage Service, scegliendo la versione in Install Version, il Supervisor bersaglio e compilando lo YAML Service Config; i controlli di compatibilità producono warning superabili o errori bloccanti. L’avanzamento si segue in Supervisors > [Supervisor] > Configure > Supervisor Services Overview > Installed, dove lo stato passa da Configuring a Configured. I due passaggi hanno privilegi distinti — «Manage Supervisor Services» su vCenter, «Manage Supervisor Services on Supervisors» sul Supervisor — e una versione Deactivated non è installabile su nuovi Supervisor ma continua a girare dove già presente. Serve inoltre un Harbor regionale nella stessa regione; per ambienti chiusi le immagini si rilocano su un registry privato, con i servizi in formato Carvel o SupervisorServiceDefinition e la CA da far fidare se il certificato è self-signed.

Trappole tipiche d’esame

  • Provider gateway, transit gateway e VPC non sono la stessa scala. Il provider gateway è un tier-0 (o tier-0 VRF) in Active Standby integrato con IP space e lo tocca solo il provider; il transit gateway nasce con l’NSX Project ed è uno solo per project; il VPC lo crea l’amministratore di organizzazione e può servire più namespace. Domande che chiedono «chi crea cosa» stanno testando questo.
  • External connection centralizzata o distribuita, mai entrambe. Un TGW ammette una sola connessione centralizzata (Edge, tier-0, BGP, servizi stateful) oppure più connessioni distribuite (VLAN sugli host ESX, external IP in NAT 1:1, DHCP distribuito). Se lo scenario chiede routing dinamico verso il fabric, la distribuita non è la risposta.
  • Blocking e priorità. In una subscription blocking la priorità 0 è la più alta, non la più bassa, e le non-blocking non garantiscono alcun ordine: chiedere «in che sequenza girano» a subscription non-blocking è una domanda con la risposta «non è determinato».
  • La day 2 policy accende la governance. È una lista di inclusione: la prima policy creata toglie i permessi a tutti gli altri, e serve una seconda policy per riabilitare chi deve continuare a operare. Non è un divieto puntuale su un’azione.
  • Hard batte soft, e il vecchio batte il nuovo. Nella fusione delle policy si guardano prima le hard (se ce ne sono, le soft si ignorano del tutto), poi l’organizzazione sopra il progetto, poi la data di creazione più remota. E le IaaS resource policy non si fondono affatto: si applicano tutte, quindi due regole incompatibili non producono un compromesso ma un blocco.
  • Registrare non è installare. Aggiungere il servizio a vCenter lo porta in stato Active; finché non lo si installa su un Supervisor con «Manage Supervisor Services on Supervisors», nessun DevOps engineer lo vede.