ALM-12074 fms资源异常的本质是FusionManager的FMS服务自身或其依赖的P2P服务器通信组件出现故障，绝大多数情况下可以靠重启服务或修复配置文件解决。
fms p2p 服务器 配置对FMS资源状态的影响
FusionManager（简称FMS）是华为FusionSphere虚拟化平台的管理节点，当系统弹出ALM-12074告警时，意味着FMS主进程检测到自己的资源状态异常，这里说的”资源”不是CPU或内存，而是FMS服务赖以生存的浮动IP、心跳链路、配置文件完整性这三样东西。
P2P服务器在FMS架构里的真实角色
很多运维同行第一次接触FusionSphere时，容易把P2P服务器想象成类似迅雷的点对点传输工具，实际上在FusionManager的多节点部署架构中，P2P服务器承担的是节点间状态同步通道的职责，FRM（FusionSphere Resource Management）组件通过P2P机制在主备节点之间传递FMS服务的健康检查报文，包括数据库连接状态、Web服务存活情况、浮动IP绑定状态等。
fms p2p 服务器 配置的核心参数位于/opt/FusionManager/etc/fms/p2p.conf，这个文件里定义了本节点在对端节点眼中的身份标识（node_id）、心跳报文发送间隔（heartbeat_interval）、P2P监听端口（默认27101端口），业内专家指出，绝大多数ALM-12074告警的根因就藏在这个配置文件里不是node_id写错,就是监听端口的防火墙策略发生变更。
配置漂移导致的资源状态闪断
配置漂移是指节点实际运行的参数与配置文件中的参数不一致，FMS在启动时会读取p2p.conf中的node_id生成自己的资源锁，如果这个锁文件（位于/opt/FusionManager/var/fms_ha.lock）与当前P2P服务器的主机名不匹配，FRM组件就会判定FMS资源异常，这种问题通常发生在手动修改过主机名或者虚拟机快照回滚之后。
如何在华为fusionmanager fms异常排查步骤中定位ALM-12074
直接说结论：排查ALM-12074的第一步不是看堆积如山的日志，而是检查FMS浮动IP是否还挂在当前节点上，FMS资源异常时，FRM会尝试将浮动IP漂移到备节点，如果备节点也无法绑定成功,告警就会持续出现。
通过命令行确认FMS服务状态
使用fms_ip命令先确认浮动IP归属，然后执行ps -ef | grep fms查看FMS主进程是否在运行，需要注意FMS包含三个核心进程：fms_master（负责配置管理）、fms_agent（负责指令下发）、fms_ha（负责心跳维护），ALM-12074的典型表现是fms_ha进程反复重启,这种情况十有八九是P2P通信端口不通。
# 检查P2P通信端口是否正常监听 ss -lntp | grep 27101 # 查看FMS主进程状态 systemctl status fms # 检查节点间P2P握手是否成功 /opt/FusionManager/bin/fms_tool --check_p2p
看穿告警日志里的关键线索
FMS资源异常的告警日志集中在/var/log/FusionManager/fms/ha.log，打开日志后重点搜索Resource abnormal和P2P handshake timeout两个关键字，在双节点部署场景下，比较常见的情况是主节点上报”resource abnormal”，备节点同时上报”p2p connection refused”，这种成对出现的日志基本可以断定是P2P服务器 配置中的监听地址没有更新。
顺带提醒一点，ALM-12074还经常伴随FusionManager Web界面无法登录的现象，如果Web界面能打开但提示”服务未就绪”，说明FMS进程还活着，只是资源锁丢失,直接重启FMS服务就能解决。
fms资源异常会导致什么后果以及不同场景的处理策略
ALM-12074并不等于FusionManager彻底瘫痪，它的危害程度取决于FMS服务的当前角色，如果FMS运行在主节点，那么云平台的生命周期管理操作将全部失败，比如创建虚拟机、修改集群配置、创建租户等，如果是备节点出现告警，业务影响相对有限,但平台的容灾能力已经大打折扣。
单节点部署场景的处理方案
单节点环境下没有浮动IP可漂移，处理思路相对简单先查磁盘后查配置文件，FMS资源异常中有相当一部分比例是磁盘空间不足导致MySQL临时文件无法写入,触发fms_master进程出现假死状态。
# 检查FMS数据目录磁盘占用率 df -h /opt/FusionManager/data # 查看MySQL临时表空间使用情况 du -sh /opt/FusionManager/data/mysql/tmp/
如果磁盘充足，那么大概率是p2p.conf文件被误修改，用备份文件覆盖恢复，或者直接从安装包解压出默认配置，然后重启FMS服务即可，行业共识认为，单节点场景下ALM-12074的恢复率很高,重启服务后30分钟内告警会自动清除。
主备双节点场景的切换策略
双节点环境下先确认当前FMS主节点还活着，如果主节点完全失联，需要人工触发FMS服务切换，要特别说明的是，强制切换操作必须配合修复P2P链路，否则备节点升主后会再次上报ALM-12074,形成告警来回跳的循环。
比较常见的处理步骤是：
- 在主节点上执行
fms_ha_tool --standby平滑降级 - 在备节点上执行
fms_ha_tool --master主动接管 - 等待5分钟后确认浮动IP已漂移到备节点
- 在主节点修复P2P配置链路后再重新加入集群
多数情况下，出现ALM-12074是因为FMS主节点的hostname变化导致P2P节点的node_id失配，对比主备节点的/etc/hosts解析记录,确保IP与主机名的映射关系完全一致。
华为fusionmanager fms异常和p2p服务器故障怎么区分
实际运维中容易混淆的问题是：ALM-12074告警展示的”FMS资源异常”，和p2p服务器自身的服务宕机，它们之间到底是什么关系。p2p服务器故障只是ALM-12074的诱因之一，反过来FMS加载异常也能让P2P同步通道失效，这是一个双向影响的关系,但从告警平台上只能看到FMS资源异常。
从进程状态区分故障源头
执行ps -ef | grep p2p查看P2P服务器的健康状态，正常情况下每个节点都有一个p2p_server进程和一个p2p_client进程，如果p2p_client进程不存在，说明FMS侧的P2P配置加载失败，告警根源在FMS服务本身，如果进程都在但日志疯狂刷”send buffer full”,那瓶颈在网络带宽或P2P包过大上。
配置项自查清单
fms p2p 服务器 配置优劣直接影响告警恢复时长，推荐运维团队保留一份P2P配置基线，在节点扩容或系统重装后第一时间做比对,这块配置里最关键的三个参数是：
[local] node_id
必须与
/etc/hostname保持一致[peer] peer_ip必须指向对端节点的管理IP[protocol] heartbeat_interval建议值1000-3000毫秒之间，小于500容易产生闪断误报
ALM-12074告警的预防手段与自愈能力说明
FusionManager平台本身具备FMS资源自愈能力，FRM会每30秒做一次健康检查尝试自动恢复，但在通过配置异常导致的P2P失联场景下，自愈的成功率并不高,更依赖于及时的人工干预。
预防思路是做好P2P链路的日常巡检，至少每个季度检查一次P2P配置文件的修改时间，如果与系统安装时间有偏差，需要确认是否有自动化脚本改动过相关配置项，同时建议在监控平台中加入FMS浮动IP绑定性检查,这个指标比FMS进程状态的告警更前置。
多数情况下ALM-12074的恢复过程不会超过一小时，关键在于快速判断是需要重启服务还是修正P2P配置，处理结束后的排查记录也建议作为知识库沉淀下来,后续再出现同样告警时能直接复用处理办法。
Q&A：关于ALM-12074 fms资源异常的高频疑问
ALM-12074告警在重启FMS服务后能自动消除吗
对于配置漂移或临时性心跳超时触发的告警，重启FMS服务后告警会在下个健康检查周期内自动清除，通常不超过10分钟，如果重启后6小时告警仍然存在，说明P2P链路未恢复正常,需要检查防火墙策略或节点间网络连通性。
fms p2p 服务器 配置中修改了node_id参数需要重启哪些服务
修改node_id后需要依次重启P2P服务器进程和FMS主服务，执行systemctl restart p2p-server和systemctl restart fms，操作顺序不能颠倒，先让P2P服务器以新身份注册,FMS服务才能与其正常建立心跳会话。
华为FusionManager的FMS服务出现异常时云平台上的业务虚拟机还在运行吗
已运行业务的虚拟机不受FMS服务异常影响，虚拟机的CPU、内存、网络功能继续由对应的CNA节点保障，FMS资源异常影响的范围主要集中在运维管理面和自动化编排能力上，故障期间无法执行创建虚拟机、调整规格等管理操作,但现有业务不会因此中断。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/584363.html
