In this first chapter, we will have a look at what Orchestrator actually does, where it fits into the VMware world, and how it can be used. We will cover the following topics in this chapter:
What is VMware Orchestrator?
Compatibility and binaries
Additional sources for information
VMware vRealize Orchestrator is the latest iteration of the Orchestrator product that VMware started shipping with vSphere 4.
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.
Most vSphere administrators don't know about Orchestrator, or underestimate its possibilities.
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:
By executing Orchestrator workflows, one can interact with any Orchestrator technology integrated into Orchestrator. As this still sounds pretty complex, here are some examples:
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:
Examples of vendors that have plug-ins are BMC, Chef, CISCO, Docker, EMC, F5, Hitachi, HP, IBM, Infoblox, NetApp, Puppet, and Riverbed.
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.
Now that we know what Orchestrator does, we should have a look at licensing and how to actually get a copy of Orchestrator.
Orchestrator is licensed with vCenter. You need at least a vSphere Standard licensing to use Orchestrator. Although Orchestrator is not available with the Essentials and Essentials Plus licensing, it can be operated in Player mode only. This limits your usage to executing existing workflows and prevents you from editing or creating them. All other licensing models allow you to use Orchestrator with all its features.
As already stated, Orchestrator was available as a Windows install in versions 4.x and 5.x. With the introduction of Version 6.x, the Windows installable has been retired. In Version 5.x, a Linux-based appliance was introduced, and it is now the only available version of Orchestrator.
Please remember that Orchestrator 5.x is called vCenter Orchestrator (vCO) and Orchestrator 6.x is called vRealize Orchestrator (vRO).
If you are using vSphere 4.x and 5.x and you have installed vCenter, you will already have had Orchestrator installed as well. To enable it, you just need to start the required service in Windows. Due to the retirement of the Windows install, this book will not cover this method; however, it is described in the VMware vRealize Orchestrator Cookbook.
The Orchestrator appliance can be downloaded from the VMware website. You will find it in the vSphere downloads.
The VMware compatibility matrix shows that vRealize Orchestrator 6.0.2 is compatible with vCenter Server 5.1, 5.5, and 6. That said, you need to be a bit more careful; SSO has been changed quite a lot between vSphere 5.1, 5.5, and 6, so there still are some problems. Best practice dictates that you should stay with the same versions. You can use vRO 6 with vCenter 5.5 or 5.1, but you should replace the vCenter plug-in and that's not that easy.
For a beginner, I would suggest you stick to any of the following combinations of vSphere, vCenter, and Orchestrator:
5.5 Update 2e
5.1 Update 3a
In this book, we focus on vSphere 6 with Orchestrator 6.
By "architecture", IT people mean the framework, the items that make up the piece and its surroundings; basically, the same way as a "normal" architect who builds houses. The architecture of a house decides how it is built, how it fits together, and how it works in the context of its surroundings.
When talking about an IT product, we normally look at things like its limitations, its properties, what it depends on, and what it needs. The following figure shows Orchestrator and its dependent components.
The figure also contains the dedicated technical user account svc_vRO that is used to connect Orchestrator to other components.
Another part of the architectural view is how Orchestrator authenticates users.
Authentication is the topic that describes how Orchestrator knows that a certain user can access it and what he is allowed to do. Since VMware introduced SSO (Single Sign on) in vSphere 5.1, it should be considered the preferred method for Orchestrator authentication. However, Orchestrator is also able to use AD and LDAP for authentication. We will configure Orchestrator with SSO in the next chapter.
After we have talked about authentication, we should also talk about a dedicated service account. What this means is that when Orchestrator itself needs to communicate with another service, for example the vCenter server, it should use a user account only used by Orchestrator. This is a pretty common practice in Enterprise systems and allows for easier reading of log files if there is a problem.
You can use one dedicated user for all services, as shown in the figure earlier, where the same technical user svc_vRO is used for vCenter, database, and e-mail. Alternatively, you can have one user for each service, a different user for e-mail, and one for the database connection.
Orchestrator needs a database. The Appliance comes with an internal database (PostgreSQL); however, for production use, you should consider using a dedicated MS SQL, PostgreSQL, or Oracle database. If you are using Orchestrator in a production environment, you want to make sure that the database is backed up the same way your other important systems such as vCenter are.
In theory, you can use Orchestrator without any VMware infrastructure around it; however, that's not fun. You should have at least a complete VMware vSphere environment consisting of a vCenter server and ESXi hosts. Orchestrator itself is a core component for VMware vRealize Automation (formally known as vCenter Automation Center, vCAC).
Other services that help make Orchestrator more productive are E-mail (SMTP system) or SNMP. This allows you to send e-mails from Orchestrator to users, notifying them about workflow executions and errors.
You can also access a POP or IMAP account via Orchestrator using the mail plug-in. This allows you to send e-mails to the Orchestrator server in order to execute workflows.
Orchestrator is not almighty; there are still some limitations you should know about. vRealize Orchestrator version 6.0.2 has the following limitations when left unconfigured:
Maximal concurrent connected vCenters
Maximal concurrent connected ESXi hosts
Maximal concurrent connected VMs
Maximal concurrent running workflows
Steps may be taken to increase these values, but this topic is beyond the scope of this book and is covered in the product documentation.
So what to do if you need more than this? Easy; use the multinode plug-in to use more than one Orchestrator instance at the same time.
If you are using Orchestrator as your main tool for production, you might want to consider clustering it. Clustering provides high availability (HA) and load balancing of the number of workflows but does not increase the maximum connected vCenters / ESXi hosts / VMs to each Orchestrator. Clustering is not part of this book; however, you can find it in the second chapter of VMware vRealize Orchestrator Cookbook.
Working with Orchestrator became much simpler in the last year. As more and more people and companies adopt Orchestrator for their automation, many more publications and posts are created. The following listing is essentially a snapshot of the most used resources.
The official documentation for Orchestrator can be found on the VMware website. Go to https://www.vmware.com/support/pubs/orchestrator_pubs.html.
Please note that you can select the version you want to have the documentation for. It's always a good idea to read the Release Notes to understand changes to the current version.
There are not that many books on Orchestrator. Actually, there are only three books that I know of, counting the one you are reading right now.
The first one that was widely recognized was Cody Bunch's book Automating vSphere with VMware vCenter Orchestrator published by VMware Press Technology. The book is based on version 4 of Orchestrator, but is still valid for most of its content. Cody has some really good explanations and examples; however, a lot of the topics discussed and what is captured in that book will look different or might not work in the way described in version 6.
The other book about Orchestrator is VMware vRealize Orchestrator Cookbook that I authored, and was published by Packt Publishing in February 2015. It covers a lot of ground and if you are a total beginner, it's better to start with the book you are currently reading. In that book, we talk a lot more about specific plug-ins and how to use them. It comes with more than 100 workflows that can be directly used. The book was based on version 5.5.x and 6 of vRealize Orchestrator.
The VMware Orchestrator community is quite big and very active. You will find it under:
Here you can ask questions, find answers, and in general, obtain a lot of help. I recommend anyone looking for VMware related queries to start here.
There are quite a lot of websites and blogs that cover Orchestrator; we can't mention everyone, so here are the author's and tech reviewers' choices:
http://www.vcoteam.info/: This is Christophe Decanini and Burke Azbill's website. It contains a lot of topics starting from very basics up to some specialized plug-in handling. If you like to learn new things this is where you will probably find it.
http://kaloferov.com/blog/: This blog contains extremely useful code examples especially for PowerShell.
http://www.vcoportal.de/: Joerg Lew has been working with Orchestrator since 2004 and has collected an amazing amount of useful tips.
If you are looking for help on Orchestrator, one of the first things to do is search for the problem in Google. To help you find better results, you can use the following tricks (replace
[problem] with what you are looking for):
(vCO OR vRO OR Orchestrator) [problem]: Due to the renaming of Orchestrator, a lot of posts and blogs still use the old naming—vCO (vCenter Orchestrator). Using Google and the uppercase
OR, you can search for the old as well as the new name.
site:communities.vmware.com [problem]: The
site:tag will make sure that Google only looks inside the VMware communities.
In this chapter, we had a quick look at all the basic information that you need to know about Orchestrator. We covered what it does, how it does it, and where to download it from. We also looked at how to get additional information and help for Orchestrator related questions.
In the next chapter, we will deploy and configure the vRealize Orchestrator appliance.