Ceph 介绍

1. 介绍

  Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统。ceph 的统一体现在可以提供文件系统、块存储和对象存储，分布式体现在可以动态扩展。在国内一些公司的云环境中，通常会采用 ceph 作为openstack 的唯一后端存储来提高数据转发效率。

  Ceph项目最早起源于Sage就读博士期间的工作（最早的成果于2004年发表），并随后贡献给开源社区。在经过了数年的发展之后，目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack都可与Ceph整合以支持虚拟机镜像的后端存储。

官网：https://ceph.com/
官方文档：http://docs.ceph.com/docs/master/#

2. 特点

2.1 高性能

  • 摒弃了传统的集中式存储元数据寻址的方案，采用CRUSH算法，数据分布均衡，并行度高。
  • 考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。
  • 能够支持上千个存储节点的规模，支持TB到PB级的数据。

2.2 高可用性

  • 副本数可以灵活控制。
  • 支持故障域分隔，数据强一致性。
  • 多种故障场景自动进行修复自愈。
  • 没有单点故障，自动管理。

2.3 高可扩展性

  • 去中心化。
  • 扩展灵活。
  • 随着节点增加而线性增长

2.4 特性丰富

  • 支持三种存储接口：块存储、文件存储、对象存储。
  • 支持自定义接口，支持多种语言驱动。

3. 应用场景

  Ceph可以提供对象存储、块设备存储和文件系统服务，其对象存储可以对接网盘（owncloud）应用业务等；其块设备存储可以对接（IaaS），当前主流的IaaS运平台软件，如：OpenStack、CloudStack、Zstack、Eucalyptus等以及kvm等。

  Ceph是一个高性能、可扩容的分布式存储系统，它提供三大功能：

  • 对象存储（RADOSGW）：提供RESTful接口，也提供多种编程语言绑定。兼容S3、Swift；
  • 块存储（RDB）：由RBD提供，可以直接作为磁盘挂载，内置了容灾机制；
  • 文件系统（CephFS）：提供POSIX兼容的网络文件系统CephFS，专注于高性能、大容量存储；

  什么是块存储/对象存储/文件系统存储？

3.1 对象存储：

  也就是通常意义的键值存储，其接口就是简单的GET、PUT、DEL 和其他扩展，代表主要有 Swift 、S3 以及 Gluster 等；

3.2 块存储：

  这种接口通常以 QEMU Driver 或者 Kernel Module 的方式存在，这种接口需要实现 Linux 的 Block Device 的接口或者 QEMU 提供的 Block Driver 接口，如 Sheepdog，AWS 的 EBS，青云的云硬盘和阿里云的盘古系统，还有 Ceph 的 RBD（RBD是Ceph面向块存储的接口）。在常见的存储中 DAS、SAN 提供的也是块存储；

3.3 文件系统存储：

  通常意义是支持 POSIX 接口，它跟传统的文件系统如 Ext4 是一个类型的，但区别在于分布式存储提供了并行化的能力，如 Ceph 的 CephFS (CephFS是Ceph面向文件存储的接口)，但是有时候又会把 GlusterFS ，HDFS 这种非POSIX接口的类文件存储接口归入此类。当然 NFS、NAS也是属于文件系统存储.

4. 核心

4.1 核心组件

avatar

  • Monitors：监视器，维护集群状态的多种映射，同时提供认证和日志记录服务，包括有关monitor 节点端到端的信息，其中包括 Ceph 集群ID，监控主机名和IP以及端口。并且存储当前版本信息以及最新更改信息，通过 "ceph mon dump"查看 monitor map。
  • MDS（Metadata Server）：Ceph 元数据，主要保存的是Ceph文件系统的元数据。注意：ceph的块存储和ceph对象存储都不需要MDS。
  • OSD：即对象存储守护程序，但是它并非针对对象存储。是物理磁盘驱动器，将数据以对象的形式存储到集群中的每个节点的物理磁盘上。OSD负责存储数据、处理数据复制、恢复、回（Backfilling）、再平衡。完成存储数据的工作绝大多数是由 OSD daemon 进程实现。在构建 Ceph OSD的时候，建议采用SSD 磁盘以及xfs文件系统来格式化分区。此外OSD还对其它OSD进行心跳检测，检测结果汇报给Monitor
  • RADOS：Reliable Autonomic Distributed Object Store。RADOS是ceph存储集群的基础。在ceph中，所有数据都以对象的形式存储，并且无论什么数据类型，RADOS对象存储都将负责保存这些对象。RADOS层可以确保数据始终保持一致。
  • librados：librados库，为应用程度提供访问接口。同时也为块存储、对象存储、文件系统提供原生的接口。
  • RADOSGW：网关接口，提供对象存储服务。它使用librgw和librados来实现允许应用程序与Ceph对象存储建立连接。并且提供S3 和 Swift 兼容的RESTful API接口。
  • RBD：块设备，它能够自动精简配置并可调整大小，而且将数据分散存储在多个OSD上。
  • CephFS：Ceph文件系统，与POSIX兼容的文件系统，基于librados封装原生接口。

4.2 存储系统的逻辑层次结构

avatar

4.3 RADOS的系统逻辑结构

avatar

4.4 Ceph 数据存储过程

avatar

  无论使用哪种存储方式（对象、块、文件系统），存储的数据都会被切分成Objects。Objects size大小可以由管理员调整，通常为2M或4M。每个对象都会有一个唯一的OID，由ino与ono生成，虽然这些名词看上去很复杂，其实相当简单。

  • ino：即是文件的File ID，用于在全局唯一标识每一个文件
  • ono：则是分片的编号

  比如：一个文件FileID为A，它被切成了两个对象，一个对象编号0，另一个编号1，那么这两个文件的oid则为A0与A1。

  File —— 此处的file就是用户需要存储或者访问的文件。对于一个基于Ceph开发的对象存储应用而言，这个file也就对应于应用中的“对象”，也就是用户直接操作的“对象”。   Ojbect —— 此处的object是RADOS所看到的“对象”。Object与上面提到的file的区别是，object的最大size由RADOS限定（通常为2MB或4MB），以便实现底层存储的组织管理。因此，当上层应用向RADOS存入size很大的file时，需要将file切分成统一大小的一系列object（最后一个的大小可以不同）进行存储。为避免混淆，在本文中将尽量避免使用中文的“对象”这一名词，而直接使用file或object进行说明。

  PG（Placement Group）—— 顾名思义，PG的用途是对object的存储进行组织和位置映射。具体而言，一个PG负责组织若干个object（可以为数千个甚至更多），但一个object只能被映射到一个PG中，即，PG和object之间是“一对多”映射关系。同时，一个PG会被映射到n个OSD上，而每个OSD上都会承载大量的PG，即，PG和OSD之间是“多对多”映射关系。在实践当中，n至少为2，如果用于生产环境，则至少为3。一个OSD上的PG则可达到数百个。事实上，PG数量的设置牵扯到数据分布的均匀性问题。关于这一点，下文还将有所展开。

  OSD —— 即object storage device，前文已经详细介绍，此处不再展开。唯一需要说明的是，OSD的数量事实上也关系到系统的数据分布均匀性，因此其数量不应太少。在实践当中，至少也应该是数十上百个的量级才有助于Ceph系统的设计发挥其应有的优势。

  基于上述定义，便可以对寻址流程进行解释了。具体而言， Ceph中的寻址至少要经历以下三次映射：

  • File -> object映射
  • Object -> PG映射，hash(oid) & mask -> pgid
  • PG -> OSD映射，CRUSH算法 　　

  CRUSH，Controlled Replication Under Scalable Hashing，它表示数据存储的分布式选择算法， ceph 的高性能/高可用就是采用这种算法实现。CRUSH 算法取代了在元数据表中为每个客户端请求进行查找，

作用：它通过计算系统中数据应该被写入或读出的位置。CRUSH能够感知基础架构，能够理解基础设施各个部件之间的关系。并CRUSH保存数据的多个副本，这样即使一个故障域的几个组件都出现故障，数据依然可用。CRUSH 算是使得 ceph 实现了自我管理和自我修复。

  RADOS 分布式存储相较于传统分布式存储的优势在于:

  • 将文件映射到object后，利用Cluster Map 通过CRUSH 计算而不是查找表方式定位文件数据存储到存储设备的具体位置。优化了传统文件到块的映射和Block MAp的管理。
  • RADOS充分利用OSD的智能特点，将部分任务授权给OSD，最大程度地实现可扩展

4.5 Ceph IO流程及数据分布

avatar

  正常IO流程图

avatar

步骤：

  • client 创建cluster handler。
  • client 读取配置文件。
  • client 连接上monitor，获取集群map信息。
  • client 读写io 根据crshmap 算法请求对应的主osd数据节点。
  • 主osd数据节点同时写入另外两个副本节点数据。
  • 等待主节点以及另外两个副本节点写完数据状态。
  • 主节点及副本节点写入状态都成功后，返回给client，io写入完成。

  新主IO流程图

avatar

说明：如果新加入的OSD1取代了原有的 OSD4成为 Primary OSD, 由于 OSD1 上未创建 PG , 不存在数据，那么 PG 上的 I/O 无法进行，怎样工作的呢？

新主IO流程步骤：

  • client连接monitor获取集群map信息。
  • 同时新主osd1由于没有pg数据会主动上报monitor告知让osd2临时接替为主。
  • 临时主osd2会把数据全量同步给osd1。
  • client IO读写直接连接临时主osd2进行读写。
  • osd2收到读写io，同时写入另外两副本节点。
  • 等待osd2以及另外两副本写入成功。
  • osd2三份数据都写入成功返回给client, 此时client io读写完毕。
  • 如果osd1数据同步完毕，临时主osd2会交出主角色。
  • osd1成为主节点，osd2变成副本。

4.6 Ceph Pool和PG分布情况

  pool：是ceph存储数据时的逻辑分区，它起到namespace的作用。每个pool包含一定数量(可配置) 的PG。PG里的对象被映射到不同的Object上。pool是分布到整个集群的。 pool可以做故障隔离域，根据不同的用户场景不统一进行隔离。

avatar