LVS就是一种实现负载均衡的解决方案。

什么是服务器集群&＃xff1f;为什么要建立服务集群&＃xff1f;

通常服务集群划分为几大类&＃xff1f;又分别适用于什么场景&＃xff1f;每一种服务集群构建的代表方案有哪些&＃xff1f;

个人的理解&＃xff0c;以一种通俗易懂的方式讲述出来&＃xff0c;如果有哪些地方说的不正确的话&＃xff0c;希望大家留言指出来。笔者会非是常的感谢&＃xff01;

Cluster服务器集群&＃xff0c;直接理解为一些单一的服务器的集合通过某种方式组合起来&＃xff0c;为客户端提供服务。

现今的服务器面临三个问题&＃xff1a;

1、 并发请求数量大&＃xff0c;这就要求服务器容量要足够大2、 在线访问量大&＃xff0c;要求服务器不能中

3、 总体的访问量庞大&＃xff0c;禅理性能要足够的强

面对这些问题我们以往采取的方式是Scale up:(向上扩展),即是将当前使用的服务器&＃xff0c;用比它性能更好的服务器替换掉&＃xff08;新机替换掉老机&＃xff09;。服务器单一管理起来非常方便&＃xff0c;但是,要知道换上的新机比老机提升了的性能和在这个新机上的花销可不是成比增长的&＃xff0c;并且还会造成对老机的浪费。所以就有了Scale out(向外扩展)即是以增加机器的方式来提升服务器的性能&＃xff0c;这其实就是Cluster“集群”。

针对以上的三个问题&＃xff0c;按服务集群的功能能将其分为三个类别&＃xff1a;
1、负载均衡集群&＃xff08;LB,load Balance Cluster&＃xff09;
2、高可用集群&＃xff08;HA,High Available Cluster&＃xff09;
3、高性能集群&＃xff08;HP&＃xff0c;High Performance Cluster&＃xff09;
负载均衡集群在Linux中的软件实现方式&＃xff1a;LVS
高可用集群在Linux中的软件实现方式:heartbeat corosync
高性能集群在Linux中的软件实现方式&＃xff1a;hadoop
负载均衡集群&＃xff1a;通过硬件实现的方式&＃xff0c;常用到的调度器有F5的BIG IP可处理的并发请求数量高达1000万&＃xff0c;IBM的A10并发请求数量可达600万&＃xff0c;Citrix&＃xff0c;Netscaler可处理并发请求数量为500万&＃xff0c;都可以满足我们的需求&＃xff0c;但是都太贵了&＃xff0c;而我们的软件实现方式很好的弥补了这个缺憾哈&＃xff01;而其中最具代表性之一的解决方案即是淘宝的章文嵩博士创立的LVS。
-----------------------------------LVS框架图-------------------------------------------

LVS&＃xff08;Linux Vitual Server&＃xff09;---虚拟服务器&＃xff0c;在工作当中它是作为一个前段的Director&＃xff08;调度器&＃xff09;工作的&＃xff0c;Director它本身不提供任何的服务&＃xff0c;只是将接收到的请求转发给后端的Real Seerver处理&＃xff0c;然后在响应给客户端。所以我们也称LVS为“4 layer switch/route"。LVS本身的两个基本的组件就是&＃xff1a;ipvs和ipvsadm。而ipvs是一个工作在内核当中的,它其实就是相当于做成了netfilter框架的一个模块。就像netfilter当中有filter表、net表、mangle表&＃xff0c;而你现在又加入了Ipvs表&＃xff0c;主要是用于让定义好的规则生效&＃xff0c;ipvsadm是工作在用户空间&＃xff0c;用来定义LVS的转发规则。LVS是工作在INPUT链上的。
-------------------------------------转发过程图----------------------------------------

Director&＃xff08;调度器&＃xff09;即是负载均衡器&＃xff0c;一个合格的Director要满足以下的要求。
1、考虑服务器负载能力通过某种调度方法&＃xff0c;调度后端服务器。
2、考虑后端服务器是否正常工作&＃xff0c;这也是需要一种机制来完成&＃xff0c;我们称其为后端主机健康状态测。
3、考虑Director本身如果出故障&＃xff0c;整个服务瘫痪的问题。这里不得不用到高可用集群。即在添加一个Director.
4、为多台的Real Server提供一个共享存储。说到共享存储就不得不说到DAS、NAS、SAN。
DAS&＃xff1a;直接辅加存储&＃xff0c;即直接连接到主机总线上的存储设备。优点在于存储容量扩展方便&＃xff0c;实施起来很简单&＃xff0c;但是这种方式太过于限制&＃xff0c;它必须要和服务器在同一个机架上。
NAS&＃xff1a;网络辅加存储&＃xff0c;双方共享文件服务器&＃xff0c;只要连接到NAS上就可以实现共享存储。并且Real Server同时写入的时候不会崩溃&＃xff0c;因为它是文件系统级别的&＃xff0c;但是DNS最多只能同时为十台服务器提供共享存储。
SAN&＃xff1a;存储区域网络&＃xff0c;这种可以说是分布式文件锁的机制&＃xff0c;
FC SAN光驱动
IP SAN&＃xff08;iSISC&＃xff09;
每个Real Sever都有RIP VIP 
每个Drector都有DIP VIP
LVS的三种工作模型&＃xff1a;NAT模型-----DR模型-----TUN模型,其中DR模型应用最广。
NAT模型&＃xff1a;网络地址转换模型&＃xff0c;
NAT模型的特点&＃xff1a;
1、Diretor和Real Server(RS)必须在同一个子网中。
2、RIP通常使用私有地址&＃xff0c;仅限于本地通信
3、Director工作在Clients和RS中间&＃xff0c;负责处理进出的全部报文
4、RS网关要指向DIP
5、可以实现端口转换&＃xff08;映射&＃xff09;
6、RS可以是任何操作系统
7、Director可能成为性能瓶颈&＃xff0c;所以不适用于教大规模的负载均衡场景
net模型详解&＃xff1a;
net模型图示&＃xff1a;
 
DR模型&＃xff1a;直接路由模型
DR模型的特点&＃xff1a;
1、RS跟Director必须在同一物理网上&＃xff08;即中间不能隔路由设备&＃xff09;。
2、RIP可以使用公网地址
3、Director仅处理请求报文
4、RS的网关不能指向DIP
5、不能使用端口映射
6、大多数操作系统可以用于RS
7、一般DR模型的Director能处理比NAT模型多的多的请求
DR模型详解&＃xff1a;
CIP向VIP发出请求&＃xff0c;CIP经由路由设备&＃xff0c;到达局域网&＃xff0c;它的目的是想和Director的VIP通信&＃xff0c;但是它不知道VIP的MAC&＃xff0c;在局域网内部通讯看的是MAC地址&＃xff0c;所以它要发广播&＃xff0c;所有收到广播包的都会回应此广播&＃xff0c;此时就会产生问题了&＃xff0c;RS1、RS2也会回应因为他们也有同样的VIP啊&＃xff0c;那交换机怎么知道&＃xff0c;哪个是Director的MAC呢&＃xff1f;所以我们这里必须要控制RS1和RS2不回应此广播包&＃xff0c;这就不得不提到两个内核参数&＃xff0c;arp_ignor和arp_annouce&＃xff0c;在RS1和RS2上均对这两个参数给与定义&＃xff0c;则RS1和RS2就不会回应由交换发出的这个找VIP的对应的MAC的广播包了。此时数据包就可以到达Director了&＃xff0c;Director通过某种调度方法计算发现RS1符合这个要求&＃xff0c;所以它要把这个请求包交给RS1来处理&＃xff0c;但是它也不知道RS1的MAC啊&＃xff0c;所以它也要发起广播消息&＃xff0c;此时Director发起的广播是在其内部发起的,每个RS的这个私有的地址都是不一样的。所以当RS1收到这个广播的时候发现时找它的&＃xff0c;它就会回应&＃xff0c;则此时Director就得到了RS1的MAC&＃xff0c;它将请求报文的目标MAC地址换成RS1的MAC地址&＃xff0c;然后在将这个请求包返回给交换机&＃xff0c;此时交换机就认为这个请求是发给RS1的&＃xff0c;它就会将其发给RS1,RS1收到请求包&＃xff0c;直接用自己的VIP给予回应&＃xff0c;不再经由Director.所以这就需要在RS1中定义一条路由"route add -host VIP dev lo:0"明确告知RS1&＃xff0c;只要是请求VIP的&＃xff0c;我就用lo:0这个上面的VIP来给予回应。
注意&＃xff1a;1、RS和DR都是单网卡的哦&＃xff0c;每个RS的VIP是设置在lo:0上的&＃xff0c;这个lo:0是虚拟的哈。DR的VIP是在eth0:0上面配置的。
2、由DR发出的广播包不被RS屏蔽掉的原因是因为它是广播的RIP这是他们的私有网络的地址&＃xff0c;刚刚设置的参数arp_ignor和arp_annouce,只是针对VIP的哈
DR模型图示&＃xff1a;
TUN模型&＃xff1a;隧道模型
TUN模型的特点
1、RS跟Director不必在同一个物理网络中
2、RIP一定不能使用私有地址
3、多数情况下Director仅处理请求报文
4、正常情况下响应报文不能经过Director
5、不能使用端口映射
6、仅允许支持隧道协议的操作系统用于RS
___________________________________________________________________
LVS的十种调度方法&＃xff0c;分为静态和动态两类。
静态四种&＃xff1b;仅根据算法本身调度&＃xff0c;不关心RS上当前的连接状态。
1、RR
根据规则依次论调,不考虑RS的性能。轮到谁就转发给谁。
2、WRR
加权轮询&＃xff0c;加入了weight&＃xff08;权重&＃xff09;&＃xff0c;可以根据RS的性能为其设置权重值&＃xff0c;权重越大功能越强&＃xff0c;但是不能发硬当前的服务器的运行的情况。
3、DH
目标地址hash&＃xff0c;适用于前段是一个drector后端是几个缓存服务器&＃xff0c;当客户端第一次访问到的是RS1的时候&＃xff0c;DH这种算法保证&＃xff0c;在客户端刷新后还是访问的是RS1。
4、SH
源地址hash&＃xff0c;用于保证响应的报文和请求的报文是同一个路径。
动态六种&＃xff1a;要将RS得连接状态计入调度考量标准。
1、LC
least connection&＃xff0c;当一个用户请求过来的时候&＃xff0c;就计算下哪台RS的链接谁最小&＃xff0c;那么这台RS就获得了下次响应客户端请求的机会&＃xff0c;计算的方法Overhead&＃61;active*256&＃43;inactive,如果两者的结果是相同的则从LVS中的规则依次往下选择RS。这种算法也是不考虑服务器的性能的。
2、WLC
这个就是加了权重的LC&＃xff0c;考虑了RS的性能&＃xff0c;即是性能好的就给的权重值大一些&＃xff0c;不好的给的权重值小一些。缺点就是如果Overhead相同&＃xff0c;则会按规则表中的顺序&＃xff0c;由上而下选择RS&＃xff0c;Overhead&＃61;(active*256&＃43;inactive)/weight
3、SED
就是对WLC的情况的补充&＃xff0c;Overhead&＃61;(active&＃43;1)*256/weight&＃xff0c;加一&＃xff0c;就是为了让其能够比较出大小。
4、NQ
never queue 基本和SED相同&＃xff0c;避免了SED当中的性能差的服务器长时间被空闲的弊端&＃xff0c;它是第一个请求给性能好的服务器&＃xff0c;第二个请求一定是给的空闲服务器不论它的性能的好与坏。以后还是会把请求给性能好的服务器
5、LBLC
它就是动态DH和LC的组合&＃xff0c;适用于cache群&＃xff0c;对于从来没有来过的那些新的请求会分给当前连接数较少的那台服务器。
6、LBLCR
带有复制功能的LBLC&＃xff0c;它的适用场景这里举例说明一下&＃xff0c;比如说现在又RS1和RS2,第一次访问RS1的5个请求第二次又来了&＃xff0c;理所应到Director将会将其交给RS1&＃xff0c;而此时在RS2是非常闲的&＃xff0c;所以此时最好的处理方法就是可以将后来的这5个请求分别交给RS1和RS2&＃xff0c;所以此时就需要把客户端第一次请求的资源复制下来。&＃xff08;特殊情况&＃xff09;
活动链接active和非活动链接inactive小解&＃xff1a;
这里以http为例&＃xff0c;http本身是一种无状态的链接&＃xff0c;当客户端请求访问的时候&＃xff0c;有个等待响应过程&＃xff0c;这个时段可以称其为活动链接active状态.当服务器端给与响应后&＃xff0c;请求因为keepalive而并未断开&＃xff0c;则此段时间的状态就是非活动链接状态。
无连接状态即是无追踪
COOKIE即是个标识用于追踪用户访问过哪个资源&＃xff0c;追踪用户的身份&＃xff0c;这种单一的COOKIE是不安全的
session结合COOKIE或者url完成用户跟踪&＃xff0c;客户端的COOKIE只需要保留session id敏感信息保留在服务器端.
持久连接是靠director上的持久模板来完成的&＃xff0c;模板上的条目用hash保存.
防火墙标记服务&＃xff0c;将两种服务标记成一种服务&＃xff0c;用mangle给某数据报文一个标记MARK&＃xff0c;但是不具有永久性&＃xff0c;所以需要使用持久连接
LVS中的持久连接类型&＃xff1a;
PCC
来自同一个用户端的所有的集群服务请求通通转发给后端的某个特定的Real
Server
PPC
将某客户端的特定的服务请求通过某种算法&＃xff0c;转发给后端的某个特定的Real Server
PFWM
将两种服务绑定&＃xff0c;即这两种服务都是通过后端所指定的某个Real Sever响应即是将多个PPC和并起来&＃xff0c;但是并未达到PCC标准
-p定义持久连接超时时间的&＃xff0c;默认是5分钟
ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]] [-O] [-M netmask]
ipvsadm -Ln --persistent-conn这是用于查看长连接的超时时常的
【管理集群服务】
1、增加集群服务
ipvsadm -A|E -t|u|f service-address [-s scheduler]
-s sheduler 指定调度方法&＃xff0c;如果不指定的话默认是WLC
-t|u|f 分别表示tcp|udp|firemark
2、删除集群服务
ipvsadm -D -t|u|f  service-address
【管理集群服务中的RS】 
1、增加集群服务的RS
ipvsadm -a|e -t|u|f service-address -r server-address [-g|i|m] 
[-w weight] 
a|e 其中a表示的是增加 e表示修改
[-g|i|m] -g表示DR模型(gatewaying) -i表示的TUN隧道模型&＃xff08;ipip&＃xff09; m表示的是nat模型(masquerading) &＃xff0c;如果默认不指定的话是DR模型.
2、删除集群服务当中的RS
ipvsadm -d -t|u|f service-address -r server-address
【查看服务信息&＃xff08;规则&＃xff09;】
ipvsadm -L|l
  -n 不进行反解
  -c 查看连接个数
  --stats 查看统计总数
  --rate 查看连接速率
ipbsadm -Z 清空计数器
【清空所有定义的规则】
ipvsadm -C
【保存集群服务的规则】
ipvsadm -R &＃61; ipvsadm-restore
ipvsadm -S &＃61; ipvsadm-save
service ipvsadm save
高可用集群&＃xff08;High Availabitity Cluster&＃xff09;
高可用集群的软件实现方式是&＃xff1a;heartbeat corosycn
在SAN共享存储中用到了HA Cluster,HA的实现即是相当于做一个冗余
高可用集群通常会采用可用性来衡量基实际效果。计算机系统的可用性是通过平均无故障时间(MTTF)及平均维修时间(MTTR)来度量。