Connecting Web or Worker Roles to a Simple Virtual Network in Windows Azure

In this post I’m going to show you how simple it is to connect cloud services to a virtual network.

Before I do that let me explain a couple of reason of why you would want to do this.

There are a few use cases for this.

Web or Worker Roles that need to:

  1. Communicate with a Virtual Machine(s)
  2. Communicate with other web or worker roles in a separate cloud service (same subscription and region though)
  3. Communicate to an on-premises network over a site to site VPN tunnel (not covered in this post)

In at least the first two cases you could accomplish the connectivity by opening up public endpoints on the cloud services and connecting using the public IP address. However, this method introduces latency because you are making multiple hops over each cloud service load balancer. Not to mention that there is a good chance that the endpoint you are trying to connect to would be more secure if it wasn’t exposed as a public endpoint. Connecting through a VNET is much faster and much more secure.

For this example I’m going to walk through a simple VNET that will accomplish the goal of connecting cloud services.

Step 1: Create an affinity group for your virtual network in the region where your cloud services will be hosted.

Step 2: Create a simple virtual network and specify the previously created affinity group along with a single subnet network configuration.

For the subnet details I am specifying which is a class B address space. I’m only carving one subnet ( out of the address space to keep things simple. Unless you need connectivity back to on-premises or are planning to lock down traffic between subnets when Windows Azure supports ACLs this will likely be a sufficient solution for simple connectivity.

Step 3: Deploy a Cloud Service to the VNET.

Unlike deploying a Virtual Machine you cannot specify virtual network settings on provisioning through the portal. The networking configuration goes inside of the .cscfg file of your Windows Azure deployment package.

To connect to this virtual network all you would need to do is paste the following below the last Role tag in your service configuration file (.cscfg) and deploy.

    <VirtualNetworkSite name="SimpleVNET" />
      <InstanceAddress roleName="MyWebRole">
          <Subnet name="AppSubnet" />

A few things to note about this configuration. If you have multiple roles in your deployment package you will need to add additional InstanceAddress elements to compensate. Another thing to point out is the purpose behind multiple subnets for each role. The idea is if you have an elastic service that has instances added/removed you could conceivably run out of addresses in the subnet you specify. If you specify multiple subnets to the role Windows Azure will automatically pull an address out of the next available subnet when the instance is provisioned if you run out of addresses from the first subnet.

Name resolution is another area to address. When deployed inside of a virtual network there is no default name resolution between instances. So if you are deploying a web role that will connect to a SQL Server running on a virtual machine you will need to specify the IP address of the SQL server in your web.config. For that specific scenario it would make sense to deploy the SQL VM first so you can actually get the internal IP address for your web app. It is of course possible to deploy your own DNS server in this environment. If you do you can specify the DNS server for your web/worker role instances with an additional XML configuration.

This would go right below the NetworkConfiguration element start tag:

        <DnsServer name="mydns" IPAddress=""/>

Finally, to make a truly connected solution you would want to deploy additional services such as VM or other cloud service/web worker roles to the VNET. The beauty of this configuration is every application deployed into this VNET will be on the same virtual network and have direct low latency and secure connectivity.

P.S. Virtual Network and Subnet Names are case sensitive in the configuration file.

Windows Azure Virtual Machines

Windows Azure Virtual Machines are a new addition to the services provided by Windows Azure. They allow a much easier and flexible solution for quickly moving an existing workload from on-premises to the cloud or for building new applications that have dependencies on applications that will only run on a server with persistent local storage. Creating VMs in Windows Azure is easy and flexible because Windows Azure provides three different ways of provisioning one.

Creating a VM from an image

The first is to create the virtual machine directly in the cloud using a number of images provided by Microsoft or partners. This is by far the easiest route to take to quickly spin up a new virtual machine.

Virtual Machine Image Gallery

Creating from a Custom Image

The second option is building your own custom images and provisioning virtual machines from the resulting image. This involves creating a new VM using a platform image, customize it with your own software and settings, and then generalize it using sysprep within Windows or waagent -deprovision+user on Linux. Once the VM is generalized and shut down you can then use the capture functionality to save the VM as a custom image.

Note: You can also generalize a VHD offline and upload it using the csupload.exe tool available in the 1.7 SDK.

Bring your own VHD

The third option is uploading existing virtual machines in VHD format. This method also uses the csupload.exe utility. You can upload a generalized image or a non-generalized VHD. The generalized image can be used to provision new VMs in the cloud as a template and the non-generalized VHD can be used as an OS disk to boot from or just a data disk to mount as a data drive.

The process you choose for each of these creation methods is up to you. Windows Azure provides capabilities from a point and click web interface to full automation with PowerShell in addition to a REST based Service Management API.

IaaS is all About the App and not the Runtime

With Windows Azure Virtual Machines the focus is all on the application. Providing the underlying infrastructure to run applications for the most part as-is in the cloud is a key goal behind introducing Virtual Machines. New scenarios such as running applications like SharePoint Server, SQL Server, Active Directory and even various distributions of Linux are now available to Windows Azure users.

VM Architecture

If you have a solid understanding of the current Windows Azure service model you have a good base of knowledge for understanding how Windows Azure Virtual Machines are built. Windows Azure Virtual Machines are built on the same service model that web and worker roles are. However, the service model has just been enhanced to support functionality needed for virtual machines such as persistent storage and single instance per role.

The Cloud Service acts as a container for virtual machines. Within a cloud service there are two slots for deployments for traditional web and worker roles Staging and Production. With virtual machines the Production slot is the only one in use (VIP swapping is not supported with VMs). The deployment is another container for VMs (within the cloud service) that has its own set of properties specifically pertaining to virtual networking which I will talk about later. Within the deployment a virtual machine is its own role with a single instance.

Cloud Services and VM Architecture

Virtual Machine Disks and Storage

One key difference with virtual machines from other Windows Azure roles is the underlying storage. There was actually a long discussion internally on whether to refer to virtual machines as Durable VMs or Persistent VMs before landing on just Virtual Machines. This internal discussion is still visible in the service management API where virtual machines are still referred to as PersistentVMRole.

The disks in a virtual machine are actually stored as page blobs in Windows Azure Storage. When you create a Virtual Machine from an image, a writable copy of the image is created in the storage account you specify on VM creation. This is where the underlying operating system VHD is created. Windows Azure storage offers numerous benefits such as extremely scale and durability. Your virtual machine storage is replicated three times within the same data center and optionally another three times in a different datacenter in the same region for extreme durability. Windows Azure storage also has the benefit of being easily accessible with a well-known API so there is already plenty of tooling available to manage it.

Virtual Machine Architecture

Looking at the diagram above you will notice that I did not add the D: drive into the list. The reason is very important. The D: drive is available to your application but you should very careful about using it for storage. It is actually the physical storage on the rack server the VM is running on. It is NOT backed by Windows Azure storage and should be considered temporary storage only. One great use for it is the OS paging file which contains data that does not need to be persistent (this is the default behavior in Windows Azure).

When dealing with virtual machine storage you should understand capacity and caching. The operating system disk can be at most 127GB. However, each virtual machine can also have additional data disks attached to it up to 1 TB per with the number of data disks dependent on the VM size. Data disks can also be dynamically added or removed while the VM is running. So adding additional storage to the VM is as simple as a few clicks in the portal or a short PowerShell command.

Virtual Machine Size and number of data disks supported

Disk Caching

There is a layer of disk caching support between the virtual machine and the underlying host. The default configuration of your OS disk will have ReadWrite host caching enabled and for data disks no caching is enabled. Take note not to put data on the OS disk without first changing the cache settings using the PowerShell Set-AzureOSDisk cmdlet. The OS Disk can also be configured for ReadOnly caching where the data disk supports None, ReadOnly and ReadWrite.

Windows Azure Virtual Machine Disks

Virtual Machine Networking

Virtual machines within the same cloud service have direct connectivity with each other. You do not have to configure internal endpoints through the service model because virtual machine’s default to allow all traffic on all ports between virtual machines. That does not mean that traffic will flow though. This is Infrastructure as a Service after all so you will still have to manage the firewalls on your VMs to allow traffic between servers.

Name resolution is handled through a multi-tenant DNS service provided by Windows Azure. Note: If you choose to configure a virtual network this DNS service is not provided and you are expected to configure your own DNS if name resolution is a requirement.

Endpoint Configuration

Configuring inbound traffic to your virtual machines is straight forward. Windows Azure has the concept of an Input Endpoint or more commonly known as just an endpoint. An endpoint is associated with a virtual machine and its properties allow traffic to flow.

Endpoint Property Names

  • Name (friendly name of your endpoint)
  • Protocol (tcp/udp)
  • Local Port
  • Public Port

For example if you wanted to configure an endpoint for a single web server your endpoint configuration might look like the following:

  • Name: iishttp
  • Protocol: tcp
  • Local Port: 80
  • Public Port: 80

If you needed to open up the web server for SSL

  • Name: iishttps
  • Protocol: tcp
  • Local Port: 443
  • Public Port: 443

Configuring the Load Balancer
The previous examples are great for opening up a port for a single virtual machine. However, sometimes you need multiple VMs responding on the same port in a load balancer. Windows Azure allows you to directly configure and control which virtual machines are configured for load balancing. It does this through load balanced sets.

Load Balanced Endpoints

A load balanced set is simply configuring the same endpoint on multiple VMs and setting another property called the “LoadBalancedEndpointSetName (or LBSetName in PowerShell) with a common name to group the endpoints together. This functionality is abstracted away within the Windows Azure management portal but it is good to go into in detail because from the command line you can have much more control over the load balancer by using custom health probes.

Load Balanced Endpoints

Configuring a Custom Health Probe for the Load Balancer

For an example on configuring a custom health probe see my post on Automating VMs with PowerShell.

Authenticated Sites and Custom Probes

It is important to understand that the URL configured for the custom probe receives a GET request from the load balancer without passing host headers or any authentication of any kind. So if the probe path you specify returns a 401 ACCESS DENIED then the load balancer is not going to add the VM to rotation. It is important to configure a health check URL here that can respond anonymously.

Port Forwarding

The architecture of cloud services makes endpoint configuration interesting. Since each cloud service has a single public IP address but multiple virtual machines can reside in it how do you address individual servers directly in a non-load balanced fashion?
The answer is port forwarding.

Port Forwarding to Multiple VMs

Port forwarding allows you to configure an endpoint on a specific VM listening on any of the ephemeral ports that will then be forwarded to the correct internal port. The illustration above shows two VMs both listening on ports 3389. To address them individually from the same public IP address two endpoints are made with the first listening on port 5586 and the second on 5587. When a remote desktop client connects to either endpoint they are forwarded to the correct machine.

Virtual Machines and Virtual Networks

Another new set of functionality with this release is Windows Azure Virtual Networks. Virtual Networks are more than just connecting your on-premises data center to the cloud (which does make it tremendously easier for building hybrid networks) but they also provide you the ability to configure the network within your Windows Azure deployment.

Persistent IP Addresses for Virtual Machines

This scenario is the easiest to understand so I will start here first. By default when you provision a virtual machine in Windows Azure you get name resolution by default and IP address management. The defaults are usually good enough until you need to do something that would require a persistent IP (notice I did not say static IP address). In the default networking configuration your VM’s IP address can and will change. So if you need to deploy something like Active Directory the default network stack will not work. This is where virtual networks save the day.

VNETs allow you to define the entire IP addressing scheme for your cloud network. You define the address space, the subnets and ultimately which VM goes into which VNET and subnet. The current biggest benefit to all of this is that each VM provisioned inside a VNET will retain the same IP address no matter how many times it is rebooted or recovered. Think of it as an infinite DHCP lease (do not set the IP address statically!). The downside is you do lose that built in name resolution when using a VNET and you do need to have a basic understanding of subnetting. If /16 and /24 are significant to you then you are likely already there.

Example Virtual Network Configuration (No Gateway)

Connect Your Data Center to a Windows Azure

Using a VPN device that supports site to site VPN you can create hybrid networks that span networks that you define from on-premises to the cloud. This means applications that do not move easily to the cloud can be directly accessed from applications in the cloud without expensive re-writes or wiring up of proxy interfaces to access the data remotely. Accessing the corporate Exchange Server, Active Directory, Solaris machines, whatever is on your corporate network can be made available to applications in the cloud. All that is needed is to configure a gateway in the virtual network configuration, share keys between the Windows Azure gateway and your VPN device and configure.

Connect Cloud Services on the Same Virtual Network

Connecting multiple cloud services on the same virtual network will open up all kinds of technical opportunities. The most obvious is the ability to take an application designed for Windows Azure web or worker roles and have them directly communicate with another application on a virtual machine such as SQL Server or Active Directory or any other application that runs in a VM. Many existing applications could easily be converted to web or worker role except for dependencies that require persistent storage. This should remove many roadblocks for migrating applications to PaaS.
Note that web and worker roles cannot currently be deployed into the same cloud service as a Virtual Machine so for direct connectivity a Virtual Network is required.

Connecting Web or Worker Roles with VMs on a Virtual Network with Hybrid Connectivity

Another interesting scenario is segmenting cloud services for large VM deployments. Since each VM is itself a Role in the Window Azure service model that brings with it the same limitations. There can only be 25 roles per cloud service so that means there can only be 25 virtual machines per cloud service. For truly large applications creating multiple cloud services and connecting them via a virtual network is a simple solution.

Name Resolution in a Virtual Network

As I mentioned earlier name resolution is not provided out of the box when you deploy a VM into a virtual network. The expectation is you will or can provide your own. There are a few ways to configure DNS for VMs in a VNET.

Configure DNS on the Network Adapter

This has the obvious draw back that you have to manually configure the DNS server IP address(s) for each machine.

Specify DNS servers in the network configuration

You can specify DNS servers when you configure the network configuration. The draw back here is there currently is no way of modifying the DNS configuration without redeploying the VMs in the VNET so at the moment this is not a flexible option.

Specify DNS during the first VM deployment

This is by far the most flexible. If for some reason the DNS server needs to be updated it’s a simpler matter of removing thfce VMs and redeploying them using the disks and specifying the new DNS configuration. All of this is easily scriptable from the Windows Azure PowerShell cmdlets (currently this is the only way of setting DNS during deployment).

Deploying a Virtual Machine into a Virtual Network

The final VNET diagram shows a typical configuration when deploying virtual machines into a virtual network. There are a few considerations before deployment.

Configure the Virtual Network First!

The reason is simple: You cannot move a provisioned VM into a VNET. The VM has to be provisioned into the VNET.

Determine DNS up front.

Will you provide it yourself by hosting DNS in your cloud service or point to a public DNS server? Will you set it at the network configuration level or at the deployment level? These are all good questions to answer before deployment. Because once a VM is deployed into a VNET you cannot change the existing settings of the VNET without first removing any VMs or web/worker roles in the VNET.

Each VNET requires an affinity group.

The cloud service that hosts your VNET must reside within the same affinity group.

The storage account has to either be in the same region as the affinity group or the same affinity group.

It cannot reside in a different affinity group within the same region or another region.

Virtual Machine Availability

With the launch of Virtual Machines comes a new SLA. With web and worker roles we offer a %99.95 uptime SLA as long as you have at least two instances of your application running to compensate for host updates and hardware failures. With VMs we realize that many applications do not need (and many do not even work with) multiple VMs. So to address this need we will offer the single instance SLA of %99.9. We will of course also offer the %99.95 (this is still under consideration but did not make GA). SLA assuming you have >1 instance using a new feature called an Availability Set.

Availability Sets

If you are familiar with the concept of upgrade and fault domains then you are mostly there with availability sets. The concept is similar except the functionality of upgrade/fault domains are combined with availability sets with VMs. The main thing to understand is that your VMs in a set will be physically on separate racks in the data center and when we upgrade the host OS beneath your VMs we will never upgrade all of the VMs in the set at the same time so only part of your application is taken down for maintenance.

Availability Sets Visualized

Availability Sets and SLA

Availability Sets give you data center hardware redundancy at each tier of your application.

Wrapping Up

In summary I would say that with the launch of Windows Azure Virtual Machines and Virtual Networks we have opened the gates up to start migrating workloads to the cloud. You are no longer required to re-write/architect your applications to have it run in the cloud. With Virtual Networks you are no longer restricted by an “all or nothing” migration approach or forced to write lots of service wrappers to surface on-premises data over the Internet.

Windows Azure still has all of the great functionality with PaaS style applications but now with the ability to run these applications side by side with traditional apps an entirely new set of opportunities have been opened up.

Michael Washam
Senior Technical Evangelist – Windows Azure