网站开发的收获与体会,佛山网站建设全方位服务,电脑版4399游戏网页,九机手机网官网旗舰店关键词
suse linux hae 、pacemakeroracle、nfs crm_failcount、timeout、trace
一、问题现象
接故障反馈#xff0c;某业务几套suse ha集群系统#xff0c;在某天不同时间点#xff0c;分别发生了oracle数据库及主机异常切换重启的故障现象#xff0c;数据库切换重启期… 关键词
suse linux hae 、pacemakeroracle、nfs crm_failcount、timeout、trace
一、问题现象
接故障反馈某业务几套suse ha集群系统在某天不同时间点分别发生了oracle数据库及主机异常切换重启的故障现象数据库切换重启期间业务作业受到影响。需排查具体切换原因及故障风险问题解决。
二、问题分析
好几套集群差不多时间共同出现问题从经验判断应该是某种共性问题导致。先跟一线了解下相关基础环境得知是有个6套suse ha的高可用集群底层虚拟化平台支撑业务使用oraclenfs。梳理每套集群异常现象和时间点发现有的集群只是重启了数据库有的集群重启过主机有的集群啥也没重启之间是有些区别。
三、处理过程
了解完基本信息后上每台主机看看日志吧系统层优先检查/var/log/message。
多台主机日志中均记录了每次故障时HA双机资源超时事件日志:并且伴随有CPU高负 载告警资源监控拉起失败多次后节点发生切换SBD事件主机节点操作系统被强制重启。
部分告警信息如下
pacemaker-controld[7556]: error: Result of monitor operation for rsc_db_XXX on node1: Timed out---集群监测到资源监控超时
pacemaker-attrd[7554]: notice: Setting last-failure rsc_db_XXX monitor_3000[node1]: 1685340011 - 1685341059----超时后对资源计数值加1
pacemaker-controld[7556]:notice: Hig CPU load detected: 147.410004---集群伴随着有CPU负载异常增高的情况
sbd[7325]:emerg: do_exit: Rebooting system: reboot---最后切换失败的集群触发了sbd强制重启操作
分析到此不难看出故障跟集群自身有些关联都是有同类资源监控超时触发后续一系列问题现象查看数据库双机资源参数配置情况资源的定义如下超时时间为180秒每隔30秒探测一次on-failed的动作为自动重启 primitive rsc_db_XXX oracle \ params sidXXX \ op monitor interval30 on-failrestart timeout180 \ 双机日志中可以看到在3分钟的时间里monitor监控没有获取到返回值。从HA的角度来看就意味着这个资源异常会尝试拉起资源在尝试拉起的过程中如果正常启动那么就会fail-count计数如果尝试很多次依然失败就会触发切换动作甚至会触发SBD将节点置于unclean的状态fence掉节点。
并且在其中一套集群切换此次事件日志中发现在资源异常的时间节点作为nfs客户端也有无法连接到NFS 服务器的告警。检查NFS服务端发现服务端也有异常告警。怀疑此次切换事件与nfs异常有一定关联。
再次核对6套集群架构中nfs的部署情况得知有5套nfs部署在同一服务端1套是另外nfs服务端而出问题的集群均发生在这5套共用nfs集群上这更加证实了nfs导致异常切换的可能性。
随后对nfs重点监控发现此后每次集群日志出现异常后nfs均伴随有相关短暂告警最后业务在暂时无法调整nfs的情况下把集群资源监控monitor超时时间从180s调整到300s后临时解决了由于nfs短暂性异常导致的切换问题。最终根据评估业务对nfs实施迁移调整彻底根治这一隐患问题。
四、知识拓展
1、关于suse ha的failcount的机制
crm_failcount 命令可查询指定节点上每个资源的故障计数。此工具还可用于重设置故障计数同时允许资源在它多次失败的节点上再次运行。 Heartbeat实现了一种复杂的方法来计算资源并在资源出现故障时强制将其故障转移到另一个节点在当前节点上。资源带有resource_stickness属性以确定它更喜欢在某个节点上运行的程度。它还携带resource_failure_stickness该值确定资源应故障转移到另一个节点的阈值。 failcount属性将添加到资源中并在资源监视失败时增加。故障计数的值乘以resource_failure_stickness的值决定了该资源的故障转移分数。如果此数字超过为此设置的首选项资源则资源被移动到另一个节点并且在重置故障计数之前不会在原始节点上再次运行。 生产上配置 rsc_defaults rsc-options: \ resource-stickiness100 \ migration-threshold3
primitive rsc_db_XXX oracle \ params sidXXX \ op monitor interval30 on-failrestart timeout180 \ meta priority1000 target-roleStarted 生产上当前配置资源在出现故障时会自动重启动。如果在当前节点上无法实现此操作或者此操作在当前节点上失败了 3次它将尝试故障转移到其他节点。每次资源失败时其失败计数都会增加。您可以定义资源的故障次数migration-threshold在该值之后资源会迁移到新节点。如果群集中存在两个以上的节点则特定资源故障转移的节点由 High Availability 软件选择。 综上failcount只是计数功能这个计数是会和集群配置里面的migration-threshold值进行比对如果大于定义的migration-threshold值会将资源迁移到备机。迁移之前会不断尝试重启资源。 2、监控timeout的机制 生产配置 特定资源的超时 primitive rsc_db_XXX oracle \ params sidXXX \ op monitor interval30 on-failrestart timeout180 \ meta priority1000 target-roleStarted 全局的超时配置 op_defaults op-options: \ timeout600 \ record-pendingtrue Once a resource has a stop failure, the node is supposed to be fenced to recover from the failure. It is taking 10 minutes for the resource to detect and recover from the stop failure. --一旦资源出现停止故障就应该对节点进行隔离以从故障中恢复。资源需要10分钟才能检测到停止故障并从中恢复。 综上当集群监控资源的role为启动状态的时候每隔30秒会监测探测一次 如果您发现系统中包含的资源需要的时间超过了系统允许的执行操作如启动、停止或监视的时间请调查原因如果预计执行时间过长则可以增加此值。超时值不是任何类型的延迟如果操作在超时期完成之前返回集群也不会等待整个超时期。 资源目前定义是180秒超时每隔30秒探测一次当180秒还没有得到返回值时会将资源置于失败状态。Failcount会增加资源计数一次。 官方手册参考https://documentation.suse.com/zh-cn/sle-ha/15-SP3/single-html/SLE-HA-administration/#sec-ha-config-basics-monitoring
3、关于trace资源监控
针对资源无法正常启动的状况无法排查到原因的可以打开资源的trace功能方法如下:
参考 https://www.suse.com/support/kb/doc/?id000019138Enable resource tracing: crm resource trace resource name operation resource name - any defined primitive in the cluster operation - start, stop, monitor, probe
Disable resource tracing: crm resource untrace resource nameoperation
Debug trace file location: /var/lib/heartbeat/trace_ra/resource/*timestamp 然后根据trace文件看是否可以定位问题发生的原因。
