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