Ceph配置参数（一）

本篇博文转载于http://blog.csdn.net/uj_mosquito/article/details/41827373?utm_source=tuicool

1、POOL, PG AND CRUSH CONFIG REFERENCE
http://docs.ceph.com/docs/master/rados/configuration/pool-pg-config-ref/
所属配置段：【global】
格式：osd pool default pg num = 250
每个存储池最大pg数：mon max pool pg num

同一个OSD Daemon中创建PG所间隔的秒数：mon
pg create interval

等待多少秒PG可被认为被卡主：mon pg stuck
threshold

Ceph OSD Daemon对PG的标志位位数：osd pg bits

Ceph OSD Daemon对PGP的标志位位数：osd pgp bits

注：pg和pgp大部分情况是一样的，但是一个pg分裂成多个时就不一样了
CRUSH规则用到chooseleaf时的bucket的类型：osd crush chooseleaf type

创建复制存储池时用到的CRUSH规则：osd pool default crush replicated ruleset

纠删码池中对象被分割成的条带大小：osd pool erasure code stripe width

副本数：osd pool default size

最小副本数：osd pool default min size

注：如果这个数目没达到，ceph不会通知客户端写以完成
pg数：osd pool default pg num

pgp数：osd pool default pgp num

新创建的存储池的flag：osd pool default flags

列表中最大的PG数：osd max pgls

修建PGLog是保留的最小PGLog数：osd min pg log entries

OSD等待客户端相应一个请求的最大秒数：osd default data pool replay window

2、JOURNAL CONFIG REFERENCE
http://docs.ceph.com/docs/master/rados/configuration/journal-ref/
Journal的作用：
（1）速度：随机小块的写操作就直接写入journal，合并成顺序IO再下刷，建议用SSD存放
（2）一致性：为保证操作的事务性，先将操作记录在journal中再应用到文件系统。每隔一段时间， Ceph OSD Daemon停止写操作，将journal和文件系统同步，删除一部分journal使得空间能够被再次利用。故障时， Ceph
OSD Daemon从最近的一次同步后的journal的开头按照其内容重新做一次操作。
开启直写Journal（大概是因为journal一般都是存储在块设备上，即在OSD的空间或SSD单独存储）：journal dio

开启异步写journal（“直写”设为true这个参数才能设）：journal aio

块对齐（这个参数设为true上面两个参数才能设）：journal block align

一次写journal的最大byte数：journal max write bytes

最多一次能并行写多少个journal：journal max write entries

任意时刻队列中存储的最大操作数：journal queue max ops

任意时刻队列中存储的最大byte数（10 << 20，即（2^10）<<20=10MB）：journal queue max bytes

最小对齐大小：journal align min size

在创建文件系统期间用0填充整个日志：journal zero on create

3、MESSAGING
http://docs.ceph.com/docs/master/rados/configuration/ms-ref/
消息传递的TCP会话中禁用nagle算法：ms tcp nodelay

错误重连的初始等待时间：ms initial backoff

错误重连的最大等待时间：ms max backoff

禁用crc校验（在CPU有限的情况下能都提升性能）：ms nocrc

debug设置（不配置）：ms die on bad msg

等待派遣的最大消息数：ms dispatch throttle bytes

将进程绑定为IPV6的IP：ms bind ipv6

堆栈大小的debug设置（不配置）：ms rwthread stack bytes

等待多少秒关闭空闲连接：ms tcp read timeout

debug设置（不配置）：ms inject socket failures

4、GENERAL CONFIG REFERENCE
http://docs.ceph.com/docs/master/rados/configuration/general-config-ref/
文件系统ＩＤ，一个集群一个：fsid

执行管理命令的socket路径（/var/run/ceph/$cluster-$name.asok）：admin socket

mom,osd,mds写PID的文件（/var/run/$cluster/$type.$id.pid ）：pid file

守护进程运行的路径：chdir

最大可以打开的文件数量（防止文件描述符被用光）：max open files

可以用信号（通信啥的……）：fatal signal handlers

5、FILESTORE CONFIG REFERENCE
http://docs.ceph.com/docs/master/rados/configuration/filestore-config-ref/
开启同步时的调试检查（开销大）：filestore debug omap check

（1）扩展属性（重要）
扩
展属性就是在文件系统（XFS、ext4等）固有属性之外的属性，以下的参数是配置如何存储这些参数的，这对系统性能很重要。有些文件系统对属性的长度有
限制，比如ext4限制属性长度不超过4KB，如果没有长度限制，ceph的扩展属性也是存储在底层文件系统中的，如果超过了长度限制，则是存主一个
key/value数据库中（aka
omap）。
使用数据库存储扩展属性（ext4必须这么做）：filestore xattr use omap

最大的扩展属性长度（不能超过文件规定的长度）：filestore max inline xattr size

每一个对象在文件系统中最多可以存储的扩展属性数量：filestore max inline xattrs

（2）同步间隔
减小同步频率可以多合并一点写操作和元数据更新。
最大同步间隔秒数：filestore max sync interval

最小同步间隔秒数：filestore min sync interval

（3）下刷
filestore flusher使得大文件写scyn前会先排序以求顺序下刷提高性能（事实证明关掉更好，默认也是关掉的）。
开启filestore flusher：filestore flusher

flusher的最大文件描述符数量：filestore flusher max fds

开启同步flusher：filestore sync flush

文件系统同步时下刷journal数据：filestore fsync flushes journal data

（4）文件系统队列 （filestore queue）
队列上可以存储的最大操作数：filestore queue max ops

队列上可以存储的最大btye数：filestore queue max bytes

一次最大可以提交的操作数：filestore queue committing max ops

一次最大可以提交的byte数：filestore queue committing max bytes

（5）超时
并行线程数：filestore op threads

文件操作线程超时秒数：filestore op thread timeout

提交一个操作多少秒都可以取消：filestore op thread suicide timeout

（6）B-TREE FILESYSTEM
开启btrfs的快照：filestore btrfs snap

开启btrfs的克隆：filestore btrfs clone range

（7）日志
开启并行日志：filestore journal parallel

开启预写式日志：filestore journal writeahead

（8）MISC
前一个子类目录中的文件合并到父类的最小数量：filestore merge threshold

前一个子目录分裂成子目录中的文件的最大数量：filestore split multiple

限制文件存储自动升级到指定的版本：filestore update to

丢弃任何讨论中的事务：filestore blackhole

存储事务转储目的文件：filestore dump file

在第 N 次机会后注入一个失效：filestore kill at

在 eio错误的时候失败或崩溃：filestore fail eio