AzureFile持久卷性能过慢问题及解决方案咨询

问题 #

我们使用AKS集群以Docker容器形式托管Azure DevOps（ADO）构建代理，已按微软官方文档完成配置。为实现多AKS代理Pod共享缓存，参考微软文档配置了基于文件共享的Persistent Volume（PV）作为Maven和Node构建缓存仓库，但构建速度比正常情况慢4倍。当前使用带专用端点的标准异地冗余存储（GRS）文件共享；采用Azure磁盘作为PV时构建速度较快，但磁盘类PV无法跨多节点挂载。现咨询：

1. 基于文件共享的PV性能问题产生的原因及推荐解决方案；
2. Azure磁盘能否实现跨多节点共享？

相关配置代码 #

Persistent Volume 配置

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: file.csi.azure.com
    readOnly: false
    volumeHandle: unique-volumeid  # make sure this volumeid is unique in the cluster
    volumeAttributes:
      resourceGroup: my-rg
      shareName: aksshare
    nodeStageSecretRef:
      name: azure-secret
      namespace: ado
  mountOptions:
    - dir_mode=0777
    - file_mode=0777
    - uid=0
    - gid=0
    - mfsymlinks
    - cache=strict
    - nosharesock
    - nobrl

Persistent Volume Claim 配置

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: ""
  volumeName: my-pv
  resources:
    requests:
      storage: 100Gi             

Secret 配置

apiVersion: v1
data:
  azurestorageaccountkey: ''
  azurestorageaccountname: ''
kind: Secret
metadata:
  name: azure-secret
  namespace: aks
type: Opaque

解答 #

问题1：文件共享PV性能问题的原因及解决方案 #

性能慢的核心原因

• 存储层级与冗余策略：标准GRS文件共享会将数据同步到异地区域，跨区域同步带来额外延迟，且标准存储的IOPS、吞吐量本身低于高级存储，无法匹配构建缓存频繁读写的需求。
• 挂载配置不合理：当前mount options中的cache=strict强制所有读写操作直接同步到后端存储，完全禁用客户端缓存，大幅增加IO往返时间，是速度慢的关键因素。
• 协议固有特性：Azure文件共享基于SMB协议，在高并发小文件读写场景（如Maven/Node缓存的大量依赖文件）下，相比本地块存储天然存在性能劣势。

推荐解决方案

1. 升级存储层级与冗余策略
   • 替换为高级本地冗余存储（LRS）文件共享：高级存储提供更高IOPS（最高100K）和吞吐量（最高1GB/s），LRS避免跨区域同步延迟，完全满足构建缓存性能需求。若无跨区域容灾需求，坚决放弃GRS/GZRS。
2. 优化挂载参数
   • 将cache=strict改为cache=loose：允许客户端缓存文件数据和元数据，减少与后端存储的交互次数，提升小文件读写速度。
   • 添加actimeo=30：设置元数据缓存有效期为30秒，降低元数据查询频率。
   • 修改后的mount options示例：

     - dir_mode=0777
     - file_mode=0777
     - uid=0
     - gid=0
     - mfsymlinks
     - cache=loose
     - nosharesock
     - nobrl
     - actimeo=30
     

3. 缓存分层策略
   • 为每个代理Pod配置本地临时缓存（如emptyDir），常用依赖先缓存到本地，仅在缺失时从共享存储拉取，同时将新依赖同步回共享存储，结合共享存储的全局特性与本地磁盘的高性能。
4. 调整共享存储容量
   • Azure文件共享性能与容量挂钩：标准存储每TB提供100IOPS，高级存储每TB提供500IOPS。若当前100Gi对应的IOPS不足，可扩容至200Gi或更高，提升基础性能。

问题2：Azure磁盘能否实现跨多节点共享？ #

Azure磁盘默认不支持跨多节点共享：

• 标准SSD/HDD、高级SSD磁盘默认访问模式为ReadWriteOnce，仅能被单个节点上的Pod挂载，无法跨节点共享。
• 唯一支持ReadWriteMany的是Azure共享磁盘，但限制严格：
  • 仅支持高级SSD和Ultra磁盘类型；
  • 需使用CSI驱动，且集群版本需符合要求；
  • 最多支持16个节点同时挂载；
  • 需配合集群文件系统（如GlusterFS、OCFS2）使用，否则多节点同时写入会导致数据损坏。

对于你的构建缓存场景，共享磁盘配置复杂度高、成本远高于优化后的文件共享，优先优化文件共享性能是更合理的选择。

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