在上一篇文章《SDS 之二：什么是软件定义存储》里，我们提到各家（包括知名的咨询机构和知名的IT厂商）对SDS定义的共性的描述：“虽然每家对SDS的定义都不尽相同，各有侧重点。但可以看出来，易于扩展（主要指在线横向扩展）、自动化、基于策略或者应用的驱动都几乎都成为大家定义中的必备特征。而这也是软件定义数据中心的重要特征，只有具备自动化的能力，才能实现敏捷交付，简单管理，节省部署和运维成本。自动化也成为各家SDS方案，是否愿意走向更高阶段的试金石”。

不过自动化是现阶段绝大多数SDS厂商或方案的较长远发展目标，也许需要3～8年。在此之前，还需先逐步完成抽象、池化的过程。实际上，绝大多数存储厂商还停留在抽象、池化这两个阶段。本篇主要在抽象、池化这两个阶段展开详细的交流。

最早提出抽象、池化和自动化的是VMware公司，这个过程论也是VMware首倡的软件定义数据中心(SDDC)概念中的重要组成部分。
 

 

那么如何理解抽象、池化、自动化呢？

如下图所示，抽象其实就是软硬件解耦的过程。早先的存储，如2000 年以前,大多数集中存储(以外置磁盘阵列为主流)，逻辑卷一旦创建，就不能更改(更改RAID、增加大小)，除非允许数据全部丢失，删除这个逻辑卷再创建 一个新的逻辑卷。那时候的逻辑卷与存储的前端端口、后端端口、物理磁盘，都紧密地绑定在一起，耦合度非常高。在这种情况下，即使是为多个业务应用提供存储 资源的集中存储，也在内部形成了一个个的孤岛，孤岛的存储资源不能相互共享，数据不能自由流动。在这种环境下，存储首要解决的问题就是解耦，将逻辑卷与硬 件解耦，打破孤岛之间的疆界，让存储资源能够共享，数据能在各个存储的硬件组件间自由流动。

例如，假设某用户单位的网管在最初给FC SAN光纤存储划分ZONE时，是按照物理WWWN的方式。这样，每当FC SAN存储控制器的前端卡因故障需要替换时，就还得进入SAN光纤交换机管理界面内，重新调整FCSAN的Zone分区，这个运维操作往往需要业务停机。 如果存储支持虚拟WWWN的方式，就简单多了，只需要进入存储管理界面，SAN光纤交换机不受影响。

再如，以往逻辑卷在创建之初，先必须挑选几块盘来创建RAID Group，在此基础上，在新建逻辑卷。这意味着逻辑卷被绑定在几块盘里，一旦业务增长规模扩大，所需容量和性能不够时，旧存储不得不停机去做数据迁移。如果存储支持精简配置(Thin Provisioning)，在线扩容就比较容易了。

这个软硬件逐渐解耦的过程，其实就是将同类硬件的不同细节的部分，隐藏起来，并与上层隔离开来。这样，上层就不必因为下层硬件的不同而修改。因此，增加了可移植性和灵活性。

不过需要注意的是，软硬件解耦也是一个循环往复的过程。有时，硬件的某些内容解耦了，继而软件完成了这些内容的抽象池化和自动化；过段时间之后，客户的需求 又可能推动再去解耦硬件的其他部分，这样，又需要再去完成其他部分的抽象池化和自动化。因为，不同时代的用户会对所需抽象的内容有不同的关注和需求，而且 硬件本身也在不停地发展。当硬件的发展日新月异，其速度和容量能够远远地超前于当下软件对其资源的要求时，硬件就有更多的机会在不同的层面、不同的角度， 不断地解耦，让更多的部件被抽象，被软件定义，直到最后，剩下该硬件的最核心最本质的部分。

解耦硬件的哪一部分（换句话说，用软件去定义哪一部分），必须结合用户主流的需求，以及当时的客观条件（主要是硬件的能力）。以上一篇文章《什么是软件定义存储》 的比喻-空调为例，当智能家居的周边条件远未具备时，例如手机应用、WIFI尚未普及之时，空调遥控器开放几个简单的如温度、风速、风向的接口，就足够了。如果有公司过早的投入人力物力去做智能空调，研究移动设备或PC机如何通过互联网来远程控制空调的接口，很有可能只有极少的用户（例如财大气粗的比尔盖茨）才有这个需求。这样，这个公司就变成先烈，而不是先进了：）

花絮：

提到“先烈”，想起了IT的两位著名“先烈”

1）1995年，拉里森提出网络计算机(NC, Network Computer)的概念：

配置简单却能充分利用网络资源的低价电脑，不需要不断更新的硬件设备和越来越复杂，庞大的操作系统，没有软盘和硬盘，只要打开电源用浏览器连上网络，就可以获得信息和存储文件；

2）1999年，比尔盖茨宣布微软耗资数十亿美元，向中国消费者推出“维纳斯计划”。这个宏大的计划试图通过嵌入微软操作系统的“神奇盒子”，将中国人使用的3.2亿台电视机变成电脑其实，拉里森和盖茨提出的东西，就是现在的云计算和互联网电视。尽管成为先烈，但不妨碍我们对其如此超前的预见、想法、举措充满敬意。十多年后的云计算和互联网引领者Salesforce,Amazon, Apple TV,乐视, 小米也许正是由于这些”先烈”的启发，因时制宜，接过他们的接力棒，为人类的发展做出贡献。

在抽象的基础之上，才能进一步做资源的池化。因为池化就意味着资源不受硬件的限制，能被自由地分配、使用和调度。池化包括存储虚拟化和存储标准化，而存储虚拟化指所有存储资源的虚拟化，包括

1）外置磁盘阵列内的虚拟化

2）跨外置磁盘阵列的虚拟化（也即异构存储的管理）

3）分布式存储服务器内的存储虚拟化，这部分在以后的篇章里再介绍

存储虚拟化最早可以溯源到IBM AIX LVM（逻辑卷管理器），和HP EVA的vDisk技术。其实HP的EVA技术，准确说是源于Compaq，甚至是DEC的VA，详情可在网上搜索林肯大叔的《存储器那点事》 。

大约在距今10 年左右，新兴厂商Compellent和EqualLogic、3PAR和LeftHand、XIV、Pillar的块级虚拟化，打破了以往RAID Group的限制，支持精简配置(Thin Provisioning)的功能，无需预先分配并实际霸占物理空间，实现写多少分配多少的策略，并支持在线扩容。有趣的是，后来上述新兴厂商分别被 DELL、HP、IBM、Oracle收入囊中。

外置磁盘阵列内的存储虚拟化，大多都不受以往存储RAID Group的限制，能将相同速度（有的存储解耦做得还不够，严格要求磁盘类型也必须相同）盘的空间形成一个存储池，统一分配和管理空间。再辅助以自动分级 技术，便可以实现数据块在SSD盘、磁盘之间的数据流动，例如DELL Compellent的Data Progression（数据调度，也即自动分级）技术。

跨外置磁盘阵列的存储虚拟化，指的是能够跨越异构的磁盘阵列，在更大的范围，如数据中心内，形成一个大的存储资源池，统一管理和分配来自不同存储厂商的存储资源。实际上，当我们讨论异构存储之间的管理的时候，其实也同时在讨论存储标准化，只有当大家开放的接口遵循共同的标准（也即规范）的时候，也就是用相同的“语言”对话时，才有可能被调用、被管理。

随着用户的数据不断增加，为了不被单一厂商锁定，规模较大的用户的存储网络往往包含了来自多个存储厂商的外置磁盘阵列，每个阵列都需要自己的管理软件，这些阵列之间缺乏互联互通，管理复杂度增加。为了解决这一个问题，2002年，SNIA（全球网络存储工业协会）提出了存储管理建议规范SMI- S（Storage Management InitiativeSpecification），希望在存储网络中的存储设备和管理软件之间提供标准化的通信方式，从而使存储管理实现厂商无关性 （vendor-neutral），使得存储管理系统能够实现鉴别、分类、监控和控制物理及逻辑资源的能力,提高管理效率、降低管理成本，促进存储的发 展。

SMI- S是一种中间件性质的规范，定义了存储管理软件和受管对象之间的交互机制。它提供了多种特性以简化SAN的管理。首先，在SMI-S标准中定义了统一的数 据模型，使用基于Web的企业管理(Web-Based Enterprise Management，WBEM)技术和公共信息模型规范(Common Information Model, CIM) ，SMI-S的代理可以与交换机、磁盘阵列等各种支持CIM的设备进行交互，获取其管理相关的数据并返回给请求方。使用SMI-S可以免除设计管理数据传 输机制的麻烦，对各种设备和组件直接进行带内或带外的管理，甚至两者并用。SMI-S还提供了基于HTTP的CMI-XML传输机制，以增强适用性。

SNIA对于SMI-S标准寄予了很高的期望，跨越的版图非常宏伟。从下图（摘自《Storage Management from SMI-S to Management Frameworks》），可以看出来，它希望做到，存储管理软件能够识别磁盘阵列、光纤交换机、IP交换机、磁带库、FC HBA卡、iSCSI HBA卡等各种各样与存储相关的设备，并通过存储管理服务，自动发现、部署和配置存储资源。

 

SMI-S标准发布以后，得到了大多数主要存储供应商的支持，目前已经超过500多个产品支持SMI-S标准。最新的标准是SMI-S v1.6.1，在SNIA官网能够下载到详细的规范，规范包括8篇文章，其中的一篇《Storage Management Technical Specification, Part 4 Block Devices》，长达1144页！其中，仅仅关于Automated Storage Tiering的描述就长达77页。如果新兴存储厂商，有兴趣有耐心通读完，也许对于存储未来研发路线的发展有所启发。
 
SNIA也直言不讳地提到了如下问题：

1、标准走向市场的时间漫长；

2、存储厂商研发新特性的过程中，规范的确立花费1年，厂商实施再需要6个月（笔者持怀疑态度），用户方接受并实施需要2年甚至遥遥无期；

3、需要加速标准走向用户的过程；

花絮：

渐渐发现，SNIA就像一个操心的大家长J，各家厂商就像顽皮的孩子，每个人都有不同的需求，而且这些需求有可能是相互冲突的。SNIA力图协调、折中，让大家尽量满意，期望大家都照章办事。但实际上，由于各家有着不同的经济利益，很难协调。除了SMI-S，再以云数据管理接口（CDMI）为例，那些业已长大成人的云存储服务提供商，如AWSEBS、阿里云OSS，愿意听家长的话吗？ 真为SNIA操心

从市场上看，跨磁盘阵列的存储虚拟化（也即异构存储的管理），比较知名的有：EMC VPLEX、IBMSVC、HDS VSP，以及Symantec Storage Foundation。他们都能或多或少的将其他厂商的存储纳入自己的存储平台之下进行管理。但这种管理，也只是将异构存储的逻辑卷做为一个外来设备使用，把它视为一个普通的容器，不知道它能提供多大的性能。同时也丢失了异构存储内嵌的丰富的软件特性，例如快照、容灾等。IBMSVC为例，这个在2003年（如此超前，非常厉害！）就诞生的存储技术，在存储虚拟化领域，在很长的一段时间内想必都是傲视群雄。

如下图，IBM SVC针对其内部盘，按照RAID方式（如8块盘）创建出Mdisk，再将多个Mdisk形成存储池，在池上创建逻辑卷VDisk(Virtual disk,现更名为Volume)。

在SVC这个存储管理体系下，也能管理异构存储，支持对HP(MSA, EVA, XP), EMC (CX, DMX), NetApp (FAS), Hitachi (AMS, WMS, 99xx) 和DELL(Compellent)等异构存储的虚拟化。以DELL Compellent为例，将Compellent逻辑卷纳入SVC之下，需要经过如下步骤：

1、业务停机；

2、在Compellent图形管理界面中，去掉卷与主机的映射关系(un-mapping)；

3、在Compellent图形管理界面中，创建新的服务器对象：SVCCluster；

4、在SVC图形管理界面中，执行MDisk发现操作；

5、将新发现的MDisk以ImageMode MDisk方式导入；

6、将这个Image Mode MDisk映射到原主机上；

Image Mode Mdisk（来自异构阵列），被SVC允许保留其原生的(Native)的数据复制服务（快照、克隆、镜像）。但是，在SVC最新的红皮书（忍不住赞一下高贵大气的IBM，无需注册，红皮书随便下载）《Implementing the IBM System Storage SAN VolumeController V7.4》里，找不到关于SVC驱动受管对象创建快照、克隆、镜像的描述，笔者猜想目前IBMSVC尚未支持这种存储之间的互操作。如果读者发现支持，并且能找到原始出处，希望能告诉笔者。

无论是内部盘还是外部盘，SVC都可以按照VDisk为单位，实施本地的数据复制服务（快照、克隆、镜像）。利用SVC，可以将放置其下的低端存储，提升起来，也具备高级功能。存储发展到现在，高端存储和中端存储的丰富的软件功能下移到低端存储，SVC的这部分作用就意义不大了。不过，时至如今，SVC的存储虚拟化，对于用户而言，利旧，方便管理（只是少部分程度的），双活，容灾(SVC灾备端可以采用与SVC生产端不一样的存储品牌)，仍有一定的现实意义。

需要注意的是，存储双活的功能，其实相当于把VMFS、MSCS、VCS具有集群高可用的部分从OS层面下沉到了一个专用的物理设备（存储网关）上。如果用户的业务应用能在应用层面，或者OS层面（相对业务应用层面更容易实现），实现其高可用的话，存储双活就不如以前那么重要了。

在存储在线Dostor网站上，董唯元和西瓜哥的《存储虚拟化技术普及贴》对于这种池化，有着简单直白的的阐述，下面摘取其中一段，可以看出在现阶段异构存储的管理有多难：“曾经有用户想用HDS的USP管理EMC的CX系列磁盘阵列，结果EMC工程师跟用户讲磁盘阵列的兼容列表上没有HDS USP，拒绝提供服务。还有一次用户实测用NetApp的V3000管理IBM DS系统磁盘阵列，发现性能低的离谱。结果NetApp和IBM的工程师都说不是自己的问题，让对方改设置来兼容自己”。

距今十多年前，存储经常提及的一个概念是互操作性，正是因为各家厂商的存储管理各自为政，缺乏互联互通，使得用户面临存储管理的巨大挑战，用户一直希望存储厂商解决互操作性：各家的存储管理软件都能管理并灵活调用其他异构存储的资源。这个互操作性，笔者更愿意视为SDS三步曲中，自动化的一部分，是存储与存储之间的资源调用和策略驱动。除此之外，自动化还包含OS/Hypervisor对存储的资源调用和策略驱动，以及应用软件对存储的资源调用和策略驱动。

当下的存储虚拟化（异构存储的管理）并没有解决互操作性的问题，也没有提供数据服务：空间部署，数据保护（快照、克隆），数据高可用（备份、容灾），性能，安全等。

SMI-S标准出来已经13年了，那么，这个互操作谁来做合适呢？存储厂商想做一统天下的存储管理软件，但问题是谁愿意做受管对象呢？

显然，其他异构存储厂商不会愿意。因为经济利益有冲突：我开放API给你，对我有什么好处？我能控制你吗？而且，被你虚化了，我对于用户的重要性就下降了。

实际上，在SMI-S v1.6.1的标准《StorageManagement Technical Specification, Part 4 Block Devices》中，已经包含了对镜像、快照、克隆的描述，但是笔者相信截止目前为止，还没有哪个存储厂商的存储虚拟化平台可以驱动受管对象的高级软件功能，如数据复制服务：快照、克隆、镜像、容灾等。

下面两图摘自SMI-S v1.6.1的标准。

 

也许EMC ViPR开源也有这个原因，开源之后，其他存储厂商对ViPR开放更多的API，才有更多的可能性。

其实，最合适做互操作的不是存储厂商，而是操作系统(OS)厂商、Hypervisor厂商，绝大多数存储资源都必须纳入到OS/Hypervisor的版图之内。在云计算、软件定义数据中心的背景下，存储资源被虚机使用的规模将远大于被物理机使用。因此，存储厂商可以考虑与VMware、Hyper-V、Citrix XenServer、RedHat
KVM、华为FusionSphere等Hypervisor厂商的互操作性。我们也看到Hypervisor厂商也在努力实现与存储的互联互通，例如Microsoft System Center 2012就把SMI-S做为组成部分。再如VMware vR Ops云管理软件利用SMI-S等协议进行存储分析。

对于虚拟化服务器市场份额的领先者VMware来说，从创立至今，它极力营造的生态环境，使得vSphere成为事实上的标准，先后推出的VAAI、VASA，以及最新的Virutal Volumes（简称vVol），都有主流存储厂商，甚至新兴的全闪存、混合阵列厂商的鼎力支持。这在存储与Hypervisor的互联互通中，占据了主流。下图右边列出的15家存储厂商，就是目前支持VMware Virtual Volumes的VMware合作伙伴。