江苏龙网

  1. 主页 > 生活百科 > >

全面分析:Web基础架构负载均衡LVS机制的原理( 三 )

架构

 
源地址
目的地址
CIP
VIP
 

  1. IPVS比对数据包请求的服务是否为集群服务 ， 若是 ， 修改数据包的目标IP地址为后端服务器IP ，  此时报文的源IP为CIP ， 目标IP为RIP；RS接收到包以后 ， 仿佛是客户端直接发给它的一样 。
 
源地址
目的地址
CIP
RIP
 
  1. RS比对发现目标为自己的IP ， 将请求处理完 ， 返回响应时 ， 此时报文的源IP为RIP ， 目标IP为CIP；
 
源地址
目的地址
RIP
CIP
 
  1. 返回时RS的包通过网关（LVS）中转 ， LVS 会做源地址转换（SNAT） ， 将包的源地址改为VIP ， 这样 ， 这个包对客户端看起来就仿佛是LVS直接返回给它的 。此时会将源IP地址修改为自己的VIP地址 ， 然后响应给客户端 ， 此时报文的源IP为VIP ， 目标IP为CIP；
 
客户端无法感知到后端RS 的存在
源地址
目的地址
VIP
CIP
要点
客户端是不知道真是RS地址的 ， 但是RS服务器却是可以知道ClientIP的（因为数据包中会包含了ClientIP） ， 但是由于中介LVS的原因 ， 使得发送的时候发给VIP（LVS） ， 返回的时候 ， 由LVS把源地址修改为VIP ， 所以对于客户端不能来讲是不知道目标地址的RS的存在 。这就是反向代理的概念 ， 客户端是不知道真正服务器的存在 ， 知道的只有门面VIP的存在 。
特性
  1. 要求DS具备双网卡 ， VIP应对公网 ， 而DIP必须和RIP在同一个网段内；
  2. RIP、DIP应该使用私网地址 ， 同在一个网段中 ， 且RS的网关要指向DIP；
  3. 请求和响应报文都要经由DS转发 ， 极高负载中 ， DS可能会成为系统瓶颈；
  4. RS可以使用任意OS；
TUN 
在原有的IP报文外再次封装多一层IP首部 ， 内部IP首部(源地址为CIP ， 目标IIP为VIP) ， 外层IP首部(源地址为DIP ， 目标IP为RIP) 。
流程分析
  1. 当用户请求到达DS后 ， 此时请求的数据报文会先到内核空间的PREROUTING链 ， 此时报文的源IP为CIP ， 目标IP为VIP；
 
源地址
目的地址
CIP
VIP
 
  1. PREROUTING检查发现数据包的目标IP是本机 ， 将数据包送至INPUT链；
  2. IPVS比对数据包请求的服务是否为集群服务 ， 若是 ， 在请求报文的首部再次封装一层IP报文 ， 封装源IP为为DIP ， 目标IP为RIP 。然后发至POSTROUTING链 。此时源IP为DIP ， 目标IP为RIP；
 
IP首部源地址
IP首部目的地址
源地址
目的地址
DIP
RIP
CIP
VIP
 
  1. POSTROUTING链根据最新封装的IP报文 ， 将数据包发至RS（因为在外层封装多了一层IP首部 ， 所以可以理解为此时通过隧道传输） ， 此时源IP为DIP ， 目标IP为RIP；
  2. RS接收到报文后发现是自己的IP地址 ， 就将报文接收下来 ， 拆除掉最外层的IP后 ， 会发现里面还有一层IP首部 ， 而且目标是自己的tun0接口VIP ， 那么此时RS开始处理此请求 ， 处理完成之后 ， 通过tun0接口送出去向外传递 ， 此时的源IP地址为VIP ， 目标IP为CIP；
 
源地址
目的地址
VIP
CIP
 
  1. 响应报文最终送达至客户端；
特性 
1、DIP、VIP、RIP都应该是公网地址；
2、RS的网关不能 ， 也不可能指向DIP；
3、RS必须支持IP隧道；
Full-NAT
无论是 DR 还是 NAT 模式 ， 不可避免的都有一个问题：LVS 和 RS 必须在同一个 vlan 下 ，  否则 LVS 无法作为 RS 的网关 。
 
这引发的两个问题是：
 
  1. 同一个VLAN的限制导致运维不方便 ， 跨VLAN的RS无法接入
  2. LVS的水平扩展受到制约 。当RS水平扩容时 ， 总有一天其上的单点LVS会成为瓶颈


    推荐阅读


上一篇：一个接口优雅的实现 Spring Cloud OAuth2 自定义token返回格式

下一篇：人们在用 WebAssembly 构建什么应用？