Q: What is the virtual network change in Azure related to affinity groups that was announced at TechEd 2014?
A: Think of Microsoft Azure IaaS as a huge number of servers that offer various services. These servers are split into "stamps," with each "stamp" (also called scale units) consisting of approximately 1,000 servers that all have the same hardware configuration. When an affinity group is created, that affinity group is bound to a specific stack, with all virtual machines created in the affinity group provisioned in the same stack. Virtual networks were previously created within an affinity group, which meant all the virtual machines also had to be within the same affinity group and therefore have the same underlying server hardware configuration—which wasn't a problem because all the base hardware was basically the same anyway.
At TechEd 2014, Microsoft announced the availability of the A8 and A9 virtual machine sizes, which offer very large numbers of vCPUs and memory and use an entirely new class of server hardware contained in their own stamps. Because an affinity group is defined within a stamp and a virtual network exists within an affinity group, A8 and A9 virtual machines can't be part of a virtual network with non-A8/A9 virtual machines.
To solve this problem, virtual networks are no longer defined within an affinity group but are instead created within an Azure region. This means virtual machines can be on different stamps and can still be part of the same virtual network; therefore, A8 and A9 virtual machines can now be part of the same virtual network as non-A8/A9 virtual machines. New virtual networks are automatically created as region-based (wide virtual network) rather than affinity group-based (narrow virtual network) when using PowerShell, by specifying a location instead of an affinity group. This change should be reflected in the Azure portal by the end of June 2014. Over time, all existing virtual networks will be converted to region-wide virtual networks.
To create a regional virtual network today, perform the following steps:
- Create a new virtual network, with no resources created in the virtual network.
- Export the virtual network configuration for your subscription (change the file location if necessary):
Get-AzureVNetConfig -ExportToFile d:\temp\VNetConfig.xml
- Open the XML file in an XML editor or Notepad and change the affinity group for the virtual network to Location. Use the location your affinity group was provisioned in (e.g., East US). I changed from
to<VirtualNetworkSite name="SavTechNet115" AffinityGroup="SavTech115">
<VirtualNetworkSite name="SavTechNet115" Location="East US">
- Save the file.
- Apply the updated configuration:
Set-AzureVNetConfig -ConfigurationPath d:\temp\VNetConfig.xml