许多IT部门在没有完全认清服务器和桌面虚拟化对存储资源的影响前就迈入了这一领域。其结果就是，其中许多被厂商引导着进行叉车式升级，又或者是，恢复到直连存储（DAS）的模式。业内专家Jon Toigo在其在纽约存储决策者论坛中发表的题为“谁扼杀了服务器和桌面虚拟化”的演讲中谈及到这些问题。他在其中描述了每个IT部门在应对服务器虚拟化所引起的数据存储问题所必需处理的两项问题。

    浏览该视频或阅读以下脚本：

    Toigo：服务器虚拟化并没有改变底层的体系架构。实际上，在最糟糕的场景中，其从视角上掩盖了这些体系架构。这使得你更难以管理实际运行I/O的物理设备。你很难看清楚你的体系架构。当然现在部分解决方案可能已经更具可视化。不过我真的讨厌虚拟化么？当然不。不过我讨厌笨拙的虚拟化结果。我想一定可以有更智能的虚拟化。让我们先从存储开始。这是一个很重要的关键点，因为它很贵。不过原因何在？存储现在占到了花在IT硬件上的每个美金的33至70美分。这是个很客观的数字。

    虚拟化项目暂停的最通常原因就是“我们不知道这堆存储体系架构会产品有什么影响，或者这样改变我们的环境需要多大的花销。”Gartner目前预测服务器虚拟化将让你的存储采购量提升600% 。仔细想一下。你必需要购买你目前已经部署的6倍，并且这将发生在之后的三年内，而原因只是为了适应你所要步入的美好的全新的虚拟化模式。

    这在你的未来规划上是否算得上是叉车式升级？你所遭遇的这些并不算特殊，因为即便是卖给你SAN的供应商现在也开始让你准备从SAN返回DAS架构。DAS是已确定的唯一能够解决虚拟化问题的方案。

    服务器虚拟化使得存储原本所具有的那些问题变得更加显著，代价更大，并且风险也更大，因为一个应用的故障会影响所有的应用。可以说从存储诞生之初我们就面临着三项挑战。其一是容量管理，其次是性能管理，而第三是对于数据保护的管理。我称之为元管理任务，这在存储资源管理层（SRM）之上，在SRM中，我们只是尽可能保持直线式管理并确保磁盘的正常旋转，我们只需要保护存放数据的设备，并且我们只需要合理地分配容量和其它资源。

    服务器虚拟化引入了新的之前从未有过的容量扩展性需求。为什么？因为我们将一大堆工作负载整合到某一台服务器上，并且指向特定的一系列磁盘组。其次，我们需要适应变化着的访问量。假如你进行vMotion并将工作负载迁移到别处，你会同时迁移存储么？你会同时迁移数据么？你是否需要将数据复制到每个角落？你的存储会因为数据复制而浪费多少？你必需运行多少复制进程，并且你如何以一致性的方式管理所有这些？在大多数镜像设计中，你甚至无法对其进行测试，除非你将其中断。你必需停止镜像后在两端进行一次以执行检查来进行测试。这多少有点自找麻烦的意思，又有谁会中断其镜像呢。而假设在七年后的某天你在需要时才发现你无法将其启动，这实在是太糟了。于是乎可靠的数据复制都必须以一种可管理的方式进行。为从存储的角度来解决这些虚拟化问题，我们只是要解决所有这些本地的问题，这些问题再存储上一直存在。并不是大问题！我们正在致力于此。

    有人会寻求一种更简易地方式。他们会说“我们将不会再继续使用SAN环境，我们现在准备只采用DAS了。”这实在意思。但问题是，你所有已有的复制策略怎么办？绝大多数出席此次存储决策者论坛的硬件供应商的复制策略都只适用于同一品牌的产品。这意味着在这种场景下进行硬件层的复制，你将被锁定在某一供应商的产品线之中。这是个问题么？或许不是，这取决于你的预算是多少。迄今为止尚没有实际应用的软件复制产品。VMware将为我们解决这一问题，让我们拭目以待。

    我真正想看到的是我们能够走出这一误区，撇开那些配置封闭而具有增值功能的控制器的异构设备，从非常复杂的垂直体系架构直接找到实际运行着的虚拟服务器群，其中的每一台都要求特殊的设备驱动器。此外：没有什么统一管理，每台设备都有其专属管理机制。因此假如你有一个异构系统，你不得不分别管理每一台设备。

    这些就是我们今天所面对的情况，所有我们需要做的就是将这些虚拟服务器呈现出来。我们现在从根本上改变了工作流程，我们可以随意地将工作负载从一台设备迁移到另一台。这改变了我们管理体系架构的方式。所有这些设备都有硬件编码——从全局地址到全局命名规则，还有你iSCSI设备上的IP地址，等等。你已经可以跟踪这些，但这些是静态的，不会根据应用所需进行任何改变。

    服务器虚拟化提供了一种解决方案。我们从单独的阵列控制器上抽象出高级功能——容量管理，性能管理，数据保护管理——然后我们将其纳入虚拟池之中。这样我们就可以创建存储池，让它根据虚拟机的需要进行迁移。这并不是从物理上进行转变。底层的设备和连线仍旧是这些。不过至少其创建的虚拟卷可以随着虚拟机进行迁移。这着实是项很棒的解决方案。其工作正常，给我们带来巨大的收益。但它仍没有解决管理底层体系架构方面的问题。通过X-IO的Web服务和RESTful管理，我可以管理PB级别的存储。这意味着什么？这意味着其设备可以和网站一样进行沟通。事实上他们已经可以相互间沟通了。当你将其中的一台设备纳入到体系架构中，他会说“嗨。你是Hyper ISE？我也是。想要交个朋友么？想要共享容量么？嘿，我这里正好有一部分带宽你能用上”然后他们就可以是朋友了！这种想法简单说来就是你基于存储模块的方式创造了一个模块化体系架构，只要你增加存储，你就可以扩展，在底层增加容量，存储会自动地匹配，其可访问性也会变得更好，因为其通过REST进行管理。我可以通过iPAD、手机、智能电话或者是桌面系统——任何支持浏览器的设备——来观察存储的分配情况。实际上，就在我刚从Coretex Developer看到一个新的Apple应用。我可以用手指将一部分资源拖拽到一个虚拟机中。这样就可以了？大家看看，太棒了。

    现在，有几件最基本的事情你要解决。你对容量管理进行了虚拟化，你重构了基于Web服务的管理组件，因此你无须直接处理每一台单独的设备；你会以整体的方式进行管理。并且，我并不在意你是否进行服务器虚拟化。即便不这样做，你也会想要降低体系架构的成本并提升存储的效率，只要你想实现这两个目标，那么这种方式肯定是最简单，而且最新潮的。