This article will cover setting up network interface configurations for virtual machines (VMs) and corresponding load balancers (LBs) within your Azure subscription. Before we begin, it is important to distinguish the important disparities between networking in Azure V1 (Classic) and Azure V2 (Resource Manager). This article will focus solely on the latter.
The old way of doing networking in the classic management portal was to wrap everything up in an abstraction known as the cloud service. The cloud service itself had a public IP address and then NAT rules would be created, using an endpoint, that opened a UDP or TCP port to the public using the cloud service's public IP address. Load balancing was achieved by simply duplicating an endpoint across two or more virtual machines. Virtual machines themselves could be connected to Internet with a public IP address, but these machines could not be load balanced. Effectively your network would look like this:
Things have changed significantly since the inception of ARM. Cloud service and endpoints have been eradicated. Instead a virtual network (VN) is designed with one or more subnets. For each virtual machine, a NIC is created and connected to a subnet in the VN and assigned an IP address within that subnet. Network security groups can be assigned to allow/deny traffic. As in classic mode, virtual machines are assigned a public IP address to expose it to the Internet. However, load balancing is no longer inherent in the network, instead they are separately provisioned.
It is important to note that an ARM load balancer is not a VM nor a network appliance but rather a function within the Network Resource Provider. A backend pool is configured within the load balancer and then associated to one or more virtual machines or to an availability set. A load balancer can only be associated to one availability set but you can create more than one backend pool from a single availability set and a VM can reside in more than one backend pool. The Azure network using Resource Manager looks like this:
While we will be outlining the basic steps to configure a typical LB/VM setup within your Virtual network, we will be also discussing three additional permutations for reference. These variations are:
To begin, we will start with the most basic configuration, which is the VMs setup with a single NIC instance. Essentially when you complete the steps below you will have a network resembling the following:
The diagram above segregates the components logically by their resource providers; Storage Resource Provider (SRP), Compute Resource Provider (CRP) and Network Resource Provider (NRP) respectively. You can learn more about Resource Providers here.
Begin by selecting which platform you wish to use to implement your virtual network.
Using Azure Portal
Create Availability Set(s) (Optional)
If you are creating more than one virtual machine (or more correctly, deploying an application with more than one tier) it may be advantageous to create availability sets. The purpose of availability sets is that the Azure platform has no way of distinguishing the application tiers associated with each VM. This could lead to a single point of failure across your entire application. When a VM is added to an availability set, by default Azure assigns it to two Fault Domains and five Update Domains. The VMs are allocated across these domains to ensure that not all VMs within a set will fail together. It is important to note that availability sets that contain only a single VM are not subjects to Azure's SLA. More information on availability sets can be found here.
Create the Virtual Machine(s).
Provision one or more virtual machines by clicking menu icon and then selecting the button.
By default, when using the Azure Portal, a new Virtual Machine will be provisioned with a single NIC with one public IP address and one private IP address on the subnet specified during setup. The network security group initial configuration is set to deny all inbound traffic to the virtual machine from outside the subnet, with the exception of port 22, which is used to SSH into the server.
Create the Load Balancer(s).
Provision one of more load balancers by clicking the menu icon and then selecting the button.
- Associate the Load Balancer to the VM or Availability Set
Add a backend pool to the Load Balance and associate to the appropriate machine(s)
- Add a Health Probe on the appropriate port(s)
Determine which port that traffic will be routed on from the load balancer to the underlying machine(s) and create a health probe on that port.
- Add Routing Rule to Load Balancer
After successfully saving the Backend Pool and Health Probe you can proceed to setup the rule that routes traffic from the Load Balancer to the VM(s) in the network.
- Open port(s) on the VM
Using Azure Powershell
Login to your Azure subscription
Connect to your Azure account and ensure you are connected to the correct subscription.
# To log in to Azure Resource Manager
Login-AzureRmAccount
# You can use a TenantID swtich for faster log in
#Login-AzureRmAccount -TenantID xxxxxxxxxx
# To view all subscriptions tied to your account
Get-AzureRmSubscription
# To switch subscriptions
Get-AzureRmSubscription -SubscriptionName "{SubscriptionName}" | Select-AzureRmSubscription
Create a Resource Group
If a Resource Group does not exist or you wish to use a new group, using the following script to create one:
#Create a Resource Group
New-AzureRmResourceGroup -Name "{ResourceGroupName}" -Location "{Location}"
Create Availability Set(s) (Optional)
If you are creating more than one virtual machine (or more correctly, deploying an application with more than one tier) it may be advantageous to create availability sets. The purpose of availability sets is that the Azure platform has no way of distinguishing the application tiers associated with each VM. This could lead to a single point of failure across your entire application. When a VM is added to an availability set, by default Azure assigns it to two Fault Domains and five Update Domains. The VMs are allocated across these domains to ensure that not all VMs within a set will fail together. It is important to note that availability sets that contain only a single VM are not subjects to Azure's SLA. More information on availability sets can be found here.
# Ensure you have AzureRm.Compute module is installed
# To view installed modules
Get-Module
# To list all modules
#Get-Module -ListAvailable
# If AzureRmCompute is not installed, go ahead and install it
#Install-Module AzureRM.Compute
# Create an availability set
New-AzureRmAvailabilitySet -ResourceGroupName "{ResourceGroupName}" -Name "{AvailabilitySetName}" -Location "{Location}"
# If you are using managed disks for your VM use the managed switch
#New-AzureRmAvailabilitySet -ResourceGroupName "{ResourceGroupName}" -Name "{AvailabilitySetName}" -Location "{Location}" -managed
Create Network Resources
Unlike in Azure Portal where network resources are created during the VM setup, in Powershell, they must be explicitly instantiated beforehand and then assigned to the VM you are creating
# Create a subnet configuration (Note: you can create more than one subnet in your VN)
$subnetConfig = New-AzureRmVirtualNetworkSubnetConfig -Name "{SubnetName}" -AddressPrefix "{IPAddressRange}"
# Create a virtual network (multiple subnets can be added using a comma-delimited list)
$vnet = New-AzureRmVirtualNetwork -ResourceGroupName "{ResourceGroupName}" -Location "{Location}" -Name "{VNName}" -AddressPrefix "{IPAddressRange}" -Subnet $subnetConfig
# Create a public IP address and specify a DNS name (you may concatenate the $(Get-Random) function to the DNS Name for uniqueness
$pip = New-AzureRmPublicIpAddress -ResourceGroupName "{ResourceGroupName}" -Location "{Location}" -AllocationMethod "{Static/Dynamic}" -IdleTimeoutInMinutes "{N}" -Name "{DNSName}"
# Create any number of security rules
# The example below allows inbound access on port 3389 for RDP connections
$nsgRuleRDP = New-AzureRmNetworkSecurityRuleConfig -Name "{RuleName}" -Protocol TCP `-Direction Inbound -Priority 1000 -SourceAddressPrefix * -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 3389 -Access Allow
# Create a network security group and assign the rules (multiple rules can be added using a comma-delimited list)
$nsg = New-AzureRmNetworkSecurityGroup -ResourceGroupName "{ResourceGroupName}" -Location "{Location}" -Name "{NetworkSecurityGroupName}" -SecurityRules $nsgRuleRDP
# Create a network interface card and associate with subnet (in this case we are assigning the first subnet), IP address and security group
$nic = New-AzureRmNetworkInterface -Name "{NicName}" -ResourceGroupName "{ResourceGroupName}" -Location "Location" -SubnetId $vnet.Subnets[0].Id -PublicIpAddressId $pip.Id -NetworkSecurityGroupId $nsg.Id
Create the Virtual Machine(s)
# Define a credential object
$cred = Get-Credential
# Create a virtual machine configuration
$vmConfig = New-AzureRmVMConfig -VMName "{VMName}" -VMSize "{VMSize}" |
Set-AzureRmVMOperatingSystem "{OperatingSystem}" -ComputerName "{VMName}" -Credential $cred |
Set-AzureRmVMSourceImage -PublisherName "{PublisherName}" -Offer "{Offer}" -Skus "{Sku}" -Version latest |
Add-AzureRmVMNetworkInterface -Id $nic.Id
Multiple NICs on a single VM
blah blah blah
Related articles