I have finally had a chance to update the
Windows Microsoft Azure PowerShell Guide.
The page is about the new functionality of assigning a static IP address to a virtual machine deployed in a Virtual Network.
I have finally had a chance to update the
Windows Microsoft Azure PowerShell Guide.
The page is about the new functionality of assigning a static IP address to a virtual machine deployed in a Virtual Network.
While working on some recent training content focused on development and test with Windows Azure Rick Rainey and I thought a great scenario would be to have a script that can copy a single Windows Azure Virtual Machine from a source subscription to a destination subscription. This script will also copy a virtual machine between data center locations. There are tons of scenarios where this can be useful for dev/test so I will not enumerate them all here
Using the Script
This script uses the Windows Azure PowerShell cmdlets so they must be installed prior to use. Also, both the source and destination subscription must be configured for PowerShell access prior to use. See the following for information on getting started with the Windows Azure PowerShell Cmdlets.
# Copy a virtual machine to a different subscription (no VNET) .\vmcopy.ps1 -SourceSubscription "source subscription" ` -DestinationSubscription "destination subscription" ` -VirtualMachineName "existingvmname" ` -SourceServiceName "sourcecloudservice" ` -DestinationServiceName "destinationcloudservice" ` -DestinationStorageAccount "destinationstorageaccount" ` -Location "West US" # Copy a virtual machine to a different subscription and specify an existing virtual network and subnet. .\vmcopy.ps1 -SourceSubscription "source subscription" ` -DestinationSubscription "destination subscription" ` -VirtualMachineName "existingvmname" ` -SourceServiceName "sourcecloudservice" ` -DestinationServiceName "destinationcloudservice" ` -DestinationStorageAccount "destinationstorageaccount" ` -VNETName "DestinationVNET" ` -SubnetName "DestinationSubnet"
The script can be downloaded from within the TechNet Script Center: Virtual Machine Copy Script.
If you find any issues with the script or would just like to make it better we have it posted in GitHub as well: GitHub – Virtual Machine Copy Script and are interested in pull requests for improvements.
Of course, if you would like deeper training on Windows Azure to learn how to write scripts like this yourself we would be happy to help
In this post I will show how you can use a Windows Azure Virtual Network (VNET) to create a site to site IPsec tunnel to connect to a Virtual Private Cloud (VPC) hosted in Amazon Web Services (AWS). Using this setup you can literally have workloads in each cloud with full VM to VM connectivity over a secure IPsec tunnel. This scenario could easily be used for failover, backup or even migration between providers. The software VPN solution I chose for testing is Open Swan.
Starting on the Amazon side create a virtual private cloud (VPC) which is the equivalent to a virtual network in Windows Azure.
VPC Creation Wizard – Single Public Subnet with Internet Gateway
I’m choosing the 10.0.0.0/16 address space for the Amazon VPC network.
Provision an EC2 instance that will be used to host Open Swan and be the Amazon side of the tunnel.
Launch Ubuntu 13.04 into the VPC Subnet
Specify the subnet of the VPC previously deployed and I would advise bumping up the instance size to Small from Micro.
Once the instance is created switch to the EC2 view and allocate a new Elastic IP. This will be the public IP address you will connect to the VM using SSH and the IP address your Windows Azure Virtual Network will connect to.
Click Yes Allocate on the new Elastic IP dialog.
Select the instance from the drop down and click Yes Associate.
Before configuring the Open Swan service I need to create the other side of the network in Windows Azure. To establish the IPsec tunnel Open Swan needs the gateway IP address and authentication key which both from the Windows Azure Virtual Network.
Create a Windows Azure Virtual Network
Specify Data Center Location and VNET/Affinity Group Name
Check site-to-site VPN
Define the onsite network properties which in this case is the Amazon VPC Address Space and Elastic IP of the Open Swan Server
Define the Windows Azure Address Space. Ensure you add the Gateway Subnet.
Creating the Windows Azure Virtual Network Gateway
Once the Virtual Network is created open it and click create gateway -> and select static routing.
Once the gateway is created you can get the gateway IP address and the authentication key and configure Open Swan on the Amazon side.
You will need the gateway IP and the key on the Amazon side.
Connect to the Open Swan VM
Switch to the instances view, select your instance and on the Actions menu click Connect.
Select Connect with a standalone SSH client.
Copy the SSH command (or use Putty using the instructions on the screen) to connect via SSH. I’m using the Windows SSH client that comes with GitBash for the record
Once connected install and configure Open Swan for the VPN solution on the Amazon side.
Installing Open Swan
sudo apt-get install openswan
Select NO for installing a certificate since we will be using key based authentication.
The next steps require you to use a text editor to modify some configuration files. If you are rusty on using Linux editors like vi here is a handy cheat sheet: VI Cheat Sheet
Edit the ipsec.conf file
cd /etc sudo vi ipsec.conf
Once open, enter edit mode by pressing: *i (in that order)
Replace the existing configuration with the following:
config setup protostack=netkey nat_traversal=yes virtual_private=%v4:10.0.0.0/16 oe=off include /etc/ipsec.d/*.conf
Exit and save the file by pressing:
Change to the ipsec.d directory and create a new file named amznazure.conf.
cd ipsec.d sudo vi amznazure.conf
Contents of amznazure.conf
conn amznazure authby=secret auto=start type=tunnel left=10.0.0.28 leftsubnet=10.0.0.0/16 leftnexthop=%defaultroute right=[WINDOWS AZURE GATEWAY IP] rightsubnet=172.16.0.0/16 ike=aes128-sha1-modp1024 esp=aes128-sha1 pfs=no
Notes about the above configuration:
Once you have specified the configuration you need to specify the authentication key.
cd /etc sudo vi ipec.secrets
Add a line to the file in the following format (do not add the  brackets):
10.0.0.28 [WINDOWS AZURE GATEWAY IP] : PSK "[WINDOWS AZURE GATEWAY KEY]"
Next, enable enable IP forwarding to the Open Swan VM:
sudo vi /etc/sysctl.conf
Then uncomment this line:
Apply the changed network setting.
sudo sysctl -p /etc/sysctl.conf
Next, disable source / destination checking on the Open Swan server.
Modify Security Groups to Allow Traffic from Windows Azure
In the Amazon management console select Security Groups and -> amzn-azure-group.
Add two custom UDP inbound rules – one for 500 and one for 4500 using the Windows Azure GW IP with /32 as the CIDR.
sudo service ipsec restart
Windows Azure Virtual Network Connected to Amazon AWS Virtual Private Cloud
The reason the software VPN solution needs to be on the Amazon AWS side is because the AWS networking stack supports configuring routing tables where Windows Azure does not (yet I assume).
In the Amazon management console switch back to the VPC view and select route tables.
Select the route table associated with your VPC and add a new route to the 172.16.0.0/16 (Windows Azure Network) and that routes traffic through the instance ID of the Open Swan Server.
Updating Route Information
Creating Instances to Test Connectivity
Create an instance in AWS on the VPC Subnet.
Launch an instance in Windows Azure on the Virtual Network created.
One both instances are up you will need to enable the ICMP rule on each VM to test out connectivity using PING.
Pinging an Azure VM from an Amazon VM over the IPsec Tunnel
Pinging an Amazon VM from an Azure VM over the IPsec Tunnel
I can now deploy applications into Amazon AWS and Windows Azure and communicate between the two on a secure IPsec tunnel over the Internet.
I will have a session “Windows Azure Virtual Machines and Virtual Networks” on Wednesday 9/12/2012 11:30AM – 12:45PM.
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:
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 10.1.0.0/16 which is a class B address space. I’m only carving one subnet (10.1.1.0/24) 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" />
<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="10.1.1.4"/>
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.
In my post on automating virtual machines I showed the basics for getting around and managing aspects of Windows Azure VMs. In this post I want to cover a few of the more complex scenarios such as connectivity between VMs, deploying into a virtual network and finally deploying a virtual machine automatically domain joined into an Active Directory Domain.
Connecting Virtual Machines
So far we have seen details on provisioning a single virtual machine. What happens if your application requires more than one VM? How to connect them? There are two options for connecting virtual machines. The first is to add multiple virtual machines to the same cloud service and the second is to provision each VM into the same virtual network. When machines are added to the same cloud service and are not within a virtual network they receive the benefits of being on the same network and receive built in name resolution with each other through Windows Azure provided DNS.
So how do you add two virtual machines to the same cloud service? When you create the first virtual machine using New-AzureVM or New-AzureQuickVM you are required to specify the -Location or -AffinityGroup parameter. When you specify either parameter it tells the cmdlets that you wish to create the cloud service at that time because the data center location can only be set on initial creation. To tell the cmdlets to create the VM in an existing cloud service you just omit the -Location/-AffinityGroup parameter.
Create a VM and a New Cloud Service (specify -Location/-AffinityGroup)
New-AzureVMConfig -ImageName $img -Name $vmn -InstanceSize Small | Add-AzureProvisioningConfig -Windows -Password $PWD | New-AzureVM -ServiceName $svc -Location $loc
Create a VM and Adds to an Existing Cloud Service by (omit -Location/-AffinityGroup)
New-AzureVMConfig -ImageName $img -Name $vmn -InstanceSize Small | Add-AzureProvisioningConfig -Windows -Password $PWD | New-AzureVM -ServiceName $svc
Connecting Virtual Machines with Windows Azure Virtual Networks
The second way of provisioning connected virtual machines is by using a Windows Azure Virtual Network. With a Windows Azure Virtual Network the network can span cloud services. This enables scenarios such as virtual machines (or web and worker roles) in different cloud services to be fully connected in the cloud.
How do you provision VMs into a VNET with PowerShell?
Just like the -Location parameter a VNET can only be specified when creating the first VM in a cloud service (note that the subnet for each VM can be set per VM on provisioning). Additionally, VNETs require that the cloud service be deployed into the same affinity group as the VNET was created in. The New-AzureVM cmdlet requires -AffinityGroup instead of -Location when deploying to a VNET.
Joining a Virtual Network at Provision Time
New-AzureVMConfig -ImageName $img -Name $vmn -InstanceSize Small | Add-AzureProvisioningConfig -Windows -Password $PWD | Set-AzureSubnet 'subnet' | New-AzureVM -ServiceName $svc -AffinityGroup 'myag' -VNetName 'VNET'
One of the significant differences between deploying a virtual machine outside of a VNET and one within is inside of a VNET there is no Windows Azure Provided DNS for VM to VM name resolution. To provide for this you are allowed to specify DNS servers inside of the Virtual Network configuration. When deploying with PowerShell you also have the ability to specify DNS settings when you create the first VM. This is a very flexible approach because it allows you the ability to specify DNS at deployment time without the need to modify the underlying virtual network configuration.
Specifying DNS Server on Provisioning
In this example I am creating a DNS object that references a DNS server (10.1.1.4) and I specify it with New-AzureVM. All VMs created in this cloud service will inherit this DNS setting on boot.
$dns = New-AzureDns -Name 'onprem-dns' -IPAddress '10.1.1.4' New-AzureVMConfig -ImageName $img -Name $vmn -InstanceSize Small | Add-AzureProvisioningConfig -Windows -Password $PWD | Set-AzureSubnet 'subnet' | New-AzureVM -ServiceName $svc -AffinityGroup 'myag' -VNetName 'VNET' -DnsSettings $dns
Deploying a Virtual Machine into an Active Directory Domain
With Windows Azure Virtual Machines it is entirely possible to have a full Active Directory environment in the cloud. AD can either be hosted on-premises with connectivity provided by a site-to-site VPN tunnel using Windows Azure Virtual Networks OR you can host an AD domain directly in the cloud.
Once AD connectivity is in place you can use the PowerShell cmdlets to automatically join a Windows Virtual Machine directly to an Active Directory domain at provision time. For AD domain join to work you must specify the DNS server IP address for your Active Directory domain.
In this example New-AzureDNS is used to specify the DNS for the VM to point to an AD DNS Server in the cloud (10.2.0.4) which itself has been configured to point to an on-premise AD server (192.168.1.6) in a previous deployment. Setting DNS at this level is also useful because any future VMs added to this cloud service will inherit the DNS setting.
$subnet = 'APPSubnet' $ou = 'OU=AzureVMs,DC=fabrikam,DC=com' $dom = 'fabrikam' $domjoin = 'fabrikam.com' $domuser = 'administrator' $domVM = New-AzureVMConfig -Name 'advm1' -InstanceSize Small -ImageName $image | Add-AzureProvisioningConfig -WindowsDomain -JoinDomain $domjoin -Domain $dom -DomainPassword $pass -Password $pass -DomainUserName $domuser -MachineObjectOU $ou | Set-AzureSubnet -SubnetNames $subnet $dns = New-AzureDns -Name 'clouddc-ad' -IPAddress '10.2.0.4' New-AzureVM -ServiceName 'app-cloudservice' -AffinityGroup 'ADAG' -VNetName 'HybridVNET' -DnsSettings $dns -VMs $domVM
If you would like to try some of this out on your own I highly suggest the Windows Azure Training Kit as a starting point. There are many hands on labs including deploying Active Directory and connecting multiple virtual machines.
I took a short breather after TechEd North America and TechEd Europe back-to-back but I did want to put up a post to summarize the sessions around Windows Azure Virtual Machines and Virtual Networks from TechEd 2012. This is a big and extremely important launch for Windows Azure so we have quite a bit of coverage on the subject
If you were looking for a crash course on Windows Azure IaaS here it is!
I have a few upcoming sessions planned for presenting on Windows Azure Virtual Machines.
The first is a FREE all-day Microsoft Cloud Day conference in London (UK) on Friday, June 22nd to learn about Windows Azure and Windows 8 where I will be talking about Windows Azure Virtual Machines and Virtual Networks.
I have quite a bit going on at TechEd Europe in Amsterdam as well.
Migrating Applications to Windows Azure Virtual Machines
This session is in D204 on Thu, Jun 28 12:00 PM – 1:15 PM.
The focus is on how you can pick up existing workloads and move them into the cloud using Windows Azure Virtual Machines (without re-writing your app!).
Windows Azure Virtual Machine Workshops
I will also be delivering two hands on workshops about deploying virtual machines that give you a two hour crash course on deploying a multi-vm application using VMs.
However, to get the inside scoop make sure you attend Mark Russinovich’s session on Windows Azure Virtual Machines and Virtual Networks in Theater on Tue, Jun 26 12:00 PM – 1:15 PM.
Of course, if you can’t make it you can see the recorded session from TechEd NA here: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/AZR209. If you haven’t familiarized with the new Windows Azure IaaS features yet this is the place to start.
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.
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
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
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 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.
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
For example if you wanted to configure an endpoint for a single web server your endpoint configuration might look like the following:
If you needed to open up the web server for SSL
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.
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.
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)
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).
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.
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.
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.
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.
Senior Technical Evangelist – Windows Azure