虚拟机添加OSD的性能瓶颈，绝大多数不在Ceph本身，而在虚拟化层的磁盘模拟与资源争抢；兼容性问题则集中在SCSI指令透传和块设备管理上，解决思路很简单：让OSD尽可能“直通”物理硬件，而不是被虚拟化层“翻译”一遍。
Ceph集群跑在虚拟机上，本身不是离经叛道的事，国内不少中小型IT团队为了省物理机器，或者为了复用云平台资源，都会优先把OSD放在虚拟机里，但真正一跑起来，各种怪问题就出来了：写入速度忽高忽低、某个OSD时不时卡死、重启后盘符乱跳、Trim指令发不下去，这些现象背后,其实都能在虚拟化配置上找到根源。
ceph虚拟机添加osd性能下降排查：瓶颈到底卡在哪一环
想解决性能问题，得先搞清楚性能在哪个环节丢掉的，OSD在虚拟机里的数据路径比物理机多走两三层，每一层都在“雁过拔毛”。
虚拟机磁盘类型对osd性能影响有多大
虚拟磁盘的IO路径，决定了时延和吞吐量的天花板，以最常用的KVM虚拟化为例，ide、virtio-blk、virtio-scsi、PCIe NVMe直通这四种方案,性能差距是代际性的。
- ide模拟磁盘：完全由QEMU软件模拟磁盘控制器，CPU开销极大，随机读写性能惨不忍睹,现代Ceph版本下基本不具备可用性。
- virtio-blk：半虚拟化方案，guest内核直接感知虚拟队列，省掉一部分模拟开销，随机读写表现尚可，但队列深度和并发能力有限,单队列设计在高IOPS场景下容易成为瓶颈。
- virtio-scsi：多队列仿真的SCSI控制器，支持更丰富的SCSI命令集，对Trim、Disk Geometry等的兼容性更好。多数性能问题排查到后期，都会发现是控制器类型没选对。
- PCIe NVMe直通：直接把物理NVMe盘或控制器透传给虚拟机，命令直达硬件，几乎没有虚拟化损耗，但牺牲了迁移和高可用灵活性。
如果你的OSD磁盘是HDD，virtio-blk勉强够用；如果是NVMe SSD，务必选择virtio-scsi或直通方案。业内专家指出，虚拟化场景下OSD性能衰减最大的诱因不是网络，而是磁盘控制器类型和队列深度设置。
KVM虚拟化ceph osd性能优化必须关注的四个层面
排查OSD性能问题，我习惯分四层逐层检查,缺一不可。
- CPU层：OSD进程对CPU中断特别敏感，虚拟机的vCPU如果没做物理核绑定（vCPU pinning），调度器在多个物理核之间迁移，会造成大量缓存未命中和中断延迟,直接体现在OSD的op延迟飙高上。
- 内存层：Ceph的OSD内存主要用于PG相关的元数据缓存，以及BlueStore的块缓存，虚拟机如果开启内存气球（memory balloon），宿主机内存不足时回收内存，轻则拖慢性能，重则触发OSD进程被OOM Killer杀掉。
- 磁盘调度层：Guest内的磁盘调度器默认是cfq或mq-deadline。把调度器改为none（noop）是解除排队延迟最直接的手段，对于SSD，mq-deadline都能省则省,直接none完事儿。
- 网络层：OSD之间有心跳和复制流量，虚拟机网卡如果走virtio默认队列，单队列撑不住多OSD的高并发，务必开启vhost-user或者多队列virtio-net。
实操时，先把guest里的调度器改掉，再检查宿主机上的libvirt CPU pinning配置，改完后你会发现，多数情况下“虚拟机性能差”其实只是默认参数太保守。
解决OSD性能瓶颈的实操方案：从驱动到CPU独占
知道瓶颈在哪，下面就是动手环节，这套组合拳适用于Ceph Octopus及更新版本,也兼容老旧的Luminous版本。
优先选择virtio-scsi并开启discard支持
创建虚拟机或给已有虚拟机加OSD时，磁盘总线选择virtio-scsi,并在XML配置里加入trim支持。
virsh edit your-osd-vm
在磁盘配置段确保有以下内容：
<disk type='file' device='disk'> <driver name='qemu' type='raw' cache='none' discard='unmap'/> <target dev='sda' bus='scsi'/> </disk>
cache='none'是必须的，direct IO模式能让OSD自己管理缓存，如果写缓存设为writeback，宿主机宕机时数据丢失风险极大，Ceph也会频繁报错。discard='unmap'开启后，BlueStore删除对象时才能把Trim命令透传给物理盘,否则SSD写放大问题会逐渐拖垮性能。
如果虚拟机已经跑起来了,可以通过在线方式验证Trim是否生效：
lsblk -D
看到DISC-GRAN和DISC-MAX不为0,说明Trim路径已打通。
CPU独占与NUMA亲和性绑定
物理机CPU是多核多路时，交叉访问内存的代价非常高，OSD虚拟机必须绑定到固定的物理核，并且绑定范围要落在同一个NUMA node内。
virsh vcpupin your-osd-vm 0 4 virsh vcpupin your-osd-vm 1 5 virsh vcpupin your-osd-vm 2 6 virsh vcpupin your-osd-vm 3 7
然后再给虚拟机设置内存绑定：
virsh numatune your-osd-vm --nodeset 1 --mode strict
相当的OSD性能问题都是NUMA跨节点访问导致的，尤其是在OpenStack或Ovirt这类云管平台批量创建的虚拟机里,默认配置完全不感知物理拓扑。
调整队列深度与IO线程
- 宿主机侧：确认磁盘控制器的IO队列深度，NVMe SSD通常建议到128或256以上。
- guest侧：virtio-scsi的多队列能力依赖
scsi_mod.use_blk_mq=1启动参数,内核较新的发行版默认开启。 - Ceph侧：
osd_op_threads和bluestore_block_size保持默认即可，不要盲目调高线程数，虚拟机CPU核数有限,线程数大于vCPU数反而引发上下文切换开销。
虚拟机添加OSD兼容性问题的避坑指南
性能只是其一，兼容性才是真正让人头疼的部分，尤其是把物理机上的Ceph集群迁移到虚拟机平台时,各种诡异问题轮番上演。
virtio-scsi与virtio-blk对Trim和SCSI命令的兼容差异
virtio-blk不支持完整的SCSI命令集，导致fstrim、blkdiscard这类操作在guest里执行后，底层块设备根本没有收到指令，Ceph层面看起来PG正常，但物理SSD长期不回收块,最终写入放大率会高得离谱。
行业共识认为，运行Ceph OSD的虚拟机磁盘控制器必须选用virtio-scsi，它能透传SCSI的UNMAP和WRITE SAME命令,和物理机的SAS控制器行为一致。
虚拟机磁盘顺序漂移导致OSD无法启动
这个问题在添加新OSD时最容易触发，虚拟机重启后，/dev/vda和/dev/vdb的对应关系可能颠倒，结果Ceph的OSD启动脚本找到了错误的块设备,直接报错。
所以别在fstab和ceph的osd配置里使用/dev/sdX这种设备名，改用/dev/disk/by-id/或by-path/下的稳定符号链接。
ls -l /dev/disk/by-id/
找到你有OSD数据的那个硬盘，在ceph配置中通过device符号链接来指向它,而不是原生的sdX。
内存气球和透明大页引发的稳定度问题
云平台一般默认开启内存气球，平时没事，一旦内存压力上来，宿主机强行回收内存页，OSD进程会发生大量major fault，延迟瞬间爆表，甚至触发Ceph的heartbeat超时,被判定为down。
在虚拟机的XML中直接删除memballoon设备，同时将宿主机内核的透明大页设置为madvise或never。
echo never > /sys/kernel/mm/transparent_hugepage/enabled
这是国内机房落地Ceph on虚拟机方案时比较容易忽略的一步。
验证性能与兼容性的一套标准动作
配置都改完之后，别急着把OSD加入集群，先做一轮快速验证,确保不会带病上线。
| 验证项目 | 推荐工具 | 预期结果 |
|---|---|---|
| Trim透传验证 | lsblk -D |
DISC-GRAN非0 |
| 块设备名称稳定 | /dev/disk/by-id/ | 符号链接固定，无漂移 |
| 存储性能摸底 | fio --randwrite=50% | 4K随机延迟低于物理盘10%以内 |
| OSD启动一致性 | ceph-disk activate --all | 无设备名错乱报错 |
跑一轮fio，参考一组典型配置：8 vCPU、16GB内存、virtio-scsi直通NVMe盘。多数情况下，随机读性能可以做到物理盘的九成左右，随机写因为存在日志和WAL的叠加写入，大约在七成到八成，如果远低于这个区间,说明虚拟化配置还是有问题。
虚拟机跑OSD的延迟数据统计中，真实稳态电量和配置相关性极大，用fio跑出来的数只能参考，最终性能要等OSD真正承载PG后，看ceph osd perf里的commitapply latency。
虚拟化跑CEPH的性能价格比与适用场景判断
虚拟机的优势在于灵活部署和运维隔离，用超融合架构里的一台宿主机同时承载数据库和OSD时，价格比优于单独购买存储服务器，但如果你想压榨出每一分IOPS,物理机仍然是不可替代的选择。
- 适用虚拟化场景：容量型存储池、备份归档、开发测试环境,对性能和延迟不太敏感。
- 不适合虚拟化场景：高并发小块随机写的生产块存储池,尤其是对接数据库或云硬盘时。
在酷番云或简米云这类公有云平台上创建的CVM/BMC实例，底层网络和磁盘延迟本身就比物理机高，再做一层Ceph OSD有点叠床架屋,国内自建机房才更适合用虚拟机跑OSD。
虚拟机添加OSD兼容性与性能常见问答
问：虚拟机里添加OSD，性能下降百分之多少算正常？
答：没有标准百分比，virtio-scsi直通NVMe，时延和带宽损失控制在15%以内合理，但启用快照或QCOW2格式后，写路径多一层CoW，下降幅度可能达到50%以上,这种情况下必须改用raw格式裸设备映射。
问：Ceph的OSD推荐部署在物理机还是虚拟机中？
答：取决于存储池用途，Ceph官方测试偏好在物理机验证功能，生产实践中，自建虚拟化平台跑OSD正在变多，但需要满足两个条件：宿主机有本地NVMe盘直通能力，以及虚拟机禁止迁移和快照操作，网上关于延迟过高的抱怨帖，不少是虚拟机默认配置带qemu缓存和调度器抖动导致的。总的原则是：虚拟化提供便利，但你要付出资源隔离的成本，并承担迁移功能受限的代价，这两点权衡清楚了再动手。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/732673.html
