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


编辑人员注释:本文章由 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。

转到包含虚拟机的云服务的仪表板视图,我可以快速找到我需要允许的公共 IP 地址。如以下仪表板视图所示,我的云服务的 IP 地址为 137.135.81.135。

我打开 Windows PowerShell 并运行以下命令,这些命令利用 Windows Azure 模块中的 cmdlet。这些命令将在对端口 80 进行侦听的每个虚拟机上创建一个新端点,并将 ACL 设置为只有我的云服务的 IP 地址 (137.135.81.135) 具有访问权限。

为测试负载平衡器是否已正常工作,我将默认 IIS 页面更改为显示指示虚拟机名称的文本。我尝试从云服务外部访问虚拟机。不出所料!ACL 已正常运行。

我使用远程桌面连接到运服务器内的虚拟机,并尝试进行相同的测试。这次我看到了网站名称和虚拟机的名称。

我强制页面不断刷新,我注意到虚拟机的名称随着负载平衡器对我的请求进行处理而不断变化。

通过将 Windows Azure 内可用的多项现有受支持服务组合起来,我已经可以对我的内部 IaaS 虚拟机实现负载平衡。此解决方案有一些不足之处(如前文所述);但我认为它在许多情况下仍然非常实用。

欢迎您提供任何反馈意见。请随时发送电子邮件到 Chris Clayton

本文翻译自:

http://blogs.msdn.com/b/windowsazure/archive/2013/10/30/how-to-load-balance-internal-servers.aspx

 

 

Comments (0)

Skip to main content