Ceph浅接触

好记性不如烂笔头o(^▽^)o

ceph

定义

原始论文：《Ceph: Reliable, Scalable, and High-Performance Distributed Storage》

Ceph的官方网站Ceph.com定义：

“Ceph is a unified, distributed storage system designed for excellent performance, reliability and scalability.”

Ceph是统一分布式存储系统，具有优异的性能、可靠性、可扩展性。
“统一的”意味着Ceph可以一套存储系统同时提供对象存储、块存储和文件系统存储三种功能，以便在满足不同应用需求的前提下简化部署和 运维。
“分布式的”在Ceph系统中则意味着真正的无中心结构和没有理论上限的系统规模可扩展性。

特性

Ceph是分布式存储的一个实现：

分布式架构,无中心查询节点, 即不使用元数据查询
无单点故障
自管理 -很多节点要维护,需要自管理
基于PAXOS 分布式算法保证决策一致性
Scale-out架构,理论上无上限扩展
无性能瓶颈
构建与Commodity 服务器之上.
完全基于软件

提供的功能：
对象存储服务 , 提供S3, SWIFT接口, 以HTTP方式存取对象(文件)
块存储服务, 提供块服务,可供挂载 (MOUNT),使用的对象是操作系统
文件存储服务, 提供网络文件服务, 支持NFS,CIFS接口, 兼容POSIX标准.

Ceph的节点类型：
OSD : 实际存储数据的节点
MON : 监控节点, 控制面 , 维持集群的成员及状态,提供强一致性决策.
MDS : 元数据服务,仅CephFS 文件服务需要.

架构

  Ceph的底层是RADOS(可靠、自动、分布式对象存储)，可以通过LIBRADOS直接访问到RADOS的对象存储系统。RBD(块设备接口)、RADOS Gateway(对象存储接口)、Ceph File System(POSIX接口)都是基于RADOS的。
  Ceph专注于扩展性，高可用性和容错性。Ceph放弃了传统的Metadata查表方式（HDFS）而改用算法（CRUSH）去定位具体的block。

各层提供的接口：
LIBRADOS（Native API）:

read、write
snapshot
append、tuncate、clone range
object level key-value mappings

RADOS Gateway(REST API)：

兼容S3和Swift接口

RBD(Block Storage ):

Thinly provisioned
Resizable images
Image import/export
Image copy or rename
Read-only snapshots
Revert to snapshots
Ability to mount with Linux or QEMU KVM clients!

Ceph File System：

It provides stronger data safety for mission-critical applications.
It provides virtually unlimited storage to file systems.
Applications that use file systems can use Ceph FS with POSIX semantics. No integration or customization required!
Ceph automatically balances the file system to deliver maximum performance.

  RADOS是ceph的核心层，它是分布式对象存储系统，由自修复、自管理、智能的存储节点组成。RADOS作为数据持久层，是RADOSGW、RBD、CEPH FS的基础。
  分布式对象存储的基本问题是如何分布数据到上千个存储节点上，RADOS的核心是CRUSH(一个可扩展的伪随机数据分布算法)。CRUSH能够有效映射数据对象到存储节点上，而且能够处理系统的扩展和硬件失效，最小化由于存储节点的添加和移除而导致的数据迁移。CRUSH算法达到了效率和扩展性这两个矛盾的目标。

Ceph最为核心的技术创新就是前面所概括的八个字——“无需查表，算算就好”。一般而言，一个大规模分布式存储系统，必须要能够解决两个最基本的问题：
一是“我应该把数据写入到什么地方”。 对于一个存储系统，当用户提交需要写入的数据时，系统必须迅速决策，为数据分配一个存储位置和空间。这个决策的速度影响到数据写入延迟，而更为重要的是，其决策的合理性也影响着数据分布的均匀性。这又会进一步影响存储单元寿命、数据存储可靠性、数据访问速度等后续问题。
二是“我之前把数据写到什么地方去了”。 对于一个存储系统，高效准确的处理数据寻址问题也是基本能力之一。
  针对上述两个问题，传统的分布式存储系统常用的解决方案是引入专用的服务器节点，在其中存储用于维护数据存储空间映射关系的数据结构。在用户写入/访问数据时，首先连接这一服务器进行查找操作，待决定/查到数据实际存储位置后，再连接对应节点进行后续操作。由此可见，传统的解决方案一方面容易导致单点故障和性能瓶颈，另一方面也容易导致更长的操作延迟。
  针对这一问题，Ceph彻底放弃了基于查表的数据寻址方式，而改用基于计算的方式。简言之，任何一个Ceph存储系统的客户端程序，仅仅使用不定期更新的少量本地元数据，加以简单计算，就可以根据一个数据的ID决定其存储位置。对比之后可以看出，这种方式使得传统解决方案的问题一扫而空。Ceph的几乎所有优秀特性都是基于这种数据寻址方式实现的。
——摘自章宇，这里链接也是别人转载的，非源地址。

Ceph和对象存储系统

  RADOS和S3、Swift同属分布式对象存储系统，但RADOS提供的功能更为基础、也更为丰富。
  Swift（以及S3）提供的API所操作的“对象”只有三个：用户账户、用户存储数据对象的容器、数据对象。并且，所有的操作均不涉及存储系统 的底层硬件或系统信息。不难看出，这样的API设计完全是针对对象存储应用开发者和对象存储应用用户的，并且假定其开发者和用户关心的内容更偏重于账户和数据的管理，而对底层存储系统细节不感兴趣，更不关心效率、性能等方面的深入优化。