为何实行服务器虚拟化？

透过服务器合并，可以协助解决服务器使用率过低的问题（根据IDC在2007年初的研究，显示业界广泛认同的平均使用率为7%）。尽管每台服务器的使用率不一样，但他们同样必须进行采购、建置，以及消耗电力。要解决这些问题，第一步也是最简单的一步，就是将在所有不同服务器上执行的操作系统与应用程序，集中到单一平台上执行。这种作法的主要好处是降低采购成本，以及减少耗电量。

第二个阶段的重点是效率，旨在让多部虚拟化服务器能机动管理各种资源、将虚拟机在各部服务器之间转移、自动处理故障转移作业、和以透明化模式进行预定时程的停机、升级、维护等动作。这个阶段非常注重降低平台的管理成本与营运费用，而硬件与软件的技术均沿着类似的发展途径－第一个建置的方案采用标准硬件，使用像是二位更新修正档等软件技巧，来建构虚拟层。之后再加入像是Intel VT-x 与VT-i 技术，以及AMD-V等硬件组件，协助从客户端操作系统中进行CPU与内存提取的复杂作业。

下一步骤，首先处理的也是软件：将虚拟机监视器（Hypervisor）基础架构，从二位更新修正档转移到仿真与半虚拟化，藉以改进底层虚拟化架构的效率并降低系统的负荷。最后一步是降低虚拟化环境所占用的空间，从GB降低到数十MB，减少软件所耗用的资源。

被遗忘的I/O

由于初期的焦点大多数是软件基础架构，因此所有的心力都聚焦于改进常见的软件瓶颈，但其中大多数问题其实来自CPU与内存。

I/O通常被视为一个经常使用的资源，即使虚拟机监视器将I/O从操作系统（称为Guest OS或GOS）中抽离，还是会让每一个动作看起来彷佛I/O仍然存在。事实上，这种解决方案仍相当实用，尤其是在最近有显著进步的仿真与半虚拟化技巧辅助之下。但这意谓I/O硬件仍属于单一组件，本身拥有许多先天的限制。例如其仍会被虚拟机监视器所“欺骗”，假装自己是在服务单一操作系统，而不是同时服务多个虚拟化的GOS。

由于I/O与GOS缺乏“相互认知的能力”，因此虽然能简化部署的过程（由于操作系统与I/O都不知悉对方，因此并不需要任何变更），但却衍生出本身的效率问题，还有安全方面的疑虑。

基本上，虚拟机监视器是所有组件的守护者，而每个GOS的每次I/O要求，都必须由虚拟机监视器来处理。虚拟机监视器提供抽离服务、处理GOS队列、岔断服务、以及管理异常状况。

从好的一面来看，目前的模式提供许多能改进I/O及储存功能的机会。最显而易见的例子，就是虚拟机监视器拥有一个内部文件系统（例如VMware中的VMFS），能从软件面着手，作为储存虚拟化的汇整点，然后再将软件重新分配给GOS。

上述模式支持许多以往向来和SAN有关的功能：诸如随需分配储存、建立快照、以及透过数据群聚（Pooling）或其他技术，进行抽象储存。一组链接至储存局域网络的服务器，成为与虚拟机监视器文件系统的GOS储存链接，而这样的储存系统仍旧位在实体机壳的内部。但这也形成许多限制，包括：

效能：

相较着重于MB/sec或IO/sec的非虚拟化服务器来说，这部分的问题比较严重。因为虚拟机监视器会运用系统CPU来管理抽象作业（进而降低生产力应用所能掌握的CPU运算周期），且数据在传到发出要求的GOS之前，必须透过虚拟机监视器进行转移。这会对每个GOS产生冗长的延迟，进而降低GOS的生产力。对于依赖快速反应来提高生产力的交易型应用，这方面的问题会更加严重。效能不必非得取决于将MB/sec或IO/sec维持在可接受的范围，其他如延迟（指令从操作系统传送到储存装置，以及储存装置响应到原始操作系统所耗费的时间）和系统CPU使用率（处理每个I/O须耗费的资源）亦为重要因素。

安全性：

当所有数据都汇入虚拟机监视器时，他们就变得必须跟其同生共死。虚拟机监视器上的臭虫（Bugs）、操作人员的管理疏失、以及病毒等，都会影响在平台上的所有数据与操作系统与应用程序，而不是仅影响单一个体。安全防护由虚拟机监视器软件来统括执行，这虽然对某些应用程序来说非常安全，但对其他程序来说可能是一个严重的安全漏洞。

服务质量（QoS）：

同样的，服务质量也跟虚拟机监视器有关。透过虚拟机监视器，系统必须执行更多程序代码来加强服务质量（运用系统资源），但这类程序代码仅能执行虚拟机监视器所提供的功能。在I/O控制器的层级上进行虚拟化服务质量的调整是不可能的，但I/O却对此事一无所知，因此其与成为最佳导入方案还有一大段距离。

即使它们无法察觉虚拟化组件层，但虚拟化仍为DAS磁盘阵列控制器提供类似储存局域网络的优点。最明显的证据就是储存汇整功能，因为这向来都是SAN型磁盘阵列最重要的特色之一。在效能与可靠度的考虑之下，用户通常须为非虚拟化服务器提供超额的储存资源，而这导致了资源使用率过低与部署成本昂贵的问题。虚拟化服务器仅需如同SAN所需的资源数量，并可视情况汇整储存空间，以及建立LUN（Logic Unit Number）给每个GOS（或虚拟机监视器自己的文件系统），并以所有常见的SAN技术来支持。

最后要提的就是I/O，特别是DAS储存系统，有局限于本地端平台的特色，这是说用户可以将储存资源抽离至某一服务器上所运行的GOS，但不影响另一部服务器上的GOS。因为服务器间并无有效的沟通管道，因此可以避免若某一台服务器故障，所有本地端储存盘案跟着毁损，导致没有任何服务器可供使用的窘境。因此，目前的VM行动建置方案，都要求将储存系统链接至SAN。

但上述缺点都只是在服务器虚拟化第一阶段，完全聚焦于CPU与内存管理下所造成的结果，因为在此阶段虚拟机监视器必须在没有任何硬件的协助下，独力解决抽离储存空间的问题。随着虚拟化日趋普遍，I/O的虚拟化也越来越重要。各种新技术推陈出新，不仅将排除虚拟化系统I/O面临的各种限制，还能维持所有的优点。这方面前景最看好的技术，就是Single-Root IO 虚拟化（SrIOV）与Multi-Root IO 虚拟化（MrIOV）。

虚拟机与IO的关联

从CPU与内存方面开始，探究服务器虚拟化需要解决的各项问题，包括其中受影响较大的地方，应该是一个合理的切入角度。但目前的情况是，当新型虚拟化CPU/内存基础架构所构成的操作数件，正要开始如预期般发挥效益之际，I/O的发展脚步却落在后头，因此将成为未来发展的焦点。储存子系统在上述限制下所受的影响尤其深远，且因其在主系统中的地位特殊，因此将成为本文另一个探讨重点。

目前服务器虚拟化架构中，所有问题的根本来源，就是IO本身完全没有被虚拟化─最多仅是透过虚拟机监视器，提供一个简单但缺乏效率的IO虚拟化仿真环境。

更明确的说，一方面虚拟机监视器会「欺骗」每个虚拟机，让它以为自己完全拥有每个IO资源，但实际上这些资源却是和其他虚拟机分享；另一方面则是「欺骗」IO控制器，让这些控制器以为只从一个虚拟机接收指令，但实际上指令是从系统中所有的虚拟机发出。这种解决方案的价值在于简单且不需要对IO子系统进行任何异动，但代价是缺乏效率以及上述的种种限制。

为解决这些问题，最近业界提出一个IO虚拟化（IOV）模型，并将其加入PCI Express标准中。这个模型主要有两种衍生版本，分别称为单根IO虚拟化（SrIOV）与多根IO虚拟化（MrIOV）。蕴含其中的观念相当简单：与其让虚拟机监视器作为虚拟机与IO控制器的中介，不如让IOV直接建立一个环境，让每个虚拟机可直接存取IO控制器，不需要虚拟机监视器的介入。此外，IO控制器能提供一个与虚拟机沟通的独特管道，以维持每个IO线程不受干扰。

SrIOV将该控制器协议完全收录在单一服务器（称为一个「PCIe根」）平台上，而MrIOV则将该解决方案延伸，想象储存控制器被移出服务器，并同时为多部服务器平台提供服务。对于刀锋型与砖块型计算机来说，这是一种有趣的解决方案，但它更适合支持未来各种新应用。

虽然这种建置方案看似简单且直接，但实际上却十分复杂，尤其是针对储存控制器而言。同时，它也替储存子系统与相关服务，创造一种全新类型的机会（以及各种挑战）。

同样地，我们就虚拟机监视器所能解决的问题，分三方面讨论：

效能：

虚拟机监视器可以完全被绕过，以建立一条无论在延迟或CPU使用率方面的效能，都足以媲美处于最佳情况下非虚拟化服务器的线路。

安全性：

每个虚拟机都拥有自己的IO线程，这些线程在进入储存控制器之前，都不会进行合并或共享资源。因此，在这边不会有数据污染、毁损、或安全入侵的危机－或至少优于共享储存控制器的非虚拟化独立服务器。

服务质量：

储存控制器现在能感应到每个虚拟机，并能针对每个虚拟机甚至是每个IO套用服务质量策略，建构一个可支持每个层级服务质量的环境。

储存控制器的特性与限制

但是，事情总是不像一开始所想的那么简单，尤其是对于共享资源的储存控制器而言。为说明这种情况，我们来看另外一个常见的IO子系统：局域网络控制器。局域网络会藉由TCP/IP或是类似的通讯协议，来为每个本地端虚拟机与远程系统之间各建立一条联机。这种方法最大的好处是，所有线程都是独立且分开的，不会共享任何通用目标组件（也就是说，他们共享一个传输管道，将不同的虚拟机链接到不同的目标上）。在这个环境下，IOV的用途变的相当单纯，并且因为目前已有数个局域网络控制器的支持，虚拟化服务器可以发挥完全的效益。

储存控制器的情况则不相同，因为「目标」装置通常并不完全属于所链接的虚拟服务器。例如，一个RAID控制器可把两个虚拟磁盘配置给两部虚拟机，而这些虚拟机可将自己设定为唯一的拥有者，但事实上，这些虚拟磁盘是来自同一个实体磁盘的RAID抽象单元。

这造成了一个管理上的问题以及需求，因为以往受限于SAN的技术现在被导入服务器域中，逐渐使子系统的组态变得更像外部RAID控制器，而非传统上应有的DAS。

若从更高的抽象层面来看，SrIOV为服务器（若为刀锋服务器，则需MrIOV）建立一个「内部SAN」，让用户可充分利用服务器储存的小型化（与低成本！），及SAN控制器的可调整性与弹性。但如此一来，所需付出的代价是IO子系统新架构的投资，而上述过程一般被称为「进化」。

这些革命性的解决方案总是会挑战现有的其他相关技术，但同时也为其创造了进一步创新的机会。例如，虚拟机监视器不仅为IO提供“漏斗”功能，还提供一个本地端文件系统（像是Vmware VMFS），可用来建立各种服务如快照、资源随需分配等。SrIOV则允许系统绕过虚拟机监视器，可以有效避免上述数据被操作的问题。这类问题有许多解决方法，但目前看来可能性最高的是转移储存控制器内的这类服务，造成越来越多像是「服务器内SAN」的情况，例如类SAN组态、类SAN链接，以及各种类似SAN的服务，包括快照与资源随需分配。

展望未来，我们必须着眼于多重服务器虚拟化的关键，也就是虚拟机的机动性。虚拟机机动性要求SAN必须保证能为每部服务器提供充裕的储存资源，而MrIOV则为DAS储存提供相同的功能与虚拟机机动性。

结语

在上述文章中，我们详细阐述为何需要服务器虚拟化、储存控制器的冲击、以及虚拟化IO控制器如何支持新类型的解决方案。最后我们提到当这波转移趋势完成后，DAS储存控制器将扮演类似SAN储存控制器的角色。两者唯一的差别是，DAS采用PCIe来传输，而SAN则采用全部类型的储存协议（光纤信道、GbE、SAS、IB、FCoE等）。但未来情况会更加复杂，更多储存控制器将透过虚拟化技术来提供许多服务，而服务器将嵌入更多的储存装置。

未来数年内，我们的焦点很可能不会全部放在DAS服务器储存以及SAN平台，而是转移到通用运算平台上，因为它可以自由被调整为通用服务器或储存服务器。服务器虚拟化技术，包括IOV技术在内，将成为推动这波汇整趋势的基础。

-- 作者为LSI企业策略总监--