文章目录
负载均衡LVS入门
简介：LVS作为一个调度器，它工作在传输层，它的性能非常好。他的性能支持４００万左右的并发是没有问题的，apache服务器１万并发可能都稍微有点扛不住了，但是他的功能特别少，所以经常需要一些其他的软件协助。调度器后方的一台业务处理服务器挂了，可以不把请求转给他就行，只是性能差了点，但是如果LVS调度器不行了，相当于整个业务都无法访问了，所以一般LVS+keepalived搭配
基本概念：
LB：load balance 负载均衡集群
HA: high Availiablity 高可用
MTBR：Mean time between failure 平均无故障时间
MTTR : Mean Time Between Filure 平均恢复前时间（故障时间）
A=MTBF/ (MTBF+MTTR) ：99% 99.9% 99.99%
HPC:高性能
分布式系统：分布式存储：云盘
分布式存储：指的是每个机器上都有一部分文件数据，每个机器上都有一些副本，这样即使死了一台机器也没关系，因为另一台机器上有副本
如何进行状态保持？
如果用户一开始登录访问到的是A机器，它的一些数据在A这个服务器上，但是当第二次访问的时候，被调度到B机器上，那么之间的数据就不能看到了。
解决方法
第一种：**根据源地址，LVS把相同的IP地址调度到同一台机器上。**但是这个方法非常糟糕，因为有些用户是通过DNAT进行上网的，在一个局域网上可能有成千上万的用户通过一个公网地址上网，那么这些用户都会登录到一台服务器上，全都调度到一个机器上了
第二种：**session绑定，**只要是同一台机器来访问的，我就把他调度到同一台机器中去
第三种：每个服务器拥有全部的session，调度到哪台机器上都有一样的session，但是这样每台机器上都存放了很多同样的数据，造成了资源的浪费，所以用户量过大，不适合
第四种，专门搭建一个服务器存session，比方说用Redis，Redis也可以建立主从，实现了会话
LVS工作模式
NAT模式
- 用户访问调度器，源：CIP:xxx>>> 目：VIP:80
- 访问到调度器后，LVS调度器根据相应的算法，这个算法一共有10种，转发给后端业务处理服务器，这时候director改变目的IP地址 源：CIP:80>>> 目：RIP1:80，NAT模式只改了目的地址
- 然后后端的业务处理服务器收到director发过的请求后进行处理，返回响应给客户端，业务处理服务器以 源：RIP：80 >> 目：CIP：80发给director
- 调度器收到后，再转发给客户端，这时候，源：VIP:80 >> 目：CIP：xxx
特点：
- 请求报文，响应报文都需要经过调度器，所以这种模式性能不是很好。
- 它可以做端口映射，也就是时候我们调度器的端口和真实的后端处理业务的服务器端口可以不同
- RIP和DIP一般在同一个网段，Real Server的网关要指向调度器
- director需要配置两个地址，一个地址对外，也就是公网地址，用来接收客户端的请求，另一个地址对内，通常一般情况下是私有地址，当然也可以是公有地址，这个地址用来把请求转发到后端的业务处理服务器
- 一般情况下，Real server是私有地址，因为它对客户端是隐藏的
DR(直接路由)模式
DR模式应用最广泛，它是基于MAC地址进行转发的。
它的原理是：
- 当一个请求到达调度器的时候。先经过PREROUTING链，然后经过路由决策，又发现是转发给本机的包，接着就会走input链。
- LVS的内核模块ipvs就工作在input链，它会比对这个包的服务是否是集群服务，如果是，根据设定的DR模式。把源Mac地址改为调度器的Mac地址，目标Mac地址改为某台后端服务器的Mac地址。它怎么知道后端服务器的Mac地址呢？他是通过ARP广播来找的，也就是说，这种模式必须调度器和real server在同一个网段，这个real server后端服务器是安按照某个调度算法决策出来的。
- 然后经过postrouting链，进行选路，发给后端real server，因为调度器并没有改变IP地址，它的目标IP还是VIP（调度器的IP），这时候，real server如果收到一个目标Mac地址是自己的，但是目标IP不是自己的数据包就会感到奇怪，所以在每一台server上都要配置VIP，又因为调度器和real server都是同一个网段的，所以为了避免地址冲突，每台real server都要经过特殊配置，让他们不启动网络服务的时候，不发ARP广播去比对自己的IP地址有没有冲突
特点
- 请求报文经过调度器，但是响应报文不经过调度器，降低了调度器的压力
- 它只是修改源目MAC，IP/端口号都是不改的，所以不能进行端口映射
- 调度器与Real Server拥有相同的VIP，要避免IP冲突
- 避免IP冲突：修改内核参数，首先为什么会IP冲突，因为主机在启动网络服务的时候，会向网络中发送ARP广播，看看网络中有没有主机有这个IP地址，如果收到与自己相同的IP地址的主机的回应，那么就IP冲突了。所以我们可以修改内核参数，让主机不发这个ARP广播去询问其他主机的IP地址，而且如果别的主机发ARP广播，我也不应答，这样就避免了IP冲突的问题
- 通过ARP广播来找MAC地址
TUN模式
TUN是隧道的意思。TUN模式的工作原理是在当请求到达调度器的时候，调度器会给报文在加一个IP报文头部，刚开始报文到调度器的时候，这个报文只有一个IP头，正常都是一个IP包头，IP包头里面，源地址是CIP，目的地址是VIP，然后调度器通过调度算法，确认要把它转发给某台Real Server的时候，会给他加一个IP头部，源地址是VIP，目的地址是调度算法确认的RIP，然后这个RIP对应的Real Server收到之后，这个Real Server需要经过特殊配置，因为它要处理有两个IP包头的数据包，收到后，它会把调度器加的那个IP包头去掉，露出最开始那个IP包头，因为这里Real Server也配置了DIP，所以它可以把响应经过路由器发给客户端，而不需要再经过调度器。虽然Real Server配置了DIP，但是实际上它并不需要考虑地址冲突的问题，因为TUN模式里面一般调度器和Real Server之间是隔着路由器的，就没有地址冲突，TUN模式一般用在跨地域的时候，比如有些大公司可能北上广深都有机房，使用TUN模式可以跨异地机房
FULL-NAT模式
这种模式和NAT模式类似，但是它在请求到达调度器的时候，调度器会把源地址，目的地址都转换掉，因为FULL-NAT模式它把源地址目的地址都改了，所以Real Server只能看到是调度器访问的，日志里面看不到客户端的IP，而NAT模式它只改了目的地址，没有改源地址，源地址还是客户端的地址，所以在后端的web服务器的日志里面可以看到是谁访问的，但是full-NAT不可以，full-NAT在调度器和RIP之间可以连接路由器，其实NAT也可以
LVS十种调度算法
下面前四种是静态调度算法，静态调度算法的意思是不考虑每台Real Server的负载怎么样 ，只按照配置的规则进行调度，而动态调度算法是根据Real Server服务器的负载进行动态的调度，看哪个相对没有那么繁忙，就尽量把它调度到那里去
RR轮询算法
轮询，轮流的调度给Real Server
WRR加权轮询算法
对性能较好的服务器分配多一点权重，按照性能分配
SH源地址哈希算法
- 对源地址进行哈希，将同一个IP的请求固定的转到一台Real server上，从而实现会话绑定，
- 因为我们的客户端第一次登录的时候调度到服务器A，会话信息都在服务器A上，但是如果下一次调度到了B，那么B上没有会话信息，客户也就看不到自己之前的数据了，
- 使用SH源地址哈希可以解决这个问题。但是这个方法也不是很好，因为如果在一个局域网里面，有上万的用户，这些用户都通过DNAT去上网，那么他们用来和互联网通信的公网地址是同一个，这样这些请求都被调度到了同一台服务器，造成这台服务器处理不过来。
- 更好的方法是使用session，粒度更细一些
DH目标地址哈希
对目标地址进行哈希，使得访问同一个资源的请求，转发给同一个服务器，这种情况一般用在具有缓存服务器的情况下，用来提高缓存命中率，比如我们一些电信运营商在一些小区，他们可能会搭建正向代理服务器和一些缓存服务器，我们去访问优酷的视频的时候，先去缓存服务器里边找，找不到再去优酷官网上找，然后缓存一份在缓存服务器上，为了提高缓存命中率，我们可以把去访问优酷的请求都调度到缓存优酷相关数据的那台缓存服务器上，这样就可以提高缓存的命中率。
LC最小连接算法
哪台服务器的连接数少，就往它那里调度，它会监控每一个real server的活动状态连接和非活动状态连接的数量，然后计算出它的当前负载 ，active*256+inactive=overhead，但是他有个缺点就是，没有考虑到每台real server的性能可能会不同，有一些real server它连接虽然很多，但是他的性能非常好，可以完全处理得过来，而有些real server虽然它连接很少，但是因为他的性能比较差，可能已经处理不过来了，LC算法没有考虑到这种情况，所以有了WLC
WLC加权最小连接算法
这是默认的集群算法（记住），通过加权，可以给性能好的服务器多加一些权重，根据real server的性能和连接数进行调度
SED 最短的期望延迟
shortest experted delay 最短的期望延迟，不考虑非活动的连接，公式，(active+1)*256/weight，它目的就是初始的时候，我们优先让权重高的优先接受请求，权重高就性能好嘛，但是这也有个问题，如果权重设的差异太过大，那么根据它的公式，很容易会造成请求一直往性能好的服务器上调度，但是性能差的服务器比较难接受到请求，会造成性能好的服务器拼命干活，性能差的服务器不干活的极端情况
NQ
第一轮先均匀分，后面再使用SED，这样至少每个服务器都有连接了
LBLC(动态DH算法)
DH算法是目标地址哈希，根据负载把一个小区的用户访问优酷的网站的请求都调度到缓存优酷数据的缓存服务器上，但是如果某个很流行的节目只有优酷可以看，比如世界杯，那么请求都往优酷视频的那个缓存服务器上调度，造成这个缓存服务器压力过大，即使你访问优酷，也往缓存爱奇艺的缓存服务器上调度，然后优酷的数据也会在这个爱奇艺的缓存服务器上缓存一份
LBLCR（带复制功能的LBLC）
解决LBLC负载不均衡问题，把负载重的服务器上的一些数据，复制到负载轻的Real Server，这样不会导致一个服务器压力过大
LBLC和LBLCR这些一般是电信运营商用的
