Most users new to VMware have problems understanding how Orchestrator fits into the VMware landscape and what it can be used for. So, let's have a closer look at this. We will start with the history of Orchestrator, then look into its features, and finally, how to expand its possibilities using plug-ins.
Orchestrator started its life as Virtual Service Orchestrator (VS-O) with a small company named Dunes in Lausanne, Switzerland. In 2007, VMware bought Dunes, renaming the product as VMware Orchestrator (VMO), and then introduced Orchestrator into vSphere 4.0 as vCenter Orchestrator (vCO). Orchestrator's first stage debut was with VMware Lifecycle Manager, which used Orchestrator to automate the virtual infrastructure life cycle.
Orchestrator itself never really received the spotlight until the recent launch of VMware vCloud Automation Center (vCAC). In the beginning, vCAC used Orchestrator only as an extension, but with version 6.1, it became the central tool for automation.
In October 2014, VMware renamed vCenter Orchestrator (vCO) to vRealize Orchestrator (vRO) to align with their new strategies. vRO is not a new product; it is just the new name of vCO. VMware also renamed vCAC with version 6.2 to vRealize Automation.
In vSphere 4.x and 5.x, Orchestrator was automatically installed when one installed vCenter. Orchestrator began its life as a Windows install, which was finally phased out with the introduction of vSphere 6. With the start of vSphere 5, a Linux-based Orchestrator appliance was introduced, which now remains the only Orchestrator installation that is officially available.
Since the introduction of vRealize Automation, Orchestrator has become the focus of a lot of development and attention from VMware and others. More vendors have released plug-ins for Orchestrator and many have been discovering Orchestrator as an innovative solution for their automation needs.
A user can interact with Orchestrator either using the Orchestrator Client, a Java executable, via the vCenter vSphere Web Client or through websites that use the Orchestrator API. Orchestrator uses a full REST API (the SOAP API was removed in 6.x) so tools such as vRealize Automation (vRA) can easily communicate with Orchestrator.
Orchestrator uses a plug-in architecture to expand its base usability, enabling it to not only interact with various VMware products but also integrate with a range of other products. There are plug-ins to interact with hardware from vendors such as HP, Cisco, EMC, and NetApp as well as with other automation solutions such as Puppet and Microsoft SCOM or Microsoft SCVMM. We will discuss plug-ins a bit further down the track.
The following figure shows how one can interact with Orchestrator and how Orchestrator interacts with other solutions:
Using the vCenter vSphere Web Client, right-click on a cluster to schedule the deployment of a VM using an Orchestrator workflow
Use an Orchestrator workflow to configure the CISCO UCS hardware of an ESXi server, and then automatically roll out an ESXi installation using VMware Autodeploy
Connect to your EMC or NetApp storage and use an Orchestrator workflow to configure a new datastore and mount it directly on all ESXi hosts in a cluster
Schedule an Orchestrator workflow that runs a PowerShell script against all Microsoft servers to collect information and then send that information via e-mail
Intercept an SNMP trap and automatically trigger the execution of an Orchestrator workflow
VMware has been releasing Orchestrator plug-ins for most of its products. This allows you to create workflows that tie all the VMware products together making it possible to easily create interactions between VMware products using a single tool.
The following figure shows all currently existing VMware plug-ins that Orchestrator can use. The green dotted line also shows which VMware products can start Orchestrator workflows.
An example of plug-in interaction could be to create a VM in vSphere and configure it with a dedicated network using NSX, and then configure this VM automatically for SRM. Or another way around would be to use an SRM recovery step to execute an Orchestrator workflow via the API to launch some network configurations in NSX.
So what it comes down to is that Orchestrator is a central tool from which one can control, trigger, and drive separate products in your environment.
The real strength of Orchestrator lies in its ability to use plug-ins. Plug-ins can be written by anyone, as VMware publishes a guide on how to write them along with an SDK to help you get started. Plug-ins are mostly written by vendors to make it possible for Orchestrator to access their product. An unofficial full list of all existing plug-ins can be found at http://www.vcoteam.info/links/plug-ins.html.
Additional to this, there is the official plug-in site, the VMware solution exchange, where you can find more plug-ins that are vendor-specific or may require licensing:
If there is no plug-in for a program you use, you could always use SOAP, REST, SSH, Mail, or PowerShell to access this program and integrate it into Orchestrator. Another possibility is to use Dynamic Types. Dynamic Types help you construct types and Orchestrator inventory entries enabling you to build XaaS (Anything as a Service). Have a look at Christophe Decanini's posts and examples:
Orchestrator itself comes with quite a lot of plugins preinstalled. The following screenshot shows all the plug-ins that vRealize Orchestrator 6.0.2 comes with:
In this book, we will work with the vCenter plug-in. All other plug-ins are discussed in detail and with example workflows in the VMware vRealize Orchestrator Cookbook.