Cloud基础设施 - 初识Ceph

初识Ceph

Ceph 是一个开源分布式存储系统系统，它不是一种单一的存储，而是面向云提供一种统一存储平台，包含块存储 RBD, 文件存储 CephFS, 以及对象存储 RGW，这种存储的出现允许用户拜托供应商的绑定，它可以提供块存储到 “云平台”，也可以提供对象存储到 “应用”，并支持理论上的无限扩展性，数千客户端访问 PB 甚至 EB 级别的数据

SAN VS Ceph

与传统 SAN 存储相比，Ceph 客户端会计算他们所需的数据所在的位置，这消除了存储系统中需要在“中心化查找”的瓶颈。 这使得 Ceph 集群可以在不损失性能的情况下进行扩展。

Ceph 集群架构组成

Ceph 集群核心是 RADOS，而基于 RADOS，构建出多种类型存储，块存储, 文件系统, 对象存储，而一个基础的 Ceph 集群的组件由 “Ceph monitor” 与 “Ceph OSD Daemon” 组成

• Ceph Monitor（进程名称为 ceph-mon，下文中以 ceph-mon 代表 Ceph Monitor） 维护集群映射的主副本。 ceph集群中的monitor，可确保 ceph-mon 守护进程在失败时的高可用性。客户端从 ceph-mon 检索集群映射的副本。
• Ceph OSD Daemon 检查”自身“及”其他“ OSD 的状态并报告给 Monitor。

Ceph 中的常见术语

Application

用于使用 Ceph 集群的任何 Ceph 外部的应用程序

Block Device

也称为 “RADOS 块设备” 或 ”RBD“ ，协调基于块的数据存储的工具，Ceph块设备拆分基于块的应用程序数据 成“块”。 RADOS 将这些块存储为对象。 Ceph 块 设备协调这些对象的存储 存储集群。

也称为 “RADOS Block Device” 或 “RBD”。一种用于协调 Ceph 中基于块的数据的存储的软件。 Ceph 块设备将基于块的应用程序数据拆分为 “Chunk”。 RADOS 将这些块存储为对象。

Chunk 与 Block 是两种不同的概念

• Chunk 存储是类似于 Key-Value 存储和对象存储，是一种结构化数据，并固定大小的块

• Block 通常被提到的上下文是作为硬件接口提供的，通常代表硬件裸设备

所以说 Block Device 是将数据划分为固定大小的 Chunk，存储在 Block 上。

MGR (Manager)

Ceph Manager 又称为 Ceph Manager Daemon，进程名称为 ceph-mgr, 是与 Ceph Monitoring 一起运行的守护进程，用于提供监视以及与外部监视和管理系统的接口。自 Luminous 版本 (12) 起，ceph-mgr 没有运行的情况下 Ceph 集群无法正常运行。

MON (Monitor)

Ceph Monitor 维护集群状态影视的守护进程，这些“集群状态”包括 Monitor map、Manager map、OSD map 和 CRUSH map。 Ceph 集群必须至少包含三个正在运行的 Monitor，才能实现冗余和高可用性。

OSD

Ceph Object Storage Daemon，又被称为 OSD, 在 “research and industry” 中 OSD 表示 ”对象存储设备“，而 Ceph 社区将 OSD 称为 OSD daemon，用于与逻辑磁盘交互的进程。

OSD fsid

用于标识 OSD 的唯一标识符。它可以在 OSD 路径中名为 osd_fsid 的文件中找到。术语 “fsid” 与 “uuid” 互换使用

OSD id

定义 OSD 的 integer，它是在创建每个 OSD 期间由监视器生成的。

Hybrid OSD

指同时拥有 HDD 和 SSD 的 OSD

Cluster Map

由 monitor map、OSD Map、PG Map、MDS Map 和 CRUSH Map 组成的一组 Map，它们共同报告 Ceph 集群的状态。有关详细信息。

CRUSH

CRUSH Controlled Replication Under Scalable Hashing 可扩展散列下的受控复制，Ceph 用于计算对象存储位置的算法。

DAS

DAS Direct-Attached Storage 直接附加存储，无需访问网络直接连接计算机的存储。例如 SSD

LVM tags

Logical Volume Manager tags 逻辑卷管理器标签，LVM “卷” 和 “组” 的可扩展元数据。它们用于存储有关设备及其与 OSD 关系的 Ceph 特定信息。

PGs (Placement Groups)

“放置组” 是每个逻辑 Ceph Pool 的子集。放置组执行将对象（作为一个组）放置到 OSD 中的功能。 Ceph 在内部以“放置组粒度”来管理数据：这比管理单个RADOS 对象的扩展性将更好。具有较大数量放置组的集群比具有较少数量放置组的其他相同集群具有更好的平衡性。

Pools

池是用于存储对象的逻辑分区。

RADOS

Reliable Autonomic Distributed Object Store 可靠的自动分布对象存储，RADOS 是为可变大小的对象提供可扩展服务的对象存储。 RADOS 对象存储是 Ceph 集群的核心组件。

Block Storage

块存储是 Ceph支持的三种存储类型之一。 Ceph 块存储指的是块存储 结合使用时的相关服务和功能 集合

Ceph File System

Ceph File System (CephFS) 是一个兼容 POSIX 的文件系统，构建在 RADOS 之上，可根据按需部署

MDS (Metadata Server)

Ceph MetaData Server daemon MDS，构建在 RADOS 之上，存储所有文件的元数据作为”文件系统“类型的存储提供给用户，运行的程序名为 ceph-mds，故 也是是否使用 CephFS 的标记

RGW (Radow Gateway)

Ceph 提供兼容 Amazon S3 RESTful API 和 OpenStack Swift API 的组件，可根据按需部署

Realm

是位于对象存储中的上下文，领域 (Realm) 是一个全局唯一的命名空间，由一个或多个区域组组成。

Zone

是位于对象存储中的上下文，区域 (zone) 是由一个或多个 RGW 实例组成的逻辑组。“zone” 的配置状态存储在 "" 中

Period

是位于对象存储中的上下文，Period 是 Realm 的配置状态。该 Period 存储多站点配置的配置状态。当 Period 被更新时，“epoch” 被认为已经改变。

CephX

CephX Ceph authentication protocol；CephX 是用于对用户和守护进程进行身份验证。 CephX 的运行方式类似于 Kerberos，但它没有单点故障。

Secrets

Secret 是用户访问是需要提供的身份验证的系统用于执行数字身份验证的凭据。

存储上下文中的锁定是您能够与硬件连接的最小尺寸。每当您从磁盘读取或写入磁盘时，无论需要读取多少个块，您都会读取此数量的次数。默认 NTFS 块大小（也称为簇大小、分配单元）为 4096 字节 (4KB)。如果您有一个正好 4096 字节长的文件，那么您将从磁盘读取一个块。如果是 4097 字节，那么您会读取两个块。您无法读取部分块，因此即使文件实际上没有消耗整个块，存储文件系统也会清空该块的其余部分。查看实际情况的一个简单方法是在硬盘驱动器上创建一个空白文本文件，查看属性以及“大小”（0 字节）和“磁盘大小”（4096 字节）之间的差异。

Ceph是一个对象（object）式存储系统，它把每一个待管理的 在（例如一个文件）切分为一到多个固定大小的（ceph底层管理机制）对象数据，在Ceph之上，每一个对象，是一个基础的原子管理单元（不可再切分的单元），并以其为原子单元完成数据存取

• 对象数据的底层存储服务是由多个主机（host）组成的存储集群，该集群也就称之为RADOS（Reliable Automatic Distributed Object Store）存储集群，即可靠、自动化、分布式对象存储系统。
• librados是RADOS存储集群的API，它支持C、C++、Java、Python、Ruby和PHP等编程语言。

存储设备

• DAS 直接附加存储：IDE、SATA、SCSI、SAS、USB
• NAS 网络附加存储（文件系统级别）：NFS、CIFS
• SAN 存储区域网络，与NAS不同的是，SAN提供的接口是块级别的接口。多数使用SCSI FC SAN ISCSI（internet SCSI）

数据是由元数据和内容（数据组成）组成，而元数据是确保路由的。传统文件系统ext有inode信息存储在元数据区，一部分空间存元数据，一部分空间存数据。数据称为数据块 data block。 当客户端试图访问某个文件时，根据给定文件路径或文件名层层查找，查询inode表。inode中记录的有在数据块空间中那些编号块存放当前文件数据。

元数据找到关联数据的存储路由表，也记录了当前文件的属性信息、如权限、属组等。这是一个标准的POSIX文件系统所应该具有的基本兼容的属性。

如将数据分散到多个节点上去存储时，就不能按照传统的机制在一个分区上组织元数据和数据，我们只能讲数据和元数据分开存放。每一个节点只提供存储空间，元数据存放在固定节点。

在存数据时，客户端将请求按照指定大小规模，每一块当做一个独立的文件，然后进行路由和调度，从而完成分散存储的目的。从而利用多个节点的网络和磁盘IO的存储能力。当用户访问时，需要联系元数据服务器，由元数据服务器返回相关数据 信息后从并行从这些节点上加载到数据块，而后根据元数据给出逻辑，由客户端组合起来，就可得到完整数据。

元数据和数据服务器分离在不通额主机之上，还要完成服务器的角色划分。在传统以Google为代表的设计体系结构当中，存放元数据的服务器被称之为名称服务器（NameNode）。存放数据的服务器被称为DataNode。

文件系统的元数据是一类非常密集、但IO量非常小的数据。因此为了高性能、高效通常需要存储在内存当中。为此需要一种机制同步存储在磁盘上，当文件被修改元数据也会被修改。大量的修改操作都是随机的。随机IO通常会非常慢。为了能够高效的使非常密集的文件元数据的修改操作能够快速高效的存在磁盘上，一般不会直接修改元数据的。而是将修改操作的操作请求记录下来。

将随机IO转成顺序IO能够快速同步磁盘进行持久保存。此方法缺点在宕机恢复时，只能通过回放记录在文件中的指令才能将数据还原回来。故其速度很慢。

因此将所有数据的持久存储都存放在第三方存储服务上，

对于数据存储级别的高可用思路

• 节点级冗余
• 数据级冗余 对每一个块 做副本
• 分片级冗余 primary shard replica shard

HDFS Hadoop FileSystem

对象存储

每一文件对象，在存储文件时，每一个对象自身大小不固定，是按照文件自身大小来存储的。不区分数据与元数据。每一个数据流自带数据和元数据。数据和数据流是存放在一起的。因此，每一个数据流就叫一个数据对象。数据是直接存放在磁盘之上的，而不在区分数据和元数据。每一对象都有自己自我管理的格式。

Ceph在存数据时，为了避免有一个元数据中心服务器成为整个系统的瓶颈所在，采用了计算方式来解决问题。在存储文件时，对文件做Hash计算映射到对应节点上去。Ceph没有中心节点，没有元数据服务器，任何对象存取都是通过实时计算得到的

从根本上来讲，Ceph在底层是RADOS的存储集群，由多个节点组成。其存储服务只是API叫做librados，Ceph在接口之上提供了几个抽象接口以便可以在传统意义上使用存储服务的逻辑实现存储功能。除用户自己在librados之上还开发了3个接口

• cephfs
• RDB 将Ceph所提供的存储空间模拟成一个个块设备使用的，每个块设备成为一个image，相当于磁盘。块接口，相当于传统硬盘
• RADOSGW 更抽象的，能跨互联网使用的对象存储。与Ceph内部对象不一样。Ceph内部的对象是固定大小的存储块，通常只在Ceph集群中使用，基于RPC协议工作。基于互联网的云存储，是基于resetful风格的接口提供的文件存储。每一个文件是一个对象，文件大小各不相同。

crush

Ceph内部通过计算方式完成对象路由的计算综合性算法。

Ceph存储集群组成

Ceph存储集群，一般可归置为几个组件组成

osd object stroage device 对象存储设备

    每个主机上有多个osd，每一个osd通常是指==单独的磁盘设备==。osd是真正存放数据的地方。如果使用files会是一个目录。对象存储设备而不是主机。多个主机组合起来称为RADOS Cluster（RADOS存储集群）

    为了使每个osd能够被单独使用和管理，每个osd都会有一个单独的专用的守护进程ceph-osd。osd本身用来存储数据，还包括数据复制、恢复、数据重新均衡、提供监视信息给mon和mgr

    一个集群至少有3个Ceph OSDs，已确保高可用。选择OSD冗余时，应自己指定故障率，故障转移率或故障容忍率。OSD级别故障就在OSD级别冗余，主机级别就跨主机冗余，故障率是机架级别就机架冗余。 在做crush运行图的设定时是应该自己指定的。

monitor 集群元数据服务器

    集群内除了存储节点之外，还有另外一种节点 monitor （monitor监视器），用来管理整个集群的，如有多少个节点，每个节点上有多少个OSD，每个OSD是否健康，他会持有整个集群的运行图（运行状态）。mon是用来集中维护集群元数据而非文件元数据。为了维护整个集群能够正常运行而设定的节点，离开此节点集群内部就无法协调。

    在一个主机上运行的守护进程 ceph-mon，守护进程扮演、监视着整个集群所有组件的角色，被称为集群运行图的持有者cluster map（整个集群有多少存储池，每个池中有多少PG，每个PG映射哪个OSD，有多少OSD等等）集群运行图 Cluster Map

    monitor负责维护整个进群的认证信息并实行认证，认证协议叫==CephX==协议（ceph内部的认证协议）。monitor用来维护认证信息并实行认证。认证中心 monitor自身是无状态的，所以实现均衡认证负载。

    monitor的高可用自己内部直接使用POSIX协议来实现数据冗余，monitor也是节点级冗余，为了确保各节点数据是强一致的，每个节点都可写，写完后会同步到其他节点。为了避免同时写导致的冲突，使用了分布式一致性协议，monitor就是使用POSIX协议来进行分布式协作的。

mgr manager

    monitor在每一次读数据都是实时查询的，故monitor不适用频繁周期性采集数据的监控操作。在Ceph新版中引入新组建mgr，（早期Ceph版本是没有mgr的）用来专门维护查询类操作，将查询操作按照自己内部空闲方式缓存下来，一旦有监控可及时响应。

    mgr是在一类节点上运行的守护进程，一般为两个活以上节点，此类守护进程被称为ceph-mgr。主要功能在于跟踪运行时的指标数据。如磁盘使用率、CPU使用率。以及集群当前状态，此状态不是内部运行状态，而是查询做监控时的状态。包括存储空间利用率、当前性能指标、节点负载（系统级）等

mds (非必要组件)

    ==Ceph Metadata Server== 用来代表ceph文件系统而提供的守护进程ceph-mds，如不使用CephFS，此进程是无需启动的。利用底层RADOS存储空间，将存储空间抽象成文件系统，来兼容POSIX file system 提供服务。

---

mgr ods mon才是一个完整的RADOS Cluster

---

管理节点 Admin Host

    Ceph通常是分布式集群，为了便于去管理维护整个集群，通常在Ceph集群中找一个专门的节点用来当管理节点。此节点可以连接至每一个节点用来管理节点上的Ceph守护进程。

    Ceph的场馆用管理接口是一句命令行工具程序，例如rados ceph rbd等命令，管理员可以从某个特定的MON节点执行管理操作，单也有人更倾向于使用专用的管理节点

    事实上，专用的管理节点有助于在Ceph相关的程序升级或硬件维护期间为管理员提供一个完整的、独立的并隔离于存储集群之外的操作系统，从而避免因重启意外中断而导致维护操作异常中断。

pool

    Ceph把他所提供的存储空间（没有目录之类一说）所有对象都是存储在数据平面上，因此，所有对象都不能同名。RADOS将他的存储空间切分为多个分区以便好进行管理。每一个分区叫做一个存储池。存储池的大小是取决于底层的存储空间的。与真正意义上的分区不是一回事。在Ceph中每一个存储池存放的数据了也可能会太大，所以存储池也可以进一步划分（可选）。被称为名称空间（先切分为存储池，每个存储池可进一步被划分成名称空间） 两级逻辑组件。

第三级 PG

每一个存储池内部会有多个PG（placement groups 规置组）存在。pool与pg都是抽象的概念。

object

对象是自带元数据的组件，

• 对象id，每一个对象应有一个对象ID在集群内部来引用对象
• 数据
• 元数据 key vlaue类型的数据

    这些类型打包成一起存储，被称为一个对象。RADOS集群会吧真正存储的每一个文件，切分成N个对象来进行存储的。（切分个数与默认对象切分大小有关）。

    每一个对象都是被单独管理的，都拥有自己的标识符。因此， 同一个文件的object有可能被映射到不同的PG上，PG提交给主机的，由主机负责将对象存储在磁盘（OSD）被存储在不同的OSD上。

文件存储到RADOS集群

一般要接入RADOS集群必须通过客户端来实现(LIBRADOS、RBD、CephFS、RADOSGW)，才能接入到集群中来。

当将文件存入Ceph中时，需要通过某一类客户端接入，客户端接入时，需要借助于Ceph存储API接口将其切分为固定大小的存储对象(Date object)，此数据对象究竟被放置在哪个OSD上存放这中间是靠crush来完成的。数据对象被存放在哪个存储池上是固定的。存储池需创建才可使用。但PG是虚拟的中间层。

PG作用

crush算法第一步

任何一个对象被存进RADOS集群中时，一定是向某一个存储池请求的。而后将对象的名字做一致性哈希计算（系列计算），计算完之后，通过顺时针找到落在最近PG。对象是归类在PG中的。每一个对象一定属于某个存储池内的某个PG（但PG不是真实存在的）。接下来还需将PG存到OSD上。

crush算法第二步

需将PG根据存储池的冗余副本数量和存储池的类型找到足量的OSD来存。是以PG为单位进行管理的，所以被称为主PG或活动PG和副本PG，一个PG中的所有对象是统一被管理的（存放在同一个OSD），如果要基于副本管理，写需写入主OSD，由主OSD同步到从OSD之上（同步过程是OSD自己内部管理）。但存储池和crush算法一定要能够确定出哪个是主的那些是从。一般来讲，传统的存储池是1主2从的存储。故其空间利用率是极低的。

Ceph也支持另外的存储池，纠删码存储池，类似于RAID5。存储数据时也会选出多个OSD来，多个OSD不是做副本方式存储，而是将数据切成多块之后每一个OSD上存一部分，另外一些OSD存放校验码，任何一个OSD坏了可以用校验码来计算出来。

故Ceph整体使用分为两部 将对象映射给PG，将PG映射给OSD 此过程是由crush算法来完成的。

最核心的组建RADOS Cluster以对象化的方式吧每一个文件切分成固定大小对象基于对象进行管理的。每一个对象要被基于crush算法实时计算之后映射到集群中某一个OSD之上。而每个集群上有多少个OSD，各个处于什么状态是由monitor负责维护和管理的，甚至监视器要维护整个集群的状态，如OSD、PG等等。故monitor是整个集群的元数据服务器。而不是文件元数据服务器。Ceph没有文件元数据服务器。所有数据访问都是通过实时计算路由的。因此整个集群可以无限制扩展

集群运行图

数据抽象接口（客户端中间层）

• Ceph存储集群提供了基础的对象数据存储服务，客户端可基于RADOS协议和librados API直接与存储系统交互进行对象数据存取
• Librados
  • Librados提供了访问RAD0OS在存储集群支持异步通信的API接口，支持对集群中对象数据的的直接并行访问，用户可通过支持的编程语言开发自定义客户端程序通过RADOS协议与存储系统进行交互
  • 客户端应用程序必须与librados绑定方可连接到RADOS存储集群，因此，用户必须实现安装librados及其依赖后才能编写使用librados的应用程序。
  • librados API本身使用C++编写的，它额外支持C、Python、Java、和PHP等开发接口
• 当然，并非所有用户都有能力自定义开发接口以接入RADOS存储集群的需要，为此，Ceph也原生提供了几个较高级别的各户端接口，它们分别是RADOS GateWay（RGW）、Reliable Block Device（RBD）和MDS（MetaData Server），分别为用户提供RESTful、块和POSIX文件系统接口。