Home > Blogs > VMware vCenter Orchestrator Blog > Monthly Archives: April 2011

Monthly Archives: April 2011

Automate (the Cloud) or Die

If you ask 10 different people for their definition of Cloud computing, you’ll likely get 10 different answers, not to mention the occasional wise remark about an open-air or floating datacenter.  While all response details will vary, each answer is guaranteed to include two fundamental concepts: “self-service” and some “behind-the-scene magic to fulfill my request (right now, please… as I’m in a hurry)”.

From a cloud consumer perspective, the instant gratification is what makes the cloud magic so attractive.  For a CIO or CFO, it’s the short-term promise of greatly reduced capital AND operational expenditures. 

For the public and private cloud providers (the IT Infrastructure and Operations groups), that magic is more often associated with a downright terrifying set of expectations and realities:

  • Drastically reduced service delivery times
  • Larger, unpredictable volumes of provisioning and decommissioning operations
  • Greater complexity in not just provisioning but maintaining complex, dynamic, multi-layered services

The only constant in cloud environments, and only in the best of cases, is the size of the provider’s IT staff.  If you believe that the current IT management models will work, think again (and read To Unlock the Power of the Cloud, Rethink IT Management).  Regardless of the tools or number of staff available in an IT organization, there’s only one kind of magic that can scale to meet the demand and economics of cloud computing: Automation.

The alternative is simple: death.  OK, so we’re only talking a virtual death here, but yes, you can definitely expect your internal or external customers to procure IT services elsewhere if you don’t automate.  Virtual computing resource price lists are only a click away and it’s getting easier to move around workloads.

Obviously, automation is not a new concept.  It’s much, much older than virtualization and even precedes the software era (yeah, seriously 🙂 ).  Since the introduction of software, the most common form of automation has been and continues to be scripting.  Even today, it continues to serve a very valuable role for many discrete operations (more to come about this subject in an upcoming blog).  But when it comes to automating much of the magic in the cloud, there is no better solution today than a well orchestrated, cloud-purposed, IT management suite.

And this is where vCenter Orchestrator comes in.  Our mission is quite simple: to enable the VMware cloud stack to integrate with our customer’s environments AND processes, thereby dramatically reducing their costs and accelerating service execution.  In short, To Automate the Cloud.

Practically, what does this mean?  Well, thanks to increased R&D investments along with contributions from VMware partners, be on the lookout throughout the year for many more out-of-the-box workflows similar to the VMware vCloud Director and Cisco UCS Manager plug-ins.

We are also quite aware that automation will not become pervasive until it can be deployed in minutes rather than hours or days (remember, it’s all about instant gratification).  So yes, we are working on that too.

In the meantime, thanks for continuing to use vCenter Orchestrator and, to end with another but less dramatic cliché, the best is yet to come 😉

 

Sample scenario for the Cisco UCS Manager plug-in

We announced some days ago the general availability of the vCenter Orchestrator plug-in for Cisco UCS Manager. As we said, this plug-in provides a complete set of workflows, actions and scripting objects that cover pretty much all the most common tasks from the Cisco UCS Manager administration point of view. And it is capable to manage multiple Cisco UCS Managers at the same time.

Now, to start getting familiar with the plug-in and its possibilities, let’s define a typical scenario inside the Cisco UCS Manager context and let’s see how we can cover it with the Cisco UCS Manager plug-in. In order to do that we will compose our own workflow with some of the workflows that the new plug-in provides.

Consider the sample scenario “Create and configure a Service Profile and attach it to a Blade”. What do we want to do exactly?

  1. Create a simple Service Profile
  2. Edit the Service Profile
    1. Add a vNIC
    2. Add a vHBA
    3. Assign a Boot Policy
  3. Assign the Service Profile to a Blade
  4. Wait for the association to be completed (the Blade will be booted)
  5. Do something else after that depending on the result (e.g. send a notification to somebody)

So, let’s build our own workflow step by step. We will call the workflow “Install New Service Profile”.

1) Create a simple Service Profile
The plug-in provides a workflow called “Create Basic Service Profile” that does exactly what we need. It creates a simple Service Profile by setting the parent Organization, a name and an optional description.

CiscoPost1-1
2) Edit the Service Profile
Here the plug-in provides a complete set of actions and workflows for creating and configuring practically all the Service Profile attributes, including vHBAs, vNICs, vSANs, profiles (IPMI, Placement…), policies (Boot, Fibre Channel Adaptor, Local Disk Configuration, Serial over LAN…), etc.
In our example we just want to create a vHBA for the Service Profile, to create a vNIC for the Service Profile and to attach a predefined Boot Policy to the Service Profile. To do that, we can use the following workflows provided by the plug-in:

  • “Create vHBA”
  • “Create vNIC”
  • “Attach Boot Policy to Service Profile”

CiscoPost1-2
Here just to comment that the workflows “Create vHBA” and “Create vNIC” have a big set of input parameters, but in our example (as we will see later) we will consider that the user of our “Install New Service Profile” workflow has to worry only about the vHBA and vNIC names because all the other parameters will be preconfigured for him/her (they will be defined as workflow attributes instead of workflow input parameters).

3) Assign the Service Profile to a Blade
Here again the plug-in provides a workflow that does exactly what we need. The workflow is called “Assign Service Profile to Blade” and it triggers the association between the specified Service Profile and Blade.

CiscoPost1-3
4) Wait for the association of the Service Profile with the Blade to be completed

Here the plug-in provides a workflow that is more flexible than what we need, because we can use it not just for monitoring the association of the Service Profile but also the disassociation, the assignment / unassignment, etc. This workflow is called “Wait For Event On Service Profile” and basically it blocks the main workflow execution until the plug-in receives an event from the Cisco UCS Manager notifying that the specified operation has finished.

CiscoPost1-4
In our example it’s clear that the association is the operation that we want to monitor, so we won’t ask the user to provide the type of operation but only to provide a timeout in case the association takes too much time. Operations like that can take a few minutes on a real Cisco environment, and this time is something that the user of the workflow has to keep in mind.

5) Do something else after the association has finished depending on the result
Here we can continue invoking UCS Manager plug-in operations or we can also invoke any other operation from vCO, including any operation from any of the plug-ins that we have installed.

CiscoPost1-5
In our example we just check the result of the association between the Service Profile and the Blade and then we run simple different tasks (success tasks or error tasks) depending on it.
But some more complex examples of these success and error tasks could be:

  • Send a confirmation e-mail to the System Administrator
  • Register the result of the process on an external log file
  • Start installing an Operating System on the new running Blade
  • Process the next Blade (if any)

Finally, this would be the full picture of the workflow:

CiscoPost1
And this could be our presentation of the workflow:

CiscoPost6
As we expect from the previous steps, the information that the user has to provide to the workflow is just:

  • Organization where the Service Profile will be created
  • Name of the Service Profile
  • Description of the Service Profile (optional)
  • Name of the vHBA to create and assign to the Service Profile
  • Name of the vNIC to create and assign to the Service Profile
  • Boot Policy to assign to the Service Profile
  • Blade which the Service Profile will be assigned to
  • Timeout to control the association operation between the Service Profile and the Blade

So, it’s time to run the workflow!

CiscoPost2
…and the workflow finishes.

The first thing we can see is if the workflow has finished successfully from the vCO Client.

CiscoPost3
Also, we can check the UCS Manager plug-in inventory and see that we have the new Service Profile created and that it contains the new vHBA and the new vNIC.

CiscoPost5
Finally, we can check the Cisco UCS Manager console and see that our workflow has finished successfully because all the elements that we created and configured are there.

CiscoPost4
And this is just the beginning!