上个周末我们的生产再次发生一个问题，一套系统状态明明是正常的，监控上没有任何报警，可是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的切换过程如下：
- 首先是虚拟IP,文件系统（VG）或者检测脚本捕获到异常，并向rgmanager上报。
- rgmanager会通知cman向对端(也就是备机）同步信息。
- 对端的cman收到信息后会向自己的rgmanager报告，备机rgmanager会决定切换。
- 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分为以下几种限流模式，分别是
- extreme极限限流
- high高限流
- med中等
- Low低限流
- 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认为存在异常，从而触发双机切换机制进行了切换。
应对建议
- 避免服务器连续出现CPU使用过高的情况：我们看到Pacemaker的限流模式不能关闭，因此首先要避免CPU使用率过高的问题。
- 尽量将双机切换的探测超时时间调长：如果CPU使用率不能优化，就只能延长Pacemaker的超时时间。
3.减少resource的数量，以减少Pacemaker需要调度的任务数量。日常实践中经常有同一个节点运行多个应用的情况，如果使用pacemaker不建议把这些应用的探测脚本拆分进行分别检测，因为在限流模式开启时，Pacemaker并不会判断任务的难易程度，而只是简单的限制任务的个数，因此减少任务个数其实能从很多程度上规避这个问题的发生。如果每个应用都
转载：https://blog.csdn.net/BEYONDMA/article/details/115819997