Questo obiettivo mette insieme quattro cose che in VCF 9.0 vivono in tre posti diversi della console: le policy operative, il monitoraggio delle applicazioni, la compliance di sicurezza e il configuration drift. Chi amministra davvero la piattaforma le tiene collegate, perché la policy è il filtro che decide se un benchmark viene valutato e se un alert nasce.

La policy è il filtro con cui VCF Operations guarda gli oggetti

Una policy operativa stabilisce «come VCF Operations monitora i tuoi oggetti e come ti notifica i problemi». In pratica governa quali metriche e proprietà vengono raccolte e persistite, quali definizioni di alert e di sintomo sono attive, come si calcola la capacità, quali soglie di compliance si applicano. La documentazione distingue policy di default, policy fornite con il prodotto e policy custom, e suggerisce di modellarle sui livelli di servizio reali: Critical Production e Important Production con analitica sulle prestazioni e alerting più o meno sensibile, Batch Workloads, Test/Staging/QA con meno alert, Development senza alert, Maintenance per monitorare senza soglie, Low Priority per l’efficienza.

Il workspace si apre dal riquadro Policy Definition nella sezione Configurations di VCF Operations, e la policy si costruisce a sezioni, ciascuna con il proprio Save: Basic Configuration (nome, descrizione e soprattutto il campo Inherit From, cioè la policy base da cui si eredita), Metrics and Properties (metriche, proprietà e super metric da includere), Alerts and Symptoms (attivazione o disattivazione delle definizioni), Capacity (override delle impostazioni situazionali, per esempio i progetti committed), Compliance (le soglie di compliance della policy), Workload Automation (impostazioni di ottimizzazione, con i lucchetti che scelgono se ereditare dal padre o sovrascrivere) e Groups and Objects. Le soglie dinamiche, invece, sono globali: si governano da Administration → Global Settings → Dynamic Thresholds, dove la doc chiarisce che una soglia «segna il confine fra comportamento normale e anomalo» e viene calcolata sui dati storici e in arrivo; il calcolo è attivo per impostazione predefinita e può essere ricalcolato fuori schedule.

Assegnazione: la priorità non è l’ultima parola

Nel workspace di Policy Assignment gli oggetti si trascinano dal pannello destro (All Objects → Inventory oppure Custom Groups) dentro la card della policy; nella finestra Assign Objects si sceglie fra «Only this object» e «Include child object», specificando una profondità fino a 10 livelli. Una policy diventa attiva solo quando è assegnata a un oggetto o a un gruppo custom. Quando più policy insistono sullo stesso oggetto vince quella a priorità più alta, tranne che una policy a priorità più bassa venga applicata se assegnata direttamente all’oggetto: è l’eccezione che l’esame ama.

Monitorare le applicazioni: scoperta, agenti, business application

Il livello applicativo si costruisce in tre strati. Service Discovery scopre i servizi che girano in ogni VM e costruisce la relazione o dipendenza fra servizi di VM diverse, con credenziali guest OS o in modalità credential-less; raccoglie anche CPU e memoria dei servizi scoperti e serve a capire cosa succede se una VM viene spenta o spostata. Gli agenti Telegraf gestiti dal prodotto si amministrano da Workload Operations → Applications → Manage Telegraf Agents: i target sono VM gestite da un cloud account vCenter ed «endpoint», cioè server fisici e VM non gestite. Il cloud proxy raccoglie dagli agenti e inoltra a VCF Operations, e i proxy si organizzano in collector group; con l’alta disponibilità attiva compaiono primario, secondario e virtual IP, ma un agente esistente non si converte: va reinstallato. Esiste anche la via del Telegraf open source su Linux e Windows, con script helper o configurazione manuale verso il cloud proxy: i servizi non supportati compaiono come <nome servizio_Generic> e per essi non viene generato alcun alert, e gli agenti gestiti vanno disinstallati prima. Sopra tutto sta la Business Application, il costrutto che raggruppa in tier applicazioni, servizi e host che erogano un servizio all’organizzazione: la salute mostrata è l’aggregato degli oggetti sottostanti, e la stessa pagina alimenta capacity, cost e what-if analysis.

Hardening e compliance

Si lavora da Security → Compliance, con quattro famiglie di benchmark: i VCF Benchmarks, basati sulla VMware Cloud Foundation Security Baseline, che auditano ESX, SDDC Manager, vCenter, vSAN e NSX; i VMware SDDC Benchmarks, allineati alle security configuration guide di vSphere, vSAN e NSX; i Regulatory (fra gli altri HIPAA, PCI DSS v4.0, CIS, DISA STIG, ISO/IEC 27001:2022, NIST SP 800-53 R5, NIST SP 800-171); e i Custom, esportabili e importabili in XML, con un tetto di cinque score card custom. Il meccanismo non è un modulo separato: la compliance si misura con definizioni di alert di sottotipo Compliance, costruite sulle proprietà e metriche degli oggetti (host, VM, distributed port group, distributed switch, cluster, NSX, vSAN), e produce un punteggio percentuale. Le definizioni si attivano in una policy attiva, e in 9.0 lo si può fare direttamente dalla pagina Compliance. Accanto vive la Security Operations con User Security (login totali, falliti, variazioni di privilegio) e Infrastructure Security (advisory, modalità di cifratura degli host, cifratura VM e vSAN, certificati); gli audit event richiedono l’integrazione con VCF Operations for Logs.

Configuration drift

Da Fleet Management → Configuration Drifts si governano solo istanze vCenter 9.0 o successive e cluster vSphere con Configuration Profiles attivi. Nella tab Configuration Templates si crea il template con Create Config Template: nome, un Configuration Source vCenter da cui estrarre le impostazioni, la selezione delle voci di schema, l’assegnazione facoltativa a una o più policy (altrimenti si fa dopo, da Policy Definition → Configuration Templates, portando il template su Activated). Gli stati sono quattro: Not Drifted, Drift Detected, Drift Check Failed, Unavailable. Con Schedule Drift Detection si definisce nome, scope (trascinando le istanze vCenter; scegliendo una cartella VCF entrano tutte le istanze che contiene), preview, criteri di filtro e schedule: nasce un job visibile in Automation Central e si può scaricare il report. Il punto che cambia il modo di lavorare: la remediation non è automatica — si rientra correggendo a mano in vCenter o allineando il template. I template si possono sincronizzare su GitLab o GitHub da Administration → Control Panel → Source Control, con token, branch e path, e con il code review attivo per impostazione predefinita che apre una merge request per ogni operazione.

Non va confuso con il drift fra vCenter Server e SDDC Manager: lì il disallineamento nasce da modifiche out-of-band fatte in vCenter o NSX Manager e si risolve con Inventory → Detailed View → VCF Instances → dominio → Actions → Sync Inventory, un dominio alla volta.

Trappole tipiche d’esame

  • Priorità contro assegnazione diretta. Con più policy applicabili vince quella a priorità più alta, ma una policy meno prioritaria assegnata direttamente all’oggetto prevale. Le domande scenario descrivono un oggetto in un gruppo e chiedono quale policy si applica.
  • La compliance passa dalla policy. Se le definizioni di alert del benchmark non sono attive in una policy assegnata all’oggetto, il punteggio non si muove. «Attivare il benchmark» e «assegnare la policy» sono due passi, non uno.
  • Tre benchmark diversi. VCF Benchmark (baseline VCF, include SDDC Manager fra i prodotti auditati), VMware SDDC Benchmark (security configuration guide di vSphere, vSAN, NSX) e Regulatory pack non sono sinonimi: la domanda gioca sul nome dello standard.
  • Drift rilevato ≠ drift corretto. VCF Operations non riporta la configurazione allo stato desiderato: la correzione è manuale in vCenter, oppure si modifica il template. E il perimetro è vCenter e cluster vSphere, non «tutta la fleet».
  • Configuration Drifts non è Sync Inventory. Il primo confronta la configurazione contro un template; il secondo riallinea l’inventario di SDDC Manager dopo modifiche out-of-band.
  • Servizio non supportato = nessun alert. Con Telegraf open source i servizi non supportati appaiono come _Generic e non generano alert: se qualcuno «non riceve avvisi sull’applicazione», questa è una causa plausibile quanto una policy sbagliata.