ktsdesign - Fotolia

Picking the right design for VMware vRealize Orchestrator

Choosing the right vRealize Orchestrator design option will determine how effective your environment runs. This chapter excerpt can help you make the right decision.

VMware vRealize Orchestrator aims to make life easier on admins who want to automate and streamline tasks inside a data center, but a challenge arises when you have multiple deployments. There are three common design options that administrators can use for the VMware vRealize Orchestrator: distributed, scale-out and cluster.

A distributed design is when you have multiple Orchestrator installations in different data centers, such as different countries, or when Orchestrator is in different environments such as production or development.

Cooking with VMware vRealize Orchestrator

Author Daniel Langenhan examines this and much more in his book VMware vRealize Orchestrator Cookbook - Second Edition. Langenhan covers everything you need to know about VMware vRealize Orchestrator, including basics like installing and configuring, to the more advanced topics, such as programming and plug-ins. In Chapter 3, titled "Distributed Design," Langenhan goes over the different obstacles admins face with VMware vRealize Orchestrator, including geographical and logical hurdles.

Langenhan also dives deeper into cluster design, noting the design is most powerful when combined with a load balancer. Throughout the chapter, Langenhan explains how to build an Orchestrator cluster with a walkthrough that includes preparation work and how to change cluster settings and content once complete. Other sections in the chapter include VMware vRealize Orchestrator load balancing, updating a cluster -- both minor and major upgrades -- and how to manage remote Orchestrators.

After a walkthrough of setting up a remote Orchestrator, Langenhan provides a step-by-step guide to creating proxy workflows. Admins can execute a proxy workflow and it will execute on both the local and the remote Orchestrator.

Below is an excerpt from Chapter 3, focusing on a cluster design:

A typical situation where a clustered Orchestrator (with a load-balancer) is a very good idea is when the Orchestrator acts as a domain manager. What is meant by that is that Orchestrator is responsible for automating the VMware domain (all things vSphere) and another automation tool (such as Ansible, Chef, or something else) uses the Orchestrator workflows. The domain manager concept is another solution to the automation problem. Instead of using one tool (such as Orchestrator or vRA) to automate everything, you use tools specialized for their domain. Examples of domains are VMware, Microsoft, Red Hat, EMC or NetApp storage, and Cisco networking. In each of these domains, a tool exists that is specialized to deal with the automation of its domain. For Red Hat there is Satellite, for Microsoft there is SMS or SCOM, and so on. Each of these tools has a SOAP or REST interface that can be accessed by a general management tool. Orchestrator would be a domain manager for VMware.

Next Steps

How does vRealize Orchestrator do more with less?

Enhanced administrative powers accompany vRealize Orchestrator

How does Orchestrator stack up against PowerCLI?

Dig Deeper on Scripting administrative tasks