Milvus 2.6.13 在 MinIO 网络时延故障下测试写入功能， StreamingNode pod挂掉，且无法自愈

[OoO-OvO-OoO-OvO]

内容

环境信息

• Milvus 版本：2.6.13
• 部署方式：Kubernetes 集群模式，Helm 部署
• Message Queue：Woodpecker
• Woodpecker 存储：MinIO
• Milvus 对象存储：MinIO
• MinIO 副本数：3
• 测试工具：一个Milvus测试脚本，能执行仅查询，仅写入，同时查询+写入

测试场景

我们正在对 Milvus 2.6.13 做 DFX 可靠性测试。

在对 MinIO 注入网络时延故障中，如果只运行Milvus测试脚本的仅查询功能，查询 QPS 表现正常，没有明显异常。

但如果脚本执行"同时查询+写入"功能，insert 请求会超时，然后查询和写入都不可用。之后即使停止脚本，只运行脚本的仅查询功能，QPS 仍然无法恢复，持续为 0。

同时观察到 StreamingNode Pod 进入 CrashLoopBackOff。

Chaos 配置

对 MinIO Pod 注入 500ms 入方向网络时延：

kind: NetworkChaos
apiVersion: chaos-mesh.org/v1alpha1
metadata:
  namespace: milvus-cluster
  name: minio-delay-500ms
spec:
  selector:
    namespaces:
      - milvus-cluster
    labelSelectors:
      app.kubernetes.io/name: minio
  mode: all
  action: delay
  duration: 10m
  delay:
    latency: 500ms
    correlation: "100"
    jitter: 0ms
  direction: to

客户端报错

开启后台写入后，客户端出现 insert 超时：

[error="rpc error: code = DeadlineExceeded desc = context deadline exceeded"]

[bg-insert][failed] err=rpc error: code = DeadlineExceeded desc = context deadline exceeded

StreamingNode 报错

StreamingNode try to new chunk manager failed:
Get "http://milvus-cluster-minio.milvus-cluster.svc.cluster.local:9000/milvus-bucket/?location=":
dial tcp 10.192.20.39:9000: connect: connection refused

之后其他 Milvus 组件也出现类似错误：

dial tcp <streamingnode-pod-ip>:22222: connect: connection refused
proxy TaskCondition context Done: context deadline exceeded

观察到的现象

1. MinIO 注入网络时延后，只运行查询 workload，QPS 正常。
2. MinIO 注入网络时延后，同时运行查询和后台持续写入，insert 请求超时。
3. StreamingNode 进入 CrashLoopBackOff。
4. 关闭后台写入后，再次只运行查询 workload，QPS 仍然为 0，无法自动恢复。
5. 需要手动恢复或重启 StreamingNode/相关组件后，集群才可能恢复。

想请教的问题

1. 在 WP 使用 MinIO 作为存储后端时，MinIO 出现网络时延或短暂不可用，导致 StreamingNode CrashLoopBackOff，这是否属于预期行为？

2. 为什么 MinIO 故障恢复后，StreamingNode 没有自动恢复，而是进入 CrashLoopBackOff？

   为什么 MinIO 故障恢复后，StreamingNode Pod正常，而查询qps为0，重启后恢复正常？日志未留存，未复现

3. 官方推荐如何隔离 MinIO 对象存储故障对 WAL/StreamingNode 链路的影响？

4. 之后是否有关于 StreamingNode 恢复、Woodpecker 存储可用性或 assignment 恢复的相关issue修复？

补充说明

我们看到社区中有一些可能相关的问题：
#44851
#44713
不过我们当前遇到的错误不是 storage is not writable，
而是 StreamingNode 在初始化 ChunkManager、访问 MinIO 时出现：connect: connection refused
想确认该问题是已知限制、配置问题，还是 StreamingNode/Woodpecker 在故障恢复场景下的 bug。

[yhmo]

1. StreamingNode也需要往minio写数据，因为streaming data要被flush成新的segment。minio持续出现网络延迟，可能触发了StreamingNode的panic逻辑导致它退出，这应该是预期的，否则streaming data驻留在内存中无法持久化也会导致OOM。
2. minio恢复后，StreamingNode仍然carshloop，需要拿日志分析原因。
3. WAL/StreamingNode都是有写入链路的，存储服务不可用的话，我认为基本上也就等同于WAL/StreamingNode不可用。
4. minio恢复后，StreamingNode仍然carshloop，这有可能是个bug。预期应该是跟着恢复。

@xiaofan-luan @yanliang567 也许有更多观点和信息输入

[tinswzy]

@OoO-OvO-OoO-OvO 看什么时候方便，我们可以拉个飞书会议直接沟通下看看有什么可以帮助到您

[OoO-OvO-OoO-OvO]

“在故障结束十几分钟后才能自愈”、“最终查询和写入都不可用” 这里有点矛盾，最终恢复读写还是没有恢复读写呢。可以把日志export出来吗

故障结束后, 服务会持续一段时间的查写不可用, 大概会在14,15分钟后恢复
因为这段描述我修改过,所以表述有一些前后出入的地方

[OoO-OvO-OoO-OvO]

@OoO-OvO-OoO-OvO 看什么时候方便，我们可以拉个飞书会议直接沟通下看看有什么可以帮助到您

可以的，我明后天都有时间。看你们方便的时间安排即可

[tinswzy]

今天下午3.30 飞书会议吧

invites you to join a Lark video meeting.
Meeting topic: milvus 故障演练讨论
Meeting time: Today, May 8, 3:30 - 4:30 PM (GMT+8)
Meeting ID: 753 160 133
Meeting link: https://vc.feishu.cn/j/753160133

One-tap dial-in
+862122504720,,753160133（Chinese Mainland）
4008208888,,753160133（Chinese Mainland）

Dial in by your location
+86 21 2250 4720（Chinese Mainland）
400 820 8888（Chinese Mainland）
+852 2245 3212（Hong Kong, China）
+44 74 1836 5327（United Kingdom）

[OoO-OvO-OoO-OvO]

今天下午3.30 飞书会议吧

invites you to join a Lark video meeting. Meeting topic: milvus 故障演练讨论 Meeting time: Today, May 8, 3:30 - 4:30 PM (GMT+8) Meeting ID: 753 160 133 Meeting link: https://vc.feishu.cn/j/753160133

One-tap dial-in +862122504720,,753160133（Chinese Mainland） 4008208888,,753160133（Chinese Mainland）

Dial in by your location +86 21 2250 4720（Chinese Mainland） 400 820 8888（Chinese Mainland） +852 2245 3212（Hong Kong, China） +44 74 1836 5327（United Kingdom）

了解

[tinswzy]

更新下关联问题：

• minio故障启动SN可能会hang住的问题 2.6: [2.6] fix: bound streaming release wait by chyezh · Pull Request #49625 · milvus-io/milvus
• etcd故障恢复慢的问题 2.6: fix: fast fail wal recovery timetick append by chyezh · Pull Request #49636 · milvus-io/milvus

另外用户使用自制的minio老版本镜像，不支持condition write。 从而触发了上面etcd故障的时候SN使用了一个 WP在fallback 模式下已经 lost lock的writer一直重试发送first tt直到超时。
开源用户使用minio时，最好使用minio RELEASE.2024-12-18T13-15-44Z 测试过的版本。