实例解读丨关于 GaussDB 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(https:// X.X.X.X:X) of member c797ab3a61e2ea55 (Get "https://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.
处理步骤
参照上面描述步骤。
版权声明: 本文为 InfoQ 作者【华为云开发者联盟】的原创文章。
原文链接:【http://xie.infoq.cn/article/a3c873c74c79417ca564bd090】。文章转载请联系作者。
评论