Windows Azure Infrastructure Services IP Address management (Part 2 of 2)

This two-part series details the IP address management of Windows Azure Infrastructure Services including:

• Part 1. Windows Azure Infrastructure Services IP assignments facts
• Part 2. How to assign a static Vnet IP to a VM and a sample session (This article)

We can use Windows Azure PowerShell to assign a static IP to a VM deployed to a Windows Azure virtual network (VNET). The following explains.

Assigning Static VNET IP Address to a VM

To assign a static IP to a VM, use PowerShell. And the VM must be deployed to a VNET. Windows Azure PowerShell v0.7.3.1 released on March 11, 2014 supports static VNET IP address. To install Windows Azure PowerShell and connect to your Windows Azure subscription, follow the instruction at http://aka.ms/AzureCmdlets.

 

In PowerShell ISE Command Add-On pane, simply search the string, azurestat, you will find out there are four Windows Azure PowerShell cmdlets associated with managing a static IP of a VM deployed to a Windows Azure virtual network, as shown on the left.

A typical routine starts with using Test-AzureStaticVnetIP to confirm the availability of a target IP address. The cmdlet returns a list of suggestions if the target IP address is not available.

Once the availability of a target IP address is confirmed, run Set-AzureStaticVNetIP and Get-AzureStaticVnetIP to assign and verify the IP assignment of a target VM. And as needed, use Remove-AzureStaticVnetIP to remove a static IP from a VM object.

With a static internal IP addresses, VMs in a VNET will maintain the same IP addresses across shutdown, reboot, and re-imaging. And the deployment order of VMs to a VNET does not impact the IP assignments anymore. Supposed two VMs were at the state, Stopped Deallocated, and then later get started again in a random order. The new internal IP addresses will likely be different. However if the two VMs were assigned with static IP addresses, the same IP address will be in the VM upon restart.

Sample Session of Assigning a Static IP

The following user experience is based on Windows Azure PowerShell already configured with connectivity to a Windows Azure subscription by following the instructions provided at http://aka.ms/AzureCmdlets.

Three VMs, vm1, vm2, and vm3 were deployed in order to myTestNet which is configured with 10.0.0.0 address space. Upon the initial deployment, 10.0.0.4, 10.0.0.5, and 10.0.0.6 are assigned to the three VMs as shown. VM2 is the target VM for a static IP assignment.

 

For this particular deployment, it is obvious which IP addresses are available. In an event that Windows Azure Management Portal is not accessible, we can use Test-AzureStaticVnetIP to confirm the availability of a target IP address within a VNET.

 

 

Once a target IP address is confirmed available, we can use Set-AzureStaticVnetIP to assign a static IP to a target VM. Here, on the left I use a small routine to first test the availability of a target IP, 10.0.0.9, in an intended VNET. If the IP is available, assign it to a target VM, here vm2. A sample script is available at http://aka.ms/StaticVnetIPSample.

 

Now vm2 has an IP address as 10.0.0.9. If this is a static IP address, redeploying all three VMs will not change the IP address of vm2 at this time.

 

 

To redeploy the three VMs, I first shut down them from Windows Azure Management Portal and brought all to the state, Stopped (Deallocated), which released the internal IP address of each VM. As shown on the left, neither VM had an IP address.

 

The three VMs were at this time started in the order of vm3, vm1, and vm2. This order is different from that of the initial deployment. And upon the deployment, notice that vm3 which was first started got the IP address, 10.0.0.4. The 2nd started VM was vm1 which got 10.0.0.5. Nevertheless, the last one started, vm2 (instead of getting the next IP address, 10.0.0.6) maintained the assigned static IP, 10.0.0.9. In other words, once a static IP address is assigned to a VM instance, the deployment order no longer impact the IP address assignment of the VM.

Best Practices for Static IP Assignments

The recommended usage pattern is to employ separate subnets for static IP address VMs and dynamic IP address VMs. Use a static IP address subnet for all static IP address VMs, while it is needed to specify a different static IP address for each VM deployed to this subnet. And use a dynamic IP address subnet for PaaS web/worker roles and those Infrastructure Services VMs without the needs for static IP addresses.

Managing VMs with static IP assignments in a separate subnet can help standardize the processes and configurations, hence better automation and streamlined operations.

Additional Resources

• Windows Azure Infrastructure Services deployment methodology
  • http://aka.ms/AzureIaaSMethod
• Windows Azure Infrastructure Service Quick Start Kit (QSK)
  • http://aka.ms/QSK
• Windows Azure free 30-day trial subscription with $200 credit
  • http://aka.ms/30

Windows Azure Infrastructure Services IP Address management (Part 1 of 2)

This two-part series details the IP address management of Windows Azure Infrastructure Services including:

• Part 1. Windows Azure Infrastructure Services IP assignments facts (This article)
• Part 2. How to assign a static IP to a Windows Azure VM and a sample session

We will first examine some basic concepts to better understand how IP addresses are assigned in Windows Azure and what are the implications.

VIP vs. DIP

Upon deployment, a Windows Azure VM instance has two IP addresses:

• A VIP (Virtual IP address) is the public IP address pointing to the cloud service where the VM is deployed to. Notice that a VIP once assigned is not released from a cloud service till every VM instance in the cloud services has either a “Stopped (Deallocated)” status or deleted.
• a DIP (an internal IP assigned by Windows Azure with DHCP) is the IP address assigned to the VM for communicating within Windows Azure. Notice that a DIP once assigned is not released from a VM till  the VM has a “Stopped (Deallocated)” status.

The following illustrates a conceptual model where multiple VMs are deployed to a cloud service. A VIP is assigned to Windows Azure’s public interface and pointing to this cloud service, while each VM within the cloud service has an individual DIP assigned by Windows Azure via DHCP.

Notice that if these VMs are deployed to a virtual network, a DIP will be assigned from or released to the address pool defined in the virtual network configuration.

Endpoint vs. Port

In Windows Azure, accessing a cloud service from Internet requires an endpoint which is a pair of two ports associated with the VIP of the cloud service. The public port of an endpoint is the one facing Internet, while within Windows Azure the corresponding port is the private port. The above diagram depicts the concept of an endpoint as the vehicle to access a cloud service from Internet, while a defined endpoint effectively connects a public interface and a private one of a cloud service with a port translation at the edge of Windows Azure where the VIP points.

Stopped vs. Stopped (Deallocated)

A Windows Azure VM instance can be shut down with two fundamental ways. One is to shut down a VM within the VM instance itself as shown below. This will bring the VM to a “Stopped” state. At this time, although the instance is stopped, it is however not deallocated, and consequently it is still being charged by minute based on the pricing model as detailed in http://aka.ms/waPrice.

Another way to stop the VM instance is to operate directly from Windows Azure Management Portal by highlighting a VM an click the Shutdown button from the black menu bar as shown above. Which in addition to shutting down the VM, it also deallocates the instance as the status, Stopped (Deallocated), indicated. At this time, the VM instance is not being charged any more.

The storage cost of a VM is introduced by the associated VHD file which include an OS disk and additional data disk, if added. This storage cost is always there since regardless the state of a VM, storage capacity is consumed to store a VHD file which is stored as page blobs in an associated storage account and depending on if geo-replication is maintained, there may be additional storage and transmission costs. The article, http://aka.ms/HADR explains the two storage account types and how they work.

IP Assignments in Windows Azure Virtual Network (VNET)

When allocating addresses, Azure reserved the first three and the last IP addresses in an address space and a subnet. For instance, defining an address space, 10.0.0.0/24, as the following results in a usable address range of 10.0.0.4 to 10.0.0.254 where the first three and the last IP addresses of this address space, i.e. 10.0.0.1-3 and 10.0.0.255 are reserved for Azure’s use. This behavior is consistent throughout the subnets. Essentially any address space allocated in Azure, the first three and the last one are reserved for system use.

When deploying VMs to a VNET, the DIPs (i.e. internal IP addresses) of VMs are allocated from a configured address pool (as defined in VNET) in the order of each VM is deployed. Therefore deploying the same VMs in a different order to the VNET or deallocating then redeploying VMs in a VNET will likely result in different internal IP addresses assigned. For example, two VMs in a VNET had had a Stopped Deallocated state and then both were restarted in a random order. The new internal IP addresses assigned to the two VMs will likely be different than those internal IP addresses previously assigned before deallocation. And it is an issue for VMs requiring persistent IP addresses throughout the lifetime of those VMs. However, if a static IP address is assigned to a VM, the same predictable IP address will be assigned with the VM upon restart. For a VM deployed to a VNET, a static IP can be assigned to the VM using Windows Azure PowerShell.

In Part 2, we will walk through a sample session on assigning a static IP to a VM which is deployed to a VNET.

Important Compliance Information of Microsoft Cloud Computing Solutions

Subscribe update of this page.

HIPPA

Microsoft’s Cloud Infrastructure Receives FISMA Approval	http://aka.ms/FISMA
Windows Azure Compliance	http://aka.ms/waCompliance
Windows Azure HIPPA Implementation Guidance	http://aka.ms/waHIPPA
Office 365 Trust Center and Regulatory Compliance FAQ	http://aka.ms/o365TC
HIPAA Compliance with Office 365 (Exchange Online) – Steps for Configuration and Use	http://aka.ms/exOnlineHIPPA
HIPAA/HITECH Act Implementation Guidance for Microsoft Office 365 and Microsoft Dynamics CRM Online	http://aka.ms/o365HIPPA or http://aka.ms/crmHIPPA

Office 365 Compliance Certifications

http://aka.ms/o365Compliance