In a previous article, I covered how to architect a Virtual Machine role application in Windows Azure. In sum, you achieve high availability of your service through resiliency of an Azure application. Your design must tolerate the loss of a VM instance, rather than depend on the persistence of a particular VM role instance (or Azure Web or Worker role instance). Your Azure VM role instances will revert to the original base image you uploaded–and lose all changes made during the life of the VM–in the event of an instance reimage. A VM role instance reimage will typically (and hopefully rarely!) happen when there is a failure of the Azure host your VM role is running on.
Your Azure VM role instances will require configuration (customization) after an instance re-image. Azure Web and Worker roles natively and automatically configure themselves using “startup tasks” you define in your Azure application; however, startup tasks are not available in the VM role. If you don’t author your own automatic reconfiguration routine into your Azure VM role instances–to take the place of Azure Web or Worker role startup tasks–VM role instances will require one or more manual configuration steps after each instance restart.
Every Azure VM role has an out-of-the-box experience
Azure virtual machine base images must be prepared using the Microsoft Sysprep utility. Sysprep strips a Windows computer of much personalization. When the Azure role VM base image ‘wakes up’ for the first time after you upload it, or after an Azure instance reimage, the VM will go through the default post-Sysprep Out Of the Box Experience (OOBE) process. The VM role instance will receive a random computer name and a generic workgroup configuration. In this baseline setup the VM may not be ready to do work for anybody.
You will typically need to access your VM role instances by Remote Desktop Protocol (RDP) to complete one or more manual configuration steps that enable your VM to start delivering work. Since Azure host failure is quite rare, this could not be not too burdensome. Once you (potentially) rename your post-Sysprep VM, and do some final configuration of software you pre-installed in the image, it could be a long time before you need to repeat that manual work. However this approach does not scale well, since it requires human touch after each new VM role deployment and reimage.
Server role vs. compatibility with the Azure VM role
In order to co-exist with the programming model and limitations of the Windows Azure platform, your programs running on a VM role instance must be stateless, so that data is not lost when an instance of the role fails. Applications such as SharePoint, SQL Server, Small Business Server, Active Directory Domain Controller and Terminal Server are stateful applications that are not supported in the VM Role.
Microsoft suggests the VM role in scenarios like these:
- Long running application installations
- Error-prone application installations
- Application installations requiring manual interaction
Imagining an automatic configuration process for the Azure VM role
To make the Azure VM role attractive in large-scale and low-touch scenarios, an automatic configuration process is a necessity. As yet, there are no best practice guides or tools available from Microsoft specific to automatic configuration of the Azure VM role. Microsoft is actually interested in learning how architects leverage the VM role, since you need to be creative in one or more aspects of your application design to leverage this niche offering in the public cloud market.
Some of the techniques available for unattended setup of Windows server and client computer images in the enterprise environment also apply to Azure base VHD images prepared with Sysprep. You could, for example, author and stage a ‘phone home’ mini-app that runs as a Windows service in your image. Assuming you provisioned your Azure VM role instance with a network connection to the Internet, your mini-app could reach out to a pre-defined Internet URL where a web service allows the mini-app to pull down configuration information needed to complete setup of re-imaged VM instances.