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 |
20 |
|
Maximal concurrent connected ESXi hosts |
1280 |
|
Maximal concurrent connected VMs |
3500 |
|
Maximal concurrent running workflows |
300 |
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.