2016年10月28日一年一度的vForum 2016在北京完美落下帷幕，而成为虚拟化和云计算领域每年最受关注的行业大会之一，今年到现场参会再次超过6000人，可见其依然保持着在业界的影响力。

本文摘自围绕vForum 2016第二天(10月28日)，分会场五-软件定义存储与超融合架构上的主题分享《软件定义存储控制平面与存储自动化》进行展开，分享给各位：

一、VMware存储自动化助力云计算：VMware云管理平台和OpenStack Cinder

云计算平台需要什么样的存储？

需要存储自动化，为快速部署的大量云主机分配能满足一定服务水平（SLA）或QoS的存储资源。

我们已经步入了移动互联网的时代，这个时代的特征瞬息之间千变万化，基础架构平台包括存储需要满足新业务应用的快速上线和变更。

我们先看左图，大家都有过管理传统存储的经验，当我们需要为虚拟化环境下的vmdk分配传统存储的空间时，需要管理员在专门的存储管理界面里选择几块盘创建Raid组或者Storage Pool，然后在此基础上建LUN(逻辑卷)，做LUN到服务器的Mapping(映射)，等等……。我们设想一下，如果在短时间里，需要为几十个虚机，创建上百个vmdk的存储空间呢？ 此时，管理员不得不陷入简单但有枯燥重复的操作之中。需要存储空间的用户不得不等候，尤其是当各个业务部门对于性能、数据保护等SLA要求不同的时候，说清需求理解需求也要消耗较长的时间和精力。业务上线以后，如果业务规模以不可预料的方式迅猛增长，vmdk在传统存储的对于的存储资源需要变更，又需要消耗很长时间。

再看右图，很多朋友都见过云计算门户的自助服务图形界面，当我们分配云主机的时候，可以自由选择CPU核数，内存大小和存储大小（比如输入8GB）。但是，你有没有想过，其实不同业务负载的云主机对于存储的要求是不同的，业务负载有很多种，例如桌面、OLTP数据库交易、备份归档等等，他们对于这8GB存储空间的性能、可用性、QoS、安全性、数据保护(Snapshot,Replication)等SLA的要求都不一样。不同业务负载需要的其实是：有差别的存储空间。这个差别其实就是要由软件定义存储的控制平面-存储策略驱动来实现。可以看到，右下角这个位置，第一步点击下拉列表后，可以选择Storage Policy，第二步可以在下拉列表里看到之前曾经根据业务负载的要求创建好的存储策略。

下面我们就来看一下VMware的存储自动化是如何助力云计算实现这点的？

主要分成两部分来介绍，分别是VMware SPBM如何对接VMware云管理平台

和OpenStack Cinder的。

VMware基于策略的存储自动化

存储自动化是云计算的内在需求。VMware作为业界领先的软件定义数据中心（SDDC）提供者，可以充分利用其强大的云管理平台，将应用程序和基础构架通过策略驱动有机的融合在一起。

vRealize Automation (vRA) 是整个SDDC的控制平面【Peter备注，注意是云计算级别的控制平面】。在其框架下， 基于策略的存储自动化涵盖了以下一些方面。首先，基础架构管理员会在vSphere中定义需要的存储策略；接着定义好的存储策略会通过策略框架暴露在vRA的视野中；在蓝图的基础上，授权的最终用户可以按照业务的需求，以自服务的方式，为即将部署的应用程序云主机选择合适的存储策略；一旦请求发出，vRA将在后台根据指定的存储策略，在考虑可用性和可用空间的前提下，自动地将云主机的不同工作负载放置在合规的存储资源上。我们可以看到在整个过程中，不同的用户角色和产品功能各司其职，但又有机合作，最终在一起支撑起了软件定义数据中心（SDDC）上的基于策略的存储自动化。

vRA SPBM集成解决方案允许授权用户为不同的虚拟机存储对象选择不同的存储策略。在方案演示的视频中，我们可以看到用户为虚拟机的VM主目录和VM 磁盘选择了不同的存储策略。根据策略的不同，VM 主目录最终被放置在vSAN这样的软件定义存储上，同时VM主目录还应用了高可用的存储策略，在物理存储上建立了多个存储副本。再看VM磁盘，由于存储策略的指定，最终它们被选择并放置在传统的iSCSI存储上。从最终用户的角度来看，他们只需要明确云主机的存储需求即可，再也需要费心地去选择和配置复杂的底层物理存储。

 vRA SPBM集成解决方案

vRA SPBM 集成解决方案充分利用了vRA 7.0版上最新的Event Broker Service (EBS)和XaaS扩展功能，通过一系列的vRealize Orchestrator（vRO）工作流覆盖了存储策略在应用程序生命周期中的设置和修改需求。在vRA中，当授权用户请求部署一个应用程序的时候，EBS系统会发出相应的虚拟机创建事件，这些创建事件会被解决方案消费，并驱动设置存储策略的vRO工作流，继而通过SPBM将存储策略应用在vSphere的虚拟机上。在Day 1的操作之后，如果应用程序需要修改已有的存储策略，授权用户可以直接请求解决方案注册的修改存储策略操作（Day 2）。修改的请求会驱动修改存储策略的vRO工作流，继而作用于虚拟机上。

vRA SPBM 集成解决方案工作流的核心业务流程包括了从预检查，修改存储策略，到后期校验的多个步骤。其中修改存储策略并不是，简单的应用策略的过程。工作流会根据当前备选存储资源的各种状态，如合规状态，可用空间状态等，选择合适的存储资源。一旦选中的数据存储和当前的数据存储不相同时，工作流还会负责将存储对象迁移到选中的数据存储上，并同时应用指定的存储策略。

 整个vRA SPBM集成解决方案的配置流程非常的简单。在完成了vRO工作流包的导入和vCenter服务器的注册后，vRA系统管理员只需要配置相应的自定义属性和属性定义，并订阅虚拟机创建事件，就可以完成Day 1相关的配置。对于Day 2的配置，则更加简单，只需要虚拟机添加修改存储策略的操作即可。

 基于存储策略的跨云迁移

vRA SPBM集成解决方案还在不断的增强中。在未来的版本中，将会加入基于策略的跨云迁移功能。在vRA中，工作负载将可以基于存储策略在不同的云中自由地迁移，从而使用户可以合理地利用并管理混合云上的不同资源。

二、VMware存储自动化的落地：vSAN和Virtual Volumes

VMware SPBM向下可对接三种存储

上面这张图其实是VMware软件定义存储非常经典而且全面的的结构图。上面的绿色部分是VMware软件定义存储的控制平面，也即Storage Policy Based Management(SPBM,基于存储策略的管理)，负责存储策略的驱动。

下面三个方框，左边就是用普通机架服务器和其内置盘或者外接JBOD进行池化，形成的分布式存储，它对内，也即对本vSphere集群的虚机以VSCISI协议提供块存储空间。如果希望VSAN对外也能提供存储空间，可以使用经过验证的NAS插件，或者刚刚发布的VSAN 6.5的iSCSI特性。需要提醒的是，两者都能支持SPBM，这就是意味着基于VSAN的NAS或者iSCSI空间，也能为不同的业务负载提供有差别（其实就是不同SLA水平）的存储空间。在这点是VSAN是唯一能做到的，其他分布式存储还尚未与SPBM对接。

中间这个方框是外置存储，只要外置存储遵循VMware Virtual Volumes标准，SPBM也能驱动底层存储资源的分配或变更。

右边这个方框是云存储。我们习惯性的认为vmdk是放在本地数据中心的物理设备里，不过请你设想一下，可否虚机运行在本地，而它的vmdk运行在其他私有云或公有云上。未来完全可能！ 比如对于一些延时要求较低的业务，例如备份归档，当网络等各方面条件具备时，vmdk存放在AWS、Azure或者阿里云上，也不是没有可能的。这也能看出VMware在软件定义存储野心，不，应该叫做远景。VMware在SDS上，其实是一个非常完善的结构，有着长远和宏伟的目标。这张图不是现在才有的，其实早在2012年VMware提出软件定义数据中心、软件定义存储时，就有着清晰的考虑。

VMware SPBM之vSAN 

我们以vSAN为例，可以看到下面列出了8个存储策略的选项，它们的组合便构成了一个规则集(Rule-Set 1)，这个规则集其实就能对应某种业务负载对于存储服务水准(SLA)的要求。

以8个存储策略选项中的IOPS Limit为例，为了避免有些非关键业务（如备份）抢占整个vsanDatastore(也即vSAN存储池)的IOPS，可以通过设置某几个vmdk的IOPS上限，来消除Noisy Neighbor(相邻干扰)。不过从我的实际经验来看，围绕着SSD设计体系架构的VSAN存储，在实际部署中，还鲜有遇到所有业务IOPS总和超过VSAN承受能力的情况。

另外，在我们未来的路线图中，还会考虑设置IOPS下限，这样就更精确了。其实通过之前介绍过的Virtual Volumes大全，细心的读者可能已经发现，设置IOPS的上限和下限，早已经含在VMware SPBM丰富的框架之中了。我们所要等待的就是，VSAN不断开发新的存储高级功能（或叫数据服务），SPBM就不断将其吸纳进来，成为日益丰富、强大、无敌的存储自动化方案。

VASA的出现，是虚拟化平台上存储技术的一次飞跃。以往，业务虚机（以及其用到的VMDK）与后端存储相互脱节，存储不知道上面跑的什么虚机，状况如何？虚机不知道运行在什么样的存储空间上。有了VASA后，它让两者相互感知，满足用户对每个虚拟机进行存储配置的需求，在存储级实现以虚拟机为粒度的灵活高效的管理。VASA的出现，为SPBM自动化奠定了基础。

VVOL至少增加了如下新特性：

1）Array-Based Replication Support(支持基于阵列的远程复制)

与以前的远程复制不同的是，VVol无需在灾备端事先部署好datastore；而且VVol能够提供细粒度的控制。Replication Group(可以视为故障切换的单位)允许将多个虚机放置在一致性组内。VVol还支持多个不同的灾备端。

2）Automating Disaster Recovery(灾难恢复自动化)

为管理员实现编排和自动化提供触发DR动作的方法；

3）VVol支持Oracle RAC

以HP 3PAR为例，首先需要需要创建一个Replication Component并命名，设置例如RPO等远程复制的 信息。

HPE 3PAR Replication对VVOL的支持

然后在添加规则集Rule-set 1时，就会发现前面新建的Replication Components，如下图的Replication to San Jose Datacenter。即可设置vmdk对应的HPE 3PAR的虚拟卷vvol的远程复制策略了。

从软件定义（云化、存储自动化或存储即服务）的角度来剖析，毫无疑问，VMware SPBM是业界最先进而且最成熟的控制平面产品，5000多个vSAN的用户，没有一个不是用SPBM实现的存储策略驱动的。而且SPBM的丰富性，从vSAN、VVOL所支持的存储选项即可看出。

vSAN虽然面市只有两年半多的时间，但从其迅猛发展的速度（例如中国2016第三季度达到去年同期的5倍以上！），以及研发的速度（vSAN 6.5已经是第5版，也曾预测，不出两年，vSAN的存储高级功能将全面超越发展了二三十年之久的外置磁盘阵列），这表明VMware在数据平面层，也逐渐开始跻身前列。

更重要的是，同时拥有控制平面和数据平面产品的公司，在全球范围内都寥寥无几。而VMware是唯一一家两者之间真正紧密集成，且落地广泛的方案。

毫不客气的说，VMware在软件定义存储领域当之无愧地位居领导者定位。

在此隆重推荐了两本书：第一本SDS书可以做为宏观了解SDS原理、生态，第二本可以深入了解vSAN的解决方案细节。