Longhorn项目中备份删除操作中的404错误分析与解决方案

背景介绍

在Longhorn分布式存储系统的测试过程中，开发团队发现了一个与备份删除操作相关的稳定性问题。当测试用例执行清理操作时，系统频繁出现"404 Not Found"错误，提示无法找到之前列出的备份资源。这个问题在Longhorn的master-head和v1.8.x-head版本中均有出现，影响了多个测试场景的正常执行。

问题现象

测试框架在执行清理操作时，会先列出所有备份资源，然后逐个删除。但在实际执行过程中，系统有时会报告找不到某个备份资源，即使该资源在之前的列表查询中确实存在。错误信息显示为HTTP 404状态码，具体表现为：

kubernetes.client.exceptions.ApiException: (404)
Reason: Not Found
HTTP response headers: ...
HTTP response body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"backups.longhorn.io \"backup-c0882962ebbd4ddf\" not found",...}

技术分析

问题根源

经过深入分析，这个问题源于Longhorn备份系统的资源管理机制和测试清理流程之间的时序竞争：

1. 备份资源生命周期：在Longhorn中，备份资源与备份卷(backup volume)存在关联关系。当备份卷被删除时，相关的备份资源也会被自动清理。

2. 测试清理流程：测试框架的清理操作分为两个主要步骤：

   • 首先执行backupstore_cleanup，删除备份卷
   • 然后执行backup_cleanup，删除剩余的备份资源

3. 竞争条件：在backup_cleanup步骤中，系统先列出所有备份资源，然后逐个删除。但在列出资源和实际删除操作之间的时间窗口内，由于备份卷已被删除，相关的备份资源可能已被系统自动清理，导致后续删除操作失败。

影响范围

这个问题主要影响以下测试场景：

• 周期性备份任务测试
• 允许在降级可用性下创建卷的测试
• 允许分离卷的周期性任务测试

解决方案

技术实现

针对这个问题，开发团队采取了以下解决方案：

1. 错误处理优化：修改backup_cleanup函数的实现，使其能够优雅地处理404错误。当尝试删除一个已经不存在的备份资源时，不再将其视为错误，而是简单地跳过该资源。

2. 功能定位明确：明确backup_cleanup函数的主要目的是清理那些没有关联备份卷的失败备份资源，而不是强制删除所有备份资源。

实现原理

优化后的清理流程更加健壮，能够适应备份系统自动清理资源的特性。具体表现为：

• 当备份资源已被系统自动清理时，测试框架不会报错
• 真正需要关注的异常情况（如无权限、网络问题等）仍会被捕获和处理
• 测试稳定性得到提升，不再因为资源状态的自然变化而失败

验证结果

该解决方案已在Longhorn的master-head版本中得到验证，测试结果显示：

• 在多次执行受影响测试用例后，未再出现备份资源找不到的错误
• 测试清理操作能够顺利完成，不影响后续测试的执行
• 系统稳定性得到显著提升

最佳实践建议

基于这个问题的分析，对于使用Longhorn备份系统的开发者，建议：

1. 资源删除操作：在执行资源删除操作时，应该考虑资源可能已被其他流程清理的情况，做好错误处理。

2. 测试设计：在编写测试用例时，要了解系统组件的交互关系，特别是资源之间的依赖关系，避免因时序问题导致测试失败。

3. 错误处理：对于预期可能发生的错误（如资源已被删除），应该在代码中明确处理，而不是将其视为异常情况。

4. 清理顺序：理解系统组件的清理顺序和依赖关系，设计合理的测试清理流程。

这个问题及其解决方案体现了分布式系统开发中常见的资源状态管理挑战，也为类似场景提供了有价值的参考。