管理指南 - SUSE Enterprise Storage 6 · 目錄關於本指南xvii I 叢集管理 1 1 使用者權限和指令提示2 1.1 與 Salt/DeepSea 相關的指令 2 1.2 與 Ceph 相關的指令

管理指南

SUSE Enterprise Storage 6

管理指南SUSE Enterprise Storage 6原著：Tomáš Bažant、Jana Haláčková、Alexandra Settle、Sven Seeberg

出版日期：05/22/2020

SUSE LLC

1800 South Novell Place

Provo, UT 84606

USA

https://documentation.suse.com

Copyright © 2020 SUSE LLC

版權所有 © 2016，RedHat, Inc 和參與者。

本文件中的文字和圖示已獲 Creative Commons Attribution-Share Alike 4.0 International (簡稱

「CC-BY-SA」) 授權。http://creativecommons.org/licenses/by-sa/4.0/legalcode 上提供了 CC-BY-

SA 的說明。根據 CC-BY-SA 的政策，如果您配送本文件或對其進行改編，則必須提供原始版本的 URL。

Red Hat、Red Hat Enterprise Linux、Shadowman 標誌、JBoss、MetaMatrix、Fedora、Infinity 標誌

和 RHCE 是 Red Hat, Inc. 在美國與其他國家/地區的註冊商標。Linux® 是 Linus Torvalds 在美國與

其他國家/地區的註冊商標。Java® 是 Oracle 和/或其關係企業的註冊商標。XFS® 是 Silicon Graphics

International Corp. 或其子公司在美國和/或其他國家/地區的商標。所有其他商標均為其各自擁有者的

財產。

如需 SUSE 商標，請參閱 http://www.suse.com/company/legal/ 。所有其他協力廠商的商標所有權分屬

其各自的公司。®、™ 等商標符號表示 SUSE 及其關係企業的商標。星號 (*) 表示協力廠商的商標。

https://documentation.suse.com

http://creativecommons.org/licenses/by-sa/4.0/legalcode

http://www.suse.com/company/legal/

本手冊中所有資訊在編輯時，都已全力注意各項細節。但這不保證百分之百的正確性。因此，SUSE LLC 及

其關係企業、作者或譯者都不需對任何錯誤或造成的結果負責。

目錄

關於本指南 xvii

I 叢集管理 1

1 使用者權限和指令提示 21.1 與 Salt/DeepSea 相關的指令 2

1.2 與 Ceph 相關的指令 2

1.3 一般的 Linux 指令 3

1.4 其他資訊 3

2 Salt 叢集管理 4

2.1 新增新的叢集節點 4

2.2 新增新的角色至節點 6

2.3 移除和重新安裝叢集節點 7

2.4 重新部署監控程式節點 9

2.5 新增 OSD 磁碟至節點 10

2.6 移除 OSD 11

移除多個 OSD 11 • 移除主機上的所有 OSD 12 • 強制移除已中止

的 OSD 12 • 驗證 OSD LVM 中繼資料 12

2.7 更換 OSD 磁碟 14

2.8 復原重新安裝的 OSD 節點 15

2.9 將管理節點移至新伺服器 16

2.10 透過 Salt 實現自動安裝 17

iv 管理指南

2.11 更新叢集節點 18

軟體儲存庫 18 • 儲存庫分段 18 • zypper patch 或 zypper

dup 19 • 叢集節點重新開機 19 • Ceph 服務停機時間 19 • 執行

更新 19

2.12 將叢集停止或重新開機 20

2.13 使用自訂設定調整 ceph.conf 21

覆寫預設值 22 • 加入組態檔案 23

2.14 啟用 AppArmor 設定檔 24

2.15 停用調整後的設定檔 25

2.16 移除整個 Ceph 叢集 25

3 備份叢集組態和資料 27

3.1 備份 Ceph 組態 27

3.2 備份 Salt 組態 27

3.3 備份 DeepSea 組態 27

3.4 備份自訂組態 28

II 操作叢集 29

4 簡介 30

5 操作 Ceph 服務 31

5.1 使用 systemd 操作與 Ceph Cluster 相關的服務 31

使用目標啟動、停止和重新啟動服務 31 • 啟動、停止和重新啟動個

別服務 32 • 識別個別服務 32 • 服務狀態 33

5.2 使用 DeepSea 重新啟動 Ceph 服務 33

重新啟動所有服務 33 • 重新啟動特定服務 34

5.3 正常關閉整個 Ceph 叢集 35

v 管理指南

6 確定叢集狀態 36

6.1 檢查叢集的狀態 36

6.2 檢查叢集狀態 37

6.3 監看叢集 45

6.4 檢查叢集的使用量統計資料 47

6.5 檢查 OSD 狀態 48

6.6 檢查填滿的 OSD 49

6.7 檢查監控程式狀態 50

6.8 檢查放置群組狀態 51

6.9 使用管理通訊端 51

6.10 儲存容量 51

6.11 監控 OSD 和放置群組 54

監控 OSD 54 • 放置群組集 55 • 建立互聯 56 • 監控放置群組狀

態 57 • 識別存在問題的放置群組 62 • 尋找物件位置 62

6.12 OSD 未在執行 63

OSD 不啟動 63 • OSD 發生故障 64 • 無可用磁碟空間 64

7 監控和警示 66

7.1 Pillar 變數 66

7.2 Grafana 67

7.3 Prometheus 67

7.4 Alertmanager 68

組態檔案 68 • 自訂警示 80 • SNMP 設陷接收器 82

8 使用 cephx 進行驗證 83

8.1 驗證架構 83

vi 管理指南

8.2 金鑰管理 85

背景資訊 86 • 管理使用者 89 • 金鑰圈管理 93 • 指令行用

法 95

9 儲存的資料管理 97

9.1 裝置 98

裝置類別 98

9.2 桶 105

9.3 規則集 108

在節點樹中逐一查看 109 • firstn 和 indep 111

9.4 置放群組 112

放置群組的使用方式 112 • 確定 PG_NUM 的值 113 • 設定放置

群組數量 114 • 獲取放置群組數量 115 • 獲取叢集的 PG 統

計資料 115 • 獲取卡住的 PG 統計資料 115 • 獲取放置群組地

圖 116 • 獲取放置群組統計資料 116 • 整理放置群組 116 • 設定放

置群組回填和復原的優先程度 116 • 還原遺失的物件 117

9.5 CRUSH 地圖操作 117

編輯 CRUSH 地圖 117 • 新增/移動 OSD 119 • ceph osd reweight 與

ceph osd crush reweight 之間的差異 119 • 移除 OSD 120 • 新增

桶 120 • 移動桶 120 • 移除桶 121

9.6 整理 121

10 Ceph 管理員模組 124

10.1 平衡器 124

「crush-compat」模式 125 • 資料平衡的規劃和執行 125

10.2 遙測模組 127

11 管理儲存池 129

11.1 將池與應用程式關聯 129

vii 管理指南

11.2 操作池 130

列出池 130 • 建立池 130 • 設定池定額 131 • 刪除池 132 • 重新

命名池 133 • 顯示池統計資料 133 • 獲取池的值 135 • 設定池的

值 135 • 設定物件複本數 138

11.3 池移轉 139

使用快取層移轉 140 • 移轉 RADOS 區塊裝置影像 142

11.4 池快照 143

建立池快照 143 • 列出池的快照 144 • 移除池快照 144

11.5 資料壓縮 144

啟用壓縮 144 • 池壓縮選項 145 • 全域壓縮選項 146

12 RADOS 區塊裝置 148

12.1 區塊裝置指令 148

在複本池中建立區塊裝置影像 148 • 在糾刪碼池中建立區塊裝置影

像 149 • 列出區塊裝置影像 149 • 擷取影像資訊 149 • 調整區塊裝

置影像的大小 150 • 移除區塊裝置影像 150

12.2 掛接和卸載 150

rbdmap：在開機時對應 RBD 裝置 152 • 增大 RBD 裝置的大小 154

12.3 快照 154

Cephx 注意事項 154 • 快照基礎知識 155 • 分層 157

12.4 鏡像 160

rbd-mirror 精靈 161 • 池組態 161 • 影像組態 163 • 鏡像狀

態 165

12.5 快取記憶體設定 166

12.6 QoS 設定 167

12.7 預先讀取設定 168

12.8 進階功能 169

12.9 使用舊核心用戶端對應 RBD 171

viii 管理指南

13 糾刪碼池 172

13.1 糾刪碼池的先決條件 172

13.2 建立範例糾刪碼池 172

13.3 糾刪碼設定檔 173

建立新糾刪碼設定檔 175 • 移除糾刪碼設定檔 176 • 顯示糾刪碼設

定檔的詳細資料 176 • 列出糾刪碼設定檔 177

13.4 含 RADOS 區塊裝置的糾刪碼池 177

14 快取分層 178

14.1 分層儲存的相關術語 178

14.2 需考量的要點 178

14.3 何時使用快取分層 179

14.4 快取模式 179

14.5 糾刪碼池和快取分層 180

14.6 設定範例分層儲存 180

14.7 設定快取層 182

命中集 182 • 快取大小調整 184 • 快取存留期 186 • 範例 186

15 使用 LVM 快取提升效能 188

15.1 先決條件 188

15.2 需考量的要點 188

15.3 準備 189

15.4 設定 LVM 快取 190

新增 LVM 快取 190 • 移除 LVM 快取 190 • 設定 LVM 快取模式 190

15.5 處理故障 191

15.6 常見問答集 191

ix 管理指南

16 Ceph 叢集組態 192

16.1 執行時期組態 192

16.2 Ceph OSD 和 BlueStore 193

自動調整快取大小 193

16.3 Ceph 物件閘道 194

一般設定 194 • HTTP 前端 203

III 存取叢集資料 205

17 Ceph 物件閘道 20617.1 物件閘道限制和命名限制 206

桶限制 206 • 儲存的物件的限制 206 • HTTP 標頭限制 207

17.2 部署物件閘道 207

17.3 操作物件閘道服務 207

17.4 組態選項 208

17.5 管理物件閘道的存取方式 208

存取物件閘道 208 • 管理 S3 和 Swift 帳戶 210

17.6 HTTP 前端 214

17.7 為物件閘道啟用 HTTPS/SSL 214

建立自行簽署的證書 214 • 簡單的 HTTPS 組態 215 • 進階 HTTPS

組態 216

17.8 同步模組 217

一般組態 217 • 同步區域 218 • ElasticSearch 同步模組 220 • 雲

端同步模組 223 • 歸檔同步模組 227

17.9 LDAP 驗證 227

驗證機制 228 • 要求 228 • 將物件閘道設定為使用 LDAP 驗

證 228 • 使用自訂搜尋過濾器來限制使用者存取權 229 • 產生用於

LDAP 驗證的存取記號 230

x 管理指南

17.10 桶索引分區 231

桶索引重新分區 231 • 新桶的桶索引分區 234

17.11 整合 OpenStack Keystone 235

設定 OpenStack 235 • 設定 Ceph 物件閘道 236

17.12 池放置和儲存類別 238

放置目標 238 • 儲存類別 239 • 區域群組/區域組態 239 • 自訂放

置 241 • 使用儲存類別 242

17.13 多站台物件閘道 243

術語 244 • 範例叢集設定 244 • 系統金鑰 244 • 命名慣

例 245 • 預設池 245 • 建立領域 246 • 刪除預設區域群

組 246 • 建立主區域群組 246 • 建立主區域 247 • 建立次要區

域 250 • 將物件閘道新增至第二個叢集 254 • 容錯移轉和災難備

援 257

17.14 使用 HAProxy 在物件閘道伺服器間實現負載平衡 259

18 Ceph iSCSI 閘道 260

18.1 連接 ceph-iscsi 管理的目標 260

Linux (open-iscsi) 260 • Microsoft Windows (Microsoft iSCSI 啟

動器) 263 • VMware 271

18.2 結論 276

19 叢集檔案系統 277

19.1 掛接 CephFS 277

用戶端準備 277 • 建立機密檔案 277 • 掛接 CephFS 278

19.2 卸載 CephFS 279

19.3 /etc/fstab 中的 CephFS 279

19.4 多個使用中 MDS 精靈 (主動/主動 MDS) 280

何時使用主動/主動 MDS 280 • 增加 MDS 使用中叢集的大

小 280 • 減小階層數 281 • 手動將目錄樹關聯到層級 282

xi 管理指南

19.5 管理容錯移轉 283

設定待命精靈 283 • 範例 284

19.6 設定 CephFS 定額 285

限制 285 • 組態 286

19.7 管理 CephFS 快照 286

建立快照 287 • 刪除快照 287

20 透過 Samba 輸出 Ceph 資料 288

20.1 透過 Samba 共用輸出 CephFS 288

Samba 相關的套件安裝 288 • 單一閘道範例 288 • 高可用性組態 290

20.2 將 Samba 閘道加入 Active Directory 中 295

準備 295 • 確認 DNS 295 • 解析 SRV 記錄 296 • 設定

Kerberos 296 • 本地主機名稱解析 297 • 設定 Samba 297 • 加

入 Active Directory 網域 300 • 設定名稱服務參數 301 • 啟動服

務 301 • 測試 winbindd 連接性 302

21 NFS Ganesha：透過 NFS 輸出 Ceph 資料 303

21.1 安裝 303

21.2 組態 303

服務組態 304 • 輸出組態 306

21.3 自訂 NFS Ganesha 角色 308

NFS Ganesha 的不同物件閘道使用者 308 • 分隔 CephFS 和物件閘道

FSAL 310 • 支援操作 311

21.4 啟動或重新啟動 NFS Ganesha 312

21.5 設定記錄層級 312

21.6 驗證輸出的 NFS 共用 312

21.7 掛接輸出的 NFS 共用 312

xii 管理指南

IV 使用圖形使用者介面工具管理叢集 314

22 Ceph Dashboard 31522.1 儀表板的 Web 使用者介面 315

登入 315 • 公用程式功能表 317 • 主功能表 317 • 內容窗

格 318 • 常用 Web UI 功能 318 • 儀表板工具集 319

22.2 管理儀表板使用者和角色 321

列出使用者 321 • 新增新使用者 322 • 編輯使用者 322 • 刪除使用

者 323 • 列出使用者角色 323 • 新增自訂角色 323 • 編輯自訂角

色 325 • 刪除自訂角色 325

22.3 檢視叢集內部 325

叢集節點 325 • Ceph 監控程式 326 • Ceph OSD 326 • 磁簇組

態 329 • CRUSH 地圖 330 • 管理員模組 331 • 記錄 331

22.4 管理池 332

新增新池 333 • 刪除池 334 • 編輯池的選項 334

22.5 管理 RADOS 區塊裝置 334

檢視有關 RBD 的詳細資料 335 • 檢視 RBD 的組態 335 • 建立

RBD 336 • 刪除 RBD 338 • RADOS 區塊裝置快照 338 • 管理 iSCSI

閘道 339 • RBD 服務品質 (QoS) 342 • RBD 鏡像 344

22.6 管理 NFS Ganesha 353

新增 NFS 輸出項 353 • 刪除 NFS 輸出 355 • 編輯 NFS 輸出項 355

22.7 管理 Ceph 檔案系統 356

檢視 CephFS 綜覽 356

22.8 管理物件閘道 357

檢視物件閘道 357 • 管理物件閘道使用者 357 • 管理物件閘道桶 360

22.9 手動組態 362

TLS/SSL 支援 362 • 主機名稱和連接埠號碼 364 • 使用者名稱與密

碼 365 • 啟用物件閘道管理前端 365 • 啟用單一登入 366

xiii 管理指南

22.10 在指令行上管理使用者和角色 367

使用者帳戶 368 • 使用者角色和許可權 368 • 反向代理 372 • 稽

核 372

V 與虛擬化工具整合 374

23 將 libvirt 與 Ceph 搭配使用 375

23.1 設定 Ceph 375

23.2 準備虛擬機器管理員 376

23.3 建立虛擬機器 377

23.4 設定虛擬機器 377

23.5 總結 379

24 Ceph 做為 QEMU KVM 例項的後端 381

24.1 安裝 381

24.2 用法 381

24.3 使用 QEMU 建立影像 381

24.4 使用 QEMU 調整影像大小 382

24.5 使用 QEMU 擷取影像資訊 382

24.6 使用 RBD 執行 QEMU 383

24.7 啟用丟棄功能/TRIM 383

24.8 QEMU 快取選項 384

VI FAQ、提示和故障診斷 385

25 技巧與提示 38625.1 識別未同步分割區 386

25.2 調整整理 386

xiv 管理指南

25.3 在不重新平衡的情況下停止 OSD 387

25.4 節點時間同步 387

25.5 檢查不均衡的資料寫入 389

25.6 Ceph 監控程式節點上 /var/lib/ceph 的 Btrfs 子磁碟區 390

要求 390 • 部署新叢集時所需執行的步驟 391 • 升級叢集時所需執

行的步驟 392 • 手動安裝 392 • 更多資訊 393

25.7 增加檔案描述子 393

25.8 與虛擬化軟體整合 393

在 Ceph 叢集中儲存 KVM 磁碟 393 • 在 Ceph 叢集中儲存 libvirt

磁碟 394 • 在 Ceph 叢集中儲存 Xen 磁碟 394

25.9 Ceph 的防火牆設定 395

25.10 測試網路效能 396

25.11 如何尋找使用 LED 燈的實體磁碟 397

26 常見問答集 402

26.1 放置群組數量對叢集的效能有何影響？ 402

26.2 是否可以在同一叢集上使用 SSD 和普通硬碟？ 402

26.3 在 SSD 上使用記錄存在哪些利弊？ 403

26.4 磁碟出現故障時，會發生什麼情況？ 403

26.5 記錄磁碟出現故障時，會發生什麼情況？ 404

27 疑難排解 405

27.1 報告軟體問題 405

27.2 使用 rados 傳送大型物件失敗，並顯示「OSD 已滿」 405

27.3 XFS 檔案系統損毀 406

27.4 「每個 OSD 的 PG 數過多」狀態訊息 406

xv 管理指南

27.5 「nn pg 停滯在非使用中狀態」狀態訊息 407

27.6 OSD 權數為 0 407

27.7 OSD 停機 408

27.8 尋找執行緩慢的 OSD 408

27.9 解決時鐘偏差警告 409

27.10 網路問題導致叢集效能不佳 409

27.11 /var 空間不足 411

A DeepSea 階段 1 自訂範例 413

B SUSE Enterprise Storage 6 的預設警示 414

C 以上游「Nautilus」小數點版本為基礎的 Ceph維護更新 418

詞彙 421

D 文件更新 424

D.1 SUSE Enterprise Storage 6 的維護更新文件 424

D.2 2019 年 6 月 (SUSE Enterprise Storage 6 發行) 426

xvi 管理指南

關於本指南

SUSE Enterprise Storage 6 是 SUSE Linux Enterprise 15 SP1 的延伸。它結合了

Ceph (http://ceph.com/ ) 儲存專案的功能與 SUSE 的企業工程和支援。憑藉 SUSE

Enterprise Storage 6，IT 組織能夠部署可以支援一些使用商用硬體平台的使用案例

的分散式儲存架構。

本指南可協助您瞭解 SUSE Enterprise Storage 6 的概念，並重點介紹如何管理 Ceph

基礎架構。它還展示了如何將 Ceph 與其他相關解決方案 (例如 OpenStack 或 KVM)

搭配使用。

本手冊的許多章節包含連到其他文件資源的連結。包括系統和網際網路上所提供的其他

文件。

如需適用於產品的文件與最新文件更新的綜覽，請參閱 http://www.suse.com/

documentation 。

1 可用文件針對本產品提供的手冊如下：

管理指南

該指南說明了安裝後一般需要執行的各項管理任務。該指南還介紹了將 Ceph 與

libvirt、Xen 或 KVM 等虛擬化解決方案整合的步驟，以及透過 iSCSI 和 RADOS

閘道存取叢集中儲存之物件的方法。

《部署指南》

引導您完成 Ceph 叢集及 Ceph 所有相關服務的安裝步驟。該指南還展示了基本

Ceph 叢集結構，並提供了相關的術語。

在已安裝系統的 /usr/share/doc/manual 下可以找到產品手冊的 HTML 版本。http://

www.suse.com/documentation 中可以找到最新的文件更新，並可從此處下載多種格

式的產品文件。

2 意見反應以下為可供使用的數種意見回應管道：

xvii 可用文件 SES 6

http://ceph.com/

http://www.suse.com/documentation




錯誤與增強功能要求

有關適用於產品的服務與支援選項，請參閱 http://www.suse.com/support/ 。

若要報告產品元件的錯誤，請登入 Novell Customer Center (http://

www.suse.com/support/ )，然後選取我的支援服務要求。

使用者意見

我們希望得到您對本手冊以及本產品隨附的其他文件的意見和建議。請使用

線上文件每頁底部的「使用者意見」功能，或造訪 http://www.suse.com/

documentation/feedback.html 在其中輸入您的意見。

郵件

如需本產品文件的反饋，您還可以傳送郵件至 [email protected]。請務必包含文

件標題、產品版本以及文件發行日期。若要報告錯誤或對增強功能提出建議，請

提供問題的簡短描述，並指出對應的章節編號及頁碼 (或 URL)。

3 文件慣例

本手冊使用下列印刷慣例：

/etc/passwd：目錄名稱與檔案名稱

placeholder：以實際的值來取代 placeholder

PATH：環境變數 PATH

ls、 --help：指令、選項和參數

user：使用者或群組

Alt 、 Alt – F1 ：供人按下的按鍵或按鍵組合；顯示的按鍵與鍵盤上一樣為大

寫

檔案、檔案另存新檔：功能表項目、按鈕

Dancing Penguins (「Penguins」一章，↑另一本手冊)：這是對另一本手冊中某

一章的參考。

xviii 文件慣例 SES 6

http://www.suse.com/support/



http://www.suse.com/documentation/feedback.html

http://www.suse.com/documentation/feedback.html

4 關於本手冊編寫

本書是採用 GeekoDoc (DocBook 的子集，請參閱 http://www.docbook.org ) 所編

寫。其中 XML 來源檔案已由 xmllint 驗證，經由 xsltproc 處理，而且採用 Norman

Walsh 樣式表的自訂版本轉換成 XSL-FO。可透過 Apache 開發的 FOP 或 RenderX 開

發的 XEP 編排最終 PDF 的格式。套件 daps 中提供了用於製作此手冊的撰寫和發佈

工具。DocBook Authoring and Publishing Suite (DAPS) 以開放原始碼軟體的形式開

發。如需詳細資訊，請參閱 http://daps.sf.net/ 。

5 Ceph 參與者

Ceph 專案及其文件是數百個參與者和組織辛勤工作的成果。請參閱 https://

ceph.com/contributors/ ，以取得詳細資料。

xix 關於本手冊編寫 SES 6

http://www.docbook.org

http://daps.sf.net/

https://ceph.com/contributors/

https://ceph.com/contributors/

I 叢集管理

1 使用者權限和指令提示 2

2 Salt 叢集管理 4

3 備份叢集組態和資料 27

1 使用者權限和指令提示

做為 Ceph 叢集管理員，您需要透過執行特定指令來設定和調整叢集行為。您將需要執

行以下幾種類型的指令：

1.1 與 Salt/DeepSea 相關的指令

這些指令可協助您部署或升級 Ceph 叢集、同時在數個 (或所有) 叢集節點上執

行指令，它們還可在您新增或移除叢集節點時為您提供協助。最常用的指令是

salt、 salt-run 和 deepsea。您需要以 root 身分在 Salt Master 節點上執行 Salt

指令 (如需詳細資料，請參閱《部署指南》, 第 5 章「使用 DeepSea/Salt 部署」,

第 5.2 節「DeepSea 簡介」)。透過以下提示符來引入這些指令：

root@master #

例如：

root@master # salt '*.example.net' test.ping

1.2 與 Ceph 相關的指令

這些是更低層級的指令，可在指令行上設定和微調叢集及其閘道的所有方面，例

如， ceph、 rbd、 radosgw-admin 或 crushtool。

若要執行與 Ceph 相關的指令，您需要擁有 Ceph 金鑰的讀取存取權，而金鑰的功能則

定義您在 Ceph 環境內的權限。一種方案是以 root 身分 (或透過 sudo ) 執行 Ceph

指令，並使用不受限制的預設金鑰圈「ceph.client.admin.key」。

建議您使用更安全的方案，即為每個管理員使用者建立限制性更高的個別金鑰，並將其

存放在使用者可讀取的目錄中，例如：

~/.ceph/ceph.client.USERNAME.keyring

2 與 Salt/DeepSea 相關的指令 SES 6

提示：Ceph 金鑰的路徑若要使用自訂管理員使用者和金鑰圈，每次執行 ceph 指令 (使用 -n

client.USER_NAME 和 --keyring PATH/TO/KEYRING 選項) 時，都需要指定該金鑰

的使用者名稱和路徑。

若要避免此情況，請在 CEPH_ARGS 變數 (位於個別使用者的 ~/.bashrc 檔案

中) 中包含這些選項。

儘管您可以在任何叢集節點上執行與 Ceph 相關的指令，但我們建議您在管理節點上執

行。此文件使用 cephadm 使用者來執行指令，因此透過以下提示符來引入指令：

cephadm@adm >

例如：

cephadm@adm > ceph auth list

提示：特定節點的指令如果文件指示您在叢集節點上以特定角色來執行指令，應透過該提示符來定址。

例如：

cephadm@mon >

1.3 一般的 Linux 指令

與 Ceph 或 DeepSea 無關的 Linux 指令 (例如 mount、 cat 或 openssl ) 透過

cephadm@adm > 或 root # 提示符引入，具體使用哪個提示符取決於相關指令所需的

權限。

1.4 其他資訊

如需 Ceph 金鑰管理的詳細資訊，請參閱第 8.2 節「金鑰管理」。

3 一般的 Linux 指令 SES 6

2 Salt 叢集管理

部署 Ceph 叢集之後，您可能偶爾需要對其進行若干修改。這些修改包括新增或移除新

的節點、磁碟或服務。本章介紹該如何完成這些管理任務。

2.1 新增新的叢集節點新增新節點至叢集的程序與《部署指南》, 第 5 章「使用 DeepSea/Salt 部署」中所

述的初始叢集節點部署程序幾乎完全相同。

提示：防止重新平衡將 OSD 新增至現有叢集時請注意，叢集將在此後的一段時間內進行重新平衡。

為了最大限度地縮短重新平衡的時間，請一次即新增所有要新增的 OSD。

另一種方法是在新增 OSD 之前，在 ceph.conf 檔案中設定 osd crush initial

weight = 0 選項：

1. 將 osd crush initial weight = 0 新增至 /srv/salt/ceph/configuration/

files/ceph.conf.d/global.conf 中。

2. 在 Salt Master 節點上建立新組態：

root@master # salt 'SALT_MASTER_NODE' state.apply ceph.configuration.create

3. 將新組態套用至目標 OSD Minion：

root@master # salt 'OSD_MINIONS' state.apply ceph.configuration

4. 新增新 OSD 之後，視需要使用 ceph osd crush reweight 指令調整其權

數。

1. 在新節點上安裝 SUSE Linux Enterprise Server 15 SP1，並組態其網路設定，

以使其能夠正確解析 Salt Master 主機名稱。確認其正確連接至公用網路和叢集

網路，並且為其正確設定了時間同步。然後安裝 salt-minion 套件：

root@minion > zypper in salt-minion

4 新增新的叢集節點 SES 6

如果 Salt Master 的主機名稱不是 salt，請編輯 /etc/salt/minion 並新增下

面一行：

master: DNS_name_of_your_salt_master

如果您對上面提到的組態檔案進行了任何變更，請重新啟動 salt.minion 服務：

root@minion > systemctl restart salt-minion.service

2. 在 Salt Master 上接受新節點的 Salt 金鑰：

root@master # salt-key --accept NEW_NODE_KEY

3. 確認 /srv/pillar/ceph/deepsea_minions.sls 針對的是新 Salt Minion，以及/或

者設定了正確的 DeepSea 粒紋。如需更多詳細資料，請參閱《部署指南》, 第 5

章「使用 DeepSea/Salt 部署」, 第 5.2.2.1 節「比對 Minion 名稱」或《部署

指南》, 第 5 章「使用 DeepSea/Salt 部署」, 第 5.3 節「叢集部署」, 執行

部署階段。

4. 執行準備階段。該階段會同步模組和粒紋，以使新 Minion 可以提供 DeepSea 所

需的所有資訊。

root@master # salt-run state.orch ceph.stage.0

重要：可能需要重新啟動 DeepSea 階段 0如果 Salt Master 在其核心更新之後進行了重新開機，則您需要重新啟動

DeepSea 階段 0。

5. 執行探查階段。該階段將在 /srv/pillar/ceph/proposals 目錄中寫入新的檔案項

目，您可在其中編輯相關的 .yml 檔案：


6. (選擇性) 如果新增的主機與現有命名規劃不符，請變更 /srv/pillar/ceph/

proposals/policy.cfg。如需詳細資訊，請參閱《部署指南》, 第 5 章「使用

DeepSea/Salt 部署」, 第 5.5.1 節「policy.cfg 檔案」。

7. 執行組態階段。該階段會讀取 /srv/pillar/ceph 下的所有內容，並相應地更新

Pillar：

5 新增新的叢集節點 SES 6


Pillar 用於儲存可以使用以下指令存取的資料：

root@master # salt target pillar.items

提示：修改 OSD 的配置如果您要修改預設的 OSD 配置並變更 DriveGroups 組態，請執

行《部署指南》, 第 5 章「使用 DeepSea/Salt 部署」, 第 5.5.2 節

「DriveGroups」所述的程序。

8. 組態和部署階段包含新增的節點：

root@master # salt-run state.orch ceph.stage.3root@master # salt-run state.orch ceph.stage.4

2.2 新增新的角色至節點

您可透過 DeepSea 部署所有受支援的角色類型。如需受支援角色類型的詳細資訊以及

相符範例，請參閱《部署指南》, 第 5 章「使用 DeepSea/Salt 部署」, 第 5.5.1.2

節「角色指定」。

若要將新服務新增至現有節點，請執行下列步驟：

1. 修改 /srv/pillar/ceph/proposals/policy.cfg，以使現有主機與新角色相符。如

需詳細資料，請參閱《部署指南》, 第 5 章「使用 DeepSea/Salt 部署」, 第

5.5.1 節「policy.cfg 檔案」。例如，如果您需要在 MON 節點上執行物件閘道，

指令行類似下方所示：

role-rgw/xx/x/example.mon-1.sls

2. 執行階段 2 以更新 Pillar：


3. 執行階段 3 以部署核心服務，或者執行階段 4 以部署選擇性服務。同時執行這

兩個階段也沒有問題。

6 新增新的角色至節點 SES 6

2.3 移除和重新安裝叢集節點

提示：暫時移除叢集節點Salt Master 預期叢集中的所有 Minion 都已啟用且能夠回應。如果某個

Minion 由於中斷而不再能夠回應，將會導致 Salt 基礎架構 (主要是 DeepSea

和 Ceph Dashboard) 產生問題。

修復該 Minion 之前，請暫時從 Salt Master 中刪除其金鑰：

root@master # salt-key -d MINION_HOST_NAME

修復 Minion 之後，請再次將其金鑰新增至 Salt Master 中：

root@master # salt-key -a MINION_HOST_NAME

若要從叢集中移除角色，請編輯 /srv/pillar/ceph/proposals/policy.cfg，移除相應

的行。然後依《部署指南》, 第 5 章「使用 DeepSea/Salt 部署」, 第 5.3 節「叢集

部署」所述執行階段 2 和 5。

注意：從叢集中移除 OSD如果您需要從叢集中移除特定 OSD 節點，請確定叢集的可用磁碟空間大於要移

除的磁碟空間。切記，移除 OSD 會導致整個叢集進行重新平衡。

執行階段 5 以進行實際移除之前，一律要檢查 DeepSea 將要移除的是哪些

OSD：

root@master # salt-run rescinded.ids

從 Minion 中移除角色時，其目的是復原與該角色相關的所有變更。對於大部分角色，

要實現該任務都很簡單，但可能會存在套件相依項問題。如果解除安裝某個套件，並不

會解除安裝其相依項。

移除的 OSD 會顯示為空白磁碟機。相關任務除了會抹除分割區表外，還會覆寫檔案系

統的開頭並移除備份分割區。

7 移除和重新安裝叢集節點 SES 6

注意：保留透過其他方法建立的分割區先前透過其他方法 (例如 ceph-deploy ) 設定的磁碟機可能仍然包含分割

區。DeepSea 不會自動摧毀這些分割區。管理員必須手動收回這些磁碟機。

範例 2.1︰從叢集中移除 SALT MINION

舉例來說，如果您的儲存 Minion 名為「data1.ceph」、「data2.ceph」...

「data6.ceph」，則 policy.cfg 中的相關行類似下方所示：

[...]# Hardware Profilerole-storage/cluster/data*.sls[...]

若要移除 Salt Minion「data2.ceph」，請將這些行變更為：

[...]# Hardware Profilerole-storage/cluster/data[1,3-6]*.sls[...]

此外，請記得調整 drive_groups.yml 檔案以與新目標相符。

[...] drive_group_name: target: 'data[1,3-6]*' [...]

然後執行階段 2，檢查將要移除的是哪些 OSD，最後執行階段 5 以完成該程序：

root@master # salt-run state.orch ceph.stage.2root@master # salt-run rescinded.idsroot@master # salt-run state.orch ceph.stage.5

範例 2.2︰移轉節點

假設出現下面的情況：在全新安裝叢集期間，您 (管理員) 在等待閘道硬體就緒

時，將其中一個儲存節點配置為獨立的物件閘道。現在，當閘道的永久硬體就緒

時，您就可以將所需角色最終指定給備用儲存節點，並移除閘道角色。

在針對新硬體執行階段 0 和 1 (請參閱《部署指南》, 第 5 章「使用 DeepSea/

Salt 部署」, 第 5.3 節「叢集部署」, 執行部署階段) 之後，您將新閘道命名

為 rgw1。如果節點 data8 需要移除物件閘道角色並新增儲存角色，且目前的

policy.cfg 類似下方所示：

8 移除和重新安裝叢集節點 SES 6

# Hardware Profilerole-storage/cluster/data[1-7]*.sls

# Rolesrole-rgw/cluster/data8*.sls

則將它變更為：

# Hardware Profilerole-storage/cluster/data[1-8]*.sls

# Rolesrole-rgw/cluster/rgw1*.sls

執行階段 2 到 4，檢查可能要移除的是哪些 OSD，然後執行階段 5 以完成該程

序。階段 3 會將 data8 新增為儲存節點。稍候片刻， data8 將同時具有兩個角

色。階段 4 將會新增物件閘道角色至 rgw1，而階段 5 將會從 data8 中移除物

件閘道角色：

root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.3root@master # salt-run state.orch ceph.stage.4root@master # salt-run rescinded.idsroot@master # salt-run state.orch ceph.stage.5

2.4 重新部署監控程式節點當一或多個監控程式節點發生故障且不回應時，您需要將發生故障的監控程式從叢集中

移除，然後再新增回叢集 (如有需要)。

重要：至少須有三個監控程式節點監控程式節點的數量不能少於 3。如果某個監控程式節點發生故障，導致您的叢

集中只有兩個監控程式節點，在重新部署發生故障的監控程式節點之前，您需要

暫時將其監控程式角色指定給其他叢集節點。重新部署發生故障的監控程式節點

後，便可以解除安裝臨時監控程式角色。

如需有關將新節點/角色新增至 Ceph 叢集的詳細資訊，請參閱第 2.1 節「新

增新的叢集節點」和第 2.2 節「新增新的角色至節點」。

如需有關移除叢集節點的詳細資訊，請參閱第 2.3 節「移除和重新安裝叢集節

點」。

9 重新部署監控程式節點 SES 6

Ceph 節點故障基本分為以下兩種程度：

Salt Minion 主機發生實體或 OS 層級損毀，無法回應 salt 'minion_name'

test.ping 呼叫。在此情況下，您需要依照《部署指南》, 第 5 章「使用

DeepSea/Salt 部署」, 第 5.3 節「叢集部署」中的相關說明，對伺服器進行徹

底的重新部署。

監控程式相關服務失敗並拒絕復原，但主機會回應 salt 'minion_name' test.ping

呼叫。在此情況下，請執行以下步驟：

1. 編輯 Salt Master 上的 /srv/pillar/ceph/proposals/policy.cfg，移除或更新發

生故障的監控程式節點對應的行，使它們現在指向正常運作的監控程式節點。例

如：

[...]# MON#role-mon/cluster/ses-example-failed1.sls#role-mon/cluster/ses-example-failed2.slsrole-mon/cluster/ses-example-new1.slsrole-mon/cluster/ses-example-new2.sls[...]

2. 執行 DeepSea 階段 2 到 5 以套用這些變更：

root@master # deepsea stage run ceph.stage.2root@master # deepsea stage run ceph.stage.3root@master # deepsea stage run ceph.stage.4root@master # deepsea stage run ceph.stage.5

2.5 新增 OSD 磁碟至節點

若要新增磁碟至現有 OSD 節點，請驗證是否已移除並抹除磁碟上的所有分割區。如

需詳細資料，請參閱《部署指南》, 第 5 章「使用 DeepSea/Salt 部署」, 第 5.3

節「叢集部署」中的步驟 12。相應地調整 /srv/salt/ceph/configuration/files/

drive_groups.yml (如需詳細資料，請參閱《部署指南》, 第 5 章「使用 DeepSea/

Salt 部署」, 第 5.5.2 節「DriveGroups」)。儲存檔案後，執行 DeepSea 的階段

3：

root@master # deepsea stage run ceph.stage.3

10 新增 OSD 磁碟至節點 SES 6

2.6 移除 OSD

您可以透過執行以下指令從叢集中移除 Ceph OSD：

root@master # salt-run osd.remove OSD_ID

OSD_ID 必須是 OSD 的編號，不含 osd. 字首。例如，對於 osd.3，僅使用數字 3。

2.6.1 移除多個 OSD

使用第 2.6 節「移除 OSD」所述的相同程序，但只需提供多個 OSD ID：

root@master # salt-run osd.remove 2 6 11 15Removing osd 2 on host data1Draining the OSDWaiting for ceph to catch up.osd.2 is safe to destroyPurging from the crushmapZapping the device

Removing osd 6 on host data1Draining the OSDWaiting for ceph to catch up.osd.6 is safe to destroyPurging from the crushmapZapping the device



2:True

11 移除 OSD SES 6

6:True11:True15:True

2.6.2 移除主機上的所有 OSD

若要移除特定主機上的所有 OSD，請執行以下指令：

root@master # salt-run osd.remove OSD_HOST_NAME

2.6.3 強制移除已中止的 OSD

有時會出現無法正常移除 OSD 的情況 (請參閱第 2.6 節「移除 OSD」)。例如，如果

OSD 或其記錄、WAL 或 DB 損毀、I/O 操作擱置或 OSD 磁碟無法卸載，可能就會發生

這種情況。

root@master # salt-run osd.remove OSD_ID force=True

提示：擱置的掛接如果正在移除的磁碟上仍掛接著分割區，指令將結束，並顯示「卸載失敗 - 請

檢查 DEVICE 上的程序」訊息。然後，您可以使用 fuser -m DEVICE 列出存取

檔案系統的所有程序。如果 fuser 未傳回任何內容，請嘗試手動執行 unmount

DEVICE，然後監看 dmesg 或 journalctl 指令的輸出。

2.6.4 驗證 OSD LVM 中繼資料

使用 salt-run osd.remove ID 或透過其他 ceph 指令移除 OSD 之後，可能無法完全移

除 LVM 中繼資料。這表示如果您想要重新部署一個新 OSD，系統卻會使用舊 LVM 中繼

資料。

1. 首先檢查是否已移除 OSD：

12 移除主機上的所有 OSD SES 6

cephadm@osd > ceph-volume lvm list

即使已成功移除某個 OSD，它也可能仍會列出。例如，如果您移除了 osd.2，輸

出內容將如下所示：

====== osd.2 =======

[block] /dev/ceph-a2189611-4380-46f7-b9a2-8b0080a1f9fd/osd-data-ddc508bc-6cee-4890-9a42-250e30a72380

block device /dev/ceph-a2189611-4380-46f7-b9a2-8b0080a1f9fd/osd-data-ddc508bc-6cee-4890-9a42-250e30a72380 block uuid kH9aNy-vnCT-ExmQ-cAsI-H7Gw-LupE-cvSJO9 cephx lockbox secret cluster fsid 6b6bbac4-eb11-45cc-b325-637e3ff9fa0c cluster name ceph crush device class None encrypted 0 osd fsid aac51485-131c-442b-a243-47c9186067db osd id 2 type block vdo 0 devices /dev/sda

在此範例中，您可以看到 osd.2 仍然位於 /dev/sda 中。

2. 驗證 OSD 節點上的 LVM 中繼資料：

cephadm@osd > ceph-volume inventory

執行 ceph-volume inventory 指令產生的輸出中將 /dev/sda 可用性標示為

False。例如：

Device Path Size rotates available Model name /dev/sda 40.00 GB True False QEMU HARDDISK /dev/sdb 40.00 GB True False QEMU HARDDISK /dev/sdc 40.00 GB True False QEMU HARDDISK /dev/sdd 40.00 GB True False QEMU HARDDISK /dev/sde 40.00 GB True False QEMU HARDDISK /dev/sdf 40.00 GB True False QEMU HARDDISK /dev/vda 25.00 GB True False

3. 在 OSD 節點上執行以下指令，以完全移除 LVM 中繼資料：

cephadm@osd > ceph-volume lvm zap --osd-id ID --destroy

4. 再次執行 inventory 指令，以確認 /dev/sda 可用性是否傳回 True。例如：

13 驗證 OSD LVM 中繼資料 SES 6

cephadm@osd > ceph-volume inventoryDevice Path Size rotates available Model name/dev/sda 40.00 GB True True QEMU HARDDISK/dev/sdb 40.00 GB True False QEMU HARDDISK/dev/sdc 40.00 GB True False QEMU HARDDISK/dev/sdd 40.00 GB True False QEMU HARDDISK/dev/sde 40.00 GB True False QEMU HARDDISK/dev/sdf 40.00 GB True False QEMU HARDDISK/dev/vda 25.00 GB True False

現已將 LVM 中繼資料移除。現在，您可以安全地對裝置執行 dd 指令。

5. 現在可以重新部署 OSD，而無需將 OSD 節點重新開機：


2.7 更換 OSD 磁碟有多種原因會導致您可能需要更換 OSD 磁碟，例如：

依據 SMART 資訊，OSD 磁碟已發生故障或很快將發生故障，並且將不再能用來安

全地儲存資料。

您需要升級 OSD 磁碟，例如增加其大小。

這兩種情況的更換程序相同，對於預設 CRUSH 地圖和自訂 CRUSH 地圖也同樣適用。

1. 例如，假設其磁碟需要更換的 OSD 的 ID 為「5」。以下指令會在 CRUSH 地圖中

將其標示為 destroyed，但會保留其原始 ID：

root@master # salt-run osd.replace 5

提示：osd.replace 和 osd.removeSalt 的 osd.replace 和 osd.remove (請參閱第 2.6 節「移除 OSD」)

指令作用相同，只不過 osd.replace 會在 CRUSH 地圖中將 OSD 保留為

「destroyed」狀態，而 osd.remove 會從 CRUSH 地圖中移除所有痕跡。

2. 手動更換發生故障/升級的 OSD 磁碟機。

14 更換 OSD 磁碟 SES 6

3. 如果您要修改預設的 OSD 配置並變更 DriveGroups 組態，請執行《部署指南》,

第 5 章「使用 DeepSea/Salt 部署」, 第 5.5.2 節「DriveGroups」所述的程

序。

4. 執行部署階段 3，以部署更換的 OSD 磁碟：


2.8 復原重新安裝的 OSD 節點

如果您的某個 OSD 節點上的作業系統損毀且無法恢復，請執行以下步驟復原該節點，

並在叢集資料保持不變的情況下，重新部署該節點的 OSD 角色：

1. 在其作業系統已損毀的節點上重新安裝基礎 SUSE Linux Enterprise 作業系統。

在 OSD 節點上安裝 salt-minion 套件，刪除 Salt Master 上的舊 Salt Minion

金鑰，並在 Salt Master 中註冊新 Salt Minion 的金鑰。如需初始部署的詳細

資訊，請參閱《部署指南》, 第 5 章「使用 DeepSea/Salt 部署」, 第 5.3 節

「叢集部署」。

2. 不要執行整個階段 0，而是執行以下部分：

root@master # salt 'osd_node' state.apply ceph.syncroot@master # salt 'osd_node' state.apply ceph.packages.commonroot@master # salt 'osd_node' state.apply ceph.minesroot@master # salt 'osd_node' state.apply ceph.updates

3. 執行 DeepSea 階段 1 到 5：

root@master # salt-run state.orch ceph.stage.1root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.3root@master # salt-run state.orch ceph.stage.4root@master # salt-run state.orch ceph.stage.5

4. 執行 DeepSea 階段 0：


5. 將相關的 OSD 節點重新開機。系統將重新探查並重新使用所有 OSD 磁碟。

6. 安裝/執行 Prometheus 的節點輸出程式：

15 復原重新安裝的 OSD 節點 SES 6

root@master # salt 'RECOVERED_MINION' \ state.apply ceph.monitoring.prometheus.exporters.node_exporter

7. 更新 Salt 粒紋：

root@master # salt 'RECOVERED_MINION' osd.retain

2.9 將管理節點移至新伺服器

如果您需要以新主機取代管理節點主機，則需要移動 Salt Master 和 DeepSea 檔案。

使用您偏好的同步工具傳輸檔案。在此程序中，我們使用的是 rsync，因為它是 SUSE

Linux Enterprise Server 15 SP1 軟體儲存庫中提供的標準工具。

1. 停止舊管理節點上的 salt-master 和 salt-minion 服務：

root@master # systemctl stop salt-master.serviceroot@master # systemctl stop salt-minion.service

2. 在新管理節點上設定 Salt，以使 Salt Master 與 Salt Minions 可以通訊。如

需更多詳細資料，請參閱《部署指南》, 第 5 章「使用 DeepSea/Salt 部署」,

第 5.3 節「叢集部署」。

提示：轉換 Salt Minion為便於將 Salt Minion 轉換到新管理節點，請從每個 Salt Minion 中移除

原始 Salt Master 的公用金鑰：

root@minion > rm /etc/salt/pki/minion/minion_master.pubroot@minion > systemctl restart salt-minion.service

3. 確認是否已安裝 deepsea 套件，如果沒有，則予以安裝。

root@master # zypper install deepsea

4. 變更 role-master 一行以自訂 policy.cfg 檔案。如需更多詳細資料，請

參閱《部署指南》, 第 5 章「使用 DeepSea/Salt 部署」, 第 5.5.1 節

「policy.cfg 檔案」。

16 將管理節點移至新伺服器 SES 6

5. 將舊管理節點上的 /srv/pillar 和 /srv/salt 目錄同步到新管理節點。

提示：rsync 試執行和符號連結如果可能，請先透過試執行試驗檔案同步，以確定將傳輸的是哪些檔案

( rsync 的選項 -n )。此外，請包含符號連結 ( rsync 的選項 -a )。使用

rsync 的同步指令將如下所示：

root@master # rsync -avn /srv/pillar/ NEW-ADMIN-HOSTNAME:/srv/pillar

6. 如果您對 /srv/pillar 和 /srv/salt 外部的檔案 (例如 /etc/salt/master 或

/etc/salt/master.d ) 進行過自訂變更，請一併同步這些檔案。

7. 現在，您便可從新管理節點上執行 DeepSea 階段。如需其詳細說明，請參閱《部

署指南》, 第 5 章「使用 DeepSea/Salt 部署」, 第 5.2 節「DeepSea 簡

介」。

2.10 透過 Salt 實現自動安裝透過使用 Salt 反應器可讓安裝自動進行。對於虛擬環境或一致的硬體環境，此組態將

允許建立具有指定行為的 Ceph 叢集。

警告Salt 無法根據反應器事件執行相依項檢查。存在使 Salt Master 過載而無法回

應的風險。

自動安裝需要：

正確建立的 /srv/pillar/ceph/proposals/policy.cfg。

準備好並已放入 /srv/pillar/ceph/stack 目錄中的自訂組態。

預設反應器組態只會執行階段 0 和 1。如此不必等待後續階段完成即可測試反應器。

第一個 salt-minion 啟動時，階段 0 即會開始。使用鎖定可阻止多個例項。所有

Minion 都完成階段 0 後，階段 1 將會開始。

17 透過 Salt 實現自動安裝 SES 6

如果正確執行了該操作，請編輯檔案

/etc/salt/master.d/reactor.conf

並將下面一行

- /srv/salt/ceph/reactor/discovery.sls

取代為

- /srv/salt/ceph/reactor/all_stages.sls

確認未將該行設為備註。

2.11 更新叢集節點

定期套用滾存更新，以使 Ceph 叢集節點保持最新。

2.11.1 軟體儲存庫

使用最新的套裝軟體修補叢集之前，請確認叢集的所有節點均可存取相關的儲存庫。

如需所需儲存庫的完整清單，請參閱《部署指南》, 第 6 章「從舊版本升級」, 第

6.8.1 節「使用安裝程式 DVD 手動升級節點」。

2.11.2 儲存庫分段

如果您使用向叢集節點提供軟體儲存庫的暫存工具 (例如 SUSE Manager、訂閱管理工

具或儲存庫鏡像工具)，請確認 SUSE Linux Enterprise Server 和 SUSE Enterprise

Storage 的「更新」儲存庫的階段都是在同一時刻建立的。

我們強烈建議使用分段工具來套用修補程式層級為凍結/暫存的修補程式。這樣可確保

加入叢集的新節點具有與已在叢集中執行的節點相同的修補程式層級。透過這種方法，

您無需向叢集的所有節點都套用最新修補程式，新節點也能加入叢集。

18 更新叢集節點 SES 6

2.11.3 zypper patch 或 zypper dup

預設透過 zypper dup 指令來升級叢集節點。如果您更喜歡使用 zypper patch 指令來

更新系統，請編輯 /srv/pillar/ceph/stack/global.yml，並新增下面一行：

update_method_init: zypper-patch

2.11.4 叢集節點重新開機

如果更新程序在更新期間升級了叢集節點的核心，則您可以選擇將節點重新開機。如

果您要避免強制將節點 (可能是所有節點) 重新開機的可能性，請確認 Ceph 節點上

已安裝且正在執行最新的核心，或者如《部署指南》, 第 7 章「自訂預設組態」, 第

7.1.5 節「階段 0 期間的更新和重新開機」所述停用節點自動重新開機。

2.11.5 Ceph 服務停機時間

如第 2.11.4 節「叢集節點重新開機」所述，叢集節點可能會在更新期間重新開機，

具體視組態而定。如果物件閘道、Samba 閘道、NFS Ganesha 或 iSCSI 等服務存在單

一故障點，用戶端機器可能會暫時解除與相應節點正在重新開機的服務的連接。

2.11.6 執行更新

若要將叢集的所有節點上的軟體套裝更新至最新版本，請執行以下步驟：

1. 在 Salt Master 上更新 deepsea、 salt-master和 salt-minion 套件，並重新

啟動相關服務：

root@master # salt -I 'roles:master' state.apply ceph.updates.master

2. 在叢集的所有節點上更新並重新啟動 salt-minion 套件：

root@master # salt -I 'cluster:ceph' state.apply ceph.updates.salt

3. 在叢集上更新所有其他軟體套裝：

19 zypper patch 或 zypper dup SES 6

root@master # salt-run state.orch ceph.maintenance.upgrade

2.12 將叢集停止或重新開機在某些情況下，可能需要將整個叢集停止或重新開機。建議您仔細檢查執行中服務的相

依項。下列步驟簡要說明如何停止和啟動叢集：

1. 告知 Ceph 叢集不要將 OSD 標示為 out：

cephadm@adm > ceph osd set noout

2. 依下面的順序停止精靈和節點：

1. 儲存用戶端

2. 閘道，例如 NFS Ganesha 或物件閘道

3. 中繼資料伺服器

4. Ceph OSD

5. Ceph 管理員

6. Ceph 監控程式

3. 視需要執行維護任務。

4. 依與關閉過程相反的順序啟動節點和伺服器：

1. Ceph 監控程式

2. Ceph 管理員

3. Ceph OSD

4. 中繼資料伺服器

5. 閘道，例如 NFS Ganesha 或物件閘道

6. 儲存用戶端

5. 移除 noout 旗標：

20 將叢集停止或重新開機 SES 6

cephadm@adm > ceph osd unset noout

2.13 使用自訂設定調整 ceph.conf

如果您需要將自訂設定放入 ceph.conf 檔案中，可透過修改 /srv/salt/ceph/

configuration/files/ceph.conf.d 目錄中的組態檔案來實現：

global.conf

mon.conf

mgr.conf

mds.conf

osd.conf

client.conf

rgw.conf

注意：獨特的 rgw.conf物件閘道提供了很大的靈活性，並且具有 ceph.conf 的其他區段所沒有的獨特

之處。所有其他 Ceph 元件都包含靜態標頭，例如 [mon] 或 [osd]。物件閘道

具有獨特的標頭，例如 [client.rgw.rgw1]。也就是說， rgw.conf 檔案需要有標

頭項目。如需範例，請參閱

/srv/salt/ceph/configuration/files/rgw.conf

或

/srv/salt/ceph/configuration/files/rgw-ssl.conf

重要：執行階段 3對上述組態檔案進行自訂變更後，執行階段 3 和 4 以將這些變更套用至叢集節

點：

21 使用自訂設定調整 ceph.conf SES 6


這些檔案透過 /srv/salt/ceph/configuration/files/ceph.conf.j2 範本檔案加入，與

Ceph 組態檔案接受的不同區段相對應。將組態片段放入正確的檔案，可讓 DeepSea 將

其放入正確的區段中。您不需要新增任何區段標頭。

提示若要將任何組態選項僅套用於精靈的特定例項，請新增一個標頭，例如

[osd.1]。以下組態選項將只套用於 ID 為 1 的 OSD 精靈。

2.13.1 覆寫預設值

區段中位於後面的陳述式會覆寫前面的陳述式。因此，可以依 /srv/salt/ceph/

configuration/files/ceph.conf.j2 範本中指定的內容來覆寫預設組態。例如，若

要關閉 cephx 驗證，可將下面三行新增至 /srv/salt/ceph/configuration/files/

ceph.conf.d/global.conf 檔案：

auth cluster required = noneauth service required = noneauth client required = none

重新定義預設值時，與 Ceph 相關的工具 (例如 rados ) 可能會發出警告，指出已在

global.conf 中重新定義 ceph.conf.j2 中的特定值。這些警告之所以出現，是因為在

最終的 ceph.conf 中將一個參數指定了兩次。

若要解決這種特定情況，請執行以下步驟：

1. 將目前的目錄切換到 /srv/salt/ceph/configuration/create：

root@master # cd /srv/salt/ceph/configuration/create

2. 將 default.sls 複製到 custom.sls：

root@master # cp default.sls custom.sls

22 覆寫預設值 SES 6

3. 編輯 custom.sls，並將 ceph.conf.j2 變更為 custom-ceph.conf.j2。

4. 將目前的目錄切換到 /srv/salt/ceph/configuration/files：

root@master # cd /srv/salt/ceph/configuration/files

5. 將 ceph.conf.j2 複製到 custom-ceph.conf.j2：

root@master # cp ceph.conf.j2 custom-ceph.conf.j2

6. 編輯 custom-ceph.conf.j2，並刪除下面一行：

{% include "ceph/configuration/files/rbd.conf" %}

編輯 global.yml，並新增下面一行：

configuration_create: custom

7. 重新整理 Pillar：

root@master # salt target saltutil.pillar_refresh

8. 執行階段 3：


現在，每個值定義便應該只有一個項目。若要重新建立組態，請執行以下指令：

root@master # salt-run state.orch ceph.configuration.create

然後確認 /srv/salt/ceph/configuration/cache/ceph.conf 的內容。

2.13.2 加入組態檔案

如果您需要套用大量自訂組態，請在自訂組態檔案中使用以下 include 陳述式來讓檔

案管理工作更輕鬆。下面是 osd.conf 檔案的範例：

[osd.1]{% include "ceph/configuration/files/ceph.conf.d/osd1.conf" ignore missing %}[osd.2]{% include "ceph/configuration/files/ceph.conf.d/osd2.conf" ignore missing %}[osd.3]{% include "ceph/configuration/files/ceph.conf.d/osd3.conf" ignore missing %}

23 加入組態檔案 SES 6

[osd.4]{% include "ceph/configuration/files/ceph.conf.d/osd4.conf" ignore missing %}

在前面的範例中， osd1.conf、 osd2.conf、 osd3.conf 和 osd4.conf 檔案包含相關

OSD 特定的組態選項。

提示：執行時期組態對 Ceph 組態檔案所做的變更會在相關 Ceph 精靈重新啟動之後生效。如需變更

Ceph 執行時期組態的詳細資訊，請參閱第 16.1 節「執行時期組態」。

2.14 啟用 AppArmor 設定檔AppArmor 是一套透過特定設定檔對程式設限的安全性解決方案。如需詳細資訊，

請參閱https://www.suse.com/documentation/sles-15/book_security/data/

part_apparmor.html 。

DeepSea 針對 AppArmor 設定檔提供了以下三種狀態：「強制」、「申訴」和「停

用」。若要啟用某種 AppArmor 狀態，請執行以下指令：

salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-STATE

若要將 AppArmor 設定檔置於「強制」狀態，請執行以下指令：

root@master # salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-enforce

若要將 AppArmor 設定檔置於「申訴」狀態，請執行以下指令：

root@master # salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-complain

若要停用 AppArmor 設定檔，請執行以下指令：

root@master # salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-disable

提示：啟用 AppArmor 服務上面呼叫的三個指令都會確認是否已安裝 AppArmor，如果未安裝，將會安裝該

軟體，然後啟動並啟用相關的 systemd 服務。如果是透過另一種方式安裝並啟

動/啟用 AppArmor 的，會導致其在沒有 DeepSea 設定檔的情況下執行，對此

DeepSea 將會向您發出警告。

24 啟用 AppArmor 設定檔 SES 6

https://www.suse.com/documentation/sles-15/book_security/data/part_apparmor.html

https://www.suse.com/documentation/sles-15/book_security/data/part_apparmor.html

2.15 停用調整後的設定檔

依預設，DeepSea 會使用 Ceph 監控程式、Ceph 管理員和 Ceph OSD 節點上調整後的

使用中設定檔來部署 Ceph 叢集。在某些情況下，您可能需要永久停用調整後的設定

檔。若要完成此操作，請在 /srv/pillar/ceph/stack/global.yml 中新增下面幾行，然

後重新執行階段 3：

alternative_defaults: tuned_mgr_init: default-off tuned_mon_init: default-off tuned_osd_init: default-off


2.16 移除整個 Ceph 叢集

ceph.purge 執行程式會移除整個 Ceph 叢集。這樣，您便可以在測試不同的設定時

清理叢集環境。 ceph.purge 完成之後，Salt 叢集將回復至 DeepSea 階段 1 結束

時的狀態。然後，您便可以變更 policy.cfg (請參閱《部署指南》, 第 5 章「使

用 DeepSea/Salt 部署」, 第 5.5.1 節「policy.cfg 檔案」)，或對該設定繼續執行

DeepSea 階段 2。

為防止意外刪除，協調程序會檢查是否解除了安全措施。您可以透過執行以下指令來解

除安全措施並移除 Ceph 叢集：

root@master # salt-run disengage.safetyroot@master # salt-run state.orch ceph.purge

提示：禁止移除 Ceph 叢集如果您要阻止任何人執行 ceph.purge 執行程式，請在 /srv/salt/ceph/purge

目錄中建立名為 disabled.sls 的檔案，然後在 /srv/pillar/ceph/stack/

global.yml 檔案中插入下面一行：

purge_init: disabled

25 停用調整後的設定檔 SES 6

重要：撤銷自訂角色如果您之前為 Ceph Dashboard 建立了自訂角色 (如需詳細資訊，請參

閱第 22.2.6 節「新增自訂角色」和第 22.10.2 節「使用者角色和許可

權」)，在執行 ceph.purge 執行程式之前，您需要執行一些手動步驟將這些角

色清除。例如，如果物件閘道的自訂角色名為「us-east-1」，請執行以下步

驟：

root@master # cd /srv/salt/ceph/rescindroot@master # rsync -a rgw/ us-east-1root@master # sed -i 's!rgw!us-east-1!' us-east-1/*.sls

26 移除整個 Ceph 叢集 SES 6

3 備份叢集組態和資料

本章說明您應當備份 Ceph 叢集的哪些部分才能還原叢集功能。

3.1 備份 Ceph 組態

備份 /etc/ceph 目錄。該目錄包含至關重要的叢集組態。例如，當您需要更換管理節

點時，就需要備份 /etc/ceph。

3.2 備份 Salt 組態

您需要備份 /etc/salt/ 目錄。該目錄包含 Salt 組態檔案，例如 Salt Master 金鑰

和已接受的用戶端金鑰。

從嚴格意義上來說，備份管理節點並不需要備份 Salt 檔案，但這些檔案能夠簡化

Salt 叢集的重新部署。如果不備份這些檔案，就需要在新管理節點上重新註冊 Salt

Minion。

注意：Salt Master 私密金鑰的安全性請務必將 Salt Master 私密金鑰的備份儲存在安全位置。Salt Master 金鑰可

用於操縱所有叢集節點。

從備份還原 /etc/salt 目錄後，請重新啟動 Salt 服務：

root@master # systemctl restart salt-masterroot@master # systemctl restart salt-minion

3.3 備份 DeepSea 組態

DeepSea 所需的所有檔案都儲存在 /srv/pillar/、 /srv/salt/ 和 /etc/salt/

master.d 中。

27 備份 Ceph 組態 SES 6

如果您需要重新部署管理節點，請在新節點上安裝 DeepSea 套件，並將備份的資料移

回這些目錄。然後，無需做出更多變更，即可再次使用 DeepSea。在再次使用 DeepSea

之前，請確定已在管理節點上正確註冊所有 Salt Minion。

3.4 備份自訂組態

Prometheus 資料和自訂。

Grafana 自訂。

確認您擁有現有 openATTIC 使用者的記錄，這樣您才能在 Ceph Dashboard 中為

這些使用者建立新帳戶。

在 DeepSea 之外手動對 ceph.conf 進行的變更。

在 DeepSea 之外手動對 iSCSI 組態進行的變更。

Ceph 金鑰。

CRUSH 地圖和 CRUSH 規則。透過執行以下指令將包含 CRUSH 規則的反編譯

CRUSH 地圖儲存到 crushmap-backup.txt 中：

cephadm@adm > ceph osd getcrushmap | crushtool -d - -o crushmap-backup.txt

Samba 閘道組態。如果您使用的是單一閘道，請備份 /etc/samba/smb.conf。如果

您使用的是 HA 設定，另請備份 CTDB 和 Pacemaker 組態檔案。如需 Samba 閘

道所使用組態的詳細資料，請參閱第 20 章「透過 Samba 輸出 Ceph 資料」。

NFS Ganesha 組態。僅當使用 HA 設定時需要備份。如需 NFS Ganesha 所使用組

態的詳細資料，請參閱第 21 章「NFS Ganesha：透過 NFS 輸出 Ceph 資料」。

28 備份自訂組態 SES 6

II 操作叢集

4 簡介 30

5 操作 Ceph 服務 31

6 確定叢集狀態 36

7 監控和警示 66

8 使用 cephx 進行驗證 83

9 儲存的資料管理 97

10 Ceph 管理員模組 124

11 管理儲存池 129

12 RADOS 區塊裝置 148

13 糾刪碼池 172

14 快取分層 178

15 使用 LVM 快取提升效能 188

16 Ceph 叢集組態 192

4 簡介

在手冊的這部分，您將瞭解如何啟動或停止 Ceph 服務、監控叢集的狀態、使用和修改

CRUSH 地圖或管理儲存池。

該指南還包含了進階主題，例如通常如何管理使用者和驗證、如何管理池和 RADOS 裝

置快照、如何設定糾刪碼池，如何透過快取分層提高叢集效能。

30 SES 6

5 操作 Ceph 服務

您可以使用 systemd 或透過 DeepSea 來操作 Ceph 服務。

5.1 使用 systemd 操作與 Ceph Cluster 相關

的服務

使用 systemctl 指令操作所有與 Ceph 相關的服務。操作在您目前登入的節點上進

行。您需要具有 root 特權才能操作 Ceph 服務。

5.1.1 使用目標啟動、停止和重新啟動服務

為了簡化啟動、停止和重新啟動節點上特定類型的所有服務 (例如所有 Ceph 服務、所

有 MON 或所有 OSD) 的操作，Ceph 提供了以下 systemd 單位檔案：

cephadm@adm > ls /usr/lib/systemd/system/ceph*.targetceph.targetceph-osd.targetceph-mon.targetceph-mgr.targetceph-mds.targetceph-radosgw.targetceph-rbd-mirror.target

若要啟動/停止/重新啟動節點上的所有 Ceph 服務，請執行以下指令：

root # systemctl start ceph.targetroot # systemctl stop ceph.targetroot # systemctl restart ceph.target

若要啟動/停止/重新啟動節點上的所有 OSD，請執行以下指令：

root # systemctl start ceph-osd.targetroot # systemctl stop ceph-osd.targetroot # systemctl restart ceph-osd.target

針對其他目標的指令與此類似。

31 使用 systemd 操作與 Ceph Cluster 相關的服務 SES 6

5.1.2 啟動、停止和重新啟動個別服務

您可以使用以下參數化 systemd 單位檔案來操作個別服務：

[email protected]@[email protected]@[email protected]@.service

若要使用這些指令，您首先需要確定要操作的服務名稱。請參閱第 5.1.3 節「識別個

別服務」以瞭解有關如何識別服務的詳細資訊。

若要啟動/停止/重新啟動 osd.1 服務，請執行以下指令：

root # systemctl start [email protected] # systemctl stop [email protected] # systemctl restart [email protected]

針對其他服務類型的指令與此類似。

5.1.3 識別個別服務

您可以透過以下幾種方式獲得某種服務類型的名稱/編號。以下指令提供 ceph* 服務

的結果。您可以在 Ceph 叢集的任何節點上執行這些指令。

若要列出 ceph* 類型的所有 (甚至是非使用中) 服務，請執行以下指令：

root # systemctl list-units --all --type=service ceph*

若只想列出非使用中服務，請執行以下指令：

root # systemctl list-units --all --state=inactive --type=service ceph*

您也可以使用 salt 查詢多個節點上的服務：

root@master # salt TARGET cmd.shell \ "systemctl list-units --all --type=service ceph* | sed -e '/^$/,$ d'"

僅查詢儲存節點：

root@master # salt -I 'roles:storage' cmd.shell \

32 啟動、停止和重新啟動個別服務 SES 6

'systemctl list-units --all --type=service ceph*'

5.1.4 服務狀態

您可以查詢 systemd 來瞭解服務的狀態。例如：

root # systemctl status [email protected] # systemctl status [email protected]

請以用於執行精靈的主機名稱取代 HOSTNAME。

如果您不知道服務的確切名稱/編號，請參閱第 5.1.3 節「識別個別服務」。

5.2 使用 DeepSea 重新啟動 Ceph 服務將更新套用至叢集節點後，需要重新啟動與 Ceph 相關的受影響服務。通常情況

下，DeepSea 會自動執行重新啟動操作。本節介紹如何手動重新啟動服務。

提示：監看重新啟動重新啟動叢集的過程可能需要一段時間。您可以透過執行以下指令來使用 Salt

事件匯流排監看事件：

root@master # salt-run state.event pretty=True

另一個用於監控使用中工作的指令為：

root@master # salt-run jobs.active

5.2.1 重新啟動所有服務

警告：服務中斷如果與 Ceph 相關的服務 (特別是 iSCSI 或 NFS Ganesha) 設定為單點存取，

並且未設定高可用性，重新啟動這些服務將導致從用戶端進行檢視時會出現暫時

中斷現象。

33 服務狀態 SES 6

提示：Samba 不受 DeepSea 管理由於 DeepSea 和 Ceph Dashboard 目前不支援 Samba 部署，您需要手動管理與

Samba 相關的服務。如需詳細資訊，請參閱第 20 章「透過 Samba 輸出 Ceph

資料」。

若要重新啟動叢集上的所有服務，請執行以下指令：

root@master # salt-run state.orch ceph.restart

如果 DeepSea 版本低於 0.8.4，則中繼資料伺服器、iSCSI 閘道、物件閘道和

NFS Ganesha 服務將平行重新啟動。

如果 DeepSea 為 0.8.4 或更新版本，您已設定的所有角色將依以下順序重

新啟動：Ceph 監控程式、Ceph 管理員、Ceph OSD、中繼資料伺服器、物件閘

道、iSCSI 閘道、NFS Ganesha。為了保持較短的停機時間並儘早發現潛在問題，

請循序重新啟動各節點。例如，一次僅重新啟動一個監控節點。

如果叢集處於降級、不良的狀態，該指令會等待叢集復原。

5.2.2 重新啟動特定服務

若要重新啟動叢集上的特定服務，請執行以下指令：

root@master # salt-run state.orch ceph.restart.service_name

例如，若要重新啟動所有物件閘道，請執行以下指令：

root@master # salt-run state.orch ceph.restart.rgw

您可以使用以下目標：

root@master # salt-run state.orch ceph.restart.mon

root@master # salt-run state.orch ceph.restart.mgr

root@master # salt-run state.orch ceph.restart.osd

root@master # salt-run state.orch ceph.restart.mds

34 重新啟動特定服務 SES 6

root@master # salt-run state.orch ceph.restart.rgw

root@master # salt-run state.orch ceph.restart.igw

root@master # salt-run state.orch ceph.restart.ganesha

5.3 正常關閉整個 Ceph 叢集

在某些情況下，您需要依建議的順序停止叢集中所有與 Ceph 相關的服務，然後才能再

次依任意順序將其啟動。例如，發生計劃中停電的情況時。

若要關閉整個 Ceph 叢集，請停用安全措施並執行 ceph.shutdown 執行程式：

root@master # salt-run disengage.safetyroot@master # salt-run state.orch ceph.shutdown

若要啟動整個 Ceph 叢集，請執行 ceph.startup 執行程式：

root@master # salt-run state.orch ceph.startup

35 正常關閉整個 Ceph 叢集 SES 6

6 確定叢集狀態

當叢集正在執行時，您可以使用 ceph 工具來監控它。若要確定叢集狀態，通常需要

檢查 Ceph OSD、Ceph 監控程式、放置群組和中繼資料伺服器的狀態。

提示：互動模式若要以互動模式執行 ceph 工具，請不帶任何引數在指令行中輸入 ceph。如果

要在一行中輸入多條 ceph 指令，則使用互動模式較為方便。例如：

cephadm@adm > cephceph> healthceph> statusceph> quorum_statusceph> mon_status

6.1 檢查叢集的狀態

若要檢查叢集的狀態，請執行以下指令：

cephadm@adm > ceph status

或

cephadm@adm > ceph -s

在互動模式下，輸入 status，然後按 Enter 。

ceph> status

Ceph 將列印叢集狀態。例如，由一個監控程式和兩個 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

36 檢查叢集的狀態 SES 6

951 active+clean

6.2 檢查叢集狀態在啟動叢集後到開始讀取和/或寫入資料期間，檢查叢集的狀態：

cephadm@adm > ceph healthHEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \node-1,node-2,node-3

提示如果之前為您的組態或金鑰圈指定了非預設位置，則此時可以指定它們的位置：

cephadm@adm > ceph -c /path/to/conf -k /path/to/keyring health

Ceph 叢集會傳回下列狀態代碼之一：

OSD_DOWN

一或多個 OSD 標示為已停機。OSD 精靈可能已停止，或對等 OSD 可能無法透過

網路連接 OSD。常見原因包括精靈已停止或已當機、主機已停機或網路中斷。

驗證主機是否執行良好，精靈是否已啟動，並且網路是否正常運作。如果精靈已

當機，精靈記錄檔案 ( /var/log/ceph/ceph-osd.* ) 可能會包含除錯資訊。

OSD_ crush type _DOWN，例如 OSD_HOST_DOWN

特定 CRUSH 子樹中的所有 OSD (例如主機上的所有 OSD) 均標示為已停機。

OSD_ORPHAN

在 CRUSH 地圖階層中參考了 OSD，但它不存在。可使用以下指令從 CRUSH 階層

中移除 OSD：

cephadm@adm > ceph osd crush rm osd.ID

OSD_OUT_OF_ORDER_FULL

以下各項的使用率閾值並不是遞增的：backfillfull (預設值為

0.90)、nearfull (預設值為 0.85)、full (預設值為 0.95)、failsafe_full。

特別是，我們需要 backfillfull < nearfull，nearfull < full 且 full <

failsafe_full。

37 檢查叢集狀態 SES 6

若要讀取最新的值，請執行以下指令：

cephadm@adm > ceph health detailHEALTH_ERR 1 full osd(s); 1 backfillfull osd(s); 1 nearfull osd(s)osd.3 is full at 97%osd.4 is backfill full at 91%osd.2 is near full at 87%

可以使用以下指令調整閾值：

cephadm@adm > ceph osd set-backfillfull-ratio ratiocephadm@adm > ceph osd set-nearfull-ratio ratiocephadm@adm > ceph osd set-full-ratio ratio

OSD_FULL

一或多個 OSD 超出了 full 閾值，阻止叢集處理寫入操作。可使用以下指令檢查

各池的使用量：

cephadm@adm > ceph df

可使用以下指令查看目前定義的 full 比率：

cephadm@adm > ceph osd dump | grep full_ratio

還原寫入可用性的臨時解決辦法是稍稍提高 full 閾值：

cephadm@adm > ceph osd set-full-ratio ratio

請透過部署更多 OSD 將新的儲存新增至叢集，或者刪除現有資料來騰出空間。

OSD_BACKFILLFULL

一或多個 OSD 超出了 backfillfull 閾值，因而不允許將資料重新平衡到此裝

置。這是一則預警，表示重新平衡可能無法完成，並且叢集將滿。可使用以下指

令檢查各池的使用量：


OSD_NEARFULL

一或多個 OSD 超出了 nearfull 閾值。這是一則預警，表示叢集將滿。可使用以

下指令檢查各池的使用量：


OSDMAP_FLAGS


已設定一或多個所需的叢集旗標。可使用以下指令設定或清除這些旗標 (full 除

外)：

cephadm@adm > ceph osd set flagcephadm@adm > ceph osd unset flag

這些旗標包括：

full

叢集標記為已滿，無法處理寫入操作。

pauserd、pausewr

已暫停讀取或寫入。

noup

不允許 OSD 啟動。

nodown

將會忽略 OSD 故障報告，如此監控程式便不會將 OSD 標示為 down。

noin

先前標示為 out 的 OSD 在啟動時將不會重新標示為 in。

noout

停機的 OSD 在設定間隔過後將不會自動標示為 out。

nobackfill、norecover、norebalance

復原或資料重新平衡程序已暫停。

noscrub、nodeep_scrub

整理程序已停用 (請參閱第 9.6 節「整理」)。

notieragent

快取分層活動已暫停。

OSD_FLAGS

一或多個 OSD 設定了所需的每 OSD 旗標。這些旗標包括：

noup

不允許 OSD 啟動。

nodown


將會忽略此 OSD 的故障報告。

noin

如果此 OSD 先前在發生故障後自動標示為 out，當它啟動時將不會標示為

in。

noout

如果此 OSD 已停機，則在設定的間隔過後，它將不會自動標示為 out。

可使用以下指令來設定和清除每 OSD 旗標：

cephadm@adm > ceph osd add-flag osd-IDcephadm@adm > ceph osd rm-flag osd-ID

OLD_CRUSH_TUNABLES

CRUSH 地圖目前使用的設定很舊，應予以更新。 mon_crush_min_required_version

組態選項可確定使用時不會觸發此狀態警告的最舊可調參數 (即能夠連接到叢集

的最舊用戶端版本)。

OLD_CRUSH_STRAW_CALC_VERSION

CRUSH 地圖目前使用較舊的非最佳方法來計算 straw 桶的中間權數值。應該更新

CRUSH 地圖，以使用較新的方法 ( straw_calc_version =1)。

CACHE_POOL_NO_HIT_SET

一或多個快取池未設定命中集來追蹤使用量，這使分層代理程式無法識別要從快

取中衝洗和逐出的冷物件。可使用以下指令對快取池設定命中集：

cephadm@adm > ceph osd pool set poolname hit_set_type typecephadm@adm > ceph osd pool set poolname hit_set_period period-in-secondscephadm@adm > ceph osd pool set poolname hit_set_count number-of-hitsetscephadm@adm > ceph osd pool set poolname hit_set_fpp target-false-positive-rate

如需快取分層的詳細資訊，請參閱第 14 章「快取分層」。

OSD_NO_SORTBITWISE

未在執行 Luminous 12 以下版本的 OSD，但是尚未設定 sortbitwise 旗標。您

需要先設定 sortbitwise 旗標，Luminous 12 或更新版本的 OSD 才能啟動：

cephadm@adm > ceph osd set sortbitwise

POOL_FULL

一或多個池已達到其定額，不再允許寫入。您可使用以下指令來設定池定額和使

用量：


cephadm@adm > ceph df detail

您可以使用以下指令來提高池定額

cephadm@adm > ceph osd pool set-quota poolname max_objects num-objectscephadm@adm > ceph osd pool set-quota poolname max_bytes num-bytes

或者刪除一些現有資料以減少使用量。

PG_AVAILABILITY

資料可用性下降，這表示叢集無法處理針對叢集中某些資料的潛在讀取或寫入要

求。具體而言，一或多個 PG 處於不允許處理 I/O 要求的狀態。有問題的 PG 狀

態包括互聯建立中、陳舊、不完整和不處於使用中 (如果不迅速解決這些狀況)。

執行以下指令可獲得有關哪些 PG 受影響的詳細資訊：

cephadm@adm > ceph health detail

大多數情況下，出現此情形的根本原因在於一或多個 OSD 目前已停機。可使用以

下指令來查詢特定的有問題 PG 的狀態：

cephadm@adm > ceph tell pgid query

PG_DEGRADED

某些資料的資料備援降低，這表示叢集沒有所需數量的複本用於所有資料 (對

於副本池) 或糾刪碼片段 (對於糾刪碼池)。具體而言，一或多個 PG 設定了

degraded 或 undersized 旗標 (叢集中沒有該放置群組的足夠例項)，或者有一

段時間未設定 clean 旗標。執行以下指令可獲得有關哪些 PG 受影響的詳細資

訊：

cephadm@adm > ceph health detail

大多數情況下，出現此情形的根本原因在於一或多個 OSD 目前已停機。可使用以

下指令來查詢特定的有問題 PG 的狀態：


PG_DEGRADED_FULL

由於叢集中的可用空間不足，某些資料的資料備援可能已降低或面臨風險。具體

而言，一或多個 PG 設定了 backfill_toofull 或 recovery_tooful 旗標，這表

示叢集無法移轉或復原資料，原因是一或多個 OSD 高於 backfillfull 閾值。


PG_DAMAGED

資料整理 (請參閱第 9.6 節「整理」) 程序探查到叢集中存在某些資料一致性

問題。具體而言，一或多個 PG 設定了 inconsistent 或 snaptrim_error 旗標

(表示某個較早的整理操作發現問題)，或者設定了 repair 旗標 (表示目前正在

修復此類不一致問題)。

OSD_SCRUB_ERRORS

最近的 OSD 整理操作發現了不一致問題。

CACHE_POOL_NEAR_FULL

快取層池將滿。此環境中的「滿」由快取池的 target_max_bytes 和

target_max_objects 內容確定。當池達到目標閾值時，如果正在從快取衝洗和

逐出資料，寫入池的要求可能會被阻擋，出現常會導致延遲很高且效能變差的狀

態。可使用以下指令調整快取池目標大小：

cephadm@adm > ceph osd pool set cache-pool-name target_max_bytes bytescephadm@adm > ceph osd pool set cache-pool-name target_max_objects objects

正常的快取衝洗和逐出活動還可能因基礎層級可用性或效能下降或者叢集的整體

負載較高而受到限制。


TOO_FEW_PGS

使用中的 PG 數量低於每個 OSD 的 PG 數的可設定閾值

mon_pg_warn_min_per_osd。這可能導致叢集中各 OSD 間的資料分發和平衡未達到

最佳，以致降低整體效能。

TOO_MANY_PGS

使用中的 PG 數量高於每個 OSD 的 PG 數的可設定閾值

mon_pg_warn_max_per_osd。這可能導致 OSD 精靈的記憶體使用率較高，叢集狀態

變更 (例如 OSD 重新啟動、新增或移除) 之後互聯速度降低，並且 Ceph 管理員

和 Ceph 監控程式上的負載較高。

雖然不能降低現有池的 pg_num 值，但可以降低 pgp_num 值。這樣可有效地將一

些 PG 併置在同組 OSD 上，從而減輕上述的一些負面影響。可使用以下指令調整

pgp_num 值：

cephadm@adm > ceph osd pool set pool pgp_num value

SMALLER_PGP_NUM


一或多個池的 pgp_num 值小於 pg_num。這通常表示 PG 計數有所提高，但未同

時提升放置行為。使用以下指令設定 pgp_num，使其與觸發資料移轉的 pg_num

相符，通常便可解決此問題：

cephadm@adm > ceph osd pool set pool pgp_num pg_num_value

MANY_OBJECTS_PER_PG

一或多個池的每 PG 平均物件數大大高於叢集的整體平均值。透過

mon_pg_warn_max_object_skew 組態值來控制該特定閾值。這通常表示包含叢集中

大部分資料的池所具有的 PG 太少，以及/或者不包含這麼多資料的其他池具有的

PG 太多。可透過調整監控程式上的 mon_pg_warn_max_object_skew 組態選項提高

閾值，來消除該狀態警告。

POOL_APP_NOT_ENABLED¶

存在包含一或多個物件，但尚未標記為供特定應用程式使用的池。將池標記為供

某個應用程式使用即可消除此警告。例如，如果池由 RBD 使用：

cephadm@adm > rbd pool init pool_name

如果池正由自訂應用程式「foo」使用，您還可以使用低層級指令標記它：

cephadm@adm > ceph osd pool application enable foo

POOL_FULL

一或多個池已達到 (或幾乎要達到) 其定額。透過

mon_pool_quota_crit_threshold 組態選項來控制觸發此錯誤狀況的閾值。可使用

以下指令上調、下調 (或移除) 池定額：

cephadm@adm > ceph osd pool set-quota pool max_bytes bytescephadm@adm > ceph osd pool set-quota pool max_objects objects

將定額值設定為 0 將停用定額。

POOL_NEAR_FULL

一或多個池接近其定額。透過 mon_pool_quota_warn_threshold 組態選項來控制觸

發此警告狀況的閾值。可使用以下指令上調、下調 (或移除) 池定額：

cephadm@adm > ceph osd osd pool set-quota pool max_bytes bytescephadm@adm > ceph osd osd pool set-quota pool max_objects objects

將定額值設定為 0 將停用定額。


OBJECT_MISPLACED

叢集中的一或多個物件未儲存在叢集希望儲存的節點上。這表示叢集最近的某項

變更導致的資料移轉尚未完成。誤放的資料本質上不屬於危險狀況。資料一致性

方面永遠不會有風險，僅當所需位置放置了物件所需份數的新副本之後，系統才

會移除物件的舊副本。

OBJECT_UNFOUND

找不到叢集中的一或多個物件。具體而言，OSD 知道物件的新複本或更新複本應

該存在，但在目前啟用的 OSD 上卻找不到該版物件的複本。系統將阻止對「未

找到」物件的讀取或寫入要求。從理論上講，可以將具有未找到物件最近複本的

已停機 OSD 重新啟用。可透過負責處理未找到物件的 PG 的互聯狀態識別候選

OSD：


REQUEST_SLOW

正花費很長的時間處理一或多個 OSD 要求。這可能表示負載極重、儲存裝置速度

緩慢或有軟體錯誤。您可以從 OSD 主機上執行以下指令，來查詢有問題的 OSD

上的要求佇列：

cephadm@adm > ceph daemon osd.id ops

您可以查看近期最慢的要求摘要：

cephadm@adm > ceph daemon osd.id dump_historic_ops

可使用以下指令尋找 OSD 的位置：

cephadm@adm > ceph osd find osd.id

REQUEST_STUCK

已將一或多個 OSD 要求阻擋一段相當長的時間，例如 4096 秒。這表示叢集已

有很長一段時間處於狀況不良狀態 (例如，沒有足夠的執行中 OSD 或非使用中

PG)，或者 OSD 存在某種內部問題。

PG_NOT_SCRUBBED

最近未整理 (請參閱第 9.6 節「整理」) 一或多個 PG。通常每

mon_scrub_interval 秒整理一次 PG，當 mon_warn_not_scrubbed 這類間隔已

過但未進行整理時，就會觸發此警告。如果 PG 未標記為清理，系統將不會整


理它們。如果 PG 放置錯誤或已降級，就會出現這種情況 (請參閱上文中的

PG_AVAILABILITY 和 PG_DEGRADED)。您可使用以下指令手動對標記為清理的 PG

啟動整理：

cephadm@adm > ceph pg scrub pgid

PG_NOT_DEEP_SCRUBBED

最近未深層整理 (請參閱第 9.6 節「整理」) 一或多個 PG。系統通常每

osd_deep_scrub_interval 秒整理一次 PG，當 mon_warn_not_deep_scrubbed 秒已

過但未進行整理時，就會觸發此警告。如果 PG 未標記為清理，系統將不會 (深

層) 整理它們。如果 PG 放置錯誤或已降級，就會出現這種情況 (請參閱上文中

的 PG_AVAILABILITY 和 PG_DEGRADED)。您可使用以下指令手動對標記為清理的

PG 啟動整理：

cephadm@adm > ceph pg deep-scrub pgid

提示如果之前為您的組態或金鑰圈指定了非預設位置，則此時可以指定它們的位置：

root # ceph -c /path/to/conf -k /path/to/keyring health

6.3 監看叢集您可以使用 ceph -s 瞭解叢集的即時狀態。例如，由一個監控程式和兩個 OSD 組成的

微型 Ceph 叢集可在某工作負載正在執行時列印以下內容：

cephadm@adm > ceph -scluster: id: ea4cf6ce-80c6-3583-bb5e-95fa303c893f health: HEALTH_WARN too many PGs per OSD (408 > max 300)

services: mon: 3 daemons, quorum ses5min1,ses5min3,ses5min2 mgr: ses5min1(active), standbys: ses5min3, ses5min2 mds: cephfs-1/1/1 up {0=ses5min3=up:active} osd: 4 osds: 4 up, 4 in rgw: 1 daemon active

45 監看叢集 SES 6

data: pools: 8 pools, 544 pgs objects: 253 objects, 3821 bytes usage: 6252 MB used, 13823 MB / 20075 MB avail pgs: 544 active+clean

輸出內容提供了以下資訊：

叢集 ID

叢集執行狀態

監控程式地圖版本編號和監控程式仲裁的狀態

OSD 地圖版本編號和 OSD 的狀態

Ceph 管理員的狀態

物件閘道的狀態

放置群組地圖版本

放置群組和池數量

理論上儲存的資料量和儲存的物件數量

儲存的資料總量

提示：Ceph 計算資料使用量的方式used 值反映實際使用的原始儲存量。 xxx GB / xxx GB 值表示叢集可用容量

(兩者中的較小數值)，以及叢集的整體儲存容量。理論數量反映在複製所儲存資

料或建立其快照前這些資料的大小。因此，實際儲存的資料量一般會超出理論上

的儲存量，因為 Ceph 會建立資料的複本，可能還會將儲存容量用於複製和建立

快照。

顯示即時狀態資訊的其他指令如下：

ceph pg stat

ceph osd pool stats

ceph df

ceph df detail

46 監看叢集 SES 6

若要即時更新資訊，請在 watch 指令中以引數的方式使用以上任意指令 (包括 ceph -

s )：

root # watch -n 10 'ceph -s'

如果您看累了，請按 Ctrl – C 。

6.4 檢查叢集的使用量統計資料若要檢視叢集的資料使用率以及資料在多個池之間的分佈，請使用 ceph df 指令。若

要獲取更多詳細資料，請使用 ceph df detail。

cephadm@adm > ceph dfRAW STORAGE: CLASS SIZE AVAIL USED RAW USED %RAW USED hdd 40 GiB 32 GiB 137 MiB 8.1 GiB 20.33 TOTAL 40 GiB 32 GiB 137 MiB 8.1 GiB 20.33POOLS: POOL ID STORED OBJECTS USED %USED MAX AVAIL iscsi-images 1 3.9 KiB 8 769 KiB 0 10 GiB cephfs_data 2 1.6 KiB 5 960 KiB 0 10 GiB cephfs_metadata 3 54 KiB 22 1.5 MiB 0 10 GiB[...]

輸出中的 RAW STORAGE 區段提供叢集用於資料的儲存空間容量綜覽。

CLASS：裝置的儲存類別。如需裝置類別的更多詳細資料，請參閱第 9.1.1 節

「裝置類別」。

SIZE：叢集的整體儲存容量。

AVAIL：叢集中的可用空間容量。

USED：單純為區塊裝置中儲存的資料物件配置的空間 (所有 OSD 上的累計空

間)。

RAW USED：「USED」空間與區塊裝置上為實現 Ceph 而配置/保留的空間 (例如

BlueStore 的 BlueFS 部分) 之和。

% RAW USED：已用的原始儲存量百分比。將此數字與 full ratio 和 near full

ratio 結合使用，可確保您不會用完叢集的容量。如需其他詳細資料，請參

閱第 6.10 節「儲存容量」。

47 檢查叢集的使用量統計資料 SES 6

注意：叢集填滿程度當原始儲存填滿層級接近 100% 時，您需要新增新儲存空間至叢集。較高的

使用量可能導致單個 OSD 填滿，叢集處於不良狀態。

使用指令 ceph osd df tree 可列出所有 OSD 的填滿程度。

輸出內容的 POOLS 區段提供了池清單和每個池的理論使用量。此區段的輸出不反映複

本、複製品或快照。例如，如果您儲存含 1MB 資料的物件，理論使用量將是 1MB，但

是根據複本、複製品或快照數量，實際使用量可能是 2MB 或更多。

POOL：池的名稱。

ID：池 ID。

STORED：使用者儲存的資料量。

OBJECTS：每個池的理論已儲存物件數。

USED：所有 OSD 節點單純為儲存資料配置的空間容量 (以 kB 計)。

%USED：每個池的理論已用儲存百分比。

MAX AVAIL：給定池中的最大可用空間。

注意POOLS 區段中的數字是理論上的。它們不包括複本、快照或複製品數量。因

此， USED 與 % USED 數量之和不會加總到輸出內容 RAW STORAGE 區段中的 RAW

USED 和 %RAW USED 數量中。

6.5 檢查 OSD 狀態您可透過執行以下指令來檢查 OSD，以確定它們已啟動且正在執行：

cephadm@adm > ceph osd stat

或

48 檢查 OSD 狀態 SES 6

cephadm@adm > ceph osd dump

您也可以根據 OSD 在 CRUSH 地圖中的位置檢視 OSD。

cephadm@adm > ceph osd tree

Ceph 將列印 CRUSH 樹及主機、它的 OSD、OSD 是否已啟動及其權數。

# id weight type name up/down reweight-1 3 pool default-3 3 rack mainrack-2 3 host osd-host0 1 osd.0 up 11 1 osd.1 up 12 1 osd.2 up 1

6.6 檢查填滿的 OSDCeph 可阻止您向填滿的 OSD 寫入資料，以防遺失資料。在正常運作的叢集中，當

叢集接近其填滿比率時，您會收到警告。 mon osd full ratio 預設設為容量的 0.95

(95%)，達到該比率後，叢集會阻止用戶端寫入資料。 mon osd nearfull ratio 預設設

為容量的 0.85 (85%)，達到該比率時，叢集會產生狀態警告。

可透過 ceph health 指令報告填滿的 OSD 節點：

cephadm@adm > ceph health HEALTH_WARN 1 nearfull osds osd.2 is near full at 85%

或

cephadm@adm > ceph health HEALTH_ERR 1 nearfull osds, 1 full osds osd.2 is near full at 85% osd.3 is full at 97%

處理填滿的叢集的最佳方法是新增新的 OSD 主機/磁碟，以便讓叢集將資料重新分佈到

新的可用儲存空間。

提示：防止 OSD 填滿OSD 變滿 (即用完 100% 的磁碟空間) 之後，往往會迅速當機而不發出警告。管

理 OSD 節點時需記住下面幾點提示。

49 檢查填滿的 OSD SES 6

每個 OSD 的磁碟空間 (通常掛接於 /var/lib/ceph/osd/osd-{1,2..} 下)

需放置在專屬的基礎磁碟或分割區上。

檢查 Ceph 組態檔案，確定 Ceph 不會將其記錄檔案儲存在專供 OSD 使用

的磁碟/分割區上。

確定沒有其他程序寫入專供 OSD 使用的磁碟/分割區。

6.7 檢查監控程式狀態啟動叢集後，請在第一次讀取和/或寫入資料之前檢查 Ceph 監控程式的仲裁狀態。如

果叢集已在處理要求，請定期檢查 Ceph 監控程式的狀態，以確定其正在執行。

若要顯示監控程式地圖，請執行以下指令：

cephadm@adm > ceph mon stat

或

cephadm@adm > ceph mon dump

若要檢查監控程式叢集的仲裁狀態，請執行以下指令：

cephadm@adm > ceph quorum_status

Ceph 將傳回仲裁狀態。例如，由三個監控程式組成的 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": "192.168.1.10:6789\/0"}, { "rank": 1, "name": "b", "addr": "192.168.1.11:6789\/0"},

50 檢查監控程式狀態 SES 6

{ "rank": 2, "name": "c", "addr": "192.168.1.12:6789\/0"} ] }}

6.8 檢查放置群組狀態放置群組會將物件對應到 OSD。監控放置群組時，您希望它們處於 active 和 clean

狀態。如需詳細內容，請參閱第 6.11 節「監控 OSD 和放置群組」。

6.9 使用管理通訊端Ceph 管理通訊端可讓您透過通訊端介面查詢精靈。依預設，Ceph 通訊端存放在 /var/

run/ceph 下。若要透過管理通訊端存取精靈，請登入執行精靈的主機，並使用以下指

令：

cephadm@adm > ceph --admin-daemon /var/run/ceph/socket-name

若要檢視可用的管理通訊端指令，請執行以下指令：

cephadm@adm > ceph --admin-daemon /var/run/ceph/socket-name help

使用管理通訊端指令可在執行時期顯示和設定您的組態。如需詳細資訊，請參

閱第 16.1 節「執行時期組態」。

另外，您也可以直接在執行時期設定組態 (管理通訊端會繞過監控程式，這與 ceph

tell daemon-type . id injectargs 不同，後者依賴於監控程式，但不需要您直接登入

有問題的主機)。

6.10 儲存容量做為防止資料遺失的安全措施，當 Ceph 儲存叢集接近其容量上限時，Ceph 將阻止您

向 Ceph OSD 寫入或從中讀取資料。因此，讓生產叢集接近其填滿比率不是一種好的做

法，因為這樣會犧牲高可用性。預設的填滿比率設定為 0.95，即容量的 95%。對於所

含 OSD 數量較少的測試叢集而言，如此設定是非常激進的。

51 檢查放置群組狀態 SES 6

提示：增加儲存容量在監控叢集時，請注意與 nearfull 比率相關的警示。出現該警示表示，如果一

或多個 OSD 發生故障，某些 OSD 的故障可能會導致服務暫時中斷。請考慮新增

更多 OSD 以增加儲存容量。

測試叢集的一種常見情境是，系統管理員從 Ceph 儲存叢集中移除 Ceph OSD，等待叢

集重新達到平衡。然後再移除另一個 Ceph OSD，依此類推，直至叢集最終達到填滿比

率並鎖死。我們建議即使使用測試叢集時也進行一定的容量規劃。透過規劃，您可以

預估維持高可用性所需的備用容量。從理論上講，您需要規劃能夠應對一系列 Ceph

OSD 發生故障的情況的方案，使叢集無需立即取代這些 Ceph OSD 也可復原到 active

+ clean 狀態。您可以執行 active + degraded 狀態的叢集，但這不適合正常運作狀

態。

下圖展示了一個包含 33 個 Ceph 節點的簡化 Ceph 儲存叢集，其中每個主機有一個

Ceph OSD，每個 Ceph OSD 從 3 TB 磁碟機讀取以及向其中寫入資料。此範例叢集實

際的容量上限為 99 TB。 mon osd full ratio 選項設定為 0.95。如果叢集的剩餘容量

降至 5 TB，叢集將不允許用戶端讀取和寫入資料。因此，儲存叢集的運作容量為 95

TB，而不是 99 TB。

圖形 6.1︰ CEPH 叢集

在這樣的叢集中，有一或兩個 OSD 發生故障屬於正常現象。一種不常發生但合乎常理

的情況是機架的路由器或電源發生故障，導致多個 OSD (例如 OSD 7-12) 同時停機。

在這種情況下，您仍然應該設法使叢集保持正常執行並達到 active + clean 狀態，即

使這表示需要立即新增一些主機及額外的 OSD。如果容量使用率過高，您可能不會遺失

資料。但是，如果叢集的容量使用率超過填滿比率，您雖然解決了故障網域內發生的中

斷問題，卻可能會損失資料可用性。因此，我們建議至少進行大致的容量規劃。

52 儲存容量 SES 6

針對您的叢集確定以下兩個數值：

1. OSD 的數量。

2. 叢集的總容量。

如果您將叢集的總容量除以叢集中的 OSD 數量，將得到叢集內單個 OSD 的平均容量。

將該數值與您預期正常運作期間將同時發生故障的 OSD 數量 (一個相對較小的數值)

相乘。最後，將叢集容量與填滿比率相乘得到運作容量上限。然後，減去您預期將發生

故障的 OSD 中的資料量，即可得到一個合理的填滿比率。使用更高的 OSD 故障數 (整

個機架的 OSD) 重複上述過程，即可得到一個合理的接近填滿比率數值。

以下設定僅在建立叢集時適用，隨後會儲存在 OSD 地圖中：

[global] mon osd full ratio = .80 mon osd backfillfull ratio = .75 mon osd nearfull ratio = .70

提示這些設定僅在建立叢集時適用。此後，需要使用 ceph osd set-nearfull-ratio

和 ceph osd set-full-ratio 指令在 OSD 地圖中變更這些設定。

mon osd full ratio

在將 OSD 視為已滿之前使用的磁碟空間百分比。預設值為 0.95

mon osd backfillfull ratio

在將 OSD 視為過滿而無法回填之前使用的磁碟空間百分比。預設值為 0.90

mon osd nearfull ratio

在將 OSD 視為將滿之前使用的磁碟空間百分比。預設值為 0.85

提示：檢查 OSD 權數如果某些 OSD 將滿，但其他 OSD 的容量充足，則表示將滿 OSD 的 CRUSH 權數

可能有問題。

53 儲存容量 SES 6

6.11 監控 OSD 和放置群組

高可用性和高可靠性要求採用容錯方法來管理硬體和軟體問題。Ceph 沒有單一故障

點，並且可以在「已降級」模式下處理資料要求。Ceph 的資料放置引入了一個間接

層，以確定資料不會直接結合至特定 OSD 位址。這表示追蹤系統故障原因需要找到屬

於問題根源的放置群組和基礎 OSD。

提示：發生故障時的存取如果叢集的某個組件發生故障，叢集可能會阻止您存取某個特定物件，但這並不

表示您無法存取其他物件。遇到故障時，請執行相關步驟來監控 OSD 和放置群

組。然後開始進行疑難排解。

Ceph 一般情況下會進行自我修復。但如果問題仍然存在，監控 OSD 和放置群組將有助

於您找到問題所在。

6.11.1 監控 OSD

OSD 可能處於在叢集內 (「in」) 狀態，也可能處於在叢集外 (「out」) 狀態。同

時，它也可能處於啟用並執行中 (「up」) 或停機且未執行 (「down」) 狀態。如果

某個 OSD 處於「up」狀態，則它可能在叢集內 (您可以讀取和寫入資料)，也可能在叢

集外。如果該 OSD 之前在叢集內，最近已移出叢集，則 Ceph 會將放置群組移轉至其

他 OSD。如果某個 OSD 在叢集外，CRUSH 將不會為其指定放置群組。如果某個 OSD 處

於「down」狀態，則它應該也處於「out」狀態。

注意：狀況不良狀態如果某個 OSD 處於「down」和「in」狀態，則表示存在問題，並且叢集將處於

狀況不良狀態。

如果您執行 ceph health、 ceph -s 或 ceph -w 等指令，可能會注意到叢集並非永遠

回應 HEALTH OK。對於 OSD，您應當預期叢集在以下情況下不會回應 HEALTH OK：

54 監控 OSD 和放置群組 SES 6

您尚未啟動叢集 (它不會回應)。

您剛啟動或重新啟動了叢集，但它尚未準備就緒，因為系統正在建立放置群組，

並且 OSD 正在互聯。

您剛新增或移除了某個 OSD。

您剛修改了叢集地圖。

監控 OSD 的一個重要目的是確定當叢集已啟用且在執行時，叢集中的所有 OSD 也已啟

用且在執行。若要確定是否所有 OSD 都在執行，請執行以下指令：

root # ceph osd statx osds: y up, z in; epoch: eNNNN

結果應顯示 OSD 總數 (x)、處於「up」狀態的 OSD 數量 (y)、處於「in」狀態的 OSD

數量 (z)，以及地圖版本編號 (eNNNN)。如果在叢集內 (「in」) 的 OSD 數量大於處

於「up」狀態的 OSD 數量，請執行以下指令來確定未在執行的 ceph-osd 精靈：

root # ceph osd tree#ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF-1 2.00000 pool openstack-3 2.00000 rack dell-2950-rack-A-2 2.00000 host dell-2950-A10 ssd 1.00000 osd.0 up 1.00000 1.000001 ssd 1.00000 osd.1 down 1.00000 1.00000

如果某個 OSD (例如 ID 為 1 的 OSD) 停機，請將其啟動：

cephadm@osd > sudo systemctl start [email protected]

對於與已停止或不會重新啟動的 OSD 相關的問題，請參閱第 6.12 節「OSD 未在執

行」。

6.11.2 放置群組集

CRUSH 向 OSD 指定放置群組時，會查看池的複本數量，然後再為 OSD 指定放置群組，

以便將每個放置群組複本都指定給不同的 OSD。例如，如果池需要三個放置群組複

本，CRUSH 可能會將這三個複本分別指定給 osd.1、 osd.2 和 osd.3。CRUSH 實際上

會尋找一種虛擬隨機放置方法，這種方法會將您在 CRUSH 地圖中設定的故障網域納入

考量，因此在大型叢集中，您很少會看到放置群組指定給最鄰近的 OSD 的情況。我們

55 放置群組集 SES 6

將應包含特定放置群組的複本的 OSD 集稱為在任集。在某些情況下，在任集中的 OSD

會處於停機狀態，或者無法處理要存取放置群組中的物件的要求。當以下其中一種情況

發生時，可能會出現這些情況：

您新增或移除了某個 OSD。CRUSH 隨後會將放置群組重新指定給其他 OSD，因而

變更了在任集的組成部分，導致系統透過「回填」程序移轉資料。

某個 OSD 之前處於「down」狀態、之前進行了重新啟動，而現在正在復原。

在任集中的某個 OSD 處於「down」狀態，或者無法處理要求，並且另一個 OSD

已暫代其職。

Ceph 使用啟用集來處理用戶端要求，啟用集是實際處理要求的 OSD 集。在大多

數情況下，啟用集和在任集幾乎完全相同。當兩者不同時，可能表示 Ceph 正在

移轉資料、某個 OSD 正在復原，或者叢集存在問題 (例如，在此類情況下，Ceph

通常會回應 HEALTH WARN 狀態及「stuck stale」訊息)。

若要擷取放置群組清單，請執行以下指令：

cephadm@adm > ;ceph pg dump

若要檢視哪些 OSD 在給定放置群組的在任集或啟用集內，請執行以下指令：

cephadm@adm > ceph pg mapPG_NUMosdmap eNNN pg RAW_PG_NUM (PG_NUM) -> up [0,1,2] acting [0,1,2]

結果應該會顯示 OSD 地圖版本編號 (eNNN)、放置群組數量 ( PG_NUM )、啟用集

(「up」) 中的 OSD，以及在任集 (「acting」) 中的 OSD：

提示：叢集問題指示器如果啟用集與在任集不相符，則可能表示叢集正在自行重新平衡，或者叢集可能

存在問題。

6.11.3 建立互聯

放置群組必須處於「active」及「clean」狀態，您才能將資料寫入其中。為了讓 Ceph

確定某個放置群組的目前狀態，該放置群組的主 OSD (在任集中的第一個 OSD) 會與第

二個和第三個 OSD 建立互聯，以便就放置群組的目前狀態達成一致 (假設池中包含三

個放置群組複本)。

56 建立互聯 SES 6

圖形 6.2︰互聯綱要

6.11.4 監控放置群組狀態

如果您執行 ceph health、 ceph -s 或 ceph -w 等指令，可能會注意到叢集並非永遠

回應 HEALTH OK 訊息。檢查 OSD 是否正在執行之後，還應檢查放置群組狀態。

在一些與放置群組互聯相關的情況下，叢集預期將不會回應 HEALTH OK：

您剛建立了池，並且放置群組尚未互聯。

放置群組正在復原。

您剛新增了 OSD 至叢集，或剛從叢集中移除了 OSD。

您剛修改了 CRUSH 地圖，並且您的放置群組正在移轉。

在不同的放置群組複本中存在資料不一致的情況。

Ceph 正在整理放置群組的複本。

Ceph 的儲存容量不足，無法完成回填操作。

如果上述其中一種情況導致 Ceph 回應 HEALTH WARN，請不要驚慌。叢集在許多情況下

都會自行復原。在有些情況下，您可能需要採取措施。監控放置群組的一個重要目的是

要確定當叢集已啟用且在執行時，所有放置群組都處於「active」狀態，並且最好處於

「clean」狀態。若要查看所有放置群組的狀態，請執行以下指令：

57 監控放置群組狀態 SES 6

cephadm@adm > ceph pg statx pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB avail

結果應該會顯示放置群組總數 (x)、處於特定狀態 (例如「active+clean」) 的放置群

組數量 (y)，以及儲存的資料量 (z)。

除了放置群組狀態之外，Ceph 還會回應使用的儲存容量 (aa)、剩餘的儲存容量

(bb)，以及放置群組的總儲存容量。在以下情況下，這些數值可能非常重要：

已達到 near full ratio 或 full ratio。

由於您的 CRUSH 組態中存在錯誤，您的資料未在叢集中分佈。

提示：放置群組 ID放置群組 ID 由池編號 (並非池名稱) 加一個句點 (.)和放置群組 ID (一個十

六進位數) 組成。您可以在 ceph osd lspools 的輸出中檢視池編號及其名稱。

例如，預設池 rbd 與池編號 0 對應。完全合格的放置群組 ID 的格式如下：

POOL_NUM.PG_ID

通常顯示如下：

0.1f

若要擷取放置群組清單，請執行以下指令：

cephadm@adm > ceph pg dump

您還可以將輸出內容設定為 JSON 格式，並將其儲存到檔案中：

cephadm@adm > ceph pg dump -o FILE_NAME --format=json

若要查詢特定的放置群組，請執行以下指令：

cephadm@adm > ceph pg POOL_NUM.PG_ID query

以下清單詳細說明了常見的放置群組狀態。

CREATING (建立中)


當您建立池時，Ceph 會建立您指定數量的放置群組。Ceph 會在建立一或多個放

置群組時回應「creating」。建立放置群組之後，屬於放置群組在任集的各 OSD

將會互聯。完成互聯程序時，放置群組狀態應該為「active+clean」，這表示

Ceph 用戶端可以開始向放置群組寫入資料。

圖形 6.3︰放置群組狀態

PEERING (正在互聯)

當 Ceph 在對放置群組執行互聯操作時，會在儲存放置群組複本的各 OSD 之間就

該放置群組中物件和中繼資料的狀態達成一致。當 Ceph 完成互聯程序時，便表

示儲存放置群組的各 OSD 之間就放置群組的目前狀態達成一致。不過，完成互聯

程序並不表示每個複本都有最新的內容。

注意：權威歷程在在任集的所有 OSD 都持續進行寫入操作之前，Ceph 將不會向用戶端確認

寫入操作。這樣做可確保在上次成功互聯之後，至少有一個在任集成員將擁

有每個確認的寫入操作的記錄。

透過準確記錄每個確認的寫入操作，Ceph 可以建構並擴充一個新的權威放

置群組歷程，即一個完整且完全有序的操作集，如果執行該操作集，會將

OSD 的放置群組複本更新至最新狀態。

ACTIVE (使用中)

當 Ceph 完成互聯程序時，放置群組可能會變為「active」狀態。「Active」狀

態表示一般可在主放置群組和複本中使用放置群組中的資料來進行讀取和寫入操

作。

CLEAN (正常)

如果放置群組處於「clean」狀態，則表示主 OSD 和複本 OSD 已成功互聯，並且

該放置群組沒有流浪複本。Ceph 已將放置群組中的所有物件複製正確的次數。

DEGRADED (已降級)


當用戶端將物件寫入主 OSD 時，該主 OSD 負責將複本寫入複本 OSD。主 OSD 將

物件寫入儲存空間之後，放置群組將保持「degraded」狀態，直至主 OSD 收到了

複本 OSD 傳送的 Ceph 已成功建立複本物件的確認訊息。

放置群組有可能處於「active+degraded」狀態，這是因為即使 OSD 尚未儲存所

有物件，它也可能處於「active」狀態。如果某個 OSD 變成停機狀態，Ceph 會

將指定給該 OSD 的每個放置群組都標示為「degraded」。當該 OSD 恢復啟用狀

態後，各 OSD 必須再次互聯。不過，如果某個已降級放置群組處於「active」狀

態，用戶端仍然可以將新物件寫入該放置群組。

如果某個 OSD 處於「down」狀態，並且持續保持「degraded」狀況，Ceph 可能

會將該停機的 OSD 標示為「out」(表示移出叢集)，並將停機 (「down」) 的

OSD 的資料重新對應至另一個 OSD。透過 mon osd down out interval 選項來控

制從將 OSD 標示為「down」到將其標示為「out」相隔的時間，該選項預設設定

為 600 秒。

放置群組也可能處於「degraded」狀態，當 Ceph 找不到應在放置群組中的一或

多個物件時，便會發生此情況。雖然您無法讀取未找到的物件或向其寫入資料，

卻仍然可以存取「degraded」狀態的放置群組中的所有其他物件。

RECOVERING (正在復原)

Ceph 設計用於在發生硬體和軟體問題時進行大規模容錯。當 OSD 變成「down」

狀態時，其內容可能落後於放置群組中其他複本的目前狀態。當 OSD 恢復「up」

狀態時，必須更新放置群組的內容，以反映最新狀態。在此期間，OSD 可能會顯

現出「recovering」狀態。

復原並非永遠都是無足輕重的，因為硬體故障可能會導致多個 OSD 發生串聯故

障。例如，一個機架或機櫃的網路交換器可能會發生故障，這可能會導致一些主

機的 OSD 落後於叢集的目前狀態。解決故障之後，必須復原每個 OSD。

Ceph 提供了一些設定，用來平衡新服務要求與復原資料物件並將放置群組還原到

最新狀態的需求之間的資源爭用。 osd recovery delay start 設定允許 OSD 在

啟動復原程序之前重新啟動、重新互聯，甚至處理一些重播要求。 osd recovery

thread timeout 用於設定線串逾時，因為有可能會有多個 OSD 交錯發生故障、重

新啟動以及重新互聯。 osd recovery max active 設定用於限制 OSD 將同時處理

的復原要求數，以防止 OSD 無法處理要求。 osd recovery max chunk 設定用於限

制復原的資料區塊大小，以避免出現網路阻塞。

BACK FILLING (正在回填)


當新 OSD 加入叢集時，CRUSH 會將叢集中 OSD 的放置群組重新指定給新增的

OSD。強制新 OSD 立即接受重新指定的放置群組可能會使新 OSD 過載。向 OSD

回填放置群組可讓此程序在背景中開始。完成回填後，新 OSD 將在準備就緒時開

始處理要求。

在執行回填操作期間，系統可能會顯示以下其中一種狀態：「backfill_wait」

表示回填操作待處理，但尚未進行；「backfill」表示正在進行回填操作；

「backfill_too_full」表示已要求進行回填操作，但由於儲存容量不足而無法完

成。如果無法回填某個放置群組，則可能會將其視為「incomplete」。

Ceph 提供了一些設定來管理與向某個 OSD (尤其是新 OSD) 重新指定放置群組有

關的負載。 osd max backfills 預設將向或從一個 OSD 同時進行的最大回填數設

定為 10。 backfill full ratio 允許 OSD 在接近其填滿比率 (預設為 90%) 時拒

絕回填要求，並使用 ceph osd set-backfillfull-ratio 指令進行變更。如果某個

OSD 拒絕回填要求， osd backfill retry interval 可讓 OSD 重試要求 (預設在

10 秒後)。OSD 還可以設定 osd backfill scan min 和 osd backfill scan max，

以管理掃描間隔 (預設值分別為 64 和 512)。

REMAPPED (已重新對應)

當用於處理放置群組的在任集發生變化時，資料會從舊在任集移轉至新在任集。

新主 OSD 可能需要一段時間才能處理要求。因此，新主 OSD 可能會要求舊主

OSD 繼續處理要求，直至放置群組移轉完成。資料移轉完成時，對應將使用新在

任集的主 OSD。

STALE (過時)

儘管 Ceph 使用活動訊號來確定主機和精靈正在執行，但 ceph-osd 精靈也可

能會卡住，無法及時報告統計資料 (例如，當發生暫時的網路故障時)。依預

設，OSD 精靈每半秒鐘 (0.5) 報告一次其放置群組、開機及故障統計資料，這個

頻率高於活動訊號閾值。如果某個放置群組在任集的主 OSD 未能向監控程式報

告，或者其他 OSD 已將該主 OSD 報告為「down」，則監控程式會將該放置群組

標示為「stale」。

當您啟動叢集後，叢集常常會在互聯程序完成之前顯示為「stale」狀態。叢集執

行一段時間之後，如果放置群組顯示為「stale」狀態，則表示這些放置群組的主

OSD 處於停機狀態，或者未向監控程式報告放置群組統計資料。


6.11.5 識別存在問題的放置群組

如前文所述，狀態不是「active+clean」的放置群組未必存在問題。一般而言，當放置

群組卡住後，Ceph 的自我修復功能可能就無法運作。卡住的狀態包括：

Unclean (不正常)：放置群組包含未複製所需次數的物件。這些放置群組應該正

在復原。

Inactive (非使用中)：放置群組無法處理讀取或寫入操作，因為它們正在等待某

個具有最新資料的 OSD 恢復為啟用狀態。

Stale (過時)：放置群組處於未知狀態，因為代管它們的 OSD 已有一段時間未向

監控程式叢集報告 (透過 mon osd report timeout 選項設定)。

若要識別卡住的放置群組，請執行以下指令：

cephadm@adm > ceph pg dump_stuck [unclean|inactive|stale|undersized|degraded]

6.11.6 尋找物件位置

若要在 Ceph 物件儲存中儲存物件資料，Ceph 用戶端需要設定物件名稱並指定相關的

池。Ceph 用戶端會擷取最新的叢集地圖，並且 CRUSH 演算法會計算如何將物件對應至

放置群組，然後計算如何以動態方式將該放置群組指定給 OSD。若要尋找物件位置，您

只需知道物件名稱和池名稱。例如：

cephadm@adm > ceph osd map POOL_NAME OBJECT_NAME [NAMESPACE]

範例 6.1︰尋找物件

做為範例，我們來建立一個物件。在指令行上使用 rados put 指令指定物件名稱

「test-object-1」、包含一些物件資料的範例檔案「testfile.txt」的路徑，以

及池名稱「data」。

cephadm@adm > rados put test-object-1 testfile.txt --pool=data

若要確認 Ceph 物件儲存是否已儲存物件，請執行以下指令：

cephadm@adm > rados -p data ls

62 識別存在問題的放置群組 SES 6

現在，我們來確定物件位置。Ceph 將會輸出物件的位置：

cephadm@adm > ceph osd map data test-object-1osdmap e537 pool 'data' (0) object 'test-object-1' -> pg 0.d1743484 \(0.4) -> up ([1,0], p0) acting ([1,0], p0)

若要移除範例物件，只需使用 rados rm 指令將其刪除：

cephadm@adm > rados rm test-object-1 --pool=data

6.12 OSD 未在執行

在正常情況下，只需重新啟動 ceph-osd 精靈便可讓 OSD 重新加入叢集並復原。

6.12.1 OSD 不啟動

如果您啟動叢集後，某個 OSD 不啟動，請檢查以下幾項：

組態檔案：如果您無法透過執行全新安裝讓 OSD 保持執行狀態，請檢查組態檔案

以確定其符合標準 (例如，使用 host 而非 hostname )。

檢查路徑：檢查您的組態中的路徑以及資料和記錄的實際路徑。如果您將 OSD 資

料與記錄資料分開儲存，並且您的組態檔案或實際掛接中存在錯誤，則可能無法

啟動 OSD。如果要在區塊裝置上儲存記錄，則需要將記錄磁碟進行分割，並向每

個 OSD 指定一個分割區。

檢查最大線串計數：如果您的某個節點具有大量 OSD，您可能會達到預設的最大

線串數 (通常是 32,000)，在復原期間更是如此。您可以使用 sysctl 指令來增

加線串數，看看將最大線串數增加至允許的最大可能線串數 (例如 4194303) 是

否會有幫助：

root # sysctl -w kernel.pid_max=4194303

如果透過增加最大線串計數能夠解決問題，您可以在 /etc/sysctl.conf 檔案中指

定 kernel.pid_max 設定，以便永久使用該組態。

kernel.pid_max = 4194303

63 OSD 未在執行 SES 6

6.12.2 OSD 發生故障

當 ceph-osd 程序非正常終止時，監控程式將透過正常執行的 ceph-osd 精靈瞭解故障

情況，並使用 ceph health 指令報告該資訊：

cephadm@adm > ceph healthHEALTH_WARN 1/3 in osds are down

具體而言，當有 ceph-osd 程序標示為「in」和「down」時，您將收到警告。您可以透

過以下指令確定已停機的 ceph-osd：

cephadm@adm > ceph health detailHEALTH_WARN 1/3 in osds are downosd.0 is down since epoch 23, last address 192.168.106.220:6800/11080

如果發生阻止 ceph-osd 正常執行或重新啟動的磁碟故障或其他故障， /var/log/ceph

下該 OSD 的記錄檔案中應該會出現相應的錯誤訊息。

如果由於活動訊號故障導致精靈停止，基礎核心檔案系統可能無法回應。請檢查

dmesg 指令的輸出內容，以確定是磁碟錯誤還是其他核心錯誤。

6.12.3 無可用磁碟空間

Ceph 會阻止您向填滿的 OSD 寫入資料，以避免資料遺失。在正常運作的叢集中，當叢

集接近其填滿比率時，您會收到警告。 mon osd full ratio 選項預設設為容量的 0.95

(95%)，達到該比率時，叢集會阻止用戶端寫入資料。 mon osd backfillfull ratio 預

設設為容量的 0.90 (90%)，達到該比率時，叢集會阻止回填程序開始。OSD nearfull

ratio 預設設為容量的 0.85 (85%)，達到該比率時，叢集會產生狀態警告。您可以使

用以下指令變更「nearfull」的值：

cephadm@adm > ceph osd set-nearfull-ratio 0.0 to 1.0

在小型叢集上測試 Ceph 如何處理 OSD 故障時，通常會出現叢集填滿問題。如果有一

個節點的叢集資料百分比很高，叢集很容易就會立即超過「nearfull」和「full」比

率。如果您在小型叢集上測試 Ceph 如何應對 OSD 故障，則應留出充足的可用磁碟空

間，並考慮使用以下指令暫時降低 OSD full ratio、OSD backfillfull ratio 和 OSD

nearfull ratio：

cephadm@adm > ceph osd set-nearfull-ratio 0.0 to 1.0cephadm@adm > ceph osd set-full-ratio 0.0 to 1.0

64 OSD 發生故障 SES 6

cephadm@adm > ceph osd set-backfillfull-ratio 0.0 to 1.0

可透過 ceph health 指令報告填滿的 Ceph OSD：

cephadm@adm > ceph healthHEALTH_WARN 1 nearfull osd(s)

或

cephadm@adm > ceph health detailHEALTH_ERR 1 full osd(s); 1 backfillfull osd(s); 1 nearfull osd(s)osd.3 is full at 97%osd.4 is backfill full at 91%osd.2 is near full at 87%

處理填滿的叢集的最佳方法是新增新的 Ceph OSD，以便讓叢集將資料重新分佈到新的

可用儲存空間。

如果 OSD 因填滿而無法啟動，您可以透過刪除已滿 OSD 中的一些放置群組目錄來刪除

一些資料。

重要：刪除放置群組目錄如果您選擇刪除某個填滿的 OSD 上的放置群組目錄，請不要刪除其他填滿的

OSD 上的同一放置群組目錄，否則可能會出現資料遺失。您必須至少在一個 OSD

上保留至少一個資料複本。

65 無可用磁碟空間 SES 6

7 監控和警示

在 SUSE Enterprise Storage 6 中，DeepSea 不再在 Salt Master 上部署監控和警示

堆疊。使用者必須定義用於 Prometheus 和 Alertmanager 的 Prometheus 角色，以及

用於 Grafana 的 Grafana 角色。當#多個節點指定了 Prometheus 或 Grafana 角色

後，即部署好了高度可用的設定。

Prometheus 是監控和警示工具套件。

Alertmanager 用於處理 Prometheus 伺服器傳送的警示。

Grafana 是虛擬化和警示軟體。

prometheus-node_exporter 是所有 Salt Minion 上執行的服務。

DeepSea 會自動設定 Prometheus 組態和抓取目標 (輸出精靈)。它還會部署預設警示

清單，例如 health error、 10% OSDs down 或 pgs inactive。

7.1 Pillar 變數Salt Pillar 是用於向 Minion 提供資訊和組態值的鍵值儲存區。它可用於所有

Minion，每個 Minion 的內容都不同。Salt Pillar 中會預先填入預設值，您可以透過

以下兩種不同的方式進行自訂：

/srv/pillar/ceph/stack/global.yml：可變更所有節點的 Pillar 值。

/srv/pillar/ceph/stack/CLUSTER_NAME/minions/HOST：可變更特定 Minion 的組

態。

以下 Pillar 變數預設可用於所有節點：

monitoring: alertmanager: config: salt://path/to/config additional_flags: '' grafana: ssl_cert: False # self-signed certs are created by default ssl_key: False # self-signed certs are created by default prometheus: # pass additional configration to prometheus additional_flags: '' alert_relabel_config: []

66 Pillar 變數 SES 6

rule_files: [] # per exporter config variables scrape_interval: ceph: 10 node_exporter: 10 prometheus: 10 grafana: 10 relabel_config: alertmanager: [] ceph: [] node_exporter: [] prometheus: [] grafana: [] metric_relabel_config: ceph: [] node_exporter: [] prometheus: [] grafana: [] target_partition: ceph: '1/1' node_exporter: '1/1' prometheus: '1/1' grafana: '1/1'

7.2 Grafana透過 Grafana 加密所有流量。您可以提供自己的 SSL 證書，或者建立一個自行簽署的

證書。

Grafana 使用下列變數：

ssl_cert

ssl_key

如需提供自己的 SSL 證書的詳細資訊，請參閱第 22.9.1.2 節「CA 簽署的證書」；

若要建立自己的證書，請參閱第 22.9.1.1 節「自行簽署的證書」。

7.3 Prometheus以輸出程式#基礎的組態，可透過 Pillar 傳遞。這些群組對應至提供資料的輸出

程式。所有節點上都存在節點輸出程式，Ceph 管理員節點負責輸出 Ceph，相應的

Prometheus 和 Grafana 節點負責輸出 Prometheus 和 Grafana。

67 Grafana SES 6

Prometheus 使用下列變數：

scrape_interval：變更抓取間隔，即抓取輸出程式的頻率。

target_partition：當部署了多個 Prometheus 例項時，分割抓取目標，讓某些

Prometheus 例項僅抓取一部分輸出程式例項。

relabel_config：在抓取目標前動態重寫目標的標籤集。每個抓取組態可以設定多

個重新加上標籤步驟。

metrics_relabel_config：在擷取前的最後一步時套用於範例。

7.4 AlertmanagerAlertmanager 處理 Prometheus 伺服器傳送的警示。它負責重複資訊刪除、分組，並

將它們路由到正確的接收器。它還負責警示靜默。透過指令行旗標和用於定義禁止規

則、通知路由及通知接收器的組態檔案來設定 Alertmanager。

7.4.1 組態檔案

每個部署的 Alertmanager 組態都是不同的。因此，DeepSea 不會提供任何相關的

預設值。您需要提供自己的 alertmanager.yml 組態檔案。依預設， alertmanager

套件會安裝 /etc/prometheus/alertmanager.yml 組態檔案，該檔案可做為範例

組態使用。如果您更喜歡透過 DeepSea 來管理您的 Alertmanager 組態，請

將下面的鍵新增至 Pillar 中，例如，新增至 /srv/pillar/ceph/stack/ceph/

minions/YOUR_SALT_MASTER_MINION_ID.sls 檔案中：

如需完整的 Alertmanager 組態檔案範例，請參閱附錄 B 「SUSE Enterprise Storage

6 的預設警示」。

monitoring: alertmanager_config: /path/to/your/alertmanager/config.yml

Alertmanager 組態檔案採用 YAML 格式撰寫。它遵循下面所述的規則。括號中的參數

是選擇性參數。對於非清單參數，將使用預設值。規則中將使用下列通用預留位置：

DURATION

68 Alertmanager SES 6

與規則運算式 [0-9]+(ms|[smhdwy]) 相符的期間

LABELNAME

與規則運算式 [a-zA-Z_][a-zA-Z0-9_]* 相符的字串

LABELVALUE

採用 Unicode 字元的字串。

FILEPATH

目前工作目錄中的有效路徑。

BOOLEAN

接受「true」或「false」值的布林。

STRING

一般字串。

SECRET

屬於機密的一般字串，例如密碼。

TMPL_STRING

使範本在使用前顯示為展開狀態的字串。

TMPL_SECRET

使範本在使用前顯示為展開狀態的機密字串。

範例 7.1︰全域組態

global: 組態中的參數在所有其他組態內容中均有效。它們還可用做其他組態區

段的預設值。

global:# the time after which an alert is declared resolved if it has not been updated[ resolve_timeout: DURATION | default = 5m ]

# The default SMTP From header field.[ smtp_from: TMPL_STRING ]# The default SMTP smarthost used for sending emails, including port number.# Port number usually is 25, or 587 for SMTP over TLS# (sometimes referred to as STARTTLS).# Example: smtp.example.org:587[ smtp_smarthost: STRING ]# The default host name to identify to the SMTP server.[ smtp_hello: STRING | default = "localhost" ][ smtp_auth_username: STRING ]

69 組態檔案 SES 6

# SMTP Auth using LOGIN and PLAIN.[ smtp_auth_password: SECRET ]# SMTP Auth using PLAIN.[ smtp_auth_identity: STRING ]# SMTP Auth using CRAM-MD5.[ smtp_auth_secret: SECRET ]# The default SMTP TLS requirement.[ smtp_require_tls: BOOL | default = true ]

# The API URL to use for Slack notifications.[ slack_api_url: STRING ][ victorops_api_key: STRING ][ victorops_api_url: STRING | default = "https://victorops.example.com/integrations/alert/" ][ pagerduty_url: STRING | default = "https://pagerduty.example.com/v2/enqueue" ][ opsgenie_api_key: STRING ][ opsgenie_api_url: STRING | default = "https://opsgenie.example.com/" ][ hipchat_api_url: STRING | default = "https://hipchat.example.com/" ][ hipchat_auth_token: SECRET ][ wechat_api_url: STRING | default = "https://wechat.example.com/cgi-bin/" ][ wechat_api_secret: SECRET ][ wechat_api_corp_id: STRING ]

# The default HTTP client configuration[ http_config: HTTP_CONFIG ]

# Files from which custom notification template definitions are read.# The last component may use a wildcard matcher, e.g. 'templates/*.tmpl'.templates:[ - FILEPATH ... ]

# The root node of the routing tree.route: ROUTE

# A list of notification receivers.receivers:- RECEIVER ...

# A list of inhibition rules.inhibit_rules:[ - INHIBIT_RULE ... ]

範例 7.2︰ ROUTE

ROUTE 區塊定義路由樹狀結構中的節點。對於未指定的參數，會繼承其父節點的

設定。每條警示都會進入路由樹狀結構中所設定的頂層路由，該層路由需要與所

有警示相符。然後，警示會周遊子節點。如果 continue 選項設定為「false」，

會在找到第一個相符的子節點後停止周遊。如果相符的節點上將該選項設定為

「true」，警示將繼續比對後續旁支。如果警示未與節點的任何子節點相符，將

依據目前節點的組態參數處理警示。


[ receiver: STRING ][ group_by: '[' LABELNAME, ... ']' ]

# If an alert should continue matching subsequent sibling nodes.[ continue: BOOLEAN | default = false ]

# A set of equality matchers an alert has to fulfill to match a node.match: [ LABELNAME: LABELVALUE, ... ]

# A set of regex-matchers an alert has to fulfill to match a node.match_re: [ LABELNAME: REGEX, ... ]

# Time to wait before sending a notification for a group of alerts.[ group_wait: DURATION | default = 30s ]

# Time to wait before sending a notification about new alerts# added to a group of alerts for which an initial notification has# already been sent.[ group_interval: DURATION | default = 5m ]

# Time to wait before re-sending a notification[ repeat_interval: DURATION | default = 4h ]

# Possible child routes.routes: [ - ROUTE ... ]

範例 7.3︰ INHIBIT_RULE

如果存在與一組比對器相符的來源警示，禁止規則會將與另一組比對器相符的目

標警示靜音。對於 equal 清單中的標籤名稱，兩個警示需要共用相同的標籤值。

這樣兩個警示便可相符，從而自行禁止。請勿撰寫警示與來源和目標均相符的禁

止規則。

# Matchers that need to be fulfilled for the alerts to be muted.target_match: [ LABELNAME: LABELVALUE, ... ]target_match_re: [ LABELNAME: REGEX, ... ]

# Matchers for which at least one alert needs to exist so that the# inhibition occurs.source_match: [ LABELNAME: LABELVALUE, ... ]source_match_re: [ LABELNAME: REGEX, ... ]


# Labels with an equal value in the source and target# alert for the inhibition to take effect.[ equal: '[' LABELNAME, ... ']' ]

範例 7.4︰ HTTP_CONFIG

HTTP_CONFIG 設定接收器用於與 API 服務通訊的 HTTP 用戶端。

請注意， basic_auth、 bearer_token 和 bearer_token_file 選項是互斥的。

# Sets the 'Authorization' header with the user name and password.basic_auth:[ username: STRING ][ password: SECRET ]

# Sets the 'Authorization' header with the bearer token.[ bearer_token: SECRET ]

# Sets the 'Authorization' header with the bearer token read from a file.[ bearer_token_file: FILEPATH ]

# TLS settings.tls_config:# CA certificate to validate the server certificate with.[ ca_file: FILEPATH ]# Certificate and key files for client cert authentication to the server.[ cert_file: FILEPATH ][ key_file: FILEPATH ]# ServerName extension to indicate the name of the server.# http://tools.ietf.org/html/rfc4366#section-3.1[ server_name: STRING ]# Disable validation of the server certificate.[ insecure_skip_verify: BOOLEAN | default = false]

# Optional proxy URL.[ proxy_url: STRING ]

範例 7.5︰ RECEIVER

接收器是一或多個通知整合的具名組態。

我們建議不要新增新接收器，而是應使用 Webhook 接收器實作自訂通知整合 (請

參閱範例 7.15 「WEBHOOK_CONFIG」)。

# The unique name of the receiver.name: STRING

# Configurations for several notification integrations.email_configs:[ - EMAIL_CONFIG, ... ]


hipchat_configs:[ - HIPCHAT_CONFIG, ... ]pagerduty_configs:[ - PAGERDUTY_CONFIG, ... ]pushover_configs:[ - PUSHOVER_CONFIG, ... ]slack_configs:[ - SLACK_CONFIG, ... ]opsgenie_configs:[ - OPSGENIE_CONFIG, ... ]webhook_configs:[ - WEBHOOK_CONFIG, ... ]victorops_configs:[ - VICTOROPS_CONFIG, ... ]wechat_configs:[ - WECHAT_CONFIG, ... ]

範例 7.6︰ EMAIL_CONFIG

# Whether to notify about resolved alerts.[ send_resolved: BOOLEAN | default = false ]

# The email address to send notifications to.to: TMPL_STRING

# The sender address.[ from: TMPL_STRING | default = global.smtp_from ]

# The SMTP host through which emails are sent.[ smarthost: STRING | default = global.smtp_smarthost ]

# The host name to identify to the SMTP server.[ hello: STRING | default = global.smtp_hello ]

# SMTP authentication details.[ auth_username: STRING | default = global.smtp_auth_username ][ auth_password: SECRET | default = global.smtp_auth_password ][ auth_secret: SECRET | default = global.smtp_auth_secret ][ auth_identity: STRING | default = global.smtp_auth_identity ]

# The SMTP TLS requirement.[ require_tls: BOOL | default = global.smtp_require_tls ]

# The HTML body of the email notification.[ html: TMPL_STRING | default = '{{ template "email.default.html" . }}' ]# The text body of the email notification.[ text: TMPL_STRING ]

# Further headers email header key/value pairs. Overrides any headers# previously set by the notification implementation.[ headers: { STRING: TMPL_STRING, ... } ]


範例 7.7︰ HIPCHAT_CONFIG

# Whether or not to notify about resolved alerts.[ send_resolved: BOOLEAN | default = false ]

# The HipChat Room ID.room_id: TMPL_STRING# The authentication token.[ auth_token: SECRET | default = global.hipchat_auth_token ]# The URL to send API requests to.[ api_url: STRING | default = global.hipchat_api_url ]

# A label to be shown in addition to the sender's name.[ from: TMPL_STRING | default = '{{ template "hipchat.default.from" . }}' ]# The message body.[ message: TMPL_STRING | default = '{{ template "hipchat.default.message" . }}' ]# Whether this message will trigger a user notification.[ notify: BOOLEAN | default = false ]# Determines how the message is treated by the alertmanager and rendered inside HipChat. Valid values are 'text' and 'html'.[ message_format: STRING | default = 'text' ]# Background color for message.[ color: TMPL_STRING | default = '{{ if eq .Status "firing" }}red{{ else }}green{{ end }}' ]

# Configuration of the HTTP client.[ http_config: HTTP_CONFIG | default = global.http_config ]

範例 7.8︰ PAGERDUTY_CONFIG

routing_key 和 service_key 選項是互斥的。

# Whether or not to notify about resolved alerts.[ send_resolved: BOOLEAN | default = true ]

# The PagerDuty integration key (when using 'Events API v2').routing_key: TMPL_SECRET# The PagerDuty integration key (when using 'Prometheus').service_key: TMPL_SECRET

# The URL to send API requests to.[ url: STRING | default = global.pagerduty_url ]

# The client identification of the Alertmanager.[ client: TMPL_STRING | default = '{{ template "pagerduty.default.client" . }}' ]# A backlink to the notification sender.[ client_url: TMPL_STRING | default = '{{ template "pagerduty.default.clientURL" . }}' ]

# The incident description.[ description: TMPL_STRING | default = '{{ template "pagerduty.default.description" .}}' ]


# Severity of the incident.[ severity: TMPL_STRING | default = 'error' ]

# A set of arbitrary key/value pairs that provide further details.[ details: { STRING: TMPL_STRING, ... } | default = { firing: '{{ template "pagerduty.default.instances" .Alerts.Firing }}' resolved: '{{ template "pagerduty.default.instances" .Alerts.Resolved }}' num_firing: '{{ .Alerts.Firing | len }}' num_resolved: '{{ .Alerts.Resolved | len }}'} ]

# The HTTP client's configuration.[ http_config: HTTP_CONFIG | default = global.http_config ]

範例 7.9︰ PUSHOVER_CONFIG


# The recipient user key.user_key: SECRET

# Registered application’s API token.token: SECRET

# Notification title.[ title: TMPL_STRING | default = '{{ template "pushover.default.title" . }}' ]

# Notification message.[ message: TMPL_STRING | default = '{{ template "pushover.default.message" . }}' ]

# A supplementary URL displayed together with the message.[ url: TMPL_STRING | default = '{{ template "pushover.default.url" . }}' ]

# Priority.[ priority: TMPL_STRING | default = '{{ if eq .Status "firing" }}2{{ else }}0{{ end }}' ]

# How often the Pushover servers will send the same notification (at least 30 seconds).[ retry: DURATION | default = 1m ]

# How long your notification will continue to be retried (unless the user# acknowledges the notification).[ expire: DURATION | default = 1h ]


範例 7.10︰ SLACK_CONFIG

# Whether or not to notify about resolved alerts.


[ send_resolved: BOOLEAN | default = false ]

# The Slack webhook URL.[ api_url: SECRET | default = global.slack_api_url ]

# The channel or user to send notifications to.channel: TMPL_STRING

# API request data as defined by the Slack webhook API.[ icon_emoji: TMPL_STRING ][ icon_url: TMPL_STRING ][ link_names: BOOLEAN | default = false ][ username: TMPL_STRING | default = '{{ template "slack.default.username" . }}' ]# The following parameters define the attachment.actions:[ ACTION_CONFIG ... ][ color: TMPL_STRING | default = '{{ if eq .Status "firing" }}danger{{ else }}good{{ end }}' ][ fallback: TMPL_STRING | default = '{{ template "slack.default.fallback" . }}' ]fields:[ FIELD_CONFIG ... ][ footer: TMPL_STRING | default = '{{ template "slack.default.footer" . }}' ][ pretext: TMPL_STRING | default = '{{ template "slack.default.pretext" . }}' ][ short_fields: BOOLEAN | default = false ][ text: TMPL_STRING | default = '{{ template "slack.default.text" . }}' ][ title: TMPL_STRING | default = '{{ template "slack.default.title" . }}' ][ title_link: TMPL_STRING | default = '{{ template "slack.default.titlelink" . }}' ][ image_url: TMPL_STRING ][ thumb_url: TMPL_STRING ]


範例 7.11︰ SLACK_CONFIG 的 ACTION_CONFIG

# Provide a button to tell Slack you want to render a button.type: TMPL_STRING# Label for the button.text: TMPL_STRING# http or https URL to deliver users to. If you specify invalid URLs, the message will be posted with no button.url: TMPL_STRING# If set to 'primary', the button will be green, indicating the best forward action to take# 'danger' turns the button red, indicating a destructive action.[ style: TMPL_STRING [ default = '' ]

範例 7.12︰ SLACK_CONFIG 的 FIELD_CONFIG

# A bold heading without markup above the value text.title: TMPL_STRING# The text of the field. It can span across several lines.


value: TMPL_STRING# A flag indicating if value is short enough to be displayed together with other values.[ short: BOOLEAN | default = slack_config.short_fields ]

範例 7.13︰ OPSGENIE_CONFIG


# The API key to use with the OpsGenie API.[ api_key: SECRET | default = global.opsgenie_api_key ]

# The host to send OpsGenie API requests to.[ api_url: STRING | default = global.opsgenie_api_url ]

# Alert text (maximum is 130 characters).[ message: TMPL_STRING ]

# A description of the incident.[ description: TMPL_STRING | default = '{{ template "opsgenie.default.description" . }}' ]

# A backlink to the sender.[ source: TMPL_STRING | default = '{{ template "opsgenie.default.source" . }}' ]

# A set of arbitrary key/value pairs that provide further detail.[ details: { STRING: TMPL_STRING, ... } ]

# Comma separated list of team responsible for notifications.[ teams: TMPL_STRING ]

# Comma separated list of tags attached to the notifications.[ tags: TMPL_STRING ]

# Additional alert note.[ note: TMPL_STRING ]

# Priority level of alert, one of P1, P2, P3, P4, and P5.[ priority: TMPL_STRING ]

# Configuration of the HTTP.[ http_config: HTTP_CONFIG | default = global.http_config ]

範例 7.14︰ VICTOROPS_CONFIG


# The API key for talking to the VictorOps API.[ api_key: SECRET | default = global.victorops_api_key ]

# The VictorOps API URL.


[ api_url: STRING | default = global.victorops_api_url ]

# A key used to map the alert to a team.routing_key: TMPL_STRING

# Describes the behavior of the alert (one of 'CRITICAL', 'WARNING', 'INFO').[ message_type: TMPL_STRING | default = 'CRITICAL' ]

# Summary of the alerted problem.[ entity_display_name: TMPL_STRING | default = '{{ template "victorops.default.entity_display_name" . }}' ]

# Long explanation of the alerted problem.[ state_message: TMPL_STRING | default = '{{ template "victorops.default.state_message" . }}' ]

# The monitoring tool the state message is from.[ monitoring_tool: TMPL_STRING | default = '{{ template "victorops.default.monitoring_tool" . }}' ]


範例 7.15︰ WEBHOOK_CONFIG

您可以使用 Webhook 接收器來設定通用接收器。


# The endpoint for sending HTTP POST requests.url: STRING


Alertmanager 會傳送以下 JSON 格式的 HTTP POST 要求：

{ "version": "4", "groupKey": STRING, // identifycation of the group of alerts (to deduplicate) "status": "<resolved|firing>", "receiver": STRING, "groupLabels": OBJECT, "commonLabels": OBJECT, "commonAnnotations": OBJECT, "externalURL": STRING, // backlink to Alertmanager. "alerts": [ { "status": "<resolved|firing>", "labels": OBJECT,


"annotations": OBJECT, "startsAt": "<rfc3339>", "endsAt": "<rfc3339>", "generatorURL": STRING // identifies the entity that caused the alert }, ... ]}

Webhook 接收器允許與以下通知機制整合：

DingTalk (https://github.com/timonwong/prometheus-webhook-dingtalk)

IRC Bot (https://github.com/multimfi/bot)

JIRAlert (https://github.com/free/jiralert)

Phabricator / Maniphest (https://github.com/knyar/phalerts)

prom2teams：將通知轉遞給 Microsoft Teams (https://github.com/

idealista/prom2teams)

SMS：支援多個提供者 (https://github.com/messagebird/sachet)

Telegram bot (https://github.com/inCaller/prometheus_bot)

SNMP 設陷 (https://github.com/SUSE/prometheus-webhook-snmp)

範例 7.16︰ WECHAT_CONFIG

# Whether or not to notify about resolved alerts.[ send_resolved: BOOLEAN | default = false ]

# The API key to use for the WeChat API.[ api_secret: SECRET | default = global.wechat_api_secret ]

# The WeChat API URL.[ api_url: STRING | default = global.wechat_api_url ]

# The corp id used to authenticate.[ corp_id: STRING | default = global.wechat_api_corp_id ]

# API request data as defined by the WeChat API.[ message: TMPL_STRING | default = '{{ template "wechat.default.message" . }}' ][ agent_id: STRING | default = '{{ template "wechat.default.agent_id" . }}' ][ to_user: STRING | default = '{{ template "wechat.default.to_user" . }}' ][ to_party: STRING | default = '{{ template "wechat.default.to_party" . }}' ][ to_tag: STRING | default = '{{ template "wechat.default.to_tag" . }}' ]


7.4.2 自訂警示

您可以定義自訂警示條件，以將通知傳送到外部服務。Prometheus 使用自己的運算式

語言來定義自訂警示。下面是一個含警示的規則範例：

groups:- name: example rules: # alert on high deviation from average PG count - alert: high pg count deviation expr: abs(((ceph_osd_pgs > 0) - on (job) group_left avg(ceph_osd_pgs > 0) by (job)) / on (job) group_left avg(ceph_osd_pgs > 0) by (job)) > 0.35 for: 5m labels: severity: warning type: ses_default annotations: description: > OSD {{ $labels.osd }} deviates by more then 30% from average PG count

for 子句 (選擇性) 指定 Prometheus 從第一次遇到新運算式輸出向量元素到將警示

視為觸發需等待的時間。在此情況下，Prometheus 將檢查警示是否持續保持使用中狀

態 5 分鐘，然後再觸發警示。待處理的元素視為處於使用中狀態，但尚未觸發。

labels 子句指定要附加至警示的一組額外的標籤。系統會覆寫衝突的標籤。可以為標

籤設定範本 (如需設定範本的更多詳細資料，請參閱第 7.4.2.1 節「範本」)。

annotations 子句指定資訊標籤。您可以使用註釋儲存額外的資訊，例如警示描

述或 Runbook 連結。可以為註釋設定範本 (如需設定範本的更多詳細資料，請參

閱第 7.4.2.1 節「範本」)。

若要新增自訂警示至 SUSE Enterprise Storage 6，請

將包含自訂警示的 YAML 檔案放在 /etc/prometheus/alerts 目錄中

或

在 Pillar 中的 monitoring:custom_alerts 鍵下提供自訂警示檔

案的路徑清單。DeepSea 階段 2 或 salt SALT_MASTER state.apply

ceph.monitoring.prometheus 指令會將您的警示檔案新增至正確的位置。

範例 7.17︰新增自訂警示至 SUSE ENTERPRISE STORAGE

包含自訂警示的檔案存放在 Salt Master 上的 /root/my_alerts/

my_alerts.yml 中。如果您新增

80 自訂警示 SES 6

monitoring: custom_alerts: - /root/my_alerts/my_alerts.yml

至 /srv/pillar/ceph/cluster/YOUR_SALT_MASTER_MINION_ID.sls 檔案

中，DeepSea 將會建立 /etc/prometheus/alerts/my_alerts.yml 檔案，並重

新啟動 Prometheus。

7.4.2.1 範本

您可以使用範本來提供標籤和注釋值。 $labels 變數包含警示例項的標籤鍵/值組，而

$value 則存放警示例項的評估值。

下面的範例將插入一個觸發的元素標籤和值：

{{ $labels.LABELNAME }}{{ $value }}

7.4.2.2 執行時期檢查警示

如果您需要確認哪些警示處於使用中狀態，可以採用以下幾種方式：

導覽至 Prometheus 的警示索引標籤。該索引標籤會顯示所定義警示處於使用中

狀態的確切標籤集。Prometheus 還會儲存待處理和觸發警示的綜合時間系列。它

們的格式如下：

ALERTS{alertname="ALERT_NAME", alertstate="pending|firing", ADDITIONAL_ALERT_LABELS}

如果警示處於使用中狀態 (待處理或觸發)，則範例值為 1。當警示處於非使用中

狀態時，該系列會標示為「stale」。

在 Prometheus Web 介面 (URL 位址為 http:// PROMETHEUS_HOST_IP :9090/

alerts) 中，檢查警示及其狀態 (非使用中、待處理或觸發)。

在 Alertmanager Web 介面 (URL 位址為 http:// PROMETHEUS_HOST_IP :9093/#/

alerts) 中，檢查警示並視需要將其設#靜默。

81 自訂警示 SES 6

7.4.3 SNMP 設陷接收器

如果您想透過 SNMP 設陷接收有關 Prometheus 警示的通知，可以透過 DeepSea 安

裝 Prometheus Alertmanager SNMP 設陷接收器。若要執行此操作，您需要在 Pillar

中的 monitoring:alertmanager_receiver_snmp:enabled 鍵下啟用相應設定。必須在

monitoring:alertmanager_receiver_snmp:config 鍵下設定接收器的組態。DeepSea 階

段 2 或 salt SALT_MASTER state.apply ceph.monitoring.alertmanager 指令將會在相

應位置安裝並設定接收器。

範例 7.18︰ SNMP 設陷組態

monitoring: alertmanager: receiver: snmp: enabled: True config: host: localhost port: 9099 snmp_host: snmp.foo-bar.com snmp_community: private metrics: True

請參閱 https://github.com/SUSE/prometheus-webhook-snmp#global-

configuration-file 上的接收器手冊，以瞭解有關組態選項的更多詳細資料。

82 SNMP 設陷接收器 SES 6

https://github.com/SUSE/prometheus-webhook-snmp#global-configuration-file

https://github.com/SUSE/prometheus-webhook-snmp#global-configuration-file

8 使用 cephx 進行驗證

為了識別用戶端並防禦中間人攻擊，Ceph 提供了 cephx 驗證系統。在此環境中，用

戶端表示人類使用者 (例如 admin 使用者) 或 Ceph 相關的服務/精靈 (例如 OSD、監

控程式或物件閘道)。

注意cephx 通訊協定不會處理 TLS/SSL 之類的傳輸中資料加密。

8.1 驗證架構

cephx 使用共用機密金鑰進行驗證，這表示用戶端和 Ceph 監控程式都有用戶端機密

金鑰的副本。驗證通訊協定可讓雙方互相證明各自擁有金鑰的副本，且無需真正透露金

鑰。這樣就實現了雙向驗證，即，叢集可確定使用者擁有機密金鑰，而使用者亦可確定

叢集擁有機密金鑰的副本。

Ceph 的一項重要延展性功能就是不需要透過集中式介面即可與 Ceph 物件儲存互動。

這表示 Ceph 用戶端可直接與 OSD 互動。為了保護資料，Ceph 提供了 cephx 驗證系

統來對 Ceph 用戶端進行驗證。

每個監控程式都可對用戶端進行驗證並分發金鑰，因此，在使用 cephx 時，不會出現

單一故障點或瓶頸。監控程式會傳回驗證資料結構，其中包含獲取 Ceph 服務時要用到

的工作階段金鑰。此工作階段金鑰自身已使用用戶端的永久機密金鑰進行了加密，因

此，只有用戶端才能向 Ceph 監控程式要求服務。然後，用戶端會使用工作階段金鑰向

監控程式要求所需的服務，監控程式會為用戶端提供一個票證，用於向實際處理資料的

OSD 驗證用戶端。Ceph 監控程式和 OSD 共用一個機密，因此，用戶端可使用監控程

式提供的票證向叢集中的任何 OSD 或中繼資料伺服器表明身分。 cephx 票證有過期時

間，因此，攻擊者無法使用已過期的票證或以不當方式獲取的工作階段金鑰。

若要使用 cephx，管理員必須先設定用戶端/使用者。在下圖中， client.admin 使用者

從指令行呼叫 ceph auth get-or-create-key 來產生使用者名稱和機密金鑰。Ceph 的

auth 子系統會產生該使用者名稱和金鑰，在監控程式中儲存一個副本，並將該使用者

的機密傳回給 client.admin 使用者。這表示用戶端和監控程式共用一個機密金鑰。

83 驗證架構 SES 6

圖形 8.1︰ cephx 的基本驗證

若要在監控程式中進行驗證，用戶端需將使用者名稱傳遞給監控程式。監控程式會產生

一個工作階段金鑰，並使用與該使用者名稱關聯的機密金鑰來加密該工作階段金鑰，然

後將加密的票證傳回給用戶端。之後，用戶端會使用共用的機密金鑰解密資料，以擷取

工作階段金鑰。工作階段金鑰可識別目前工作階段的使用者。然後，用戶端會要求與該

使用者相關、由工作階段金鑰簽署的票證。監控程式會產生一個票證，以使用者的機密

金鑰對其加密，然後將其傳回給用戶端。用戶端解密該票證，並使用它來簽署傳至整個

叢集中的 OSD 和中繼資料伺服器的要求。

圖形 8.2︰ cephx 驗證

84 驗證架構 SES 6

cephx 通訊協定會對用戶端機器與 Ceph 伺服器之間進行的通訊進行驗證。完成初始

驗證後，將使用監控程式、OSD 和中繼資料伺服器可透過共用機密進行驗證的票證，來

簽署用戶端與伺服器之間傳送的每條訊息。

圖形 8.3︰ cephx 驗證 - MDS 和 OSD

重要這種驗證提供的保護僅限於 Ceph 用戶端與 Ceph 叢集主機之間，驗證不會延伸

到 Ceph 用戶端以外。如果使用者從遠端主機存取 Ceph 用戶端，則不會對使用

者主機與用戶端主機之間的連接套用 Ceph 驗證。

8.2 金鑰管理

本節介紹 Ceph 用戶端使用者，以及如何在 Ceph 儲存叢集中對其進行驗證和授權。使

用者是指使用 Ceph 用戶端來與 Ceph 儲存叢集精靈互動的個人或系統參與者 (例如應

用程式)。

85 金鑰管理 SES 6

Ceph 在啟用驗證和授權 (預設啟用) 的情況下執行時，您必須指定一個使用者名稱，

以及包含所指定使用者的機密金鑰的金鑰圈 (通常透過指令行指定)。如果您未指定

使用者名稱，Ceph 將使用 client.admin 做為預設使用者名稱。如果您未指定金鑰

圈，Ceph 將透過 Ceph 組態檔案中的金鑰圈設定來尋找金鑰圈。例如，如果您在未指

定使用者名稱或金鑰圈的情況下執行 ceph health 指令，Ceph 將依如下所示解釋該指

令：

cephadm@adm > ceph -n client.admin --keyring=/etc/ceph/ceph.client.admin.keyring health

或者，您可以使用 CEPH_ARGS 環境變數來避免重複輸入使用者名稱和機密。

8.2.1 背景資訊

無論 Ceph 用戶端是何類型 (例如，區塊裝置、物件儲存、檔案系統、原生

API)，Ceph 都會在池中將所有資料儲存為物件。Ceph 使用者需要擁有池存取權才能讀

取和寫入資料。此外，Ceph 使用者必須擁有執行權限才能使用 Ceph 的管理指令。以

下概念可協助您理解 Ceph 使用者管理。

8.2.1.1 使用者

使用者是指個人或系統參與者 (例如應用程式)。透過建立使用者，您可以控制誰 (或

哪個參與者) 能夠存取您的 Ceph 儲存叢集、其池及池中的資料。

Ceph 使用多種類型的使用者。進行使用者管理時，將一律使用 client 類型。Ceph

透過句點 (.) 分隔格式來識別使用者，該格式由使用者類型和使用者 ID 組成。例

如， TYPE.ID、 client.admin 或 client.user1。區分使用者類型的原因在於，Ceph 監

控程式、OSD 和中繼資料伺服器也使用 cephx 通訊協定，但它們並非用戶端。區分使

用者類型有助於將用戶端使用者與其他使用者區分開來，從而簡化存取控制、使用者監

控和追溯性。

有時，Ceph 的使用者類型可能會令人混淆，因為依據指令行用法的不同，Ceph 指令行

允許您指定具有類型的使用者或不具有類型的使用者。如果您指定 --user 或 --id，

則可以省略類型。因此，可將 client.user1 簡單地輸入為 user1。如果您指定的是

--name 或 -n，則必須指定類型和名稱，例如 client.user1。做為最佳實務，我們建

議儘可能使用類型和名稱。

86 背景資訊 SES 6

注意Ceph 儲存叢集使用者與 Ceph 物件儲存使用者或 Ceph 檔案系統使用者均不

同。Ceph 物件閘道使用 Ceph 儲存叢集使用者在閘道精靈與儲存叢集之間通

訊，但閘道有自己的使用者管理功能來管理最終使用者。Ceph 檔案系統使用

POSIX 語意。與其關聯的使用者空間和 Ceph 儲存叢集使用者不同。

8.2.1.2 授權和能力

Ceph 使用「能力」(caps) 術語來描述對已驗證的使用者進行授權，允許其運用監控

程式、OSD 和中繼資料伺服器的功能。功能還可限制對池或池名稱空間內的資料的存

取。Ceph 管理使用者可在建立或更新使用者時設定使用者的能力。

能力語法的格式如下：

daemon-type 'allow capability' [...]

下面是每個服務類型的能力清單：

監控程式能力

包括 r、 w、 x 和 allow profile cap。

mon 'allow rwx'mon 'allow profile osd'

OSD 能力

包括 r、 w、 x、 class-read、 class-write 和 profile osd。此外，使用 OSD

能力還能進行池和名稱空間設定。

osd 'allow capability' [pool=poolname] [namespace=namespace-name]

MDS 能力

只需要 allow，或留為空白。

mds 'allow'

以下各項描述了每個能力：

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 開機的權限。授權給部署工具，使其在將 OSD 開機時有權新

增金鑰。

profile bootstrap-mds

授予使用者將中繼資料伺服器開機的權限。授權給部署工具，使其在將中繼資料

伺服器開機時有權新增金鑰。

8.2.1.3 池

池是指使用者在其中儲存資料的邏輯分割區。在 Ceph 部署中，常見的做法是為相似類

型的資料建立一個池做為邏輯分割區。例如，將 Ceph 部署為 OpenStack 的後端時，

一般的部署方式是為磁碟區、影像、備份和虛擬機器以及使用者 (如 client.glance

或 client.cinder ) 建立相應的池。


8.2.2 管理使用者

使用者管理功能可讓 Ceph 叢集管理員能夠直接在 Ceph 叢集中建立、更新和刪除使用

者。

在 Ceph 叢集中建立或刪除使用者時，可能需要將金鑰分發到用戶端，以便可將金鑰新

增至金鑰圈。如需詳細資料，請參閱第 8.2.3 節「金鑰圈管理」。

8.2.2.1 列出使用者

若要列出叢集中的使用者，請執行以下指令：


Ceph 將列出您叢集中的所有使用者。例如，在包含兩個節點的叢集中， ceph auth

list 輸出類似下方所示：

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-mdsclient.bootstrap-osd key: AQBHCbtT4GxqORAADE5u7RkpCN/oo4e5W0uBtw== caps: [mon] allow profile bootstrap-osd

89 管理使用者 SES 6

注意：TYPE.ID 表示法請注意，針對使用者採用 TYPE.ID 表示法，例如， osd.0 指定 osd 類型的使用

者，其 ID 為 0。 client.admin 是 client 類型的使用者，其 ID 為 admin。

另請注意，每個項目都包含一個 key: value 項目，以及一或多個 caps: 項

目。

您可以將 -o filename 選項和 ceph auth list 結合使用，以將輸出儲存到某個

檔案。

8.2.2.2 獲取有關使用者的資訊

若要擷取特定的使用者、金鑰和能力，請執行以下指令：

cephadm@adm > ceph auth get TYPE.ID

例如：

cephadm@adm > ceph auth get client.adminexported keyring for client.admin[client.admin] key = AQA19uZUqIwkHxAAFuUwvq0eJD4S173oFRxe0g== caps mds = "allow" caps mon = "allow *" caps osd = "allow *"

開發人員也可以執行以下指令：

cephadm@adm > ceph auth export TYPE.ID

auth export 指令與 auth get 相同，不過它還會列印內部驗證 ID。

8.2.2.3 新增使用者

新增使用者會建立使用者名稱 ( TYPE.ID )、機密金鑰，以及包含在指令中用於建立該使

用者的所有能力。

使用者可使用其金鑰向 Ceph 儲存叢集進行驗證。使用者的能力授予該使用者在 Ceph

監控程式 (mon)、Ceph OSD (osd) 或 Ceph 中繼資料伺服器 (mds) 上進行讀取、寫入

或執行的能力。


可以使用以下幾個指令來新增使用者：

ceph auth add

此指令是新增使用者的規範方法。它會建立使用者、產生金鑰，並新增所有指定

的能力。

ceph auth get-or-create

此指令往往是建立使用者的最便捷方法，因為它會傳回包含使用者名稱 (在方括

號中) 和金鑰的金鑰檔案格式。如果該使用者已存在，此指令只以金鑰檔案格式

傳回使用者名稱和金鑰。您可以使用 -o filename 選項將輸出儲存到某個檔案。

ceph auth get-or-create-key

此指令是建立使用者並僅傳回使用者金鑰的便捷方式。對於只需要金鑰的用戶端

(例如 libvirt )，此指令非常實用。如果該使用者已存在，此指令只傳回金鑰。

您可以使用 -o filename 選項將輸出儲存到某個檔案。

建立用戶端使用者時，您可以建立不具有能力的使用者。不具有能力的使用者可以進行

驗證，但不能執行其他操作。此類用戶端無法從監控程式擷取叢集地圖。但是，如果您

希望稍後再新增能力，可以使用 ceph auth caps 指令建立一個不具有能力的使用者。

一般的使用者至少對 Ceph 監控程式具有讀取能力，並對 Ceph OSD 具有讀取和寫入能

力。此外，使用者的 OSD 權限通常限制為只能存取特定的池。

cephadm@adm > ceph auth add client.john mon 'allow r' osd \ 'allow rw pool=liverpool'cephadm@adm > ceph auth get-or-create client.paul mon 'allow r' osd \ 'allow rw pool=liverpool'cephadm@adm > ceph auth get-or-create client.george mon 'allow r' osd \ 'allow rw pool=liverpool' -o george.keyringcephadm@adm > ceph auth get-or-create-key client.ringo mon 'allow r' osd \ 'allow rw pool=liverpool' -o ringo.key

重要如果您為某個使用者提供了對 OSD 的能力，但未限制只能存取特定池，則該使

用者將有權存取叢集中的所有池。


8.2.2.4 修改使用者能力

使用 ceph auth caps 指令可以指定使用者以及變更該使用者的能力。設定新能力會覆

寫目前的能力。若要檢視目前的能力，請執行 ceph auth get USERTYPE.USERID。若要

新增能力，使用以下格式時還需要指定現有能力：

cephadm@adm > 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]']

例如：

cephadm@adm > ceph auth get client.johncephadm@adm > ceph auth caps client.john mon 'allow r' osd 'allow rw pool=prague'cephadm@adm > ceph auth caps client.paul mon 'allow rw' osd 'allow r pool=prague'cephadm@adm > ceph auth caps client.brian-manager mon 'allow *' osd 'allow *'

若要移除某個能力，可重設該能力。如果希望使用者無權存取以前設定的特定精靈，請

指定一個空白字串：

cephadm@adm > ceph auth caps client.ringo mon ' ' osd ' '

8.2.2.5 刪除使用者

若要刪除使用者，請使用 ceph auth del：

cephadm@adm > ceph auth del TYPE.ID

其中， TYPE 是 client、 osd、 mon 或 mds 之一， ID 是使用者名稱或精靈的 ID。

如果您建立了僅對不再存在的池具有權限的使用者，則應該考慮也刪除那些使用者。

8.2.2.6 列印使用者的金鑰

若要將使用者的驗證金鑰列印到標準輸出，請執行以下指令：

cephadm@adm > ceph auth print-key TYPE.ID

其中， TYPE 是 client、 osd、 mon 或 mds 之一， ID 是使用者名稱或精靈的 ID。

當您需要在用戶端軟體 (例如 libvirt ) 中填入某個使用者的金鑰時，列印使用者的金

鑰非常實用，如以下範例所示：

root # mount -t ceph host:/ mount_point \-o name=client.user,secret=`ceph auth print-key client.user`


8.2.2.7 輸入使用者

若要輸入一或多個使用者，請使用 ceph auth import 並指定金鑰圈：

cephadm@adm > ceph auth import -i /etc/ceph/ceph.keyring

注意Ceph 儲存叢集將新增新使用者及其金鑰和能力，並更新現有使用者及其金鑰和

能力。

8.2.3 金鑰圈管理

當您透過 Ceph 用戶端存取 Ceph 時，該用戶端會尋找本地金鑰圈。依預設，Ceph 會

使用以下四個金鑰圈名稱預先指定金鑰圈設定，因此，除非您要覆寫預設值，否則無需

在 Ceph 組態檔案中設定這些名稱：

/etc/ceph/cluster.name.keyring/etc/ceph/cluster.keyring/etc/ceph/keyring/etc/ceph/keyring.bin

cluster 元變數是依 Ceph 組態檔案名稱定義的 Ceph 叢集名稱。 ceph.conf 表示叢集

名稱為 ceph，因此金鑰圈名稱為 ceph.keyring。 name 元變數是使用者類型和使用者

ID (例如 client.admin )，因此金鑰圈名稱為 ceph.client.admin.keyring。

建立使用者 (例如 client.ringo ) 之後，必須獲取金鑰並將其新增至 Ceph 用戶端上

的金鑰圈，以使該使用者能夠存取 Ceph 儲存叢集。

第 8.2 節「金鑰管理」詳細介紹了如何直接在 Ceph 儲存叢集中列出、獲取、新增、

修改和刪除使用者。不過，Ceph 還提供了 ceph-authtool 公用程式，可讓您從 Ceph

用戶端管理金鑰圈。

8.2.3.1 建立金鑰圈

當您依照第 8.2 節「金鑰管理」中的程序建立使用者時，需要向 Ceph 用戶端提供使

用者金鑰，以使用戶端能擷取指定使用者的金鑰，並向 Ceph 儲存叢集驗證身分。Ceph

用戶端將存取金鑰圈，以查閱使用者名稱並擷取使用者的金鑰：

93 金鑰圈管理 SES 6

cephadm@adm > ceph-authtool --create-keyring /path/to/keyring

建立包含多個使用者的金鑰圈時，我們建議使用叢集名稱 (例如 cluster .keyring) 做

為金鑰圈檔案名稱，並將其儲存在 /etc/ceph 目錄中，如此，您無需在 Ceph 組態檔

案的本地副本中指定檔案名稱，金鑰圈組態預設設定就會選取正確的檔案名稱。例如，

可執行以下指令來建立 ceph.keyring：

cephadm@adm > ceph-authtool -C /etc/ceph/ceph.keyring

建立包含單個使用者的金鑰圈時，我們建議使用叢集名稱、使用者類型和使用者

名稱，並將其儲存在 /etc/ceph 目錄中。例如，為 client.admin 使用者建立

ceph.client.admin.keyring。

8.2.3.2 將使用者新增至金鑰圈

將某個使用者新增至 Ceph 儲存叢集時 (請參閱第 8.2.2.3 節「新增使用者」)，您

可以擷取該使用者、金鑰和能力，並將該使用者儲存到金鑰圈。

如果您只想對每個金鑰圈使用一個使用者，可以將 -o 選項與 ceph auth get 指令結

合使用，以金鑰圈檔案格式儲存輸出。例如，若要為 client.admin 使用者建立金鑰

圈，請執行以下指令：

cephadm@adm > ceph auth get client.admin -o /etc/ceph/ceph.client.admin.keyring

若要將使用者輸入到金鑰圈，可以使用 ceph-authtool 來指定目的地金鑰圈和來源金

鑰圈：

cephadm@adm > ceph-authtool /etc/ceph/ceph.keyring \ --import-keyring /etc/ceph/ceph.client.admin.keyring

8.2.3.3 建立使用者

Ceph 提供 ceph auth add 指令用於直接在 Ceph 儲存叢集中建立使用者。不過，您也

可以直接在 Ceph 用戶端金鑰圈中建立使用者、金鑰和能力。然後，可將使用者輸入到

Ceph 儲存叢集：

cephadm@adm > ceph-authtool -n client.ringo --cap osd 'allow rwx' \ --cap mon 'allow rwx' /etc/ceph/ceph.keyring

94 金鑰圈管理 SES 6

您也可以在建立金鑰圈的同時將新使用者新增至該金鑰圈：

cephadm@adm > ceph-authtool -C /etc/ceph/ceph.keyring -n client.ringo \ --cap osd 'allow rwx' --cap mon 'allow rwx' --gen-key

在前面的方案中，新使用者 client.ringo 僅存放在金鑰圈中。若要將該新使用者新增

至 Ceph 儲存叢集，您仍必須手動新增：

cephadm@adm > ceph auth add client.ringo -i /etc/ceph/ceph.keyring

8.2.3.4 修改使用者

若要修改金鑰圈中某條使用者記錄的能力，請指定該金鑰圈和使用者，然後指定能力：

cephadm@adm > ceph-authtool /etc/ceph/ceph.keyring -n client.ringo \ --cap osd 'allow rwx' --cap mon 'allow rwx'

若要在 Ceph 叢集環境中更新已修改的使用者，必須將金鑰圈中的變更輸入到 Ceph 叢

集中的使用者項目：

cephadm@adm > ceph auth import -i /etc/ceph/ceph.keyring

請參閱第 8.2.2.7 節「輸入使用者」，瞭解有關根據金鑰圈更新 Ceph 儲存叢集使用

者的詳細資料。

8.2.4 指令行用法

ceph 指令支援以下與使用者名稱和機密操作相關的選項：

--id 或 --user

Ceph 使用類型和 ID ( TYPE . ID，例如 client.admin 或 client.user1 ) 來識

別使用者。使用 id、 name 和 -n 選項可以指定使用者名稱的 ID 部分 (例如

admin 或 user1 )。您可以使用 --id 指定使用者，並省略類型。例如，若要指定

使用者 client.foo，請輸入以下指令：

cephadm@adm > ceph --id foo --keyring /path/to/keyring healthcephadm@adm > ceph --user foo --keyring /path/to/keyring health

--name 或 -n

95 指令行用法 SES 6

Ceph 使用類型和 ID ( TYPE . ID，例如 client.admin 或 client.user1 ) 來識別

使用者。使用 --name 和 -n 選項可以指定完整的使用者名稱。您必須指定使用

者類型 (一般為 client ) 和使用者 ID：

cephadm@adm > ceph --name client.foo --keyring /path/to/keyring healthcephadm@adm > ceph -n client.foo --keyring /path/to/keyring health

--keyring

包含一或多個使用者名稱和機密的金鑰圈路徑。 --secret 選項提供相同的功能，

但它不適用於物件閘道，該閘道將 --secret 用於其他目的。您可以使用 ceph

auth get-or-create 來擷取金鑰圈並將其儲存在本地。這是慣用的方法，因為您

無需切換金鑰圈路徑就能切換使用者名稱：

cephadm@adm > rbd map --id foo --keyring /path/to/keyring mypool/myimage

96 指令行用法 SES 6

9 儲存的資料管理

CRUSH 演算法透過運算資料儲存位置來確定如何儲存和擷取資料。利用 CRUSH，Ceph

用戶端無需透過集中式伺服器或仲介，即可直接與 OSD 通訊。借助演算法確定的資料

儲存和擷取方法，Ceph 可避免單一故障點、效能瓶頸和延展性實體限制。

CRUSH 需要獲取叢集的地圖，它使用 CRUSH 地圖以虛擬隨機方式在 OSD 中儲存和擷取

資料，並以一致的方式在整個叢集中分發資料。

CRUSH 地圖包含一個 OSD 清單、一個用於將裝置聚合到實體位置的「桶」清單，以及

一個指示 CRUSH 應如何在 Ceph 叢集的池中複製資料的規則清單。透過反映安裝的基

礎實體組織，CRUSH 可對相關裝置故障的潛在根源塑模，從而解決故障的根源。一般的

根源包括實體距離、共用電源和共用網路。透過將這些資訊編碼到叢集地圖中，CRUSH

放置規則可將物件複本分隔在不同的故障網域中，同時維持所需的分發方式。例如，為

了消除可能的並行故障，可能需要確定資料複本位於使用不同機架、機櫃、電源、控制

器和/或實體位置的裝置上。

部署 Ceph 叢集後，將會產生預設的 CRUSH 地圖。這種模式適合 Ceph 沙箱環境。但

是，在部署大規模的資料叢集時，強烈建議您考慮建立自訂 CRUSH 地圖，因為這樣做

有助於管理 Ceph 叢集、提高效能並確保資料安全。

例如，如果某個 OSD 停機，而您需要使用現場支援或更換硬體，則 CRUSH 地圖可協助

您定位到發生 OSD 故障的主機所在的實體資料中心、機房、裝置排和機櫃。

同樣，CRUSH 可以協助您更快地確定故障。例如，如果特定機櫃中的所有 OSD 同時停

機，故障可能是由某個網路交換器或者機櫃或網路交換器的電源所致，而不是發生在

OSD 自身上。

當與故障主機關聯的放置群組 (請參閱第 9.4 節「置放群組」) 處於降級狀態時，自

訂 CRUSH 地圖還可協助您確定 Ceph 儲存資料備援副本的實體位置。

CRUSH 地圖包括三個主要部分。

裝置包括與 ceph-osd 精靈對應的任何物件儲存裝置。

桶由儲存位置 (例如裝置排、機櫃、主機等) 及為其指定的權數的階層聚合組

成。

規則集由桶選取方式組成。

97 SES 6

9.1 裝置

為了將放置群組對應到 OSD，CRUSH 地圖需要 OSD 裝置 (OSD 精靈的名稱) 的清單。

裝置清單顯示在 CRUSH 地圖的最前面。

#devicesdevice NUM osd.OSD_NAME class CLASS_NAME

例如：

#devicesdevice 0 osd.0 class hdddevice 1 osd.1 class ssddevice 2 osd.2 class nvmedevice 3 osd.3class ssd

一般而言，一個 OSD 精靈對應到一個磁碟。

9.1.1 裝置類別

Ceph 的優勢之一是 CRUSH 地圖能夠靈活控制資料的放置。這也是叢集最難管理的環節

之一。裝置類別可自動對 CRUSH 地圖進行最常見的變更，而這些在以前都必須由管理

員手動進行。

9.1.1.1 CRUSH 管理問題

Ceph 叢集常由多種類型的儲存裝置建構而成：HDD、SSD、NVMe，甚至是以上這些類別

的混合。我們將這些不同的儲存裝置類型稱為裝置類別，以避免與 CRUSH 桶的類型內

容 (例如 host、rack 和 row，請參閱第 9.2 節「桶」以瞭解更多詳細資料) 產生混

淆。受 SSD 支援的 Ceph OSD 比受旋轉式磁碟支援的 OSD 速度快得多，因此更適合特

定工作負載。利用 Ceph，您可輕鬆為不同資料集或工作負載建立 RADOS 池，以及指定

不同的 CRUSH 規則來控制這些池的資料放置。

98 裝置 SES 6

圖形 9.1︰使用混合裝置類別的 OSD

不過，透過設定 CRUSH 規則將資料僅放置到特定類別的裝置這個過程十分枯燥。規則

是針對 CRUSH 階層運作的，但如果將某些裝置混合到同一主機或機架中 (如上面的範

例階層所示)，則這些裝置預設會混合在一起並顯示在階層的同一子樹狀結構中。若要

手動將它們分隔到單獨的樹狀結構中，需要針對先前版本的 SUSE Enterprise Storage

中的每個裝置類別，為每個中間節點建立多個版本。

9.1.1.2 裝置類別

Ceph 提供了一個較佳的解決方案，就是新增一個名為裝置類別的內容至每個 OSD。

依預設，OSD 會依據 Linux 核心所公開的硬體內容，自動將自己的裝置類別設定為

「hdd」、「ssd」或「nvme」。 ceph osd tree 指令輸出的新欄中會報告這些裝置類

別：

cephadm@adm > ceph osd tree ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF -1 83.17899 root default -4 23.86200 host cpach 2 hdd 1.81898 osd.2 up 1.00000 1.00000 3 hdd 1.81898 osd.3 up 1.00000 1.00000 4 hdd 1.81898 osd.4 up 1.00000 1.00000 5 hdd 1.81898 osd.5 up 1.00000 1.00000 6 hdd 1.81898 osd.6 up 1.00000 1.00000 7 hdd 1.81898 osd.7 up 1.00000 1.00000 8 hdd 1.81898 osd.8 up 1.00000 1.00000 15 hdd 1.81898 osd.15 up 1.00000 1.00000 10 nvme 0.93100 osd.10 up 1.00000 1.00000 0 ssd 0.93100 osd.0 up 1.00000 1.00000 9 ssd 0.93100 osd.9 up 1.00000 1.00000

99 裝置類別 SES 6

如果裝置類別自動偵測失敗 (例如由於未透過 /sys/block 正確向裝置驅動程式公開裝

置的相關資訊而導致失敗)，您可以使用指令行調整裝置類別：

cephadm@adm > ceph osd crush rm-device-class osd.2 osd.3done removing class of osd(s): 2,3cephadm@adm > ceph osd crush set-device-class ssd osd.2 osd.3set osd(s) 2,3 to class 'ssd'

9.1.1.3 CRUSH 放置規則

CRUSH 規則可限制對特定裝置類別執行放置操作。例如，您可以透過執行以下指令來建

立僅將資料分佈在 SSD 磁碟上的「fast」複本池：

cephadm@adm > ceph osd crush rule create-replicated RULE_NAME ROOT FAILURE_DOMAIN_TYPE DEVICE_CLASS

例如：

cephadm@adm > ceph osd crush rule create-replicated fast default host ssd

建立名為「fast_pool」的池，並將其指定給「fast」規則：

cephadm@adm > ceph osd pool create fast_pool 128 128 replicated fast

建立糾刪碼規則的程序略有不同。首先，建立包含所需裝置類別所對應內容的糾刪碼設

定檔。然後，在建立糾刪碼池時使用該設定檔：

cephadm@adm > ceph osd erasure-code-profile set myprofile \ k=4 m=2 crush-device-class=ssd crush-failure-domain=hostcephadm@adm > ceph osd pool create mypool 64 erasure myprofile

為應對您需要手動編輯 CRUSH 地圖來自訂規則的情況，已將該語法進行擴充，以便允

許指定裝置類別。例如，上述指令產生的 CRUSH 規則如下所示：

rule ecpool { id 2 type erasure min_size 3 max_size 6 step set_chooseleaf_tries 5 step set_choose_tries 100 step take default class ssd step chooseleaf indep 0 type host step emit}


此處的重要差異是，「take」指令包含額外的「class CLASS_NAME」尾碼。

9.1.1.4 其他指令

若要列出 CRUSH 地圖中使用的裝置類別，請執行以下指令：

cephadm@adm > ceph osd crush class ls[ "hdd", "ssd"]

若要列出現有的 CRUSH 規則，請執行以下指令：

cephadm@adm > ceph osd crush rule lsreplicated_rulefast

若要檢視名為「fast」的 CRUSH 規則的詳細資料，請執行以下指令：

cephadm@adm > ceph osd crush rule dump fast{ "rule_id": 1, "rule_name": "fast", "ruleset": 1, "type": 1, "min_size": 1, "max_size": 10, "steps": [ { "op": "take", "item": -21, "item_name": "default~ssd" }, { "op": "chooseleaf_firstn", "num": 0, "type": "host" }, { "op": "emit" } ]}

若要列出屬於「ssd」類別的 OSD，請執行以下指令：

cephadm@adm > ceph osd crush class ls-osd ssd0


1

9.1.1.5 從舊版 SSD 規則移轉至裝置類別

在早於版本 5 的 SUSE Enterprise Storage 中，若要寫入適用於裝置的規則，您需

要手動編輯 CRUSH 地圖，並為每個具體的裝置類型 (例如 SSD) 維護平行的階層。自

SUSE Enterprise Storage 5 起，裝置類別特性透明地實現了這一目的。

您可以使用 crushtool 指令將舊版規則和階層轉換為基於類別的新版規則。系統提供

了以下幾種轉換類型：

crushtool --reclassify-root ROOT_NAME DEVICE_CLASS

此指令會獲取 ROOT_NAME 下的階層中的所有內容，並將透過

take ROOT_NAME

參考該根的所有規則都調整為

take ROOT_NAME class DEVICE_CLASS

它會對桶重新編號，以便為指定類別的「shadow tree」使用舊 ID。因此不會移

動資料。

範例 9.1︰ crushtool --reclassify-root

假設存在以下現有規則：

rule replicated_ruleset { id 0 type replicated min_size 1 max_size 10 step take default step chooseleaf firstn 0 type rack step emit}

如果您將根「default」重新分類為「hdd」類別，規則將變為

rule replicated_ruleset { id 0 type replicated min_size 1 max_size 10 step take default class hdd step chooseleaf firstn 0 type rack step emit


}

crushtool --set-subtree-class BUCKET_NAME DEVICE_CLASS

此方法會將根目錄為 BUCKET_NAME 的子樹狀結構中的每部裝置標示為指定的裝置

類別。

--set-subtree-class 通常與 --reclassify-root 選項結合使用，以確定該根

中的所有裝置均標為正確的類別。不過，其中一些裝置可能特意使用了不同的

類別，因此您不需要重新對它們進行標記。在此類情況下，請勿使用 --set-

subtree-class 選項。請記住，這樣的重新對應並不完美，因為之前的規則是跨多

個類別的裝置配送的，而調整後的規則將僅對應至指定裝置類別的裝置。

crushtool --reclassify-bucket MATCH_PATTERN DEVICE_CLASS DEFAULT_PATTERN

此方法允許將類型特定的平行階層與一般階層合併。例如，許多使用者會具有類

似如下的 CRUSH 地圖：

範例 9.2︰ crushtool --reclassify-bucket

host node1 { id -2 # do not change unnecessarily # weight 109.152 alg straw hash 0 # rjenkins1 item osd.0 weight 9.096 item osd.1 weight 9.096 item osd.2 weight 9.096 item osd.3 weight 9.096 item osd.4 weight 9.096 item osd.5 weight 9.096 [...]}

host node1-ssd { id -10 # do not change unnecessarily # weight 2.000 alg straw hash 0 # rjenkins1 item osd.80 weight 2.000 [...]}

root default { id -1 # do not change unnecessarily alg straw hash 0 # rjenkins1 item node1 weight 110.967 [...]}


root ssd { id -18 # do not change unnecessarily # weight 16.000 alg straw hash 0 # rjenkins1 item node1-ssd weight 2.000 [...]}

此函數會將與給定模式相符的每個桶重新分類。模式的格式可能為 %尾碼或字

首%。在上面的範例中，您需要使用 %-ssd 模式。對於每個相符的桶，與「%」

萬用字元相符的名稱的其餘部分指定了基本桶。相符桶中的所有裝置都標示為指

定的裝置類別，隨後會移至基本桶中。如果基本桶不存在 (例如，如果「node12-

ssd」存在，但「node12」不存在)，則系統會建立基本桶，並將其關聯到指定的

預設父桶下。系統會為新的陰影桶保留舊桶 ID，以防資料移動。系統會對包含參

考舊桶的 take 步驟的規則進行調整。

crushtool --reclassify-bucket BUCKET_NAME DEVICE_CLASS BASE_BUCKET

您可以使用不包含萬用字元的 --reclassify-bucket 選項來對應單個桶。例如，

在上面的範例中，我們希望將「ssd」桶對應至預設桶。

用於轉換由上述片段組成的地圖的最後一個指令將如下所示：

cephadm@adm > ceph osd getcrushmap -o originalcephadm@adm > crushtool -i original --reclassify \ --set-subtree-class default hdd \ --reclassify-root default hdd \ --reclassify-bucket %-ssd ssd default \ --reclassify-bucket ssd ssd default \ -o adjusted

若要確認轉換是否正確，可以使用 --compare 選項。該選項會測試大量對 CRUSH

地圖的輸入，並比較是否會產生相同的結果。透過適用於 --test 的相同選項來

控制這些輸入。對於上面的範例，指令將如下所示：

cephadm@adm > crushtool -i original --compare adjustedrule 0 had 0/10240 mismatched mappings (0)rule 1 had 0/10240 mismatched mappings (0)maps appear equivalent

提示如果存在差異，括號中將會顯示重新對應的輸入比率。


如果您對調整後的 CRUSH 地圖滿意，便可將其套用於叢集：

cephadm@adm > ceph osd setcrushmap -i adjusted

9.1.1.6 更多資訊

如需 CRUSH 地圖的更多詳細資料，請參閱第 9.5 節「CRUSH 地圖操作」。

如需 Ceph 池的更多一般詳細資料，請參閱第 11 章「管理儲存池」

如需糾刪碼池的更多詳細資料，請參閱第 13 章「糾刪碼池」。

9.2 桶

CRUSH 地圖包含 OSD 的清單，可將這些 OSD 組織成「桶」，以便將裝置聚合到實體位

置。

0 osd OSD 精靈 (osd.1、osd.2 等)。

1 host 包含一或多個 OSD 的主機名稱。

2 chassis 組成機櫃的機箱。

3 rack 電腦機櫃。預設值為 unknownrack。

4 row 由一系列機櫃組成的裝置排。

5 pdu 電源分配單位。

6 pod

7 room 包含主機機櫃和主機排的機房。

8 datacenter 包含機房的實體資料中心。

9 region

10 root

105 桶 SES 6

提示您可以修改現有類型，以及建立自己的桶類型。

Ceph 的部署工具可產生 CRUSH 地圖，其中包含每個主機的桶，以及名為「default」

的根 (可用於預設的 rbd 池)。剩餘的桶類型提供了一種儲存有關節點/桶的實體位置

資訊的方法，當 OSD、主機或網路硬體無法正常運作，並且管理員需要存取實體硬體

時，這種方法可顯著簡化叢集管理工作。

桶具有類型、唯一的名稱 (字串)、以負整數表示的唯一的 ID、相對於其項目總容量/

功能的權數、桶演算法 (預設為 straw2 )，以及雜湊 (預設為 0，代表 CRUSH 雜湊

rjenkins1 )。一個桶可以包含一或多個項目。項目可由其他桶或 OSD 組成。項目可能

會有一個權數來反映該項目的相對權數。

[bucket-type] [bucket-name] { id [a unique negative numeric ID] weight [the relative capacity/capability of the item(s)] alg [the bucket type: uniform | list | tree | straw2 | straw ] hash [the hash type: 0 by default] item [item-name] weight [weight]}

下面的範例說明如何使用桶來聚合池，以及諸如資料中心、機房、機櫃和裝置排的實體

位置。

host ceph-osd-server-1 { id -17 alg straw2 hash 0 item osd.0 weight 0.546 item osd.1 weight 0.546}

row rack-1-row-1 { id -16 alg straw2 hash 0 item ceph-osd-server-1 weight 2.00}

rack rack-3 { id -15 alg straw2 hash 0 item rack-3-row-1 weight 2.00 item rack-3-row-2 weight 2.00 item rack-3-row-3 weight 2.00

106 桶 SES 6

item rack-3-row-4 weight 2.00 item rack-3-row-5 weight 2.00}

rack rack-2 { id -14 alg straw2 hash 0 item rack-2-row-1 weight 2.00 item rack-2-row-2 weight 2.00 item rack-2-row-3 weight 2.00 item rack-2-row-4 weight 2.00 item rack-2-row-5 weight 2.00}

rack rack-1 { id -13 alg straw2 hash 0 item rack-1-row-1 weight 2.00 item rack-1-row-2 weight 2.00 item rack-1-row-3 weight 2.00 item rack-1-row-4 weight 2.00 item rack-1-row-5 weight 2.00}

room server-room-1 { id -12 alg straw2 hash 0 item rack-1 weight 10.00 item rack-2 weight 10.00 item rack-3 weight 10.00}

datacenter dc-1 { id -11 alg straw2 hash 0 item server-room-1 weight 30.00 item server-room-2 weight 30.00}

root data { id -10 alg straw2 hash 0 item dc-1 weight 60.00 item dc-2 weight 60.00}

107 桶 SES 6

9.3 規則集

CRUSH 地圖支援「CRUSH 規則」概念，這些規則確定池的資料放置。對於大型叢集，

您可能會建立許多池，其中每個池各自可能具有自己的 CRUSH 規則集和規則。預設

CRUSH 地圖具有適用於預設根的規則。如果您想使用更多根和更多規則，則需稍後自行

建立，或者在建立新池時讓系統自動建立。

注意大多數情況下，您無需修改預設規則。建立新池時，該池的預設規則集為 0。

規則採用以下格式：

rule rulename {

ruleset ruleset type type min_size min-size max_size max-size step step

}

ruleset

一個整數。將規則分類，使其屬於一個規則集。透過在池中設定規則集來啟用。

必須指定此選項。預設值為 0。

type

一個字串。描述了適用於「複本」或「糾刪碼」池的規則。必須指定此選項。預

設值為 replicated。

min_size

一個整數。如果池群組建立的複本數小於此數字，CRUSH 將不選取此規則。必須

指定此選項。預設值為 2。

max_size

一個整數。如果池群組建立的複本數大於此數字，CRUSH 將不選取此規則。必須

指定此選項。預設值為 10。

step take bucket

108 規則集 SES 6

採用以名稱指定的桶，並開始在樹狀結構中向下逐一查看。必須指定此選項。如

需在樹中逐一查看的說明，請參閱第 9.3.1 節「在節點樹中逐一查看」。

step target mode num type bucket-type

target 可以是 choose 或 chooseleaf。如果設定為 choose，則會選取許多

桶。 chooseleaf 直接從桶集的每個桶的子樹中選取 OSD (葉節點)。

mode 可以是 firstn 或 indep。請參閱第 9.3.2 節「firstn 和 indep」。

選取給定類型的桶的數量。其中，N 是可用選項的數量，如果 num > 0 且 < N，

則選擇該數量的桶；如果 num < 0，則表示 N - 數量；如果 num = 0，則選擇 N

個桶 (全部可用)。跟在 step take 或 step choose 後使用。

step emit

輸出目前的值並清空堆疊。一般在規則的結尾使用，但也可在同一規則中用來構

成不同的樹。跟在 step choose 後使用。

9.3.1 在節點樹中逐一查看

可採用節點樹的形式來檢視使用桶定義的結構。在此樹中，桶是節點，OSD 是葉。

CRUSH 地圖中的規則定義如何從此樹中選取 OSD。規則從某個節點開始，然後在樹中向

下逐一查看，以傳回一組 OSD。無法定義需要選取哪個分支。CRUSH 演算法可保證 OSD

集能夠符合複製要求並均衡分發資料。

使用 step take bucket 時，在節點樹中從給定的桶 (而不是桶類型) 開始逐一查

看。如果要傳回樹中所有分支上的 OSD，該桶必須是根桶。否則，以下步驟只會在子樹

中逐一查看。

完成 step take 後，接下來會執行規則定義中的一或多個 step choose 項目。每個

step choose 會從前面選定的上層節點中選擇指定數量的節點 (或分支)。

最後，使用 step emit 傳回選定的 OSD。

step chooseleaf 是一個便捷函數，可直接從給定桶的分支中選取 OSD。

圖形 9.2 「範例樹」中提供了展示如何使用 step 在樹中逐一查看的範例。在下面的

規則定義中，橙色箭頭和數字與 example1a 和 example1b 對應，藍色箭頭和數字與

example2 對應。

109 在節點樹中逐一查看 SES 6

圖形 9.2︰範例樹

# orange arrowsrule example1a { ruleset 0 type replicated min_size 2 max_size 10 # orange (1) step take rack1 # orange (2) step choose firstn 0 host # orange (3) step choose firstn 1 osd step emit}

rule example1b { ruleset 0 type replicated min_size 2 max_size 10 # orange (1) step take rack1 # orange (2) + (3) step chooseleaf firstn 0 host step emit}

# blue arrowsrule example2 { ruleset 0

110 在節點樹中逐一查看 SES 6

type replicated min_size 2 max_size 10 # blue (1) step take room1 # blue (2) step chooseleaf firstn 0 rack step emit}

9.3.2 firstn 和 indep

CRUSH 規則定義有故障節點或 OSD 的取代項 (請參閱第 9.3 節「規則集」)。關鍵字

step 要求使用 firstn 或 indep 參數。圖形 9.3 「節點取代方法」提供了範例。

firstn 將取代節點新增至使用中節點清單的結尾。如果某個節點發生故障，其後的正

常節點會移位到左側，以填滿有故障節點留下的空缺。這是副本池的預設方法，也是需

要採取的方法，因為次要節點已包含所有資料，因此可立即接管主要節點的職責。

indep 為每個使用中節點選取固定的取代節點。取代有故障節點不會變更剩餘節點的

順序。這對於糾刪碼池而言是所需的行為。在糾刪碼池中，節點上儲存的資料取決於在

選取節點時它所在的位置。如果節點的順序發生變化，受影響節點上的所有資料都需要

重新放置。

圖形 9.3︰節點取代方法

111 firstn 和 indep SES 6

9.4 置放群組

Ceph 會將物件對應至放置群組 (PG)。放置群組是指邏輯物件池的分區或片段，可將物

件以群組形式放置到 OSD 中。放置群組可減少 Ceph 將資料儲存到 OSD 中時每個物件

的中繼資料數量。如果放置群組的數量較多 (例如，每個 OSD 有 100 個放置群組)，

將可實現較佳的平衡。

9.4.1 放置群組的使用方式

放置群組 (PG) 聚合了池內的物件。主要原因是基於每個物件來追蹤物件放置和中繼資

料的計算成本較高。例如，包含數百萬個物件的系統無法直接追蹤各個物件的放置。

圖形 9.4︰池中的放置群組

Ceph 用戶端負責計算物件將屬於哪個放置群組。它會對物件 ID 進行雜湊處理，並依

據所定義池中的 PG 數及池的 ID 來套用操作。

系統會在一組 OSD 中儲存放置群組內的物件內容。例如，在大小為 2 的複本池中，每

個放置群組將物件儲存到兩個 OSD 中：

112 置放群組 SES 6

圖形 9.5︰放置群組和 OSD

如果 OSD 2 發生故障，則系統會將另一個 OSD 指定給放置群組 1，並在該 OSD 中填

入 OSD 1 內所有物件的複本。如果池大小從 2 變為 3，則系統會向放置群組另外再指

定一個 OSD，並在該 OSD 中填入放置群組內所有物件的複本。

放置群組並不擁有 OSD，它們與同一池甚至其他池內的其他放置群組共用 OSD。如果

OSD 2 發生故障，放置群組 2 也將需要使用 OSD 3 來還原物件的複本。

當放置群組的數量增加時，系統會向新放置群組指定 OSD。CRUSH 函數的結果也會發生

變更，並且系統會將之前的放置群組的部分物件複製到新放置群組，並將它們從舊放置

群組移除。

9.4.2 確定 PG_NUM 的值

建立新池時，必須選擇 PG_NUM 的值：

root # ceph osd pool create POOL_NAME PG_NUM

系統無法自動計算 PG_NUM 的值。以下是一些常用的值，選擇哪個值取決於叢集中的

OSD 數量：

少於 5 個 OSD：

將 PG_NUM 設定為 128。

5 到 10 個 OSD：


10 到 50 個 OSD：


113 確定 PG_NUM 的值 SES 6

隨著 OSD 數量的增加，選擇正確的 PG_NUM 值也變得愈加重要。 PG_NUM 對叢集的行

為以及 OSD 發生故障時的資料持久性具有很大影響。

9.4.2.1 超過 50 個 OSD 時的放置群組數

如果 OSD 數量低於 50，請使用第 9.4.2 節「確定 PG_NUM 的值」中所述的預先選取

的值。如果 OSD 數量超過 50，建議為每個 OSD 使用約 50 到 100 個放置群組，以平

衡資源的使用、資料持久性和資料分佈。對於單個物件池，您可以使用以下公式來計算

基線數量：

total PGs = (OSDs * 100) / POOL_SIZE

其中， POOL_SIZE 是複本的數量 (如果是複本池) 或 ceph osd erasure-code-profile

get 指令所傳回的「k」和「m」之和 (如果是糾刪碼池)。應將結果捨入至最接近的 2

的次方數。對於 CRUSH 演算法，建議進行捨入，以便均衡放置群組之間的物件數。

例如，如果叢集包含 200 個 OSD 和大小為 3 個複本的池，您需要依照如下方式預估

PG 數：

(200 * 100) / 3 = 6667

最接近的 2 的次方數為 8192。

使用多個資料池儲存物件時，您需要確保在每個池的放置群組數與每個 OSD 的放置群

組數之間取得平衡。您需要採用合理的放置群組總數，在不過度佔用系統資源或導致互

聯程序過慢的前提下，確保每個 OSD 的差異保持在合理的較低水平。

例如，如果叢集包含 10 個池，每個池有 512 個放置群組 (位於 10 個 OSD 中)，則

表示共有 5,120 個放置群組分佈於 10 個 OSD 中，即每個 OSD 有 512 個放置群組。

這樣的設定不會使用過多資源。但是，如果建立了 1000 個池，且每個池有 512 個放

置群組，那麼每個 OSD 需要處理約 50,000 個放置群組，這樣完成互聯所需的資源和

時間便會顯著增加。

9.4.3 設定放置群組數量

若要設定池內的放置群組數量，您需要在建立池時指定放置群組數量 (請參

閱第 11.2.2 節「建立池」)。為池設定放置群組後，您可以增加放置群組的數量，但

不能減少其數量。若要增加放置群組的數量，請執行以下指令：

114 設定放置群組數量 SES 6

root # ceph osd pool set POOL_NAME pg_num PG_NUM

增加放置群組數量後，您還需要增加要放置的放置群組數量 ( PGP_NUM )，以便您的

叢集重新達到平衡。 PGP_NUM 是考慮要透過 CRUSH 演算法放置的放置群組數。增加

PG_NUM 會分割放置群組，但在增加 PGP_NUM 之前，資料不會移轉至較新的放置群

組。 PGP_NUM 應等於 PG_NUM。若要增加應放置的放置群組數量，請執行以下指令：

root # ceph osd pool set POOL_NAME pgp_num PGP_NUM

9.4.4 獲取放置群組數量

若要獲取池內的放置群組數量，請執行以下指令：

root # ceph osd pool get POOL_NAME pg_num

9.4.5 獲取叢集的 PG 統計資料

若要獲取叢集內放置群組的統計資料，請執行以下指令：

root # ceph pg dump [--format FORMAT]

有效格式為「plain」(預設值) 和「json」。

9.4.6 獲取卡住的 PG 統計資料

若要獲取所有卡在指定狀態的放置群組的統計資料，請執行以下指令：

root # ceph pg dump_stuck STATE \ [--format FORMAT] [--threshold THRESHOLD]

可能的狀態有：「inactive」(PG 由於在等待擁有最新資料的 OSD 恢復啟用狀態而無

法處理讀取或寫入)、「unclean」(PG 包含未複製所需次數的物件)、「stale」(PG 處

於未知狀態，即代管 PG 的 OSD 未在 mon_osd_report_timeout 選項所指定的時間間隔

內向監控程式叢集報告相關資訊)、「undersized」或「degraded」。

有效格式為「plain」(預設值) 和「json」。

該閾值定義放置群組至少卡住多少秒 (預設為 300 秒) 後，系統會將其包含到傳回的

統計資料中。

115 獲取放置群組數量 SES 6

9.4.7 獲取放置群組地圖

若要獲取特定放置群組的地圖，請執行以下指令：

root # ceph pg map PG_ID

Ceph 將傳回放置群組地圖、放置群組和 OSD 狀態：

root # ceph pg map 1.6cosdmap e13 pg 1.6c (1.6c) -> up [1,0] acting [1,0]

9.4.8 獲取放置群組統計資料

若要擷取特定放置群組的統計資料，請執行以下指令：

root # ceph pg PG_ID query

9.4.9 整理放置群組

若要整理 (第 9.6 節「整理」) 放置群組，請執行以下指令：

root # ceph pg scrub PG_ID

Ceph 會檢查主要節點和複本節點、產生放置群組內所有物件的目錄，並對它們進行比

較，以確定沒有缺少或不符的物件且物件的內容均一致。假設所有複本均相符，最後的

語意整理便可確定所有與快照相關的物件中繼資料均一致。系統透過記錄來報告錯誤。

9.4.10 設定放置群組回填和復原的優先程度

您可能會遇到數個放置群組需要復原和/或回填，而其中一些放置群組儲存的資料比其

他放置群組更為重要的情況。例如，這些 PG 可能儲存著執行中機器所使用的影像資

料，其他 PG 則可能儲存的是由非使用中機器使用的資料或相關度較低的資料。在該情

況下，您可能需要優先復原這些放置群組，以便更早地還原這些放置群組中所儲存資料

的效能和可用性。若要將特定放置群組標示為在回填或復原期間優先處理，請執行以下

指令：

116 獲取放置群組地圖 SES 6

root # ceph pg force-recovery PG_ID1 [PG_ID2 ... ]root # ceph pg force-backfill PG_ID1 [PG_ID2 ... ]

這將導致 Ceph 先對指定放置群組執行復原或回填，然後再處理其他放置群組。這并不

會中斷目前正在進行的回填或復原，而是會使指定的 PG 儘快得到處理。如果您改變了

主意或將錯誤的放置群組設為優先處理，請使用以下指令取消優先程度：

root # ceph pg cancel-force-recovery PG_ID1 [PG_ID2 ... ]root # ceph pg cancel-force-backfill PG_ID1 [PG_ID2 ... ]

cancel-* 指令會移除 PG 的「force」旗標，這樣系統便會依預設順序處理這些 PG。

同樣，這並不會影響目前正在處理的放置群組，只會影響仍排在佇列中的放置群組。完

成放置群組復原或回填後，系統即會自動清除「force」旗標。

9.4.11 還原遺失的物件

如果叢集遺失了一或多個物件，而您已決定放棄搜尋遺失的資料，則需要將未找到的物

件標示為「lost」。

如果在查詢過所有可能的位置後仍未找到這些物件，您可能需要放棄這些遺失的物件。

這可能是由於幾種故障同時發生 (這種情況很少見) 所導致，致使叢集在寫入自身復原

之前便得知寫入已執行。

目前唯一支援的選項為「revert」，該選項會復原到物件的先前版本，或在有新物件時

完全忽略遺失物件。若要將「未找到」的物件標示為「lost」，請執行以下指令：

root # ceph pg PG_ID mark_unfound_lost revert|delete

9.5 CRUSH 地圖操作

本節介紹基本的 CRUSH 地圖操作方法，例如編輯 CRUSH 地圖、變更 CRUSH 地圖參

數，以及新增/移動/移除 OSD。

9.5.1 編輯 CRUSH 地圖

若要編輯現有的 CRUSH 地圖，請執行以下操作：

117 還原遺失的物件 SES 6

1. 獲取 CRUSH 地圖。要獲取叢集的 CRUSH 地圖，請執行以下指令：

cephadm@adm > ceph osd getcrushmap -o compiled-crushmap-filename

Ceph 會將編譯的 CRUSH 地圖輸出 ( -o ) 至您指定名稱的檔案。由於該 CRUSH 地

圖採用編譯格式，您必須先將其反編譯，才能對其進行編輯。

2. 反編譯 CRUSH 地圖。若要反編譯 CRUSH 地圖，請執行以下指令：

cephadm@adm > crushtool -d compiled-crushmap-filename \ -o decompiled-crushmap-filename

Ceph 將對已編譯的 CRUSH 地圖進行反編譯 ( -d )，並將其輸出 ( -o ) 至您指定

名稱的檔案。

3. 至少編輯「裝置」、「桶」和「規則」中的其中一個參數。

4. 編譯 CRUSH 地圖。若要編譯 CRUSH 地圖，請執行以下指令：

cephadm@adm > crushtool -c decompiled-crush-map-filename \ -o compiled-crush-map-filename

Ceph 會將編譯的 CRUSH 地圖儲存至您指定名稱的檔案。

5. 設定 CRUSH 地圖。若要設定叢集的 CRUSH 地圖，請執行以下指令：

cephadm@adm > ceph osd setcrushmap -i compiled-crushmap-filename

Ceph 將輸入您所指定檔案名稱的已編譯 CRUSH 地圖，做為叢集的 CRUSH 地圖。

提示：使用版本設定系統請為輸出並修改過的 CRUSH 地圖檔案使用諸如 git 或 svn 的版本設定系統。

這可以讓可能發生的復原變得簡單。

提示：測試新 CRUSH 地圖請使用 crushtool --test 指令測試調整後的新 CRUSH 地圖，並與套用新 CRUSH

地圖之前的狀態進行比較。以下指令參數十分有用： --show-statistics、 --

show-mappings、 --show-bad-mappings、 --show-utilization、 --show-

utilization-all、 --show-choose-tries

118 編輯 CRUSH 地圖 SES 6

9.5.2 新增/移動 OSD

若要在執行中叢集的 CRUSH 地圖中新增或移動 OSD，請執行以下指令：

cephadm@adm > ceph osd crush set id_or_name weight root=pool-namebucket-type=bucket-name ...

ID

一個整數。OSD 的數字 ID。必須指定此選項。

name

一個字串。OSD 的全名。必須指定此選項。

weight

一個雙精度浮點數。OSD 的 CRUSH 權數。必須指定此選項。

root

一個鍵值組。依預設，CRUSH 階層包含 default 池做為根。必須指定此選項。

bucket-type

多個鍵值組。您可在 CRUSH 階層中指定 OSD 的位置。

下面的範例將 osd.0 新增至階層，或移動先前某個位置的 OSD。

cephadm@adm > ceph osd crush set osd.0 1.0 root=data datacenter=dc1 room=room1 \row=foo rack=bar host=foo-bar-1

9.5.3 ceph osd reweight 與 ceph osd crush reweight 之

間的差異

有兩個相似的指令都可變更 Ceph OSD 的權數。它們的使用情境不同，可能會造成混

淆。

9.5.3.1 ceph osd reweight

使用率：

cephadm@adm > ceph osd reweight OSD_NAME NEW_WEIGHT

119 新增/移動 OSD SES 6

ceph osd reweight 用於對 Ceph OSD 設定覆寫權數。此值介於 0 到 1 之間，會強制

CRUSH 重新放置此磁碟機上將以其他方式儲存的資料。該指令不會變更指定給 OSD 上

方的桶的權數，它是一種在正常 CRUSH 分佈出現問題時的矯正措施。例如，如果您的

其中一個 OSD 處於 90%，而其他 OSD 處於 40%，則您可縮小此權數，以嘗試對其進行

補償。

注意：OSD 權數是暫時的請注意， ceph osd reweight 並非永久設定。將某個 OSD 標示為「out」時，它

的權數將設為 0，一旦將它重新標示為「in」，其權數又會變更為 1。

9.5.3.2 ceph osd crush reweight

使用率：

cephadm@adm > ceph osd crush reweight OSD_NAME NEW_WEIGHT

ceph osd crush reweight 用於設定 OSD 的 CRUSH 權數。此權數可以是任意值 (通常

是以 TB 計的磁碟大小)，用於控制系統嘗試指定給 OSD 的資料量。

9.5.4 移除 OSD

若要從執行中叢集的 CRUSH 地圖中移除 OSD，請執行以下指令：

cephadm@adm > ceph osd crush remove OSD_NAME

9.5.5 新增桶

若要新增桶至執行中叢集的 CRUSH 地圖，請執行 ceph osd crush add-bucket 指令：

cephadm@adm > ceph osd crush add-bucket BUCKET_NAME BUCKET_TYPE

9.5.6 移動桶

若要將某個桶移至 CRUSH 地圖階層中的不同位置，請執行以下指令：

120 移除 OSD SES 6

cephadm@adm > ceph osd crush move BUCKET_NAME BUCKET_TYPE=BUCKET_NAME [...]

例如：

cephadm@adm > ceph osd crush move bucket1 datacenter=dc1 room=room1 row=foo rack=bar host=foo-bar-1

9.5.7 移除桶

若要從 CRUSH 地圖階層中移除某個桶，請執行以下指令：

cephadm@adm > ceph osd crush remove BUCKET_NAME

注意：僅限空的桶從 CRUSH 階層中只能移除空的桶。

9.6 整理

除了為物件建立多個複本外，Ceph 還可透過整理放置群組來確保資料完整性 (請參

閱《部署指南》, 第 1 章「SUSE Enterprise Storage 6 和 Ceph」, 第 1.3.2 節

「放置群組」以瞭解有關放置群組的詳細資訊)。Ceph 的整理類似於在物件儲存層上執

行 fsck。對於每個放置群組，Ceph 都會產生一個包含所有物件的目錄，並比較每個

主要物件及其複本，以確定不會有遺失或不相符的物件。每天的淺層整理會檢查物件大

小和屬性，而每週的深層整理則會讀取資料，並使用檢查總數來確保資料完整性。

整理對於維護資料完整性非常重要，但該操作可能會降低效能。您可以透過調整以下設

定來增加或減少整理操作：

osd max scrubs

同時針對一個 Ceph OSD 執行的整理操作數量上限。預設值為 1。

osd scrub begin hour、 osd scrub end hour

依小時定義的一天內可以執行整理的時間段 (0 到 24)。預設開始時間為 0，結

束時間為 24。

121 移除桶 SES 6

重要如果放置群組的整理間隔超出 osd scrub max interval 設定的值，則無論

您定義的整理時間範圍為何，都將執行整理。

osd scrub during recovery

允許復原期間執行整理。若將此選項設定為「false」，則當有復原程序處於使用

中狀態時，將禁止排程新的整理。已在執行的整理將繼續執行。此選項有助於降

低忙碌叢集上的負載。預設值為「true」。

osd scrub thread timeout

整理線串逾時前的最長時間 (以秒計)。預設值為 60。

osd scrub finalize thread timeout

整理完成線串逾時前的最長時間 (以秒計)。預設值為 60*10。

osd scrub load threshold

正常化的最大負載。當系統負載 (由 getloadavg () 與 online cpus 數量之比定

義) 高於此數字時，Ceph 將不會執行整理。預設值為 0.5。

osd scrub min interval

當 Ceph 叢集負載較低時，整理 Ceph OSD 的最短間隔 (以秒計)。預設值為

60*60*24 (一天一次)。

osd scrub max interval

無論叢集負載如何都整理 Ceph OSD 的最長間隔 (以秒計)。預設值為

7*60*60*24 (一週一次)。

osd scrub chunk min

單次操作期間要整理的物件儲存區塊數量下限。整理期間，Ceph 會阻止向單個區

塊寫入資料。預設值為 5。

osd scrub chunk max

單次操作期間要整理的物件儲存區塊數量上限。預設值為 25。

osd scrub sleep

整理下一組區塊之前睡眠的時間。增大此值會降低整個整理操作的速度，但對用

戶端操作的影響較小。預設值為 0。

122 整理 SES 6

osd deep scrub interval

深層整理 (完整讀取所有資料) 的間隔。 osd scrub load threshold 選項不會影

響此設定。預設值為 60*60*24*7 (一週一次)。

osd scrub interval randomize ratio

在排程放置群組的下一次整理工作時，為 osd scrub min interval 值新增一個

隨機延遲。該延遲為一個隨機的值，小於 osd scrub min interval * osd scrub

interval randomized ratio 所得結果。因此，該預設設定實際上是將整理隨機地

排程在允許的時間範圍 [1, 1.5] * osd scrub min interval 內執行。預設值為

0.5。

osd deep scrub stride

執行深層整理時讀取的大小。預設值為 524288 (512 kB)。

123 整理 SES 6

10 Ceph 管理員模組

Ceph 管理員的架構 (請參閱《部署指南》, 第 1 章「SUSE Enterprise Storage 6

和 Ceph」, 第 1.2.3 節「Ceph 節點和精靈」中的簡短介紹) 允許您透過「儀表板」

(請參閱第 22 章「Ceph Dashboard」)、「prometheus」(請參閱第 7 章「監控和警

示」) 或「平衡器」等模組來延伸其功能。

若要列出所有可用的模組，請執行：

cephadm@adm > ceph mgr module ls{ "enabled_modules": [ "restful", "status" ], "disabled_modules": [ "dashboard" ]}

若要啟用或停用特定模組，請執行：

cephadm@adm > ceph mgr module enable MODULE-NAME

例如：

cephadm@adm > ceph mgr module disable dashboard

若要列出已啟用模組所提供的服務，請執行：

cephadm@adm > ceph mgr services{ "dashboard": "http://myserver.com:7789/", "restful": "https://myserver.com:8789/"}

10.1 平衡器

平衡器模組可最佳化各 OSD 之間的放置組 (PG) 分佈，以實現更平衡的部署。儘管預

設會啟用該模組，但它將處於非使用中狀態。它支援「crush-compat」和「upmap」這

兩種模式。

124 平衡器 SES 6

提示：目前的平衡器組態若要檢視目前的平衡器組態，請執行以下指令：

cephadm@adm > ceph config-key dump

重要：支援的模式我們目前僅支援「crush-compat」模式，因為「upmap」模式要求啟用能夠阻止

所有早於 Luminous 版本的 OSD 連接至叢集的 OSD 功能。

10.1.1 「crush-compat」模式

在「crush-compat」模式下，平衡器會調整 OSD 的重設權數集，以改進資料分佈。它

會將 PG 在 OSD 之間移動，因此會暫時出現由 PG 錯放所導致的 HEALTH_WARN 叢集狀

態。

提示：模式的啟用儘管「crush-compat」為預設模式，但我們仍建議明確將其啟用：

cephadm@adm > ceph balancer mode crush-compat

10.1.2 資料平衡的規劃和執行

您可以使用平衡器模組建立資料平衡計畫。隨後，您可以手動執行該計畫，或讓平衡器

持續平衡 PG。

若要決定是以手動還是自動模式來執行平衡器，需要考慮諸如目前資料的不平衡情況、

叢集大小、PG 計數或 I/O 活動等多項因素。我們建議選擇在叢集中的 I/O 負載較低

時建立和執行初始計畫。原因是初始的不平衡情況可能會非常嚴重，因此最好將對用戶

端的影響保持在較低程度。初始的手動執行完成後，建議您啟用自動模式，並監控正常

I/O 負載下的重新平衡流量。需要對照平衡器所導致的重新平衡流量來權衡 PG 分佈的

改進。

125 「crush-compat」模式 SES 6

提示：放置組 (PG) 的可移動部分在平衡過程中，平衡器模組會節流 PG 的移動，以便僅移動可設定的 PG 部分。

該部分預設為 5%，您可透過執行以下指令調整該部分 (例如，調整為 9%)：

cephadm@adm > ceph config set mgr target_max_misplaced_ratio .09

若要建立和執行平衡計畫，請執行以下步驟：

1. 檢查目前的叢集分數：

cephadm@adm > ceph balancer eval

2. 建立計畫，例如「great_plan」：

cephadm@adm > ceph balancer optimize great_plan

3. 查看「great_plan」將引發的變更：

cephadm@adm > ceph balancer show great_plan

4. 檢查潛在的叢集分數 (如果您決定套用「great_plan」)：

cephadm@adm > ceph balancer eval great_plan

5. 執行「great_plan」一次：

cephadm@adm > ceph balancer execute great_plan

6. 使用 ceph -s 指令觀察叢集平衡情況。如果您對結果滿意，請啟用自動平衡：

cephadm@adm > ceph balancer on

如果您稍後決定停用自動平衡，請執行：

cephadm@adm > ceph balancer off

提示：在不執行初始計畫的情況下啟用自動平衡您可以不執行初始計畫，直接啟用自動平衡。在此情況下，放置組的重新平衡用

時可能會非常長。

126 資料平衡的規劃和執行 SES 6

10.2 遙測模組遙測外掛程式可傳送有關執行其的叢集的 Ceph 專案匿名資料。

此 (選擇加入) 元件包含有關叢集部署方式、Ceph 版本、主機分佈，以及其他有助於

專案更好地瞭解 Ceph 使用方式的參數的計數器和統計資料。它不包含任何諸如池名

稱、物件名稱、物件內容或主機名稱等敏感性資料。

遙測模組用於為開發人員提供自動化回饋迴路，以協助其量化採用率、追蹤情況，或指

出為避免出現不良後果而需在組態期間以更佳方式進行解釋或驗證的內容。

注意遙測模組需要 Ceph 管理員節點能夠透過 HTTPS 將資料推入至上游伺服器。請

確定您的企業防火牆允許此動作。

1. 若要啟用遙測模組，請執行以下指令：

cephadm@adm > ceph mgr module enable telemetry

注意此指令只能讓您在本地檢視您的資料。它並不會將您的資料與 Ceph 社群共

用。

2. 若要允許遙測模組開始共用資料，請執行以下指令：

cephadm@adm > ceph telemetry on

3. 若要停用遙測資料共用，請執行以下指令：

cephadm@adm > ceph telemetry off

4. 若要產生可列印的 JSON 報告，請執行以下指令：

cephadm@adm > ceph telemetry show

5. 若要新增聯絡資訊和描述至報告，請執行以下指令：

cephadm@adm > ceph config set mgr mgr/telemetry/contact ‘John Doe [email protected]’cephadm@adm > ceph config set mgr mgr/telemetry/description ‘My first Ceph cluster’

127 遙測模組 SES 6

6. 該模組預設每 24 小時編譯並傳送一次新報告。若要調整此間隔，請執行以下指

令：

cephadm@adm > ceph config set mgr mgr/telemetry/interval HOURS

128 遙測模組 SES 6

11 管理儲存池

Ceph 將資料儲存在池中。池是用於儲存物件的邏輯群組。如果您先部署叢集而不建立

池，Ceph 會使用預設池來儲存資料。下面著重指出與 Ceph 池有關的重要特性：

韌性：您可以設定允許多少個 OSD、桶或葉發生故障而不會遺失資料。對於副本

池，它是物件的所需副本/複本數。建立新池時，會將預設複本數設定為 3。對於

糾刪碼池，該計數為編碼區塊數 (在糾刪碼設定檔中，設定為 m=2)。

放置群組：用於跨 OSD 將資料儲存在某個池中的內部資料結構。CRUSH 地圖中

定義了 Ceph 將資料儲存到 PG 中的方式。建立池時，您可以為其設定放置群組

數量。一般的組態為每個 OSD 使用約 100 個放置群組，以提供最佳平衡而又不

會耗費太多運算資源。設定多個池時，請務必將池和叢集做為整體進行考量，以

確保設定合理的放置群組數。每個池的 Ceph PG 數計算器 (https://ceph.com/

pgcalc/) 可為您提供協助。

CRUSH 規則：在池中儲存資料時，系統會依據對應至該池的 CRUSH 規則集來放置

物件及其複本或區塊 (如果是糾刪碼池)。您可以為池建立自訂 CRUSH 規則。

快照：使用 ceph osd pool mksnap 建立快照時，可高效建立特定池的快照。

若要將資料組織到池中，您可以列出、建立和移除池。您還可以檢視每個池的使用量統

計資料。

11.1 將池與應用程式關聯在使用池之前，需要將它們與應用程式關聯。將與 CephFS 搭配使用或由物件閘道自動

建立的池會自動相關聯。

對於其他情況，可以手動將自由格式的應用程式名稱與池關聯：

cephadm@adm > ceph osd pool application enable pool_name application_name

提示：預設應用程式名稱CephFS 使用應用程式名稱 cephfs，RADOS 區塊裝置使用 rbd，物件閘道使用

rgw。

129 將池與應用程式關聯 SES 6

https://ceph.com/pgcalc/

https://ceph.com/pgcalc/

一個池可以與多個應用程式關聯，而每個應用程式都可具有自己的中繼資料。您可以使

用以下指令顯示給定池的應用程式中繼資料：

cephadm@adm > ceph osd pool application get pool_name

11.2 操作池

本節介紹對池執行基本任務的特定資訊。您可以瞭解如何列出、建立和刪除池，以及如

何顯示池統計資料或管理池快照。

11.2.1 列出池

若要列出叢集的池，請執行以下指令：

cephadm@adm > ceph osd pool ls

11.2.2 建立池

可以建立「replicated」(用於保留物件的多個複本，以便從發生故障的 OSD 復原) 或

「erasure」(用於獲得某種通用 RAID6 功能) 類型的池。複本池所需的原始儲存空間

較多，而糾刪碼池所需的原始儲存空間較少。預設值為「replicated」。

若要建立副本池，請執行以下指令：

cephadm@adm > ceph osd pool create pool_name pg_num pgp_num replicated crush_ruleset_name \expected_num_objects

若要建立糾刪碼池，請執行以下指令：

cephadm@adm > ceph osd pool create pool_name pg_num pgp_num erasure erasure_code_profile \ crush_ruleset_name expected_num_objects

如果超出了每個 OSD 的放置群組限制，則 ceph osd pool create 可能會失敗。使用

mon_max_pg_per_osd 選項可設定該限制。

pool_name

130 操作池 SES 6

池的名稱，必須是唯一的。必須指定此選項。

pg_num

池的放置群組總數，必須指定此選項。預設值為 8。

pgp_num

用於放置資料的放置群組總數。此數量應該與放置群組總數相等，放置群組拆分

情況除外。必須指定此選項。預設值為 8。

crush_ruleset_name

此池的 crush 規則集名稱。如果所指定的規則集不存在，則建立複本池的操作

將會失敗，並顯示 -ENOENT。對於複本池，該規則集是 osd pool default crush

replicated ruleset 組態變數所指定的規則集。此規則集必須存在。對於糾

刪碼池，如果使用預設糾刪碼設定檔，則規則集為「erasure-code」，否則為

POOL_NAME。如果此規則集尚不存在，系統將隱式建立該規則集。

erasure_code_profile=profile

僅適用於糾刪碼池。使用糾刪碼設定檔。該設定檔必須是 osd erasure-code-

profile set 所定義的現有設定檔。

建立池時，請將放置群組數設定為合理的值。還需考慮每個 OSD 的放置群組總

數。放置群組在運算方面的開銷很高，因此如果您的許多池都包含很多放置群組

(例如有 50 個池，每個池各有 100 個放置群組)，效能將會下降。

如需計算池的適當放置群組數的詳細資料，請參閱第 9.4 節「置放群組」。

expected_num_objects

此池的預期物件數。如果設定此值 (與一個為負數的 filestore merge threshold

值)，系統在建立池時會分割 PG 資料夾。這可避免因執行時期資料夾拆分導致的

延遲影響。

11.2.3 設定池定額

您可以設定池定額，限定每個池的最大位元組數和/或最大物件數。

cephadm@adm > ceph osd pool set-quota pool-name max_objects obj-count max_bytes bytes

例如：

cephadm@adm > ceph osd pool set-quota data max_objects 10000

131 設定池定額 SES 6

若要移除定額，請將其值設定為 0。

11.2.4 刪除池

警告：刪除池的操作不可逆池中可能包含重要資料。刪除池會導致池中的所有資料消失，且無法復原。

不小心刪除池十分危險，因此 Ceph 實作了兩個機制來防止刪除池。若要刪除池，必須

先停用這兩個機制。

第一個機制是 NODELETE 旗標。每個池都有這個旗標，其預設值為「false」。若要確

定某個池的此旗標值，請執行以下指令：

cephadm@adm > ceph osd pool get pool_name nodelete

如果指令輸出 nodelete: true，則只有在使用以下指令變更該旗標後，才能刪除池：

cephadm@adm > ceph osd pool set pool_name nodelete false

第二個機制是叢集範圍的組態參數 mon allow pool delete，其預設值為「false」。

這表示預設不能刪除池。顯示的錯誤訊息是：

Error EPERM: pool deletion is disabled; you must first set themon_allow_pool_delete config option to true before you can destroy a pool

若要規避此安全設定以刪除池，可以暫時將 mon allow pool delete 設定為

「true」，刪除池，然後將該參數恢復為「false」：

cephadm@adm > ceph tell mon.* injectargs --mon-allow-pool-delete=truecephadm@adm > ceph osd pool delete pool_name pool_name --yes-i-really-really-mean-itcephadm@adm > ceph tell mon.* injectargs --mon-allow-pool-delete=false

injectargs 指令會顯示以下訊息：

injectargs:mon_allow_pool_delete = 'true' (not observed, change may require restart)

這主要用於確認該指令已成功執行。它不是錯誤。

如果為您建立的池建立了自己的規則集和規則，則應該考慮在不再需要該池時移除規則

集和規則。

132 刪除池 SES 6

11.2.5 重新命名池

若要重新命名池，請執行以下指令：

cephadm@adm > ceph osd pool rename current-pool-name new-pool-name

如果重新命名了某個池，且為經過驗證的使用者使用了依池能力，則必須用新的池名稱

更新使用者的能力。

11.2.6 顯示池統計資料

若要顯示池的使用量統計資料，請執行以下指令：

cephadm@adm > rados dfPOOL_NAME USED OBJECTS CLONES COPIES MISSING_ON_PRIMARY UNFOUND DEGRADED RD_OPS RD WR_OPS WR USED COMPR UNDER COMPR.rgw.root 768 KiB 4 0 12 0 0 0 44 44 KiB 4 4 KiB 0 B 0 Bcephfs_data 960 KiB 5 0 15 0 0 0 5502 2.1 MiB 14 11 KiB 0 B 0 Bcephfs_metadata 1.5 MiB 22 0 66 0 0 0 26 78 KiB 176 147 KiB 0 B 0 Bdefault.rgw.buckets.index 0 B 1 0 3 0 0 0 4 4 KiB 1 0 B 0 B 0 Bdefault.rgw.control 0 B 8 0 24 0 0 0 0 0 B 0 0 B 0 B 0 Bdefault.rgw.log 0 B 207 0 621 0 0 0 5372132 5.1 GiB 3579618 0 B 0 B 0 Bdefault.rgw.meta 961 KiB 6 0 18 0 0 0 155 140 KiB 14 7 KiB 0 B 0 Bexample_rbd_pool 2.1 MiB 18 0 54 0 0 0 3350841 2.7 GiB 118 98 KiB 0 B 0 Biscsi-images 769 KiB 8 0 24 0 0 0 1559261 1.3 GiB 61 42 KiB 0 B 0 Bmirrored-pool 1.1 MiB 10 0 30 0 0 0 475724 395 MiB 54 48 KiB 0 B 0 Bpool2 0 B 0 0 0 0 0 0 0 0 B 0 0 B 0 B 0 Bpool3 333 MiB 37 0 111 0 0 0 3169308 2.5 GiB 14847 118 MiB 0 B 0 Bpool4 1.1 MiB 13 0 39 0 0 0 1379568 1.1 GiB 16840 16 MiB 0 B 0 B

各欄的描述如下：

USED

池使用的位元組數。

133 重新命名池 SES 6

OBJECTS

池中儲存的物件數。

CLONES

池中儲存的克隆數。如果在建立快照時某個用戶端向物件寫入資料，系統將會建

立原始物件的克隆，而不是對該物件進行修改，這樣便不會修改已建立快照的原

始物件內容。

COPIES

物件複本的數量。例如，如果某個複製因數為 3 的複本池有「x」個物件，它通

常將會有 3 * x 個複本。

MISSING_ON_PRIMARY

當主 OSD 上的複本缺失時，處於降級狀態 (不是所有複本都存在) 的物件的數

量。

UNFOUND

未找到的物件數。

DEGRADED (已降級)

已降級的物件數。

RD_OPS

針對此池要求的讀取操作總數。

RD

從此池讀取的位元組總數。

WR_OPS

針對此池要求的寫入操作總數。

WR

寫入池的位元組總數。請注意，該數值與池的使用率不同，因為您可能會多次寫

入同一物件。如此一來，池的使用率雖然不變，但寫入池的位元組數會增長。

USED COMPR

為壓縮資料配置的位元組數。

UNDER COMPR

壓縮資料在未壓縮時佔用的位元組數。

134 顯示池統計資料 SES 6

11.2.7 獲取池的值

若要獲取池中的值，請執行以下指令：

cephadm@adm > ceph osd pool get pool-name key

您可以獲取第 11.2.8 節「設定池的值」中所列鍵以及下列鍵的值：

pg_num

池的放置群組數。

pgp_num

計算資料放置時要使用的放置群組的有效數量。有效範圍小於或等於 pg_num。

提示：池的所有值若要列出與特定池相關的所有值，請執行以下指令：

cephadm@adm > ceph osd pool get POOL_NAME all

11.2.8 設定池的值

若要設定池的值，請執行以下指令：

cephadm@adm > ceph osd pool set pool-name key value

您可以設定以下鍵的值：

size

設定池中物件的複本數。如需更多詳細資料，請參閱第 11.2.9 節「設定物件複

本數」。僅限副本池。

min_size

設定 I/O 所需的最小複本數。如需更多詳細資料，請參閱第 11.2.9 節「設定

物件複本數」。僅限副本池。

crash_replay_interval

允許用戶端重送已確認但未提交的要求的秒數。

135 獲取池的值 SES 6

pg_num

池的放置群組數。如果您將新 OSD 新增至叢集，請確認所有池上專用於新 OSD

的放置群組的值。

pgp_num

計算資料放置時要使用的放置群組的有效數量。

crush_ruleset

用於在叢集中對應物件放置的規則集。

hashpspool

為給定池設定 (1) 或取消設定 (0) HASHPSPOOL 旗標。啟用此旗標會變更演算

法，以採用更佳的方式將 PG 分佈到 OSD 之間。對之前 HASHPSPOOL 旗標設為預

設值 0 的池啟用此旗標後，叢集會開始回填，以使所有 PG 恢復正確的放置狀

態。請注意，此操作可能會在叢集上產生大量 I/O 負載，因此請勿對負載較高的

生產叢集啟用該旗標 (由 0 變更為 1)。

nodelete

防止移除池。

nopgchange

防止變更池的 pg_num 和 pgp_num。

nosizechange

防止變更池的大小。

write_fadvise_dontneed

對給定池設定/取消設定 WRITE_FADVISE_DONTNEED 旗標。

noscrub、nodeep-scrub

停用 (深層) 整理特定池的資料，以解決暫時性的高 I/O 負載問題。

hit_set_type

對快取池啟用命中集追蹤。請參閱布隆過濾器 (http://en.wikipedia.org/

wiki/Bloom_filter) 以瞭解更多資訊。此選項可用的值如

下： bloom、 explicit_hash、 explicit_object。預設值為 bloom，其他值僅用於

測試。

hit_set_count

136 設定池的值 SES 6

http://en.wikipedia.org/wiki/Bloom_filter


要為快取池儲存的命中集數。該數值越高， ceph-osd 精靈耗用的 RAM 越多。預

設值為 0。

hit_set_period

快取池的命中集期間的時長 (以秒計)。該數值越高， ceph-osd 精靈耗用的 RAM

越多。

hit_set_fpp

布隆命中集類型的誤報率。請參閱布隆過濾器 (http://en.wikipedia.org/wiki/

Bloom_filter) 以瞭解更多資訊。有效範圍是 0.0 - 1.0，預設值為 0.05

use_gmt_hitset

為快取分層建立命中集時，強制 OSD 使用 GMT (格林威治標準時間) 時戳。這可

確保在不同時區中的節點傳回相同的結果。預設值為 1。不應該變更此值。

cache_target_dirty_ratio

在快取分層代理程式將已修改 (髒) 物件衝洗到後備儲存池之前，包含此類物件

的快取池百分比。預設值為 0.4。

cache_target_dirty_high_ratio

在快取分層代理程式將已修改 (髒) 物件衝洗到速度更快的後備儲存池之前，包

含此類物件的快取池百分比。預設值為 0.6。

cache_target_full_ratio

在快取分層代理程式將未修改 (乾淨) 物件從快取池逐出之前，包含此類物件的

快取池百分比。預設值為 0.8。

target_max_bytes

觸發 max_bytes 閾值後，Ceph 將會開始衝洗或逐出物件。

target_max_objects

觸發 max_objects 閾值後，Ceph 將會開始衝洗或逐出物件。

hit_set_grade_decay_rate

兩次連續的 hit_set 之間的溫度降低率。預設值為 20。

hit_set_search_last_n

計算溫度時在 hit_set 中對出現的項最多計 N 次。預設值為 1。

cache_min_flush_age

137 設定池的值 SES 6



在快取分層代理程式將物件從快取池衝洗到儲存池之前的時間 (以秒計)。

cache_min_evict_age

在快取分層代理程式將物件從快取池中逐出之前的時間 (以秒計)。

fast_read

如果對糾刪碼池啟用此旗標，則讀取要求會向所有分區發出子讀取指令，並一直

等到接收到足夠解碼的分區，才會為用戶端提供服務。對於 jerasure 和 isa 糾

刪外掛程式，前 K 個複本傳回時，就會使用從這些複本解碼的資料立即處理用

戶端的要求。採用此方法會產生較高的 CPU 負載，而磁碟/網路負載則較低。目

前，此旗標僅支援用於糾刪碼池。預設值為 0。

scrub_min_interval

叢集負載低時整理池的最小間隔 (以秒計)。預設值 0 表示使用來自 Ceph 組態

檔案的 osd_scrub_min_interval 值。

scrub_max_interval

無論叢集負載如何都整理池的最大間隔 (以秒計)。預設值 0 表示使用來自 Ceph

組態檔案的 osd_scrub_max_interval 值。

deep_scrub_interval

深層整理池的間隔 (以秒計)。預設值 0 表示使用來自 Ceph 組態檔案的

osd_deep_scrub 值。

11.2.9 設定物件複本數

若要設定副本池上的物件複本數，請執行以下指令：

cephadm@adm > ceph osd pool set poolname size num-replicas

num-replicas 包括物件自身。例如，如果您想用物件和物件的兩個複本組成物件的三

個例項，請指定 3。

警告：設定的複本不能少於 3 個如果將 num-replicas 設定為 2，資料將只有一個副本。例如，如果一個物件例

項發生故障，則需要在復原期間確定自上次整理後，另一個複本沒有損毀 (如需

詳細資料，請參閱第 9.6 節「整理」)。

138 設定物件複本數 SES 6

將池設定為具有一個複本意味著池中的資料物件只有一個例項。如果 OSD 發生

故障，您將遺失資料。若要短時間儲存臨時資料，可能就會用到只有一個副本的

池。

提示：設定 3 個以上的複本為池設定 4 個複本可將可靠性提高 25%。

如果有兩個資料中心，您至少需要為池設定 4 個複本，使每個資料中心都有兩

個複本。如此，當其中一個資料中心發生故障時，仍有兩個複本存在，並且如果

又有一個磁碟發生故障，您仍可確保不會遺失資料。

注意物件可接受降級模式下複本數量低於 pool size 的 I/O。若要設定 I/O 所需複

本的最小數量，您應該使用 min_size 設定。例如：

cephadm@adm > ceph osd pool set data min_size 2

這可確保資料池中沒有物件會接收到複本數量低於 min_size 的 I/O。

提示：獲取物件複本數若要獲取物件複本數，請執行以下指令：

cephadm@adm > ceph osd dump | grep 'replicated size'

Ceph 將列出池，並反白顯示 replicated size 屬性。Ceph 預設會建立物件的兩

個複本 (共三個副本，或者大小為 3)。

11.3 池移轉

建立池 (請參閱第 11.2.2 節「建立池」) 時，您需要指定池的初始參數，例如池類

型或放置群組數量。如果您稍後決定變更其中的任一參數 (例如將複本池轉換為糾刪碼

池，或者減少放置群組數量)，您需要將池資料移轉至參數適合您的部署的另一個池。

139 池移轉 SES 6

移轉池的方法有多種。我們建議使用快取層，因為此方法是透明的，能夠減少叢集停機

時間並避免複製整個池的資料。

11.3.1 使用快取層移轉

提示：僅移轉複本池您可以使用快取層方法，從複本池移轉至糾刪碼池或另一個複本池。不支援從糾

刪碼池移轉。

該方法的原理十分簡單，只需將需要移轉的池依相反的順序加入快取層中即可。如需快

取層的詳細資訊，請參閱第 14 章「快取分層」。下面是將名為「testpool」的複本

池移轉至糾刪碼池的範例：

程序 11.1︰將複本池移轉至糾刪碼池

1. 建立一個名為「newpool」的新糾刪碼池。如需池建立參數的詳細說明，請參

閱第 11.2.2 節「建立池」。

cephadm@adm > ceph osd pool create newpool PG_NUM PGP_NUM erasure default

確認使用的用戶端金鑰圈所提供的針對「newpool」的功能至少與針對

「testpool」的相同。

您現在有兩個池，即填滿資料的原始副本池「testpool」和新的空白糾刪碼池

「newpool」：

圖形 11.1︰移轉前的池

2. 設定快取層，並將複本池「testpool」設定為快取池。透過使用 -force-

nonempty 選項，即使池已有資料，您也可以新增快取層：

cephadm@adm > ceph tell mon.* injectargs \

140 使用快取層移轉 SES 6

'--mon_debug_unsafe_allow_tier_with_nonempty_snaps=1'cephadm@adm > ceph osd tier add newpool testpool --force-nonemptycephadm@adm > ceph osd tier cache-mode testpool proxy

圖形 11.2︰快取層設定

3. 強制快取池將所有物件移到新池中：

cephadm@adm > rados -p testpool cache-flush-evict-all

圖形 11.3︰資料衝洗

4. 您需要指定一個重疊層，以便在舊池中搜尋物件，直到所有資料都已衝洗到新的

糾刪碼池。

cephadm@adm > ceph osd tier set-overlay newpool testpool

有了重疊層，所有操作都會轉到舊的副本池「testpool」：

圖形 11.4︰設定重疊層

現在，您可以將所有用戶端都切換為存取新池中的物件。

5. 所有資料都移轉至糾刪碼池「newpool」後，移除重疊層和舊快取池

「testpool」：

141 使用快取層移轉 SES 6

cephadm@adm > ceph osd tier remove-overlay newpoolcephadm@adm > ceph osd tier remove newpool testpool

圖形 11.5︰完成移轉

6. 執行

cephadm@adm > ceph tell mon.* injectargs \ '--mon_debug_unsafe_allow_tier_with_nonempty_snaps=0'

警告：您無法將 RBD 影像和 CephFS 輸出移轉至糾刪碼池您無法將 RBD 影像和 CephFS 輸出從複本池移轉至糾刪碼池。糾刪碼池可以儲

存資料，但無法儲存中繼資料。系統將無法衝洗 RBD 的標題物件。這一點對

CephFS 同樣適用。

11.3.2 移轉 RADOS 區塊裝置影像

建議採用如下方式將 RBD 影像從一個複本池移轉至另一個複本池。

1. 禁止用戶端 (例如虛擬機器) 存取 RBD 影像。

2. 在目標池中建立新影像，並將其父項設定為來源影像：

cephadm@adm > rbd migration prepare SRC_POOL/IMAGE TARGET_POOL/IMAGE

提示：僅將資料移轉至糾刪碼池如果您只需將影像資料移轉至新糾刪碼池，而將中繼資料保留在原始複本池

中，請改為執行以下指令：

cephadm@adm > rbd migration prepare SRC_POOL/IMAGE \

142 移轉 RADOS 區塊裝置影像 SES 6

--data-pool TARGET_POOL/IMAGE

注意：用戶端支援和停機時間使用 rbd migration 方法可確保在移轉影像時最大限度地減少用戶端停機

時間。您只需要在「準備」步驟之前停止用戶端，在此之後便可將其啟動。

請注意，只有支援此功能的 librbd 用戶端 (Ceph Nautilus 或更新版本)

才能在「準備」步驟之後開啟影像，而較舊的 librbd 用戶端或 krbd 用

戶端在執行「提交」步驟之前將無法開啟影像。

3. 讓用戶端存取目標池中的影像。

4. 將資料移轉至目標池：

cephadm@adm > rbd migration execute SRC_POOL/IMAGE

5. 移除舊影像：

cephadm@adm > rbd migration commit SRC_POOL/IMAGE

11.4 池快照

池快照是整個 Ceph 池的狀態快照。透過池快照，您可以保留池狀態的歷程。建立池快

照會佔用與池大小成正比的儲存空間。在建立池快照之前，請務必檢查相關儲存是否有

足夠的磁碟空間。

11.4.1 建立池快照

若要建立池快照，請執行以下指令：

cephadm@adm > ceph osd pool mksnap POOL-NAME SNAP-NAME

例如：

cephadm@adm > ceph osd pool mksnap pool1 snap1created pool pool1 snap snap1

143 池快照 SES 6

11.4.2 列出池的快照

若要列出池的現有快照，請執行以下指令：

cephadm@adm > rados lssnap -p POOL_NAME

例如：

cephadm@adm > rados lssnap -p pool11 snap1 2018.12.13 09:36:202 snap2 2018.12.13 09:46:032 snaps

11.4.3 移除池快照

若要移除池的某個快照，請執行以下指令：

cephadm@adm > ceph osd pool rmsnap POOL-NAME SNAP-NAME

11.5 資料壓縮BlueStore (如需更多詳細資料，請參閱《部署指南》, 第 1 章「SUSE Enterprise

Storage 6 和 Ceph」, 第 1.4 節「BlueStore」) 提供即時資料壓縮，以節省磁碟空

間。壓縮率取決於系統中儲存的資料。請注意，壓縮/解壓縮需要額外的 CPU 資源。

您可以全域設定資料壓縮 (請參閱第 11.5.3 節「全域壓縮選項」)，然後覆寫每個個

別池的特定壓縮設定。

無論池是否包含資料，您都可以啟用或停用池資料壓縮，或者隨時變更壓縮演算法和模

式。

啟用池壓縮之後，將不會向現有資料套用壓縮。

停用某個池的壓縮之後，將會解壓縮該池的所有資料。

11.5.1 啟用壓縮

若要對名為 POOL_NAME 的池啟用資料壓縮，請執行以下指令：

cephadm@adm > ceph osd pool set POOL_NAME compression_algorithm COMPRESSION_ALGORITHM

144 列出池的快照 SES 6

cephadm@adm > ceph osd pool set POOL_NAME compression_mode COMPRESSION_MODE

提示：停用池壓縮若要對池停用資料壓縮，請使用「none」壓縮演算法：

cephadm@adm > ceph osd pool set POOL_NAME compression_algorithm none

11.5.2 池壓縮選項

完整的壓縮設定清單：

compression_algorithm

可用的值有 none、 zstd、 snappy。預設值為 snappy。

使用的壓縮演算法取決於特定使用案例。以下是一些相關的建議：

只要您沒有充分的理由變更預設值 snappy，就請使用該值。

zstd 可提供較佳的壓縮率，但當壓縮少量資料時，會導致 CPU 負擔較高。

針對實際資料的樣本執行這些演算法的基準測試，同時觀察叢集的 CPU 和記

憶體使用率。

compression_mode

可用的值有 none、 aggressive、 passive、 force。預設值為 none。

none：永不壓縮

passive：如果提示 COMPRESSIBLE，則壓縮

aggressive：除非提示 INCOMPRESSIBLE，才壓縮

force：永遠都壓縮

compression_required_ratio

值：雙精度浮點數，比率 = SIZE_COMPRESSED / SIZE_ORIGINAL。預設值為

0.875，這表示如果壓縮未將佔用空間至少減少 12.5%，將不會壓縮物件。

由於淨增益低，儲存高於此比率的物件時不會壓縮。

145 池壓縮選項 SES 6

compression_max_blob_size

值：不帶正負號的整數，大小以位元組計。預設值： 0

所壓縮物件的最小大小。

compression_min_blob_size


所壓縮物件的最大大小。

11.5.3 全域壓縮選項

可在 Ceph 組態中設定以下組態選項，並將其套用於所有 OSD 而不僅僅是單個

池。第 11.5.2 節「池壓縮選項」中列出的池特定組態優先。

bluestore_compression_algorithm

請參閱compression_algorithm

bluestore_compression_mode

請參閱compression_mode

bluestore_compression_required_ratio

請參閱compression_required_ratio

bluestore_compression_min_blob_size


所壓縮物件的最大大小。系統預設會忽略該設定，並

使用 bluestore_compression_min_blob_size_hdd 和

bluestore_compression_min_blob_size_ssd 的值。如果設定為非零值，則該設定

優先。

bluestore_compression_max_blob_size


在將物件分割為更小的區塊之前，所壓縮物件的大小上限。系統預設

會忽略該設定，並使用 bluestore_compression_max_blob_size_hdd 和

bluestore_compression_max_blob_size_ssd 的值。如果設定為非零值，則該設定

優先。

bluestore_compression_min_blob_size_ssd

146 全域壓縮選項 SES 6

值：不帶正負號的整數，大小以位元組計。預設值： 8K

壓縮並儲存在固態硬碟上的物件的最小大小。

bluestore_compression_max_blob_size_ssd


在將物件分割為更小的區塊之前，在固態硬碟上壓縮並儲存的物件的大小上限。

bluestore_compression_min_blob_size_hdd


壓縮並儲存在普通硬碟上的物件的最小大小。

bluestore_compression_max_blob_size_hdd


在將物件分割為更小的區塊之前，在硬碟上壓縮並儲存的物件的大小上限。

147 全域壓縮選項 SES 6

12 RADOS 區塊裝置

一個區塊就是由若干位元組組成的序列，例如 4 MB 的資料區塊。區塊式儲存介面是使

用旋轉媒體 (例如硬碟、CD、軟碟) 儲存資料最常見的方式。區塊裝置介面的普及，也

使得虛擬區塊裝置成為與大量資料儲存系統 (例如 Ceph) 進行互動的理想選擇。

Ceph 區塊裝置允許共用實體資源，並且可以調整大小。它們會將儲存資料在 Ceph 叢

集中的多個 OSD 上進行分割。Ceph 區塊裝置會利用 RADOS 功能，例如建立快照、複

製和一致性。Ceph 的 RADOS 區塊裝置 (RBD) 使用核心模組或 librbd 程式庫與 OSD

互動。

圖形 12.1︰ RADOS 通訊協定

Ceph 的區塊裝置為核心模組提供高效能及無限的延展性。它們支援虛擬化解決方案

(例如 QEMU)，或依賴於 libvirt 的雲端運算系統 (例如 OpenStack)。您可以使用同

一個叢集來同時操作物件閘道、CephFS 和 RADOS 區塊裝置。

12.1 區塊裝置指令

使用 rbd 指令可建立、列出、內省和移除區塊裝置影像。您還可以使用它來執行其他

操作，例如，複製影像、建立快照、將影像復原到快照，或檢視快照。

12.1.1 在複本池中建立區塊裝置影像

將區塊裝置新增至用戶端之前，您需要在現有池中建立一個相關的影像 (請參閱第 11

章「管理儲存池」)：

cephadm@adm > rbd create --size MEGABYTES POOL-NAME/IMAGE-NAME

例如，若要建立名為「myimage」的 1 GB 影像，並使其將資訊儲存在名為「mypool」

的池中，請執行以下指令：

148 區塊裝置指令 SES 6

cephadm@adm > rbd create --size 1024 mypool/myimage

提示：影像大小單位如果您省略了大小單位捷徑 (「G」或「T」)，影像大小將以百萬位元組計。請

在大小數值之後使用「G」或「T」來指定十億位元組或兆位元組。

12.1.2 在糾刪碼池中建立區塊裝置影像

自 SUSE Enterprise Storage 5 起，可以將區塊裝置影像的資料直接儲存在糾刪碼

(EC) 池中。RADOS 區塊裝置影像由資料和中繼資料兩部分組成。您只能將 RADOS 區塊

裝置影像的「資料」部分儲存在 EC 池中。若要這麼做，池的「overwrite」旗標需要

設定為 true，並且用於儲存池的所有 OSD 都必須使用 BlueStore。

不能將影像的「中繼資料」部分儲存在 EC 池中。您需要使用 rbd create 指令的 --

pool= 選項來指定用於儲存影像中繼資料的複本池。

透過以下步驟可在新建立的 EC 池中建立 RBD 影像：

cephadm@adm > ceph osd pool create POOL_NAME 12 12 erasurecephadm@adm > ceph osd pool set POOL_NAME allow_ec_overwrites true

#Metadata will reside in pool "OTHER_POOL", and data in pool "POOL_NAME"cephadm@adm > rbd create IMAGE_NAME --size=1G --data-pool POOL_NAME --pool=OTHER_POOL

12.1.3 列出區塊裝置影像

若要列出名為「mypool」的池中的區塊裝置，請執行以下指令：

cephadm@adm > rbd ls mypool

12.1.4 擷取影像資訊

若要從名為「mypool」的池內的影像「myimage」擷取資訊，請執行以下指令：

cephadm@adm > rbd info mypool/myimage

149 在糾刪碼池中建立區塊裝置影像 SES 6

12.1.5 調整區塊裝置影像的大小

RADOS 區塊裝置影像是簡易佈建的 — 在您開始將資料儲存到這些影像之前，它們實際

上並不會使用任何實體儲存。但是，這些影像具有您使用 --size 選項設定的最大容

量。如果您要增大 (或減小) 影像的最大大小，請執行以下指令：

cephadm@adm > rbd resize --size 2048 POOL_NAME/IMAGE_NAME # to increasecephadm@adm > rbd resize --size 2048 POOL_NAME/IMAGE_NAME --allow-shrink # to decrease

12.1.6 移除區塊裝置影像

若要移除「mypool」池內的影像「myimage」所對應的區塊裝置，請執行以下指令：

cephadm@adm > rbd rm mypool/myimage

12.2 掛接和卸載

建立 RADOS 區塊裝置之後，便可以像任何其他磁碟裝置一般使用它：進行格式化、將

其掛接以便能夠交換檔案，以及在完成時將其卸載。

1. 確定您的 Ceph 叢集的池中包含要對應的磁碟影像。假設池名為 mypool，影像名

為 myimage。

cephadm@adm > rbd list mypool

2. 將影像對應到新的區塊裝置。

cephadm@adm > rbd map --pool mypool myimage

提示：使用者名稱和驗證若要指定使用者名稱，請使用 --id user-name。如果您使用 cephx 驗證，

則還需要指定機密。該機密可能來自金鑰圈，或某個包含機密的檔案：

cephadm@adm > rbd map --pool rbd myimage --id admin --keyring /path/to/keyring

或

150 調整區塊裝置影像的大小 SES 6

cephadm@adm > rbd map --pool rbd myimage --id admin --keyfile /path/to/file

3. 列出所有對應的裝置：

cephadm@adm > rbd showmapped id pool image snap device 0 mypool myimage - /dev/rbd0

我們要使用的裝置是 /dev/rbd0。

提示：RBD 裝置路徑您可以使用 /dev/rbd/POOL_NAME/IMAGE_NAME 做為永久裝置路徑來取代 /

dev/rbdDEVICE_NUMBER。例如：

/dev/rbd/mypool/myimage

4. 在 /dev/rbd0 裝置上建立 XFS 檔案系統。

root # mkfs.xfs /dev/rbd0 log stripe unit (4194304 bytes) is too large (maximum is 256KiB) log stripe unit adjusted to 32KiB meta-data=/dev/rbd0 isize=256 agcount=9, agsize=261120 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0 data = bsize=4096 blocks=2097152, imaxpct=25 = sunit=1024 swidth=1024 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=8 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0

5. 掛接裝置並檢查它是否已正確掛接。以您的掛接點取代 /mnt。

root # mount /dev/rbd0 /mntroot # mount | grep rbd0/dev/rbd0 on /mnt type xfs (rw,relatime,attr2,inode64,sunit=8192,...

現在，您便可以將資料移入和移出裝置，就如同它是本地目錄一樣。

151 掛接和卸載 SES 6

提示：增大 RBD 裝置的大小如果您發現 RBD 裝置的大小不再夠用，可以輕鬆增大大小。

1. 增大 RBD 影像的大小，例如增大到 10GB。

cephadm@adm > rbd resize --size 10000 mypool/myimage Resizing image: 100% complete...done.

2. 擴充檔案系統以填入裝置的新大小。

root # xfs_growfs /mnt [...] data blocks changed from 2097152 to 2560000

6. 當您存取完裝置後，可以將其取消對應並卸載。

cephadm@adm > rbd unmap /dev/rbd0root # unmount /mnt

提示：手動掛接 (卸載)由於在開機後手動對應和掛接 RBD 影像以及在關機前卸載和取消對應會非常

麻煩，我們提供了 rbdmap 程序檔和 systemd 單位。請參閱第 12.2.1 節

「rbdmap：在開機時對應 RBD 裝置」。

12.2.1 rbdmap：在開機時對應 RBD 裝置

rbdmap 是一個外圍程序程序檔，可對一或多個 RBD 影像自動執行 rbd map 和 rbd

unmap 操作。雖然您隨時都可以手動執行該程序檔，但其主要優勢是在開機時自動對應

和掛接 RBD 影像 (以及在關機時卸載和取消對應)，此操作由 Init 系統觸發。 ceph-

common 套件中隨附了一個 systemd 單位檔案 rbdmap.service 用於執行此操作。

該程序檔使用單個引數，可以是 map 或 unmap。使用任一引數時，該程序檔都會剖析

組態檔案。它預設為 /etc/ceph/rbdmap，但可透過環境變數 rbdmapFILE 覆寫。該組

態檔案的每一行相當於一個要對應或取消對應的 RBD 影像。

組態檔案採用以下格式：

152 rbdmap：在開機時對應 RBD 裝置 SES 6

image_specification rbd_options

image_specification

池中影像的路徑。以 pool_name / image_name 格式指定。

rbd_options

要傳遞給基礎 rbd map 指令的參數的選擇性清單。應該以逗號分隔的字串指定這

些參數及其值，例如：

PARAM1=VAL1,PARAM2=VAL2,...

該範例讓 rbdmap 程序檔執行以下指令：

cephadm@adm > rbd map POOL_NAME/IMAGE_NAME --PARAM1 VAL1 --PARAM2 VAL2

下面的範例中介紹了如何使用相應的金鑰指定使用者名稱和金鑰圈：

cephadm@adm > rbdmap map mypool/myimage id=rbd_user,keyring=/etc/ceph/ceph.client.rbd.keyring

以 rbdmap map 形式執行時，該程序檔會剖析組態檔案，並且對於每個指定的 RBD 影

像，它會嘗試先對應影像 (使用 rbd map 指令)，然後再掛接影像。

以 rbdmap unmap 形式執行時，將卸載並取消對應組態檔案中列出的影像。

rbdmap unmap-all 會嘗試卸載然後取消對應所有目前已對應的 RBD 影像，而不論它們

是否列在組態檔案中。

如果成功，rbd map 操作會將影像對應到 /dev/rbdX 裝置，此時會觸發 udev 規則，

以建立易記的裝置名稱符號連結 /dev/rbd/pool_name/image_name，該連結指向實際對

應的裝置。

為了使掛接和卸載成功，「易記的」裝置名稱在 /etc/fstab 中需有對應項。寫入 RBD

影像的 /etc/fstab 項目時，指定「noauto」(或「nofail」) 掛接選項。這可防止

Init 系統過早 (尚未出現有問題的裝置時) 嘗試掛接裝置，因為 rbdmap.service 一

般在開機序列中相當靠後的時間觸發。

如需 rbd 選項的完整清單，請參閱 rbd 手冊頁 ( man 8 rbd )。

如需 rbdmap 用法的範例，請參閱 rbdmap 手冊頁 ( man 8 rbdmap )。

153 rbdmap：在開機時對應 RBD 裝置 SES 6

12.2.2 增大 RBD 裝置的大小

如果您發現 RBD 裝置的大小不再夠用，可以輕鬆增大大小。

1. 增大 RBD 影像的大小，例如增大到 10GB。

cephadm@adm > rbd resize --size 10000 mypool/myimage Resizing image: 100% complete...done.

2. 擴充檔案系統以填入裝置的新大小。

root # xfs_growfs /mnt [...] data blocks changed from 2097152 to 2560000

12.3 快照RBD 快照是 RADOS 區塊裝置影像的快照。透過快照，您可以保留影像狀態的歷

程。Ceph 還支援快照分層，這可讓您輕鬆快捷地複製虛擬機器影像。Ceph 使用 rbd

指令和許多高階介面 (包括 QEMU、 libvirt、OpenStack 和 CloudStack) 支援區塊裝

置快照。

注意在建立影像的快照之前，請停止輸入和輸出操作，並衝洗所有待處理寫入操作。

如果影像包含檔案系統，則在建立快照時，檔案系統必須處於一致狀態。

12.3.1 Cephx 注意事項

如果啟用了 cephx，則必須指定使用者名稱或 ID，以及包含使用者相應金鑰的金鑰圈

的路徑。請參閱第 8 章「使用 cephx 進行驗證」，以取得詳細資料。您還可以新增

CEPH_ARGS 環境變數，以免重新輸入以下參數。

cephadm@adm > rbd --id user-ID --keyring=/path/to/secret commandscephadm@adm > rbd --name username --keyring=/path/to/secret commands

例如：

cephadm@adm > rbd --id admin --keyring=/etc/ceph/ceph.keyring commands

154 增大 RBD 裝置的大小 SES 6

cephadm@adm > rbd --name client.admin --keyring=/etc/ceph/ceph.keyring commands

提示將使用者和機密新增至 CEPH_ARGS 環境變數，如此您便無需每次都輸入它們。

12.3.2 快照基礎知識

下面的程序展示如何在指令行上使用 rbd 指令來建立、列出和移除快照。

12.3.2.1 建立快照

若要使用 rbd 建立快照，請指定 snap create 選項、池名稱和影像名稱。

cephadm@adm > rbd --pool pool-name snap create --snap snap-name image-namecephadm@adm > rbd snap create pool-name/image-name@snap-name

例如：

cephadm@adm > rbd --pool rbd snap create --snap snapshot1 image1cephadm@adm > rbd snap create rbd/image1@snapshot1

12.3.2.2 列出快照

若要列出影像的快照，請指定池名稱和影像名稱。

cephadm@adm > rbd --pool pool-name snap ls image-namecephadm@adm > rbd snap ls pool-name/image-name

例如：

cephadm@adm > rbd --pool rbd snap ls image1cephadm@adm > rbd snap ls rbd/image1

12.3.2.3 復原快照

若要使用 rbd 復原快照，請指定 snap rollback 選項、池名稱、影像名稱和快照名

稱。

155 快照基礎知識 SES 6

cephadm@adm > rbd --pool pool-name snap rollback --snap snap-name image-namecephadm@adm > rbd snap rollback pool-name/image-name@snap-name

例如：

cephadm@adm > rbd --pool pool1 snap rollback --snap snapshot1 image1cephadm@adm > rbd snap rollback pool1/image1@snapshot1

注意將影像復原到快照意味著會使用快照中的資料覆寫目前版本的影像。執行復原所

需的時間將隨影像大小的增加而延長。從快照複製較快，而從影像到快照的復原

較慢，因此複製是恢復到先前存在狀態的慣用方法。

12.3.2.4 刪除快照

若要使用 rbd 刪除快照，請指定 snap rm 選項、池名稱、影像名稱和使用者名稱。

cephadm@adm > rbd --pool pool-name snap rm --snap snap-name image-namecephadm@adm > rbd snap rm pool-name/image-name@snap-name

例如：

cephadm@adm > rbd --pool pool1 snap rm --snap snapshot1 image1cephadm@adm > rbd snap rm pool1/image1@snapshot1

注意Ceph OSD 會以非同步方式刪除資料，因此刪除快照不能立即釋放磁碟空間。

12.3.2.5 清除快照

若要使用 rbd 刪除影像的所有快照，請指定 snap purge 選項和影像名稱。

cephadm@adm > rbd --pool pool-name snap purge image-namecephadm@adm > rbd snap purge pool-name/image-name

例如：

156 快照基礎知識 SES 6

cephadm@adm > rbd --pool pool1 snap purge image1cephadm@adm > rbd snap purge pool1/image1

12.3.3 分層

Ceph 支援為一個區塊裝置快照建立多個寫入時複製 (COW) 克隆的功能。快照分層可

讓 Ceph 區塊裝置用戶端能夠極快地建立影像。例如，您可以建立區塊裝置影像並將

Linux 虛擬機器寫入其中，然後建立影像的快照、保護快照，並建立您所需數量的「寫

入時複製」複製品。快照是唯讀的，因此複製快照簡化了語意，如此可快速建立複製

品。

注意下面的指令行範例中提到的「父」和「子」這兩個術語是指 Ceph 區塊裝置快照

(父) 和從快照複製的相應影像 (子)。

每個複製的影像 (子) 都儲存了對其父影像的參考，這可讓複製的影像開啟父快照並讀

取其內容。

快照的 COW 複製品運作方式與任何其他 Ceph 區塊裝置影像完全相同。您可針對複製

的影像執行讀取、寫入、複製和調整大小操作。系統對複製的影像沒有特殊限制。但

是，快照的寫入時複製複製品會參考快照，因此您必須在複製快照之前保護快照。

注意：不支援 --image-format 1您無法為透過已取代的 rbd create --image-format 1 選項建立的影像建立快

照。Ceph 僅支援克隆預設的 format 2 影像。

12.3.3.1 分層入門

Ceph 區塊裝置分層是一個簡單的過程。您必須有一個影像。您必須建立影像的快照。

您必須保護快照。在您執行這些步驟之後，就可以開始複製快照了。

複製的影像具有對父快照的參考，並且包含池 ID、影像 ID 和快照 ID。包含池 ID 表

示您可以將快照從一個池複製到另一個池中的影像。

157 分層 SES 6

影像範本：一種常見的區塊裝置分層使用案例是建立主影像和當成複製品範本使

用的快照。例如，使用者可為 Linux 套裝作業系統 (如 SUSE Linux Enterprise

Server) 建立影像並為它建立快照。使用者可以定期更新影像和建立新的快照

(例如，先執行 zypper ref && zypper patch，接著執行 rbd snap create )。隨著

影像日趨成熟，使用者可以複製任何一個快照。

延伸的範本：更進階的使用案例包括延伸比基礎影像提供的資訊更多的範本影

像。例如，使用者可以複製影像 (虛擬機器範本) 並安裝其他軟體 (例如，資料

庫、內容管理系統或分析系統)，然後建立延伸影像的快照，這個延伸影像可以如

基礎影像一般更新。

範本池：使用區塊裝置分層的一種方法是建立包含主影像 (用做範本) 的池，然

後建立這些範本的快照。之後，您便可以擴充使用者的唯讀特權，使他們可以複

製快照，卻不能寫入池或在池中執行。

影像移轉/復原：使用區塊裝置分層的一種方法是將資料從一個池移轉或復原到另

一個池。

12.3.3.2 保護快照

複製品會存取父快照。如果使用者意外刪除了父快照，則所有複製品都會損毀。為了防

止資料遺失，您需要先保護快照，然後才能複製它。

cephadm@adm > rbd --pool pool-name snap protect \ --image image-name --snap snapshot-namecephadm@adm > rbd snap protect pool-name/image-name@snapshot-name

例如：

cephadm@adm > rbd --pool pool1 snap protect --image image1 --snap snapshot1cephadm@adm > rbd snap protect pool1/image1@snapshot1

注意您無法刪除受保護的快照。

158 分層 SES 6

12.3.3.3 複製快照

若要複製快照，您需要指定父池、影像、快照、子池和影像名稱。您需要先保護快照，

然後才能複製它。

cephadm@adm > rbd clone --pool pool-name --image parent-image \ --snap snap-name --dest-pool pool-name \ --dest child-imagecephadm@adm > rbd clone pool-name/parent-image@snap-name \pool-name/child-image-name

例如：

cephadm@adm > rbd clone pool1/image1@snapshot1 pool1/image2

注意您可以將快照從一個池複製到另一個池中的影像。例如，可以在一個池中將唯讀

影像和快照做為範本維護，而在另一個池中維護可寫入複製品。

12.3.3.4 取消保護快照

您必須先取消保護快照，然後才能刪除它。另外，您無法刪除複製品所參考的快照。您

需要先壓平快照的每個複製品，然後才能刪除快照。

cephadm@adm > rbd --pool pool-name snap unprotect --image image-name \ --snap snapshot-namecephadm@adm > rbd snap unprotect pool-name/image-name@snapshot-name

例如：

cephadm@adm > rbd --pool pool1 snap unprotect --image image1 --snap snapshot1cephadm@adm > rbd snap unprotect pool1/image1@snapshot1

12.3.3.5 列出快照的子項

若要列出快照的子項，請執行以下指令：

cephadm@adm > rbd --pool pool-name children --image image-name --snap snap-namecephadm@adm > rbd children pool-name/image-name@snapshot-name

159 分層 SES 6

例如：

cephadm@adm > rbd --pool pool1 children --image image1 --snap snapshot1cephadm@adm > rbd children pool1/image1@snapshot1

12.3.3.6 壓平複製的影像

複製的影像會保留對父快照的參考。移除子複製品對父快照的參考時，可透過將資訊從

快照複製到複製品，高效「壓平」影像。壓平複製品所需的時間隨快照大小的增加而延

長。若要刪除快照，必須先壓平子影像。

cephadm@adm > rbd --pool pool-name flatten --image image-namecephadm@adm > rbd flatten pool-name/image-name

例如：

cephadm@adm > rbd --pool pool1 flatten --image image1cephadm@adm > rbd flatten pool1/image1

注意由於壓平的影像包含快照中的所有資訊，壓平的影像佔用的儲存空間將比分層複

製品多。

12.4 鏡像RBD 影像可以在兩個 Ceph 叢集之間以非同步方式鏡像。此功能使用 RBD 記錄影像功

能來確保叢集之間的複製在當機時保持一致。鏡像在對等叢集中依池設定，並且可以

設定為自動鏡像池中的所有影像，或僅鏡像特定的影像子集。使用 rbd 指令來設定鏡

像。 rbd-mirror 精靈負責從遠端對等叢集提取影像更新，並將它們套用於本地叢集中

的影像。

注意：rbd-mirror 精靈若要使用 RBD 鏡像，您需要有兩個 Ceph 叢集，每個叢集都執行 rbd-mirror

精靈。

160 鏡像 SES 6

重要：透過 iSCSI 輸出的 RADOS 區塊裝置您無法使用基於核心的 iSCSI 閘道鏡像透過 iSCSI 輸出的 RBD 裝置。

如需 iSCSI 的更多詳細資料，請參閱第 18 章「Ceph iSCSI 閘道」。

12.4.1 rbd-mirror 精靈

兩個 rbd-mirror 精靈負責監看遠端對等叢集上的影像記錄，並針對本地叢集重放記錄

事件。RBD 影像記錄功能會依發生的順序記錄對影像進行的所有修改。如此可確保遠端

影像當機狀態一致的鏡像可在本地使用。

rbd-mirror 精靈在 rbd-mirror 套件中提供。您可以在 OSD 節點、閘道節點甚至是專

屬節點上安裝該套件。不建議您將 rbd-mirror 安裝在管理節點上。安裝、啟用和啟動

rbd-mirror：

root@minion > zypper install rbd-mirrorroot@minion > systemctl enable ceph-rbd-mirror@server_name.serviceroot@minion > systemctl start ceph-rbd-mirror@server_name.service

重要每個 rbd-mirror 精靈都必須能夠同時連接到兩個叢集。

12.4.2 池組態

下面的程序展示如何使用 rbd 指令來執行設定鏡像的基本管理任務。在 Ceph 叢集中

依池來設定鏡像。

您需要在兩個對等叢集上執行池組態步驟。為清楚起見，這些程序假設可從單部主機存

取名為「local」和「remote」的兩個叢集。

如需如何連接到不同 Ceph 叢集的更多詳細資料，請參閱 rbd 手冊頁 ( man 8 rbd )。

提示：多個叢集在下面的範例中，叢集名稱與同名的 Ceph 組態檔案 /etc/ceph/remote.conf 相

對應。

161 rbd-mirror 精靈 SES 6

12.4.2.1 在池上啟用鏡像

若要針對池啟用鏡像，請指定 mirror pool enable 子指令、池名稱和鏡像模式。鏡像

模式可以是池或影像：

pool

系統會鏡像啟用了記錄功能的池中的所有影像。

image

需要針對每個影像明確啟用鏡像。如需詳細資訊，請參閱第 12.4.3.2 節「啟用

影像鏡像」。

例如：

cephadm@adm > rbd --cluster local mirror pool enable POOL_NAME poolcephadm@adm > rbd --cluster remote mirror pool enable POOL_NAME pool

12.4.2.2 停用鏡像

若要對池停用鏡像，請指定 mirror pool disable 子指令和池名稱。使用這種方法對

池停用鏡像時，還會對已為其明確啟用鏡像的所有影像 (該池中) 停用鏡像。

cephadm@adm > rbd --cluster local mirror pool disable POOL_NAMEcephadm@adm > rbd --cluster remote mirror pool disable POOL_NAME

12.4.2.3 新增叢集對等

為了讓 rbd-mirror 精靈探查它的對等叢集，需要向池註冊該對等叢集。若要新增鏡像

對等叢集，請指定 mirror pool peer add 子指令、池名稱和叢集規格：

cephadm@adm > rbd --cluster local mirror pool peer add POOL_NAME client.remote@remotecephadm@adm > rbd --cluster remote mirror pool peer add POOL_NAME client.local@local

12.4.2.4 移除叢集對等

若要移除鏡像對等叢集，請指定 mirror pool peer remove 子指令、池名稱和對等

UUID (可透過 rbd mirror pool info 指令獲得)：

162 池組態 SES 6

cephadm@adm > rbd --cluster local mirror pool peer remove POOL_NAME \ 55672766-c02b-4729-8567-f13a66893445cephadm@adm > rbd --cluster remote mirror pool peer remove POOL_NAME \ 60c0e299-b38f-4234-91f6-eed0a367be08

12.4.3 影像組態

與池組態不同，影像組態只需要針對單個鏡像對等 Ceph 叢集執行。

系統會將鏡像的 RBD 影像指定為主要或非主要。這是影像的內容，而不是池的內容。

不能修改指定為非主要的影像。

當首次對某個影像啟用鏡像時 (如果池鏡像模式是「池」並且影像已啟用記錄影像功

能，則暗示已啟用，或者可透過 rbd 指令明確啟用 (請參閱第 12.4.3.2 節「啟用

影像鏡像」))，影像會自動升級為主要影像。

12.4.3.1 影像記錄支援

RBD 鏡像使用 RBD 記錄功能來確保複製的影像永遠在當機時保持一致狀態。在將影

像鏡像到對等叢集之前，必須啟用記錄功能。在建立影像時，可以透過將 --image-

feature exclusive-lock,journaling 選項提供給 rbd 指令來啟用該功能。

您也可以針對預先存在的 RBD 影像動態啟用記錄功能。若要啟用記錄，請指定

feature enable 子指令、池和影像名稱以及功能名稱：

cephadm@adm > rbd --cluster local feature enable POOL_NAME/IMAGE_NAME journaling

注意：選項相依項journaling 功能依賴於 exclusive-lock 功能。如果 exclusive-lock 功能尚未

啟用，您需要先啟用它，再啟用 journaling 功能。

警告：針對所有新影像啟用記錄您可以在 Ceph 組態檔案中的 rbd default features 選項中附加 journaling

值，以便預設對所有新影像啟用記錄。例如：

rbd default features = layering,exclusive-lock,object-map,deep-flatten,journaling

163 影像組態 SES 6

套用此變更之前，請慎重考慮對所有新影像啟用記錄是否適合您的部署，因為這

樣做可能會對效能產生負面影響。

12.4.3.2 啟用影像鏡像

如果鏡像設定為「影像」模式，則需要為池中的每個影像明確啟用鏡像。若要為特定影

像啟用鏡像，請指定 mirror image enable 子指令以及池和影像名稱：

cephadm@adm > rbd --cluster local mirror image enable POOL_NAME/IMAGE_NAME

12.4.3.3 停用影像鏡像

若要為特定影像停用鏡像，請指定 mirror image disable 子指令以及池和影像名稱：

cephadm@adm > rbd --cluster local mirror image disable POOL_NAME/IMAGE_NAME

12.4.3.4 影像升級和降級

在需要將主要指定移動到對等叢集中影像的容錯移轉情況下，您需要停止存取主要影

像、降級目前主要影像、升級新的主要影像，然後繼續存取替代叢集上的影像。

注意：強制升級可以使用 --force 選項強制升級。降級不能傳播到對等叢集時 (例如，當叢集

發生故障或通訊中斷時)，就需要強制升級。這將導致兩個對等叢集之間出現電

腦分裂的情況，並且影像將不再同步，直到發出了 resync 子指令。

若要將特定影像降級為非主要影像，請指定 mirror image demote 子指令以及池和影

像名稱：

cephadm@adm > rbd --cluster local mirror image demote POOL_NAME/IMAGE_NAME

若要將池中的所有主要影像都降級為非主要影像，請指定 mirror pool demote 子指令

以及池名稱：

164 影像組態 SES 6

cephadm@adm > rbd --cluster local mirror pool demote POOL_NAME

若要將特定影像升級為主要影像，請指定 mirror image promote 子指令以及池和影像

名稱：

cephadm@adm > rbd --cluster remote mirror image promote POOL_NAME/IMAGE_NAME

若要將池中的所有非主要影像都升級為主要影像，請指定 mirror pool promote 子指

令以及池名稱：

cephadm@adm > rbd --cluster local mirror pool promote POOL_NAME

提示：拆分 I/O 負載因為主要或非主要狀態是針對影像的，所以可以使用兩個叢集來分割 I/O 負

載，並進行容錯移轉或錯誤回復。

12.4.3.5 強制影像重新同步

如果 rbd-mirror 精靈偵測到電腦分裂事件，則在該情況解決之前，它不會嘗試鏡像受

影響的影像。若要繼續鏡像影像，請先降級確定已過期的影像，然後要求與主要影像重

新同步。若要要求影像重新同步，請指定 mirror image resync 子指令以及池和影像

名稱：

cephadm@adm > rbd mirror image resync POOL_NAME/IMAGE_NAME

12.4.4 鏡像狀態

系統會儲存每個主要鏡像影像的對等叢集複製狀態。可使用 mirror image status 和

mirror pool status 子指令來擷取此狀態：

若要要求鏡像影像狀態，請指定 mirror image status 子指令以及池和影像名稱：

cephadm@adm > rbd mirror image status POOL_NAME/IMAGE_NAME

若要要求鏡像池摘要狀態，請指定 mirror pool status 子指令以及池名稱：

cephadm@adm > rbd mirror pool status POOL_NAME

165 鏡像狀態 SES 6

提示：將 --verbose 選項新增至 mirror pool status 子指令會額外地輸出池中每個鏡

像影像的狀態詳細資料。

12.5 快取記憶體設定

Ceph 區塊裝置的使用者空間實作 ( librbd ) 無法利用 Linux 頁面快取。因此，它具

有自己的記憶體內部快取。RBD 快取的行為與硬碟快取類似。當作業系統傳送屏障或衝

洗要求時，所有「改動」資料都會寫入 OSD。這表示只要虛擬機器可以正確傳送衝洗要

求，使用寫回快取與使用執行良好的實體硬碟一樣安全。該快取運用最久未使用 (LRU)

演算法，並且在寫回模式下可以合併相鄰要求，以提高輸送量。

Ceph 支援為 RBD 提供寫回快取。若要啟用該快取，請將

[client]...rbd cache = true

新增至 ceph.conf 檔案的 [client] 區段。 librbd 預設不會執行任何快取。寫入和

讀取都直接到達儲存叢集，並且只有當資料的所有複本都寫入磁碟後，寫入操作才會

傳回。如果啟用了快取，寫入操作會立即傳回，除非未衝洗的位元組數大於 rbd cache

max dirty 選項中設定的數值。在此情況下，寫入操作會觸發寫回機制並一直阻塞，直

至衝洗了足夠多的位元組。

Ceph 支援為 RBD 提供直寫快取。您可以設定快取的大小，以及從寫回快取切換到直寫

快取的目標和限值。若要啟用直寫模式，請設定

rbd cache max dirty = 0

這表示只有當資料的所有複本都寫入磁碟後，寫入操作才會傳回，但可能會從快取中讀

取資料。快取資訊儲存在用戶端的記憶體中，並且每個 RBD 都有自己的快取。由於對

用戶端而言快取位於本地，因此如果有其他用戶端存取影像，不會存在快取一致性的問

題。如果啟用了快取，在 RBD 上將不能執行 GFS 或 OCFS。

RBD 的設定應位於 ceph.conf 組態檔案的 [client] 區段下。其設定包括：

rbd cache

對 RADOS 區塊裝置 (RBD) 啟用快取。預設值為「true」。

166 快取記憶體設定 SES 6

rbd cache size

RBD 快取大小 (以位元組計)。預設值為 32 MB。

rbd cache max dirty

使快取觸發寫回機制的「改動」資料限值 (以位元組計)。 rbd cache max dirty

的值必須小於 rbd cache size 的值。如果設定為 0，將使用直寫快取。預設值為

24 MB。

rbd cache target dirty

達到該「改動資料目標」後，快取即會開始向資料儲存空間寫入資料。該設定不

會使寫入快取的操作阻塞。預設值為 16 MB。

rbd cache max dirty age

寫回開始前，改動資料在快取中暫存的時間 (以秒計)。預設值為 1。

rbd cache writethrough until flush

開始進入直寫模式，在收到第一個衝洗要求後切換到寫回模式。啟用此設定雖然

較為保守，但卻是一種安全的做法，如此可應對在 rbd 上執行的虛擬機器太舊而

無法傳送衝洗要求的情況 (例如，核心早於 2.6.32 的 Linux 中的 Virtio 驅動

程式)。預設值為「true」。

12.6 QoS 設定一般而言，服務品質 (QoS) 指的是設定流量優先順序和資源保留的方法。它對於具有

特殊要求的流量傳輸尤為重要。

重要：不受 iSCSI 支援只有使用者空間 RBD 實作 librbd 會使用下列 QoS 設定， kRBD 實作不使用

這些設定。由於 iSCSI 使用的是 kRBD，因此不使用 QoS 設定。不過，對於

iSCSI，您可以使用標準核心工具在核心區塊裝置層上設定 QoS。

rbd qos iops limit

指定的每秒 I/O 操作次數上限。預設值為 0 (無上限)。

rbd qos bps limit

167 QoS 設定 SES 6

指定的每秒 I/O 位元組數上限。預設值為 0 (無上限)。

rbd qos read iops limit

指定的每秒讀取操作次數上限。預設值為 0 (無上限)。

rbd qos write iops limit

指定的每秒寫入操作次數上限。預設值為 0 (無上限)。

rbd qos read bps limit

指定的每秒內讀取的位元組數上限。預設值為 0 (無上限)。

rbd qos write bps limit

指定的每秒內寫入的位元組數上限。預設值為 0 (無上限)。

rbd qos iops burst

指定的 I/O 操作次數高載上限。預設值為 0 (無上限)。

rbd qos bps burst

指定的 I/O 位元組數高載上限。預設值為 0 (無上限)。

rbd qos read iops burst

指定的讀取操作次數高載上限。預設值為 0 (無上限)。

rbd qos write iops burst

指定的寫入操作次數高載上限。預設值為 0 (無上限)。

rbd qos read bps burst

指定的讀取的位元組數高載上限。預設值為 0 (無上限)。

rbd qos write bps burst

指定的寫入的位元組數高載上限。預設值為 0 (無上限)。

rbd qos schedule tick min

QoS 的最小排程刻點 (以毫秒計)。預設值為 50。

12.7 預先讀取設定RADOS 區塊裝置支援預先讀取/預先擷取功能，以最佳化小區塊的循序讀取。如果使用

虛擬機器，此操作通常應由客體作業系統處理，但開機載入程式可能不會發出有效的讀

取要求。如果停用快取，則會自動停用預先讀取功能。

168 預先讀取設定 SES 6

rbd readahead trigger requests

觸發預先讀取所必需的循序讀取要求數。預設值為 10。

rbd readahead max bytes

預先讀取要求的大小上限。如果設定為 0，則會停用預先讀取功能。預設值為

512kB。

rbd readahead disable after bytes

從 RBD 影像讀取此數量的位元組後，該影像的預先讀取功能將會停用，直至其關

閉。使用此設定，客體作業系統開機時便可接管預先讀取工作。如果設定為 0，

預先讀取將永遠處於啟用狀態。預設值為 50 MB。

12.8 進階功能

RADOS 區塊裝置支援可增強 RBD 影像功能的進階功能。您可以在建立 RBD 影像時在指

令行上指定這些功能，或者在 Ceph 組態檔案中使用 rbd_default_features 選項來指

定。

您可以透過以下兩種方式指定 rbd_default_features 選項的值：

指定為相應功能的內部值之和。每項功能都有自己的內部值，例如，

「layering」的內部值為 1，「fast-diff」的內部值為 16。因此，如果想要預

設啟用這兩項功能，請指定以下選項：

rbd_default_features = 17

指定為各功能的逗號分隔清單。上面的範例應如下所示：

rbd_default_features = layering,fast-diff

注意：iSCSI 不支援的功能iSCSI 不支援具有以下功能的 RBD 影像： deep-flatten、 object-

map、 journaling、 fast-diff、 striping

以下是 RBD 的進階功能清單：

169 進階功能 SES 6

layering

分層允許您使用克隆。

內部值為 1，預設值為「yes」。

striping

分割功能會將資料分佈在多個物件之間，有助於平行處理循序讀取/寫入工作負

載。它可防止大型或繁忙的 RADOS 區塊裝置出現單節點瓶頸。


exclusive-lock

如果啟用，用戶端需要在寫入資料之前鎖定物件。僅當一次只有一個用戶端在存

取影像時，才應啟用獨佔鎖定。內部值為 4。預設值為「yes」。

object-map

物件對應支援相依於獨佔鎖定支援。區塊裝置採用的是簡易佈建，也就是說這些

裝置僅儲存實際存在的資料。物件對應支援有助於追蹤哪些物件實際存在 (在磁

碟機上儲存了資料)。啟用物件對應支援可以加快克隆、輸入和輸出資料稀疏的影

像，以及刪除所需的 I/O 操作。


fast-diff

Fast-diff 支援相依於物件對應支援和獨佔鎖定支援。它會新增另一個內容至物

件對應，使其更快地產生影像各快照之間的差異以及快照的實際資料使用率。


deep-flatten

Deep-flatten 使 rbd flatten (請參閱第 12.3.3.6 節「壓平複製的影像」)

除了對影像自身有作用外，還對影像的所有快照有作用。如果沒有該功能，

影像的快照將仍然相依於其父影像，因而如果未刪除快照，您將無法刪除父影

像。Deep-flatten 使父影像可獨立於其克隆，即使這些克隆有快照也不例外。


journaling

記錄支援相依於獨佔鎖定支援。記錄會依修改發生的順序記錄影像的所有修

改。RBD 鏡像 (請參閱第 12.4 節「鏡像」) 會使用記錄將當機一致性影像複製

到遠端叢集。

內部值為 64，預設值為「no」。

170 進階功能 SES 6

12.9 使用舊核心用戶端對應 RBD

舊用戶端 (例如 SLE11 SP4) 可能無法對應 RBD 影像，因為使用 SUSE Enterprise

Storage 6 部署的叢集會強制執行一些舊用戶端不支援的功能 (RBD 影像層級功能和

RADOS 層級功能)。發生此情況時，OSD 記錄將顯示類似如下的訊息：

2019-05-17 16:11:33.739133 7fcb83a2e700 0 -- 192.168.122.221:0/1006830 >> \192.168.122.152:6789/0 pipe(0x65d4e0 sd=3 :57323 s=1 pgs=0 cs=0 l=1 c=0x65d770).connect \protocol feature mismatch, my 2fffffffffff < peer 4010ff8ffacffff missing 401000000000000

警告：變更 CRUSH 地圖桶類型將導致大規模重新平衡如果您打算在 CRUSH 地圖桶類型「straw」與「straw2」之間切換，請做好相應

規劃。這樣做預計會對叢集負載產生重大影響，因為變更桶類型將導致叢集大規

模重新平衡。

1. 停用任何不支援的 RBD 影像功能。例如：

cephadm@adm > rbd feature disable pool1/image1 object-mapcephadm@adm > rbd feature disable pool1/image1 exclusive-lock

2. 將 CRUSH 地圖桶類型由「straw2」變更為「straw」：

a. 儲存 CRUSH 地圖：

cephadm@adm > ceph osd getcrushmap -o crushmap.original

b. 反編譯 CRUSH 地圖：

cephadm@adm > crushtool -d crushmap.original -o crushmap.txt

c. 編輯 CRUSH 地圖，並以「straw」取代「straw2」。

d. 重新編譯 CRUSH 地圖：

cephadm@adm > crushtool -c crushmap.txt -o crushmap.new

e. 設定新 CRUSH 地圖：

cephadm@adm > ceph osd setcrushmap -i crushmap.new

171 使用舊核心用戶端對應 RBD SES 6

13 糾刪碼池

Ceph 提供了一種在池中正常複製資料的替代方案，稱為糾刪池或糾刪碼池。糾刪碼池

不能提供複本池的所有功能 (例如，它們無法儲存 RBD 池的中繼資料)，但其所需的原

始儲存空間更少。一個能夠儲存 1 TB 資料的預設糾刪碼池需要 1.5 TB 的原始儲存空

間，以應對發生單個磁碟故障的情況。從這方面而言，糾刪碼池優於複本池，因為後者

需要 2 TB 的原始儲存空間才能實現相同目的。

如需糾刪碼的背景資訊，請參閱 https://en.wikipedia.org/wiki/Erasure_code 。

注意使用 FileStore 時，除非已設定快取層，否則無法透過 RBD 介面存取糾刪碼

池。請參閱第 14.5 節「糾刪碼池和快取分層」以瞭解更多詳細資料，或使用

預設 BlueStore (請參閱《部署指南》, 第 1 章「SUSE Enterprise Storage 6

和 Ceph」, 第 1.4 節「BlueStore」)。

13.1 糾刪碼池的先決條件若要使用糾刪碼，您需要：

在 CRUSH 地圖中定義糾刪碼規則。

定義用於指定要使用的編碼演算法的糾刪碼設定檔。

建立使用上述規則和設定檔的池。

請記住，一旦建立好池且池中包含資料，便無法變更設定檔和設定檔中的詳細資料。

確定糾刪池的 CRUSH 規則對 step 使用 indep。如需詳細資料，請參閱第 9.3.2 節

「firstn 和 indep」。

13.2 建立範例糾刪碼池最簡單的糾刪碼池相當於 RAID5，至少需要三個主機。以下程序介紹如何建立用於測試

的池。

172 糾刪碼池的先決條件 SES 6

https://en.wikipedia.org/wiki/Erasure_code

1. ceph osd pool create 指令用於建立類型為糾刪的池。 12 表示放置群組的數

量。使用預設參數時，該池能夠處理一個 OSD 的故障。

cephadm@adm > ceph osd pool create ecpool 12 12 erasurepool 'ecpool' created

2. 字串 ABCDEFGHI 將寫入名為 NYAN 的物件。

cephadm@adm > echo ABCDEFGHI | rados --pool ecpool put NYAN -

3. 為了進行測試，現在可以停用 OSD，例如，透過斷開其網路連接來停用。

4. 若要測試該池是否可以處理多部裝置發生故障的情況，可以使用 rados 指令來存

取檔案的內容。

cephadm@adm > rados --pool ecpool get NYAN -ABCDEFGHI

13.3 糾刪碼設定檔呼叫 ceph osd pool create 指令來建立糾刪池時，除非指定了其他設定檔，否則會使

用預設的設定檔。設定檔定義資料備援。若要進行此定義，可以設定隨意命名為 k 和

m 的兩個參數。k 和 m 定義要將資料片段拆分成多少個區塊，以及要建立多少個編碼

區塊。之後，備援區塊即會儲存在不同的 OSD 上。

糾刪池設定檔所需的定義：

chunk

如果呼叫該編碼函數，它會傳回相同大小的區塊：可串連起來以重新建構原始物

件的資料區塊，以及可用於重建所遺失區塊的編碼區塊。

k

資料區塊的數量，即要將原始物件分割成的區塊數量。例如，如果 k = 2，則會

將一個 10 kB 物件分割成各為 5 kB 的 k 個物件。糾刪碼池的預設 min_size

為 k + 1。不過，我們建議將 min_size 設定為 k + 2 或更大的值，以避免寫入

操作和資料遺失。

m

編碼區塊的數量，即編碼函數運算的額外區塊數量。如果有 2 個編碼區塊，則表

示可以移出 2 個 OSD，而不會遺失資料。

173 糾刪碼設定檔 SES 6

crush-failure-domain

定義要將區塊分佈到的裝置。其值需要設定為某個桶類型。如需所有的桶類型，

請參閱第 9.2 節「桶」。如果故障網域為機櫃，則會將區塊儲存在不同的機櫃

上，以提高機櫃發生故障時的復原能力。請記住，這需要 k+m 個機架。

使用第 13.2 節「建立範例糾刪碼池」中所用的預設糾刪碼設定檔時，如果單個 OSD

或主機發生故障，叢集資料將不會遺失。因此，若要儲存 1 TB 資料，需要額外提供

0.5 TB 原始儲存空間。也就是說，需要 1.5 TB 原始儲存空間才能儲存 1 TB 資料

(因為 k=2、m=1)。這相當於常見的 RAID 5 組態。做為對比，複本池需要 2 TB 原始

儲存空間才能儲存 1 TB 資料。

可使用以下指令來顯示預設設定檔的設定：

cephadm@adm > ceph osd erasure-code-profile get defaultdirectory=.libsk=2m=1plugin=jerasurecrush-failure-domain=hosttechnique=reed_sol_van

選擇適當的設定檔非常重要，因為在建立池後便無法修改設定檔。需要建立使用不同設

定檔的新池，並將之前的池中的所有物件移到新池 (請參閱第 11.3 節「池移轉」)。

設定檔最重要的幾個參數是 k、 m 和 crush-failure-domain，因為它們定義儲存負擔

和資料持久性。例如，如果在兩個機架發生故障並且儲存負擔達到 66% 的情況下，必

須能夠維繫所需的架構，您可定義以下設定檔。請注意，這僅適用於擁有「rack」類型

的桶的 CRUSH 地圖：

cephadm@adm > ceph osd erasure-code-profile set myprofile \ k=3 \ m=2 \ crush-failure-domain=rack

對於此新設定檔，可以重複第 13.2 節「建立範例糾刪碼池」中的範例：

cephadm@adm > ceph osd pool create ecpool 12 12 erasure myprofilecephadm@adm > echo ABCDEFGHI | rados --pool ecpool put NYAN -cephadm@adm > rados --pool ecpool get NYAN -ABCDEFGHI

NYAN 物件將分割成三個 ( k=3 )，並將建立兩個額外的區塊 ( m=2 )。 m 值定義可以同

時遺失多少個 OSD 而不會遺失任何資料。 crush-failure-domain==rack 將建立一個

CRUSH 規則集，用於確保不會將兩個區塊儲存在同一個機櫃中。

174 糾刪碼設定檔 SES 6

13.3.1 建立新糾刪碼設定檔

以下指令可建立新糾刪碼設定檔：

root # ceph osd erasure-code-profile set NAME \ directory=DIRECTORY \ plugin=PLUGIN \ stripe_unit=STRIPE_UNIT \ KEY=VALUE ... \ --force

DIRECTORY

選用。設定從中載入糾刪碼外掛程式的目錄名稱。預設為 /usr/lib/ceph/

erasure-code。

175 建立新糾刪碼設定檔 SES 6

PLUGIN

選用。使用糾刪碼外掛程式可計算編碼區塊和復原遺失的區塊。可用的外掛程式

有「jerasure」、「isa」、「lrc」和「shes」。預設為「jerasure」。

STRIPE_UNIT

選用。資料區塊中每個分割區的資料量。例如，如果設定檔有 2 個資料

區塊，且 stripe_unit 等於 4K，則系統會將範圍 0-4K 的資料置於區塊

0 中，將 4K-8K 置於區塊 1 中，然後再將 8K-12K 置於區塊 0 中。需要

有多個 4K 才能實現最佳效能。預設值取自建立池時的監控程式組態選項

osd_pool_erasure_code_stripe_unit。使用此設定檔的池的「stripe_width」等於

資料區塊的數量乘以此「stripe_unit」。

KEY=VALUE

選定糾刪碼外掛程式特定的選項鍵值組。

--force

選用。覆寫名稱相同的現有設定檔，並允許設定不依 4K 對齊的 stripe_unit。

13.3.2 移除糾刪碼設定檔

以下指令可依 NAME 所識別的糾刪碼設定檔移除相應設定檔：

root # ceph osd erasure-code-profile rm NAME

重要如果某個池參考了該設定檔，則刪除將會失敗。

13.3.3 顯示糾刪碼設定檔的詳細資料

以下指令可依 NAME 所識別的糾刪碼設定檔顯示其詳細資料：

root # ceph osd erasure-code-profile get NAME

176 移除糾刪碼設定檔 SES 6

13.3.4 列出糾刪碼設定檔

以下指令可列出所有糾刪碼設定檔的名稱：

root # ceph osd erasure-code-profile ls

13.4 含 RADOS 區塊裝置的糾刪碼池

若要將 EC 池標示為 RBD 池，請對其進行相應標記：

cephadm@adm > ceph osd pool application enable rbd ec_pool_name

RBD 可在 EC 池中儲存影像資料。但是，影像標題和中繼資料仍需要儲存在複本池中。

為此，假設您的池命名為「rbd」：

cephadm@adm > rbd create rbd/image_name --size 1T --data-pool ec_pool_name

您可以如同使用任何其他影像一般正常使用該影像，只不過所有資料都將儲存在

ec_pool_name 池而非「rbd」池中。

177 列出糾刪碼設定檔 SES 6

14 快取分層

快取層是在用戶端與標準儲存之間實作的附加儲存層。該層用於加快存取低速硬碟中儲

存的池以及糾刪碼池的速度。

通常，快取分層涉及到建立一個由相對快速的儲存裝置 (例如 SSD 磁碟機) 組成且設

定為充當快取層的池，以及一個由較慢但較便宜的裝置組成且設定為充當儲存層的後備

池。快取池大小通常是儲存池大小的 10-20%。

14.1 分層儲存的相關術語

快取分層可識別兩種類型的池：快取池和儲存池。

提示如需池的一般資訊，請參閱第 11 章「管理儲存池」。

儲存池

在 Ceph 儲存叢集中儲存一個物件的多個副本的標準副本池，或糾刪碼池 (請參

閱第 13 章「糾刪碼池」)。

儲存池有時稱為「後備」儲存或「冷」儲存。

快取池

標準副本池，儲存在相對較小但速度較快的儲存裝置上，在 CRUSH 地圖中具有自

己的規則集。

快取池也稱為「熱」儲存。

14.2 需考量的要點

快取分層可能會降低特定工作負載的叢集效能。以下幾點指出了您需要考量的有關快取

分層的幾個方面：

178 分層儲存的相關術語 SES 6

取決於工作負載：快取能否提高效能取決於工作負載。由於將物件移入或移出快

取會耗費資源，因此，如果大多數要求只涉及到少量的物件，則使用快取可能更

高效。快取池的大小應該足以接收工作負載的工作集，以避免效能大幅波動。

難以進行基準測試：大多數效能基準測試可能會反映使用快取分層時效能較低。

原因在於，這些基準測試要求了大量的物件，而快取的「預熱」需要較長時間。

效能可能較低：對於不適合進行快取分層的工作負載而言，其效能往往比不啟用

快取分層的普通副本池更低。

librados 物件列舉：如果應用程式直接使用 librados 並依賴於物件列舉，則快

取分層可能無法依預期運作 (對於物件閘道、RBD 或 CephFS 而言，這不會造成

問題)。

14.3 何時使用快取分層

在以下情況下，可考慮使用快取分層：

您的糾刪碼池儲存在 FileStore 上，並且您需要透過 RADOS 區塊裝置來存取它

們。如需 RBD 的詳細資訊，請參閱第 12 章「RADOS 區塊裝置」。

您的糾刪碼池儲存在 FileStore 上，並且您需要透過 iSCSI 存取它們。如需

iSCSI 的詳細資訊，請參閱第 18 章「Ceph iSCSI 閘道」。

您的高效能儲存數量有限，而低效能儲存眾多，您需要更快地存取儲存的資料。

14.4 快取模式

快取分層代理程式可處理快取層與後備儲存層之間的資料移轉。管理員可以設定如何進

行這種移轉。主要有兩種方案：

寫回模式

在寫回模式下，Ceph 用戶端將資料寫入快取層，並從快取層接收確認回應。一

段時間後，寫入快取層的資料將移轉至儲存層，並從快取層中衝洗出去。從概念

上講，快取層疊加在後備儲存層的「前面」。當 Ceph 用戶端需要存放於儲存層

中的資料時，快取分層代理程式會在讀取時將資料移轉至快取層，然後，資料將

179 何時使用快取分層 SES 6

傳送到 Ceph 用戶端。因此，用戶端可以使用快取層執行 I/O，直到資料變為非

使用中狀態。這種做法非常適合可變的資料，例如，相片或視訊編輯，或交易資

料。

唯讀模式

在唯讀模式下，Ceph 用戶端將資料直接寫入後備層。在讀取時，Ceph 將要求的

物件從後備層複製到快取層。系統會根據定義的規則從快取層中移除過時物件。

這種做法非常適合不可變的資料，例如，在社交網路上呈現的圖片或視訊、DNA

資料或 X 光影像，因為從可能包含過時資料的快取池中讀取資料會導致一致性很

差。不要對可變的資料使用唯讀模式。

14.5 糾刪碼池和快取分層糾刪碼池需要的資源比複本池多。若要克服這些限制，建議在糾刪碼池的前面設定一個

快取層。使用 FileStore 時需要這麼做。

例如，如果「hot-storage」池由高速儲存裝置構成，則可使用以下指令來加

速第 13.3 節「糾刪碼設定檔」中建立的「ecpool」：

cephadm@adm > ceph osd tier add ecpool hot-storagecephadm@adm > ceph osd tier cache-mode hot-storage writebackcephadm@adm > ceph osd tier set-overlay ecpool hot-storage

這會將充當 ecpool 池的一個層的「hot-storage」池置於寫回模式，以便每次在

ecpool 中寫入和讀取資料時實際使用的都是熱儲存，從而受益於熱儲存的靈活性和速

度。

cephadm@adm > rbd --pool ecpool create --size 10 myvolume


14.6 設定範例分層儲存本節說明如何在標準硬碟 (冷儲存) 的前面設定一個高速 SSD 快取層 (熱儲存)。

提示下面的範例只是用於說明，其中的設定包含存在於單個 Ceph 節點上的 SSD 部

件的一個根及一條規則。

180 糾刪碼池和快取分層 SES 6

在生產環境中，叢集設定一般包含熱儲存以及混合節點 (配有 SSD 和 SATA 磁

碟) 的更多根和規則項目。

1. 建立兩個額外的 CRUSH 規則「replicated_ssd」和「replicated_hdd」，前者用

於較快的 SSD 快取裝置類別，後者用於較慢的 HDD 裝置類別：

cephadm@adm > ceph osd crush rule create-replicated replicated_ssd default host ssdcephadm@adm > ceph osd crush rule create-replicated replicated_hdd default host hdd

2. 將所有現有池都切換為使用「replicated_hdd」規則。這樣可防止 Ceph 將資料

儲存到新增的 SSD 裝置：

cephadm@adm > ceph osd pool set POOL_NAME crush_rule replicated_hdd

3. 使用 DeepSea 將該機器轉變成 Ceph 節點。依第 2.1 節「新增新的叢集節

點」所述安裝軟體並設定主機機器。我們假設此節點名為 node-4。此節點需要有

4 個 OSD 磁碟。

[...]host node-4 { id -5 # do not change unnecessarily # weight 0.012 alg straw hash 0 # rjenkins1 item osd.6 weight 0.003 item osd.7 weight 0.003 item osd.8 weight 0.003 item osd.9 weight 0.003}[...]

4. 編輯熱儲存池 (與受高速 SSD 磁碟機支援的 OSD 對應) 的 CRUSH 地圖。定義

另一個包含 SSD 根節點的階層 (指令為「root ssd」)。此外，請為 SSD 變更

權數並新增一個 CRUSH 規則。如需 CRUSH 地圖的詳細資訊，請參閱第 9.5 節

「CRUSH 地圖操作」。

使用 getcrushmap 和 crushtool 等指令行工具直接編輯 CRUSH 地圖：

cephadm@adm > ceph osd crush rm-device-class osd.6 osd.7 osd.8 osd.9cephadm@adm > ceph osd crush set-device-class ssd osd.6 osd.7 osd.8 osd.9

5. 建立用於快取分層的熱儲存池。對該池使用新的「ssd」規則：

cephadm@adm > ceph osd pool create hot-storage 100 100 replicated ssd

181 設定範例分層儲存 SES 6

6. 使用預設的「replicated_ruleset」規則建立冷儲存池：

cephadm@adm > ceph osd pool create cold-storage 100 100 replicated replicated_ruleset

7. 然後，設定快取層的過程就涉及到將後備儲存池與快取池關聯，在本例中，需要

將冷儲存 (即儲存池) 與熱儲存 (即快取池) 關聯：

cephadm@adm > ceph osd tier add cold-storage hot-storage

8. 若要將快取模式設定為「寫回」，請執行以下指令：

cephadm@adm > ceph osd tier cache-mode hot-storage writeback

如需快取模式的詳細資訊，請參閱第 14.4 節「快取模式」。

寫回快取層疊加在後備儲存池上，因此需要執行一個額外的步驟：必須將來自儲

存池的所有用戶端流量導向至快取池。例如，若要將用戶端流量直接導向至快取

池，請執行以下指令：

cephadm@adm > ceph osd tier set-overlay cold-storage hot-storage

14.7 設定快取層

可以使用多個選項來設定快取層。使用以下語法：

cephadm@adm > ceph osd pool set cachepool key value

14.7.1 命中集

使用命中集參數可以調整快取池。Ceph 中的命中集通常是布隆過濾器，提供節省記憶

體使用量的方式來追蹤已存放於快取池的物件。

命中集是一個位元陣列，用於儲存對物件名稱套用的一組雜湊函數的結果。所有位元最

初都設定為 0。將一個物件新增至命中集後，系統會對該物件的名稱進行雜湊，並且

結果將對應在命中集中的不同位置，那時，相應位元的值會設定為 1。

為了確定某個物件是否存在於快取中，將會再次對物件名稱進行雜湊。如果任一位元為

0，則表示該物件一定不在快取中，需要從冷儲存中擷取它。

182 設定快取層 SES 6

不同物件的結果可能會儲存在命中集的同一位置。在巧合的情況下，可能所有位元都是

1，而物件卻不在快取中。因此，處理布隆過濾器的命中集只能確定某個物件是否一定

不在快取中，需要從冷儲存擷取它。

一個快取池可以使用多個命中集來追蹤各期間的檔案存取。 hit_set_count 設定定義

所用的命中集數量， hit_set_period 定義每個命中集已使用了多長時間。該時期過期

後，將使用下一個命中集。如果用盡了命中集，將會釋放最舊命中集的記憶體，並建立

一個新的命中集。將 hit_set_count 和 hit_set_period 的值相乘可定義已追蹤物件

存取的整個時間範圍。

圖形 14.1︰包含 3 個儲存物件的布隆過濾器

與進行雜湊的物件數量相比，基於布隆過濾器的命中集非常節省記憶體的使用量。只需

使用不到 10 個位元即可將誤報率降低到 1% 以下。可以使用 hit_set_fpp 定義誤報

率。Ceph 可根據放置群組中的物件數量及誤報率自動計算命中集的大小。

可以使用 min_write_recency_for_promote 和 min_read_recency_for_promote 限制快

取池中所需的儲存。如果將值設定為 0，則所有物件在被讀取或寫入後，會立即提升

到快取池，並且在被逐出之前會一直保持這種模式。使用大於 0 的任何值可定義在其

中搜尋物件的命中集 (已依存留期排序) 的數量。如果在某個命中集中找到了該物件，

會將該物件提升到快取池。請記住，對物件執行備份操作也可能導致將物件提升到快取

中。如果執行值設定為「0」的完全備份，可能會導致所有資料都提升到快取層，而使

用中資料會從快取層中移除。因此，依據備份策略變更此設定的做法可能會有幫助。

183 命中集 SES 6

注意期間越長， min_read_recency_for_promote 和 min_write_recency_for_promote

的值越大， ceph-osd 精靈耗費的 RAM 就越多。特別是，當代理程式正在衝洗或

逐出快取物件時，所有 hit_set_count 命中集都會載入到 RAM 中。

14.7.1.1 對命中集使用 GMT

快取層設定包含一個稱作命中集的布隆過濾器。該過濾器測試某個物件是屬於一組熱物

件還是冷物件。物件將新增至命中集，其名稱後面附有時戳。

如果叢集機器位於不同的時區，且時戳根據當地時間衍生，則命中集中物件的名稱可能

會包含將來或過去的時戳，致使使用者產生誤解。在最壞的情況下，物件可能根本不在

命中集中。

為防止這種問題發生，在新建立的快取層設定中， use_gmt_hitset 預設設為「1」。這

樣，您便可以在建立命中集的物件名稱時，強制 OSD 使用 GMT (格林威治標準時間)

時戳。

警告：保留預設值不要變更 use_gmt_hitset 的預設值「1」。如果與此選項相關的錯誤不是因叢集

設定造成，切勿手動變更此選項。否則，叢集的行為可能變得無法預測。

14.7.2 快取大小調整

快取分層代理程式執行兩項主要功能：

衝洗

代理程式識別已修改的 (髒) 物件，並將其轉遞到儲存池以長期儲存。

逐出

代理程式識別未曾修改的 (乾淨) 物件，並將其中最近用得最少的物件從快取中

逐出。

184 快取大小調整 SES 6

14.7.2.1 絕對大小調整

快取分層代理程式可根據位元組總數或物件總數來衝洗或逐出物件。若要指定最大位元

組數，請執行以下指令：

cephadm@adm > ceph osd pool set cachepool target_max_bytes num_of_bytes

若要指定最大物件數，請執行以下指令：

cephadm@adm > ceph osd pool set cachepool target_max_objects num_of_objects

注意Ceph 無法自動確定快取池的大小，因此需要設定絕對大小。否則，衝洗和逐出

功能將無法正常運作。如果您指定了這兩項限制，則一旦觸發任一閾值，快取分

層代理程式即開始執行衝洗或逐出。

注意僅當達到 target_max_bytes 或 target_max_objects 時，才會阻擋所有用戶端

要求。

14.7.2.2 相對大小調整

快取分層代理程式可以根據快取池的相對大小 (透過第 14.7.2.1 節「絕對大小調

整」中所述的 target_max_bytes 或 target_max_objects 指定) 衝洗或逐出物件。當

快取池中的已修改 (髒) 物件達到特定百分比時，快取分層代理程式會將這些物件衝洗

到儲存池。若要設定 cache_target_dirty_ratio，請執行以下指令：

cephadm@adm > ceph osd pool set cachepool cache_target_dirty_ratio 0.0...1.0

例如，如果將值設定為 0.4，則當已修改 (髒) 物件的大小達到快取池容量的 40%

時，就會開始衝洗這些物件。

cephadm@adm > ceph osd pool set hot-storage cache_target_dirty_ratio 0.4

當髒物件的大小達到容量的特定百分比時，將以更高的速度衝洗。使用

cache_target_dirty_high_ratio：

cephadm@adm > ceph osd pool set cachepool cache_target_dirty_high_ratio 0.0..1.0

185 快取大小調整 SES 6

當快取池的大小達到其容量的特定百分比時，快取分層代理程式會逐出物件，以維持可

用容量。若要設定 cache_target_full_ratio，請執行以下指令：

cephadm@adm > ceph osd pool set cachepool cache_target_full_ratio 0.0..1.0

14.7.3 快取存留期

您可以指定在快取分層代理程式將最近修改過 (改動) 的物件衝洗到後備儲存池之前，

這些物件可存留的最短時間。請注意，此指令僅在快取確實需要衝洗/逐出物件時適

用：

cephadm@adm > ceph osd pool set cachepool cache_min_flush_age num_of_seconds

您可以指定在將某個物件逐出快取層之前，該物件至少可存留的時間：

cephadm@adm > ceph osd pool set cachepool cache_min_evict_age num_of_seconds

14.7.4 範例

14.7.4.1 大型快取池和少量記憶體

如果有大量的儲存，但只有少量的 RAM 可用，則所有物件在被存取後可立即提升到快

取池。命中集保持較小的規模。下面是一組範例組態值：

hit_set_count = 1hit_set_period = 3600hit_set_fpp = 0.05min_write_recency_for_promote = 0min_read_recency_for_promote = 0

14.7.4.2 小型快取池和大量記憶體

如果只有少量的儲存，但可用的記憶體量相對較大，則可以將快取層設定為將有限數量

的物件提升到快取池。如果有 12 個命中集，並且在 14,400 秒期限內可以使用其中每

個命中集，則這些命中集總共可提供 48 小時的追蹤。如果在過去 8 小時內存取了某

個物件，該物件將提升到快取池。這種情況的一組範例組態值如下：

186 快取存留期 SES 6

hit_set_count = 12hit_set_period = 14400hit_set_fpp = 0.01min_write_recency_for_promote = 2min_read_recency_for_promote = 2

187 範例 SES 6

15 使用 LVM 快取提升效能

警告：技術預覽LVM 快取目前為技術預覽功能。

LVM 快取是一種用於提升邏輯磁碟區 (LV) 效能的快取機制。通常會使用較小較快的裝

置來提升較大較慢的 LV 的 I/O 效能。請參閱其手冊頁 ( man 7 lvmcache ) 來瞭解有

關 LVM 快取的更多詳細資料。

在 SUSE Enterprise Storage 中，LVM 快取可提升 OSD 的效能。透過 ceph-volume

外掛程式來提供 LVM 快取支援。您可以執行 ceph-volume lvmcache 來瞭解有關其用

法的詳細資訊。

15.1 先決條件

若要使用 LVM 快取功能來提升 Ceph 叢集的效能，您需要有以下資源：

處於穩定狀態 (「HEALTH_OK」) 的執行中 Ceph 叢集。

已部署 BlueStore 和 LVM 的 OSD。如果使用 SUSE Enterprise Storage 6 或更

新版本部署 OSD，則預設會為 OSD 部署這兩項。

用於快取的空磁碟或分割區。

15.2 需考量的要點

在將 OSD 設定為使用 LVM 快取之前，請注意以下事項：

確認 LVM 快取適合您的使用案例。如果您只有幾個不用於 OSD 的快速磁碟機，

一般建議將它們用做 OSD 的 WAL/DB 裝置。在此情況下，系統會在快速磁碟機上

套用 WAL 和 DB 操作 (較小且很少發生的操作)，而在慢速 OSD 磁碟機上套用資

料操作。

188 先決條件 SES 6

提示如果對您的部署而言，降低延遲比提升 IOPS 或輸送量更重要，則您可將快

速磁碟機用做 LVM 快取而非 WAL/DB 分割區。

如果您計劃將快速磁碟機用做多個 OSD 的 LVM 快取，請注意，所有 OSD 操作

(包括複製) 都將經過快取裝置。所有讀取的查詢操作都將從快取裝置進行，僅當

在快取中未尋找到目標時才會從慢速裝置查詢。寫入一律先套用於快取裝置，稍

後才會衝洗至慢速裝置 (預設的快取模式為「writeback」)。

在決定是否要使用 LVM 快取時，請確認快速磁碟機在充當多個 OSD 的前端的同

時，是否仍能提供可接受的 IOPS 量。您可以透過下面的方法來測試：先測量快

速裝置可提供的最大 IOPS 量，然後將所得結果除以快速裝置後面的 OSD 數量。

如果結果低於或接近 OSD 在不使用快取的情況下可提供的最大 IOPS 量，則 LVM

快取很可能不適用於此設定。

LVM 快取裝置與 OSD 的互動十分重要。系統會定期將寫入從快取裝置衝洗至慢速

裝置。如果內送流量持續進入且數量很大，快取裝置會努力跟上內送要求及衝洗

程序的速度，因而會導致效能下降。除非快速裝置能夠比慢速裝置提供高得多的

IOPS 且延遲更低，否則請勿對持續的大容量工作負載使用 LVM 快取。高載模式

的流量更適合 LVM 快取，因為這種模式會給快取留出衝洗改動資料的時間，且不

會干擾用戶端流量。對於持續的低流量工作負載，很難提前預估使用 LVM 快取是

否能提升效能。最佳測試方法是對照 WAL/DB 設定確定 LVM 快取設定的基準，並

將兩種設定進行比較。此外，由於 WAL 分割區上的較小寫入非常多，建議將快速

裝置用於 DB 和/或 WAL，而非 LVM 快取。

如果您不確定是否應使用 LVM 快取，請將快速裝置用做 WAL 和/或 DB 裝置。

15.3 準備

您需要將快速裝置分割成多個分割區。每個 OSD 需要有兩個快取分割區，一個用於快

取資料，另一個用於快取中繼資料。每個分割區的最小大小為 2 GB。您可以使用單個

快速裝置來快取多個 OSD。只需對其進行相應的磁碟分割即可。

189 準備 SES 6

15.4 設定 LVM 快取

若要瞭解有關新增、移除和設定 LVM 快取的詳細資訊，請執行 ceph-volume lvmcache

指令。

15.4.1 新增 LVM 快取

若要新增 LVM 快取至現有 OSD，請使用以下指令：

cephadm@osd > ceph-volume lvmcache add --cachemetadata METADATA-PARTITION --cachedata DATA-PARTITION --osd-id OSD-ID

選擇性的 --data、 --db 或 --wal 用於指定要快取的分割區。預設為 --data。

提示：指定邏輯磁碟區 (LV)或者，您可以使用 --origin 而非 --osd-id 選項來指定要快取的 LV：

[...]--origin VOLUME-GROUP/LOGICAL-VOLUME

15.4.2 移除 LVM 快取

若要從 OSD 中移除現有 LVM 快取，請使用以下指令：

cephadm@osd > ceph-volume lvmcache rm --osd-id OSD-ID

15.4.3 設定 LVM 快取模式

若要指定快取模式，請使用以下指令：

cephadm@osd > ceph-volume lvmcache mode --set CACHING-MODE --osd-id OSD-ID

CACHING-MODE 為「writeback」(預設值) 或「writethrough」

190 設定 LVM 快取 SES 6

15.5 處理故障

如果快取裝置發生故障，則需要從叢集中移除快取裝置後面的所有 OSD (請參閱第 2.6

節「移除 OSD」)、將它們清除，然後重新部署。如果 OSD 磁碟機發生故障，雖

然 OSD 的 LV 及其快取的 LV 將會處於使用中狀態，但卻無法運作。使用 pvremove

PARTITION 可清除用於 OSD 快取資料和中繼資料分割區的分割區 (實體磁碟區)。您可

以使用 pvs 列出所有實體磁碟區。

15.6 常見問答集

問： 1.如果移除 OSD，會發生什麼情況？

使用 lvremove 移除 OSD 的 LV 時，會一併移除快取 LV。不過，您仍需要在分

割區上呼叫 pvremove，以確定已抹除所有標籤。

問： 2.如果使用 ceph-volume zap 清除 OSD，會發生什麼情況？

此問題的答案與如果移除 OSD，會發生什麼情況？問題的答案相同。

問： 3.如果原始磁碟機出現故障，會發生什麼情況？

快取 LV 仍存在，並且 cache info 仍會將它們顯示為可用狀態。您將無法取消

快取，因為 LVM 會由於原始 LV 的裝置已不存在而無法衝洗快取。現在的情況是

原始 LV 存在，但其後備裝置不存在。您可以透過使用 pvs 指令並找到與原始

LV 相關聯的裝置來修復此問題。然後，便可以使用以下指令將它們移除：

cephadm@osd > sudo pvremove /dev/DEVICE or PARTITION

您可對快取分割區執行相同操作。此程序將會使原始 LV 以及快取 LV 消失。您

也可以使用

cephadm@osd > sudo dd if=/dev/zero of=/dev/DEVICE or PARTITION

將它們抹除，然後再使用 pvremove。

191 處理故障 SES 6

16 Ceph 叢集組態

本章提供重要的 Ceph 叢集設定及其描述清單。設定依主題排序。

16.1 執行時期組態

第 2.13 節「使用自訂設定調整 ceph.conf」介紹如何對 Ceph 組態檔案 ceph.conf

進行變更。但是，實際的叢集行為並不是由 ceph.conf 檔案的目前狀態決定，而是由

執行中 Ceph 精靈的組態 (儲存在記憶體中) 決定。

若要查詢個別 Ceph 精靈以瞭解特定的組態設定，您可以在執行精靈的節點上使用

admin socket。例如，以下指令可從名為 osd.0 的精靈獲取 osd_max_write_size 組

態參數的值：

cephadm@adm > ceph --admin-daemon /var/run/ceph/ceph-osd.0.asok \config get osd_max_write_size{ "osd_max_write_size": "90"}

您還可以在執行時期變更精靈的設定。請注意，此變更是暫時性的，精靈下次重新啟動

時，變更將會遺失。例如，以下指令可針對叢集中的所有 OSD 將 osd_max_write_size

參數變更為「50」：

cephadm@adm > ceph tell osd.* injectargs --osd_max_write_size 50

警告：injectargs 並非百分百可靠有時，使用 injectargs 指令可能無法成功變更叢集設定。如果您需要確保變更

的參數生效，請在叢集所有節點上的組態檔案中進行變更，並重新啟動叢集中的

所有精靈。

192 執行時期組態 SES 6

16.2 Ceph OSD 和 BlueStore

16.2.1 自動調整快取大小

如果 tc_malloc 設定為記憶體配置器並且啟用了 bluestore_cache_autotune 設

定，可將 BlueStore 設定為自動調整其快取大小。目前，此選項預設處於啟用

狀態。BlueStore 會嘗試將 OSD 堆積記憶體使用率維持在 osd_memory_target

組態選項指定的目標大小之下。這是一種最優演算法，而且快取不會縮減到小

於 osd_memory_cache_min 所指定的大小。系統將依據優先程度的階層選擇快

取率。如果無法獲取優先程度資訊，將使用 bluestore_cache_meta_ratio 和

bluestore_cache_kv_ratio 選項做為備選。

bluestore_cache_autotune

在遵循最小值的要求下，自動調整為不同 BlueStore 快取指定的比率。預設值為

True。

osd_memory_target

如果啟用了 tc_malloc 和 bluestore_cache_autotune，該選項將嘗試在記憶體中

對應此數量的位元組。

注意此數量可能與程序的 RSS 記憶體使用率並不完全相符。雖然程序對應的堆

積記憶體總量一般應該保持為接近此目標的數量，但並不能保證核心會真正

收回已取消對應的記憶體。

osd_memory_cache_min

如果啟用了 tc_malloc 和 bluestore_cache_autotune，該選項可設定用於快取的

最小記憶體量。

注意將此值設定得過小可能會導致嚴重的快取猛移。

193 Ceph OSD 和 BlueStore SES 6

16.3 Ceph 物件閘道您可以使用 /etc/ceph/ceph.conf 檔案中以下區段下的幾個選項來控制物件閘道行

為：

[client.radosgw.INSTANCE_NAME]

如果未指定選項，將使用預設值。完整的物件閘道選項清單如下：

16.3.1 一般設定

rgw_frontends

設定 HTTP 前端。請以逗號分隔的清單指定多個前端。每個前端組態可能包含一

組以空格分隔的選項，每個選項的格式均為「鍵=值」或「鍵」。預設為

rgw_frontends = beast port=7480

rgw_data

為物件閘道設定資料檔案的位置。預設值為 /var/lib/ceph/radosgw/CLUSTER_ID。

rgw_enable_apis

啟用指定的 API。預設值為「s3, swift, swift_auth, admin All APIs」。

rgw_cache_enabled

啟用或停用物件閘道快取。預設值為「true」。

rgw_cache_lru_size

物件閘道快取中的項目數。預設值為 10000。

rgw_socket_path

網域通訊端的通訊端路徑。 FastCgiExternalServer 使用此通訊端。如果您未指

定通訊端路徑，物件閘道將不會做為外部伺服器執行。您在此處指定的路徑須與

rgw.conf 檔案中指定的路徑相同。

rgw_fcgi_socket_backlog

fcgi 的通訊端積存資料。預設值為 1024。

rgw_host

物件閘道例項的主機，可以是 IP 位址或主機名稱。預設值為 0.0.0.0

194 Ceph 物件閘道 SES 6

rgw_port

例項用於監聽要求的連接埠號碼。如果未指定，物件閘道將執行外部 FastCGI。

rgw_dns_name

所處理的網域的 DNS 名稱。

rgw_script_uri

如果要求中未設定 SCRIPT_URI，則做為其備用值。

rgw_request_uri

如果要求中未設定 REQUEST_URI，則做為其備用值。

rgw_print_continue

啟用 100-continue (如果可正常運作)。預設值為「true」。

rgw_remote_addr_param

遠端位址參數。例如，包含遠端位址的 HTTP 欄位或 X-Forwarded-For 位址 (如

果反向代理可正常運作)。預設值為 REMOTE_ADDR。

rgw_op_thread_timeout

開啟的線串的逾時 (以秒計)。預設值為 600。

rgw_op_thread_suicide_timeout

物件閘道程序停止前逾時的時間 (以秒計)。如果設定為 0 (預設值)，則表示停

用。

rgw_thread_pool_size

Beast 伺服器的線串數。如果需要處理更多要求，請設定更高的值。預設為 100

個線串。

rgw_num_rados_handles

物件閘道的 RADOS 叢集控制代碼數量。現在，每個物件閘道工作線串都可以選取

一個 RADOS 控制代碼並在其有效期內保留。未來版本中可能會取代並移除此選

項。預設值為 1。

rgw_num_control_oids

不同 rgw 例項之間用於快取同步的通知物件數量。預設值為 8。

rgw_init_timeout

物件閘道放棄啟始化前經過的秒數。預設值為 30。

195 一般設定 SES 6

rgw_mime_types_file

MIME 類型的路徑和位置。用於物件類型的 Swift 自動偵測。預設值為 /etc/

mime.types。

rgw_gc_max_objs

垃圾回收在一個垃圾回收處理週期內可處理的最大物件數量。預設值為 32。

rgw_gc_obj_min_wait

垃圾回收處理可移除和處理物件前需等待的最短時間。預設值為 2 * 3600。

rgw_gc_processor_max_time

兩次連續的垃圾回收處理週期開始時所間隔的最長時間。預設值為 3600。

rgw_gc_processor_period

垃圾回收處理的週期時間。預設值為 3600。

rgw_s3_success_create_obj_status

create-obj 的備用成功狀態回應。預設值為 0。

rgw_resolve_cname

物件閘道是否應使用要求主機名稱欄位的 DNS CNAME 記錄 (如果主機名稱與物件

閘道 DNS 名稱不同)。預設值為「false」。

rgw_obj_stripe_size

物件閘道物件的物件分割大小。預設值為 4 << 20。

rgw_extended_http_attrs

新增可對實體 (例如，使用者、桶或物件) 設定的一組新屬性。使用 POST 方法

放置或修改實體時，可透過 HTTP 標題欄位設定這些額外的屬性。如果設定了這

些屬性，當對實體發出 GET/HEAD 要求時，它們將做為 HTTP 欄位傳回。預設值

為「content_foo, content_bar, x-foo-bar」。

rgw_exit_timeout_secs

無條件結束前等待程序的秒數。預設值為 120。

rgw_get_obj_window_size

單個物件要求的視窗大小 (以位元組計)。預設值為「16 << 20」。

rgw_get_obj_max_req_size

傳送到 Ceph 儲存叢集的單次 GET 操作的要求大小上限。預設值為 4 << 20。


rgw_relaxed_s3_bucket_names

為 US 區域桶啟用寬鬆 S3 桶名稱規則。預設值為「false」。

rgw_list_buckets_max_chunk

列出使用者桶時，在一次操作中擷取的桶數量上限。預設值為 1000。

rgw_override_bucket_index_max_shards

表示桶索引物件的分區數量。設為 0 (預設值) 表示沒有分區。不建議將此值設

定得太大 (例如 1000)，因為這樣會增加列出桶的成本。應在用戶端或全域區段

中設定此變數，以便將其自動套用至 radosgw-admin 指令。

rgw_curl_wait_timeout_ms

某些 curl 呼叫的逾時時間 (以毫秒計)。預設值為 1000。

rgw_copy_obj_progress

啟用在費時較長的複製操作期間輸出物件進度的功能。預設值為「true」。

rgw_copy_obj_progress_every_bytes

兩次複製進度輸出相隔的最小位元組數。預設值為 1024 * 1024。

rgw_admin_entry

管理要求 URL 的進入點。預設值為「admin」。

rgw_content_length_compat

為設定了 CONTENT_LENGTH 和 HTTP_CONTENT_LENGTH 的 FCGI 要求啟用相容性處

理。預設值為「false」。

rgw_bucket_quota_ttl

已快取定額資訊的受信任時長 (以秒計)。經過此逾時時間後，將從叢集重新擷取

定額資訊。預設值為 600。

rgw_user_quota_bucket_sync_interval

同步到叢集前，桶定額資訊的累計時長 (以秒計)。在此期間，其他物件閘道例

項將不會看到與此例項上的操作相關的桶定額統計資料發生的變更。預設值為

180。

rgw_user_quota_sync_interval

同步到叢集前，使用者定額資訊的累計時長 (以秒計)。在此期間，其他物件閘道

例項將不會看到與此例項上的操作相關的使用者定額統計資料發生的變更。預設

值為 180。


rgw_bucket_default_quota_max_objects

每個桶的預設物件數量上限。如果未指定其他定額，此上限將對新使用者設定，

對現有使用者無效。應在用戶端或全域區段中設定此變數，以便將其自動套用至

radosgw-admin 指令。預設值為 -1。

rgw_bucket_default_quota_max_size

每個桶的預設容量上限 (以位元組計)。如果未指定其他定額，此上限將對新使用

者設定，對現有使用者無效。預設值為 -1。

rgw_user_default_quota_max_objects

使用者的預設物件數量上限。這個數量包括該使用者擁有的所有桶中的全部物

件。如果未指定其他定額，此上限將對新使用者設定，對現有使用者無效。預設

值為 -1。

rgw_user_default_quota_max_size

如果未指定其他定額，使用者定額大小上限值 (以位元組計) 將對新使用者設

定，對現有使用者無效。預設值為 -1。

rgw_verify_ssl

發出要求時驗證 SSL 證書。預設值為「true」。

rgw_max_chunk_size

將在單個操作中讀取的最大資料區塊大小。將值增至 4MB (4194304) 可以在處理

大型物件時提高效能。預設值為 128kB (131072)。

多站台設定

rgw_zone

閘道例項所在區域的名稱。如果未設定區域，可使用 radosgw-admin zone

default 指令設定叢集範圍的預設值。

rgw_zonegroup

閘道例項所在區域群組的名稱。如果未設定區域群組，可使用 radosgw-admin

zonegroup default 指令設定叢集範圍的預設值。

rgw_realm

閘道例項所在領域的名稱。如果未設定領域，可使用 radosgw-admin realm

default 指令設定叢集範圍的預設值。

rgw_run_sync_thread


如果領域中有其他要依據其同步的區域，則繁衍線串來處理資料和中繼資料的同

步。預設值為「true」。

rgw_data_log_window

資料記錄項目時段 (以秒計)。預設值為 30。

rgw_data_log_changes_size

要為資料變更記錄儲存的記憶體內項目數。預設值為 1000。

rgw_data_log_obj_prefix

資料記錄的物件名稱字首。預設值為「data_log」。

rgw_data_log_num_shards

儲存資料變更記錄的分區 (物件) 數。預設值為 128。

rgw_md_log_max_shards

中繼資料記錄的分區數量上限。預設值為 64。

SWIFT 設定

rgw_enforce_swift_acls

強制執行 Swift 存取控制清單 (ACL) 設定。預設值為「true」。

rgw_swift_token_expiration

Swift 記號過期時間 (以秒計)。預設值為 24 * 3600。

rgw_swift_url

Ceph Object Gateway Swift API 的 URL。

rgw_swift_url_prefix

Swift StorageURL 中在「/v1」部分前面的 URL 字首。此設定允許在同一主機上

執行多個閘道例項。出於相容性考慮，請將此組態變數設為空白，以便使用預設

值「/swift」。使用明確的字首「/」會在根目錄啟動 StorageURL。

警告如果啟用了 S3 API，將此選項設為「/」將不會運作。請注意，如果停用

S3，將無法在多站台組態中部署物件閘道！

rgw_swift_auth_url


未使用內部 Swift 驗證時，用於驗證 v1 驗證記號的預設 URL。

rgw_swift_auth_entry

Swift 驗證 URL 的進入點。預設值為「auth」。

rgw_swift_versioning_enabled

啟用 OpenStack Object Storage API 的物件版本設定。此選項可讓用戶端對應

當建立版本的容器設定 X-Versions-Location 屬性。該屬性指定儲存已歸檔版本

的容器名稱。出於存取控制驗證 (ACL 不在考慮範圍之內) 的原因，必須由已建

立版本的容器所屬的同一使用者擁有該屬性。無法透過 S3 物件版本設定機制來

為這些容器建立版本。預設值為「false」。

記錄設定

rgw_log_nonexistent_bucket

允許物件閘道記錄針對不存在的桶的要求。預設值為「false」。

rgw_log_object_name

物件名稱的記錄格式。如需格式指定元的詳細資料，請參閱 man 1 date 手冊

頁。預設值為「%Y-%m-%d-%H-%i-%n」。

rgw_log_object_name_utc

記錄的物件名稱是否包含 UTC 時間。如果設定為「false」(預設值)，則會使用

本地時間。

rgw_usage_max_shards

用於使用率記錄的分區數量上限。預設值為 32。

rgw_usage_max_user_shards

用於單個使用者的使用率記錄的分區數量上限。預設值為 1。

rgw_enable_ops_log

啟用記錄每個成功物件閘道操作的功能。預設值為「false」。

rgw_enable_usage_log

啟用使用率記錄。預設值為「false」。

rgw_ops_log_rados

是否應將操作記錄寫入 Ceph 儲存叢集後端。預設值為「true」。


rgw_ops_log_socket_path

用於寫入操作記錄的 Unix 網域通訊端。

rgw_ops_log_data_backlog

寫入 Unix 網域通訊端的操作記錄的資料積存大小上限。預設值為 5 << 20。

rgw_usage_log_flush_threshold

同步衝洗前使用率記錄中已合併的改動項目數量。預設值為 1024。

rgw_usage_log_tick_interval

每隔「n」秒衝洗待處理使用率記錄資料。預設值為 30。

rgw_log_http_headers

要在記錄項目中包含的 HTTP 標題的逗號分隔清單。標題名稱不區

分大小寫，使用完整標題名稱格式，且各單字間以底線分隔。例如

「http_x_forwarded_for」、「http_x_special_k」。

rgw_intent_log_object_name

要記錄的記錄物件名稱的記錄格式。如需格式指定元的詳細資料，請參閱 man 1

date 手冊頁。預設值為「%Y-%m-%d-%i-%n」。

rgw_intent_log_object_name_utc

要記錄的記錄物件名稱是否包含 UTC 時間。如果設定為「false」(預設值)，則

會使用本地時間。

KEYSTONE 設定

rgw_keystone_url

Keystone 伺服器的 URL。

rgw_keystone_api_version

應用於與 Keystone 伺服器通訊的 OpenStack Identity API 的版本 (2 或 3)。

預設值為 2。

rgw_keystone_admin_domain

使用 OpenStack Identity API v3 時，具有管理員權限的 OpenStack 網域名

稱。

rgw_keystone_admin_project


使用 OpenStack Identity API v3 時，具有管理員權限的 OpenStack 專案名

稱。如果未設定，將使用 rgw keystone admin tenant 的值取代。

rgw_keystone_admin_token

Keystone 管理員記號 (共享秘密)。在物件閘道中，使用管理員記號的驗證的優

先程度高於使用管理員身分證明的驗證 (選項 rgw keystone admin user、 rgw

keystone admin password、 rgw keystone admin tenant、 rgw keystone admin

project 和 rgw keystone admin domain )。系統將管理員記號功能視為已取代。

rgw_keystone_admin_tenant

使用 OpenStack Identity API v2 時，具有管理員權限的 OpenStack 租用戶

(服務租用戶) 的名稱。

rgw_keystone_admin_user

使用 OpenStack Identity API v2 時，具有管理員權限的 OpenStack 使用者

(服務使用者) 的名稱。

rgw_keystone_admin_password

使用 OpenStack Identity API v2 時 OpenStack 管理員使用者的密碼。

rgw_keystone_accepted_roles

處理要求需要具有的角色。預設值為「Member, admin」。

rgw_keystone_token_cache_size

每個 Keystone 記號快取中的項目數上限。預設值為 10000。

rgw_keystone_revocation_interval

記號撤銷檢查間隔的時間 (以秒計)。預設值為 15 * 60。

rgw_keystone_verify_ssl

向 Keystone 發出記號要求時，驗證 SSL 證書。預設值為「true」。

16.3.1.1 補充說明

rgw_dns_name

如果將參數 rgw dns name 新增至 ceph.conf，請確定已設定 S3 用戶端，以導

向 rgw dns name 所指定端點的要求。


16.3.2 HTTP 前端

16.3.2.1 Beast

port、ssl_port

IPv4 和 IPv6 監聽連接埠號碼。您可以指定多個連接埠號碼：

port=80 port=8000 ssl_port=8080

預設值為 80。

endpoint、ssl_endpoint

監聽位址採用「位址[:連接埠]」格式，其中，位址為採用點分隔十進位格式的

IPv4 位址字串，或是採用以方括號括住的十六進位標記法表示的 IPv6 位址。指

定將僅監聽 IPv6 的 IPv6 端點。 endpoint 和 ssl_endpoint 的選用連接埠號碼

分別預設為 80 和 443。您可以指定多個位址：

endpoint=[::1] endpoint=192.168.0.100:8000 ssl_endpoint=192.168.0.100:8080

ssl_private_key

此為選擇性設定，指定用於啟用了 SSL 的端點的私密金鑰檔案路徑。如果未指

定，將使用 ssl_certificate 檔案做為私密金鑰。

tcp_nodelay

如果指定該選項，通訊端選項將針對連接停用 Nagle 的演算法。這表示將會儘快

傳送封包，而不會等到發生緩衝區滿載或逾時才傳送。

「1」會對所有通訊端停用 Nagle 的演算法。

「0」會使 Nagle 的演算法保持啟用狀態 (預設值)。

範例 16.1︰ /etc/ceph/ceph.conf 中的範例 BEAST 組態

rgw_frontends = beast port=8000 ssl_port=443 ssl_certificate=/etc/ssl/ssl.crt error_log_file=/var/log/radosgw/civetweb.error.log

16.3.2.2 CivetWeb

port

203 HTTP 前端 SES 6

監聽連接埠號碼。對啟用了 SSL 的連接埠新增「s」尾碼 (例如「443s」)。若

要結合特定 IPv4 或 IPv6 位址，請使用「位址:連接埠」格式。您可以透過使用

「+」聯結多個端點或透過提供多個選項，來指定多個端點：

port=127.0.0.1:8000+443sport=8000 port=443s

預設值為 7480。

num_threads

Civetweb 所繁衍以處理內送 HTTP 連接的線串數。此設定可有效限制前端可處理

的並行連接數。

預設為 rgw_thread_pool_size 選項所指定的值。

request_timeout_ms

Civetweb 在放棄前需等待更多內送資料的時長 (以毫秒計)。

預設值為 30000 毫秒。

access_log_file

存取記錄檔案的路徑。您可以指定完整路徑，或目前工作目錄的相對路徑。如果

未指定 (預設設定)，將不會記錄存取。

error_log_file

錯誤記錄檔案的路徑。您可以指定完整路徑，或目前工作目錄的相對路徑。如果

未指定 (預設設定)，將不會記錄錯誤。

範例 16.2︰ /etc/ceph/ceph.conf 中的範例 CIVETWEB 組態

rgw_frontends = civetweb port=8000+443s request_timeout_ms=30000 error_log_file=/var/log/radosgw/civetweb.error.log

16.3.2.3 通用選項

ssl_certificate

用於啟用了 SSL 的端點的 SSL 證書檔案路徑。

字首

要插入到所有要求的 URI 中的字首字串。例如，僅支援 Swift 的前端可能會提

供一個「/swift」URI 字首。


III 存取叢集資料

17 Ceph 物件閘道 206

18 Ceph iSCSI 閘道 260

19 叢集檔案系統 277

20 透過 Samba 輸出 Ceph 資料 288

21 NFS Ganesha：透過 NFS 輸出 Ceph 資料 303

17 Ceph 物件閘道

本章介紹物件閘道相關管理任務的詳細資料，例如，檢查服務的狀態，管理帳戶、多站

台閘道或 LDAP 驗證。

17.1 物件閘道限制和命名限制

下面列出了物件閘道的一些重要限制：

17.1.1 桶限制

透過 S3 API 存取物件閘道時，桶名稱必須符合 DNS 且允許使用虛線字元「-」。當透

過 Swift API 存取物件閘道時，您可使用支援 UTF-8 的字元 (斜線字元「/」除外)

的任何組合。桶名稱最多可包含 255 個字元。桶名稱必須是唯一的。

提示：使用符合 DNS 的桶名稱雖然透過 Swift API 存取時，可使用任何基於 UTF-8 的桶名稱，但仍建議您根

據 S3 命名限制對桶命名，以免在透過 S3 API 存取同一個桶時發生問題。

17.1.2 儲存的物件的限制

每個使用者的物件數量上限

預設無限制 (大約不超過 2^63)。

每個桶的物件數量上限

預設無限制 (大約不超過 2^63)。

要上傳/儲存的物件的最大大小

單次上傳的上限為 5GB。更大的物件可分為多個部分上傳。多部分區塊的最大數

量為 10000。

206 物件閘道限制和命名限制 SES 6

17.1.3 HTTP 標頭限制

HTTP 標頭和要求限制取決於所使用的 Web 前端。預設 Beast 會將 HTTP 標題大小限

制為 16 kB。

17.2 部署物件閘道建議透過 DeepSea 基礎架構來部署 Ceph 物件閘道，具體做法是新增相關的 role-rgw

[...] 行至 Salt Master 上的 policy.cfg 檔案中，並執行所需的 DeepSea 階段。

若要在 Ceph 叢集部署期間加入物件閘道，請參閱《部署指南》, 第 5 章「使用

DeepSea/Salt 部署」, 第 5.3 節「叢集部署」和《部署指南》, 第 5 章「使用

DeepSea/Salt 部署」, 第 5.5.1 節「policy.cfg 檔案」。

若要新增物件閘道角色至已部署的叢集，請參閱第 2.2 節「新增新的角色至節

點」。

17.3 操作物件閘道服務可使用 systemctl 指令來操作物件閘道服務。您需要擁有 root 特權才能操作物件閘

道服務。請注意， GATEWAY_HOST 是您需要操作其物件閘道例項的伺服器主機名稱。

物件閘道服務支援以下子指令：

systemctl status ceph-radosgw@rgw. GATEWAY_HOST

將服務的狀態資訊列印出來。

systemctl start ceph-radosgw@rgw. GATEWAY_HOST

如果服務尚未執行，則將它啟動。

systemctl restart ceph-radosgw@rgw. GATEWAY_HOST

重新啟動服務。

systemctl stop ceph-radosgw@rgw. GATEWAY_HOST

停止正在執行的服務。

systemctl enable ceph-radosgw@rgw. GATEWAY_HOST

啟用服務，以便在系統啟動時自動啟動該服務。

207 HTTP 標頭限制 SES 6

systemctl disable ceph-radosgw@rgw. GATEWAY_HOST

停用服務，以便在系統啟動時不自動啟動該服務。

17.4 組態選項如需物件閘道組態選項的清單，請參閱第 16.3 節「Ceph 物件閘道」。

17.5 管理物件閘道的存取方式您可以使用與 S3 或 Swift 相容的介面來與物件閘道通訊。S3 介面與大部分 Amazon

S3 RESTful API 都相容。Swift 介面與大部分 OpenStack Swift API 都相容。

這兩個介面都要求您建立特定的使用者，並安裝相關的用戶端軟體，以使用該使用者的

機密金鑰來與閘道通訊。

17.5.1 存取物件閘道

17.5.1.1 S3 介面存取方式

若要存取 S3 介面，您需要有 REST 用戶端。 S3cmd 是一個指令行 S3 用戶端。您

可以在 OpenSUSE Build Service (https://build.opensuse.org/package/show/

Cloud:Tools/s3cmd) 中找到它。該儲存庫包含既適用於 SUSE Linux Enterprise 套

裝作業系統又適用於基於 openSUSE 的套裝作業系統的版本。

如果您想測試自己是否能夠存取 S3 介面，也可以編寫一個簡短的 Python 程序

檔。該程序檔將連接到物件閘道，建立新桶，並列出所有桶。 aws_access_key_id 和

aws_secret_access_key 的值取自第 17.5.2.1 節「新增 S3 和 Swift 使用者」中所

述 radosgw_admin 指令傳回的 access_key 和 secret_key 的值。

1. 安裝 python-boto 套件：

root # zypper in python-boto

2. 建立名為 s3test.py 的新 Python 程序檔，並在其中包含以下內容：

208 組態選項 SES 6

https://build.opensuse.org/package/show/Cloud:Tools/s3cmd

https://build.opensuse.org/package/show/Cloud:Tools/s3cmd

import botoimport boto.s3.connectionaccess_key = '11BS02LGFB6AL6H1ADMW'secret_key = 'vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY'conn = boto.connect_s3(aws_access_key_id = access_key,aws_secret_access_key = secret_key,host = 'HOSTNAME',is_secure=False,calling_format = boto.s3.connection.OrdinaryCallingFormat(),)bucket = conn.create_bucket('my-new-bucket')for bucket in conn.get_all_buckets(): print "NAME\tCREATED".format( name = bucket.name, created = bucket.creation_date, )

請以您在其上設定了物件閘道服務的主機的主機名稱來取代 HOSTNAME，例如

gateway_host。

3. 執行程序檔：

python s3test.py

該程序檔將輸出類似下方內容的資訊：

my-new-bucket 2015-07-22T15:37:42.000Z

17.5.1.2 Swift 介面存取

若要透過 Swift 介面存取物件閘道，需要使用 swift 指令行用戶端。該介面的手冊

頁 man 1 swift 介紹了有關其指令行選項的詳細資訊。

從 SUSE Linux Enterprise 12 SP3 到 SUSE Linux Enterprise 15 的「Public

Cloud」模組中都隨附了該套件。在安裝該套件之前，需要啟動該模組並重新整理軟體

儲存庫：

root # SUSEConnect -p sle-module-public-cloud/12/x86_64sudo zypper refresh

或

root # SUSEConnect -p sle-module-public-cloud/15/x86_64root # zypper refresh

209 存取物件閘道 SES 6

若要安裝 swift 指令，請執行以下指令：

root # zypper in python-swiftclient

使用以下語法進行 swift 存取：

tux > swift -A http://IP_ADDRESS/auth/1.0 \-U example_user:swift -K 'SWIFT_SECRET_KEY' list

請以閘道伺服器的 IP 位址取代 IP_ADDRESS，以在第 17.5.2.1 節「新增 S3 和

Swift 使用者」中針對 swift 使用者執行 radosgw-admin key create 指令所產生輸

出中的相應值取代 SWIFT_SECRET_KEY。

例如：

tux > swift -A http://gateway.example.com/auth/1.0 -U example_user:swift \-K 'r5wWIxjOCeEO7DixD1FjTLmNYIViaC6JVhi3013h' list

輸出為：

my-new-bucket

17.5.2 管理 S3 和 Swift 帳戶

17.5.2.1 新增 S3 和 Swift 使用者

您需要建立使用者、存取金鑰和機密才能讓最終使用者與閘道互動。使用者分兩種類

型：使用者和子使用者。與 S3 介面互動時使用使用者，子使用者是 Swift 介面的使

用者。每個子使用者都與某個使用者相關聯。

也可以透過 DeepSea 檔案 rgw.sls 新增使用者。如需範例，請參閱第 21.3.1 節

「NFS Ganesha 的不同物件閘道使用者」。

若要建立 Swift 使用者，請執行以下步驟：

1. 若要建立 Swift 使用者 (在我們的術語中稱作子使用者)，您需要先建立關聯

的使用者。

cephadm@adm > radosgw-admin user create --uid=USERNAME \ --display-name="DISPLAY-NAME" --email=EMAIL

例如：

210 管理 S3 和 Swift 帳戶 SES 6

cephadm@adm > radosgw-admin user create \ --uid=example_user \ --display-name="Example User" \ [email protected]

2. 若要建立使用者的子使用者 (用於 Swift 介面)，必須指定使用者 ID (--

uid= USERNAME )、子使用者 ID 和該子使用者的存取層級。

cephadm@adm > radosgw-admin subuser create --uid=UID \ --subuser=UID \ --access=[ read | write | readwrite | full ]

例如：

cephadm@adm > radosgw-admin subuser create --uid=example_user \ --subuser=example_user:swift --access=full

3. 為使用者產生機密金鑰。

cephadm@adm > radosgw-admin key create \ --gen-secret \ --subuser=example_user:swift \ --key-type=swift

4. 這兩個指令都會輸出 JSON 格式的資料，其中顯示了使用者狀態。請注意以下幾

行，並記住 secret_key 值：

"swift_keys": [ { "user": "example_user:swift", "secret_key": "r5wWIxjOCeEO7DixD1FjTLmNYIViaC6JVhi3013h"}],

透過 S3 介面存取物件閘道時，需要執行以下指令來建立 S3 使用者：

cephadm@adm > radosgw-admin user create --uid=USERNAME \ --display-name="DISPLAY-NAME" --email=EMAIL

例如：

cephadm@adm > radosgw-admin user create \ --uid=example_user \ --display-name="Example User" \ [email protected]

該指令還會建立使用者的存取金鑰和機密金鑰。檢查該指令輸出中的 access_key 和

secret_key 關鍵字及其值：


[...] "keys": [ { "user": "example_user", "access_key": "11BS02LGFB6AL6H1ADMW", "secret_key": "vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY"}], [...]

17.5.2.2 移除 S3 和 Swift 使用者

刪除 S3 使用者與刪除 Swift 使用者的程序類似。不過，在刪除 Swift 使用者時，您

可能需要同時刪除該使用者及其子使用者。

若要移除 S3 或 Swift 使用者 (包括其所有子使用者)，請在以下指令中指定 user rm

和使用者 ID：

cephadm@adm > radosgw-admin user rm --uid=example_user

若要移除子使用者，請指定 subuser rm 和子使用者 ID。

cephadm@adm > radosgw-admin subuser rm --uid=example_user:swift

您可使用以下選項：

--purge-data

清除與該使用者 ID 關聯的所有資料。

--purge-keys

清除與該使用者 ID 關聯的所有金鑰。

提示：移除子使用者移除某個子使用者時，移除的是其對 Swift 介面的存取權限。該使用者仍會保

留在系統中。

17.5.2.3 變更 S3 和 Swift 使用者的存取金鑰與機密金鑰

存取閘道時， access_key 和 secret_key 參數用於識別物件閘道使用者。變更現有使

用者金鑰的過程與建立新使用者金鑰的過程相同，舊金鑰會被覆寫。

對於 S3 使用者，請執行以下指令：


cephadm@adm > radosgw-admin key create --uid=EXAMPLE_USER --key-type=s3 --gen-access-key --gen-secret

對於 Swift 使用者，請執行以下指令：

cephadm@adm > radosgw-admin key create --subuser=EXAMPLE_USER:swift --key-type=swift --gen-secret

--key-type=TYPE

指定金鑰的類型。值為 swift 或 s3。

--gen-access-key

產生隨機存取金鑰 (預設針對 S3 使用者)。

--gen-secret

產生隨機機密金鑰。

--secret=KEY

指定機密金鑰，例如手動產生的金鑰。

17.5.2.4 使用者定額管理

Ceph 物件閘道允許您針對使用者以及使用者擁有的桶設定定額。定額包括一個桶中的

最大物件數，以及最大儲存大小 (MB)。

在啟用使用者定額之前，需要先設定定額的參數：

cephadm@adm > radosgw-admin quota set --quota-scope=user --uid=EXAMPLE_USER \ --max-objects=1024 --max-size=1024

--max-objects

指定最大物件數。指定負值會停用檢查。

--max-size

指定最大位元組數。指定負值會停用檢查。

--quota-scope

設定定額的範圍。選項包括 bucket 和 user。桶定額將套用到使用者擁有的桶。

使用者定額將套用到使用者。

設定使用者定額後，可啟用該定額：


cephadm@adm > radosgw-admin quota enable --quota-scope=user --uid=EXAMPLE_USER

若要停用定額：

cephadm@adm > radosgw-admin quota disable --quota-scope=user --uid=EXAMPLE_USER

若要列出定額設定：

cephadm@adm > radosgw-admin user info --uid=EXAMPLE_USER

若要更新定額統計資料：

cephadm@adm > radosgw-admin user stats --uid=EXAMPLE_USER --sync-stats

17.6 HTTP 前端Ceph 物件閘道支援兩個內嵌式 HTTP 前端：Beast 和 Civetweb。

Beast 前端使用 Boost.Beast 程式庫處理 HTTP 剖析，使用 Boost.Asio 程式庫處理

非同步網路 I/O。

Civetweb 前端使用 Civetweb HTTP 程式庫，該程式庫屬於 Mongoose 的分支。

您可以在 /etc/ceph/ceph.conf 檔案中使用 rgw_frontends 選項來設定這兩個前端。

如需組態選項的清單，請參閱第 16.3 節「Ceph 物件閘道」。

17.7 為物件閘道啟用 HTTPS/SSL若要讓預設物件閘道角色可使用 SSL 進行安全通訊，您需要擁有 CA 核發的證書，或

建立自行簽署的證書。共有兩種方法可以設定啟用 HTTPS 的物件閘道，使用預設設定

是較簡單的方法，而進階方法則可微調 HTTPS 相關的設定。

17.7.1 建立自行簽署的證書

提示如果您已擁有 CA 簽署的有效證書，請跳過本節。


依預設，DeepSea 預期證書檔案位於 Salt Master 的 /srv/salt/ceph/rgw/cert/

rgw.pem 下。它會將證書分發到具有物件閘道角色的 Salt Minion 的 /etc/ceph/

rgw.pem 下，以便 Ceph 讀取。

以下程序說明如何在 Salt Master 上產生自行簽署的 SSL 證書。

1. 如果您需要透過其他主體身分來識別您的物件閘道，請將這些身分新增至 /etc/

ssl/openssl.cnf 檔案 [v3_req] 區段的 subjectAltName 選項中：

[...][ v3_req ]subjectAltName = DNS:server1.example.com DNS:server2.example.com[...]

提示：subjectAltName 中的 IP 位址若要在 subjectAltName 選項中使用 IP 位址而非網域名稱，請使用下面一

行取代範例行：

subjectAltName = IP:10.0.0.10 IP:10.0.0.11

2. 使用 openssl 建立金鑰和證書。輸入需要包含在證書中的所有資料。建議您輸入

FQDN 做為通用名稱。簽署證書前，確認「X509v3 Subject Alternative Name:」

包含在要求的延伸中，並且產生的證書中設定了「X509v3 Subject Alternative

Name:」。

root@master # openssl req -x509 -nodes -days 1095 \ -newkey rsa:4096 -keyout rgw.key -out /srv/salt/ceph/rgw/cert/rgw.pem

3. 向證書檔案附加金鑰：

root@master # cat rgw.key >> /srv/salt/ceph/rgw/cert/rgw.pem

17.7.2 簡單的 HTTPS 組態

依預設，物件閘道節點上的 Ceph 會讀取 /etc/ceph/rgw.pem 證書，並使用連接埠

443 進行 SSL 安全通訊。如果您不需要變更這些值，請執行以下步驟：

1. 編輯 /srv/pillar/ceph/stack/global.yml，新增下行：

215 簡單的 HTTPS 組態 SES 6

rgw_init: default-ssl

2. 將預設物件閘道 SSL 組態複製到 ceph.conf.d 子目錄：

root@master # cp /srv/salt/ceph/configuration/files/rgw-ssl.conf \ /srv/salt/ceph/configuration/files/ceph.conf.d/rgw.conf

3. 執行 DeepSea 階段 2、3 和 4 以套用這些變更：

root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.3root@master # salt-run state.orch ceph.stage.4

17.7.3 進階 HTTPS 組態

如果您需要變更物件閘道 SSL 設定的預設值，請執行以下步驟：

1. 編輯 /srv/pillar/ceph/stack/global.yml，新增下行：

rgw_init: default-ssl

2. 將預設物件閘道 SSL 組態複製到 ceph.conf.d 子目錄：

root@master # cp /srv/salt/ceph/configuration/files/rgw-ssl.conf \ /srv/salt/ceph/configuration/files/ceph.conf.d/rgw.conf

3. 編輯 /srv/salt/ceph/configuration/files/ceph.conf.d/rgw.conf，變更預設選

項，例如連接埠號碼或 SSL 證書路徑，以反映您的設定。

4. 執行 DeepSea 階段 3 和 4 以套用這些變更：


提示：結合到多個連接埠Beast 伺服器可以結合到多個連接埠。如果您需要使用 SSL 和非 SSL 兩種連接

來存取單個物件閘道例項，這種做法將非常實用。兩個連接埠的組態行如下所

示：

216 進階 HTTPS 組態 SES 6

[client.{{ client }}]rgw_frontends = beast port=80 ssl_port=443 ssl_certificate=/etc/ceph/rgw.pem

17.8 同步模組

使用物件閘道的多站台功能可以建立多個區域，並在這些區域之間鏡像資料和中繼資

料。同步模組建立在多站台架構的基礎上，可將資料和中繼資料轉遞到不同的外部層。

利用同步模組，可讓系統在每當有資料發生變更 (例如執行桶或使用者建立等中繼資料

操作) 時即執行一組動作。當物件閘道多站台變更最終在遠端站台上保持一致時，變更

將以非同步方式傳播。因而很多情況下都適合使用同步模組，例如，將物件儲存備份到

外部雲端叢集、使用磁帶機的自訂備份解決方案，或在 ElasticSearch 中為中繼資料

編制索引。

17.8.1 一般組態

所有同步模組的設定方式都是相似的。您需要建立一個新區域 (請參閱第 17.13 節

「多站台物件閘道」以瞭解更多詳細資料) 並為其設定 --tier_type 選項，例如針對

雲端同步模組設定 --tier-type=cloud：

cephadm@adm > radosgw-admin zone create --rgw-zonegroup=ZONE-GROUP-NAME \ --rgw-zone=ZONE-NAME \ --endpoints=http://endpoint1.example.com,http://endpoint2.example.com, [...] \ --tier-type=cloud

您可以使用以下指令來設定特定層：

cephadm@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \ --rgw-zone=ZONE-NAME \ --tier-config=KEY1=VALUE1,KEY2=VALUE2

組態中的 KEY 指定您希望更新的組態變數， VALUE 指定該變數的新值。使用句點可存

取巢狀的值。例如：

cephadm@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \ --rgw-zone=ZONE-NAME \ --tier-config=connection.access_key=KEY,connection.secret=SECRET

217 同步模組 SES 6

您可以透過附加方括號「[]」及參考的項目來存取相應陣列項目。您可以使用方括號

「[]」來新增新的陣列項目。索引值 -1 參考的是陣列中的最後一個項目。在同一個指

令中無法建立新項目並再次參考該項目。例如，用於為以 PREFIX 開頭的桶建立新設定

檔的指令如下所示：

cephadm@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \ --rgw-zone=ZONE-NAME \ --tier-config=profiles[].source_bucket=PREFIX'*'cephadm@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \ --rgw-zone=ZONE-NAME \ --tier-config=profiles[-1].connection_id=CONNECTION_ID,profiles[-1].acls_id=ACLS_ID

提示：新增和移除組態項目您可以使用 --tier-config-add=KEY=VALUE 參數來新增新的層組態項目。

您可以使用 --tier-config-rm=KEY 移除現有的項目。

17.8.2 同步區域

同步模組組態對於區域而言位於本地。同步模組會確定區域是要輸出資料，還是只

能使用已在另一區域中修改的資料。從 Luminous 版本開始，支援的同步外掛程式有

ElasticSearch、 rgw 和 log，其中 rgw 是在區域之間同步資料的預設同步外掛程

式，log 是記錄遠端區域中發生的中繼資料操作的一般同步外掛程式。以下各節內容包

含了使用 ElasticSearch 同步模組的區域範例。其程序與設定任何其他同步外掛程式

的程序均相似。

注意：預設同步外掛程式rgw 是預設的同步外掛程式，不需要明確設定。

218 同步區域 SES 6

17.8.2.1 要求和假設

我們假設已依照第 17.13 節「多站台物件閘道」中所述建立了一個簡單的多站台組

態，它由 us-east 和 us-west 這兩個區域組成。現在，我們新增第三個區域 us-

east-es，此區域只處理來自其他站台的中繼資料。此區域可與 us-east 位於同一

Ceph 叢集中，也可位於不同的叢集中。此區域只使用來自其他區域的中繼資料，並且

此區域中的物件閘道不會直接處理任何最終使用者要求。

17.8.2.2 設定同步模組

1. 建立類似於第 17.13 節「多站台物件閘道」中所述區域的第三個區域，例如

cephadm@adm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-es \--access-key=SYSTEM-KEY --secret=SECRET --endpoints=http://rgw-es:80

2. 可透過以下指令為此區域設定同步模組

cephadm@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --tier-type=TIER-TYPE \--tier-config={set of key=value pairs}

3. 例如，在 ElasticSearch 同步模組中執行以下指令

cephadm@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --tier-type=elasticsearch \--tier-config=endpoint=http://localhost:9200,num_shards=10,num_replicas=1

如需支援的各個 tier-config 選項，請參閱第 17.8.3 節「ElasticSearch 同

步模組」。

4. 最後，更新期間

cephadm@adm > radosgw-admin period update --commit

5. 現在，在區域中啟動 radosgw

root # systemctl start ceph-radosgw@rgw.`hostname -s`root # systemctl enable ceph-radosgw@rgw.`hostname -s`

219 同步區域 SES 6

17.8.3 ElasticSearch 同步模組

此同步模組會將來自其他區域的中繼資料寫入 ElasticSearch。從 Luminous 版本開

始，這些中繼資料就是我們目前在 ElasticSearch 中所儲存資料欄位的 JSON。

{ "_index" : "rgw-gold-ee5863d6", "_type" : "object", "_id" : "34137443-8592-48d9-8ca7-160255d52ade.34137.1:object1:null", "_score" : 1.0, "_source" : { "bucket" : "testbucket123", "name" : "object1", "instance" : "null", "versioned_epoch" : 0, "owner" : { "id" : "user1", "display_name" : "user1" }, "permissions" : [ "user1" ], "meta" : { "size" : 712354, "mtime" : "2017-05-04T12:54:16.462Z", "etag" : "7ac66c0f148de9519b8bd264312c4d64" } }}

17.8.3.1 ElasticSearch 層類型組態參數

endpoint

指定要存取的 ElasticSearch 伺服器端點。

num_shards

(整數) 資料同步啟始化時將為 ElasticSearch 設定的分區數量。請注意，啟始

化之後將無法變更此數量。在此處進行任何變更都需要重建 ElasticSearch 索

引，並需要重新啟始化資料同步程序。

num_replicas

(整數) 資料同步啟始化時將為 ElasticSearch 設定的複本數量。

explicit_custom_meta

220 ElasticSearch 同步模組 SES 6

(true | false) 指定是否將為所有使用者自訂中繼資料編製索引，或者使用者

是否需要 (在桶層級) 設定應為哪些客戶中繼資料項目編製索引。此參數預設為

false

index_buckets_list

(逗號分隔的字串清單) 如果為空白，將會為所有桶編製索引。否則，將只為

此處指定的桶編製索引。可以提供桶字首 (例如「foo*」) 或桶字尾 (例如

「*bar」)。

approved_owners_list

(逗號分隔的字串清單) 如果為空白，將會為所有擁有者的桶編製索引 (需遵守其

他限制)；否則，將只為指定擁有者擁有的桶編製索引。也可以提供字尾和字首。

override_index_path

(字串) 如果非空白，則此字串將做為 ElasticSearch 索引路徑。否則，將在同

步啟始化時確定並產生索引路徑。

username

指定 ElasticSearch 的使用者名稱 (如果需要驗證)。

password

指定 ElasticSearch 的密碼 (如果需要驗證)。

17.8.3.2 中繼資料查詢

由於 ElasticSearch 叢集現在儲存物件中繼資料，因此務必確定 ElasticSearch 端點

不會向公眾公開，只有叢集管理員可存取它們。向最終使用者自己公開中繼資料查詢會

造成問題，因為我們希望該使用者只查詢自己的中繼資料，而不能查詢任何其他使用者

的中繼資料，這要求 ElasticSearch 叢集如同 RGW 所做的那樣來對使用者進行驗證，

而這就導致了問題發生。

從 Luminous 版本開始，中繼資料主區域中的 RGW 可處理最終使用者要求。這樣就

無需向公眾公開 ElasticSearch 端點，同時也解決了驗證和授權問題，因為 RGW 自

身就能對最終使用者要求進行驗證。出於此目的，RGW 在桶 API 中引入了可處理

ElasticSearch 要求的新查詢。所有這些要求都必須傳送到中繼資料主區域。

獲取 ElasticSearch 查詢

GET /BUCKET?query=QUERY-EXPR


要求參數：

max-keys：要傳回的最大項目數

marker：分頁標記

expression := [(]<arg> <op> <value> [)][<and|or> ...]

運算子為下列其中一項：<、<=、==、>=、>

例如：

GET /?query=name==foo

將傳回使用者有權讀取且編製了索引、名為「foo」的所有鍵。輸出內容將是 XML

格式的鍵清單，與 S3 的「列出桶」要求的回應類似。

設定自訂中繼資料欄位

定義應該 (在指定的桶中) 為哪些自訂中繼資料項目編製索引，以及這些鍵的類

型是什麼。如果設定了明確的自訂中繼資料索引，則需要此定義，以便 rgw 為指

定的自訂中繼資料值編製索引。如果未設定，在已編製索引的中繼資料鍵類型不

是字串的情況下，也需要此定義。

POST /BUCKET?mdsearchx-amz-meta-search: <key [; type]> [, ...]

若中繼資料欄位有多個，則必須使用逗號加以分隔，可以使用分號「;」強制指定

欄位的類型。目前允許的類型有字串 (預設)、整數和日期。例如，如果您想要將

自訂物件中繼資料 x-amz-meta-year 以整數類型編入索引，將 x-amz-meta-date

以日期類型編入索引，並將 x-amz-meta-title 以字串類型編入索引，您需要執

行以下指令：

POST /mybooks?mdsearchx-amz-meta-search: x-amz-meta-year;int, x-amz-meta-release-date;date, x-amz-meta-title;string

刪除自訂中繼資料組態

刪除自訂中繼資料桶組態。

DELETE /BUCKET?mdsearch

獲取自訂中繼資料組態

擷取自訂中繼資料桶組態。

GET /BUCKET?mdsearch


17.8.4 雲端同步模組

本節介紹用於將區域資料同步到遠端雲端服務的模組。該同步是單向的，無法將資料從

遠端區域同步回其本地區域。此模組的主要目的是實現面向多個雲端服務提供者的資料

同步，目前僅支援與 AWS (S3) 相容的雲端提供者。

若要將資料同步到遠端雲端服務，您需要設定使用者身分證明。由於許多雲端服務都對

每個使用者可建立的桶數量設定了限制，因此您可以設定來源物件與桶的對應，以使不

同的目標對應至不同的桶和桶字首。請注意，系統不會保留來源存取清單 (ACL)。可以

將特定來源使用者的許可權對應至特定目的地使用者。

由於 API 存在限制，因此無法保留原始物件修改時間和 HTTP 實體標記 (ETag)。雲端

同步模組會將它們儲存為目的地物件的中繼資料屬性。

17.8.4.1 一般組態

下面提供了一些一般和非一般雲端同步模組組態範例。請注意，一般組態可能會與非一

般組態發生衝突。

範例 17.1︰一般組態

{ "connection": { "access_key": ACCESS, "secret": SECRET, "endpoint": ENDPOINT, "host_style": path | virtual, }, "acls": [ { "type": id | email | uri, "source_id": SOURCE_ID, "dest_id": DEST_ID } ... ], "target_path": TARGET_PATH,}

範例 17.2︰非一般組態

{ "default": { "connection": { "access_key": ACCESS, "secret": SECRET, "endpoint": ENDPOINT, "host_style" path | virtual, }, "acls": [

223 雲端同步模組 SES 6

{ "type": id | email | uri, # optional, default is id "source_id": ID, "dest_id": ID } ... ] "target_path": PATH # optional }, "connections": [ { "connection_id": ID, "access_key": ACCESS, "secret": SECRET, "endpoint": ENDPOINT, "host_style": path | virtual, # optional } ... ], "acl_profiles": [ { "acls_id": ID, # acl mappings "acls": [ { "type": id | email | uri, "source_id": ID, "dest_id": ID } ... ] } ], "profiles": [ { "source_bucket": SOURCE, "connection_id": CONNECTION_ID, "acls_id": MAPPINGS_ID, "target_path": DEST, # optional } ... ],}

下面是對所用組態術語的解釋：

connection

表示與遠端雲端服務的連接。包含「connection_id」、「access_key」、

「secret」、「endpoint」和「host_style」。

access_key

將用於特定連接的遠端雲端存取金鑰。

secret

遠端雲端服務的機密金鑰。

endpoint

遠端雲端服務端點的 URL。


host_style

存取遠端雲端端點時要使用的主機類型 (「path」或「virtual」)。預設值為

「path」。

acls

存取清單對應陣列。

acl_mapping

每個「acl_mapping」結構都包含「type」、「source_id」和「dest_id」。它

們將定義每個物件的 ACL 變動。ACL 變動允許將來源使用者 ID 轉換為目的地

ID。

type

ACL 類型：「id」定義使用者 ID，「email」依電子郵件定義使用者，「uri」依

uri (群組) 定義使用者。

source_id

來源區域中的使用者 ID。

dest_id

目的地中的使用者 ID。

target_path

用於定義目標路徑建立方式的字串。目標路徑指定附加至來源物件名稱的字首。

可對目標路徑進行設定，以使其包含以下任何變數：

SID

表示同步例項 ID 的唯一字串。

ZONEGROUP

區域群組名稱。

ZONEGROUP_ID

區域群組 ID。

ZONE

區域名稱。

ZONE_ID

區域 ID。


BUCKET

來源桶名稱。

OWNER

來源桶擁有者 ID。

例如：target_path = rgwx- ZONE - SID / OWNER / BUCKET

acl_profiles

存取清單設定檔陣列。

acl_profile

每個設定檔均包含代表設定檔的「acls_id」和用於儲存「acl_mappings」清單的

「acls」陣列。

profiles

設定檔清單。每個設定檔均包含以下變數：

source_bucket

用於定義此設定檔來源桶的桶名稱或桶字首 (如果以 * 結尾)。

target_path

請參閱上文的相關解釋。

connection_id

將用於此設定檔的連接 ID。

acls_id

將用於此設定檔的 ACL 設定檔 ID。

17.8.4.2 S3 特定的可設定項

雲端同步模組僅適用於與 AWS S3 相容的後端。該模組提供了一些可設定項，用來調整

它在存取 S3 雲端服務時的行為：

{ "multipart_sync_threshold": OBJECT_SIZE, "multipart_min_part_size": PART_SIZE}

multipart_sync_threshold


針對大小大於或等於此值的物件，將使用多部分上傳來與雲端服務進行同步。

multipart_min_part_size

透過多部分上傳同步物件時所使用的部分大小下限。

17.8.5 歸檔同步模組

歸檔同步模組利用了物件閘道中 S3 物件的版本設定功能。您可以設定一個歸檔區域，

用來擷取其他區域中一段時間內出現的 S3 物件的不同版本。只能透過與歸檔區域關聯

的閘道來刪除歸檔區域保留的版本歷程。

借助這樣的架構，一些沒有建立版本的區域可以透過自身的區域閘道來鏡像它們的資料

和中繼資料，以便向最終使用者提供高可用性，同時，歸檔區域會擷取所有資料更新，

以便將它們合併為 S3 物件的版本。

透過在多區域組態中包含歸檔區域，您可以靈活地在一個區域中保留 S3 物件歷程，同

時能夠節省其餘區域中已建立版本的 S3 物件的複本原本會需要的空間。

17.8.5.1 組態

提示：更多資訊如需設定多站台閘道的詳細資料，請參閱第 17.13 節「多站台物件閘道」。

如需設定同步模組的詳細資料，請參閱第 17.8 節「同步模組」。

若要使用歸檔模組，您需要建立一個新區域，並將其層類型設定為 archive：

cephadm@adm > radosgw-admin zone create --rgw-zonegroup=ZONE_GROUP_NAME \ --rgw-zone=OGW_ZONE_NAME \ --endpoints=http://OGW_ENDPOINT1_URL[,http://OGW_ENDPOINT2_URL,...] --tier-type=archive

17.9 LDAP 驗證除了預設的本地使用者驗證之外，物件閘道還能利用 LDAP 伺服器服務來對使用者進行

驗證。

227 歸檔同步模組 SES 6

17.9.1 驗證機制

物件閘道從記號擷取使用者的 LDAP 身分證明。可以根據使用者名稱建構搜尋過濾器。

物件閘道使用設定的服務帳戶在目錄中搜尋相符項。如果找到了某個項目，物件閘道會

嘗試使用記號中的密碼結合到所找到的可辨識名稱。如果身分證明有效，結合將會成

功，並且物件閘道會授予存取權。

您可以透過將搜尋範圍設定為特定的組織單位，或者指定自訂搜尋過濾器 (例如，要求

特定的群組成員資格、自訂物件類別或屬性)，來限制允許的使用者。

17.9.2 要求

LDAP 或 Active Directory：物件閘道可存取的執行中 LDAP 例項。

服務帳戶：物件閘道要使用且擁有搜尋權限的 LDAP 身分證明。

使用者帳戶：LDAP 目錄中的至少一個使用者帳戶。

重要：LDAP 使用者和本地使用者不能重疊不得對本地使用者以及要使用 LDAP 進行驗證的使用者使用相同的使用者名稱。

物件閘道無法區分兩者，會將它們視為同一個使用者。

提示：健康檢查使用 ldapsearch 公用程式可驗證服務帳戶或 LDAP 連接。例如：

tux > ldapsearch -x -D "uid=ceph,ou=system,dc=example,dc=com" -W \-H ldaps://example.com -b "ou=users,dc=example,dc=com" 'uid=*' dn

請務必在 Ceph 組態檔案中使用相同的 LDAP 參數，以杜絕可能的問題。

17.9.3 將物件閘道設定為使用 LDAP 驗證

/etc/ceph/ceph.conf 組態檔案中的以下參數與 LDAP 驗證相關：

rgw_ldap_uri

228 驗證機制 SES 6

指定要使用的 LDAP 伺服器。請務必使用 ldaps://FQDN:PORT 參數，以免公開傳

輸純文字身分證明。

rgw_ldap_binddn

物件閘道使用的服務帳戶的可辨識名稱 (DN)。

rgw_ldap_secret

服務帳戶的密碼。

rgw_ldap_searchdn

指定在目錄資訊樹狀結構中搜尋使用者的範圍，可以是使用者的組織單位，或某

個更具體的組織單位 (OU)。

rgw_ldap_dnattr

在建構的搜尋過濾器中用來比對某個使用者名稱的屬性。根據所用的目錄資訊樹

狀結構 (DIT)，可能會是 uid 或 cn。

rgw_search_filter

如果未指定，則物件閘道會使用 rgw_ldap_dnattr 設定自動建構搜尋過濾器。

使用此參數能非常靈活地縮小所允許使用者清單的範圍。如需詳細資料，請參

閱第 17.9.4 節「使用自訂搜尋過濾器來限制使用者存取權」。

17.9.4 使用自訂搜尋過濾器來限制使用者存取權

可透過兩種方式使用 rgw_search_filter 參數。

17.9.4.1 用於進一步限制所建構搜尋過濾器的部分過濾器

部分過濾器的範例：

"objectclass=inetorgperson"

物件閘道將照常使用記號中的使用者名稱和 rgw_ldap_dnattr 的值產生搜尋過濾器。

然後，建構的過濾器將與 rgw_search_filter 屬性中的部分過濾器合併。根據所用的

使用者名稱和設定，最終的搜尋過濾器可能會變成：

"(&(uid=hari)(objectclass=inetorgperson))"

229 使用自訂搜尋過濾器來限制使用者存取權 SES 6

在這種情況下，僅當在 LDAP 目錄中找到了使用者「hari」，該使用者具有物件類別

「inetorgperson」並且確實指定了有效密碼時，才向他授予存取權。

17.9.4.2 完整過濾器

完整過濾器必須包含 USERNAME 記號，在嘗試驗證期間，將以使用者名稱取代該記號。

在這種情況下，不再使用 rgw_ldap_dnattr 參數。例如，若要將有效使用者限制為特

定的群組，可使用以下過濾器：

"(&(uid=USERNAME)(memberOf=cn=ceph-users,ou=groups,dc=mycompany,dc=com))"

注意：memberOf 屬性若要在 LDAP 搜尋中使用 memberOf 屬性，您的特定 LDAP 伺服器實作需要提供

伺服器端支援。

17.9.5 產生用於 LDAP 驗證的存取記號

radosgw-token 公用程式根據 LDAP 使用者名稱和密碼產生存取記號。它會輸出

base-64 編碼字串，即實際的存取記號。請使用偏好的 S3 用戶端 (請參閱第 17.5.1

節「存取物件閘道」)，將該記號指定為存取金鑰，並使用空白機密金鑰。

tux > export RGW_ACCESS_KEY_ID="USERNAME"tux > export RGW_SECRET_ACCESS_KEY="PASSWORD"cephadm@adm > radosgw-token --encode --ttype=ldap

重要：純文字身分證明存取記號是一個 base-64 編碼的 JSON 結構，並包含純文字形式的 LDAP 身分

證明。

注意：Active Directory對於 Active Directory，請使用 --ttype=ad 參數。

230 產生用於 LDAP 驗證的存取記號 SES 6

17.10 桶索引分區

物件閘道在索引池中儲存桶索引資料，該池預設為 .rgw.buckets.index。如果將太多

(數十萬個) 物件放入單個桶中，並且不設定每個桶的最大物件數量定額 ( rgw bucket

default quota max objects )，索引池的效能可能會下降。桶索引分區可在允許每個桶

中放入大量物件的同時，防止出現此類效能下降的情況。

17.10.1 桶索引重新分區

如果隨著桶的增大，其初始組態不再能符合需求，則需要對桶的索引池進行重新分

區。您可以使用自動線上桶索引重新分區功能 (請參閱第 17.10.1.1 節「動態重新分

區」)，也可以手動離線執行桶索引重新分區 (請參閱第 17.10.1.2 節「手動重新分

區」)。

17.10.1.1 動態重新分區

從 SUSE Enterprise Storage 5 開始，我們支援線上桶重新分區功能。此功能會偵測

每個桶的物件數量是否達到某個閾值，如果達到該閾值，將會相應地自動增加桶索引使

用的分區數量。此程序會減少每個桶索引分區中的項目數。

該偵測程序在以下情況和環境中執行：

當有新的物件新增至桶中時。

在定期掃描所有桶的背景程序中。掃描的目的是為了處理未在更新的現有桶。

需要重新分區的桶會新增至 reshard_log 佇列，且將排程於稍後進行重新分區。重新

分區線串在背景中執行，並將逐個執行已排程的重新分區。

設定動態重新分區

rgw_dynamic_resharding

啟用或停用動態桶索引重新分區。可用的值為「true」或「false」。預設設為

「true」。

rgw_reshard_num_logs

重新分區記錄的分區數。預設設為 16。

231 桶索引分區 SES 6

rgw_reshard_bucket_lock_duration

重新分區期間將桶物件鎖定的持續時間。預設設為 120 秒。

rgw_max_objs_per_shard

每個桶索引分區的最大物件數。預設設為 100000 個物件。

rgw_reshard_thread_interval

兩輪重新分區線串處理間隔的最長時間。預設設為 600 秒。

重要：多站台組態多站台環境下不支援動態重新分區。從 Ceph 12.2.2 起預設會停用該功能，但

我們建議您再次檢查此設定。

用於管理重新分區程序的指令

將桶新增至重新分區佇列：

cephadm@adm > radosgw-admin reshard add \ --bucket BUCKET_NAME \ --num-shards NEW_NUMBER_OF_SHARDS

列出重新分區佇列：

cephadm@adm > radosgw-admin reshard list

處理/排程桶重新分區：

cephadm@adm > radosgw-admin reshard process

顯示桶重新分區狀態：

cephadm@adm > radosgw-admin reshard status --bucket BUCKET_NAME

取消等待中的桶重新分區：

cephadm@adm > radosgw-admin reshard cancel --bucket BUCKET_NAME

17.10.1.2 手動重新分區

第 17.10.1.1 節「動態重新分區」所述的動態重新分區僅適用於簡單物件閘道組態。

對於多站台組態，請使用本節所述的手動重新分區。

232 桶索引重新分區 SES 6

若要手動對桶索引執行離線重新分區，請使用以下指令：

cephadm@adm > radosgw-admin bucket reshard

bucket reshard 指令執行以下操作：

為指定物件建立一組新的桶索引物件。

分散這些索引物件的所有項目。

建立新的桶例項。

列出新的桶例項以及桶，以便所有新的索引操作都能夠套用到新的桶索引。

將舊的和新的桶 ID 列印到標準輸出。

程序 17.1︰將桶索引池重新分區

1. 確定對桶執行的所有操作都已停止。

2. 備份原始桶索引：

cephadm@adm > radosgw-admin bi list \ --bucket=BUCKET_NAME \ > BUCKET_NAME.list.backup

3. 對桶索引重新分區：

cephadm@adm > radosgw-admin reshard \ --bucket=BUCKET_NAME \ --num-shards=NEW_SHARDS_NUMBER

提示：舊桶 ID此指令還會將新的和舊的桶 ID 列印到其輸出中。請記下舊桶 ID，清除舊

的桶索引物件時需要用到它。

4. 將舊桶索引清單與新桶索引清單進行比較，以驗證列出的物件是否正確。然後，

清除舊的桶索引物件：

cephadm@adm > radosgw-admin bi purge --bucket=BUCKET_NAME --bucket-id=OLD_BUCKET_ID

233 桶索引重新分區 SES 6

17.10.2 新桶的桶索引分區

有兩個選項會影響桶索引分區：

對於簡單組態，請使用 rgw_override_bucket_index_max_shards 選項。

對於多站台組態，請使用 bucket_index_max_shards 選項。

將選項設為 0 將停用桶索引分區。如果將其設為大於 0 的值，則會啟用桶索引分

區，並設定最大分區數。

下面的公式可協助您計算建議的分區數：

number_of_objects_expected_in_a_bucket / 100000

注意，分區的最大數量為 7877。

17.10.2.1 簡單組態

1. 開啟 Ceph 組態檔案，然後新增或修改以下選項：

rgw_override_bucket_index_max_shards = 12

提示：所有或一個物件閘道例項若要為物件閘道的所有例項設定桶索引分區，請在 [global] 區段中包含

rgw_override_bucket_index_max_shards。

若要僅為物件閘道的某個特定例項設定桶索引分區，請在相關例項區段中包

含 rgw_override_bucket_index_max_shards。

2. 重新啟動物件閘道。請參閱第 17.3 節「操作物件閘道服務」，以取得詳細資

料。

17.10.2.2 多站台組態

多站台組態可能會使用另一個索引池來管理容錯移轉。若要為一個區域群組內的區域設

定一致的分區數量，請在該區域群組的組態中設定 bucket_index_max_shards 選項：

234 新桶的桶索引分區 SES 6

1. 將區域群組組態輸出至 zonegroup.json 檔案：

cephadm@adm > radosgw-admin zonegroup get > zonegroup.json

2. 編輯 zonegroup.json 檔案，為每個指定的區域設定 bucket_index_max_shards

選項。

3. 重設區域群組：

cephadm@adm > radosgw-admin zonegroup set < zonegroup.json

4. 更新期間：


17.11 整合 OpenStack KeystoneOpenStack Keystone 是一項用於 OpenStack 產品的身分服務。您可以將物件閘道與

Keystone 相整合，以設定接受 Keystone 驗證記號的閘道。Ceph 物件閘道端將會對

Keystone 授權可存取閘道的使用者進行驗證，並視需要自動建立使用者。物件閘道會

定期查詢 Keystone，以獲取已撤銷記號清單。

17.11.1 設定 OpenStack

設定 Ceph 物件閘道前，需要先設定 OpenStack Keystone 以啟用 Swift 服務，並將

其指向 Ceph 物件閘道：

1. 設定 Swift 服務。若要使用 OpenStack 來驗證 Swift 使用者，請先建立 Swift

服務：

tux > openstack service create \ --name=swift \ --description="Swift Service" \ object-store

2. 設定端點。建立 Swift 服務後，指向 Ceph 物件閘道。以閘道的區域群組名稱或

區域名稱取代 REGION_NAME。

tux > openstack endpoint create --region REGION_NAME \

235 整合 OpenStack Keystone SES 6

--publicurl "http://radosgw.example.com:8080/swift/v1" \ --adminurl "http://radosgw.example.com:8080/swift/v1" \ --internalurl "http://radosgw.example.com:8080/swift/v1" \ swift

3. 驗證設定。建立 Swift 服務並設定端點後，顯示端點以確認所有設定正確無誤。

tux > openstack endpoint show object-store

17.11.2 設定 Ceph 物件閘道

17.11.2.1 設定 SSL 證書

Ceph 物件閘道會定期查詢 Keystone，以獲取已撤銷記號清單。系統會對這些要求加以

編碼並簽署。還可設定 Keystone 以提供自行簽署的記號，這些記號同樣經過編碼和簽

署。您需要設定閘道以便其可以解碼並驗證這些已簽署訊息。因此，需要將 Keystone

用於建立要求的 OpenSSL 證書轉換為「nss db」格式：

root # mkdir /var/ceph/nssroot # openssl x509 -in /etc/keystone/ssl/certs/ca.pem \ -pubkey | certutil -d /var/ceph/nss -A -n ca -t "TCu,Cu,Tuw"rootopenssl x509 -in /etc/keystone/ssl/certs/signing_cert.pem \ -pubkey | certutil -A -d /var/ceph/nss -n signing_cert -t "P,P,P"

為允許 Ceph 物件閘道與 OpenStack Keystone 互動，OpenStack Keystone 可使用

自行簽署的 SSL 證書。可在執行 Ceph 物件閘道的節點上安裝 Keystone 的 SSL 證

書，也可以將選項 rgw keystone verify ssl 的值設為「false」。將 rgw keystone

verify ssl 設為「false」表示閘道將不會嘗試驗證證書。

17.11.2.2 設定物件閘道的選項

您可以使用以下選項設定 Keystone 整合：

rgw keystone api version

Keystone API 的版本。有效選項為 2 或 3。預設設為 2。

rgw keystone url

236 設定 Ceph 物件閘道 SES 6

Keystone 伺服器上管理 RESTful API 的 URL 和連接埠號碼。採用

SERVER_URL:PORT_NUMBER 模式。

rgw keystone admin token

在 Keystone 內部為管理要求設定的記號或共用機密。

rgw keystone accepted roles

處理要求需要具有的角色。預設設為「Member, admin」。

rgw keystone accepted admin roles

允許使用者獲取管理特權的角色清單。

rgw keystone token cache size

Keystone 記號快取中的最大項目數。

rgw keystone revocation interval

檢查已撤銷記號前間隔的秒數。預設設為 15 * 60。

rgw keystone implicit tenants

在各自的同名租用戶中建立新使用者。預設設為「false」。

rgw s3 auth use keystone

如果設為「true」，Ceph 物件閘道將使用 Keystone 對使用者進行驗證。預設設

為「false」。

nss db path

NSS 資料庫的路徑。

還可以設定 Keystone 服務租用戶、Keystone 的使用者和密碼 (適用於 OpenStack

Identity API 2.0 版本)，設定方法與設定 OpenStack 服務的方法類似。使用此方

法可避免在組態檔案中設定共用機密 rgw keystone admin token，生產環境中應停

用該共用機密。服務租用戶身分證明應擁有管理員權限。如需更多詳細資料，請參

閱 OpenStack Keystone 官方文件 (https://docs.openstack.org/keystone/latest/

#setting-up-projects-users-and-roles) 。相關組態選項如下：

rgw keystone admin user

Keystone 管理員使用者名稱。

rgw keystone admin password

237 設定 Ceph 物件閘道 SES 6

https://docs.openstack.org/keystone/latest/#setting-up-projects-users-and-roles

https://docs.openstack.org/keystone/latest/#setting-up-projects-users-and-roles

Keystone 管理員使用者密碼。

rgw keystone admin tenant

Keystone 2.0 版管理員使用者租用戶。

Ceph 物件閘道使用者與 Keystone 租用戶一一對應。系統會為一個 Keystone 使用

者指定不同的角色，這些角色可能分佈在不止一個租用戶上。當 Ceph 物件閘道收到

票證時，會查看為該票證指定的租用戶和使用者角色，並根據 rgw keystone accepted

roles 選項的設定接受或拒絕要求。

提示：對應到 OpenStack 租用戶雖然 Swift 租用戶預設會對應到物件閘道使用者，但也可透過 rgw keystone

implicit tenants 選項將其對應到 OpenStack 租用戶。如此會讓容器使用租用

戶名稱空間，而不是物件閘道預設採用的 S3 之類全域名稱空間。建議在規劃階

段就決定好對應方法，以免產生混淆。這是因為以後切換選項只會影響租用戶下

所對應的較新要求，而先前建立的舊桶仍將繼續放在全域名稱空間中。

對於 OpenStack Identity API 3 版本，您應使用以下選項取代 rgw keystone admin

tenant 選項：

rgw keystone admin domain

Keystone 管理員使用者網域。

rgw keystone admin project

Keystone 管理員使用者專案。

17.12 池放置和儲存類別

17.12.1 放置目標

放置目標用於控制哪些池與特定桶相關聯。桶的放置目標是在建立桶時選取的，無法修

改。您可透過執行以下指令來顯示桶的「placement_rule」：

cephadm@adm > radosgw-admin bucket stats

238 池放置和儲存類別 SES 6

區域群組組態包含一個放置目標清單，其中初始目標名為「default-placement」。

區域組態隨後會將每個區域群組放置目標名稱對應至其本地儲存。此區域放置資

訊包括表示桶索引的「index_pool」名稱、表示不完整多部分上傳相關中繼資料的

「data_extra_pool」名稱，以及表示每個儲存類別的「data_pool」名稱。

17.12.2 儲存類別

儲存類別有助於自訂物件資料的放置。S3 桶生命週期規則可自動轉換物件的儲存類

別。

依據放置目標來定義儲存類別。每個區域群組放置目標會列出它的可用儲存類別，

其中初始類別名為「STANDARD」。區域組態負責為每個區域群組的儲存類別提供

「data_pool」池名稱。

17.12.3 區域群組/區域組態

您可以對區域群組和區域使用 radosgw-admin 指令來設定其放置。可以使用以下指令

來查詢區域群組放置組態：

cephadm@adm > radosgw-admin zonegroup get{ "id": "ab01123f-e0df-4f29-9d71-b44888d67cd5", "name": "default", "api_name": "default", ... "placement_targets": [ { "name": "default-placement", "tags": [], "storage_classes": [ "STANDARD" ] } ], "default_placement": "default-placement", ...}

若要查詢區域放置組態，請執行以下指令：

cephadm@adm > radosgw-admin zone get{ "id": "557cdcee-3aae-4e9e-85c7-2f86f5eddb1f",

239 儲存類別 SES 6

"name": "default", "domain_root": "default.rgw.meta:root", ... "placement_pools": [ { "key": "default-placement", "val": { "index_pool": "default.rgw.buckets.index", "storage_classes": { "STANDARD": { "data_pool": "default.rgw.buckets.data" } }, "data_extra_pool": "default.rgw.buckets.non-ec", "index_type": 0 } } ], ...}

注意：之前未進行多站台組態如果您之前未進行過任何多站台組態，系統將會為您建立「default」區域和

區域群組，並且您必須重新啟動 Ceph 物件閘道，對該區域/區域群組所做的變

更才會生效。如果您已建立過多站台領域，則當您使用 radosgw-admin period

update --commit 指令提交對區域/區域群組的變更後，變更即會生效。

17.12.3.1 新增放置目標

若要建立一個名為「temporary」的新放置目標，首先請將該放置目標新增至區域群

組：

cephadm@adm > radosgw-admin zonegroup placement add \ --rgw-zonegroup default \ --placement-id temporary

然後為該目標提供區域放置資訊：

cephadm@adm > radosgw-admin zone placement add \ --rgw-zone default \ --placement-id temporary \ --data-pool default.rgw.temporary.data \ --index-pool default.rgw.temporary.index \ --data-extra-pool default.rgw.temporary.non-ec

240 區域群組/區域組態 SES 6

17.12.3.2 新增儲存類別

若要新增一個名為「COLD」的新儲存類別至「default-placement」目標，首先請將該

儲存類別新增至區域群組：

cephadm@adm > radosgw-admin zonegroup placement add \ --rgw-zonegroup default \ --placement-id default-placement \ --storage-class COLD

然後為該儲存類別提供區域放置資訊：

cephadm@adm > radosgw-admin zone placement add \ --rgw-zone default \ --placement-id default-placement \ --storage-class COLD \ --data-pool default.rgw.cold.data \ --compression lz4

17.12.4 自訂放置

17.12.4.1 預設放置

新桶預設會使用區域群組的「default_placement」目標。您可以使用以下指令變更此

區域群組設定：

cephadm@adm > radosgw-admin zonegroup placement default \ --rgw-zonegroup default \ --placement-id new-placement

17.12.4.2 使用者放置

Ceph 物件閘道使用者可以透過在使用者資訊中設定非空白「default_placement」欄

位，來覆寫區域群組的預設放置目標。同樣，「default_storage_class」也可以覆寫

預設套用於物件的「STANDARD」儲存類別。

cephadm@adm > radosgw-admin user info --uid testid{ ... "default_placement": "",

241 自訂放置 SES 6

"default_storage_class": "", "placement_tags": [], ...}

如果區域群組的放置目標包含任何標記，則除非使用者資訊的「placement_tags」欄位

中至少包含一個相符的標記，否則使用者將無法建立具有該放置目標的桶。這有助於限

制對某些特定儲存類型的存取。

radosgw-admin 無法直接修改這些欄位，因此您需要手動編輯 JSON 格式：

cephadm@adm > radosgw-admin metadata get user:USER-ID > user.jsontux > vi user.json # edit the file as requiredcephadm@adm > radosgw-admin metadata put user:USER-ID < user.json

17.12.4.3 S3 桶放置

採用 S3 通訊協定建立桶時，可在 LocationConstraint 選項中提供放置目標，以覆寫

使用者和區域群組的預設放置目標。

通常， LocationConstraint 需要與區域群組的 api_name 相符：

<LocationConstraint>default</LocationConstraint>

您可以新增自訂放置目標至 api_name (需在該自訂目標前加上一個冒號)：

<LocationConstraint>default:new-placement</LocationConstraint>

17.12.4.4 Swift 桶放置

採用 Swift 通訊協定建立桶時，您可以在 HTTP 標題的「X-Storage-Policy」中提供

放置目標：

X-Storage-Policy: NEW-PLACEMENT

17.12.5 使用儲存類別

所有放置目標均具有「STANDARD」儲存類別，這是系統預設為新物件套用的儲存類別。

您可以使用物件的「default_storage_class」覆寫此預設值。

242 使用儲存類別 SES 6

若要建立不屬於預設儲存類別的物件，請在要求的 HTTP 標題中提供所需的儲存類別名

稱。S3 通訊協定使用「X-Amz-Storage-Class」標題，而 Swift 通訊協定則使用「X-

Object-Storage-Class」標題。

憑藉 S3 物件生命週期管理，您可以使用「Transition」(轉換) 操作來切換物件資料

的儲存類別。

17.13 多站台物件閘道

區域

一或多個物件閘道例項的邏輯分組。必須將區域群組中的一個區域指定為主區

域，負責處理所有桶和使用者的建立。

區域群組

一個區域群組由多個區域組成。應設定一個將負責處理系統組態變更的主區域群

組。

區域群組地圖

用於存放整個系統地圖的組態結構，例如，哪個區域群組是主區域群組、不同區

域群組之間的關係，以及儲存規則等特定組態選項。

領域

容納區域群組的容器。使用領域可在叢集之間分隔區域群組。可以建立多個領

域，以便在同一叢集中更輕鬆地執行完全不同的組態。

期間

期間存放領域目前狀態的組態結構。每個期間都包含一個唯一的 ID 和一個版本

編號。每個領域都有一個關聯的目前期間，存放區域群組組態的目前狀態和儲存

規則。非主區域發生的任何組態變更都會使期間的版本編號遞增。將主區域變更

為其他區域會觸發以下變更：

產生具有新期間 ID 和版本編號為 1 的新期間。

領域的目前期間會更新，以指向新產生的期間 ID。

領域的版本編號會遞增。

您可將每個物件閘道設定為參與同盟架構，在使用中區域組態中運作，同時允許寫入非

主區域。

243 多站台物件閘道 SES 6

17.13.1 術語

下面解釋了同盟架構特定的術語：

17.13.2 範例叢集設定

本範例重點說明如何建立包含三個不同區域的單個區域群組，這三個區域會主動同步其

資料。其中兩個區域屬於同一叢集，第三個區域屬於其他叢集。在物件閘道之間鏡像資

料變更時，不需要同步代理程式的參與。如此可大大簡化組態規劃和主動/主動組態。

請注意，中繼資料操作 (例如建立新使用者) 仍需要透過主區域處理。但是，資料操作

(例如建立桶和物件) 可由任意區域處理。

17.13.3 系統金鑰

物件閘道需要您在設定區域時建立與 S3 相容的系統使用者，以及他們的存取金鑰和機

密金鑰。這樣，另一個物件閘道例項便可以使用該存取金鑰和機密金鑰從遠端提取組

態。如需建立 S3 使用者的詳細資訊，請參閱第 17.5.2.1 節「新增 S3 和 Swift 使

用者」。

提示在建立區域自身之前產生存取金鑰和機密金鑰的做法非常實用，因為這可以讓稍

後的程序檔編寫和組態管理工具的使用變得更輕鬆。

對於本範例，我們假設已在環境變數中設定存取金鑰和機密金鑰：

# SYSTEM_ACCESS_KEY=1555b35654ad1656d805# SYSTEM_SECRET_KEY=h7GhxuBLTrlhVUyxSPUKUV8r/2EI4ngqJxD7iBdBYLhwluN30JaT3Q==

一般情況下，存取金鑰包含 20 個英數字元，而機密金鑰包含 40 個英數字元 (也可以

包含 +/= 字元)。您可在指令行中產生這些金鑰：

# SYSTEM_ACCESS_KEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 20 | head -n 1)# SYSTEM_SECRET_KEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 40 | head -n 1)

244 術語 SES 6

17.13.4 命名慣例

本範例介紹設定主區域的過程。我們假設有一個名為 us 的區域群組，該區域群組橫

跨美國，將做為我們的主區域群組。此區域群組將包含採用區域群組 -區域格式的兩個區

域。這只是我們一貫採用的格式，您可以選擇偏好的格式。概括如下：

主區域群組：美國： us

主區域：美國東部區域 1： us-east-1

次要區域：美國東部區域 2： us-east-2

次要區域：美國西部區域： us-west

此設定將屬於名為 gold 的較大領域。 us-east-1 和 us-east-2 區域屬於同一個

Ceph 叢集， us-east-1 是主區域。 us-west 在另一個不同的 Ceph 叢集中。

17.13.5 預設池

為物件閘道設定相應的權限後，它便可自行建立預設池。 pg_num 和 pgp_num 值取自

ceph.conf 組態檔案。依預設，與區域相關的池的格式遵循區域名稱 .池名稱約定。以

us-east-1 區域為例，它將建立以下池：

.rgw.rootus-east-1.rgw.controlus-east-1.rgw.data.rootus-east-1.rgw.gcus-east-1.rgw.logus-east-1.rgw.intent-logus-east-1.rgw.usageus-east-1.rgw.users.keysus-east-1.rgw.users.emailus-east-1.rgw.users.swiftus-east-1.rgw.users.uidus-east-1.rgw.buckets.indexus-east-1.rgw.buckets.dataus-east-1.rgw.meta

也可以在其他區域中建立這些池，只需以相應的區域名稱取代 us-east-1。

245 命名慣例 SES 6

17.13.6 建立領域

設定名為 gold 的領域，並將其設為預設領域：

cephadm@adm > radosgw-admin realm create --rgw-realm=gold --default{ "id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "name": "gold", "current_period": "09559832-67a4-4101-8b3f-10dfcd6b2707", "epoch": 1}

請注意，每個領域都有一個 ID，這樣，以後便可靈活地執行所需的操作 (例如，將領

域重新命名)。每當我們變更主區域中的任何設定時， current_period 都會發生變化。

如果主區域的組態有變更，導致目前期間發生變更， epoch 將會遞增。

17.13.7 刪除預設區域群組

採用預設設定安裝物件閘道時會建立名為 default 的預設區域群組。由於我們不再需

要預設區域群組，因此將其移除。

cephadm@adm > radosgw-admin zonegroup delete --rgw-zonegroup=default

17.13.8 建立主區域群組

建立名為 us 的主區域群組。該區域群組將管理區域群組地圖，並將變更傳播到系統

的其餘元件。透過將某個區域群組標示為預設區域群組，可以明確指定要在後續指令中

使用的 rgw-zonegroup 參數。

cephadm@adm > radosgw-admin zonegroup create --rgw-zonegroup=us \--endpoints=http://rgw1:80 --master --default{ "id": "d4018b8d-8c0d-4072-8919-608726fa369e", "name": "us", "api_name": "us", "is_master": "true", "endpoints": [ "http:\/\/rgw1:80" ], "hostnames": [], "hostnames_s3website": [], "master_zone": "",

246 建立領域 SES 6

"zones": [], "placement_targets": [], "default_placement": "", "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"}

或者，可使用以下指令將某個區域群組標示為預設區域群組：

cephadm@adm > radosgw-admin zonegroup default --rgw-zonegroup=us

17.13.9 建立主區域

現在，建立一個預設區域，並將其新增至預設區域群組。請注意，您在執行中繼資料操

作 (例如建立使用者) 時將會用到此區域：

cephadm@adm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-1 \--endpoints=http://rgw1:80 --access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY{ "id": "83859a9a-9901-4f00-aa6d-285c777e10f0", "name": "us-east-1", "domain_root": "us-east-1/gc.rgw.data.root", "control_pool": "us-east-1/gc.rgw.control", "gc_pool": "us-east-1/gc.rgw.gc", "log_pool": "us-east-1/gc.rgw.log", "intent_log_pool": "us-east-1/gc.rgw.intent-log", "usage_log_pool": "us-east-1/gc.rgw.usage", "user_keys_pool": "us-east-1/gc.rgw.users.keys", "user_email_pool": "us-east-1/gc.rgw.users.email", "user_swift_pool": "us-east-1/gc.rgw.users.swift", "user_uid_pool": "us-east-1/gc.rgw.users.uid", "system_key": { "access_key": "1555b35654ad1656d804", "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q==" }, "placement_pools": [ { "key": "default-placement", "val": { "index_pool": "us-east-1/gc.rgw.buckets.index", "data_pool": "us-east-1/gc.rgw.buckets.data", "data_extra_pool": "us-east-1/gc.rgw.buckets.non-ec", "index_type": 0 } } ], "metadata_heap": "us-east-1/gc.rgw.meta", "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"}

247 建立主區域 SES 6

請注意， --rgw-zonegroup 和 --default 參數會將該區域新增至某個區域群組，並將

其設為預設區域。或者，也可以使用以下指令實現相同的目的：

cephadm@adm > radosgw-admin zone default --rgw-zone=us-east-1cephadm@adm > radosgw-admin zonegroup add --rgw-zonegroup=us --rgw-zone=us-east-1

17.13.9.1 建立系統使用者

若要存取區域池，需要建立一個系統使用者。請注意，在設定次要區域時，也需要這些

金鑰。

cephadm@adm > radosgw-admin user create --uid=zone.user \--display-name="Zone User" --access-key=$SYSTEM_ACCESS_KEY \--secret=$SYSTEM_SECRET_KEY --system

17.13.9.2 更新期間

由於您變更了主區域組態，因此需要提交這些變更，使其在領域組態結構中生效。最初

的期間類似下方所示：

cephadm@adm > radosgw-admin period get{ "id": "09559832-67a4-4101-8b3f-10dfcd6b2707", "epoch": 1, "predecessor_uuid": "", "sync_status": [], "period_map": { "id": "09559832-67a4-4101-8b3f-10dfcd6b2707", "zonegroups": [], "short_zone_ids": [] }, "master_zonegroup": "", "master_zone": "", "period_config": { "bucket_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 }, "user_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 } }, "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "realm_name": "gold", "realm_epoch": 1}

更新期間並提交變更：

cephadm@adm > radosgw-admin period update --commit{ "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "epoch": 1, "predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707", "sync_status": [ "[...]"


], "period_map": { "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "zonegroups": [ { "id": "d4018b8d-8c0d-4072-8919-608726fa369e", "name": "us", "api_name": "us", "is_master": "true", "endpoints": [ "http:\/\/rgw1:80" ], "hostnames": [], "hostnames_s3website": [], "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0", "zones": [ { "id": "83859a9a-9901-4f00-aa6d-285c777e10f0", "name": "us-east-1", "endpoints": [ "http:\/\/rgw1:80" ], "log_meta": "true", "log_data": "false", "bucket_index_max_shards": 0, "read_only": "false" } ], "placement_targets": [ { "name": "default-placement", "tags": [] } ], "default_placement": "default-placement", "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7" } ], "short_zone_ids": [ { "key": "83859a9a-9901-4f00-aa6d-285c777e10f0", "val": 630926044 } ] }, "master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e", "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0", "period_config": { "bucket_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1


}, "user_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 } }, "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "realm_name": "gold", "realm_epoch": 2}

17.13.9.3 啟動物件閘道

在啟動物件閘道之前，需要在組態檔案中指定物件閘道區域和連接埠選項。如需物件閘

道及其組態的詳細資訊，請參閱第 17 章「Ceph 物件閘道」。物件閘道的組態區段應

類似下方所示：

[client.rgw.us-east-1]rgw_frontends="beast port=80"rgw_zone=us-east-1

啟動物件閘道：

root # systemctl start [email protected]

17.13.10 建立次要區域

區域群組內的區域會複製所有資料，以確保各區域都具有相同資料。建立次要區域時，

請在指定為次要區域提供服務的主機上執行以下所有操作。

在次要叢集中，建立並設定名為 us-east-2 的次要區域。您可在代管主區域自身的節

點中執行以下所有指令。

若要建立次要區域，請使用建立主區域時所用的相同指令，不過需要去掉 master 旗

標：

cephadm@adm > radosgw-admin zone create --rgw-zonegroup=us --endpoints=http://rgw2:80 \--rgw-zone=us-east-2 --access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY{ "id": "950c1a43-6836-41a2-a161-64777e07e8b8", "name": "us-east-2", "domain_root": "us-east-2.rgw.data.root", "control_pool": "us-east-2.rgw.control", "gc_pool": "us-east-2.rgw.gc",

250 建立次要區域 SES 6

"log_pool": "us-east-2.rgw.log", "intent_log_pool": "us-east-2.rgw.intent-log", "usage_log_pool": "us-east-2.rgw.usage", "user_keys_pool": "us-east-2.rgw.users.keys", "user_email_pool": "us-east-2.rgw.users.email", "user_swift_pool": "us-east-2.rgw.users.swift", "user_uid_pool": "us-east-2.rgw.users.uid", "system_key": { "access_key": "1555b35654ad1656d804", "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q==" }, "placement_pools": [ { "key": "default-placement", "val": { "index_pool": "us-east-2.rgw.buckets.index", "data_pool": "us-east-2.rgw.buckets.data", "data_extra_pool": "us-east-2.rgw.buckets.non-ec", "index_type": 0 } } ], "metadata_heap": "us-east-2.rgw.meta", "realm_id": "815d74c2-80d6-4e63-8cfc-232037f7ff5c"}

17.13.10.1 更新期間

透過執行期間更新並提交變更，通知所有閘道有關系統地圖中發生的新變化：

cephadm@adm > radosgw-admin period update --commit{ "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "epoch": 2, "predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707", "sync_status": [ "[...]" ], "period_map": { "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "zonegroups": [ { "id": "d4018b8d-8c0d-4072-8919-608726fa369e", "name": "us", "api_name": "us", "is_master": "true", "endpoints": [ "http:\/\/rgw1:80" ], "hostnames": [], "hostnames_s3website": [],


"master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0", "zones": [ { "id": "83859a9a-9901-4f00-aa6d-285c777e10f0", "name": "us-east-1", "endpoints": [ "http:\/\/rgw1:80" ], "log_meta": "true", "log_data": "false", "bucket_index_max_shards": 0, "read_only": "false" }, { "id": "950c1a43-6836-41a2-a161-64777e07e8b8", "name": "us-east-2", "endpoints": [ "http:\/\/rgw2:80" ], "log_meta": "false", "log_data": "true", "bucket_index_max_shards": 0, "read_only": "false" }

], "placement_targets": [ { "name": "default-placement", "tags": [] } ], "default_placement": "default-placement", "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7" } ], "short_zone_ids": [ { "key": "83859a9a-9901-4f00-aa6d-285c777e10f0", "val": 630926044 }, { "key": "950c1a43-6836-41a2-a161-64777e07e8b8", "val": 4276257543 }

] }, "master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e", "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0", "period_config": { "bucket_quota": {


"enabled": false, "max_size_kb": -1, "max_objects": -1 }, "user_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 } }, "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "realm_name": "gold", "realm_epoch": 2}

17.13.10.2 啟動物件閘道

調整次要區域的物件閘道組態，並啟動物件閘道：

[client.rgw.us-east-2]rgw_frontends="beast port=80"rgw_zone=us-east-2

cephadm@adm > sudo systemctl start [email protected]

17.13.10.3 更新 Ceph Dashboard 組態

1. 進行以下設定，以依據機密金鑰和存取金鑰變數更新您的多站台儀表板組態：

cephadm@adm > ceph dashboard set-rgw-api-access-key ACCESS-KEYcephadm@adm > ceph dashboard set-rgw-api-secret-key SECRET-KEY

2. 將儀表板預設使用者設定為 admin：

cephadm@adm > ceph dashboard set-rgw-api-user-id admin

3. 停用儀表板，然後將其重新啟用以套用設定。

cephadm@adm > ceph mgr module disable dashboardcephadm@adm > ceph mgr module enable dashboard

4. 如果物件閘道節點發生了變更，或使用了負載平衡器來取代物件閘道，請更新儀

表板：


cephadm@adm > dashboard set-rgw-api-host HOSTcephadm@adm > dashboard set-rgw-api-port PORT

17.13.11 將物件閘道新增至第二個叢集

第二個 Ceph 叢集與初始叢集屬於同一個區域群組，不過可以位於不同的地理位置。

17.13.11.1 預設領域和區域群組

由於您已建立第一個閘道的領域，因此可在此處提取該領域並將其設為預設領域：

cephadm@adm > radosgw-admin realm pull --url=http://rgw1:80 \--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY{ "id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "name": "gold", "current_period": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "epoch": 2}cephadm@adm > radosgw-admin realm default --rgw-realm=gold

透過提取期間，從主區域獲取組態：

cephadm@adm > radosgw-admin period pull --url=http://rgw1:80 \--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY

將已建立的 us 區域群組設為預設區域群組：

cephadm@adm > radosgw-admin zonegroup default --rgw-zonegroup=us

17.13.11.2 次要區域組態

使用相同的系統金鑰建立名為 us-west 的新區域：

cephadm@adm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-west \--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY \--endpoints=http://rgw3:80 --default{ "id": "950c1a43-6836-41a2-a161-64777e07e8b8", "name": "us-west", "domain_root": "us-west.rgw.data.root", "control_pool": "us-west.rgw.control", "gc_pool": "us-west.rgw.gc",

254 將物件閘道新增至第二個叢集 SES 6

"log_pool": "us-west.rgw.log", "intent_log_pool": "us-west.rgw.intent-log", "usage_log_pool": "us-west.rgw.usage", "user_keys_pool": "us-west.rgw.users.keys", "user_email_pool": "us-west.rgw.users.email", "user_swift_pool": "us-west.rgw.users.swift", "user_uid_pool": "us-west.rgw.users.uid", "system_key": { "access_key": "1555b35654ad1656d804", "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q==" }, "placement_pools": [ { "key": "default-placement", "val": { "index_pool": "us-west.rgw.buckets.index", "data_pool": "us-west.rgw.buckets.data", "data_extra_pool": "us-west.rgw.buckets.non-ec", "index_type": 0 } } ], "metadata_heap": "us-west.rgw.meta", "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"}

17.13.11.3 更新期間

為了傳播區域群組地圖變更，我們將更新並提交期間：

cephadm@adm > radosgw-admin period update --commit --rgw-zone=us-west{ "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "epoch": 3, "predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707", "sync_status": [ "", # truncated ], "period_map": { "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "zonegroups": [ { "id": "d4018b8d-8c0d-4072-8919-608726fa369e", "name": "us", "api_name": "us", "is_master": "true", "endpoints": [ "http:\/\/rgw1:80" ], "hostnames": [],


"hostnames_s3website": [], "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0", "zones": [ { "id": "83859a9a-9901-4f00-aa6d-285c777e10f0", "name": "us-east-1", "endpoints": [ "http:\/\/rgw1:80" ], "log_meta": "true", "log_data": "true", "bucket_index_max_shards": 0, "read_only": "false" }, { "id": "950c1a43-6836-41a2-a161-64777e07e8b8", "name": "us-east-2", "endpoints": [ "http:\/\/rgw2:80" ], "log_meta": "false", "log_data": "true", "bucket_index_max_shards": 0, "read_only": "false" }, { "id": "d9522067-cb7b-4129-8751-591e45815b16", "name": "us-west", "endpoints": [ "http:\/\/rgw3:80" ], "log_meta": "false", "log_data": "true", "bucket_index_max_shards": 0, "read_only": "false" } ], "placement_targets": [ { "name": "default-placement", "tags": [] } ], "default_placement": "default-placement", "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7" } ], "short_zone_ids": [ { "key": "83859a9a-9901-4f00-aa6d-285c777e10f0", "val": 630926044 },


{ "key": "950c1a43-6836-41a2-a161-64777e07e8b8", "val": 4276257543 }, { "key": "d9522067-cb7b-4129-8751-591e45815b16", "val": 329470157 } ] }, "master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e", "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0", "period_config": { "bucket_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 }, "user_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 } }, "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "realm_name": "gold", "realm_epoch": 2}

請注意，期間的版本編號已遞增，表示組態發生了變更。

17.13.11.4 啟動物件閘道

此操作與在第一個區域中啟動物件閘道類似。唯一的差別在於，物件閘道區域組態應反

映 us-west 區域名稱：

[client.rgw.us-west]rgw_frontends="beast port=80"rgw_zone=us-west

啟動第二個物件閘道：


17.13.12 容錯移轉和災難備援

如果主區域發生故障，將容錯移轉至次要區域，以實現災難備援。

257 容錯移轉和災難備援 SES 6

1. 將次要區域設為主區域和預設區域。例如：

cephadm@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --default

依預設，Ceph 物件閘道將以主動/主動組態執行。如果已將叢集設定為以主動/被

動組態執行，則次要區域是唯讀區域。移除 --read-only 狀態可讓區域接收寫入

操作。例如：

cephadm@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --default \--read-only=False

2. 更新期間，以使變更生效。


3. 最後，重新啟動 Ceph 物件閘道。

root # systemctl restart ceph-radosgw@rgw.`hostname -s`

如果之前的主區域已復原，請還原操作。

1. 在已復原的區域中，從目前主區域提取期間。

cephadm@adm > radosgw-admin period pull --url=URL-TO-MASTER-ZONE-GATEWAY \--access-key=ACCESS-KEY --secret=SECRET

2. 將已復原的區域設為主區域和預設區域。

cephadm@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --default



4. 然後，在已復原的區域中重新啟動 Ceph 物件閘道。


5. 如果次要區域需要採用唯讀組態，請更新次要區域。

cephadm@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --read-only


258 容錯移轉和災難備援 SES 6


7. 最後，在次要區域中重新啟動 Ceph 物件閘道。


17.14 使用 HAProxy 在物件閘道伺服器間實現

負載平衡

您可以使用 HAProxy 負載平衡器將所有要求分發在多個物件閘道後端伺服器之間。

如需設定 HAProxy 的詳細資訊，請參閱https://www.suse.com/documentation/sle-

ha-15/book_sleha_guide/data/sec_ha_lb_haproxy.html 。

下面是一種 HAProxy 的簡單組態，使用遞迴平衡演算法來平衡物件閘道節點：

tux > cat /etc/haproxy/haproxy.cfg[...]frontend HTTPS_FRONTENDbind *:443 crt path-to-cert.pem [ciphers: ... ]default_backend rgw

backend rgwmode httpbalance roundrobinserver rgw_server1 RGW-ENDPOINT1 weight 1 maxconn 100 checkserver rgw_server2 RGW-ENDPOINT2 weight 1 maxconn 100 check[...]

259 使用 HAProxy 在物件閘道伺服器間實現負載平衡 SES 6

https://www.suse.com/documentation/sle-ha-15/book_sleha_guide/data/sec_ha_lb_haproxy.html

https://www.suse.com/documentation/sle-ha-15/book_sleha_guide/data/sec_ha_lb_haproxy.html

18 Ceph iSCSI 閘道

本章重點介紹與 iSCSI 閘道相關的管理任務。如需部署程序，請參閱《部署指南》,

第 10 章「安裝 iSCSI 閘道」。

18.1 連接 ceph-iscsi 管理的目標

本節介紹如何從執行 Linux、Microsoft Windows 或 VMware 的用戶端連接至 ceph-

iscsi 管理的目標。

18.1.1 Linux (open-iscsi)

使用 open-iscsi 連接 ceph-iscsi 支援的 iSCSI 目標需要執行兩個步驟。首先，啟

動器必須探查閘道主機上可用的 iSCSI 目標，然後必須登入並對應可用的邏輯單位

(LU)。

這兩個步驟都需要 open-iscsi 精靈處於執行狀態。啟動 open-iscsi 精靈的方式取決

於您的 Linux 套裝作業系統：

在 SUSE Linux Enterprise Server (SLES) 和 Red Hat Enterprise Linux

(RHEL) 主機上，執行 systemctl start iscsid (如果 systemctl 不可用，請執

行 service iscsid start )。

在 Debian 和 Ubuntu 主機上，執行 systemctl start open-iscsi (或 service

open-iscsi start )。

如果啟動器主機執行 SUSE Linux Enterprise Server，請參閱

https://www.suse.com/documentation/sles-15/book_storage/data/

sec_iscsi_initiator.html 以瞭解有關如何連接至 iSCSI 目標的詳細資料。

對於支援 open-iscsi 的任何其他 Linux 套裝作業系統，請繼續探查 ceph-iscsi 閘

道上的目標 (本範例使用 iscsi1.example.com 做為入口網站位址；對於多重路徑存

取，請使用 iscsi2.example.com 重複這些步驟)：

root # iscsiadm -m discovery -t sendtargets -p iscsi1.example.com192.168.124.104:3260,1 iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol

260 連接 ceph-iscsi 管理的目標 SES 6

https://www.suse.com/documentation/sles-15/book_storage/data/sec_iscsi_initiator.html

https://www.suse.com/documentation/sles-15/book_storage/data/sec_iscsi_initiator.html

然後登入該入口網站。如果登入成功完成，則入口網站中所有受 RBD 支援的邏輯單位

將立即在系統 SCSI 匯流排上變為可用：

root # iscsiadm -m node -p iscsi1.example.com --loginLogging in to [iface: default, target: iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol, portal: 192.168.124.104,3260] (multiple)Login to [iface: default, target: iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol, portal: 192.168.124.104,3260] successful.

針對其他入口網站 IP 位址或主機重複此過程。

如果系統上已安裝 lsscsi 公用程式，您可以使用它來列舉系統上可用的 SCSI 裝置：

lsscsi[8:0:0:0] disk SUSE RBD 4.0 /dev/sde[9:0:0:0] disk SUSE RBD 4.0 /dev/sdf

在多重路徑組態 (其中兩個已連接的 iSCSI 裝置代表一個相同的 LU) 中，您還可以使

用 multipath 公用程式檢查多重路徑裝置狀態：

root # multipath -ll360014050cf9dcfcb2603933ac3298dca dm-9 SUSE,RBDsize=49G features='0' hwhandler='0' wp=rw|-+- policy='service-time 0' prio=1 status=active| `- 8:0:0:0 sde 8:64 active ready running`-+- policy='service-time 0' prio=1 status=enabled`- 9:0:0:0 sdf 8:80 active ready running

現在，您可視需要將此多重路徑裝置當成任何區塊裝置使用。例如，可將該裝置當成

Linux 邏輯磁碟區管理 (LVM) 的實體磁碟區使用，或者直接在該裝置上建立檔案系

統。下面的範例說明如何在新連接的多重路徑 iSCSI 磁碟區上建立 XFS 檔案系統：

root # mkfs -t xfs /dev/mapper/360014050cf9dcfcb2603933ac3298dcalog stripe unit (4194304 bytes) is too large (maximum is 256KiB)log stripe unit adjusted to 32KiBmeta-data=/dev/mapper/360014050cf9dcfcb2603933ac3298dca isize=256 agcount=17, agsize=799744 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0data = bsize=4096 blocks=12800000, imaxpct=25 = sunit=1024 swidth=1024 blksnaming =version 2 bsize=4096 ascii-ci=0 ftype=0log =internal log bsize=4096 blocks=6256, version=2 = sectsz=512 sunit=8 blks, lazy-count=1realtime =none extsz=4096 blocks=0, rtextents=0

請注意，由於 XFS 是非叢集檔案系統，無論何時，您都只能將它掛接到單個 iSCSI 啟

動器節點上。

261 Linux (open-iscsi) SES 6

任何時候若要停止使用與特定目標關聯的 iSCSI LU，請執行以下指令：

root # iscsiadm -m node -p iscsi1.example.com --logoutLogging out of session [sid: 18, iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol, portal: 192.168.124.104,3260]Logout of [sid: 18, target: iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol, portal: 192.168.124.104,3260] successful.

與執行探查和登入時一樣，必須針對所有入口網站 IP 位址或主機名稱重複登出步驟。

18.1.1.1 多重路徑組態

多重路徑組態保留在用戶端或啟動器上，並不相依於任何 ceph-iscsi 組態。在使用區

塊儲存之前，請選取一項策略。編輯 /etc/multipath.conf 之後，請使用以下指令重

新啟動 multipathd

root # systemctl restart multipathd

對於包含易記名稱的主動/被動組態，請將

defaults { user_friendly_names yes}

新增至 /etc/multipath.conf。成功連接目標後，請執行

root # multipath -llmpathd (36001405dbb561b2b5e439f0aed2f8e1e) dm-0 SUSE,RBDsize=2.0G features='0' hwhandler='0' wp=rw|-+- policy='service-time 0' prio=1 status=active| `- 2:0:0:3 sdl 8:176 active ready running|-+- policy='service-time 0' prio=1 status=enabled| `- 3:0:0:3 sdj 8:144 active ready running`-+- policy='service-time 0' prio=1 status=enabled `- 4:0:0:3 sdk 8:160 active ready running

注意每個連結的狀態。對於主動/主動組態，請將

defaults { user_friendly_names yes}

devices { device {

262 Linux (open-iscsi) SES 6

vendor "(LIO-ORG|SUSE)" product "RBD" path_grouping_policy "multibus" path_checker "tur" features "0" hardware_handler "1 alua" prio "alua" failback "immediate" rr_weight "uniform" no_path_retry 12 rr_min_io 100 }}

新增至 /etc/multipath.conf。重新啟動 multipathd 並執行

root # multipath -llmpathd (36001405dbb561b2b5e439f0aed2f8e1e) dm-3 SUSE,RBDsize=2.0G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw`-+- policy='service-time 0' prio=50 status=active |- 4:0:0:3 sdj 8:144 active ready running |- 3:0:0:3 sdk 8:160 active ready running `- 2:0:0:3 sdl 8:176 active ready running

18.1.2 Microsoft Windows (Microsoft iSCSI 啟動器)

若要從 Windows 2012 伺服器連接 SUSE Enterprise Storage iSCSI 目標，請執行以

下步驟：

1. 開啟 Windows 伺服器管理員。在儀表板中，選取 Tools (工具) iSCSI

Initiator (iSCSI 啟動器)。iSCSI Initiator Properties (iSCSI 啟動器內容)

對話方塊隨即顯示。選取 Discovery (探查) 索引標籤：

263 Microsoft Windows (Microsoft iSCSI 啟動器) SES 6

圖形 18.1︰ ISCSI 啟動器內容

2. 在 Discover Target Portal (探查目標入口網站) 對話方塊中的 Target (目標)

欄位內，輸入目標的主機名稱或 IP 位址，然後按一下 OK (確定)：


圖形 18.2︰探查目標入口網站

3. 針對所有其他閘道主機名稱或 IP 位址重複此過程。完成後，查看 Target

Portals (目標入口網站) 清單：


圖形 18.3︰目標入口網站

4. 接下來，切換到 Targets (目標) 索引標籤並查看已探查的目標。


圖形 18.4︰目標

5. 在 Targets (目標) 索引標籤中按一下 Connect (連接)。Connect To Target

(連接至目標) 對話方塊隨即顯示。選取 Enable Multi-path (啟用多重路徑) 核

取方塊以啟用多重路徑 I/O (MPIO)，然後按一下 OK (確定)：

6. Connect to Target (連接至目標) 對話方塊關閉後，選取 Properties (內容)

以查看目標的內容：


圖形 18.5︰ ISCSI 目標內容

7. 選取 Devices (裝置)，然後按一下 MPIO 以查看多重路徑 I/O 組態：


圖形 18.6︰裝置詳細資料

預設的負載平衡規則為 Round Robin With Subset (以子集循環配置資源)。如果

您偏好單純的容錯移轉組態，請將規則變更為 Fail Over Only (僅容錯移轉)。

iSCSI 啟動器的組態設定到此結束。現在，可以像使用任何其他 SCSI 裝置一樣使用

iSCSI 磁碟區，並可將其啟始化，使其可當成磁碟區和磁碟機使用。按一下 OK (確定)

以關閉 iSCSI Initiator Properties (iSCSI 啟動器內容) 對話方塊，然後繼續在

Server Manager (伺服器管理員) 儀表板中設定 File and Storage Services (檔案和

存放服務) 角色。

觀察新連接的磁碟區。該磁碟區識別為 iSCSI 匯流排上的 SUSE RBD SCSI 多重路徑磁

碟機，並且最初標示為離線狀態，其分割區表類型為未知。如果新磁碟區未立即顯示，

請從 Tasks (任務) 下拉式方塊中選取 Rescan Storage (重新掃描儲存)，以重新掃描

iSCSI 匯流排。


1. 以滑鼠右鍵按一下 iSCSI 磁碟區，然後從快顯功能表中選取 New Volume (新

磁碟區)。New Volume Wizard (新磁碟區精靈) 隨即顯示。按一下 Next (下一

步)，反白新連接的 iSCSI 磁碟區，然後按一下 Next (下一步) 開始建立新磁碟

區。

圖形 18.7︰新磁碟區精靈

2. 該裝置最初是空的，不包含任何分割區表。當出現對話方塊指出將要使用 GPT 分

割區表啟始化磁碟區時，確認該操作：

圖形 18.8︰離線磁碟提示

3. 選取磁碟區大小。使用者一般會使用裝置的全部容量。然後，指定新建立磁碟區

將在其上變為可用狀態的磁碟機代號或目錄名稱。接下來，選取要在新磁碟區上

建立的檔案系統。最後，按一下 Create (建立) 以確認所做的選擇並完成磁碟區

的建立：


圖形 18.9︰確認選取的磁碟區設定

完成該過程後，請檢查結果，然後按一下 Close (關閉) 以結束磁碟機啟始化。

完成啟始化後，便可以像使用新啟始化的本地磁碟機一般使用該磁碟區 (及其

NTFS 檔案系統)。

18.1.3 VMware

1. 若要連接至 ceph-iscsi 管理的 iSCSI 磁碟區，需要有設定好的 iSCSI 軟體

介面卡。如果 vSphere 組態中未提供此類介面卡，請選取 Configuration (組

態) Storage Adapters (儲存介面卡) Add (新增) iSCSI Software initiator

(iSCSI 軟體啟動器) 來建立一個介面卡。

2. 如果適用，請以滑鼠右鍵按一下該介面卡並從快顯功能表中選取 Properties (內

容)，來選取該介面卡的內容：

271 VMware SES 6

圖形 18.10︰ ISCSI 啟動器內容

3. 在 iSCSI Software Initiator (iSCSI 軟體啟動器) 對話方塊中，按一下

Configure (設定) 按鈕。然後移至 Dynamic Discovery (動態探查) 索引標籤並

選取 Add (新增)。

4. 輸入 ceph-iscsi iSCSI 閘道的 IP 位址或主機名稱。如果您在容錯移轉組態中

執行多個 iSCSI 閘道，請針對要操作的所有閘道重複此步驟。

272 VMware SES 6

圖形 18.11︰新增目標伺服器

輸入所有 iSCSI 閘道後，請在對話方塊中按一下 OK (確定)，以發起對 iSCSI

介面卡的重新掃描。

5. 重新掃描完成後，新的 iSCSI 裝置會顯示在 Details (詳細資料) 窗格中的

Storage Adapters (儲存介面卡) 清單下。對於多重路徑裝置，您現在可以在

該介面卡上按一下滑鼠右鍵，然後從快顯功能表中選取 Manage Paths (管理路

徑)：

273 VMware SES 6

圖形 18.12︰管理多重路徑裝置

您現在應該會看到，所有路徑的 Status (狀態) 下面都帶有綠燈。其中一個路徑

應該已標示為 Active (I/O) (使用中 (I/O))，其他所有路徑只是標示為 Active

(使用中)：

圖形 18.13︰多重路徑的路徑清單

6. 現在，您可以從 Storage Adapters (儲存介面卡) 切換到標為 Storage (儲

存) 的項目。在窗格右上角選取 Add Storage... (新增儲存...)，以開啟 Add

Storage (新增儲存) 對話方塊。然後選取 Disk/LUN (磁碟/LUN) 並按一下 Next

(下一步)。新增的 iSCSI 裝置會顯示在 Select Disk/LUN (選取磁碟/LUN) 清單

中。選取該裝置，然後按一下 Next (下一步) 繼續：

274 VMware SES 6

圖形 18.14︰「ADD STORAGE」(新增儲存) 對話方塊

按一下 Next (下一步) 以接受預設的磁碟配置。

7. 在 Properties (內容) 窗格中，為新資料儲存指定名稱，然後按一下 Next (下

一步)。接受將磁碟區的整個空間用於資料儲存的預設設定，或者選取 Custom

Space Setting (自訂空間設定) 以建立較小的資料儲存：

圖形 18.15︰自訂空間設定

275 VMware SES 6

按一下 Finish (完成) 以完成資料儲存的建立。

新資料儲存現在即會顯示在資料儲存清單中，您可以選取它來擷取詳細資料。現

在，您可以如同使用任何其他 vSphere 資料儲存一般使用 ceph-iscsi 支援的

iSCSI 磁碟區。

圖形 18.16︰ ISCSI 資料儲存綜覽

18.2 結論

ceph-iscsi 是 SUSE Enterprise Storage 6 的一個關鍵元件，使用它可以從任何支援

iSCSI 通訊協定的伺服器或用戶端存取高度可用的分散式區塊儲存。在一或多個 iSCSI

閘道主機上使用 ceph-iscsi，可將 Ceph RBD 影像當成與 iSCSI 目標關聯的邏輯單位

(LU) 使用，並可視需要以負載平衡且高度可用的方式來存取該邏輯單位。

由於系統將所有 ceph-iscsi 組態都儲存在 Ceph RADOS 物件儲存中， ceph-iscsi 閘

道主機先天就不具有持久性狀態，因而可以任意對其進行取代或者增減。因此，憑藉

SUSE Enterprise Storage 6，SUSE 客戶可在商用硬體和完全開放原始碼的平台上執行

真正的分散式、高度可用、有復原能力且可自我修復的企業儲存技術。

276 結論 SES 6

19 叢集檔案系統

本章介紹通常應在完成叢集設定與輸出 CephFS 後執行的管理任務。如需有關設定

CephFS 的詳細資訊，請參閱《部署指南》, 第 11 章「安裝 CephFS」。

19.1 掛接 CephFS建立檔案系統後，如果 MDS 處於使用中狀態，您便可以從用戶端主機掛接檔案系統。

19.1.1 用戶端準備

如果用戶端主機執行的是 SUSE Linux Enterprise 12 SP2 或 SP3，您可以跳過本節，

因為系統無需額外設定即可掛接 CephFS。

如果用戶端主機執行的是 SUSE Linux Enterprise 12 SP1，您需要套用所有最新的修

補程式，才能掛接 CephFS。

無論是哪一種情況，SUSE Linux Enterprise 中都包含了掛接 CephFS 需要的所有項

目。不需要 SUSE Enterprise Storage 6 產品。

為了支援完整的 mount 語法，在嘗試掛接 CephFS 之前，應該先安裝 ceph-common 套

件 (於 SUSE Linux Enterprise 中隨附)。

19.1.2 建立機密檔案

Ceph 叢集執行時預設會開啟驗證功能。您應該建立一個可用於儲存您的機密金鑰 (不

是金鑰圈自身) 的檔案。請執行以下操作，以獲取特定使用者的機密金鑰並建立該檔

案：

程序 19.1︰建立機密金鑰

1. 在金鑰圈檔案中檢視特定使用者的金鑰：

cephadm@adm > cat /etc/ceph/ceph.client.admin.keyring

2. 複製要使用所掛接 Ceph FS 檔案系統的使用者的金鑰。金鑰的格式通常類似下方

所示：

277 掛接 CephFS SES 6

AQCj2YpRiAe6CxAA7/ETt7Hcl9IyxyYciVs47w==

3. 為使用者 admin 建立一個檔案名稱包含使用者名稱的檔案，例如 /etc/ceph/

admin.secret。

4. 將金鑰值貼至上一步中建立的檔案中。

5. 設定對該檔案的適當存取權限。該使用者應該是唯一有權讀取該檔案的使用者，

其他人不能有任何存取權限。

19.1.3 掛接 CephFS

可以使用 mount 指令掛接 CephFS。您需要指定監控程式的主機名稱或 IP 位址。由

於 SUSE Enterprise Storage 中預設會啟用 cephx 驗證，因此，您還需要指定一個

使用者名稱及其相關的機密：

root # mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \ -o name=admin,secret=AQATSKdNGBnwLhAAnNDKnH65FmVKpXZJVasUeQ==

由於上一個指令會保留在外圍程序歷程中，因此更安全的做法是從檔案讀取機密：

root # mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \ -o name=admin,secretfile=/etc/ceph/admin.secret

請注意，機密檔案應該僅包含實際的金鑰圈機密。因此，在本範例中，該檔案僅包含下

行：

AQATSKdNGBnwLhAAnNDKnH65FmVKpXZJVasUeQ==

提示：指定多個監控程式最好能在 mount 指令行中指定多個監控程式並以逗號分隔，以避免某個監控程

式在掛接時剛好發生停機的情況。每個監控程式的位址採用主機[:連接埠] 格式。

如果未指定連接埠，預設會使用連接埠 6789。

在本地主機上建立掛接點：

root # mkdir /mnt/cephfs

278 掛接 CephFS SES 6

掛接 CephFS：

root # mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \ -o name=admin,secretfile=/etc/ceph/admin.secret

如果要掛接檔案系統的某個子集，可以指定子目錄 subdir：

root # mount -t ceph ceph_mon1:6789:/subdir /mnt/cephfs \ -o name=admin,secretfile=/etc/ceph/admin.secret

可在 mount 指令中指定多個監控程式主機：

root # mount -t ceph ceph_mon1,ceph_mon2,ceph_mon3:6789:/ /mnt/cephfs \ -o name=admin,secretfile=/etc/ceph/admin.secret

重要：對根目錄的讀取存取權如果使用實施了路徑限制的用戶端，則 MDS 功能需要包含對根目錄的讀取存取

權。例如，金鑰圈的格式可能如下所示：

client.bar key: supersecretkey caps: [mds] allow rw path=/barjail, allow r path=/ caps: [mon] allow r caps: [osd] allow rwx

allow r path=/ 部分表示路徑受限的用戶端能夠查看根磁碟區，但無法寫入資料

至其中。在要求完全隔離的使用情況下，這可能會造成問題。

19.2 卸載 CephFS若要卸載 CephFS，請使用 umount 指令：

root # umount /mnt/cephfs

19.3 /etc/fstab 中的 CephFS

若要在用戶端啟動時自動掛接 CephFS，請在其檔案系統表 /etc/fstab 中插入相應的

行：

279 卸載 CephFS SES 6

mon1:6790,mon2:/subdir /mnt/cephfs ceph name=admin,secretfile=/etc/ceph/secret.key,noatime,_netdev 0 2

19.4 多個使用中 MDS 精靈 (主動/主動 MDS)依預設，CephFS 是針對單個使用中 MDS 精靈設定的。若要調整大規模系統的中繼資料

效能，您可以啟用多個使用中 MDS 精靈，以便互相分擔中繼資料工作負載。

19.4.1 何時使用主動/主動 MDS

如果依預設設定使用單個 MDS 時中繼資料效能出現瓶頸，可考慮使用多個使用中 MDS

精靈。

增加精靈數量並不會提高所有工作負載類型的效能。例如，增加 MDS 精靈的數量不會

讓單個用戶端上執行的單個應用程式受益，除非該應用程式在同時執行大量中繼資料操

作。

一般而言，能夠因大量使用中 MDS 精靈受益的工作負載是使用許多用戶端的工作負

載，也許是在許多獨立目錄中運作的工作負載。

19.4.2 增加 MDS 使用中叢集的大小

每個 CephFS 檔案系統都有一項 max_mds 設定，用於控制將要建立的階層數。僅當某

個備用精靈可用於承擔新階層時，檔案系統中的實際階層數才會增加。例如，如果只有

執行一個 MDS 精靈，而 max_mds 設定為兩個，則將不會建立另一個階層。

在下面的範例中，我們將 max_mds 選項設定為 2，以便在保留預設階層的情況下再建

立一個新階層。若要查看變更，請在設定 max_mds 之前和之後執行 ceph status，然

後觀察包含 fsmap 的行：

cephadm@adm > ceph status [...] services: [...] mds: cephfs-1/1/1 up {0=node2=up:active}, 1 up:standby [...]cephadm@adm > ceph mds set max_mds 2cephadm@adm > ceph status

280 多個使用中 MDS 精靈 (主動/主動 MDS) SES 6

[...] services: [...] mds: cephfs-2/2/2 up {0=node2=up:active,1=node1=up:active} [...]

新建立的階層 (1) 會經歷「正在建立」狀態，然後進入「使用中」狀態。

重要：待命精靈即使具有多個使用中 MDS 精靈，當任何在執行使用中精靈的伺服器發生故障

時，高可用性系統也仍會要求待命精靈接管工作。

因此，高可用性系統的 max_mds 合理最大值比系統中的 MDS 伺服器總數小 1。

若要在發生多次伺服器故障時保持可用性，可增加系統中待命精靈的數量，使之

與不會導致失去可用性的伺服器故障數相符。

19.4.3 減小階層數

所有階層 (包括要移除的階層) 首先必須是使用中的。這表示至少需要有 max_mds 個

MDS 精靈可用。

首先，將 max_mds 設為一個較小的數字。例如，我們重新使用單個使用中 MDS：

cephadm@adm > ceph status [...] services: [...] mds: cephfs-2/2/2 up {0=node2=up:active,1=node1=up:active} [...]cephadm@adm > ceph mds set max_mds 1cephadm@adm > ceph status [...] services: [...] mds: cephfs-1/1/1 up {0=node2=up:active}, 1 up:standby [...]

請注意，我們仍有兩個使用中 MDS。即使減小 max_mds，階層也仍會存在，因為

max_mds 只會限制新階層的建立。

接下來，使用 ceph mds deactivate rank 指令移除不需要的階層：

cephadm@adm > ceph status

281 減小階層數 SES 6

[...] services: [...] mds: cephfs-2/2/1 up {0=node2=up:active,1=node1=up:active}cephadm@adm > ceph mds deactivate 1telling mds.1:1 192.168.58.101:6805/2799214375 to deactivate

cephadm@adm > ceph status [...] services: [...] mds: cephfs-2/2/1 up {0=node2=up:active,1=node1=up:stopping}

cephadm@adm > ceph status [...] services: [...] mds: cephfs-1/1/1 up {0=node2=up:active}, 1 up:standby

已停用的階層首先會進入「正在停止」狀態並會保持一段時間，期間它會將所分擔的中

繼資料負載轉移給其餘使用中精靈。此階段可能需要數秒到數分鐘時間。如果 MDS 看

起來像停在「正在停止」狀態，則應該調查原因，以判斷是否有可能存在錯誤。

如果一個 MDS 精靈在「正在停止」狀態下當機或終止，待命精靈會接管工作，階層將

恢復到「使用中」狀態。當此精靈重新啟動後，您可以嘗試再次將它停用。

精靈結束「正在停止」狀態後，將再次啟動，並重新變為待命精靈。

19.4.4 手動將目錄樹關聯到層級

在多個使用中中繼資料伺服器組態中，將會執行一個平衡器，用於在叢集中均衡分配中

繼資料負載。這種模式通常足以符合大多數使用者的需求，但有時，使用者需要使用中

繼資料到特定階層的明確對應來覆寫動態平衡器。這樣，管理員或使用者便可以在整個

叢集上均衡地分攤應用程式負載，或限制使用者的中繼資料要求對整個叢集的影響。

針對此目的提供的機制稱為「輸出關聯」。它是目錄的延伸屬性。此延伸屬性名為

ceph.dir.pin。使用者可以使用標準指令來設定此屬性：

root # setfattr -n ceph.dir.pin -v 2 /path/to/dir

延伸屬性的值 ( -v ) 是要將目錄子樹指定到的階層。預設值 -1 表示不關聯該目錄。

目錄輸出關聯從設定了輸出關聯的最近的父級繼承。因此，對某個目錄設定輸出關聯會

影響該目錄的所有子項。但是，可以透過設定子目錄輸出關聯來覆寫父級的關聯。例

如：

282 手動將目錄樹關聯到層級 SES 6

root # mkdir -p a/b # "a" and "a/b" start with no export pin set.setfattr -n ceph.dir.pin -v 1 a/ # "a" and "b" are now pinned to rank 1.setfattr -n ceph.dir.pin -v 0 a/b # "a/b" is now pinned to rank 0 # and "a/" and the rest of its children # are still pinned to rank 1.

19.5 管理容錯移轉如果 MDS 精靈停止與監控程式通訊，監控程式會等待 mds_beacon_grace 秒 (預設為

15 秒)，然後將精靈標示為 laggy。可以設定一或多個「待命」精靈，用於在 MDS 精

靈容錯移轉期間接管工作。

19.5.1 設定待命精靈

有多項組態設定可控制精靈處於待命狀態時的行為。您可以在執行 MDS 精靈的主機上

的 ceph.conf 中指定這些設定。精靈在啟動時會載入這些設定，然後將其傳送至監控

程式。

依預設，如果不使用其中的任何設定，則不具備階層的所有 MDS 精靈將會做為任一階

層的「待命」精靈。

將待命精靈與特定名稱或階層加以關聯的設定不保證該精靈只用於該階層。具體而言，

當有多個待命精靈可用時，將使用關聯的待命精靈。如果某個階層發生故障，而此時有

某個待命精靈可用，則即使該精靈與其他某個階層或指定的精靈相關聯，也會使用該精

靈。

mds_standby_replay

如果設定為 true，則待命精靈將持續讀取某個已啟動階層的中繼資料記錄。這就

為此階層提供了一個熱中繼資料快取，當為該階層提供服務的精靈發生故障時，

此記錄可加快容錯移轉程序的速度。

一個已啟動的階層只能指定一個待命重放精靈。如果將兩個精靈都設定為待命重

放，則其中任意一個會贏得控制權，另一個將成為正常的非重放待命精靈。

當某個精靈進入待命重放狀態時，它只會做為所跟隨階層的待命精靈。如果另一

個階層發生故障，系統不會使用此待命重放精靈來取代前者，即使沒有其他可用

的待命精靈也是如此。

mds_standby_for_name

283 管理容錯移轉 SES 6

如果指定此設定，則僅當最後一個具備故障階層的精靈與此名稱相符時，待命精

靈才會接管該故障階層。

mds_standby_for_rank

如果指定此設定，待命精靈只會接管指定的階層。如果另外的階層發生故障，將

不會使用此精靈來取代此階層。

與 mds_standby_for_fscid 結合使用時，可以指定在使用多個檔案系統時，具體

針對哪個檔案系統的階層。

mds_standby_for_fscid

如果設定了 mds_standby_for_rank，則 mds_standby_for_fscid 只是一個用於指

出所指檔案系統階層的修飾詞。

如果未設定 mds_standby_for_rank，則設定 FSCID 會導致此精靈以指定 FSCID

中的任何階層為目標。如果您希望只在特定的檔案系統中將某個精靈用於任何階

層，可使用此設定。

mon_force_standby_active

在監控程式主機上使用此設定。其預設值為 true。

如果值為 false，則 standby_replay 設定為 true 的精靈只有在其已設定要跟

隨的階層/名稱發生故障時，才會變為使用中精靈。另一方面，如果此設定為

true，則可將其他某個階層指定給 standby_replay 設定為 true 的精靈。

19.5.2 範例

下面顯示了多個範例 ceph.conf 組態。您可將包含所有精靈的組態的 ceph.conf 複製

到所有伺服器，或者在每部伺服器上建立一個不同的檔案，並在其中包含該伺服器的精

靈組態。

19.5.2.1 簡單配對

「a」和「b」兩個 MDS 精靈充當一對。其中，目前未指定階層的精靈將是另一個精靈

的待命重放跟隨者。

[mds.a]mds standby replay = truemds standby for rank = 0

284 範例 SES 6

[mds.b]mds standby replay = truemds standby for rank = 0

19.6 設定 CephFS 定額

您可以對 Ceph 檔案系統的任何子目錄設定定額。定額可限制目錄階層中指定點下所儲

存的位元組或檔案數。

19.6.1 限制

CephFS 的定額設定具有以下限制：

定額是合作性而非競爭性的。

達到限制時，Ceph 定額依賴於掛接檔案系統的用戶端來停止向其寫入資料。伺

服器端無法阻止惡意用戶端寫入所需數量的資料。在用戶端完全不受信任的環境

中，請勿使用定額來阻止填入檔案系統。

定額並不精確。

在達到定額限制不久後，系統便會停止向檔案系統寫入資料的程序。這樣便會不

可避免地允許這些程序在超出設定的限制後又寫入一定數量的資料。系統將會在

超出所設定限制後的十分之一秒內停止用戶端寫入程序。

自 4.17 版本起，即在核心用戶端中實作了定額。

定額受使用者空間用戶端 (libcephfs、ceph-fuse) 支援。4.17 及更新版本的

Linux 核心用戶端支援 SUSE Enterprise Storage 6 叢集上的 CephFS 定額。核

心用戶端 (甚至最近的版本) 無法處理較舊叢集的定額，即使它們可以設定定額

延伸屬性也是如此。

與基於路徑的掛接限制配合使用時，需謹慎設定定額。

用戶端需要有權存取設定了定額的目錄 Inode，才能強制執行這些定額。如果依

據 MDS 功能，用戶端對特定路徑 (例如 /home/user ) 的存取受到限制，並且對

其無權存取的上階目錄 ( /home ) 設定了定額，則用戶端將無法強制執行該定額。

在使用基於路徑的存取限制時，請務必對用戶端可以存取的目錄 (例如 /home/

user 或 /home/user/quota_dir) 設定定額。

285 設定 CephFS 定額 SES 6

19.6.2 組態

您可以使用虛擬延伸屬性來設定 CephFS 定額：

ceph.quota.max_files

設定檔案限制。

ceph.quota.max_bytes

設定位元組限制。

如果某個目錄 Inode 存在這些屬性，即表示對該位置設定了定額。如果不存在，則表

示未對該目錄設定定額 (即使可能對父目錄設定了定額)。

若要設定 100 MB 的定額，請執行以下指令：

cephadm@mds > setfattr -n ceph.quota.max_bytes -v 100000000 /SOME/DIRECTORY

若要設定 10,000 個檔案的定額，請執行以下指令：

cephadm@mds > setfattr -n ceph.quota.max_files -v 10000 /SOME/DIRECTORY

若要檢視定額設定，請執行以下指令：

cephadm@mds > getfattr -n ceph.quota.max_bytes /SOME/DIRECTORY

cephadm@mds > getfattr -n ceph.quota.max_files /SOME/DIRECTORY

注意：未設定定額如果延伸屬性的值為「0」，則表示未設定定額。

若要移除定額，請執行以下指令：

cephadm@mds > setfattr -n ceph.quota.max_bytes -v 0 /SOME/DIRECTORYcephadm@mds > setfattr -n ceph.quota.max_files -v 0 /SOME/DIRECTORY

19.7 管理 CephFS 快照在建立 CephFS 快照時，快照會建立此時間點檔案系統的唯讀檢視。您可以在任何目錄

中建立快照。快照將涵蓋檔案系統中指定目錄下的所有資料。建立快照後，系統會從各

用戶端非同步衝洗緩衝區資料。因此，建立快照的速度十分快。

286 組態 SES 6

重要：多個檔案系統如果您有多個 CephFS 檔案系統在共用一個池 (透過名稱空間)，則這些檔案系

統的快照將會發生衝突，並且刪除其中一個快照將會導致共用同一個池的其他快

照遺失檔案資料。

19.7.1 建立快照

對於新檔案系統，系統預設會啟用 CephFS 快照功能。若要對現有檔案系統啟用該功

能，請執行以下指令：

cephadm@adm > ceph fs set CEPHFS_NAME allow_new_snaps true

啟用快照後，CephFS 中的所有目錄都將包含一個特殊的 .snap 子目錄。

CephFS 核心用戶端有一個限制：它們無法處理一個目錄樹狀結構中所含快照數量超過

400 個的情況。快照的數量應永遠低於此上限，無論使用哪個用戶端均如此。如果使用

較舊的 CephFS 用戶端 (例如 SLE12-SP3)，請記住，快照數量超過 400 個對運作十分

有害，因為這會導致用戶端當機。

提示：自訂快照子目錄名稱您可以透過進行 client snapdir 設定來為快照子目錄設定其他名稱。

若要建立快照，請以自訂名稱在 .snap 目錄下建立子目錄。例如，若要建立目錄

/CEPHFS_MOUNT/2/3/ 的快照，請執行以下指令：

tux > mkdir /CEPHFS_MOUNT/2/3/.snap/CUSTOM_SNAPSHOT_NAME

19.7.2 刪除快照

若要刪除某個快照，請在 .snap 目錄中刪除該快照的子目錄：

tux > rmdir /CEPHFS_MOUNT/2/3/.snap/CUSTOM_SNAPSHOT_NAME

287 建立快照 SES 6

20 透過 Samba 輸出 Ceph 資料

本章介紹如何透過 Samba/CIFS 共用輸出 Ceph 叢集中儲存的資料，以便您可從

Windows* 用戶端機器輕鬆存取這些資料。另外還介紹了有助於您將 Ceph Samba 閘道

設定為加入到 Windows* 網域中的 Active Directory，以進行使用者驗證和授權的資

訊。

注意：Samba 閘道效能由於用戶端與儲存區之間的額外網路躍程會導致通訊協定負擔增加並產生額外的

延遲，因此與使用原生 Ceph 用戶端相比，透過 Samba 閘道存取 CephFS 可能

會使應用程式效能大幅降低。

20.1 透過 Samba 共用輸出 CephFS

警告：跨通訊協定存取原生 CephFS 和 NFS 用戶端不受透過 Samba 獲取的檔案鎖定限制，反之亦然。

如果透過其他方式存取 CephFS 支援的 Samba 共用路徑，則依賴跨通訊協定檔

案鎖定的應用程式可能會出現資料損毀。

20.1.1 Samba 相關的套件安裝

若要設定和輸出 Samba 共用，需要安裝以下套件： samba-ceph 和 samba-winbind。

若尚未安裝這些套件，請執行以下指令進行安裝：

cephadm@smb > zypper install samba-ceph samba-winbind

20.1.2 單一閘道範例

在輸出 Samba 共用的準備過程中，需要選擇用於充當 Samba 閘道的合適節點。該節點

必須能存取 Ceph 用戶端網路，同時要有足夠的 CPU、記憶體和網路資源。

288 透過 Samba 共用輸出 CephFS SES 6

您可以透過 CTDB 和 SUSE Linux Enterprise High Availability Extension 提供容

錯移轉功能。如需 HA 設定的詳細資訊，請參閱第 20.1.3 節「高可用性組態」。

1. 請確定叢集中已存在一個正常運作的 CephFS。如需詳細資料，請參閱《部署指

南》, 第 11 章「安裝 CephFS」。

2. 在 Ceph 管理節點上建立一個特定於 Samba 閘道的金鑰圈，並將其複製到 Samba

閘道節點：

cephadm@adm > ceph auth get-or-create client.samba.gw mon 'allow r' \ osd 'allow *' mds 'allow *' -o ceph.client.samba.gw.keyringroot@master # scp ceph.client.samba.gw.keyring SAMBA_NODE:/etc/ceph/

使用 Samba 閘道節點的名稱取代 SAMBA_NODE。

3. 在 Samba 閘道節點上執行以下步驟。將 Samba 連同 Ceph 整合套件一併安裝：

cephadm@smb > sudo zypper in samba samba-ceph

4. 使用以下內容取代 /etc/samba/smb.conf 檔案的預設內容：

[global] netbios name = SAMBA-GW clustering = no idmap config * : backend = tdb2 passdb backend = tdbsam # disable print server load printers = no smbd: backgroundqueue = no

[SHARE_NAME] path = / vfs objects = ceph ceph: config_file = /etc/ceph/ceph.conf ceph: user_id = samba.gw read only = no oplocks = no kernel share modes = no

提示：Oplocks 和共用模式oplocks (也稱為 SMB2+ 租用) 可透過加速用戶端快取來提升效能，不

過如果將其他 CephFS 用戶端 (例如核心 mount.cephfs、FUSE 或 NFS

Ganesha) 與 Samba 一併部署，該機制目前並不安全。

289 單一閘道範例 SES 6

如果由 Samba 專門處理所有 CephFS 檔案系統路徑存取，則可安全啟用

oplocks 參數。

目前，在使用 CephFS vfs 模組執行的共用中，需要停用 kernel share

modes，檔案處理才能正常運作。

重要：允許存取由於 vfs_ceph 不需要檔案系統掛接，共用路徑會解譯為所連接 Ceph 叢集

上 Ceph 檔案系統中的絕對路徑。若要實現成功的共用 I/O，路徑的存取控

制清單 (ACL) 需要允許給定 Samba 用戶端的對應使用者進行存取。您可以

透過 CephFS 核心用戶端暫時掛接，並對共用路徑使用 chmod、 chown 或

setfacl 公用程式來修改 ACL。例如，若要允許所有使用者進行存取，請執

行以下指令：

root # chmod 777 MOUNTED_SHARE_PATH

5. 啟動並啟用 Samba 精靈：

cephadm@smb > sudo systemctl start smb.servicecephadm@smb > sudo systemctl enable smb.servicecephadm@smb > sudo systemctl start nmb.servicecephadm@smb > sudo systemctl enable nmb.service

20.1.3 高可用性組態

重要：不支援透明容錯移轉儘管多節點 Samba + CTDB 部署比單節點部署的高可用性更佳 (請參閱第 20 章

「透過 Samba 輸出 Ceph 資料」)，但它並不支援用戶端透明容錯移轉。應用程

式可能會在 Samba 閘道節點發生故障時出現短暫的中斷。

本節提供一個範例來展示如何設定 Samba 伺服器的雙節點高可用性組態。該設定需要

SUSE Linux Enterprise High Availability Extension。兩個節點分別名為 earth

( 192.168.1.1 ) 和 mars ( 192.168.1.2 )。

290 高可用性組態 SES 6

如需 SUSE Linux Enterprise High Availability Extension 的詳細資料，請參閱

https://www.suse.com/documentation/sle-ha-15/ 。

此外，使用兩個浮動的虛擬 IP 位址可讓用戶端連接到服務，而不管該服務在哪個實

體節點上執行。 192.168.1.10 用於透過 Hawk2 進行叢集管理， 192.168.2.1 專門用於

CIFS 輸出。如此可讓日後能更輕鬆地套用安全性限制。

以下程序說明範例安裝。https://www.suse.com/documentation/sle-ha-15/

book_sleha_quickstarts/data/art_sleha_install_quick.html 上提供了更多詳細

資料。

1. 在管理節點上建立一個特定於 Samba 閘道的金鑰圈，並將其複製到上述兩個節點

上：

cephadm@adm > ceph auth get-or-create client.samba.gw mon 'allow r' \ osd 'allow *' mds 'allow *' -o ceph.client.samba.gw.keyringroot@master # scp ceph.client.samba.gw.keyring earth:/etc/ceph/root@master # scp ceph.client.samba.gw.keyring mars:/etc/ceph/

2. 準備好 earth 和 mars，以代管 Samba 服務：

a. 繼續操作前，請確定已安裝下列套件： ctdb , tdb-tools和 samba (smb 和

nmb 資源需要這些套件)。

cephadm@smb > zypper in ctdb tdb-tools samba samba-ceph

b. 確定 ctdb、 smb 和 nmb 服務已停止且停用：

cephadm@smb > sudo systemctl disable ctdbcephadm@smb > sudo systemctl disable smbcephadm@smb > sudo systemctl disable nmbcephadm@smb > sudo systemctl stop smbcephadm@smb > sudo systemctl stop nmb

c. 在所有節點上開啟防火牆的連接埠 4379。這是為了使 CTDB 能夠與其他叢

集節點通訊。

3. 在 earth 上建立 Samba 的組態檔案。這些檔案稍後將自動同步到 mars。

a. 在 /etc/ctdb/nodes 中插入包含叢集中每個節點的所有私人 IP 位址的所有

節點：

192.168.1.1


https://www.suse.com/documentation/sle-ha-15/

https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/art_sleha_install_quick.html

https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/art_sleha_install_quick.html

192.168.1.2

b. 設定 Samba。在 /etc/samba/smb.conf 的 [global] 區段中新增以下行。使

用所選的主機名稱取代「CTDB-SERVER」(叢集中的所有節點將顯示為一個此

名稱的大節點，以方便操作)。另外，新增一個共用定義，以 SHARE_NAME 為

例：

[global] netbios name = SAMBA-HA-GW clustering = yes idmap config * : backend = tdb2 passdb backend = tdbsam ctdbd socket = /var/lib/ctdb/ctdb.socket # disable print server load printers = no smbd: backgroundqueue = no

[SHARE_NAME] path = / vfs objects = ceph ceph: config_file = /etc/ceph/ceph.conf ceph: user_id = samba.gw read only = no oplocks = no kernel share modes = no

請注意， /etc/ctdb/nodes 和 /etc/samba/smb.conf 檔案需要在所有 Samba

閘道節點上都相符。

4. 安裝並開機 SUSE Linux Enterprise High Availability 叢集。

a. 在 earth 和 mars 上註冊 SUSE Linux Enterprise High Availability

Extension：

root@earth # SUSEConnect -r ACTIVATION_CODE -e E_MAIL

root@mars # SUSEConnect -r ACTIVATION_CODE -e E_MAIL

b. 在兩個節點上安裝 ha-cluster-bootstrap ：

root@earth # zypper in ha-cluster-bootstrap

root@mars # zypper in ha-cluster-bootstrap

c. 在 earth 上啟始化叢集：


root@earth # ha-cluster-init

d. 讓 mars 加入該叢集：

root@mars # ha-cluster-join -c earth

5. 檢查叢集的狀態。您應該會看到兩個節點都已新增至叢集中：

root@earth # crm status2 nodes configured1 resource configured

Online: [ earth mars ]

Full list of resources:

admin-ip (ocf::heartbeat:IPaddr2): Started earth

6. 在 earth 上執行以下指令，以設定 CTDB 資源：

root@earth # crm configurecrm(live)configure# primitive ctdb ocf:heartbeat:CTDB params \ ctdb_manages_winbind="false" \ ctdb_manages_samba="false" \ ctdb_recovery_lock="!/usr/lib64/ctdb/ctdb_mutex_ceph_rados_helper ceph client.samba.gw cephfs_metadata ctdb-mutex" ctdb_socket="/var/lib/ctdb/ctdb.socket" \ op monitor interval="10" timeout="20" \ op start interval="0" timeout="200" \ op stop interval="0" timeout="100"crm(live)configure# primitive nmb systemd:nmb \ op start timeout="100" interval="0" \ op stop timeout="100" interval="0" \ op monitor interval="60" timeout="100"crm(live)configure# primitive smb systemd:smb \ op start timeout="100" interval="0" \ op stop timeout="100" interval="0" \ op monitor interval="60" timeout="100"crm(live)configure# group g-ctdb ctdb nmb smbcrm(live)configure# clone cl-ctdb g-ctdb meta interleave="true"crm(live)configure# commit

組態選項 ctdb_recovery_lock 中的二進位檔案 /usr/lib64/

ctdb/ctdb_mutex_ceph_rados_helper 中依如下順序包含以下參

數： CLUSTER_NAME、 CEPHX_USER、 RADOS_POOL 和 RADOS_OBJECT。


可附加一個額外的鎖定逾時參數來覆寫所用的預設值 (10 秒)。使用更高的值將

會增加 CTDB 復原主節點的容錯移轉時間，然而使用更低的值可能會導致不正確

地將復原主節點偵測為停機狀態，以致觸發翻動容錯移轉。

7. 新增叢集化 IP 位址：

crm(live)configure# primitive ip ocf:heartbeat:IPaddr2 params ip=192.168.2.1 \ unique_clone_address="true" \ op monitor interval="60" \ meta resource-stickiness="0"crm(live)configure# clone cl-ip ip \ meta interleave="true" clone-node-max="2" globally-unique="true"crm(live)configure# colocation col-with-ctdb 0: cl-ip cl-ctdbcrm(live)configure# order o-with-ctdb 0: cl-ip cl-ctdbcrm(live)configure# commit

如果 unique_clone_address 設定為 true，IPaddr2 資源代辦會向指定的位

址新增一個複製品 ID，從而導致出現三個不同的 IP 位址。這些位址通常

是不需要的，但有助於實現負載平衡。如需有關此主題的詳細資訊，請參閱

https://www.suse.com/documentation/sle-ha-15/book_sleha_guide/data/

cha_ha_lb.html 。

8. 檢查結果：

root@earth # crm statusClone Set: base-clone [dlm] Started: [ factory-1 ] Stopped: [ factory-0 ] Clone Set: cl-ctdb [g-ctdb] Started: [ factory-1 ] Started: [ factory-0 ] Clone Set: cl-ip [ip] (unique) ip:0 (ocf:heartbeat:IPaddr2): Started factory-0 ip:1 (ocf:heartbeat:IPaddr2): Started factory-1

9. 從用戶端機器執行測試。在 Linux 用戶端上執行以下指令，確定是否可以將檔案

複製到系統或從系統複製檔案：

root # smbclient //192.168.2.1/myshare


https://www.suse.com/documentation/sle-ha-15/book_sleha_guide/data/cha_ha_lb.html

https://www.suse.com/documentation/sle-ha-15/book_sleha_guide/data/cha_ha_lb.html

20.2 將 Samba 閘道加入 Active Directory

中

您可以將 Ceph Samba 閘道設定為支援 Active Directory (AD) 的 Samba 網域成員。

做為 Samba 網域成員，您可以針對來自輸出 CephFS 的檔案和目錄在本地存取清單

(ACL) 中使用網域使用者和群組。

20.2.1 準備

本節介紹在設定 Samba 自身之前，您需要執行的一些準備步驟。首先，您需要準備一

個乾淨的環境，這樣有助於防止混淆，並可確認以前所安裝的 Samba 系統中的檔案未

與新安裝的網域成員混用。

提示：同步時鐘所有 Samba 閘道節點的時鐘都需要與 Active Directory 網域控制器保持同

步。時鐘誤差可能會導致驗證失敗。

確認沒有執行中的 Samba 或名稱快取程序：

cephadm@smb > ps ax | egrep "samba|smbd|nmbd|winbindd|nscd"

如果輸出列出了任何 samba、 smbd、 nmbd、 winbindd 或 nscd 程序，請將其停止。

如果您之前在此主機上執行過 Samba 安裝，請移除 /etc/samba/smb.conf 檔案。另

外，請移除所有 Samba 資料庫檔案 (例如 *.tdb 和 *.ldb 檔案)。若要列出包含

Samba 資料庫的目錄，請執行以下指令：

cephadm@smb > smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR"

20.2.2 確認 DNS

Active Directory (AD) 使用 DNS 來尋找網域控制器 (DC) 和服務 (例如

Kerberos)。因此，AD 網域成員和伺服器需要能夠解析 AD DNS 區域。

295 將 Samba 閘道加入 Active Directory 中 SES 6

確認已正確設定 DNS 且正向和反向尋找均可正確解析，例如：

cephadm@adm > nslookup DC1.domain.example.comServer: 10.99.0.1Address: 10.99.0.1#53

Name: DC1.domain.example.comAddress: 10.99.0.1

cephadm@adm > 10.99.0.1Server: 10.99.0.1Address: 10.99.0.1#53

1.0.99.10.in-addr.arpa name = DC1.domain.example.com.

20.2.3 解析 SRV 記錄

AD 使用 SRV 記錄尋找服務 (例如 Kerberos 和 LDAP)。若要確認能否正確解析 SRV

記錄，請使用 nslookup 互動外圍程序，例如：

cephadm@adm > nslookupDefault Server: 10.99.0.1Address: 10.99.0.1

> set type=SRV> _ldap._tcp.domain.example.com.Server: UnKnownAddress: 10.99.0.1

_ldap._tcp.domain.example.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = dc1.domain.example.comdomain.example.com nameserver = dc1.domain.example.comdc1.domain.example.com internet address = 10.99.0.1

20.2.4 設定 Kerberos

Samba 支援 Heimdal 和 MIT Kerberos 後端。若要對網域成員設定 Kerberos，請在您

的 /etc/krb5.conf 檔案中進行以下設定：

[libdefaults]

296 解析 SRV 記錄 SES 6

default_realm = DOMAIN.EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = true

上面的範例為 DOMAIN.EXAMPLE.COM 領域設定了 Kerberos。我們不建議在 /etc/

krb5.conf 檔案中設定任何進一步的參數。如果您的 /etc/krb5.conf 中包含 include

行，則您必須移除此行，否則該檔案將無法運作。

20.2.5 本地主機名稱解析

當您將主機加入網域中時，Samba 會嘗試在 AD DNS 區域中註冊其主機名稱。為

此， net 公用程式需要能夠使用 DNS 或 /etc/hosts 檔案中的正確項目來解析主機名

稱。

若要確認您的主機名稱解析正確，請使用 getent hosts 指令：

cephadm@adm > getent hosts example-host10.99.0.5 example-host.domain.example.com example-host

主機名稱和 FQDN 不得解析為 127.0.0.1 IP 位址，或與網域成員的 LAN 介面上所用

IP 位址不同的任何 IP 位址。如果未顯示輸出或主機解析為錯誤的 IP 位址，而您未

在使用 DHCP，請在 /etc/hosts 檔案中設定正確的項目：

127.0.0.1 localhost10.99.0.5 example-host.samdom.example.com example-host

提示：DHCP 和 /etc/hosts如果您在使用 DHCP，請檢查 /etc/hosts 是否僅包含「127.0.0.1」行。如果仍

然有問題，請聯絡 DHCP 伺服器的管理員。

如果您需要新增機器主機名稱的別名，請將別名新增至以機器 IP 位址開頭的行

的末尾，切勿新增至「127.0.0.1」行。

20.2.6 設定 Samba

本節介紹有關您需要在 Samba 組態檔案 /etc/samba/smb.conf 中包含的特定組態選項

的資訊。

297 本地主機名稱解析 SES 6

20.2.6.1 選擇 winbindd 中用於 ID 對應的後端

如果您需要讓您的使用者使用不同的登入外圍程序和/或 Unix 主目錄路徑，或者讓他

們在任何地方都使用相同的 ID，您需要使用 winbind「ad」後端並將 RFC2307 屬性新

增至 AD 中。

重要：RFC2307 屬性和 ID 編號建立使用者或群組時，系統不會自動新增 RFC2307 屬性。

DC 上找到的 ID 編號 (3000000 範圍內的編號) 不是 RFC2307 屬性，Unix 網

域成員上將不會使用該編號。如果您需要在任何地方都使用相同的 ID 編號，請

將 uidNumber 和 gidNumber 屬性新增至 AD 中，並在 Unix 網域成員上使用

winbind「ad」後端。如果您決定將 uidNumber 和 gidNumber 屬性新增至 AD

中，請不要使用 3000000 範圍內的編號。

如果您的使用者僅將 Samba AD DC 用於驗證目的，而不會在其上儲存資料或登入其

中，則您可使用 winbind「rid」後端。如此，系統會依據 Windows* RID 來計算使用

者和群組 ID。如果您在每個 Unix 網域成員上的 smb.conf 中都使用相同的 [global]

區段，您將會獲得相同的 ID。如果您使用「rid」後端，則不需要向 AD 新增任何

內容，系統將會忽略 RFC2307 屬性。使用「rid」後端時，請在 smb.conf 中設定

template shell 和 template homedir 參數。它們是全域設定，會為所有使用者設定

相同的登入外圍程序和 Unix 主目錄路徑 (RFC2307 屬性則不同，可用來設定個別的

Unix 主目錄路徑和外圍程序)。

如果您需要讓您的使用者和群組在任何地方都使用相同的 ID，但只需要為他們設定相

同的登入外圍程序和相同的 Unix 主目錄路徑，還可使用另一種方法來設定 Samba。您

可以透過使用 winbind「ad」後端並在 smb.conf 中使用範本行來實現此目的。使用此

方法時，您僅需將 uidNumber 和 gidNumber 屬性新增至 AD 中。

提示：有關 ID 對應後端的更多資訊如需可用 ID 對應後端的更多詳細資訊，請參閱下列相關手冊頁： man 8

idmap_ad、 man 8 idmap_rid 和 man 8 idmap_autorid。

298 設定 Samba SES 6

20.2.6.2 設定使用者和群組 ID 範圍

決定好使用哪個 winbind 後端後，您需要在 smb.conf 中設定 idmap config 選項來

指定要使用的範圍。依預設，Unix 網域成員上有多個使用者和群組 ID 區塊：

表格 20.1︰預設使用者和群組 ID 區塊

ids 範圍

0-999 本地系統使用者和

群組。

從 1000 開始本地 Unix 使用者

和群組。

從 10000 開始 DOMAIN 使用者和群

組。

依據上述範圍，您不應將「*」或「DOMAIN」範圍設定為 999 以內，因為它們會與本地

系統使用者和群組發生衝突。您還應為任何本地 Unix 使用者和群組留出餘地，因此將

idmap config 範圍設定為從 3000 開始是不錯的折衷方法。

您需要確定「DOMAIN」可能會增長到多大，並決定是否打算建立任何受信任的網域。然

後，便可依如下所示來設定 idmap config 範圍：

表格 20.2︰ ID 範圍

領域範圍

* 3000-7999

DOMAIN 10000-999999

TRUSTED 1000000-9999999

20.2.6.3 將網域管理員帳戶對應至本地 root 使用者

Samba 可讓您將網域帳戶對應至本地帳戶。透過此功能，您可以用不同於用戶端上要求

執行操作的帳戶的使用者身分在網域成員的檔案系統上執行檔案操作。

299 設定 Samba SES 6

提示：對應網域管理員 (選擇性)將網域管理員對應至本地 root 帳戶屬於選擇性操作。請僅在網域管理員需要

能夠使用 root 許可權在網域成員上執行檔案操作時設定該對應。請注意，將

Administrator 對應至 root 帳戶後，其便不能以「Administrator」身分登入

Unix 網域成員。

若要將網域管理員對應至本地 root 帳戶，請執行以下步驟：

1. 將以下參數新增至 smb.conf 檔案的 [global] 區段：

username map = /etc/samba/user.map

2. 建立包含以下內容的 /etc/samba/user.map 檔案：

!root = DOMAIN\Administrator

重要使用「ad」ID 對應後端時，請不要為網域管理員帳戶設定 uidNumber 屬

性。如果為網域管理員帳戶設定了該屬性，其值會覆寫 root 使用者的本地

UID「0」，因而會導致對應失敗。

如需更多詳細資料，請參閱 smb.conf 手冊頁 ( man 5 smb.conf ) 中的 username map

參數。

20.2.7 加入 Active Directory 網域

若要將主機加入 Active Directory，請執行以下指令：

cephadm@smb > net ads join -U administratorEnter administrator's password: PASSWORDUsing short domain name -- DOMAINJoined EXAMPLE-HOST to dns domain 'DOMAIN.example.com'

300 加入 Active Directory 網域 SES 6

20.2.8 設定名稱服務參數

若要使網域使用者和群組可供本地系統使用，您需要啟用名稱服務參數 (NSS) 程式

庫。在 /etc/nsswitch.conf 檔案中，將 winbind 項目附加到以下資料庫：

passwd: files winbindgroup: files winbind

重要：需考量的要點

將 files 項目指定為這兩個資料庫的第一個來源。這可讓 NSS 在查詢

winbind 服務之前，先從 /etc/passwd 和 /etc/group 檔案中尋找網域使

用者和群組。

不要將 winbind 項目新增至 NSS shadow 資料庫中。這樣做可能會導致

wbinfo 公用程式失敗。

不要在本地 /etc/passwd 檔案中使用與網域中相同的使用者名稱。

20.2.9 啟動服務

若要讓 Unix 網域成員具備完整功能，您需要啟用並啟動以下三項服務： smbd、 nmbd

和 winbindd。請透過使用以下指令啟用並啟動這些服務：

cephadm@smb > sudo systemctl enable smbd.service && systemctl start smbd.servicecephadm@smb > sudo systemctl enable nmbd.service && systemctl start nmbd.servicecephadm@smb > sudo systemctl enable winbindd.service && systemctl start winbindd.service

提示：nmbd 是選擇性服務如果您不需要網路瀏覽，則無需在 Unix 網域成員上啟用並啟動 nmbd 服務。

301 設定名稱服務參數 SES 6

20.2.10 測試 winbindd 連接性

20.2.10.1 傳送 winbindd Ping

若要驗證 winbindd 服務能否連接至 AD 網域控制器 (DC) 或主要網域控制器 (PDC)，

請輸入以下指令：

cephadm@smb > wbinfo --ping-dcchecking the NETLOGON for domain[DOMAIN] dc connection to "DC.DOMAIN.EXAMPLE.COM" succeeded

如果前一條指令失敗，請確認 winbindd 服務正在執行，且正確設定了 smb.conf 檔

案。

20.2.10.2 尋找網域使用者和群組

您可以使用 libnss_winbind 程式庫尋找網域使用者和群組。例如，若要尋找網域使用

者「DOMAIN\demo01」，請執行以下指令：

cephadm@smb > getent passwd DOMAIN\\demo01DOMAIN\demo01:*:10000:10000:demo01:/home/demo01:/bin/bash

若要尋找網域群組「Domain Users」，請執行以下指令：

cephadm@smb > getent group "DOMAIN\\Domain Users"DOMAIN\domain users:x:10000:

20.2.10.3 為網域使用者和群組指定檔案許可權

利用名稱服務參數 (NSS) 程式庫，您可以在指令中使用網域使用者帳戶和群組。例

如，若要將檔案的擁有者設定為「demo01」網域使用者，並將群組設定為「Domain

Users」網域群組，請輸入以下指令：

cephadm@smb > chown "DOMAIN\\demo01:DOMAIN\\domain users" file.txt

302 測試 winbindd 連接性 SES 6

21 NFS Ganesha：透過 NFS 輸出 Ceph 資料

NFS Ganesha 是一部 NFS 伺服器 (請參閱與 NFS 共用檔案系統 (https://

documentation.suse.com/sles/15-SP1/html/SLES-all/cha-nfs.html) )，它在使用

者位址空間中執行，而不是做為作業系統核心的一部分執行。憑藉 NFS Ganesha，您可

以插入自己的儲存機制 (例如 Ceph)，並從任何 NFS 用戶端存取它。

系統依使用者將 S3 桶輸出到 NFS，例如，透過路徑

GANESHA_NODE:/USERNAME/BUCKETNAME 輸出。

預設透過路徑 GANESHA_NODE:/cephfs 輸出 CephFS。

注意：NFS Ganesha 效能由於用戶端與儲存區之間的額外網路躍程會導致通訊協定負擔增加並產生額外

的延遲，因此與使用原生 CephFS 或物件閘道用戶端相比，透過 NFS 閘道存取

Ceph 可能會使應用程式效能大幅降低。

21.1 安裝

如需安裝說明，請參閱《部署指南》, 第 12 章「安裝 NFS Ganesha」。

21.2 組態

如需可在組態檔案中使用的所有參數的清單，請參閱：

man ganesha-config

man ganesha-ceph-config，用於 CephFS 檔案系統抽象層 (FSAL) 選項。

man ganesha-rgw-config，用於物件閘道 FSAL 選項。

本節包含的資訊可協助您設定 NFS Ganesha 伺服器，以輸出可透過物件閘道和 CephFS

存取的叢集資料。

303 安裝 SES 6

https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-nfs.html

https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-nfs.html

NFS Ganesha 組態包含兩個部分：服務組態和輸出組態。透過 /etc/ganesha/

ganesha.conf 來控制服務組態。注意，在執行 DeepSea 階段 4 時將會覆寫對此檔案

所做的變更。若要永久變更這些設定，請編輯位於 Salt Master 上的檔案 /srv/salt/

ceph/ganesha/files/ganesha.conf.j2。輸出組態以 RADOS 物件的形式儲存在 Ceph 叢

集中。

21.2.1 服務組態

服務組態儲存在 /etc/ganesha/ganesha.conf 中，用於控制所有 NFS Ganesha 精靈設

定，包括 Ceph 叢集中儲存輸出組態的位置。注意，在執行 DeepSea 階段 4 時將會覆

寫對此檔案所做的變更。若要永久變更這些設定，請編輯位於 Salt Master 上的檔案

/srv/salt/ceph/ganesha/files/ganesha.conf.j2。

21.2.1.1 RADOS_URLS 區段

RADOS_URLS 區段用於設定為了從 RADOS 物件讀取 NFS Ganesha 組態所需進行的 Ceph

叢集存取。

RADOS_URLS { Ceph_Conf = /etc/ceph/ceph.conf;

UserId = "ganesha.MINION_ID"; watch_url = "rados://RADOS_POOL/ganesha/conf-MINION_ID";}

Ceph_Conf

Ceph 組態檔案路徑位置。

UserId

CephX 使用者 ID。

watch_url

用於監看重新載入通知的 RADOS 物件 URL。

21.2.1.2 RGW 區段

RGW {

304 服務組態 SES 6

ceph_conf = "/etc/ceph/ceph.conf"; name = "name"; cluster = "ceph";}

ceph_conf

指向 ceph.conf 檔案。與 DeepSea 一起部署時，不需要變更此值。

name

NFS Ganesha 使用的 Ceph 用戶端使用者名稱。

cluster

Ceph 叢集的名稱。SUSE Enterprise Storage 6 目前僅支援一個叢集名稱，預設

為 ceph。

21.2.1.3 RADOS 物件 URL

%url rados://RADOS_POOL/ganesha/conf-MINION_ID

NFS Ganesha 支援從 RADOS 物件讀取組態。使用 %url 指令可指定用於識別 RADOS

物件位置的 RADOS URL。

RADOS URL 可採用以下兩種格式： rados://<POOL>/<OBJECT> 或 rados://<POOL>/

<NAMESPACE>/<OBJECT>，其中 POOL 是儲存物件的 RADOS 池， NAMESPACE 是儲存物件

的池名稱空間， OBJECT 是物件名稱。

為了支援 Ceph Dashboard 的 NFS Ganesha 管理功能，您需要遵循每個服務精靈的

RADOS 物件的命名慣例。物件名稱必須採用 conf-MINION_ID 格式，其中 MINION_ID

是正在執行此服務的節點的 Salt Minion ID。

DeepSea 已負責執行正確產生此 URL 的工作，您無需再進行任何變更。

21.2.1.4 變更預設 NFS Ganesha 連接埠

NFS Ganesha 預設使用連接埠 2049 提供 NFS 支援，使用 875 提供 rquota 支援。若

要變更預設連接埠號碼，請在 NFS_CORE_PARAM 區段中使用 NFS_Port 和 RQUOTA_Port

選項，例如：

NFS_CORE_PARAM{NFS_Port = 2060;

305 服務組態 SES 6

RQUOTA_Port = 876;}

21.2.2 輸出組態

輸出組態以 RADOS 物件的形式儲存在 Ceph 叢集中。每個輸出區塊都儲存在各自名為

export-<id> 的 RADOS 物件中，其中， <id> 必須與輸出組態的 Export_ID 屬性相

符。透過 conf-MINION_ID 物件來實現輸出與 NFS Ganesha 服務之間的關聯。每個服

務物件包含該服務所輸出的每個輸出的 RADOS URL 清單。輸出區塊如下所示：

EXPORT{ Export_Id = 1; Path = "/"; Pseudo = "/"; Access_Type = RW; Squash = No_Root_Squash; [...] FSAL { Name = CEPH; }}

若要為上面的輸出區塊建立 RADOS 物件，我們需要先將輸出區塊代碼儲存到一個檔案

中。然後可以使用 RADOS CLI 工具將之前所儲存檔案的內容儲存到 RADOS 物件中。

cephadm@adm > rados -p POOL -N NAMESPACE put export-EXPORT_ID EXPORT_FILE

建立輸出物件後，我們便可將輸出與服務例項進行關聯，方法是將輸出物件的相應

RADOS URL 新增至服務物件。下面的章節介紹如何設定輸出區塊。

21.2.2.1 Export 主區段

Export_Id

每個輸出項都需有唯一的「Export_Id」(強制)。

Path

相關 CephFS 池中的輸出項路徑 (強制)。允許從 CephFS 中輸出子目錄。

Pseudo

目標 NFS 輸出項路徑 (對於 NFSv4 為強制)。它定義在哪個 NFS 輸出項路徑下

可獲得輸出的資料。

306 輸出組態 SES 6

範例：使用值 /cephfs/ 並執行

root # mount GANESHA_IP:/cephfs/ /mnt/

之後，將可在用戶端上的 /mnt/cephfs/ 目錄中獲得 CephFS 資料。

Access_Type

「RO」表示唯讀存取權，「RW」表示讀取寫入存取權，「None」表示禁止存取。

提示：限制用戶端的存取如果您在主 EXPORT 區段保留 Access_Type = RW，並在 CLIENT 區段限制

某個特定用戶端的存取，其他用戶端仍可連接。若要禁止所有用戶端的存

取，而只允許特定用戶端進行存取，請在 EXPORT 區段設定 Access_Type =

None，然後在 CLIENT 區段為一或多個用戶端指定限制較少的存取模式：

EXPORT {

FSAL { access_type = "none"; [...] }

CLIENT { clients = 192.168.124.9; access_type = "RW"; [...] }[...]}

Squash

NFS squash 選項。

FSAL

輸出「檔案系統抽象層」。請參閱第 21.2.2.2 節「FSAL 子區段」。

21.2.2.2 FSAL 子區段

EXPORT{

307 輸出組態 SES 6

[...] FSAL { Name = CEPH; }}

Name

定義 NFS Ganesha 使用的後端。允許的值為 CEPH (表示 CephFS) 或 RGW (表

示物件閘道)。根據您的選擇，必須在 policy.cfg 中定義 role-mds 或 role-

rgw。

21.3 自訂 NFS Ganesha 角色

可為叢集節點定義自訂 NFS Ganesha 角色。然後可在 policy.cfg 中將這些角色指定

給節點。角色允許：

分別使用不同的 NFS Ganesha 節點來存取物件閘道和 CephFS。

將不同的物件閘道使用者指定給 NFS Ganesha 節點。

擁有不同的物件閘道使用者可讓 NFS Ganesha 節點存取不同的 S3 桶。S3 桶可用於進

行存取控制。注意：不要將 S3 桶與 CRUSH 地圖中使用的 Ceph 桶混淆。

21.3.1 NFS Ganesha 的不同物件閘道使用者

下面針對 Salt Master 的範例程序展示如何建立兩個具有不同物件閘道使用者的 NFS

Ganesha 角色。在此範例中，使用了角色 gold 和 silver，DeepSea 已經提供了它們

的範例組態檔案。

1. 使用您選擇的編輯器開啟 /srv/pillar/ceph/stack/global.yml 檔案。如果該檔

案不存在，請予以建立。

2. 該檔案需要包含以下數行：

rgw_configurations: - rgw - silver - gold

308 自訂 NFS Ganesha 角色 SES 6

ganesha_configurations: - silver - gold

稍後可以在 policy.cfg 中指定這些角色。

3. 建立 /srv/salt/ceph/rgw/users/users.d/gold.yml 檔案並新增以下內容：

- { uid: "gold1", name: "gold1", email: "[email protected]" }

建立 /srv/salt/ceph/rgw/users/users.d/silver.yml 檔案並新增以下內容：

- { uid: "silver1", name: "silver1", email: "[email protected]" }

4. 現在，需要為每個角色建立 ganesha.conf 的範本。使用 DeepSea 的原始範本是

較佳的做法。建立兩個副本：

root@master # cd /srv/salt/ceph/ganesha/files/root@master # cp ganesha.conf.j2 silver.conf.j2root@master # cp ganesha.conf.j2 gold.conf.j2

5. 新角色需要金鑰圈來存取叢集。若要提供存取權，請複製 ganesha.j2：

root@master # cp ganesha.j2 silver.j2root@master # cp ganesha.j2 gold.j2

6. 複製物件閘道的金鑰圈：

root@master # cd /srv/salt/ceph/rgw/files/root@master # cp rgw.j2 silver.j2root@master # cp rgw.j2 gold.j2

7. 物件閘道還需要不同角色的組態：

root@master # cd /srv/salt/ceph/configuration/files/root@master # cp ceph.conf.rgw silver.confroot@master # cp ceph.conf.rgw gold.conf

8. 在 /srv/pillar/ceph/proposals/policy.cfg 中將新建立的角色指定給叢集節點：

role-silver/cluster/NODE1.slsrole-gold/cluster/NODE2.sls

分別以要將角色指定給的節點名稱取代 NODE1 和 NODE2。

9. 執行 DeepSea 階段 0 到 4。

309 NFS Ganesha 的不同物件閘道使用者 SES 6

21.3.2 分隔 CephFS 和物件閘道 FSAL

下面針對 Salt Master 的範例程序展示如何建立使用 CephFS 和物件閘道的兩個不同

的新角色：

1. 使用您選擇的編輯器開啟檔案 /srv/pillar/ceph/rgw.sls。如果該檔案不存在，

請予以建立。

2. 該檔案需要包含以下數行：

rgw_configurations: ganesha_cfs: users: - { uid: "demo", name: "Demo", email: "[email protected]" } ganesha_rgw: users: - { uid: "demo", name: "Demo", email: "[email protected]" }

ganesha_configurations: - ganesha_cfs - ganesha_rgw

稍後可以在 policy.cfg 中指定這些角色。

3. 現在，需要為每個角色建立 ganesha.conf 的範本。使用 DeepSea 的原始範本是

較佳的做法。建立兩個副本：

root@master # cd /srv/salt/ceph/ganesha/files/root@master # cp ganesha.conf.j2 ganesha_rgw.conf.j2root@master # cp ganesha.conf.j2 ganesha_cfs.conf.j2

4. 編輯 ganesha_rgw.conf.j2，移除以下區段：

{% if salt.saltutil.runner('select.minions', cluster='ceph', roles='mds') != [] %} [...]{% endif %}

5. 編輯 ganesha_cfs.conf.j2，移除以下區段：

{% if salt.saltutil.runner('select.minions', cluster='ceph', roles=role) != [] %} [...]{% endif %}

6. 新角色需要金鑰圈來存取叢集。若要提供存取權，請複製 ganesha.j2：

root@master # cp ganesha.j2 ganesha_rgw.j2

310 分隔 CephFS 和物件閘道 FSAL SES 6

root@master # cp ganesha.j2 ganesha_cfs.j2

可從 ganesha_rgw.j2 中移除 caps mds = "allow *" 這一行。

7. 複製物件閘道的金鑰圈：

root@master # cp /srv/salt/ceph/rgw/files/rgw.j2 \/srv/salt/ceph/rgw/files/ganesha_rgw.j2

8. 物件閘道需要您對新角色進行組態設定：

root@master # cp /srv/salt/ceph/configuration/files/ceph.conf.rgw \/srv/salt/ceph/configuration/files/ceph.conf.ganesha_rgw

9. 在 /srv/pillar/ceph/proposals/policy.cfg 中將新建立的角色指定給叢集節點：

role-ganesha_rgw/cluster/NODE1.slsrole-ganesha_cfs/cluster/NODE1.sls

分別以要將角色指定給的節點名稱取代 NODE1 和 NODE2。

10. 執行 DeepSea 階段 0 到 4。

21.3.3 支援操作

RGW NFS 介面支援對檔案及目錄執行的大部分操作，但存在以下限制：

不支援包含符號連結的連結。

不支援 NFS 存取控制清單 (ACL)。支援 Unix 使用者及群組擁有權和許可權。

目錄不可移動或重新命名。您可在目錄之間移動檔案。

僅支援完整的循序寫入 I/O。因此，它會強制上傳寫入操作。許多執行非循序儲

存的一般 I/O 操作 (如就地編輯檔案) 必定會失敗。有一些歸檔公用程式 (例

如，GNU tar 的某些版本) 表面上是循序寫入，但也可能會因偶爾的非循序儲存

而失敗。透過 NFS 掛接時，一般可透過同步掛接 ( -o sync 選項) 強制應用程

式的循序 I/O 向 NFS 伺服器循序寫入資料。無法同步掛接的 NFS 用戶端 (例如

Microsoft Windows*) 將無法上傳檔案。

NFS RGW 僅支援對小於 4 MB 的儲存區塊執行讀取寫入操作。

311 支援操作 SES 6

21.4 啟動或重新啟動 NFS Ganesha若要啟用並啟動 NFS Ganesha 服務，請執行以下指令：

root@minion > systemctl enable nfs-ganesharoot@minion > systemctl start nfs-ganesha

若要重新啟動 NFS Ganesha，請執行以下指令：

root@minion > systemctl restart nfs-ganesha

啟動或重新啟動 NFS Ganesha 時，NFS v4 會有 90 秒的逾時寬限期間。在寬限期間，

系統會主動拒絕來自用戶端的新要求。因此，當 NFS 處於寬限狀態時，用戶端可能會

發生要求處理速度變慢的情況。

21.5 設定記錄層級您可以透過編輯 /etc/sysconfig/nfs-ganesha 檔案，來變更預設除錯層級

NIV_EVENT。以 NIV_DEBUG 或 NIV_FULL_DEBUG 取代 NIV_EVENT。提高記錄詳細層級可

能會在記錄檔案中產生大量資料。

OPTIONS="-L /var/log/ganesha/ganesha.log -f /etc/ganesha/ganesha.conf -N NIV_EVENT"

變更記錄層級時，需要重新啟動服務。

21.6 驗證輸出的 NFS 共用使用 NFS v3 時，您可以在 NFS Ganesha 伺服器節點上驗證是否輸出了 NFS 共用：

root@minion > showmount -e/ (everything)

21.7 掛接輸出的 NFS 共用若要在用戶端主機上掛接輸出的 NFS 共用 (依據第 21.2 節「組態」中的設定)，請

執行以下指令：

312 啟動或重新啟動 NFS Ganesha SES 6

root # mount -t nfs -o rw,noatime,sync \ nfs_ganesha_server_hostname:/ /path/to/local/mountpoint

313 掛接輸出的 NFS 共用 SES 6

IV 使用圖形使用者介面工具管理叢

集

22 Ceph Dashboard 315

22 Ceph Dashboard

Ceph Dashboard 是一個模組，它新增了一個內建的 Web 式監控和管理應用程式至

Ceph 管理員 (如需 Ceph 管理員的更多詳細資料，請參閱《部署指南》, 第 1 章

「SUSE Enterprise Storage 6 和 Ceph」, 第 1.2.3 節「Ceph 節點和精靈」)。現

在，您不必瞭解複雜的 Ceph 相關指令，便可輕鬆管理和監控您的 Ceph 叢集。您可以

使用 Ceph Dashboard 的直觀 Web 介面，也可以使用其內建的 REST API。

在部署程序中的 DeepSea 階段 3，系統會自動啟用和設定 Ceph Dashboard (請參

閱《部署指南》, 第 5 章「使用 DeepSea/Salt 部署」, 第 5.3 節「叢集部署」)。

在具有多個 Ceph 管理員例項的 Ceph 叢集中，只有目前使用中的 Ceph 管理員精靈上

執行的儀表板會處理內送要求。系統會將存取任何其他目前待命中 Ceph 管理員例項上

的儀表板 TCP 連接埠的要求進行 HTTP 重新導向 (303)，轉至目前使用中 Ceph 管理

員的儀表板 URL。如此，無論您將瀏覽器指向任何 Ceph 管理員例項，都可以存取該儀

表板。在利用防火牆保障存取安全或規劃 HA 設定時，請考慮此種行為。

22.1 儀表板的 Web 使用者介面

22.1.1 登入

若要登入儀表板 Web 應用程式，請將瀏覽器指向其 URL，包括連接埠號碼。您可以透

過執行以下指令找到其網址

cephadm@adm > ceph mgr services | grep dashboard"dashboard": "https://ses-dash-node.example.com:8443/",

315 儀表板的 Web 使用者介面 SES 6

圖形 22.1︰ CEPH DASHBOARD 登入畫面

您需要有使用者帳戶才能登入儀表板 Web 應用程式。DeepSea 會為您建立一個擁有管

理員權限的預設使用者「admin」。如果您決定使用預設「admin」使用者登入，請透過

執行以下指令擷取相應密碼

root@master # salt-call grains.get dashboard_creds

提示：自訂使用者帳戶如果您不想使用預設「admin」帳戶存取 Ceph Dashboard，請建立擁有管理員權

限的自訂使用者帳戶。如需更多詳細資料，請參閱第 22.10 節「在指令行上

管理使用者和角色」。

儀表板使用者介面在圖形上分為以下幾個區塊：公用程式功能表、主功能表和主內容窗

格。

316 登入 SES 6

圖形 22.2︰ CEPH DASHBOARD 首頁

22.1.2 公用程式功能表

公用程式功能表位於螢幕右上方。該功能表包含與儀表板更為相關 (相較於 Ceph 叢

集) 的一般任務。按一下相應項目可以存取以下主題：

變更儀表板使用者介面的語言。您可以選取捷克語、英語、德語、西班牙語、法

語、葡萄牙語、中文或印尼語。

顯示正在背景中執行的 Ceph 相關任務清單。

檢視並清除最近的儀表板通知。

顯示提供儀表板相關資訊、其完整文件及 REST API 綜覽的連結清單。

管理儀表板的使用者和使用者角色。如需更詳細的指令行描述，請參閱第 22.10

節「在指令行上管理使用者和角色」。

登出儀表板。

22.1.3 主功能表

儀表板的主功能表位於螢幕的左上方。它涵蓋下列主題：

317 公用程式功能表 SES 6

儀表板

回到 Ceph Dashboard 首頁。

叢集

檢視有關叢集的整體組態、CRUSH 地圖、叢集的主機、Ceph OSD、Ceph 監控程式

及記錄檔案內容的詳細資訊。

池

檢視並管理叢集池。

區塊

檢視並管理區塊裝置及其 iSCSI 輸出。

NFS

檢視並管理 NFS Ganesha 部署。

Filesystems

檢視並管理 CephFS。

物件閘道

檢視並管理物件閘道的精靈、使用者和桶。

22.1.4 內容窗格

內容窗格佔據儀表板螢幕的主要部分。儀表板首頁上顯示了很多有用的工具集，為您提

供叢集目前狀態、容量及效能的簡要資訊。

22.1.5 常用 Web UI 功能

在 Ceph Dashboard 中，您經常會用到清單 — 例如，池清單、OSD 節點清單或 RBD

裝置清單。所有清單預設每 5 秒便會自動重新整理一次。下列常用工具集可協助您管

理或調整這些清單：

按一下可手動觸發清單的重新整理。

按一下可顯示或隱藏表的個別欄。

按一下並選取要在一頁上顯示多少列。

318 內容窗格 SES 6

在中按一下並輸入要搜尋的字串以過濾列。

如果清單跨多頁顯示，可使用來變更目前顯示的頁。

22.1.6 儀表板工具集

每個儀表板工具集顯示與執行中 Ceph 叢集特定方面相關的特定狀態資訊。有些工具集

是使用中連結，按一下它們會將您重新導向至其所代表主題的相關詳細頁面。

提示：滑鼠懸停時顯示更多詳細資料有些圖形工具集會在您將滑鼠移至其上時顯示更多詳細資料。

22.1.6.1 狀態工具集

狀態工具集為您提供有關叢集目前狀態的簡要綜覽。

圖形 22.3︰狀態工具集

叢集狀態

顯示有關叢集狀態的基本資訊。

監控程式

顯示執行中監控程式的數量及其仲裁。

OSD

顯示 OSD 的總數及處於「up」和「in」狀態的 OSD 數量。

管理員精靈

顯示使用中和待命 Ceph 管理員精靈的數量。

主機

319 儀表板工具集 SES 6

顯示叢集節點的總數。

物件閘道

顯示執行中物件閘道的數量。

中繼資料伺服器

顯示中繼資料伺服器的數量。

iSCSI 閘道

顯示設定的 iSCSI 閘道的數量。

22.1.6.2 效能工具集

效能工具集提供 Ceph 用戶端的基本效能資料。

圖形 22.4︰效能工具集

用戶端 IOPS

用戶端輸送量

用戶端讀取/寫入

復原輸送量

整理

22.1.6.3 容量工具集

容量工具集顯示有關儲存容量的簡要資訊。

320 儀表板工具集 SES 6

圖形 22.5︰容量工具集

池

顯示叢集中池的數量。

原始容量

顯示已用與可用原始儲存容量的比率。

物件

顯示叢集中儲存的資料物件數量。

每個 OSD 的 PG 數

顯示每個 OSD 的放置群組數量。

PG 狀態

顯示依照狀態分組的放置群組圖表。

22.2 管理儀表板使用者和角色

如需在指令行上使用 Ceph 指令執行儀表板使用者管理的說明，請參閱第 22.10 節

「在指令行上管理使用者和角色」。

本節介紹如何使用儀表板 Web 使用者介面來管理使用者帳戶。

22.2.1 列出使用者

按一下公用程式功能表中的，然後選取使用者管理。

該清單包含每個使用者的使用者名稱、全名、電子郵件及為其指定的角色清單。

321 管理儀表板使用者和角色 SES 6

圖形 22.6︰使用者管理

22.2.2 新增新使用者

按一下表標題左上方的新增可新增新使用者。輸入其使用者名稱、密碼、全名 (選擇

性) 和電子郵件。

圖形 22.7︰新增使用者

按一下鉛筆小圖示可為使用者指定預先定義的角色。按一下建立使用者進行確認。

22.2.3 編輯使用者

按一下使用者表中對應的列，然後選取編輯可編輯使用者的詳細資料。按一下更新使用

者進行確認。

322 新增新使用者 SES 6

22.2.4 刪除使用者

按一下使用者表中對應的列，然後選取刪除可刪除使用者帳戶。啟用是的，我確定核取

方塊，然後按一下刪除使用者進行確認。

22.2.5 列出使用者角色

按一下公用程式功能表中的，然後選取使用者管理。然後按一下角色索引標籤。

該清單包含每個角色的名稱、描述及其是否屬於系統角色。

圖形 22.8︰使用者職能

22.2.6 新增自訂角色

按一下表標題左上方的新增可新增新的自訂角色。輸入其名稱、描述並設定針對個別主

題的必需許可權。

提示：清除自訂角色如果您建立了自訂使用者角色，並打算以後使用 ceph.purge 執行程式移除

Ceph 叢集，則需要先清除自訂角色。如需更多詳細資料，請參閱第 2.16 節

「移除整個 Ceph 叢集」。

323 刪除使用者 SES 6

圖形 22.9︰新增角色

提示：多項目啟用透過啟用主題名稱前的核取方塊，您可以啟用針對該主題的所有許可權。透過啟

用全部核取方塊，您可以啟用針對所有主題的所有許可權。

按一下建立角色進行確認。

324 新增自訂角色 SES 6

22.2.7 編輯自訂角色

按一下自訂角色表中對應的列，然後選取表標題左上方的編輯，即可編輯自訂角色的描

述和許可權。按一下更新角色進行確認。

22.2.8 刪除自訂角色

按一下角色表中對應的列，然後選取刪除可刪除角色。啟用是的，我確定核取方塊，然

後按一下刪除角色進行確認。

22.3 檢視叢集內部

叢集功能表項目可讓您檢視有關 Ceph 叢集主機、OSD、MON、CRUSH 地圖和記錄檔案內

容的詳細資訊。

22.3.1 叢集節點

按一下叢集主機可檢視叢集節點清單。

圖形 22.10︰ HOSTS (主機)

按一下主機名稱欄中的節點名稱可檢視該節點的效能詳細資料。

服務欄中會列出每個相關節點上的所有執行中精靈。按一下精靈名稱可檢視其詳細組

態。

325 編輯自訂角色 SES 6

22.3.2 Ceph 監控程式

按一下叢集監控程式可檢視具有執行中 Ceph 監控程式的叢集節點清單。該清單包含

每個監控程式的階層編號、外部 IP 位址和開啟的工作階段數量。

清單分為兩個表：一個表顯示屬於仲裁成員的 Ceph 監控程式，另一個表顯示不屬於仲

裁成員的 Ceph 監控程式。

按一下名稱欄中的節點名稱可檢視相關的 Ceph 監控程式組態。

狀態表顯示有關執行中 Ceph 監控程式的一般統計資料。

圖形 22.11︰ CEPH 監控程式

22.3.3 Ceph OSD

按一下叢集 OSD 可檢視具有執行中 OSD 精靈/磁碟的節點清單。該清單包含每個節點

的名稱、狀態、放置群組數量、大小、使用率、不同時間的讀取/寫入圖表，以及每秒

讀取/寫入操作次數比率。

326 Ceph 監控程式 SES 6

圖形 22.12︰ CEPH OSD

按一下表標題中的設定叢集範圍的旗標，會開啟一個快顯視窗，其中會列出適用於整個

叢集的旗標。您可以啟用或停用個別旗標，然後按一下提交進行確認。

圖形 22.13︰ OSD 旗標

327 Ceph OSD SES 6

按一下表標題中的設定叢集範圍的復原優先程度，會開啟一個快顯視窗，其中會列出適

用於整個叢集的 OSD 復原優先程度。您可以啟用偏好的優先程度設定檔，並對下面的

個別值進行微調。按一下提交以確認。

圖形 22.14︰ OSD 復原優先程度

按一下主機欄中的節點名稱，可檢視含有 OSD 設定和效能詳細資料的擴充表。您可以

在數個索引標籤之間切換，以便查看屬性、中繼資料、效能計數器清單，以及讀取/寫

入操作次數的圖形長條圖。

328 Ceph OSD SES 6

圖形 22.15︰ OSD 詳細資料

提示：在 OSD 上執行特定任務按一下 OSD 節點名稱後，表中該節點對應的列的色彩會發生細微變化，這表示

您現在可以在該節點上執行任務了。按一下表標題左上方的向下箭頭，然後選取

要執行的任務，例如深層整理。為任務輸入所需的值 (選擇性)，然後確認在節

點上執行該任務。

22.3.4 磁簇組態

按一下叢集組態可檢視 Ceph 叢集組態選項的完整清單。該清單包含選項的名稱、其

簡短描述，以及選項的目前值和預設值。

329 磁簇組態 SES 6

圖形 22.16︰磁簇組態

按一下特定選項列可反白并查看該選項的詳細資訊，例如其數值類型、允許的最大和最

小值、是否可在執行時期更新等等。

反白特定選項後，您可以透過按一下表標題左上方的編輯按鈕來編輯它的值。按一下儲

存確認變更。

22.3.5 CRUSH 地圖

按一下叢集 CRUSH 地圖可檢視叢集的 CRUSH 地圖。如需 CRUSH 地圖的更多一般資

訊，請參閱第 9.5 節「CRUSH 地圖操作」。

按一下根、節點或個別 OSD 可檢視更多詳細資訊，例如 CRUSH 權數、地圖樹狀結構的

深度、OSD 的裝置類別等等。

圖形 22.17︰ CRUSH 地圖

330 CRUSH 地圖 SES 6

22.3.6 管理員模組

按一下叢集管理員模組可檢視可用 Ceph 管理員模組的清單。每行包含模組名稱以及

該模組目前啟用與否的資訊。

圖形 22.18︰管理員模組

反白特定模組後，您可以在下面的詳細資料表中查看其詳細設定。按一下表標題左上方

的編輯按鈕可進行編輯。按一下更新確認變更。

22.3.7 記錄

按一下叢集記錄可檢視叢集的最近記錄項目清單。每行包含一個時戳、記錄項目的類

型及自身所記錄的訊息。

按一下稽核記錄索引標籤可檢視稽核子系統的記錄項目。如需啟用或停用稽核的指令，

請參閱第 22.10.4 節「稽核」。

331 管理員模組 SES 6

圖形 22.19︰記錄

22.4 管理池

提示：池的更多資訊如需 Ceph 池的更多一般資訊，請參閱第 11 章「管理儲存池」。如需糾刪碼

池特定的資訊，請參閱第 13 章「糾刪碼池」。

若要列出所有可用的池，請按一下主功能表中的 Pools (池)。

該清單顯示每個池的名稱、類型、相關應用程式、放置群組狀態、複本大小、糾刪碼設

定檔、使用率，以及讀取/寫入統計資料。

332 管理池 SES 6

圖形 22.20︰池清單

若要檢視有關池的更多詳細資訊，請啟用表中對應的列。

22.4.1 新增新池

若要新增新池，請按一下池表左上方的新增。您可以在池表單中輸入池的名稱、類型、

放置群組數量及其他資訊，例如池的應用程式、壓縮模式和演算法。池表單會自行預先

計算最適合此特定池的放置群組數量。計算以叢集中的 OSD 數量和所選池類型及其特

定設定為依據。如果手動設定了放置群組數量，計算出的數量會取代設定的數量。按一

下建立池進行確認。

333 新增新池 SES 6

圖形 22.21︰新增新池

22.4.2 刪除池

若要刪除某個池，請按一下表中對應的列，然後按一下池表左上方的刪除。

22.4.3 編輯池的選項

若要編輯某個池的選項，請按一下表中對應的列，然後選取池表左上方的編輯。

您可以變更池的名稱、增加放置群組的數量、變更池的應用程式清單和壓縮設定。按一

下編輯池進行確認。

22.5 管理 RADOS 區塊裝置

若要列出所有可用的 RADOS 區塊裝置 (RBD)，請按一下主功能表中的區塊裝置影

像。

334 刪除池 SES 6

該清單顯示有關裝置的簡要資訊，例如裝置的名稱、相關池名稱、裝置大小、裝置上物

件的數量和大小。

圖形 22.22︰ RBD 影像清單

22.5.1 檢視有關 RBD 的詳細資料

若要檢視某部裝置的更多詳細資訊，請按一下表中對應的列：

圖形 22.23︰ RBD 詳細資料

22.5.2 檢視 RBD 的組態

若要檢視某部裝置的詳細組態，請按一下表中對應的列，然後按一下下方表中的組態索

引標籤：

335 檢視有關 RBD 的詳細資料 SES 6

圖形 22.24︰ RBD 組態

22.5.3 建立 RBD

若要新增新裝置，請按一下表標題左上方的新增，然後在建立 RBD 螢幕上執行以下操

作：

336 建立 RBD SES 6

圖形 22.25︰新增新的 RBD

1. 輸入新裝置的名稱。請參閱《部署指南》, 第 2 章「硬體要求和建議」, 第

2.10 節「命名限制」以瞭解命名限制。

337 建立 RBD SES 6

2. 選取要在其中建立新 RBD 裝置且指定了「rbd」應用程式的池。

3. 指定新裝置的大小。

4. 為裝置指定其他選項。若要微調裝置參數，請按一下進階，然後輸入物件大小、

分割單位或分割計數的值。若要輸入服務品質 (QoS) 限制，請按一下服務品質，

然後輸入限制。

5. 按一下建立 RBD 進行確認。

22.5.4 刪除 RBD

若要刪除某部裝置，請按一下表中對應的列，然後選取表標題左上方的刪除按一下刪除

RBD 確認刪除。

提示：將 RBD 移至垃圾桶刪除 RBD 的動作無法復原。如果您選擇將裝置移至垃圾桶，那麼稍後還可以將

其還原，只需在主表的垃圾桶索引標籤上選取該裝置，然後按一下表標題左上方

的還原。

22.5.5 RADOS 區塊裝置快照

若要建立 RADOS 區塊裝置快照，請按一下表中裝置對應的列，然後在主表下的快照索

引標籤中，按一下表標題左上方的建立。輸入快照的名稱，然後按一下建立快照進行確

認。

選取快照後，您可以在裝置上執行其他動作，例如重新命名、保護、克隆、複製或刪

除。復原可根據目前的快照還原裝置的狀態。

圖形 22.26︰ RBD 快照

338 刪除 RBD SES 6

22.5.6 管理 iSCSI 閘道

提示：iSCSI 閘道的更多資訊如需 iSCSI 閘道的更多一般資訊，請參閱《部署指南》, 第 10 章「安裝

iSCSI 閘道」和第 18 章「Ceph iSCSI 閘道」。

若要列出所有可用閘道和對應的影像，請按一下主功能表中的區塊 iSCSI。綜覽索引

標籤即會開啟，列出目前設定的 iSCSI 閘道和對應的 RBD 影像。

閘道表列出每個閘道的狀態、iSCSI 目標數量及工作階段數量。影像表列出每個對應影

像的名稱、相關池名稱、後備儲存類別，以及其他統計資料詳細資訊。

目標索引標籤列出目前設定的 iSCSI 目標。

圖形 22.27︰ ISCSI 目標清單

若要檢視有關某個目標的更多詳細資料，請按一下表中對應的列。一個樹狀結構綱要即

會開啟，列出磁碟、入口網站、啟動器和群組。按一下某一項可將其展開並檢視詳細內

容，右側的表中也可能會顯示其相關組態。

339 管理 iSCSI 閘道 SES 6

圖形 22.28︰ ISCSI 目標詳細資料

22.5.6.1 新增 iSCSI 目標

若要新增新的 iSCSI 目標，請按一下目標表左上方的新增，並輸入所需資訊。


圖形 22.29︰新增新目標

1. 輸入新閘道的目標位址。

2. 按一下新增入口網站，然後從清單中選取一或多個 iSCSI 入口網站。

3. 按一下新增影像，然後為閘道選取一或多個 RBD 影像。

4. 如果您需要使用驗證才能存取閘道，請選取驗證核取方塊並輸入身分證明。選

取雙向驗證和探查驗證之後，您可看到更多進階驗證選項。

5. 按一下建立目標進行確認。

22.5.6.2 編輯 iSCSI 目標

若要編輯某個現有 iSCSI 目標，請按一下目標表中對應的列，然後按一下表左上方

的編輯。

然後，您便可以修改 iSCSI 目標、新增或刪除入口網站，以及新增或刪除相關 RBD 影

像。您還可以調整閘道的驗證資訊。


22.5.6.3 刪除 iSCSI 目標

若要刪除某個 iSCSI 目標，請按一下表中對應的列，然後選取閘道表左上方的刪除。

啟用是的，我確定，然後按一下刪除 iSCSI 進行確認。

22.5.7 RBD 服務品質 (QoS)

提示：更多資訊如需 RBD QoS 組態選項的更多一般資訊和描述，請參閱第 12.6 節「QoS 設

定」。

您可以在不同層級設定 QoS 選項。

全域

基於每個池

基於每個影像

全域組態位於清單頂部，將用於所有新建立的 RBD 影像，以及不會覆寫池或 RBD 影像

層相應值的影像。基於每個池或影像設定的值可能會覆寫全域指定的選項值。對某個

池指定的選項將適用於該池的所有 RBD 影像，除非對影像設定的組態選項覆寫了池選

項。對影像指定的選項將覆寫對池指定的選項以及全域指定的選項。

因此可以如此操作：全域定義預設值，對預設值進行調整以適合特定池的所有 RBD 影

像，然後覆寫個別 RBD 影像的池組態。

22.5.7.1 全域設定選項

若要全域設定 RBD 選項，請在主功能表中選取叢集組態。

若要列出所有可用的全域組態選項，請按一下層級進階。然後在搜尋欄位中過濾

「rbd_qos」，以過濾表的結果。QoS 的所有可用組態選項即會列出。若要變更某個

值，請按一下表中對應的列，然後選取表左上方的編輯。編輯對話方塊包含 6 個不

同的欄位供您指定值。在 mgr 文字方塊中，RBD 組態選項值是必填的。請注意，此對

話方塊與其他對話方塊不同，不允許您使用方便的單位指定值。您只能使用位元組或

IOPS 單位設定這些值，具體取決於您要編輯的選項。

342 RBD 服務品質 (QoS) SES 6

22.5.7.2 對新池設定選項

若要建立新池並對其設定 RBD 組態選項，請按一下池建立。選取複本做為池類型。

然後，您需要將 rbd 應用程式標記新增至池，這樣才能設定 RBD QoS 選項。

注意對於糾刪碼池是無法設定 RBD QoS 組態選項的。若要為糾刪碼池設定 RBD QoS

選項，您需要編輯 RBD 影像的複本中繼資料池。該組態隨後將套用於該影像的

糾刪碼資料池。

22.5.7.3 對現有池設定選項

若要對某個現有池設定 RBD QoS 選項，請按一下池，然後按一下表中該池對應的列，

並選取表左上方的編輯。

對話方塊中應該就會顯示 RBD 組態區段，下方是服務品質區段。

注意如果 RBD 組態和服務品質區段均未顯示，則可能是因為您正在編輯無法用於設

定 RBD 組態選項的糾刪碼池，或該池未設定為供 RBD 影像使用。在下一個案例

中，將為池指定 rbd 應用程式標記，相應的組態區段將會顯示。

22.5.7.4 組態選項

按一下服務品質 + 以展開組態選項。所有可用選項的清單即會顯示。文字方塊中已

顯示組態選項的單位。對於任何每秒位元組數 (BPS) 選項，您可以選擇使用「1M」或

「5G」之類的捷徑。系統會自動將其轉換為對應的「1 MB/s」和「5 GB/s」。

按一下每個文字方塊右側的重設按鈕，將移除對該池設定的所有值。此操作不會移除全

域設定或對 RBD 影像所設定選項的組態值。

343 RBD 服務品質 (QoS) SES 6

22.5.7.5 使用新 RBD 影像建立 RBD QoS 選項

若要建立 RBD 影像並對該影像設定 RBD QoS 選項，請選取區塊影像，然後按一下建

立。按一下進階可展開進階組態區段。按一下服務品質可開啟所有可用組態選項。

22.5.7.6 編輯現有影像的 RBD QoS 選項

若要編輯現有影像的 RBD QoS 選項，請選取區塊影像，然後按一下表中該池對應的

列，最後按一下編輯。編輯對話方塊隨即顯示。按一下進階可展開進階組態區段。按一

下服務品質可開啟所有可用組態選項。

22.5.7.7 在複製或克隆影像時變更組態選項

如果克隆或複製了 RBD 影像，系統預設還會複製對該特定影像設定的值。如果您想在

複製或克隆期間變更這些值，可透過在複製/克隆對話方塊中指定更新的組態值來進行

變更，此程序與建立或編輯 RBD 影像時的方式相同。執行此操作只能設定 (或重設)

所複製或克隆的 RBD 影像的值，無法變更來源 RBD 影像組態，也無法變更全域組態。

如果您選擇在複製/克隆時重設選項值，系統將不會對該影像設定該選項的值。這表示

系統將使用為父池指定的該選項的任何值 (如果為父池設定了相應值)。如果沒有為父

池設定相應值，則將使用全域預設值。

22.5.8 RBD 鏡像

提示：一般資訊如需 RADOS 區塊裝置鏡像的一般資訊和指令行方法，請參閱第 12.4 節「鏡

像」。

您可以使用 Ceph Dashboard 在兩個或更多叢集之間設定 RBD 影像複製。

344 RBD 鏡像 SES 6

22.5.8.1 主要叢集和次要叢集

主要叢集是用於建立包含影像的原始池的叢集。次要叢集是用於從主要叢集複製池/影

像的叢集。

注意：相對命名在複製情境中，主要與次要這兩個術語有可能是相對的，因為相較於叢集來說，

它們與個別池更為相關。例如，在雙向複製中，可將一個池從主要叢集鏡像到次

要叢集，與此同時，也可以將另一個池從次要叢集鏡像到主要叢集。

22.5.8.2 複製模式

資料複製有兩種模式：

使用池模式，您可以複製池中的所有 RBD 影像。

使用影像模式，您可以僅啟用池中特定影像的鏡像。

22.5.8.3 設定 rbd-mirror 精靈

rbd-mirror 精靈負責執行實際的叢集資料複製。若要安裝、設定以及執行該精靈，請

執行以下步驟：

1. 需要在次要叢集管理節點以外的其他某個節點上執行 rbd-mirror 精靈。系統預

設不會安裝該精靈，因此需手動安裝：

root@minion > zypper install rbd-mirror

2. 在主要叢集上，為 rbd-mirror 精靈程序建立唯一的 Ceph 使用者 ID。在此範例

中，我們使用「uid1」做為使用者 ID：

cephadm@adm > ceph auth get-or-create client.rbd-mirror.uid1 \ mon 'profile rbd-mirror' osd 'profile rbd'[client.rbd-mirror.uid1] key = AQBbDJddZKLBIxAAdsmSCCjXoKwzGkGmCpUQ9g==

3. 在您先前安裝了 rbd-mirror 套件的次要叢集節點上，建立該 Ceph 使用者，並

將輸出儲存到金鑰圈：


root@minion > ceph auth get-or-create client.rbd-mirror.uid1 \ mon 'profile rbd-mirror' osd 'profile rbd' \ > /etc/ceph/ceph.client.rbd-mirror.uid1.keyring

4. 在同一節點上，啟用並執行 rbd-mirror 服務：

root@minion > systemctl enable [email protected]@minion > systemctl start [email protected]@minion > systemctl status [email protected]● [email protected] - Ceph rbd mirror daemon Loaded: loaded (/usr/lib/systemd/system/[email protected]; enabled; vendor preset: disabled) Active: active (running) since Fri 2019-10-04 07:48:53 EDT; 2 days ago Main PID: 212434 (rbd-mirror) Tasks: 47 CGroup: /system.slice/system-ceph\x2drbd\x2dmirror.slice/[email protected] └─212434 /usr/bin/rbd-mirror -f --cluster ceph --id rbd-mirror.test --setuser ceph --setgroup ceph

Oct 04 07:48:53 doc-ses6min4 systemd[1]: Started Ceph rbd mirror daemon.

5. 在次要叢集的 Ceph Dashboard 上，導覽至區塊鏡像。精靈表的左側會顯示處

於使用中狀態的執行中 rbd-mirror 精靈及其狀態。

圖形 22.30︰執行中 rbd-mirror 精靈

22.5.8.4 在 Ceph Dashboard 中設定池複製

rbd-mirror 精靈需要擁有主要叢集的存取權，才能鏡像 RBD 影像。因此，您需要在

主要叢集上建立對等 Ceph 使用者帳戶，並告知次要叢集其金鑰圈資訊：

1. 在主要叢集上，建立將用於資料複製的新「client.rbd-mirror-peer」使用者：

cephadm@adm > ceph auth get-or-create client.rbd-mirror-peer \ mon 'profile rbd' osd 'profile rbd'[client.rbd-mirror-peer]


key = AQBbDJddZKLBIxAAdsmSCCjXoKwzGkGmCpUQ9g==

2. 在主要和次要兩個叢集上，建立名稱相同的池，並為其指定「rbd」應用程式。如

需建立新池的更多詳細資料，請參閱第 22.4.1 節「新增新池」。

圖形 22.31︰建立具有 RBD 應用程式的池

3. 在主要和次要兩個叢集的儀表板上，導覽至區塊鏡像。在池表右側按一下要複

製的池的名稱，然後按一下編輯模式，並選取複製模式。在此範例中，我們將使

用池複製模式，也就是說，將複製給定池中的所有影像。按一下更新進行確認。


圖形 22.32︰設定複製模式

重要：主要叢集上的錯誤或警告更新複製模式後，右側相應的欄中會顯示錯誤或警告旗標。這是因為尚未為

池指定用於複製的對等使用者。對於主要叢集，請省略此旗標，因為我們僅

需為次要叢集指定對等使用者。

4. 在次要叢集的儀表板上，導覽至區塊鏡像。按一下要鏡像的池名稱並選取新增

對等，以便將「client.rbd-mirror-peer」使用者金鑰圈註冊到該池中。提供主

要叢集的詳細資料：


圖形 22.33︰新增對等身分證明

叢集名稱

用於識別主要叢集的任意唯一字串，例如「primary」。該叢集名稱不得與實

際環境中次要叢集的名稱相同。

CephX ID

您建立做為鏡像對等的 Ceph 使用者 ID。此範例中為「rbd-mirror-

peer」。

監控程式位址

主要叢集的 Ceph 監控程式節點的 IP 位址/主機名稱逗號分隔清單。

CephX 金鑰

與對等使用者 ID 相關的金鑰。您可以透過在主要叢集上執行以下範例指令

來擷取該金鑰：

cephadm@adm > ceph auth print_key client.rbd-mirror-peer

按一下提交以確認。


圖形 22.34︰複本池清單

22.5.8.5 確認 RBD 影像複製是否有效

如果 rbd-mirror 精靈正在執行，在 Ceph Dashboard 上設定 RBD 影像複製後，就需

要確認複製實際上是否有效：

1. 在主要叢集的 Ceph Dashboard 上建立 RBD 影像，並將您已建立用於複製目的的

池設為其父池。為影像啟用獨佔鎖定和記錄功能。如需如何建立 RBD 影像的詳細

資料，請參閱第 22.5.3 節「建立 RBD」。


圖形 22.35︰新 RBD 影像

2. 建立要複製的影像後，開啟次要叢集的 Ceph Dashboard，並導覽至區塊鏡像。

右側的池表將在遠端數量中所示數量的影像中反映該變更，並會同步本地數量中

所示數量的影像。


圖形 22.36︰同步的新 RBD 影像

提示：複製進度頁面底部的影像表會顯示 RBD 影像的複製狀態。問題索引標籤包含可能的

問題，正在同步索引標籤顯示影像複製的進度，準備就緒索引標籤列出所有

已成功複製的影像。

圖形 22.37︰ RBD 影像的複製狀態

3. 在主要叢集上，將資料寫入 RBD 影像。在次要叢集的 Ceph Dashboard 上，導覽

至區塊影像，並監控相應影像大小的增長是否與主要叢集上寫入的資料一致。


22.6 管理 NFS Ganesha

提示：NFS Ganesha 的更多資訊如需 NFS Ganesha 的更多一般資訊，請參閱第 21 章「NFS Ganesha：透過

NFS 輸出 Ceph 資料」。

若要列出所有可用的 NFS 輸出項，請按一下主功能表中的 NFS。

該清單會顯示每個輸出的目錄、精靈主機名稱、儲存後端類型以及存取類型。

圖形 22.38︰ NFS 輸出項清單

若要檢視某個 NFS 輸出的更多詳細資訊，請按一下表中對應的列。

圖形 22.39︰ NFS 輸出項詳細資料

22.6.1 新增 NFS 輸出項

若要新增新的 NFS 輸出項，請按一下輸出項表左上方的新增並輸入所需的資訊。

353 管理 NFS Ganesha SES 6

圖形 22.40︰新增新的 NFS 輸出項

1. 選取一或多個將執行輸出的 NFS Ganesha 精靈。

2. 選取儲存後端 — CephFS 或物件閘道。

3. 選取使用者 ID 及與後端相關的其他選項。

4. 輸入 NFS 輸出項的目錄路徑。如果該目錄在伺服器上不存在，系統將建立該目

錄。

5. 指定與 NFS 相關的其他選項，例如支援的 NFS 通訊協定版本、虛擬、存取類

型、匿名存取或傳輸通訊協定。

6. 如果您需要設定限制，以便僅允許特定的用戶端存取，請按一下新增用戶端，並

新增它們的 IP 位址以及存取類型和匿名存取選項。

354 新增 NFS 輸出項 SES 6

7. 按一下提交以確認。

22.6.2 刪除 NFS 輸出

若要刪除某個輸出，請按一下表中對應的列，然後選取輸出表左上方的刪除。

22.6.3 編輯 NFS 輸出項

若要編輯某個現有輸出，請按一下表中對應的列，然後按一下輸出表左上方的編輯。

然後，您便可以調整 NFS 輸出項的所有詳細資料。

圖形 22.41︰編輯 NFS 輸出項

355 刪除 NFS 輸出 SES 6

22.7 管理 Ceph 檔案系統

提示：更多資訊若要檢視有關 CephFS 的詳細資訊，請參閱第 19 章「叢集檔案系統」。

22.7.1 檢視 CephFS 綜覽

在主功能表中按一下檔案系統可檢視所設定檔案系統的綜覽。主表會顯示每個檔案系統

的名稱、建立日期，以及檔案系統是否已啟用。

按一下表中某個檔案系統對應的列，可檢視其階層以及新增至其中的池的詳細資料。

圖形 22.42︰ CEPHFS 詳細資料

您可在螢幕底部查看即時收集的相關 MDS Inode 及用戶端要求數量統計資料。

356 管理 Ceph 檔案系統 SES 6

22.8 管理物件閘道

提示：物件閘道的更多資訊如需物件閘道的更多一般資訊，請參閱第 17 章「Ceph 物件閘道」。

22.8.1 檢視物件閘道

若要檢視設定的物件閘道清單，請按一下物件閘道精靈。該清單包含閘道的 ID、執

行閘道精靈的叢集節點的主機名稱，以及閘道的版本號碼。

按一下表中某個閘道對應的列可檢視該閘道的詳細資訊。效能計數器索引標籤顯示有關

讀取/寫入操作及快取統計資料的詳細資料。

圖形 22.43︰閘道的詳細資料

22.8.2 管理物件閘道使用者

按一下物件閘道使用者可檢視現有物件閘道使用者的清單。

357 管理物件閘道 SES 6

按一下表中某個使用者對應的列可檢視該使用者帳戶的詳細資料，例如狀態資訊或使用

者定額及桶定額詳細資料。

圖形 22.44︰閘道使用者

22.8.2.1 新增新閘道使用者

若要新增新閘道使用者，請按一下表標題左上方的新增。填寫其身分證明、有關 S3 金

鑰及使用者/桶定額的詳細資料，然後按一下新增進行確認。

358 管理物件閘道使用者 SES 6

圖形 22.45︰新增新閘道使用者

22.8.2.2 刪除閘道使用者

若要刪除某個閘道使用者，請按一下表中使用者對應的列，然後選取表標題左上方的刪

除。啟用是的，我確定核取方塊，然後按一下刪除使用者進行確認。

22.8.2.3 編輯閘道使用者詳細資料

若要變更閘道使用者詳細資料，請按一下表中使用者對應的列，然後選取表標題左上方

的編輯。

修改基本或附加使用者資訊，例如其功能、金鑰、子使用者和定額資訊。按一下更新進

行確認。

359 管理物件閘道使用者 SES 6

金鑰索引標籤包含唯讀的閘道使用者清單，以及這些使用者的存取金鑰和機密金鑰。若

要檢視這些金鑰，請按一下清單中的使用者名稱，然後選取表標題左上方的顯示。在

S3 金鑰對話方塊中，按一下眼睛圖示可顯示金鑰，按一下剪貼板圖示可將相關金鑰複

製到剪貼板。

22.8.3 管理物件閘道桶

物件閘道 (OGW) 桶實作了 OpenStack Swift 容器的功能。物件閘道桶可充當儲存資料

物件的容器。

按一下物件閘道桶可檢視 OGW 桶清單。

22.8.3.1 新增新的桶

若要新增新 OGW 桶，請按一下表標題左上方的新增。輸入桶的名稱，並選取其擁有

者。請按新增加以確認。

22.8.3.2 檢視桶詳細資料

若要檢視某個 OGW 桶的詳細資訊，請按一下表中對應的列。

360 管理物件閘道桶 SES 6

圖形 22.46︰閘道桶詳細資料

提示：桶定額您可以在詳細資料表下方查看桶定額設定的詳細資料。

22.8.3.3 更新桶的擁有者

按一下表中某個桶對應的列，然後選取表標題左上方的編輯。

更新桶的擁有者，然後按一下更新進行確認。

361 管理物件閘道桶 SES 6

22.8.3.4 刪除桶

若要刪除某個 OGW 桶，請按一下表中對應的列，然後選取表標題左上方的刪除。啟

用是的，我確定核取方塊，然後按一下刪除桶進行確認。

22.9 手動組態本節為更喜歡在指令行上手動組態儀表板設定的使用者提供了進階資訊。

22.9.1 TLS/SSL 支援

所有連至儀表板的 HTTP 連接預設都使用 SSL/TLS 來保障安全。安全連接需要 SSL 證

書。您可以使用自行簽署的證書，也可以產生證書並讓知名證書管理中心 (CA) 簽署該

證書。

提示：停用 SSL您可能會出於某種原因需要停用 SSL 支援。例如，如果儀表板是在不支援 SSL

的代理之後執行。

停用 SSL 要慎重，因為停用 SSL 後，使用者名稱和密碼將以未加密的形式傳送

至儀表板。

若要停用 SSL，請執行以下指令：

cephadm@adm > ceph config set mgr mgr/dashboard/ssl false

提示：重新啟動 Ceph 管理員程序變更 SSL 證書和金鑰後，您需要手動重新啟動 Ceph 管理員程序。您可以透過

執行以下指令

cephadm@adm > ceph mgr failACTIVE-MANAGER-NAME

或停用儀表板模組之後再重新將其啟用的方式來執行此操作，如此還會觸發管理

員自行重新繁衍：

cephadm@adm > ceph mgr module disable dashboard

362 手動組態 SES 6

cephadm@adm > ceph mgr module enable dashboard

22.9.1.1 自行簽署的證書

為了安全通訊而建立自行簽署的證書的過程非常簡單。採用這種方式可迅速讓儀表板執

行起來。

注意：網頁瀏覽器控訴大多數網頁瀏覽器都將對自行簽署的證書發起控訴，並需要在建立與儀表板的安

全連接前進行明確確認。

若要產生並安裝自行簽署的證書，請使用以下內建指令：

cephadm@adm > ceph dashboard create-self-signed-cert

22.9.1.2 CA 簽署的證書

為了正確保障連至儀表板的連接安全，以及消除網頁瀏覽器對自行簽署的證書的控訴，

我們建議使用 CA 簽署的證書。

您可以使用如下指令產生證書金鑰組：

root # openssl req -new -nodes -x509 \ -subj "/O=IT/CN=ceph-mgr-dashboard" -days 3650 \ -keyout dashboard.key -out dashboard.crt -extensions v3_ca

以上指令會輸出 dashboard.key 和 dashboard.key.crt 檔案。獲得 CA 簽署的

dashboard.key.crt 檔案後，請執行以下指令為所有 Ceph 管理員例項啟用該證書：

cephadm@adm > ceph config-key set mgr/dashboard/crt -i dashboard.crtcephadm@adm > ceph config-key set mgr/dashboard/key -i dashboard.key

提示：每個管理員例項使用不同的證書如果您需要為每個 Ceph 管理員例項使用不同的證書，請依如下所示修改指令，

並在其中指定例項的名稱。以 Ceph 管理員例項的名稱 (通常是相關的主機名

稱) 取代 NAME：

363 TLS/SSL 支援 SES 6

cephadm@adm > ceph config-key set mgr/dashboard/NAME/crt -i dashboard.crtcephadm@adm > ceph config-key set mgr/dashboard/NAME/key -i dashboard.key

22.9.2 主機名稱和連接埠號碼

Ceph Dashboard Web 應用程式結合至特定 TCP/IP 位址和 TCP 連接埠。依預設，代管

儀表板的目前使用中 Ceph 管理員會結合至 TCP 連接埠 8443 (如果停用 SSL，則結合

至 8080 連接埠)。

儀表板 Web 應用程式預設結合至「::」，該符號表示所有可用的 IPv4 和 IPv6 位

址。您可以使用以下指令變更 Web 應用程式的 IP 位址和連接埠號碼，以使它們適用

於所有 Ceph 管理員例項：

cephadm@adm > ceph config set mgr mgr/dashboard/server_addr IP_ADDRESScephadm@adm > ceph config set mgr mgr/dashboard/server_port PORT_NUMBER

提示：單獨設定 Ceph 管理員例項因為每個 ceph-mgr 精靈都代管著各自的儀表板例項，您可能需要單獨設定每個

Ceph 管理員例項。使用以下指令 (以 ceph-mgr 例項的 ID 取代 NAME ) 變更特

定管理員例項的 IP 位址和連接埠號碼：

cephadm@adm > ceph config set mgr mgr/dashboard/NAME/server_addr IP_ADDRESScephadm@adm > ceph config set mgr mgr/dashboard/NAME/server_port PORT_NUMBER

提示：列出設定的端點ceph mgr services 指令會顯示目前設定的所有端點。尋找「dashboard」鍵可獲

取用於存取儀表板的 URL。

364 主機名稱和連接埠號碼 SES 6

22.9.3 使用者名稱與密碼

如果您不想使用預設管理員帳戶，可建立其他使用者帳戶，並將其與至少一個角色相關

聯。我們提供了一組預先定義的系統角色供您使用。如需詳細資訊，請參閱第 22.10

節「在指令行上管理使用者和角色」。

若要建立具有管理員權限的使用者，請使用以下指令：

cephadm@adm > ceph dashboard ac-user-create USER_NAME PASSWORD administrator

22.9.4 啟用物件閘道管理前端

若要使用儀表板的物件閘道管理功能，您需要提供啟用了「system」旗標的使用者的登

入身分證明：

1. 如果您沒有帶「system」旗標的使用者，請建立一個：

cephadm@adm > radosgw-admin user create --uid=USER_ID --display-name=DISPLAY_NAME --system

記下指令輸出中的「access_key」和「secret_key」金鑰。

2. 您還可以使用 radosgw-admin 指令來獲取現有使用者的身分證明：

cephadm@adm > radosgw-admin user info --uid=USER_ID

3. 向儀表板提供收到的身分證明：

cephadm@adm > ceph dashboard set-rgw-api-access-key ACCESS_KEYcephadm@adm > ceph dashboard set-rgw-api-secret-key SECRET_KEY

請注意以下幾點事項：

系統會自動確定物件閘道的主機名稱和連接埠號碼。

如果使用多個區域，物件閘道會自動確定主區域群組和主區域內的主機。此方式

足以符合大部分設定的需求，但在某些情況下，您可能需要手動設定主機名稱和

連接埠：

cephadm@adm > ceph dashboard set-rgw-api-host HOST

365 使用者名稱與密碼 SES 6

cephadm@adm > ceph dashboard set-rgw-api-port PORT

您可能需要進行的額外設定如下：

cephadm@adm > ceph dashboard set-rgw-api-scheme SCHEME # http or httpscephadm@adm > ceph dashboard set-rgw-api-admin-resource ADMIN_RESOURCEcephadm@adm > ceph dashboard set-rgw-api-user-id USER_ID

如果您在物件閘道設定中使用的是自行簽署的證書 (第 22.9.1 節「TLS/SSL 支

援」)，請在儀表板中停用證書驗證，以避免發生因證書是由未知 CA 簽署或與主

機名稱不符而導致連接遭拒。

cephadm@adm > ceph dashboard set-rgw-api-ssl-verify False

如果物件閘道處理要求所花的時間過長，導致儀表板逾時，則可調整逾時值 (預

設為 45 秒)：

cephadm@adm > ceph dashboard set-rest-requests-timeout SECONDS

22.9.5 啟用單一登入

單一登入 (SSO) 是一種允許使用者以單個 ID 和密碼同時登入多個應用程式的存取控

制方法。

Ceph Dashboard 支援透過 SAML 2.0 通訊協定對使用者進行外部驗證。由於仍由儀表

板負責進行授權，因此您需要先建立使用者帳戶，並將其與所需角色相關聯。不過，可

由現有身分提供者 (IdP) 來執行驗證。

若要設定單一登入，請使用以下指令：

cephadm@adm > ceph dashboard sso setup saml2 CEPH_DASHBOARD_BASE_URL \ IDP_METADATA IDP_USERNAME_ATTRIBUTE \ IDP_ENTITY_ID SP_X_509_CERT \ SP_PRIVATE_KEY

參數：

CEPH_DASHBOARD_BASE_URL

可用於存取 Ceph Dashboard 的基本 URL (例如「https://

cephdashboard.local」)。

IDP_METADATA

366 啟用單一登入 SES 6

IdP 中繼資料 XML 的 URL、檔案路徑或內容 (例如「https://myidp/

metadata」)。

IDP_USERNAME_ATTRIBUTE

選用。將用於從驗證回應中獲取使用者名稱的屬性。預設為「uid」。

IDP_ENTITY_ID

選用。當 IdP 中繼資料上存在多個實體 ID 時，請使用該參數。

SP_X_509_CERT / SP_PRIVATE_KEY

選用。Ceph Dashboard (服務提供者) 進行簽署和加密時將使用的證書的檔案路

徑或內容。

注意：SAML 要求SAML 要求的發出者值將採用以下格式：

CEPH_DASHBOARD_BASE_URL/auth/saml2/metadata

若要顯示目前的 SAML 2.0 組態，請執行以下指令：

cephadm@adm > ceph dashboard sso show saml2

若要停用單一登入，請執行以下指令：

cephadm@adm > ceph dashboard sso disable

若要檢查是否啟用了 SSO，請執行以下指令：

cephadm@adm > ceph dashboard sso status

若要啟用 SSO，請執行以下指令：

cephadm@adm > ceph dashboard sso enable saml2

22.10 在指令行上管理使用者和角色本節說明如何管理 Ceph Dashboard 使用的使用者帳戶。該工具可協助您建立或修改使

用者帳戶，以及設定正確的使用者角色和許可權。

367 在指令行上管理使用者和角色 SES 6

22.10.1 使用者帳戶

Ceph Dashboard 支援管理多個使用者帳戶。每個使用者帳戶包含使用者名稱、密碼

(使用 bcrypt 以加密形式儲存)、選用名稱和選用電子郵件地址。

系統將使用者帳戶儲存在 Ceph 管理員的組態資料庫中，並在所有 Ceph 管理員例項之

間全域共用該資訊。

使用以下指令可管理使用者帳戶：

顯示現有使用者：

cephadm@adm > ceph dashboard ac-user-show [USERNAME]

建立新使用者：

cephadm@adm > ceph dashboard ac-user-create USERNAME [PASSWORD] [ROLENAME] [NAME] [EMAIL]

刪除使用者：

cephadm@adm > ceph dashboard ac-user-delete USERNAME

更改使用者的密碼:

cephadm@adm > ceph dashboard ac-user-set-password USERNAME PASSWORD

修改使用者名稱和電子郵件：

cephadm@adm > ceph dashboard ac-user-set-info USERNAME NAME EMAIL

22.10.2 使用者角色和許可權

本節介紹您可為使用者角色指定的安全性範圍、如何管理使用者角色，以及如何為使用

者帳戶指定角色。

22.10.2.1 安全性範圍

使用者帳戶與一組角色相關聯，這些角色定義了該使用者可以存取儀表板的哪些部分。

儀表板的各個部分均會劃分在某個安全性範圍內。安全性範圍已預先定義且固定不變。

目前可用的安全性範圍如下：

368 使用者帳戶 SES 6

hosts

包含與主機功能表項目相關的所有功能。

config-opt

包含與 Ceph 組態選項管理相關的所有功能。

pool

包含與池管理相關的所有功能。

osd

包含與 Ceph OSD 管理相關的所有功能。

monitor

包含與 Ceph 監控程式管理相關的所有功能。

rbd-image

包含與 RADOS 區塊裝置影像管理相關的所有功能。

rbd-mirroring

包含與 RADOS 區塊裝置鏡像管理相關的所有功能。

iscsi

包含與 iSCSI 管理相關的所有功能。

rgw

包含與物件閘道管理相關的所有功能。

cephfs

包含與 CephFS 管理相關的所有功能。

manager

包含與 Ceph 管理員管理相關的所有功能。

log

包含與 Ceph 記錄管理相關的所有功能。

grafana

包含與 Grafana 代理相關的所有功能。

dashboard-settings

369 使用者角色和許可權 SES 6

允許變更儀表板設定。

22.10.2.2 使用者職能

角色指定了一個安全性範圍與一組許可權之間的一組對應。許可權分為四種類型：

「read」、「create」、「update」和「delete」。

下面的範例指定了一個角色，具有該角色的使用者擁有池管理相關功能的「read」和

「create」許可權，以及 RBD 影像管理相關功能的完整許可權：

{ 'role': 'my_new_role', 'description': 'My new role', 'scopes_permissions': { 'pool': ['read', 'create'], 'rbd-image': ['read', 'create', 'update', 'delete'] }}

儀表板提供了一組預先定義的角色，我們稱之為系統角色。全新安裝 Ceph Dashboard

後即可使用這些角色：

administrator

提供針對所有安全性範圍的完整許可權。

read-only

提供針對儀表板設定以外的其他所有安全性範圍的 read 許可權。

block-manager

提供針對「rbd-image」、「rbd-mirroring」和「iscsi」範圍的完整許可權。

rgw-manager

提供針對「rgw」範圍的完整許可權。

cluster-manager

提供針對「hosts」、「osd」、「monitor」、「manager」和「config-opt」範

圍的完整許可權。

pool-manager

提供針對「pool」範圍的完整許可權。

cephfs-manager

提供針對「cephfs」範圍的完整許可權。


22.10.2.2.1 管理自訂角色

您可以使用以下指令建立新使用者角色：

建立新角色：

cephadm@adm > ceph dashboard ac-role-create ROLENAME [DESCRIPTION]

刪除角色:

cephadm@adm > ceph dashboard ac-role-delete ROLENAME

新增範圍許可權至角色：

cephadm@adm > ceph dashboard ac-role-add-scope-perms ROLENAME SCOPENAME PERMISSION [PERMISSION...]

從角色中刪除範圍許可權：

cephadm@adm > ceph dashboard ac-role-del-perms ROLENAME SCOPENAME

22.10.2.2.2 為使用者帳戶指定角色

使用以下指令可為使用者指定角色：

設定使用者角色：

cephadm@adm > ceph dashboard ac-user-set-roles USERNAME ROLENAME [ROLENAME ...]

新增其他角色至使用者：

cephadm@adm > ceph dashboard ac-user-add-roles USERNAME ROLENAME [ROLENAME ...]

刪除使用者的角色：

cephadm@adm > ceph dashboard ac-user-del-roles USERNAME ROLENAME [ROLENAME ...]

提示：清除自訂角色如果您建立了自訂使用者角色，並打算以後使用 ceph.purge 執行程式移除

Ceph 叢集，則需要先清除自訂角色。如需更多詳細資料，請參閱第 2.16 節

「移除整個 Ceph 叢集」。


22.10.2.2.3 範例：建立使用者和自訂角色

本節說明建立具有以下功能的使用者帳戶的程序：可管理 RBD 影像、檢視和建立 Ceph

池，並擁有針對任何其他範圍的唯讀存取權。

1. 建立名為「tux」的新使用者：

cephadm@adm > ceph dashboard ac-user-create tux PASSWORD

2. 建立角色並指定範圍許可權：

cephadm@adm > ceph dashboard ac-role-create rbd/pool-managercephadm@adm > ceph dashboard ac-role-add-scope-perms rbd/pool-manager \ rbd-image read create update deletecephadm@adm > ceph dashboard ac-role-add-scope-perms rbd/pool-manager pool read create

3. 將角色與「tux」使用者相關聯：

cephadm@adm > ceph dashboard ac-user-set-roles tux rbd/pool-manager read-only

22.10.3 反向代理

如果您要透過反向代理組態存取儀表板，則可能需要使用 URL 字首來存取。若要讓儀

表板使用包含您字首的超連結，您可以進行 url_prefix 設定：

cephadm@adm > ceph config set mgr mgr/dashboard/url_prefix URL_PREFIX

然後，便可透過網址 http://HOST_NAME:PORT_NUMBER/URL_PREFIX/ 來存取儀表板。

22.10.4 稽核

Ceph Dashboard 的 REST API 可將 PUT、POST 和 DELETE 要求記錄至 Ceph 稽核記錄

中。記錄功能預設處於停用狀態，但您可使用以下指令將其啟用：

cephadm@adm > ceph dashboard set-audit-api-enabled true

如果記錄功能處於啟用狀態，將會記錄每個要求的以下參數：

from

要求的來源，例如「https://[::1]:44410」。

372 反向代理 SES 6

path

REST API 路徑，例如「/api/auth」。

method

「PUT」、「POST」或「DELETE」。

user

使用者的名稱 (或「None」)。

範例記錄項目如下所示：

2019-02-06 10:33:01.302514 mgr.x [INF] [DASHBOARD] \ from='https://[::ffff:127.0.0.1]:37022' path='/api/rgw/user/exu' method='PUT' \ user='admin' params='{"max_buckets": "1000", "display_name": "Example User", "uid": "exu", "suspended": "0", "email": "[email protected]"}'

提示：停用記錄要求封包內容的功能要求封包內容 (引數及其值的清單) 的記錄功能預設處於啟用狀態。您可以依照

如下方式停用該功能：

cephadm@adm > ceph dashboard set-audit-api-log-payload false

373 稽核 SES 6

V 與虛擬化工具整合

23 將 libvirt 與 Ceph 搭配使用 375

24 Ceph 做為 QEMU KVM 例項的後端 381

23 將 libvirt 與 Ceph 搭配使用

libvirt 程式庫在監管程式介面與使用這些介面的軟體應用程式之間建立了一個虛

擬機器抽象層。使用 libvirt，開發人員和系統管理員可將工作重心放在通用管理架

構、通用 API、通用外圍程序介面 ( virsh )，以及諸多不同的監管程式 (包括 QEMU/

KVM、Xen、LXC 或 VirtualBox) 上。

Ceph 區塊裝置支援 QEMU/KVM。您可以透過與 libvirt 連接的軟體來使用 Ceph 區塊

裝置。雲端解決方案使用 libvirt 來與 QEMU/KVM 互動，而 QEMU/KVM 透過 librbd

來與 Ceph 區塊裝置互動。

若要建立使用 Ceph 區塊裝置的虛擬機器，請依以下各節所述的程序操作。在範例中，

我們分別使用了 libvirt-pool、 client.libvirt 和 new-libvirt-image 做為池名稱、

使用者名稱和影像名稱。您可以根據個人喜好使用任何值，但在執行後續程序中的指令

時，請務必取代這些值。

23.1 設定 Ceph

若要將 Ceph 設定為與 libvirt 搭配使用，請執行以下步驟：

1. 建立池。下面的範例使用池名稱 libvirt-pool 和 128 個放置群組。

cephadm@adm > ceph osd pool create libvirt-pool 128 128

驗證該池是否存在。

cephadm@adm > ceph osd lspools

2. 建立 Ceph 使用者。下面的範例使用 Ceph 使用者名稱 client.libvirt 並參考

libvirt-pool。

cephadm@adm > ceph auth get-or-create client.libvirt mon 'profile rbd' osd \ 'profile rbd pool=libvirt-pool'

驗證該名稱是否存在。


375 設定 Ceph SES 6

注意：使用者名稱或 IDlibvirt 將使用 ID libvirt，而不是 Ceph 名稱 client.libvirt 來存

取 Ceph。如需 ID 與名稱之間的差別的詳細說明，請參閱第 8.2.1.1 節

「使用者」。

3. 使用 QEMU 在 RBD 池中建立影像。下面的範例使用影像名稱 new-libvirt-image

並參考 libvirt-pool。

提示：金鑰圈檔案位置libvirt 使用者金鑰儲存在 /etc/ceph 目錄下的金鑰圈檔案中。需要

為金鑰圈檔案指定適當的名稱，其中應包含其所屬 Ceph 叢集的名稱。

如果叢集名稱為預設名稱「ceph」，則金鑰圈檔案名稱為 /etc/ceph/

ceph.client.libvirt.keyring。

如果該金鑰圈不存在，請使用以下指令建立它：

cephadm@adm > ceph auth get client.libvirt > /etc/ceph/ceph.client.libvirt.keyring

root # qemu-img create -f raw rbd:libvirt-pool/new-libvirt-image:id=libvirt 2G

驗證該影像是否存在。

cephadm@adm > rbd -p libvirt-pool ls

23.2 準備虛擬機器管理員

雖然您可以單獨使用 libvirt，而不藉助虛擬機器管理員，但您可能會發現，使用

virt-manager 來建立第一個網域會更簡單。

1. 安裝虛擬機器管理員。

root # zypper in virt-manager

376 準備虛擬機器管理員 SES 6

2. 準備/下載要執行虛擬化的系統的 OS 影像。

3. 啟動虛擬機器管理員。

virt-manager

23.3 建立虛擬機器

若要使用 virt-manager 建立虛擬機器，請執行以下步驟：

1. 從清單中選擇連接，在其上按一下滑鼠右鍵，然後選取新增。

2. 透過提供現有儲存的路徑來輸入現有的磁碟影像。指定 OS 類型和記憶體設定，

並為虛擬機器命名，例如 libvirt-virtual-machine。

3. 完成組態並啟動虛擬機器。

4. 使用 sudo virsh list 驗證新建立的網域是否存在。如果需要，請指定連接字

串，例如

virsh -c qemu+ssh://root@vm_host_hostname/system listId Name State-----------------------------------------------[...] 9 libvirt-virtual-machine running

5. 在將虛擬機器設定為與 Ceph 搭配使用前，登入虛擬機器並將其停止。

23.4 設定虛擬機器

本章重點介紹如何使用 virsh 設定虛擬機器，以與 Ceph 整合。 virsh 指令通常需

要 root 特權 ( sudo )，它不會傳回相應的結果，也不會告知您需要 root 特權。如需

virsh 指令的參考資訊，請參閱 man 1 virsh (需要安裝 libvirt-client )。

1. 使用 virsh edit vm-domain-name 開啟組態檔案。

root # virsh edit libvirt-virtual-machine

377 建立虛擬機器 SES 6

2. <devices> 下面應該包含 <disk> 項目。

<devices> <emulator>/usr/bin/qemu-system-x86_64</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/path/to/image/recent-linux.img'/> <target dev='vda' bus='virtio'/> <address type='drive' controller='0' bus='0' unit='0'/> </disk>

以 OS 影像的路徑取代 /path/to/image/recent-linux.img。

重要請使用 sudo virsh edit，不要使用文字編輯器。如果使用文字編輯器編輯

/etc/libvirt/qemu 下的組態檔案， libvirt 可能無法辨識變更。如果 /

etc/libvirt/qemu 下的 XML 檔案內容與 sudo virsh dumpxml vm-domain-

name 傳回的結果有差異，則表示虛擬機器可能沒有正常運作。

3. 將先前建立的 Ceph RBD 影像新增為 <disk> 項目。

<disk type='network' device='disk'> <source protocol='rbd' name='libvirt-pool/new-libvirt-image'> <host name='monitor-host' port='6789'/> </source> <target dev='vda' bus='virtio'/></disk>

以您主機的名稱取代 monitor-host，並視需要取代池名稱和/或影像名稱。您可

為 Ceph 監控程式新增多個 <host> 項目。 dev 屬性是邏輯裝置名稱，將顯示在

虛擬機器的 /dev 目錄下。選擇性 bus 屬性表示要模擬的磁碟裝置類型。有效的

設定都是驅動程式特定的 (例如 ide、scsi、virtio、xen、usb 或 sata)。

4. 儲存檔案。

5. 如果 Ceph 叢集已啟用驗證 (預設會啟用)，您必須產生一個機密。開啟所選的編

輯器，並建立包含以下內容的 secret.xml 檔案：

<secret ephemeral='no' private='no'> <usage type='ceph'> <name>client.libvirt secret</name> </usage></secret>

378 設定虛擬機器 SES 6

6. 定義機密。

root # virsh secret-define --file secret.xml<uuid of secret is output here>

7. 獲取 client.libvirt 金鑰，並將金鑰字串儲存到某個檔案中。

cephadm@adm > ceph auth get-key client.libvirt | sudo tee client.libvirt.key

8. 設定機密的 UUID。

root # virsh secret-set-value --secret uuid of secret \--base64 $(cat client.libvirt.key) && rm client.libvirt.key secret.xml

此外，必須透過將以下 <auth> 項目新增至前面輸入的 <disk> 元素 (請以上述

指令行範例的結果取代 uuid 值)，來手動設定機密。

root # virsh edit libvirt-virtual-machine

然後，將 <auth></auth> 元素新增至網域組態檔案：

...</source><auth username='libvirt'> <secret type='ceph' uuid='9ec59067-fdbc-a6c0-03ff-df165c0587b8'/></auth><target ...

注意示範的 ID 為 libvirt，而不是在第 23.1 節「設定 Ceph」的步驟 2 中

產生的 Ceph 名稱 client.libvirt。請務必使用所產生 Ceph 名稱的 ID

組成部分。如果您出於某個原因需要重新產生機密，則在再次執行 sudo

virsh secret-set-value 之前，需要執行 sudo virsh secret-undefine

uuid。

23.5 總結設定要與 Ceph 搭配使用的虛擬機器之後，便可啟動該虛擬機器。若要驗證虛擬機器與

Ceph 是否可相互通訊，可執行以下程序。

379 總結 SES 6

1. 檢查 Ceph 是否在執行：

cephadm@adm > ceph health

2. 檢查虛擬機器是否在執行：

root # virsh list

3. 檢查虛擬機器是否在與 Ceph 通訊。以虛擬機器網域的名稱取代 vm-domain-

name：

root # virsh qemu-monitor-command --hmp vm-domain-name 'info block'

4. 檢查 /dev 或 /proc/partitions 下是否存在 &target dev='hdb' bus='ide'/>

中的裝置：

tux > ls /devtux > cat /proc/partitions

380 總結 SES 6

24 Ceph 做為 QEMU KVM 例項的後端

最常見的 Ceph 使用案例涉及到向虛擬機器提供區塊裝置影像。例如，在理想的組態

中，使用者可以建立包含 OS 和所有相關軟體的「黃金」影像。然後，使用者可以建立

該影像的快照。最後，使用者可以複製該快照 (通常要複製多次，如需詳細資料，請參

閱第 12.3 節「快照」)。能夠建立快照的寫入時複製複製品，就表示 Ceph 能夠快速

向虛擬機器佈建區塊裝置影像，因為用戶端不需要在每次運轉新的虛擬機器時都下載整

個影像。

Ceph 區塊裝置可與 QEMU 虛擬機器相整合。如需 QEMU KVM 的詳細資訊，

請參閱 https://www.suse.com/documentation/sles-15/book_virt/data/

part_virt_qemu.html 。

24.1 安裝若要使用 Ceph 區塊裝置，需在 QEMU 上安裝相應的驅動程式。請檢查是否已安裝

qemu-block-rbd 套件，若未安裝，則予以安裝：

root # zypper install qemu-block-rbd

24.2 用法使用 QEMU 指令行時，您需要指定池名稱和影像名稱。您也可以指定快照名稱。

qemu-img command options \rbd:pool-name/image-name@snapshot-name:option1=value1:option2=value2...

例如，可依如下所示指定 id 和 conf 選項：

qemu-img command options \rbd:pool_name/image_name:id=glance:conf=/etc/ceph/ceph.conf

24.3 使用 QEMU 建立影像您可以透過 QEMU 建立區塊裝置影像。必須指定 rbd、池名稱，以及要建立的影像名

稱。此外，還必須指定影像的大小。

381 安裝 SES 6

https://www.suse.com/documentation/sles-15/book_virt/data/part_virt_qemu.html

https://www.suse.com/documentation/sles-15/book_virt/data/part_virt_qemu.html

qemu-img create -f raw rbd:pool-name/image-name size

例如：

qemu-img create -f raw rbd:pool1/image1 10GFormatting 'rbd:pool1/image1', fmt=raw size=10737418240 nocow=off cluster_size=0

重要事實上， raw 資料格式是可對 RBD 使用的唯一合理格式選項。從技術上講，您

也可以使用 QEMU 支援的其他格式 (例如 qcow2 )，但這會增加額外的負擔，如

果啟用了快取，還會在即時移轉虛擬機器時讓磁碟區變得不安全。

24.4 使用 QEMU 調整影像大小您可以透過 QEMU 調整區塊裝置影像的大小。必須指定 rbd、池名稱，以及要調整大

小的影像名稱。此外，還必須指定影像的大小。

qemu-img resize rbd:pool-name/image-name size

例如：

qemu-img resize rbd:pool1/image1 9GImage resized.

24.5 使用 QEMU 擷取影像資訊您可以透過 QEMU 擷取區塊裝置影像的資訊。必須指定 rbd、池名稱和影像名稱。

qemu-img info rbd:pool-name/image-name

例如：

qemu-img info rbd:pool1/image1image: rbd:pool1/image1file format: rawvirtual size: 9.0G (9663676416 bytes)disk size: unavailablecluster_size: 4194304

382 使用 QEMU 調整影像大小 SES 6

24.6 使用 RBD 執行 QEMUQEMU 可以透過 librbd 直接將影像做為虛擬區塊裝置來存取。這可以避免額外的網路

位置切換，並可利用 RBD 快取的優勢。

您可以使用 qemu-img 將現有的虛擬機器影像轉換成 Ceph 區塊裝置影像。例如，如果

您有一個 qcow2 影像，則可以執行：

qemu-img convert -f qcow2 -O raw sles12.qcow2 rbd:pool1/sles12

若要執行從該影像開機的虛擬機器，您可以執行：

root # qemu -m 1024 -drive format=raw,file=rbd:pool1/sles12

RBD 快取可大幅提高效能。QEMU 的快取選項可控制 librbd 快取：

root # qemu -m 1024 -drive format=rbd,file=rbd:pool1/sles12,cache=writeback

如需 RBD 快取的詳細資訊，請參閱第 12.5 節「快取記憶體設定」。

24.7 啟用丟棄功能/TRIMCeph 區塊裝置支援丟棄操作。這表示客體可以傳送 TRIM 要求，以便讓 Ceph 區塊裝

置回收未使用的空間。可以透過結合丟棄選項掛接 XFS，在客體中啟用此功能。

若要讓客體可使用此功能，必須明確為區塊裝置啟用此功能。為此，您必須指定與磁碟

機關聯的 discard_granularity：

root # qemu -m 1024 -drive format=raw,file=rbd:pool1/sles12,id=drive1,if=none \-device driver=ide-hd,drive=drive1,discard_granularity=512

注意上面的範例使用 IDE 驅動程式。Virtio 驅動程式不支援丟棄功能。

如果您在使用 libvirt，請使用 virsh edit 編輯 libvirt 網域的組態檔案，以包含

xmlns:qemu 值。然後，將 qemu:commandline block 新增為該網域的子級。下面的範例

展示如何將包含 qemu id= 的兩部裝置設定為不同的 discard_granularity 值。

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>

383 使用 RBD 執行 QEMU SES 6

<qemu:commandline> <qemu:arg value='-set'/> <qemu:arg value='block.scsi0-0-0.discard_granularity=4096'/> <qemu:arg value='-set'/> <qemu:arg value='block.scsi0-0-1.discard_granularity=65536'/> </qemu:commandline></domain>

24.8 QEMU 快取選項

QEMU 的快取選項與以下 Ceph RBD 快取設定對應。

寫回：

rbd_cache = true

寫入：

rbd_cache = truerbd_cache_max_dirty = 0

無：

rbd_cache = false

QEMU 的快取設定會覆寫 Ceph 的預設設定 (未在 Ceph 組態檔案中明確指定的設定)。

如果在 Ceph 組態檔案中明確指定了 RBD 快取設定 (請參閱第 12.5 節「快取記憶體

設定」)，您的 Ceph 設定將會覆寫 QEMU 快取設定。如果您在 QEMU 指令行中指定了

快取設定，則 QEMU 指令行設定會覆寫 Ceph 組態檔案設定。

384 QEMU 快取選項 SES 6

VI FAQ、提示和故障診斷

25 技巧與提示 386

26 常見問答集 402

27 疑難排解 405

25 技巧與提示

本章提供可協助您增強 Ceph 叢集效能的資訊，以及有關如何設定叢集的提示。

25.1 識別未同步分割區

若要識別可能處於未同步狀態的記錄/WAL/DB 裝置，請執行以下步驟：

1. 選取可能存在孤立分割區的裝置，並將其分割區清單儲存到檔案中：

root@minion > ls /dev/sdd?* > /tmp/partitions

2. 針對所有 block.wal、block.db 和記錄裝置執行 readlink，並將輸出與先前儲

存的分割區清單進行比較：

root@minion > readlink -f /var/lib/ceph/osd/ceph-*/{block.wal,block.db,journal} \ | sort | comm -23 /tmp/partitions -

輸出內容為 Ceph 未使用的分割區清單。

3. 使用您偏好的指令 (例如 fdisk、 parted 或 sgdisk ) 移除不屬於 Ceph 的未同

步分割區。

25.2 調整整理

依預設，Ceph 每天會執行一次淺層整理 (請參閱第 9.6 節「整理」以瞭解詳細資

料)，每週會執行一次深層整理。淺層整理會檢查物件大小與檢查總數，以確定放置群

組儲存的是相同的物件資料。深層整理會檢查物件的內容及其複本，以確定實際內容相

同。在整理期間檢查資料完整性會增加叢集上的 I/O 負載。

預設設定允許 Ceph OSD 在不合適的時間 (如負載較重時) 啟動整理。當整理操作與客

戶操作發生衝突時，可能會出現延遲和效能不佳情況。Ceph 提供了數個整理設定，可

將整理限制在低負載或非峰值時段執行。

如果叢集在日間負載高而在夜間負載低，請考慮將整理限制在夜間執行，例如在晚上

11 點到早上 6 點期間執行。

386 識別未同步分割區 SES 6

[osd]osd_scrub_begin_hour = 23osd_scrub_end_hour = 6

如果使用時間限制無法有效決定整理排程，請考慮使用 osd_scrub_load_threshold 選

項。其預設值為 0.5，但也可針對低負載情況進行相應調整：

[osd]osd_scrub_load_threshold = 0.25

25.3 在不重新平衡的情況下停止 OSD

進行定期維護時，您可能需要停止 OSD。如果您不希望 CRUSH 自動重新平衡叢集，以

免出現大量資料傳輸，請先將叢集設為 noout：

root@minion > ceph osd set noout

當叢集設為 noout 時，您便可開始在需要執行維護工作的故障網域中停止 OSD：

root@minion > systemctl stop ceph-osd@OSD_NUMBER.service

如需詳細資訊，請參閱第 5.1.2 節「啟動、停止和重新啟動個別服務」。

完成維護工作後，再次啟動 OSD：

root@minion > systemctl start ceph-osd@OSD_NUMBER.service

OSD 服務啟動後，取消叢集的 noout 設定：

cephadm@adm > ceph osd unset noout

25.4 節點時間同步

Ceph 要求所有節點之間的時間都保持精確同步。

我們建議將所有 Ceph 叢集節點與內部網路上至少三個可靠的時間來源進行同步。內部

時間來源可指向公用時間伺服器，或使用自己的時間來源。

387 在不重新平衡的情況下停止 OSD SES 6

重要：公用時間伺服器不要將所有 Ceph 叢集節點直接與遠端公用時間伺服器同步。如果採用這種組

態，叢集中的每個節點都會憑藉自己的 NTP 精靈透過網際網路持續與三到四部

時間伺服器通訊，而這些伺服器提供的時間可能會稍有不同。此解決方案在很大

程度上帶來了延遲方面的變數，使得難以甚至無法將時鐘偏差保持在 0.05 秒以

下 (Ceph 監控程式要求這種精度)。

如需如何設定 NTP 伺服器的詳細資料，請參閱《SUSE Linux Enterprise Server 管

理指南》 (https://www.suse.com/documentation/sles-15/book_sle_admin/data/

cha_ntp.html) 。

若要變更叢集上的時間，請執行以下操作：

重要：設定時間您可能會遇到需要將時間往回調的情況，例如，當時間從夏令時改成標準時間時

就需要如此。不建議將時間回調的幅度超過叢集的關閉時長。將時間往前調不會

造成任何問題。

程序 25.1︰叢集上的時間同步

1. 停止正在存取 Ceph 叢集的所有用戶端，尤其是使用 iSCSI 的用戶端。

2. 關閉 Ceph 叢集。在每個節點上，執行：

root # systemctl stop ceph.target

注意如果您使用了 Ceph 和 SUSE OpenStack Cloud，則還需停止 SUSE

OpenStack Cloud。

3. 確認 NTP 伺服器的設定是否正確，即所有 chronyd 精靈是否可從本地網路中的

一或多個時間來源獲取時間。

4. 在 NTP 伺服器上設定正確的時間。

5. 確認 NTP 正在執行且在正常運作，然後在所有節點上執行：

388 節點時間同步 SES 6

https://www.suse.com/documentation/sles-15/book_sle_admin/data/cha_ntp.html



root # systemctl status chronyd.service

6. 啟動所有監控節點，並確認不存在時鐘偏差：

root # systemctl start target

7. 啟動所有 OSD 節點。

8. 啟動其他 Ceph 服務。

9. 啟動 SUSE OpenStack Cloud (如果有)。

25.5 檢查不均衡的資料寫入

如果資料均衡寫入 OSD，則認為叢集是平衡的。系統會為叢集中的每個 OSD 指定一

個權數。權數是一個相對數字，告知 Ceph 應寫入相關 OSD 的資料量。權數越高，要

寫入的資料就越多。如果 OSD 的權數為零，則不會向其寫入任何資料。如果某個 OSD

的權數相對於其他 OSD 而言較高，則大部分資料將會寫入這個 OSD，致使叢集變得不

平衡。

不平衡叢集的效能較差。如果某個權數較高的 OSD 突然當機，則大量的資料就需要轉

移到其他 OSD，這也會導致叢集速度變慢。

為避免此問題，您應該定期檢查 OSD 中的資料寫入量。如果寫入量介於給定規則集所

指定 OSD 群組容量的 30% 到 50% 之間，則您需要重新設定 OSD 的權數。檢查各個磁

碟，找出其中哪些磁碟的填滿速度比其他磁碟更快 (或者一般情況下速度更慢)，並降

低其權數。對於資料寫入量不足的 OSD，可以採用相同的思路：可以提高其權數，讓

Ceph 將更多的資料寫入其中。在下面的範例中，您將確定 ID 為 13 的 OSD 的權數，

並將權數從 3 重新設定為 3.05：

$ ceph osd tree | grep osd.13 13 3 osd.13 up 1

$ ceph osd crush reweight osd.13 3.05 reweighted item id 13 name 'osd.13' to 3.05 in crush map

$ ceph osd tree | grep osd.13 13 3.05 osd.13 up 1

389 檢查不均衡的資料寫入 SES 6

提示：依使用率重新設定 OSD 的權數ceph osd reweight-by-utilization threshold 指令可自動完成降低嚴重過度使

用的 OSD 權數的過程。依預設，此指令將對達到平均使用率的 120% 的 OSD 降

低權數，但是，如果您指定了閾值，則指令會使用該百分比。

25.6 Ceph 監控程式節點上 /var/lib/ceph 的

Btrfs 子磁碟區SUSE Linux Enterprise 預設安裝在 Btrfs 分割區中。Ceph 監控程式將其狀態和資料

庫儲存在 /var/lib/ceph 目錄下。為防止 Ceph 監控程式因基於之前某個快照進行的

系統復原而損毀，請為 /var/lib/ceph 建立 Btrfs 子磁碟區。專屬子磁碟區會從根子

磁碟區的快照中排除監控程式資料。

提示請在執行 DeepSea 階段 0 之前建立 /var/lib/ceph 子磁碟區，因為階段 0 會

安裝與 Ceph 相關的套件，並建立 /var/lib/ceph 目錄。

隨後，DeepSea 階段 3 會驗證 @/var/lib/ceph 是否為 Btrfs 子磁碟區，如果它是普

通目錄，則驗證將失敗。

25.6.1 要求

25.6.1.1 新部署

需正確安裝 Salt 和 DeepSea，並確定它們正常運作。

25.6.1.2 現有部署

如果您已安裝好叢集，則必須符合以下要求：

390 Ceph 監控程式節點上 /var/lib/ceph 的 Btrfs 子磁碟區 SES 6

已將節點升級至 SUSE Enterprise Storage 6，並且叢集受 DeepSea 的控制。

Ceph 叢集已啟動且正常執行。

升級程序已將 Salt 和 DeepSea 模組同步到所有 Minion 節點。

25.6.2 部署新叢集時所需執行的步驟

25.6.2.1 執行 DeepSea 階段 0 之前

在執行 DeepSea 階段 0 之前，請對將充當 Ceph 監控程式的每個 Salt Minion 套用

以下指令：

root@master # salt 'MONITOR_NODES' saltutil.sync_allroot@master # salt 'MONITOR_NODES' state.apply ceph.subvolume

ceph.subvolume 指令會執行以下操作：

建立 /var/lib ceph，以做為 @/var/lib/ceph Btrfs 子磁碟區。

掛接該新子磁碟區，並相應地更新 /etc/fstab。

25.6.2.2 DeepSea 階段 3 驗證失敗

如果您忘記在執行階段 0 之前執行第 25.6.2.1 節「執行 DeepSea 階段 0 之前」所

述的指令，而 /var/lib/ceph 子目錄已存在，則 DeepSea stage 3 驗證會失敗。若要

將該子目錄轉換為子磁碟區，請執行以下操作：

1. 切換到 /var/lib 目錄：

cephadm@mon > cd /var/lib

2. 備份 ceph 子目錄的目前內容：

cephadm@mon > sudo mv ceph ceph-

3. 建立並掛接子磁碟區，然後更新 /etc/fstab：

391 部署新叢集時所需執行的步驟 SES 6

root@master # salt 'MONITOR_NODES' state.apply ceph.subvolume

4. 切換到備份子目錄，將其內容與新子磁碟區進行同步，然後將其移除：

cephadm@mon > cd /var/lib/ceph-cephadm@mon > rsync -av . ../cephcephadm@mon > cd ..cephadm@mon > rm -rf ./ceph-

25.6.3 升級叢集時所需執行的步驟

在 SUSE Enterprise Storage 5.5 上， /var 目錄不在 Btrfs 子磁碟區上，但其子資

料夾 (例如 /var/log 或 /var/cache ) 是「@」下的 Btrfs 子磁碟區。建立 @/var/

lib/ceph 子磁碟區需要先掛接「@」子磁碟區 (預設未掛接)，然後在其下建立 @/var/

lib/ceph 子磁碟區。

下面的範例指令闡述了該過程：

root # mkdir -p /mnt/btrfsroot # mount -o subvol=@ ROOT_DEVICE /mnt/btrfsroot # btrfs subvolume create /mnt/btrfs/var/lib/cephroot # umount /mnt/btrfs

此時，即已建立 @/var/lib/ceph 子磁碟區，您可以依第 25.6.2 節「部署新叢集時

所需執行的步驟」中所述繼續操作。

25.6.4 手動安裝

在 Ceph 監控程式節點上自動設定 @/var/lib/ceph Btrfs 子磁碟區可能並不適用於所

有情境。您可以執行以下步驟將您的 /var/lib/ceph 目錄移轉至 @/var/lib/ceph 子

磁碟區：

1. 終止執行中 Ceph 程序。

2. 卸載節點上的 OSD。

3. 切換到備份子目錄，將其內容與新子磁碟區進行同步，然後將其移除：

cephadm@mon > cd /var/lib/ceph-

392 升級叢集時所需執行的步驟 SES 6

cephadm@mon > rsync -av . ../cephcephadm@mon > cd ..cephadm@mon > rm -rf ./ceph-

4. 重新掛接 OSD。

5. 重新啟動 Ceph 精靈。

25.6.5 更多資訊

如需手動設定的詳細資訊，請參閱 Salt Master 節點上的 /srv/salt/ceph/subvolume/

README.md 檔案。

25.7 增加檔案描述子

對於 OSD 精靈而言，讀取/寫入操作對保持 Ceph 叢集平衡至關重要。這些精靈往往需

要同時開啟許多檔案以進行讀取和寫入。在 OS 層級，同時開啟的檔案的最大數量稱為

「檔案描述子的最大數量」。

為防止 OSD 用盡檔案描述子，您可以覆寫 OS 預設值，並在 /etc/ceph/ceph.conf 中

指定該數量，例如：

max_open_files = 131072

變更 max_open_files 之後，您需要在相關的 Ceph 節點上重新啟動 OSD 服務。

25.8 與虛擬化軟體整合

25.8.1 在 Ceph 叢集中儲存 KVM 磁碟

您可為 KVM 驅動的虛擬機器建立磁碟影像，將該影像儲存在 Ceph 池中，選擇性地將

某個現有影像的內容轉換到該影像，然後使用 qemu-kvm 執行虛擬機器，以利用叢集

中儲存的磁碟影像。如需詳細資訊，請參閱第 24 章「Ceph 做為 QEMU KVM 例項的後

端」。

393 更多資訊 SES 6

25.8.2 在 Ceph 叢集中儲存 libvirt 磁碟

與 KVM (請參閱第 25.8.1 節「在 Ceph 叢集中儲存 KVM 磁碟」) 類似，您可以使用

Ceph 來儲存 libvirt 驅動的虛擬機器。這樣做的好處是可以執行任何支援 libvirt

的虛擬化解決方案，例如 KVM、Xen 或 LXC。如需詳細資訊，請參閱第 23 章「將

libvirt 與 Ceph 搭配使用」。

25.8.3 在 Ceph 叢集中儲存 Xen 磁碟

使用 Ceph 儲存 Xen 磁碟的方法之一是依第 23 章「將 libvirt 與 Ceph 搭配使

用」所述利用 libvirt。

另一種方法是讓 Xen 直接與 rbd 區塊裝置驅動程式通訊：

1. 如果您尚未為 Xen 準備磁碟影像，請建立一個新影像：

cephadm@adm > rbd create myimage --size 8000 --pool mypool

2. 列出 mypool 池中的影像，並檢查您的新影像是否在該池中：

cephadm@adm > rbd list mypool

3. 透過將 myimage 影像對應至 rbd 核心模組來建立一個新區塊裝置：

cephadm@adm > rbd map --pool mypool myimage

提示：使用者名稱和驗證若要指定使用者名稱，請使用 --id user-name。此外，如果您使用了

cephx 驗證，則還必須指定機密。該機密可能來自金鑰圈，或某個包含機

密的檔案：

cephadm@adm > rbd map --pool rbd myimage --id admin --keyring /path/to/keyring

或

cephadmrbd map --pool rbd myimage --id admin --keyfile /path/to/file

4. 列出所有對應的裝置：

394 在 Ceph 叢集中儲存 libvirt 磁碟 SES 6

rbd showmapped id pool image snap device 0 mypool myimage - /dev/rbd0

5. 現在，您可以將 Xen 設定為使用此裝置做為執行虛擬機器所用的磁碟。例如，可

將下行新增至 xl 樣式的網域組態檔案：

disk = [ '/dev/rbd0,,sda', '/dev/cdrom,,sdc,cdrom' ]

25.9 Ceph 的防火牆設定

警告：使用防火牆時，DeepSea 階段失敗當防火牆處於使用中狀態 (甚至只是設定了防火牆) 時，DeepSea 部署階段會失

敗。若要正確完成該階段，需要執行以下指令關閉防火牆

root # systemctl stop SuSEfirewall2.service

或在 /srv/pillar/ceph/stack/global.yml 中將 FAIL_ON_WARNING 選項設為

「False」：

FAIL_ON_WARNING: False

建議使用 SUSE 防火牆來保護網路叢集通訊。您可以透過選取 YaST 安全性和使用

者防火牆允許的服務，來編輯防火牆的組態。

下面列出了 Ceph 相關服務以及這些服務通常使用的連接埠號碼：

Ceph 監控程式

啟用 Ceph MON 服務或連接埠 6789 (TCP)。

Ceph OSD 或中繼資料伺服器

啟用 Ceph OSD/MDS 服務或連接埠 6800-7300 (TCP)。

iSCSI 閘道

開啟連接埠 3260 (TCP)。

物件閘道

395 Ceph 的防火牆設定 SES 6

開啟物件閘道通訊所用的連接埠。可在 /etc/ceph.conf 內以 rgw frontends =

開頭的行中設定此連接埠。HTTP 的預設連接埠為 80，HTTPS (TCP) 的預設連接

埠為 443。

NFS Ganesha

依預設，NFS Ganesha 使用連接埠 2049 (NFS 服務、TCP) 和 875 (rquota 支

援、TCP)。如需變更預設 NFS Ganesha 連接埠的詳細資訊，請參閱第 21.2.1.4

節「變更預設 NFS Ganesha 連接埠」。

以 Apache 為基礎的服務 (例如 SMT) 或 SUSE Manager

開啟用於 HTTP 的連接埠 80，用於 HTTPS (TCP) 的連接埠 443。

SSH


NTP

開啟連接埠 123 (UDP)。

Salt

開啟連接埠 4505 和 4506 (TCP)。

Grafana


Prometheus


25.10 測試網路效能

為方便測試網路效能，DeepSea 的 net 執行程式提供了以下指令：

向所有節點發出簡單的 ping：

root@master # salt-run net.pingSucceeded: 9 addresses from 9 minions average rtt 1.35 ms

向所有節點發出大規模的 ping：

root@master # salt-run net.jumbo_ping

396 測試網路效能 SES 6

Succeeded: 9 addresses from 9 minions average rtt 2.13 ms

頻寬測試：

root@master # salt-run net.iperfFastest 2 hosts: |_ - 192.168.58.106 - 2981 Mbits/sec |_ - 192.168.58.107 - 2967 Mbits/secSlowest 2 hosts: |_ - 192.168.58.102 - 2857 Mbits/sec |_ - 192.168.58.103 - 2842 Mbits/sec

提示：手動停止「iperf3」程序使用 net.iperf 執行程式執行測試時，所啟動的「iperf3」伺服器程序不

會在測試完成時自動停止。若要停止這些程序，請使用以下執行程式：

root@master # salt '*' multi.kill_iperf_cmd

25.11 如何尋找使用 LED 燈的實體磁碟本節介紹如何使用 libstoragemgmt 和/或協力廠商工具調整實體磁碟上的 LED 燈。可

能並非所有硬體平台都支援此功能。

將 OSD 磁碟與實體磁碟保持相符是項困難的工作，對磁碟密度較高的節點來說尤

為如此。在一些具有 LED 燈的硬體環境中，可使用軟體調整 LED 燈，使其以不

同的色彩閃爍或發光，從而達到方便識別的目的。SUSE Enterprise Storage 透過

Salt、 libstoragemgmt 和特定於所用硬體的協力廠商工具來提供此功能支援。可在 /

srv/pillar/ceph/disk_led.sls Salt Pillar 中定義此功能的組態：

root # cat /srv/pillar/ceph/disk_led.sls# This is the default configuration for the storage enclosure LED blinking.# The placeholder {device_file} will be replaced with the device file of# the disk when the command is executed.

397 如何尋找使用 LED 燈的實體磁碟 SES 6

## Have a look into the /srv/pillar/ceph/README file to find out how to# customize this configuration per minion/host.

disk_led: cmd: ident: 'on': lsmcli local-disk-ident-led-on --path '{device_file}' 'off': lsmcli local-disk-ident-led-off --path '{device_file}' fault: 'on': lsmcli local-disk-fault-led-on --path '{device_file}' 'off': lsmcli local-disk-fault-led-off --path '{device_file}'

disk_led.sls 的預設組態透過 libstoragemgmt 層來提供 LED 支援。但

libstoragemgmt 是透過特定於硬體的外掛程式和協力廠商工具來提供此支援的。

因此，除非已安裝適用於硬體的 libstoragemgmt 外掛程式和協力廠商工具，否則

libstoragemgmt 將無法調整 LED。

不論是否安裝了 libstoragemgmt，可能都需要透過協力廠商工具來調整 LED 燈。眾多

硬體廠商都提供此類協力廠商工具。下面是一些常見的廠商和工具：

表格 25.1︰協力廠商儲存工具

廠商/磁碟控制卡工具

HPE SmartArray hpssacli

LSI MegaRAID storcli

SUSE Linux Enterprise Server 還提供了 ledmon 套件和 ledctl 工具。此工具可能

還適用於使用 Intel 儲存機箱的硬體環境。使用此工具的正確語法如下所示：

root # cat /srv/pillar/ceph/disk_led.slsdisk_led: cmd: ident: 'on': ledctl locate='{device_file}' 'off': ledctl locate_off='{device_file}' fault: 'on': ledctl locate='{device_file}' 'off': ledctl locate_off='{device_file}'

如果您使用的是已安裝所有必需協力廠商工具的受支援硬體，則可以在 Salt Master

節點上使用以下指令語法來啟用或停用 LED：

root # salt-run disk_led.device NODE DISK fault|ident on|off


例如，若要針對 OSD 節點 srv16.ceph 上的 /dev/sdd 啟用或停用 LED 識別或故障

燈，請執行以下指令：

root # salt-run disk_led.device srv16.ceph sdd ident onroot # salt-run disk_led.device srv16.ceph sdd ident offroot # salt-run disk_led.device srv16.ceph sdd fault onroot # salt-run disk_led.device srv16.ceph sdd fault off

注意：裝置命名在 salt-run 指令中使用的裝置名稱需要與 Salt 所辨識的名稱相符。您可使用

以下指令來顯示這些名稱：

root@master # salt 'minion_name' grains.get disks

在許多環境中，為了調整 LED 燈以符合特定的硬體需求，需要對 /srv/pillar/ceph/

disk_led.sls 組態進行變更。透過以其他工具取代 lsmcli 或調整指令行參數，可

以進行簡單的變更。若要實現複雜的變更，則可能需要呼叫外部程序檔，而非使用

lsmcli 指令。對 /srv/pillar/ceph/disk_led.sls 進行任何變更時，均需執行以下步

驟：

1. 對 Salt Master 節點上的 /srv/pillar/ceph/disk_led.sls 進行所需變更。

2. 驗證 Pillar 資料中是否正確反映了這些變更：

root # salt 'SALT MASTER*' pillar.get disk_led

3. 使用以下指令重新整理所有節點上的 Pillar 資料：

root # salt '*' saltutil.pillar_refresh

您可以透過外部程序檔直接使用協力廠商工具來調整 LED 燈。下面提供了介紹如何調

整 /srv/pillar/ceph/disk_led.sls 以支援外部程序檔的範例，以及分別適用於 HP 和

LSI 環境的兩個範例程序檔。

修改過的 /srv/pillar/ceph/disk_led.sls，其中呼叫了外部程序檔：

root # cat /srv/pillar/ceph/disk_led.slsdisk_led: cmd:


ident: 'on': /usr/local/bin/flash_led.sh '{device_file}' on 'off': /usr/local/bin/flash_led.sh '{device_file}' off fault: 'on': /usr/local/bin/flash_led.sh '{device_file}' on 'off': /usr/local/bin/flash_led.sh '{device_file}' off

使用 hpssacli 公用程式在 HP 硬體上閃爍 LED 燈的範例程序檔：

root # cat /usr/local/bin/flash_led_hp.sh#!/bin/bash# params:# $1 device (e.g. /dev/sda)# $2 on|off

FOUND=0MAX_CTRLS=10MAX_DISKS=50

for i in $(seq 0 $MAX_CTRLS); do # Search for valid controllers if hpssacli ctrl slot=$i show summary >/dev/null; then # Search all disks on the current controller for j in $(seq 0 $MAX_DISKS); do if hpssacli ctrl slot=$i ld $j show | grep -q $1; then FOUND=1 echo "Found $1 on ctrl=$i, ld=$j. Turning LED $2." hpssacli ctrl slot=$i ld $j modify led=$2 break; fi done [[ "$FOUND" = "1" ]] && break fidone

使用 storcli 公用程式在 LSI 硬體上閃爍 LED 燈的範例程序檔：

root # cat /usr/local/bin/flash_led_lsi.sh#!/bin/bash# params:# $1 device (e.g. /dev/sda)# $2 on|off

[[ "$2" = "on" ]] && ACTION="start" || ACTION="stop"

# Determine serial number for the diskSERIAL=$(lshw -class disk | grep -A2 $1 | grep serial | awk '{print $NF}')if [ ! -z "$SERIAL" ]; then # Search for disk serial number across all controllers and enclosures DEVICE=$(/opt/MegaRAID/storcli/storcli64 /call/eall/sall show all | grep -B6 $SERIAL | grep Drive | awk '{print $2}') if [ ! -z "$DEVICE" ]; then


echo "Found $1 on device $DEVICE. Turning LED $2." /opt/MegaRAID/storcli/storcli64 $DEVICE $ACTION locate else echo "Device not found!" exit -1 fielse echo "Disk serial number not found!" exit -1fi


26 常見問答集

26.1 放置群組數量對叢集的效能有何影響？

當叢集空間的 70% 至 80% 已填滿時，便有必要新增更多的 OSD 至其中。增加 OSD 的

數量時，可以考慮同時增加放置群組的數量。

警告變更放置群組 (PG) 的數量會導致在叢集中傳輸大量的資料。

為最近調整大小的叢集計算最佳值是一項複雜的任務。

如果 PG 數量較大，將會建立一些較小的資料區塊。在發生 OSD 故障後，這樣可以加

快復原速度，但同時會對監控程式節點施加大量的負荷，因為這些節點負責計算資料位

置。

另一方面，如果 PG 數量較小，則發生 OSD 故障後，復原系統所需的時間和資料傳輸

量就會增加，但不會對監控程式節點施加如此多的負荷，因為需要由這些節點計算位置

的資料區塊更少 (但更大)。

如需叢集最佳 PG 數量的詳細資訊，請參閱第 9.4.2 節「確定 PG_NUM 的值」。

26.2 是否可以在同一叢集上使用 SSD 和普通

硬碟？

一般而言，固態硬碟 (SSD) 的速度比普通硬碟要快。如果對同一寫入操作混用這兩種

磁碟，SSD 磁碟的資料寫入速度將會因普通硬碟的效能限制而減慢。因此，對於遵循相

同規則的資料寫入操作，切勿混用 SSD 和普通硬碟 (如需資料儲存規則的詳細資訊，

請參閱第 9.3 節「規則集」)。

以下兩種情況通常適合在同一叢集上使用 SSD 和普通硬碟：

402 放置群組數量對叢集的效能有何影響？ SES 6

1. 針對遵循不同規則的資料寫入操作使用各自的磁碟類型。然後，您需要針對 SSD

磁碟和普通硬碟分別使用不同的規則。

2. 針對特定目的使用各自的磁碟類型。例如，將 SSD 磁碟用於記錄，將普通硬碟用

於儲存資料。

26.3 在 SSD 上使用記錄存在哪些利弊？為 OSD 記錄使用 SSD 有助於提高效能，因為在僅包含普通硬碟的 OSD 中，記錄通常

會成為瓶頸。SSD 往往用於共用多個 OSD 的記錄。

以下列出使用 SSD 來進行 OSD 記錄的潛在不利因素：

SSD 磁碟比普通硬碟更昂貴。但是，由於一個 OSD 記錄最多只需要 6GB 磁碟空

間，因此價格因素並不那麼重要。

SSD 磁碟會佔用儲存插槽，而大容量普通硬碟可以利用這些插槽來延伸叢集容

量。

與普通硬碟相比，SSD 磁碟的寫入週期更少，但最新的技術有望解決該問題。

如果是在同一部 SSD 磁碟上共用多個記錄，則在 SSD 磁碟發生故障後，將會面

臨遺失所有相關 OSD 的風險。在這種情況下，將需要移動大量資料來重新平衡叢

集。

熱插拔磁碟變得更複雜，因為有故障的 OSD 與記錄磁碟之間不存在一對一的資料

對應關係。

26.4 磁碟出現故障時，會發生什麼情況？當某個儲存叢集資料的磁碟出現硬體問題而無法正常運作時，會發生以下情況：

相關的 OSD 將會當機，並自動從叢集中移除。

有故障磁碟的資料會從其他 OSD 中儲存的相同資料的其他副本複製到叢集中的另

一個 OSD。

然後，您應該從叢集的 CRUSH 地圖中移除該磁碟，並從主機硬體中移除其實體。

403 在 SSD 上使用記錄存在哪些利弊？ SES 6

26.5 記錄磁碟出現故障時，會發生什麼情況？

可將 Ceph 設定為在獨立於 OSD 的裝置上儲存記錄或預寫式記錄。如果專用於記錄的

磁碟發生故障，相關的 OSD 也會發生故障 (請參閱第 26.4 節「磁碟出現故障時，會

發生什麼情況？」)。

警告：在一個磁碟上代管多個記錄若要大幅提升效能，可以使用高速磁碟 (例如 SSD) 來儲存多個 OSD 的記錄分

割區。不建議在一個磁碟上代管 4 個以上 OSD 的記錄，因為一旦記錄磁碟發生

故障，您就會面臨所有相關 OSD 磁碟儲存的資料都將遺失的風險。

404 記錄磁碟出現故障時，會發生什麼情況？ SES 6

27 疑難排解

本章描述您在操作 Ceph 叢集時可能會遇到的數種問題。

27.1 報告軟體問題

如果您在執行 SUSE Enterprise Storage 6 時遇到了與叢集的某些元件 (例如 Ceph

或物件閘道) 相關的問題，請向 SUSE 技術支援報告該問題。建議使用 supportconfig

公用程式來報告問題。

提示由於 supportconfig 是模組化軟體，因此請確定已安裝 supportutils-plugin-

ses 套件。

tux > rpm -q supportutils-plugin-ses

如果 Ceph 伺服器上缺少此套件，可使用以下指令安裝

root # zypper ref && zypper in supportutils-plugin-ses

儘管您可以在指令行中使用 supportconfig，但我們建議使用相關的 YaST 模

組。https://www.suse.com/documentation/sles-15/singlehtml/book_sle_admin/

book_sle_admin.html#sec.admsupport.supportconfig 上提供了有關

supportconfig 的詳細資訊。

27.2 使用 rados 傳送大型物件失敗，並顯示

「OSD 已滿」

rados 是用於管理 RADOS 物件儲存的指令行公用程式。如需詳細資訊，請參閱 man 8

rados。

如果您使用 rados 公用程式將大型物件傳送到 Ceph 叢集，例如

405 報告軟體問題 SES 6

https://www.suse.com/documentation/sles-15/singlehtml/book_sle_admin/book_sle_admin.html#sec.admsupport.supportconfig

https://www.suse.com/documentation/sles-15/singlehtml/book_sle_admin/book_sle_admin.html#sec.admsupport.supportconfig

cephadm@adm > rados -p mypool put myobject /file/to/send

該物件可能會填滿所有相關的 OSD 空間，並導致叢集效能出現嚴重問題。

27.3 XFS 檔案系統損毀

在極少見的情況下 (例如出現核心錯誤，或硬體損毀/設定不當)，OSD 用來儲存資料的

基礎檔案系統 (XFS) 可能會損毀或無法掛接。

如果您確定硬體沒有問題並且系統設定正確，請報告 SUSE Linux Enterprise Server

核心的 XFS 子系統出現了錯誤，並將特定的 OSD 標示為停機：

cephadm@adm > ceph osd down OSD_ID

警告：不要格式化或修改損毀的裝置儘管使用 xfs_repair 來修復檔案系統問題看似合理，但它會修改檔案系統，因

此請勿使用該指令。OSD 可以啟動，但它的執行可能會受到影響。

現在，請執行以下指令抹除基礎磁碟，並重新建立 OSD：

cephadm@osd > ceph-volume lvm zap --data /dev/OSD_DISK_DEVICEcephadm@osd > ceph-volume lvm prepare --bluestore --data /dev/OSD_DISK_DEVICE

27.4 「每個 OSD 的 PG 數過多」狀態訊息

如果您在執行 ceph status 後收到每個 OSD 的 PG 數過多訊息，則表示超出了

mon_pg_warn_max_per_osd 值 (預設值為 300)。系統會將此值與每個 OSD 的 PG 數比

率進行比較。這意味著叢集設定並不是最佳的。

建立池後，便不能減少 PG 數。您可以放心地刪除尚不包含任何資料的池，然後重新

建立包含較少 PG 的池。如果池中已包含資料，則唯一的解決方法是將 OSD 新增至叢

集，使每個 OSD 的 PG 數比率變低。

406 XFS 檔案系統損毀 SES 6

27.5 「nn pg 停滯在非使用中狀態」狀態訊息

如果您在執行 ceph status 後收到停滯在非使用中狀態狀態訊息，則表示 Ceph 不知道要

將儲存的資料複製到何處，因此無法遵循複製規則。在完成初始 Ceph 設定不久後可能

會發生此問題，並且系統可自動修復。在其他情況下出現此問題可能需要進行手動互

動，例如啟動已中止的 OSD，或者將新的 OSD 新增至叢集。在極少見的情況下，降低

複製層級可能有所幫助。

如果放置群組一直處於停滯狀態，則您需要檢查 ceph osd tree 的輸出。輸出採用的

應該是樹狀結構，類似於第 27.7 節「OSD 停機」中的範例。

如果 ceph osd tree 的輸出結構相對扁平，如以下範例中所示

cephadm@adm > ceph osd treeID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY-1 0 root default 0 0 osd.0 up 1.00000 1.00000 1 0 osd.1 up 1.00000 1.00000 2 0 osd.2 up 1.00000 1.00000

您應該檢查相關的 CRUSH 地圖是否包含樹狀結構。如果 CRUSH 地圖也是扁平的，或者

不包含上面範例中所示的主機，則可能表示叢集中的主機名稱解析未正常運作。

如果階層不正確 (例如，根包含主機，但 OSD 位於頂層，並且自身未指定到主機)，您

需要將 OSD 移到階層中的正確位置。可以使用 ceph osd crush move 和/或 ceph osd

crush set 指令實現此目的。如需更多詳細資料，請參閱第 9.5 節「CRUSH 地圖操

作」。

27.6 OSD 權數為 0

當 OSD 啟動時，系統會給它指定一個權數。權數越高，叢集向該 OSD 寫入資料的幾率

就越大。可在叢集 CRUSH 地圖中指定該權數，或者透過 OSD 的啟動程序檔計算得出。

在某些情況下，計算出的 OSD 權數值可能會捨位到零。這表示不會排程該 OSD 儲存資

料，因此不會向其寫入資料。發生此情況的原因通常是相應的磁碟太小 (小於 15GB)，

應該更換為更大的磁碟。

407 「nn pg 停滯在非使用中狀態」狀態訊息 SES 6

27.7 OSD 停機OSD 精靈的狀態要麼是執行中，要麼是已停止/已停機。導致 OSD 停機的原因一般有以

下三種：

硬碟故障。

OSD 已當機。

伺服器已當機。

您可以執行以下指令來查看 OSD 的詳細狀態

cephadm@adm > ceph osd tree# id weight type name up/down reweight -1 0.02998 root default -2 0.009995 host doc-ceph1 0 0.009995 osd.0 up 1 -3 0.009995 host doc-ceph2 1 0.009995 osd.1 up 1 -4 0.009995 host doc-ceph3 2 0.009995 osd.2 down 1

範例清單顯示 osd.2 已停機。然後，您可以檢查是否已掛接 OSD 所在的磁碟：

root # lsblk -f [...] vdb ├─vdb1 /var/lib/ceph/osd/ceph-2 └─vdb2

您可以透過檢查 OSD 的記錄檔案 /var/log/ceph/ceph-osd.2.log 來追蹤其停機原因。

找到並解決 OSD 未執行的原因之後，請使用以下指令將它啟動


請記得用已停止 OSD 的實際編號取代 2。

27.8 尋找執行緩慢的 OSD調校叢集效能時，識別叢集中執行緩慢的儲存/OSD 非常重要。原因在於，如果將資料

寫入 (最) 緩慢的磁碟，則會拖慢整個寫入操作，因為它永遠要等待在所有相關磁碟上

的操作全部完成。

408 OSD 停機 SES 6

找到儲存瓶頸並非無足輕重。您需要檢查每一個 OSD 才能找出使寫入程序減慢的

OSD。若要針對單個 OSD 執行基準測試，請執行：

ceph tell osd.OSD_ID_NUMBER bench

例如：

cephadm@adm > ceph tell osd.0 bench { "bytes_written": 1073741824, "blocksize": 4194304, "bytes_per_sec": "19377779.000000"}

然後，您需要在每個 OSD 上執行此指令，並與 bytes_per_sec 值進行比較，以找出

(最) 緩慢的 OSD。

27.9 解決時鐘偏差警告所有叢集節點中的時間資訊都必須是同步的。如果某個節點的時間未完全同步，在檢查

叢集狀態時，您可能會收到時鐘偏差警告。

可使用 NTP 來管理時間同步 (請參閱 http://en.wikipedia.org/wiki/

Network_Time_Protocol )。設定每個節點，使其時間與一或多部 NTP 伺服器同步，

最好是與同一群組的 NTP 伺服器同步。如果節點上仍然出現時間偏差，請執行以下步

驟予以修復：

root # systemctl stop chronyd.serviceroot # systemctl stop ceph-mon.targetroot # systemctl start chronyd.serviceroot # systemctl start ceph-mon.target

然後，您可以使用 chronyc sourcestats 檢視時間偏移。

Ceph 監控程式的時鐘需要同步，彼此之間的偏差必須控制在 0.05 秒以內。如需詳細

資訊，請參閱第 25.4 節「節點時間同步」。

27.10 網路問題導致叢集效能不佳導致叢集效能變差的原因有很多，其中之一可能是網路問題。在這種情況下，您可能會

發現叢集即將達到仲裁數、OSD 和監控程式節點離線、資料傳輸耗費很長時間，或者嘗

試了很多次重新連接。

409 解決時鐘偏差警告 SES 6

http://en.wikipedia.org/wiki/Network_Time_Protocol

http://en.wikipedia.org/wiki/Network_Time_Protocol

若要檢查叢集效能下降是否因網路問題導致，請檢查 /var/log/ceph 目錄中的 Ceph

記錄檔案。

若要解決叢集上的網路問題，請重點關注以下幾點：

基本網路診斷。嘗試使用 DeepSea 診斷工具執行器 net.ping 在叢集節點之間執

行 ping 指令，以確定個別介面是否可以連接到特定的介面，並瞭解平均回應時

間。此指令還會報告比平均值要慢得多的所有特定回應時間。例如：

root@master # salt-run net.ping Succeeded: 8 addresses from 7 minions average rtt 0.15 ms

嘗試在啟用巨型框架的情況下驗證所有介面：

root@master # salt-run net.jumbo_ping Succeeded: 8 addresses from 7 minions average rtt 0.26 ms

網路效能基準測試。嘗試使用 DeepSea 的網路效能執行器 net.iperf 來測試節

點間的網路頻寬。在某個給定的叢集節點上，有許多 iperf 程序 (具體視 CPU

核心數而定) 是做為伺服器啟動的。其餘的叢集節點將做為用戶端來產生網路流

量。執行器會報告單個節點上所有 iperf 程序的累積頻寬。此值應該能反映所有

叢集節點上可達到的最大網路輸送量。例如：

root@master # salt-run net.iperf cluster=ceph output=full192.168.128.1: 8644.0 Mbits/sec192.168.128.2: 10360.0 Mbits/sec192.168.128.3: 9336.0 Mbits/sec192.168.128.4: 9588.56 Mbits/sec192.168.128.5: 10187.0 Mbits/sec192.168.128.6: 10465.0 Mbits/sec

檢查叢集節點上的防火牆設定。確定這些設定不會封鎖 Ceph 運作所需的連接埠/

通訊協定。如需防火牆設定的詳細資訊，請參閱第 25.9 節「Ceph 的防火牆設

定」。

檢查網路卡、纜線或交換器等網路硬體是否正常運作。

410 網路問題導致叢集效能不佳 SES 6

提示：獨立網路為確保在叢集節點之間進行快速安全的網路通訊，請設定一個專供叢集 OSD 和

監控程式節點使用的獨立網路。

27.11 /var 空間不足

依預設，Salt Master 會在其工作快取中儲存每個 Minion 針對每個工作傳回的內容。

以後便可使用快取來查閱先前工作的結果。快取目錄預設為 /var/cache/salt/master/

jobs/。

每個 Minion 針對每個工作傳回的內容都儲存在一個檔案中。久而久之，此目錄會變得

非常大，具體大小取決於發佈的工作數量和 /etc/salt/master 檔案中 keep_jobs 選

項的值。 keep_jobs 用於設定應將過去的 Minion 工作的相關資訊保留多少小時 (預設

值為 24)。

keep_jobs: 24

重要：請勿將 keep_jobs 設定為 0如果將 keep_jobs 設定為「0」，則工作快取清除工具永不執行，可能會導致分

割區變滿。

若要停用工作快取，請將 job_cache 設定為「False」：

job_cache: False

提示：還原因工作快取而變滿的分割區當由於 keep_jobs 設定不當而導致包含工作快取檔案的分割區變滿時，請執行

以下步驟來釋放磁碟空間並改進工作快取設定：

1. 停止 Salt Master 服務：

root@master # systemctl stop salt-master

411 /var 空間不足 SES 6

2. 透過編輯 /etc/salt/master 來變更與工作快取相關的 Salt Master 組

態：

job_cache: Falsekeep_jobs: 1

3. 清除 Salt Master 工作快取：

root # rm -rfv /var/cache/salt/master/jobs/*

4. 啟動 Salt Master 服務：

root@master # systemctl start salt-master

412 /var 空間不足 SES 6

A DeepSea 階段 1 自訂範例

{% set master = salt['master.minion']() %}

include: - ..validate

ready: salt.runner: - name: minions.ready - timeout: {{ salt['pillar.get']('ready_timeout', 300) }}

refresh_pillar0: salt.state: - tgt: {{ master }} - sls: ceph.refresh

discover roles: salt.runner: - name: populate.proposals - require: - salt: refresh_pillar0

discover storage profiles: salt.runner: - name: proposal.populate - kwargs: 'name': 'prod' 'db-size': '59G' 'wal-size': '1G' 'nvme-spinner': True 'ratio': 12 - require: - salt: refresh_pillar0

413 SES 6

B SUSE Enterprise Storage 6 的預設警示

groups: - name: cluster health rules: - alert: health error expr: ceph_health_status == 2 for: 5m labels: severity: critical type: ses_default annotations: description: Ceph in error for > 5m - alert: unhealthy expr: ceph_health_status != 0 for: 15m labels: severity: warning type: ses_default annotations: description: Ceph not healthy for > 5m - name: mon rules: - alert: low monitor quorum count expr: ceph_monitor_quorum_count < 3 labels: severity: critical type: ses_default annotations: description: Monitor count in quorum is low - name: osd rules: - alert: 10% OSDs down expr: sum(ceph_osd_down) / count(ceph_osd_in) >= 0.1 labels: severity: critical type: ses_default annotations: description: More then 10% of OSDS are down - alert: OSD down expr: sum(ceph_osd_down) > 1 for: 15m labels: severity: warning type: ses_default annotations: description: One or more OSDS down for more then 15 minutes - alert: OSDs near full expr: (ceph_osd_utilization unless on(osd) ceph_osd_down) > 80 labels: severity: critical

414 SES 6

type: ses_default annotations: description: OSD {{ $labels.osd }} is dangerously full, over 80% # alert on single OSDs flapping - alert: flap osd expr: rate(ceph_osd_up[5m])*60 > 1 labels: severity: warning type: ses_default annotations: description: > OSD {{ $label.osd }} was marked down at back up at least once a minute for 5 minutes. # alert on high deviation from average PG count - alert: high pg count deviation expr: abs(((ceph_osd_pgs > 0) - on (job) group_left avg(ceph_osd_pgs > 0) by (job)) / on (job) group_left avg(ceph_osd_pgs > 0) by (job)) > 0.35 for: 5m labels: severity: warning type: ses_default annotations: description: > OSD {{ $labels.osd }} deviates by more then 30% from average PG count # alert on high commit latency...but how high is too high - name: mds rules: # no mds metrics are exported yet - name: mgr rules: # no mgr metrics are exported yet - name: pgs rules: - alert: pgs inactive expr: ceph_total_pgs - ceph_active_pgs > 0 for: 5m labels: severity: critical type: ses_default annotations: description: One or more PGs are inactive for more then 5 minutes. - alert: pgs unclean expr: ceph_total_pgs - ceph_clean_pgs > 0 for: 15m labels: severity: warning type: ses_default annotations: description: One or more PGs are not clean for more then 15 minutes. - name: nodes rules:

415 SES 6

- alert: root volume full expr: node_filesystem_avail{mountpoint="/"} / node_filesystem_size{mountpoint="/"} < 0.1 labels: severity: critical type: ses_default annotations: description: Root volume (OSD and MON store) is dangerously full (< 10% free) # alert on nic packet errors and drops rates > 1 packet/s - alert: network packets dropped expr: irate(node_network_receive_drop{device!="lo"}[5m]) + irate(node_network_transmit_drop{device!="lo"}[5m]) > 1 labels: severity: warning type: ses_default annotations: description: > Node {{ $labels.instance }} experiences packet drop > 1 packet/s on interface {{ $lables.device }} - alert: network packet errors expr: irate(node_network_receive_errs{device!="lo"}[5m]) + irate(node_network_transmit_errs{device!="lo"}[5m]) > 1 labels: severity: warning type: ses_default annotations: description: > Node {{ $labels.instance }} experiences packet errors > 1 packet/s on interface {{ $lables.device }} # predict fs fillup times - alert: storage filling expr: ((node_filesystem_free - node_filesystem_size) / deriv(node_filesystem_free[2d]) <= 5) > 0 labels: severity: warning type: ses_default annotations: description: > Mountpoint {{ $lables.mountpoint }} will be full in less then 5 days assuming the average fillup rate of the past 48 hours. - name: pools rules: - alert: pool full expr: ceph_pool_used_bytes / ceph_pool_available_bytes > 0.9 labels: severity: critical type: ses_default annotations: description: Pool {{ $labels.pool }} at 90% capacity or over - alert: pool filling up expr: (-ceph_pool_used_bytes / deriv(ceph_pool_available_bytes[2d]) <= 5 ) > 0 labels: severity: warning

416 SES 6

type: ses_default annotations: description: > Pool {{ $labels.pool }} will be full in less then 5 days assuming the average fillup rate of the past 48 hours.

417 SES 6

C 以上游「Nautilus」小數點版本為基礎的

Ceph 維護更新

SUSE Enterprise Storage 6 中的幾個關鍵套件均以 Ceph 的 Nautilus 版本系列為基

礎。當 Ceph 專案 (https://github.com/ceph/ceph ) 在 Nautilus 系列中發佈新的

小數點版本時，SUSE Enterprise Storage 6 即會更新，以確保產品套用最新的上游錯

誤修復並可進行功能向後移植。

本章簡要介紹有關已經或計劃在產品中包含的每個上游小數點版本中的重要變更。

Nautilus 14.2.4 小數點版本

此小數點版本修復了 14.2.3 小數點版本中發現的一個嚴重的迴歸問題。此迴歸問題未

對 SUSE Enterprise Storage 客戶產生影響，因為我們未隨附以 14.2.3 為基礎的版

本。


修復了拒絕服務弱點，如果存在該弱點，Ceph 物件閘道的未驗證用戶端可能會觸

發未擷取的例外所導致的當機。

現在，以 Nautilus 為基礎的 librbd 用戶端可以開啟 Jewel 叢集上的影像。

已移除物件閘道 num_rados_handles。如果您之前使用的 num_rados_handles 值

大於 1，將目前的 objecter_inflight_ops 和 objecter_inflight_op_bytes 參數

與 num_rados_handles 以前的值相乘，即可設定相同的節流行為。

在此版本中，Messenger v2 通訊協定的安全模式不再是實驗性的。現在，此模式

是偏好的監控程式連接模式。

osd_deep_scrub_large_omap_object_key_threshold 已降低，以便更輕鬆地偵測儲

存了大量 omap 鍵的物件。

Ceph Dashboard 現在支援將 Prometheus 通知設為靜默模式。

418 Nautilus 14.2.4 小數點版本 SES 6

https://github.com/ceph/ceph


已修改 no{up,down,in,out} 相關指令。現在可使用以下兩種方式來設定

no{up,down,in,out} 旗標：一種是舊指令

ceph osd [un]set FLAG

該指令可設定叢集範圍的旗標；另一種是新指令

ceph osd [un]set-group FLAGS WHO

該指令能以任何 CRUSH 節點或裝置類別的細粒度大量設定旗標。

radosgw-admin 引入了兩個子指令，用來管理對較早版本物件閘道中進行桶重新分

區後可能遺留的過時物件的廢棄。其中一個子指令可列出此類物件，而另一個子

指令可將其刪除。

較早的 Nautilus 版本 (14.2.1 和 14.2.0) 存在如下問題：如果在升級後

的叢集 (即最初是在 Nautilus 之前部署的叢集) 上部署一個新的 Nautilus

BlueStore OSD，將會損壞 ceph df 報告的池利用統計資料。在您透過 ceph-

bluestore-tool repair 重新佈建或更新所有 OSD 之前，池統計資料顯示的值將

低於實際值。14.2.2 版本解決了此問題，因此，僅當所有 OSD 均為 14.2.2 或

更新版本 (即區塊儲存)，並且已透過修復功能更新 (如果它們是在 Nautilus 之

前建立的) 後，叢集才會轉為使用更準確的基於池的統計資料。

mon_crush_min_required_version 的預設值已由 firefly 變更為 hammer，這表

示如果您的 CRUSH 可調參數比 Hammer 舊，叢集將發出狀態警告。在轉為使用

Hammer 可調參數時，一般將會重新平衡少量 (但並非零) 資料。

如果可能，建議您將允許的最舊用戶端設定為 hammer 或更新版本。若要顯示目

前允許的最舊用戶端，請執行以下指令：

cephadm@adm > ceph osd dump | grep min_compat_client

如果目前值比 hammer 舊，請執行以下指令以確認有無比目前連接至叢集的

Hammer 更舊的用戶端，據此判斷進行此變更是否安全：

cephadm@adm > ceph features


Hammer 中引入了更新的 straw2 CRUSH 桶類型。如果您確認所有用戶端均為

Hammer 或更新版本，便可使用僅適用於 straw2 桶的新功能，包括平衡器的

crush-compat 模式 (第 10.1 節「平衡器」)。

如需修補程式的詳細資訊，請造訪 https://download.suse.com/Download?

buildid=D38A7mekBz4~


這是原始 Nautilus 版本 (14.2.0) 之後的第一個小數點版本。SUSE Enterprise

Storage 6 的原始 (「正式版本」或「GA」) 版本以此小數點版本為基礎。


https://download.suse.com/Download?buildid=D38A7mekBz4~

https://download.suse.com/Download?buildid=D38A7mekBz4~

詞彙

一般

CRUSH、CRUSH 地圖

基於可延展雜湊的受控複製：透過計算資料儲存位置來確定如何儲存和擷取資料的

演算法。CRUSH 需要獲取叢集的地圖來以虛擬隨機的方式在 OSD 中儲存和擷取資

料，並以一致的方式在整個叢集中分散資料。

OSD

表示物件儲存裝置或物件儲存精靈，視內容而定。 ceph-osd 精靈是 Ceph 的元件，

負責在本地檔案系統上儲存物件，並在網路中提供對它們的存取。

OSD 節點

一個叢集節點，用於儲存資料、處理資料複製、復原、回填、重新平衡，以及透過

檢查其他 Ceph OSD 精靈為 Ceph 監控程式提供某些監控資訊。

放置組

放置組：池的細分，用於進行效能調整。

桶

將其他節點聚合成實體位置階層的一個點。

重要：請勿混用 S3 桶S3 桶或容器代表不同的術語，表示儲存物件的資料夾。

池

用於儲存物件 (例如磁碟影像) 的邏輯分割區。

監控程式節點、MON

用於維護叢集狀態地圖的叢集節點，包括監控程式地圖或 OSD 地圖。

421 SES 6

管理節點

用於執行 ceph-deploy 公用程式以在 OSD 節點上部署 Ceph 的節點。

節點

Ceph 叢集中的任何一部機器或伺服器。

規則集

用於確定池的資料放置的規則。

路由樹狀結構

該術語指的是展示接收器可執行的不同路由的任何圖表。

Ceph 特定術語

Alertmanager

用於處理 Prometheus 伺服器傳送的警示並通知最終使用者的單個二進位檔案。

Ceph 儲存叢集

用於儲存使用者資料的儲存軟體的核心集合。此類集合由 Ceph 監控程式和 OSD 組

成。

也稱為「Ceph 物件儲存」。

Grafana

資料庫分析和監控解決方案。

Prometheus

系統監控和警示工具套件。

物件閘道特定的術語

歸檔同步模組

允許建立物件閘道區域以保留 S3 物件版本歷程的模組。

422 SES 6

物件閘道

Ceph 物件儲存的 S3/Swift 閘道元件。

423 SES 6

D 文件更新

本章列出了自 SUSE Enterprise Storage 5 的最新維護更新發行以來，本文件內

容所發生的變更。如需適用於先前版本的變更，請參閱 https://www.suse.com/

documentation/suse-enterprise-storage-5/book_storage_admin/data/

ap_adm_docupdate.html 。

本文件在以下日期進行了更新：

第 D.1 節「SUSE Enterprise Storage 6 的維護更新文件」

第 D.2 節「2019 年 6 月 (SUSE Enterprise Storage 6 發行)」

D.1 SUSE Enterprise Storage 6 的維護更新

文件一般更新

新增了第 17.8.5 節「歸檔同步模組」(https://jira.suse.com/browse/

SES-380 )。

新增了第 22.5.8 節「RBD 鏡像」(https://jira.suse.com/browse/

SES-235 )。

新增了第 15 章「使用 LVM 快取提升效能」(https://jira.suse.com/browse/

SES-269 )。

錯誤修復

在第 3.1 節「備份 Ceph 組態」中的備份內容清單中新增了 /etc/ceph

(https://bugzilla.suse.com/show_bug.cgi?id=1153342 )。

在第 2.1 節「新增新的叢集節點」中修正了新增新叢集節點時的指定目標和重

設權數指令 (https://bugzilla.suse.com/show_bug.cgi?id=1151861 )。

針對 Ceph 14.2.4 新增了變更記錄項目 (https://bugzilla.suse.com/

show_bug.cgi?id=1151881 )。

424 SUSE Enterprise Storage 6 的維護更新文件 SES 6

https://www.suse.com/documentation/suse-enterprise-storage-5/book_storage_admin/data/ap_adm_docupdate.html



https://jira.suse.com/browse/SES-380






https://bugzilla.suse.com/show_bug.cgi?id=1153342




在第 2 章「Salt 叢集管理」中指出了需要在執行階段 5 之前確認可能會移除

的 OSD (https://bugzilla.suse.com/show_bug.cgi?id=1150406 )。

在第 2.8 節「復原重新安裝的 OSD 節點」中，於描述復原 OSD 的程序中新增

了兩個額外步驟 (https://bugzilla.suse.com/show_bug.cgi?id=1137132 )。

新增了一章有關 Ceph 管理員模組的內容，在第 10.1 節「平衡器」中重點介紹

了平衡器模組 (https://bugzilla.suse.com/show_bug.cgi?id=1133550 )。

在第 2.11 節「更新叢集節點」中重新撰寫了有關套用叢集軟體滾存更

新的部分，並以手動指令取代了階段 0，以避免出現無限迴圈 (https://

bugzilla.suse.com/show_bug.cgi?id=1134444 )。

新增了描述如何取代管理節點的新章節：第 2.9 節「將管理節點移至新伺服

器」(https://bugzilla.suse.com/show_bug.cgi?id=1145080 )。

在第 12.4.3 節「影像組態」中新增了對所有新影像啟用影像記錄可能會對

叢集效能產生負面影響的警告 (https://bugzilla.suse.com/show_bug.cgi?

id=1134734 )。

新增了檢查 nscd 的程序，以及將時鐘與 Active Directory 控制器保持同步的

提示 (https://bugzilla.suse.com/show_bug.cgi?id=1144696 )。

新增了第 2.16 節「移除整個 Ceph 叢集」，並在第 22.2.6 節「新增自訂角

色」和第 22.10.2 節「使用者角色和許可權」中新增了有關清除自訂角色的提

示 (https://bugzilla.suse.com/show_bug.cgi?id=1138846 )。

在第 9.1.1.3 節「CRUSH 放置規則」中新增了一個遺漏的指令，

並在第 9.1.1.4 節「其他指令」中新增了兩個新指令 (https://


新增了第 2.6.2 節「移除主機上的所有 OSD」(https://bugzilla.suse.com/


在第 6.4 節「檢查叢集的使用量統計資料」中更新了 ceph df 指令的輸出

(https://bugzilla.suse.com/show_bug.cgi?id=1143551 )。

在《部署指南》, 第 10 章「安裝 iSCSI 閘道」, 第 10.4.5 節「進階設

定」中新增了兩項新的進階設定 (https://bugzilla.suse.com/show_bug.cgi?

id=1142341 )。

425 SUSE Enterprise Storage 6 的維護更新文件 SES 6


















新增了第 2.15 節「停用調整後的設定檔」(https://bugzilla.suse.com/


在第 11.3.1 節「使用快取層移轉」中新增了快取層移轉方法僅適用於複本池的

說明 (https://bugzilla.suse.com/show_bug.cgi?id=1102242 )。

在第 25.6 節「Ceph 監控程式節點上 /var/lib/ceph 的 Btrfs 子磁碟區」中

更新了 @/var/lib/ceph 子磁碟區建立說明 (https://bugzilla.suse.com/


D.2 2019 年 6 月 (SUSE Enterprise Storage

6 發行)一般更新

新增了第 17.6 節「HTTP 前端」，並將物件閘道組態選項移到了第 16.3 節

「Ceph 物件閘道」(https://jira.suse.com/browse/SES-453 )。

新增了第 16 章「Ceph 叢集組態」 (jsc#SES-526)。

在第 22 章「Ceph Dashboard」中新增了有關 Ceph Dashboard URL 的動態特性

的詳細資訊 (jsc#SES-461)。

新增了第 25.11 節「如何尋找使用 LED 燈的實體磁碟」(jsc#SES-100)。

更新了第 22.6 節「管理 NFS Ganesha」(jsc#SES-533)。

在第 22.9.3 節「使用者名稱與密碼」中新增了有關使用名為「admin」的預設

Ceph Dashboard 使用者帳戶的提示 (jsc#SES-485)。

新增了第 17.12 節「池放置和儲存類別」(jsc#SES-326)。

在第 17.8.3.1 節「ElasticSearch 層類型組態參數」中新增了 username 和

password 參數 (jsc#SES-130)。

新增了第 20.2 節「將 Samba 閘道加入 Active Directory

中」(jsc#SES-38)。

新增了第 17.8.1 節「一般組態」和第 17.8.4 節「雲端同步模

組」(jsc#SES-96)。

426 2019 年 6 月 (SUSE Enterprise Storage 6 發行) SES 6







新增了第 12.6 節「QoS 設定」(Fate#324269)。

新增了第 19.7 節「管理 CephFS 快照」(Fate#325488)。

移除/更新了過時的 ceph-disk (Fate#324466)。

新增了第 19.6 節「設定 CephFS 定額」(Fate#323422)。

將區塊儲存做為預設儲存後端 (Fate#325658)。

新增了第 5.3 節「正常關閉整個 Ceph 叢集」(Fate#323666)。

新增了第 2.7 節「更換 OSD 磁碟」。

移除了對外部線上文件的所有參考，並以相關內容取代了這些參考

(Fate#320121)。

錯誤修復

新增了第 12.9 節「使用舊核心用戶端對應 RBD」(https://


更新了物件閘道部分，由 CivetWeb 改為使用 Beast (https://


在《部署指南》, 第 10 章「安裝 iSCSI 閘道」, 第 10.4.3 節「透過 iSCSI

輸出 RBD 影像」中移除了有關 RBD 影像格式 1 的內容，並統一了池/磁碟區名

稱 (https://bugzilla.suse.com/show_bug.cgi?id=1135175 )。

在第 12.6 節「QoS 設定」中說明了 iSCSI 不支援 QoS 功能 (https://


在第 20 章「透過 Samba 輸出 Ceph 資料」和第 21 章「NFS Ganesha：透

過 NFS 輸出 Ceph 資料」中新增了效能備註 (https://bugzilla.suse.com/


427 2019 年 6 月 (SUSE Enterprise Storage 6 發行) SES 6










Documents

管理指南 - SUSE Enterprise Storage 6 · 目錄 關於本指南xvii I 叢集管理 1 1 使用者權限和指令提示2 1.1 與 Salt/DeepSea 相關的指令 2 1.2 與 Ceph 相關的指令

管理指南 - SUSE Enterprise Storage 6 · 目錄關於本指南xvii I 叢集管理 1 1 使用者權限和指令提示2 1.1 與 Salt/DeepSea 相關的指令 2 1.2 與 Ceph 相關的指令