之前我们介绍了HBase，并且实战了如何通过HBase+SpringBoot实战分布式文件存储，我们为什么要使用HBase来实现文件存储呢，究其原因还是因为HDFS本身具有一定的局限性。而且大多数的公司在使用Hadoop的时候一般只用到了它的MR部分（分布式计算框架），对于HDFS这个文件存储服务的热忱并不太高，一是因为一般他自身都有一套支持虚拟化的文件存储服务，而且数据迁移及HDFS的一些特性相对来讲优势并不是很大。
那么有没有什么优秀的开源的分布式文件存储服务呢，答案必然是有的，今天我们就介绍一个特征丰富，高度可扩展的分布式存储系统：Ceph。
ceph简介
Ceph 是一个专注于分布式的、弹性可扩展的、高可靠的、性能优异的存储系统平台，可用于为虚拟机提供块存储方案或通过 FUSE 提供常规的文件系统。所以随着云计算的发展，搭上了OpenStack的顺风车，受到广泛的关注。Ceph 是个高度可配置的系统，管理者可以控制系统的各个方面。它提供了一个命令行界面用于监视和控制其存储集群。Ceph 也包含鉴证和授权功能，可兼容多种存储网关接口，如 OpenStack Swift 和 Amazon S3。功能可谓非常齐全。
Ceph支持三种调用接口:
1. 对象存储（Object）：有原生的API，而且也兼容Swift和S3的API
2. 块存储（Block）：支持精简配置、快照、克隆
3. 文件系统挂载（File）：Posix接口，支持快照这三种方式可以一同进行使用，通常我们会采用ceph作为openstack的后端存储来提高数据的存储和转发效率。
ceph基本结构
对照ceph的结构图我们先来介绍几个名词:
-
RADOS
RADOS位于ceph的最下层，Reliable, Autonomic, Distributed Object Store，即可靠的、自动化的、分布式的对象存储。CEPH所有的存储功能都是基于RADOS实现,RADOS由大量的存储设备节点组成，每个节点拥有自己的硬件资源（CPU、内存、硬盘、网络），并运行着操作系统和文件系统。
-
librados
顾名思义，这一层的功能是对RADOS进行抽象和封装，并向上层提供API，以便直接基于RADOS（而不是整个Ceph）进行应用开发。目前提供PHP、Ruby、Java、Python、C和C++支持。
-
RADOS GW（RADOS Gateway）、 RBD（Reliable Block Device）和Ceph FS（Ceph File System）
这三个模块我们一同来讲，它们都位于ceph的应用接口层，其作用是在librados库的基础上提供抽象层次更高、更便于应用或客户端使用的上层接口。
其中，RADOS GW是一个提供与Amazon S3和Swift兼容的RESTful API的gateway，以供相应的对象存储应用开发使用。RADOS GW提供的API抽象层次更高，但功能则不如librados强大。因此，开发者应针对自己的需求选择使用。
RBD则提供了一个标准的块设备接口，常用于在虚拟化的场景下为虚拟机创建volume。目前，Red Hat已经将RBD驱动集成在KVM/QEMU中，以提高虚拟机访问性能。
Ceph FS是一个POSIX兼容的分布式文件系统。由于还处在开发状态，因而Ceph官网并不推荐将其用于生产环境中
通过上面的介绍，我们可以清晰的看出Ceph的基本结构，以及其提供的完善的，多功能的接口服务。那么我们如何基于ceph进行应用呢，在上图中的第四层也可以清晰的看出来。在上图中最上面的那一层层，也就是应用层是不同场景下对于Ceph各个应用接口的各种应用方式，例如基于librados直接开发的对象存储应用，基于RADOS GW开发的对象存储应用，基于RBD实现的云硬盘等等。
ceph核心组件介绍
-
OSD
OSD全称Object Storage Device，也就是负责响应客户端请求返回具体数据的进程。一个Ceph集群一般都有很多个OSD。 -
Monitor
一个Ceph集群需要多个Monitor组成的小集群，它们通过Paxos同步数据，用来保存OSD的元数据。 -
Object
Ceph最底层的存储单元是Object对象，每个Object包含元数据和原始数据。 -
PG
PG全称Placement Grouops，是一个逻辑的概念，一个PG包含多个OSD。引入PG这一层其实是为了更好的分配数据和定位数据。（这个我们后面会着重介绍） - CRUSH
CRUSH是Ceph使用的数据分布算法，类似一致性哈希，让数据分配到预期的地方。
详情查看：ceph官方文档
参考资料：
[ceph总结][3]共同学习，写下你的评论
评论加载中...
作者其他优质文章
