在多个静态文件服务器之间均衡负载平衡的最佳方式,甚至是带宽分配?

首先,我会向你解释我的情况。 我正在运行一个相当受欢迎的网站作为一个副项目,所以我不能真的投入大量的资金。 我目前只有一个HAProxy服务器,向Apache发送正常请求,并向Lighttpd发送所有静态文件请求。 这是工作得很好,因为所有的PHP和POST请求都被Apache处理,而所有的图像被发送到更快的Lighttpd(该网站主要是图像,所以这是非常重要的)。 如果不需要build立一个服务于图片的子域名,这将是很好的,因为短的URL也是非常重要的,所以我使用HAProxy的原因。

我find了一个托pipe服务提供商,提供了我一直使用的相当便宜的无限量带宽,问题出现在我开始推出100MB网卡所能处理的带宽时,因此需要第二台服务器。

我已经对我的select进行了很多的思考,所以我会向你解释每一个。 希望你能提供一些洞察力,哪一个对我来说是最好的select,或者还有另一个我还没有想到的select。

要求:

  • 甚至带宽分配也是必须的。 我有一个非常强大的服务器,所以扩大是不是一个选项。 我需要扩展以获得更多的带宽。

  • 短url。 我真的不想设置像img.example.com这样的子域来提供我的图片。 example.com/image.jpg是如何现在,我真的很喜欢它留下来。 但是,如果没有别的办法,那么我明白了。

  • 处理请求的最接近的服务器将是非常好的,但不是必须的。 有一些事情要记住。

HAProxy负载平衡

  • 无论如何,因为我已经在使用HAProxy,所以做起来真的很容易。 不过,我认为问题出现在分配带宽时。 我可能在这方面是错误的,但不HAProxy发送请求到服务器处理它的服务器,然后通过HAProxy发送回到客户端? 因此,所有stream量都通过负载均衡器返回,从而使其占用与所有服务器组合在一起的带宽。

DNS循环:

  • 这可能是我最好的select。 只需复制网站跨多台服务器,并做我现在正在做的事情。 缺点是如果一台服务器停机,客户端仍然被发送到它。 我也需要在多个服务器上复制站点。 我有种希望,我可以有一个主要的服务器,除了静态文件处理一切,然后有几个静态文件服务器。 我还看到,这就是“穷人的负载平衡”,如果有更复杂一点的东西,那就太好了。

直接服务器返回:

  • 这似乎很复杂,但可能是一个不错的select。 我仍然能够发送特定的URL到某些服务器? 就像现在使用HAProxy一样,每个以正确文件扩展名结尾的URL都会被发送到Lighttpd,而其他扩展则被发送到Apache。 所以我需要类似的东西。 就像所有的php请求都由运行平衡软件的服务器处理,而所有的jpg请求都被发送到多个服务器。

理想情况下,如果HAProxy支持Direct Server Return,那么我的问题就可以解决了。 我也不想使用CDN,因为它们非常昂贵,毕竟这只是一个副项目。

你明白我的问题吗? 让我知道如果我没有解释正确的东西,或者如果你需要更多的信息。

为应用程序绘制您的请求/响应周期的图片,并隔离瓶颈。 你是正确的,一个代理分发负载到许多应用程序服务器将需要所有应用程序服务器的总带宽。 传统的解决scheme是RR DNS。 谷歌,雅虎和亚马逊都使用这种技术短TTL。 我做了一些调查, logging了我的发现 。

另一种解决scheme是使用虚拟IP寻址的花式企业负载平衡解决scheme来平衡具有真实IP地址的多个应用服务器之间的请求。 我曾与Netscaler和Stonesoft产品合作。 这两个performance都不错,但有很糟糕的特质,而且相当复杂。

一些答案:

  • 是的,所有stream量都通过HAProxy传递出去,因为它作为HTTP级别的代理。 即使HAProxy安装在负载均衡多个后端服务器的单独服务器上,情况也是如此。 因此,如果您的托pipe服务提供商只提供100MBit的networking端口,而您已经推送了100MBit,那么您遇到了问题。
  • 关于域名,最好的办法是从不同于你的web应用程序的域中提供图像 – 而不是一个子域,一个不同的子域,以便cookies不会在图像请求中发送。 请参阅Steve Souders的原创作品 ,或者在Stack Overflow上执行此处 。 如果短URL对你来说非常重要,最好的办法是将webapp从主URL移出,即将文件pipe理应用程序移到login.sitename.com上?

你需要authentication的图像请求? 如果没有,那么如何使用像Amazon S3的东西? 它具有很强的可扩展性,数据传输成本相当便宜。 在这种情况下,我会使用诸如i.sitename.com之类的东西作为Amazon S3存储桶主机名的DNS CNAME, 请参阅Amazons文档 。 AFAIK你不能拥有根域名(sitename.com)作为CNAME,所以你必须使用像i.sitename.com这样的子域名。

你也可以在多个服务器上散列你的图片。 即你创build一个像login.sitename.com和a.sitename.com的DNS结构; b.sitename.com; c.sitename.com等等。 “一个” 和“b”。 etc服务器只包含一个带有图像的文件系统和一个轻量级的HTTP服务器(你已经使用了Lighttpd,所以继续使用它)对于未来的项目,我build议把nginx看作是一个更好的替代品。一个图像,你创build一个唯一的标识符的哈希,也许他的用户名,也许文件名,或多个标识符的组合 。 从这个散列,你决定哪个服务器来存储图像。

编辑我应该看到哈希已经被讨论过了。 基本上我在这里提出的只是在主机名上使用散列,以在多个主机上均匀地分配networkingstream量。

我不知道你需要这么便宜 – 但是当你推动100MB的networkingstream量的时候,那么“便宜又好”很快就变成了一种幻想。 也许你应该首先考虑获得一个好的商业模式,一些可以提供经常性收入的东西,然后再实施适当的技术?

我假设HAProxy和其他应用程序在同一台服务器上? 您可以将HAProxy分解到另一个系统,以便运行请求,并将请求发送到一台服务器,并将请求映像到另一台服务器。 这个问题是所有的请求仍然会到一个盒子,如果你饱和它的带宽,那么这可能不会帮你很多。

你说短url很重要。 为什么? 将图片从“example.com”切换到“i.example.com”真的是一件大事吗? 您可以使用Lighttpd在自己的服务器上将“我”设置为自己的IP,并完全绕过HAProxy,从而解决您的吞吐量问题。 您也可以从Web浏览器中获益,从而允许更多的请求一次打开,因为它会将它们视为不同的域名并可以打开更多的并发连接。 如果单个“我”服务器饱和,您可以使用DNS循环来添加另一个。 希望到那个时候,您可以获得足够的收入来实施更好的解决scheme。

您的托pipe服务提供商提供负载均衡服务吗 我认为是最好的解决scheme。

另一种方式做到这一点,但它需要被testing,重写(在lighty或apache)的请求。 例如:example.com/file.html停留在apache,example.com/image.jpgredirect到i.example.com/image.jpg。 所有请求都将通过apache进行pipe理,但是响应(上行带宽)将转到lighttpd服务器。 该域对用户是透明的。 你仍然需要testing一下,如果Apache可以处理所有的请求,或者让lighttpd做这个工作。

你是对的所有的数据通过HAProxy,所以你不能(直到我知道)直接服务器回报。

UPDATE

在HAproxy文档中,我find了“redir”参数。 我不知道它是否可以像Apache重写,但它可以是有用的。 该文件说:

主要用途是通过让客户端直接连接到静态服务器来增加带宽。

也许它适用于你的情况。

我假设,任何大规模的图像集都不会根据原始文件名存储图像,因为您很快就会遇到名称冲突。

处理这些types的问题的很多应用程序都使用该文件的哈希和基于该哈希的目录结构。 目录结构如下所示,其中目录path是哈希的前两个字符,而第二级目录是哈希中的后两个字符。

/image root/AA/AA/images /image root/AA/AB/images 

这样做的好处是散列保持文件的分布非常均匀,它为您提供了一个易于在多个服务器上分割的命名空间。 基本上你可以从不同的服务器提供哈希空间的一部分,当你缩放的时候,你可以根据需要进一步细分。

缺点是哈希不完美,可能会发生碰撞。 我不确定这是如何处理的。 所以这可能需要您的一些研究。 我想在代理的重写规则应该能够采取散列说A3A8BBC83261.jpg并重写它到http://img3.domain.com/A3/A8/BBC83261.jpg 。 你可能不认为这是一个简短的url。

在你的文章中,你提到你觉得DNS round robbin可能是你最好的select,但你担心一台服务器出现故障。

如果是这种情况,请查看JH软件的简单故障转移。 我以前用过它,效果很好。

http://www.simplefailover.com

基本上,它监视你的服务器,当它看到一个下降,它迅速重写DNS,以拉死服务器的轮换。

以下是他们网站的摘录:

简单的故障转移会持续监视您的服务器,以确定哪些服务器已启动,哪些服务器已closures,然后相应地dynamic更新DNSlogging,以便您的域名始终指向function服务器。

它可以与Web服务器(HTTP),邮件服务器(SMTP,IMAP,POP3),FTP服务器以及几乎任何其他基于TCP / IP的服务器types一起使用。

如前所述,我曾经在网站和邮件服务器上使用它。 它performance相当好。 在大多数情况下,故障转移非常快(猜测2-5分钟),而且几乎所有人都会在不到15分钟的时间内完成故障转移。

不一定完美…但绝对快速和容易。

注:这是一个Windows产品。 我不知道他们是否有Linux版本,但是你可以故障转移任何你喜欢的服务器,因为它基于DNS。

在我们的例子中,我们只是把它扔在一台XP机器上,告诉机器每晚重启一次,运行良好多年。