是否可以仅在请求开始时使用负载均衡器?

是否可以仅在请求开始时使用负载均衡器?

假设客户端请求一个页面www.example.com/index.html。DNS 会将其转换为203.0.113.15/index.html

然后,该服务器作为负载均衡器(假设是 Apache mod_proxy_balancer),将请求重定向到另一个 IP(不在同一个本地网络中)198.51.100.5

这个想法是这样的:

client ==> example.com ==> DNS ==> 203.0.113.15 (Load Balancer) => 198.51.100.5 (destination server)

一旦客户端和目的地之间建立了链接, 如何避免客户端和目的地之间的进一步通信198.51.100.5需要经过中间服务器203.0.113.15

更准确地说:一旦负载均衡服务器 (203.0.113.15) 允许客户端和目标服务器 198.51.100.5 “见面”/“相互了解”,那么:

  • 它们之间的进一步通信(上传/下载,可能是兆字节或千兆字节!)不再通过 203.0.113.15 传输(为了节省负载均衡器的带宽)
  • 所有这些example.com仍然显示在他的浏览器中

如何配置这个mod_proxy_balancer

答案1

关于连接server -> client:这是可能的,并且是主要特点,Linux 虚拟服务器项目, 哪个

是建立在真实服务器集群之上的高度可扩展和高可用性服务器,负载均衡器运行在 Linux 操作系统上。服务器集群的架构对最终用户完全透明,用户交互时就像是一台高性能虚拟服务器。

我已在这个答案

答案2

不,这是不可能的,因为根据定义,请求发生在会话内,而该会话绑定到 TCP 流,而 TCP 流本身又绑定到 IP 地址。您要求的是更改绑定的 IP 地址,这会中断连接。

但这是一个坚定的“不”答案,仅仅是因为你如何提出问题,因为你所问的问题表明了你对网络层面的网络浏览工作原理的理解不够。

有很多方法可以实现类似的效果。直接服务器返回允许服务器返回结果,而无需将结果通过负载均衡器。这对 Web 服务器来说非常高效,因为只有入站流量需要通过负载均衡器。出站流量可以直接发送。由于 Web 流量通常请求量较小,但结果量较大,因此这种模型允许相对较小的负载均衡器处理相对较大的网站。

大多数负载均衡器在网络堆栈的高层工作,处理高级 HTTP 流。但这并不是必需的,因此您可以选择在第 2 层或第 3 层工作的较低级别的负载均衡器来平衡 IP 之间的流量,这些流量可由多个服务器直接处理。在此模型中,每个服务器实际上都是自己的负载均衡器,因此根本没有中间人专用的负载均衡器来处理流量。

没有必要只保留一个会话。您可以登录到一台负载平衡服务器,并向客户端传递一个加载内容或重定向到另一台服务器(或负载平衡服务器组)的页面。特别是,如果您正确使用 IFrame,不同框架的内容看起来就像来自一台服务器一样。同样,您可以使用针对多种角色进行优化的多个系统。通常,这被设置为内容分发网络,其中较少数量的服务器处理动态内容,而通常较多的分布式服务器处理静态内容。

这个问题有多种解决方案。一般来说,你会想要研究扩展 Web 场的选项。但你的问题是有缺陷的,因为负载平衡器服务器永远不会允许客户端和目标服务器“相遇”/“相互了解”。从客户端的角度来看,只有一台服务器,客户端永远不会知道负载平衡器背后的基础设施。

答案3

听起来你想让 LB 跟踪一组服务器,并将客户端重定向到正在响应的服务器。

我可能会这样做,当纽约市离线时,通常使用我的纽约服务器的全球用户将被发送到澳大利亚墨尔本的备份服务器。

但并非所有流量都必须经过 LB。

这个想法太棒了!我认为你无法使用 mod_proxy_balancer 模块来实现这一点。你需要的是一个选项,用于向客户端发送 302 REDIRECT 作为“平衡操作”。

您两年前就问过这个问题,我猜您现在不会再寻找答案了。不过,您引起了我的好奇心,所以您介意让我们都知道您做了什么吗?

如果你仍在寻找答案,我很乐意进一步讨论您的需求并提出一些想法。

谢谢!Mike

答案4

根据您的示例,我认为您希望在 http/https 上执行此操作,因此我的答案将基于此。在我看来,您正在寻找负载平衡器上的粘性会话。这可以轻松完成。尽管它会发生在 L7,而不是 L4(我们通常在那里看到负载均衡器)。

这是我们公司所采用的方法的理论(也是 AWS 如何在其托管负载均衡器上创建粘性会话)。

  1. 当请求到达时,检查它是否具有 的唯一 cookie session。可以是 之类的routeid
  2. 如果该 cookie 不存在,请添加该 cookie,并将其值作为后端路由的名称。
  3. 如果该 cookie 已经存在,则使用该 cookie 来确定将您的请求发送到何处。

在自动缩放系统中,您还需要处理后端不再存在的情况。 Apache 的配置示例如下:

http://docs.motechproject.org/en/latest/deployment/sticky_session_apache.html#method-2-using-additional-session-cookie

相关内容