VMware vRealize is one of the hottest topics around in virtualization circles right now. In this series of articles,...
I cover the basics of vRealize and how to install it in a test lab scenario. It will walk through building a very basic vRealize lab based on vRealize 6.2.
Editor's note: This is a basic lab. This is done so that the reader can grasp the fundamentals of the vRealize architecture without getting bogged down in the complexity of resiliency, HA, load balancing or other non-vRealize related infrastructure. The lab is in no way a production ready environment.
VMware vRealize, formerly known as VCAC (VMware vCloud Automation Centre) is a suite of products that helps a company leverage cloud infrastructure to reduce costs and provide internal, external and hybrid cloud infrastructure.
VRealize provides the ability to fully automate virtual server deployments, approvals, workflows and manage machine lifecycle management within one consistent interface. This platform helps control costs and virtual machine (VM) sprawl within an environment.
Every VM irrespective of hypervisor platform, physical or virtual, has a lifecycle of commission, use and finally decommission and vRealize can automate all of that, including the building and management.
Administrators can define the life of the VM in number of days, months or other set period of time. Such end to end automation reduces the number of machines that are forgotten about, never utilized or even over specified. This has a direct and quantifiable operational expenditure saving.
Automation and self service
VRealize removes the labor-intensive task of building and managing VMs. It replaces the concept of manual or semiautomated deployments such as templates with blueprints. Blueprints are made available to business administrators, groups or whoever you choose to have the ability to request VMs in the environment.
In a fully configured vRealize environment, a VM deployed from a blueprint should be capable of being started and ready for interaction without any manual intervention, even including ancillaries such as DNS and networks. This functionality saves a wealth of time for administrators and it also reduces the overhead that is associated with such requests and reduces errors.
Blueprints are held within the inbuilt service catalogue. As the name suggests, a catalogue is a collection of services that the business (read IT services) provides users. The users can then consume them via the self-service portal, which is a core component of vRealize.
The vRealize portal can be configured with various groups of users that are assigned roles -- as required -- to perform functions. VRealize is more than just a self-service portal however. The system is designed so an administrator can create logic workflows in vRealize to utilize them to handle exceptions or add additional capabilities to the portal. This logic also extends to include network related logic, IP configuration based upon the network and other items.
Each user on the portal has to be authorized and, depending on how vRealize is configured, the requests can be routed for approval by an elected business administrator (i.e., a manager). The main attributes of vRealize can be broken down into the following two categories
The blueprints and self-service functions, along with users are grouped together as a single "tenant." VRealize has multi-tenancy at its core. One example could be a modest-sized company that has both an engineering and a testing department. Each could be a tenant and have their own blueprints and services, as well as approvers, approval processes and even have different costing models should they desire it. In a default installation there is only a single tenant. Further tenants, if needed, will need to be added manually in the first instance.
Within a vRealize environment there are a number of administrator roles used to perform different duties within the environment. Each role is distinct from the others. In this lab we are breaking this separation since it's only a test lab.
The reason for having several administrator roles is to provide a degree of separation between the tenants, their daily use and the underlying infrastructure that is to be consumed (local or cloud). These resources are managed on behalf of the tenants. The last thing you'd want is a tenant administrator claiming all the resources or breaking the infrastructure somehow.
There are three types of administrators within a vRealize environment. These are:
- System administrator -- The system administrator is the individual who is responsible for configuring new tenants and manage infrastructure wide systems as well as system availability and logging. There is only one system administrator role per vRealize installation.
- IaaS administrators -- The IaaS administrator's job is to manage the infrastructure, endpoints and endpoint credentials for the resources that the fabric administrator uses. They also create the fabric groups and manage the infrastructure at a macro level. Again there is only one IaaS administrator role per installation.
- Fabric administrator -- Fabric administrators take care of the resources provided by the IaaS admin. IaaS admins bundle up the compute and cloud infrastructure resources and provide it to the fabric administrators. Fabric administrators set up the resource allocation to the business group.
There are also several fewer technical roles that exist with vRealize, such as business group managers, business users and tenant administrators.
In summary, vRealize could be seen as a marked departure from what could be seen as VMware's normal type of products. It makes life easier for the administrator and allows the business to provide a predefined set of machines and at the same time control the costs associated with their range of VMs.
In part two of the series, we cover the actual installation of the key servers that make up the vRealize infrastructure.