As the use of vRealize Automation expands within datacenters use cases are becoming more complex. Users want to automate more of the less important tasks and focus on the real reason we even have infrastructure. The applications. Development teams don’t want to wait for the infrastructure and IT Administrators want to meet the needs of the developers.
One very useful feature of vRealize Automation to aid IT Administrators in providing infrastructure services to the developers quickly and efficiently is Multi-Machine blueprints. Multi-Machine blueprints provide the ability to provision a stack of infrastructure with theq2#A$E click of a button. Although they provide some very useful functionality they also have their challenges.
As the use of Multi-Machine Blueprints grow some of these challenges become more apparent. The most common challenges customers are facing when using Multi-Machine Blueprints are:
Blueprint Sprawl
Multi-Machine Blueprints are dependent on Single Machine Blueprints to function. As more Multi-Machine Blueprints are created it is necessary to create additional Single Machine Blueprints to adapt to the needs of the Multi-Machine app. These needs could be:
• Different naming conventions for different applications or groups.
• Different configurations within the deployed virtual machine.
• Different workflows that need to run against the different components.
While this is only a few of the reasons they are the most common I have seen. Whatever the reasons the common goal customers are asking for is for the ability to minimize the number of blueprints they have to maintain.
Server Naming
The single machine blueprint typically handles the naming of the component machines deployed by Multi-Machine services. Naming conventions are either configured in the blueprint or inherited by the business group under which the request was made. Often this is not flexible enough for the needs of the application being deployed.
This leads to additional blueprints being created so different naming conventions may be used for different Multi-Machine applications leading to the blueprint sprawl I already mentioned.
Administration of Deployed Machines
I frequently hear complaints from IT administrators that outside of vRealize Automation it is very difficult to determine the relationship of the deployed component virtual machines. They are deployed into vCenter and from there they are just virtual machines. There is no way to establish a relationship to help them understand they are part of the same application deployment.
This leads to increased complexity and management of the overall infrastructure in some environments.
The Solution
The solution to these and other similar challenges is vRealize Automation. I know I’m talking crazy, but it is really the solution. vRealize Automation was designed to be flexible. It was designed to allow you to customize it to meet your needs. The three issues I spoke about seem like pretty big issues that would be difficult to overcome. In reality they are very simple to solve.
Below are three example vRealize Orchestrator workflows that can be used with vRealize Automation to solve the three challenges I spoke about:
Custom Hostname Workflow
The custom hostname workflow which you can find on the Dailyhypervisor blog provides the flexibility to completely modularize you naming convention and provide custom naming of Single Machine Blueprints, Multi-Machine components, as well as the Multi-Machine app itself. It provides you all the flexibility you could ever need solving the hostname challenge.
Custom vCenter Folders Workflow
The custom vCenter Folder workflow that you can find on the Dailyhypervisor blog provides similar capabilities to the custom hostname workflow but aimed at vCenter folders. It provides a means to crate a folder named after the deployed Multi-Machine App in which you can place all the component machines allowing you to establish a relationship for the machines. It also support NSX and will move an NSX Edge deployed as part of a Multi-Machine to the app service folder.
Ultimate Multi-Machine Blueprint Workflow
The Ultimate Multi-Machine Blueprint Wokflow can also be found on the Dailyhyperisor blog really demonstrates the flexibility of vRealize Automation. This is a relatively simple workflow that significantly enhances the power of Multi-Machine blueprints. The workflow itself simply allows you to specify custom properties and determines which component machine the properties are applied to.
This now enables you to utilize the same single machine blueprint for each of the components and customize it based on it’s intended function significantly reducing the number of overall blueprints needed. This is just one use for this workflow. What you are able to do with this capability is truly up to your imagination.
Final Notes
In the end the point is that you may have needs that vRealize Automation doesn’t meet after initial installation, but it was built to support them. The workflows that I listed above are examples of what you can achieve. The ability to create these workflows is there for anyone and everyone. The next time vRA doesn’t do what you want it to do I challenge you to not throw your hands up and say it can’t do it, but to think about how you can make it do it. Chances are you will be surprised.
