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

yuxing

　　基础概念
　　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，