vRealize Automation Data Object Overview
There are many types of data objects under the hood in the vRealize Automation databases. The intent of this section is to convey the purpose of the data objects and the relationships between them. Doing so will help you understand how the data is structured, the order in which they must be created, and the purpose for creating them.
The following figure shows the relationship of the various data objects that are most commonly interacted with.
Figure 1. vRealize Automation Data Constructs & Relationships
Endpoints represent data connections to external systems. Endpoints get registered with the vRealize Automation system, usually using a service account, which enables vRealize Automation to connect to the external system for the purpose of collecting data and managing interactions with the system.
There are numerous endpoint types available in vRealize Automation:
- Amazon EC2 – manages EC2 instances via AWS. Enables creation of instances based on AMIs in addition to elastic load balancers (ELB), EBS volumes, and key pairs.
- OpenStack – enables virtual machines to be provisioned off of an OpenStack instance including RackSpace and vSphere Integrated OpenStack among other flavors.
- vCloud Air – represents a connection to the providers available in the vCloud Air Network. This connection is essentially a specialized vCloud Director endpoint.
- vCloud Director – enables managing VMs and vApps on vCloud Director instances.
- vRealize Operations Manager – new in 7.3 is the ability to integrate with vRealize Operations Manager for workload placement decisions. Registering vRealize Operations Manager as an endpoint enables this feature.
- Network and Security
- NSX – previously, vRealize Automation utilized the vCloud Networking and Security product to allow for automated network build-out and tear-down. This functionality has been replaced with NSX integration allowing for full software-defined networking capabilities to be integrated with vRealize Automation operations.
- Proxy – allows you to define an HTTP proxy to send external web communications through
- vRealize Orchestrator – enables integration with vRealize Orchestrator nodes for callouts to workflows
- NetApp ONTAP – allows communication with NetApp products for storage array management integration
- Hyper-V (SCVMM) – management of Hyper-V servers either in standalone mode or through Microsoft System Center Virutal Machine Manager
- KVM (RHEV) – allows management of KVM servers and RedHat Enterprise Virtualization installations
- vSphere (vCenter) – the most commonly used endpoint, which allows management of vSphere environments
Compute resources represent physical hardware running in a datacenter, whether it’s on-premises in your organization’s space or in the cloud at another provider’s location. Compute resources represent:
- Hosts – single servers that may not be part of a cluster
- Clusters – an abstraction or pool of hosts clustered together
- Resource Pools – in vCloud Director, an organization virtual datacenter can be resource pool-backed. In these cases, it is possible to back compute resources with resource pools in vSphere, which are themselves a slice of physical compute resources
- Cloud Regions – in cloud environments, such as AWS, compute resources are abstracted at the region and availability zone level. Regions and availability zones are pools of hardware in the cloud provider’s datacenter, and in this way they are not unlike resource pools.
In order for provisioning of virtual resources to occur on top of physical resources, the compute resources must be discovered and managed by vRealilze Automation. This process occurs after an endpoint is registered. Compute resources from the endpoint are data collected and cataloged in the vRealize Automation database, after which they begin to be managed. This enables administrators to then begin the process of carving those resources up and allocating them to tenants and their business groups.
Reservations represent a slice of the physical compute resource pie. In some respects, a reservation is not unlike a resource pool. The point of a reservation is to set a quota on the amount of resources that are available for use by a particular business group. The specific constructs that make up a reservation vary depending on the endpoint and provider type, but the basic premise is the same.
Reservations have the following characteristics:
- Assigned to a single business group – each reservation is assigned to a single business group. A business group can be assigned many reservations across the spectrum of endpoint types.
- Maps a compute resource to a business group – each reservation ties one compute resource and a slice of its resources to the single business group it is assigned to. A single business group can be assigned resources on multiple compute resources by way of being mapped to multiple reservations.
- Allocates a set of resources from the compute resource to the business group – the reservation defines how much memory, storage, the number of virtual machines, and which networks are available for consumption with the reservation.
- Are utilized for placement decisions – the allocated resources, including storage policies, reservation policies, compute resource locations, amount of available space in the quota, and available networks are all used to help determine which reservation can meet the needs of a user’s request. These aspects are inferred from the full set of reservations available to a user at request time by matching the request details to reservations that can meet the request. If no reservation is available that can satisfy all of the requirements of a request, then the allocation step of a request fails resulting in a total failure of the request.
Business groups are very similar to security groups in a directory solution like Microsoft Active Directory. Business groups are used to define distinct operational groups in vRealize Automation who share similar resource needs, cost centers, and blueprint/service catalog requirements. Business group membership is determined by mapping a set of LDAP user and group principals to a business group object. When a user logs in to the vRealize Automation portal, their membership in these groups is determined based on their membership in the LDAP groups that have been federated with the Horizon Identity Management solution. Once they’re mapped to a set of business groups, their view of the service catalog is tailored to match the business groups for which they’re a member. Business group membership also has a role in determining which provisioned items can be seen and managed by the user.
A business group is local to a single tenant. They are mapped to one or many reservations which entitle the business group to a set of resources on physical hardware located either on-premises or off premises in a cloud or collocated compute provider datacenter. One or many entitlements are mapped to business groups to determine which catalog items members of the business group are allowed to see, request, and manage.
Entitlements represent permissions to see service offerings in the service catalog. A user can only request services from the catalog for business groups he or she is a member and for which one or more entitlements exist enabling those business groups to request services.
In addition to defining the set of service available in the service catalog, entitlements can also be utilized to map approval policies to those service requests, enabling a different approval route for one business group requesting the same service as another business group. In other words, entitlements enable us to define per-catalog item, per-service category, and per-business group approval policies.
We can also use entitlements to enable a subset of day-2 operations on provisioned resources, such as power cycle, reconfiguration, and destruction. The service blueprint defines the base set of available day-2 operations on any item provisioned from that blueprint. But we can further restrict these operations using entitlements, thus allowing us to set the enable operations on a per-business group basis.
As with provisioning request approvals, we can also set approval policies on day-2 operations and further divide them on a per-business group basis.
Catalog items represent a blueprint definition that has been published to the service catalog. The process is to first define the blueprint, which is a mapping of all the required steps and resources to instantitate a service offering when a user requests it. These blueprints cannot be requested by a user until they have been published to a catalog item. Further, the catalog items will not be displayed in the service catalog for any users who do not have an entitelement enabling them to request it.
Catalog items allow you to define icons and service categories for blueprints in the system. This affects the user interface of the service catalog and how the items are displayed to the end user.
Blueprints are at the core of the vRealize Automation product. A blueprint encompasses a definition of all the resources, networks, storage, virtual machine types, and procedures required to instantiate a service offering that a user will request from the service catalog.
Blueprints can be summed up as defining the steps required to repeatably and consistently produce a provisioned item of a particular type.
There are multiple types of blueprints:
- Blueprints – the basic type of blueprint which offers the converged design canvas from where multiple blueprints, components, and objects can be combined to create a single blueprint.
- Software Components – these represent the scriptable steps required to perform a software install and lifecycle management events, such as configure, install, and uninstall operations for a particular software package.
- XaaS Blueprints – XaaS Blueprints are vRealize Automation representations of vRealize Orchestrator workflows that have been mapped to service offerings. This gives administrators a way to enable users to request non-standard service types that are not always represented by a virtual machine provisioned on hardware. It also allows administrators to map these workflows as a component of other blueprints in order to perform callout operations via vRealize Orchestrator while provisioning other resources.
Blueprints can be constructed using the following elements:
- Virtual Machines – includes Amazon EC2, Azure, Generic, Hyper-V, KVM, OpenStack, vCloud Air, vCloud Director, vSphere, and XenServer machines/instances.
- Software Components – any software components that have been previously defined in the system.
- Blueprints – other blueprints that have already been defined in the system (i.e. blueprints can serve as building blocks for each other)
- Network & Security – includes container networks, existing networks, pre-existing or on-demand NSX security groups, NSX security tags, on-demand load balancers, on-demand NAT networks, and on-demand routed networks.
- XaaS Blueprints – consists of any XaaS blueprints that have been defined in the system.
- Containers – as of vRealize automation 7.2, hybrid blueprints consisting of both virtual machine types and containers managed in the Containers tab (powered by Admiral) can be included in a blueprint
- Configuration Management – callouts to configuration management tools like Puppet can be utilized to help with server configuration after provisioning
- Other Components – contains other components exposed through other interfaces not listed above