马哥 36_02 _Linux集群系列之二——LVS类型详解 有大用

对外提供的地址就是前端负载均衡器的ip地址

负载均衡器设备:

    硬件(Hardware): 代价高,通常几十万, 硬件当然也要通过软件来实现 (要买两台)

            F5,BIG IP    几十万,上百万

            Citrix(思捷), Netscaler

            A10   

    软件(Software):

           四层:(TCP/IP协议的第四层)(只理解解析四层协议,对于七层应用层当中是什么内容,它不做任何处理,由于不解析高层协议 ,所以工作性能更好,但是所支持的高级特性没有 比如对 http的 url 负载均衡,LVS是不具备这种能力的)

                LVS: (Linux Virtual Server: Linux虚拟服务器)(可以理解成四层交换设备,四层路由设备)可以根据用户请求的ip和端口来实现将用户的请求分发至一个后端不同的主机,作者为中国人,张文松(淘宝的副总裁)跳到滴滴了

           七层:(TCP/IP协议的第七层,应用层协议,七层代理)(一般叫做反向代理)(是为某些特定协议提供的,因此能精确解码解剖对应的协议,而且它能够在对应的协议的基础上做一定的修改之后向后做负载均衡的,所以在前端就能够做一定的处理,因此它的操作能力更强,但是它的性能可能略逊于四层设备,在某些特定的场景下,七层所实现的功能加特性一起,可能更符合生产环境的需要)      

                 nginx:俄罗斯人,http,smtp,pop3,imap等做负载均衡的,只负责有限的七层协议

                 haproxy:主要是http,还能对 tcp(mysql,smtp)做负载均衡

LVS,nginx,haproxy,都是开源的,安装在linux上,通过硬件及其服务负责调优之后,将它们做成一个负载均衡设备

LVS(四层交换设备 四层路由设备)(能够识别用户请求的ip地址和端口号)

LVS: Linux Virtual Server,它本身是一个负载均衡设备(调度器 分发器)(director )(dispatch ),本身不提供任何服务,用户请求时,将请求转发至后端真正提供服务的服务器(real server),

这里定义了集群服务 Cluster server 只有172.16.100.1:80 才会向后转发

如果请求的是172.16.100.1:22,就不会转发,就是调度器自身

LVS:本身是工作在内核上(TCP/IP协议栈上)的,(先到内核空间,再到用户空间)如果用户请求已经到达了用户空间,就无法向后转发了,所以LVS依然借鉴了Netfilter的框架,

LVS依然借鉴了Netfilter的框架,它工作在input链上

LVS监控在input链上,设置了有规则,一旦发现用户请求的是集群服务,它会强行的修改用户数据报文的行程,把请求报文送往forward链,通过forward链,经由 postrouting 转发至其它主机,

它有点反常于iptables的机制了,所以iptables与LVS不能同时使用

iptables两段式工具

iptables/netfilter: 前端写规则的叫 iptables,真正工作在netfilter上,在netfilter上生效,(netfilter是一个框架)

LVS也是两段式工具   必须要把某一种服务定义成集群服务以后,才能生效,而且是以规则的方式来进行检查的

    ipvsadm  (ip virtual service admin)      管理工具,用户空间定义管理集群服务的命令行工具

    ipvs    (ip virtual service)工作在内核上的,并且监控在input链上的框架

ipvsadmin写一堆规则,送给ipvs,ipvs结合了input钩子,请求到input链的时候,ipvs进行判断是不是访问的集群服务器的ip和端口,如果是进行转发至forward钩了,再送至postrouting,再向外发送

lvs必须有一段工作在内核中才能发挥作用

linux 2.4.23 之前,lvs没有被吸引进内核,所以要使用lvs,要向内核打补丁,要编译安装内核,编译安装ipvsadm

linux 2.4.23 和linux 2.6.2以后的版本的内核上,直接内置了ipvs代码,,,如果再安装了ipvsadm 就能够工作为一个负载均衡的调度器了

schedule method 调度方法(调度算法);就是一个挑算一个后端服务器接受一个新请求的计算标准(计算机制)

lvs只对定义了集群服务的服务向后台转发及转发到何处,非集群服务它是不转发的;一个服务的标准通常都是一个套接字,意味着地址+端口;;;;这叫做四层交换(四层路由)

一个调度器可以为多种集群服务的提供调度功能的,为什么要进行负载均衡集群,就是因为一台服务器的性能有限,所以通常情况下,一个调度器只为一个服务提供集群能力(调度功能)

调度器(director)应该有两个地址,第一个是面向外部的,第二个与real server进行通信的

VIP:virtual IP,虚拟IP,是这么称呼,但并不是虚拟ip,在调度器上它是向外提供服务的

RIP:后台主机的ip就是RIP(RS IP)(real server ip)

DIP:调度器上,与real server通信的IP,DIP(Director ip)

CIP:前端客户端,请求时,它也有IP,  CIP(client IP)

LVS分为多种不同的类型 (根据与后端real server通信方式的不同,或整个集群组织架构的不同,以及 real server所配置的地址的不同)

1) LVS_NAT:(network address translation) 地址转换(类似于iptables的目标地址转换DNAT)

            与DNAT不一样的地方,它是多目标,工作机制与DNAT一样,用户所请求的路线?

            只不过不需要写DNAT规则,而是写ipvs的规则

            用户请求的进出请求都得经过 director(调度器)(分发器),,,理想情况下,director 能带动real server 10个(差强人意),多了就不行了

            应该像DNAT一样,可以进行端口映射的, 

            我们在ipvsadmin中需要写个规则,告诉它(director?),是工作在NAT模式下,就会以这个结构来工作,

            在NAT模型下(框架当中),一般它有这样几项要求

                       1) director和所有real server 必须要在同一个网络中,每一个 real server的网关要指向DIP,不然的话 real server 出去的报文无法经过 director,那么无法用director修改源地址(请求响应出去的时候 把源地址邮 rip 改成  vip)

                       2) rip地址只能是私有地址,仅能与各集群节点之间通信(当然包括dip)

                       3) director 位于 client与 real server 之间,并负责处理所有的通信(包括进来的和出去的)

                       4) 集群节点(real server)使用DIP作为默认网关(因为响应要从dip返回出去)

                       5) 支持端口映射

                       6) 任何类型的操作系统都可用于 real server 上  ,,,,只要director 自身是linux就可以了(因为它需要装LVS)

                       7) 较大规模应用场景中,单个的director很有可能成为集群的瓶颈  

TCP/IP报文的 源地址/目标地址,,,请求过程中 会改变 

进来时:     源ip/目标ip=CIP/VIP    经过director  源ip/目标ip=DIP/RIP

出去时:     源ip/目标ip=RIP/DIP    经过director   源ip/目标ip=VIP/CIP

将来实际应用中,哪怕只有三五个 real server,一般也不会使用 nat 模型的,一般都使用dr模型

2)LVS-DR:directory routing 直接路由

        用户请求时,通过交换机,到达 director, director根据某种挑选标准,挑选出一个real server,并把请求转发给这个 real server, real server的响应报文不经过 director,直接通过交换机,响应给客户端

         real server的 VIP地址不拿来接受用户的任何请求,VIP地址是配置在网卡别名上,并且是隐藏的,(所以在整个网络上,广播一下,问问谁是VIP,没有人回答的,他们也不会认为自己有VIP地址),VIP地址不做跟任何人通信用,只有在响应客户端请求的时候,把它作为源地址使用,虽然响应的时候作为源地址使用,但是真正出去的网卡仍然是rip的网址,真正通信的仍然是rip (real server ip )的ip地址

       director和real server 上都有两个IP,

            director的 (DIP ,VIP),反正一个配置在网卡,另一个配置在网卡别名上;;马哥说的不清晰

            real server (RIP,VIP),马哥说的清清楚楚,RIP (real server ip ) 配置在网卡,VIP配置在网卡别名上;

                    TCP/IP报文的 源地址/目标地址,,,请求过程中 永远不会改变 请求进来时: 源ip/目标ip=CIP/VIP  请求出去时: 源ip/目标ip=VIP/CIP

        外面请求过来的时候,路由器如何把报文发给director?(本地网络情况下,两个设备真正通信靠的是物理层的mac地址,所以根据ARP协议,把vip转换成mac,,这是通过广播的方式),,,,,,路由器根据VIP地址找到director (此时 real server 上的vip是千万不能响应的) 路由器转发报文的时候,只有director上的vip响应,,,,,所以来自CIP的请求最终都交给 director 了,directory 怎么发给 real server? director 转发报文给 各 real server时是不会改目标地址的,仅仅是修改了mac地址(director 有自己的dip, real server有自己rip,它们本身是在同一个物理网络上,同一个交换机上,所以dip,rip1,rip2,rip3是可以互相通信,而且能通过arp解析得到各自的mac地址,,,,,,,)用户请求到达 director时,发现是集群服务,它是不会拆ip首部的,只会拆mac首部,重新封装mac首部,此时 源mac 变成 director自己的dmac (directory mac),目标mac变成它所挑选的那个real server的rmac (real server mac) ,,,,,假设rip2 收到了转发的请求报文,看到报文的目标mac是自己的,就认为这个报文是到达自己主机的,它拆掉了mac地址(帧封装)以后,看到里面的目标ip是VIP(自己主机上有VIP),所以同样认为是到达自己主机的报文,,,,,发现自己的确有客户端请求的服务,服务响应以后要封装响应报文,(人家请求的是VIP,所以要用VIP去响应)(所以它封装了源地址是VIP,目标地址是CIP),就这样直接响应出去了,,,,,,也就意味着,它不用把网关指向director的DIP了(假如网关指向了director的DIP,,那出去的报文还是从director出去,这就违背了DR给director减负的初衷了),

所以这样的场景当中,director仅负责处理入站请求,对响应的报文不作任何处理,所以director就大大的解脱了,(因为请求报文都很小,响应报文都很大,,所以性能会提高n倍)    (所以一般说来NAT模型能带动10个 real server,DR模型能带动100个 real server);;;;;所以在生产环境中,我们一旦用到LVS,直接上DR

        DR模型应遵循的基本法则:

                1) 各集群节点必须要跟director在同一物理网络中(因为要根据mac地址转发)(里面只有交换机把它们连起来) (还不能使用路由设备去相互连接,因为两个路由会跨物理网络)

                2) RIP ( real server ip )地址可以不用是私有IP了(可以是公网地址,将来一旦 director 坏了,直接访问 rip ,照样可以获得服务,,还可以直接通过互联网联进来,进行便捷的管理和监控),,,,,当然也可以是私网地址

                3)director只负责处理入站请求,响应报文由real server 直接发往客户端

                4)集群节点一定不能使用director当作它们的默认网关,因为 real server  的响应直接出去,不经过director,(real server不能将网关指向DIP,而是直接使用前端网关)

                5)director不支持端口映射  (因为响应报文直接由 real server 响应, 客户端请求的是(80) 你要映射到一个不同的端口(8080),我们客户端没有请求你这个端口(8080),客户端不会接受这个8080端口的响应) (再说了,人家客户端请求的是80,你80上没有服务,就8080提供服务,你当然不会响应人家客户端) (nat可以,因为nat的director负责出站和入站的tcp/ip的地址和端口转换) (这边DR的 director 其实对源地址,源端口,目标地址,目标地址,都没有改变,所以请求啥端口,real server 必须工作在哪个端口上,所以无法实现端口映射)

                6)大多数的操作系统都可以用到 real server 上,(不是所有?因为我们的 real server 要求隐藏VIP,有些操作系统不支持隐藏?)

                7)DR能够比NAT带动多得多的real server

3)LVS-TUN:tunneling 隧道

            隧道的工作机制与 DR 一样,(但是各个real server 在天南海北,不在同一个物理网络)只不过在转发的时候,它需要重新封装IP报文(不是mac地址)    用户请求的时候,到director的VIP上,它跟DR模型一样,每个real server既有 RIP(肯定必须是公网IP,因为各个real server在天南海北,),又有VIP,,,,,当用户请求到达 director的时候,director选择一个 real server (RIP)进行响应,,,但是director的DIP与各 real server 并不在同一个网络上;;;因为与DR一样,各 real server 是直接响应给客户端的,也就是real server 必须以VIP作为源地址, (real server 必须要有VIP地址,VIP地址同样是隐藏的);;;;;互联网上,我们还得确保用户请求的时候请求的 VIP 到达director主机, 所以  各个real server 的 VIP在互联网上是不可见的,所以director转发的时不能以VIP作为目的地址转发,它们因为天南海北,所以不能通过mac地址进行通信

当报文到达 director 的时候, director 要转发,记住 IP首部 源ip/目标ip ( CIP/VIP )不能动,,,,,假如转发到 RIP2, 报文首部不动,再在IP报文的外面加上IP首部 源ip/目标ip ( DIP/RIP2 ),这样子就两个ip首部,,,,ip为 RIP2 的real server 收到报文后,先拆掉第一层封装  源ip/目标ip ( DIP/RIP2 ),,,发现里面还有个封装 源ip/目标ip ( CIP/VIP )  ,,,,,,,这个用IP报文发送另外一个IP报文,这就是隧道(借助于一个ip报文,发送另外一个ip报文);;;RIP2 节点拆掉第一层封装后,看到了 源ip/目标ip ( CIP/VIP ) ,创建响应报文  源ip/目标ip ( VIP /CIP ) ,,这样就可以 不用经过director 直接发出响应报文了        所以要求director和 real server 必须支持隧道机制,,,(用特殊的连接???去封装另外一个ip报文)

    TUN模型特点:

        1)各集群节点没必要在同一个物理网络中,可以跨超Internet

        2)real server 的 rip 必须得是公网地址,它必须要能够借助于互联网通信的,必须能通过将用户的请求从一个网络发送到另一个网络(从director到rip,,以及从 real server到 客户端cip),,,(现实实际生产过程中必须的,做实验当然可以不是这样子的)

        3)director只负责处理入站请求,响应报文由real server 直接发往客户端

        4)响应报文一定不能通过 director,,,,因为DR也不能通过director,,,TUN与DR的原理是一样,,只是real server与director不在同一个物理网络而已

        5)只有支持隧道功能的OS才能用于 real server

        6)不支持端口映射

NAT最简单 ,DR最常用,TUN用得很少很少