Su VMware vSphere Foundation l’osservabilità non è un accessorio da comprare a parte: VCF Operations e VCF Operations for Logs sono componenti della piattaforma, al pari di vCenter, ESX e vSAN. Sono anche i due nomi su cui la memoria di chi viene da vSphere 7 o 8 sbaglia più spesso, perché fino a poco fa si chiamavano Aria Operations e Log Insight (e prima ancora vRealize). Nella 9.0 quei nomi non esistono più nella documentazione, e l’esame usa esclusivamente la forma corrente.

Due domande diverse, due strumenti

La separazione fra i due prodotti non è di prodotto, è di tipo di dato. VCF Operations raccoglie metriche, proprietà ed eventi come serie temporali strutturate: ti dice quanto, da quando e se è normale. VCF Operations for Logs raccoglie eventi di log testuali dai componenti e ti dice cosa è successo esattamente in quel momento.

Da qui discende la scelta nello scenario d’esame. Se la domanda è «il cluster sta esaurendo capacità fra due mesi», «quanto mi costa questo tenant», «questa VM è sovradimensionata», «l’ambiente è conforme al benchmark» — è VCF Operations. Se la domanda è «perché quella migrazione è fallita alle 03:14», «quale host ha registrato quell’errore di storage», «voglio un alert quando appare questa stringa» — sono i log. La cerniera fra i due esiste: dalla pagina Infrastructure Operations > Analyze > ANALYSE LOGS interroghi i log dentro la stessa interfaccia, e il widget Log Analysis si mette in una dashboard accanto ai grafici delle metriche.

Che cosa fa VCF Operations

La documentazione descrive VCF Operations su sette aree funzionali: fleet management, operations management, workload operations, performance monitoring, FinOps e capacity, workload mobility (VCF Operations HCX) e security and compliance. In pratica, per chi amministra, si traduce in tre usi quotidiani.

Il primo è monitoraggio e troubleshooting: oltre alle soglie fisse, VCF Operations calcola dynamic thresholds, cioè la fascia di comportamento normale di una metrica ricavata dai dati storici e da quelli in arrivo, ricalcolata a intervalli regolari. È la ragione per cui uno stesso valore di CPU ready può generare un alert su un cluster e non su un altro.

Il secondo è capacità e costo: analisi della capacità, cost driver e pricing card.

Il terzo è fleet management: ciclo di vita, certificati, password e licenze della flotta. È anche il posto dove si applica la licenza, in VCF Operations > License Management > Registration, dove l’istanza vive in Connected Mode (reporting d’uso automatico) o Disconnected Mode (upload manuale dei file di consumo).

Perché raccolga qualcosa devi collegare la sorgente: Administration > Integrations > Accounts > Add, tipo account vCenter, con credenziali in sola lettura assegnate a livello di datacenter o di vCenter, più il privilegio Performance > Modify intervals se vuoi le metriche guest. Si chiude con Validate Connection e poi Add.

I componenti del cluster VCF Operations

Il cluster è fatto di tre tipi di appliance con ruoli distinti. L’appliance VCF Operations fleet management è la console centrale. I nodi analytics costituiscono il motore che ingerisce e correla i dati: fra questi c’è il primary node, eventuali data node, e — quando attivi l’alta disponibilità — un data node promosso a replica. L’appliance VCF Operations collector raccoglie i dati dalle sorgenti e si può moltiplicare in collector group. Nel modello continuously available compare un quarto elemento, il witness, che non ospita dati ma arbitra.

I tre modelli di distribuzione di VCF Operations

Il Simple model distribuisce un nodo singolo di ogni componente nel cluster vSphere di gestione e si appoggia a vSphere HA per il riavvio in caso di guasto host: non c’è alta disponibilità applicativa. Supporta scale-up e scale-out dei data node e dei collector.

L’High Availability model aggiunge un cluster a tre nodi per il motore analytics, lasciando fleet management e collector a nodo singolo. Si attiva dalla console admin del primary node, https://nome-o-ip-del-primary/admin: Add new Nodes, ruolo Data, e poi sotto High Availability il pulsante Activate, scegliendo quale data node diventa replica; il cluster si riavvia, si sincronizza e si ribilancia. Servono una regola di anti-affinity DRS sui nodi e almeno quattro host ESX nel cluster di gestione, per poter mettere un host in manutenzione senza perdere la protezione.

Il Continuous Availability model divide il cluster in due fault domain su due istanze vSphere in due availability zone, con ogni oggetto scritto su due nodi (primary e replica) attraverso i fault domain, più un witness in un terzo sito. I requisiti di latenza documentati sono 10 ms fra i nodi del cluster, con picchi fino a 20 ms su intervalli di 20 secondi, e 30 ms fra witness e nodi. Si parte da un cluster Simple o HA, si distribuisce il witness scegliendo Witness come configurazione dell’OVF, si distribuisce lo stesso numero di nodi nel fault domain replica e si preme Activate CA.

VCF Operations for Logs: componenti e modelli

Anche qui i modelli documentati sono due. Il Simple model è un nodo singolo — un primary node con integrated load balancer — nel cluster di gestione, protetto da vSphere HA, con dimensioni appliance Small, Medium o Large; il recupero passa dal ripristino di un backup. L’High Availability model è un deployment a tre nodi dietro il load balancer interno: un primary e due worker, dimensionati in modo identico, con anti-affinity DRS a impedire che finiscano sullo stesso host. Il cluster va da tre a diciotto nodi; primary e worker sono responsabili ciascuno di un sottoinsieme dei dati, e i primary interrogano tutti i sottoinsiemi aggregando i risultati.

Su VVF l’appliance dei log si distribuisce a mano: Deploy OVF Template dal vSphere Client, poi integrazione dalla UI di VCF Operations in Administration > Control Panel, riquadro Operations-Logs Appliance Integration. Per aggiungere un nodo si apre la sua interfaccia, si sceglie Join Existing Deployment e si incollano indirizzo del primary e il token generato sulla pagina Management Cluster. Le sorgenti si accendono da Infrastructure Operations > Configurations, riquadro Log Collection, con Edit log sources per vCenter (eventi, task e allarmi) e per gli altri componenti presenti.

Trappole tipiche d’esame

  • VCF Operations non è VCF Operations for Logs, e non è SDDC Manager. Metriche e capacità stanno nel primo, gli eventi testuali nel secondo. Domande su «trovare l’errore esatto» vogliono i log; domande su «prevedere l’esaurimento» vogliono le metriche.
  • Le liste di sorgenti nella documentazione sono quelle condivise con VCF. Vedrai citati NSX, VCF Automation e VCF Identity Broker fra le sorgenti di log: su vSphere Foundation quei componenti non fanno parte della piattaforma, quindi non compaiono nel tuo inventario. Non dedurne che VVF li includa.
  • Il witness appartiene a Continuous Availability, non a High Availability. Il modello HA è tre nodi analytics in un solo sito; il witness serve solo quando i fault domain sono due e vive in un terzo sito.
  • Attivare HA non basta. Senza regola di anti-affinity DRS e senza il quarto host ESX nel cluster di gestione, l’alta disponibilità è nominale: vSphere HA riavvia, ma nulla ti garantisce che i nodi fossero su host diversi.
  • Su VVF le due distribuzioni non arrivano insieme. VCF Operations e il suo collector fanno parte del percorso guidato di distribuzione della piattaforma; l’appliance dei log si distribuisce e si integra separatamente, con licenza VVF e file OVA alla mano.