通过TTL加权轮循-可能吗？

我目前使用DNS轮询进行负载平衡，效果很好。记录看起来像这样（我的TTL为120秒）

;; ANSWER SECTION:
orion.2x.to.        116 IN  A   80.237.201.41
orion.2x.to.        116 IN  A   87.230.54.12
orion.2x.to.        116 IN  A   87.230.100.10
orion.2x.to.        116 IN  A   87.230.51.65

我了解到并不是每个ISP /设备都以相同的方式对待这种响应。例如，某些DNS服务器随机旋转地址，或始终循环访问它们。有些只是传播第一个条目，而另一些则通过查看IP地址来确定哪个最好（在区域附近）。

但是，如果用户群足够大（分布在多个ISP等上），则可以很好地保持平衡。从最高负载到最低负载的服务器的差异几乎都不超过15％。

但是，现在我遇到的问题是，我正在向系统中引入更多服务器，而并非所有服务器都具有相同的容量。

我目前只有1 Gbps服务器，但我想同时使用100 Mbps和10 Gbps服务器。

因此，我想介绍一种权重为100的10 Gbps服务器，权重为10的1 Gbps服务器和权重为1的100 Mbps服务器。

之前，我曾两次添加服务器以向它们带来更多流量（效果很好，带宽几乎增加了一倍）。但是将10 Gbps服务器100次添加到DNS有点荒谬。

所以我考虑使用TTL。

如果我给服务器A提供240秒的TTL，给服务器B仅提供120秒（这大约是用于轮询的最小时间，因为如果指定了较低的TTL，则许多DNS服务器都设置为120（所以我已经听说过））。我认为这样的事情应该在理想的情况下发生：

First 120 seconds
50% of requests get server A -> keep it for 240 seconds.
50% of requests get server B -> keep it for 120 seconds

Second 120 seconds
50% of requests still  have server A cached -> keep it for another 120 seconds.
25% of requests get server A -> keep it for 240 seconds
25% of requests get server B -> keep it for 120 seconds

Third 120 seconds
25% will get server A (from the 50% of Server A that now expired) -> cache 240 sec
25% will get server B  (from the 50% of Server A  that now expired) -> cache 120 sec
25% will have server A cached for another 120 seconds
12.5% will get server B (from the 25% of server B that now expired) -> cache 120sec
12.5% will get server A (from the 25% of server B that now expired) -> cache 240 sec

Fourth 120 seconds
25% will have server A cached -> cache for another 120 secs
12.5% will get server A (from the 25% of b that now expired) -> cache 240 secs
12.5% will get server B (from the 25% of b that now expired) -> cache 120 secs
12.5% will get server A (from the 25% of a that now expired) -> cache 240 secs
12.5% will get server B (from the 25% of a that now expired) -> cache 120 secs
6.25% will get server A (from the 12.5% of b that now expired) -> cache 240 secs
6.25% will get server B (from the 12.5% of b that now expired) -> cache 120 secs
12.5% will have server A cached -> cache another 120 secs
... I think I lost something at this point, but I think you get the idea...

如您所见，这很难预测，在实践中肯定不会这样。但这绝对会对分配产生影响！

我知道加权轮询存在并且仅由根服务器控制。它只是在响应时循环浏览DNS记录，并以与加权相对应的固定概率返回DNS记录。我的DNS服务器不支持此功能，我的要求也不是很精确。如果它不能完美地加重，可以，但是应该朝正确的方向发展。

我认为使用TTL字段可能是一种更优雅，更轻松的解决方案-它不需要DNS服务器动态地控制它，从而节省了资源-在我看来，这是DNS负载平衡与硬件负载平衡器的重点。

我现在的问题是：是否有使用DNS记录的TTL属性权衡循环分配的最佳实践/方法/经验法则？

编辑：

该系统是前向代理服务器系统。带宽量（非请求）超过一台带有以太网的服务器可以处理的带宽。因此，我需要一个平衡解决方案，将带宽分配到多个服务器。除了使用DNS，还有其他方法吗？当然，我可以使用带有光纤通道等的负载平衡器，但是成本太高了，而且它只会增加瓶颈的宽度，而不能消除瓶颈。我唯一能想到的就是Anycast（是Anycast还是组播？）IP地址，但是我没有办法建立这样的系统。

首先，我完全同意@Alnitak的观点，即DNS不是为此类事情而设计的，最佳实践是不要将DNS用作穷人的负载平衡器。

我现在的问题是...是否有最佳的规范/方法/经验法则来衡量使用DNS记录的TTL属性的轮询分配？

为了在问题的前提下回答，使用DNS执行basix加权轮询的方法是：

• 调整权威DNS响应中记录的相对出现率。也就是说，如果Server A要拥有1/3的流量并Server B拥有2/3，则对DNS代理的权威DNS响应的1/3将仅 包含AIP，而响应的2/3 仅包含BIP。（如果两个或更多服务器共享相同的“权重”，则可以将它们捆绑为一个响应。）
• 保持较低的DNS TTL，以使不平衡的负载相对较快地得到平衡。由于下游DNS代理后面的客户端数量非常不均匀，因此您希望经常重新整理记录。

亚马逊的Route 53 DNS服务使用此方法。

带宽量（非请求）超过一台带有以太网的服务器可以处理的带宽。因此，我需要一个平衡解决方案，将带宽分配到多个服务器。

对。因此，据我了解，您有某种“便宜”的下载/视频分发/大文件下载服务，其中总服务比特率超过1 GBit。

如果不知道服务和服务器布局的确切细节，就很难做到精确。但是这种情况下的常见解决方案是：

• DNS循环到两个或多个TCP / IP或HTTP级别的负载均衡器实例。
• 每个负载平衡器实例都是高度可用的（2个相同的负载平衡器协作以始终保持一个IP地址处于打开状态）。
• 每个负载均衡器实例都使用加权轮询或加权随机连接处理到后端服务器。

可以使用开源软件或许多供应商提供的专用设备来构建这种设置。这里的负载平衡标签是一个很好的起点，或者您可以雇用在此之前已经做过此事的系统管理员为您咨询...

我现在的问题是...是否有最佳的规范/方法/经验法则来衡量使用DNS记录的TTL属性的轮询分配？

是的，最佳做法是不做！

请在我之后重复

• DNS不用于负载平衡
• DNS不提供弹性
• DNS不提供故障转移功能

DNS用于将名称映射到一个或多个IP地址。您所获得的任何后续平衡都是靠运气，而不是设计。

看一下PowerDNS。它允许您创建自定义管道后端。我已经修改了用perl编写的示例负载均衡器DNS后端，以使用Algorithm :: ConsistentHash :: Ketama模块。这使我可以像这样设置任意权重：

my $ketamahe = Algorithm::ConsistentHash::Ketama->new();

# Configure servers and weights
$ketamahe->add_bucket("192.168.1.2", 50);
$ketamahe->add_bucket("192.168.1.25", 50);

还有一个：

# multi-colo hash
my $ketamamc = Algorithm::ConsistentHash::Ketama->new();

# Configure servers and weights
$ketamamc->add_bucket("192.168.1.2", 33);
$ketamamc->add_bucket("192.168.1.25", 33);
$ketamamc->add_bucket("192.168.2.2", 17);
$ketamamc->add_bucket("192.168.2.2", 17);

我已经从所需的顶级域中将一个cname添加到一个称为gslb的子区域，即Global Server Load Balancing。从那里，我调用此自定义DNS服务器，并根据我想要的权重发送A记录。

像冠军一样工作。ketama哈希具有在添加服务器或调整权重时对现有配置造成最小干扰的良好特性。

我建议阅读Jan-Piet Mens撰写的“备用DNS服务器”。他在那里有很多好主意以及示例代码。

我还建议您放弃TTL调制。您已经走得很远了，在顶部添加另一个垃圾将使故障排除和文档编制变得极为困难。

您可以使用PowerDNS进行加权轮询，尽管以这种不平衡的方式分配负载（100：1？）可能会非常有趣，至少对于我在解决方案中使用的算法而言，每个RR条目都具有与之相关的权重，介于1到100之间，并且随机值用于包含或排除记录。

这是我写的有关在PowerDNS中使用MySQL后端执行加权RR DNS的文章：http : //www.mccartney.ie/wordpress/2008/08/wrr-dns-with-powerdns/

RIPienaar也有一些基于Ruby的示例（使用PowerDNS管道后端）：http : //code.google.com/p/ruby-pdns/wiki/RecipeWeightedRoundRobin

为了处理这种设置，您需要查看一个真正的负载平衡解决方案。阅读Linux虚拟服务器和HAProxy。如果服务器发生故障并且会更容易理解，则可以自动将服务器从池中删除，从而获得额外的好处。加权只是要调整的设置。