如何对内部服务器实现负载平衡

Article
11/05/2013

编辑人员注释： 本文章由 Windows Azure 客户咨询团队项目经理 Chris Clayton 撰写。

我从 2009 年开始服务于 Windows Azure。期间我有幸为各种规模的组织的众多客户构建了解决方案。随着解决方案的增长，我常常需要对内部服务器进行负载平衡。发表本文时，Windows Azure 还没有应对负载平衡的内置解决方案。但是，通过对公共端点引进访问控制列表 (ACL)，我能够使用受支持的标准 Windows Azure 服务和组件来实现负载平衡。

在我的示例中，我想对运行于虚拟机上的一对 Internet 信息服务 (IIS) 服务器进行负载平衡，这对服务器充当通过使用 ASP.NET Web API 暴露的内部服务的外观。通过创建每个 IIS 服务器共享的公共负载平衡端点，我能够通过使用 Windows Azure 中的标准负载平衡器（您可通过此平衡器访问所有公共端点），在这些服务器上对我的查询进行负载平衡。

我担心 Internet 上的任何人都能访问我的服务。但通过向端点应用 ACL，我可以限制为只有我的云服务具有访问权限。ACL 添加了限制，使得只有来自我的云服务内的查询才能访问负载平衡的端点，如下图所示。

好极了！这真是太容易了。于是我花了一些时间考虑我的决定的影响，以下是我想到的优点和缺点：

优点

我在ASP.NET Web API 层上实现了负载平衡，而无需寻求合作伙伴解决方案。
我使用了 Microsoft 支持的服务和功能，从而实现了能准确完成我想执行的操作的受支持结构。
我与产品团队讨论了我的解决方案，他们赞同我的解决方案是目前受支持的实施方案，因为他们当前还不提供此功能。

缺点

目前可以在 Windows Azure 中的云服务上创建的公共端口数为 25 个，这也算作其中一个。
所有通过单一云服务进行的通信都将来自于相同的公共 IP 地址。这意味着所有客户端将共享 TCP 施加的同一 64K 连接限制。此限制适用于从相同源端口和源 IP 地址到相同目标端口和目标 IP 地址的连接。
仅支持将 ACL 用作基础结构即服务 (IaaS) 解决方案，因此我失去了平台即服务 (PaaS) 解决方案。

缓解

与任何有缺点的解决方案一样，总是能够找到缓解其缺点的创新方法。我思考了前两个缺点，它们皆是由于对云服务施加的限制（例如，公共端口最大数量和每个云服务一个 IP 地址）所致。我意识到可以将虚拟机分散到多个云服务。通过使用虚拟网络，我可以将其拆分并保持通信功能。但是，这要求在 ACL 中配置更多 IP 地址。

逐步解决方案

接下来我将说明我如何在两台虚拟机上设置负载平衡解决方案…

开始时我完整配置了两个用于 IIS 的虚拟机，然后使用 Windows PowerShell 创建负载平衡的端点，并在每个端点上分配了一个 ACL。