LVS 实验笔记1 一些基础概念

基础概念

rsync 同步软件 效率不高

inotify 通知

三种集群：

LB: load balance 提升服务器的并发能力

HA： 高可用 high availability不会由于一台服务器宕机致使服务不可用

HP:high perfomence  高性能计算集群

         并行处理集群

                   分布式文件系统

                   将大任务切割为小任务，分别进行处理

 

health check：健康检查

NFS：net filesystem 共享存储设备

DAS:直接附加存储 块级别交换数据 直接连到多态主机，性能好，可是要注意对同一文件的同时写

NAS：网络附加存储 networkattached storage  文件级别交换数据

 

DAS:

         ULTRAscsi  320Mbps 40M/s

         SAS: 6Gbps

 

NAS: 数据交换取决于交换机以太网

 

split-brain：脑裂 两台服务器互相觉得对方挂了，而对统一存储设备同时读写，形成崩溃

STONITH :爆头

为了不此状况，集群通常要有奇数个节点，用以仲裁。

LVS模型

负载均衡集群：分发器接受用户请求，根据某种策略将用户请求分发到后端某个服务器，而且后端服务器群可以进行健康检查。分发到哪台主机取决于调度算法

 

Hardware 实现

         F5bigIP

         A10

Software 实现 三款

         四层负载均衡设备

                 LVS  根据IP：端口 进行分发。只解析四层协议  Linux virtual server

         七层： 反向代理

                   nginx根据应用层协议实现负载均衡如 根据url进行分发 可能更符合生产环境须要

                   haproxy

        

 

LVS：Linux virtual server能识别IP：端口来决定是否转发至后端主机

工做在内核空间，借助NET Filter 内置5条链（钩子）

         prerouting input  forword  output postrouting

所以，LVS工做在INPUT

lvs监控在input链，一旦规则发现用户请求的是后端集群服务，强行修改数据报文，经过postrouting 转发。所以 iptables和LVS不能同时使用

iptables/netfilter 两段式 iptables写规则，在netfilter生效

lvs 也是两段式

         ipvsadm： 管理集群服务的命令行工具 在用户空间写规则而后送给ipvs

         ipvs：内核 监控input链

lvs 三种类型：

         Network-address-translationLVS-NAT ：地址转换

         Direct-routingLVS-DIR：直接路由

         IP-tunneling LVS-TUN 隧道

 

NAT 模型;

最多负载均衡10个后端server，内网的网关要指向DIP，RIP和DIP必须在同一网络中，director处于client和server之间，负责进出的全部通讯（所以director颇有可能限制集群能力）；支持端口映射

         请求：客户请求报文[cip|vip]àDirector（ipvs）à[cip|rip]à后端服务器

         回应：响应报文[rip|cip]à Director (ipvs) à [vip|cip]à客户

支持端口映射：如用户IQ你滚球80端口服务，可是本机并无提供，而是映射到后端某服务器8080端口响应

DR 模型：

用户请求报文[CIP|VIP] à router路由器进行ARP物理地址解析封装MAC地址[router MAC |director MAC]à switchboardàdirecto，人后转发请求到reserver,此时的转发仅仅是director修改了报文的目标MAC 即[CIP|VIP][director MAC |reserver MAC] àreserver接收报文拆掉mac，发现目标是VIP，而VIP配置在eth0别名上，就是本身，就接收报文à响应报文封装[VIP|CIP]直接送出。

所以：director只负责如站请求，而通常请求报文比较小，响应报文比较大，这样一来director效率有了提升，能带动百十来个server

***部分解析：

         由于客户请求的是VIP，所以响应报文的源IP就应该是VIP，所以realsrver须要VIP。可是realserver的通讯靠的是RIP，所以这个VIP不是通讯用，仅仅做为源IP封装

server的eth0别名上配置VIP

特色：

         集群节点跟director必须在同一个物理IP网络中

         RIP可以使用公网IP，实现远程管理

         director仅负责处理入站请求，响应报文由reserver直接发往客户端

         realserver网关不能指向director，而是前端网关

         不能端口映射

 

TUN模型：

隧道协议双IP封装[CIP|VIP][DIP|RIP]

各个realserver在不一样区域，拥有本身的公网IP做为RIP，同时网卡还有别名为VIP

用户访问director主机以后在[CIP|VIP]基础上再加一层IP封装即 [CIP|VIP][DIP|RIP]来实现请求分发。realserver接受报文，拆掉第一层，发现RIP就是本身，拆掉第二层发现VIP是本身的别名，仍是本身因而就接受了报文。响应报文就直接[VIP|CIP]发出去

 

特色：

         集群节点能够跨越互联网

         RIP必须是公网地址

         director仅处理入站请求

         只有支持隧道协议的OS才能用于realserver

         不支持端口映射

lvs调度方法

固定调度：

调度时没有考虑服务器是否繁忙等状态，如某时刻各有100个请求，可是1个小时后，有的空闲了，有的仍是1001个请求，可是静态调度依旧按规则分发请求

         rr：轮询

         wrr：加权重轮询

         SH：sessionsharing 实现session affinity ：会话绑定

         DH：把同一个IP的请求发给同一个server

 

动态调度：考虑服务器状态，如活动连接数，非活动连接数，他们占用资源是不同的

         LC：lestconnection 最少连接

                   active*256+inactive谁的小选谁

         WLC:加权最少连接 权重大小由服务器性能决定  默认算法

                  （active*256+inactive）/w

         sed:最短时间望延迟  忽略静态连接

                   (active+1)*256/w

         NQ：永不排队  无论计算值多少，只要有空闲服务器，不管如何会发给空闲服务器一个请求

         LBLC：基于本地的最少链链接

                   基于LC，和DH目的同样，可是会考虑服务器状态，有可能破坏缓存命中率，所以提升命中率和负载均衡效果成反比

         LBLCR:基于本地的带复制功能的最少连接

                   如两个cacheserver 能够实现共享，

 

 

SH：sessionsharing原地址哈希对用户请求作哈希运算，在director中位置一张哈希表，记录了上一次这个用户访问被分发在了哪台realserver，当同一用户再次访问时，计算哈希值到表中检索，按照记录将用户请求依旧发送到以前的realserver。这样一来其实破坏了调度平衡，可是又须要这样作

why？ 好比WEB服务器，用户访问以后，加入购物车什么的操做，一刷新，被转发到新的WEB服务器上，以前全部的操做都没了，爽不爽？

由于http是无状态协议，即用户上一次访问和下一次访问，服务器没法识别是否是同一人，所以借助session和cookie来识别用户，机制是：当用户首次访问server，server会生成一个该用户的cookie发给客户端，保存在客户端的coocki文件中。早期的cookie机制是用户访问server时每发一次请求都会附加上cookie信息，server对比cookie就知道是否同一用户，所以cookie可能包含URL、身份认证等敏感信息，太不安全，因此如今流行清理cookie，清理cookie中的敏感信息，而只保留用户认证信息，而后在服务器里边对应用户cookie在内存中维持一段区域来保留用户的详细信息，这段内存区域就叫session

 

session affinity ：会话绑定

 

固然若是集群里的WEB服务器有一个坏了，那么这个服务器上的session就没了，用户请求被定义到新的主机，可是以前的操做就没了，因此要进行session共享，吧session信息同步到一个共享存储。固然若是实现了session共享，就不须要sh算法了

 

 

DH：如今有多个cacheserver。咱们知道用户请求某对象会先查找缓存，缓存没有才会请求源服务器，而后缓存到cache本地，而后返回给用户，因此懂了么？同一个请求发往同一个cachesserver，