K8S容器环境下disk IO性能调优

背景

某云原生 application 在部署阶段对磁盘 I/O 有明确要求：
在挂载的 volume 上执行如下命令时，返回结果必须 ≥ 1MB/s。

dd if=/dev/zero of=./test2.img bs=4k count=10240 oflag=direct

• 顺序写
• 使用 O_DIRECT（无 page cache）
• 无 fsync
• 无元数据更新
• 无 WAL / journal
• 无随机写
• 无多层 flush

这是一个 4K 小块、无缓存、直写磁盘的测试场景。
如果在该条件下仍能满足性能要求，基本可以覆盖关系型数据库的所有严苛 I/O 场景。

系统架构与部署环境

1. 3 台 Baremetal（HP DL380 Gen11）

   • CPU：96 Core × 4
   • 内存：512 GB
   • 磁盘：4 × 4T HDD + 4 × 4T SSD
   • 网络：10G 光口

2. HDD 做 RAID1 用于 Host OS，SSD 不做 RAID

3. Host OS：Ubuntu 24.04，启用 KVM

4. 每台 Host 上运行多个 VM，其中部分 VM 挂载 SSD

5. VM 上部署 OpenShift

6. 3 个挂载 SSD 的 VM 作为存储节点，部署 ODF（Ceph）

   • 每块 SSD 对应一个 Ceph OSD

7. OpenShift 内部署 MariaDB 集群

   • 1 Master + 2 Slave
   • 使用 Ceph RWO Volume

8. 在 MariaDB 数据卷中执行 I/O 测试

调优过程

初始测试结果约 500~600 KB/s，远低于目标。

• Host 与 VM 层磁盘性能正常（SSD >100MB/s）
• VM 磁盘使用 virtio + cache=none + io=native

<disk type='block' device='disk'>
  <driver name='qemu' type='raw' cache='none' io='native' iothreads='8'/>
  <source dev='/dev/nvme0n1'/>
  <target dev='sda' bus=virtio'/>
  <address type='pci' controller='0' bus='0' target='0' unit='0'/>
</disk>

徘徊多次后，仍旧提升非常有限，检查ceph的性能指标是发现：

root@service:~#  oc exec $(oc get pod -n openshift-storage | grep tools | head -n 1) -n openshift-storage -it -- bash
bash-5.1$ ceph osd perf
osd commit_latency(ms) apply_latency(ms)
11                   0                 0
10                   0                 0
 9                   0                 0
 8                   0                 0
 7                   0                 0
 6                   0                 0
 5                   4                 4
 4                   0                 0
 3                   0                 0
 2                   4                 4
 1                   2                 2
 0                   5                 5

这里很明显的发现问题，osd网络延时有问题，不在同一个host上的osd延时明显较大，对比site上的情况，osd之间的延时是低于1ms的。
进行下一步验证网络延时发现，VM和VM之间，甚至HOST之间的ping值也是高于1ms的，所以基本锁定，性能上不去基本上是网络延时引起的，而不是disk I/O本身性能瓶颈引起。
为了进一步验证，把ceph的副本个数从三个改成一个，测试的结果有了明显的提升。

错误的尝试

中间尝试把HOST的网卡开启SR-IOV，网络延时瞬间降到0.1ms，提升明显，但是部署OCP的过程遇到很多问题，而且考虑到NUMA的影响，资源会浪费一半，无法走通，遂放弃。

尝试更改MTU，从1500增加到8500，有提升到700K/s,仍是无法满足要求，而且OCP更改MTU的成本也挺高。

核心瓶颈

在同另外一套lab环境对比以后，发现有几不同，我们的网卡类型，英特尔的网卡+10G光口，另一套的lab是高通的网卡+10G电口，网速ping值的差距非常明显，一个是1ms，一个是0.1ms,怀疑网卡配置，但是调试多次以后，甚至交换网卡，仍然没有明显的改变。
最后猜测是不是CPU的调度问题，发现两个OS，一个是Ubuntu，一个是redhat，查询以后发现Ubuntu在很久前就引入了CPU idle（C-states），Ubuntu 默认启用内核的 cpuidle 子系统，允许 CPU 进入多级低功耗状态（如 C1, C2, C3 … 更深 C-states），Ubuntu 24.04 引入并默认使用 power-profiles-daemon 来统一管理电源策略，包括 idle、freq 和 sleep profiles。这意味着除了 CPU idle states 外，Ubuntu 24.04 会：

• 在桌面环境中提供电源模式（Balanced/Power-Saver/Performance）选项

• 默认是 Balanced 模式，结合 P-states + idle states 使功耗更低

https://help.ubuntu.com/stable/ubuntu-help/power-profile.html.en

检查Host OS以后，果然是默认开启了这个配置，修改成Performance模式，果然网速ping值里面提升到0.1ms， ceph的性能立马延时也降到1ms内。

再次测试dd，效果立竿见影达到1.4M/s，达成目标。

总结

1. 确认问题是网络延时引起的，明确瓶颈方向后持续深挖，避免无效调参。
2. HostOS尽量使用成熟的商业版本，推荐RedHat/RockyLinux。
3. 上层有软件级别的存储服务(Ceph),物理层就不要做raid了。
4. KVM跨node进行部署的时候还是会有小问题，优选还是安装openstack作为VNF层。

P.S. 以下命令会直接破坏磁盘数据，注意of的指向目录，请勿在生产环境使用：

dd if=/dev/zero of=/dev/vdd bs=4k count=10240 oflag=direct