In vSphere Foundation la contabilità dell’infrastruttura e il monitoraggio dello storage abitano lo stesso posto: VCF Operations, che nel bundle VVF arriva insieme a vSphere, vSAN e VCF Operations for Logs. Quello che non arriva è VCF Automation, e quindi non esiste un catalogo self-service da tariffare né un workload domain a cui appendere un centro di costo. Qui il costing serve a rispondere a «quanto mi costa questo cluster» e a produrre showback verso le business unit; il monitoraggio serve a capire se il datastore vSAN sta reggendo. Sono due mestieri diversi che condividono la stessa console, e l’esame li mescola volentieri.

Cost driver: da dove nasce il numero

Il costo non si digita: si costruisce dai cost driver, che si raggiungono da Infrastructure Operations → Configurations → Cost Drivers. Le voci sono quelle di un conto economico di data center: Server Hardware: Traditional, Server Hardware: Hyper-Converged, Storage, License, Applications, Maintenance, Labor, Network, Facilities e Additional Cost. La distinzione fra i due driver hardware è quella che conta su VVF: un cluster vSAN è infrastruttura iperconvergente e finisce sotto Server Hardware: Hyper-Converged, non sotto quello tradizionale. Lo Storage si valorizza invece per datastore, in costo mensile per GB, e il Network per tipo di NIC.

Dentro la scheda Settings dei cost driver si sceglie il modello di ammortamento: Straight Line oppure Max of Double or Straight, su un periodo che va da due a cinque anni. VCF Operations calcola il valore annuo e lo divide per dodici per ottenere la quota mensile, quindi ogni modifica al periodo di ammortamento sposta l’intera curva del costo mensile. I cost driver si possono esportare e reimportare come file — utile per replicare la stessa base di costo su più data center — con l’eccezione di Additional Cost. Dopo il salvataggio il totale mensile e la media per gruppo di server vengono ricalcolati.

Pricing: il prezzo non è il costo

Il costo è quanto spendi tu; il prezzo è quanto addebiti. Per questo esistono le pricing card, che fissano il prezzo di ciascuna risorsa e si assegnano a un vCenter o a un cluster. Ne esistono due famiglie: rate-based, dove le tariffe le decide l’amministratore, e cost-based, dove il prezzo si aggancia al costo calcolato dai driver. Su un ambiente VVF la scelta tipica è cost-based con un ricarico, perché non c’è un listino di servizio da difendere.

La lettura si fa in Cost Analysis, che confronta metriche su oggetti e gruppi e mostra i primi e gli ultimi 5, 10 o 20 oggetti per la metrica scelta. Le schede separano l’Analysis of Cost Metrics (Cost of Ownership, Potential Savings, Realized Savings su VM, host e cluster) dall’Analysis of Price Metrics, che si basa sulle politiche di pricing definite. Le analisi si salvano e si riaprono.

Integrare VCF Operations con i componenti VVF

Tutto passa da Administration → Integrations, che apre sulla scheda Accounts; la scheda Repository elenca le integrazioni installate e disponibili e permette di installarne in formato PAK (nella documentazione le integrazioni sono chiamate anche management pack).

Per il vCenter: Add → vCenter, poi Display Name, Physical Data Center, indirizzo del vCenter — usa l’FQDN, non l’IP, se vuoi la compatibilità con il Single Sign-On — credenziali con almeno accesso in lettura a livello di data center o di vCenter, ed eventuali action credentials separate per le operazioni sul guest. Si sceglie il collector o il collector group che gestirà l’account, si preme Validate Connection e si confronta il certificato presentato prima di accettarlo. In Advanced Settings stanno le opzioni che l’esame ama: fra queste Enable vSphere Supervisor Collection, vera per impostazione predefinita, che crea automaticamente un’istanza di adapter per ogni Supervisor. La raccolta log richiede l’appliance VCF Operations for Logs già installata. Dopo l’aggiunta la raccolta va avviata a mano con Start Collecting, e le prime metriche possono richiedere più cicli da cinque minuti.

Le credenziali sono oggetti riusabili, gestiti da Administration → Integrations → Accounts → Credentials: si applicano a più adapter, non si cancellano se un adapter le sta usando, e per impostazione predefinita ognuno modifica solo le proprie — a meno di disattivare Credential Ownership Enforcement nelle Global Settings. VMware Infrastructure Health invece non si configura: è attivo di default, con un account creato per ogni nodo e cloud proxy, e riporta disponibilità, servizi, certificati, password e alert attivi dei componenti della piattaforma.

Monitorare lo storage vSAN

La trappola sta all’inizio: vSAN non si aggiunge come account a sé. Si apre l’account vCenter, si va sulla scheda vSAN e si attiva la configurazione, eventualmente con credenziali alternative e con la raccolta dei dati SMART dei dischi fisici. Il prerequisito è che lo stesso vCenter sia già monitorato da un vCenter adapter: solo i vCenter configurati per entrambi compaiono nell’albero di inventario. Poi Start Collecting All, e i dashboard vSAN si popolano dopo qualche minuto.

La verifica si fa da Inventory → Adapter Instances → vSAN Adapter Instance, guardando due indicatori distinti: Collection State verde significa che l’oggetto è connesso, Collection Status verde che l’adapter sta effettivamente prelevando dati. Sono due cose diverse. E c’è un prerequisito lato vSphere: se il vSAN performance service non è attivo, l’adapter resta connesso ma le metriche di performance non arrivano, con warning nei log dell’adapter.

La vista operativa è Infrastructure Operations → Storage Operations, dashboard centralizzata per storage vSAN e non-vSAN: inventario e utilizzo dei datastore, alert di storage, vSAN Cluster Health Score, IOPS, latenza e throughput per cluster, più il widget vSAN Cluster Performance da cui si lancia una diagnostica scegliendo l’obiettivo fra Troubleshooting e Benchmarking and Optimizing. Accanto ci sono le dashboard predefinite: vSAN Performance, che ordina i cluster per latenza disco più alta e scende a disk group, cache disk e capacity disk; vSAN ESA Performance, che per la stessa analisi parla di storage pool e physical disk; vSAN Utilization e vSAN Contention, da usare in coppia; Storage Heavy Hitters, che incrocia IOPS e throughput per isolare le VM che picchiano sullo storage e per capire, dalla divergenza fra le due curve, che il block size è cambiato. Se VCF Operations è integrato con VCF Operations for Logs, la scheda Logs nella pagina di dettaglio di un oggetto vSAN — cluster, witness host, disk group, cache disk, capacity disk — porta direttamente ai log di quell’oggetto.

Trappole tipiche d’esame

  • «Aggiungi un account vSAN». Non esiste come flusso separato: la configurazione vSAN è una scheda dentro l’account vCenter, e richiede che quel vCenter sia già monitorato. Chi cerca Add → vSAN perde la domanda.
  • Collection State contro Collection Status. Il primo dice che l’oggetto è connesso, il secondo che i dati stanno arrivando. Uno scenario con «adapter verde ma nessuna metrica di performance vSAN» non è un problema di credenziali: è il vSAN performance service spento lato vSphere.
  • Cost driver contro pricing card. I driver producono il costo, le pricing card il prezzo da addebitare e si assegnano a vCenter o cluster. Cambiare un driver non modifica il listino, e viceversa.
  • ESA e OSA hanno dashboard e vocabolario diversi. Disk group, cache disk e capacity disk appartengono alla dashboard vSAN Performance; su ESA si ragiona per storage pool e dischi fisici. Una risposta che cerca i disk group su un cluster ESA è sbagliata per costruzione.
  • VVF non è VCF. Nell’elenco degli account integrabili compaiono anche NSX e VCF Automation, che in vSphere Foundation non hai: in uno scenario VVF le integrazioni plausibili sono vCenter, vSAN, vSphere Supervisor, VCF Operations for Logs e Infrastructure Health.