一、高级运维
高级集群操作主要包括用 ceph 服务管理脚本启动、停止、重启集群，和集群健康状态检查、监控和操作集群。
操纵集群
运行 Ceph
每次用命令启动、重启、停止Ceph 守护进程（或整个集群）时，你必须指定至少一个选项和一个命令，还可能要指定守护进程类型或具体例程。
{commandline} [options] [commands] [daemons]
ceph 命令的选项包括：
选项 简写 描述 --verbose -v 详细的日志。 --valgrind N/A （只适合开发者和质检人员）用 Valgrind 调试。 --allhosts -a 在 ceph.conf 里配置的所有主机上执行，否 则它只在本机执行。 --restart N/A 核心转储后自动重启。 --norestart N/A 核心转储后不自动重启。 --conf -c 使用另外一个配置文件。
Ceph 子命令包括：
命令 描述 start 启动守护进程。 stop 停止守护进程。 forcestop 暴力停止守护进程，等价于 kill -9 killall 杀死某一类守护进程。 cleanlogs 清理掉日志目录。 cleanalllogs 清理掉日志目录内的所有文件。
至于子系统操作， ceph 服务能指定守护进程类型，在 [daemons] 处指定守护进程类型就行了，守护进程类型包括：
mon
osd
mds
通过 sysvinit 机制运行 Ceph
在 CentOS 、 Redhat 、 Fedora 和 SLES 发行版上可以通过传统的 sysvinit 运行 Ceph ， Debian/Ubuntu 的较老的版本也可以用此方法。
启动所有守护进程
要启动 Ceph 集群，执行 ceph 时加上 start 命令，语法如下：
sudo /etc/init.d/ceph [options] [start|restart] [daemonType|daemonID]
下面是个典型实例：
sudo /etc/init.d/ceph -a start
加 -a （即在所有节点上执行）执行完成后 Ceph 应该开始运行了。
停止所有守护进程
要停止 Ceph 集群，执行 ceph 时加上 stop 命令，语法如下：
sudo /etc/init.d/ceph [options] stop [daemonType|daemonID]
下面是个典型实例：
sudo /etc/init.d/ceph -a stop
执行命令时一旦加了 -a （即在所有节点执行），整个 Ceph 集群都会关闭。
启动一类守护进程
要启动本节点上某一类的所有 Ceph 守护进程，按此语法：
sudo /etc/init.d/ceph start {daemon-type}
sudo /etc/init.d/ceph start osd
要启动非本机节点上某一类的所有 Ceph 守护进程，按此语法：
sudo /etc/init.d/ceph -a start {daemon-type}
sudo /etc/init.d/ceph -a start osd
停止一类守护进程
要停止本节点上某一类的所有 Ceph 守护进程，按此语法：
sudo /etc/init.d/ceph stop {daemon-type} sudo /etc/init.d/ceph stop osd
要启动非本机节点上某一类的所有 Ceph 守护进程，按此语法：
sudo /etc/init.d/ceph -a stop {daemon-type}
sudo /etc/init.d/ceph -a stop osd
启动单个守护进程
要启动本节点上某个 Ceph 守护进程，按此语法：
sudo /etc/init.d/ceph start {daemon-type}.{instance}
sudo /etc/init.d/ceph start osd.0
要启动另一节点上某个 Ceph 守护进程，按此语法：
sudo /etc/init.d/ceph -a start {daemon-type}.{instance}
sudo /etc/init.d/ceph -a start osd.0
停止单个守护进程
要停止本节点上某个 Ceph 守护进程，按此语法：
sudo /etc/init.d/ceph stop {daemon-type}.{instance}
sudo /etc/init.d/ceph stop osd.0
要停止另一节点上某个 Ceph 守护进程，按此语法：
sudo /etc/init.d/ceph -a stop {daemon-type}.{instance}
sudo /etc/init.d/ceph -a stop osd.0
把 Ceph 当服务运行
如果你是用 ceph-deploy 部署 Argonaut 或 Bobtail 的，那么 Ceph 可以作为服务运行（还可以用 sysvinit ）。
启动所有守护进程
要启动你的 Ceph 集群，执行 ceph 时加上 start 命令，按此语法：
sudo service ceph [options] [start|restart] [daemonType|daemonID]
下面是个典型实例：
sudo service ceph -a start
加 -a （即在所有节点上执行）执行完成后 Ceph 应该开始运行了。
停止所有守护进程
要停止你的 Ceph 集群，执行 ceph 时加上 stop 命令，按此语法：
sudo service ceph [options] stop [daemonType|daemonID]
例如：
sudo service ceph -a stop
加 -a （即在所有节点上执行）执行完成后 Ceph 应该已停止。
启动一类守护进程
要启动本节点上某一类的所有 Ceph 守护进程，按此语法：
sudo service ceph start {daemon-type}
sudo service ceph start osd
要启动所有节点上某一类的所有 Ceph 守护进程，按此语法：
sudo service ceph -a start {daemon-type}
sudo service ceph -a start osd
停止一类守护进程
要停止本节点上某一类的所有 Ceph 守护进程，按此语法：
sudo service ceph stop {daemon-type}
sudo service ceph stop osd
要停止所有节点上某一类的所有 Ceph 守护进程，按此语法：
sudo service ceph -a stop {daemon-type}
sudo service ceph -a stop osd
启动单个守护进程
要启动本节点上某个 Ceph 守护进程，按此语法：
sudo service ceph start {daemon-type}.{instance}
sudo service ceph start osd.0
要启动另一节点上某个 Ceph 守护进程，按此语法：
sudo service ceph -a start {daemon-type}.{instance}
sudo service ceph -a start osd.0
停止单个守护进程
要停止本节点上某个 Ceph 守护进程，按此语法：
sudo service ceph stop {daemon-type}.{instance}
sudo service ceph stop osd.0
要停止另一节点上某个 Ceph 守护进程，按此语法：
sudo service ceph -a stop {daemon-type}.{instance}
sudo service ceph -a stop osd.0
监控集群
集群运行起来后，你可以用 ceph 工具来监控，典型的监控包括检查 OSD 状态、监视器状态、归置组状态和元数据服务器状态
交互模式
要在交互模式下运行 ceph ，不要带参数运行 ceph ，例如：
ceph ceph> health ceph> status ceph> quorum_status ceph> mon_status
检查集群健康状况
启动集群后、读写数据前，先检查下集群的健康状态。你可以用下面的命令检查：
ceph health
如果你的配置文件或密钥环不在默认路径下，你得指定：
ceph -c /path/to/conf -k /path/to/keyring health
集群起来的时候，你也许会碰到像 HEALTH_WARN XXX num placement groups stale 这样的健康告警，等一会再检查下。集群准备好的话 ceph health 会给出像 HEALTH_OK 一样的消息，这时候就可以开始使用集群了。
观察集群
要观察集群内正发生的事件，打开一个新终端，然后输入：
ceph -w
Ceph 会打印各种事件。例如一个包括 1 个监视器、和 2 个 OSD 的小型 Ceph 集群可能会打印出这些：
cluster b370a29d-9287-4ca3-ab57-3d824f65e339 health HEALTH_OK monmap e1: 1 mons at {ceph1=10.0.0.8:6789/0}, election epoch 2, quorum 0 ceph1 osdmap e63: 2 osds: 2 up, 2 in pgmap v41338: 952 pgs, 20 pools, 17130 MB data, 2199 objects 115 GB used, 167 GB / 297 GB avail 952 active+clean 2014-06-02 15:45:21.655871 osd.0 [INF] 17.71 deep-scrub ok 2014-06-02 15:45:47.880608 osd.1 [INF] 1.0 scrub ok 2014-06-02 15:45:48.865375 osd.1 [INF] 1.3 scrub ok 2014-06-02 15:45:50.866479 osd.1 [INF] 1.4 scrub ok 2014-06-02 15:45:01.345821 mon.0 [INF] pgmap v41339: 952 pgs: 952 active+clean; 17130 MB data, 115 GB used, 167 GB / 297 GB avail 2014-06-02 15:45:05.718640 mon.0 [INF] pgmap v41340: 952 pgs: 1 active+clean+scrubbing+deep, 951 active+clean; 17130 MB data, 115 GB used, 167 GB / 297 GB avail 2014-06-02 15:45:53.997726 osd.1 [INF] 1.5 scrub ok 2014-06-02 15:45:06.734270 mon.0 [INF] pgmap v41341: 952 pgs: 1 active+clean+scrubbing+deep, 951 active+clean; 17130 MB data, 115 GB used, 167 GB / 297 GB avail 2014-06-02 15:45:15.722456 mon.0 [INF] pgmap v41342: 952 pgs: 952 active+clean; 17130 MB data, 115 GB used, 167 GB / 297 GB avail 2014-06-02 15:46:06.836430 osd.0 [INF] 17.75 deep-scrub ok 2014-06-02 15:45:55.720929 mon.0 [INF] pgmap v41343: 952 pgs: 1 active+clean+scrubbing+deep, 951 active+clean; 17130 MB data, 115 GB used, 167 GB / 297 GB avail
输出信息里包含：
集群唯一标识符
集群健康状况
监视器图元版本、和监视器法定人数状态
OSD 图元版本、和 OSD 状态摘要
归置组图版本
归置组和存储池数量
其内存储的数据和对象数量的粗略统计，以及数据总量
Ceph 如何计算数据量
used 值反映了确实已占用的原始存储空间。
xxx GB / xxx GB 值则是剩余空间（较小的数）与集群总容量的比较。
理论数值反映了所存储数据的原始尺寸，未计算其副本、克隆、或快照空间，所以数据存储实际占用的空间通常会超过理论数值，
因为 Ceph 会自动创建数据副本，另外存储空间也可能用于克隆和快照。
检查集群的使用情况
要检查集群的数据用量及其在存储池内的分布情况，可以用 df 选项，它和 Linux 上的 df 相似。如下：
ceph df
输出的 GLOBAL 段展示了数据所占用集群存储空间的概要。
SIZE: 集群的总容量；
AVAIL: 集群的空闲空间总量；
RAW USED: 已用存储空间总量；
% RAW USED: 已用存储空间比率。用此值参照 full ratio 和 near full \ ratio 来确保不会用尽集群空间。
输出的 POOLS 段展示了存储池列表及各存储池的大致使用率。本段没有展示副本、克隆品和快照占用情况。例如，如果你把 1MB 的数据存储为对象，理论使用率将是 1MB ，但考虑到副本数、克隆数、和快照数，实际使用率可能是 2MB 或更多。
NAME: 存储池名字； ID: 存储池唯一标识符； USED: 大概数据量，单位为 KB 、 MB 或 GB ； %USED: 各存储池的大概使用率； Objects: 各存储池内的大概对象数。
注意：POOLS 段内的数字是理论值，它们不包含副本、快照或克隆。因此，它与 USED 和 %USED 数量之和不会达到 GLOBAL 段中的 RAW USED 和 %RAW USED 数量
检查集群状态
要检查集群的状态，执行下面的命令：
ceph status
或者：
ceph -s
在交互模式下，输入 status 然后按回车：
ceph> status
Ceph 将打印集群状态，例如一个包括 1 个监视器、和 2 个 OSD 的小型 Ceph 集群可能打印：
cluster b370a29d-9287-4ca3-ab57-3d824f65e339 health HEALTH_OK monmap e1: 1 mons at {ceph1=10.0.0.8:6789/0}, election epoch 2, quorum 0 ceph1 osdmap e63: 2 osds: 2 up, 2 in pgmap v41332: 952 pgs, 20 pools, 17130 MB data, 2199 objects 115 GB used, 167 GB / 297 GB avail 1 active+clean+scrubbing+deep 951 active+clean
检查 OSD 状态
你可以执行下列命令来确定 OSD 状态为 up 且 in ：
ceph osd stat
或者：
ceph osd dump
你也可以根据 OSD 在 CRUSH 图里的位置来查看：
ceph osd tree
Ceph 会打印 CRUSH 的树状态、它的 OSD 例程、状态、权重：
# id weight type name up/down reweight -1 3 pool default -3 3 rack mainrack -2 3 host osd-host 0 1 osd.0 up 1 1 1 osd.1 up 1 2 1 osd.2 up 1
检查监视器状态
如果你有多个监视器（很可能），你启动集群后、读写数据前应该检查监视器法定人数状态。运行着多个监视器时必须形成法定人数，最好周期性地检查监视器状态来确定它们在运行。
要查看监视器图，执行下面的命令：
ceph mon stat
或者：
ceph mon dump
要检查监视器的法定人数状态，执行下面的命令：
ceph quorum_status
Ceph 会返回法定人数状态，例如，包含 3 个监视器的 Ceph 集群可能返回下面的：
"election_epoch": 10, "quorum": [ 0, 1, 2], "monmap": { "epoch": 1, "fsid": "444b489c-4f16-4b75-83f0-cb8097468898", "modified": "2011-12-12 13:28:27.505520", "created": "2011-12-12 13:28:27.505520", "mons": [ { "rank": 0, "name": "a", "addr": "127.0.0.1:6789\/0"}, { "rank": 1, "name": "b", "addr": "127.0.0.1:6790\/0"}, { "rank": 2, "name": "c", "addr": "127.0.0.1:6791\/0"} ] } }
检查 MDS 状态
元数据服务器为 Ceph 文件系统提供元数据服务，元数据服务器有两种状态： up | down 和 active | inactive ，执行下面的命令查看元数据服务器状态为 up 且 active ：
ceph mds stat
要展示元数据集群的详细状态，执行下面的命令：
ceph mds dump
检查归置组状态
归置组把对象映射到 OSD 。监控归置组时，我们希望它们的状态是 active 且 clean 。
使用管理套接字
Ceph 管理套接字允许你通过套接字接口查询守护进程，它们默认存在于 /var/run/ceph 下。要通过管理套接字访问某个守护进程，先登录它所在的主机、再执行下列命令：
ceph daemon {daemon-name}
ceph daemon {path-to-socket-file}
比如，这是下面这两种用法是等价的：
ceph daemon osd.0 foo ceph daemon /var/run/ceph/ceph-osd.0.asok foo
用下列命令查看可用的管理套接字命令：
ceph daemon {daemon-name} help
管理套接字命令允许你在运行时查看和修改配置，见查看运行时配置。
另外，你可以在运行时直接修改配置选项（也就是说管理套接字会绕过监视器，不要求你直接登录宿主主机，不像 ceph {daemon-type} tell {id} injectargs 依赖监视器。
监控 OSD 和归置组
高可用性和高可靠性要求容错方法来管理软硬件。 Ceph 没有单故障点，并且能在“降级”模式下继续提供服务。其数据归置引进了一个间接层，它可保证数据不会直接绑死到某一个特定 OSD 地址，这也意味着追踪系统错误的根源得深入归置组及底层的 OSD
注意：集群某一部分失效可能导致不能访问某个对象，但不会牵连其他对象。碰到这种问题时无需恐慌，只需按步骤检查 OSD 和归置组，然后排除故障。
Ceph 通常能自己康复，然而如果故障持续存在，监控 OSD 和归置组有助于找出问题所在。
监控 OSD
某 OSD 的状态可以是在集群内（ in ）或集群外（ out ）、也可以是活着且在运行（ up ）或挂了且不在运行（ down ）。
如果一个 OSD 活着，它也可以是 in （你可以读写数据）或者 out 集群。
如果它以前是 in 但最近 out 了， Ceph 会把其归置组迁移到其他 OSD 。如果一 OSD out 了， CRUSH 就不会再分配归置组给它。
如果它挂了（ down ）其状态也应该是 out。
如果你执行过这些命令，如 ceph health 、 ceph -s 、或 ceph -w ，也许注意到了，集群并非一直返回 HEALTH OK ，别紧张。就 OSD 而言你应该明确，在一些情况下集群不会返回 HEALTH OK ：
1.你还没启动集群（它不会响应的）。
2.你刚刚启动或重启完集群，而且它还没准备好，因为归置组正被创建、 OSD 们正在相互建立连接。
3.你刚刚增加或拆除一个 OSD 。
4.你刚刚修改完集群运行图
OSD 监控的一个重要事情是，当集群启动并运行时，所有 OSD 也应该是启动（ up ）并在集群内（ in ）运行。用下列命令查看：
ceph osd stat
其结果会告诉你运行图版本（ eNNNN ）、 总共有 x 个 OSD 、 y 个是 up 的、 z 个是 in 的。
eNNNN: x osds: y up, z in
如果处于 in 状态的 OSD 多于 up 的，用下列命令看看哪些 ceph-osd 守护进程没在运行：
ceph osd tree :: dumped osdmap tree epoch 1 # id weight type name up/down reweight -1 2 pool openstack -3 2 rack dell-2950-rack-A -2 2 host dell-2950-A1 0 1 osd.0 up 1 1 1 osd.1 down 1
注意：精心设计的 CRUSH 分级结构可以帮你更快的定位到物理位置、加快故障排除
若一个 OSD 状态为 down ，启动它：
sudo /etc/init.d/ceph -a start osd.1
归置组集
CRUSH 要把归置组分配到 OSD 时，它先查询这个存储池的副本数设置，再把归置组分配到 OSD ，这样就把各副本分配到了不同 OSD 。
比如，如果存储池要求归置组有 3 个副本， CRUSH 可能把它们分别分配到 osd.1 、 osd.2 、 osd.3 。考虑到你设置于 CRUSH 运行图中的失败域，实际上 CRUSH 找出的是伪随机位置，所以在大型集群中，你很少能看到归置组被分配到了相邻的 OSD 。
我们把涉及某个特定归置组副本的一组 OSD 称为 acting set 。在一些情况下，位于 acting set 中的一个 OSD down 了或者不能为归置组内的对象提供服务，这些情形发生时无需惊慌，常见原因如下：
1.你增加或拆除了一 OSD 。然后 CRUSH 把那个归置组分配到了其他 OSD ，因此改变了 Acting Set 的构成、并且用 backfill 进程启动了数据迁移； 2.一 OSD down 了、重启了、而现在正恢复（ recovering ）； 3.acting set 中的一个 OSD 挂了，不能提供服务，另一个 OSD 临时接替其工作。
Ceph 靠 up set 处理客户端请求，它们是最终处理请求的一系列 OSD 。大多数情况下 up set 和 acting set 本质上相同，如果不同，说明可能 Ceph 在迁移数据、某 OSD 在恢复、或者哪里有问题。这种情况下， Ceph 通常表现为 HEALTH WARN 状态，还有 “stuck stale” 消息。
用下列命令获取归置组列表：
ceph pg dump
要根据指定归置组号查看哪些 OSD 位于 Acting Set 或 Up Set 里，执行：
ceph pg map {pg-num}
其结果会告诉你 osdmap 版本（ eNNN ）、归置组号（ {pg-num} ）、 Up Set 内的 OSD （ up[] ）、和 Acting Set 内的 OSD （ acting[] ）。
osdmap eNNN pg {pg-num} -> up [0,1,2] acting [0,1,2]
注意：如果 Up Set 和 Acting Set 不一致，这可能表明集群内部在重均衡或者有潜在问题
节点互联
写入数据前，归置组必须处于 active 、而且应该是 clean 状态。假设一存储池的归置组有 3 个副本，为让 Ceph 确定归置组的当前状态，一归置组的主 OSD （即 acting set 内的第一个 OSD ）会与第二和第三 OSD 建立连接、并就归置组的当前状态达成一致意见。
OSD 们也向监视器报告自己的状态，
监控归置组状态
如果你执行过 ceph health 、 ceph -s 、或 ceph -w 命令，你也许注意到了集群并非总返回 HEALTH OK 。检查完 OSD 是否在运行后，你还应该检查归置组状态。你应该明白，在归置组建立连接时集群不会返回 HEALTH OK ：
1.刚刚创建了一个存储池，归置组还没互联好；
2.归置组正在恢复；
3.刚刚增加或删除了一个 OSD ；
4.刚刚修改了 CRUSH 图，并且归置组正在迁移；
5.某一归置组的副本间的数据不一致；
6.Ceph 正在洗刷一个归置组的副本；
7.Ceph 没有足够空余容量来完成回填操作
如果是前述原因之一导致了 Ceph 返回 HEALTH WARN ，无需紧张。很多情况下，集群会自行恢复；有些时候你得采取些措施。归置组监控的一件重要事情是保证集群起来并运行着，所有归置组都处于 active 状态、并且最好是 clean 状态。用下列命令查看所有归置组状态：
ceph pg stat
其结果会告诉你归置组运行图的版本号（ vNNNNNN ）、归置组总数 x 、有多少归置组处于某种特定状态，如 active+clean （ y ）。
vNNNNNN: x pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB avail
注意：Ceph 同时报告出多种状态是正常的
除了归置组状态之外， Ceph 也会报告数据占据的空间（ aa ）、剩余空间（ bb ）和归置组总容量。这些数字在某些情况下是很重要的：
快达到 "near full ratio" 或 "full ratio" 时；
由于 CRUSH 配置错误致使你的数据没能在集群内分布。
归置组唯一标识符
归置组 ID 由存储池号（不是存储池名字）、后面跟一个点（ . ）、然后是归置组 ID ，它是一个十六进制数字。用 ceph osd lspools 可查看存储池号及其名字，例如，默认存储池 rbd 对应的存储池号是 0 。完整的归置组 ID 格式如下：
{pool-num}.{pg-id}
典型长相：
0.1f
用下列命令获取归置组列表：
ceph pg dump
你也可以让它输出到 JSON 格式，并保存到文件：
ceph pg dump -o {filename} --format=json
要查询某个归置组，用下列命令：
ceph pg {poolnum}.{pg-id} query
Ceph 会输出成 JSON 格式。
{ "state": "active+clean", "up": [ 1, 0 ], "acting": [ 1, 0 ], "info": { "pgid": "1.e", "last_update": "4'1", "last_complete": "4'1", "log_tail": "0'0", "last_backfill": "MAX", "purged_snaps": "[]", "history": { "epoch_created": 1, "last_epoch_started": 537, "last_epoch_clean": 537, "last_epoch_split": 534, "same_up_since": 536, "same_interval_since": 536, "same_primary_since": 536, "last_scrub": "4'1", "last_scrub_stamp": "2013-01-25 10:12:23.828174" }, "stats": { "version": "4'1", "reported": "536'782", "state": "active+clean", "last_fresh": "2013-01-25 10:12:23.828271", "last_change": "2013-01-25 10:12:23.828271", "last_active": "2013-01-25 10:12:23.828271", "last_clean": "2013-01-25 10:12:23.828271", "last_unstale": "2013-01-25 10:12:23.828271", "mapping_epoch": 535, "log_start": "0'0", "ondisk_log_start": "0'0", "created": 1, "last_epoch_clean": 1, "parent": "0.0", "parent_split_bits": 0, "last_scrub": "4'1", "last_scrub_stamp": "2013-01-25 10:12:23.828174", "log_size": 128, "ondisk_log_size": 128, "stat_sum": { "num_bytes": 205, "num_objects": 1, "num_object_clones": 0, "num_object_copies": 0, "num_objects_missing_on_primary": 0, "num_objects_degraded": 0, "num_objects_unfound": 0, "num_read": 1, "num_read_kb": 0, "num_write": 3, "num_write_kb": 1 }, "stat_cat_sum": { }, "up": [ 1, 0 ], "acting": [ 1, 0 ] }, "empty": 0, "dne": 0, "incomplete": 0 }, "recovery_state": [ { "name": "Started\/Primary\/Active", "enter_time": "2013-01-23 09:35:37.594691", "might_have_unfound": [ ], "scrub": { "scrub_epoch_start": "536", "scrub_active": 0, "scrub_block_writes": 0, "finalizing_scrub": 0, "scrub_waiting_on": 0, "scrub_waiting_on_whom": [ ] } }, { "name": "Started", "enter_time": "2013-01-23 09:35:31.581160" } ] }
后续子章节详述了常见状态。
存储池在建中
创建存储池时，它会创建指定数量的归置组。 Ceph 在创建一或多个归置组时会显示 creating ；创建完后，在其归置组的 Acting Set 里的 OSD 将建立互联；一旦互联完成，归置组状态应该变为 active+clean ，意思是 Ceph 客户端可以向归置组写入数据了.
互联建立中
Ceph 为归置组建立互联时，会让存储归置组副本的 OSD 之间就其中的对象和元数据状态达成一致。 Ceph 完成了互联，也就意味着存储着归置组的 OSD 就其当前状态达成了一致。然而，互联过程的完成并不能表明各副本都有了数据的最新版本。
权威历史 Ceph 不会向客户端确认写操作，直到 acting set 里的所有 OSD 都完成了写操作。这样处理保证了从上次成功互联起， acting set 中至少有一个成员确认了每个写操作。 有了各个已确认写操作的精确记录， Ceph 就可以构建和散布一个新的归置组权威历史——一个完整、完全有序的操作集，如果被采用，就能把一个 OSD 的归置组副本更新到最新。
活跃
Ceph 完成互联后，一归置组状态会变为 active 。 active 状态意味着数据已完好地保存到了主归置组和副本归置组
整洁
某一归置组处于 clean 状态时，主 OSD 和副本 OSD 已成功互联，并且没有偏离的归置组。 Ceph 已把归置组中的对象复制了规定次数。
已降级
当客户端向主 OSD 写入数据时，由主 OSD 负责把数据副本写入其余副本 OSD 。主 OSD 把对象写入存储器后，在副本 OSD 创建完对象副本并报告给主 OSD 之前，主 OSD 会一直停留在 degraded 状态。
归置组状态可以处于 active+degraded 状态，原因在于一 OSD 即使尚未持有所有对象也可以处于 active 状态。如果一 OSD 挂了， Ceph 会把分配到此 OSD 的归置组都标记为 degraded ；那个 OSD 重生后，它们必须重新互联。然而，客户端仍可以向处于 degraded 状态的归置组写入新对象，只要它还在 active 状态。
如果一 OSD 挂了，且老是处于 degraded 状态， Ceph 会把 down 的 OSD 标记为在集群外（ out ）、并把那个 down 掉的 OSD 上的数据重映射到其它 OSD 。从标记为 down 到 out 的时间间隔由 mon osd down out interval 控制，默认是 300 秒。
归置组也会被降级（ degraded ），因为 Ceph 找不到本应存在于此归置组中的一或多个对象，这时，你不能读写找不到的对象，但仍能访问位于降级归置组中的其它对象。
恢复中
Ceph 被设计为可容错，可抵御一定规模的软、硬件问题。当某 OSD 挂了（ down ）时，其内的归置组会落后于别的归置组副本；此 OSD 重生（ up ）时，归置组内容必须更新到当前状态；在此期间， OSD 处于 recovering 状态。
恢复并非总是这些小事，因为一次硬件失败可能牵连多个 OSD 。比如一个机柜或房间的网络交换机失败了，这会导致多个主机上的 OSD 落后于集群的当前状态，故障恢复后每一个 OSD 都必须恢复。
Ceph 提供了几个选项来均衡资源竞争，如新服务请求、恢复数据对象和恢复归置组到当前状态。 osd recovery delay start 选项允许一 OSD 在开始恢复进程前，先重启、重建互联、甚至处理一些重放请求；osd recovery threads 选项限制恢复进程的线程数，默认为 1 线程； osd recovery thread timeout 设置线程超时，因为多个 OSD 可能交替失败、重启和重建互联； osd recovery max active 选项限制一 OSD 最多同时接受多少请求，以防它压力过大而不能正常服务； osd recovery max chunk 选项限制恢复数据块尺寸，以防网络拥塞。
回填中
有新 OSD 加入集群时， CRUSH 会把现有集群内的部分归置组重分配给它。强制新 OSD 立即接受重分配的归置组会使之过载，用归置组回填可使这个过程在后台开始。只要回填顺利完成，新 OSD 就可以对外服务了。
在回填运转期间，你可能见到以下几种状态之一： backfill_wait 表明一回填操作在等待时机，尚未开始； backfill 表明一回填操作正在进行； backfill_too_full 表明需要进行回填，但是因存储空间不足而不能完成。某归置组不能回填时，其状态应该是 incomplete 。
Ceph 提供了多个选项来解决重分配归置组给一 OSD （特别是新 OSD ）时相关的负载问题。默认， osd_max_backfills 把双向的回填并发量都设置为 10 ； osd backfill full \ ratio 可让一 OSD 在接近占满率（默认 85% ）时拒绝回填请求，如果一 OSD 拒绝了回填请求，在 osd backfill retry interval 间隔之后将重试（默认 10 秒）； OSD 也能用 osd backfill scan min 和 osd backfill scan max 来管理扫描间隔（默认 64 和 512 ）。
被重映射
负责维护某一归置组的 Acting Set 变更时，数据要从旧集合迁移到新的。新的主 OSD 要花费一些时间才能提供服务，所以老的主 OSD 还要持续提供服务、直到归置组迁移完。数据迁移完后，运行图会包含新 acting set 里的主 OSD 。
发蔫
虽然 Ceph 用心跳来保证主机和守护进程在运行，但是 ceph-osd 仍有可能进入 stuck 状态，它们没有按时报告其状态（如网络瞬断）。默认， OSD 守护进程每半秒（ 0.5 ）会一次报告其归置组、出流量、引导和失败统计状态，此频率高于心跳阀值。如果一归置组的主 OSD 所在的 acting set 没能向监视器报告、或者其它监视器已经报告了那个主 OSD 已 down ，监视器们就会把此归置组标记为 stale 。
启动集群时，会经常看到 stale 状态，直到互联完成。集群运行一阵后，如果还能看到有归置组位于 stale 状态，就说明那些归置组的主 OSD 挂了（ down ）、或没在向监视器报告统计信息。
找出故障归置组
如前所述，一个归置组状态不是 active+clean 时未必有问题。一般来说，归置组卡住时 Ceph 的自修复功能往往无能为力，卡住的状态细分为：
Unclean: 归置组里有些对象的副本数未达到期望次数，它们应该在恢复中；
Inactive: 归置组不能处理读写请求，因为它们在等着一个持有最新数据的 OSD 回到 up 状态；
Stale: 归置组们处于一种未知状态，因为存储它们的 OSD 有一阵子没向监视器报告了（由 mon osd report timeout 配置）
为找出卡住的归置组，执行：
ceph pg dump_stuck [unclean|inactive|stale|undersized|degraded]
定位对象
要把对象数据存入 Ceph 对象存储，一 Ceph 客户端必须：
设置对象名
指定一存储池
Ceph 客户端索取最新集群运行图、并用 CRUSH 算法计算对象到归置组的映射，然后计算如何动态地把归置组映射到 OSD 。要定位对象，只需要知道对象名和存储池名字，例如：
ceph osd map {poolname} {object-name}
练习：定位一个对象
反正是练习，我们先创建一个对象。给 rados put 命令指定一对象名、一个包含数据的测试文件路径、和一个存储池名字，例如： rados put {object-name} {file-path} --pool=data rados put test-object-1 testfile.txt --pool=data 用下列命令确认 Ceph 对象存储已经包含此对象： rados -p data ls 现在可以定位对象了： ceph osd map {pool-name} {object-name} ceph osd map data test-object-1 Ceph 应该输出对象的位置，例如： osdmap e537 pool 'data' (0) object 'test-object-1' -> pg 0.d1743484 (0.4) -> up [1,0] acting [1,0] 要删除测试对象，用 rados rm 即可，如： rados rm test-object-1 --pool=data
随着集群的运转，对象位置会动态改变。 Ceph 动态重均衡的优点之一，就是把你从人工迁移中解救了。
用户管理
本文档叙述了 Ceph 客户端的用户身份，及其与 Ceph 存储集群的认证和授权。用户可以是个人或系统角色（像应用程序），它们用 Ceph 客户端和 Ceph 服务器守护进程交互。
当 Ceph 在启用身份验证和授权时运行 (默认情况下启用), 您必须指定一个用户名和一个包含指定用户密钥 (通常通过命令行) 的密匙环。
如果不指定用户名, Ceph 将使用客户端. admin 作为默认用户名。如果不指定密匙环, Ceph 将通过 Ceph 配置中的密匙环设置来查找密匙环。
例如, 如果在不指定用户或密匙环的情况下执行 ceph 运行状况命令:
ceph health
ceph -n client.admin --keyring=/etc/ceph/ceph.client.admin.keyring health
另外你也可以用 CEPH_ARGS 环境变量来避免多次输入用户名和密钥。
背景
无论 Ceph 客户端的类型如何 (例如, 块设备、对象存储、文件系统、本地 API 等), Ceph 都将所有数据存储为池中的对象。
Ceph 用户必须具有对池的访问权限才能读写数据。此外, Ceph 用户必须具有执行权限才能使用 Ceph 的管理命令。以下概念将帮助您了解 Ceph 的用户管理。
用户
用户要么是个人, 要么是系统参与者 (如应用程序)。创建用户允许您控制谁 (或什么) 可以访问您的 Ceph 存储群集、它的池以及池中的数据。
Ceph 有一个用户类型的概念。对于用户管理的目的, 类型将始终是客户端。Ceph 标识以句点 (.) 分隔形式的用户。
有时 Ceph 的用户类型可能看起来很混乱, 因为 Ceph 命令行允许您指定具有或不带类型的用户, 这取决于您的命令行用法。如果您指定--用户或--id, 则可以省略该类型。因此, 客户端 user1 可以简单地输入为 user1。如果指定--名称或-n, 则必须指定类型和名称, 如客户端. user1。
Ceph 存储群集用户与 Ceph 对象存储用户或 Ceph 文件系统用户不同。
Ceph 对象网关使用 Ceph 存储群集用户在网关守护进程和存储群集之间进行通信, 但网关对最终用户具有自己的用户管理功能。
Ceph 文件系统使用 POSIX 语义。与 Ceph 文件系统相关联的用户空间与 Ceph 存储群集用户不同。
授权（能力）
eph 用能力（ capabilities, caps ）这个术语来描述给认证用户的授权，这样才能使用监视器、 OSD 、和元数据服务器的功能。能力也用于限制对一存储池内的数据或某个名字空间的访问。 Ceph 的管理用户可在创建或更新某用户时赋予他能力。
能力的语法符合下面的形式：
{daemon-type} 'allow {capability}' [{daemon-type} 'allow {capability}']
监视器能力： 监视器能力包括 r 、 w 、 x 和 allow profile {cap} ，例如：
mon 'allow rwx' mon 'allow profile osd'
OSD 能力： OSD 能力包括 r 、 w 、 x 、 class-read 、 class-write 和 profile osd 。另外， OSD 能力还支持存储池和命名空间的配置
osd 'allow {capability}' [pool={poolname}] [namespace={namespace-name}]
元数据服务器能力： 元数据服务器能力比较简单，只需要 allow 或者空白，也不会解析更多选项。
mds 'allow'
注意：Ceph 对象网关守护进程（ radosgw ）是 Ceph 存储集群的一种客户端，所以它没被表示成一种独立的 Ceph 存储集群守护进程类型
下面描述了各种能力
allow 描述: 在守护进程的访问设置之前，仅对 MDS 隐含 rw 。 r 描述: 授予用户读权限，监视器需要它才能搜刮 CRUSH 图。 w 描述: 授予用户写对象的权限。 x 描述: 授予用户调用类方法的能力，即同时有读和写，且能在监视器上执行 auth 操作。 class-read 描述: 授予用户调用类读取方法的能力， x 的子集。 class-write 描述: 授予用户调用类写入方法的能力， x 的子集。 * 描述: 授权此用户读、写和执行某守护进程/存储池，且允许执行管理命令。 profile osd 描述: 授权一个用户以 OSD 身份连接其它 OSD 或监视器。授予 OSD 们允许其它 OSD 处理复制、心跳流量和状态报告。 profile mds 描述: 授权一个用户以 MDS 身份连接其它 MDS 或监视器。 profile bootstrap-osd 描述: 授权一用户自举引导一 OSD 。授予部署工具，像 ceph-disk 、 ceph-deploy 等等，这样它们在自举引导 OSD 时就有权限增加密钥了。 profile bootstrap-mds 描述: 授权一用户自举引导一元数据服务器。授予像 ceph-deploy 一样的部署工具，这样它们在自举引导元数据服务器时就有权限增加密钥了。
存储池
存储池是用户存储数据的逻辑分区。在 Ceph 部署中，经常创建存储池作为逻辑分区、用以归类相似的数据。例如，用 Ceph 作为 OpenStack 的后端时，典型的部署通常会创建多个存储池，分别用于存储卷宗、映像、备份和虚拟机，以及用户（如 client.glance 、 client.cinder 等）。
命名空间
池中的对象可以与池中的 namespace–a 的逻辑组相关联。用户对池的访问可以与命名空间关联, 这样用户的读写操作只在命名空间内进行。写入到池中的命名空间的对象只能由有权访问该命名空间的用户访问
命名空间的基本原理是, 为了授权单独的用户集, 池可以是一种计算性很高的分离数据集的方法。
例如, 每个 OSD 的池应该有 ~ 100 放置组。因此, 一个示范集群与1000操作系统将有10万安置小组为一个水池。每个池将在模范集群中创建另外10万位置组。相比之下, 将对象写入命名空间只是将该命名空间与对象名称关联起来, 从而排除了单独池的计算开销。您可以使用命名空间, 而不是为用户或用户集创建单独的池。注: 仅在此时使用 librados
管理用户
用户管理功能为 Ceph 的存储群集管理员提供了在 Ceph 存储群集中直接创建、更新和删除用户的能力。
当您在 Ceph 存储群集中创建或删除用户时, 您可能需要向客户端分发密钥, 以便将它们添加到钥匙环中
罗列用户
要列出群集中的用户, 请执行以下操作：
ceph auth list
Ceph 将列出您的群集中的所有用户。例如, 在两个节点的模范群集中, ceph 的身份验证列表将输出如下所示的内容:
installed auth entries: osd.0 key: AQCvCbtToC6MDhAATtuT70Sl+DymPCfDSsyV4w== caps: [mon] allow profile osd caps: [osd] allow * osd.1 key: AQC4CbtTCFJBChAAVq5spj0ff4eHZICxIOVZeA== caps: [mon] allow profile osd caps: [osd] allow * client.admin key: AQBHCbtT6APDHhAA5W00cBchwkQjh3dkKsyPjw== caps: [mds] allow caps: [mon] allow * caps: [osd] allow * client.bootstrap-mds key: AQBICbtTOK9uGBAAdbe5zcIGHZL3T/u2g6EBww== caps: [mon] allow profile bootstrap-mds client.bootstrap-osd key: AQBHCbtT4GxqORAADE5u7RkpCN/oo4e5W0uBtw== caps: [mon] allow profile bootstrap-osd
获取用户
要检索特定用户、密钥和功能, 请执行以下操作:
ceph auth get {TYPE.ID}
例如：
ceph auth get client.admin
新增用户
添加用户将创建一个用户名 (即, 类型. ID)、一个密钥以及用于创建该用户的命令中包含的任何功能。
用户的密钥使用户能够使用 Ceph 存储群集进行身份验证。用户的功能授权用户读取、写入或执行 Ceph 监视器 (mon)、Ceph 操作系统 (osd) 或 Ceph 元数据服务器 (mds)。
ceph auth add:此命令是添加用户的规范化方法。它将创建用户, 生成密钥并添加任何指定的功能。
ceph auth get-or-create:此命令通常是创建用户的最方便的方法, 因为它返回一个具有用户名 (在方括号中) 和键的文件格式。
如果用户已存在, 则此命令仅返回文件格式的用户名和密钥。您可以使用-o {文件名} 选项将输出保存到文件中。
ceph auth get-or-create-key:此命令是创建用户并返回用户密钥 (仅限) 的一种简便方法。这对于仅需要密钥的客户端 (例如, libvirt) 非常有用。
如果用户已存在, 则此命令只返回密钥。您可以使用-o {文件名} 选项将输出保存到文件中
创建客户端用户时, 您可以创建一个没有任何功能的用户。没有任何功能的用户在单纯的身份验证中是无用的, 因为客户端无法从监视器中检索群集映射。但是, 如果希望以后使用 ceph 身份验证 cap 命令推迟添加功能, 则可以创建没有任何功能的用户.
典型的用户至少具有 Ceph 监视器的读取功能, 并且对 Ceph 操作系统具有读写能力。此外, 用户的 OSD 权限通常仅限于访问特定的池。
ceph auth add client.john mon 'allow r' osd 'allow rw pool=liverpool' ceph auth get-or-create client.paul mon 'allow r' osd 'allow rw pool=liverpool' ceph auth get-or-create client.george mon 'allow r' osd 'allow rw pool=liverpool' -o george.keyring ceph auth get-or-create-key client.ringo mon 'allow r' osd 'allow rw pool=liverpool' -o ringo.key
注意：如果为用户提供了操作系统的功能, 但不限制对特定池的访问, 则用户将有权访问群集中的所有池!
修改用户能力
ceph auth caps 命令可以用来修改指定用户的能力。设置新能力时会覆盖当前能力。查看用户当前的能力可以用 ceph auth get USERTYPE.USERID ；增加能力时应该加上当前已经有的能力，命令格式如下：
ceph auth caps USERTYPE.USERID {daemon} 'allow [r|w|x|*|...] [pool={pool-name}] [namespace={namespace-name}]' [{daemon} 'allow [r|w|x|*|...] [pool={pool-name}] [namespace={namespace-name}]']
例如：
ceph auth get client.john ceph auth caps client.john mon 'allow r' osd 'allow rw pool=liverpool' ceph auth caps client.paul mon 'allow rw' osd 'allow rwx pool=liverpool' ceph auth caps client.brian-manager mon 'allow *' osd 'allow *'
若要删除功能, 可以重置功能。如果希望用户对以前设置的特定守护程序没有访问权限, 请指定一个空字符串。例如:
ceph auth caps client.ringo mon ' ' osd ' '
删除用户
要删除一用户，用 ceph auth del 命令：
ceph auth del {TYPE}.{ID}
其中 {TYPE} 是 client 、 osd 、 mon 或 mds 之一， {ID} 是用户名或守护进程的 ID 。
查看用户密钥
要将用户的身份验证密钥打印到标准输出, 请执行以下操作:
ceph auth print-key {TYPE}.{ID}
其中 {TYPE} 是客户端、osd、mon或 mds 之一, {id} 是守护进程的用户名或 id。
导入用户
要导入一个或多个用户, 请使用 ceph 授权导入并指定一个密匙环:
ceph auth import -i /path/to/keyring
例如：
sudo ceph auth import -i /etc/ceph/ceph.keyring
注意：ceph 存储群集将添加新用户、其密钥和功能, 并将更新现有用户、其密钥及其功能
密钥环管理
当您通过 Ceph 客户端访问 Ceph 时, Ceph 客户端将查找本地密匙环。默认情况下, Ceph 预设带有以下四密匙环的密匙环设置, 这样您就不必在 Ceph 配置文件中设置它们, 除非您想覆盖默认值 (不推荐):
/etc/ceph/$cluster.$name.keyring /etc/ceph/$cluster.keyring /etc/ceph/keyring /etc/ceph/keyring.bin
$cluster 元是您的 Ceph 群集名称, 由 Ceph 配置文件的名称 (即 Ceph) 定义. 组名是指群集名称为 Ceph; 因此, Ceph. 密匙圈)。$name 元是用户类型和用户 ID (例如, 客户端. admin; 因此, ceph.client.admin.keyring)。
在您创建用户 之后, 您必须获取该密钥并将其添加到 Ceph 客户端上的钥匙环中, 以便用户可以访问 Ceph 存储群集。
创建密钥环
ceph authtool 工具允许您创建一个密匙环。要创建空的密匙环, 请使用--create-keyring或-C。例如:
ceph-authtool --create-keyring /path/to/keyring
在创建带有多个用户的密匙环时, 建议使用群集名称 (例如, $cluster. 密匙环), 并将其保存在 ceph 目录中, 以便密匙环配置默认设置将拾取文件名而不要求您在 Ceph 配置文件的本地副本中指定它。例如, 通过执行以下操作创建 ceph. 密匙环:
sudo ceph-authtool -C /etc/ceph/ceph.keyring
在与单个用户创建密匙环时, 建议使用群集名称、用户类型和用户名, 并将其保存在/等/ceph 目录中。例如, ceph.client.admin.keyring 为客户端. admin 用户。
要创建一个密匙环/等/ceph, 你必须这样做根。这意味着该文件将仅对 root 用户具有 rw 权限, 这在密匙环包含管理员键时是适当的。但是, 如果您打算为特定用户或用户组使用密匙环, 请确保执行 chown 或 chmod 以建立适当的密匙圈所有权和访问权。
把用户加入密钥环
当你在 Ceph 存储集群中创建用户后，你可以用获取用户里面的方法获取此用户、及其密钥、能力，并存入一个密钥环文件。
当您只想在每个密匙环中使用一个用户时, 使用-o 选项的获取用户过程将以密匙密文件格式保存输出。例如, 要为客户端创建一个密匙环. 管理用户, 请执行以下操作:
sudo ceph auth get client.admin -o /etc/ceph/ceph.client.admin.keyring
当您要将用户导入到密匙环时, 您可以使用 ceph authtool 来指定目标keyring和源keyring。例如:
sudo ceph-authtool /etc/ceph/ceph.keyring --import-keyring /etc/ceph/ceph.client.admin.keyring
创建用户
Ceph 提供了创建用户功能, 以便直接在 Ceph 存储群集中创建用户。但是, 您也可以直接在 Ceph 客户端密匙环上创建用户、键和功能。然后, 您可以将用户导入到 Ceph 存储群集。例如:
sudo ceph-authtool -n client.ringo --cap osd 'allow rwx' --cap mon 'allow rwx' /etc/ceph/ceph.keyring
您还可以创建一个密匙环, 并同时向密匙环添加一个新用户。例如:
sudo ceph-authtool -C /etc/ceph/ceph.keyring -n client.ringo --cap osd 'allow rwx' --cap mon 'allow rwx' --gen-key
修改用户属性
要修改keyring中的用户记录的功能, 请指定keyring, 然后使用该功能。例如:
sudo ceph-authtool /etc/ceph/ceph.keyring -n client.ringo --cap osd 'allow rwx' --cap mon 'allow rwx'
要将用户更新到 Ceph 存储群集, 您必须将keyring中的用户更新为 Ceph 存储群集中的用户条目。
sudo ceph auth import -i /etc/ceph/ceph.keyring
命令行用法
Ceph 支持用户名和密钥的下列用法：
--id | --user 描述: Ceph 用一个类型和 ID（ 如 TYPE.ID 或 client.admin 、 client.user1 ）来标识用户， id 、 name 、和 -n 选项可用于指定用户名（如 admin 、 user1 、 foo 等）的 ID 部分，你可以用 --id 指定用户并忽略类型，例如可用下列命令指定 client.foo 用户： ceph --id foo --keyring /path/to/keyring health ceph --user foo --keyring /path/to/keyring health
--name | -n 描述: Ceph 用一个类型和 ID （如 TYPE.ID 或 client.admin 、 client.user1 ）来标识用户， --name 和 -n 选项可用于指定完整的用户名，但必须指定用户类型（一般是 client ）和用户 ID ，例如： ceph --name client.foo --keyring /path/to/keyring health ceph -n client.foo --keyring /path/to/keyring health
--keyring 描述: 包含一或多个用户名、密钥的密钥环路径。 --secret 选项提供了相同功能，但它不能用于 RADOS 网关，其 --secret 另有用途。你可以用 ceph auth get-or-create 获取密钥环并保存在本地，然后您就可以改用其他用户而无需重指定密钥环路径了。 sudo rbd map --id foo --keyring /path/to/keyring mypool/myimage
局限性
cephx 协议提供 Ceph 客户端和服务器间的相互认证，并没打算认证人类用户或者应用程序。如果有访问控制需求，那必须用另外一种机制，它对于前端用户访问 Ceph 对象存储可能是特定的，其任务是确保只有此机器上可接受的用户和程序才能访问 Ceph 的对象存储。
用于认证 Ceph 客户端和服务器的密钥通常以纯文本存储在权限合适的文件里，并保存于可信主机上。
注意：密钥存储为纯文本文件有安全缺陷，但很难避免，它给了 Ceph 可用的基本认证方法，设置 Ceph 时应该注意这些缺陷
尤其是任意用户、特别是移动机器不应该和 Ceph 直接交互，因为这种用法要求把明文认证密钥存储在不安全的机器上，这些机器的丢失、或盗用将泄露可访问 Ceph 集群的密钥。
相比于允许潜在的欠安全机器直接访问 Ceph 对象存储，应该要求用户先登录安全有保障的可信机器，这台可信机器会给人们存储明文密钥。未来的 Ceph 版本也许会更彻底地解决这些特殊认证问题。
当前，没有任何 Ceph 认证协议保证传送中消息的私密性。所以，即使物理线路窃听者不能创建用户或修改它们，但可以听到、并理解客户端和服务器间发送过的所有数据。此外， Ceph 没有可加密用户数据的选项，当然，用户可以手动加密、然后把它们存在对象库里，但 Ceph 没有自己加密对象的功能。在 Ceph 里存储敏感数据的用户应该考虑存入 Ceph 集群前先加密。
3620
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
