After having given an overview of cloud computing and a SDDC strategy, we will now focus on vRealize Automation. In detail, we will cover the different components of vRealize Automation and describe in detail how they interact with each other. Basically, vRealize Automation comprises three main components that can be identified as follows:
- vRealize Automation appliance: This is the main component, and is delivered as a virtual appliance in the Open Virtualization Format (OVF). Essentially, it hosts the web console (comprising the self-service portal). It also includes the Application Services and vRealize Orchestrator:
- vRealize Automation Infrastructure as a Service (IaaS): The installation files for the IaaS components are stored on the vRealize Automation appliance. The IaaS-components themselves must be installed on a Windows machine and are responsible for the provisioning of IaaS resources. Therefore, the Windows machine must be able to communicate with hypervisors, cloud environments and physical hosts.
- Authentication Services: The Authentication Services ship as part of the vRealize Automation appliance.
Besides these core components, there are additional appliances and components which extend the functionality of vRealize Automation:
- vRealize Orchestrator:Just as the Authentication Services, the Orchestrator is running on the vRealize Automation appliance, but it can also be deployed as a stand-alone appliance. vRealize Orchestrator is VMware’s central tool for all kinds of automation in the datacenter. It is also the preferred tool to extend vRealize Automation by any custom logic.
- vRealize Business Standard Edition:When it comes to costing, vRealize Business helps you to calculate the total costs of your datacenter, to price any services, to compare the prices of private cloud service offerings with public cloud competitors or to generate reports about the money spent on these service offerings. vRealize Business Standard Edition is deployed as a stand-alone appliance and integrates into the vRealize Automation self-service portal.
- vRealize Code Stream:Technically, from vRealize Automation 6.2 onwards, the vRealize Automation appliance also hosts vRealize Code Stream – an automation tool that helps DevOps teams to build a release pipeline and provision new applications to a productive environment. However, whilst technically hosted on the vRealize Automation appliance, it is a separate product and is not part of the vRealize Automation or vRealize Suite licenses.
| Background
With the release of vRealize Automation 7, the Application Services appliance no longer exists. However, some of the Application Service functionalities are available in the new blueprint model. This includes defining software and application components and many other functionalities. However, not all features of the Application Services are covered. Additional Application Services features will be added to vRealize Automation in a future release. Unfortunately, the migration of 6.2.x Application Services blueprints is not in the scope of the vRealize Automation 7 release. |
In addition to these components, there is also the need for further software components. For the IaaS components, an instance of SQL Server is required. Microsoft Active Directory is needed as an authentication source for the Authentication Services.
Many customers want to dynamically provision networks. In that case, VMware NSX can be used. In the recent versions, vRealize Automation has significantly enhanced its integration with VMware NSX to provide even more virtual networking and security capabilities.
The different components are depicted in Fig. 1
| Fig. 1: Logical overview of vRealize Automation components |
2.1 The components in detail
2.1.1 vRealize Automation appliance
The appliance is the heart of vRealize Automation. Introduced with version 6 of the product, it hosts the user interface, the self-service portal, an Orchestrator instance and now also the Authentication Services. Internally, it is based on the following components:
- Suse Linux Enterprise Server (SLES)
- vPostgresSQL as an embedded database
- tcServer as a Java Web Server
- RabbitMQ Message Broker
2.1.2 IaaS components
The IaaS components must be installed on a Windows machine and are certainly the most difficult ones to understand, install and maintain. The following set of IaaS services and web sites are required to run a vRealize Automation environment:
- IaaS Website
- Model Manager
- vCloud Automation Center Manager Service
- IaaS MS SQL Server database
- Distributed Execution Manager
- vCloud Automation Center Management Agent
- A proxy agent (for communication with hypervisors)
It is worth noting that despite the product name having changed to vRealize Automation in 2014, some of the component names still reference to “vCloud Automation Center”.
Basically, VMware wants to migrate the IaaS components to the Linux appliance in the long term. Historically, vRealize Automation was a pure Windows product implemented in Microsoft .NET up to version 5.2 There is still a long way for the transformation and we can only expect to see running everything on Linux in one of the next releases.
| Background
With the vRealize Automation 7 release, most of the Windows components remain untouched and continue to run on Windows. However, most noteworthy, business groups are not maintained on the Windows components anymore – they have been migrated to the Linux appliance. In the next releases we will probably see the other components (for example the Model Manager and the workflow components) running on Linux. |
In the following we want to discuss these components in detail.
2.1.2.1 IaaS Website
The IaaS website is based on the Internet Information Server (IIS) and hosts the Model Manager as well as the management interface for the communication with the vRealize Automation appliance. While the user interface runs basically on the main Linux appliance, the IaaS content is still generated on the Windows machine. The automation appliance only uses frames to display the IaaS information. These capabilities are available under the infrastructure tab on the automation appliance user interface.
| Background
If you have worked with vRealize Automation before, you might know that the web performance varies significantly. All the stuff coming from the Linux appliance loads quite fast, while the Windows components take significantly more time to generate their content. In vRealize Automation 7, these performance issues basically still continue whilst some performance tuning has been done. |
2.1.2.2 Model Manager
The model manger represents the heart of the IaaS components. Running within IIS, its basic tasks are to encapsulate the Microsoft SQL Server database and provide access to the IaaS data via web services. Furthermore, all information, logic or any other artifacts that are needed to execute workflows on external systems (like VMware vSphere, Microsoft System Center Virtual Machine Manager, Cisco UCS Manager, etc.) are stored within the Model Manager. Distributed Execution Managers (DEMs) use this information later on to provision IaaS resources. For high-availability reasons, the model manager can have multiple instances that run on different hosts within the vRealize Automation environment. Internally, the Model Manager has the following components:
Data model and REST interface
We just mentioned that all data is stored within a Microsoft SQL Server and there is a REST web service to retrieve this data. The interface helps to expose the data as entities. Internally, the REST interface is implemented by means of the Microsoft .NET framework. If there is the need to directly interact with the model manager, using the REST interface is certainly the easiest way to do so – we will show that later in chapter X (however, remember that the Linux appliance also exposes most of the data via its own REST interface, which should be used when possible).
| Background: REST
Representation State Transfer (REST) represents an architectural style, which can be used to implement web services. From a technical point of view, it uses the HTTP verbs GET, POST, PUT, DELETE as well as URLs to provide access to resources. The following samples show how to use the REST architectural pattern: GET /items # Read all items GET /items/:id # Read one item POST /items # Create a new item PUT /items/:id # Update one item DELETE /items/:id # Delete one item Because of its simplicity and scalability, it is currently the most popular technique used when implementing web services. |
Security information
The model manager also stores permissions, such as who is able to see what kind of data and which actions can be invoked on an IaaS resource.
Workflows
We have already discussed that vRealize Automation provides the means to provision resources to different platforms (physical, virtual and cloud environments). However, depending on the underlying platform and the provisioning technique, there is the need to have different workflows stored in the model manager. It is also possible to extend these built-in workflows with custom logic. Indeed, there are plenty of use cases for that and we will deep-dive into that topic later in the extensibility section of the book. Typical use cases for extending the build-in workflows are registering a machine within a Configuration Management Database (CMDB), integrating the machine into a Puppet environment or running a custom script after provisioning.
Events and triggers
Another important functionality of the model manager is to register custom events within the data model. There are also plenty of use cases for that. For example, if you change a property of the machine from the self-service portal, it might be nice to have a trigger installed that automatically forwards such changes to a CMDB database.
2.1.2.3 vCloud Automation Manager Service
The vCloud Automation Center Manager Service runs as a Windows service and is responsible for the interaction between Model Manager, database, vRealize Automation agents, Active Directory and SMTP. There is not much to configure in this service, however, you must make sure that this service is running just once. When installed, it must be ensured that the service has administrative privileges to run on the IaaS host.
2.1.2.4 IaaS MS SQL database
As we have already discussed, IaaS uses a Microsoft SQL Server to store all of its data. Currently, only Microsoft SQL Server is supported. If you want to prepare for high-availability, you should consider implementing a Microsoft SQL Server failover cluster. While database mirroring or replication should be possible, VMware’s ‘preferred way’ is to set up a cluster.
2.1.2.5 Distributed Execution Manager (DEM)
While the workflow logic itself is stored within the model manager, it is not the model manager itself that executes the workflow. Instead, this is done by DEMs. Basically, DEMs are in charge of talking to the model manager, fetch some work and then execute any workflow. From a technical perspective, there are two different kinds of DEMs:
- The DEM orchestrator communicates with the model manager and schedules the workflow execution. The DEM orchestrator only monitors the execution of the workflow, but does not do the work itself. As there is a lot of interaction between the DEM orchestrator and the Model Manager, it is recommended to install the DEM orchestrator on, or ‘near’ to the Windows machine hosting the Model Manager. At any time, only one DEM orchestrator can be active within the vRealize Automation installation. For high-availability reasons, it is therefore always a good practice to have a failover machine, which could become active in case of any failure.
- DEM workers are responsible for the execution of workflows. In contrast to DEM orchestrators, multiple workers can be active at the same time. This might be useful for scalability as well as for high-availability purposes. Because DEM workers interact with external resources, they should be installed as ‘near’ as possible to the system they are provisioning to. As described, different DEM workers can exist in parallel. Sometimes we want to define where a certain workflow should be run (e.g. in a special location or in a machine which meets specific requirements). This can be configured by the means of skills. Essentially, a skill is a relationship between a DEM worker and a workflow. This means that a workflow can only be run by a custom DEM worker which resides on a certain host. Technically, to run a workflow, a DEM worker will contact the model manager and download all the artifacts needed (e.g. some scripts) to run the code. DEM workers regularly contact the model manager and ask for new work. The interaction between the model manager and the DEMs is depicted in 2.
| Background: Workflow engines
As of vRealize Automation 6, custom workflows can be implemented both in Orchestrator as well as in .NET, so there are two competing workflow engines within the same product. It is recommended to use Orchestrator for custom workflows wherever possible, as VMware plans to shift away from .NET in the long term. |
| Fig. 2: Model manager and DEM interaction |
2.1.2.6 vCloud Automation Center management agent
Before being able to run the installation wizard on the Linux appliance, administrators must ensure that the vCloud Automation Center Management Agent is installed on every Windows machine. The basic task of the agent is to collect support and telemetry information and register IaaS nodes with the vRealize Automation appliance. As well as the manager service, the management agent is installed as a Windows service.
2.1.2.7 Proxy agents
As discussed, DEMs interact with external systems in order to run workflows on them. Unfortunately, in some cases they lack the knowledge to interact directly and need the help of agents. This is especially true for hypervisors (like vSphere, Hyper-V), which were implemented in the first versions of vRealize Automation (support for other hypervisors like KVM, Redhat Enterprise Linux OpenStack, Amazon Web Services, Dell iDRAC or Cisco UCS was later directly implemented in the DEM). Right now, there exist several different kinds of agents:
- Virtualization proxy agents are used to interact with hypervisors. They are responsible for the provisioning of a machine or for synchronizing hypervisor data with the vRealize database (e.g. importing virtual machine data from the hypervisor). Agents are installed as Windows services and must be installed and configured for every single virtualization environment. This means, if you want to address three different vCenter Servers, you must install three different agents. There are virtualization agents for vSphere, Hyper-V and XenServer.
- Virtual Desktop Integration (VDI) agents help with registering of virtual machines in external desktop management systems. One of the most popular VDI systems is Citrix XenDesktop. After provisioning and registering, vRealize Automation provides the owners of registered machines with a direct connection to the XenDesktop Web interface. A single installed agent can communicate with a single Desktop Delivery Controller (DDC) or with multiple DDCs.
- External Provisioning Integration (EPI) PowerShell agents help with the on-demand streaming of Citrix disk images, from which the machines boot and run. An EPI Agent for Visual Basic helps to run visual basic scripts as an additional step in the provisioning process (the script can be invoked before or after provisioning a machine or when deposing).
- Windows Management Instrumentation (WMI) agents allow the collection of information for machines under vRealize Automation control. This is required if you want to provision machines via Windows Image File (WMI).
| Background: Guest agents
There is another kind of agents in vRealize Automation, which are not part of the vRealize management infrastructure, but are installed instead on the templates to be provisioned. These agents are called guest agents. Guest agents communicate via SSL to the IaaS server and can be used to perform post-provisioning tasks. |
As a conclusion, Fig. 3 shows the interaction between the different IaaS components.
| Fig. 3: IaaS components interaction |
2.1.3 Authentication Services
One of the biggest changes in the new release of vRealize Automation is that the Identity Appliance has been removed. Instead, the vRealize Automation appliance already comes integrated with the Authentication Services.
The Authentication Services support a single Active Directory (AD) or a multi-domain AD forest. Multi-forest enables you to deploy multitenant configurations. Multitenancy refers to the ability to have segregation for authentication and most of the vRealize Automation resources and configurations, so that you can support multiple customers or companies. There is no 1:1 relationship between a tenant and a domain. With the Authentication Services, it is possible to connect multiple domains to a single tenant as well as to map a single domain to multiple tenants.
It also made sense to natively integrate the Authenticate Services from a branding perspective. All the security-related screens such as login-screens have the same look-and-feel like the vRealize Automation self-service portal, but can – of course – be customized.
The Authentication Services also support adding additional layers of security to the self-service portal. There is native support for 3rd party SAML Token as well as out-of-the-box smart-card and multi-factor authentication capabilities.
For security reasons, auditing is also supported.
| Background: vSphere SSO
In former versions of vRealize Automation, there were no Authentication Services included –instead, the vSphere SSO component was used (if you did not want to use your existing SSO component, you also had the choice to deploy a dedicated Identity Appliance). However, with the new version of vRealize Automation, VMware decided to shift away from the SSO components and to use the Authentication Services instead. The Authentication Services have not been implemented from scratch – they come from the VMware View product and are well proven. The main reason to move away from the old SSO appliance was that the main use case driver of the vSphere SSO component is the vSphere infrastructure itself and not any enterprise use case like multi-factor authentication, Kerberos, customizable access device rules or SAML integration. |
From a technical point of view, users and groups are now synchronized with the Authentication Services data store, which also leads to a better runtime performance. The architecture of the Application Services is depicted in Fig. 4. Chapter 5 will cover in detail how to configure the Authentication Services.
| Fig. 4: Authentication Services architecture |
2.1.4 vRealize Orchestrator
Another important tool within vRealize is Orchestrator which helps you to automate your environment. The vRealize Automation appliance already ships with an embedded Orchestrator instance (including plug-ins for vRealize Automation, NSX and vRealize Code Stream). If you don’t want to use the embedded Orchestrator instance (for performance and high-availability reasons), you can still deploy your own Orchestrator instance, or use the one bundled with vCenter Server.
You can use Orchestrator for different technical use cases.
Firstly, if you want to provision XaaS services to the service catalog, the underlying workflows must run in Orchestrator. From a developer’s point of view, the first step is to create these workflows in Orchestrator. When you are finished with that, the next step would be to build a graphical frontend with the Advanced Service Designer (ASD) and then to publish the workflow to the service catalog. There are many use cases for the ASD and we will cover some of them in chapter X. Under the hood, Orchestrator already ships with over 300 different workflows, so that in many cases you don’t need to create a workflow from scratch, but can modify existing ones.
You also need Orchestrator if you want to customize the way machines are provisioned. There are really plenty of use cases for that. For example, if you are not happy with the hostname and IP address assigned by vRealize Automation, you could call a workflow to invoke an IP address management (IPAM) tool such as Infoblox instead. Many companies also need to register their resources into a configuration management database (CMBD). There are plenty of other scenarios where Orchestrator would be the right component for customization – we will talk more about them in a later chapter. Fig. 5 shows the machine lifecycle of a virtual machine in vRealize Automation and the separate stages where customization can occur.
| Fig. 5: Machine lifecycle in vRealize Automation |
In addition, Orchestrator is also required for NSX configuration within vRealize Automation.
The new release of Orchestrator has a lot of new noteworthy features integrated. Most important, there is a new event broker available that allows to subscribe to lifecycle events, allows blocking and non-blocking subscriptions and makes the old .NET based lifecycle callouts obsolete. In addition, vRealize Orchestrator offers a new Control Center for monitoring workflows and troubleshooting.
2.1.5 vRealize Business for Cloud
In most environments, it is important to have insight into your costs (i.e. to find out ‘who’ is responsible for what costs and show these costs in a transparent manner). Showing costs was already possible with vCloud Director: There was a tool called vCenter Chargeback manager. From vRealize Automation 6 onwards, VMware shipped vRealize Business Standard as a dedicated tool for cost showback and price calculations.
With vRealize Business 7, VMware now provides a fast and accurate cost, pricing and reporting engine. This includes automated pricing for vRealize Automation endpoints in order to provide a single source for cost & pricing and having a centralized reporting.
| Fig. 6: Service catalog pricing |
There are also a lot of changes in the new release of vRealize Business. Most notably, all cost configuration has been moved to vRealize Business (e.g. there is no cost profile in vRealize Automation itself). Also, there is a lot more information regarding show back, pricing and cost transparency. Unfortunately, vRealize Business still does not support the pricing of XaaS services.
Fig. 6 shows the detailed pricing information for users about provisioned resources. We will cover vRealize Business for Cloud in detail in a later chapter.
2.1.6 NSX
Another important VMware product within the cloud ecosystem is NSX. NSX provides network virtualization and a security platform for the software-defined datacenter. Amongst other things, NSX has the following capabilities and features:
- Creation of logical networks.
- Provisioning of networking and security gateways (i.e. firewalls, NAT Router, Load Balancing, VPN or DHCP).
- Creation of VXLAN network (a logical layer 2 network which can encompass different locations).
- Data Security (analyze network traffic for sensitive data).
While NSX is not part of any vRealize Automation edition, there is nevertheless tight integration – which has been further deepened in the current version of vRealize Automation. When integrated into vRealize Automation, NSX components can be orchestrated and automatically provisioned created from an ordinary deployment processes. This is useful when the mere provision of virtual machines is not enough and micro-segmentation is needed for each application. In addition, NSX load balancer can be dynamically provisioned from the service catalog.
Fig. 7 shows the integration of NSX into vRealize Automation blueprints. vRealize Automation allows to automatically deploy NSX components when provisioning a service to the user.
| Fig. 7: NSX integration in vRealize Automation |
2.1.7 Code Stream
One of the most recent products from VMware is vRealize Code Stream. vRealize Code Stream is technically bundled with vRealize Automation. However, you need to separately purchase this and then unlock its functionality within the graphical user interface by way of a serial number.
vRealize Code Stream helps teams that want to use DevOps practices in their company to become more productive. Basically, the product helps developers with the following features:
- It automates the different tasks required to provision, deploy, test, monitor and decommission software for a specific release.
- It helps to assure standardized configurations by coordinating the artifacts and processes across each release delivery stage.
- Governance is provided as well. This includes control across the end-to-end process in the delivery pipeline.
2.2 vRealize Automation Licensing
Like many other products from VMware, vRealize Automation comes in different editions: There is an advanced and an enterprise edition available. Furthermore, vRealize Automation is available as a stand-alone product or as part of the vRealize Suite or vCloud Suite.
| Features | Advanced | Enterprise |
| Self-Service with unified service catalog and API functionality | X | X |
| Multi-vendor virtual, physical and public cloud. | X | X |
| Infrastructure as a Service (IaaS)
· Single and multi-tier machine provisioning and comprehensive life-cycle management · Network and security configuration
|
X | X |
| Anything as a Service (XaaS)
· Authoring of custom IT services · Can be deployed as a catalog item or day two operation
|
X | X |
| Application Authoring
· Software component authoring and application stack provisioning · Dynamic software scripting and dependency bindings · Application centric network and security configuration
|
X |
Many companies, however, will not purchase vRealize Automation as a stand-alone product, but as part of the vRealize or vCloud Suite, so it makes sense to talk about these licensing options as well.
vRealize Suite licensing
VMware positions the vRealize Suite as a solution to build an enterprise-ready cloud management platform. This includes the following functionality:
- The ability to provision, monitor and manage applications, infrastructure and custom IT services.
- Management of a Software-Defined Data Center (SDDC) across compute, storage and network resources.
- Management of public clouds, third party hypervisors and physical servers.
As you know, the vRealize Suite includes a set of products to help you build the aforementioned solution. The list of products includes:
- First of all, vRealize Automation
- vRealize Operations for health, performance and capacity management.
- vRealize Log Insight for log collection and analysis.
- vRealize Business for Cloud for automated costing, usage metering and service pricing.
Not surprisingly, the different vRealize editions include a different set of these products. Recently, VMware tried to provide a theoretical framework for delivering these different versions: The editions correspond to different requirements in your enterprise, i.e. if you want to have managed virtualization, intelligent operations, automated IT to IaaS or even DevOps-Ready IT.
There is no need to talk about managed virtualization, because that’s VMware traditional business, the vSphere business. The other initiatives are shown in the following table.
| Initiative | Description | Product edition |
| Intelligent Operations | Targets IT operations that wish to increase operational efficiency as well as application performance and availability | Standard |
| Automated IT to IaaS | Accelerates the delivery of IT infrastructure by automating their delivery and ongoing management | Advanced |
| DevOps-Ready IT | For IT organizations with Dev-Ops initiatives who want to automate the delivery and management of full application stacks | Enterprise |
Tab 1: vRealize editions
To make things even a little bit more complicated, it also depends on the product edition which features can be used (see the table below):
| Capabilities | vRealize Standard | vRealize Advanced | vRealize Enterprise |
| vRealize Operations: Application monitoring | X | ||
| vRealize Automation: Application Automation | X | ||
| vRealize Automation: Infrastructure Automation | X | X | |
| vRealize Business for Cloud: Cloud planning | X | X | |
| vRealize Business for Cloud: Cloud compare and costing | X | X | X |
| vRealize Log Insight: Log Analytics for SDDC | X | X | X |
| vRealize Operations Advanced: SDDC Monitoring for Hybrid Clouds | X | X | X |
Tab 2: vRealize editions and features
Last but not least, the new vCloud Suite 7.0 now includes all capabilities of the vRealize Suite 7.0 and is another way for customers to get the vRealize Suite.
Portable License Unit
With the advent of the vRealize Suite 7.0, VMware has also updated its way to license the workload across systems. The new way of licensing workload is called Portable License Unit (PLU) and enables customers to take licenses and use them on-premise or for virtual machines running in the cloud. This also includes non-VMware platforms such Amazon Web Services. One PLU allows usage of vRealize Suite to manage unlimited OSIs/VMs deployed on one on-premise vSphere CPU or up to 15 OSIs deployed on the public cloud including vCloud Air, vCloud Air Network Partners, other supported public clouds, as well as third-party hypervisors and physical servers. PLU allows the continued usage of current deployments of vRealize Suite even when the underlying infrastructure for workloads change from on-premise to off-premise and vice versa. The licensing metric will be converted automatically, so there is no need to switch the licenses.
2.3 Summary
This chapter discussed the architecture of vRealize Automation. The main components are the vRealize Automation appliance and the IaaS components. Furthermore, there are also other components such as the Authentication Services, vRealize Orchestrator or vRealize Business. Altogether, they form the vRealize Automation environment. It is crucial to understand the roles of these different components in order to create a design for a vRealize deployment and begin with the installation.
Recent Comments