Ceph学习笔记

Ceph是一个高性能、可扩容的分布式存储系统，它提供三大功能：

1. 对象存储：提供RESTful接口，也提供多种编程语言绑定。兼容S3、Swift
2. 块存储：由RBD提供，可以直接作为磁盘挂载，内置了容灾机制
3. 文件系统：提供POSIX兼容的网络文件系统CephFS，专注于高性能、大容量存储

Ceph集群由一系列节点（机器）组成，在这些节点上运行以下组件：

1. Ceph OSDs：OSD即对象存储守护程序，但是它并非针对对象存储。OSD负责存储数据、处理数据复制、恢复、回填（Backfilling）、再平衡。此外OSD还对其它OSD进行心跳检测，检测结果汇报给Monitor
2. Monitors：监视器，维护集群状态的多种映射，同时提供认证和日志记录服务
3. MDSs：元数据服务器，存储CephFS的元数据信息

Ceph将客户端的数据作为对象存储在它的存储池中，基于CRUSH算法，Ceph计算出每个对象应该位于那个PG，计算哪个OSD负责存储PG

术语	说明
RADOS	可靠的、自动化的分布式对象存储（Reliable, Autonomic Distributed Object Store）是Ceph的核心之一 librados是RADOS提供的库，上层的RBD、RGW和CephFS都是通过librados访问RADOS的
RGW	即RADOS Gateway，指Ceph的对象存储API或者RGW守护进程
RBD	即RADOS Block Device，指Ceph提供的基于复制性的分布式的块设备。类似于LVM中的逻辑卷，RBD只能属于一个Pool
MDS	即Ceph元数据服务器，是CephFS服务依赖的元数据服务
CephFS	Ceph File System，是Ceph对外提供的文件系统服务
Pool	存储池是Ceph中一些对象的逻辑分组。它不是一个连续的分区，而是一个逻辑概念，类似LVM中的卷组（Volume Group） 存储池分为两个类型： Replicated 复制型，对象具有多份拷贝，确保部分OSD丢失时数据不丢失，需要更多的磁盘空间。复制份数可以动态调整，可以置为1 Erasure-coded 纠错码型，节约空间，但是速度慢，不支持所有对象操作（例如局部写）
PG	归置组（Placement Group），PG是Pool组织对象的方式，便于更好的分配数据和定位数据，Pool由若干PG组成 PG 的数量会影响Ceph集群的行为和数据的持久性。集群扩容后可以增大PG数量：5个以下OSD设置为128即可 PG的特点：同一个PG中所有的对象，在相同一组OSDs上被复制。复制型Pool中PG可以有一个作为主（Primary）OSD，其它作为从OSD。一个对象仅仅属于一个PG，也就是说对象存储在固定的一组OSDs上 PG在OSD的/var/lib/ceph/osd/ceph-2/current目录下，表现为目录
CRUSH	CRUSH即基于可扩容哈希的受控复制（Controlled Replication Under Scalable Hashing），是一种数据分发算法，类似于哈希和一致性哈希。哈希的问题在于数据增长时不能动态添加Bucket，一致性哈希的问题在于添加Bucket时数据迁移量比较大，其他数据分发算法依赖中心的Metadata服务器来存储元数据因而效率较低，CRUSH则是通过计算、接受多维参数的来解决动态数据分发的场景 CRUSH算法接受的参数包括： Cluster map，也就是硬盘分布的逻辑位置，例如这有多少个机房、多少个机柜、硬盘是如何分布的等等。Cluster map是类似树的结构，子节点是真正存储数据的device，每个device都有id和权重，中间节点是bucket，bucket有多种类型用于不同的查询算法，例如一个机柜一个机架一个机房就是bucket Placement rules，它指定了一份数据有多少备份，数据的分布有什么限制条件（例如同一份数据不能放在同一个机柜里）。每个Rule对应一系列操作： take，选取一个bucket select，选择n个类型为t的项 emit，提交 CRUSH与一致性哈希最大的区别在于接受的参数多了Cluster map和Placement rules，这样就可以根据目前Cluster的状态动态调整数据位置，同时通过算法得到一致的结果 基于此算法，Ceph存储集群能够动态的扩容、再平衡、恢复
Object	Ceph最底层的存储单元是Object，每个Object包含元数据和原始数据 一个RBD会包含很多个Object
OSD	对象存储守护进程（Object Storage Daemon），负责响应客户端请求返回具体数据的进程。Ceph集群中有大量OSD 一个节点上通常只运行一个OSD守护进程，此守护进程在一个存储驱动器上只运行一个 filestore
EC	Erasure Code（EC），即纠删码，是一种前向错误纠正技术（Forward Error Correction，FEC），主要应用在网络传输中避免包的丢失， 存储系统利用它来提高可靠性。相比多副本复制而言， 纠删码能够以更小的数据冗余度获得更高数据可靠性， 但编码方式较复杂，需要大量计算 。纠删码只能容忍数据丢失，无法容忍数据篡改，纠删码正是得名与此 EC将n份原始数据，增加m份数据，并能通过n+m份中的任意n份数据，还原为原始数据。即如果有任意小于等于m份的数据失效，仍然能通过剩下的数据还原出来 纠删码技术在分布式存储系统中的应用主要有三类： 阵列纠删码（Array Code: RAID5、RAID6等）：RAID是EC的特例，RAID5只支持一个盘失效，RAID6支持两个盘失效，而EC支持多个盘失效 RS(Reed-Solomon)里德-所罗门类纠删码 LDPC(LowDensity Parity Check Code)低密度奇偶校验纠删码：目前主要用于通信、视频和音频编码等领域，与RS编码相比，LDPC编码效率要略低，但编码和解码性能要优于RS码以及其他的纠删码

监视器维护集群状态的多种映射—— 包monmap、OSD map、PG map、CRUSH map、MDS map，同时提供认证和日志记录服务。Ceph会记录Monitor、OSD、PG的每次状态变更历史（此历史称作epoch）。客户端连到单个监视器并获取当前映射就能确定所有监视器、 OSD 和元数据服务器的位置。依赖于CRUSH算法和当前集群状态映射，客户端就能计算出任何对象的位置，直连OSD读写数据。

Ceph客户端、其它守护进程通过配置文件发现mon，但是mon之间的相互发现却依赖于monmap的本地副本。所有mon会基于分布式一致性算法Paxos，确保各自本地的monmap是一致的，当新增一个mon后，所有现有mon的monmap都自动更新为最新版本。

使用多个mon时，每个mon都会检查其它mon是否具有更新的集群状态映射版本 —— 存在一个或多个epoch大于当前mon的最高epoch。太过落后的mon可能会离开quorum，同步后再加入quorum。执行同步时，mon分为三类角色：

1. Leader：具有最新版本状态映射的mon
2. Provider：同上，但是它的最新状态是从Leader同步获得
3. Requester：落后于Leader，必须获取最新集群状态映射才能重回quorum

如果mon的时钟不同步，可能会导致：

1. 守护进程忽略收到的消息（时间戳过时）
2. 消息未及时收到时，超时触发得太快或太晚

OSD使用日志的原因有两个：

1. 速度： 日志使得 OSD 可以快速地提交小块数据的写入， Ceph 把小片、随机 IO 依次写入日志，这样，后端文件系统就有可能归并写入动作，并最终提升并发承载力。因此，使用 OSD 日志能展现出优秀的突发写性能，实际上数据还没有写入 OSD ，因为文件系统把它们捕捉到了日志
2. 一致性：OSD需要一个能保证原子化复合操作的文件系统接口。 OSD 把一个操作的描述写入日志，并把操作应用到文件系统。这确保了对象（例如归置组元数据）的原子更新。每隔一段时间（由filestore max sync interval 和 filestore min sync interval控制 ）， OSD 会停止写入，把日志同步到文件系统，这样允许 OSD 修整日志里的操作并重用空间。若失败， OSD 从上个同步点开始重放日志。日志的原子性表现在，它不使用操作系统的文件缓存（基于内存），避免断电丢数据的问题

注意：OSD进程在往数据盘上刷日志数据的过程中，是停止写操作的。 

通常使用独立SSD来存储日志，原因是：

1. 避免针对单块磁盘的双重写入 —— 先写日志，再写filestore
2. SSD性能好，可以降低延迟提升IOPS

	IN	OUT
UP	正常状态，OSD位于集群中，且接收数据	OSD虽然在运行，但是被踢出集群 —— CRUSH不会再分配归置组给它
DOWN	这种状态不正常，集群处于非健康状态	正常状态

在Luminous中，Bluestore已经代替Filestore作为默认的存储引擎。Bluestore直接管理裸设备，不使用OS提供的文件系统接口，因此它不会收到OS缓存影响。

使用Bluestore时，你不需要配备SSD作为独立的日志存储，Bluestore不存在双重写入问题，它直接把数据落盘到块上，然后在RockDB中更新元数据（指定数据块的位置）。

一个基于Bluestore的OSD最多可以利用到三块磁盘，例如下面的最优化性能组合：

1. 使用HDD作为数据盘
2. 使用SSD作为RockDB元数据盘
3. 使用NVRAM作为RockDB WAL

一些概念：

1. Acting Set：牵涉到PG副本的OSD集合
2. Up Set：指Acting Set中排除掉Down掉的OSD的子集

Ceph依赖于Up Set来处理客户端请求。如果 Up Set 和 Acting Set 不一致，这可能表明集群内部在重均衡或者有潜在问题。

写入数据前，归置组必须处于 active 、而且应该是 clean 状态。假设一存储池的归置组有 3 个副本，为让 Ceph 确定归置组的当前状态，一归置组的主 OSD （即 acting set 内的第一个 OSD ）会与第二和第三 OSD 建立连接，并就归置组的当前状态达成一致意见。

由于以下原因，集群状态可能显示为HEALTH WARN：

1. 刚刚创建了一个存储池，归置组还没互联好
2. 归置组正在恢复
3. 刚刚增加或删除了一个 OSD
4. 刚刚修改了 CRUSH 图，并且归置组正在迁移
5. 某一归置组的副本间的数据不一致
6. Ceph 正在洗刷一个归置组的副本
7. Ceph 没有足够空余容量来完成回填操作

这些情况下，集群会自行恢复，并返回 HEALTH OK 状态，归置组全部变为active+clean。

状态	说明
Creating	在你创建存储池时，Ceph会创建指定数量的PG，对应此状态 创建PG完毕后，Acting Set中的OSD将进行互联，互联完毕后，PG变为Active+Clean状态，PG可以接受数据写入
Peering	Acting Set中的OSD正在进行互联，它们需要就PG中对象、元数据的状态达成一致。互联完成后，所有OSD达成一致意见，但是不代表所有副本的内容都是最新的
Active	互联完成后归置组状态会变为Active
Clean	主OSD和副本OSD已成功互联，并且没有偏离的归置组。 Ceph 已把归置组中的对象复制了规定次数
Degraded	当客户端向主 OSD 写入数据时，由主 OSD 负责把数据副本写入其余副本 OSD 。主 OSD 把对象写入存储器后，在副本 OSD 创建完对象副本并报告给主 OSD 之前，主 OSD 会一直停留在 degraded 状态 如果OSD挂了， Ceph 会把分配到此 OSD 的归置组都标记为 degraded。只要它归置组仍然处于active 状态，客户端仍可以degraded归置组写入新对象 如果OSD挂了（down）长期（ mon osd down out interval ，默认300秒）不恢复，Ceph会将其标记为out，并将其上的PG重新映射到其它OSD
Recovering	当挂掉的OSD重启（up）后，其内的PG中的对象副本可能是落后的，副本更新期间OSD处于此状态
Backfilling	新 OSD 加入集群时， CRUSH 会把现有集群内的部分归置组重分配给它。强制新 OSD 立即接受重分配的归置组会使之过载，用归置组回填可使这个过程在后台开始 回填执行期间，你可能看到以下状态之一： backfill_wait，等待时机，回填尚未开始 backfill_too_full，需要进行回填，但是因存储空间不足而不能完成
Remapped	负责某个PG的Acting Set发生变更时，数据需要从久集合迁移到新集合。此期间老的主OSD仍然需要提供服务，直到数据迁移完成
Stale	默认情况下，OSD每0.5秒会一次报告其归置组、出流量、引导和失败统计状态，此频率高于心跳 如果： 归置组的主 OSD 所在的 Acting Set 没能向MON报告 或者其它MON已经报告，说主 OSD 已 down了 则MONs就会把此归置组标记为 stale 集群运行期间，出现此状态，所有PG的主OSD挂了
Inactive	归置组不能处理读写请求，因为它们在等着一个持有最新数据的 OSD 回到 up 状态
Unclean	归置组里有些对象的副本数未达到期望次数，它们应该在恢复中
Down	归置组的权威副本OSD宕机，必须等待其开机，或者被标记为lost才能继续

CRUSH 算法通过计算数据存储位置来确定如何存储和检索。 CRUSH授权Ceph 客户端直接连接 OSD ，而非通过一个中央服务器或代理。数据存储、检索算法的使用，使 Ceph 避免了单点故障、性能瓶颈、和伸缩的物理限制。

CRUSH 需要一张集群的 Map，利用该Map中的信息，将数据伪随机地、尽量平均地分布到整个集群的 OSD 里。此Map中包含：

1. OSD 列表
2. 把设备汇聚为物理位置的“桶”（Bucket，也叫失败域，Failure Domain）列表
3. 指示 CRUSH 如何复制存储池中的数据的规则列表

通过CRUSH map来建模存储设备的物理位置，Ceph能够避免潜在的关联性故障 —— 例如一个机柜中的设备可能共享电源、网络供应，它们更加可能因为断电而同时出现故障，Ceph会刻意的避免把数据副本放在同一机柜。

新部署的OSD自动被放置到CRUSH map中，位于一个host节点（OSD所在主机名）。在默认的CRUSH失败域（Failure Domain） 设置中，副本/EC分片会自动分配在不同的host节点上，避免单主机的单点故障。在大型集群中，管理员需要更加仔细的考虑失败域设置，将副本分散到不同的Rack、Row。

OSD在CRUSH map中的位置，称为CRUSH location。此Location以如下形式来描述：

你可以在Ceph配置文件中，用crush location选项来声明。每当OSD启动时，它会验证当前CRUSH map是否匹配crush location设置，如果不匹配会更新CRUSH map。设置下面的选项可以禁用此行为：

CRUSH map是一个树状的层次结构，它是对存储设备物理位置松散的建模。 

在这个层次结构中，叶子节点是Device，对应了OSD守护程序（通常管理一块或几块磁盘）。设备的以name.id来识别，通常是osd.N。设备可以关联一个设备类别（Device Class），取值例如hdd、ssd，CRUSH rule可以使用到设备类别。

除了叶子节点之外的，都称为桶（Bucket），每个桶都具有类型，默认支持的类型包括root,regin, datacenter, room, row, pod, pdu, rack, chassis, host。大部分集群仅仅使用一部分类型的桶。

每个节点都具有一个权重（Weight）字段，指示子树负责存储的数据的比例。权重应该仅仅在叶子节点上设置，由Ceph自动向上类加。权重的单位通常是TB。

执行命令 ceph osd crush tree可以查看CRUSH的层次，包括节点权重。

CRUSH rule定义了数据如何跨越设备分布的规则。大部分情况下你可以通过命令行来创建CRUSH rule，少数情况下需要手工便捷CRUSH map。

随着Ceph的发展，CRUSH算法被不断的优化。Ceph允许你自由选择新或旧的算法变体，这依赖Tunable实现。

要使用新的Tunable，客户端、服务器必须同时支持。Tunable的命名就是最初支持对应算法变体的那个Ceph版本的名称（例如jewel）。

用户空间的Ceph块设备实现（librbd）不能使用Linux的页面缓存，因此它自己实现了一套基于内存的LRU缓存——RBD Cacheing。

此缓存的行为类似于页面缓存，当OS发送屏障/Flush请求时，内存中的脏数据被刷出到OSD。

这是一个POSIX兼容的文件系统，它使用Ceph的存储集群来保存数据。

一个Ceph集群可以有0-N个CephFS文件系统，每个CephFS具有可读名称和一个集群文件系统ID（FSCID）。每个CephFS可以指定多个处于standby状态的MDS进程。 

每个CephFS包含若干Rank，默认是1个。Rank可以看作是元数据分片。CephFS的每个守护进程（ceph-mds）默认情况下无Rank启动，Mon会自动为其分配Rank。每个守护进程最多持有一个Rank。

如果Rank没有关联到ceph-mds，则其状态为failed，否则其状态为up。

每个ceph-mds都有一个关联的名称，典型情况下设置为所在的节点的主机名。每当ceph-mds启动时，会获得一个GID，在进程生命周期中，它都使用此GID。

如果MDS进程超过 mds_beacon_grace seconds没有和MON联系，则它被标记为laggy。

Ceph对象存储网关是基于librados构建的一套RESTful服务，提供对Ceph存储集群的访问。此服务提供两套接口：

1. S3兼容接口：Amazon S3的子集
2. Swift兼容接口： OpenStack Swift的子集

这两套接口可以混合使用。

对象存储网关由守护程序radosgw负责，它作为客户端和Ceph存储集群之间的媒介。radosgw具有自己的用户管理系统。

从firefly版本开始，对象存储网关在Civetweb上运行，Civetweb内嵌在ceph-radosw这个Daemon中。在老版本中，对象网关基于Apache+FastCGI。

Ceph仪表盘是一个内置的、基于Web的管理/监控工具。通过它你能够管理集群中各种资源。仪表盘作为Ceph Manager的模块实现。

包含一系列集群编排有关的命令。

列出对编排器可见的服务：

列出对编排器可见的守护进程，守护进程是服务的实例：

设置某种组件（服务/守护进程）的数量或者归置规则，格式：

下面是一些简单的例子：

管理守护进程。

add子命令，添加一个守护进程：

redeploy子命令，重新部署某个守护进程，可以指定使用的镜像：

如果节点上的守护进程容器被意外删除，也就是 podman ps看不到对应容器，可以使用redeploy命令重新部署。

rm子命令，删除某个守护进程：

你也可以启动、停止、重启、重新配置某个守护进程：

如果需要启动、停止、重启、重新配置某种服务的所有守护进程：

管理块设备。

显示某些主机上的块设备：

清除块设备上的内容：

管理主机。

添加主机，可选的，添加标签：

为主机添加/移除标签：

列出主机：

检查是否可以在不损害可用性的前提下，停止主机：

删除主机：

修改主机地址：

删除OSD实例：

检查删除OSD操作的进度：

暂停编排器的后台任务

恢复暂停的编排器后台任务

选择编排器后端： ceph orch set backend <module_name>

显示使用的编排器后端，以及它的状态：

cephadm就是一个编排器后端，下文会有介绍。

升级相关操作：

查看日志：

Cephadm是最新的Ceph部署工具，他利用容器和Systemd，仅仅支持Octopus或者更新的版本。

Cephadm的外部依赖包括容器运行时（Docker或者Podman），以及Python3。

安装支持cephadm命令及其依赖：

上述命令会安装一个单MON节点的Ceph集群。改命令会：

1. 创建MON和MGR守护进程到本机
2. 为Ceph集群生成SSH密钥，并添加到roo用户的/root/.ssh/authorized_keys
3. 生成最小化配置的 /etc/ceph/ceph.conf，用于和新集群通信
4. 生成Ceph管理密钥 /etc/ceph/ceph.client.admin.keyring
5. 复制公钥副本到/etc/ceph/ceph.pub

这样你就可以直接使用ceph命令了：

你需要提前为节点安装好Python3

列出现有节点：

orch子命令用于Ceph集群相关的编排。

将集群的公钥安装到新节点的authorized_keys：

添加节点，注意要提供主机名：

使用下面的命令，可以将集群主机所有空闲设备作为OSD：

将特定主机的特定磁盘作为OSD：

NFS Ganesha是一个用户模式的NFS，支持v3  4.0 4.1 4.2，可以同时运行这些协议。

使用下面的命令来部署NFS Ganesha网关。

 

ceph-deploy是一个ceph部署工具，服务器只需要提供SSH、sudo、一些Python包即可完成ceph的安装部署。

准备好服务器集群后，选取一台作为管理主机，在其上执行：

为了防止时钟不同步导致问题，建议安装NTP客户端，并保持和NTP服务器的同步。

在集群中的管理主机上，执行：

执行下面的命令，部署初始mon节点，并收集key：

以ceph-deploy作为工具，将一台主机作为OSD或MDS时，需要收集MON、OSD、MDS的初始keyring：

不再使用ceph-deploy或者另外建立一个新集群时，需要删除管理主机、本地目录的密钥：

下面的命令可以擦净（删除分区表）磁盘，以供Ceph使用 ： 

警告：所有数据会被删除。

此命令在ceph-deploy 2.0.0中已经废除

使用prepare命令来准备磁盘，会自动创建分区。在大部分OS中，activate会随后自动执行

建议：将日志存储在独立磁盘中以最优化性能，如果将日志和数据存储在一起，会有损性能。

此命令在ceph-deploy 2.0.0中已经废除

很多操作系统上，不需要手工激活OSD。

激活之后，系统运行ceph-osd进程，OSD进入up+in状态。

即prepare + activate：

仅仅luminous支持，否则报错Error EACCES: access denied could not create mgr

默认情况下RGW监听7480端口，你可以验证RGW是否正常工作：

如果只想清除 /var/lib/ceph 下的数据、并保留 Ceph 安装包，可以：

如果向同时清除数据、Ceph安装包：

要允许某些主机以管理员权限执行 Ceph 命令，可以：

上述命令执行后，当前目录中的ceph.client.admin.keyring被分发到所有指定的主机，在这些主机上可以执行ceph -s命令了。

要将修改过的、当前目录下的配置文件分发给集群内其它主机，可以：

要获取某台主机的配置文件，可以：

启动Ceph服务时，初始化进程会启动一系列守护进程，这些进程至少包含两类：

1. ceph-mon 监控进程
2. ceph-osd  Ceph OSD的守护进程

要使用Ceph文件系统功能，则需要额外运行：

1. ceph-mds Ceph元数据服务

要使用Ceph对象存储功能，则需要额外运行：

1. ceph-rgw RADOS网关守护进程 

要列出当前使用的所有配置值，可以访问守护进程的管理套接字。

在节点上执行下面的命令，获得管理套接字的位置：

调用下面的命令列出所有配置：

对于osd或者其它守护进程，也可以使用上述方式获取运行时配置。

所有守护进程从同一个配置文件ceph.conf中检索自己感兴趣的信息。该配置文件中包含了集群身份、认证配置、集群成员、主机名、主机 IP 地址、Keyring路径、日志路径、数据路径，以及其它运行时选项。

按照以下顺序来搜索，后面的可以覆盖前面的：

1. 编译进二进制文件的默认值
2. ceph-mon的集群中心配置数据库
3. 本机上的配置文件：
   1. /etc/ceph/ceph.conf
   2. ~/.ceph/config
   3. ./ceph.conf
4. 环境变量：$CEPH_CONF 
5. 命令行参数：-c path/path
6. 管理员在运行时设置的选项

一个Ceph进程启动时，它会先从命令行、环境变量、本地配置文件收集配置项，然后连接ceph-mon读取集群中心配置信息，然后启动。

配置项的名称唯一，标准格式是小写字母 + 下划线

在命令行中指定配置项时，下划线_可以替换为短横线

在配置文件中指定配置项时，下划线可以替换为空格或短横线

配置项	说明
公共选项 [global]
host	用于指定节点的主机名
mon host	指定mon节点的地址，逗号分隔
auth cluster required	集群身份验证设置，默认值cephx。如果启用，集群守护进程之间必须相互验证身份
auth service required	服务身份验证设置，默认值cephx。如果启用，服务端需要验证客户端身份
auth client required	客户端身份验证设置，默认值cephx。如果启用，客户端需要验证服务端身份
keyring	钥匙串的位置 默认值：/etc/ceph/$cluster.$name.keyring,/etc/ceph/$cluster.keyring,/etc/ceph/keyring,/etc/ceph/keyring.bin
public network	公共网络配置，CIDR格式，多个则用逗号分隔
cluster network	集群网络配置，CIDR格式，多个则用逗号分隔 如果配置了集群网， OSD 将把心跳、对象复制和恢复流量路由到集群网
fsid	存储集群的唯一标识，便于允许在同一套硬件上部署多个集群
max open files	设置操作系统级的 max open fds 建议值：131072
fatal signal handlers	如果设置为true，则安装 SEGV 、 ABRT 、 BUS 、 ILL 、 FPE 、 XCPU 、 XFSZ 、 SYS 信号处理器，用于产生有用的日志信息
chdir	进程一旦启动、运行就进入这个目录。默认 /
mon选项  [mon]
mon addr	监听地址:端口，可以针对每个mon.$id段分别配置，或者在mon段下配置： 10.0.0.10:6789,10.0.0.11:6789,10.0.0.12:6789
mon data	mon存储数据的路径，默认/var/lib/ceph/mon/$cluster-$id
mon initial members	集群初始化监视器ID，逗号分隔。这些MON必须在线以建立quorum，正确设置此参数可能让集群更快的可用
mon osd full ratio	磁盘利用率总计多少认为满了，默认 .95 当Ceph集群利用率达到此比率时，作为防止数据丢失的安全措施，它会阻止你读写 OSD 注意： 删除OSD、OSD out都会导致利用率增加，甚至超过full ratio导致锁死 如果一些 OSD 快满了，但其他的仍有足够空间，你可能配错了CRUSH权重
mon osd nearfull ratio	磁盘利用率总计多少认为快满了，默认.85
mon sync timeout	mon从其provider获取下一个更新消息的超时
mon tick interval	监视器的心跳间隔，单位为秒。默认5
mon clock drift allowed	监视器间允许的时钟漂移量。默认.050
mon timecheck interval	和 leader 的时间偏移检查间隔。默认300秒
mon osd min down reports	OSD连续多少次向mon报告某个OSD宕掉，mon才采纳，默认3
mon osd min down reporters	类似上面，mon要求多少个OSD都报告某个OSD宕掉，才采纳，默认1
mon osd min up ratio	把 OSD 标记为 down 前，保持处于 up 状态的 OSD 最小比例。默认.3
mon osd min in ratio	把 OSD 标记为 out 前，保持处于 in 状态的 OSD 最小比例。默认.3
mon osd auto mark in	是否把任何启动中的 OSD 标记为在集群中。默认false
mon osd auto mark auto out in	是否把正在启动、且被自动标记为 out 状态的 OSD 标记为 in 。默认true
mon osd auto mark new in	是否把正在启动的新 OSD 标记为 in 。默认true
mon osd down out interval	在 OSD 停止响应多少秒后把它标记为 down 且 out。默认300
mon osd downout subtree limit	最大可以把什么级别的CRUSH单元标记为out，默认rack
osd选项 [osd]
osd data	osd存储数据的路径，默认/var/lib/ceph/osd/$cluster-$id
osd map cache size	OSD map缓存大小，默认500M，建议1024
osd map cache bl size	OSD进程的In-Memory OSD map缓存大小，默认50，建议128
osd heartbeat interval	和其它OSD进行心跳检查的间隔，默认6秒
osd heartbeat grace	多久没有心跳，认为其它OSD宕掉
osd max write size	OSD一次写入的最大尺寸，默认90MB，建议512
osd mkfs options {fs-type}	为OSD新建文件系统时的选项
osd mount options {fs-type}	为OSD挂载文件系统时的选项
osd journal	OSD 日志路径，可以指向文件或块设备（例如SSD分区） 默认 /var/lib/ceph/osd/$cluster-$id/journal
osd journal size	日志文件的尺寸（MB），如果为0，且日志路径为块设备，则自动使用整个设备 推荐最少2G，有的用户则以 10GB 日志尺寸起步。合理的值是： osd journal size = {2 * (期望吞吐量* filestore max sync interval)} 期望吞吐量应考虑两个参数：硬盘吞吐量（即持续数据传输速率）、网络吞吐量，例如一个 7200 转硬盘的速度大致是 100MB/s 。硬盘和网络吞吐量中较小的一个是相对合理的吞吐量
osd client message size cap	客户端允许在内存中的最大数据量。默认524288000，建议2147483648
crush location	此OSD的CRUSH location设置
crush location hook	用于生成crush location的钩子
osd max scrubs	OSD 的最大并发洗刷操作数 除了为对象复制多个副本外， Ceph 还要洗刷归置组以确保数据完整性。这种洗刷类似对象存储层的 fsck ，对于每个归置组， Ceph 生成一个所有对象的目录，并比对每个主对象及其副本以确保没有对象丢失或错配。轻微洗刷（每天）检查对象尺寸和属性，深层洗刷（每周）会读出数据并用校验和方法确认数据完整性
osd scrub begin hour	被调度的洗刷操作，允许的运行区间起点，默认0
osd scrub end hour	被调度的洗刷操作，允许的运行区间终点，默认24
osd scrub load threshold	系统负载高于该值，不进行洗刷操作，默认0.5
osd scrub min interval	系统负载不高的前提下，多久进行一次洗刷，默认每天一次，60*60*24秒
osd scrub max interval	不论系统负载如何，最大多久进行一次洗刷，默认每周
osd deep scrub interval	深度洗刷的间隔，默认每周
osd deep scrub stride	深度洗刷允许读取的字节数。默认524288，建议131072
osd op threads	OSD 操作线程数， 0 禁用多线程。增大数量可以增加请求处理速度，默认2，建议8 增加此线程数会增大CPU开销
osd disk threads	硬盘线程数，用于在后台执行磁盘密集型操作，像数据洗刷和快照修复。默认1，建议4 增加此线程数会增大CPU开销
osd max backfills	当集群新增或移除 OSD 时，按照 CRUSH 算法应该重新均衡集群，它会把一些归置组移出或移入多个 OSD 以回到均衡状态。归置组和对象的迁移会导致集群运营性能显著降低，为维持运营性能， Ceph 用 backfilling 来执行此迁移，它可以使得 Ceph 的回填操作优先级低于用户读写请求 单个 OSD 允许的最大回填操作数。默认10，建议4
osd backfill full ratio	OSD 的占满率达到多少时拒绝接受回填请求，默认85%
osd recovery op priority	恢复操作优先级，取值1-63，值越高占用资源越高。默认10，建议4
osd recovery delay start	当集群启动、或某 OSD 守护进程崩溃后重启时，此 OSD 开始与其它 OSD 们建立互联（Peering），这样才能正常工作 如果某 OSD 崩溃并重启，通常会落后于其他 OSD ，也就是没有同归置组内最新版本的对象。这时， OSD 守护进程进入恢复模式并检索最新数据副本，并更新运行图。根据 OSD 宕掉的时间长短， OSD 的对象和归置组可能落后得厉害，另外，如果挂的是一个失效域（如一个机柜），多个 OSD 会同时重启，这样恢复时间更长、更耗资源 为保持性能， Ceph 进行恢复时会限制恢复请求数、线程数、对象块尺寸，这样在降级状态下也能保持良好的性能 对等关系建立完毕后， Ceph 开始对象恢复前等待的时间。默认0秒
osd recovery max active	每个OSD同时处理的活跃恢复请求最大数，增大此值能加速恢复，但它们会增加OSD的负担，甚至导致其无法提供服务
osd recovery max chunk	恢复时一次推送的数据块的最大尺寸，可以用于防止网络拥塞
osd recovery threads	数据恢复时的线程数，默认1
osd mount options xfs	OSD的xfs挂载选项，默认rw,noatime,inode64，建议rw,noexec,nodev,noatime,nodiratime,nobarrier
rbd客户端调优  [client]
rbd cache	是否启用RBD缓存，默认true 用于用户空间块设备实现——librbd
rbd cache size	RBD缓存大小，默认33554432，建议268435456
rbd cache max dirty	缓存为write-back时允许的最大dirty字节数，如果为0，使用write-through。默认25165824，建议25165824
rbd cache max dirty age	在被刷新到存储盘前dirty数据存在缓存的时间，默认1秒，建议5
filestore选项  [osd]
filestore max inline xattr size	每个对象在文件系统中存储XATTR（扩展属性）的最大尺寸，不得超过文件系统限制。默认值根据底层文件系统自动设置
filestore max inline xattrs	每个对象在文件系统中存储XATTR（扩展属性）的最大数量
filestore max sync interval	filestore 需要周期性地静默（暂停）写入、同步文件系统 —— 创建了一个提交点，然后就能释放相应的日志条目了。 较高的同步频率可减小执行同步的时间及保存在日志里的数据量，但是日志利用率较低 较低的频率使得后端的文件系统能优化归并较小的数据和元数据写入，因此可能使同步更有效 默认5秒。建议15
filestore min sync interval	从日志到数据盘最小同步间隔。默认.01秒，建议10
filestore op threads	并发文件系统操作数。默认2，建议32
filestore flusher	是否启用回写器（Flusher）。回写器强制使用sync file range 来写出大块数据，这样处理可能减小最终同步的代价，禁用回写器有时可能提高性能 默认false
filestore flusher max fds	回写器的最大文件描述符数量。默认512
filestore fsync flushes journal data	在fsync时是否也回写日志数据
filestore queue max ops	文件存储在阻止新操作加入队列之前，可以接受的最大操作数。取值示例25000
filestore queue max bytes	文件存储单个操作的最大字节数。取值示例10485760
filestore queue committing max ops	文件存储单次可以提交的最大操作数
filestore queue committing max bytes	文件存储单次可以提交的最大字节数
filestore journal parallel	允许并行记日志，对 btrfs 默认开
filestore journal writeahead	允许预写日志，对 xfs 默认开
journal选项  [osd]
journal dio	启用日志的Direct I/O，要求journal block align=true。默认true
journal aio	使用libaio库进行日志的异步写，要求journal dio =true。0.61+默认true
journal block align	日志按块对齐。默认true
journal max write bytes	日志写操作单次最大字节数。建议1073714824
journal max write entries	日志写操作单次最大条目数。建议10000
journal queue max ops	排队等候日志写的操作最大数。建议50000
journal queue max bytes	排队等候日志写的最大字节数。建议10485760000
journal align min size	对于大于此尺寸的数据，进行对齐操作
journal zero on create	在创建文件系统（ mkfs ）期间用 0 填充整个日志
pool/pg/crush相关 [global]
osd pool default size	对象默认副本份数
osd pool default min size	降级情况下，默认允许写操作的最小可用副本份数
osd pool default pg num	归置组的默认数量
osd pool default pgp num	为归置使用的归置组数量，默认值等同于 mkpool 的 pgp_num 参数。当前 PG 和 PGP 应该相同
mon max pool pg num	每个存储的最大归置组数量。默认65536
mon pg create interval	在同一个 OSD 里创建 PG 的间隔秒数。默认30
mon pg stuck threshold	多长时间无响应，则认为PG卡住了
mon pg min inactive	如果大于此数量的PG处于inactive状态超过mon_pg_stuck_threshold，则显示集群为HEALTH_ERR。默认1
mon pg warn min per osd	如果每OSD平均可用PG低于此数量，则显示集群为HEALTH_WARN。默认30
mon pg warn max per osd	如果每OSD平均可用PG高于此数量，则显示集群为HEALTH_WARN。默认300
osd crush chooseleaf type	在CRUSH 规则内用于 chooseleaf 的桶类型。用序列号而不是名字，默认1
osd crush initial weight	新加入到CRUSH map中的OSD的权重 默认情况下，权重是OSD的磁盘容量，单位TB
osd pool default crush rule	创建复制型池时，使用的默认CRUSH规则。默认-1，表示使用ID最低的规则
osd pool erasure code stripe unit	EC池中的对象条带尺寸
osd pool default flags	新存储池的默认标志
ms选项
ms tcp nodelay	禁用 nagle 算法，默认true
ms initial backoff	出错时重连的初始等待时间
ms max backoff	出错重连时等待的最大时间
ms nocrc	禁用网络消息的 crc 校验， CPU 不足时可提升性能
mds选项
mds cache memory limit	MDS缓存最大使用多少内存

变量	说明
$cluster	展开为存储集群的名称，在相同硬件上运行多个集群时有用
$type	展开为守护进程类型，例如mds, osd, or mon
$id	展开为守护进程或者客户端的标识符，对于osd.0其标识符为0
$host	展开为主机名
$name	展开为$type.$id
$pid	展开为守护进程的PID

配置文件是INI格式的，可以分为以下段落：

段落	用途
global	这里的配置影响 Ceph 集群里的所有守护进程
osd	影响存储集群里的所有 ceph-osd 进程，覆盖global相同选项
mon	影响集群里的所有 ceph-mon 进程，覆盖global相同选项
mds	影响集群里的所有 ceph-mds 进程，覆盖global相同选项
client	影响所有客户端（如挂载的 Ceph 文件系统、挂载的块设备等等）

你还可以针对特定的实例配置段落：

1. [osd.1]，针对ID为1的OSD的配置
2. [mon.HOSTNAME]，针对名称为HOSTNAME的MON的配置

进程连接ceph-mon、进行身份验证、抓取集群中心配置信息时需要一些配置，这些配置必须存放在本地：

选项	说明
mon_host	ceph-mon的主机列表
mon_dns_serv_name	ceph-mon的DNS名称，默认 ceph-mon
mon_data, osd_data, mds_data, mgr_data	守护进程在本地存放数据的路径
keyring, keyfile,key	连接ceph-mon进行身份验证时，使用的凭证

ceph-mon集群管理了配置配置选项的数据库，用于供整个集群来消费。为了简化管理，大部分的Ceph选项应该在此数据库中管理。

集群中心配置的分段情况，和上文的配置段落一致。

传入命令行选项 --no-mon-config，可以让进程不去读取集群中心配置，使用场景：

1. 希望所有配置信息在本地文件中管理
2. ceph-mon目前宕机，但是需要进行一些维护工作

集群中心配置的配置项，可以关联一个掩码，用于限定选项应用到哪种守护进程、哪种客户端。例如host:foo，限制foo选项仅仅应用到运行在host上的进程或客户端。

以下命令可以用于修改集群中心配置：

命令	说明
ceph config dump	Dump出整个集群中心配置
ceph config get [who]	获取指定的客户端/守护进程存放在集群中心的配置，例如mds.a
ceph config set [who] [opt] [val]	设置指定客户端/守护进程的配置项，示例： Shell 1 2 # 启用特定OSD的调试日志 ceph config set osd.123 debug_osd 20
ceph tell [who] config set  [opt] [val]	临时设置配置项，目标重启后失效
ceph config show [who]	显示指定客户端/守护进程的当前使用的配置信息，可能和集群中心配置不一样
ceph config assimilate-conf -i -o	从-i选项读取所有配置信息，注入到集群中心配置。任何无法识别、无效的配置项存放到-o

在运行时，你可以使用 ceph osd pool set命令来修改这些选项：

选项	说明
size	对象副本数
min_size	I/O 需要的最小副本数
crush_rule	此存储池使用的CRUSH规则
compression_algorithm	BlueStore使用的压缩算法，可选值lz4, snappy, zlib, zstd
compression_mode	BlueStore使用的压缩模式，可选值none, passive, aggressive, force
compression_min_blob_size compression_max_blob_size	BlueStore启用压缩的阈值
hashpspool	设置或者取消HASHPSPOOL标记。1设置0取消
nodelete	设置或取消NODELETE标记。1设置0取消
nopgchange	设置或取消NOPGCHANGE标记
nosizechange	设置或取消NOSIZECHANGE标记
write_fadvise_dontneed	设置或取消WRITE_FADVISE_DONTNEED标记
noscrub	设置或取消NOSCRUB标记
nodeep-scrub	设置或取消NODEEP_SCRUB标记
hit_set_type	启用缓存存储池的命中集跟踪，设置命中集类型，生产环境仅仅支持bloom
hit_set_count	为缓存存储池保留的命中集数量。此值越高， OSD消耗的内存越多
hit_set_fpp	bloom 命中集类型的误检率（false positive probability）
cache_target_dirty_ratio	缓存存储池包含的修改（脏）对象达到多少比例时就把它们回写到后端的存储池
cache_target_dirty_high_ratio	缓存存储池内包含的已修改（脏）对象达到什么比例时，缓存层代理就会更快地把脏对象刷回到后端存储池
cache_target_full_ratio	缓存存储池包含的干净对象达到多少比例时，缓存代理就把它们清除出缓存存储池
target_max_bytes	回写（Flushing）或清除（Evicting）对象的阈值，按字节数
target_max_objects	回写（Flushing）或清除（Evicting）对象的阈值，按对象数
scrub_min_interval	在负载低时，洗刷存储池的最大间隔秒数
scrub_max_interval	不管集群负载如何，都要洗刷存储池的最大间隔秒数
deep_scrub_interval	深度洗刷存储池的间隔秒数

Ubuntu系统下，基于ceph-deploy部署集群后，可以用这种方法来操控集群。

列出节点上所有Ceph进程：

启动节点上所有Ceph进程：

启动节点上特定类型的Ceph进程： 

启动特定类型的Ceph进程的某个实例：

停止特定类型的Ceph进程的某个实例：

在 CentOS 、 Redhat 、 Fedora 和 SLES 发行版上可以通过传统的 sysvinit 运行 Ceph ， Debian/Ubuntu 的较老的版本也可以用此方法。

命令格式：

执行 ceph status或则 ceph -s可以查看集群的状态：

1. active+clean：说明集群健康运行
2. undersized+degraded：如果有OSD节点宕机，可能进入此状态。降级后还是可以正常读写数据
3. undersized+degraded+peered：如果超过min size要求的OSD宕机，则不可读写，显示为此状态。min size默认2，副本份数默认3。执行下面的命令可以修改min size：
   
   Shell

   1	ceph osd pool set rbd min_size 1

   peered相当于已经配对（PG - OSDs），但是正在等待OSD上线

4. remapped+backfilling：默认情况下，OSD宕机5分钟后会被标记为out状态，Ceph认为它已经不属于集群了。Ceph会按照一定的规则，将已经out的OSD上的PG重映射到其它OSD，并且从现存的副本来回填（Backfilling）数据到新OSD

执行 ceph health可以查看简短的健康状态。

执行 ceph -w可以持续的监控发生在集群中的各种事件。

执行命令 ceph df可以查看集群的数据用量及其在存储池内的分布情况：

通过PG这个中间层，Ceph确保了数据不会被绑死在某个特定的OSD。要追踪错误根源，你需要检查归置组、以及底层的OSD。

执行下面的命令，获取最简短的OSD状态：

执行 ceph osd dump则可以获得详细信息，包括在CRUSH map中的权重、UUID、是in还是out：

执行 ceph osd tree可以在OSD树中打印各OSD的位置、状态、权重。如果OSD的in数量大于up数量，可以通过此命令快速定位：

执行命令 ceph pg stat可以查看全局性的PG统计信息。

可以获取PG列表：

执行下面的命令可以查看PG到OSD的映射关系：

执行 ceph status也可以看到PG的统计性信息。

执行 ceph pg 1.13d query可以查看某个PG的非常细节的信息。

导出monmap：

打印monmap的内容：

从monmap中删除一个MON：

添加一个MON到monmap中：

导入monmap到MON节点：

一旦启动了 OSD ，其状态就变成了 up+in ，此时可以通过ceph -w来观察数据迁移。归置组状态会变为active, some degraded objects，最终变回active+clean

删除OSD之前，应该评估集群容量，保证操作之后，集群不会到达 near full 比率

踢出OSD后，Ceph会进行数据迁移，达到再平衡。归置组状态会变为active, some degraded objects，最终变回active+clean。

对于某些小型测试集群，踢出一个OSD即导致CRUSH进入临界状态，某些归置组一直卡在active+remapped状态。如果遇到这种情况，你可以：

等待数据迁移完毕后，再将OSD踢出。 

你可能需要更新CRUSH map才能让新进入的OSD接受数据：

标记OSD为lost，可能导致数据丢失，谨慎：

Ceph不允许向满的 OSD 写入数据，以免丢失数据。在运营着的集群中，你应该能收到集群空间将满的警告。mon osd full ratio 默认为 0.95 ，也就是说达到 95% 时它将阻止客户端写入数据； mon osd backfillfull ratio 默认为 0.90 ，也就是说达到容量的 90% 时它会阻塞，防止回填启动； OSD 将满比率默认为 0.85 ，也就是说达到容量的 85% 时它会产生健康警告。

使用下面的命令临时修改设置，否则你可能没有机会清理不需要的RBD以腾出空间：

首先，在/var/lib/ceph/mds/mds.N创建一个数据挂载点。N是MDS的ID，通常就是主机名。

然后，修改Ceph配置，添加一个mds段。修改完毕后进行配置分发：

 如果启用了CephX，需要创建认证密钥：

执行下面的命令将目标mds标记为宕机：

移除MDS的/var/lib/ceph/mds/ceph-NAME下对应目录，然后，删除/etc/systemd/system/ceph-mds.target.wants/下的对应项目：

如果服务是通过/etc/init.d/ceph加载的，则：

查看守护进程的简短状态：

你可以使用多种方式来引用一个MDS守护进程：

和MDS进程的Standby行为相关的配置项包括：

如果不进行任何配置，没有持有Rank的那些MDS进程，可以作为任何Rank的Standby。

配置示例：

标记当前活动MDS为失败，触发故障转移：

要创建一个文件系统，你至少需要两个存储池，一个存放数据，另外一个存放元数据。注意：

1. 元数据池的副本份数要设置的高，因为任何元数据的丢失都会导致整个文件系统不可用
2. 元数据池应该使用高速存储，例如SSD，因为这对客户端操作的延迟有直接影响

示例：

创建了文件系统之后，在Luminous版本中，集群状态中显示：

查看CephFS的详细状态，包括MDS列表、Rank列表等：

要获取某个文件系统的信息，可以：

如果集群中有多个文件系统，而客户端在挂载时没有明确指定使用哪个，则使用默认文件系统：

EC池可以作为Ceph的数据池，但是需要启用overwirte：

注意：EC池不能用来存储元数据。

CephFS支持对任何一个子目录进行配额。但是，需要注意以下限制：

1. 需要客户端协作，因此被篡改过的客户端可以突破配额
2. 配额不是非常精确的
3. 内核客户端，仅仅在4.17+才支持配额。用户空间客户端fuse、libcephfs都支持配额

设置配额（设置为0则移除配额）：

查看配额：

你可以直接使用Linux内核提供的驱动来挂载CephFS：

如何启用了CephX，需要指定访问密钥，否则会报22错误：

如果报can't read superblock，说明客户端内核不支持。

要实现自动挂载，你需要修改fstab：

要在用户空间挂载CephFS，你需要：

1. 将Ceph配置文件拷贝到客户端，命名为/etc/ceph/ceph.conf
2. 将Keyring拷贝到客户端，命名为/etc/ceph/ceph.keyring：
   
   Shell

   1	sudo scp -i ~/Documents/puTTY/gmem.key root@xenon.gmem.cc:/etc/ceph/ceph.client.admin.keyring /etc/ceph/ceph.keyring

3. 执行挂载：
   
   Shell

   1 2 3 4

   sudo ceph-fuse -m 10.0.1.1:6789 /mnt/cephfs # ceph-fuse[847]: starting ceph client                                                                                                                                                     # 2018-06-07 19:18:25.503086 7fa5c44e1000 -1 init, newargv = 0x7fa5cd643b40 newargc=9                                                                                                       # ceph-fuse[847]: starting fuse

如果有多个CephFS，你可以为ceph-fuse指定命令行选项--client_mds_namespace，或者在客户端的ceph.conf中添加client_mds_namespace配置。

要实现自动挂载，你需要修改fstab：

创建存储池之后，在管理节点上，使用rbd工具来初始化池：

要取消配额，设置为0即可。 

镜像就是块设备，所谓块是一系列连续的字节序列（例如512KB）。基于块的存储接口，是磁盘、CD、软盘、甚至磁带都使用的，是存储对象最广泛使用的方式。

Ceph的块设备具有以下特点：thin-provisioned（精简配备）、可改变大小、跨越多OSD存储。

如果不指定池名称，则列出默认池中的镜像。

下面的命令可以列出池中延迟删除的镜像：

注意：rbd info输出的是thin provisioning的大小，不是实际磁盘空间占用。

除了上面的命令，还可以：

可以看到什么客户端在使用（watch）镜像：

如果不指定存储池，则在默认池中创建镜像。

从Jewel开始，RBD镜像可以异步的跨越两个集群进行镜像（Mirroring）。通过配置，你可以镜像池中的所有、或者一部分镜像。

mode取值：

1. pool，池中所有启用了journaling特性的镜像都被复制
2. image，只有明确配置的镜像才进行复制 

Dump出所有PG：

Dump出卡在指定状态中的PG的统计信息：

参考官网的算法进行计算。

执行调整之前，必须保证集群处于健康状态。

为避免调整PG数量导致业务性能受到严重影响，应该调整一些参数：

其它相关的参数还包括：

按照2的幂进行翻倍增长，例如原来32个，可以先调整为64个。

注意：不要一下子把PG设置为太大的值，这会导致大规模的rebalance，影响系统性能。

等到上一步操作后，集群变为Active+Clean状态后，再将pgp_num设置的和pg_num一致。 

推送修改后的配置文件后，重启RGW服务：

RGW在index_pool池中存放桶（Bucket）索引数据，此池默认名为.rgw.buckets.index。

从0.94版本开始，支持对桶索引进行分片，避免单个桶中对象数量过多时出现性能瓶颈：

你可以在global段配置上面的选项。 

要使用RGW的RESTful接口，你需要：

1. 创建初始的S3接口的用户
2. 创建Swift接口的子用户
3. 验证用户可以访问网关

要创建S3接口用户，需要在网关机上执行：

access_key、secret_key会打印在屏幕上，要访问网关，客户端必须提供这两个key：

要创建Swift子用户，需要在网关机上执行：

你需要为Swift子用户创建secret key：

现在，你可以用自己熟悉的语言的S3、Swift客户端来验证用户是否可用。 

要创建桶，你需要使用合法的User ID + AWS Access Key发起请求，Ceph没有提供对应的命令行。需要注意以下约束：

1. 桶名称必须唯一
2. 桶名称不能格式化为IP地址
3. 桶名称在3-63字符之间
4. 桶名称不得包含大写字母、下划线，但是可以包含短横线
5. 桶名称必须以小写字母或数字开头
6. 桶名称必须由一系列的标签组成，每个标签用点号.分隔

我们可以使用MinIO客户端创建桶：

现在通过Rgw命令行可以看到这个桶：

Ceph默认开启了cephx协议，加密认证需要消耗少量的资源。

启用cephx后，Cephe会自动在包括/etc/ceph/ceph.$name.keyring在内的位置寻找钥匙串，你可以指定keyring选项来修改默认路径，但是不推荐。

在禁用了cephx的集群上，启用它的步骤为：

1. 创建 client.admin 密钥：
   
   Shell

   1 2	# 如果你使用的自动部署工具已经生成此文件，切勿执行此命令，会覆盖 ceph auth get-or-create client.admin mon 'allow *' mds 'allow *' osd 'allow *' -o /etc/ceph/ceph.client.admin.keyring

2. 创建mon集群所需的钥匙串、密钥：
   
   Shell

   1	ceph-authtool --create-keyring /tmp/ceph.mon.keyring --gen-key -n mon. --cap mon 'allow *'

3. 将上述钥匙串复制到所有mon的mon data目录，例如：
   
   Shell

   1	cp /tmp/ceph.mon.keyring /var/lib/ceph/mon/ceph-a/keyring

4. 为每个OSD生成密钥：
   
   Shell

   1	ceph auth get-or-create osd.{$id} mon 'allow rwx' osd 'allow *' -o /var/lib/ceph/osd/ceph-{$id}/keyring

5. 为每个 MDS 生成密钥：

   Shell

   1	ceph auth get-or-create mds.{$id} mon 'allow rwx' osd 'allow *' mds 'allow *' -o /var/lib/ceph/mds/ceph-{$id}/keyring

6. 添加以下内容到配置文件的global段：

   Shell

   1 2 3

   auth cluster required = cephx auth service required = cephx auth client required = cephx

7. 启动或重启Ceph集群：  

   Shell

   1 2 3

   # 停止当前节点上的所有Ceph守护进程 sudo stop ceph-all sudo start ceph-all

修改配置文件global段：

然后重启Ceph集群。 

任何时后你都可以Dump、反编译、修改、编译、注入CURSH map。如果要完全基于手工方式管理，不使用自动生成的CRUSH map，可以设置：

执行命令 ceph osd crush dump，可以将整个CRUSH导出为可读形式：