VCF Operations Orchestrator è la piattaforma di sviluppo e automazione dei processi della famiglia VCF: una libreria estensibile di workflow più il motore che li esegue. Automatizza attività operative e di gestione sui prodotti Broadcom e su applicazioni di terze parti: la documentazione cita i sistemi di service desk e di change management. È lo stesso prodotto che conoscevi come vRealize Orchestrator e poi Aria Automation Orchestrator: nelle mappature dei nomi da VCF 5.x, «VMware Aria Automation Orchestrator» corrisponde a «VCF Operations Orchestrator».

Di che pezzi è fatto

Quattro blocchi: la workflow library con il workflow engine, che crea ed esegue i flussi; i plug-in, che danno accesso a tecnologie esterne; un authentication provider per gli account utente; un database PostgreSQL che conserva i dati dei workflow eseguiti.

Il database non è un dettaglio da diagramma: la piattaforma dichiara persistence e check-pointing, cioè ogni passo di un workflow viene salvato, ed è questo che impedisce la perdita di dati in un processo lungo. Ci sono poi il versioning su tutti gli oggetti, l’integrazione con Git, un policy engine, l’API REST, un motore di scripting JavaScript (Mozilla Rhino) che supporta anche Python, Node.js e PowerShell/PowerCLI.

Workflow, action, policy: i tre oggetti da non confondere

Un workflow è una serie di azioni e decisioni che si eseguono sequenzialmente. Prende input da utenti, da altri workflow, da processi esterni o da chiamate a web service; si può programmare o far scattare al verificarsi di un evento previsto; può invocarne altri (nesting). La libreria standard è in sola lettura: per personalizzarne uno lo duplichi. Puoi disegnarne il form di input e chiedere un’interazione utente a metà esecuzione — è così che si inserisce un’approvazione umana.

Un’action è una funzione JavaScript: accetta più parametri di input e restituisce un solo valore. È il mattone riusabile dentro lo schema di un workflow e può invocare qualsiasi oggetto dell’API di Orchestrator o importato dai plug-in.

Una policy monitora eventi e attiva workflow o script: è fatta di regole, gauge, soglie e filtri di eventi valutati di continuo, e può osservare oggetti vCenter come HostSystem e VirtualMachine. È il pezzo event-driven: il workflow è il processo che fa partire.

I plug-in: dove tocca il resto dell’infrastruttura

Fra i plug-in preinstallati ci sono vCenter, vCloud Suite API (vAPI), Active Directory, SQL, SSH, PowerShell, HTTP-REST, SOAP, AMQP, Mail, SNMP, XML, Dynamic Types, Multi-Node e quelli per VCF Automation. Si gestiscono dalla pagina System Settings e alcuni vanno configurati prima dell’uso — il caso tipico è vCenter, senza il quale i workflow vSphere non hanno inventario su cui agire. L’API Explorer mostra gli oggetti esposti.

Embedded o esterno, e che cosa cambia su VVF

Un’istanza embedded vive nella Provider Consumption Organization di VCF Automation, si raggiunge dalla scheda Orchestrate ed è configurata di default; ne esiste una sola per Provider Consumption Organization (e una per All Apps organization), non è supportata come embedded dentro un’organizzazione All Apps, e i suoi workflow si pubblicano lì come catalog item.

Un’istanza esterna è separata e si integra con VCF Automation (All Apps e VM Apps), con vSphere — autenticazione vSphere oppure VCF SSO — e con VCF Operations. È la forma raccomandata per VM Apps e All Apps, e sostituisce l’embedded quando il carico su VCF Automation è molto alto.

Qui sta il punto che vale l’esame: su VVF VCF Automation non c’è. Le management appliance di vSphere Foundation sono VCF Operations, VCF Operations collector, VCF Operations for Logs, vCenter ed ESX — l’Orchestrator non è in quell’elenco — e vSphere Foundation non include le capacità di cloud management e di automazione integrata disponibili in VMware Cloud Foundation. Su VVF la forma pertinente è quindi l’istanza esterna integrata con vSphere o con VCF Operations, non la scheda Orchestrate.

Quando lo scegli davvero

Quando un’operazione è ripetibile, multi-step e deve venire identica ogni volta: provisioning di VM con nome, cartella, tag e storage policy corretti; decommissioning ordinato; una manutenzione che mette gli host in maintenance mode in sequenza. Quando il processo deve attraversare sistemi diversi — un ticket sul service desk, un database, un’API REST, una mail — perché è ciò che gli permettono i plug-in. Quando deve partire da un evento (policy) o via API REST, e quando vuoi versionare i processi in Git.

Non lo scegli quando basta un allarme che avvisa qualcuno: quello si definisce nel vSphere Client dalla scheda Configure, in Alarm Definitions. Né per metriche, dashboard o log, che sono di VCF Operations e VCF Operations for Logs. E non è un catalogo self-service multi-tenant: quello è VCF Automation, fuori dal perimetro VVF.

Trappole tipiche d’esame

  • Il nome vecchio. vRealize Orchestrator e Aria Automation Orchestrator sono lo stesso prodotto: in un contesto 9.0 la risposta è VCF Operations Orchestrator, come i log stanno in VCF Operations for Logs e non in «Log Insight».
  • Action, workflow e policy scambiati. L’action è una funzione JavaScript con un solo valore di ritorno usata dentro un workflow; il workflow è la sequenza di azioni e decisioni; la policy osserva eventi. «Reagire automaticamente a un evento su un oggetto vCenter» punta alla policy, non a un workflow pianificato.
  • VVF confuso con VCF. vSphere Foundation non porta VCF Automation e la sua lista di management appliance è corta: VCF Operations, collector, VCF Operations for Logs, vCenter, ESX. Una risposta che passa dalla scheda Orchestrate presuppone un prodotto che su VVF non hai.
  • Embedded contro esterno. Una sola istanza embedded per Provider Consumption Organization e mai come embedded in un’organizzazione All Apps; l’esterna è la forma consigliata, e quella da adottare quando il carico su VCF Automation è elevato.
  • Orchestrator preso per un sistema di monitoraggio. Non raccoglie metriche: esegue processi. Il monitoraggio è di VCF Operations, gli allarmi di oggetto di vCenter.