介绍
??ipvs 是内核中的一个模块,工作在四层(传输层),正因如此,它并不理解上层包中的内容是什么,只负责转发,所以它不会像Nginx、Haproxy那样可以实现根据 url实现负载均衡。因为ipvs工作在内核,所以性能会比后面二者高一些。
??ipvs 模块主要监控在input链上,当请求经过 PREROUTING 链,到达INPUT 链时,ipvs 会检查一下该报文的 IP + Port,看看是不是来访问LVS所管辖的服务,如果是,则直接转发到 FORWARD 链,然后到达后面提供服务的服务器(Real Server),后面的多台RS如何选择,选择哪个就是LVS中算法控制的。根据相应的负载均衡算法来选择RS。
NAT 模式
??NAT(Network Address Translation,网络地址转换),这种模式比较简单,因为只需要设置一下iptables规则即可。他的流程是这样的:
当请求到达director(负载均衡器)时,director会根据算法选择一台RS,然后通过网络地址转换的方法,将报文转发到这台RS,RS将报文处理后,先发送给director,然后再由director将应答返回给客户端。因为是使用NAT模式,director和 RS们分别处在2 、3层,因此RS的网关必须指向director,这就出现了一个问题,就是来回的报文都必须要经过director,随着RS的增多,性能会大大降低,director会成为瓶颈。但是NAT模式的RS不管是什么操作系统的主机,只要能提供服务,能收到报文可提供服务。
DR 模式
??由于NAT模式来回都要经过director,所以说性能特别的低,为了解决这个问题,出现了DR模式。
??DR(Director Routing,直接路由模式)这种模式在RS收到报文时,处理后直接返回给客户端,而不需要经过director的转发,性能大大提升。DR模式过程大致是这样的:
??客户端请求到达director时,director会根据算法将该请求的目的MAC地址改为对于RS的MAC,然后来一个ARP广播,但是后端的RS收到director的ARP,发现这个包上面的IP地址并不是我的,于是会不理这个ARP。为了解决这个问题,就必须在每个RS上配置一个VIP,那么问题又来了,如果每个RS都配置相同的VIP,就是导致ARP记录不唯一(MAC地址和IP地址不是一一对应),当客户端发请求到VIP时,RS上都配有VIP,到底哪个RS接收?如果都接收,那么director将起不到相应作用,会不会冲突?为了解决这些问题,就必须要抑制ARP,用户发来的报文,到达director时,让RS的VIP不做任何应答。这样就解决了多个VIP的问题。RS收到报文,处理后直接返回给后端。
??DR模式虽然性能高,缺点当然也有,因为请求到达director时候,由于director向RS转发需要通过MAC,数据链路层,因此就必须将director和RS放在同一局域网内。
TUN 模式
??DR模式的性能已经特别高,为何还会出现一个TUN模式呢?TUN模式的出现与性能无关,与场景有关。如果多台real server不在一个局域网呢,一个在北京,一个在上海,怎么让他们提供业务呢?于是就出现了TUN模式。
??大部分隧道都是是在报文上做手脚,TUN实现的方式就是当客户端请求到达director时候,将报文再次增加一层报头,该报头根据预先设定的负载均衡算法选择一台机器,然后将报头指向这台主机,目的就是将报文引领到远程的RS上,当报文到达RS时,由于和正常的报文不一样,默认会以错误的报文将其丢弃,因此就必须要让RS端也能明白这层报头的含义,所以说director和后面的RS必须得支持TUN隧道的协议,做额外的配置才可以。
原文地址:https://www.cnblogs.com/sugare/p/12566215.html