1、HA Cluster基础原理

Linux Cluster  -->  linux集群类型分三种：

LB：负载均衡，LoadBalance

HA：双机集群系统，指高可用性集群，High Available

HP：Hadoop

 

LB的实现方式：

传输层：lvs

应用层：nginx, haproxy, httpd, perlbal, ats, varnish

HA的实现方式：

vrrp: keepalived

AIS: heartbeat, OpenAIS, corosync/pacemaker, cman/rgmanager(conga) --> RHCS红帽集群套件

http://www.voidcn.com/article/p-nyeucptv-on.html

HA集群故障场景:

• 硬件故障：
• 设计缺陷
• 使用过久自然损坏
• 人为故障
• …… ……
• 软件故障
• 设计缺陷
• bug
• 人为误操作
• ……

对于HA集群或者提高高可用的思路是降低平均修复时间，衡量一个系统出现故障的方式：

A=MTBF/(MTBF+MTTR)    可用性=平均无故障时间/(平均无故障时间+平均修复时间)

MTBF: Mean Time Between Failure

MTTR: Mean Time To Repair

0<A<1: 百分比

90%, 95%, 99%

99.9%, 99.99%, 99.999%

提供冗余：当节点出现故障，就用冗余节点替代

network partition： 网络发生隔离后，采用投票系统vote system

隔离：

STONITH：shoot the other node on the head  节点级别隔离

Fence: 资源级别的隔离

 

无论哪种高可用集群，都需要一个运行在多个节点、彼此间能够互相通信的、用来传递心跳、传递集群事务决策中所依赖的其他信息的一个应用程序，这个程序对于高可用集群来讲是个基础性的程序，这个程序就叫高可用集群的信息传递层(Messaging Layer)也称为基础结构层(Infrastructure layer)。

keepalived除了传递心跳信息外，还利用节点的优先级决定是主节点还是备用节点，在硬件没有发生故障时，keepalived可以通过本地监控的资源、条件不能满足要求时，会让主机点降为备用节点，这是一种集群事务仲裁机制，这个事务仲裁机制从本质上来讲是由keepalived提供完成的。但是对于遵循openAIS类别的集群来讲，机制是不相同的。Messaging Layer并不负责集群事务仲裁功能，它只是将当前的活动节点所通告的心跳信息通过多播、单播或广播的方式传递给同一集群中的其他节点，最终哪个节点是主节点哪个节点是备节点，为什么是主节点及为什么是备节点，keepalived是通过arrp_script来额外定义脚本实现的，这就不是keepalived自身的功能了。但对于AIS集群来讲有一个专门的、功能非常强大的层次来完成这个任务，这个层次也需要运行在各个节点之上，但需要调用Messaging Layer中所需要实现的功能。

AIS(Application Interface Specification)：AIS除了提供底层消息传递层之外，还有非常复杂的API。

为什么要有API？Messaging Layer能够在各节点传递集群事务信息，但假如A节点是活动的，B节点是备用的，一旦活动节点A宕机，那么A传递心跳信息的机制也就无法完成了，这时就需要把A之前配置的IP地址、运行的服务程序切换至B节点上，那么是谁来切换？因为Messaging Layer并不负责完成这个功能的，即使在keepalived集群中也是通过定义notify等脚本完成的。

同样在AIS机制中Messaging Layer也无法完成这种功能，因为比如先高可用nginx、再高可用httpd等高可用服务是不断切换的，所以不可能把这些功能全部高可用进Messaging Layer，所以为了支撑更多的服务实现高可用功能，Messaging Layer就把自己提供的各种功能都通过API向外提供，这就是openAIS中定义了大量的API的原因。但是一个服务想要实现高可用功能，就要调用API进行研发，不调用API就无法实现高可用。任何一个服务类的程序要想高可用，必须在设计这个程序时，调用API，然后这个程序在内部一旦发现活动节点故障，就可以通过API中所传递的信息知道需要把自己(服务程序)移动到其他节点运行，这种功能就是通过调用API来实现，但由于互联网上需要运行的服务很多，被高可用的服务也很多，所以基于Messaging Layer提供的API去研发是不太可能的，这就需要把API做成通用功能。

鉴于诸多程序都要借助于Messaging Layer提供的API来完成自我救赎，那么就在服务程序下层再开发一个底层的服务模块，这个服务模块可以调用Messaging Layer提供的API，一旦发现故障，这个服务模块就可以把服务程序转换到其它节点上，同样其他节点也有这个服务模块，因此就把这个服务模块做成通用模块，支撑更多的服务。因此任何一个服务类应用程序就无需自己调用API了，而是由这个通用模块去调用Messaging Layer提供的API，作为向上为每一个服务程序提供平台。这个通用模块就称为资源管理器(Resource Manager，简称RM),这也就是为什么把这个平台上所运行的服务称为资源了。

RM的功能是承上启下的，承上是负责管理每一个应该运行在高可用集群中的某一个活动节点上的各资源，启下是RM要根据Messaging Layer所传递的信息或者通过API所开发的功能来决定多个节点中哪一个节点是活动的哪一个是备用的，一旦活动节点出现故障，就会将活动节点转移到备用节点。同时RM不但能够监控硬件还可以监控软件，比如活动节点运行的httpd服务出现故障，那么RM就会尝试重启httpd程序，重启成功继续使用，不成功会再重启一次，还不成功就要把httpd和IP地址转移到备用节点。

那么如何保证服务和IP地址同进退？这就需要自行定义，需要定义资源和资源之间有一种什么样的关系。但是基于以上叙述可以看出RM是非常忙碌的，所以就在每一个节点上启用了第三个层次，称之为Local Resource Manager：本地资源管理器，是RM的子系统，但可以把RM和LRM当作一个层次来理解，那么RM就是全局的，而LRM是服务当前节点的服务启动等任务，并把当前节点操作结果通知给全局的RM。

资源代理：在centos6启动服务是依靠/etc/rc.d/init.d/下的服务脚本，centos7上是/usr/lib/systemd/system/下的sys unit文件，所以启动服务并不是利用程序包直接启动服务，而是借助于外部的脚本或者外部的服务控制程序来启动的，这些都可以理解为服务的启动代理。这个脚本在资源管理器中通常被称为资源代理，因为他可以负责管理资源的，即启动、停止、查看状态、重启等操作，LRM对本地资源的管理不是自己定义的，而是借助于外部的脚本或者systmectl服务控制程序，这些程序在LRM或者高可用集群中就称之为resource agent，所以对于资源的管理就需要一个又一个的资源代理来实现，而LRM就是通过资源代理来完成资源管理的。高可用集群中的基本层次：LRM和RM是由一个层次来完成，资源代理是由服务脚本来实现的。

 

假如一个集群中7个主机，其中3个连接交换机A，其他四个连接的是交换机B。这两个交换机由网线连接，忽然有一天网站故障，那么这两天交换机就无法进行连接了。那么交换机A上的3台主机和交换B上的4台主机就不是一个集群了，集群被割裂，这就是网络分区。但是这7台主机是没有故障的，只是因为网线的问题无法通信，交换机A的三台主机是可以互相通信的，交换机B的4太交换机也是彼此可以互相通信的。假如交换机A上的一台主机运行了httpd服务，那么在网线出现故障后，交换机B上的4台主机是无法收到运行httpd服务的心跳信息了。那么交换机B上的主机就要找一台主机夺过来IP和启动httpd服务，这会出现什么问题？如果交换机A和交换机B上的主机同时都可以连接到路由上，可以与外界通信，那么就要做出决策：即在网络分区的情况下，只有一个交换机代表集群工作。这是可以设计一个投票系统(vote system)，少数服从多数。所以当出现网络分区的情况下，虽然交换机B上的主机无法连接交换机A上的主机，但是交换机B上的主机数多，所以交换机B上的主机可以把IP夺过来，并运行httpd服务。同时也需要把交换机A上的主机进行切断，防止对IP和httpd服务的拉锯战。那么如何关闭交换机A上的主机呢？隔离有两种方式：STONITH(节点级别隔离)，这种隔离是关闭主机，另一种是Fence: 资源级别的隔离。

 

高可用集群和负载均衡集群的区别是什么？多节点集群有什么用？

对于高可用集群来讲，一个服务在某一时刻只能运行在一个节点上，如果一个服务运行在多个节点上那就是负载均衡集群了，所以高可用集群的法则就是一个服务在某一时刻只能运行在某一个节点上，如果高可用集群中有多个节点的话，其他节点在某一时刻就是闲置的。那就是浪费资源了，解决办法就是让多个节点配置出来多个服务。

假如有5个节点组成的高可用集群，同时运行多个服务。就可以在主机A上运行web服务，把剩余4个作为备用节点，同时在主机2上运行smtp服务，把剩余四个当作备用节点，以此类推，这种就叫N-M模型，N个节点M个服务。同时也可以N对M模型，即5个节点运行4个服务，其中一个是备用节点，即4个运行服务的节点都把这一个备用节点当做备用，这就解决了资源的闲置浪费。

那么问题来了，如何确定4个运行服务的主节点宕机后一定转移到唯一的备用节点呢？

利用优先级来决定是不合适的，这时候需要用到资源管理器RM。资源管理器在节点出现故障需要转移到备用节点时，可以分为两类情况：

1、可以把主机划分为主机组或者资源组，也叫failover domain。把主机A和主机E做成故障转移域，一个节点可以属于多个域。列表如下：

failover domain：

fda: node1, node5

fdb: node2, node5

fdc: node3, node5

fdd: node4, node5

2、资源的约束性：定义资源对节点的倾向性，即不再对主机分组。

比如在5个节点的高可用集群中启动4个服务：web、smtp、nginx、mysql，这4个服务直接在集群启动起来的时候，很难在不分组的情况下让这4个服务分别运行在不同的节点上。解决办法是：额外提供一种属性，为每一个节点对每一个资源的倾向性打分，一个资源可以定义对一个节点的倾向性。比如定义第一个资源即web资源对节点A的倾向性是无穷大，对节点B、C、D、D的倾向性是负无穷大，而对节点D的倾向性是100，这样web服务首先会在节点A上运行，节点A故障后会选择节点E，第二个资源以此类推。

假如在某一个时刻5个节点中有两个节点故障，同时集群中运行的4个服务有两个一定不能同时运行在同一个节点上，所以还需要定义两个服务之间的关系，有的服务之间非常亲密不能分开，有的服务具有排斥性，即排列约束，定义资源的排列关系。

 

资源的约束性：

位置约束：资源对节点的倾向性；

排列约束：资源即服务彼此间是否能运行于同一节点的倾向性；

顺序约束：多个资源启动顺序依赖关系；

 

vote system:投票系统

少数服从多数：quorum

> total/2  //大于总票数的二分之一

with quorum: 拥有法定票数，即大于总票数的二分之一

without quorum: 不拥有法定票数

 

两个节点(偶数个节点)：//很少使用

Ping node  仲裁节点

qdisk   

 

failover：一旦节点出现故障，要转移到其他节点

failback：一旦节点恢复功能，要把资源转移回来

 

高可用集群分为三个层次：Messaging Layer、Resource Manager(子系统Local Resource Managemer)、Resource agent

1、Messaging Layer的实现：这个层次上通常需要一些服务程序，而且要运行在每一个节点上都要有一个服务程序来共同组成。

包括的服务程序：

heartbeat：有三个版本，且功能各不相同

corosync

cman

 

注意：每一个集群资源管理器在配置成高可用集群时，要告诉资源管理器有哪些资源被它管理。所以资源管理器要有一个配置接口，要链接到资源管理器上配置哪一个服务要成为高可用服务、并让资源管理器决定这个服务运行在哪个节点上等等，所以每一个CMR即资源管理器都要有它的配置接口。

2、Cluster Resource Manager(CRM)：集群资源管理器层

heartbeat v1 haresources自带资源管理器 (配置接口：配置文件haresources)  //版本1的名字就叫haresources

heartbeat v2 crm 第二版叫做crm(在每个节点运行一个crmd(5560/tcp)守护进程，有命令行接口，这个命令行接口可以通过简要命令向crmd发配置信息，它会自动转                                //成xml格式，同时这个xml格式的配置文件会发布给每一个节点上的crmd，命令行接口crmsh;补充性的 GUI: hb_gui) 

heartbeat v3, pacemaker (配置接口：crmsh, pcs; GUI: hawk(suse), LCMC, pacemaker-gui)  //pacemaker被独立出来称为一个完整的项目

rgmanager (配置接口：cluster.conf, system-config-cluster, conga(webgui), cman_tool, clustat)

 

一个高可用由Massaging Layer和上面的CRM共同组成，组合方式：

heartbeat v1 (haresources)  //自我就可以运行，但是没有投票系统

heartbeat v2 (crm)          //自我就可以运行，且拥有了自己的投票系统

heartbeat v3 + pacemaker    //第三版本要加上pacemaker才能作为高可用集群使用，因为pacemaker已经独立出来

corosync + pacemaker        //两种组合

corosync v1 + pacemaker (plugin)   //corosync版本1与pacemaker结合使用时，pacemaker是作为corosync的插件运行的

corosync v2 + pacemaker (standalone service)  //orosync版本2与pacemaker结合使用时，pacemaker是作为独立服务运行的  centos7使用此组合

cman + rgmanager                  //如果只用cman，不用corosync，那么cman只能与rgmanager结合。

corosync v1 + cman + pacemaker   //corosync v1投票系统不完善，cman的投票系统很完善，把cman当作corosync的插件

 

RHCS: Red Hat Cluster Suite   红帽集群套件

RHEL5: cman + rgmanager + conga (ricci/luci)

RHEL6: cman + rgmanager + conga (ricci/luci)

 corosync + pacemaker

 corosync + cman + pacemaker

RHEL7: corosync + pacemaker  //corosync第二版本就有自己的投票系统，且比cman更好用，不再用cman了

 

3、Resource Agent：功能是把高可用集群的LRM借助于Resource agent(脚本或工具)完成服务的启动、停止、重启、状态查看等基本管理操作。

资源代理的类型：就是指资源代理服务脚本基于什么样的风格去编写的

service(heartbeat legacy不再这么称呼): /etc/ha.d/haresources.d/目录下的脚本；

LSB: /etc/rc.d/init.d/目录下的脚本；

OCF：Open Cluster Framework

provider:

STONITH:

Systemd:

 

资源类型：

primitive：主资源，原始资源；在集群中只能运行一个实例；

clone：克隆资源，在集群中可运行多个实例；

匿名克隆(无名称)、全局惟一克隆、状态克隆(主动、被动)

multi-state(master/slave主从类型)：克隆资源的特殊实现；多状态资源；

group: 组资源；属于高级资源

属性：

启动或停止；

资源监视

相关性：如果组中的一个资源无法运行，那么组中其他资源也都无法启动。

 

资源属性：在集群的资源管理器上去定义资源时，就需要定义资源的诸多属性

priority: 优先级；如果集群上不允许所有资源都处于活动状态，那么集群管理器会优先停止优先级较低的资源；或者集群运行资源过载时，就会先关掉优先级低的资源。

target-role：started, stopped, master；把资源定义到子群上后，这个资源的默认状态是什么样的

is-managed: 是否允许集群管理此资源；

resource-stickiness: 资源粘性；指资源对当前运行节点的倾向性(比如资源运行的node1节点宕机，转移到node2节点，过一会node1节点恢复了，是否要转移回去，                               //这就要资源取决于对node2的粘性，粘性就是资源对当前节点的默认值，同时还可以另外定义它的约束值，比如资源对于node2的                               //粘性为10，但是留在node2的倾向性为负无穷大)

allow-migrate: 是否允许迁移；

 

资源约束：通过score衡量

位置约束：资源对节点的倾向性；

取值范围：(-oo, +oo):

特殊情况：两个资源被定义为一个组，但第一个资源对于节点1的倾向性为负无穷，第二个资源对于节点1的倾向性为正无穷，但是这两个资源又必须运行在一块，如何？

这就需要运算，三种情况：无穷大定义的值是100万

任何值+无穷大=无穷大

任何值+负无穷大=负无穷大

无穷大+负无穷大=负无穷大

排列约束：资源彼此间是否能运行于同一节点的倾向性；定义两个节点在一块运行的倾向性。

(-oo, +oo)

顺序约束：多个资源启动顺序依赖关系；

(-oo, +oo)

需要两种特殊的用法

Mandatory：强制，相当于正无穷