一、核心概念
为什么需要集群？
假如我们有一个web站点，之允许100个用户同时在线访问。网站上线初期，通常只有几个用户在线，后期用户数量达到上千人。网站负荷加重，经常会“反应迟钝就”影响用户体验，怎么解决？
web站点键入网址后3s内必须响应，经统计若3s后响应将流失40%用户，10s后流失70%用户
解决方案：
Scale up:向上扩展/垂直扩展 （性价比不高）
Scalle out:向外扩展/横向扩展
director/dispatcher/load balancer
调度器/分发器/负载均衡器
集群
服务器集群就是指将很多服务器集中起来一起进行同一种服务，在客户端看来就像是只有一个服务器。集群可以利用多个计算机进行并行计算从而获得很高的计算速度，也可以用多个计算机做备份，从而使得任何一个机器坏了整个系统还是能正常运行。
负载均衡
负载均衡是由多台服务器以对称的方式组成一个服务器集合，每台服务器都具有等价的地位，都可以单独对外提供服务而无须其他服务器的辅助。通过某种负载分担技术，将外部发送来的请求均匀分配到对称结构中的某一台服务器上，而接收到请求的服务器独立地回应客户的请求。
均衡负载能够平均分配客户请求到服务器列阵，籍此提供快速获取重要数据，解决大量并发访问服务问题。这种群集技术可以用最少的投资获得接近于大型主机的性能。
负载均衡器
是一种把网络请求分散到一个服务器集群中的可用服务器上去，通过管理进入的Web数据流量和增加有效的网络带宽。
硬件：F5 BIG-IP
软件：LVS,Nginx及HAProxy
系统指标
可扩展性：表明了需要增加资源以完成更多工作任务时能够获得划算地同等提升
可用性：可用性指标（99%,99.9%,99.99%,99.999%一年不可用时间不超过5分钟）
高可用性：系统在一定时间单位内，保证服务在绝大多时间内可用
性能:
响应时间：发出请求到获得结果中间的时长，同一系统在不同并发下表现不同
容量：在一定时间内能完成的工作量，容量必须是可有效利用，在保证可接受性能的情况下能够达到的吞吐量
最大吞吐量：基准性能测试时得出的数据指标，系统容量的极限
系统运维：保证系统可用-->标准化-->自动化
SPOF：Single Point Of Failure 单点故障
Linux Cluster类型:
负载均衡集群：Load Balancing (扩容也可实现高可用)
高可用集群：High Availability
A（可用性）=平均无故障时间/（平均无故障时间+平均修复时间）
95%，99%，99.99%,99.999%
高性能集群：High Performance
分布式系统：
Nosql:HBase,Redis
存储：Mogilefs
文件系统：Ceph
构建高可扩展的系统，应该遵循一个基本原则：在系统内部尽量避免串行化和交互，
消息队列：将同步改成异步
GSLB:Global Service Load Balancing 全局服务负载均衡
负载均衡集群 (LB:load balancing)
负载均衡集群为企业需求提供了更实用的系统。如名称所暗示的，该系统使负载可以在计算机集群中尽可能平均地分摊处理。该负载可能是需要均衡的应用程序处理负载或网络流量负载。这样的系统非常适合于运行同一组应用程序的大量用户。每个节点都可以处理一部分负载，并且可以在节点之间动态分配负载，以实现平衡。对于网络流量也是如此。通常，网络服务器应用程序接受了太多入网流量，以致无法迅速处理，这就需要将流量发送给在其它节点上运行的网络服务器应用。还可以根据每个节点上不同的可用资源或网络的特殊环境来进行优化。
高可用性集群(HA:High Availability)
高可用性集群的出现是为了使集群的整体服务尽可能可用，以便考虑计算硬件和软件的易错性。如果高可用性集群中的主节点发生了故障，那么这段时间内将由次节点代替它。次节点通常是主节点的镜像，所以当它代替主节点时，它可以完全接管其身份，并且因此使系统环境对于用户是一致的。
高性能集群(HP :High Performance )
通常，第一种涉及为集群开发并行编程应用程序，以解决复杂的科学问题。这是并行计算的基础，尽管它不使用专门的并行超级计算机，这种超级计算机内部由十至上万个独立处理器组成。但它却使用商业系统，如通过高速连接来链接的一组单处理器或双处理器 PC，并且在公共消息传递层上进行通信以运行并行应用程序。因此，您会常常听说又有一种便宜的 Linux 超级计算机问世了。但它实际是一个计算机集群，其处理能力与真的超级计算机相等，通常一套象样的集群配置开销要超过 $100,000。这对一般人来说似乎是太贵了，但与价值上百万美元的专用超级计算机相比还算是便宜的。
在集群的这三种基本类型之间，经常会发生混合与交杂。于是，可以发现高可用性集群也可以在其节点之间均衡用户负载，同时仍试图维持高可用性程度。同样，可以从要编入应用程序的集群中找到一个并行集群，它可以在节点之间执行负载均衡。尽管集群系统本身独立于它在使用的软件或硬件，但要有效运行系统时，硬件连接将起关键作用。
下面开始学习前两种集群方式，也是企业中最常用的。（不是做科学研究，模拟***爆炸，宇宙曲线计算等的大型项目高性能集群一般用不到）
构建负载均衡高可用系统
思路：
分层：接入层-->应用层-->服务层-->数据层
分割：切割大业务为多个小业务，化整为零
分布式：
分布式应用
分布式静态资源
分布式数据和存储
分布式计算
LB集群调度器实现
工作协议层来划分：
tcp:根据请求报文中的目标地址和端口进行调度
应用层：根据请求的内容进行调度，而且此种调度为“代理”方式
软件：
tcp:LVS(Linux Virtual Server),HAProxy,nginx
http:HAProxy,nginx,apache(Proxy module,balancer module),ats(apache traffic server),squid,varnish
mysql:mysql-proxy
硬件：
F5:Big-IP
Citrix(思杰):NetScaler
A10:A10
Array:Array
三、LVS
LVS:Linux Virtual Server,章文嵩
layer4 router/layer4 switch
根据目标地址和端口作出转发与否决策，
根据调度方法作出转发至哪一个后端的决策
组成部分：ipvs,ipvsadm
netfilter:
PREROUTING,INPUT,FORWARD,OUTPUT,POSTROUTING
ipvs工作于netfilter的INPUT链接：
ipvsadm用于在ipvs上定义集群服务，同时也得定义此集群服务对应于有哪些后端主机可用
支持协议：TCP,UDP,SCTP,AH,ESP,AH_ESP
1、LVS中的常用术语约定：
Host:
Director:调度器
Real Server:RS 后端提供服务的主机
IP：
Client:CIP
Directory Virtual IP:VIP
Directory IP:DIP
Real IP:RIP
2、LVS的类型
lvs_nat:masquerade
lvs_dr:direct routing
lvs_tun:tunneling
lvs_fullnat:fullnat
lvs-nat类型
架构：
在一组RS前有一个Director，它们通过Swith相连接，这些RS提供相同的网络服务、相同的内容，即不管请求被发送到哪一台RS，执行结果都一样。
服务的内容可以复制到每台服务器的本地硬盘上，可以通过文件系统（如NFS）共享，也可以通过一个分布式文件系统来提供
工作原理：类似于DNAT，但支持多目标转发
用户通过VIP访问网络服务时，请求报文达到Director，Director根据调度方法（算法）从一组RS中选出一台服务器，将请求报文的目标地址改写成选定RIP，目标端口改写成选定RS的相应端口，最后将修改后的报文发送给选定RS，同时调度器Hash表中记录这个连接，当这个连接的下一个报文到达时，从Hash中可以得到哦原先选定的服务器的地址和端口，执行同样的改写操作，并将报文传送给原先选定的RS。当来自RS的响应报文经过Direcctor时，调度器将报文的源地址和源端口改为VIP和相应的端口，再把报文发给用户。
架构特性：
1）RS应该使用私有地址，即RIP应该为私有地址，各RS的网关必须指向DIP
2）请求和响应报文都经由Director转发，高负载场景中,Director易成为系统瓶颈
3）支持端口映射
4）RS可使用任意 类型OS
5）RS的RIP必须与DIP在同一网络
6）用户所看到的只是在Director上提供服务，而服务器集群的结构对用户而言是透明的
lvs-dr类型：
大多数Internet服务都有这样的特性：请求报文较短而响应报文往往包含大量的数据。
如果能将请求和响应分开处理，即Director只负责调度请求，而响应直接返回给客户，这将极大第提高整个集群系统的吞吐量。
工作原理
Director在实现转发时不修改请求报文IP首部，而是通过直接封装MAC首部完成转发。目标MAC是Director根据调度算法选定的RS的MAC地址
架构特性：
1）保证前端路由器将目标地址为VIP的请求报文通过ARP地址解析后送往Director
解决方案：
静态绑定:在前端路由直接将VIP对应的目标MAC地址静态配置为Director的MAC地址（不靠谱）
arptables:在各RS上，通过arptables规则拒绝其响应VIP的ARP广播请求（不常用）
内核参数：在各RS上修改内核参数，并结合地址的配置方式实现拒绝响应VIP的ARP广播请求
注意：2.4.26，2.6.4及以后的kernel版本内核已经默认支持IPVS
arp_announce:定义ARP通知的级别
#对网络接口上，本地IP地址的发出的，ARP回应，作出相应级别的限制: 确定不同程度的限制,宣布对来自本地源IP地址发出Arp请求的接口
0 - (默认) 在任意网络接口（eth0,eth1，lo）上的任何本地地址
1 -尽量避免不在该网络接口子网段的本地地址做出arp回应. 当发起ARP请求的源IP地址是被设置应该经由路由达到此网络接口的时候很有用.此时会检查来访IP是否为所有接口上的子网段内ip之一.如果改来访IP不属于各个网络接口上的子网段内,那么将采用级别2的方式来进行处理.
2 - 对查询目标使用最适当的本地地址.在此模式下将忽略这个IP数据包的源地址并尝试选择与能与该地址通信的本地地址.首要是选择所有的网络接口的子网中外出访问子网中包含该目标IP地址的本地地址. 如果没有合适的地址被发现,将选择当前的发送网络接口或其他的有可能接受到该ARP回应的网络接口来进行发送.
arp_ignore:定义对目标地址为本地IP的ARP询问不同的应答模式0
0 - (默认值): 回应任何网络接口上对任何本地IP地址的arp查询请求
1 - 只回答目标IP地址是来访网络接口本地地址的ARP查询请求
2 -只回答目标IP地址是来访网络接口本地地址的ARP查询请求,且来访IP必须在该网络接口的子网段内
3 - 不回应该网络界面的arp请求，而只对设置的唯一和连接地址做出回应
4-7 - 保留未使用
8 -不回应所有（本地地址）的arp查询
arp_ignore 设置为1，这个比较好理解，当别人的arp请求过来的时候，如果接收的设备上面没有这个ip，就不响应，默认是0，只要这台机器上面任何一个设备上面有这个ip，就响应arp请求，并发送mac地址应答。
路径：/proc/sys/net/ipv4/conf/INTERFACE
临时修改arp_announce和arp_ignore：
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
永久修改：
向/etc/sysctl.conf文件添加
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
在lvs环境中，需要设定以下的参数
echo"1">/proc/sys/net/ipv4/conf/all/arp_ignore
echo"1">/proc/sys/net/ipv4/conf/lo/arp_ignore
echo"2">/proc/sys/net/ipv4/conf/lo/arp_announce
echo"2">/proc/sys/net/ipv4/conf/all/arp_announce
2）RS的RIP可以使用私有IP，此时也可以使用公网IP，此时可以通过互联网直接对此RS发起管理操作
3）Director只负责调度请求，而响应直接返回给用户，请求报文必须经由Director调度，但响应报文必须不经过Director调度
4）各RIP必须DIP在同一物理网段中
5）不支持端口映射
6）RS可以使用大多数的OS
7）RS的网关一定不能指向Director
8)VIP被Director和RS组共享
lvs-tun类型
工作原理：
不修改请求报文IP首部，而是通过IP隧道机制在原有的IP报文之外再封装IP首部，经由互联网把请求报文转发给选定的RS
内层IP首部CIP,VIP
外层IIP首部DIP,RIP
架构特性：
1）RIP,DIP,VIP都是公网IP
2）RS的网关不能也不可能指向DIP
3）请求报文由Director分发，但响应报文直接由RS响应给Client
4）不支持端口映射
5）RS的OS必须支持IP隧道技术
lvs-fullnat类型
工作原理：
通过修改请求报文的源地址为DIP,目标地址为RIP来实现转发，对于响应报文而言，修改源地址为VIP，目标地址为CIP来实现转发
架构特性：
1）RIP，DIP可以使用私有地址
2）RIP，DIP可以不在同一网段中，且RS的网关未必需要指向Director
3) 支持端口映射
4）RS的OS可以使用任意类型
5）请求报文经由Director，响应报文经由Director
3、LVS Scheduler
LVS的调度方法
静态方法：仅根据算法本身实现调度（起点公平）
RR:round-robin 轮询/轮叫/轮调/轮流
WRR:weighted round-robin 加权轮询：
DH:Destionation ip Hashing 目标地址哈希
SH:source ip Hashing 源地址哈希
动态方法：根据算法及后端RS当前的负载状况实现调度（结果公平）
LC：Least connection 最少连接,优先分配给Overhead（负载值）小的RS
相同Overhead就自上而下分配
Overhead(负载值)=Active*256(活动连接数)+Inactive（非活动连接数）
WLC：weighted Least connection 加权最少连接(lvs默认使用的算法)
Overhead=(Active*256+Inactive)/weighted
SED:Shorted Expection Delay 最短期望延迟
Overhead=(Active+1)*256/weighted
NQ:Never Queue 永不排队，第一轮先自上而下分配，第二轮开始计算最少连接
LBLC：Local-Based Least Connetion 动态方式的DH的算法
LBLCR：Replicated LBLC 带复制的LBLC
4、Session 保持
Session sticky(粘性) 基于源IP绑定:SH算法,基于cookie绑定
Session Replication Cluster Session 复制集群 (少数RS适用3-5个RS)
各RS做成多播集群，RS之间以多播方式“复制”各session，从而每个RS会持有所有session
Session Server:引入第三存储，专用于共享存储session信息（redis,memcached）
LVS性能强大，功能简单，工作于传输层
HAProxy/Nignx工作于应用层，功能强大，基于Socket，并发3-5W
5W以上并发考虑才使用：也不直接使用LVS（调度至HAProxy/Nignx调度器）
CDN分流，大业务分割
