注：EMC对存储虚拟化的远景已经在最新产品ViPR中有消息描述，参考专家问答专家问答（翻译稿）：使用ViPR管理软件定义的数据中心

介绍

小虾最近的文章都有点“虚”，基本是无关具体实现和原理的，有点像是售前给客户做需求汇总。不过话说回来，最近业内啥东西都得和一个“虚（Virtual）”字扯上点关系，所以小虾也算是个赶潮流的人。但个人认为，只有在理解了最初需求的大背景之下，再深入具体技术，最后具体到某一产品，你才能真正理解一个产品在整个IT架构中所处的位置，它所存在的意义，为什么要这样设计，以及与竞争对手的差异等等。这也就是为什么人们要研究历史的原因所在吧。所以，小虾今天就继续冒死“虚”一把。

更多信息

为了真正的实现IT-as-a-Service，“云计算”的概念出现了，而要实现云计算基础架构，虚拟化又是必须的。目前我们已经能够做到“Virtualize Everything”，把所有的物理资源都进行重新封装，以资源池的方式进行分配和管理，而本文将专注于其中的存储虚拟化。就EMC来讲，Virtual Provisioning（VP）和Storage Tiering（FAST）都是存储虚拟化的产物。VP将所有物理硬盘进行了“池”化，把封装之后的存储对象（Pool LUN）给主机使用，做到了按需分配（ThinLUN）、更好的伸缩性（添加\移除物理硬盘更容易）、相比传统RAID组更灵活等诸多优点；FAST基于VP实现了存储分层，将冷/热数据智能地分布在不同性能的存储资源之上。以上两种概念听起来都挺不错的，但作用范围，仅限于存储内部。EMC对于存储虚拟化有着更大的愿景：

对于最终用户来说，数据是无处不在的（Access Anywhere），你可以在任何时间，任何地点访问你所需要的数据。不用担心数据安全，性能等诸多问题，这所有的一切对你来说都是透明的。你所要做的，就是尽情的访问。
对于技术人员来说，那就意味着更多更复杂的问题等着你去解决，比如下面这些：

Unified Management - 不论底层是哪个厂商的存储，都能将它们的存储资源进行打包，统一管理和分配
Non-disruptive - 数据在存储设备之间的移动不能存在业务中断（不存在主机重新识别LUN的过程）
High Availability - 任何位置的失败都不会影响数据访问
High Performance – 不论你在哪，对同一份数据的访问都不会感到性能上的差异
Collaboration – 对一份数据的修改必须立刻在另一个位置表现出来，从而确保地域间的业务合作不会因为数据不一致而变得不可行（数据一致性）

想要实现这些需求，仅仅在存储内部做虚拟化是不够的，你必须把所有存储资源（EMC & non-EMC）统一封装起来，对新的存储对象添加控制管理机制以及新功能才行，这一层封装显然要位于存储之外了，因为目标对象不再仅是某个存储设备内部的磁盘，而是所有存储设备的磁盘（当然还可能是磁带等其他媒介）。我们把这一虚拟层称为Virtualization Controller，它可以是Block-level，也可以是File-Level，我们主要讲Block-Level。Block-level Storage Virtualization的做法一般是这样的：在物理存储设备和主机之间建立一个抽象层（Abstraction Layer），它会把其下的所有存储资源（比如LUN）重新打包成其自身所能识别的一种存储对象（比如叫Virtual Storage），然后再将Virtual Storage呈现给主机进行访问。有人会反驳说主机端的LVM（Logical Volume Manger）也可以视为一个中间层，为什么还要多此一举。没错，但LVM是基于主机的，对于存储虚拟化有着太多的局限性（性能、数据移动性、容灾、可用性、灵活性、伸缩性等等等等…要说的话估计又是一篇文章了），要真正地做到存储虚拟化，就必须将抽象层建立于底层存储和主机之外，把对资源的控制权完全交给Virtualization Controller，主机要做的事就是“计算”，而关于存储的一切，您就别插手了。

“虚”完了咱来点“实”的，简单的描述了存储虚拟化的必要性以及它在EMC眼中的位置，是时候来认识下具体实现了。EMC的Virtualization Controller实现就是VPLEX，它是一套软/硬结合的解决方案，来看看VPLEX究竟长啥样。

VPLEX硬件

下左图的机柜就是一个完整的VPLEX硬件图示，整个机柜内的所有设备组成了一个VPLEX解决方案。最关键的部分是Engine，每个Engine由两个Director组成，Director相当于存储架构中的控制器（Storage Processor），拥有CPU/RAM/前后端口/缓存，运行GeoSynchrony操作系统，负责将针对Virtual Storage的逻辑I/O转换成到后端存储的物理I/O和管理VPLEX对象。VPLEX将Director以集群的方式运行，实现高可用和负载均衡。图中一共有4个Engine，即8个Director，她们共同组成了一个集群，接收来自主机的I/O。每个Cluster会配备一台Management Server，她是用于管理VPLEX的一个接口，其上运行着VPLEX web server进程，我们可以通过VPLEX GUI/CLI/REST-based服务接口对整个系统进行管理。如果你购买的配置有多个Engine，那么还会有一对FC交换机用于Director之间的通信。Switch UPS和SPS用于断电保护和Cache Vaulting，我就不多介绍了。下右图是一个逻辑结构，清楚地标明了VPLEX所处的位置。

可以看到，Engine是VPLEX硬件架构中最重要的一个部件，让我们来个近景。下图为一个VPLEX VS2 Engine（老版本是VS1），由两个Director组成（左B右A），是不是和VNX/CLARiiON CX4的SP很像，其实道理都是一样的，长得像也不足为奇。最左边的是管理模块，用于Management Server的IP通信。另外，每个SP可以安装5个I/O模块，从左到右分别用于主机连接、后端存储连接、集群内部Director间通信、集群间通信、保留为将来使用。

VPLEX VS2 Engine

整个机柜为一个集群，最多允许4个Scale-out Engine（Scale-out果然是将来的架构趋势，EMC Isilon也是如此，请看EMCIsilon– “Scale Out”时代 https://community.emc.com/docs/DOC-17726），VPLEX当然也支持多集群，那就你会看到如下的配置，我们称之为VPLEX Metro解决方案，它使得你的应用程序和数据能够在两个站点间任意移动，且保证数据的一致性和可用性（Witness用于提高可用性，本文不做介绍）：

对存储结构有经验的读者很快便能理解这些组件之间的关系和大概的工作流，硬件就不多做介绍了，来看一下具体的存储对象。为了更清楚地解释，我们以VNX-block为例作为后端存储。下图是VPLEX的存储对象图示，当你将VPLEX Director的后端端口与VNX的前端端口连接，并通过VNX Storage Group将LUN映射给VPLEX Director之后，VPLEX看到的就是Storage Volume对象。随后，你可以将Storage Volume分割成Extent，再将Extent组合成Device，最后通过VPLEX的Mapping机制Storage View将Virtual Volume呈现给主机，最终主机扫描总线之后就能看到磁盘了。

了解了技术产生的背景以及简单的硬件和存储对象介绍，我相信你已经理解了VPLEX在整个IT架构中的位置以及宏观上的工作方式了。但这还不足以让客户掏钱，因为VPLEX的使用场景才是真正使人兴奋的地方，必须围观一下她是如何满足我们之前所提到的那么多需求的。然后你才能体会到，没有Virtualization Controller这一抽象层，很多客户需求是满足不了的。

VPLEX所提供的VPLEX Local、VPLEX Metro、VPLEX Geo以及将来的VPLEX Global这四种解决方案，正如下图所示，你的应用程序和数据能够在任何一个数据中心内穿梭，真正的做到Data Access Anywhere，这也是EMC对于存储虚拟化的最大愿景。

本文简单地介绍了VPLEX，目的是让读者知道Virtualization Controller的存在意义以及什么是VPLEX。以后会继续讲述一些关于VPLEX的应用场景，以及实现中关键性技术，比如Global Distributed Cache, VPLEX Witness, VPLEX Mobility等，尽请关注。