首页
/ Longhorn存储引擎在节点滚动更新时陷入停止状态的技术分析

Longhorn存储引擎在节点滚动更新时陷入停止状态的技术分析

2025-06-02 22:47:08作者:秋阔奎Evelyn

问题背景

在Kubernetes生产环境中使用Longhorn作为分布式存储解决方案时,运维团队在进行节点滚动更新操作时遇到了一个严重问题:部分存储引擎(Engine)和对应的副本(Replica)会陷入"stopped"状态,导致相关存储卷(Volume)无法成功挂载到Pod上。这种情况在Longhorn 1.7.x版本中尤为明显,影响了生产环境的稳定性。

问题现象

当集群执行节点滚动更新操作时,特别是通过Cluster API进行节点替换时,会出现以下典型症状:

  1. 多个Engine组件进入"stopped"状态
  2. 关联的存储卷无法完成挂载操作
  3. Pod事件中反复出现"FailedAttachVolume"错误
  4. 系统可能长时间(90分钟以上)无法自动恢复

根本原因分析

经过深入分析,这个问题主要由两个相互关联的因素导致:

1. 副本数量与调度条件的严格校验

在Longhorn 1.7.2版本中引入了一个关键变更:系统不仅检查现有副本是否已调度,还会严格比较当前副本数量与配置的副本数量(spec.numberOfReplicas)。当两者不匹配时,系统会将卷标记为"Scheduled=False",进而导致卷处于"NotReadyForWorkload"状态。

这种设计在正常情况下可以防止数据不一致,但在节点滚动更新这种特殊场景下会产生问题:

  • 当节点被排空(drain)和封锁(cordon)时,该节点上的副本会被标记为失败
  • 系统会删除长时间处于失败状态的副本CR
  • 由于卷处于分离(detached)状态,系统不会立即补充新副本
  • 导致当前副本数量小于配置值,触发"Scheduled=False"状态
  • 进而阻止卷重新挂载,形成死锁

2. 实例管理器(Instance Manager)不可用

另一个相关问题是当节点被封锁后:

  • 节点上的实例管理器(Instance Manager)Pod无法启动
  • 导致该节点上的副本无法正常运行
  • 如果此时其他副本也出现问题,系统可能无法自动重建
  • 特别是在"allow-volume-creation-with-degraded-availability=false"设置下,问题更加明显

解决方案与优化建议

针对这一问题,Longhorn团队已经制定了修复方案,并将包含在1.7.3和1.8.1版本中。主要改进包括:

  1. 优化调度条件判断逻辑:调整卷"Scheduled"条件的判断逻辑,避免在节点滚动更新时产生死锁情况。

  2. 临时解决方案:在生产环境可以暂时将"allow-volume-creation-with-degraded-availability"设置为true,虽然这不符合生产环境的最佳实践,但可以缓解问题。

  3. 增强副本重建机制:改进副本重建逻辑,确保在节点维护期间也能保持足够的副本可用性。

最佳实践建议

对于使用Longhorn的生产环境,特别是在需要频繁进行节点维护的场景下,建议:

  1. 在升级到1.7.3或1.8.1版本前,评估临时启用"allow-volume-creation-with-degraded-availability"的必要性

  2. 进行节点滚动更新时,监控Longhorn卷的状态变化,特别是副本数量和调度状态

  3. 考虑在维护窗口期进行节点更新,减少对业务的影响

  4. 确保集群有足够的容量冗余,避免因单个节点不可用导致副本无法重建

总结

Longhorn存储引擎在节点滚动更新时陷入停止状态的问题,揭示了分布式存储系统在动态Kubernetes环境中的复杂性。通过深入分析问题根源,Longhorn团队已经找到了解决方案,并将通过后续版本更新提供给用户。对于生产环境用户,理解这一问题的影响范围和临时解决方案,可以帮助更好地规划系统维护和升级策略。

登录后查看全文
热门项目推荐

热门内容推荐

最新内容推荐

项目优选

收起
docsdocs
OpenHarmony documentation | OpenHarmony开发者文档
Dockerfile
144
1.93 K
kernelkernel
deepin linux kernel
C
22
6
ohos_react_nativeohos_react_native
React Native鸿蒙化仓库
C++
192
274
openGauss-serveropenGauss-server
openGauss kernel ~ openGauss is an open source relational database management system
C++
145
189
RuoYi-Vue3RuoYi-Vue3
🎉 (RuoYi)官方仓库 基于SpringBoot,Spring Security,JWT,Vue3 & Vite、Element Plus 的前后端分离权限管理系统
Vue
930
553
nop-entropynop-entropy
Nop Platform 2.0是基于可逆计算理论实现的采用面向语言编程范式的新一代低代码开发平台,包含基于全新原理从零开始研发的GraphQL引擎、ORM引擎、工作流引擎、报表引擎、规则引擎、批处理引引擎等完整设计。nop-entropy是它的后端部分,采用java语言实现,可选择集成Spring框架或者Quarkus框架。中小企业可以免费商用
Java
8
0
openHiTLSopenHiTLS
旨在打造算法先进、性能卓越、高效敏捷、安全可靠的密码套件,通过轻量级、可剪裁的软件技术架构满足各行业不同场景的多样化要求,让密码技术应用更简单,同时探索后量子等先进算法创新实践,构建密码前沿技术底座!
C
423
392
金融AI编程实战金融AI编程实战
为非计算机科班出身 (例如财经类高校金融学院) 同学量身定制,新手友好,让学生以亲身实践开源开发的方式,学会使用计算机自动化自己的科研/创新工作。案例以量化投资为主线,涉及 Bash、Python、SQL、BI、AI 等全技术栈,培养面向未来的数智化人才 (如数据工程师、数据分析师、数据科学家、数据决策者、量化投资人)。
Jupyter Notebook
75
66
CangjieCommunityCangjieCommunity
为仓颉编程语言开发者打造活跃、开放、高质量的社区环境
Markdown
1.11 K
0
openHiTLS-examplesopenHiTLS-examples
本仓将为广大高校开发者提供开源实践和创新开发平台,收集和展示openHiTLS示例代码及创新应用,欢迎大家投稿,让全世界看到您的精巧密码实现设计,也让更多人通过您的优秀成果,理解、喜爱上密码技术。
C
64
511