Azure Traffic Manager and Load Balancing Network Design and Deep Dive

Business and technology leaders are facing new challenges and a changing landscape when it comes to operating and hosting their business. At Navisite, we have been working for quite some time with clients moving from a simple co-location and managed hosting to a multi-cloud environments.
The challenges are not just technical in nature. They require a holistic business strategy to embark on a journey from managing your own stack – servers, network, data and pipe to a cloud environment where your traditional methods of operations do not always apply.
In many cases, our clients are not in a position to do a forklift replacement from a managed/co-location to the cloud. As a result the typical question that comes up – “is there a hybrid world that we can live in”?
The challenges start with the people who are on the front-line, keeping your business services running 24x7x365. They have to unlearn much of what they have learned because the philosophy of operating in the new environment is fundamentally different.
As a business leader, you will need to arm the team with new skills, and put in place new best practices on security, data stewardship and governance. In this post, we will peel the onion to the core on moving to a hybrid cloud, along with the challenges and best practices on how to do it methodically because not doing it right is not an option for your business service availability.

Topic 1: Azure Load Balancing Network Design and Deep Dive

Microsoft documentation is very thorough and vast; this article bridges the gap between documentation and real-world implementation. The contents should enable you to implement  Azure load balancing technologies. This article also walks you through an example of multi-region Azure Traffic Manager Design and various verification steps.
Before we start, let’s test drive…

Test Drive (Click the links for real time experience)
Azure Load Balancer (L4 Load Balancing)

Azure Application Gateway (L7 Load Balancing with Round Robin)
Region: US East
Region: SE Asia

Azure Traffic Manager (Geo load balancing)

Check out the DNS Load balancing across the globe

Current Azure Load Balancing Limitations:

• Load balanced VMs need to be in the same availability sets.
• Azure Traffic Manager Geo load balancing is based on the closest DNS server that made the request and not the client proximity. This could skew the results.
• Application Gateway does not support static public IP addresses, but it does support static internal IP.

Azure Load Balancing Methods
There are different options to distribute network traffic using Microsoft Azure. These options work differently from each other, having a different feature set and support different scenarios. They can each be used in isolation, or combining them.

• Azure Load Balancer works at the transport layer (Layer 4 in the OSI network reference stack). It provides network-level distribution of traffic across instances of an application running in the same Azure data center.
• Application Gateway works at the application layer (Layer 7 in the OSI network reference stack). It acts as a reverse-proxy service, terminating the client connection and forwarding requests to back-end endpoints.
• Traffic Manager works at the DNS level. It uses DNS responses to direct end-user traffic to globally distributed endpoints. Clients then connect to those endpoints directly.

 
Preparing the Network Configuration for Azure Load Balancing
Create a Resource Group
Create Virtual Networks for each region 
Create Network Security Groups
Create Availability Sets
Create Management and Web Virtual Machines 
Azure Load Balancer (layer 4)
Azure Load Balancer works at layer 4 and is configured with Hash Based Distribution Method. The default load distribution method is based on 5-tuple (Source IP, Source Port, Protocol, Dest IP, Dest Port). This method can be changed via PowerShell. Other options are Source IP and Source IP Protocol. 
There are three types of Azure load balancing configurations:

• External load balancing: Load balance incoming Internet traffic to virtual machines.
• External load balancing: Load balance traffic between virtual machines in a virtual network, between virtual machines in cloud services, or between on-premises computers and virtual machines in a cross-premises virtual network.
• Port Forwarding/NAT: Forward external traffic to a specific virtual machine.

To create a new load balancer from Azure Portal configure the following:

1. Review frontend IP Configuration.
2. Create a backend server pools. Associate with the availability set and add target web servers – Red, Green and Blue.
3. Add the Health probe with tcp/80.
4. Create load balancing Rule for tcp/80.
5. Optional NAT.

Closer Looks at Packet Flow on Red Web Server

root@nn-east-web-red:~# ip add sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0d:3a:00:2b:84 brd ff:ff:ff:ff:ff:ff
    inet 10.5.2.4/24 brd 10.5.2.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::20d:3aff:fe00:2b84/64 scope link
       valid_lft forever preferred_lft forever
root@nn-east-web-red:~# arp -an
? (10.5.2.1) at 12:34:56:78:9a:bc [ether] on eth0
root@nn-east-web-red:~# netstat -ant | grep EST
root@nn-east-web-red:/var/www/html# tcpdump -ni eth0 not port 22 and not host 52.239.198.20 and not host 168.63.129.16
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:46:33.020665 IP 216.251.225.7.56131 > 10.5.2.4.80: Flags [S], seq 1133805041, win 8192, options [mss 1170,nop,wscale 8,nop,nop,sackOK], length 0
14:46:33.020707 IP 10.5.2.4.80 > 216.251.225.7.56131: Flags [S.], seq 1606609168, ack 1133805042, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
14:46:33.062949 IP 216.251.225.7.56131 > 10.5.2.4.80: Flags [.], ack 1, win 260, length 0
14:46:33.065195 IP 216.251.225.7.56131 > 10.5.2.4.80: Flags [P.], seq 1:491, ack 1, win 260, length 490: HTTP: GET / HTTP/1.1
14:46:33.065216 IP 10.5.2.4.80 > 216.251.225.7.56131: Flags [.], ack 491, win 237, length 0
14:46:33.065820 IP 10.5.2.4.80 > 216.251.225.7.56131: Flags [P.], seq 1:484, ack 491, win 237, length 483: HTTP: HTTP/1.1 200 OK
14:46:33.300238 IP 216.251.225.7.56131 > 10.5.2.4.80: Flags [.], ack 484, win 258, length 0
14:46:38.047966 IP 10.5.2.4.80 > 216.251.225.7.56131: Flags [F.], seq 484, ack 491, win 237, length 0
14:46:38.140927 IP 216.251.225.7.56131 > 10.5.2.4.80: Flags [.], ack 485, win 258, length 0
14:46:38.262114 IP 216.251.225.7.56131 > 10.5.2.4.80: Flags [F.], seq 491, ack 485, win 258, length 0
14:46:38.262133 IP 10.5.2.4.80 > 216.251.225.7.56131: Flags [.], ack 492, win 237, length 0
Notice FIN sent by the web server after 5 seconds (Apache KeepAliveTimeout)
root@nn-east-web-red:/etc/apache2# grep -A 2 KeepAliveTimeout apache2.conf
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#
KeepAliveTimeout 5
root@nn-east-web-red:~# netstat -ant | grep EST
tcp        0      0 10.5.2.4:22             10.5.1.4:54766          ESTABLISHED
tcp6       0      0 10.5.2.4:80             216.251.225.7:56462     ESTABLISHED

 
Distribution Method 

 
Azure Application Gateway (layer 7)
Application Gateway is a layer 7 load balancer, which means it works with web traffic only (HTTP/HTTPS/WebSocket). It supports capabilities such as SSL termination, cookie-based session affinity, and round robin for load balancing traffic. AAG Frequently Asked Questions (FAQs).
To configure Application Gateway
1. Create Application Gateway. Cannot use static public IPs.
2. Update appGatewayBackendPool with target web servers- Red, Green and Blue.

Azure Traffic Manager (DNS Based)
Azure Traffic Manager provides DNS based distribution service to load balance applications in multiple regions based on geographic proximity.
There are three types of endpoint supported by Traffic Manager:

• Azure endpointsare used for services hosted in Azure – PaaS cloud services, Web Apps or PublicIPAddress resources (which can be connected to VMs either directly or via an Azure Load Balancer). The PublicIPAddress must have a DNS name assigned to be used in a Traffic Manager profile.
• External endpoints are used for services hosted outside Azure, either on-premises or with a different hosting provider.
• Nested endpoints are used to combine Traffic Manager profiles to create more flexible traffic-routing schemes to support the needs of larger, more complex deployments.

To configure Azure Traffic manager

1. Create a Traffic Manager Profile. Pick a unique DNS name and use the Routing Method as “Performance”. Closest endpoint based on network latency.
2. Go to settings -> endpoints and add Azure Endpoints. Add the two Azure Application Gateways as endpoints.
3. Test the URL: https://nncolors.trafficmanager.net
4. Verify Geo load balancing from DNS servers across the globe. East coast will resolve to the application gateway on the East and the Southeast Asia ones resolve to the application gateway on the Southeast Asia regions.

Check out the DNS Load balancing across the globe 

Stay tuned for more posts on this series.  Special thanks to my esteemed leaders John Rudenauer and Dave Grimes for their help on this post about Azure load balancing.
Questions or Comments? Reach out to Nehali Neogi ( nneogi [at] navisite.com ).