负载均衡——三角传输

  • ​三角指的是哪三个东西?

    1.客户端     2.AD负载均衡    3.服务器

  • 应用场景:

     客户端需要在服务器看到真实IP且服务器网关不能指向负载均衡设备

  • 以下是正常环境下的数据流向示范,以单臂旁路方式进行举例,:

假设客户端的IP和端口为 172.16.0.1:8000,负载均衡设备的虚拟IP(VIP)为 10.0.0.1:80,设备自身的NSIP为10.0.0.100,服务器 10.0.0.2:80的默认网关指向3层交换机的接口地址10.0.0.254。

由上图可以看出,当客户端请求通过三层交换机到达负载均衡设备虚IP 10.0.0.1:80时,负载均衡设备将会对请求中的目标IP 10.0.0.1:80转换为 10.0.0.2:80,并将请求发送给服务器。此时请求中的IP仍然为客户端IP 172.16.0.1:8000,这样服务器收到请求后查看到请求中的源IP为客户端,这样将会应答直接从默认网关10.0.0.254发出,发回客户端。

至此会发生什么问题呢?
客户端发送的请求中源IP为自身,目的IP为负载均衡器上的虚拟IP

但是客户端通过三层交换机默认网关接收到的应答中,源IP为真实服务器IP,目标IP为客户端,这样客户端与服务器是无法建立通信的。

为了解决这个问题,此时有两种方法:

  1. 将服务器的默认网关配置为负载均衡器的接口地址

  2. 在负载均衡器分发请求的过程中改变请求包中的源IP,此方法也成为SNAT(Source Network Address Translation,源网络地址转换)

以上两种方法互斥,两者选其一

以下按照第2种方法进行举例,如图所示:

由于负载均衡器配置了SNAT,在接收到请求包时,会将源IP改为自己的NSIP  10.0.0.100,这样在客户端接收到请求包后,会将应答包返回给负载均衡器,然后负载均衡器再次对应答包中的源IP进行修改,修改为自身的虚拟IP(VIP)10.0.0.1,再将应答包返回给客户端。这个过程最后就是:


客户端发出的请求中:源IP为172.16.0.1,目标IP为10.0.0.1(负载均衡设备上的虚拟VIP)

客户端接收到的应答中:源IP为虚拟VIP 10.0.0.1,目标IP为172.16.0.1

这样双方就可以建立通信

但是我们会发现请求包与应答包都需要从负载均衡器进行转发,有什么办法可以提高传输效率呢?会不会有一种让请求经过负载均衡器,而服务的响应无须从负载均衡器原路返回的工作模式呢?有啊,上面的第一张图,如图!

整个请求、转发、响应的链路形成一个“三角关系”

不对,上面不是已经分析过了吗,这种模式由于请求包与应答包中的源IP和目的IP对不上号,所以无法建立通信,为什么这里又要搬出来呢?

唯一的区别在于,服务器在发送响应客户端的请求的应答的时候,源IP采用的是10.0.0.1,而非第一张图中的自己的接口ip10.0.0.2。这个时候,客户端收到的应答,源ip就成了10.0.0.1:80,目标IP为172.16.0.1:8000,所以连接成功建立。这种成功建立的方式,像一个三角形,所以称为三角传输。

总结一下,就是在服务器上配置Loopback的IP为负载均衡器上的虚拟IP(VIP)同时负载均衡设备在转发请求的时候不改变请求的源和目标IP,这样应答包中的源IP就是请求包中的目的IP  

  • 2
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

无敌菜小包包

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值