教你一招：让集群慢节点无处可藏

摘要： GaussDB 在大规模集群上运行的过程中，随着时间推移，部分节点可能会出现性能严重下降的情况。此时这些节点仍然能对外提供服务，但响应明显变慢，处理同样的请求所需时间较其他正常节点大很多，从而影响了整个集群的性能。这样的节点称为“亚健康节点”，或“慢节点”。

本文分享自华为云社区《GaussDB(DWS)新技术 集群慢节点竟然无处可藏》，原文作者：菜花 。

背景

慢实例简介

GaussDB 在大规模集群上运行的过程中，随着时间推移，部分节点可能会出现性能严重下降的情况。此时这些节点仍然能对外提供服务，但响应明显变慢，处理同样的请求所需时间较其他正常节点大很多，从而影响了整个集群的性能。这样的节点称为“亚健康节点”，或“慢节点”。

大规模集群中亚健康节点的准确识别本身是一个难题。经过深入观察和分析，我们发现节点响应慢还可能是业务倾斜导致的，例如对某些数据的集中访问，或是某些业务需要较多的运算，导致某些节点的工作量剧增。此外，这样的节点不属于性能低下的慢节点。如果单纯通过响应时间判断慢节点容易导致误判，而频繁的误报警则会降低用户的体验，增加工程人员的排查负担。本特性实现需要在充分考虑业务倾斜等因素的前提下，迅速、准确地识别出慢节点。

慢实例的获取机制

Gauss DB 中的等待状态视图 pg_thread_wait_status 可以显示每个实例上各线程的瞬时状态。通过深入分析其监控原理，结合现网的时间，我们发现通过该视图有效地发现响应慢的节点。平均低来讲，节点响应越慢，上面的等待事件就越多，二者存在正相关，因此可以通过查询该视图中各节点的等待事件数量来衡量节点响应的快慢。根据现网的经验，如果等待状态视图中等待的 DN 大多数是同一个节点上的 DN，则这个节点大概率是慢节点。

以图 1 所示的工行集群上的等待状态视图查询结果为例，890 这个节点上的事件等待数量在连续多次查询中均为全网之冠，且占全网等待数量的比例在 50%以上。最终硬件检测表明 890 节点确实存在硬件故障，导致运行缓慢。

GaussDB 的数据节点（Datanode）采用主备模式。如果一个物理机器上的 Datanode 全是备机，该物理机器并不会直接对外提供服务，也无法通过 pg_thread_wait_status 视图查询等待事件的数量。但是主 DN 需要向备 DN 同步日志。如果这样的“全备机”物理机器恰好是一个慢节点，由于同步日志缓慢，会影响主 DN 的性能。虽然主机上的 pg_thread_wait_status 视图等待数量会有所增加，但因为该物理机器对应的主 DN 被分散到多个物理节点上，单个物理节点上等待数量可能并不能达到阈值。针对这种情况，还需要对等待视图中主 DN 对应的备 DN 做进一步计算，间接得到“全备机”物理机器的等待数量。

图 1.1 通过等待视图识别慢节点

由于主备切换，数据倾斜等原因，集群中各节点的负载并不均衡，负载高可能也会造成节点响应缓慢。为了避免误报，需要消除负载倾斜对于亚健康节点识别的干扰。为了简化判断，我们进一步假定负载倾斜和故障不会同时出现在同一节点上。也就是说，如果一个节点的负载水平较高，响应慢被认为是正常的，不会被当成慢节点而告警。

节点的负载水平可以通过数据的访问量和运算量来衡量，而后者可以通过 IO 的数量、消耗 CPU 时间以及网络数据流量来进行量化计算。GaussDB 内部对 IO 的数量（block 数）、CPU 时间和网络数据流量进行了打点统计，并通过多种视图呈现出来。通过定期访问这些视图，可以获得节点在单位时间内的工作量，进而获得每个节点在各个时段的负载水平。

与等待事件的数量一样，“全备机”的物理机器的负载水平，也需要通过其对应的主 DN 的负载水平间接推算。由于备机很少参与运算，主要工作是接收日志，因此主要通过主 DN 的 IO 数量和网络流量来衡量备机的繁忙程度。并且由于间接推算的准确性相对较差，只有“全备机”节点才会采用这种方式。只要某台物理机器上有主 DN 的存在，就直接采用主 DN 的数据。

对慢实例进行监控

场景分析

根据客户需求分析，可以将客户需求定义为集群中慢节点发生次数与频率的时间序列及详情展示。包含以下主要功能：

a. 开启关闭慢实例检测功能

b. 配置慢实例检测参数

c. 采集慢实例信息上报 DMS 数据库

d. 将慢实例触发次数及慢实例名称等信息以时间序列展示在页面上

方案整体架构设计

图 2.1 慢实例监控整体架构图

整体方案属于慢实例检测端到端的新增项，并调用健康检查相关模块进行慢实例数据生产。

① dms-agent 调用健康检查脚本并传入 collection 下发的配置参数，主要操作包括初始启动调用，以及进程中断重启调用；

② 健康检查脚本采集慢节点数据到用户数据库中

③ dms-agent 通过查库获取相关数据

④ dms-agent 根据 dms-collection 下发的上报频率进行数据上报

⑤dms-collection 接收 dms-agent 上报的数据进行 dms 数据库入库等。

⑥dms-monitoring 查询 dms 数据库获取慢节点数据展示到 dws-console 前端页面

⑦dws-console 通过 dms-monitoring 下发启停配置到 dms-agent,并通过 dms-monitoring 将启停信息持久化到 dms 数据库中； dws-console 通过 dms-monitor 持久化监控参数配置到 dms 数据库中。

⑧dms-monitoring 将修改后的配置通过 grpc 下发到 dms-agent，dms-agent 按照新的上报频率以及配置进行数据采集上报

⑨ dms-agent 在配置更新后，按照新配置进行健康检查脚本的重启操作。

慢实例数据详解及数据处理

慢实例表结构设计

drop table if exists dms_mtc_cluster_slow_inst cascade;


create table dms_mtc_cluster_slow_inst(
      ctime bigint not null,                                                   -- 采集时间
      virtual_cluster_id int not null,                                       -- 虚拟集群id
      check_time bigint,                                                        -- 检测时间
      host_id int,                                                                   -- 主机id
      host_name varchar(128),                                             -- 主机名
      inst_id varchar(64),                                                      -- 集群分配的实例id
      inst_name  varchar(128),                                             -- 实例名称
      primary key(virtual_cluster_id, inst_id, check_time)
);

慢实例数据处理

数据入库 Dms-collection 接收 agent 上报的数据进行入库

insert into
       dms_mtc_cluster_slow_inst (ctime, virtual_cluster_id, check_time, host_id,host_name, host_id, inst_name)
values
      (#{sinst.ctime}, #{ sinst.virtual_cluster_id}, #{sinst.check_time},#{sinst.host_id}, #{sinst.host_name}, #{sinst.inst_id}, #{sinst.inst_name});

数据查询

Dms-monitoring 查询慢实例时间序列以及数量

select
      check_time, count(*) as slow_inst_num
from
      dms_mtc_cluster_slow_inst
where
      virtual_cluster_id =
            (select
                    virtual_cluster_id
             from
                    dms_meta_cluster
             where
                    cluster_id = #{clusterId})
and
      check_time >= #{from}
and
      check_time <= #{to}
group by
      check_time;

Dms-monitoring 查询慢实例数据详情

select
      t1.check_time, t1.host_name, t1.inst_name, t2.trigger_times
from
             (select
                    check_time, host_name, inst_name
             from
                    dms_mtc_cluster_slow_inst
             where
                    virtual_cluster_id = (
                           select
                                  virtual_cluster_id
                           from
                                  dms_meta_cluster
                           where
                                  cluster_id = #{clusterId})
             and
                    check_time = #{checkTime}) as t1
      inner join
             (select
                    inst_name, count(*) as trigger_times
             from
                    dms_mtc_cluster_slow_inst
             where
                    virtual_cluster_id = (select
                           virtual_cluster_id
                    from
                           dms_meta_cluster
                    where
                           cluster_id = #{clusterId})
             and
                    check_time >= (#{checkTime} - 86400000)
             and
                    check_time <= #{checkTime}
             group by
                    inst_name) as t2
      on
             t1.inst_name = t2.inst_name;

想了解 GuassDB(DWS)更多信息，欢迎微信搜索“GaussDB DWS”关注微信公众号，和您分享最新最全的 PB 级数仓黑科技，后台还可获取众多学习资料~

点击关注，第一时间了解华为云新鲜技术~

标签：实例,inst,id,cluster,dms,集群,一招,节点
来源： https://blog.51cto.com/u_15214399/2830518