VMware WebHook Shim and AutoScale with vRO

Auto-Scale VMware vRA Workloads with Web-Hook Shims

Hello Folks, this blog is a continuation to the two AutoScale blogs which was posted earlier, if you have not got a chance to look at it, please find the link below.

AutoScale vSphere Workloads with vRA and PowerShell based NetScaler NITRO API’s

Auto-Scale vRA workloads with vROPS,vRO and NSX.

Request vRA Actions on Behalf of other User with vRO

The approaches followed in my earlier two blogs for auto-scale was by using a SNMP policy which would capture the alert and invoke the workflow.

Well there are some caveats with this solution as i have noticed that the SNMP policy eventhough run’s perfect gives some issues some times and would stop collecting the traps from vROPS abruptly and what i ended up in doing is to restart the policy,

If that does not work restart the vco service itself by executing the below commands

service vco-server restart

and

service vco-configurator restart

when both the above commands are executed it effectively restart’s the vRO Server and vRO ControlCenter services.

Well this is a bit of pain to execute in a real production environment where there might be a huge number of tasks which are solely dependent on the SNMP polcy to trigger workflows.

Well there is a solution to this!!, Introducing Web – Hook Shims from VMware an amazing solution which basically works on the principle of REST Notifications from the vROPS server to invoke workflows, how cool is that!.

Forget the long iteration task of SNMP policies which would decipher 1000’s of alerts generated from vROPS , go through them one by one and invoke the workflow’s along with this the uncertainty of it not working some times as described in the above paragraphs.

Well to get started with this incredible technology you can follow the official Cloud Management Blog where we have detailed explanation on the concepts and also a step by step procedure on how to implement them by vROP’s Ninjas and scripting experts John Dias and Steve Flanders

The Self-Healing Datacenter (Part 1) – Using Webhooks to Automate Remediation

The Self-Healing Data Center (Part 2) – Installing the Webhook Shims for Automating Alerts

The Self-Healing Data Center (Part 3) – Configuring and Testing the Orchestrator Shim

The Self-Healing Data Center (Part 4) – Configuration of the vRO Example Workflow

The Self-Healing Data Center (Part 5) – Configure an Alert to Trigger the vRO Workflow

#######################################################################################

My good friend Sajal Debnath a SDDC veteran and scripting expert has written an incredible post on AutoScale too with both SNMP based triggers and Web-Hook Shims too, you can check it out here- http://vtechguru.com/2017/06/configure-auto-scaling-private-cloud.html

This blog also contains the packages for Scale IN too and an extensive video where he outlines why we need auto-scale , various aspects of how and when to use it and also the whole solution too as a walk through 🙂 . Please do check it out! highly recommended for the finer details!

#######################################################################################

Well once you go through all the above blogs and get your Web-Hook Shim setup up and running, lets see the sample workflow which is provided along with this in the github link.

Well you can see that there are three REST API’ calls which was made in the workflows to get the whole solution working

1. Get Alert from the Alert ID
2. Get Relations of the Resource from the Resource ID
3. Get Properties of the Resource from the Resource ID

All the 3 steps are used in conjunction with one another to extract the IP address of the Linux VM which is basically fed into the workflow “SSH Restart VMTools” to restart the vmtools service on the VM for which the alert gets generated on the vROPS server.

So now for our auto-scale solution , lets re-use this master workflow and create two new workflows which would help us to extract the

a) VM Name for the Citrix based AutoScale solution

As you can see in the above script, i just made a small change in the find parent resource scriptable task to extract the metric called “config|name” and its value

var properties = JSON.parse(contentAsString);

System.log(properties)

for (var prop in properties["property"]){
	if (properties["property"][prop]["name"] == "config|name") {
		vmname = properties["property"][prop]["value"];
		System.log("Virtual Machine Name is ---- " + vmname)
	}
}

Now you may be thinking how i narrowed down to this metric, well vRO has a Sytem.log(properties) function 🙂 based on which you can do this

Here’s an extract of the log details where we can clearly see the vm name mentioned in this metric.

Here’s a view from the sample run

If you keep a close eye on the Photon VM which has the Web-Hook shim’s installed you would see that the workflow gets started and you can see which workflow is triggered by having a look at the workflow id.

Here’s a view from the vRO logs

b) NSX LoadBalancer name for the NSX based AutoScale solution

Similarly for the NSX load balancer name, i made the below modifications, for some reason i saw that the LBName was not coming as an output from the Get Resource Properties workflow / REST call, hence i had to use the output of the GetResource workflow to extract this

Here’s the code which does this magic.

var resource = JSON.parse(contentAsString);

System.log("Resource  is" +resource)

for (var res in resource["resourceList"]){
System.log(res)
	if (resource["resourceList"][res]["resourceKey"].resourceKindKey == "EdgeServicesGateway") {
		System.log("Resource Kind Key is " + resource["resourceList"][res]["resourceKey"].resourceKindKey)
		var nsxlbname = resource["resourceList"][res]["resourceKey"].name;
		
	}
}

System.log("NSX LB Name is :- " + nsxlbname)

Here’s the extract of the log details.

Here’s a view from a sample run from the Photon VM and the vRO Logs.

Well once you get this setup ready lets create the Orchestrator shim instance for CPU and NSXLB to the outbound settings and define the workflow id at the end( highlighted in blue).

CPU Orchestrator SHIM instance – Workflow ID in blue is the id for “AutoScale with NetScaler” workflow

NSXLB Orchestrator SHIM instance – Workflow ID in blue is the id for “AutoScale with NSX” workflow

Now its the time to edit the notification settings on the vROPS server change it from the SNMP policy which is described in my earlier blogposts to the cool Orchestrator SHIM instance.

Change the method to Rest notification plugin and select the appropriate SHIM instance for both the CPU utilization alert

and the NSX LB hit alert as shown below

Once this is done also note you need to modify the auto-scale workflow’s and append the two new workflows which we created earlier and attach them as the input’s for the auto-scale action

CPU NetScaler Auto-Scale

NSXLB Auto-Scale

Once you have all the above steps completed!, you are good to go and would see that when alerts come in, the REST notification orchestrator SHIM for both the NSX LB and CPU based for NetScaler invokes the appropriate workflows and completes the autoscale actions as outined in the earlier blogposts

Attached are the vRO Workflow packages too – You can download them and modify it as per your environment and usecase.

Hope you enjoyed this blog and looking forward to share more wizarderies!! in the coming future !