This two-part series details the IP address management of Windows Azure Infrastructure Services including:
This series is a cross-posting from http://yungchou.wordpress.com.
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.
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.
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.
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.
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, 1-.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 after being shut down from Windows Azure Management Portal.
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.
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.