Start to finish: Building a cloudy service in two weeks

Feature Wading through Microsoft's private cloud offerings has been a bit of a slog for me. My background is mostly VMWare and my experience of providing web services is largely Lamp-based.

A major element in Microsoft's play is the concept of services, and an outsider looking to learn the details of how these work may face a wall of unfamiliar jargon. Let's deconstruct the terms.

In the context of a private cloud, a service consists of a group of interdependent virtual machines, their configurations and connectivity requirements managed from within System Center Virtual Machine Manager (SCVMM) 2012.

Services mark Microsoft's move beyond infrastructure-as-a-service towards platform-as-a-service and software-as-a-service.

The creation of a service starts with the creation of virtual machine templates. Depending on the virtualisation software you use, a virtual machine template can be the rough equivalent of a heavily customised operating system install CD, a system image, or anywhere in between.

Think of the children

A virtual machine template contains the hardware profile of the child virtual machines: what size hard drive they have, how many network cards, how much RAM and so on. The templates usually have an operating system installed and may contain one or more pre-configured applications.

You will notice a lot of wiggle room in that description. Virtual machine templates can come in many shapes and sizes. To qualify for inclusion in a service, the options available become more limited.

At the moment, services must be Windows Server-based. SCVMM has a lot of built-in knowledge about how Windows Server works, even to the point of being able to drive role selection and configuration.

In a service template world we like the concept of things that are stateless. (This will be familiar to many virtual desktop infrastructure admins.) Stateless virtual machine templates are a lot closer to the customised install CD than to the system image.

This ties back into the "must be Windows Server" rationale: private cloud services take a collection of stateless virtual machines, push a configuration into them and present them as a single instance to the user. The interaction between operating system and management application is key.

In the beginning

Let's take an example. The virtual service I created to learn how all this works consists of three virtual machines: a web server, an app server and a database server.

As in the Windows-centric world, the web server is IIS-based. It stores its information on the SQL server.

The application server runs a piece of third-party Win32 software that also talks to the same database on the same SQL server. All three pieces are needed for this application to work.

The web server is a good starting point. As this is the only one of our three examples to be completely stateless, we need to lay the groundwork first.

Statelessness in the Microsoft private cloud begins with operating system profiles. SCVMM knows all about Windows Server. Normally, I would install Windows into the virtual machine, configure a whole bunch of settings and then run sysprep.

In this instance, it is not required. I can tell SCVMM that this is a Windows Server 2008 R2 virtual machine and that I want various roles and features deployed. It does what needs to be done from an .iso installer.

In the case of the web virtual machine, I tell SCVMM that I want the IIS role (and various dependencies) deployed and the .NET framework feature installed. I provide the naming scheme for the virtual machine and credentials to join it to the domain.

So far, so boring. We have successfully replicated the .SIF file, in virtual machine form. This is not much of a cause for excitement, and we still don't have a working web app in this virtual machine.

To be a proper web profile virtual machine, the web application we install should be coded as a web deploy package.

Voila: you have one virtual machine template created from scratch

Think of a web deploy package as being like an rpm file. It's essentially a Zip ball with some metadata in it that dictates where the files should go. It can be configured with any number of variables that can have defaults or be overwritten by user-supplied information at time of install. All of this through SCVMM or the user portal.

SCVMM speaks web deploy. If the web app you want to install is properly packaged, you can simply upload the Zip via SCVMM, provide the necessary variables, and you're done.

Among those variables will probably be the connection info for the database. You might include other things such as administrative user information and so forth. You can have the users supply some or all of the info when they spin up the service or code all the variables in yourself.

Dynamic configuration information is tracked by SCVMM. If you configure your virtual machine template so that the computer name is Webserver-##, then SCVMM will make the first instance Webserver-01, the second one Webserver-02 and so on.

It tracks the allocation, and reclaims available iterations when a virtual machine instance is destroyed. There is also room for pre-deploy and post-deploy scripts to be added to the mix, just in case you have any other tinkering you need to do.

Voila: you have one completely stateless virtual machine template created from scratch.

Care instructions

Before we get into the configuration of the other two virtual machines in our service, I want to talk about the care and feeding of your shiny new stateless web server.

We like this stateless idea because it allows us to dynamically add or remove any number of virtual machines for any number of reasons. (Persistent data is made to live elsewhere.)

We also like it because template virtual machines in services are linked to their descendants. Change the parent virtual machine – a setting, script, what-have-you – and all descendant virtual machines will be updated.

You read that right: SCVMM cascades updates to child instances when modifying the parent template.

Obviously, if your templates are designed to be stateful, this is a bad plan. If I am storing all my data inside the virtual machine and then I modify the parent virtual machine, I will probably clobber all that important data during the next update.

We are off into application virtualisation territory here. Persistent data either has to be dynamic or stored in a central location.

So now we have a pretty good idea of how we might go about setting up a stateless virtual machine for inclusion in a service, and why we should care.

But life isn't quite so simple. Plenty of applications are just not going to cooperate with such a purist approach.

The SQL database is one example. What possible use could a stateless (or semi-stateless) SQL server virtual machine be? It depends on the application. (You can segregate the storage but we will address that later.)

You might decide that stateless SQL servers are no good to you. If you are spinning up a series of web virtual machines to cope with changing load conditions, you might choose to tie them back to a centralised SQL cluster.

This can easily be done when defining the virtual machine template definitions.

Yet there are instances where a mostly stateless SQL server can come in handy. Depending on your load profile, you might want to spin up a read-only SQL instance slaved to a central master along with your web front-end.

In this case, so long as the web front end goes away whenever the SQL server is destroyed, who cares? By coupling them as a service, you ensure this is what happens.

Alternatively, you might have need of applications with a defined lifetime. Consider a distributed model.

Your short-lived service eats a series of CSV dumps from various other applications. It parses the data using a database as temporary storage and completes its task by injecting the results of the number-crunching into a central database.

In this instance, the web server and the SQL server it relies on need to exist only long enough to accomplish their task, after which they can be destroyed. All of them can be automated using SCVMM.

Spread the word

Let's look at the other two virtual machine types. Both the other virtual machines tie back to this SQL server, so let's start there.

The operating system is Server 2008 R2, for which SCVMM has a built-in operating system profile, but we are not going to configure anything here beyond system name and Active Directory join info.

As we need to install SQL Server 2008 R2, we have to actually installing the operating system and then SQL.

We are already off into the weeds here: this isn't a stateless virtual machine. The standard rules still apply though. Tinker with the template's virtual hard disk (say by running a service pack against SQL), and you can cascade that update down to all children.

Not being a purely stateless virtual machine isn't a big downer. With a little creativity you can segregate the SQL data storage from the operating system image.

In the case of my service, some minor scripting allowed me put the SQL data files on a completely separate drive, a mounted iSCSI LUN.

I used a post-install script for this, with the LUN chosen tied to the generated system name. This allows me to update the operating system without harming the data.

After that has been accomplished and all the updates are run, sysprepping the operating system and the SQL server application must be done. Tell SCVMM that this template is an SQL server (by assigning it to the SQL server profile) and the second virtual machine is complete.

There is a third class of native virtual machine type that SCVMM understands: App-V.

My particular case doesn't call for one but they are not hard to grasp. If you understand how the web deploy stuff works, then the take away from App-V is more or less the same.

Instead of being web-based, they are more traditional Windows-style applications usually delivered through RDP.

The upshot is that the apps generally have to be purpose-built for the occasion. The 20-year-old financials package you have been babying along is not likely to play nice.

Those legacy applications, however, are far more interesting and still represent the bulk of what is out there. I certainly haven't seen a lot of App-V certified anything in the marketing propaganda of the past year, and web deploy was a fuzzy something-or-other I didn't particularly care about until I set forth to write this article.

Add your flavourings

Microsoft is aware of this. Its solution to the problem is the inclusion of Generic Command-line Executables (GREs). These are exactly what they say on the tin: they provide the ability to add various flavours of script to your template in addition to the typical pre- and post-install scripts.

In my case, I was able to take some ancient pre-MSI installer chiselled out of a stone tablet by a mysterious species of extinct gnome and do enough things to it so that it actually behaved like a stateless application.

To start with, I used GREs to put this application's storage in a central place using iSCSI and SMB. They also came in handy when tweaking operating system parameters such as screen resolution (which would turn out to be critical later on.)

The more complicated use of GREs was to tie my virtual machine template to a central SMB storage location and call a series of scripts located there. For reasons too tedious go into, the scripts in question had to be dynamically generated.

They used the computer name, a centralised authentication system controlled by the application vendor and various other things that actually had to be fed into a web server so the next script in the series could be generated.

There is even a mouse macro to click the various buttons required for full automation. But it works. I have a stateless version of this application that can be created and destroyed at will by an end-user, an SCVMM trigger or a Powershell script.

The resultant service has a kludgy old app and a spiffy stateless webserver tied back to a semi-stateless SQL server. When users require an instance of the service, they can go to the self-service portal, push a button and 15 minutes later their service is ready.

This will result in massive time savings for me. The application stack in question is used as a testing and development version of a set of production servers.

A dozen of these might be created and destroyed over the course of a month, each instance taking about two hours to create, four hours to run Windows updates and half an hour to dispose of afterwards.

To get this far, I had to teach myself Hyper-V, System Center Operations Manager, SCVMM, Windows clustering, web deploy, App-V and the maddening details of that legacy app's installer. The result was a proper cloudy service that runs on a highly available cluster.

From start to finish, the project took about two weeks of my spare time. Everything about it is scalable. Two hosts or 2,000, one instance to thousands: all the same concepts and technologies apply. ®

This is the third article in a three-part series by Trevor Pott, a sysadmin based in Edmonton, Canada.

1. Microsoft private cloud: introduction
2. Microsoft private cloud: infrastructure drilldown
3. Start to finish: Building a cloudy service in two weeks