How Windows Azure enables load balancing for internal servers

I started serving Windows http://www.aliyun.com/zixun/aggregation/13357.html ">azure" since 2009. During this period I was fortunate enough to build a solution for many customers of all sizes. As the solution grows, I often need to load balance my internal servers. When this article is published, Windows Azure has no built-in solution for load balancing. However, by introducing access control lists (ACLs) to public endpoints, I was able to load-balance using the standard Windows Azure services and components supported.

In my example, I want to load-balance a pair of Internet information Services (IIS) servers running on a virtual machine, which serves as the look of internal services exposed by using the ASP.net Web API. By creating a public load balancing endpoint shared by each IIS server, I am able to load balance my queries on these servers by using the standard load balancer in Windows Azure, where you can access all public endpoints.

I'm concerned that anyone on the Internet can access my service. But by applying ACLs to endpoints, I can restrict access to only my cloud service. ACLs add restrictions so that only queries from my cloud services can access the load-balanced endpoints, as shown in the following illustration.

Great！ It's so easy. So I spent some time thinking about the impact of my decision, and here are the pros and cons I think of:

Advantages

I implemented load balancing on the ASP.net Web API layer without looking for a partner solution. I used Microsoft-supported services and features to achieve a supported architecture that accurately completes the operations I want to perform. I discussed my solution with the product team, and they agreed that my solution is currently a supported implementation because they do not currently provide this functionality.

Shortcomings

The number of public ports that can currently be created on cloud services in Windows Azure is 25, which counts as one. All traffic through a single cloud service will come from the same public IP address. This means that all clients will share the same 164 K connection restrictions imposed by TCP. This restriction applies to connections from the same source port and source IP address to the same destination port and destination IP address. Only the ACL is supported as the infrastructure, the service (IaaS) solution, so I lost the platform, the service (PaaS) solution.

Ease

As with any flawed solution, it is always possible to find innovative ways to mitigate its shortcomings. I thought about the first two drawbacks, all due to the restrictions imposed on the cloud services (for example, the maximum number of public ports and one IP address per cloud service). I realized that I could spread virtual machines across multiple cloud services. By using a virtual network, I can split and maintain communication capabilities. However, this requires more IP addresses to be configured in the ACL.

Step-by-Step Solutions

Next I'll explain how I set up a load-balancing solution on two virtual machines ...

I initially configured two virtual machines for IIS and then used Windows PowerShell to create load-balanced endpoints and assign an ACL to each endpoint.

Go to the dashboard view of the cloud service that contains the virtual machine, and I can quickly find the public IP address I need to allow. As shown in the dashboard view below, my cloud service has an IP address of 137.135.81.135.