用于管理任何规模集群的十个必要的Ceph命令
2022-03-31 08:45:16来源：新钛云服
如果遵循部署和维护的最佳实践，Ceph将变得很简单和容易操作。以下是我们日常去管理我们内部和客户的Ceph集群的一些最基本和最有用的命令。
一、status首先也是最重要的命令是**ceph -s**** 或 **ceph status**，这通常是你在任何Ceph集群中想要运行的第一个命令。输出的内容也包含了许多其他的命令输出并合并到一起，可以查看集群的健康状况、大小、使用量、和任何可能会发生的问题。**
**HEALTH_OK**是你想要找的，这表示你晚上可以睡个好觉了，而不是**HEALTH_WARN**或**HEALTH_ERR**，这可能表示驱动器或节点错误或故障。
其他关键的输出是查看有多少个OSD在线或不在线，有多少服务在运行，例如rgw或cephfs，以及他们是如何运行的。
$ ceph -scluster: id: 7c9d43ce-c945-449a-8a66-5f1407c7e47f health: HEALTH_OKservices: 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 treeID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF-1 329.69476 root default-3 109.89825 host danny-10 hdd 9.15819 osd.0 up 1.00000 1.000001 hdd 9.15819 osd.1 up 1.00000 1.000002 hdd 9.15819 osd.2 up 1.00000 1.000003 hdd 9.15819 osd.3 up 1.00000 1.000004 hdd 9.15819 osd.4 up 1.00000 1.000005 hdd 9.15819 osd.5 up 1.00000 1.000006 hdd 9.15819 osd.6 up 1.00000 1.00000-7 109.89825 host danny-212 hdd 9.15819 osd.12 up 1.00000 1.0000013 hdd 9.15819 osd.13 up 1.00000 1.0000014 hdd 9.15819 osd.14 up 1.00000 1.0000015 hdd 9.15819 osd.15 up 1.00000 1.0000016 hdd 9.15819 osd.16 up 1.00000 1.0000017 hdd 9.15819 osd.17 up 1.00000 1.00000-5 109.89825 host danny-324 hdd 9.15819 osd.24 up 1.00000 1.0000025 hdd 9.15819 osd.25 up 1.00000 1.0000026 hdd 9.15819 osd.26 up 1.00000 1.0000027 hdd 9.15819 osd.27 up 1.00000 1.0000028 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 dfRAW 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.69POOLS: 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 detailpool 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 rgwpool 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 rgwpool 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 rgwpool 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 rgwpool 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 rgwpool 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.adminAQDgrLhg3qY1ChAAzzZPHCw2tYz/o+2RkpaSIg==d八、crash ls
守护进程崩溃?发生这种情况的原因很多，但是ceph crash ls是首要的查看方法，我们将得到崩溃的线索，然后我们可以进一步的进行诊断，通常他们会有些次要的告警帮助更简单的定位错误，但是crash能够提供严肃的问题，其他一些有用的命令是ceph crash info ，它会给出在问题中的crash ID的更多信息，如果告警不必担心的话，我们将存储所有crash，或已经处理的问题。
$ ceph crash ls1 daemons have recently crashedosd.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 nooutnoout is set$ ceph osd set nobackfillnobackfill is set$ ceph osd set norecovernorecover is set$ ceph osd set norebalancenorebalance is set$ ceph osd set nodownnodown is set$ ceph osd set pausepauserd,pausewr is set$ ceph health detailHEALTH_WARN pauserd,pausewr,nodown,noout,nobackfill,norebalance,norecover flag(s) setOSDMAP_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 osdsdumped osdsOSD_STAT USED AVAIL USED_RAW TOTAL HB_PEERS PG_SUM PRIMARY_PG_SUM31 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 7213 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 6625 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 6432 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 7323 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 6918 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 6711 64 GiB 9.1 TiB 65 GiB 9.2 TiB [10,12,21,28,29,31,32,33,34,35] 0 08 90 GiB 9.1 TiB 91 GiB 9.2 TiB [1,2,7,9,14,15,21,27,30,33] 2 014 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 6433 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 803 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 7430 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 7615 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 727 70 GiB 9.1 TiB 71 GiB 9.2 TiB [6,8,15,17,30,31,32,33,34,35] 0 028 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 7316 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 661 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 7026 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 6122 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 800 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 835 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 6921 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 634 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 7734 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 7317 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 7224 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 7310 76 GiB 9.1 TiB 77 GiB 9.2 TiB [4,9,11,15,17,18,25,29,34,35] 1 027 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 752 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 6219 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 7720 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 6935 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 789 77 GiB 9.1 TiB 78 GiB 9.2 TiB [1,8,10,12,13,16,21,23,32,35] 1 06 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 5812 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 7829 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 74sum 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/
