2020/01/05 02-LVS工作实现

DR模型优势，请求报文和响应报文不都经过LVS，缺点是LVS和RS是需要在一个网段的，这样就容易产生安全隐患

所以有了tun模式，隧道模式

**tun（隧道），在转发数据的时候，把数据报文拿过来，然后在数据报文的ip的地方（ip报文头部，网络层源地址本是CIP）
（应用层报文头部如http，里面是传输层头部，如tcp，再往里ip报文头部
**
tun模式会在里面继续封装一个报文头部，这个头部是新的报文头部，会加源地址CIP，目标是RIP
成为了一个新的ip报文头部了，就经过层层转发，到达了rs服务器，rs服务器收到后，接收数据报文，然后把报文拆开，拆开以后发现有一个新的IP报文，新的报文发现是CIP发送过来的，vip是目标，就需要在RS上配置VIP，不然就抛弃了，这一点和DR模式类似

在里面增加新的报文头部，新的报文头部是源地址是LVS服务器T-ip，目标地址是被调度的RIP，lvs和rs可以跨路由，RS收到后，会把报文拆开，得到源地址和目标地址，目标地址VIP，所以需要RS也要绑定VIP，这样RS就可以直接响应客户端，这样回应请求也不会经过负载均衡LVS服务器，实现的好处是，可以跨路由，
甚至可以隔一个互联网，dip在北京，vip在深圳都是可以做到的
跨机房的调度

tun模型封装了新的报文头部，要求你的服务器要识别加报文头部的方式

fullnat模式和nat模式很像，nat模式，替换的是请求报文的目标地址，源地址不替换，
fullnat是把源地址也替换了

fullnat模式就有些变化了，DIP是源地址，RIP是目标地址，cip被替换成DIP ,VIP替换成RIP的某一个
这样LVS和Rs中间可以隔网段，可以加路由

fullnat默认不支持，需要重新编译

**nat模式和DR模式用的比较多
相同：请求报文和响应报文都需要经过LVS服务器
fullnat和nat的区别：
nat 只替换目标地址， （中间也可以隔路由器）
fullnat 源地址和目标地址都进行替换
**

dr和tun模型请求报文都经过LVS，但是响应报文都直接响应给看客户端

**server用什么服务器，对于nat用什么主机都可以，对于tun模型需要支持隧道功能，dr模型需要把arp禁用
server-network服务器网络，nat私有ip，
server-number 服务器数量，nat和fullat请求和响应都经过lvs，所以数量不用太多10-20.
**

如何把用户请求调度到哪个RS上
调度的问题，静态调度算法和动态调度算法，无非就是考虑不考虑后端RS的压力，动态考虑后面的RS压力

静态的就是设定了固定的算法调度，不管后面的RS的负载情况如何
静态4种算法，动态6种算法，总共10种算法，面试

RR就是一个轮一个

2.WRR加权调度，相对来讲要考虑后端服务器的性能，定义一个权重，按比例分配，测试的时候测的量大一些就能显示了


3.源哈希，就是实行的session sticky(绑定)，调度掉第一台机器，那么会话信息就是保存在第一台机器上的（下次如果调度到第2台机器，那么会话信息就丢了，比如一些购物车信息，之前的解决方案是根据IP地址和调度到哪个RS的地址，记录在调度器上)

http协议本身无状态，即时同一台电脑来了，理论上也是记不住的，如何记住，两种方法，
（cookie，用户访问的时候，服务器随机分配cookie，客户端记录cookie信息，同时在服务器记录xx对应cookie，会在请求报文的首部字段行放入cookie信息，这样服务器就知道是谁来访问，但是有时候cookie太大，比如要把购物车信息塞进去，网络带宽消耗严重）

就有第二种解决方案，比如购物车放在session里，在内存里分配空间，每个用户登录会分配一个ID号，cookie只放ID，下次访问把ID传给服务器，对应sessio是有这个ID的购物车信息的，就可以进行访问

IE浏览器可以看到cookie

这样就可以查到cookie

就是个文本文件，也是个键值对，通过cookie才能确定用户身份

如果禁用cookie，好多应用网站都会受到影响

调度掉第一台机器，那么会话信息就是保存在第一台机器上的（下次如果调度到第2台机器，那么会话信息就丢了，如何解决，有两种，Session复制，只要调度了，其他RS就自动同步session信息，但是这样消耗服务器内存比较大。
第二种，可以对调度器做工作，SH，源地址hash，根据客户端IP地址来进行调度，就意味着要把源地址做一个哈希运算，得出一个摘要，MD5对于任何数据算出来都是128位的二进制，只要ip地址一样哈希值就一样

第三种，session不放在RS，放在一个专门的后端服务器上，比如redis集群

目标地址哈希，看的是，上次往哪里调度，这次还是往哪里调度，是把目标地址做了一个调度,一般宽带运用商用的比较多

1.LC最少连接调度，看后台哪台服务器负载比较小，就优先往哪里调度
活动链接数acticeconns*256+inactiveconns不活动的链接数（握手了没有数据交换，什么事情也不敢，叫非活动连接）
谁的值越小就往谁上面调度，但是存在服务器性能有好有坏的问题，就需要加权重

WLC，但是这样，如果首次访问，哪台机器在前面（LVS命令加在第一个就是第一了，权重是2，但是性能不好）就先调度到哪台机器上，但是如果这台机器性能差的话，就不合理

所以有了sed
shortest 最短 expection期望 delay延迟 ，解决的就是初始的时候让连接权重高的优先
只要活动链接+1，那就是没有链接数也不会算出等于0了，这样权重为5的主机，得出的数就小，就优先调度。
但是如果权重差距太大，也会导致，其他机器不干活，n能干的累死

**never queue 第一次不按照什么权重的算法。第一次均匀分配，后续第二次的时候才按照SED按权重 **

LC最短链接，动态的DH算法
当第一个缓存服务器负载过大的时候，可以将请求进行调度，调度到第二台机器上去，即使访问优酷也往这里调度，这样优酷视频在两个缓存服务器上调度了，这样就实现了一个负载均衡，而不会导致一个机器累死的情况

LBLCR witch replication带复制功能 ,之前的根据负载来调度的话，终究不是很严谨
现在发现youku访问量很大，就把缓存每个缓存服务器上都去复制一份，这样都有缓存，用户的请求转发到每个机器上都可以进行访问，这样就可以实现更加均衡的负载
lvs是内核就具有的功能，这里记录了所有内核启用的功能列表 ,/boot/config-VERSION-RELEASE.x86_64

not_set表示功能没启用

y表示编译到内核里去了

y和m都表示编译到内核里去了，y表示把功能加载到了内核的文件中，m就是没有放到内核文件里

这就是内核文件

m的功能放在了/lib/modules/

这是文件系统的驱动

模块方式提供的功能，表现为一个个ko文件，这样的好处就是想起用就加载到内存里，不想启用就不加载

m，是以模块方式加载的

10种调度算法
规划一下并且实现

路由器两块网卡，桥接和仅主机

客户端只有桥接的
lvs和rs都是仅主机

配置客户端网卡

地址生效

配置路由器

修改另外的仅主机网卡


另外配置三个主机，lvs，rs

失效是因为没有eth1网卡了，加载不了，可以删除
网关生效了

修改路由让它启用转发功能
执行sysctl -p就存住了
配置rs1

把原来的网卡配置删除

配置rs2

删除原来的配置文件
先确保能否ping通，vip等会再设置
现在开始搭建LVS服务器，使用ipvsadm

在lvs服务器安装ipvsadm

现在还没有定义ipvs规则

有一个脚本

修改下后端服务器地址

g代表dr模型
上面是VIP，下面是两个RIP、权重都是1

配置后端两个RS，也是用脚本跑
VIP绑定在lo：1回环网卡，非常稳定，因为是虚拟网卡，不会down

配置RS2

两个页面不一样

现在就成功了

现在把27宕机

但是还是会调度,LVS没有后端健康检查功能，nginx就有健康性检查
脚本停了策略就没了

修改下脚本调整权重

把原来RS2的http服务恢复

这样就有权重了