【Azure Service Fabric 】节点扩展状态为 Not Ready 的恢复办法

简介: Azure Service Fabric Windows节点卡在“Node configuration is in progress”状态,实为扩展未就绪(Not Ready),非正常进行中。本文详解通过停止服务、重命名运行时目录、重启安装服务及虚拟机,触发自动修复完成节点恢复的实操方案。

问题描述

Azure Service Fabric 节点无法启动时,扩展状态里的 Node configuration is in progress 很容易让人觉得“再等一会儿就好”。

但如果节点持续无法恢复,这条提示只能说明配置尚未完成,并不能证明配置仍在正常推进。

这次遇到的问题发生在 Windows 节点 node 0 上。

检查 Microsoft.Azure.ServiceFabric.ServiceFabricNode 扩展时,看到以下状态:

Type    Microsoft.Azure.ServiceFabric.ServiceFabricNode

Display Status    Not Ready

Handler Version    1.1.0.27

Status Code    ProvisioningState/NotReady/1

Status Level    Info

Status Message    Node configuration is in progress

  • 1.1.0.27 是扩展处理程序版本,不是 Service Fabric 运行时版本。
  • Info 也不代表节点健康,它是这条扩展状态信息的级别,而 Not Ready 明确表示扩展尚未就绪。

那么,节点到底卡在什么环节?当重新映像这条恢复路径暂时走不通时,是否还有办法让节点配置继续完成?

 

问题解答

Service Fabric 节点启动涉及本机运行时安装、节点配置以及加入集群等,节点长期处于 Down 状态时,可能是引导过程中的某个步骤无法完成,例如配置节点、安装 Service Fabric 或重新加入集群。证书过期、磁盘空间不足等问题也可能阻碍启动。在

在这次的恢复方法中,采用了最暴力的办法,直接将节点中文件夹“C:\Program Files\Microsoft Service Fabric\bin”中的全部文件,Service Fabric集群就可以通过自动修复任务重新配置了节点。

 

执行的清理命令如下


# stop Service Fabric processes/services

sc stop ServiceFabricNodeBootstrapUpgradeAgent


sc stop ServiceFabricNodeBootstrapAgent


sc stop FabricHostSvc


sc query ServiceFabricNodeBootstrapAgent


# clean up runtime

dir "C:\Program Files\Microsoft Service Fabric"


dir "C:\Program Files\Microsoft Service Fabric\FabricInstallerService.Code"


cd "C:\Program Files\Microsoft Service Fabric"


move bin bin_moved



sc start FabricInstallerSvc



# restart vm to re-activate ServiceFabricNodeBootstrapAgent

shutdown /r

 


手动恢复的步骤为:

第一步:通过远程桌面的方式进入节点

第二步:停止相关服务,确认已经停止

依次执行:

sc  stop ServiceFabricNodeBootstrapUpgradeAgent

sc  stop ServiceFabricNodeBootstrapAgent

sc  stop FabricHostSvc

然后查询服务状态:

sc  query ServiceFabricNodeBootstrapUpgradeAgent

sc  query ServiceFabricNodeBootstrapAgent

sc  query FabricHostSvc

sc stop(即是sc.exe stop )发出停止请求,并不意味着服务已经停止。如果仍显示 STOP_PENDING,需要继续等待并重新查询,确认相关服务进入 STOPPED 后再继续。

 

第三步:检查目录,将原运行时目录移走

先检查安装目录和安装服务的代码目录:

dir "C:\Program Files\Microsoft Service Fabric"

dir "C:\Program Files\Microsoft Service Fabric\FabricInstallerService.Code"

确认目录与现场预期一致后,进入安装目录:

cd /d "C:\Program Files\Microsoft Service Fabric"

确认当前目录切换成功、源目录存在,且目标备份目录尚不存在,再执行:

move bin bin_moved

这一步的“清理”实际上是将原运行时目录重命名保留,不是直接删除文件。

保留下来的目录可以用于后续比对和取证,但它不是完整的节点备份,也不意味着恢复失败后可以无条件改名还原。

 

第四步:启动安装服务

sc start FabricInstallerSvc

 

第五步:重启目标虚拟机

shutdown /r

 

 

参考资料

Service-Fabric-Troubleshooting-Guides : https://github.com/Azure/Service-Fabric-Troubleshooting-Guides/blob/master/Cluster/Why%20is%20my%20node%20unhealthy.md#troubleshooting-node-stuck-in-down-state

Service Fabric managed cluster automatic node repair :https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-node-auto-repair

 



当在复杂的环境中面临问题,格物之道需:浊而静之徐清,安以动之徐生。 云中,恰是如此!

相关文章
|
29天前
|
前端开发 安全 JavaScript
打字乐园:一个为零基础孩子设计的纯前端指法打字练习(MIT 开源)
《打字乐园》是MIT开源的纯前端儿童打字练习工具,专为7–8岁零基础孩子设计。通过八指着色键盘、实时手指提示、五阶渐进课程(基准键→A-Z→单词),坚持“准确优先”,离线即用,无数据收集,守护儿童隐私与学习安全。
283 2
|
8天前
|
NoSQL 网络协议 Java
【Azure Redis】TCP_USER_TIMEOUT 不生效时,Java 长连接为何要几分钟才恢复?
Linux下Java应用使用Lettuce/Netty连Redis时,网络抖动后常因TCP_USER_TIMEOUT未生效导致连接数分钟无法恢复。关键在于确认是否正确启用netty-transport-native-epoll并设置EpollChannelOption,否则内核重传机制将延迟失效连接的识别与重建。(239字)
105 1
2026万网双十一.com权益:新购/转入76元,续费90元
2026 年万网双11 域名分会场(11 月 1 日–11 月 30 日)的 .com 价格:新购、转入 76 元/年,续费 90 元/年,不限量、不限个数;已持有 ICP 备案的域名转入 5 折,低至 46 元。多年注册 3–4 年 9.2 折、5–8 年 9.1 折、9–10 年 9 折。
|
11天前
|
人工智能 JavaScript API
跟着做就行!DeepSeek Harness 十大插件保姆级教程,手把手教你搭出自己的 AI 工作台
DeepSeek Harness 的魅力在于——它不是一个"成品工具",而是一个可无限生长的骨架。十大插件只是起点,你可以继续从 dsh-market 探索上百款社区插件,用 TypeScript 写自己的专属插件(导出一个 apply(ctx) 函数即可),甚至把经验沉淀为可复用的 Skill 模板。 而这一切的地基,是 阿里云计算巢 Deepseek-Harness 社区版一键部署教程服务平台 给你的三分钟交付能力,和 阿里云百炼大模型服务平台页面 给你的百余款模型、超 1 亿免费 Tokens、4.5 折双十一钜惠。 现在,打开这两个平台,装好框架,插满插件,让你的 AI 工作台——
256 1
|
1月前
|
JSON Java Maven
响应自动序列化:JSON 响应一键转 Java 实体对象,JQuick-Curl 第三方接口调用不再手动解析
JQuick-Curl 支持响应自动序列化:JSON 响应可一键转为 Java 实体对象,告别手动解析。结合 curl 命令式调用,大幅提升第三方接口集成效率。轻量、直观、开箱即用。
|
13天前
|
存储 运维 监控
【Azure Container Apps】为什么通过 Diagnostic Settings 发送到 Log Analytics 中的日志会延迟几分钟?
本文详解 Azure Container Apps 日志集成 Log Analytics 的机制与延迟问题:Console/System/HTTP 日志需经 Diagnostic Settings 路由,存在典型 3–10 分钟端到端延迟,属 Azure Monitor Resource Logs 固有特性,不可配置消除;实时查看应使用 Log Stream,二者场景互补。(239 字)
105 0
|
1月前
|
运维 监控 安全
双因素认证抗钓鱼效能与部署策略研究
本文基于卡内基梅隆大学2026年双因素认证指南,系统分析短信验证码、TOTP、推送通知、通行密钥及硬件密钥等方案的安全梯度、抗钓鱼能力与部署实践,强调FIDO2/WebAuthn方案的协议级防钓鱼优势,并提出分层认证、备用设备、用户教育等关键运维策略。(239字)
122 2
|
18天前
|
API 数据中心
【Azure APIM】使用 Terraform 为现有 APIM 配置自动缩放
本文详解如何使用Terraform为Azure API Management(APIM)配置自动缩放。因官方azurerm_api_management资源不支持auto scale参数,需借助azurerm_monitor_autoscale_setting资源实现,并适配中国区环境(设置environment="china")。文中提供完整模板、部署步骤及常见错误解决方案。(240字)
111 0
|
2月前
|
存储 人工智能 缓存
阿里云发布 Agentic Storage 全矩阵产品:面向 AI 到 Agent 负载的全栈演进
阿里云在2026云栖大会发布Agentic存储全栈产品,覆盖AI Native与Agent Native场景:CPFS支撑百万卡训练,KVCacheStore优化推理缓存,AgenticFS等实现百万级智能体安全隔离存储,OSS统一多模态数据底座,助力大模型高效训练、低延时推理与Agent规模化落地。(239字)
635 1
|
2月前
|
存储 运维 监控
可观测性平台建设:从数据割裂到统一观测的演进路径
企业监控体系为何越建越复杂?本文深入分析监控数据割裂的根源,提出以统一元数据模型打通指标、日志、链路的分步落地路径,对比自建、商业一体化与混合三种技术路线的适用边界,并总结采集聚合、标签基数、拓扑维护等常见实践坑,帮助团队判断何时适合推进统一可观测平台建设。