Linux 高可用（HA）集群基本概念详解

Linux 高可用（HA）集群基本概念详解

LB, HA, HP, hadoop

集群的分类

LB:

    传输层：lvs

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

HA:

    vrrp: keepalived

    AIS: heartbeat, OpenAIS, corosync/pacemaker, cman/rgmanager(conga) RHCS

一、高可用集群的定义

 

高可用集群，英文原文为High Availability Cluster，简称HACluster，简单的说，集群（cluster）就是一组计算机，它们作为一个整体向用户提供一组网络资源。这些单个的计算机系统 就是集群的节点（node）。

高可用集群的出现是为了使集群的整体服务尽可能可用，从而减少由计算机硬件和软件易错性所带来的损失。如果某个节点失效，它的备援节点将在几秒钟的时间内接管它的职责。因此，对于用户而言，集群永远不会停机。

高可用集群软件的主要作用就是实现故障检查和业务切换的自动化。只有两个节点的高可用集群又称为双机热备，即使用两台服务器互相备份。当一台服务器出现故障时，可由另一台服务器承担服务任务，从而在不需要人工干预的 情况下，自动保证系统能持续对外提供服务。双机热备只是高可用集群的一种，高可用集群系统更可以支持两个以上的节点，提供比双机热备更多、更高级的功能，更能满足用户不断出现的需求变化。

二、高可用集群的衡量标准

HA(High Available), 高可用性群集是通过系统的可靠性(reliability)和可维护性(maintainability)来度量的。

故障场景：

    硬件故障：

        设计缺陷

        使用过久自然损坏

        人为故障

        …… ……

    软件故障

        设计缺陷

        bug

        人为误操作

        ……

HA=MTTF/(MTTF+MTTR)*100%        

    MTTF (Mean Time To Failure，平均无故障时间)

    MTBF (Mean Time Between Failure，平均失效间隔)

    MTTR (Mean Time To Repair，平均修复时间)

具体HA衡量标准:

99% 一年宕机时间不超过4天

99.9% 一年宕机时间不超过10小时

99.99% 一年宕机时间不超过1小时

99.999% 一年宕机时间不超过6分钟

    0

        90%, 95%, 99%

        99.9%, 99.99%, 99.999%

提供冗余：

三、高可用集群的层次结构

Messaging Layer（集群的消息管理）:Messaging主要用于节点之间传递心跳信息，也称为心

跳层。节点之间传递心跳信息可以通过广播，组播，单播等方式。成员关系（Membership）层，这层最重要的作用是主节点（DC）通过Cluster Consensus Menbership Service（CCM或者CCS）这种服务由Messaging层提供的信息，来产生一个完整的成员关系。这层主要实现承上启下的作用，承上，将下层产生的信息生产成员关系图传递给上层以通知各个节点的工作状态；启下，将上层对于隔离某一设备予以具体实施。

    heartbeat v1 v2 v3

    corosync v1 v2

    cman

Cluster Resource Manager(CRM)集群资源管理器: 真正实现集群服务的层。在该层中每个节点都运行一个CRM，它能为实现高可用提供核心组件，包括资源定义，属性等。在每一个节点上CRM都维护有一个CIB(集群信息库 XML文档)和LRM（本地资源管理器）组件。对于CIB，只有工作在DC（主节点）上的文档是可以修改的，其他CIB都是复制DC上的那个文档而来的。对于LRM,是执行CRM传递过来的在本地执行某个资源的执行和停止的具体执行人。当某个节点发生故障之后，是由DC通过PE（策略引擎）和TE（实施引擎）来决定是否抢夺资源。

    heartbeat v1 haresources (配置接口：配置文件haresources)

    heartbeat v2 crm (在每个节点运行一个crmd(5560/tcp)守护进程，有命令行接口crmsh; GUI: heartbeat gui–hb_gui)

    heartbeat v3, pacemaker (配置接口：crmsh, pcs; GUI: hawk(suse), LCMC, pacemaker-gui)

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

    组合方式：

        heartbeat v1 (haresources) 一体化的

        heartbeat v2 (crm)    一体化的

        heartbeat v3 + pacemaker

        corosync + pacemaker:

            corosync v1 + pacemaker (plugin)（投票系统不够完善）

            corosync v2 + pacemaker (standalone service)

                    

        cman + rgmanager （rgmanager弱爆了，所以cman又有了第二种方式）

        corosync v1 + cman + pacemaker（corosync投票系统不完善需要借助cman完善的投票系统）

 

        RHCS: Red Hat Cluster Suite

            RHEL5: cman + rgmanager + conga (ricci/luci)（基于web接口的全生命周期的集群管理程序）

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

                corosync + pacemaker

                corosync + cman + pacemaker（cman当成corosync插件解决corosync投票系统问题，分布式文件系统的锁，集群锁管理器（lock manager ）支持不太好，诡异不好用）

            RHEL7: corosync （v2）+ pacemaker （corosync v2 就自己支持投票系统，而且投票系统比cman的还好）

Resource Agent(资源代理层)集群资源代理(能够管理本节点上的属于集群资源的某一资源的启动，停止和状态信息的脚本)，

资源代理分为：

    service: /etc/ha.d/haresources.d/目录下的脚本；heartbeat legacy(传统的)有的服务本身没有脚本额外补充的脚本比如IP地址。

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

    OCF：Open Cluster Framework(比LSB更专业，更加通用)子类别有更多的子类别，遵循ocf规范，提供脚本受高可用高可用lrm管理。

        provider:开放的有提供者

        STONITH: 爆头专用，通常用stonith厂商开发

    Systemd: systemctl

    Legacy heartbeat（v1版本的资源管理）

 

四、核心组件的具体说明：

1.ccm组件（Cluster Consensus Menbership Service）：作用，承上启下，监听底层接受的心跳信息，当监听不到心跳信息的时候就重新计算整个集群的票数和收敛状态信息，并将结果转递给上层，让上层做出决定采取怎样的措施，ccm还能够生成一个各节点状态的拓扑结构概览图，以本节点做为视角，保证该节点在特殊情况下能够采取对应的动作。

2.crmd组件（Cluster Resource Manager，集群资源管理器，也就是pacemaker）：实现资源的分配，资源分配的每个动作都要通过crm来实现，是核心组建，每个节点上的crm都维护一个cib用来定义资源特定的属性，哪些资源定义在同一个节点上。

3.cib组件（集群信息基库，Cluster Infonation Base）：是XML格式的配置文件，在内存中的一个XML格式的集群资源的配置文件，主要保存在文件中，工作的时候常驻在内存中并且需要通知给其它节点，只有DC上的cib才能进行修改，其他节点上的cib都是拷贝DC上。配置cib文件的方法有，基于命令行配置和基于前台的图形界面配置。

4.lrmd组件（Local Resource Manager，本地资源管理器）：用来获取本地某个资源的状态，并且实现本地资源的管理，如当检测到对方没有心跳信息时，来启动本地的服务进程等。

5.pengine组件：

PE（Policy Engine）：策略引擎，来定义资源转移的一整套转移方式，但只是做策略者，并不亲自来参加资源转移的过程，而是让TE来执行自己的策略。

TE（Transition Engine）： 就是来执行PE做出的策略的并且只有DC上才运行PE和TE。

6.stonithd组件

STONITH(Shoot The Other Node in the Head，”爆头”)， 这种方式直接操作电源开关，当一个节点发生故障时，另 一个节点如果能侦测到，就会通过网络发出命令，控制故障节点的电源开关，通过暂时断电，而又上电的方式使故障节点被重启动， 这种方式需要硬件支持。

STONITH应用案例（主从服务器），主服务器在某一端时间由于服务繁忙，没时间响应心跳信息，如果这个时候备用服务器一下子把服务资源抢过去，但是这个时候主服务器还没有宕掉，这样就会导致资源抢占，就这样用户在主从服务器上都能访问，如果仅仅是读操作还没事，要是有写的操作，那就会导致文件系统崩溃，这样一切都玩了，所以在资源抢占的时候，可以采用一定的隔离方法来实现，就是备用服务器抢占资源的时候，直接把主服务器给STONITH，就是我们常说的”爆头 “。

 

五、资源的概念、约束。

resource：其实就是服务

（1）资源类型：

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

2、clone：克隆资源，在集群中可运行多个实例；stonith：每个节点都可以克隆一个或多个

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

3、multi-state(master/slave)：克隆资源的特殊实现；多状态资源；只能运行两份，一主多从（一般来说一主一从）

4、group:将多个资源归为一个组，同进同退。ip httpd 共享存储 nginx 那么我们可以定义于组

    特性：

    启动或停止：

    资源监视：监视资源是否正常

    相关性：比如一个资源无法运行，其它也无法运行

 

（2）资源属性：

    priority: 优先级；

    target-role：started, stopped, master; 那种状态下保存此资源

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

    resource-stickiness: 资源粘性；资源对当前这个节点的倾向性。

    allow-migrate: 是否允许迁移；yes or no

 

（3）隔离：network partition：一旦网络发生了分区，就得使用vote system来确定那部分资源继续提供服务，少数服从多数（票数多的一方继续提供服务）。

quorum > total/2 with quorum: 拥有法定票数，否则without quorum: 不拥有法定票数。

如果有的资源绝对不允许同时在提供服务（会引起系统奔溃或者系统出故障）。如果网络恢复了，那么开始提供服务的一方就会来抢占资源造成系统的故障。

我们就得使用隔离操作。

隔离：

1、shoot the other node on the head 节点级别隔离 （比如stonith电源）

2、Fence: 资源级别的隔离 （比如向存储交换机上某一接口发出关闭某相应接口的指令完成，阻止另一台设备访问存储资源）。

两节点之间网络分区怎么办？谁都不能假设它是大于半数，必须借助于第三方仲裁机制。

1、共同的网关，只能有一人能够联系到网关。设置仲裁节点，靠ping去探测节点。

2、仲裁盘，共享存储。qdisk(quorum disk)

    

（4）failover domain：故障转移域

N–M模型：

    fda: node1, node5

    fdb: node2, node5

    fdc: node3, node5

    fdd: node4, node5

    资源的约束性（score）：

        位置约束：资源对节点的倾向性；类似于优先级，数字越高的越优先，数字越小的越靠后，资源对节点的倾向性；(-oo, +oo):

            任何值+无穷大=无穷大

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

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

        排列约束：资源彼此间是否能运行于同一节点的倾向性；有的两个服务之间不能运行在同一台服务器上的情况，资源彼此间是否能运行于同一节点的倾向性；(-oo, +oo)

        顺序约束：多个资源启动顺序依赖关系；服务启动的顺序。多个资源启动顺序依赖关系；(-oo, +oo)

    failover——>failback

 

Current DC：制定的协调员，整个集群内选出来的做全局事物决策的节点。

crm(live)configure# property default-resource-stickiness=0

centos 6 上关掉一个任然会显示without quorum资源部会转移

crm(live)configure# property no-quorum-policy=

 

Messaging Layer:

        heartbeat v1, v2, v3 v3版不怎么活跃了

        corosync v1, v2(votequorum)主用centos 6 默认corosync v1 centos 7 默认corosync v2拥有 vote system qourm

        OpenAIS————>cman

    CRM:

        pacemaker

            配置接口：crmsh (agentless), pssh

                     pcs (agent), pcsd pcsd是运行在各节点的守护进程它能接受pcs控制指令

                conga(ricci/luci) ricci 运行在各节点上的守护进行而luci是向ricci发送控制指令，centos 6.5 后ricci被废了centos7后被彻底废了，pcsd luci也可以基于web gui接口也能向pcsd发送控制指令。

            配置方式：

                group:failover domain(故障转移域)

                constraint：基于约束

        rgmanager(cman)

            resource group:资源组的配置——>failover domain(故障转移域)

 

        配置：

            全局属性：property, stonith-enable等等；

            高可用服务：资源，通过RA

 

    RA:

        LSB: /etc/rc.d/init.d/

        systemd：/etc/systemd/system/multi-user.wants

            处于enable状态的服务；

        OCF: [provider]

            heartbeat

            pacemaker

            linbit drdb 通用服务类型（master/slave）

        service:不完全是lsb也不完全是ocf但是它可以在各种linux发行版上使用

        stonith：专用于stonith类型的资源

 

    高可用集群的可用方案：

        heartbeat v1（不常用）

        heartbeat v2 （不常用）

        heartbeat v3 + pacemaker X （不常用）

        corosync + pacemaker （centos 6.6之前默认corosync v1，使用v2得手动编译，支持也不太好，centos 7默认是v2+pacemaker就比较好了）

        cman + rgmanager （虽然cman有投票系统但是rgmanager 弱爆了）

        corosync + cman + pacemaker （centos 6折中方案有cman的投票系统，也能用pacemaker）

 

        corosync v2+ pacemaker （centos 7） 漂移服务，负担稍大

        keepalived（vrrp）更重要浮动ip，负担小        

 

    # ps -aux | prep pacemaker

    root 9534 0.0 0.8 132652 8336 ? Ss 04:31 0:00 /usr/sbin/pacemakerd -f

    haclust+ 9536 0.1 1.6 135324 15364 ? Ss 04:31 0:00 /usr/libexec/pacemaker/cib

    root 9537 0.0 0.8 135604 7900 ? Ss 04:31 0:00 /usr/libexec/pacemaker/stonithd

    root 9538 0.0 0.5 105092 5012 ? Ss 04:31 0:00 /usr/libexec/pacemaker/lrmd

    haclust+ 9539 0.0 0.8 126920 7628 ? Ss 04:31 0:00 /usr/libexec/pacemaker/attrd

    haclust+ 9540 0.0 2.2 153104 20864 ? Ss 04:31 0:00 /usr/libexec/pacemaker/pengine

    haclust+ 9541 0.1 1.2 186360 11560 ? Ss 04:31 0:00 /usr/libexec/pacemaker/crmd

HA集群的工作模型：

        A/P：两节点，active, passive；工作于主备模型；(关闭投票，或者使用仲裁盘，仲裁ip节点)

        without-quorum-policy={stop(停止)|ignore(忽略仲裁)|suicide(自杀)|freeze(不再接受心情求，老请求继续服务到结束)}

        A/A：两节点，active/active，双主模型；pacemaker可以让一个ip跑在两台server上（ipaddr里面专门参数，双活动有一定风险一般很少使用）

        N-M：N>M, N个节点，M个服务；活动节点数为N，备用节点数为N-M

        N-N：N个节点，N个服务；

    network partition：

        如果没有投票系统，每个分裂出来的小片都会认为自己就是集群—–> brain-split：块级别的共享存储时，非常危险（元数据与数据将不一致）—–>vote quorum:with quorm　> total 1/2 继续服务

        without quorum <= total1/2

        当发生分裂不再拥有法定票数的一方怎么去处理自己：stop(默认) —-> stonith

    cap：

        consistency:一致性

        availiablity：可用性

        partition tolerance：分区容错（把不具有法定票数的一方踢掉）

        大多满足3者中两者，而考虑最多的是ap。

 

    资源运行的倾向性（资源转移倾向性）：

        rgmanager:

            failover domain, node priority

        pacemaker：

            资源黏性：资源倾向于留在当前的分数（-oo, +oo）

            资源约束：

                位置约束：资源对某节点运行的倾向性（-oo, +oo）

                    inf: 正无穷

                    -inf: 负无穷

                    n:

                    -n:

                排列约束：定义资源彼此间的倾向性（是否在一起）

                    inf:

                    -inf:

                    n, -n

                顺序约束：属于同一服务的多个资源运行在同一节点时，其启动及关闭的次序约束；

                    A –> B –> C

                    C –> B –> A

 

            例如：定义高可用的web服务，有三个资源vip, httpd, nfs，思考，如何限制它们要运行于同一节点，并且如何按vip–>nfs–>httpd的次序启动？

                排序约束：inf

                顺序约束：mandatory

 

    资源类型：

        primitive, native: 主资源，其仅能运行某一节点

        group: 组资源，可用于实现限制多个资源运行于同一节点及对此些资源统一进行管理

        clone: 克隆资源，一个资源可以运行于多个节点；

            应该指定：最大克隆的份数，每个节点最多可以运行的克隆；

        master/slave: 主从资源，特殊的克隆资源；

 

    pacemaker的crm的角色：

        DC：Designated Coordinator