如果遵循部署和维护的最佳实践，Ceph将变得很简单和容易操作。以下是我们日常去管理我们内部和客户的Ceph集群的一些最基本和最有用的命令。
一、status
首先也是最重要的命令是**ceph -s**** 或 **ceph status**，这通常是你在任何Ceph集群中想要运行的第一个命令。输出的内容也包含了许多其他的命令输出并合并到一起，可以查看集群的健康状况、大小、使用量、和任何可能会发生的问题。**
**HEALTH_OK**是你想要找的，这表示你晚上可以睡个好觉了，而不是**HEALTH_WARN**或**HEALTH_ERR**，这可能表示驱动器或节点错误或故障。
其他关键的输出是查看有多少个OSD在线或不在线，有多少服务在运行，例如rgw或cephfs，以及他们是如何运行的。
$ ceph -s
cluster:
id: 7c9d43ce-c945-449a-8a66-5f1407c7e47f
health: HEALTH_OK
services:
mon: 1 daemons, quorum danny-mon (age 2h)
mgr: danny-mon(active, since 2h)
osd: 36 osds: 36 up (since 2h), 36 in (since 2h)
rgw: 1 daemon active (danny-mgr)
task status:
data:
pools: 6 pools, 2208 pgs
objects: 187 objects, 1.2 KiB
usage: 2.3 TiB used, 327 TiB / 330 TiB avail
pgs: 2208 active+clean
二、osd tree
接下来是**ceph osd tree**，它提供了每个OSD的列表还包括类、权重、状态，OSD所在的节点，以及任何重新加权或优先级。在OSD故障的情况下，这是你首先要查看的地方，比如说您需要查看OSD日志或本地节点故障一样，这将为你提供正确的引导。OSD通常根据大小相互加权，因此1T OSD的权重是500G SSD的两倍，以确保集群以相同的速率填满OSD。
如果在tree中特定OSD存在问题，或者是你的集群规模很大，但你需要快速的在不使用grep以及滚动浏览文本输出的情况下找到单个OSD的详细状态，你可以使用osd find，这个命令能够帮助你通过单个命令识别OSD的IP地址和机架位置等。
$ ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 329.69476 root default
-3 109.89825 host danny-1
0 hdd 9.15819 osd.0 up 1.00000 1.00000
1 hdd 9.15819 osd.1 up 1.00000 1.00000
2 hdd 9.15819 osd.2 up 1.00000 1.00000
3 hdd 9.15819 osd.3 up 1.00000 1.00000
4 hdd 9.15819 osd.4 up 1.00000 1.00000
5 hdd 9.15819 osd.5 up 1.00000 1.00000
6 hdd 9.15819 osd.6 up 1.00000 1.00000
-7 109.89825 host danny-2
12 hdd 9.15819 osd.12 up 1.00000 1.00000
13 hdd 9.15819 osd.13 up 1.00000 1.00000
14 hdd 9.15819 osd.14 up 1.00000 1.00000
15 hdd 9.15819 osd.15 up 1.00000 1.00000
16 hdd 9.15819 osd.16 up 1.00000 1.00000
17 hdd 9.15819 osd.17 up 1.00000 1.00000
-5 109.89825 host danny-3
24 hdd 9.15819 osd.24 up 1.00000 1.00000
25 hdd 9.15819 osd.25 up 1.00000 1.00000
26 hdd 9.15819 osd.26 up 1.00000 1.00000
27 hdd 9.15819 osd.27 up 1.00000 1.00000
28 hdd 9.15819 osd.28 up 1.00000 1.00000
$ ceph osd find37
{
"osd": 37,
"ip": "172.16.4.68:6804/636",
"crush_location": {
"datacenter": "pa2.ssdr",
"host": "lxc-ceph-main-front-osd-03.ssdr",
"physical-host": "store-front-03.ssdr",
"rack": "pa2-104.ssdr",
"root": "ssdr"
}
}
三、df
与 *nix df 命令类似，它告诉我们在大多数unix和linux系统中还有多少可用空间，ceph有它自己的df命令，**ceph df**，提供了我们集群中存储量的概览和细节，使用了多少和可用多少，以及它是如何在我们的池和存储中区分的。
使用Ceph时将集群容量填满是一个非常糟糕的主意，当你得到90%!的(MISSING)标记时，你需要添加新的存储设备，并确保以合理的方式添加它以允许重新均衡，如果你的集群有大量活动的会话，这一点是尤为重要的。
$ ceph df
RAW STORAGE:
CLASS SIZE AVAIL USED RAW USED %RAW USED
hdd 330 TiB 327 TiB 2.3 TiB 2.3 TiB 0.69
TOTAL 330 TiB 327 TiB 2.3 TiB 2.3 TiB 0.69
POOLS:
POOL ID PGS STORED OBJECTS USED %USED MAX AVAIL
.rgw.root 1 32 1.2 KiB 4 768 KiB 0 104 TiB
default.rgw.control 2 32 0 B 8 0 B 0 104 TiB
default.rgw.meta 3 32 0 B 0 0 B 0 104 TiB
default.rgw.log 4 32 0 B 175 0 B 0 104 TiB
default.rgw.buckets.index 5 32 0 B 0 0 B 0 104 TiB
default.rgw.buckets.data 6 2048 0 B 0 0 B 0 104 TiB
四、osd pool ls detail
这是一个非常有用的快速查看存储池的命令，但包含有关特定配置的更多信息，理想情况下，我们需要知道这个存储池是纠删码还是三副本，在place内有什么样的crush规则，最小尺寸是多少，在存储池中有多少放置组，以及我们在特定的池中的应用程序。
$ ceph osd pool ls detail
pool 1 '.rgw.root' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 32 pgp_num 32 autoscale_mode warn last_change 64 flags hashpspool stripe_width 0 application rgw
pool 2 'default.rgw.control' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 32 pgp_num 32 autoscale_mode warn last_change 68 flags hashpspool stripe_width 0 application rgw
pool 3 'default.rgw.meta' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 32 pgp_num 32 autoscale_mode warn last_change 73 flags hashpspool stripe_width 0 application rgw
pool 4 'default.rgw.log' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 32 pgp_num 32 autoscale_mode warn last_change 71 flags hashpspool stripe_width 0 application rgw
pool 5 'default.rgw.buckets.index' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 32 pgp_num 32 autoscale_mode warn last_change 76 flags hashpspool stripe_width 0 application rgw
pool 6 'default.rgw.buckets.data' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 2048 pgp_num 2048 autoscale_mode warn last_change 83 lfor 0/0/81 flags hashpspool stripe_width 0 application rgw
五、osd crush rule dump
Crush rules是ceph cluster的核心，crush是ceph放置组算法，规则帮助我们定义如何在集群中放置数据，无论是驱动器、主机、节点、机柜还是数据中心，例如，我们需要强制要求我们的每个站点都需要至少一个数据副本用于镜像存储，我们会为我们的镜像存储池分配一个CRUSH规则来强制执行该行为，而不管我们有多少节点，可能在每一边都有。
crush rule dump 是一个快速获取crush rule列表以及如何在集群中定义他们的好方法，如果我们想要进行更改，我们可以使用大量的CRUSH命令来进行修改，或者，我们可以手动下载下来然后通过反编译的方式以进行手动更改，重新编译并将其推送回我们的集群。
$ ceph osd crush rule dump
[
{
"rule_id": 0,
"rule_name": "replicated_rule",
"ruleset": 0,
"type": 1,
"min_size": 1,
"max_size": 10,
"steps": [
{
"op": "take",
"item": -1,
"item_name": "default"
},
{
"op": "chooseleaf_firstn",
"num": 0,
"type": "host"
},
{
"op": "emit"
}
]
}
]
六、versions
在生产环境中运行分布式集群，一次升级所有内容任何和祈祷不出现问题问题，这显然不是个好注意。为此，每个在ceph内的集群范围的守护进程都有自己的版本并且能独立升级，并使集群保持最新状态，而不会或几乎不中断服务。
只要我们保持版本相互接近，不同版本的守护进程就可以完美的相互协作。这意味可能在升级过程中管理数百个不同的守护进程和各自的版本。输入ceph version ，一个很简单的查看正在运行的特定版本的守护进程实例。
$ ceph versions
{
"mon": {
"ceph version 14.2.15-2-g7407245e7b (7407245e7b329ac9d475f61e2cbf9f8c616505d6) nautilus (stable)": 1
},
"mgr": {
"ceph version 14.2.15-2-g7407245e7b (7407245e7b329ac9d475f61e2cbf9f8c616505d6) nautilus (stable)": 1
},
"osd": {
"ceph version 14.2.15-2-g7407245e7b (7407245e7b329ac9d475f61e2cbf9f8c616505d6) nautilus (stable)": 36
},
"mds": {},
"rgw": {
"ceph version 14.2.15-2-g7407245e7b (7407245e7b329ac9d475f61e2cbf9f8c616505d6) nautilus (stable)": 1
},
"overall": {
"ceph version 14.2.15-2-g7407245e7b (7407245e7b329ac9d475f61e2cbf9f8c616505d6) nautilus (stable)": 39
}
}
七、auth print-key
如果有很多不同的客户端使用集群，我们需要从集群中拿到密钥以便他们进行认证，使用ceph auth print-key命令是一个查看密钥比较好的方法，比通过配置文件获取要好一些。其他有用相关的命令是ceph auth list，这将列出整个集群中和守护进程的所有身份认证密钥的完整列表，以及他们各自的功能。
$ ceph auth print-key client.admin
AQDgrLhg3qY1ChAAzzZPHCw2tYz/o+2RkpaSIg==d
八、crash ls
守护进程崩溃?发生这种情况的原因很多，但是ceph crash ls是首要的查看方法，我们将得到崩溃的线索，然后我们可以进一步的进行诊断，通常他们会有些次要的告警帮助更简单的定位错误，但是crash能够提供严肃的问题，其他一些有用的命令是ceph crash info ，它会给出在问题中的crash ID的更多信息，如果告警不必担心的话，我们将存储所有crash，或已经处理的问题。
$ ceph crash ls
1 daemons have recently crashed
osd.9 crashed on host danny-1 at 2021-03-06 07:28:12.665310Z
九、osd flags
有许多OSD flags是非常有用的，可以在OSDMAP_FLAGS** 查看到完整的列表，这里将一些场景的列出，如下**
- pauserd, pausewr - 不再回应读写请求
- noout - 如果守护进程由于某种原因失效，Ceph不会将OSD视为集群之外。
- nobackfill, norecover, norebalance - 恢复和重新均衡处于关闭状态
我们可以在下边的演示看到如何使用ceph osd set命令设置这些标志，以及这如何影响我们的健康消息传递，另一个有用且相关的命令是通过简单的bash扩展取出过的OSD的能力。
$ ceph osd out {7..11}
marked out osd.7. marked out osd.8. marked out osd.9. marked out osd.10. marked out osd.11.
$ ceph osd set noout
noout is set$ ceph osd set nobackfill
nobackfill is set
$ ceph osd set norecover
norecover is set
$ ceph osd set norebalance
norebalance is set
$ ceph osd set nodown
nodown is set
$ ceph osd set pause
pauserd,pausewr is set
$ ceph health detail
HEALTH_WARN pauserd,pausewr,nodown,noout,nobackfill,norebalance,norecover flag(s) set
OSDMAP_FLAGS pauserd,pausewr,nodown,noout,nobackfill,norebalance,norecover flag(s) set
十、pg dump
所有的数据计划放到Ceph中，它提供了一个抽象层 - 类似数据buckets的bit(不是S3存储桶) - 用于我们的存储，并允许集群轻松决定如何分发数据并对故障做出最佳反应。详细了解我们的放置组是如何在我们的OSD上映射的。或者相反的，我们可以使用pgdump完成两种操作，虽然很多放置组命令可以非常冗长且难以阅读，但ceph pg dump osds可以很好的将其提取到单个窗格中。
$ ceph pg dump osds
dumped osds
OSD_STAT USED AVAIL USED_RAW TOTAL HB_PEERS PG_SUM PRIMARY_PG_SUM
31 70 GiB 9.1 TiB 71 GiB 9.2 TiB [0,1,2,3,4,5,6,8,9,12,13,14,15,16,17,18,19,20,21,22,23,30,32] 175 72
13 70 GiB 9.1 TiB 71 GiB 9.2 TiB [0,1,2,3,4,5,6,7,8,9,10,11,12,14,24,25,26,27,28,29,30,31,32,33,34,35] 185 66
25 77 GiB 9.1 TiB 78 GiB 9.2 TiB [0,1,2,3,4,5,6,12,13,14,15,16,17,18,19,20,21,22,23,24,26] 180 64
32 83 GiB 9.1 TiB 84 GiB 9.2 TiB [0,1,2,3,4,5,6,7,12,13,14,15,16,17,18,19,20,21,22,23,31,33] 181 73
23 102 GiB 9.1 TiB 103 GiB 9.2 TiB [0,1,2,3,4,5,6,7,8,9,10,11,22,24,25,26,27,28,29,30,31,32,33,34,35] 191 69
18 77 GiB 9.1 TiB 78 GiB 9.2 TiB [0,1,2,3,4,5,6,7,8,9,10,11,17,19,24,25,26,27,28,29,30,31,32,33,34,35] 188 67
11 64 GiB 9.1 TiB 65 GiB 9.2 TiB [10,12,21,28,29,31,32,33,34,35] 0 0
8 90 GiB 9.1 TiB 91 GiB 9.2 TiB [1,2,7,9,14,15,21,27,30,33] 2 0
14 70 GiB 9.1 TiB 71 GiB 9.2 TiB [0,1,2,3,4,5,6,7,8,9,10,11,13,15,24,25,26,27,28,29,30,31,32,33,34,35] 177 64
33 77 GiB 9.1 TiB 78 GiB 9.2 TiB [0,1,2,3,4,5,6,12,13,14,15,16,17,18,19,20,21,22,23,32,34] 187 80
3 89 GiB 9.1 TiB 90 GiB 9.2 TiB [2,4,8,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35] 303 74
30 77 GiB 9.1 TiB 78 GiB 9.2 TiB [0,1,2,3,4,5,6,9,12,13,14,15,16,17,18,19,20,21,22,23,29,31] 179 76
15 71 GiB 9.1 TiB 72 GiB 9.2 TiB [0,1,2,3,4,5,6,7,8,10,11,14,16,24,25,26,27,28,29,30,31,32,33,34,35] 178 72
7 70 GiB 9.1 TiB 71 GiB 9.2 TiB [6,8,15,17,30,31,32,33,34,35] 0 0
28 90 GiB 9.1 TiB 91 GiB 9.2 TiB [0,1,2,3,4,5,6,7,9,12,13,14,15,16,17,18,19,20,21,22,23,27,29] 188 73
16 77 GiB 9.1 TiB 78 GiB 9.2 TiB [0,1,2,3,4,5,6,7,8,9,10,11,15,17,24,25,26,27,28,29,30,31,32,33,34,35] 183 66
1 77 GiB 9.1 TiB 78 GiB 9.2 TiB [0,2,8,9,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35] 324 70
26 77 GiB 9.1 TiB 78 GiB 9.2 TiB [0,1,2,3,4,5,6,12,13,14,15,16,17,18,19,20,21,22,23,25,27] 186 61
22 89 GiB 9.1 TiB 90 GiB 9.2 TiB [0,1,2,3,4,5,6,7,8,9,11,21,23,24,25,26,27,28,29,30,31,32,33,34,35] 178 80
0 103 GiB 9.1 TiB 104 GiB 9.2 TiB [1,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35] 308 83
5 70 GiB 9.1 TiB 71 GiB 9.2 TiB [4,6,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35] 312 69
21 77 GiB 9.1 TiB 78 GiB 9.2 TiB [0,1,2,3,4,5,6,7,8,9,10,11,20,22,24,25,26,27,28,29,30,31,32,33,34,35] 187 63
4 96 GiB 9.1 TiB 97 GiB 9.2 TiB [3,5,10,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35] 305 77
34 96 GiB 9.1 TiB 97 GiB 9.2 TiB [0,1,2,3,4,5,6,8,9,12,13,14,15,16,17,18,19,20,21,22,23,33,35] 189 73
17 96 GiB 9.1 TiB 97 GiB 9.2 TiB [0,1,2,3,4,5,6,7,8,9,10,11,16,18,24,25,26,27,28,29,30,31,32,33,34,35] 185 72
24 77 GiB 9.1 TiB 78 GiB 9.2 TiB [0,1,2,3,4,5,6,10,12,13,14,15,16,17,18,19,20,21,22,23,25] 186 73
10 76 GiB 9.1 TiB 77 GiB 9.2 TiB [4,9,11,15,17,18,25,29,34,35] 1 0
27 89 GiB 9.1 TiB 90 GiB 9.2 TiB [0,1,2,3,4,5,6,10,12,13,14,15,16,17,18,19,20,21,22,23,26,28] 185 75
2 77 GiB 9.1 TiB 78 GiB 9.2 TiB [1,3,8,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35] 310 62
19 77 GiB 9.1 TiB 78 GiB 9.2 TiB [0,1,2,3,4,5,6,7,8,9,10,11,18,20,24,25,26,27,28,29,30,31,32,33,34,35] 184 77
20 77 GiB 9.1 TiB 78 GiB 9.2 TiB [0,1,2,3,4,5,6,7,8,9,10,11,19,21,24,25,26,27,28,29,30,31,32,33,34,35] 183 69
35 96 GiB 9.1 TiB 97 GiB 9.2 TiB [0,1,2,3,4,5,6,12,13,14,15,16,17,18,19,20,21,22,23,34] 187 78
9 77 GiB 9.1 TiB 78 GiB 9.2 TiB [1,8,10,12,13,16,21,23,32,35] 1 0
6 83 GiB 9.1 TiB 84 GiB 9.2 TiB [5,7,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35] 323 58
12 89 GiB 9.1 TiB 90 GiB 9.2 TiB [0,1,2,3,4,5,6,8,9,10,11,13,24,25,26,27,28,29,30,31,32,33,34,35] 189 78
29 64 GiB 9.1 TiB 65 GiB 9.2 TiB [0,1,2,3,4,5,6,9,12,13,14,15,16,17,18,19,20,21,22,23,28,30] 185 74
sum 2.8 TiB 327 TiB 2.9 TiB 330 TiB
使用这些基本的命令，您可以很好的处理日常Ceph集群管理。借助HyperDrive存储管理器，你可以更轻松一些。
就像孩子在使用计算器之前学习如何在纸上进行加法、减法、除法和乘法一样，任何Ceph管理员都必须了解这些关键的Ceph命令，但是一旦他们掌握在您的掌控之下，那么为什么不使用HyperDrive Storage Manager让集群管理更加简单/或将简单的管理任务委托给团队中不太精通的人呢?
HyperDrive Storage Manager是一个功能强大、统一且直观的系统，它从根本上简化了对所有Ceph软件和存储硬件的管理，无论他们是HyperDrive还是通用存储。
原文：https://softiron.com/blog/10-essential-ceph-commands-for-managing-any-cluster-at-any-scale/
