SDS软件定义存储

计算机发展到今天，软件定义已经是一种潮流，前有软件定义网络，后有软件定义存储。

对于软件定义存储来说，是随着当年EMC在EMC World上发布的软件定义存储战略迅速成为业界热点的。软件定义存储将硬件存储资源整合起来，并通过软件编程的方式来定义这些资源，借此，用户能够根据一定的策略来配置和使用存储服务。

另外，随着存储系统的多样化，如果依然对不同的存储使用不同的软件，效率会非常低，并且会增加运维的复杂度。而且不同的存储软件之间不能互通，这也会影响存储的调度。于是急需一个非常高效的、统一的存储软件，用于管理不同的存储，并且可以在不同的存储之间根据用户的需求进行相应的调度。这就促进了软件定义存储的诞生，来满足管理、资源调度或编排的需求。

OpenSDS

当今企业正在经历从传统数据中心向云转型的过程，现在计算、网络已在虚拟化进程中取得重大进展，而存储的虚拟化进程还相对滞后，依然面临异构管理、烟囱式建设的问题，这成为了数据中心云化演进的瓶颈。

软件定义存储是存储云化的重要手段，其方向在于帮助用户在传统数据中心或云内实现存储资源的池化和服务化，以及在多云之间实现数据的统一管理和自由流动。但目前软件定义存储尚不成熟，主要挑战在于控制面标准缺失，各存储厂商自行定义标准和规范，导致生态发展缓慢。因此业界需要有统一的软件定义存储标准，面向应用提供灵活、按需供给、服务化、目录化的存储数据服务。

基于这样的背景和OpenStack成功的启示，华为牵手多家业界领先的存储厂商和优秀企业，经过一系列的交流讨论最终达成一致的结论，决定在Linux基金会下共同组建OpenSDS开源社区，以致力于软件定义存储标准化推行、软件定义存储控制器参考架构发布，以及标准API开放。最终用户基于OpenSDS标准可获得轻量级、厂商中立的软件定义存储环境，面向多云场景提供资源按需供给，数据统一管理及跨云自由流动的多云数据服务。

OpenSDS架构

如果读者比较熟悉存储的管理系统，包括现在云计算管理平台涉及存储的管理内容，可以看到如图1所示的混乱现状：有多种计算平台，开源的也好，厂商自研的也好；中间的存储控制器也是层出不穷，几乎每个设备商都会自己研制1～N个控制器，还有一大堆开源的控制器；最后到具体存储设备，或者存储的解决方案也是五花八门。

也就是说，用户如果准备把业务迁移到云上，首先要挑选一个云计算平台，然后挑选一个存储控制器，还要挑选一个符合自身业务特性的存储后端。由此可见用户需要做多项选择，这个图并不是每个用户都需要在上面做全连接，其实对于任何一个用户即便是从三层里面每一层挑一个出来，如果想达到一个最好的选择，都是一件非常困难的事情。

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

其实我们发现，在大多数情况下都不是这样的，会存在错配的情况，也就是存储并不能按需进行调度分配，通常情况就是将就着使用，反正也没有别的选择。

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

正是在这些需求的驱动下，OpenSDS社区成立了，社区愿景就像刚才描述的一样，也就是对应用来说，有一个标准而统一的控制器，可以提供存储资源；而对存储资源来说，有一个标准的控制器，能够把正确的调度需求传达下来，以使设备或其他存储方案能够最佳地匹配应用需求，从而发挥最大的功效。用一句话概括来说，OpenSDS就是适用于多云环境下的存储资源统一编排调度的存储控制器，它可以提供如下的功能。

·　标准：OpenSDS目的是建立一套关于软件定义存储的开放标准。

·　服务发现（Discovery）：把每一个存储的后端作为一个服务，来进行后端的一些资源池及一些能力的上报。

·　资源池：提供一套统一的资源池，供上面的云平台进行调度。

·　服务发放（Provisioning）：针对存储相关的业务提供一个服务发放的功能。

·　管理：有一个统一的控制器，对下面的存储资源进行统一的管理。

·　自动化：OpenSDS的目标是提供一套用于云化存储的自动化的一个解决方案。

·　自服务（Self-service）：可以提供自服务的功能，比如说会有一些内部的系统监控，以保证系统的高可用性。

·　异构：定位是解决现在存储异构的一些统一的管理问题。

·　编排：会提供一套基于策略的编排调度的框架。

OpenSDS包括两个核心的子项目：Sushi与Hotpot。Sushi是OpenSDS的北向插件项目，与容器、OpenStack等云管理平台对接。Hotpot是OpenSDS的Controller项目。

Sushi与Hotpot整合在一起，就是如图2所示的OpenSDS架构，最上层是统一的北向接口；中间是控制或编排器核心的逻辑，通过它处理一些基于策略的调度，比如一些设备发现、存储池化、服务目录等；最下层是HUB，HUB用来接入第三方不同厂商的设备，实现OpenSDS对多后端存储的支持，给开发者一个灵活的开发模型。

OpenSDS的开放性应该是其最重要的特点之一，北向通过REST API实现与不同IaaS、PaaS、CaaS和SaaS的平台对接，并把企业级存储能力开放给上层调度和编排系统，南向HUB通过OpenStack API、OpenSDS Native API或CoprHd实现对不同存储的管理和服务编排。这种标准的南北向API完全屏蔽不同生态使用存储的差异性，使用户或租户更加关注上层应用和存储服务指标。

存储系统未来发展的两大趋势是数据服务化和智能运维，服务化或云化，是指在使用资源时，买多少用多少（配额管理），买多长时间用多长时间（计量），用时开通不用时关闭（资源复用）。

OpenSDS也考虑到了智能运维和数据流动，或数据生命周期管理的问题，通过监控、报表、分析和预测等工具实现智能运维。通过与华为云、AWS、Azure和Google云形成混合云，实现数据流动和生命周期管理，让数据在生命周期的不同阶段保存在合适的存储位置中。

OpenSDS应用场景

1.传统数据中心场景

通过定义和实现存储标准化接口，帮助用户简化传统数据中心种类繁多的异构存储管理方式，降低存储运维成本，提高存储资源的利用率，避免厂商绑定。

·　存储接口标准化：通过标准化定义的软件定义存储统一标准，为用户解决异构存储设备接口多样化的问题，降低数据中心维护成本。基于标准接口构建丰富的北向生态，帮助用户轻松将存储与北向的云平台和应用集成，支撑用户业务快速上云。

·　存储能力服务化：对各厂商、多类型的存储资源进行逻辑池化，并使用标签化的方式将资源池中的存储能力简单、抽象地表达出来，简化对存储设备能力的定义，通过统一的接口、视图让运维管理人员轻松识别数据中心存储整体能力情况。同时根据用户业务诉求，帮助用户构建典型的SLA，使得存储资源发放变得简单高效，用户只需结合自己的业务情况选择对应的SLA，即可完成存储资源自动化发放。

2.多云场景

如图3所示，帮助用户解除存储厂商和云厂商绑定，统一数据中心和公有、私有云之间的数据管理，让用户基于统一视图进行管理、流动和利用所有数据，降低用户在多云场景中的数据管理成本，并充分发挥用户数据的最大价值。

·　数据统一管理：从空间维度看，应用不关注数据放在哪个数据中心的存储设备或放在哪朵云上，通过一套标准接口即可在多个数据中心或公有、私有云中进行智能的数据流动和统一管理。

·　数据生命周期管理：从时间维度看，实现数据从过去、现在到未来（即数据发放、数据保护、数据流动、数据归档、数据消亡等）的数据生命周期管理。

与Kubernetes集成

如图4所示，OpenSDS社区提供了专门的OpenSDS CSI（Container Storage Interface）Plugin与Kubernetes集成，同时在Kubernetes内部还开发了特定的OpenSDS Service Broker，来负责在不改变代码的情况下暴露OpenSDS的高级特性（比如replication、migration、data protection等）给Kubernetes。

与OpenStack集成

OpenSDS最新的Aruba版本里增加了与OpenStack的集成，如图6-5所示。在部署OpenStack环境时，通过Cinder-compatible api模块，可以使用OpenSDS取代Cinder的角色，这个时候，我们不需要部署Cinder，只需要部署OpenSDS，然后OpenSDS会通过Cinder Driver Lib项目访问原本在Cinder中支持的那些后端存储驱动（目前并不是所有的Cinder后端存储驱动能够被这个项目支持）。