Above The Cloud

Firstly this is pure speculation. Either that or it is known fact and I am behind the game (I’ve been out of action for a couple months, you may have noticed my absence in blogging). If I am the first person you have heard this from, then there is every chance that it is false, so once again, this is just speculation.

Recently there have been a spate of questionnaires going out to Azure consumers/clients. Being a good CTP user and evangelist of the platform, I filled out every single one that came my way. Some took hours, some took minutes. But while it would seem that Microsoft were collecting information from me, it also alluded/hinted at some features that might be released by Microsoft sometime in the future. This post is simply identifying those features that have already been discussed in those surveys.

Get on with it already

The feature name currently is ‘Managed VM Role’ and would essentially be an instance that you could remote to like any other server. This would fall into direct competition with GoGrid/EC2 type hosting where you provision server instances and get full terminal services access to the instance. In this case it would be custom Server 2008 instances that could still be managed by the Fabric Controller. Microsoft summarises the concept like so:

‘A mechanism to snapshot an entire application environment and create a Windows VM to be deployed and managed by Windows Azure together with the relevant data, registry settings, and the ability to choose and control OS versioning. In this case, the customer is responsible for installing security patches, OS updates, and upgrades by creating a new image snapshot updating the running VM roles using the Windows Azure upgrade facility’.

This would work in harmony with a ‘Managed Application Role’ which basically sounds like what they are already doing with Windows Azure, however it also hints at using a packaging facility like MSI for the deployment process. Also some elevated privileges might be possible in the final release (currently you can run in full trust but under a restricted user account).

Anything Else?

There’s a few other smaller bits and pieces hinted at, summarised below:

• Cloud Storage Explorer (although there are already good candidates)
• Better deployment story from Visual Studio (I’d like to see MSBuild tasks)
• Better deployment feedback (provisioning process for example)
• Design surface for your service oriented application (this would be way cool)

Remember as I said before, its all speculation at this point.

A few weeks ago I discussed the concept of what the Azure Fabric really is, and then followed with a discussion about how the Azure Fabric Controller works to manage the fabric. In this post I’d like to dive a little deeper into the lifetime of a server in the Azure Fabric and the process of deploying resources on demand.

Server Utilization

In many data-centres server utilization at any given point in time is quite low. The ultimate goal of a lot of cloud computing providers is to provide cost savings to customers by increasing server utilization, which reduces the number of servers required. Microsoft is no exception, and with Azure hopes to maximise server utilization through multitenancy with the appropriate security boundaries and without impacting on performance. Their goal is to improve the performance per watt per dollar ratio by running more services on less hardware.

In Azure the security isolation is managed via virtualization. A virtual machine dedicated to any application instance ensures it is isolated and also provides some benefits around health, monitoring and performance management. And of course, this provides the correct abstractions from the host operating system and hardware.

Obviously Hyper-V plays a major role in all of this. Azure uses versions of Server 2008 for its host machine and virtual machine environments. These versions are much like the versions you see today except that there are optimizations for running in the Azure Fabric. In a Hyper-V scenario, the host operating system sits above the hypervisor just like the guest virtual machines.

What this means for Azure is that the host and guest operating systems can be provisioned in the same way. Currently this happens by VHD (virtual hard disks). The VHDs are created and managed offline. When a new server is available and needs to be utilised, a host VHD is loaded onto the server, followed by guest VHDs as necessary. The host VHD will be Hyper-V enabled, and the machine will be booted with that host OS (a feature made available in Server 2008 R2 and also coming to Windows 7).

Servicing the images also happens offline. If a patch or service pack needs to be applied, it is difficult to apply it to thousands of virtual machines in a data centre all at once. It is also risky to the applications that are already running on those instances. Instead, the images are updated offline and when a new machine needs to be provisioned, the host or guest VHD’s it receives will already be patched and updated.

So how does this deployment happen?

Let’s emulate the life cycle of a server. This could be any server hardware; the key is that it is empty – no host operating system, just a network bootable bios enabled.

The first thing that happens is the server remote boots a maintenance OS – something similar to WinPE. There is an agent on this OS that knows how to find and talk to the Azure Fabric Controller. The FC then tells the agent to prepare a host partition. The agent then downloads a Hyper-V enabled version of Windows Server 2008 Core (since the host OS should be as lightweight as possible). This VHD is read-only and only contains the basics. Then a differencing disk is attached to the base VHD where all changes will be made. This provides the advantage of being able to rollback to a known state at any point in the server lifecycle. Images that are downloaded are really nothing more than XCOPY.

At this point the maintenance OS shuts down and the server reboots into the Server Core OS that has just been setup. There is also an agent on this OS that can talk to the Fabric Controller to get its next instructions. That next instruction might be to download a new virtual machine to run on this server. A Windows Server 2008 Enterprise VHD is downloaded (could be any version of server 2008) and as with the host OS this base VHD is read only, with a differencing disk downloaded and attached as the next step. Further to that an application specific VHD is downloaded – this contains specific applications required by your application, such as IIS, .Net Framework, etc. Finally your actual application is downloaded – this might be your web role, and this whole guest partition will serve that role.

Next the host OS agent receives a message to provision another virtual machine. It creates the guest partition and this time downloads a Server 2008 Core VHD instead (since the application that will be running doesn’t need all the features of Enterprise edition). As before, a differencing disk is applied to the partition and an application VHD is attached as well before the actual application is downloaded to the box.

The host OS agent receives another message from the Fabric Controller – another Server 2008 Enterprise application needs to be deployed. Since the first partition also was Server 2008, and the base VHD is read only, that VHD can be shared by the new partition we are creating. Not copied: shared. This saves on disk space for that particular server (since the Enterprise VHD is huge).

Given the nature of the read only base images for each guest (and the host) it is very easy to roll back an instance to a safe point in time without having to recreate the entire partition or reimage the whole server.

Because it is possible that more than 1 server might want to get a copy of a VHD at any time, the VHDs are sent using a multicast protocol, meaning that only 1 copy of the image is being sent at any given time, and multiple host agents can receive the image at any given time. Naturally this optimizes internal bandwidth.

This Sounds Great – Can I Do This In My Own Data Centre?

There’s been gossip about whether or not Azure will be something you can run in your own data centre and to date the official word has been ‘no’. However the innovations we see in Azure have started to filter their way down into Microsoft products and technologies, such as Windows Server, Hyper-V, and Virtual Machine Manager.

Pretty soon it will be possible to manage your own cloud infrastructure using the above Microsoft products.

Yesterday Amazon Web Services announced they are now offering Windows instances in the EU region. This means you can now spin up a Windows Server 2003 with either IIS or SQL Server (or Linux/Unix if that’s your cup of tea) closer to your consumers (if you are a European based company). On initial inspection, it appears that the European pricing structure is approximately 10% more expensive than the US pricing. If you are interested in finding out more, there is a webinar available for free on March 17th that will focus on cloud computing in Europe.

If you haven’t seen Elastic Cloud Compute (EC2) it is a virtualization provisioning service that allows you to provision a new virtual machine in the cloud from the click of a button (or a PowerShell command).

You can select from a set of existing pre-baked virtual machines, or you can upload your own. The selection screen looks like this:

When you select a machine, you then create a public and private key pair. This is used so that you can securely connect to your virtual machine. The key is saved to the user’s desktop. The next step is configuring firewall security. We do this by creating a security group that all our instances will belong in. Finally, we specify how many instances of our VM we want to spin up. It will usually take a few minutes for your instances to spin up.

Using the EC2 console you can do a lot of things including provisioning more images, arranging your IP addresses (and assigning static IPs), manage storage (which uses the Amazon Simple Storage Service [S3]), manage your individual instances (shutdown, reboot, etc), and more. The cheapest virtual machine comes in at USD$0.10 per hour, so you can happily spin up a few VM’s to play with, without breaking the bank!