Auto scaling your application with the vRealize Suite
When I was advocating for vRealize Automation while in my previous role, a frequent question I was asked by application owners was: "Can I auto scale my application, like <insert cloud provider here> allows me to?" This question often lead to defensive responses on my part.
I'd fall back to proper planning, and the need to have your application designed for it, etc. This would always fall on relatively deaf ears. Thus when I stumbled on a blog laying out a framework for doing so, I was very excited. While Vinth's blog accomplished what it set out to do, it was very static in it's approach, leading me look for ways to adapt it into something a bit more flexible. Hopefully, between Vinth's blog and my updates you can take it even a step further. Without any further ado, let's get into it.
The vRO code, vROPS content, and vRA Cloud Templates we will be leveraging for this exercise are specific to my lab environment, however you should be able to leverage them in your environment by updating the tags with in the vRA Template to ensure proper resource/image/network selection.
Next, you will need to use the cloud template, vROPS alerts, and vRO code to do this. I have packaged these up in a single zip for you to download.
Lastly, for this to all work you will need a working and integrated deployment of the following systems:
- NSX-t 3.0
- vRA 8.2
- vROPS 8.2
This cloud template is dependent upon NSX on-demand networks and load balancing, as well as vROPS is dependent upon being able to call vRO workflows as part of the automated actions. The full details of setting this up is outside of the scope of this post. You can find some guidance on the vROPS + vRO integration in my blog series Day Two Automation Self Service Framework
It is possible that the code will work in earlier versions, but it was built and tested in those versions.
Our goal is simple: Monitor the web front ends of our web app.
- When one of them exceeds a given CPU utilization, trigger a vRA update request to add another front end.
- When one of them experiences CPU utilization below a certain threshold, trigger a vRA update request to reclaim a front end.
This is intended to be a demo of the Art of the Possible and needs a fair bit of polishing to be production ready.
Automation Set Up
Import net.sentania.autoscale.package into your vRO environment. There are two actions and two workflows. One each for scale-out, and one for scale-in.
You will need to edit each workflow and update the vRAURL with the appropriate value for your environment.
First - you will want to validate that vROPS is connected to your vRO instance and that it is properly importing the vRO Package you just imported. As I mentioned, if you need help with that, check out my other vROPS + vRO Series.
These three content items contain the definition of how vROPS will react when it detects the front end web server having high (or low) CPU utilization.
There are two additional steps you will need to perform to prepare vROPS.
- Create a new monitoring policy and configure it so that the Opencart frontend CPU is XYZ is enabled locally and set to enabled for automation, there is an additional vROPS export in the zip PolicyExample.xml This is a sample vROPS policy that enables the alerts and automation. You can import this and verify the changes you make to your policy match.
- Create a new Custom group, configure with dynamic membership for the vSphere tag serverType:frontend, and set it to use your newly defined AutoScale Policy
Import the cloud template from the zip file, and review the constraint tags so that they match valid selections in your environment. Key things to keep in mind:
- You will need a network profile that creates a network configured for Static and DHCP.
- You will need image mappings and flavor mappings that align with the template.
- The NSX Manager configure should be in manager mode and not policy mode. As of this posting, there is currently an issue with NSX tagging in Policy mode.
The template does tag the deployed VM in both vSphere and NSX. If the tags do not exist, it will be created - no need to prepopulate them. That said - if you don't want to clog your environment with tags - feel free to remove the tagging code.
The actions themselves are fairly straight forward. I won't do a full walk through some pseudo code is below.
1Get API Token
2Get all vRA Managed virtual machines from vRA API: ***/iaas/api/machines***
3Get MachineID of alarmed VM from result
4Get Alarmed Machine from vRA API: ***/iaas/api/machines/\<vmid>***
5Get Deployment ID from result
6Get Deployment from vRA API: **/iaas/api/deployments/\<deploymentid>***
7Get Deployment inputs from result
8Increment Deployment size
9Submit request to update the Deployment to added an additional VM
The Workflow as written is limited to 4 front ends that are supported. This is a combination of the cloud template design, and the workflow itself.
This is a pretty rough example and has a couple of opportunities for polishing:
- If a deployment has more then one front end, scale vertically before scaling horizontally.
- Take the portability of it further to allow for scaling of "other" applications
- Scale the database <-- This is tricky because the database is not set up currently to support HA
Hopefully you found this useful and find this example useful in finding new ways to leverage vROPS + vRA in new ways to power up your environment. Feel free to reach out if you run into challenges or have questions.