我这次演讲的题目叫做OpenSDS的前世今生，给大家介绍命题的由来。 如果大家比较熟悉存储的管理系统，包括现在所谓的云计算管理平台涉及到存储这部分的管理内容，其实大家可以发现现在的现状。

先感谢现在还坚守在会场的朋友，咱们这一下午如果有人一直在这边听听了很多的存储解决方案。

刚才讲了很多，其实OpenSDS解决的问题就是你在这么多种优秀的存储资源或者存储后端的选择的情况下，对于一个管理平台来讲你怎么更好的管理这些存储的资源和系统。

我这次演讲的题目叫做OpenSDS的前世今生，给大家介绍命题的由来。

如果大家比较熟悉存储的管理系统，包括现在所谓的云计算管理平台涉及到存储这部分的管理内容，其实大家可以发现现在的现状。

之前胶片也有一个类似的图，一个非常混乱的，我们有非常多种的计算平台，开源的也好，厂商自研也好，中间所谓的存储控制器也是层出不穷，几乎每个设备商都会自研一到N个控制器，你还有开源的，还有一大堆的控制器，最后到了存储具体设备，或者说存储的解决方案也是五花八门。

你看今天下午介绍了很多种，你要加上各个存储厂商的设备实现非常多，那么也就是说，我们说对于一个用户，我准备把我的业务迁移到云上，那我要挑选一个云计算平台，我要挑选一个存储控制器，我要挑选一个我认为符合我的业务特性的存储后端。

大家看一下它要做的选择是多么的困难，这个图并不是每一个客户都会有，所有的都是都在上面做全连接，其实就是对于任何一个客户即便是从三层里面每一层挑一个出来，如果想达到一个最好的选择，其实都是一个非常困难的事情，其实另外一个现状就是假定说我可能我的目标非常明确。

我的思维也非常清晰，我选择上，在异构管理上困难并不是太大，我上中下三层基本都已经是一个非常定型的东西。

其实还有一个问题，我们现有的这些计算平台也好，控制器也好，存储资源也好，他们互相之间是不是真的理解，也就是当你用你手头的自己觉得非常好用的云计算管理平台为你的应用去调度存储资源或者分配存储资源的时候，你觉得你用的存储真的了解你的应用的需求吗，还有你可能花了大量的金钱，采购了这些存储设备，他们真的会理解你的应用特性请求吗？

其实我们发现好多的都不是这样，会存在错配的情况，也就是存储并不是能够很好的按需调度分配应用的，通常情况大家就像凑合过日子，反正你也没有别的选择，我只能分析这些，凑合用。

这些并不是新问题，已经存在很长时间，软件定义也不是一个新名词，到了现在至少存在了五到六年的时间，不管是厂商还是客户一直以来其实是有一个期望的，那也就是对于我的客户来说，我能不能更简单的管理我的资源，第二，能够按需调度我的存储资源，对于开发者来说，我是不是能够学一次就行。每次新出来一个东西就会被客户逼着去开发一大堆的东西，有没有一种方法可以去尽量减轻这些痛苦。

正是这些需求的驱动下，我们几个厂商加客户其实一起在去年年底成立的OpenSDS社区，社区愿景就像刚才描述的一样，也就是我们希望对于应用来说，我有一个标准而统一的控制器，可以为我提供存储资源。

仅此而已，我希望我拿到我所需要的存储，那么对于存储资源来说，我希望有一个标准的控制器，能够把正确的调度需求告诉我，以使得我是设备或者其他存储方案也好，能够最佳的匹配应用需求，从而发挥我最大的功效。

其实社区历程，我们这是一个非常非常年轻的社区，整个社区正式成立是在去年的年底，当时成立的时候基金会的CEO是非常高兴得，觉得我们填补了一个空白，这些年成立了这么多项目还没有一个专门做存储的项目。

那我们到现在其实大家可以看到目前社区的成员包括EMC，HDS，有华为，客户有沃达丰，有比较有名的做开源的做开源的院校OSU，他们有一个非常大的专门做开源的实验室，那么其实我们去年正式成立的社区，今年开始，代码开发几乎是从0开始的，其实这个也是OpenSDS的一个重要特点。

我们觉得完全是从0开源开发的，之前的开源项目一定是某些厂商事先开发出来，告诉你我们有多牛逼，我们非常非常牛，直到你客户用的时候发现这是一个单厂商的开源项目，有N多坑，因为单厂商的开源项目往往是这个厂商拿到了这个厂商相对的客户需求。

我根据这个客户需求我们做了一个基础项目，可能老大说你这个也卖不的多少钱，所以最后就发现好多我们就把代码扔出去了，开源并不只是说把代码扔出去，其实开源最重要的一点一定要有公开的设计，OpenStack有一个非常著名四个公开的原则，我觉得非常好，所以我们就是这么一个社区，所有代码都是这样，大家有兴趣可以去看几乎是从0开始干的。

社区伙伴刚才提了，目前我们社区的会员，我们现在社区处于初期的形式，这是基金会建议的，为了使项目快速启动，我们现在在制订正式的治理模式的章程，应该是今年年终或者年底的出来就会有比较正式的会员等级，像治理规范还有各种的专业委员会，比如做技术的，做技术开发的委员会，这些都会建立起来。

所以如果有兴趣的现在尽早加入，现在还是一个比较好的事情，跟我们相关的开源社区非常多。

大家可以看到，刚才提到社区的开发其实我们是从头开发，而且我们所有的东西都是公开的，我们的主办代码在OpenSDS文件夹下面。

然后我们除了开发架构是通过由各个会员厂商的架构师，我们每周或者每两周的例行会议，这些都是开放的，我们最近也开始梳理会议纪要放在网上，大家可以看到OpenSDS架构是怎么产生的，怎么演进的，这个架构是完全公开讨论公开定的，不是任何一个厂商已有的东西。

第三个就是我们现在做的API的，因为一个标准化的接口对我们来说是一个非常重要的事情，这个后面会具体提，尤其对存储来说是非常重要的我们做OpenSDS的初衷。

最后是我们的成员公司，因为刚才提到了SDS不是一个新的东西，大家之前做了很多的尝试，有像EMC提的，我们把这些原代码也都放上来了。

刚才介绍的都是社区，下面介绍一下技术。OpenSDS的架构是这样的，我们大体分成三层，北向有一个统一的接口，中间就是我们控制或者编排器核心的逻辑，我们处理一些基于策略的调度，比如一些设备发现的综合做一些，最下面一层就是我们的HUB，整体非常highlevel的架构就是这些。

实际实现就是有立体模块的，这个图有点老，我们后面会发新的。

我们现在在做的可以找到的代码叫POC版本，因为我们是从0做的，我们要不断的验证我们做的这个东西是是否合理，所以到今年3月底之前我们完成的其实是K8S的POC，我们达到的目的就是现在可以通过OpenSDS为1.5版本提供一个混合了Open stack的块储存与文件储存混合的存储服务。

我们一阶段实现的就是这样的功能，所以我们的代码来说，我们的API这层基本组件已经开发完成，HUB里面有一个组件是作为一个统一的抽象的，我们专门写了一层，会把接口重新定义出来，比如快照都会定义出来。我们的消息是用的gRPC，我们用gRPC后面提到有现实目的的，不是为了用而用的，是因为我们部署的需求。

刚才讲的是我们技术架构的，提到了我们三月底之前问题一阶段的POC，要测试的，所以我们在社区官方的集群申请了一套节点，我们做了相当与现在官方的做了K8、OpenSDS和Openstack的集中测试，基本达到了目的。

刚才提到了我们为什么会用gRPC，其实在我们真正部署的时候其实所有的控制器都会有这个问题，大家如果熟悉网络，网络有一个非常有名的开源的，它的最终设计的时候就是作为一个中央的业务控制器，所以当它需要处理稍微大一点规模的时候，就必须要把控制器分布起来，你一旦要做控制器分布式，你控制器里面维护的状态同步就非常重要，遇到非常经典的CAP等这些问题。所以当我们在实际做POC我们做部署的时候发现其实我们是可以通过把OpenSDS控制器组件拆分，通过一种方式尽可能的避免这个问题。

我们实际部署的时候，刚才大家看到上面的两层部署到控制节点，HUB也就是抽象的接入层匹配上所有你应用需要的后端的驱动，这一些我们是给打包另外一个模块，心里就可以编译成文件部署在你所有需要的节点上，我们是通过HUB分布式方式实现分布式部署的。

其实这样尤其是我们用gRPC在并发的场景下我们发现像吞吐这些问题还不是特别大，而且它支持会相对好一些，通常情况下只有一个像我们跟K8功能部署的时候，你基本一个控制节点能够对应的HUB分布式节点数目可以做得非常高，所以避免了你要处理分布式的这种状态和管理，尽量避免这个问题。

当然随之带来的就是控制器和HUB怎么处理心跳得问题，就是新问题引入解决旧问题，比如之前很多的开发者过来看我们的演示，跟我们反馈他们没有用的后端都要定义，这是一个非常痛苦的事情，可见工作量对他们造成的困扰，所以我们现在正在进行的，我们通过OpenSDS对多后端的支持，给开发者节省掉你需要为每一种后端开发驱动的一个困境。

第二个，我们会增强对快照以及快照策略的支持，因为阶段一的话，我们做的是Openstack大家可以想像又是K8，层级非常多，我们开发一个存储后端原生的一个插件，我们会希望5月份通过OpenSDS可以直接管理ceph这样的存储后端，调动一个可以部署不同在存储后端上的容器需要的存储。

刚才有一个未来的全景图，其实我们还是希望OpenSDS能够作为一个存储界的专业的开源存储控制器，能够把所有相关的生态连接起来，像我一开始说的，你会想要有基于内存的分布式的尊出系统，你可能会用数据库的存储，无论怎么样，我们的目标就是给你提供一个你可以应用分配这些多种多样存储的一个调度器和控制器。

最后非常欢迎大家的参与，刚才提到了我们的代码仓库就在这个上面，这个项目现在还非常年轻，所以特别欢迎大家有想法加入到我们这里，作为唯一的一个软件定义存储的开源项目，其实我觉得未来在各位的手中。

感谢大家，大家有兴趣可以私下找我联系，谢谢大家。