在线服务故障自动重建

场景描述

自动重建是保障在线推理服务高可用、自愈、稳定运行的核心能力，适用于以下场景：

• 容器、进程意外崩溃，业务快速恢复

  推理实例（Pod）因进程异常、内存溢出（OOM，Out of Memory）、依赖缺失、代码 Bug 等意外退出时，平台自动重建Pod并重新拉起推理服务，无需人工介入，减少业务中断时间。

• 部署配置变更后平滑生效

  修改镜像、环境变量、资源规格、挂载路径等配置后，自动重建可按策略自动重启并重建实例，使新配置快速生效，保证服务连续性。

• 滚动升级、版本迭代时容错保障

  服务升级、切换模型版本、变更部署配置时，若部分实例升级失败，自动重建可自动恢复异常实例，避免整体服务受影响。

• 底层节点故障后快速迁移重建

  专属资源池节点系统崩溃、硬件异常、NPU故障时，自动重建可将Pod调度到正常节点并重建实例，保障推理服务持续可用。

• 长期稳定运行、无人值守生产环境

  大模型在线推理、智能客服、实时预测等7×24 小时在线业务，依赖自动重建能力实现故障自愈、降低运维成本、减少人工干预。

自动重建开启后，由于部署配置变更或者故障等原因导致Pod重启时，平台将按策略自动执行重建。若不开启，平台将不会主动干预处理。

重建策略如下：

• 部署副本重建：Pod发生重启时，对整个部署副本进行重建。
• 单元重建：Pod发生重启时，对整个单元进行重建。
• 单元副本重建：Pod发生重启时，对整个单元副本进行重建。
• Pod重建：Pod发生重启时，对整个Pod进行重建。

约束限制

• 资源池限制：专属资源池和公共资源池均支持故障自动重建。
• 依赖健康检查：若未配置健康检查（就绪 / 存活探针），平台无法精准识别异常，可能导致无效重建或重建延迟。
• 故障自动重建与故障自动重启的区别：自动重建侧重配置变更 / 软件异常后的实例重建；故障自动重启侧重硬件 / NPU / 交换机故障后的调度重启，二者可叠加使用。
• 插件依赖：推理部署的A5资源池中必须安装ClusterX插件，才能感知到节点的亚健康故障，触发自动重建。ClusterX插件相关描述请参见算力资源管理中的ClusterX插件章节。
• 单元副本重建：资源池KubeInfer插件7.5.2及以上版本可使用。
• 单元重建、单元副本重建或Pod重建三种策略下，重建前需等待容器退出，由于优雅停机机制或分批生效，当单元副本的资源实例数大于1时，容器退出整体耗时可能会达到优雅停机时间的2倍左右。
• 在资源池KubeInfer插件7.5.2及以上版本且单副本资源实例数大于1的情况下，若重建策略为Pod重建，Leader Pod异常重启或被删除时会触发整个单元副本下所有Pod重建；若不开启自动重建，删除Leader Pod会触发整个单元副本下所有Pod重建。如图 1 所示（单元名称为role-0，单元副本数为2，单副本资源实例数为3）其中role-0-0、role-0-0-1、role-0-0-2组成单元副本1，role-0-1、role-0-1-1、role-0-1-2组成单元副本2，role-0-0和role-0-1分别为两个单元副本的Leader Pod。
  图1 部署副本Pod详情示例
  

前提条件

在线推理服务的状态为 “运行中”。

开启故障自动重建

方式一：

在添加部署时，在“单元配置 > 更多配置”，勾选“自动重建”，选择重建策略。

方式二：

如果部署时未开启故障自动重建，可以升级部署服务，修改配置，具体操作如下。

1. 登录ModelArts管理控制台，在左侧菜单栏中选择“模型推理>在线推理”，进入在线服务管理页面。
2. 单击目标在线服务名称，进入服务详情页。在详情页导航栏切换至“部署”页签，选择目标部署卡片，单击“升级”，进入升级部署页面。
3. 在“单元配置 > 更多配置”，勾选“自动重建”，选择重建策略（四选一）。
   • Pod重建：仅重建当前异常Pod
   • 单元重建：重建整个推理单元
   • 单元副本重建：Pod发生重启时，对整个单元副本进行重建。
   • 部署副本重建：重建整个部署副本
4. 保存配置，完成自动重建开启。

   开启后，Pod因异常退出或配置变更触发重启时，平台将按照策略自动重建实例。

相关操作

建议同时配置健康检查，提升异常识别精度，减少无效重建。具体操作请参考在线服务健康检查。

常见问题

NPU故障导致进程残留，造成故障自动重建机制失效

问题现象：

在NPU上运行大模型或推理业务时，若底层守护进程心跳异常触发NPU硬件故障（例如 昇腾A5卡的0x8C204E00 故障），由于主机侧（Host）与设备侧（Device）可能存在通信异常，常会引发以下连锁反应：

• 业务容器正常退出后，主机侧仍有残留的NPU相关进程未能彻底消亡。
• 该残留会导致NPU显存无法及时释放，进而造成上层的故障自动重建机制失效。

通常情况下，这类残留进程在驱动或内核通信超时后会在5分钟左右恢复。

解决方案：为服务配置优雅停机脚本，并在优雅停机脚本中主动中止进程并等待NPU显存释放完成。

停机脚本中先主动中止进程，参考样例：

# 中止相关进程
pkill -9 route-server;pkill -9 vllm;pkill -9 VLLM;pkill -9 python;pkill -9 python3

停机脚本中加入轮询检测逻辑，确保vllm相关残留进程被完全回收后NPU显存完成释放，再允许容器完全退出或触发重建流程。检测命令的参考样例：

# 检测NPU显存是否完成释放
 
npu-smi info | grep NA | grep -oP '\d+(?=\s*/\s*\d+\s*\|)' | awk '$1>5000{print "卡"NR-1" HBM未释放: "$1"MB"}'

优雅停机更多介绍请参见在线服务优雅停机。