KVM存储虚拟化

KVM存储虚拟化

引用了网上的一些图片，感谢没查到名字的大神们

KVM的存储模式有很多种，threads，dataplane，vhost等，甚至还可以利用PCI直通技术做存储的直通。当然还有好几种cache模式，比如None，Writeback，Writethrough等。本文不会聚焦于这些技术的实现原理，仅从实践场景出发，总结一下这些模式的特点，和各自能够胜任的场景。以及在实践过程中，遇到的一些问题，尤其是性能问题，以及它们对应的解决方案。

典型KVM存储栈

如下图，是一个典型的KVM虚拟机的存储栈，所有存储模式基本上都大同小异。程序和内核与在物理机上运行没有什么差别。Guest通过硬件仿真与Qemu通信；Qemu将IO转化成对镜像文件的读写；Host kernel处理Guest里面来的IO和其他一般程序也就没有什么差别了。 

从上见面这张图其实就可以看出KVM甚至其他hypervisor虚拟机存储栈的一些特点：

两套文件系统，Guest和Host分别都有文件系统。

两套存储管理，比如Guest和Host都可以用LVM等做存储管理。

两套page cache，Guest和Host都有针对文件的Buffer。

两套IO调度，Guest里面调度一次，Host再调度一次。

从上面描述的这几条继续分析，实际上这样的存储栈上面是有一些问题的，所有的工作，里面和外面重复了。实际上 ，在真实的业务场景下，这样的重复工作确实会带来一些问题，最典型的就是性能和数据可靠性的问题。 

先说数据可靠性，在一些数据可靠性要求高的情况下，应用程序会使用Direct IO或者Sync等命令保证数据已经被正确地写到了磁盘上面。还有磁盘调度，比如我们常见的电梯算法，它主要是为传统的机械硬盘设计的，目的就是最大化地在一个周期内合并相邻的IO，从而提升存储性能。这两种技术都不是诞生于虚拟化时代，所以将这两种技术用于虚拟机时，就有可能会产生一些和预想不太一样的结果。

调度的选择

　　因为有镜像文件，Host的存储视角和Guest的存储视角是不一样的，尤其在精简置备这种场景下，在Guest里面相邻的两个数据块在Host上不一定是相邻的。所以在Guest里面合并在一起的IO到了Host以后，又要被拆开。反而造成性能的下降。

所以，一般在虚拟机里面做存储性能优化，都会将调度器设置成为deadline或者none，来减少Guest内部调度器做的无用功。 

当然在使用一些高端存储时，也会建议将调度器设置成为deadline或者none，具体原因会在后面的SSD存储章节里面分析。

Cache的选择

writethrough

这个模式是默认的，如果选择这个模式，Host page cache会生效，但Guest中的磁盘写cache会被禁止。这也就是说，即使Guest里面没有做往磁盘上刷数据的操作（比如fsync之类的），数据也会被写入到物理磁盘中。这种方式写性能会比较差。

writeback

如果选择这个模式，则Host page cache和Guest中的磁盘写cache都是生效的。正因为这样，这种模式的IO性能是最好的，但是有掉电丢失数据的风险。

none

这个模式是Host page cache不生效，但是Guest的磁盘写cache生效。如果Guest里面用fsync之类的命令，则可以保证数据被写入到物理存储中。因为没有page cache，所以读性能会差一些。

unsafe

因为Qemu支持这种cache模式，所以我把它列了出来，但正如它的名字，这种模式不建议用在生产环境中，所以我也就偷个懒不写了。

这些cache模式没有说哪个是最好的，在特定的业务场景下，根据性能和数据可靠性的要求去选择最合适的那个吧。 

小结

　　OS运行在虚拟机里面时，它所管理的硬件不再是真正的硬件，而是hypervisor虚拟出来的硬件，所以Guest OS看到的硬件视图和Host上的硬件视图有一些差别。这一点，在存储世界尤其明显。比如在Guest里面给0扇区写数据，对应到Host的物理存储上就不一定是0扇区了；在Guest里面相邻的两个存储数据块，在Host上就不一定是相邻的了。 

　　在物理机上运行还比较好的代码，在虚拟机里面就不一定合适了。所以在实践过程中，一些功能重新审视，Guest和Host内外重新协调起来，才能使存储这块运行地更加流畅。