ეს ბრაუზერი აღარ არის მხარდაჭერილი.
გადადით Microsoft Edge-ზე, რათა ისარგებლოთ უახლესი ფუნქციებით, უსაფრთხოების განახლებებითა და ტექნიკური მხარდაჭერით.
This article discusses a collection of Azure best practices for your load balancer deployment. These best practices are derived from our experience with Azure networking and the experiences of customers like yourself.
For each best practice, this article explains:
These best practices are based on a consensus opinion, and Azure platform capability and features sets, as they exist at the time this article was written.
The following architectural guidance helps ensure the reliability of your Azure Load Balancer deployment. It includes best practices for deploying with zone-redundancy, redundancy in your backend pool, and deploying a global load balancer. Along with reliability for Gateway Load Balancer, which is recommended when using NVAs instead of a dual load balancer set-up.
The following best practices are recommended to ensure the reliability of your Azure Load Balancer deployment.
Zone-redundancy provides the best resiliency by protecting the data path from zone failure. The load balancer's availability zone selection is synonymous with its frontend IP's zone selection. For public load balancers, if the public IP in the load balancer's frontend is zone redundant then the load balancer is also zone-redundant.
Ensure that the backend pool contains at least two instances. If your backend pool only has one instance and it's unhealthy, all traffic sent to the backend pool fails due to lack of redundancy. The Standard Load Balancer SLA is also only supported when there are at least 2 healthy backend pool instances per backend pool. Visit the SLA documentation for more information.
Standard Load Balancer supports cross-region load balancing enabling regional redundancy through linking a global load balancer to your existing regional load balancers. With a global load balancer, if one region fails, the traffic is routed to the next closest healthy regional load balancer. For more details, visit the Global Load Balancer documentation.
For more information, see Azure Load Balancer Reliability documentation.
The following best practices are recommended to ensure the reliability of your Gateway Load Balancer deployment.
Chaining your Gateway Load Balancer to a Standard Public Load Balancer is recommended. This configuration provides high availability and redundancy on both the NVA and application layer. For more information, see Tutorial: Create a gateway load balancer
We recommend using a Gateway load balancer in north-south traffic scenarios with partner Network Virtual Appliances (NVAs). It's easier to deploy because Gateway load balancers don’t require extra configuration such as user-defined routes (UDRs) because it maintains flow stickiness and flow symmetry. It's also easier to manage because NVAs can be easily added and removed. For more information, see the Gateway Load Balancer documentation.
The following configuration guidance are best practices for configuring your Azure Load Balancer deployments.
To explicitly permit allowed inbound traffic, you should create Network Security Groups (NSGs). NSGs must be created on the subnet or network interface card (NIC) of your VM, otherwise there will be no inbound connectivity to your Standard external load balancers. For more information, see Create, change, or delete an Azure network security group.
Ensure 168.63.129.16 IP address isn't blocked by any Azure network security groups and local firewall policies. This IP address enables health probes from Azure Load Balancer to determine the health state of the VM. If it isn't allowed, the health probe fails as it is unable to reach your instance and it marks your instance as down. For more information, see Azure Load Balancer health probe and What is IP address 168.63.129.16?s.
Use outbound rules with manual port allocation instead of default port allocation to prevent SNAT exhaustion or connection failures. Default port allocation automatically assigns a conservative number of ports which can cause a higher risk of SNAT port exhaustion. Manual port allocation can help maximize the number of SNAT ports made available for each of the instances in your backend pool which can help prevent your connections from being impacted due to port reallocation. There are two options for manual port allocation, “ports per instance” or “maximum number of backend instances”. To understand the considerations of both, see Source Network Address Translation (SNAT) for outbound connections.
Azure Load Balancer uses a 5-tuple hash based distribution mode by default and also offers session persistence using a 2-tuple or 3-tuple hash. Consider whether your deployment could benefit from session persistence (also known as session affinity) where connections from the same client IP or same client IP and protocol go to the same backend instance within the backend pool. Also consider that enabling session affinity can cause uneven load distribution as most connections come from the same client IP or same client IP and protocol will be sent to the same backend VM. For more information about Azure Load Balancers distribution modes, see Azure Load Balancer distribution modes.
Enabling TCP resets on your Load Balancer sends bidirectional TCP resets packets to both client and server endpoints on idle time-out to inform your application endpoints that the connection timed out and is no longer usable. Without enabling TCP reset, the Load Balancer silently drops flows when the idle time-out of a flow is reached. It can also be beneficial to increase idle time-out and/or use a TCP keep-alive if you’re seeing connections time out. For more information on TCP resets, idle time-outs, and TCP keepalive, visit Load Balancer TCP Reset and idle time-out in Azure.
If you enable floating IP, ensure you have a loopback interface within guest OS that is configured with the frontend IP address of the load balancer. Floating IP needs to be enabled it you want to reuse the backend port across multiple rules. Some example use cases of port reuse include clustering for high availability and network virtual appliances. For more information, see Azure Load Balancer Floating IP configuration.
Separate your trusted and untrusted traffic on two different tunnel interfaces; use the tunnel interface type external for untrusted/not yet inspected or managed traffic and use the tunnel interface type internal for trusted/inspected traffic. As a security best practice, this ensures isolation of trusted and untrusted traffic and can allow for more granular traffic control and troubleshooting.
Ensure your NVAs MTU limit is increased to at least 1550, or up to the recommended limit of 4000 for scenarios where jumbo frames are used. Without increasing the MTU limit, you can experience packet drops due to the larger packet size from other packets generated by the VXLAN headers.
Along with new improvements and updates to Azure Load Balancer, there are also deprecations to functionalities. It's critical to stay updated and ensure you're making the necessary changes to avoid any potential service disruptions. For a complete list of retirement announcements, see the Azure Updates page and filter for “Load Balancer” under “Products” and “Retirements” under “Update Type”.
Basic Load Balancer will be retired September 30, 2025 and customers should upgrade from Basic Load Balancer to Standard Load Balancer by then. Standard Load Balancer provides significant improvements including high performance, ultra-low latency, security by default, and SLA of 99.99% availability.
Moving forward, don't use default outbound access and ensure all VMs have a defined explicit outbound method. This is recommended for better security and greater control over how your VMs connect to the internet. Default outbound access will retire September 30, 2025 and VMs created after this date must use one of the following outbound solutions to communicate to the internet:
ტრენინგი
მოდული
Improve application scalability and resiliency by using Azure Load Balancer - Training
In this module, you learn how to use Azure Load Balancer to distribute traffic between multiple virtual servers or services.
სერტიფიკაცია
Microsoft Certified: Azure Network Engineer Associate - Certifications
Demonstrate the design, implementation, and maintenance of Azure networking infrastructure, load balancing traffic, network routing, and more.
დოკუმენტაცია
Azure Load Balancer components
Overview of Azure Load Balancer components.
Quickstart: Create an internal load balancer - Azure portal - Azure Load Balancer
Learn to create an internal Azure Load Balancer and test it with two virtual machines. Learn how to configure traffic rules and health probes to distribute traffic across multiple VMs.
Learn how to use Azure Load Balancer to efficiently distribute traffic and improve application scalability. Explore quickstarts, tutorials, and how-to guides for deploying load balancers in virtual machines, cloud resources, and cross-premises networks.