ceph对象存储

1. ceph这款云存储技术怎么样

Ceph是一套高性能，易扩展的，无单点的分布式文件存储系统，基于Sage A. Weil的论文开发，主要提供以下三个存储服务：
对象存储(Object Storage)，既可以通过使用Ceph的库，利用C, C++, Java, Python, PHP代码，也可以通过Restful网关以对象的形式访问或存储数据，兼容亚马逊的S3和OpenStack的Swift。
块存储(Block Storage)，作为块设备像硬盘一样直接挂载。
文件系统(File System) ，如同网络文件系统一样挂载，兼容POSIX接口。

Ceph的结构，对象存储由LIBRADOS和RADOSGW提供，块存储由RBD提供，文件系统由CEPH FS提供，而RADOSGW, RBD, CEPH FS均需要调用LIBRADOS的接口，而最终都是以对象的形式存储于RADOS里。

Ceph集群的节点有三种角色：
Monitor，监控集群的健康状况，向客户端发送最新的CRUSH map(含有当前网络的拓扑结构)
OSD，维护节点上的对象，响应客户端请求，与其他OSD节点同步
MDS，提供文件的Metadata，如果不使用CephFS可以不安装
​

2. 【ceph】对象存储 - bucket命名规范

用于存储 日志文件的 存储桶的名称必须符合非美国标准区域的命名要求。Amazon S3 将存储桶名称定义为符合以下规则的一个或多个标签（用句点分隔开）：

警告
由于 S3 允许您的存储桶用作可公开访问的 URL，因此您选择的存储桶名称必须具有全局唯一性。如果其他一些账户已使用您选择的名称创建存储桶，则必须使用其他名称。有关更多信息，请参阅 Amazon Simple Storage Service 开发人员指南 中的存储桶局限和限制。

参考
https://docs.aws.amazon.com/zh_cn/awscloudtrail/latest/userguide/cloudtrail-s3-bucket-naming-requirements.html

3. Ceph RGW：数据的存储及寻址

RGW是一个对象处理网关。数据实际存储在ceph集群中。利用librados的接口，与ceph集群通信。RGW主要存储三类数据：元数据(metadata)、索引数据(bucket index)、数据(data)。这三类数据一般存储在不同的pool中，元数据也分多种元数据，存在不同的ceph pool中。

1、 Metadata
元数据信息包括：user，bucket，以及bucket.instance。其中：
user: 主要是对象存储的用户信息
bucket：主要维护bucket name与bucket instance id之间的映射信息
bucket.instance：维护了bucket instance信息

查看user的元数据如下：
radosgw-admin metadata list user:

radosgw-admin metadata get user:testid:

radosgw-admin metadata list bucket:

radosgw-admin metadata get bucket:first:

radosgw-admin metadata list bucket.instance:

radosgw-admin metadata get bucket.instance:first:{bucket_id}

2、Bucket Index
bucket index主要维护的是一个bucket中object的索引信息。一个bucket对应一个或多个rados object(开启bucket shards下)。维护的是一个key-val的map结构，map存放在object的omap(rocksdb)中，key对应的rgw object，val是关于rgw object的一些元数据信息，检索bucket的存放的object时，需要这些信息。omap也包含一个Header，其存放的是bucket account info，如此bucket中Object的个数，总的size等。
3、Data
rgw object内容，存放在一个或多个rados object中。rados object分为header和tail部分，header最多可以容纳512KB的数据，如果一个rgw object的大小小于512KB，那么只有header。否则剩余的数据会按照集群rados object的大小条带化分割成多个rados object。

在Pool： {zone}.rgw.meta利用namespace隔离多个存储空间：

对于Pool: {zone}.rgw.log也包含多个namespace:

当检索对象存储中的一个object时，会包含三个要素：user，bucket,object。user主要是RGW用于获取user id验证ACL；bucket及obejct用于确定object在pool中的位置。

User

user数据存储在 {zone}.rgw.meta:users.uid 中，如下：

包含两部分： ups3: user本身信息; ups3.buckets: 用户所属的bucket。

ups3： 用户的基本信息，及ACL/Bucekt Quota/User Quota等；对应struct RGWUserInfo， 定义于rgw_common.h。
ups3.buckets：用户所属的Buckets，key-value结构，存放于omap结构中；对应struct cls_user_bucket_entry，定义于rgw_common.h，数据操作如下：

通过{uid}.buckets查到用户具有哪些buckets，并且这些bucket以下基本数据。

Bucket

Bucket信息存在在 {zone}.rgw.meta:root 中，如下：

first： 记录了bucket与bucket_instance_id的对应关系，其对应于数据结构：struct RGWBucketEntryPoint
.bucket.meta.first:1c60b268-0a5d-4718-ad02-e4b5bce824bf.44166.4： bucket instance；寻址方式：.bucket.meta.{tenant}:{bucket.name}:{bucket_id}；对应结构体：struct RGWBucketInfo。
其中Bucket ACL及IAM Policy存放在bucket instance object的attr中。如下：

获取Bucket ACL及IAM Policy数据如下：

Object

Bucket Index： Bucket中包含的Object信息，都存放在一个或多个Object的 omap 中。此omap为一个key-value结构，key为object的名称，value对应 struct rgw_bucket_dir_entry : cls_rgw_types.h 。
Bucket Index Object：

如下：

在此bucket下，有一个object: ntp.conf:

检索value:

omap header记录了以下统计信息：

对象存储object的数据存放在pool: {zone}.rgw.buckets.data 中。object的构成及寻址分为以下两类：

一个RGW Object可以由一个或多个rados object构成。其中第一个 object 是此RGW 的 head 对象，主要包含一些元数据信息，如 manifest, ACLs, content type, ETag, and user-defined metadata 。这些metadata存放在此head 对象的xattr中。其中 manifest 描述了此rgw object在分布情况。同时，此head对象，最多可额外容纳 4MB 数据，如果RGW Object大小下于 4MB ，那么此 RGW Object就不会分片，只有此 head 对象。
如下检索：

目前bucket下有一个 ntp.conf ， <4MB 。检索其 manifest :

如上：
max_head_size： 表示head对象最大size；
head_size： 表示当前head 对象size；
prefix： 用于在rados中分片object的寻址。

RGW OBject ACL:

上传一个 >4MB 的 RGW Object，检索其 manifest 信息：

Manifest信息：

根据 manifest 检索对象：

对于一个大的RGW Object，会被切割成多个独立的RGW Object上传，称为multipart。multipar的优势是断点续传。s3接口默认切割大小为15MB。

在此，上传一个60MB大小的Object。

分成了四个部分上传，查看rados对象：

包含了三类对象， head，multipart，shadow 。

multipart 下的 manifest :

所有的object的检索是根据上述manifest信息构建object index:

在上以上的信息中，此RGW Object大小为48128000字节，分为4段，三段15MB，最后一段为920KB。同时每段存储在rados集群中的条带化大小为4MB。因此15MB大小的分段，也分为4个rados object，一个multipart首部，及3个shadow分片。920KB大小的分段只有一个multipart首部。

.rgw.root :

包含的都是zone,zonegroup,realm等信息

4. 可以把ceph作为对象存储，用于生产环境吗

Swift在小文件对象（如图像）存储上，性能很好。Ceph目前坑还是比较多，不是很稳定，如果没有研发能力，只是做对象存储，不建议在生产环境中用。国内生产环境最大的部署是京东，主要也是为了做块存储。

5. c ep h是一种什么形式的对象存储系统

ceph是一种形式的对象存储系统
一、意思不同
.h中一般放的是同名.c文件中定义的变量、数组、函数的声明，需要让.c外部使用的声明。
.c文件一般放的是变量、数组、函数的具体定义。
二、用法不同
.c文件，以c为扩展名，一般存储具体功能的实现。
.h文件，称为头文件，一般存储类型的定义，函数的声明等。通常，头文件被.c文件包含，使用#include语句。但值得注意的是，这只是一种约定，而非强制。

6. ceph（第一步） 基础架构

ceph 是什么？
ceph 是一种开源存储软件。底层实现了对象存储，并以此为基础对外提供对象存储接口、块存储接口、文件级存储接口。

ceph 结构包含两个部分：

ceph 版本：Nautilus

官网的一张架构图：

对于这张图，一开始没有看懂它想表达什么，后来明白了。如下图：

相关名词解释：

ceph 组件分为两部分：

此部分介绍构成 ceph 集群的基础组件。
其中包含 OSD、Manager、MDS、Monitor。

此部分介绍 ceph 对外提供各种功能的组件。
其中包含：Block Device、Object Storage、Filesystem。

前面两个部分主要介绍了 ceph 的一些组件及对外提供的功能。
这部分主要介绍 ceph 的存储逻辑。

首先，在对象存储中，一切都是扁平化的，并且存储的最小单元为对象（obj）。存储 obj 如下图：

ceph 在对象存储的基础上提供了更加高级的思想。

当对象数量达到了百万级以上，原生的对象存储在索引对象时消耗的性能非常大。ceph 因此引入了 placement group （pg）的概念。一个 pg 就是一组对象的集合。如下图：

obj 和 pg 之间的映射由 ceph client 计算得出。

讨论 pg 时，不得不提的另外一个名词：pgp。
pgp 决定了 pg 和 osd 之间的映射关系。一般将 pgp_num 设置成和 pg_num 一样大小。

这里还有一个名词需要提一下，在 ceph 中会经常见到 crush 算法。简单来说，crush 算法就是指 ceph 中数据如何存储、读取的过程。

由于 ceph 集群面对许多的独立项目，因此 ceph 还引入了 ceph pool 的概念用于划分不同的项目。
ceph pool 是对 ceph 对象的逻辑划分，并不是物理划分。

pg 和 ceph pool 的区别：

像大多数集群软件一样，ceph 也提供了缓存的概念。称之为 Cache Tier（缓存层，在具体使用时有时会称之为缓存池）。
缓存池对用户来说是透明的，因此不会改变用户的原有使用逻辑。以下缓存池的介绍，均为底层逻辑。
在没有缓存池时，ceph client 直接指向存储池。
在添加缓存池后，ceph client 指向缓存池，缓存池再指向存储池。

官方原话：
When pg_num is increased for any pool, every PG of this pool splits into half, but they all remain mapped to their parent OSD.
Until this time, Ceph does not start rebalancing. Now, when you increase the pgp_num value for the same pool, PGs start to migrate from the parent to some other OSD, and cluster rebalancing starts. This is how PGP plays an important role.
By Karan Singh
个人翻译：
当一个池增加 pg 数量时，这个池中的所有 pg 都会变化。但是原 pg 的实际物理存储位置不会改变。
当一个池增加 pgp 的数量时，pg 的实际物理存储位置会发生改变。

首先，截至目前，没有具体查到资料证明以下观点。（基于一致性hash的猜想）

图中出现了一个新词： vosd ，这个是指虚拟 osd。它的数量等于 pgp 的数量，而 pgp 一般又等于 pg。

pgp 的数量就是 vosd 的数量。

引入 pg 可以实现 pool 概念，以及优化碎片管理（这一点十分不确定）。

引入 pgp（vosd），是为了在增加 osd 时可以让数据更加均衡的分布。

如猜想图：
当我们增加池的 pg 数量时，不会改变 vosd，因此原 pg 与 vosd 之间的映射未变，原 pg 的实际物理位置也不会发生变化。只是会影响同一个池中 obj 的分布。
当我们增加池的 pgp 数量时，相当于改变了 vosd，通过 hash 计算出的部分 pg 与 vosd 之间的映射就要发生改变，从而导致 pg 的实际物理位置发生改变。

与一致性hash不同的地方：
一般情况下，一致性hash只有一层虚拟化层，并且虚拟化层是根据物理硬件而变化的。但是ceph却是一种反着来的意思。

当 ceph 增加一个 osd 时，pg 的物理位置也会发生改变。
在该猜想下：
当增加 osd 时，并不会增加 vosd 的数量，原部分 vosd 会映射到新的 osd 上，因此产生一种部分 pg 的实际物理位置发生变化的情况。

创建池时，会分配固定的 pg，以及设置与 pg 一样大小的 pgp。
注意，一般 pg 数量都设置为 2 的次方。

严格意义上，我们无论为池分配多少个 pg 都没有问题。但有时候 pg num 配置小了会报错，配置大了也会报错。这不是因为这么配置不对，是因为有其它的参数在限制我们随意配置 pg num。

比如：
osd 有两个配置，当每个 osd 的 pg num 过少（默认30）时会告警，当每个 osd 的 pg num 过多（默认300）也会告警。

所以，想要入门使用 ceph，还是需要了解许多基础知识才可以。否则，各种意外。

https://docs.ceph.com/docs/master/architecture/

https://ceph.com/pgcalc/

7. ceph原理 Ceph简单介绍

1、Ceph是一个可靠地、自动重均衡、自动恢复的分布式存储系统，根据场景划分可以将Ceph分为三大块，分别是对象存储、块设备存储和文件系统服务。在虚拟化领域里，比较常用到的是Ceph的块设备存储，比如在OpenStack项目里，Ceph的块设备存储可以对接OpenStack的cinder后端存储、Glance的镜像存储和虚拟机的数据存储，比较直观的是Ceph集群可以提供一个raw格式的块存储来作为虚拟机实例的硬盘。

2、Ceph相比其它存储的优势点在于它不单单是存储，同时还充分利用了存储节点上的计算能力，在存储每一个数据时，都会通过计算得出该数据存储的位置，尽量将数据分布均衡，同时由于Ceph的良好设计，采用了CRUSH算法、HASH环等方法，使得它不存在传统的单点故障的问题，且随着规模的扩大性能并不会受到影响。

8. 【ceph】对象存储的目录/文件夹概念

对象存储（OSS）中文件夹的概念仅是一个逻辑概念，在通过API/SDK的方式设置文件夹的时候可以指定object对应的key值包括前面的目录即可实现该功能。例如，定义object的key为abc/1.jpg就会在该bucket下创建一个abc的文件夹，而在文件夹下即会有一个1.jpg的文件。

对象存储（OSS）中的文件夹其实是一个大小为0KB的空文件。因此，用户创建一个key值为1/的object就会定义文件夹1；并且如果用户创建文件abc/1.jpg，系统是不会创建abc/这个文件的，因此在删除abc/1.jpg后将不会再存在abc这个文件夹。

由于对象存储（OSS）采用的是分布式存储的方式，object并不是根据文件夹进行物理存储的。也就是说并不是一个文件夹下的所有的文件都会存储在一起的。在后端存储的过程中不同的文件夹的文件仅仅是key值的前缀不一样。因此这种架构下就会导致无法很方便的统计某个文件夹下的汇总信息，如文件夹大小、文件夹PV数等。而想要遍历某个文件夹下的所有的文件也需要首先通过ListObject接口获取文件夹下的所有文件的key值（这里需要通过prefix指定文件夹），然后再进行操作。

在逻辑上“中国.mp4”将存放到目录“videos”中

https://help.aliyun.com/knowledge_detail/39527.html
https://www.jianshu.com/p/4212d37c0e0f

9. ceph 对象存储多站点同步user id 配置方案

最近在配置多站点的时候，想了好久， 有一个纠结的地方是：

由于在异地有两套或两套以上的集群，在配置多站点同步前，需要在主zone上创建一个 网关系统用户 用于同步，数据的读取都是依赖这个用户的权限。可是时间久了（或者说换了个管理员）， 我怎么找到当时配置多站点的时候用的是哪个网关用户呢？也就是用的这个同步的用户的用户id是多少呢，看官网文档的意思是，固定一个用户id 用做多站点同步，固定一个用户id就要求，这个固定的id 没有之前没有被占用，

突然想到一个办法是， 设置zone 的access key 的时候就等同于 system user id,这样每次查看zone的信息的时候就可以看到access key也就是可以看到用于同步的 system user id，

下面命令get zone info

radosgw-admin zone get

并且用户信息，zone信息是会在多个zone间同步的， 也就是你在异地的另一个集群也查看到指定的用于同步的网关用户信息。

当你要更换同步密钥的时候，更改该用户的密钥，然后在相继所有zone的key就可以了，当然也可以换用其他id的系统以后， 然后把该用户删掉就可以了。

此问题解决了如何在异地不同集群上找到用于同步的网关系统用户，不依赖于第三方的系统。

链接： 配置ceph多站点官方文档

10. Ceph 架构与原理

Ceph 是一个开源项目，它提供软件定义的、统一的存储解决方案 。Ceph 是一个具有高性能、高度可伸缩性、可大规模扩展并且无单点故障的分布式存储系统 。
Ceph 是软件定义存储解决方案
Ceph 是统一存储解决方案
Ceph 是云存储解决方案

高可用性

高扩展性

特性丰富

Ceph独一无二地统一的系统提供了对象存储、块存储和文件存储功能。Ceph存储集群由几个不同的软件守护进程组成（比较重要的两个是MON和OSD），每个守护进程负责Ceph的一个独特功能并将值添加到相应的组件中。

RADOS是CEPH存储系统的核心,也称为Ceph 存储集群。Ceph的数据访问方法(如RBD,CephFS,RADOSGW，librados)的所有操作都是在RADOS层之上构建的。当Ceph 集群接收到来自客户端的请求时,CRUSH算法首先计算出存储位置,最后将这些对象存储在OSD中,当配置的复制数大于1时,RADOS负责的形式将数据分发到集群内的所有节点,最后将这些对象存储在OSD中。当配置的复制数大于1时,RADOS负责数据的可靠性,它复制对象，创建副本并将它们存储在不同的故障区域中。
RADOS包含两个核心组件: OSD和MON

OSD 是Ceph 存储集群中最重要的一个基础组件，他负责将实际的数据以对象的形式存储在每一个集群节点的物理磁盘中。对于任何读写操作，客户端首先向MON请求集群MAP，然后客户端旧可以直接和OSD进行I/O操作。
一个Ceph 集群包含多个OSD。一个典型的Ceph集群方案会为集群节点上的每个物理磁盘创建一个ODS守护进程,这个是推荐的做法。OSD上的每个对象都有一个主副本和几个辅副本,辅副本分散在其他OSD。一个OSD对于一些对象是主副本，同时对于其他对象可能是辅副本，存放辅副本的OSD主副本OSD控制,如果主副本OSD异常(或者对应的磁盘故障),辅副本OSD可以成为主副本OSD。
OSD是有一个已经存在的Linux文件系统的物理磁盘驱动器和OSD服务组成。Ceph 推荐OSD使用的文件系统是XFS。OSD的所有写都是先存到日志,再到存储.

MON 负责监控整个集群的健康状况。它以守护进程的形式存在,一个MON为每一个组件维护一个独立的MAP,如OSD，MON,PG,CRUSH 和MDS map。这些map 统称为集群的MAP。MON 不为客户端存储和提供数据,它为客户端以及集群内其他节点提供更新集群MAP的服务。客户端和集群内其他节点定期与MON确认自己持有的是否是集群最新的MAP.一个Ceph集群通常包含多个MON节点,但是同一时间只有一个MON。

librados是一个本地的C语言库，通过它应用程序可以直接和RADOS通信，提高性能

Ceph 块存储，简称 RBD，是基于 librados 之上的块存储服务接口。RBD 的驱动程序已经被集成到 Linux 内核（2.6.39 或更高版本）中，也已经被 QEMU/KVM Hypervisor 支持，它们都能够无缝地访问 Ceph 块设备。Linux 内核 RBD（KRBD）通过 librados 映射 Ceph 块设备，然后 RADOS 将 Ceph 块设备的数据对象以分布式的方式存储在集群节点中

RGW，Ceph对象网关，也称做RADOS网关，它是一个代理，可以将HTTP请求转换为RADOS，也可以把RADOS转换为HTTP请求，从而提供restful接口，兼容S3和Swift。Ceph对象网关使用Ceph对象网关守护进程(RGW)与librgw、librados交互。Ceph对象网关支持三类接口：S3、Swift、管理API（通过restful接口管理Ceph集群）。RGW有自己的用户管理体系

Ceph 元数据服务器服务进程，简称 MDS。只有在启用了 Ceph 文件存储（CephFS）的集群中才需要启用 MDS，它负责跟踪文件层次结构，存储和管理 CephFS 的元数据。MDS 的元数据也是以 Obejct 的形式存储在 OSD 上。除此之外，MDS 提供了一个带智能缓存层的共享型连续文件系统，可以大大减少 OSD 读写操作频率。

CephFS在RADOS层之上提供了一个兼容POSIX的文件系统。它使用MDS作为守护进程，负责管理其元数据并将它和其他数据分开。CephFS使用cephfuse模块（FUSE）扩展其在用户空间文件系统方面的支持（就是将CephFS挂载到客户端机器上）。它还允许直接与应用程序交互，使用libcephfs库直接访问RADOS集群。

Ceph管理器软件，可以收集整个集群的所有状态。有仪表板插件

一个对象通常包含绑定在一起的数据和元数据，并且用一个全局唯一的标识符标识。这个唯一的标识符确保在整个存储集群中没有其他对象使用相同的对象ID，保证对象唯一性。基于文件的存储中，文件大小是有限制的，与此不同的是，对象的大小是可以随着大小可变的元数据而变得很大。对象不使用一个目录层次结构或树结构来存储，相反，它存储在一个包含数十亿对象且没有任何复杂性的线性地址空间中。对象可以存储在本地，也可以存放在地理上分开的线性地址空间中，也就是说，在一个连续的存储空间中。任何应用程序都可以基于对象ID通过调用restful API从对象中获取数据。这个URL可以以同样的方式工作在因特网上，一个对象ID作为一个唯一的指针指向对象。这些对象都以复制的方式存储在OSD中，因为能提供高可用性。

对于Ceph集群的一次读写操作，客户端首先联系MON获取一个集群map副本，然后使用对象和池名/ID将数据转换为对象。接着将对象和PG数一起经过散列来生成其在Ceph池中最终存放的那一个PG。然后前面计算好的PG经过CRUSH查找来确定存储或获取数据所需的主OSD的位置。得到准确的OSD ID之后，客户端直接联系这个OSD来存取数据。所有这些计算操作都由客户端来执行，因此它不会影响Ceph集群的性能。一旦数据被写入主OSD，主OSD所在节点将执行CRUSH查找辅助PG和OSD的位置来实现数据复制，进而实现高可用。
  简单地说，首先基于池ID将对象名和集群PG数应用散列函数得到一个PG ID，然后，针对这个PG ID执行CRUSH查找得到主OSD和辅助OSD，最后写入数据。

PG是一组对象地逻辑集合，通过复制它到不同的OSD上来提供存储系统的可靠性。根据Ceph池的复制级别，每个PG的数据会被复制并分发到Ceph集群的多个OSD上。可以将PG看成一个逻辑容器，这个容器包含多个对象，同时这个逻辑容器被映射到多个OSD。
  计算正确的PG数对一个Ceph存储集群来说是至关重要的一步。PG数计算公式如下

Ceph池是一个用来存储对象的逻辑分区，每个池都包含一定数量的PG，进而实现把一定数量的对象映射到集群内部不同OSD上的目的。每一个池都是交叉分布在集群所有节点上的，这样就能提供足够的弹性。池可以通过创建需要的副本数来保障数据的高可用性。
  Ceph的池还支持快照功能，我们可以使用ceph osd pool mksnap命令来给特定的池制作快照。此外，Ceph池还允许我们为对象设置所有者和访问权限。

数据管理始于客户端向Ceph池中写数据。一旦客户端准备写数据到Ceph池中，数据首先写入基于池副本数的主OSD中。主OSD再复制相同的数据到每个辅助OSD中，并等待它们确认写入完成。只要辅助OSD完成数据写入，就会发送一个应答信号给主OSD。最后主OSD再返回一个应答信号给客户端，以确认完成整个写入操作。