Windows Azure Virtual Machines, the Infrastructure-As-A-Service (IAAS) offering, is a big leap for Windows Azure platform. Virtual Machines, as the name suggests, offers multi-tenant virtualized infrastructure, wherein end user can deploy applications. This specifically simplifies the migration of legacy applications to Cloud, offering more optimization avenues to the enterprise IT.
When Virtual Machine preview was released in June 2012, I thought it would be a no-brainer - just spawn a new VM with few mouse clicks on Azure portal - and from there on, it’s more like interacting with a remote server within your enterprise. But as I started working with it, aligning it to enterprise deployments, the experience turned out to be quite different and very educating. This article is an outcome of my dabbling, wherein I would be listing down five key points I wish I knew and understood well at the starting of my IAAS journey on Windows Azure platform.
This article is published from the November Edition of the DNC Magazine – A Free High Quality Digital Magazine for .NET professionals published once every two months.
The November edition featured hot topics likeProcesses using TFS 2012, Knockout JS in ASP.NET MVC, Azure IAAS, the Roslyn project in action, Creating Visual Studio 12 extensions, Notifications and Live Tiles using WinJS and more! Last but not least, our special guest in the Interview chair, Jon Galloway!.
Click Here to Download all the issues of this Free .NET Magazine
Working with a Windows Azure Virtual Machines
Tip #1 Use PowerShell
Being a developer writing code most of the time, I wasn’t an advocate of PowerShell. But when I looked at Windows Azure PowerShell cmdlets (pronounced command-lets), I was completely sold. Using these cmdlets you can customize almost every aspect of VM creation which otherwise you would manually via Azure portal. In fact, few advance configurations are only possible via these cmdlets. For instance, basic configurations can be easily set with cmdlets like specify the VM name, instance size, base image name (refer to this article on how to add your own image to Windows Azure Image Gallery), login password, Cloud Service (the container for VM) name, affinity group, Virtual network and even the subnet in Virtual network. But if you are looking to support advance scenarios like creating a VM that should be domain joined with an Active Directory installed on Azure, you can specify additional cmdlet parameters like fully qualified domain name, domain user name, domain password and necessary DNS settings. While you got to spend some time initially understanding various parameters cmdlets accepts, once you are through with this initial phase, PowerShell enhances your productivity to the next level. Below is a simple PowerShell Script to create a VM. You can download cmdlets from the Azure portal
#Download publish settings using
#set subscription / storage for VM deployment
Set-AzureSubscription -SubscriptionName 'subscriptionName' -CurrentStorageAccount 'accountName'
#Set VM configuration parameters
$ServiceName = 'DNCService'
$imgName = 'MSFT__Win2K8R2SP1-Datacenter-201208.01-en.us-30GB.vhd'
$vmConfig = New-AzureVMConfig -Name 'DNCService1' -InstanceSize Small -ImageName $imgName | Add-AzureProvisioningConfig -Windows -Password 'Password123'
#Create new VM
New-AzureVM –ServiceName $serviceName -VMs $vmConfig -AffinityGroup 'NRAffGroup'
Tip #2 Control VM lifetimes
Most of the Cloud computing resources are billable on an hourly basis and it’s important that you release these resources when you no longer need them. This typically applies to Windows Azure Virtual machines not running 24x7, example - there could be business workloads which requires an application to run only twelve hours on week days. To avoid billing, most users stop their VMs to realize that Windows Azure bills you for VMs that are in a stopped state. So, your only option to control costs is to delete the VMs. But wouldn’t delete VM cause any issues?
The answer is both No and Yes. When you delete a VM, you are just deleting the VM instance but the underlying OS and data disks are still intact (in fact, you still keeping paying for their storage which luckily is quite negligible). Hence you can easily resurrect your VM without much harm. The issue you might face though when you delete and re-create the VM, is the public IP address change. I work in an organization with strict IT security rules and locked down access. Static IP was necessary for me to raise an outbound RDP access request with my IT team. But with IP changing everyday, it was definitely turning into a challenge. At the end, the solution I adopted was to create an extra small VM running 24x7 and bounce from there to other VMs.
It’s important to note that when you delete the VM, you still retain the underlying Cloud Service container and its associated Site URL (see ‘#3 Recover from VM failures’ for more information on this topic). This snapshot from the Azure Portal shows an empty Cloud Service Container post deletion of the VM.
To delete a VM You can use PowerShell cmdlets. PowerShell cmdlets allow you to export your VM configuration, delete the VM and then re-create VM using exported configuration. A sample script is listed below:
#Export VM configuration to a file on local disk
Export-AzureVM -ServiceName '<cloud service>' -Name '<vm name>' -Path 'c:\vmconf.xml'
# Delete Azure VM
Remove-AzureVM -ServiceName '<cloud service>' -Name '<vm name>'
#Import / Recreate Azure VM using the exported configuration file
Import-AzureVM -Path 'c:\vmconf.xml' | New-AzureVM -ServiceName '<cloud service>' -VNetName ‘<vnet name>’ -DnsSettings ‘<DNS entry>’
Export configuration generated above is stored in a XML file. It contains various properties of a VM including Endpoints, disks, VM size, subnet, etc.
Tip #3 Recover from VM failures
Your ability to handle failures is quintessential while working with any cloud platform and same applies to Windows Azure Virtual Machines. Being in preview mode (This article was written in November when IAAS was in preview mode), I expected some glitches with this offering. There were times when I would setup a VM and next day wasn’t able to RDP (Remote Desktop) into it. I looked like my hard work of setting up the VM would go down the drain. But those initial struggles filled my knowledge gaps. While the stability of VMs has dramatically improved with the General Availability, below are few pointers to deal with RDP failures.
a. Restart VM: First is to restart your VM. That should do the trick whenever your VM becomes unresponsive.
b. Delete VM: In case that doesn’t work or restart itself is failing you can try deleting the VM and re-creating VM as detailed in ‘Controlling VM lifetimes’. If you are following those steps and attempting a manual delete via Azure Portal, you should delete the underlying Cloud Service too. As explained later in ‘Load Balancing VMs’, Cloud Service – is the container holding your VM and would become visible when you delete the VM. Deleting your Cloud Service would allow you to reuse your DNS name (as best practices ensure that your VM and DNS names are prefixed with unique identifiers). I have seen quite a few developers struggle and provide different names to their VMs every time they delete it, failing to realize that they need to delete the Cloud Service too. The following figure shows how you can create a new VM by selecting an existing disk
c. Resize VM: An alternative to deleting your VM is to change the size of your VM. This is a less intrusive but might not be feasible all the times.
d. Unlock VHD / Disk: At times, after you delete your VM, the portal might show that Disk is still attached to the deleted VM. This would result into a difficult situation because you can’t reuse the Disk until is detached. The easier option to resolve this is to delete the disk object. Deleting the Disk object would still retain the underlying blob. After deletion you can re-create the disk object and use it to spawn a new VM. If you can’t delete the disk then your only option is to break the blob lease manually via PowerShell or using Storage Client Library (refer to this MSDN forum link for further information).
Tip #4 Load Balance VMs
Load balancing is essential to leverage Cloud’s elasticity. If you want to maximize your Cloud migration ROI, you should be able to scale your application linearly to the corresponding demand. While establishing load balancing was trivial with Platform-As-A-Service (PAAS) offerings like web role, IAAS requires you to understand how individual Virtual machines are connected. When you create a Windows Azure VM, it’s placed inside a container called ‘Cloud Service’ – the fundamental unit of deployment on Windows Azure Platform. The name of this Cloud Service is the DNS name you specified while creating your VM in the Azure Portal.
Interestingly, the Cloud Service container is hidden and you see this container only when you delete the VM or when you deploy more than one VM in the same Cloud Service. It’s important to note that portal currently doesn’t support adding multiple VMs inside a Cloud Service, and the same has to be carried via PowerShell cmdlets. VMs placed inside the same cloud service are connected by default. This is a primary requirement to Load Balance VMs and it really doesn’t matter whether your VMs are part of a Virtual network (Virtual networks are used to connect Cloud Services in the same affinity group) or not. Bottom line - you can’t load balance VMs that don’t belong to a single Cloud Service. The PowerShell cmdlets to create a VM with a new Cloud Service and to create a VM to join existing Cloud Service are quite similar. For the latter, you just don’t provide an affinity group / location and your VM will be created in specified Cloud Service. Sample script is listed below:
#Create VM with a New Cloud Service
New-AzureVM –ServiceName $cloudService -VMs $vmConfig -VNetName $virtualNetwork
#Create VM into an existing Cloud Service
New-AzureVM –ServiceName $cloudService -VMs $vmConfig -VNetName $virtualNetwork
CloudService variable should be common for creation of both VMs. After multiple VMs are placed inside the same Cloud Service, you need to setup load balancing endpoint. For web based applications, this would typically be on port 80. For each VM, you need to select the load balanced endpoint as shown below:
Tip #5 Restrict VM’s public access
Every Virtual machine in Windows Azure is contained inside a Cloud Service. For accessibility to inside VMs, every Cloud Service has public IP address and an internal IP address. At times though, you might require different levels of access. Consider a 3-tier deployment scenario, where you want only your front end web servers to be accessible publically and rest of your deployment including database servers to be reachable only via those front end servers (internal access).
To achieve this, you got to control your VM endpoints. VM endpoints are publically accessible endpoints of a VM. To restrict public access to a VM it’s as simple as deleting those endpoints. Note you can still reach out to these VMs using internal IP address provided they are in the same Cloud Service or connected via Virtual Network. You can RDP into the VMs using internal IP address and allow access to specific ports as required. The below snapshot shows you a VM with no public endpoints and hence Azure portal doesn’t display its public IP address.
To summarize, this article listed few aspects of Windows Azure Virtual Machines that you need to keep in mind. As shown in the article, you can use PowerShell for most of your tasks and if your VMs deployed are deployed in the same Cloud Service container it’s easy to load balance them. You can also restrict public access to VMs by controlling VM endpoints. Finally, it’s important that you manage the lifetimes of your VM to maximize your Azure Cloud ROI and in case your VM becomes unresponsive, you can try the various routes including restarting it. Hope that will make your adoption of Azure Virtual machines lot easier. Please mail me your feedback.
This article is written by Niraj Bhatt for the Free DNC .NET Magazine. Niraj works as a Senior Architect for a Fortune 500 company and has an innate passion for building / studying software systems. He is a top rated speaker at various technical forums including Tech Ed, MCT Summit, Developer Summit, and Virtual Tech Days, among others. He enjoys working on – IT innovations that impact enterprise’s bottom line, architecture and integration of systems, performance tuning, and review of enterprise applications. He has received Microsoft MVP award for ASP.NET, Connected Systems and Windows Azure. He maintains a blog at http://nirajrules.wordpress.com and can be reached at firstname.lastname@example.org.