教你一招：讓集羣慢節點無處可藏

摘要：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的數據。

對慢實例進行監控

場景分析

根據客戶需求分析，可以將客戶需求定義爲集羣中慢節點發生次數與頻率的時間序列及詳情展示。包含以下主要功能：

1. 開啓關閉慢實例檢測功能
2. 配置慢實例檢測參數
3. 採集慢實例信息上報DMS數據庫
4. 將慢實例觸發次數及慢實例名稱等信息以時間序列展示在頁面上

方案整體架構設計

圖 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級數倉黑科技，後臺還可獲取衆多學習資料~

 

點擊關注，第一時間瞭解華爲雲新鮮技術~