5種GaussDB ETCD服務異常實例分析處理
摘要：一文帶你細數幾種ETCD服務異常實例狀態。
本文分享自華為雲社區《【實例狀態】GaussDB ETCD服務異常》，作者：酷哥 。
首先確認是否是虛擬機、網絡故障
虛擬機故障導致ETCD服務異常告警
問題現象
管控面上報etcd服務異常告警，虛擬機發生重啟，熱遷移、冷遷移，HA等動作。
問題分析及界定
在告警信息中找到實例ID、節點ID、虛擬機ID，在管控面查看虛擬機狀態是否正常，能否正常登錄，
如果虛擬機異常無法登錄，聯繫IaaS技術支持修復虛擬機。
檢查虛擬機是否發生過重啟，熱遷移、冷遷移、HA等動作，例如內存、網卡等問題引起熱遷移。
處理步驟
聯繫IaaS技術支持修復虛擬機，確認虛擬機故障原因，例如內存、網卡等問題引起熱遷移。
網絡故障導致ETCD服務異常告警
問題現象
管控面上報etcd服務異常告警，虛擬機無法登錄或ping通其他節點IP, 或者監控顯示網絡有異常。
問題分析及界定
在該節點上ping其他節點IP，測試是否ping通。
如果ping不通，執行步驟（1）（2），檢查該節點網絡、IP配置、防火牆配置等。
如果ping通，執行步驟（3）確認告警時間點網絡是否斷開。
（1）檢查IP是否正常：
ifconfig查看etcd使用的IP是否存在，如果不存在，排查IP配置丟失原因，常見原因是虛擬機重啟後IP沒有重新配置，導致丟失。
（2）檢查防火牆是否正常
在Ruby用戶下查看etcd的IP和端口： ps ux | grep etcd
在root用戶下iptables -L命令檢查防火牆是否限制了IP和端口，如果有限制，去掉防火牆限制。
(3) 查看etcd日誌
進入Ruby用戶
cd $GAUSSLOG/cm/etcd
查看對應時間點的etcd_xxx.log日誌，如果有如下日誌，可能是etcd節點間網絡斷開, 或者對端的etcd進程down，導致本端etcd連接斷開。
排查網絡原因或對端的etcd進程是否重啟，網絡原因可能是網絡斷開，網卡故障，也有可能是虛擬機故障。
grpc: Server.processUnaryRPC failed to write status: connection error: desc = “transport is closing”
rafthttp: lost the TCP streaming connection with peer c797ab3a61e2ea55 (stream MsgApp v2 reader)
etcdserver: failed to reach the peerURL(// X.X.X.X:X) of member c797ab3a61e2ea55 (Get “//X.X.X.X:X/version”: dial tcp X.X.X.X:X: i/o timeout)
rafthttp: health check for peer c797ab3a61e2ea55 could not connect: dial tcp X.X.X.X:X: i/o timeout (prober “ROUND_TRIPPER_RAFT_MESSAGE”)
處理步驟
處理步驟同上，已說明。
負載過重導致ETCD服務異常警告
問題現象
管控面上報etcd服務異常告警, 磁盤IO/CPU/內存 很高.
問題分析及界定
進入Ruby用戶
cd $GAUSSLOG/cm/etcd
查看對應時間點的etcd_xxx.log日誌，告警時間點有如下日誌，說明etcd節點負載過重, 磁盤IO、CPU等壓力大。
2021-04-09 10:57:40.112936 W | wal: sync duration of 2.00201804s, expected less than 1s ===通常這個表示磁盤IO壓力大。
2021-04-09 10:57:40.112993 W | etcdserver: failed to send out heartbeat on time (exceeded the 1s timeout for 2.124414ms, to c8eccd97bed22939)
2021-04-09 10:57:40.112999 W | etcdserver: server is likely overloaded
2021-04-09 10:57:43.126444 W | etcdserver: read-only range request “key:\”/Ruby/ignoreNodeNumKey\” ” with result “error:context canceled” took too long (1.999877971s) to execute
cd $GAUSSLOG/cm/cm_agent
搜索對應時間點的cm_agent-xxx.log, 如果有如下日誌，表示當時磁盤io比較高， io util 100 表示磁盤io 達到100%
2021-04-09 11:06:24.047 tid=15822 LOG: device vdb1, tot_ticks 889640579, cputime 1798651342, io util 100
處理步驟
1、在管控面查看該節點當時磁盤IO、CPU、內存監控指標是否很高，
示例1：數據盤寫延時在16:00左右升高，影響etcd狀態。
示例2： etcd故障時刻，cpu、內存、磁盤寫延時都有增長，尤其是磁盤寫延時很明顯，需要分析磁盤寫延時升高的原因。
2、如果故障現場還在： iostat -mx 1 查看磁盤IO狀態，top和free命令查看cpu、內存使用情況, 分析磁盤IO高、CPU高，內存高的原因。
3、root用戶查看該節點的系統日誌, cd /var/log, 查看該時間點message日誌是否有異常記錄。例如：節點內存耗盡了，分析佔用內存的原因，是否內存泄漏等。
如果仍無法確認原因，聯繫華為工程師。
etcd進程故障導致ETCD服務異常告警
問題現象
etcd進程down、重啟，管控面上報etcd服務異常告警
問題分析及界定
登陸故障etcd節點， 進入Ruby用戶，執行命令ps ux | grep etcd， 查看etcd進程是否在運行。
如果進程在，查看etcd進程啟動時間，告警時是否重啟過，聯繫華為工程師確認重啟原因。
如果進程不在，查看etcd無法啟動原因：
（1）cd $GAUSSLOG/bin, 查看目錄下是否有cluster_manual_start 和 etcd_manual_start 兩個文件，
如果有表示集群被停止，確認停止集群的原因，之後啟動集群，定位結束。
（2）cd $GAUSSHOME/bin 查看目錄下是否存在etcd這個文件，文件權限是否正確，確認文件不存在或權限不正確的原因。
（3）檢查etcd的數據目錄所在磁盤是否滿了或者故障，etcd目錄如下：cm_ctl query -Cvipd查看
檢查etcd的數據目錄所在磁盤是否滿了或者目錄權限不正確（正確是700）或者故障，
如果磁盤滿，檢查佔用磁盤的文件並清除或者轉存到其他盤，如果是etcd本身的文件佔滿，聯繫華為工程師分析原因。
如果目錄權限不正確，修改為正確的目錄權限。如果是磁盤故障，聯繫IaaS技術支持分析定位。
處理步驟
參照上述處理，如果不是以上原因，請聯繫華為工程師
OM接口無法正確返回結果導致ETCD服務異常告警
問題現象
管控面上報etcd服務異常告警， 管控無法獲取集群狀態
問題分析及界定
查看管控面是否獲取集群狀態成功，是否獲取空消息，聯繫華為工程師分析定位。
cd $GAUSSLOG/om/
查看gs_om-xxx.log，是否有如下異常日誌
例如： The status file does not exist. Path: /usr/local/temp/local_status_1611355718.58.dat.
處理步驟
參照上面描述步驟。
