解析服务器虚拟化引起的数据存储问题

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

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

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

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

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

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

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

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

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

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