ceph 学习笔记

简述

1、架构哲学

所有组件可扩展不存在单点故障解决方案是软件定义，开源可适配运行于通用硬件之上尽可能自我管理

2、CRUSH算法

controlled replication under scalable hashing在后台计算数据存储和读取的位置基础设施感知，CRUSH以多副本的方式保存数据，以保证在失效区域中有些组件失效的情况下数据依旧可用

3、块存储

数据被以块的形式存储在卷里，卷会被挂接到节点上rbd协议（ceph块设备）：     RBD块被带状分布在多个Ceph对象之上，而这些对象本身又是分布在整个Ceph存储集群中；    RBD支持全内存式缓存，大大提高其性能；    支持最大的image的大小为16EB，这些image可以被映射成磁盘给物理裸机、虚拟机或其它主机使用    完全支持云平台;在openstack中，可通过cinder（块）和glance（image）组件来使用ceph块设备，这样可使用其copy-on-write特性在很短的时间内创建上千个VM

4、文件系统：

CephFS，一个兼容POSIX的文件系统Ceph文件系统库（libcephfs）运行在RADOS库（librados）之上，要使用CephFS，集群节点上最少要配置一个Ceph元数据服务器（MDS）

5、对象存储

Ceph是通过其object gateway，即RADOS gateway（radosgw）提供对象存储接口。RADOS gateway利用librgw（RADOS gateway library）和librados这些库，允许应用程序跟Ceph对象存储建立连接    RADOS gateway提供RESTful接口让用户的应用程序存储数据到Ceph存储集群中。RADOS gateway接口是：         • Swift compatibility Swift 兼容: This is an object storage functionality for the OpenStack Swift API         • Swift 兼容: 这是为OpenStack Swift API提供的对象存储功能。         • S3 compatibility S3兼容: This is an object storage functionality for the Amazon S3 API         • S3兼容: 这是为Amazon S3 API提供的对象存储功能。         • Admin API: This is also known as the management API or native API, which can be used directly in the application to gain access to the storage system for management purposes         • Admin API: 这也被称为管理API或者native API，应用程序可以直接使用它来获取访问存储系统的权限以管理存储系统。

内容整理

RADOS：是ceph存储集群的基础

为保证数据的一致性，RADOS在集群节点上执行数据复制、失败检测、数据恢复、数据迁移和再平衡

当执行写操作到ceph集群，数据会被以对象的形式存储在ceph OSD （ceph集群中唯一存储实际用户数据的组件）上

一般，一个osd 守护进程对应集群中的一个物理硬盘

MON：通过与集群状态（OSD、MON、PG、CRUSH映射）保持映射，监测整个集群的健康。

所有集群节点向mon节点汇报并共享（节点状态变化的）信息mon 不存储实际数据

librados库: librados API 支持直接接入RADOS，并且可以建自己的接口（接入ceph存储集群）

提供一个本地接口接入 ceph存储集群、RADOS、其他服务的基础（RBD、RGW、POSIX）

RBD：提供块存储，一个可以映射、格式化、挂载；和服务器的硬盘类似的设备。

RGW：（RADOS gateway），提供RESTful API接口，

MDS：追踪文件结构，仅为CephFS存储元数据

RBD和RADOS gateway 不需要元数据。

cephFS： 提供POSIX-compliant、任何大小的分布式文件系统。

需要依赖MDS

ceph RADOS

Reliable Autonomic Distributed Object Store

RADOS以对象的方式存储数据到池中，查看RODOS的池： rados lspools

查看池中对象清单： rados -p medadata ls

查看集群的利用情况： rados df

RADOS有2个核心组件：OSD 和MON

OSD

ceph集群中大部分的工作是由 ceph OSD 守护程序完成的

在OSD中，每个对象都有一个主副本和几个次副本，分散在所有其他osd中

每一个OSD都是一些对象的主OSD，其他对象的次OSD；次OSD受控于主OSD当一个硬盘失效，ceph OSD 守护程序明智地参考其他 OSD 进行恢复操作；在此期间，包含失效对象的次OSD会被提升为主OSD，同时生成新的次副本。这些操作对于客户端是透明的。

ceph OSD 文件系统

ceph osd 由 物理硬盘驱动、Linux 文件系统 和 ceph osd 服务组成

Linux 文件系统支持 XATTRs ，XATTRs 提供内部数据（对象状态、快照、元数据、ACL等）给ceph OSD 守护程序，有助于数据管理

ceph osd 日志

在提交数据到后备存储之前，ceph首先写数据到一个被称为日志的缓冲区大小的隔离的存储区

基于这一原理，ceph 写所有数据都是首先写到日志，然后在到后备存储区（文件系统、物理硬盘）

osd commands

查看单个节点上的 osd 状态：

service ceph status osd

查看所有节点的osd状态： (在配置文件ceph.conf中必须有所有osd及其主机名的信息)

service ceph -a status osd

验证osd ID： ceph osd ls

查看osd 映射和状态： ceph osd stat

查看osd tree: ceph osd tree

ceph MON

集群映射包括MON、OSD、PG、CRUSH、MDS 映射等

MON 映射：

一个mon 节点的端对端信息：包括ceph集群ID，MON主机名和IP地址端口;映射建立时间和最近一次变化信息查看mon map： `ceph mon dump`

OSD map:

集群ID，osd map 建立时间和最近一次变化；和池相关的信息：池的名称、ID，类型，复制水平，和PG，osd信息：数量，状态，权重，last clean interval ，osd主机信息查看：`ceph osd dump`

PG map:

in-placement group version, 时间戳，最近osd map 时间，full ratio, near full ratio， 追踪每个PG的 ID，对象数，状态，状态戳，up and acting OSD sets,scrub details查看：`ceph pg dump`

CRUSH map:

集群存储设备，失效域层次结构，存储时针对失效域定义的规则查看： `ceph osd crush dump`

MDS map：

现在MDS map 时间，映射建立及修改时间，数据和元数据池的ID，集群MDS数量和状态查看： `ceph mds dump`

MON commands

service  ceph status monceph mon statceph mon_statusceph mon dump

librados

librados 是一个本地C库，提供很多API支持。通过librados库可以直接与RADOS 集群直接交互

ceph object gateway

即RADOS gateway；把HTTP请求转变为RADOS请求 ，反之亦然

ceph 内在

一个对象典型的有数据和元数据2个组件，它们绑定在一起，并提供一个全局唯一的标识符。

列出ceph集群所有资源池的名称： rados lspools

列出metadata池中系统生成的对象名称： rados -p metadata ls

CRUSH

Controlled Replication Under Scalable Hashing 算法

可以准确算出数据应该被写入到哪里或从哪里读取。

crush强制集群中所有磁盘参与；并为每个osd分配权重，权重越高，表示其物理存储容量越大。

当新主机或磁盘添加到ceph集群中，crush开始执行再平衡（rebalancing）操作；建议新加入的osd的权重设为0，再逐渐增加权重，避免加重集群再平衡的负载及其性能下降。

crush 管理着pgs在整个集群内部的再定位

PG

pg 是一组对象的逻辑集合

建议每个osd上放置50-100个pg

pg数计算

PG总数=（osd总数*100）/最大复制数

PG总数=（osd总数*100）/最大复制数/pool数

每个pool 里面的pg 数一旦配置完成，只能增不能减，

pool 配置 pg 数参考：    少于5个osd：pg_num=128    5和10之间：pg_num=512    10和50之间：pg_num=4096    大于50：pg_num 权衡，计算

osd daemon依赖Extended Attributes (XATTRs)存储内部对象状态和元数据

内外网配置

外网：

public network = {public-netwaor/netmask}

内网：

cluster network = {cluster-network/netmask}

如果有内网，osds 的 heartbeat ,object replication ,recovery traffic 将会选择在内网

ceph客户端首先会链接ceph monitor， 复制一份cluster map 和 CRUSH algorithm ，然后在本地就可以计算每一个object的位置。 ——ceph的高效性，可扩展性

Heartbeat 默认配置

各 OSD 每 6 秒会与其他 OSD 进行心跳检查,用[osd]下的osd heartbeat interval 可更改此间隔、或运行时更改。如果一个 OSD 20 秒都没有心跳,集群就认为它 down 了,用[osd]下的osd heartbeat grace 可更改宽限期、或者运行时更改。

默认情况下,一个 OSD 必须向监视器报告三次另一个 OSD down 的消息,监视器才会认为那个被报告的 OSDdown 了;配置文件里[mon]段下的 mon osd min down reports 选项(v0.62 之前是 osd min down reports)可更改这个最少 osd down 消息次数,或者运行时设置。默认情况下,只要有一个 OSD 报告另一个 OSD 挂的消息即可,配置文件里[mon]段下的 mon osd min down reporters 可用来更改必需 OSD 数(v0.62 之前的 osd min downreporters),或者运行时更改。

mon osd down out interval = 1800（在osd停止响应多少秒后把它标记为down，默认300），手动停止一个osd，等待了1802秒后，ceph开始迁移数据。

如果一 OSD 至少 120 秒没向监视器报告过,监视器就认为它 down 了,你可以设置[osd]下的osd mon reportinterval max来更改此报告间隔,或者运行时更改。

OSD 每 30 秒会报告它自己的状态,在[osd]段下设置osd mon report interval min可更改 OSD 报告间隔,或运行时更改

OSD 默认配置

可以在配置文件里配置 OSD,但它可以用默认值和最小化配置。最简 OSD 配置需设置 osd journal size 和osd host,其他几乎都能用默认值

除了为对象保存多个副本外,ceph 还靠洗刷归置组来保证数据完整性。这种洗刷类似对象存储层的 fsck,对每个归置组,ceph 生成一个所有对象的目录,并比对每个主对象及其副本以确保没有对象丢失或错配。轻微
洗刷(每天)检查对象尺寸和属性,深层洗刷(每周)会读出数据并用校验和保证数据完整性。

osd op threads=4osd disk threads=2

当增加或移除 OSD 时,CRUSH 算法将要求重新均衡集群,它会把一些归置组移出或移入多个 OSD 以回到均衡状态。归置组和对象的迁移过程会明显降低集群运营性能,为维持运营性能,ceph 用 backfilling 来执行此迁移,它可以使得 ceph 的回填操作优先级低于用户读写请求。（通过优先级来区分读写请求，这个做法很好！）

如果某 OSD 崩溃并重生,通常和其他 OSD 不同步,没有同归置组内最新版本的对象。这时,OSD 进入恢复模式并且搜索最新数据副本,并更新运行图。根据 OSD 挂的时间长短,OSD 的对象和归置组可能明显过期,另外,如果一个失效域挂了(如一个机柜),多个 OSD 会同时重生,这样恢复时间更长、更耗资源。

ceph 扩展属性用底层文件系统(如果没有尺寸限制)的 XATTR 存储为 inline xattr。

本文出自“he ivy”的博客，转载请务必保留此出处：http://blog.csdn.net/heivy/article/details/50560684