负载均衡器会泛滥吗？

Question

我正在阅读有关负载平衡的信息。

我理解负载均衡器在任何给定应用程序的多个从属服务器之间传输负载的想法。然而，我能找到的文献中很少有文献说明当负载均衡器本身开始与大量请求作斗争时会发生什么，以至于负载均衡（在奴隶之间分配请求）的“简单”任务变得不可能完成。< / p>

以这张照片为例，您可以看到3个负载均衡器（LB）和一些从属服务器。

图1：客户端知道他们连接的一个IP，一个负载均衡器在IP之后，并且必须处理所有这些请求，因此第一个负载均衡器是瓶颈（和互联网连接）。

当第一台负载均衡器开始挣扎时会发生什么？如果我将新的负载均衡器添加到第一个负载均衡器，我必须添加另一个，以便客户端只需要知道一个IP。所以困境继续：我仍然只有一个负载均衡器接收我的所有请求......！

图2：我添加了一个负载均衡器，但是为了让客户端只知道一个IP，我必须添加另一个来集中传入的连接，从而最终产生相同的瓶颈。

此外，我的互联网连接也将达到其可以处理的客户端的限制，因此我可能希望将我的负载平衡器放在远程位置以避免充斥我的互联网连接。但是，如果我分发我的负载均衡器，并希望让我的客户只知道他们必须连接的一个IP，我仍然需要在该IP后面有一个中央负载均衡器，再次承载所有流量......

Google和Facebook等现实世界公司如何处理这些问题？这可以在不给客户端多个IP的情况下完成，并期望他们随机选择一个IP，避免每个客户端连接到同一负载均衡器，从而充斥我们吗？

Answer 1

您的问题听起来并不适合AWS，因此这是一个通用的答案（AWS中的弹性LB根据流量自动缩放）：

你是对的，你可以用进入的请求数来压倒负载均衡器。如果你在标准的构建机器上部署LB，你可能会首先耗尽/超载网络堆栈，包括最大值打开的连接数和传入连接的处理速率。

作为第一步，您将微调LB机器的网络堆栈。如果仍然无法满足您所需的吞吐量，市场上就会出现专用负载均衡器设备，这些设备经过全面构建并经过高度优化，可处理大量传入连接并将其路由到多个服务器。这些例子是F5和netscaler

您还可以设计应用程序，以帮助您将流量分配到不同的子域，从而减少1 LB必须处理的请求数。

也可以实现一个round-robin DNS，你可以在几个面向客户的LB上有一个DNS入口点，而不是你所描绘的一个。

Answer 2

由于您标记了亚马逊，因此他们在系统中内置了负载均衡器，因此您不需要这样做。只需使用ELB，亚马逊就会将流量引导到正确的系统。

如果您自己这样做，负载平衡器通常具有非常轻的处理负载。它们通常只是根据对数据的浅层检查（或不检查）将连接从一台机器重定向到另一台机器。它们可能会被淹没，但通常需要一个会使大多数连接饱和的负载。

如果您自己运行它，并且如果您的负载均衡器正在做更多工作或者您的连接已经饱和，则下一步是使用Round-Robin DNS来查找负载均衡器，通常使用NS的组合和CNAME记录所以不同的名称查找给出不同的IP地址。

Answer 3

像Netscaler等类似的高级负载均衡器也使用DNS进行GSLB而不是简单的DNS-RR（以解释进一步的扩展）

如果要连接到甚至service.domain.com，则让负载均衡器成为区域的Authorative DNS，并将所有负载均衡器添加为有效名称服务器。

当客户查找＆＃34; service.domain.com＆＃34;您的任何负载均衡器都将回答DNS请求，并使用您客户端的正确数据中心的IP进行回复。然后，您可以根据客户端的地理位置，客户端DNS服务器和netscaler之间的延迟，在DNS请求上进一步进行负载均衡器回复，或者您可以根据不同的数据中心负载进行回答。

在每个数据中心中，您通常在群集中设置一个节点或多个节点。您可以使用这样的设计进行相当高的扩展。

Answer 4

如果您打算使用amazon elastic load balancer，则声称

  

Elastic Load Balancing 会自动扩展其请求处理   满足应用流量需求的能力。另外，   Elastic Load Balancing提供与Auto Scaling的集成以确保   您拥有后端容量满足不同级别的流量   水平而无需人工干预。

所以你可以使用它们，而不需要使用你自己的实例/产品来处理Load Balancer