AKS环境下Qdrant集群分片与高可用性技术问询

我在AKS通过Helm部署了Qdrant集群，包含4个节点、4个Pod副本及4个PVC（均为Azure SSD磁盘，默认存储类，容量500G）。推送100万条带分片的集合数据后，发现仅两个PVC存储了实际数据：

k exec q181-qdrant-0 -- df -ah
Filesystem      Size  Used Avail Use% MountedON
/dev/sde        503G   14G  490G   3% /qdrant/storage
k exec q181-qdrant-1 -- df -ah
/dev/sdc        503G   24G  480G   5% /qdrant/storage
k exec q181-qdrant-2 -- df -ah
/dev/sdc        503G  5.4M  503G   1% /qdrant/storage
k exec q181-qdrant-3 -- df -ah
/dev/sdd        503G  9.1M  503G   1% /qdrant/storage

Pod列表：

{~/ws} greetings, earthling [166.140Mb]$ ☞ kgp -o wide
NAME            READY   STATUS    RESTARTS   AGE     IP           NODE                                 NOMINATED NODE   READINESS GATES
q181-qdrant-0   1/1     Running   0          4h44m   10.3.6.155   aks-qdrant64gb-12987685-vmss000000   <none>           <none>
q181-qdrant-1   1/1     Running   0          4h49m   10.3.6.139   aks-qdrantnoaz-19721947-vmss000005   <none>           <none>
q181-qdrant-2   1/1     Running   0          4h48m   10.3.6.11    aks-qdrant64gb-12987685-vmss000004   <none>           <none>
q181-qdrant-3   1/1     Running   0          4h50m   10.3.6.20    aks-qdrant64gb-12987685-vmss000003   <none>           <none>

GET /cluster接口返回结果：

{
  "result": {
    "status": "enabled",
    "peer_id": 3922056191064933,
    "peers": {
      "3922056191064933": {
        "uri": "http://q181-qdrant-0.q181-qdrant-headless:6335/"
      },
      "612800828958104": {
        "uri": "http://q181-qdrant-2.q181-qdrant-headless:6335/"
      },
      "5183492229046375": {
        "uri": "http://q181-qdrant-3.q181-qdrant-headless:6335/"
      },
      "1755630610601120": {
        "uri": "http://q181-qdrant-1.q181-qdrant-headless:6335/"
      }
    },
    "raft_info": {
      "term": 402,
      "commit": 871,
      "pending_operations": 0,
      "leader": 1755630610601120,
      "role": "Follower",
      "is_voter": true
    },
    "consensus_thread_status": {
      "consensus_thread_status": "working",
      "last_update": "2024-03-20T18:10:53.895767796Z"
    },
    "message_send_failures": {}
  },
  "status": "ok",
  "time": 0.0000052
}

问题与解答 #

1. 若每个Pod/PV存储不同数据，当Pod-3故障时，客户端请求该Pod的数据时，集群如何保障高可用性？ #

Qdrant的高可用依赖分片副本机制和Raft共识协议：

• 如果集合配置了分片副本（replication_factor>1），分片数据会复制到多个Pod。Pod-3故障时，Raft集群会检测到节点离线并触发故障转移，客户端请求会被自动路由到存储对应分片副本的其他Pod；
• 从当前数据看，Pod-2、3的PVC仅存储集群元数据，未分配实际分片，因此Pod-3故障不会影响现有数据的访问。

2. Shard是逻辑概念还是PV中的物理分区？我通过Qdrant客户端的REST API或Python模块创建集合时会生成分片，但分片如何与4个Pod关联？ #

• Shard是逻辑概念，对应集合的部分数据子集（基于哈希规则划分），在PV中以独立目录形式存储，而非物理分区；
• 分片与Pod的关联由Qdrant集群自动管理：
  1. 创建集合时指定shards_count（分片数）和replication_factor（副本数）；
  2. Raft leader节点根据集群负载、节点状态，将分片（含副本）分配到不同Pod；
  3. 未分配分片的Pod仅存储集群元数据，因此PVC占用空间极小。当前仅Pod0、1有数据，说明分片仅分配到了这两个节点。

3. 若配置HPA，Pod数量不固定，非高峰时段Pod缩容时，其上的分片会被删除吗？对应的PVC未删除但无法被其他Pod访问该如何处理？ #

• 缩容Pod时，Qdrant会先将该Pod上的分片（含副本）迁移到集群内其他可用Pod，不会直接删除分片数据；仅当分片无副本且Pod被删除时，数据才会丢失；
• 缩容后遗留的PVC默认不会被删除，其中的分片数据已完成迁移，属于冗余存储，处理方式：
  • 在Helm values中设置persistence.deletePVC=true，让StatefulSet缩容时自动删除对应PVC；
  • 手动清理无数据的PVC，避免存储浪费；
  • 合理配置HPA缩容阈值，减少频繁缩容带来的分片迁移开销。

4. 我们需推送3亿条集合数据，高可用性部署的最佳实践是什么？是否需要像常规StatefulSet一样将数据复制到所有PVC/Pod？ #

不需要将数据复制到所有Pod，Qdrant采用分片+副本的分布式存储模式，最佳实践如下：

• 分片与副本规划：按每个分片存储500万-1亿条数据计算，3亿条可设置3-6个分片；同时设置replication_factor=2或更高，保证每个分片至少有1个副本，避免单Pod故障导致数据丢失；
• 存储配置：使用Azure Premium SSD这类高性能存储，为PVC分配足够容量，设置存储类reclaimPolicy=Retain防止数据意外丢失；
• 集群架构：Pod数量需≥分片数×副本数，确保分片均匀分配；将Pod调度到不同AZ的节点，避免单AZ故障影响多个分片；
• HPA配置：基于CPU/内存或Qdrant自定义指标（如查询延迟、分片负载）配置HPA，扩容时优先补充节点再增加Pod，缩容时确保有足够目标Pod接收分片迁移；
• 监控与备份：用Prometheus监控分片状态、存储使用量，定期通过Qdrant快照API或PVC备份机制留存数据。

内容的提问来源于stack exchange，提问作者Rajendra N