Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 26 Next »

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.

Azure V1 (Classic)

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:



Azure V2 (Resource Manager)

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:


Networking guide

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:

Creating Your Virtual Network

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
  1. 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.



    Availability sets can be created before or during the VM setup process. However, a VM cannot be added to an availability set after it has been provisioned; it must be specified at the time of initial configuration.

  2. Create the Virtual Machine(s).
    Provision one or more virtual machines by clicking  menu icon and then selecting the  button.



    Be sure to select Resource Manager when choosing the deployment model. This option is selected by default.

    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.


    If there is no need to connect to the VM from the public domain you may disassociate the public IP from the network interface attached to it. However, since all inbound traffic is essentially blocked on the public IP there is no consequence to leaving it enabled.

  3. Create the Load Balancer(s).

    Provision one of more load balancers by clicking the  menu icon and then selecting the  button.

    When assigning a new public IP address, the address will not be allocated until the load balancer is associated to a backend pool and the rules and probes are in place. Until this is configured, Azure considers the load balance to be not in use.

  4. 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)



  5. 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. 



  6. 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.



  7. Open port(s) on the VM
 Using Azure Powershell

Before proceeding please ensure you have installed Azure Powershell. For more information, see Install Azure Powershell. In addition, please ensure you run the Powershell application with elevated privileges.

  1. Login to your Azure subscription

    Connect to your Azure account and ensure you are connected to the correct subscription.

    PowerShell
    # 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
    
    
  2. 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:

    PowerShell
    #Create a Resource Group
    New-AzureRmResourceGroup -Name "{ResourceGroupName}" -Location "{Location}"
    
    
  3. 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.

    PowerShell
    # 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
    
    
  4. 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

    PowerShell
    # 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



  5. Create the Virtual Machine(s)

    PowerShell
    # 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
    
    
    # Create the VM
    New-AzureRMVM -ResourceGroupName "{ResourceGroupName}" -Location "{Location}" -VM $vmConfig











Multiple NICs on a single VM

blah blah blah


  • No labels