某局点UIS 出现“仲裁主机异常”告警的经验案例

略。

   某局点UIS实时告警中多次出现“仲裁主机异常”的告警，报错截图如下：

现场虽然出现 “仲裁主机异常”告警，但根据收集的日志分析，仲裁主机并无异常。即该问题仅为告警显示异常，并不影响业务以及平台正常使用。

看仲裁主机的内存使用情况，发现其cache达到14G。而正常情况下，内存cache为10G以下。、

远程查看现场的环境时，发现现场的多台主机，都出现了cache较大的情况：

主节点的内存cache达到12G。

[root@SZ-A1U20-U1 log]# free –g

              total        used        free      shared  buff/cache   available

Mem:            754         466         275           3          12         274

Swap:            31           0          31

         备节点的内存cache达到18G。

[root@SZ-A2U20-U2 ~]# free –g

              total        used        free      shared  buff/cache   available

Mem:            754         183         552           4          18         557

Swap:            31           0          31

         仲裁节点的内存cache达到20G。

[root@SZ-A1U23-U3 ~]# free –g

              total        used        free      shared  buff/cache   available

Mem:            754         402         331           3          20         338

Swap:            31           0          31

    主节点的cmsd日志中有以下报错：

备节点的cmsd日志也有以下报错。：

综合以上信息，结合现场的环境，该问题定位如下：UIS超融合环境中，由于Linux操作系统自身机制，运行中读写文件时会占用内存中的cache缓存，不会立即释放，长时间运行会导致剩余的空闲内存不足。如果不及时释放缓存，会出现连续的空闲内存不足；或者由于缓存过多，导致回收过慢，使得其他进程（包括检测的进程）无法及时申请到内存，从而影响UIS告警检测。

现场之前虽然部署了drop cache脚本，但因为cron配置语法错误，该脚本并没有生效。现场后重新按照文档，部署了drop cache脚本，发现cache明显减少。

彻底解决方案：

升级至UIS E0712及之后的版本。

临时规避措施：

可以参考《ONEStor和UIS超融合产品的drop cache优化方案》进行规避，系统会定期释放内存资源，这样主机也就能及时响应双机热备的探测报文。部署完此脚本之后，建议在业务量小的时候，切换一下双机，排除主备硬件本身差异的干扰，以达到同步脚本生效的目的。