note：写这个也许算是翻译，又或算是对这个论文[1]的理解，又或者只是我的看法。
这篇论文和IOFlow相比较，更加注重软件定义存储的框架（利用已有的框架来创建新的框架，然后使用已有的协议），而不是像IOFlow那样注重通信的协议。并且，这个框架还是软件定义环境的框架，而不仅仅是存储的框架，不过全文注重说了存储（更有挑战性）。特别地，关于可软件定义的存储逻辑，从这里可以管中窥豹。
SDE软件定义环境
数据中心的环境包括Compute、Network和Storage资源。
数据中心对（flex）灵活性和rapid的需求越来越大，而数据中心应用程序性能和计算、网络和存储这些资源息息相关。一个整体的对数据中心的smart的组织和安排方案（global view）肯定能打破计算，网络和存储的限制，明显的增加QoS和用户体验。
Objective of SDS
SDS的目标和软件定义网络的目标是一样的，SDN的目标可以分为两个维度，从横向上来说，是全局的优化能力；从纵向上来说，是控制平面和数据平面的软件集成。
从高层应用程序的角度来看(和低层的LUN和RAID比较)，应用程序的部署要求storage provision和一定的性能(从整个系统的角度看)，系统将所需的逻辑卷分配给应用程序。然而，应用程序的生命周期是动态变化的，需要的资源不停地在动态变化着(存储需求，性能需求，数据保护要求，拷贝政策，恢复点目标和恢复点时间的改变)等，所以上面提到的这些变化如果可以显示的去配置，那么对于应用程序来说，就太有效了。
总之，SDS的总目标就是使得需求和下层的infrastucture解耦。
已有的存储方案
企业级的解决方案
存储企业界提出了一个叫做SMI-S（存储管理首创说明）的草案来作为管理不同存储设备的统一接口。但是这个和SDS是有区别的，也不能达到在前面提出的SDS的目标。为了减小它和SDS的区别，达到更好的用户级需求和体验，IBM的存储管理方案VSC做了很多事情，其他的企业级存储还包括RMC，NetAPP等等。
开源社区的解决方案
Openstack是一个来源的云管理系统，这个开源项目现在由许许多多的vendor在参与，已经取得了很大的成就。Openstack中提供了SDS的平台，他的存储部分主要是包括了swift(给应用程序和虚拟机提供了对象存储)和Cinder(给虚拟机提供了块存储)。
Swift
Swift管理和提供对象存储，提供相应的API给client。swift的一个很重要的能力就是在可用的磁盘和nodes中间自动的复制数据，自动的来提供可扩展性，有效性和数据保护的能力(这些都是隐藏的功能，swift有一套嘛)。然后swift的目标是更小的存储开销，因为集群中的机器都是有大容量存储的商品机。现在的新的应用程序中很流行使用对象存储，尤其是web程序(因为swift的 REST API 在http上面很盛行)。比起文件存储和块存储来说，对象存储更加有扩展性，也更加灵活。
cinder
它是一个块管理组件，提供了块存储管理的功能，比如给服务器创建，增加块设备，或者删除某个服务器的块设备。(这些服务器不再使用简单的linux服务器的存储，而是使用统一的存储支持，(向上甚至支持ceph和netapp))。现在cinder可以管理很多的存储系统，比如GBFS(IBM的分布式并行文件系统，属于底层的一个文件系统)和lvm(卷管理器)。cinder包括一个scheduler(plugged，所以可以采用第三方的)来为服务器选择最佳的块设备(根据需求，可能包括volume type(也是存储资源的一种抽象吧))。更多学习cinder，点击这里。
openstack的这些存储机制是在一定程度上支持软件定义的概念的，但是对那些具体的支持还不够，如果说是SDS应该还算不上。
框架架构
这篇文章提出了一个叫做IBM Open Platform的平台（如下图所示），主要包括了对工作负载的抽象，对资源的抽象，以及负载到资源的映射，以及相关的优化。要让这个框架发挥作用，对workload和对资源的抽象都很重要。对workload的抽象就是把各种各样不同的workload通过一种抽象方式（比如说JSON或者XML）表述，然后抓取出其中的与应用相关的需求，比如说基础架构和操作流。
而资源的抽象就是提供一个统一的接口来提供、管理和监控下层的计算、存储和网络资源。所以复杂的设备对于用户来说就是透明的了，而那个核心的SDE统一控制平面就翻译workload的抽象表示，也翻译来自下层资源的抽象表示，然后组织sdc、sdn和sds的组件（为了灵活而有效的管理）。
工作负载的抽象
比如说，一个简单的三层的web程序一般包括一个web服务器，包括一个数据库，还要一个应用服务器。这种软件模式可以被一个描述性的语言格式来描述，比如JSON。然后中间的unifiedcontrol plane的engine解析这种语言，之后为这个workload组织安排底层的资源。
从存储的角度来说，这个框架可以创造灵活的存储语义。比如说，应用程序可以指定存储卷的大小，存储服务类型和相关的其他的政策等。因此，这个框架使得程序开发者和系统管理者显式的指定他们对底层存储的需求。这种用户级的存储需求也可以在用户程序的生命周期中发生改变，带来了更大的灵活性。
资源的抽象
那么资源的抽象是怎么做的呢？
IBM的开放平台支持的底层平台不仅仅是企业级的存储子系统，也包括商业存储设备，比如GBFS。资源抽象就是将存储资源(不管是SAN，还是NAS或者是DAS)抽象为一个资源池，然后再根据workload的需求去管理和分配。
比如说这个框架可以在GBFS中利用底层的存储设备创建一个文件，然后把这个文件作为一个块设备分配给虚拟机去使用，也可以使用GBFS的快照和文件迁移的功能去管理虚拟块设备。关于底层的特殊的设备，有的设备可能是企业级的，会提供一些高级的功能，比如固件级的压缩和去重能力。这个时候，就可以使用这些功能。但是如果底层的存储设备没有这些功能，就需要调用软件的方法来达到这个目的。
总之这个框架提供了一个存储资源的抽象，能够达到很好的存储资源利用率，并且提高操作性能，减少了存储系统的复杂度。
资源的映射
从上面的描述我们看到，这个框架中 unified control plane的功能就是利用上面的请求，组织安排下面的资源。对于存储请求，那就是解析存储请求的要求并传给sds模块来达到资源映射的目的。从下面的例子可以很好的了解有关存储资源的映射过程。
performance-aware存储配置
形象一点来说，对于每个存储资源创建请求，都需要一个“服务类型”的标签，代表着特殊的对（storage provisioning）的需求，比如说RAID的级别或者是错误恢复特性（resiliency profile）。每个服务类型代表一组存储的配置。比如说对于“白金”级别的服务类型，那可能就是要求低延迟，这样的workload创建的存储卷更有可能放在ssd中，而不是普通的磁盘。另外，如果可用的ssd有很多，组成一个资源池，这个框架还会分析ssd资源池中设备的利用率情况，然后将新创建的存储卷放在其中一个SSD（会产生最小的性能影响的）。
存储fabric管理
当存储单元创建好了之后，也就是创建好了workload服务器和存储卷之间的联系。然后对于下面的存储网络技术，比如fc，iscsi，infiniband和fcoe都提供了统一的接口。然后这个框架提供一个最好的zone管理和fabric 分析来确定服务器和存储卷之间的最好的storage fabric。（比如说，通过分析存储设备的利用率，然后在多个端口之间进行负载平衡）（也可以使用爬山算法来找到最好的路径）
存储恢复
还原能力是数据保护的一个重要的特性。在这平台上，有两种形式的resiliency。一种是fabric resiliency，应用程序可以选择一条IO路径，保证路径上的每一个节点都是好的（不会failue，就像fcoe存储节点上面的需求那样）；对于存储设备级的数据保护措施，这个框架可以让应用程序选择一种复制策略，比如point-in-time快照，同步的镜像或者异步的镜像。存储恢复还可以利用sde的整体功能，包括计算，来实现更加整体的数据还原功能。
连续模式优化ILM
这里有一个很重要的概念，叫做存储信息生命周期管理（ILM）。这是因为数据的价值在它的生命周期中是动态变化的，比如邮件数据在刚开始的时候价值是最高的，后来随着时间这个邮件越来越没有价值了。所以ILM的目标就是在正确的时间把正确的数据放在正确的storage tier上面。这也就是Storage tiering技术（根据历史io行为，来决定io tier）。而我们的这个框架使得可以应用程序根据独特的需求来控制存储的tier。比如说给一个服务类型指定是（higher tier和lower tier的类型，然后自动的在某些io阈值的时候执行某些tier policy。
note：就比如说应用程序编程的时候就可以指定在将来某个时候把数据存放在哪块盘上面~~~
SDE的集成
数据中心对（flex）灵活性和rapid的需求越来越大，而数据中心应用程序性能和计算、网络和存储这些资源息息相关。一个整体的对数据中心的smart的组织和安排方案（global view）肯定能打破计算，网络和存储的限制，明显的增加QoS和用户体验。
这个sde框架中的存储部分和其他的部件比如sdc和sdn都合作良好，并且整个框架有着丰富的api，还可以在这个框架上做各种各样的优化。比如说VM的安放问题。
storage-aware VM placement
VM的放置关系到cpu，内存和vdisk。对于一个io密集型的vm来说，它的vdisk放在SAN中的某个位置是相当重要的（延迟和带宽），对于一个计算密集型的VM来说，cpu和内存的分配就更加重要。所以vm的放置往往也需要考虑到cpu，存储和vdisk的问题。这个框架的逻辑能提供一个灵活的vm存储放置方案。LAB
IBM的研究人员创建了一个小型的实验环境，这个框架得到了很好的应用，效果也很好。
参考文献
[1]Alba, A., et al. "Efficient and agile storage management insoftware defined environments." IBM Journal of Research and Development 58.2 (2014): 1-12.