In the first episode of this series of posts we explored the cloud on-boarding experience with VMware partner Stratogen. I strongly suggest you read the first episode first for proper context moving forward. In essence we subscribed to the Stratogen public cloud offering (currently in beta) and I am now going to show, in this post, basic operations that an end-user would do to start “consuming the cloud”.
The organization administrator experience
The very first thing is that, as you may know, when you subscribe to a vCloud service, usually the SP creates an organization administrator user id that has full rights for the cloud sandbox. In my case Stratogen created an organization administrator id called Massimo. That’s good but I also want to entitle a couple of other people in my team to consume the cloud. They are Alessandro and Elisa. I have already added Alessandro and I am now adding Elisa. See picture:
In my case I have given Alessandro the vApp Author role whereas I am giving Elisa the vApp User role. The only difference is that Alessandro will be able to create new vApps from scratch whereas Elisa will only be able to instantiate existing vApps templates from catalogs. The vApp User and vApp Author are regular roles available out-of-the-box with vCD but more sophisticated roles can be created by the cloud administrator for the organizations to use. Stratogen hasn’t yet created any custom role as far as I can see.
Another interesting thing to note is that these three users are created and maintained at Stratogen. There is an option in vCloud Director that allows the cloud administrator, when creating a new organization (IT20 in my case), to point back to an AD/LDAP service that is maintained by the on-boarding customer in its premise. This would allow the customer to pick any existing user in his own Active Directory and assign them a role in the cloud sandbox (Vs having to create a user and then assign him/her a role). If you want to know more about this you can read this previous post titled vCloud Director and Active Directory Backed Authentication. Stratogen may decide to offer this flexibility in their future service offerings.
Another thing I’d like to do as an organization administrator is to create a private catalog to the IT20 organization. In a real life environment you may want to do this because you want to give internal users (Elisa and Alessandro for me) a set of private templates that are specific to my own organization requirements. This may be because the software stacks I’d like to deploy are not available in the public catalog(s) the SP is publishing. In my case the driver for having a private catalog was a bit different. I have noted that Stratogen provides a number of vApp templates but all of them have VMs that have a 50GB VMDK file associated (see pictures in the first episode). This may be OK for production environments but in order to play with this sandbox I’d like to have something smaller and more agile that would allow me to instantiate a vApp (and their VMs) very quickly. So I decided to create a local catalog to my org (called it20cat) where I created a vApp with a small TurnkeyLinux VM. Note that this VM is just about 2GB in space so it will deploy in a fraction of the time that the Stratogen vApp would.
How did I do that? There are a couple of ways to put that vApp into the catalog.
- You can import it from an existing OVF file (that’s what the most left-handside button above the TurnekeyLinux label does).
- You can create a vApp with a VM from scratch, install your TurnekyLinux and when done you can “add it to the catalog”
Remember to share this catalog with everyone in the organization (or with selected users if you wish so) otherwise others won’t be able to see it. If you are interested in exploring more about the catalog capabilities you can check out this post titled vCloud Director: Catalog Experiments.
There is one last thing I want to do that requires the role of an organization administrator. I want to enable the DHCP service on both the Internal Network as well as the External Network (NAT-Routed). By default, when the cloud administrator creates organization networks, the DHCP service for the private layer 2 segment – provided by the Edge device – is not enabled. Here is how you can enable, for example, the DHCP service on the Internal Network. We first need to check out the range for the Static IP pool that has been associated to the network segment. This was setup by Stratogen and it looks like this:
The range of IPs from 192.168.1.100 all the way to 192.168.1.199 is allocated to the vCD Static IP Pool (note I could change that if I want). We are going to enable a DHCP scope that falls outside of that range so I am going to enable it with these values:
These are values that vCloud Director suggests but they could be changed (provided they don’t overlap with the Static IP Pool). However you shouldn’t worry too much: if you, by mistake, mess things up vCloud Director will tell you so. This is what happens if the organization administrator creates an overlap between the Static IP Pool and the DHCP scope:
This is the magic of cloud. Self-service capabilities with error checking built-in (yeah I wish it was so across the board).
There are a few other things you may need to do as an organization administrator to tune your cloud sandbox. One of these is to tune what I call the time-to-live of the vApps. As an organization administrator you can choose whether the vApps deployed in your sandbox can live forever (until manually removed) or if they have to have a temporal deadline. This really depends on the use cases: for a lab-like use case you may want to set a default expiration date whereas for a production use case you may want to set it to Never Expires. This is usually set when the cloud admin creates the organization but the organization administrator can override these values. Users in the organization (Alessandro and Elisa in my case) will be able to set an expiration date on a per vApp basis with the only gotcha that they cannot set it to be longer than the maximum set by the organization administrator. In other words if the organization administrator set the Maximum runtime lease to 7 days, users cannot set their vApps to Never expires. They can however choose a 7 days or shorter runtime lease.
The organization user experience
Now that we are done with the preparation of the organization for actual usage, we can either continue to do stuff as an org admin (the role can do everything including creating and deploying vApps if we want) or we can hand over the job to other users. To give you an idea of what a real life usage scenario may look like I’ll just logoff as an org admin (Massimo) and I’ll login as a vApp Author (Alessandro). Once you log in as Alessandro this is what you get:
As you can see the user experience and the richness of the interface is reduced dramatically. In fact vCloud Director has three context of operations that are:
- Cloud administrator: you can do everything cloud-wise (richest interface). I don’t have access at this level. Stratogen is running the show here.
- Organization administrator: you can do (almost) everything organization-wise (somewhat rich interface)
- Organization user: you can only do limited things such as creating and deploying vApps and plug them into the environment the cloud admin and the org admin created for you (most limited interface)
There are a few types of org users that are available out of the box (vApp User, vApp Author, etc) and more custom roles can be created each of which will have slightly different rights. For example Alessandro is an “author” and you can depict that from the fact that he can add vApps from the catalogs(s) (that’s what Add Cloud Computing System button means) as well as compose a vApp from scratch (the Build New vApp button). I am not going to show this in a picture but Elisa would only have the first button available since vApp Users do not have the right to create vApps from scratch. You have to trust me or check it out for yourself.
So say Alessandro would want to instantiate an existing vApp from a template in the catalog, this is what he would see:
The local catalog is shown and Alessandro can deploy the TurnKeyLinux vApp Massimo has created. Note that the out-of-the-box organization user roles do not have the right to access public catalog. So you either have to have your SP create a custom role that has that right or you have to use more powerful roles (e.g. Organization Administrator).
As you progress with the wizard to deploy this vApp you’ll note that the VM is configured with a single vNIC. Here the system asks you where you want to connect that vNIC and a drop down with all available Org Networks is presented.
Note the Add Network choice: that would create a so called vApp Network that is a layer 2 network dedicated to the context of this vApp. Potentially more on this in future posts. Another thing to note is that you have an option to select the vDC where you want to deploy this vApp. For me this wasn’t much of a choice since I only have a single vDC available (see the first episode to have more background on how this cloud sandbox is configured).
For the purpose of this deployment I will choose to connect the VM to the Internal Network available in this organization and get an IP from the DHCP service we have enabled a few steps above:
If you think this is cool and true self-service, I say… wait for the next posts in this series to see what we can do.
A few minutes later Alessandro has his vApp ready to go instantiated into its own cloud space:
We have deployed a vApp from an existing vApp template. Let’s see what happens if Alessandro chooses to compose a new vApp. So we push the Build New vApp button and:
This interface is a little bit different than the previous. In the previous interface I could choose a vApp from the catalog to deploy and that was pretty much it. The authoring wizard on the other hand presents you with a list of all VMs available in all vApps available in the catalog you are pointing to. In my case only one VM (the TurnKeyLinux) shows up. You can then start composing your new vApp by selecting existing VMs and adding them to it. But that’s not all. You can also hit the New Virtual Machine button and this will open up a new interface where you can specify the characteristics of your new VM.
In my case I am adding a new Windows 2008 R2 VM with 1 vCPU, 2GB of memory, a 16GB Disk and 1 vNIC. These are all user configurable parameters and you can choose whatever mix you have. It is obvious that, being this a brand new VM, it doesn’t have any Guest OS installed. Check out the vCloud Director: Catalog Experiments post for some additional hints on how to install a Guest OS in a naked-VM.
And a couple of minutes later…
This is a slightly different view of Alessandro’s cloud space that shows the previously created vApp (instantiated from the catalog) as well as the newly created vApp which is comprised of the same TurneKeyLinux VM available in the vApp in the catalog as well as the Windows VM I have created from scratch.
This concludes this second episode. The purpose of this episode was to give you an idea of how the vCloud can be prepared by an organization administrator and then consumed by end-users defined in the same organization. In future posts I may dig more into advanced networking configurations as well as any other end-user experiences you may want to suggest me to explore in more details. Please let me know either by e-mail (see the About page) or via my twitter account.
No comments:
Post a Comment