Milvus 2.x 高可用部署方案简化探讨

[jinjianming]

考虑到 Milvus 2.x 已采用 etcd+S3 的存储架构，使其本质上成为无状态服务，我想探讨一种更轻量的高可用方案：

是否可以通过部署双副本 StatefulSet，共享同一套 etcd+S3 后端存储，并配置为主备模式（仅主节点提供读写服务）来实现高可用？当主节点故障时，通过健康探针或自定义 Operator 自动切换到备用节点继续提供服务。

这种方案相比完整的分布式部署更适合小型生产环境，但我想确认在这种配置下是否存在潜在的数据一致性问题或其他需要注意的技术风险点。

就目前官网提供的分布式方案确实很强，但是对于成本偏高，数据虽然很少但还是希望系统是高可用的。

[jinjianming]

看到前面有类似讨论但都没有很好的结论，类似：#38337

基于云上场景，S3是直接可以调用托管的而非minio，Etcd现在大部分云厂商也有托管，理论上单机不需要kakfa但是看到有提及需要这是为什么。

[yhmo]

不管是standalone或是cluster，如果有两套milvus service同时运行在同一套etcd+S3上，那么他俩就会互相污染，恐怕两者都无法运行。
目前要做两组服务主备，只能依靠这个工具：https://github.com/zilliztech/milvus-cdc，这个工具会将上游milvus的dml/ddl请求从etcd/pulasr/kafka中获取，并发送给下游milvus。

单机不需要kafka是因为单机内嵌了一个RocksDB作为消息流组件，RocksDB运行在单机本地磁盘，所以milvus-cdc无法用在RocksDB作为消息流的单机milvus上。对于使用pulsar/kakfa的单机milvus，milvus-cdc仍然是可以工作的。

[jinjianming]

这一套下来维护成本看起来也不低，如果单纯启动两个连接相同的etcd+s3不可行我将在调研下我们的分布式架构。
另外我发现https://milvus.io/docs/zh/main_components.md官网文档里面看到写了两遍数据节点，这是写错了吗。还是有特殊意义

[yhmo]

以英文为准，这里是翻译错了。我稍后会通知改正
https://milvus.io/docs/main_components.md
原文是：
Microservice components
Root coord
Proxy
Query coord
Query node
Data coord
Index node
Data node

[jinjianming]

#26185
您好想请问下，现在支持腾讯的COs对象存储了吗。
我看很久没有更新了

[yhmo]

这里列举了所有支持的storage backend:
https://milvus.io/docs/product_faq.md#Where-does-Milvus-store-data

使用时在milvus.yaml里指定cloudProvider为tencent:

milvus/configs/milvus.yaml

Line 146 in 2c55aae

cloudProvider: aws

代码层面可以看到tencent是支持的:
https://github.com/milvus-io/milvus/blob/2.5/internal/storage/remote_chunk_manager.go#L48

[jinjianming]

感谢我尝试下的

[jinjianming]

@yhmo HI，这几天我学习了解了下我们的分布式，突然启发到，如果启动两个milvus单机连接相同的kafka，好像也可以达到高可用效果，其实就是又将微服务合并了一下不知道这样是否还有互相污染的问题

[yhmo]

两个milvus使用同一个kafka，它们只是使用同一组topic，它们各写各的数据，各读各的数据，最终它们的数据存在不同的etcd/minio里。不过这基本上跟两个milvus使用不同的kafka没有本质区别。