一、
基础概念
rsync 同步软件 效率不高inotify 通知
三种集群：
LB: load balance 提高服务器的并发能力
HA： 高可用 high availability 不会因为一台服务器宕机导致服务不可用
HP:high perfomence 高性能计算集群
并行处理集群
分布式文件系统
将大任务切割为小任务，分别进行处理
health check：健康检查
NFS：net filesystem 共享存储设备
DAS:直接附加存储 块级别交换数据 直接连到多态主机，性能好，但是要注意对同一文件的同时写
NAS：网络附加存储 network attached storage 文件级别交换数据
DAS:
ULTRAscsi 320Mbps 40M/s
SAS : 6Gbps
NAS: 数据交换取决于交换机以太网
split-brain：脑裂 两台服务器互相以为对方挂了，而对统一存储设备同时读写，造成崩溃
STONITH :爆头
为了避免此情况，集群一般要有奇数个节点，用以仲裁。
LVS模型
负载均衡集群： 分发器接受用户请求，根据某种策略将用户请求分发到后端某个服务器，并且后端服务器群能够进行健康检查。分发到哪台主机取决于调度算法
Hardware 实现
F5 bigIP
A10
Software 实现三款
四层负载均衡设备
LVS 根据IP：端口 进行分发。只解析四层协议 Linux virtual server
七层： 反向代理
nginx 根据应用层协议实现负载均衡 如 根据url进行分发 可能更符合生产环境需要
haproxy
LVS：Linux virtual server 能识别IP：端口来决定是否转发至后端主机
工作在内核空间，借助NETFilter 内置5条链（钩子）
prerouting input forword output postrouting
因此，LVS工作在INPUT
lvs监控在input链，一旦规则发现用户请求的是后端集群服务，强行修改数据报文，通过postrouting 转发。因此 iptables和LVS不能同时使用
iptables/netfilter 两段式 iptables写规则，在netfilter生效
lvs 也是两段式
ipvsadm ： 管理集群服务的命令行工具 在用户空间写规则然后送给ipvs
ipvs：内核 监控input链
Network-address-translation LVS-NAT ：地址转换
Direct-routing LVS-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
黄色部分解析：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
不支持端口映射
因为客户请求的是VIP，因此响应报文的源IP就应该是VIP，因此realsrver需要VIP。但是realserver的通信靠的是RIP，因此这个VIP不是通信用，仅仅作为源IP封装
server的eth0别名上配置VIP
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
808
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
