目前各家（包括知名的咨询机构和知名的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机如何通过互联网来远程控制空调的接口，很有可能只有极少的用户才有这个需求。

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

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盘、磁盘之间的数据流动。

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

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

SMI- S是一种中间件性质的规范，定义了存储管理软件和受管对象之间的交互机制。它提供了多种特性以简化SAN的管理。首先，在SMI-S标准中定义了统一的数据模型，使用基于Web的企业管理(Web-Based Enterprise Management，WBEM)技术和公共信息模型规范(CommonInformation 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页！其中，仅仅关于AutomatedStorage Tiering的描述就长达77页。

SNIA也直言不讳地提到了如下问题：

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

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

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

从市场上看，跨磁盘阵列的存储虚拟化（也即异构存储的管理），比较知名的有：EMC VPLEX、IBM SVC、HDS VSP，以及Symantec Storage Foundation。他们都能或多或少的将其他厂商的存储纳入自己的存储平台之下进行管理。但这种管理，也只是将异构存储的逻辑卷做为一个外来设备使用，把它视为一个普通的容器，不知道它能提供多大的性能。同时也丢失了异构存储内嵌的丰富的软件特性，例如快照、容灾等。

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

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

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

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

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