一旦你有一个可以运行的集群之后，你就可以在集群里执行一些命令来监控集群中的健康状态、对进群进行一些运维操作等。Ceph中提供了一个核心命令ceph，通常默认会被安装在/usr/bin/目录下。Ceph中所有组件的操作，都通过它提供的子命令完成。同时，它也提供两种访问模式，交互模式和普通命令行模式，如下所示：
ceph> health
EALTH_OK
ceph> status
cluster 8b9a9a32-c11b-4719-95fd-8c9aa4730cc9
health HEALTH_OK
monmap e5: 3 mons at {ceph-01=192.168.0.5:6789/0,ceph-02=192.168.0.6:6789/0,ceph-03=192.168.0.7:6789/0}
election epoch 32, quorum 0,1,2 ceph-01,ceph-02,ceph-03
osdmap e42: 3 osds: 3 up, 3 in
pgmap v70: 64 pgs, 1 pools, 0 bytes data, 0 objects
103 MB used, 79726 MB / 79829 MB avail
64 active+clean
ceph> mon_status
{"name":"ceph-02","rank":1,"state":"peon","election_epoch":32,"quorum":[0,1,2],"outside_quorum":[],"extra_probe_peers":[],"sync_provider":[],"monmap":{"epoch":5,"fsid":"8b9a9a32-c11b-4719-95fd-8c9aa4730cc9","modified":"2016-06-22 11:21:01.792270","created":"0.000000","mons":[{"rank":0,"name":"ceph-01","addr":"192.168.0.5:6789\/0"},{"rank":1,"name":"ceph-02","addr":"192.168.0.6:6789\/0"},{"rank":2,"name":"ceph-03","addr":"192.168.0.7:6789\/0"}]}}
一般交互模式的命令，在普通命令行下都能完成。并且普通命令行支持不同的format，可以使得输出结果更加的便于阅读，比如上面执行的mon_status子命令，通过普通命令行能够显示的更加优雅。
# ceph mon_status
-f json-pretty
{
"name": "ceph-03",
"rank": 2,
"state": "peon",
"election_epoch": 32,
"quorum": [
0,
1,
2
],
"outside_quorum": [],
"extra_probe_peers": [],
"sync_provider": [],
"monmap": {
"epoch": 5,
"fsid": "8b9a9a32-c11b-4719-95fd-8c9aa4730cc9",
"modified": "2016-06-22 11:21:01.792270",
"created": "0.000000",
"mons": [
{
"rank": 0,
"name": "ceph-01",
"addr": "192.168.0.5:6789\/0"
},
{
"rank": 1,
"name": "ceph-02",
"addr": "192.168.0.6:6789\/0"
},
{
"rank": 2,
"name": "ceph-03",
"addr": "192.168.0.7:6789\/0"
}
]
}
}
目前ceph的命令输出支持以下几种格式：
# ceph --help|grep format
-f {json,json-pretty,xml,xml-pretty,plain}, --format {json,json-pretty,xml,xml-pretty,plain}
以下将以普通命令行的方式，介绍集群中常用的命令。
基本的集群是由Monitor和OSD组成的，如果您使用了对象存储服务那么集群中还有RGW服务的存在，如果您使用了文件服务则还需要注意MDS的状态。在使用集群提供的存储服务之前，要确保集群的整体状态是正常的，具体可以通过以下命令完成：
# ceph health
HEALTH_OK
当然，如果集群当前状态不是OK的，可以通过以下命令显示较为详细的信息。
# ceph health detail
如果您在安装时，修改了配置文件或者密钥的路径，那么在执行命令时需要指定现在的路径。
# ceph -c /path/to/conf -k /path/to/keyring health
如果要观察集群中当前发生的事件，可以通过以下命令查看
# ceph -w
cluster 8b9a9a32-c11b-4719-95fd-8c9aa4730cc9
health HEALTH_OK
monmap e5: 3 mons at
{ceph-01=192.168.0.5:6789/0,ceph-02=192.168.0.6:6789/0,ceph-03=192.168.0.7:6789/0}
election epoch 32, quorum 0,1,2 ceph-01,ceph-02,ceph-03
osdmap e46: 3 osds: 3 up, 3 in
pgmap v86: 64 pgs, 1 pools, 24 bytes data, 3 objects
104 MB used, 79725 MB / 79829 MB avail
64 active+clean
2016-06-22 15:47:55.718646 mon.0 [INF] pgmap v86: 64 pgs: 64 active+clean; 24 bytes data,
104 MB used, 79725 MB / 79829 MB avail
2016-06-22 15:48:15.164651 mon.0 [INF] pgmap v87: 64 pgs: 64 active+clean; 277 MB data, 104 MB used, 79725
MB / 79829 MB avail; 39 B/s rd, 5694 B/s wr, 2 op/s
2016-06-22 15:48:16.230646 mon.0 [INF] pgmap v88: 64 pgs: 64 active+clean; 669 MB data,
115 MB used, 79714 MB / 79829 MB avail; 199 B/s rd, 68381 B/s wr, 33 op/s
2016-06-22 15:48:20.167758 mon.0 [INF] pgmap v89: 64 pgs: 64 active+clean; 1085 MB data,
128 MB used, 79701 MB / 79829 MB avail; 3890 B/s rd, 338 kB/s wr, 173 op/s
2016-06-22 15:48:21.241525 mon.0 [INF] pgmap v90: 64 pgs: 64 active+clean; 1398 MB data,
137 MB used, 79692 MB / 79829 MB avail; 3887 B/s rd, 340 kB/s wr, 174 op/s
输出的信息里包括：
- 集群唯一标识符
- 集群健康状况
- monitor视图版本、monitor个数以及每个monitor的信息、monitor法定小组选举版本以及当前法定小组成员
- osd视图版本、当前osd个数以及状态
- pg视图版本、pg个数、存储池个数以及当前存储池中的数据和对象数量的统计。
- pg的状态信息
如果集群的健康状况是HEALTH_OK，则集群的状态一定是正常的，接下来介绍monitor、osd、pg的视图状态。
Monitor作为集群的管理者维护了整个集群的状态信息，并保证在某一时刻集群中所有信息大家都是达成一致的，所以在生产的集群中monitor一般会通过设置多个来避免单点故障问题。如果您的集群中有超过1个的monitor时，那么多个monitor会形成一个法定小组，当小组内的成员必须超过monitor个数的一半时，整个集群才能对外提供服务。
要检查当前集群中的monitor，可以通过以下命令中的任意一个完成：
# ceph mon stat
# ceph -s
# ceph status
以上命令也包含了monitor法定小组的基本信息，如果需要获得更为详细的法定小组的信息，可以通过以下命令：
# ceph
quorum_status -f json-pretty
{
"election_epoch": 32,
"quorum": [
0,
1,
2
],
"quorum_names": [
"ceph-01",
"ceph-02",
"ceph-03"
],
"quorum_leader_name": "ceph-01",
"monmap": {
"epoch": 5,
"fsid": "8b9a9a32-c11b-4719-95fd-8c9aa4730cc9",
"modified": "2016-06-22 11:21:01.792270",
"created": "0.000000",
"mons": [
{
"rank": 0,
"name": "ceph-01",
"addr": "192.168.0.5:6789\/0"
},
{
"rank": 1,
"name": "ceph-02",
"addr": "192.168.0.6:6789\/0"
},
{
"rank": 2,
"name": "ceph-03",
"addr": "192.168.0.7:6789\/0"
}
]
}
}
OSD作为集群数据的存储者，它的状态分为两个维度。可以是活着且在运行（up）或挂了且不在运行（down）也可以是在集群内（in）或集群外（out）、也。如果一个OSD活着，它也可以是in（可以读写数据）或者 out 集群。如果它以前是in但最近out了，Ceph 会把其归置组迁移到其他 OSD 。如果一个OSD out 了， CRUSH 就不会再分配归置组给它。如果它挂了（down）并且在规定的时间内没有恢复成up，其状态也会被置为out 。
OSD的状态可以通过以下命令获得：
# ceph osd stat
# ceph -s
# ceph status
当一个集群正常工作是，它的in的OSD个数应该是等于up的OSD个数。如果in的OSD个数大于up的OSD个数，说明有OSD的状态为down，那么你可以通过service ceph start osd.[instance]的命令启动它.
另外，通过以下命令也可以显示OSD的状态：
# ceph osd tree
ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1 0.07999 root default
-2 0.01999 host ceph-02
0 0.01999 osd.0 up 1.00000 1.00000
-3 0.03000 host ceph-01
3 0.03000 osd.3 up 1.00000 1.00000
-4 0.03000 host ceph-03
4 0.03000 osd.4 up 1.00000 1.00000
其中reweight列的值表示了OUT/IN的状态。如果你精心设计了CRUSH分级结构（后面会介绍如何管理CRUSH分级结构），那么当OSD出现故障的时候从这里你能快速找到OSD的物理位置，加快排查。
当你在检查集群状态时，发现集群不处于HEALTH_OK状态，并且所有的Monitor和OSD的状态都是正常时，你还需要确认PG的状态。
PG是Ceph数据存储的最小管理单元，在创建资源池时需要指定资源池包含的PG的个数。当向资源池中写入数据时，首先这些数据会被切分成一个或者多个Object，然后Object会通过Hash映射到一个或者多个PG上。PG经过CRUSH算法就会对应到一组OSD上，也就是PG中包含的Object最终会存储在这些OSD上。
可以通过以下命令查看，集群中所有PG的状态：
# ceph pg stat
v121: 64 pgs: 64 active+clean; 1398 MB data, 129 MB used, 79700 MB / 79829 MB avail
其中如果PG的状态均为active+clean，表示集群状态正常，如果包含以下几种状态，则说明集群正在恢复或者处于异常状态。
通过以下命令可以dump出集群中所有PG的详细信息：
# ceph pg dump
dumped all in format plain
version 127
stamp 2016-06-22 23:03:30.468568
last_osdmap_epoch 46
last_pg_scan 1
full_ratio 0.95
nearfull_ratio 0.85
pg_stat objects mip degr misp unf bytes log disklog state state_stamp v reported up up_primary acting acting_primary last_scrub scrub_stamp last_deep_scrub deep_scrub_stamp
0.22 14 0 0 0 0 31178752 17 17 active+clean 2016-06-22 15:43:51.085300 46'17 46:54 [4,3,0] 4 [4,3,0] 4 0'0 2016-06-21 23:29:16.926924 0'0 2016-06-21 23:29:16.926924
0.21 8 0 0 0 0 19513344 9 9 active+clean 2016-06-22 15:43:50.956897 46'9 46:35 [3,4,0] 3 [3,4,0] 3 0'0 2016-06-21 23:29:16.926923 0'0 2016-06-21
23:29:16.926923
0.20 12 0 0 0 0 28377088 14 14 active+clean 2016-06-22 15:43:50.956691 46'14 46:40 [3,0,4] 3 [3,0,4] 3 0'0 2016-06-21 23:29:16.926923 0'0 2016-06-21 23:29:16.926923
0.1f 9 0 0 0 0 24100864 9 9 active+clean 2016-06-22 15:43:51.085185 46'9 46:38 [4,0,3] 4 [4,0,3] 4 0'0 2016-06-21 23:29:16.926922 0'0 2016-06-21 23:29:16.926922
......
以上的输出结果比较难以阅读，一般我们会关注如下几列：
- pg_stat，PG的唯一标识，以｛poolid｝.{pgid}的形式存在。通过ceph osd lspools可以查看pool以及poolid信息，pgid是一个16进制的数字。
- objects，当前PG中包含的object个数。
- state，PG当前的状态，如上例中active+clean，表示正常。
- v，PG的版本信息
- up/acting , up_primary/acting_primary，表示PG映射到的对应的up set 和acting set OSD集合， 而up_primary和acting_primary分别指的是up set和acting set中的primary OSD。通常情况下，up set和acting set是相同的。up set中的OSD是PG通过CRUSH算法算出来的集合，而当up_primary因为缺少数据而需要进行数据同步时，monitor会临时调整Primary OSD，从所有有数据的OSD中选择一个作为临时的Primary OSD，而这个临时的OSD set就叫做acting set，临时的Primary OSD就是acting_primary。
如果想让输出结果可读性更高，可以使用json-pretty这种输出格式。
# ceph pg dump -o {filename} -f json-pretty
另外，可以通过以下命令查看某个PG各阶段的具体状态。
# ceph pg 0.23 query
{
"state": "active+clean",
"snap_trimq": "[]",
"epoch": 46,
"up": [
3,
4,
0
],
"acting": [
3,
4,
0
],
"actingbackfill": [
"0",
"3",
"4"
],
"info": {
"pgid": "0.23",
"last_update": "46'11",
"last_complete": "46'11",
...
"history": {
"epoch_created": 1,
"last_epoch_started": 44,
...
"last_deep_scrub_stamp": "2016-06-21 23:29:16.926924",
"last_clean_scrub_stamp": "0.000000"
},
"stats": {
"version": "46'11",
"reported_seq": "37",
"reported_epoch": "46",
"state": "active+clean",
...
"stats_invalid": "0",
"stat_sum": {
"num_bytes": 19570688,
"num_objects": 8,
...
"num_bytes_hit_set_archive": 0
},
"up": [
3,
4,
0
],
"acting": [
3,
4,
0
],
"blocked_by": [],
"up_primary": 3,
"acting_primary": 3
},
"empty": 0,
...
"hit_set_history": {
"current_last_update": "0'0",
...
"history": []
}
},
"peer_info": [
{
"peer": "0",
"pgid": "0.23",
"last_update": "46'11",
"last_complete": "46'11",
"log_tail": "0'0",
...
}
],
...
}
以上的输出结果相比于ceph pg dump的输出又多了几项：
- info，纪录了主PG的详细信息，包括PG上次处于数据完成同步的版本号（last_complete）和上次已经完成本地更新的版本号（last_update），这两个主要用于PG之间数据一致性的协商。还有PG的一些历史信息以及统计信息。
- peer_info，如果采用副本机制，这部分会纪录所有peer的信息，其内容和主PG的内容类似。
- recovery_state，纪录了recovery过程中进行recovery和backfill的进程以及参与者信息，同时还包含PG进行scrub的信息。每个PG都会维护一个pg_log，用于纪录该PG上所产生的更新操作（写、删除、更新）等，如果recovery过程，能够通过比对所有peer的pg_log达成一致进行恢复，那么就进行recovery操作，如果peer之间数据差异较大，无法通过pg_log计算出数据差异，则主PG会主导缺失数据的PG进行backfill操作。
这里再介绍一下peer，在采用3副本机制的集群中，写入数据时，PG必须处于active、而且应该是clean状态。为了确保所有副本之间的数据是一致的，一般PG的主OSD，也就是PG对应的acting set中的第一个OSD，会进行协调管理的工作，和第二、第三个OSD（即上面提到的peer）建立连接，并且保证这三个OSD上的PG的当前状态达成一致。
在检查PG的状态时，并不是一直处于active+clean的状态，当集群异常时，你也会看到其他的一些状态。
这里介绍一下常见的状态：
- creating，当你创建存储池时，会创建存储池对应的PG。Ceph在创建PG时，对应的PG会进入creating状态。PG会在的acting set中所有的OSD上都进行创建。
- peering，一旦所有PG都创建成功之后，主OSD将会和它的peer进行同步，即进入peering状态。peering过程主要是保证所有PG中的数据能够协商一致，生成一份权威数据，并且按照这个权威数据进行数据同步。peering过程结束之后，PG的状态会被设置为active。
- active，说明PG中的数据已经比对出来了，如果主OSD上的PG和peer上的PG的数据一致，则这个PG将会进入clean状态。如果有数据不一致，主OSD上的PG知道哪些peer上有数据缺失，它会主导其他peer的数据恢复，这时PG可能会进入recovery或者backfill状态。
- recovery，如果主OSD上的PG能够通过pg_log进行恢复，则PG会进入recovery状态。
- backfill，如果主OSD上的PG不能通过pg_log进行恢复，则PG会进入backfill状态，主PG会依次比对所有PG的数据，如果不一致，则peer会进行全量数据恢复。
- degraded，如果存放PG数据的OSD出现Down的状态时，对应的PG会进入degraded状态。
- undersized，该状态和degraded的类似，唯一的区别是处于degraded的PG，存放它的数据的OSD可以在整个集群中找到副本个，而处于undersized状态的PG，则找不到。
- remapped，负责某一个PG的acting set变更时，数据要从旧的OSD set迁移到新的OSD set中去。新的主OSD还需要一段时间完成数据同步之后，才能提供服务，所以老的主OSD还要持续提供服务，这时PG会处于remapped状态。
- stale，当存储PG的所有OSD都处于Down状态时，PG会进入该状态。
- down+peering，PG在peering过程无法获取所有PG的信息。
- incomplete，PG无法在peering过程中获取权威log信息。
如果您开启了CephFS的服务，那么您还需要检查MDS的服务状态。MDS维护了CephFS文件系统中的层级结构以及文件的一些访问权限等信息。可以通过如下命令查看集群MDS的信息。
# ceph -s
# ceph mds stat
注意，如果您只是启动了MDS服务，但没有创建任何文件系统时，mds是不工作的，即不处于active状态。所以这个时候，您在ceph -s的输出看不到mds的信息，在ceph mds stat的输出中会看到没有up的mds。
# ceph mds stat
e9: 0/0/0 up
当您执行如下命令创建了一个文件系统之后，您会发现mds的状态变为up:active了。
# ceph osd pool create cephfs_data 64 64
# ceph osd pool create cephfs_metadata 64 64
# ceph fs new cephfs cephfs_metadata cephfs_data
# ceph mds stat
e13: 1/1/1 up {0=ceph-03=up:active}
当然您也可以通过如下命令查看所有mds的详细信息。
# ceph mds dump
dumped mdsmap epoch 13
epoch 13
flags 0
created 2016-06-23 19:06:14.132631
modified 2016-06-23 19:06:16.326815
tableserver 0
root 0
session_timeout 60
session_autoclose 300
max_file_size 1099511627776
last_failure 0
last_failure_osd_epoch 0
compat compat={},rocompat={},incompat={1=base v0.20,2=client writeable ranges,3=default file layouts on dirs,4=dir inode in separate object,5=mds uses versioned encoding,6=dirfrag is stored in omap,8=no anchor table}
max_mds 1
in 0
up {0=74594}
failed
stopped
data_pools 2
metadata_pool 3
inline_data disabled
74594: 192.168.0.7:6804/3779 'ceph-03' mds.0.2 up:active seq 75
这里介绍一下MDS常见的几种状态：
- up:active，正常状态。
- up:active(laggy or crashed)，有MDS进程挂掉了。
- failed
- slave