In this series about vCloud Automation Center 6 (vCAC), it’s time for another example of vCAC’s Advanced Service Designer (ASD).
In this specific article I will discuss an example in which vCAC offers NetApp as a service (NaaS). With NaaS, designated vSphere administrators (the vCAC users in this example) have the ability to request a new NetApp based NFS datastore which is automatically configured on selected ESXi hosts. By automating the creation of the NetApp volume, configuring NFS and adding the NFS datastore to vSphere, you will get a fast and highly efficient process with very limited user interaction.
For this service vCAC’s ASD is used which will execute a custom vCenter Orchestrator workflow. The vCO workflow will kick off the workflow in NetApp’s Workflow Automation (WFA) tool. NetApp WFA is NetApp’s own orchestrator. The WFA workflow contains the actual logic to create the NFS datastore and configures it on the vSphere layer.
Although things might sound a bit complicated at first, I am only using mostly standard building blocks to achieve this result.
NetApp-as-a-Service – Create an NFS datastore
Before we can create the workflow, we need to get insight into the automation steps. Creating and adding an NFS datastore to vSphere involves the following steps:
- Request a new NFS datastore for vSphere in the vCAC portal;
- Approve or deny the request;
- Start the vCO workflow after the request has been approved;
- After the request has been approved:
- Create a new NetApp volume;
- Add the volume to the exports configuration to allow selected hosts to connect to the new NFS datastore;
- Add the NFS volume to the ESXi hosts.
The new NFS datastore is now ready to use.
Approach – Required software components
My approach in this example is to use as many standard orchestration components as possible and to minimize coding. To achieve this I will use the following software components:
- vCloud Automation Center + vCenter Orchestrator;
- NetApp OnCommand Workflow Automation – NetApp’s own orchestrator;
- NetApp OnCommand Workflow Automation package for vCenter Orchestrator – The NetApp WFA vCO plugin allows you start WFA workflows right from vCenter vCO. Required WFA parameters are entered into the vCO workflow;
- NetApp OnCommand Unified Manager – This component is required for the interaction with your NetApp filer. OnCommand Unified Manager is used by WFA (WFA cannot communicatie directly with a NetApp filer);
- VMware PowerCLI on the NetApp WFA server – NetApp WFA uses PowerCLI to communicate with VMware vCenter Server;
The relationship between these components is the detailed in the following figure:
Download NetApp WFA vCO plugin here; also watch the video on this page called ‘How-to Video: Using the OnCommand Workflow Automation package for vCenter Orchestrator’. And here’s a document that explains how to install the vCO WFA plugin. I will not discuss the installation process for the other components; comprehensive documentation is available on the NetApp website.
Note that some of the components officially only support vSphere 5.1; however, in my setup I used vSphere 5.5 without any problem.
Let’s dive a little deeper and see how the different components are configured. I will start off with the NetApp WFA.
Configuring the workflow in NetApp WFA
The NetApp WFA includes a workflow called “Create VMware NFS Datastores”. By default this workflow creates four different NFS datastores. I’ve slightly changed this: my custom workflow only creates one NFS datastore:
The first step in this workflow creates a new volume on NetApp, the second step configures the exports file, and the third step configures the ESXi hosts in vSphere. Yes; in this case the WFA is responsible for both the configuration of the NetApp filer and the vSphere layer. For the configuration of vSphere, WFA is leveraging VMware PowerCLI. This component has to be installed on the WFA server:
Of course you could argue for letting vCO configure the NFS datastores on the vSphere level; this is a slightly different approach and would require some additional editing of the WFA and vCO workflow.
After the WFA workflow is ready, you can try to run it on the WFA server: a new NFS volume is then created and added to vSphere.
Connecting vCO to WFA
- VirtualCenterIP – IP address of the vCenter Server;
- ESXClusterName – Name of the ESXi cluster;
- DataStoreName – Name of the NetApp volume;
- DataStoreSize – Size of the volume/datastore in GB;
- ESXRWHosts – Hostnames and/or IP addresses of the ESXi host that should be added to the exports file on the NetApp.
These are the parameters for the original WFA workflow, which are now configured in vCO as detailed in the next figure:
Of course you’re free at this point to test the vCO workflow and see if everything works as expected in vCO.
Connecting vCAC to the vCO workflow
The last step is to create the actual NetApp as a Service offered in the vCAC portal. Of course we will use the Advanced Service Designer for this and follow the procedure described in one of my earlier articles: Deploying a VM with vCAC’s Advanced Service Designer (part I/II). Specifically read step 2 and 3; here you will learn how to link a vCO workflow to vCAC and publish the workflow as a service in the vCAC portal.
You can set a default value for some of the parameters of the vCO workflow and make these values visible/invisible for the vCAC users. E.g. you can configure the workflow in such a way that the vCAC user can only determine the datastore size. As an example, the next picture shows a pre-defined configuration for the vCenter IP address:
The next step is to publish the new service in the vCAC catalog. If everything went according to plan, we will end up with a NetApp NFS Datastore object in our catalog. This new service will allow our vSphere administrator to request a new NFS datastore if needed. Of course you can add an appropriate approval policy if needed, allowing a storage administrator to approve a request before the NFS datastore is automatically deployed and added to vSphere.
Happy automating! Read more about vCloud Automation Center here.
2 Comments
JE
This is really a terrific post. Thank you for this. think where I get confused however is right at the end inside VCAC itself regarding service blueprints, custom resources, resource actions. In this case, were custom resource created so that VCAC keeps track somehow in items\inventory of what was done? Are those custom resources only available due to the WFA vCO plugin providing them? Also, are there any return values\notifications within the VCAC service area to let the customer know that it was completed?
viktorious
Hi! Thanks for your comment. Unfortunately I was not able to create a custom resource, because a NetApp NFS datastore is not recognized as an object in vCO. The NetApp plugin doesn’t create any objects. Because I’m not able to create a custom resource, there will be no object in the vCAC portal after the datastore is created.
The default vCO/WFA workflows don’t return any value. I was thinking to customize the workflow, return some kind of ID related to the datastore and create a custom resource based on this. Have to find some time for this, suggestions are always more than welcome!
Also notice: vCAC will monitor the status of your vCO workflow; if the vCO workflow fails, vCAC will report this. A succesful completion of the vCO workflow will be reported in the vCAC interface as well.