所谓的集群知识—只需要简单的梳理
（图可能较多，笔者喜欢用图形的排版方式来梳理知识而告别繁琐的文字）
刚解除集群，这东西庞而多杂的概念，各种集群的架构：负载均衡、高可用、高性能等等，难免或让人眼花缭乱。当然想要快速掌握他们，需要的只是从简单到复杂。那么笔者同大家一起进行这些知识的梳理，告别繁琐的文字的束缚，由浅入深，来一层一层剥离他们的关系。
如上图，我们告别繁琐的书面信息（这些东西从哪里来，怎么得来，由谁搞出来等），先来大致认识下集群及其分类，大致功能。这些掌握ok再去寻根问底。
LB负载均衡集群详解
定义（本人解释方法）：
如果一台服务器，某个时间点接受了N多用户的请求，那么它肯定会出现处理不了导致响应缓慢的问题，而硬件提升服务器太昂贵或者已经达到顶峰，那么LB的作用就在这里体现了。 当用户（大量）请求到来时，由负载均衡器接收，而将这些请求分摊发放给由它管理的服务器上。让M多服务器同时来承受这些用户的请求（这些服务器的功能是相同的也就好比同一台服务器的影分身）。
了解了他的大致作用，来看下图，它的分类
到这里，我们大致要对LB有个思维上的理解，那么开始详解他们的功能
四层LVS详解：
LVS由前端的负载均衡器(Load Balancer，LB)和后端的真实服务器(Real Server，RS)群组成。RS间可通过局域网或广域网连接。LVS的这种结构对用户是透明的，用户只能看见一台作为LB的虚拟服务器(Virtual Server)，而看不到提供服务的RS群。
当用户的请求发往虚拟服务器，LB根据设定的包转发策略和负载均衡调度算法将用户请求转发给RS。RS再将用户请求结果返回给用户。同请求包一样，应答包的返回方式也与包转发策略有关。
LVS转发策略：三种模式
(ps：这里我们需要说明一下具体的一些名词：)
Director：复制调度集群的主机 VIP(virtual ip) 向外提供服务的IP RIP（real ip）后端真正提供接点的ip DIP（Director‘s ip）及负载均衡器（Loader balance，LB）上连接D/RIP的地址（向内部的IP通信的IP，在Director主机上） CIP(custom ip)用户请求的ip
1、NAT 地址转换
1.集群节点跟director(引向器)必须在同一个IP网络中 2.RIP通常是私有地址，仅用于各集群节点通讯 3.director位于client和real server之间，并负责处理进出的所有通信 4.realserver必须将网关指向DIP 5.支持端口映射 6.realserver可以使用任意操作系统(OS) 7.使用在较大规模应用场景中，director易成为系统瓶颈（进口出口都在DIP） PS： Director上只需要一个网卡，然后利用别名来配置两个IP：VIP和DIP。Director在接受到外部主机的请求的时候转发给Real Server。 Real Server进行回复时，将请求先交给DIP，然后由VIP转发给交换机实现通信。
2、DR直接路由 (最常用的)
1.集群节点跟directr必须在同一个物理网络中； 2.RIP可以使用公网地址，实现便捷的远程管理和监控； 3.director仅负责处理入站请求，响应报文则由realserver直接发往客户端； 4.realserver不能将网关指向DIP； 5.不支持端口映射； 6.realserver隐藏自己的DIP PS： Director如NAT模型 每个Real Server上都有两个IP：VIP和RIP，但是VIP是隐藏的，只是用来做请求回复的（暂时可以这么理解）。 Director在接受到外部主机的请求的时候转发给Real Server的时候并不更改目标地址，只是进行一次封装然后转给Real Server Real Server在接受到信息以后拆除第一层封装，并且丢掉，只保留原始的SIP（CIP），然后直接回复给CIP
3、TUN 隧道模型
这个模型跟DR模型有些相似，只不过Real Server跟DIP不在同一物理网络中。Real Server回复模式同DR模型相似。DIP向RIP传送的时候同样也是进行了一次包装而里面保留了CIP的SIP（source ip）。图不在继续画。
集群节点可以跨越互联网； RIP必须是公网地址； director仅负责处理入站请求，响应报文则由realserver直接发往客户端； realserver不能将网关指向DIP； 只有支持隧道功能的OS才能用于realserver； 不支持端口映射
LVS的调度算法
LVS是一个L4转发，因为他是根据用户请求的服务不同，提供转发的，所以他是使用四层的端口进行转发的，对用户来说是透明的。
静态调度方法
rr： 轮叫，轮询轮循着,它将请求依次分配不同的RS，也就是在RS中均摊请求。这种算法简单，但是只适合于RS处理性能相差不大的情况； wrr: Weight, 加权轮调，它将依据不同RS的权值分配任务。权值较高的RS将优先获得任务，并且分配到的连接数将比权值较低的RS更多。相同权值的RS得到相同数目的连接数； sh: source hash, 源地址hash 将来自同一个用户的请求，始终转发到特定的路由器或防火墙（平均内网负载），从而保证cookie与session等进行会话绑定； dh: destination hash 根据服务的请求转发到特定的服务器，跟用户建立粘性，提高缓存命中率。主要用于缓存服务器；
动态调度方法
lc: (least-connect)最少连接，检查active和inactive，连接数（overhead）最少的接受请求。公式：active*256+inactive 谁小给谁 wlc （weight least-connect）加权最小连接数（集群最好的算法），公式：（active*256+inactive)/weight 谁小给谁（权值表示服务器的性能，越好权值越高。）默认 sed: shortest expected delay （SED）最短期望延迟（谁响应最快给谁），不考虑非活动状态，在计算overhead之前，把非活动状态的总数加上1 。公式：(active+1)*256/weight nq: （never query）基于sed, 只要有空闲的，不考虑算法的接受请求； LBLC: (locality-based-least-connect:DH)支持权重(Real server是缓存服务器的),基于地址的最小连接数调度(Locality-Based Least-Connection) , 如果这台服务器尚未满负荷，将来自同一目的地址的请求分配给同一台RS(realserver)，否则分配给连接数最小的RS，并以它为下一次分配的首先考虑； LBLCR: (带复制功能的最少连接) （locality-based-least-connect with replication scheduling）是对LBLC的改进，对于某一目的地址，对应有一个RS子集。对此地址的请求，为它分配子集中连接数最小的RS；如果子集中所有的服务器均已满负荷，则从集群中选择一个连接数较小的服务器，将它加入到此子集并分配连接（同时从本应连接的那台服务器中复制过来用户的信息）；若一定时间内，这个子集未被做任何修改，则将子集中负载最大的节点从子集删除；
LVS的命令介绍
ipvsadm：管理集群服务的命令行工具，工作于用户空间 ipvs：为lvs提供服务的内核模块，工作于内核空间 PS：在linux内核2.4.23之前的内核中模块默认是不存在的，需要自己手动打补丁，然后把此模块编译进内核才可以正常使用：确定内核中是否有ipvs模块，grep -i 'ip_vs' /boot/config-2.6.18-308.el5
ipvsadm命令
ipvsadm 功能及使用：
1.定义集群服务默认方法：wlc
ipvsadm -A|-E -t|-u|-f VIP:PORT {tcp|udp|firewall mark} [-s scheduler调度算法]
-A 添加
-t: TCP协议的集群
-u：UDP协议的集群
service-address:IP:PORT
-f：FWM 防火墙标记file ware mark
server-address： Mark Number
-E 修改
-D 删除
ipvsadm -D -t|-u|-f VIP:PORT 删除定义的集群
# ipvsadm -A -t 172.16.100.1:80 -s rr
2.要为集群服务定义realserver
ipvsadm -a|-e -t|-u VIP:port -r REALSERVER:port -g|-i|-m(模型) [-w weitht] -a 添加 -t|-u|-f service-address：实现定义好的某集群服务 -r server-address: 某RS的地址，在NAT模型中，可使用IP:PORT实现端口映射 -e 修改 -w 权重 -d 删除 ipvsadm -d -t|-u VIP:port -r REALSERVER:PORT -C 情况规则 -R 恢复 -S 保存 其中模式中的-g|-i|-m分别用于dr|tun|nat # ipvsadm -a -t 172.16.100.1:80 -r 192.168.10.8 -m # ipvsadm -a -t 172.16.100.1:80 -r 192.168.10.9 -m
3.查看
ipvsadm -l|-L|--list -n 数字的方式来显示主机地址和端口号 --stats显示统计的数据信息 --rate 显示统计的速率 --timeout: 显示tcp、tcpin和udp的会话超时时长 --sort：根据协议、地址和蹲坑进行排序 -c：显示当前ipvs连接状况 -Z: 清空，重新计数
4.删除所有集群服务
-C：清空ipvs规则
5.保存规则
-S # service ipvsadm save 在 /etc/sysconfig/ipvsadm.web 或者 # ipvsadm -S > /path/to/somefile 载入此前的规则： -R # ipvsadm -R < /path/from/somefile
实验：
由于实验环境约束，将对NAT模型及DR模型进行演示。
由于实验过程加起来有点长，本人将在后边的博客中进行贴出。此处留位子以便以后进行编辑。
HA高可用集群详解
什么是高可用集群
高可用集群是指以减少服务中断时间为目的的服务器集群技术。它通过保护用户的业务程序对外不间断提供的服务，把因软件/硬件/人为造成的故障对业务的影响降低到最小程度。高可用集群的应用系统有多样化发展趋势，用途也越来越多样化，同时带来了配置及可操作性方面的复杂性，因此选择好的高可用软件至关重要。
PS：上边是学术界给出的说法，笔者觉得一句话就可以了：保证服务不间断安全运行的方式。
少一点文字，直接上关系图：
结合什么是高可用集群的概念与这张图。大概可以划分下其中大致关系：
split-brain:脑裂：
脑裂扰乱心跳信息的传递，集群节点无法有效获取其它节点的状态信息，产生脑裂
什么是状态信息，他们怎么传播状态信息？
节点A B为主从关系（1个挂掉由另外一个接替关系），但是为了更好的确保他们是否知道对方是否出现故障（挂掉），双方（当然节点多的情况下你懂的）要进行通信（也就是发送状态信息），也可以将之称之为（heartbeat），这个传播的通道即为 Messaging Layer。 脑裂的后果之一： 抢占共享存储：假如节点A B都连接到一台MySQL，如果A正在写入数据到表中，但是突然发生了脑裂，B默认接收不到A的信息自然会认为A坏掉了，从而接管A的位子，正式连接到MySQL，恰巧连接到了A正在写入数据的表中，那么双方都在写入，如果都进行存储，势必会发生文件系统崩溃。当然如果是三个节点，ABC，如果AB可以通信。C他们都连接不到，那么自然会认为是C坏掉了，然后干掉C。
避免脑裂的方式：
1、在A和B之间连接一个硬盘，让他们不停的往里面写数据，当检测到对方停止写数据时，自然认为他坏掉了。于是干掉。 2、当节点为多节点的时候，可以引入“仲裁机制”：比如2个节点的场景，A节点性能好，给他2位的权位，B位1位的。如果通信不到，A就干掉B。多节点的情况类似。 without_quorum_policy“法定票数”不够仲裁的情况下：（根据权重票数分法不同）资源隔离设备： freeze：冻结 stop：关闭停止 ignore：忽略，
CRM: Cluster Resource Manager: 集群资源管理器（CRM是运行在节点上的）
搜索每一个资源的状态，来计算出来资源节点应该运行的级别上，DC。
DC: Designated Coordinator : 指定的协调器（计算粘性的） （DC:PE,TE) PE：策略引擎 Policy Engine ：得出结果 TE：事务引擎Transaction：指挥执行 LRM: Local Resource Manager: 本地资源管理器 接受TE的指挥，从而在某个节点上运行 LSB：linux Standard Base 符合linux标准库的脚本： RA：Resource Agent资源代理（俗称脚本） RG：Resource Group 资源组（将VIP 和IPVS 定义在一个资源组）
资源约束：Constraint （资源粘性）
排列约束：coloationconstraint 资源是否能够运行于同一节点 score: 正值：可以在一起负值：不能在一起 -inf：负无穷 inf：正无穷 位置约束：location constraint , score(分数) 正值：倾向于此节点 负值：倾向于逃离此节点 顺序约束(order constraint) 定义资源启动或关闭时的次序 VIP-IPVS
,