Load-Balance traffic in Azure Flashcards
What is load balancing?
The term load balancing refers to the even distribution of workloads (that is, incoming network traffic), across a group of backend computing resources or servers. Load balancing aims to optimize resource use, maximize throughput, minimize response time, and avoid overloading any single resource.
What are the 4 main load balancers azure offers?
- Azure Load Balancer - High-performance, ultra-low-latency Layer 4 load-balancing service (inbound and outbound) for all UDP and TCP protocols.
- Traffic Manager - DNS-based traffic load balancer that enables you to distribute traffic optimally to services across global Azure regions, while providing high availability and responsiveness.
- Azure Application Gateway - Provides application delivery controller (ADC) as a service, offering various Layer 7 load-balancing capabilities. Use it to optimize web farm productivity by offloading CPU-intensive SSL termination to the gateway.
- Azure Front Door - Application delivery network that provides global load balancing and site acceleration service for web applications. It offers Layer 7 capabilities for your application like SSL offload, path-based routing, fast failover, caching, etc.
In what 2 ways can these Load Balancing services be categorized?
- Global versus regional:
- Global load-balancing services distribute traffic across regional backends, clouds, or hybrid on-premises services. These services route end-user traffic to the closest available backend.
- Regional load-balancing services distribute traffic within virtual networks across virtual machines (VMs) or zonal and zone-redundant service endpoints within a region. - HTTP(S) versus non-HTTP(S):
- HTTP(S) load-balancing services are Layer 7 load balancers that only accept HTTP(S) traffic. They’re intended for web applications or other HTTP(S) endpoints. They include features such as SSL offload, web application firewall, path-based load balancing, and session affinity.
- non-HTTP(S) load-balancing services can handle non-HTTP(S) traffic and are recommended for nonweb workloads.
What categories do the 4 LB services mentioned earlier fall in?
What things should you consider when designing a LB solution?
- Type of traffic - is it for a web application? Is it a public-facing or private application?
- Scope - do you need to load balance virtual machines and containers within a virtual network, or load balance across regions, or both?
- Availability - what is the Service Level Agreement (SLA) for the service?
- Cost - In addition to the cost of the actual service itself, consider the operational cost to manage and maintain a solution built on that service. See Load balancing pricing.
- Features and limitations - what features and benefits does each service provide, and what are its limitations? See Load balancer limits.
How does the Azure Load Balancer work?
Azure Load Balancer operates at layer 4 of the Open Systems Interconnection (OSI) model. It’s the single point of contact for clients. Azure Load Balancer distributes inbound flows that arrive at the load balancer’s front end to backend pool instances.
Name and briefly describe the 2 types of LBs.
- Public load balancer - can provide outbound connections for virtual machines (VMs) inside your virtual network. These connections are accomplished by translating their private IP addresses to public IP addresses. External load balancers are used to distribute client traffic from the internet across your VMs.
- Internal load balancer - is used where private IPs are needed at the frontend only. Internal load balancers are used to load balance traffic from internal Azure resources to other Azure resources inside a virtual network.
How do Zonal/Zone-redundant LBs work?
- Zone-Redundant:
A single frontend IP address survives zone failure. The frontend IP may be used to reach all (nonimpacted) backend pool members no matter the zone. One or more availability zones can fail and the data path survives as long as one zone in the region remains healthy.
- Zonal:
You can choose to have a frontend guaranteed to a single zone, which is known as a zonal. The data path is unaffected by failures in zones other than where it was guaranteed. You can use zonal frontends to expose an IP address per Availability Zone.
For a public load balancer frontend, you add a zones parameter to the public IP. This public IP is the frontend IP configuration used by the respective rule.
For an internal load balancer frontend, add a zones parameter to the internal load balancer frontend IP configuration. A zonal frontend guarantees an IP address in a subnet to a specific zone.
Name the 2 LB SKUs available and their offerings in the followings areas:
- Backend pool size
- Backend pool endpoints
- Health probes
- Health probe down behavior
- Availability Zones
- Basic:
- Backend pool size - Supports up to 300 instances.
- Backend pool endpoints - Virtual machines in a single availability set or virtual machine scale set.
- Health probes - TCP, HTTP
- Health probe down behavior - TCP connections stay alive on an instance probe down. All TCP connections end when all probes are down.
- Availability Zones - Not available
- Standard:
- Backend pool size - Supports up to 1,000 instances.
- Backend pool endpoints - Any virtual machines or virtual machine scale sets in a single virtual network.
- Health probes - TCP, HTTP, HTTPS
- Health probe down behavior - TCP connections stay alive on an instance probe down and on all probes down.
– Availability Zones - Zone-redundant and zonal frontends for inbound and outbound traffic.
What SKU does Microsoft recommend and why?
Microsoft recommends Standard load balancer. Standalone VMs, availability sets, and virtual machine scale sets can be connected to only one SKU, never both. Load balancer and the public IP address SKU must match when you use them with public IP addresses.
SKUs aren’t mutable; therefore, you cannot change the SKU of an existing resource.
What is azure traffic manager?
Azure Traffic Manager is a DNS-based traffic load balancer. This service allows you to distribute traffic to your public facing applications across the global Azure regions.
Name and briefly describe the 5 key features of TM.
- Increase application availability - Traffic Manager delivers high availability for your critical applications by monitoring your endpoints and providing automatic failover when an endpoint goes down.
- Improve application performance - Azure allows you to run cloud services and websites in datacenters located around the world. Traffic Manager can improve the responsiveness of your website by directing traffic to the endpoint with the lowest latency.
- Service maintenance without downtime - You can plan maintenance on your applications without downtime. Traffic Manager can direct traffic to alternative endpoints while the maintenance is in progress.
- Combine hybrid applications - Traffic Manager supports external, non-Azure endpoints enabling it to be used with hybrid cloud and on-premises deployments, including the burst-to-cloud, migrate-to-cloud, and failover-to-cloud scenarios.
- Distribute traffic for complex deployments - Using nested Traffic Manager profiles, multiple traffic-routing methods are combined to create sophisticated and flexible rules to scale to the needs of larger, more complex deployments.
When Azure TM recieves traffic for an endpoint, how does it decide which endpoint to send it to?
They choose an endpoint based on:
- The configured state of each endpoint (disabled endpoints aren’t returned)
- The current health of each endpoint, as determined by the Traffic Manager health checks.
- The chosen traffic-routing method.
Name and briefly explain the 6 Azure TM routing methods.
- Priority - This routing method for a primary service endpoint for all traffic. You can provide multiple backup endpoints in case the primary or one of the backup endpoints is unavailable.
- Weighted - This routing method when you want to distribute traffic across a set of endpoints based on their weight. Set the weight the same to distribute evenly across all endpoints.
- Performance - This routing method when endpoints are in different geographic locations. Users should use the “closest” endpoint for the lowest network latency.
- Geographic - This routing method to direct users to specific endpoints (Azure, External, or Nested) based on where their DNS queries originate from geographically. With this routing method, it enables you to be compliant with scenarios such as data sovereignty mandates, localization of content & user experience and measuring traffic from different regions.
- MultiValue - This routing method for Traffic Manager profiles with only one IPv4/IPv6 address endpoint. When a query is received for this profile, all healthy endpoints are returned.
- Subnet - This routing method to map sets of end-user IP address ranges to a specific endpoint. When a request is received, the endpoint is the one mapped for that request’s source IP address.
What are the 3 types of endpoints TM supports?
- Azure endpoints - Use this type of endpoint to load-balance traffic to a cloud service, web app, or public IP address in the same subscription within Azure.
- External endpoints - Use this type of endpoint to load balance traffic for IPv4/IPv6 addresses, FQDNs, or for services hosted outside Azure. These services can either be on-premises or with a different hosting provider.
- Nested endpoints - Use this type of endpoint to combine Traffic Manager profiles to create more flexible traffic-routing schemes to support the needs of larger, more complex deployments.
Name the 2 Monitoring methods Azure Traffic Manager uses and how they work.
- HTTP/HTTPS - When the monitoring protocol is set as HTTP or HTTPS, the Traffic Manager probing agent makes a GET request to the endpoint using the protocol, port, and relative path given. An endpoint is considered healthy if probing agent receives a 200-OK response, or any of the responses configured in the Expected status code *ranges. If the response is a different value or no response get received within the time out period, the Traffic Manager probing agent reattempts according to the Tolerated Number of Failures setting.
- TCP - When the monitoring protocol is TCP, the Traffic Manager probing agent creates a TCP connection request using the port specified. If the endpoint responds to the request with a response to establish the connection, that health check is marked as a success. The Traffic Manager probing agent resets the TCP connection. In cases where the response is a different value or no response get received within the time out period, the Traffic Manager probing agent reattempts according to the Tolerated Number of Failures setting.
What does the Azure Application gateway provide?
Application Gateway provides features such as load balancing HTTP traffic and web application firewall. It provides support for TLS/SSL encryption of traffic between users and an application gateway and between application servers and an application gateway.
How does App-GW route its traffic?
Application Gateway uses a round-robin process to load balance requests to the servers in each back-end pool.
What is session stickiness?
Session stickiness ensures client requests in the same session are routed to the same back-end server. Session stickiness is especially important with e-commerce applications where you don’t want a transaction to be disrupted because the load balancer bounces it around between back-end servers.
Name some of the key features & App-GW offers?
- Support for the HTTP, HTTPS, HTTP/2, and WebSocket protocols
- A web application firewall to protect against web application vulnerabilities
- End-to-end request encryption
- Autoscaling to dynamically adjust capacity as your web traffic load change
- Connection draining allowing graceful removal of back-end pool members during planned service updates
Briefly name and explain the main 3 components of an APP-GW.
- Front-end IP address: Client requests are received through a front-end IP address. You can configure Application Gateway to have a public IP address, a private IP address, or both. Application Gateway can’t have more than one public IP address and one private IP address.
- Listeners: Application Gateway uses one or more listeners to receive incoming requests. A listener accepts traffic arriving on a specified combination of protocol, port, host, and IP address. Each listener routes requests to a back-end pool of servers following routing rules that you specify. A listener can be Basic or Multi-site. A Basic listener only routes a request based on the path in the URL. A Multi-site listener can also route requests using the hostname element of the URL. Listeners also handle TLS/SSL certificates for securing your application between the user and Application Gateway.
- Routing rules: A routing rule binds a listener to the back-end pools. A rule specifies how to interpret the hostname and path elements in the URL of a request and direct the request to the appropriate back-end pool. A routing rule also has an associated set of HTTP settings. These HTTP settings indicate whether (and how) traffic is encrypted between Application Gateway and the back-end servers. Other configuration information includes Protocol, Session stickiness, Connection draining, Request timeout period, and Health probes.
What is a backend pool and how does it work?
A back-end pool is a collection of web servers that can be made up of: a fixed set of virtual machines, a virtual machine scale-set, an app hosted by Azure App Services, or a collection of on-premises servers.
Each back-end pool has an associated load balancer that distributes work across the pool. When configuring the pool, you provide the IP address or name of each web server. All the servers in the back-end pool should be configured in the same way, including their security settings.
If you’re using TLS/SSL, the back-end pool has an HTTP setting that references a certificate used to authenticate the back-end servers. The gateway re-encrypts the traffic by using this certificate before sending it to one of your servers in the back-end pool.
If you’re using Azure App Service to host the back-end application, you don’t need to install any certificates in Application Gateway to connect to the back-end pool. All communications are automatically encrypted. Application Gateway trusts the servers because Azure manages them.
What are the 2 primary methods an App-GW uses to route client traffic?
Path-based routing
Path-based routing sends requests with different URL paths to different pools of back-end servers.
Multiple-site routing
Multiple-site routing configures more than one web application on the same Application Gateway instance. In a multi-site configuration, you register multiple DNS names (CNAMEs) for the IP address of the application gateway, specifying the name of each site. Application Gateway uses separate listeners to wait for requests for each site. Each listener passes the request to a different rule, which can route the requests to servers in a different back-end pool.
What is TLS/SSL termination and what benefit does it provide?
It’s the termination of TLS/SSL connections at the application gateway. It offloads the CPU-intensive termination workload from your servers. Also, you don’t need to install certificates and configure TLS/SSL on your servers.
If you need end-to-end encryption, Application Gateway can decrypt the traffic on the gateway by using your private key, then re-encrypt again with the public key of the service running in the back-end pool.
