解析Ceph和9000分布式存储
OceanStor 9000是国内比较流行的商业分布式文件系统，基于华为上一代CSS-F海量存储系统而演进，在架构上抛弃了元数据节点，从而采用分布式全对称架构。在媒资、高性能计算、大数据和视频监控都有很多成功案例和交付经验。今天我们花点时间讨论下Ceph和9000存储架构、应用场景和兼容性等方面的差异。
Cehp的基础服务架构
Cehp的基础服务架构主要包括了ObjectStorage Device(OSD)，Monitor和MDS。基于此，Ceph提供了Librados原生对象基础库、Librbd块存储库、Librgw基于S3和Swift兼容的对象库和Libceph文件系统库。
OSD(Object Storage Device)负责存储数据，处理数据复制、数据恢复、数据再均衡以及通过心跳机制监测其它OSD状况并报告给Ceph Monitors。
Monitor负责监控集群状态，包括监控自身状态、集群OSD状态、PlacementGroup（存储组织和位置映射）状态、CRUSH状态(Controlled Replication Under Scalable Hashing，一种伪随机数据分布算法)。同时，Monitor还会记录它们的每一个历史状态改变版本信息，以确定集群该遵循哪个版本。
MDS负责文件系统的元数据存储和管理，也就是如前所说，块存储和对象存储服务是不需要这个模块的。MDS负责提供标准的POSIX文件访问接口。
搭建一台Ceph系统至少需要1个Ceph Monitor和2个Ceph OSD逻辑角色，而Ceph Metadata server仅仅是运行CephFS时存储文件元数据。但在物理部署上，这些逻辑角色可以运行在同一台物理机上的。Ceph存储数据默认是2副本拷贝，所以不管是提供Object、Block还是File system服务，最小的Ceph系统需要2台OSD存储服务器。
9000的基础服务架构
9000是一个比较庞大的集群系统，在内部又由很多个负责不同角色的小集群组成。这些集群都部署在普通存储节点之上，ISM、CMS和Monitoring集群分别负责GUI管理配置、系统集群管理和状态监控，节点处于Active Standby模式保证系统可靠性。
CA(Client Agent)负责文件系统协议的语义解析执行，是文件系统业务发动机，文件切片、数据组合都由CA完成。9000支持标准CIFS、NFS和私有客户端；在私有客户端场景下，CA/SCA安装在服务器上，基于VFS文件系统开发并兼容Posix接口标准。
MDS(MetaData Service)管理文件系统的元数据，在9000中元数据和用户数据都保持在存储节点上，元数据采用高可靠多副本存储。元数据管理服务管理着整个系统的元数据和文件数据的布局信息，负责系统的资源分配。每个存储节点都是元数据节点。
客户端对对象服务的请求，通过OSC对象接口服务来响应，首先查找OMD对象存储元数据，然后根据查找结果获取对象位置并读写对于对象。OMD以集群的模式提供对象元数据服务，部署在每个对象存储物理节点上。
OBS是整个系统的基础服务器系统，基于对象存储系统，数据通过Key-Value的形式存储在磁盘上，基于OBS系统提供上层NAS和Object存储服务。OBS-C是客户端、负责数据的操作；OBS-S是服务端、提供数据存储服务，数据以对象的形式存放在数据子域中。
Cehp的软件体系架构
(1)基础存储系统RADOS
RADOS(Reliable, Autonomic, Distributed Object Store)一层本身就是一个完整的对象存储系统，包括Cehp的基础服务(MDS，OSD，Monitor)，所有存储在Ceph系统中的用户数据事实上最终都是由这一层来存储的。而Ceph的高可靠、高可扩展、高性能、高自动化等等特性本质上也是由这一层所提供的。因此，理解RADOS是理解Ceph的基础与关键。
RADOS在物理形态上由大量的存储设备节点组成，每个节点拥有自己的硬件资源(CPU、内存、硬盘、网络)，并运行着操作系统和文件系统。
(2)基础库librados
这一层的功能是对RADOS进行抽象和封装，并向上层提供不同API，以便直接基于RADOS进行原生对象或上层对象、块和文件应用开发。特别要注意的是，RADOS是一个对象存储系统，因此，基于librados实现的API也只是针对对象存储功能的。
RADOS所提供的原生librados API包括C和C++两种。Librados在部署上和基于其上开发的应用位于同一台机器。应用调用本机上的librados API，再由后者通过socket与RADOS集群中的节点通信并完成各种操作。
(3)高层存储应用接口
这一层包括了RADOSGW(RADOS Gateway)、 RBD(Reliable Block Device)和Ceph FS(Ceph File System)三个部分，其作用是在librados库的基础上提供抽象层次更高、更便于应用或客户端使用的上层接口。
RADOS GW是一个提供与Amazon S3和Swift兼容的RESTful API的gateway，以供相应的对象存储应用开发使用。RADOS GW提供的API抽象层次更高，但功能则不如librados强大。因此，开发者应针对自己的需求选择使用。
RBD则提供了一个标准的块设备接口，常用于在虚拟化的场景下为虚拟机创建volume。如前所述，Red Hat已经将RBD驱动集成在KVM/QEMU中，以提高虚拟机访问性能。
CephFS是一个POSIX兼容的分布式文件系统。目前还处在开发状态，因而Ceph官网并不推荐将其用于生产环境中。
(4)服务器客户端层
这一层就是不同场景下对于Ceph各个应用接口的各种应用方式，例如基于librados直接开发的对象存储应用，基于RADOS GW开发的对象存储应用，基于RBD实现的云硬盘等等。
Ceph Client是基于Fuse层(User SpacE)和VFS文件系统开发，兼容Posix接口标准。在Ceph存储系统中，Ceph Metadata Daemon 提供了元数据服务器，而Ceph Object Storage Daemon 提供了数据和元数据的实际存储。Ceph对DFS、Block和Object数据写入和读取，都需Client利用Crush算法(负责集群中的数据放置和检索的算法)完成存储位置计算和数据组装。
9000的软件体系架构
(1)基础服务层
OBS是整个系统的基础服务器系统，数据通过Key-Value的形式存储在磁盘上，基于OBS系统提供上层NAS和Object存储服务。采用Key-Value方式进行编址及存储，可以减少原来LBA方式的元数据存储量。
(2)数据处理层
基于OBS基础服务层，通过数据处理层构建NAS和Object服务。NAS的主要核心模块是MDS元数据服务和CA数据服务，每次数据请求都需要CA查找不同节点上的不同元数据定位请求文件的位置，并把从每个存储节点读取到的数据进行汇总，统一返回给客户端。Object的主要可行模块是OSC对象接口服务和OMD对象存储元数据服务。
(3)存储服务层
9000提供NAS和对象两种类型服务，同时提供了丰富的存储增值服务。对象包括数据重删、多版本、多租户、Swift和S3等服务；NAS包括快照、文件复制、分级存储、负载均衡等增值服务和HDFS、NDMP等服务。
由于9000集群管理、监控等服务都是采用1 Active主2 Standby备模式，且EC算法等要求，所以9000存储系统支持最少3节点起配；当NAS和对象共存时，做小节点是5节点起配。文件和对象元数据相互分离，但用户数据空间是共享的。
OpenStack的兼容和支持
Ceph存储软件最常见的用途之一是作为OpenStack云存储后端，另一个用途是在 RADOS中存放和检索VM镜像(OpenStack Glance镜像服务)。目前以HP、Dell、Intel等为代表的企业IT领导厂商和以Mirantis、eNovance、UnitedStack为代表的OpenStack社区新兴厂商，都将Ceph作为重要的乃至于首选的开源存储解决方案。
Ceph事实上是目前OpenStack生态系统中呼声最高的开源存储解决方案。Ceph的对象存储(Object Storage)可以对接网盘等应用业务；块设备存储(Block Device Storage)可以对接(IaaS)，例如OpenStack、CloudStack、Zstack、Eucalyptus以及KVM虚拟化等主流的IaaS云平台软件，文件系统(CephFS)尚不成熟。
目前已经与QEMU虚机化(硬件虚拟化)集成，通过相关命令调用管理Ceph块存储服务(RBD)。支持通过对OpenStacklibvirt和QEMU之间的配置，来实现对KVM、XEN、LXC、VirtualBOX等各种虚机镜像管理。
支持通过libvirt将Ceph块存储服务(RBD)加入到OpenStack，已经完成与Glance(VM镜像管理)、Cinder(块存储)集成。通过Glance存储虚机镜像到CephRBD或者通过Cinder启动虚机。
Ceph对象(Object Gateway)目前支持Amazon S3和OpenStack Swift，集成支持了OpenStack的keystone身份认证。
9000目前计划支持Openstack Malina NAS接口，实现也Openstack进行对接。另外也支持Amazon S3和OpenStack Swift，集成支持了OpenStack的keystone身份认证。由于目前9000还不支持SAN存储，所以无法实现与OpenStack Glance镜像集成。
学习总结
Ceph基础库Librados和高层应用都提供了API，但是二者面向的用户对象不同。librados API更底层，没有账户、容器等等高级概念，它更适合对存储系统理解深刻并进行功能定制和性能深度优化的存储高级用户；而RADOS Gateway等的高级应用API则更加适合应用的开发者。下面我们对Ceph和9000存储系统进行简单对比。
扩展性: Ceph针对的场景主要是大规模和分布式存储，数据量级一般希望PB级别以上，存储节点成千上万。9000目前最大支持288节点、60PB容量，据悉未来规划切平台到RH系列X86服务器之后，在节点上应该无限制。
系统架构: 9000和Ceph在架构上很相似，分布式、全对称、X86商业硬件的SDS架构，存储层数据基于对象保存在磁盘上。区别在于9000集成CA数据访问客户端，对外提供标准的CIFS和NFS，可以兼容Windows、Linux、Unix和Mac OS等系统，支持NAS和Object存储服务；Ceph需要单独的服务器客户端，目前主要兼容Linux主流系统。
应用场景: Ceph支持NAS、SAN和Object服务，服务接口更丰富，但主要提供SAN和Object存储，一般用于和OpenStack云对接，聚焦备份和归档；9000支持NAS和Object服务，针对大数据、媒资和HPC场景设计，所以主要用于高带宽媒资编辑、基因测序、视频监控和容量资源池等场景，两者应用场景有些不同。
可靠性和容量利用率: Ceph采用Crush算法(类似EC)和双副本方法存储数据，但是Ceph数据存储和检索处理都在Clinet端处理，在数据读写过程中可能对Clinet服务器端的性能有些影响。9000也是采用EC(Erasure Code)和多副本技术，所以在可靠性和容量使用率上与Ceph基本一致；但9000数据的切片和聚合都在存储上实现，对主机没有什么影响。
软件特性: Ceph和9000都实现了文件快照、HDFS等特性，但是文件分级、文件复制、NDMP等在Ceph中暂时还没看到。Ceph实现了块存储快照、Thin和复制等功能。虽然说Ceph在NAS功能上比较欠缺，但目前Ceph发展的策略是从Block、Object到FilesyStem。
统一管理: 目前Ceph采用CLI和配置文件方式完成系统配置和管理，这基本上是开源项目的典型一个特点，对运维管理人员要求比较高。9000支持统一GUI管理、配置和监控，比较方便运维。但是Ceph在云集成方面的能力值得9000学习和借鉴。
温馨提示：
请搜索“ICT_Architect”或“扫一扫”下面二维码关注公众号，获取更多精彩内容。
