这是上下两篇技术文章中的下篇，文中将探讨服务器虚拟化对 IO 设备的影响。在上篇《Luca Bert：服务器虚拟化和DAS存储(上)》中，我们讨论了业界目前的情况，介绍了如何利用当前的服务器架构部署虚拟化，并指出了目前大部分工作都集中在 CPU／存储器复杂性方面，因此忽略了 IO 方面的问题。
所以，比较合理的步骤是考虑服务器虚拟化需要解决哪些问题，如服务器虚拟化会对哪种领域产生最大的影响，特别是对 CPU 和存储器的复杂性会产生什么影响。不过，现在情况却发生了逆转。现在，基于新型虚拟化 CPU／存储器基础架构的计算技术充分发挥其潜力，但 IO 却落在了后面，这使其成为未来需要重点解决的对象。存储子系统是本文讨论的主题，因为它在系统中发挥着重要的作用，且特别受 IO 领域局限的影响。
在目前的虚拟化服务器中，存储 IO 主要受如下三大方面的影响：
- 性能：在 MB/sec 或 IO/sec 方面所受的影响不太大，仍可维持可接受的速率，但在时延（命令从 OS 传输到存储设备以及存储设备做出响应后反馈给原 OS 所需的时间）和系统 CPU 占用率（每台 IO 所占用的处理资源）方面所受的影响较大。
- 安全性：如上篇所述，所有运行在虚拟机 (VM) 中的操作系统都可通过系统管理程序级发出 IO 调用来处理，可能对数据完整性造成危险，出现安全漏洞。
- 服务质量 (QoS)：局限于系统管理程序的功能，不在存储控制器上。
说到底，上述问题的根本原因在于目前的服务器虚拟化架构。IO 根本就没有被虚拟化，也就是说，系统管理程序只是对 IO 虚拟化进行了简单低效的模拟。
更具体地说，一方面，管理程序"欺骗"了每台虚拟机，使其认为自己完全拥有了所有 IO 资源，而实际上这些资源需与其它的虚拟机共享；而另一方面，系统管理程序还"欺骗"了 IO 控制器，使其认为自己接到的命令来自于同一部虚拟机，而实际上其接到的请求来自于系统中安装的所有虚拟机。现在这种解决方案虽然简单，不需要改变 IO 子系统，但却造成了上述效率低下以及性能局限性等代价。
为了解决上述问题，近期业界提出了 IO 虚拟化模型，并将其整合至 PCI Express 标准中，该模型包括单根 IO 虚拟化 (SrIOV) 和多根 IO 虚拟化 (MrIOV) 两种。
这种 IO 虚拟化的理念极其简单：系统管理程序不再作为虚拟机与 IO 控制器之间的中间人，而是建立一种全新的环境，使每台虚拟机都能直接与 IO 控制器打交道，不再受系统管理程序的干涉。同时，IO 控制器可提供一个与每台虚拟机通信的专门路径，以使所有不同的 IO 线程分离。
SrIOV 完全在一台服务器（即一个"PCIe 根"）平台中处理此类控制器协议，而 MrIOV 则将上述解决方案进行了扩展，存储控制器不再与服务器物理关联，可服务于多台服务器平台。这对刀片和砖式计算机而言是一种非常有趣的解决方案，不过这更适合未来长期发展的应用。
Luca Bert,LSI公司知名存储技术专家
尽管上述解决方案看上去简单直接，但实际上这非常复杂，特别是在存储控制器方面会遇到不少问题，而且还会对存储子系统以及相关服务带来了全新的机遇和挑战。
系统管理程序需解决如下三个问题：
- 性能：系统管理程序完全被绕开，因此时延与 CPU 占用方面的性能直接取决于非虚拟化服务器能否优化。
- 安全性：每台虚拟机均拥有自己的 IO 线程，其既不会整合，也不会使用共同的资源，直到他们同时处于存储控制器内部，这种情况才会发生。因此，这不存在数据污染、损坏或安全漏洞的风险，至少这比共享同一存储控制器的独立式非虚拟化服务器要安全的多。
- QoS：存储控制器现在能了解到每台虚拟机的情况，并可根据每台虚拟机乃至每个 IO 来实施 QoS 策略，从而创建一个可支持各种 QoS 级别的环境。
不过，事情并不总像看上去那么简单，特别是对共享资源的存储控制器而言更是如此。我们不妨谈谈 LAN 控制器这另一种常见的 IO 子系统，并以此为例加以说明。LAN 使用 TCP/IP 以及其它类似的已知协议，在每台本地虚拟机与远程系统之间建立了连接。其主要优势在于，所有线程都彼此分开隔离，特别的是它们并不共享任何相同的目标元素（如使用共享的传输将不同的虚拟机连接至不同的目标）。在此环境下，IOV 的使用比较简单，目前一些 LAN 控制器能够支持这种工作，虚拟服务器也能从中充分受益。
存储控制器的情况与此不同，因为"目标"设备通常不能专供连接的虚拟机使用。例如，RAID 控制器可将两台虚拟磁盘连接至两台虚拟机上，这两台虚拟机每台都能作为唯一的所有者，但事实上，这些虚拟磁盘是同一物理磁盘的 RAID 抽象。
上述情况会造成严重的管理问题，通常需要将此前仅限于 SAN 领域的技术移植到服务器领域中，进而使子系统的配置与外部 RAID 控制器的相似度更高于其与传统的 DAS 的相似度。
如果我们从高级抽象的角度看，SrIOV 对服务器的作用（对 MrIOV 而言则可能是对刀片的作用）就是创建一个"服务器中的 SAN"，而用户将同时获得服务器的存储小型化与低成本的优势以及 SAN 控制器的可配置性与高灵活性的优势。但用户需付出的代价则是投资全新的 IO 子系统架构。这就是技术"发展"之所在……
最后要说的一点是，解决方案的不断发展将挑战并推动其它相关技术的发展。同时也会为进一步的技术改进带来新的机遇。例如，现在的系统管理程序不仅能为 IO 提供"通道"功能，有时还可提供 Vmware VMFS 等本地文件系统功能，进而可将其用于创建快照以及自动精简配置等服务。不过，SrIOV 使我们可以完全绕开系统管理程序，因此也就可以避免出现上述的数据操纵 (data manipulation) 情况。我们可通过一些解决方案来应对这种情况，而最可能的一种方法则是将上述服务移植到存储控制器内部，这将使其越来越像是"服务器中的 SAN"：类似于 SAN 的配置、类似于 SAN 的连接以及快照与自动精简配置等类似于 SAN 的服务。
放眼未来，我们应该指出，多服务器虚拟化成功的关键在于虚拟机的移动性，目前我们需要 SAN 来确保存储对每台服务器的可用性，但我们不难设想，MrIOV 不仅将为 DAS 提供相同的功能，而且还将支持 DAS 存储的虚拟机移动性。
注释：我们详细介绍了需要服务器虚拟化的理由、服务器虚拟化对存储控制器产生的影响，以及 IO 控制器的虚拟化会带来什么样的新型解决方案。随着技术转型的完成，我们将看到基于 DAS 的存储控制器会类似于 SAN 存储控制器，二者唯一的区别在于 DAS 使用 PCIe 传输，而 SAN 则采用一套完整的存储协议（FC、GbE、SAS、IB 以及 FCoE 等等）。不过，随着越来越多的存储控制器通过虚拟化技术提供诸多服务的同时，服务器也将嵌入更多的存储服务，上述界限也将变得日益模糊。
未来的几年里，我们所关心的问题很可能不再是基于 DAS 的服务器存储和基于 SAN 的平台，而是重点讨论既能配置为通用服务器又能配置为存储服务器的通用计算平台，而包括 IOV 技术在内的服务器虚拟化技术将是上述技术发展整合的基础。
