Ceph 笔记(二)

本篇文章主要简述了 Ceph 的存储对象名词解释及其含义，以及对 Ceph 集群内 CRUSH bucket 调整、PG/PGP 参数调整等设置；同时参考了一些书籍资料简单的概述一下 Ceph 集群硬件要求等

1、Ceph 组件及定义

1.一、对象

对象是 Ceph 中最小的存储单元，对象是一个数据和一个元数据绑定的总体；元数据中存放了具体数据的相关属性描述信息等；Ceph 为每一个对象生成一个集群内惟一的对象标识符，以保证对象在集群内的惟一性；在传统文件系统的存储中，单个文件的大小是有必定限制的，而 Ceph 中对象随着其元数据区增大能够变得很是巨大

1.二、CRUSH

在传统的文件存储系统中，数据的元数据占据着极其重要的位置，每次系统中新增数据时，元数据首先被更新，而后才是实际的数据被写入；在较小的存储系统中(GB/TB)，这种将元数据存储在某个固定的存储节点或者磁盘阵列中的作法还能够知足需求；当数据量增大到 PB/ZB 级别时，元数据查找性能将会成为一个很大的瓶颈；同时元数据的统一存放还可能形成单点故障，即当元数据丢失后，实际数据将没法被找回；与传统文件存储系统不一样的是，Ceph 使用可扩展散列下的受控复制(Controlled Replication Under Scalable Hashing,CRUSH)算法来精确地计算数据应该被写入哪里/从哪里读取；CRUSH按需计算元数据，而不是存储元数据，从而解决了传统文件存储系统的瓶颈

1.三、CRUSH 查找

在 Ceph 中，元数据的计算和负载是分布式的，而且只有在须要时才会执行；元数据的计算过程称之为 CRUSH 查找，不一样于其余分布式文件系统，Ceph 的 CRUSH 查找是由客户端使用本身的资源来完成的，从而去除了中心查找带来的性能以及单点故障问题；CRUSH 查找时，客户端先经过 monitor 获取集群 map 副本，而后从 map 副本中获取集群配置信息；而后经过对象信息、池ID等生成对象；接着经过对象和 PG 数散列后获得 Ceph 池中最终存放该对象的 PG；最终在经过 CRUSH 算法肯定该 PG 所需存储的 OSD 位置，一旦肯定了 OSD 位置，那么客户端将直接与 OSD 通信完成数据读取与写入，这直接去除了中间环节，保证了性能的极大提高

1.四、CRUSH 层级结构

在 Ceph 中，CRUSH 是彻底支持各类基础设施和用户自定义的；CRUSH 设备列表中预先定义了一系列的设备，包括磁盘、节点、机架、行、开关、电源电路、房间、数据中心等等；这些组件称之为故障区(CRUSH bucket)，用户能够经过本身的配置把不一样的 OSD 分布在不一样区域；此后 Ceph 存储数据时根据 CRUSH bucket 结构，将会保证每份数据都会在所定义的物理组件之间彻底隔离；好比咱们定义了多个机架上的不一样 OSD，那么 Ceph 存储时就会智能的将数据副本分散到多个机架之上，防止某个机架上机器所有跪了之后数据所有丢失的状况

1.五、恢复和再平衡

当故障区内任何组件出现故障时，Ceph 都会将其标记为 down 和 out 状态；而后默认状况下 Ceph 会等待 300秒以后进行数据恢复和再平衡，这个值能够经过在配置文件中的 mon osd down out interval 参数来调整

1.六、PG

PG 是一组对象集合体，根据 Ceph 的复制级别，每一个PG 中的数据会被复制到多个 OSD 上，以保证其高可用状态

1.七、Ceph 池

Ceph 池是一个存储对象的逻辑分区，每个池中都包含若干个 PG，进而实现将必定对象映射到集群内不一样 OSD 中，池能够以复制方式或者纠错码方式建立，但不可同时使用这两种方式

2、Ceph 组件调整及操做

2.一、池操做

# 建立池rados mkpool test-pool# 列出池rados lspools# 复制池rados cppool test-pool cp-pool# 删除池rados rmpool test-pool test-pool --yes-i-really-really-mean-it

2.二、对象操做

# 将对象加入到池内rados put testfile anaconda-ks.cfg -p test# 列出池内对象rados ls -p test# 检查对象信息ceph osd map test testfile# 删除对象rados rm testfile -p test

2.三、修改 PG 和 PGP

计算 PG 数为 Ceph 企业级存储必不可少的的一部分，其中集群内 PG 计算公式以下

PG 总数 = (OSD 数 * 100) / 最大副本数

对于单个池来说，咱们还应该为池设定 PG 数，其中池的 PG 数计算公式以下

PG 总数 = (OSD 数 * 100) / 最大副本数 / 池数

PGP 是为了实现定位而设计的 PG，PGP 的值应该与 PG 数量保持一致；当池的 pg_num 增长的时候，池内全部 PG 都会一分为二，可是他们仍然保持着之前 OSD 的映射关系；当增长 pgp_num 的时候，Ceph 集群才会将 PG 进行 OSD 迁移，而后开始再平衡过程

获取现有 PG 和 PGP 值能够经过以下命令

ceph osd pool get test pg_num
ceph osd pool get test pgp_num

当计算好 PG 和 PGP 之后能够经过如下命令设置

ceph osd pool set test pgp_num 32
ceph osd pool set test pgp_num 32

一样在建立 pool 的时候也能够同步指定

ceph osd pool create POOLNAME PG PGP

2.四、pool 副本数调整

默认状况，当建立一个新的 pool 时，向 pool 内存储的数据只会有 2 个副本，查看 pool 副本数能够经过以下命令

ceph osd dump | grep pool

当咱们须要修改默认副本数以使其知足高可靠性需求时，能够经过以下命令完成

ceph osd pool set POOLNAME size NUM

2.五、定制机群布局

上面已经讲述了 CRUSH bucket 的概念，经过如下相关命令，咱们能够定制本身的集群布局，以使 Ceph 完成数据的容灾处理

# 查看现有集群布局ceph osd tree# 添加机架ceph osd crush add-bucket rack01 rack
ceph osd crush add-bucket rack02 rack
ceph osd crush add-bucket rack03 rack# 移动主机到不一样的机架(dockerX 为个人主机名)ceph osd crush move docker1 rack=rack01
ceph osd crush move docker2 rack=rack02
ceph osd crush move docker3 rack=rack03# 移动每一个机架到默认的根下ceph osd crush move rack01 root=default
ceph osd crush move rack02 root=default
ceph osd crush move rack03 root=default

最终集群总体布局以下

  ~ ceph osd tree
ID WEIGHT  TYPE NAME            UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1 0.01469 root default
-5 0.00490     rack rack01
-2 0.00490         host docker1
 0 0.00490             osd.0         up  1.00000          1.00000
-6 0.00490     rack rack02
-3 0.00490         host docker2
 1 0.00490             osd.1         up  1.00000          1.00000
-7 0.00490     rack rack03
-4 0.00490         host docker3
 2 0.00490             osd.2         up  1.00000          1.00000

3、Ceph 硬件配置

硬件规划通常是一个企业级存储的必要工做，如下简述了 Ceph 的通常硬件需求

3.一、监控需求

Ceph monitor 经过维护整个集群的 map 从而完成集群的健康处理；可是 monitor 并不参与实际的数据存储，因此实际上 monitor 节点 CPU 占用、内存占用都比较少；通常单核 CPU 加几个 G 的内存便可知足需求；虽然 monitor 节点不参与实际存储工做，可是 monitor 的网卡至少应该是冗余的，由于一旦网络出现故障则集群健康会难以保证

3.二、OSD 需求

OSD 做为 Ceph 集群的主要存储设施，其会占用必定的 CPU 和内存资源；通常推荐作法是每一个节点的每块硬盘做为一个 OSD；同时 OSD 还须要写入日志，因此应当为 OSD 集成日志留有充足的空间；在出现故障时，OSD 需求的资源可能会更多，因此 OSD 节点根据实际状况(每一个 OSD 会有一个线程)应该分配更多的 CPU 和内存；固态硬盘也会增长 OSD 存取速度和恢复速度

3.三、MDS 需求

MDS 服务专门为 CephFS 存储元数据，因此相对于 monitor 和 OSD 节点，这个 MDS 节点的 CPU 需求会大得多，同时内存占用也是海量的，因此 MDS 通常会使用一个强劲的物理机单独搭建

转载请注明出处，本文采用 CC4.0 协议受权

本文转自: https://mritd.me/2017/05/30/ceph-note-2/