星星博客 »  > 

疑难杂症:系统状态正常,LInux双机Pacemaker为什么还要切换?

上个周末我们的生产再次发生一个问题,一套系统状态明明是正常的,监控上没有任何报警,可是Cent OS操作系统的双机软件Packmaker还是发起切换了。由于单位主机的日志涉及敏感信息,而且无法连通外网,不方便与Github进行联动查询源代码,不过当时日志显示当时的两条info信息还是引起了我的注意,我们知道throlle是节流阀的意思,这个信息虽然连warning的级别都没到,但是也许还是提示系统在切换时的状态可能并不正常。

Apr 17 13:02 [61870] **** crmd: info: throttle_send_command:new throttle mode:0100(was 0100)

Apr 17 13:02 [61870] **** crmd: notice: throttle_check_thresholds: High CPU load detected 169.1

而且这个问题的分析不需要什么基础知识,只需要结合代码一起分析就行了,因此我决定在本周的《疑难杂症》先插播这篇,下周再继续聊《内存富裕,为何申请不到》的话题,还是老大跌笔者还是周末在阿里云上申请两台处于同一Region的ECS,进行场景复现。

PaceMaker简介

这里我们先简要介绍一下PaceMaker这个双机切换软件,这里笔者必须说明目前双机互备的架构已经比较落后了,不过PaceMaker其实并不是一个仅针对双机切换场景的切换软件,它也完全可以支持多节点的集群架构,因此先从PaceMaker入手学习高可用架构还是一个不错的学习路径。Pacemaker的代码是在这里的https://github.com/ClusterLabs/pacemaker/,简单抽象的话其架构如下图:

 

Rgmanager:可以看到一个典型的其核心就是rgmanager,这也是是RHCS中的一个核心服务,这是一个系统的service,它负责管理各种resource和cman。

cman一般在双机互备体系运行时,都会使用ping对端IP的方式来检测另一节点的健康状态,不过出现比如心跳连接断开,两台服务器都无法探测对方的运行情况也在所难免,双方也都各自认为自己是主节点,这也就是我们常说的脑裂在这种情况下,高可用软件要求通过Fence机制来保障系统切换时,先发出fence信息的主机可以在切换时拿到所有的资源,保证切换正常进行。

一般的PC服务器主机都配备有Fence口,他是一个独立于服务器其它部件的硬件电源管理接口,这个网络可以直接强制服务器的重启,以强制被Fence的节点释放资源,保证被fence的节点不再进行任何操作

cman就是掌管心跳检测和Fence机制的服务,如果把cman类比对集群的RAFT投票机制时,可以看成是投票服务节点。

Resources(资源)在Pacemaker的体系中Resources 指的是组成一个应用服务所需要一切资源。包括应用程序、虚拟IP、文件系统以及检查应用程序运行状态的脚本当然资源之间是有层次关系比如应用程序的启动往往需要在虚拟IP文件系统都已经正常的情况下才能进行。

一般切换过程:以我们本次要分析的案例来说,典型的pacemaker的切换过程如下:

  1. 首先是虚拟IP,文件系统(VG)或者检测脚本捕获到异常,并向rgmanager上报。
  2. rgmanager会通知cman向对端(也就是备机)同步信息。
  3. 对端的cman收到信息后会向自己的rgmanager报告,备机rgmanager会决定切换。
  4. resource这时会由主机切换到备机,如果遇到主机不释放的情况,备机的cman会在rgmanager的命令下将主机fence出集群。

 

pacemaker异常切换的问题分析

其实这个问题只需要定位到Pacemaker限流机制的源代码

https://github.com/ClusterLabs/pacemaker/blob/master/daemons/controld/controld_throttle.c

也就迎刃而解了。

1.不可关闭的限流。首先我们可以看到在Pacemaker对于当前系统占用率计算时,使用的是代码内的宏进行定义,这也就是限流是Pacemaker的内部机制,说我们不能通过配置文件去修改它的限流机制。

#define THROTTLE_FACTOR_LOW    1.2

#define THROTTLE_FACTOR_MEDIUM 1.6

#define THROTTLE_FACTOR_HIGH   2.0

2 限流模式分类:我们看到Pacemaker分为以下几种限流模式,分别是

  1. extreme极限限流
  2. high高限流
  3. med中等
  4. Low低限流
  5. None不限流

代码如下:

enum throttle_state_e {

    throttle_none       = 0x0000,

    throttle_low        = 0x0001,

    throttle_med        = 0x0010,

    throttle_high       = 0x0100,

    throttle_extreme    = 0x1000,

};

而他具体的工作模式是由CPU的核心数以及CPU的负载共同决定的。具体代码如下:

throttle_mode(void)

{

    enum throttle_state_e mode = throttle_none;



#if SUPPORT_PROCFS

    unsigned int cores;

    float load;

    float thresholds[4];



    cores = pcmk__procfs_num_cores();

    if(throttle_cib_load(&load)) {

        float cib_max_cpu = 0.95;



        /* The CIB is a single-threaded task and thus cannot consume

         * more than 100% of a CPU (and 1/cores of the overall system

         * load).

         *

         * On a many-cored system, the CIB might therefore be maxed out

         * (causing operations to fail or appear to fail) even though

         * the overall system load is still reasonable.

         *

         * Therefore, the 'normal' thresholds can not apply here, and we

         * need a special case.

         */

        if(cores == 1) {

            cib_max_cpu = 0.4;

        }

        if(throttle_load_target > 0.0 && throttle_load_target < cib_max_cpu) {

            cib_max_cpu = throttle_load_target;

        }



        thresholds[0] = cib_max_cpu * 0.8;

        thresholds[1] = cib_max_cpu * 0.9;

        thresholds[2] = cib_max_cpu;

        /* Can only happen on machines with a low number of cores */

        thresholds[3] = cib_max_cpu * 1.5;



        mode = throttle_check_thresholds(load, "CIB load", thresholds);

    }



    if(throttle_load_target <= 0) {

        /* If we ever make this a valid value, the cluster will at least behave as expected */

        return mode;

    }



    if(throttle_load_avg(&load)) {

        enum throttle_state_e cpu_load;



        cpu_load = throttle_handle_load(load, "CPU load", cores);

        if (cpu_load > mode) {

            mode = cpu_load;

        }

        crm_debug("Current load is %f across %u core(s)", load, cores);

    }

#endif // SUPPORT_PROCFS

    return mode;

}

3.限流机制:而接下来的关键点在这个函数throttle_get_job_limit中,如果Pacemaker在限流模式,那么其运行的job数量将被限制,其中极端extreme和high的情况一样,都是只有一个任务可以被放行,其余任务均被阻断。

throttle_get_job_limit(const char *node)

{

    int jobs = 1;

    struct throttle_record_s *r = NULL;



    r = g_hash_table_lookup(throttle_records, node);

    if(r == NULL) {

        r = calloc(1, sizeof(struct throttle_record_s));

        r->node = strdup(node);

        r->mode = throttle_low;

        r->max = throttle_job_max;

        crm_trace("Defaulting to local values for unknown node %s", node);



        g_hash_table_insert(throttle_records, r->node, r);

    }



    switch(r->mode) {

        case throttle_extreme:

        case throttle_high:

            jobs = 1; /* At least one job must always be allowed */

            break;

        case throttle_med:

            jobs = QB_MAX(1, r->max / 4);

            break;

        case throttle_low:

            jobs = QB_MAX(1, r->max / 2);

            break;

        case throttle_none:

            jobs = QB_MAX(1, r->max);

            break;

        default:

            crm_err("Unknown throttle mode %.4x on %s", r->mode, node);

            break;

    }

    return jobs;

}

这个造成的直接后果,就是rgmanager无法通过script的运行得知应用具体的运行状态,如果系统长时间负载过高,则很有可能会被自身的rgmanager检测认为异常,从而通知对端主机进行切换。

再结合到我们刚刚的图来说,其余就是由于限流script应用检查脚本未被调起,从而被主机的rgmanager认为存在异常,从而触发双机切换机制进行了切换。

 

应对建议

  1. 避免服务器连续出现CPU使用过高的情况:我们看到Pacemaker的限流模式不能关闭,因此首先要避免CPU使用率过高的问题。
  2. 尽量将双机切换的探测超时时间调长:如果CPU使用率不能优化,就只能延长Pacemaker的超时时间。

3.减少resource的数量,以减少Pacemaker需要调度的任务数量。日常实践中经常有同一个节点运行多个应用的情况,如果使用pacemaker不建议把这些应用的探测脚本拆分进行分别检测,因为在限流模式开启时,Pacemaker并不会判断任务的难易程度,而只是简单的限制任务的个数,因此减少任务个数其实能从很多程度上规避这个问题的发生。如果每个应用都

相关文章