My LBaaS Journey part 1

My upcoming blog posts will be dedicated to my LBaaS journey. With LBaaS, I am referring to “Load Balancer as a Service”. In my journey, I am going to explain how you can create a NSX based  edge device, configured as a vRealize Automation 7.x Infrastructure Load Balancer what will be offered as a self service catalog item within vRealize Automation.

The first part of the journey is all about the relevant REST API calls to the NSX manager. On a high level, the following steps will be followed in this part of the journey.

  • Create the NSX Edge device
  • Configure the NSX Edge device as a vRA 7.x infrastructure Load Balancer
  • Capture the NSX Edge device config via a REST API call
  • Modify the NSX Edge device config
  • Deploy a new NSX Edge device via a REST API call

In the next section, I am going to explain these high level steps in much more detail

  1. The first task is to create your nsx edge device and configure it as you want. Because my use-case is all about creating a vRA 7.x Infrastructure Load Balancer, I used the following VMware document as my reference (https://docs.vmware.com/en/vRealize-Automation/7.4/vrealize-automation-load-balancing.pdf).  The NSX-V version I am using is 6.4.3. Please write down the Id of the nsx edge device, we need this Id later in this blog-post. The Id of my template nsx edge device = edge-60.
  2. No we have created the template nsx edge device, we want to capture all of it’s configuration. To achieve this, we need to execute a REST API command to the NSX Manager. However, before we can execute REST API commands to the NSX Manager, we need to authenticate to the NSX Manager REST API. I am using Postman in this blog-post as my REST Client. In the below screenshots, you can see how I managed to get an Authorization Header for my future REST API calls to the NSX Manager.
  3. Now we have the Authorization Header, we need to add two additional Headers. With these two additional headers, we make sure that the Response Body of the REST API call, will be in json format.
  4. Now we have all the ingredients to execute the right REST API call to capture the configuration of our template nsx edge device, we can execute the following REST API call.

    Make sure you have the 3 Headers configured as explained earlier in this blog-post. As you can see in this REST API call, we also needed to provide in here the Id of the template nsx edge device. The outcome of this REST API call is the configuration of the template nsx edge device in json format.
  5. Now we have the main configuration of our template nsx edge device in json format, we are able to modify the contents. In this blog I am going to modify the following information:
  6. The contents of the new configuration file used in my example looks now like the following:
  7. We can now try to deploy the template nsx edge device based on the modified json file as the REST Request Body. Again make sure you have also the 3 Headers configured . Now execute the following REST API call.

  8. As you already discovered, the REST API call failed with the following error “HTTP Status 400 Bad Request”
  9. The reason for this error is due to a missing password in the REST Request Body. This missing variable and it’s value are not part of the GET REST API call. To fix this issue with the REST API call, you need to modify the REST Request Body again and include the variable “password” with your password as the value. See the below example.
  10. After we included the password variable into the REST Request Body, we can finally deploy a new nsx edge device based on the json configuration file. Again make sure you have also the 3 Headers configured. Execute again the following REST API call. This time the REST API call should succeed and it will return a status of 201 Created.


  11. After a few moments you will see in your vCenter Client that a new nsx edge device has been deployed.

This is the end of part 1 of My LBaaS Journey blog series. I hope you enjoyed! In the next part of my Journey, I am going to develop a vRealize Orchestrator Workflow based on the REST API calls demonstrated in part 1 of the Journey.

Rubrik Dynamic Day2Operation with vRealize Automation

In my previous blog we created a dynamic populated drop-down list with all available Rubrik SLA domain names. This drop-down list was used in a standard vRA IaaS request form when requesting a new virtual machine.

After doing some testing at my customers environment, we discovered that our current approach for facilitating backups with Rubrik through vRealize Automation was not efficient enough.

This was caused by the behavior of how Rubrik can include a virtual machine into backup. Before a newly deployed virtual machine is available for assigning a SLA domain name, it needs to be recognized by Rubrik. To be recognized by Rubrik, we needed to force a Rubrik discovery of vCenter objects after every virtual machine deployment with vRealize Automation.

This resulted in long virtual machine deployment times because every  deployment needed to wait on a task for Rubrik discovery of vCenter objects. To make it even worse, multiple tasks for Rubrik discovery of vCenter objects get queued when more virtual machines are requested frequently or simultaneously. Eventually this resulted in failed virtual machine deployments because the vRO actions used in the Rubrik vRO workflows are receiving a time-out.

However, out-of-the-box, a Rubrik discovery of vCenter objects task is triggered a couple of times per hour. With the knowledge that you can assign a default SLA domain on vCenter objects (vCenter Server, vCenter Cluster or vCenter ESXi Host), we decided to change our backup strategy.

We are now assigning a default SLA domain name on the vCenter Cluster level, so every requested virtual machine with vRA will be automatically in backup. Instead of asking the SLA domain name on the the vRA request form, we are now offering a vRA Day2Operation to dynamically change the Rubrik SLA domain name. This blog reveals how we configured this vRA Day2Operation.

  1. First we created a copy/duplicate of the Rubrik vRO workflow “Rubrik Assign VM to SLA Domain”. Name this new workflow “Rubrik Change SLA Domain”.
  2. Edit the “Rubrik Change SLA Domain” workflow. Go to the presentation tab and add a property of the type “predefined answers” to the input parameter “slaDomainName”.
  3. Assign the action “rubrikGetAllSLA” (The one we created in my previous blog post) as a value to this new property.
  4. Save the new workflow and it is ready to be used as a Day2Operation in vRealize Automation.
  5. Now create a resource action in vRA based on the newly created vRO workflow “Rubrik Change SLA Domain”.
  6. Next, publish the resource action and assign it to your entitlement.
  7. When you now select your provisioned virtual machines under Items in vRA, you will see your newly created Day2Operation “Rubrik Change SLA Domain”.
  8. Now lets test the new available vRA Day2Operation. After you select it, it will ask you for the new Rubrik SLA domain name. Make you choice, change the Rubrik SLA domain name of your virtual machine and click Submit.
  9. Thats’s it! You now have changed the Rubrik SLA domain name of your virtual machine. Enjoy consuming Rubrik through vRA.

All available Rubrik SLA domain names dynamically populated in standard vRA IaaS Request Forms

Anyone familiar with Rubrik? Rubrik Cloud Data Management delivers automated backup, instant recovery, offsite replication, and data archival in a simple, scale out platform built for hybrid cloud. For more information go to https://www.rubrik.com/product/overview/

My current customer is using Rubrik as a backup solution for their vSphere managed virtual machines. They are also using vRealize Automation 7.x as their preferred private cloud solution.

With vRA 7 they automated the deployment of their Windows and Linux virtual servers. As part of their deployment process, they needed an automated integration with Rubrik. They asked me to dynamically populate a drop-down list on a vRA 7 request form with all available SLA domain names from their Rubrik environment. These SLA domain names must be based on actual “live” information. One of the good things about Rubrik, is that it ships with a REST API.  This blog reveals how I full-filled my customer use case.

  1. To start the integration with Rubrik into vRealize Automation, I downloaded the latest version of vRealize Orchestrator package for Rubrik. This package is compatible for Rubrik v3.0 API calls. You can download this package from the following location: https://github.com/rubrikinc/vRO-Workflow/releases/tag/3.0.0
  2. Now import this vRO package into your vRO environment. It contains the following workflows and actions, a configuration element and a rubrik logo.
  3. To configure the Rubrik integration into vRealize Orchestrator, you have to run the vRO workflow “Rubrik Add Cluster Instance”. This will add a the Rubrik appliance as a REST Host to the vRO Inventory section and will also store the required Rubrik information in a vRO configuration element.
  4. To address my customer requirements, I needed to create a vRO action that combined a couple of the Rubrik library actions including a slightly modified Rubrik library action. On top of this I needed to remove any input requirements for these vRO actions to simplify the integration into vRealize Automation. The populated vRO configuration element with all the required Rubrik information was very helpful for this challenge.
  5. I created a copy of the Rubrik Library action “rubrikGetSLAID” and named it “rubrikGetAllSLA”. Inside the “rubrikGetAllSLA” action, I stored the values of the required Rubrik configuration element attributes into local variables to feed the inputs of the called out Rubrik Library actions “rubrikGetToken” and “base64Encode_1”. As a result of this, I was able to run the modified Rubrik Library action “rubrikGetSLAID” which returns an array of strings containing the available Rubrik SLA domain names.
  6. The contents of the vRO action “rubrikGetAllSLA” is shown below.
  7. The result of the vRO action “rubrikGetAllSLA” is shown below.
  8. To dynamically populate a drop-down list in a vRA 7 standard IaaS request form with all available Rubrik SLA domain names, I needed to create a custom property with the name “Vm.RubrikSLADomain” on the standard IaaS blueprints for the Windows and Linux deployments. Secondly I needed to create a vRA property definition based on an external value, which is in fact the vRO action that I created before. Below is my example of this vRA property definition.
  9. Finally, when I request a new virtual machine with vRealize Automation 7.x, it looks like the screenshot below. (The below example is based on a deployment for a Linux virtual machine).
  10. Enjoy using vRA, vRO and Rubrik 😉

How to consume the vRO 7.x API with Oauth2.0 Authentication

Most of us know that vRO has a REST API and that every request to this Orchestrator REST API must be authorized by an authenticated user.
Depending on whether you configure Orchestrator with LDAP,vCenter Single Sign-On or Oauth2.0, the authentication scheme for the Orchestrator REST API is different.

The most commonly way to consume the Orchestrator REST API, is based on LDAP Authentication. The downside of this approach is, that you must apply the Basic HTTP authentication scheme on the vRO virtual appliance or on the vRA virtual appliance when using the embedded vRO instance.

To apply the Basic HTTP authentication scheme, you need to add the following property to vmo.properties configuration file:

com.vmware.o11n.sso.basic-authentication.enabled = true

The vRO API documentation can be found on:

HOWEVER, if Orchestrator is configured with vIDM you can use an oauth bearer access token to access system objects in Orchestrator through the REST API. This also removes the requirement to apply the Basic HTTP authentication scheme. vIDM Authentication is THE recommended authentication mechanism when using vRO 7.x together with vRA 7.x !

This blogpost reveals how to consume the vRO 7.x REST API with Oauth2.0 Authentication!

  1. First you need to lookup the client id. You can do this by logging into the vRA virtual appliance with your favorite SSH client.  The <CLIENT_ID> can be found in /etc/vcac/solution-users.properties. For this request to work you will need the cafe_cli client. The following script should print it in the console. (grep -i cafe_cli= /etc/vcac/solution-users.properties | sed -e ‘s/cafe_cli=//’)
  2. Secondly write down the following prerequisites <vRA VA>, <TENANT>, <USERNAME> and <PASSWORD>. Please note that the <USERNAME> must be entered the same way it is entered on the login page. The <DOMAIN> is the fully qualified name of the domain of the user. You can find it by searching for the user in ‘Administration -> Users & Groups -> Directory Users and Groups’.
  3. Now you have gathered all the prerequisites, you can request the bearer token with the following REST API call.

  4. Finally we can use our bearer token to consume the vRO REST API ! See below for an example when using the external vRO virtual appliance.

  5. Have fun with the vRO REST API 😉

vRA 7.1 brings us a nice OOTB UI for REST API calls

vRA 7.1 comes with a very nice out of the box user interface which brings us unattended installation features and more. All of this is provided via “guided commands” in the form of REST API calls. This new cool feature is accessible via the config page of the vRA virtual appliance VAMI interface.

This blog article describes how to use this new cool functionality.

In my example I am going to prepare my first vRA IaaS server from scratch, create my vRA IaaS SQL database on a remote SQL server and do the vRA IaaS web server installation. This all happens on a guided approach and will be fully automated and unattended.

[Prerequisites]

  • Deploy and configure a vRA 7.1 virtual appliance.
  • Deploy and configure a fresh new Windows 2012 R2 server.
  • Apply the latest MS Hotfixes on this new Windows server.
  • Install the vRA Management Agent with the credentials of your vRA IaaS service account on this new Windows server.
  • Give your vRA IaaS Service account local administrator rights on this new Windows server.
  • Make sure there is a remote SQL server available where your vRA IaaS Service account has been granted the sysadmin role and where MSDTC has been configured properly.
  1. Open the config page from the vRA virtual appliance VAMI interface. eg. https://pb0vrava07.flexlab.local:5480/configblog-vra-vami-configThe red marked commands will be used in this example.
  2. First we need to know the NodeId of the management agent running on the new deployed Windows server. To gather that information we are going to execute the GET /node/list command.blog-get-node-listClick on the Try it out! button and provide the root credentials of the vRA virtual appliance.blog-authentication-requiredIf everything went OK, you see a Response Code of 200 and you can read the NodeId in the Response Body as shown below.blog-get-node-list-response
  3. Now we have the NodeId of the vRA IaaS server, we can prepare this Windows server for the installation of vRA IaaS components. To achieve this we are going to execute the PUT /execute/command/run-prereq/node/{nodeId} command.blog-prereq-checkerBefore we are going to execute this command we need to provide the nodeId in here as also the correct parameters. When providing the parameters, make sure that the property ValidationMode is set to True. On this way we can validate the command upfront! If the Response code returns a 200 you are fine. This is also the signal that you can change the property ValidationMode to False and really execute the command. The [nodeid] and [parameters] I used for this command are:

    Now it’s time to click on the Try it out! button and check the Response Body and Response Code. blog-prereq-checker-responseAs you can see the Response Code returns a 200. Now change ValidationMode to False in the parameters section and click again on the Try it out! button. When the Response Body returns a Status: COMPLETED, the prerequisite command has been finished.
  4. Reboot the vRA IaaS Server and proceed to the following command. We are now going to execute the PUT /execute/command/install-db/node/{nodeId} command. This time, the [nodeid] and [parameters] I used are:

    Again, if the Response Code returns a 200, change ValidationMode to False and click again on the Try it out! button. When the Response Body returns a Status: COMPLETED, the vRA IaaS Database Component Installation command has been finished.
  5. Lastly we are going to execute the PUT /execute/command/install-web/node/{nodeId} command. This time, the [nodeid] and [parameters] I used are:

    Again, if the Response Code returns a 200, change ValidationMode to False and click again on the Try it out! button. When the Response Body returns a Status: COMPLETED, the vRA IaaS Web Component Installation command has been finished.
  6. Enjoy Automating vRA