【Cluster】02、LVS基础

uyfrjk

　　

　　

　　一、LVS简介

1、LVS
　　LVS：Linux Virtual Server
　　作者：章文嵩
　　也被称作layer4 router/layer4 switch
　　根据目标地址和端口作出转发与否决策，根据调度方法作出转发至哪一个后端服务器的决策
　　

　　2、组成部分
　　ipvs/ipvsadm
　　ipvs：
　　   是框架，需要依赖于规则；工作于内核中，是真正实现将用户请求转发功能的组件，ipvs工作于netfilter的INPUT链接，
　　ipvs打破了netfilter的工作模式，所以ipvs和netfilter的过滤功能不应该同时使用

　　

　　ipvsadm：
　　用于在ipvs上定义集群服务，同时也得定义此集群服务对应于有哪些后端主机可用
　　

　　支持协议：TCP，UDP，SCTP，AH，ESP，AH_ESP
　　

3、LVS中的常用术语约定
　　Host:
　　Director：调度器
　　Real Server：RS，后端正在提供服务的的主机
　　IP：

　　Client：CIP，用户的ip
　　Directory Virtual IP：VIP；调度器上对外向客户公布的IP，可以转移
   Real IP：RIP；后端真正提供服务的主机通信的ip
　　Directory IP：DIP；调度器上与RIP通信的ip
二、LVS的类型
　　NAT：相当于多目标的iptables的DNAT
　　DR：direct routing
　　TUN：tunneling
　　FULLNAT：fullnat
　　原生不支持，需要向内核打补丁，重新编译
　　

　　1、NAT类型
　　架构：

　　在一组RS前有一个Director，它们通过Swith相连接，这些RS提供相同的网络服务、相同的内容，即不管请求被发送到哪一台RS，执行结果都一样。服务的内容可以复制到每台服务器的本地硬盘上，也可以通过文件系统（如NFS）共享，也可以通过一个分布式文件系统来提供

　　

　　工作原理：类似于iptables的DNAT，但支持多目标转发
　　用户通过VIP访问网络服务时，请求报文达到Director，Director根据调度方法（算法）从一组RS中选出一台服务器，将请求报文的目标地址改写成选定RIP，目标端口改写成选定RS的相应端口，当来自RS的响应报文经过Direcctor时，调度器将报文的源地址和源端口改为VIP和相应的端口，再把报文发给用户。
架构特性：

　　1）RRIP应该为私有地址，各RS的网关必须指向DIP
　　2）请求和响应报文都经由Director转发，高负载场景中，Director易成为系统瓶颈
　　3）支持端口映射
　　4）RS可使用任意类型OS
　　5）RS的RIP必须与DIP在同一网络
　　6）服务器集群的结构对用户而言是透明的，用户所看到的只是在Director上提供服务
　　

　　NAT类型适用于并发不是特别高场景中，RS 10台以内


　　2、DR类型 （Direct Routing）
　　直接路由，通过MAC地址转发
　　大多数Internet服务都有这样的特性：请求报文较短而响应报文往往包含大量的数据。
　　如果能将请求和响应分开处理，即Director只负责调度请求，而响应直接返回给客户，这将极大第提高整个集群系统的吞吐量。
　　架构：

　　工作原理

　　Director在实现转发时不修改请求报文IP首部，而是通过直接封装MAC首部完成转发。目标MAC是Director根据调度算法选定的RS的MAC地址


架构特性：
　　1）VIP被Director和RS组共享
　　2）让前端路由将请求发往VIP时，只能发往Director上的VIP
　　解决方案：
　　静态绑定：在前端路由直接将VIP对应的目标MAC地址静态配置为Director的MAC地址              此方法不实用：
　　未必有路由器的配置权限
　　Director调用时静态地址绑定将难以适用
　　arptables：在各RS上，通过arptables规则拒绝其响应VIP的ARP广播请求（不常用）
　　内核参数：在各RS上修改内核参数，并结合地址的配置方式实现拒绝响应VIP的ARP广播请求（将RS上的VIP配置为lo接口的别名，限制linux仅对对应接口响应）
　　3）RS的RIP可以使用私有IP，此时也可以使用公网IP，此时可以通过互联网直接对此RS发起管理操作

　　4）Director只负责调度请求报文，而响应报文直接返回给用户，请求报文必须经由Director调度，但响应报文必须不经过Director调度
　　   5）各RIP必须DIP在同一物理网段中（不能有路由器分隔，广播报文要能到达），最好在同一网络中
　　6）不支持端口映射
　　7）RS可以使用大多数的OS
　　8）RS的网关一定不能指向Director
　　3、lvs-tun类型

　　扩展的dr类型，跨互联网

　　工作原理：

　　不修改请求报文IP首部，而是通过IP隧道机制在原有的IP报文之外再封装IP首部，经由互联网把请求报文转发给选定的RS
　　

　　内层IP首部CIP,VIP

　　外层IIP首部DIP,RIP
　　

　　架构特性：
　　1）RIP,DIP（可以不是）,VIP都必须是公网IP
　　2）RS的网关不可能指向DIP；RS和Directory不在同一个地理位置
　　3）请求报文由Director分发，但响应报文直接由RS响应给Client
　　4）不支持端口映射
　　5）RS的OS必须支持IP隧道技术
　　


　　4、FULLNAT类型
工作原理：
    通过修改请求报文的源地址为DIP,目标地址为RIP来实现转发，对于响应报文而言，修改源地址为VIP，目标地址为CIP来实现转发
架构特性：
　　1）RIP，DIP可以使用私有地址

　　2）RIP，DIP可以不在同一网段中，且RS的网关未必需要指向Director
　　3) 支持端口映射
　　4）RS的OS可以使用任意类型
　　5）请求报文经由Director，响应报文经由Director


三、LVS Scheduler
　　LVS的调度方法
　　1、静态方法
　　仅根据算法本身实现调度；起点公平

　　RR：round robin           轮询/轮叫/轮调/轮流
　　WRR：weighted round-robin     加权轮询
　　DH：Destionation ip Hashing   目标地址哈希，用的不多
　　SH：source ip Hashing       源地址哈希，用的不多

SH：Source ip Hashing，源地址哈希   当请求到达调度器时，调度器会在内存中找一段空间，将请求中的源地址抽取出来，做哈希计算。如果该用户是第一次请求，它会通过算法挑一台后端RS，并将这台RS和用户请求的哈希计算的结果对应起来，保存在哈希表中。所以，当用户请求到达时，会先查这张表。因此，它会将来自同一个地址请求，统统定向至此前选定的RS。这是一种反负载均衡的算法。那这种算法意义何在？会话保持，防止购物车中的信息刷新后没了。 DH：Destination ip Hashing, 目标地址哈希，这里指的是响应报文中的目标地址     特殊场景中才会用到，比如一个公司有多个入口；为了防止用户的请求是通过第一个防火墙进来，但响应是通过第二个防火墙出去，但防火墙只允许通过它出去的响应报文才能进来，导致用户无法收到响应报文的情况。因此在公司内部搞一个调度器，将用户请求为某目标的。可以增加缓存的命中率，这种场景很少见。

　　

　　2、动态方法
　　 根据算法及后端RS当前的负载状况实现调度；结果公平

　　LC：Least connection 最少连接
　　优先分配给Overhead（负载值）小的RS，相同Overhead就自上而下分配
　　Overhead(负载值) = Active*256(活动连接数) + Inactive（非活动连接数）
　　WLC：weighted Least connection 加权最少连接(lvs默认使用的算法)
　　Overhead = (Active*256+Inactive)/weighted
　　SED：Shorted Expection Delay  最短期望延迟
　　Overhead=(Active+1)*256/weighted
　　NQ：Never Queue  永不排队，第一轮先自上而下分配，第二轮开始计算最少连接
　　LBLC：Local-Based Least Connetion  动态方式的DH的算法，用的不多
　　它的主要目的跟dh一样，只是dh并不考虑cache server的负载情况，lblc考虑而已。尽管要保证命中的提高，并同样的请求发送给同一个cache server但也要考虑轮询新的连接用一个相对空闲的cache server来响应。
　　LBLCR：Replicated LBLC 带复制的LBLC，用的不多
　　“带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标 IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组，按“最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台服务器，将该服务器加入。


4、集群Session持久机制
　　Session sticky(粘性)：
　　基于源IP绑定，SH算法，基于cookie绑定
　　反均衡，服务器故障时session问题解决不了
　　Session Replication Cluster：
　　Session复制集群，适用于少数RS（3-5个RS)
　　各RS做成多播集群，RS之间以多播方式“复制”各session，从而每个RS会持有所有session
　　这个集群缺点在于，后端每台RS都要维护RS数量倍数的会话，RS数量越多，RS的压力就越大。
　　

　　Session Server：
　　使用独立的服务器，专用于共享存储session信息（redis，memcached）
　　session server需要高可用
　　

　　基于cookie而不再是IP做调度：
　　用户在访问服务器时，服务器会给客户端发一个瘦cookie，而后将每个cookie和session的对应关系，保存在一个表中。此后客户端请求时，服务器通过追踪客户端提交的cookie来关联它的session。由于LVS工作在4层而不是应用层，因此不支持。因此haproxy和Nginx便有了用武之地。
　　

　　 wlc是lvs的默认调度算法，要考虑session的话，就只能使用SH了。因为lvs工作在四层，所以无法基于cookie做调度。而正因为lvs工作在四层，所以它的连接数不受套接字的限制，才能有那么好的性能。