Un nome solo, appliance diverse
In VCF 9.0 «VCF Operations» è insieme la console centrale della flotta e una famiglia di appliance distinte, e l’esame gioca su questa ambiguità. Fra le management appliance la documentazione elenca separatamente VCF Operations, VCF Operations collector, VCF Operations fleet management, VCF Operations for logs, VCF Operations for networks e VCF Operations for networks collector. Motore analitico, raccolta dati e gestione di lifecycle, licenze, certificati e password sono macchine diverse: negli scenari conta le appliance, non le funzioni.
Simple, High Availability, Continuous Availability
La design library descrive tre modelli. Il Simple VCF Operations Model «deploys a single node of all the VCF Operations components»: un analytic node, un collector, una fleet management appliance. Non c’è alta disponibilità applicativa — la protezione è vSphere HA, che riavvia il nodo dopo il guasto di un host ESX. La taglia si sceglie sul numero di VM e oggetti previsto; si cresce poi in scale-up o in scale-out, aggiungendo data node e collector node.
Il modello High Availability porta a tre nodi il solo cluster analitico («a three node cluster for the analytic engine»), mentre fleet management e collector restano a nodo singolo. Servono una regola anti-affinity DRS, perché i tre nodi non finiscano sullo stesso host, e almeno quattro host ESX nel management vSphere cluster di default. La ridondanza del collector si ottiene a parte, aggiungendo collector node e raccogliendoli in collector group.
Il modello Continuous Availability separa il cluster in due fault domain su due istanze vSphere in due availability zone: «each object is stored in two nodes (primary and replica) across fault domains», con un witness node in una terza posizione che determina la salute del cluster e quale fault domain resta online. I due fault domain devono avere lo stesso numero di nodi. Il percorso reale: deploy Simple o HA con il VCF Installer nel dominio primario; OVA del witness con configurazione Witness nel template OVF, poi aggiunta dalla administrator console; se avevi HA la disattivi (il replica node ridiventa un data node); deploy dei nodi nel fault domain di replica; Activate CA e, nella procedura guidata, spostamento dei data node di replica nel loro fault domain; infine trigger inventory sync sul componente Operations in Fleet Management > Lifecycle. La doc fissa anche un tetto di latenza fra i fault domain, più stretto di quello ammesso verso il witness.
VCF Operations for Logs: quando è la risposta giusta
La pagina Analyze vive dentro la console di VCF Operations, ma il prerequisito dichiarato è il deploy del componente VCF Operations for logs: senza quell’appliance non hai log. È il «centralized log management framework for vCenter, ESX, NSX, VCF Operations, VCF Automation, and VCF Identity Broker». L’agent è preinstallato nei componenti supportati, si configura tramite agent group e si auto-aggiorna; il cloud proxy fa da intermediario e la configurazione di raccolta sta nel cluster Logs. Novità 9.0: i widget basati sui log nelle dashboard.
Si installa da Fleet Management > Lifecycle, con Add su operations-logs dopo aver scaricato il binario sulla fleet management appliance: New Install, deployment type Standard o Cluster, node size Small/Medium/Large con Medium minimo raccomandato in produzione. Il modello Simple è «one primary node with an integrated load balancer»; il modello HA è «one primary and two worker nodes with an integrated load balancer», nodi dimensionati in modo identico e protetti da vSphere HA più anti-affinity DRS.
VCF Operations for Networks: quando è la risposta giusta
Il blueprint la chiama «VCF Network Operations», la documentazione di prodotto scrive VCF Operations for networks. È lo strumento quando la domanda è di rete: «accelerates micro-segmentation planning and deployment, enables visibility across virtual and physical networks». In pratica: Path Topology fra due VM, Path to Internet, i BGP neighbor di un NSX edge o di un logical router, le Recommended Firewall Rules a valle dell’analisi dei flussi e il guided network troubleshooting, che costruisce un dependency graph con metriche e alert correlati.
L’architettura è a due tipi di nodo: il platform node elabora e serve l’interfaccia, il collector node raccoglie dai data source. Il modello Simple è un platform node non in cluster più almeno un collector, con riserva del 100% di CPU e RAM; il modello a cluster porta a tre i platform node e ne mantiene uno collector. Le taglie sono «brick» (da Small a 2 Extra Large): Small è solo per valutazione. Si installa da Fleet Management > Lifecycle > Add su operations-networks; qui gli FQDN non sono richiesti. L’integrazione con VCF Operations porta gli alert nella console con il prefisso vrni- e abilita il launch-in-context dalle pagine entità (VM, Host, NSX): l’utente VCF Operations deve esistere in VCF Operations for networks con almeno privilegi Member.
Trappole tipiche d’esame
- HA non è Continuous Availability. Tre nodi analitici in un’unica istanza vSphere sono HA; due availability zone più un witness in una terza posizione sono CA. Se lo scenario parla di perdita di un intero sito la risposta è CA — e per arrivarci si disattiva prima la High Availability, non la si somma.
- Il cluster analitico non protegge il collector. Nel modello HA fleet management e collector restano a nodo singolo: la ridondanza della raccolta arriva dai collector node aggiuntivi messi in un collector group.
- La pagina Analyze non implica i log. L’analisi vive nella console di VCF Operations, ma senza l’appliance for logs non c’è nulla da analizzare. E il cluster Logs è primary più due worker con integrated load balancer: non è il cluster analitico a tre nodi.
- Tre platform node non sono alta disponibilità. Nel cluster di VCF Operations for networks scala e prestazioni vengono dai platform node, la disponibilità resta a vSphere HA. E anche nel modello Simple serve almeno un collector: il platform node da solo non raccoglie niente.
- Nomi e sinonimi. Il blueprint dice «VCF Network Operations», il prodotto «for Networks»; la doc scrive ESX, non «ESXi»; vRealize e Aria non sono più nomi di prodotto, pur sopravvivendo in qualche slug di URL.