Ⅰ 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/
Ⅱ 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等信息
Ⅲ 云计算分布式存储是用ceph还是hadoop
云计算的开发需要多种语言共同参与，HADOOP在云计算产品中只是一个底层框架，适合做云盘、分布式计算等底层业务。很少有一种云产品只用一种开发语言解决所有问题的，袜缓语言只是工具，关键是要学会在不同的应用场景下，如何正确选择合适的工具。云产品的框架有很多，比如OpenStack是用Python写的，Hadoop是用Java写的。
Ceph架构简介及其特点
Ceph简介
Ceph是一个统一的分布式存储系统，设计初衷是提供较好的性能、可靠性和可扩展性。
Ceph项目最早起源于Sage就读博士期间的工作（最早的成果于2004年发表），并随后贡献给开源社区。在经过了数年的发展之后，目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack都可与Ceph整合以支持虚拟机镜像的后端存储。
Ceph特点
高性能
a.摒弃了传统的集中式存储元数据寻址的方案，采用CRUSH算法，数据分布均衡，并行度高。
b.考虑茄好祥了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。
c.能够支持上千个存储节点的规模，支持TB到PB级的数据。
高可用性
a.副本数可以灵活控制颤搏。
b.支持故障域分隔，数据强一致性。
c.多种故障场景自动进行修复自愈。
d.没有单点故障，自动管理。
高可扩展性
a.去中心化。
b.扩展灵活。
c.随着节点增加而线性增长。
特性丰富
a.支持三种存储接口：块存储、文件存储、对象存储。
b.支持自定义接口，支持多种语言驱动。
Hadoop简介及其特点
Hadoop是一个由Apache基金会所开发的分布式系统基础架构。用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。Hadoop实现了一个分布式文件系统（HadoopDistributedFileSystem），简称HDFS。
HDFS有高容错性的特点，并且设计用来部署在低廉的（low-cost）硬件上；而且它提供高吞吐量（highthroughput）来访问应用程序的数据，适合那些有着超大数据集（largedataset）的应用程序。HDFS放宽了（relax）POSIX的要求，可以以流的形式访问（streamingaccess）文件系统中的数据。Hadoop的框架最核心的设计就是：HDFS和MapRece。HDFS为海量的数据提供了存储，而MapRece则为海量的数据提供了计算。
云计算的开发语言多样
hadoop和云计算是两回事，HADOOP开发首选JAVA，次选C/C++或者Python云计算就复杂了，不同的应用又不同额选择。很少有一种云产品只用一种开发语言解决所有问题的语言只是工具，关键是要学会在不同的应用场景下，如何正确选择合适的工具。云产品的框架有很多，比如OpenStack是用Python写的，Hadoop是用Java写的。
HADOOP在云计算产品中只是一个底层框架，适合做云盘、分布式计算等底层业务。中间层和上层用什么语言开发取决产品的特性和技术人员的技术特点。
Ⅳ Ceph之Cephfs存储
CephFS 是一个支持POSFIX 接口的文件系统,它使用Ceph 存储集群来存储数据。文件系统对于客户端来说可以方便的挂载至本地使用。CephFS 构建在RADOS之上,继承RADOS的容错性和扩展性,支持荣誉副本和数据高可靠性。
Ceph 文件系统要求 Ceph 存储集群内至少有一个 Ceph 元数据服务器
1、为元数据存斗咐储池设置较空察纯高的副本水平，因为此存储池丢失任何数据都会导致整个文件系统失效。
2、为元数据存没燃储池分配低延时存储器（像 SSD ），因为它会直接影响到客户端的操作延时。
默认设置为文件系统创建两个存储池
Ceph监视器为: 10.65.3.76
Ⅳ 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再返回一个应答信号给客户端，以确认完成整个写入操作。
Ⅵ Ceph之块存储
块是一个字节序列（例如，一个 512 字节的数据块）。基于块的存储接口是最常见的存储数据方法，它们基于旋转介质，像硬盘、 CD 、软盘、甚至传统的 9 磁道磁带。无处不在的块设备接口使虚拟块设备成为与 Ceph 这样的海量存储系统交互的理想之选。
Ceph 块设备是精简配置的、大小可调且将数据条带化存储到集群内的多个 OSD 。 Ceph 块设备利用 RADOS 的多种能力，如快照、复制和一致性。睁尘余 Ceph 的 RADOS 块设备（ RBD ）使用内核模块或 librbd 库与 OSD 交互。
Ceph 块设备靠无限伸缩性提供了高性能，如向兄棚内核模块、或向 abbr:KVM (kernel virtual machines) （如 Qemu 、 OpenStack 和 CloudStack 等云计算系统通过 libvirt 和 Qemu 可与 Ceph 块设备集成）。你可以用同一个集群同时运行 Ceph RADOS 网关、 Ceph FS 文件系统、和 Ceph 块设备。
默认 image 的特性包括：
作为 rbd 一般只需要 layering ，需要把其他的特性全部禁止掉。
克隆独悉滚立存在，不依赖于快照，就需要对克隆和快照做一个合并
参考:
Blog: https://www.cnblogs.com/hukey/p/13283351.html