用于管理任何規模集群的十個必要的Ceph命令
如果遵循部署和維護的最佳實踐，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/
