vRealize Orchestrator (vRO) is the new name (since October 2014) of vCenter Orchestrator (vCO). In this book, we will refer to vRO/vCO simply as Orchestrator.
This chapter is dedicated to the configuration of Orchestrator and discusses how to set the tone for your Orchestrator deployment. Configuring Orchestrator wasn't easy in the past; therefore, not many people really used it. But now, the initial configuration is already done out-of-the-box and people can start using Orchestrator without too much fuss. However, if one plans to use Orchestrator in a production environment, it is important to know how to configure it properly.
There are four different Orchestrator versions. One version is shipped with vCenter Server and the other with vRealize Automation appliance. Then, there is the Windows-based installation and a preinstalled Linux appliance.
The vRealize Automation (formerly vCloud Automation Center or vCAC) appliance is shipped with a preinstalled and preconfigured vRO (Orchestrator). Orchestrator installed on vRA is already configured and works the way the normal Orchestrator appliance does.
If you are using the vRA-integrated version, just read all the recipes in this chapter and the next chapter as if you are using the appliance.
You can read more about vRA Orchestrator integration in the introduction to Chapter 7, Working with VMware Infrastructure.
The question most people are asking these days is what type of Orchestrator should one use for a production environment or which one is recommended.
There isn't really a right answer. The appliance runs on Linux and therefore consumes less CPU and memory and, saves money on a Windows license. However, more people are familiar with Windows than with Linux.
There is another fact that one should be aware of. VMware has already announced that the Windows version update from 5.1.x to 5.5.x will not update the database. This, in my personal opinion, indicates that the Windows version doesn't receive as much attention from VMware as the appliance version. However, the version that is installed along with vCenter is pretty integrated; see the first recipe of this chapter.
A consideration you should be aware of is that, depending on your Windows security settings or other installed applications, such as antivirus, backup agents, or infrastructure discovery agents, your Windows Orchestrator installation might be impaired.
So, what is right for you? My personal preference and that of most of the VMware consultants I know is the appliance; it is easy to use, install, and update. However, keep in mind that Windows works just as well.
Another question that is constantly asked is: Should one install Orchestrator on the same server as vCenter or vRA? As with the issue of appliance or Windows installation, it really depends on the objective of your Orchestrator installation. Installing Orchestrator on a vCenter Server where the Single Sign-On (SSO), the Web Client, Inventory, and vCenter services are already competing for resources makes quite an impact. If the Orchestrator installation is aimed at automating a sizable production environment, sharing Orchestrator resources with vCenter isn't such a great idea. For a small environment, a shared vCenter/Orchestrator VM can be quite a good solution.
The vRA-integrated Orchestrator installation is also fine for smaller environments; however, if you plan to automate a production environment with vRA, it is recommended that you use a separate Orchestrator installation and maybe even an Orchestrator cluster (see Chapter 2, Optimizing Orchestrator Configuration).
What it basically comes down to is managing the Java heap sizes of the different services (see the Tuning Java recipe in Chapter 2, Optimizing Orchestrator Configuration). A correct sizing of all the Java heap sizes (vCenter services as well as Orchestrator) will allow a good coexistence of all services. However, you should consider issues such as manageability as well as the ability to monitor and update all the services.