部署指南 - SUSE Enterprise Storage 6...目錄關於本指南x I SUSE ENTERPRISE STORAGE 1 1...

部署指南

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 及

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

目錄

關於本指南 x

I SUSE ENTERPRISE STORAGE 1

1 SUSE Enterprise Storage 6 和 Ceph 21.1 Ceph 的特性 2

1.2 核心元件 3

RADOS 3 • CRUSH 4 • Ceph 節點和精靈 4

1.3 儲存結構 6

池 6 • 放置群組 6 • 範例 6

1.4 BlueStore 8

1.5 其他資訊 9

2 硬體要求和建議 10

2.1 多架構組態 10

2.2 最低叢集組態 10

2.3 物件儲存節點 11

最低需求 11 • 最小磁碟大小 11 • BlueStore 的 WAL 和 DB 裝置

的建議大小 12 • 使用 SSD 儲存 OSD 記錄 12 • 磁碟的最大建議

數量 13

2.4 監控程式節點 13

2.5 物件閘道節點 14

2.6 中繼資料伺服器節點 14

2.7 Salt Master 14

iv 部署指南

2.8 iSCSI 節點 14

2.9 網路建議 14

將私人網路新增到執行中的叢集 15 • 不同子網路中的監控程式節

點 16

2.10 命名限制 16

2.11 共用一部伺服器的 OSD 和監控程式 16

2.12 建議的生產叢集組態 17

2.13 SUSE Enterprise Storage 6 以及其他 SUSE 產品 18

SUSE Manager 18

3 管理節點 HA 設定 19

3.1 管理節點的 HA 叢集概述 19

3.2 建構含管理節點的 HA 叢集 20

4 使用者權限和指令提示 22

4.1 與 Salt/DeepSea 相關的指令 22

4.2 與 Ceph 相關的指令 22

4.3 一般的 Linux 指令 23

4.4 其他資訊 23

II 叢集部署和升級 24

5 使用 DeepSea/Salt 部署 255.1 閱讀版本說明 25

5.2 DeepSea 簡介 26

組織和重要位置 27 • 定位 Minion 28

5.3 叢集部署 30

v 部署指南

5.4 DeepSea CLI 39

DeepSea CLI：監控模式 39 • DeepSea CLI：獨立模式 40

5.5 組態和自訂 42

policy.cfg 檔案 42 • DriveGroups 47 • 使用自訂設定調整

ceph.conf 56

6 從舊版本升級 57

6.1 升級前的注意事項 57

6.2 備份叢集資料 61

6.3 從 ntpd 移轉至 chronyd 61

6.4 升級前對叢集套用修補程式 62

所需的軟體儲存庫 63 • 儲存庫暫存系統 63 • 對整個叢集套用最

新的修補程式 64

6.5 確認目前環境 64

6.6 檢查叢集的狀態 65

6.7 CTDB 叢集的離線升級 66

6.8 依節點升級 - 基本程序 66

使用安裝程式 DVD 手動升級節點 67 • 使用 SUSE 套裝作業系統移轉

系統升級節點 69

6.9 升級管理節點 70

6.10 升級 Ceph 監控程式/Ceph 管理員節點 71

6.11 升級中繼資料伺服器 72

6.12 升級 Ceph OSD 73

6.13 將 OSD 移轉至 BlueStore 77

6.14 升級應用程式節點 78

6.15 更新 policy.cfg 並使用 DeepSea 部署 Ceph Dashboard 79

vi 部署指南

6.16 從以設定檔為基礎的部署移轉至 DriveGroups 81

分析目前配置 81 • 建立與目前配置相符的 DriveGroups 82 • OSD

部署 82 • 更複雜的設定 83

7 自訂預設組態 84

7.1 使用自訂的組態檔案 84

停用部署步驟 84 • 取代部署步驟 85 • 修改部署步驟 86 • 修改

部署階段 87 • 階段 0 期間的更新和重新開機 89

7.2 修改已探查的組態 90

為 Ceph 叢集部署啟用 IPv6 92

III 安裝其他服務 93

8 安裝用於存取資料的服務 94

9 Ceph 物件閘道 95

9.1 手動安裝物件閘道 95

物件閘道組態 96

10 安裝 iSCSI 閘道 102

10.1 iSCSI 區塊儲存 102

Linux 核心 iSCSI 目標 103 • iSCSI 啟動器 103

10.2 有關 ceph-iscsi 的一般資訊 104

10.3 部署考量 105

10.4 安裝和組態 106

將 iSCSI 閘道部署到 Ceph 叢集 106 • 建立 RBD 影像 106 • 透過

iSCSI 輸出 RBD 影像 107 • 驗證和存取控制 108 • 進階設定 110

10.5 使用 tcmu-runner 輸出 RADOS 區塊裝置影像 113

11 安裝 CephFS 115

11.1 支援的 CephFS 情境和指導原則 115

vii 部署指南

11.2 Ceph 中繼資料伺服器 116

新增中繼資料伺服器 116 • 設定中繼資料伺服器 116

11.3 CephFS 121

建立 CephFS 121 • MDS 叢集大小 123 • MDS 叢集和更新 123 • 檔

案配置 124

12 安裝 NFS Ganesha 129

12.1 準備 129

一般資訊 129 • 要求摘要 130

12.2 範例安裝 130

12.3 高可用性主動-被動組態 131

基本安裝 131 • 清理資源 133 • 設定 Ping 資源 134 • NFS

Ganesha HA 和 DeepSea 134

12.4 主動-主動組態 135

先決條件 135 • 設定 NFS Ganesha 136 • 填入叢集寬限資料

庫 137 • 重新啟動 NFS Ganesha 服務 137 • 結論 138

12.5 更多資訊 138

IV 以 SUSE CAAS PLATFORM 4 為基礎的叢集部署 (技術預覽) 139

13 在 SUSE CaaS Platform 4 Kubernetes 叢集上部署的 SUSE Enterprise Storage 6 140

13.1 考量事項 140

13.2 先決條件 140

13.3 獲取 Rook 資訊清單 141

13.4 安裝 141

組態 141 • 建立 Rook 操作者 142 • 建立 Ceph 叢集 143

13.5 使用 Rook 做為 Kubernetes 工作負載的儲存 144

13.6 解除安裝 Rook 144

viii 部署指南

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

詞彙 149

B 文件更新 152

B.1 SUSE Enterprise Storage 6 的維護更新文件 152

B.2 2019 年 6 月 (SUSE Enterprise Storage 6 發行) 153

ix 部署指南

關於本指南

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 意見反應以下為可供使用的數種意見回應管道：

x 可用文件 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」一章，↑另一本手冊)：這是對另一本手冊中某

一章的參考。

xi 文件慣例 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/ ，以取得詳細資料。

xii 關於本手冊編寫 SES 6

http://www.docbook.org

http://daps.sf.net/

https://ceph.com/contributors/

https://ceph.com/contributors/

I SUSE Enterprise Storage

1 SUSE Enterprise Storage 6 和 Ceph 2

2 硬體要求和建議 10

3 管理節點 HA 設定 19

4 使用者權限和指令提示 22

1 SUSE Enterprise Storage 6 和 Ceph

SUSE Enterprise Storage 6 是以 Ceph 技術為基礎的分散式儲存系統，旨在提高延

展性、可靠性和效能。Ceph 叢集可在通用網路 (例如乙太網路) 中的商用伺服器上執

行。此類叢集可以順利地擴展至數千部伺服器 (下文稱為「節點」) 並擁有 PB 級的處

理能力。與使用配置表來儲存和擷取資料的傳統系統相反，Ceph 使用決定性演算法來

為資料配置儲存空間，且不採用任何集中式資訊結構。Ceph 的假設是，在儲存叢集中

的硬體新增或移除屬於常例，而非例外情況。Ceph 叢集可將資料分發和重新分發、資

料複製、故障偵測和復原等管理任務自動化。Ceph 既可自我修復，又可自我管理，因

此降低了管理負荷和預算負擔。

本章提供 SUSE Enterprise Storage 6 的高階綜覽，並簡要介紹一些最重要的元件。

提示從 SUSE Enterprise Storage 5 開始，DeepSea 是唯一的叢集部署方法。如需

部署程序的詳細資料，請參閱第 5 章「使用 DeepSea/Salt 部署」。

1.1 Ceph 的特性

Ceph 環境具有以下特性：

延展性

Ceph 可延伸至數千個節點，並可管理 PB 級的儲存。

商用硬體

無需特殊的硬體即可執行 Ceph 叢集。如需詳細資料，請參閱第 2 章「硬體要

求和建議」。

自我管理

Ceph 叢集可自我管理。新增、移除節點或節點發生故障時，叢集可自動重新分發

資料。此外，它還能識別超載的磁碟。

無單一故障點

重要的資訊不會單獨儲存在叢集中的某個節點上。您可設定備援數量。

2 Ceph 的特性 SES 6

開放原始碼軟體

Ceph 是一套開放原始碼軟體解決方案，獨立於特定的硬體或廠商。

1.2 核心元件

若要充分利用 Ceph 的強大功能，需要瞭解一些基本的元件和概念。本節介紹經常在其

他章節中提及的 Ceph 的某些組成部分。

1.2.1 RADOS

Ceph 的基本元件稱為 RADOS (可靠自主分散式物件儲存) 。該元件負責管理叢集中儲

存的資料。Ceph 中的資料通常以物件的形式儲存。每個物件由識別碼和資料組成。

RADOS 提供以下方法來存取涉及許多使用案例的儲存物件：

物件閘道

物件閘道是 RADOS 物件儲存的 HTTP REST 閘道。使用該閘道可以直接存取 Ceph

叢集中儲存的物件。

RADOS 區塊裝置

您可以如同存取任何其他區塊裝置一般存取 RADOS 區塊裝置 (RBD)。例如，可將

這些裝置與 libvirt 組合使用，以實現虛擬化。

CephFS

Ceph 檔案系統是符合 POSIX 標準的檔案系統。

librados

librados 是一個程式庫，可與許多程式設計語言搭配使用，以建立能夠直接與儲

存叢集互動的應用程式。

librados 由物件閘道和 RBD 使用，而 CephFS 直接與 RADOS 連接。請參閱圖形 1.1

「與 Ceph 物件儲存的連接」。

3 核心元件 SES 6

RADOS

圖形 1.1︰與 CEPH 物件儲存的連接

1.2.2 CRUSH

Ceph 叢集的核心是 CRUSH 演算法。CRUSH 是 Controlled Replication Under

Scalable Hashing (基於可延展雜湊的受控複製) 的縮寫。CRUSH 是處理儲存配置的函

數，所需的參數相對較少。這意味著，只需提供少量的資訊就能計算物件的儲存位置。

參數是叢集的目前對應，包括健康狀態、管理員定義的某些放置規則，以及需要儲存或

擷取的物件名稱。提供這些資訊後，Ceph 叢集中的所有節點即可計算物件及其複本的

儲存位置。如此可讓資料寫入或讀取變得非常高效。CRUSH 會嘗試在叢集中的所有節點

上均勻分發資料。

CRUSH 地圖包含所有儲存節點，以及管理員定義的要在叢集中儲存物件的放置規則。該

地圖定義了通常對應於叢集實體結構的階層結構。例如，包含資料的磁碟位於主機中，

主機位於機架中，機架位於裝置列中，而裝置列位於資料中心中。此結構可用於定義故

障網域。然後，Ceph 可確保將複製項儲存在特定故障網域的不同分支中。

如果將故障網域設定為機架，則將在不同的機架中分發物件複製項。這樣做可緩解機架

中的交換器發生故障所造成的服務中斷。如果某個電源分配單位為一列機架供電，則可

將故障網域設定為裝置列。當電源分配單位發生故障時，其他裝置列中仍可提供複製的

資料。

1.2.3 Ceph 節點和精靈

在 Ceph 中，節點是為叢集工作的伺服器。它們可以執行多種不同類型的精靈。建議在

每個節點上僅執行一種類型的精靈，但 Ceph 管理員精靈除外，此類精靈可與 Ceph 監

控程式併置。每個叢集都至少需要執行 Ceph 監控程式、Ceph 管理員和 OSD 精靈：

4 CRUSH SES 6

管理節點

管理節點是執行 Salt Master 服務的 Ceph 叢集節點。管理節點是 Ceph 叢集的

中心點，因為它透過查詢叢集其餘節點的 Salt Minion 服務並提供指示來管理其

餘節點。它通常也會提供其他服務，例如包含 Grafana 儀表板 (由 Prometheus

監控工具套件提供支援) 的 Ceph Dashboard Web UI。

Ceph 監控程式

Ceph 監控程式 (通常縮寫為 MON) 節點負責維護有關叢集健康狀態、所有節點的

地圖和資料分發規則的資訊 (請參閱第 1.2.2 節「CRUSH」)。

如果發生故障或衝突，叢集中的 Ceph 監控程式節點會依據多數原則確定哪些

資訊是正確的。為了構成有效的多數，建議您設定奇數數量的 Ceph 監控程式節

點，並至少設定三個這樣的節點。

如果使用多個站點，應在奇數個站點之間分發 Ceph 監控程式節點。每個站點的

Ceph 監控程式節點數應滿足以下要求：當有一個站點發生故障時，50% 以上的

Ceph 監控程式節點仍保持正常執行。

Ceph 管理員

Ceph 管理員 (MGR) 會從整個叢集收集狀態資訊。Ceph 管理員精靈與監控程式精

靈一同執行。它會提供附加的監控功能，並與外部監控和管理系統連接。

Ceph 管理員不需要額外的組態，只需確保它在執行即可。您可以使用 DeepSea

將它部署為獨立的角色。

Ceph OSD

Ceph OSD 是一個精靈，負責處理屬於實體或邏輯儲存單位 (硬碟或分割區) 的物

件儲存裝置。物件儲存裝置可以是實體磁碟/分割區，也可以是邏輯磁碟區。此

外，該精靈還會處理資料複製，並在新增或移除節點後進行重新平衡。

Ceph OSD 精靈與監控程式精靈通訊，並為其提供其他 OSD 精靈的狀態。

若要使用 CephFS、物件閘道、NFS Ganesha 或 iSCSI 閘道，還需要其他節點：

中繼資料伺服器 (MDS)

中繼資料伺服器負責儲存 CephFS 的中繼資料。使用 MDS，您可以執行 ls 等基

本檔案系統指令，而不會讓叢集超載。

物件閘道

物件閘道是 RADOS 物件儲存的 HTTP REST 閘道。它與 OpenStack Swift 和

Amazon S3 相容，具有自己的使用者管理功能。

NFS Ganesha

5 Ceph 節點和精靈 SES 6

使用 NFS Ganesha 可透過 NFS 存取物件閘道或 CephFS。該元件在使用者空間而

不是核心空間中執行，直接與物件閘道或 CephFS 互動。

iSCSI 閘道

iSCSI 是一種儲存網路通訊協定，可讓用戶端將 SCSI 指令傳送至遠端伺服器上

的 SCSI 儲存裝置 (目標)。

Samba 閘道

Samba 閘道提供對 CephFS 上所儲存資料的 SAMBA 存取途徑。

1.3 儲存結構

1.3.1 池

Ceph 叢集中儲存的物件放置在池中。對外部環境而言，池代表叢集的邏輯分割區。對

於每個池，可以定義一組規則，例如，每個物件必須有多少個複製項。池的標準組態稱

為複本池。

池通常包含多個物件，但也可以將其設定為充當類似 RAID 5 的作用。在此組態中，物

件連同其他編碼區塊一起儲存在區塊中。編碼區塊包含備援資訊。管理員可以定義資料

和編碼區塊的數量。在此組態中，池稱為糾刪碼池。

1.3.2 放置群組

放置群組 (PG) 用於在池中分發資料。建立池時，會設定特定數目的放置群組。放置群

組在內部用於將物件分組，是影響 Ceph 叢集效能的重要因素。物件的 PG 依據該物件

的名稱確定。

1.3.3 範例

本節提供有關 Ceph 如何管理資料的簡化範例 (請參閱圖形 1.2 「小規模 Ceph 範

例」)。此範例並不代表 Ceph 叢集的建議組態。硬體設定由三個儲存節點或 Ceph OSD

(主機 1、主機 2 和主機 3 ) 組成。每個節點包含三個用做 OSD ( osd.1 到 osd.9 )

的硬碟。此範例中略過了 Ceph 監控程式節點。

6 儲存結構 SES 6

注意：Ceph OSD 與 OSD 之間的差別儘管 Ceph OSD 或 Ceph OSD 精靈是指節點上執行的精靈，但 OSD 一詞指的卻

是與精靈互動的邏輯磁碟。

叢集包含兩個池：池 A 和池 B。儘管池 A 僅複製物件兩次，但池 B 的韌性更重要，

該池中的每個物件都有三個複製項。

當應用程式將某個物件放入池中時 (例如，透過 REST API)，將會依據池和物件名稱選

擇放置群組 ( PG1 到 PG4 )。然後，CRUSH 演算法會依據包含物件的放置群組，計算要

將物件儲存到哪些 OSD。

在此範例中，故障網域設定為主機。這可確保將物件的複製項儲存在不同的主機上。依

據針對池設定的複製層級，物件將儲存在放置群組使用的兩個或三個 OSD 上。

寫入物件的應用程式只與一個 Ceph OSD (主要 Ceph OSD) 互動。主要 Ceph OSD 負責

處理複製程序，並在所有其他 OSD 儲存物件後確認寫入程序完成。

如果 osd.5 發生故障， osd.1 上仍會提供 PG1 中的所有物件。一旦叢集發現某個

OSD 發生故障，另一個 OSD 會立即接管工作。在此範例中， osd.4 用於取代 osd.5。

然後，會將 osd.1 上儲存的物件複製到 osd.4，以還原複製層級。

圖形 1.2︰小規模 CEPH 範例

7 範例 SES 6

如果將包含新 OSD 的新節點新增到叢集，叢集地圖將會發生變更。然後，CRUSH 函

數將傳回物件的不同位置。接收新位置的物件將被重新定位。此程序將平衡使用所有

OSD。

1.4 BlueStore

從 SUSE Enterprise Storage 5 開始，系統使用 BlueStore 做為 Ceph 的新預設儲存

後端。BlueStore 的效能優於 FileStore，具有全資料檢查總數及壓縮功能。

它可管理一至三部儲存裝置。在最簡單案例中，BlueStore 會使用一個主要儲存裝置。

該裝置通常被分割為兩部分：

1. 一個名為 BlueFS 的較小分割區，用於執行 RocksDB 所需的類似檔案系統的功

能。

2. 其餘部分通常是一個較大的分割區，佔用了裝置的剩餘空間。它直接由

BlueStore 管理，包含所有實際資料。此主要裝置通常透過資料目錄中的區塊符

號連結進行識別。

您還可跨兩個額外的裝置來部署 BlueStore：

WAL 裝置可用於儲存 BlueStore 的內部記錄或預寫記錄檔。它透過資料目錄中的

block.wal 符號連結進行識別。只有 WAL 裝置速度比主要裝置或 DB 裝置快時，使用

單獨的 WAL 裝置才比較實用，例如，下列情況就很適合：

WAL 裝置是 NVMe，DB 裝置是 SSD，資料裝置是 SSD 或 HDD。

WAL 和 DB 裝置都是單獨的 SSD，資料裝置是 SSD 或 HDD。

DB 裝置可用於儲存 BlueStore 的內部中繼資料。BlueStore (更確切地說，是內嵌式

RocksDB) 會將盡可能多的中繼資料儲存於 DB 裝置，以提升效能。再次重申，只有共

用 DB 裝置速度比主要裝置快時，佈建共用 DB 裝置才有所助益。

提示：規劃 DB 大小規劃時請考慮充分，以確定為 DB 裝置配置足夠的大小。如果 DB 裝置填滿，中

繼資料將溢出至主要裝置，這會嚴重降低 OSD 的效能。

8 BlueStore SES 6

您可以使用 ceph daemon osd.ID perf dump 指令來檢查 WAL/DB 分割區是否即將

填滿及溢出。 slow_used_bytes 值顯示即將溢出的資料數量：

cephadm@adm > ceph daemon osd.ID perf dump | jq '.bluefs'"db_total_bytes": 1073741824,"db_used_bytes": 33554432,"wal_total_bytes": 0,"wal_used_bytes": 0,"slow_total_bytes": 554432,"slow_used_bytes": 554432,

1.5 其他資訊

做為一個社群專案，Ceph 自身擁有大量線上文件。對於本手冊中未介紹的主題，

請參閱 http://docs.ceph.com/docs/master/ 。

由 S.A. Weil、S.A. Brandt、E.L. Miller 和 C. Maltzahn 撰寫的原始文獻

CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data

(CRUSH：複製資料的受控、可延展、分散式放置) 提供了有關 Ceph 內部工作原

理的有用見解。特別是在部署大規模叢集時，推薦您閱讀此文章。可在 http://

www.ssrc.ucsc.edu/papers/weil-sc06.pdf 上找到該文獻。

SUSE Enterprise Storage 可與非 SUSE OpenStack 套裝作業系統配合使

用。Ceph 用戶端需與 SUSE Enterprise Storage 相容。

注意SUSE 負責支援 Ceph 部署的伺服器元件，由 OpenStack 套裝作業系統廠商

對用戶端提供支援。

9 其他資訊 SES 6

http://docs.ceph.com/docs/master/

http://www.ssrc.ucsc.edu/papers/weil-sc06.pdf

http://www.ssrc.ucsc.edu/papers/weil-sc06.pdf

2 硬體要求和建議

Ceph 的硬體要求在很大程度上取決於 IO 工作負載。在開始進行詳細規劃時，應考慮

以下硬體要求和建議。

一般情況下，本節所述的建議是按程序提出的。如果同一部機器上有多個程序，則需要

提高 CPU、RAM、磁碟和網路要求。

2.1 多架構組態

SUSE Enterprise Storage 支援 x86 和 Arm 架構。考慮每個架構時，請務必注意從每

個 OSD 的核心數、頻率和 RAM 的角度進行，不同的 CPU 架構在大小調整方面並無實

際差異。

與較小的 x86 處理器 (非伺服器) 一樣，效能較低的基於 Arm 的核心可能無法提供最

佳體驗，特別是用於糾刪碼池時。

2.2 最低叢集組態

至少需要四個 OSD 節點，每個節點包含八個 OSD 磁碟。

三個 Ceph 監控程式節點 (需要使用 SSD 做為專屬 OS 磁碟機).

iSCSI 閘道、物件閘道和中繼資料伺服器需要遞增的 4 GB RAM 和四個核心。

Ceph 監控程式、物件閘道和中繼資料伺服器的節點需要備援部署。

具有 4 GB RAM、四個核心和 1 TB 容量的獨立管理節點，通常是 Salt Master

節點。管理節點上不支援 Ceph 監控程式、Ceph 管理員、中繼資料伺服器、Ceph

OSD、物件閘道或 NFS Ganesha 等 Ceph 服務和閘道。

10 多架構組態 SES 6

2.3 物件儲存節點

2.3.1 最低需求

CPU 建議：

每個旋轉式磁碟 1x 2GHz CPU 線串

每個 SSD 2x 2GHz CPU 線串

每個 NVMe 磁碟 4x 2GHz CPU 線串

獨立的 10 GbE 網路 (公用/用戶端和後端)，需要 4x 10 GbE，建議 2x 25

GbE。

總計所需 RAM = OSD 數量 x (1 GB + osd_memory_target ) + 16 GB

如需 osd_memory_target 的更多詳細資料，請參閱《管理指南》, 第 16 章

「Ceph 叢集組態」, 第 16.2.1 節「自動調整快取大小」。

OSD 磁碟採用 JBOD 組態或個別的 RAID-0 組態。

OSD 記錄可以存放在 OSD 磁碟上。

OSD 磁碟應該專門由 SUSE Enterprise Storage 使用。

作業系統專屬的磁碟/SSD，最好採用 RAID 1 組態。

如果此 OSD 主機將要代管用於快取分層的一部分快取池，請至少額外配置 4 GB

RAM。

Ceph 監控程式、閘道和中繼資料伺服器可以存放在物件儲存節點上。

考慮到磁碟效能，我們建議使用裸機做為 OSD 節點，而不要使用虛擬機器。

2.3.2 最小磁碟大小

需要在 OSD 上執行以下兩種類型的磁碟空間：磁碟記錄 (針對 FileStore) 或 WAL/DB

裝置 (針對 BlueStore) 的空間以及儲存資料的主要空間。記錄/WAL/DB 的最小 (預

設) 值為 6 GB。資料的最小空間為 5 GB，因為系統會自動為小於 5 GB 的分割區指定

權數 0。

11 物件儲存節點 SES 6

因此，儘管 OSD 的最小磁碟空間為 11 GB，但不建議使用小於 20 GB 的磁碟，即使在

測試中也是如此。

2.3.3 BlueStore 的 WAL 和 DB 裝置的建議大小

提示：更多資訊如需 BlueStore 的詳細資訊，請參閱第 1.4 節「BlueStore」。

我們建議為 WAL 裝置保留 4 GB。對於大多數工作負載而言，建議的 DB 大小為

64 GB。

如果您打算將 WAL 和 DB 裝置置於同一磁碟，建議您為這兩個裝置使用一個分割

區，而不是為每個裝置使用單獨的分割區。這樣，Ceph 便可以使用 DB 裝置來執

行 WAL 操作。這對於磁碟空間的管理也會更有效，因為 Ceph 只會在需要時才會

為 WAL 使用 DB 分割區。另一個好處是，WAL 分割區填滿的可能性很小，當該分

割區未完全利用時，其空間並不會浪費，而是用於 DB 操作。

若要與 WAL 共用 DB 裝置，請不要指定 WAL 裝置，而是僅指定 DB 裝置。

如需指定 OSD 配置的詳細資訊，請參閱第 5.5.2 節「DriveGroups」。

2.3.4 使用 SSD 儲存 OSD 記錄

固態硬碟 (SSD) 不包含移動部件。這可以減少隨機存取時間和讀取延遲，同時加快資

料輸送量。由於 SSD 的每 MB 價格大大高於旋轉型硬碟，SSD 只適用於較小規模的儲

存。

如果將記錄儲存在 SSD 上，並將物件資料儲存在獨立的硬碟上，OSD 的效能會得到大

幅提高。

提示：為多個記錄共用 SSD由於記錄資料佔用的空間相對較小，因此您可以將多個記錄目錄掛接至一個 SSD

磁碟。請注意，每共用一個記錄，SSD 磁碟的效能就會有所下降。不建議在同一

個 SSD 磁碟中共用 6 個以上的記錄，或者在 NVMe 磁碟中共用 12 個以上的記

錄。

12 BlueStore 的 WAL 和 DB 裝置的建議大小 SES 6

2.3.5 磁碟的最大建議數量

您可以在一部伺服器上使用所允許的任意數量的磁碟。規劃每部伺服器的磁碟數量時，

需要考慮以下幾點：

網路頻寬：在一部伺服器中使用的磁碟越多，執行磁碟寫入操作時必須透過網路

卡傳輸的資料就越多。

記憶體：系統會將超過 2 GB 的 RAM 用於 BlueStore 快取。當

osd_memory_target 設為預設值 4 GB 時，該起始快取大小對於旋轉式媒體而言是

比較合理的。如果使用 SSD 或 NVME，請考慮增加快取大小以及為每個 OSD 配置

的 RAM，以便最大限度地提高效能。

容錯：如果整部伺服器發生故障，則伺服器包含的磁碟越多，叢集暫時丟失的

OSD 就越多。此外，為了確保複製規則的執行，需要將發生故障伺服器中的所有

資料複製到叢集中的其他節點。

2.4 監控程式節點

至少需要三個 Ceph 監控程式節點。監控程式數量應永遠為奇數 (1+2n)。

4 GB RAM。

具有四個邏輯核心的處理器。

強烈建議您為監控程式使用 SSD 或其他速度足夠快的儲存類型，特別是針對每個

監控程式節點上的 /var/lib/ceph 路徑，因為最低核准人數可能不穩定且磁碟延

遲較高。建議提供兩個採用 RAID 1 組態的磁碟來進行備援。建議為監控程式程

序使用獨立的磁碟，或者至少是獨立的磁碟分割區，以防止記錄檔案增大等問題

導致監控程式的可用磁碟空間不足。

每個節點只能有一個監控程式程序。

僅當有足夠的硬體資源可用時，才支援混用 OSD、監控程式或物件閘道節點。這

意味著，對於所有服務需提高相應要求。

與多個交換器結合的兩個網路介面。

13 磁碟的最大建議數量 SES 6

2.5 物件閘道節點物件閘道節點應有 6 到 8 個 CPU 核心和 32 GB RAM (建議 64 GB)。如果將其他程序

併置在同一部機器上，則需要提高相應要求。

2.6 中繼資料伺服器節點中繼資料伺服器節點的適當大小取決於特定使用案例。一般而言，中繼資料伺服器需要

處理的開啟檔案越多，所需要的 CPU 和 RAM 就越多。以下是最低要求：

為每個中繼資料伺服器精靈指定 3 GB 的 RAM。

結合網路介面。

2.5 GHz CPU，至少具有兩個核心。

2.7 Salt Master至少需要 4 GB RAM 和四核 CPU。其中包括在管理節點上執行 Ceph Dashboard。對於

包含數百個節點的大型叢集，建議提供 6 GB RAM。

2.8 iSCSI 節點iSCSI 節點應有 6 到 8 個 CPU 核心和 16 GB RAM。

2.9 網路建議要執行 Ceph 的網路環境最好是至少包含兩個網路介面結合的組合，該組合使用 VLAN

邏輯分割成公共部分和可信的內部部分。如果可能，建議採用 802.3ad 結合模式，以

提供最高的頻寬和復原能力。

公共 VLAN 用於向客戶提供服務，而內部部分則用於已驗證的 Ceph 網路通訊。建議採

用此模式的主要原因在於，儘管 Ceph 可提供驗證並能在建立機密金鑰後防範攻擊，但

用於設定這些金鑰的訊息可能會公開傳輸，因而容易受到攻擊。

14 物件閘道節點 SES 6

提示：透過 DHCP 設定的節點如果儲存節點是透過 DHCP 設定的，則預設逾時可能會不夠長，無法保證能在各

個 Ceph 精靈啟動前正確設定網路。如果發生此問題，Ceph MON 和 OSD 將不會

正常啟動 (執行 systemctl status ceph\* 會導致「無法結合」錯誤)。為避免

此問題發生，建議您在儲存叢集的每個節點上，將 DHCP 用戶端逾時增加到至少

30 秒。為此，可在每個節點上變更以下設定：

在 /etc/sysconfig/network/dhcp 中，設定

DHCLIENT_WAIT_AT_BOOT="30"

在 /etc/sysconfig/network/config 中，設定

WAIT_FOR_INTERFACES="60"

2.9.1 將私人網路新增到執行中的叢集

如果您在 Ceph 部署期間未指定叢集網路，則系統假設使用的是單一公用網路環境。儘

管 Ceph 可在公用網路中正常運作，但如果您設定了另一個私人叢集網路，Ceph 的效

能和安全性將會得到提升。若要支援兩個網路，每個 Ceph 節點上至少需有兩個網路

卡。

需要對每個 Ceph 節點套用以下變更。對小型叢集執行此操作的速度相對較快，但如果

叢集包含數百甚至數千個節點，則此程序可能十分耗時。

1. 在每個叢集節點上停止 Ceph 相關的服務。

在 /etc/ceph/ceph.conf 中新增一行以定義叢集網路，例如：

cluster network = 10.0.0.0/24

如果需要指定具體的靜態 IP 位址或覆寫 cluster network 設定，您可以使用選

擇性的 cluster addr 執行此操作。

2. 檢查私人叢集網路在 OS 層級是否如預期般運作。

3. 在每個叢集節點上啟動 Ceph 相關的服務。

root # systemctl start ceph.target

15 將私人網路新增到執行中的叢集 SES 6

2.9.2 不同子網路中的監控程式節點

如果監控程式節點位於多個子網路中，例如，位於不同的房間並由不同的交換器

提供服務，則您需要相應地調整 ceph.conf 檔案。例如，如果節點的 IP 位址為

192.168.123.12、1.2.3.4 和 242.12.33.12，請將以下幾行新增至 global 區段：

[global][...]mon host = 192.168.123.12, 1.2.3.4, 242.12.33.12mon initial members = MON1, MON2, MON3[...]

此外，如果您需要指定每個監控程式的公用位址或網路，則需要為每個監控程式新增

[mon.X] 區段：

[mon.MON1]public network = 192.168.123.0/24



2.10 命名限制

一般情況下，Ceph 不支援在組態檔案、池名稱、使用者名稱等內容中使用非 ASCII 字

元。設定 Ceph 叢集時，建議您在所有 Ceph 物件/組態名稱中僅使用簡單的英數字元

(A-Z、a-z、0-9) 和最少量的標點符號 (「.」、「-」、「_」)。

2.11 共用一部伺服器的 OSD 和監控程式

儘管從技術上講可以在測試環境中的同一部伺服器上執行 Ceph OSD 和監控程式，但強

烈建議您在生產環境中為每個監控程式節點使用獨立的伺服器。這樣做的主要原因在於

效能 — 叢集包含的 OSD 越多，監控程式節點需要執行的 I/O 操作就越多。另外，當

監控程式節點與 OSD 之間共用一部伺服器時，OSD I/O 操作便將成為監控程式節點的

限制因素。

16 不同子網路中的監控程式節點 SES 6

另一個考慮因素是，是否要在 OSD、監控程式節點與伺服器上的作業系統之間共用磁

碟。答案非常簡單：如果可能，請將一個獨立的磁碟專門用於 OSD，並將一部獨立的伺

服器用於監控程式節點。

儘管 Ceph 支援基於目錄的 OSD，但 OSD 應永遠具有一個專屬磁碟，而不能與作業系

統共用一個磁碟。

提示如果確實有必要在同一部伺服器上執行 OSD 和監控程式節點，請將一個獨立磁

碟掛接至 /var/lib/ceph/mon 目錄以在該磁碟上執行監控程式，這樣可以稍微提

升一些效能。

2.12 建議的生產叢集組態

七個物件儲存節點

單一節點不超出總容量的 15% 左右

10 Gb 乙太網路 (與多個交換器結合的四個實體網路)

每個儲存叢集有 56 個以上的 OSD

每個 OSD 儲存節點具有 RAID 1 OS 磁碟

依據 6:1 的 SSD 記錄與 OSD 的比率為記錄提供 SSD

在每個物件儲存節點上，為每 TB 的原始 OSD 容量提供 1.5 GB RAM

為每個物件儲存節點上的每個 OSD 提供 2 GHz

專屬的實體基礎架構節點

三個 Ceph 監控程式節點：4 GB RAM，四核處理器，RAID 1 SSD 磁碟

一個 SES 管理節點：4 GB RAM，四核處理器，RAID 1 SSD 磁碟

閘道或中繼資料伺服器節點的備援實體部署：

17 建議的生產叢集組態 SES 6

物件閘道節點：32 GB RAM，八核處理器，RAID 1 SSD 磁碟

iSCSI 閘道節點：16 GB RAM，四核處理器，RAID 1 SSD 磁碟

中繼資料伺服器節點 (一個使用中/一個熱待命)：32 GB RAM，八核處理

器，RAID 1 SSD 磁碟

2.13 SUSE Enterprise Storage 6 以及其他

SUSE 產品

本節包含有關將 SUSE Enterprise Storage 6 與其他 SUSE 產品整合的重要資訊。

2.13.1 SUSE Manager

SUSE Manager 與 SUSE Enterprise Storage 未整合，因此 SUSE Manager 目前無法管

理 SUSE Enterprise Storage 叢集。

18 SUSE Enterprise Storage 6 以及其他 SUSE 產品 SES 6

3 管理節點 HA 設定

管理節點是執行 Salt Master 服務的 Ceph 叢集節點。管理節點是 Ceph 叢集的中心

點，因為它透過查詢叢集其餘節點的 Salt Minion 服務並提供指示來管理其餘節點。

它通常也會提供其他服務，例如包含 Grafana 儀表板 (由 Prometheus 監控工具套件

提供支援) 的 Ceph Dashboard Web UI。

如果管理節點發生故障，通常需要為該節點提供新的工作硬體，並透過最近的備份還原

完整的叢集組態堆疊。這種方法很費時，並會導致叢集故障。

為避免出現由於管理節點故障導致的 Ceph 叢集效能下降，建議您為 Ceph 管理節點使

用高可用性 (HA) 叢集。

3.1 管理節點的 HA 叢集概述

HA 叢集的原理是，當其中一個叢集節點發生故障時，由另一個節點自動接管其職責，

包括虛擬化管理節點。使用此方法時，其他 Ceph 叢集節點將不會知道管理節點發生故

障。

管理節點的精簡 HA 解決方案需要以下硬體：

兩部能夠執行具有高可用性延伸的 SUSE Linux Enterprise，以及虛擬化管理節

點的裸機伺服器。

兩個或多個備援網路通訊路徑，例如透過網路裝置結合。

用於代管管理節點虛擬機器磁碟影像的共用儲存。必須能夠透過這兩部伺服器存

取共用儲存。例如，共用儲存可以是 NFS 輸出、Samba 共用或 iSCSI 目標。

如需叢集要求的更多詳細資料，請造訪 https://www.suse.com/documentation/sle-

ha-15/book_sleha_quickstarts/data/sec_ha_inst_quick_req.html 。

19 管理節點的 HA 叢集概述 SES 6

https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/sec_ha_inst_quick_req.html

https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/sec_ha_inst_quick_req.html

圖形 3.1︰管理節點的雙節點 HA 叢集

3.2 建構含管理節點的 HA 叢集

以下程序摘要了建構將管理節點虛擬化的 HA 叢集的幾個最重要步驟。如需詳細資料，

請參閱指定連結。

1. 設定一個具有共用儲存的基本雙節點 HA 叢集，如 https://

www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/

art_sleha_install_quick.html 中所述。

2. 在兩個叢集節點上，安裝執行 KVM 監管程式和 libvirt 工具套件所需的所有

套件，如 https://www.suse.com/documentation/sles-15/book_virt/data/

sec_vt_installation_kvm.html 中所述。

3. 在第一個叢集節點上，使用 libvirt 建立新的 KVM 虛擬機器 (VM)，

如 https://www.suse.com/documentation/sles-15/book_virt/data/

sec_libvirt_inst_vmm.html 中所述。使用預先設定的共用儲存來儲存虛擬機

器的磁碟影像。

4. 虛擬機器設定完成後，將其組態輸出至共用儲存上的 XML 檔案。使用以下語法：

root # virsh dumpxml VM_NAME > /path/to/shared/vm_name.xml

20 建構含管理節點的 HA 叢集 SES 6

https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/art_sleha_install_quick.html



https://www.suse.com/documentation/sles-15/book_virt/data/sec_vt_installation_kvm.html

https://www.suse.com/documentation/sles-15/book_virt/data/sec_vt_installation_kvm.html

https://www.suse.com/documentation/sles-15/book_virt/data/sec_libvirt_inst_vmm.html

https://www.suse.com/documentation/sles-15/book_virt/data/sec_libvirt_inst_vmm.html

5. 為管理節點虛擬機器建立資源。如需建立 HA 資源的一般資訊，請參閱

https://www.suse.com/documentation/sle-ha-15/book_sleha_guide/data/

cha_conf_hawk2.html 。http://www.linux-ha.org/wiki/VirtualDomain_

%28resource_agent%29 中提供了有關為 KVM 虛擬機器建立資源的詳細資訊。

6. 在新建立的虛擬機器客體中，部署管理節點，包括您需要在其上使用的其他服

務。執行第 5.3 節「叢集部署」中的相關步驟。同時，在非 HA 叢集伺服器上

部署其餘 Ceph 叢集節點。

21 建構含管理節點的 HA 叢集 SES 6

https://www.suse.com/documentation/sle-ha-15/book_sleha_guide/data/cha_conf_hawk2.html

https://www.suse.com/documentation/sle-ha-15/book_sleha_guide/data/cha_conf_hawk2.html

http://www.linux-ha.org/wiki/VirtualDomain_%28resource_agent%29

http://www.linux-ha.org/wiki/VirtualDomain_%28resource_agent%29

4 使用者權限和指令提示

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

行以下幾種類型的指令：

4.1 與 Salt/DeepSea 相關的指令

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

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

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

指令 (如需詳細資料，請參閱第 5.2 節「DeepSea 簡介」)。透過以下提示符來引入

這些指令：

root@master #

例如：

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

4.2 與 Ceph 相關的指令

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

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

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

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

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

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

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

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

22 與 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 >

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

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

權限。

4.4 其他資訊如需 Ceph 金鑰管理的詳細資訊，請參閱《管理指南》, 第 8 章「使用 cephx 進行驗

證」, 第 8.2 節「金鑰管理」。

23 一般的 Linux 指令 SES 6

II 叢集部署和升級

5 使用 DeepSea/Salt 部署 25

6 從舊版本升級 57

7 自訂預設組態 84

5 使用 DeepSea/Salt 部署

Salt 與 DeepSea 是元件的堆疊，可協助您部署和管理伺服器基礎架構。Salt 具有很

高的可延展性，速度快，且相對容易執行。在開始使用 Salt 部署叢集之前，請閱讀以

下注意事項：

Salt Minion 是由一個稱為 Salt Master 的專屬節點控制的節點。Salt Minion

具有角色，例如 Ceph OSD、Ceph 監控程式、Ceph 管理員、物件閘道、iSCSI 閘

道或 NFS Ganesha。

Salt Master 會執行自己的 Salt Minion。執行特權任務 (例如，建立、授權金

鑰以及將金鑰複製到 Minion) 需要 Salt Master，這樣，遠端 Minion 就永遠不

需要執行特權任務。

提示：每部伺服器共用多個角色如果將每個角色都部署在一個獨立節點上，則 Ceph 叢集的效能是最佳的。

但實際部署有時會要求多個角色共用一個節點。為避免效能欠佳以及升級程

序出現問題，請勿向管理節點部署 Ceph OSD、中繼資料伺服器或 Ceph 監

控程式角色。

Salt Minion 需要能透過網路正確解析 Salt Master 的主機名稱。預設情況

下，Minion 會尋找 salt 主機名稱，但您可以在 /etc/salt/minion 檔案中指定

可透過網路連接的其他任何主機名稱，具體請參閱第 5.3 節「叢集部署」。

5.1 閱讀版本說明

在版本說明中，您可以找到其他有關自 SUSE Enterprise Storage 的上一個版本發行

後所進行的變更的資訊。檢查版本說明以瞭解：

您的硬體是否有特殊的注意事項。

所用的任何軟體套件是否已發生重大變更。

是否需要對您的安裝施行特殊預防措施。

25 閱讀版本說明 SES 6

版本說明還會提供無法及時編入手冊的資訊。它們還包含有關已知問題的說明。

安裝套件 release-notes-ses之後，本地的 /usr/share/doc/release-notes 目錄中或

https://www.suse.com/releasenotes/ 網頁上會提供版本說明。

5.2 DeepSea 簡介DeepSea 旨在節省管理員的時間，讓他們能夠自信地對 Ceph 叢集執行複雜操作。

Ceph 是一款高度可設定的軟體解決方案。它提高了系統管理員的自由度和職責履行能

力。

最低的 Ceph 設定能夠很好地滿足展示目的，但無法顯示 Ceph 在處理大量節點時可體

現的卓越功能。

DeepSea 會收集並儲存個別伺服器的相關資料，例如位址和裝置名稱。對於諸如 Ceph

的分散式儲存系統，可能需要收集並儲存數百個這樣的項目。收集資訊並手動將資料輸

入至組態管理工具的程序非常耗費精力，並且容易出錯。

準備伺服器、收集組態資訊以及設定和部署 Ceph 所需執行的步驟大致相同。但是，這

種做法無法解決管理獨立功能的需求。在日常操作中，必須做到不厭其煩地將硬體新增

至給定的功能，以及適當地移除硬體。

DeepSea 透過以下策略解決了這些需求：DeepSea 可將管理員的多項決策合併到一個檔

案中。這些決策包括叢集指定、角色指定和設定檔指定。此外，DeepSea 還會收集各組

任務以組成一個簡單的目標。每個目標就是一個階段：

DEEPSEA 階段描述

階段 0 — 準備：在此階段，將套用全部所需的更新，並且可能會將您的系統重

新開機。

重要：管理節點重新開機後重新執行階段 0如果在階段 0 執行期間，管理節點進行了重新開機以載入新核心版本，則

您需要再次執行階段 0，否則將無法定位 Minion。

階段 1 即探查階段，在此階段會偵測您叢集中的所有硬體，並會收集 Ceph 組態

的必要資訊。如需組態的詳細資料，請參閱第 5.5 節「組態和自訂」。

階段 2 — 組態：您需要以特定的格式準備組態資料。

26 DeepSea 簡介 SES 6

https://www.suse.com/releasenotes/

階段 3 — 部署：建立包含必要 Ceph 服務的基本 Ceph 叢集。如需必要服務的

清單，請參閱第 1.2.3 節「Ceph 節點和精靈」。

階段 4 — 服務：可在此階段安裝 Ceph 的其他功能，例如 iSCSI、物件閘道和

CephFS。其中每個功能都是選擇性的。

階段 5 — 移除階段：此階段不是必需的，在啟始設定期間，通常不需要此階

段。在此階段，將會移除 Minion 的角色以及叢集組態。如果您需要從叢集中移

除某個儲存節點，則需要執行此階段。如需詳細資料，請參閱《管理指南》, 第

2 章「Salt 叢集管理」, 第 2.3 節「移除和重新安裝叢集節點」。

5.2.1 組織和重要位置

Salt 在 Master 節點上使用多個標準位置和多個命名約定：

/srv/pillar

該目錄儲存叢集 Minion 的組態資料。Pillar 是向所有叢集 Minion 提供全域組

態值的介面。

/srv/salt/

該目錄儲存 Salt 狀態檔案 (也稱為 sls 檔案)。狀態檔案是叢集應處於狀態的

帶格式說明。

/srv/module/runners

該目錄儲存稱為執行程式的 Python 程序檔。執行程式在 Master 節點上執行。

/srv/salt/_modules

該目錄儲存稱為模組的 Python 程序檔。這些模組將套用於叢集中的所有

Minion。

/srv/pillar/ceph

該目錄由 DeepSea 使用。收集的組態資料儲存在此處。

/srv/salt/ceph

DeepSea 使用的目錄。其中儲存了可採用不同格式的 sls 檔案，但 sls 檔案包

含在各子目錄中。每個子目錄僅包含一種類型的 sls 檔案。例如， /srv/salt/

ceph/stage 包含 salt-run state.orchestrate 執行的協調化檔案。

27 組織和重要位置 SES 6

5.2.2 定位 Minion

DeepSea 指令透過 Salt 基礎架構執行。使用 salt 指令時，您需要指定一組將受到

該指令影響的 Salt Minion。我們將該組 Minion 描述為 salt 指令的目標。以下各

節說明定位 Minion 的可行方法。

5.2.2.1 比對 Minion 名稱

您可以透過名稱比對來定位一個或一組 Minion。Minion 的名稱通常為執行該 Minion

的節點的短主機名稱。這是一種一般的 Salt 定位方法，與 DeepSea 無關。您可以使

用萬用字元、一般運算式或清單來限制 Minion 名稱的範圍。遵循的一般語法如下：

root@master # salt target example.module

提示：僅限 Ceph 叢集如果您環境中的所有 Salt Minion 均屬於 Ceph 叢集，則可以安全地使用 '*'

取代 target，以包含所有註冊的 Minion。

比對 example.net 網域中的所有 Minion (假設 Minion 名稱與其「完整」的主機名稱

相同)：

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

比對「web1」Minion 與「web5」Minion：

root@master # salt 'web[1-5]' test.ping

使用一般運算式比對「web1-prod」和「web1-devel」Minion：

root@master # salt -E 'web1-(prod|devel)' test.ping

比對簡單的 Minion 清單：

root@master # salt -L 'web1,web2,web3' test.ping

比對叢集中的所有 Minion：

root@master # salt '*' test.ping

28 定位 Minion SES 6

5.2.2.2 使用 DeepSea 粒紋進行定位

在受 Salt 管理的異質環境中 (SUSE Enterprise Storage 6 與其他叢集解決方案一併

部署在一部分節點上)，執行 DeepSea 階段 0 之前，您需要透過對相關 Minion 套用

「deepsea」粒紋來標示它們。這樣您便可以在無法透過 Minion 名稱比對的環境中輕

鬆定位 DeepSea Minion。

若要將「deepse」Grain 套用於一組 Minion，請執行以下指令：

root@master # salt target grains.append deepsea default

若要從一組 Minion 移除「deepse」Grain，請執行以下指令：

root@master # salt target grains.delval deepsea destructive=True

將「deepsea」Grain 套用於相關 Minion 後，您可以執行以下指令來進行定位：

root@master # salt -G 'deepsea:*' test.ping

或執行以下等效指令：

root@master # salt -C 'G@deepsea:*' test.ping

5.2.2.3 設定 deepsea_minions 選項

設定 deepsea_minions 選項的目標是 DeepSea 部署所需。在階段執行期間，DeepSea

會使用該選項指示 Minion (如需詳細資料，請參閱DeepSea 階段描述)。

若要設定或變更 deepsea_minions 選項，請編輯 Salt Master 上的 /srv/pillar/

ceph/deepsea_minions.sls 檔案，新增或取代下行：

deepsea_minions: target

提示：deepsea_minions 目標對於 deepsea_minions 選項的 target，您可以使用以下任何定位方法：比對

Minion 名稱和使用 DeepSea 粒紋進行定位。

比對叢集中的所有 Salt Minion：

deepsea_minions: '*'

29 定位 Minion SES 6

使用「deepsea」Grain 比對所有 Minion：

deepsea_minions: 'G@deepsea:*'

5.2.2.4 更多資訊

您可以使用 Salt 基礎架構以更進階的方式來定位 Minion。您可以透過「deepsea-

minions」手冊頁瞭解有關 DeepSea 定位的更多詳細資料 ( man 7 deepsea_minions )。

5.3 叢集部署

叢集部署程序包括多個階段。首先，需要透過設定 Salt 來準備叢集的所有節點，然後

部署並設定 Ceph。

提示：在未定義 OSD 設定檔的情況下部署監控程式節點如果您需要跳過定義 OSD 的儲存角色 (如第 5.5.1.2 節「角色指定」所述)，

先部署 Ceph 監控程式節點，則可以透過設定 DEV_ENV 變數來實現。

此設定允許您在 role-storage/ 目錄不存在的情況下部署監控程式，以及部署至

少包含一個儲存、監控程式和管理員角色的 Ceph 叢集。

若要設定環境變數，請將其全域啟用，方法是在 /srv/pillar/ceph/stack/

global.yml 檔案中進行設定，或者僅針對目前的外圍程序工作階段設定：

root@master # export DEV_ENV=true

例如，可建立包含以下內容的 /srv/pillar/ceph/stack/global.yml：

DEV_ENV: True

下面詳細說明了叢集準備程序。

1. 在叢集的每個節點上安裝並註冊 SUSE Linux Enterprise Server 15 SP1 以及

SUSE Enterprise Storage 6 延伸。

30 叢集部署 SES 6

2. 列出現有的軟體儲存庫，驗證是否已安裝並註冊正確的產品。執行 zypper lr -

E，並將輸出與以下清單進行比較：

SLE-Product-SLES15-SP1-Pool SLE-Product-SLES15-SP1-Updates SLE-Module-Server-Applications15-SP1-Pool SLE-Module-Server-Applications15-SP1-Updates SLE-Module-Basesystem15-SP1-Pool SLE-Module-Basesystem15-SP1-Updates SUSE-Enterprise-Storage-6-Pool SUSE-Enterprise-Storage-6-Updates

3. 在每個節點上設定網路設定，包括正確的 DNS 名稱解析。Salt Master 和所有

Salt Minion 需要依據各自的主機名稱相互解析。如需設定網路的詳細資訊，

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

sec_network_yast.html 。如需設定 DNS 伺服器的詳細資訊，請參閱 https://

www.suse.com/documentation/sles-15/book_sle_admin/data/cha_dns.html 。

4. 選取一或多個時間伺服器/池，並將其與本地時間同步。確認每次系統啟動時都會

啟用時間同步服務。您可以使用 yast ntp-client 指令 (在 yast2-ntp-client

套件中提供) 來設定時間同步。

提示虛擬機器並非可靠的 NTP 來源。

如需設定 NTP 的詳細資訊，請參閱 https://www.suse.com/documentation/

sles-15/book_sle_admin/data/sec_ntp_yast.html 。

5. 在 Salt Master 節點上安裝 salt-master 和 salt-minion 套件：

root@master # zypper in salt-master salt-minion

檢查 salt-master 服務是否已啟用並啟動，並視需要進行啟用和啟動：

root@master # systemctl enable salt-master.serviceroot@master # systemctl start salt-master.service

6. 如果您要使用防火牆，請驗證 Salt Master 節點是否為所有 Salt Minion 節點

開啟了連接埠 4505 和 4506。如果這些連接埠處於關閉狀態，您可以使用 yast2

firewall 指令並透過允許 SaltStack 服務來開啟這些連接埠。


https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_network_yast.html

https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_network_yast.html

https://www.suse.com/documentation/sles-15/book_sle_admin/data/cha_dns.html

https://www.suse.com/documentation/sles-15/book_sle_admin/data/cha_dns.html

https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_ntp_yast.html

https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_ntp_yast.html

警告：使用防火牆時，DeepSea 階段失敗當防火牆處於使用中狀態 (甚至只是設定了防火牆) 時，DeepSea 部署階段

會失敗。若要正確完成該階段，需要執行以下指令關閉防火牆

root # systemctl stop firewalld.service

或在 /srv/pillar/ceph/stack/global.yml 中將 FAIL_ON_WARNING 選項設

為「False」：

FAIL_ON_WARNING: False

7. 在所有 Minion 節點上安裝 salt-minion 套件。

root@minion > zypper in salt-minion

請確定所有其他節點都可將每個節點的完全合格的網域名稱解析為公用網路 IP

位址。

8. 設定所有 Minion (包括 Master Minion) 以連接至 Master。如果無法透過主機

名稱 salt 連接 Salt Master，請編輯檔案 /etc/salt/minion，或建立包含以下

內容的新檔案 /etc/salt/minion.d/master.conf：

master: host_name_of_salt_master

如果對上述組態檔案執行了任何變更，請在所有 Salt Minion 上重新啟動 Salt

服務：

root@minion > systemctl restart salt-minion.service

9. 檢查所有節點上是否已啟用並啟動 salt-minion 服務。依據需要啟用並啟動該服

務：

root # systemctl enable salt-minion.serviceroot # systemctl start salt-minion.service

10. 驗證每個 Salt Minion 的指紋，如果指紋相符，則接受 Salt Master 上的所有

Salt 金鑰。


注意如果 Salt Minion 指紋傳回空白，請確定 Salt Minion 具有 Salt Master

組態且可與 Salt Master 通訊。

檢視每個 Minion 的指紋：

root@master # salt-call --local key.fingerlocal:3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

收集到所有 Salt Minion 的指紋後，將列出 Salt Master 上所有未接受 Minion

金鑰的指紋：

root@master # salt-key -F[...]Unaccepted Keys:minion1:3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

如果 Minion 的指紋相符，則接受這些金鑰：

root@master # salt-key --accept-all

11. 驗證是否已接受金鑰：

root@master # salt-key --list-all

12. 在部署 SUSE Enterprise Storage 6 前，手動清理所有磁碟。請記得使用正確的

磁碟代號取代「X」：

a. 停止使用特定磁碟的所有程序。

b. 驗證磁碟上是否掛接有任何分割區，並視需要進行卸載。

c. 如果磁碟由 LVM 管理，請停用整個 LVM 基礎架構並將其刪除。如需更

多詳細資料，請參閱 https://www.suse.com/documentation/sles-15/

book_storage/data/cha_lvm.html 。


https://www.suse.com/documentation/sles-15/book_storage/data/cha_lvm.html

https://www.suse.com/documentation/sles-15/book_storage/data/cha_lvm.html

d. 如果磁碟是 MD RAID 的一部分，請停用 RAID。如需更多詳細資料，請參

閱 https://www.suse.com/documentation/sles-15/book_storage/data/

part_software_raid.html 。

e.提示：將伺服器重新開機如果您在執行以下步驟時收到諸如「分割區正在使用」或「無法使用

新的分割區表更新核心」之類的錯誤訊息，請將伺服器重新開機。

抹除每個分割區的開頭部分 (以 root 身分)：

for partition in /dev/sdX[0-9]*do dd if=/dev/zero of=$partition bs=4096 count=1 oflag=directdone

f. 抹除磁碟機的開頭部分：

root # dd if=/dev/zero of=/dev/sdX bs=512 count=34 oflag=direct

g. 抹除磁碟機的結尾部分：

root # dd if=/dev/zero of=/dev/sdX bs=512 count=33 \ seek=$((`blockdev --getsz /dev/sdX` - 33)) oflag=direct

h. 使用以下指令確認磁碟機是空的 (不含 GPT 結構)：

root # parted -s /dev/sdX print free

或

root # dd if=/dev/sdX bs=512 count=34 | hexdump -Croot # dd if=/dev/sdX bs=512 count=33 \ skip=$((`blockdev --getsz /dev/sdX` - 33)) | hexdump -C

13. (選擇性) 如果您需要在安裝 deepsea 套件之前預先組態叢集的網路設定，請手

動建立 /srv/pillar/ceph/stack/ceph/cluster.yml，並設定 cluster_network:

和 public_network: 選項。請注意，在您安裝 deepsea之後，系統將不會覆寫該

檔案。


https://www.suse.com/documentation/sles-15/book_storage/data/part_software_raid.html

https://www.suse.com/documentation/sles-15/book_storage/data/part_software_raid.html

提示：啟用 IPv6如果您需要啟用 IPv6 網路定址，請參閱第 7.2.1 節「為 Ceph 叢集部署

啟用 IPv6」。

14. 在 Salt Master 節點上安裝 DeepSea：

root@master # zypper in deepsea

15. master_minion 參數的值是依據 Salt Master 上的 /etc/salt/minion_id 檔

案動態衍生的。如果您需要覆寫探查的值，請編輯 /srv/pillar/ceph/stack/

global.yml 檔案並設定相關值：

master_minion: MASTER_MINION_NAME

如果可透過更多主機名稱存取您的 Salt Master，請使用 salt-key -L 指令傳

回的名稱做為儲存叢集的 Salt Minion 名稱。如果在 ses 網域中使用 Salt

Master 的預設主機名稱 salt，則該檔案如下所示：

master_minion: salt.ses

現在部署並設定 Ceph。除非另有說明，否則必須執行所有步驟。

注意：Salt 指令慣例可透過兩種方式執行 salt-run state.orch，一種方式是使用

「stage. STAGE_NUMBER」，另一種方式是使用階段的名稱。這兩種標記法會產生

相同的效果，至於使用哪個指令，完全取決於您的偏好。

程序 5.1︰執行部署階段

1. 確定可透過 /srv/pillar/ceph/deepsea_minions.sls 中的 deepsea_minions 選項

正確定位到屬於 Ceph 叢集的 Salt Minion。如需相關資訊，請參閱第 5.2.2.3

節「設定 deepsea_minions 選項」。


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

後的使用中設定檔來部署 Ceph 叢集。在某些情形中，您可能需要在沒有已調整

設定檔的情況下進行部署。若要完成此操作，請在執行 DeepSea 階段前在 /srv/

pillar/ceph/stack/global.yml 中新增下面幾行。

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

3. 選擇性：為 /var/lib/ceph/ 建立 Btrfs 子磁碟區。需要在執行 DeepSea

stage.0 之前執行此步驟。若要移轉現有目錄或瞭解更多詳細資料，請參閱《管

理指南》, 第 25 章「技巧與提示」, 第 25.6 節「Ceph 監控程式節點上 /var/

lib/ceph 的 Btrfs 子磁碟區」。

對每個 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。

4. 準備叢集。如需更多詳細資料，請參閱DeepSea 階段描述。

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

或

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

注意：使用 DeepSea CLI 執行或監控階段使用 DeepSea CLI，可透過在監控模式下執行 DeepSea CLI，或者直接透過

DeepSea CLI 執行階段，來即時追蹤階段執行進度。如需詳細資料，請參

閱第 5.4 節「DeepSea CLI」。


5. 探查階段會從所有 Minion 收集資料並建立組態片段，這些片段儲存在 /srv/

pillar/ceph/proposals 目錄中。資料以 YAML 格式儲存在 *.sls 或 *.yml 檔案

中。

執行以下指令以觸發探查階段：


或

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

6. 成功完成上述指令後，請在 /srv/pillar/ceph/proposals 中建立 policy.cfg 檔

案。如需詳細資料，請參閱第 5.5.1 節「policy.cfg 檔案」。

提示如果需要變更叢集的網路設定，請編輯 /srv/pillar/ceph/stack/ceph/

cluster.yml，調整以 cluster_network: 和 public_network: 開頭的行。

7. 組態階段將會剖析 policy.cfg 檔案，並將包含的檔案合併為其最終形式。叢集

和角色相關的內容放置於 /srv/pillar/ceph/cluster 中，而 Ceph 特定的內容放

置於 /srv/pillar/ceph/stack/default 中。

執行以下指令以觸發組態階段：


或

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

組態步驟可能需要數秒完成。指令完成後，您可以透過執行以下指令，檢視指定

Minion (例如，名為 ceph_minion1、 ceph_minion2 等的 Minion) 的 pillar 資

料：

root@master # salt 'ceph_minion*' pillar.items


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

節「DriveGroups」所述的程序。

注意：覆寫預設值一旦指令完成，您便可檢視預設組態並視需要進行變更。如需詳細資料，請

參閱第 7 章「自訂預設組態」。

8. 現在執行部署階段。在此階段，將驗證 Pillar 並會啟動 Ceph 監控程式和 Ceph

OSD 精靈：


或

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

執行該指令需要幾分鐘時間。如果該指令失敗，則您需要解決問題，然後再次執

行前面的階段。該指令成功後，請執行以下指令來檢查狀態：

cephadm@adm > ceph -s

9. Ceph 叢集部署程序的最後一個步驟是服務階段。在此階段，您要例項化目前支援

的所有服務：iSCSI 閘道、CephFS、物件閘道、和 NFS Ganesha。此階段將建立

所需的池、授權金鑰圈和啟動服務。若要啟動該階段，請執行以下指令：


或

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

視具體設定而定，該指令可能會執行幾分鐘時間。

10. 繼續之前，我們強烈建議先啟用 Ceph 遙測模組。如需詳細資訊和說明，請參

閱《管理指南》, 第 10 章「Ceph 管理員模組」, 第 10.2 節「遙測模組」。


5.4 DeepSea CLI

DeepSea 還提供了一個指令行介面 (CLI) 工具，供使用者監控或執行階段，同時即時

直觀地呈現執行進度。確認是否已安裝 deepsea-cli 套件 (在您執行 deepsea 可執行

檔之前)。

支援使用以下兩種模式來視覺化階段的執行進度：

DEEPSEA CLI 模式

監控模式：視覺化另一個終端工作階段中發出的 salt-run 指令所觸發 DeepSea

階段的執行進度。

獨立模式：執行 DeepSea 階段，並在該階段的組成步驟執行時提供相應的即時視

覺化效果。

重要：DeepSea CLI 指令在 Salt Master 節點上，必須使用 root 權限才能執行 DeepSea CLI 指令。

5.4.1 DeepSea CLI：監控模式

進度監控程式提供詳細的即時視覺化效果，顯示在其他終端機工作階段中使用 salt-

run state.orch 指令執行階段期間發生的情況。

提示：在新終端機工作階段中啟動監控程式在執行任何 salt-run state.orch 指令之前，您都需要在新終端機視窗中啟動監

控程式，如此，當階段開始執行時，監控程式便可以偵測到。

如果在發出 salt-run state.orch 指令之後再啟動監控程式，將不會顯示執行進度。

您可執行以下指令來啟動監控模式：

root@master # deepsea monitor

如需 deepsea 監控程式指令的可用指令行選項的詳細資訊，請查看該指令的手冊頁：

39 DeepSea CLI SES 6

root@master # man deepsea-monitor

5.4.2 DeepSea CLI：獨立模式

在獨立模式下，可以使用 DeepSea CLI 來執行 DeepSea 階段，並即時顯示其執行進

度。

從 DeepSea CLI 執行 DeepSea 階段的指令遵循以下格式：

root@master # deepsea stage run stage-name

其中， stage-name 對應於 Salt 協調化狀態檔案的參考方式。例如，對應於 /srv/

salt/ceph/stage/deploy 中目錄的部署階段以 ceph.stage.deploy 的形式參考。

此指令可取代用於執行 DeepSea 階段 (或任何 DeepSea 協調化狀態檔案) 的基於

Salt 的指令。

指令 deepsea stage run ceph.stage.0 與 salt-run state.orch ceph.stage.0 等效。

如需 deepsea stage run 指令接受的可用指令行選項的詳細資訊，請查看該指令的手

冊頁：

root@master # man deepsea-stage run

下圖顯示了執行階段 2 時，DeepSea CLI 的輸出範例：

40 DeepSea CLI：獨立模式 SES 6

圖形 5.1︰ DEEPSEA CLI 階段執行進度輸出

5.4.2.1 DeepSea CLI stage run 別名

針對 Salt 的進階使用者，我們還支援使用別名來執行 DeepSea 階段，採用執行階段

所用的 Salt 指令 (例如 salt-run state.orch stage-name ) 做為 DeepSea CLI 的指

令。

範例：

root@master # deepsea salt-run state.orch stage-name

41 DeepSea CLI：獨立模式 SES 6

5.5 組態和自訂

5.5.1 policy.cfg 檔案

/srv/pillar/ceph/proposals/policy.cfg 組態檔案用於確定個別叢集節點的角色。例

如，哪些節點充當 Ceph OSD 或 Ceph 監控程式。請編輯 policy.cfg，以反映所需的

叢集設定。區段採用任意順序，但所包含行的內容將覆寫前面行的內容中相符的金鑰。

提示：policy.cfg 的範例您可以在 /usr/share/doc/packages/deepsea/examples/ 目錄中找到完整規則檔

案的多個範例。

5.5.1.1 叢集指定

在 cluster 區段中選取叢集的 Minion。您可以選取所有 Minion，也可以將 Minion

加入黑名單或白名單。下面顯示了名為 ceph 的叢集的範例。

若要包含所有 Minion，請新增以下幾行：

cluster-ceph/cluster/*.sls

若要將特定的 Minion 加入白名單，請執行以下指令：

cluster-ceph/cluster/abc.domain.sls

若要將一組 Minion 加入白名單，可以使用外圍程序萬用字元：

cluster-ceph/cluster/mon*.sls

若要將 Minion 加入黑名單，可將其設定為 unassigned：

cluster-unassigned/cluster/client*.sls

42 組態和自訂 SES 6

5.5.1.2 角色指定

本節詳細介紹了如何為您的叢集節點指定「角色」。在本文中，「角色」是指您需要在

節點上執行的服務，例如 Ceph 監控程式、物件閘道或 iSCSI 閘道。不會自動指定任

何角色，只會部署已新增到 policy.cfg 中的角色。

指定遵循以下模式：

role-ROLE_NAME/PATH/FILES_TO_INCLUDE

其中的項目具有以下意義和值：

ROLE_NAME 為下列任何一項：「master」、「admin」、「mon」、「mgr」、

「storage」、「mds」、「igw」、「rgw」、「ganesha」、「grafana」或

「prometheus」。

PATH 是 .sls 或 .yml 檔案的相對目錄路徑。對於 .sls 檔案，該路徑通常是

cluster；而 .yml 檔案則位於 stack/default/ceph/minions。

FILES_TO_INCLUDE 是 Salt 狀態檔案或 YAML 組態檔案。這些檔案通常包含 Salt

Minion 的主機名稱，例如 ses5min2.yml。您可以使用外圍程序萬用字元進行更具

體的相符。

每個角色的範例如下：

master - 該節點具有所有 Ceph 叢集的管理金鑰圈。目前僅支援一個 Ceph 叢

集。由於 master 角色是必需的，因此，請一律新增類似下方所示的行：

role-master/cluster/master*.sls

admin - 該 Minion 將取得管理金鑰圈。您可按如下方式定義角色：

role-admin/cluster/abc*.sls

mon - 該 Minion 將向 Ceph 叢集提供監控程式服務。此角色需要已指定 Minion

的位址。從 SUSE Enterprise Storage 5 開始，將以動態方式計算公用位址，並

且 Salt Pillar 中不再需要該位址。

role-mon/cluster/mon*.sls

該範例將監控程式角色指定給一組 Minion。

43 policy.cfg 檔案 SES 6

mgr - 從整個叢集收集所有狀態資訊的 Ceph 管理員精靈。請將它部署在您想要

部署 Ceph 監控程式角色的所有 Minion 上。

role-mgr/cluster/mgr*.sls

storage - 使用此角色可指定儲存節點。

role-storage/cluster/data*.sls

mds - 該 Minion 將提供中繼資料服務以支援 CephFS。

role-mds/cluster/mds*.sls

igw - 該 Minion 將充當 iSCSI 閘道。此角色需要所指定 Minion 的位址，因

此，您還需要包含 stack 目錄中的檔案：

role-igw/cluster/*.sls

rgw - 該 Minion 將充當物件閘道：

role-rgw/cluster/rgw*.sls

ganesha - 該 Minion 將充當 NFS Ganesha 伺服器。「ganesha」角色需要叢集

中的「rgw」或「mds」角色，否則，驗證將於階段 3 失敗。

role-ganesha/cluster/ganesha*.sls

若要成功安裝 NFS Ganesha，需要進行額外的設定。如果您要使用 NFS

Ganesha，請在執行階段 2 和 4 之前閱讀第 12 章「安裝 NFS Ganesha」。但

是，也可於稍後再安裝 NFS Ganesha。

在某些情況下，為 NFS Ganesha 節點定義自訂角色可能很有用。如需詳細資料，

請參閱《管理指南》, 第 21 章「NFS Ganesha：透過 NFS 輸出 Ceph 資料」,

第 21.3 節「自訂 NFS Ganesha 角色」。

grafana、prometheus - 此節點會將基於 Prometheus 警示的 Grafana 圖表新

增至 Ceph Dashboard。如需詳細描述，請參閱《管理指南》, 第 22 章「Ceph

Dashboard」。

role-grafana/cluster/grafana*.sls

role-prometheus/cluster/prometheus*.sls


注意：叢集節點的多個角色您可將多個角色指定給一個節點。例如，可將「mds」角色指定給監控程式節

點：

role-mds/cluster/mon[1,2]*.sls

5.5.1.3 通用組態

通用組態區段包括探查 (階段 1)期間產生的組態檔案。這些組態檔案儲存 fsid 或

public_network 等參數。若要包含所需的 Ceph 通用組態，請新增以下幾行：

config/stack/default/global.ymlconfig/stack/default/ceph/cluster.yml

5.5.1.4 項目過濾

有時，使用 *.sls 萬用字元無法包含給定目錄中的所有檔案。 policy.cfg 檔案剖析器

可識別以下過濾器：

警告：進階方法本節介紹供進階使用者使用的過濾方法。如果使用不當，過濾可能會導致問題發

生，例如，節點編號改變。

slice=[start:end]

使用 slice 過濾器可以僅包含從 start 到 end-1 的項目。請注意，給定目錄中

的項目將依英數字元順序排序。下行包含 role-mon/cluster/ 子目錄中的第三到

第五個檔案：

role-mon/cluster/*.sls slice[3:6]

re=regexp

使用一般運算式過濾器可以僅包含與給定運算式相符的項目。例如：


role-mon/cluster/mon*.sls re=.*1[135]\.subdomainX\.sls$

5.5.1.5 例如 policy.cfg 檔案

下面是一個基本 policy.cfg 檔案的範例：

## Cluster Assignmentcluster-ceph/cluster/*.sls 1

## Roles# ADMINrole-master/cluster/examplesesadmin.sls 2

role-admin/cluster/sesclient*.sls 3

# MONrole-mon/cluster/ses-example-[123].sls 4

# MGRrole-mgr/cluster/ses-example-[123].sls 5

# STORAGErole-storage/cluster/ses-example-[5,6,7,8].sls 6

# MDSrole-mds/cluster/ses-example-4.sls 7

# IGWrole-igw/cluster/ses-example-4.sls 8

# RGWrole-rgw/cluster/ses-example-4.sls 9

# COMMONconfig/stack/default/global.yml 10

config/stack/default/ceph/cluster.yml 11

1 指示在 Ceph 叢集中包含所有 Minion。如果您不想在 Ceph 叢集中包含某些

Minion，請使用：

cluster-unassigned/cluster/*.slscluster-ceph/cluster/ses-example-*.sls

第一行將所有 Minion 標記為未指定。第二行覆寫與「ses-example-*.sls」相符

的 Minion，並將其指定給 Ceph 叢集。


2 名為「examplesesadmin」的 Minion 具有「master」角色。順便指出，這表示該

Minion 將取得叢集的管理金鑰。

3 與「sesclient*」相符的所有 Minion 也將取得管理金鑰。

4 與「ses-example-[123]」相符的所有 Minion (應該是 ses-example-1、ses-

example-2 和 ses-example-3 這三個 Minion) 將設定為 MON 節點。

5 與「ses-example-[123]」相符的所有 Minion (範例中的所有 MON 節點) 將設定

為 MGR 節點。

6 所有與「ses-example-[5,6,7,8]」相符的 Minion 都將設定為儲存節點。

7 Minion「ses-example-4」將具有 MDS 角色。

8 Minion「ses-example-4」將具有 IGW 角色。

9 Minion「ses-example-4」將具有 RGW 角色。

10 表示我們接受 fsid 和 public_network 等通用組態參數的預設值。

11 表示我們接受 fsid 和 public_network 等通用組態參數的預設值。

5.5.2 DriveGroups

DriveGroups 用於指定 Ceph 叢集中 OSD 的配置。需要在單個檔案 /srv/salt/ceph/

configuration/files/drive_groups.yml 中定義 DriveGroups。

管理員應手動指定一組相關的 OSD (在固態硬碟和旋轉式硬碟上部署的混合式 OSD)，

或一組使用相同部署選項的 OSD (例如，物件儲存、加密選項完全相同的各獨立

OSD)。為了避免明確列出裝置，DriveGroups 會使用與 ceph-volume 庫存報告

中的幾個所選欄位對應的過濾項目清單。在最簡單的情形中，過濾項目可能就是

「rotational」旗標 (所有固態磁碟機為「db_devices」，所有旋轉式磁碟機為「data

devices」)，或者是相關性更高的項目 (例如「model」字串或大小)。DeepSea 將提供

用於將這些 DriveGroups 轉換為供使用者檢查的實際裝置清單的代碼。

下面是一個簡單的程序，演示了設定 DriveGroups 時的基本工作流程：

1. 檢查磁碟的內容是否與 ceph-volume 指令的輸出一致。DriveGroups 僅可接受這

些內容：

root@master # salt-run disks.details

47 DriveGroups SES 6

2. 開啟 /srv/salt/ceph/configuration/files/drive_groups.yml YAML 檔案，並依據

您的需求進行調整。請參閱第 5.5.2.1 節「規格」。請記得使用空格而不是定

位字元。如需更多進階範例，請參閱第 5.5.2.4 節「範例」。下面的範例包括

Ceph 可用做 OSD 的所有磁碟機：

default_drive_group_name: target: '*' data_devices: all: true

3. 確認新配置：

root@master # salt-run disks.list

此執行程式會依據您的 DriveGroups 傳回由相符磁碟組成的結構。如果您對結果

不滿意，請重複上一步。

提示：詳細報告除了 disks.list 執行程式外，您還可以使用 disks.report 執行程式列印

接下來的 DeepSea 階段 3 呼叫中將發生事件的詳細報告。

root@master # salt-run disks.report

4. 部署 OSD。在接下來的 DeepSea 階段 3 呼叫中，將依據您的磁碟機群組規格部

署 OSD 磁碟。

5.5.2.1 規格

/srv/salt/ceph/configuration/files/drive_groups.yml 接受以下選項：

drive_group_default_name: target: * data_devices: drive_spec: DEVICE_SPECIFICATION db_devices: drive_spec: DEVICE_SPECIFICATION wal_devices: drive_spec: DEVICE_SPECIFICATION block_wal_size: '5G' # (optional, unit suffixes permitted) block_db_size: '5G' # (optional, unit suffixes permitted)


osds_per_device: 1 # number of osd daemons per device format: # 'bluestore' or 'filestore' (defaults to 'bluestore') encryption: # 'True' or 'False' (defaults to 'False')

對於 FileStore 設定， drive_groups.yml 可能如下所示：

drive_group_default_name: target: * data_devices: drive_spec: DEVICE_SPECIFICATION journal_devices: drive_spec: DEVICE_SPECIFICATION format: filestore encryption: True

5.5.2.2 相符磁碟裝置

您可以使用以下過濾器描述規格：

依磁碟型號：

model: DISK_MODEL_STRING

依磁碟廠商：

vendor: DISK_VENDOR_STRING

提示：小寫的廠商字串DISK_VENDOR_STRING 一律採用小寫。

磁碟是否為旋轉式硬碟。SSD 和 NVME 磁碟機不屬於旋轉式硬碟。

rotational: 0

部署將全部可用磁碟機皆用於 OSD 的節點：

data_devices: all: true

此外，還可透過限制相符磁碟的數量來過濾：

limit: 10


5.5.2.3 依大小過濾裝置

您可以依磁碟裝置大小對其過濾，可以依確切大小也可以依大小範圍來過濾。 size:

參數接受使用下列格式的引數：

'10G' - 包括大小為該值的磁碟。

'10G:40G' - 包括大小在該範圍內的磁碟。

':10G' - 包括大小小於或等於 10 GB 的磁碟。

'40G:' - 包括大小等於或大於 40 GB 的磁碟。

範例 5.1︰依磁碟大小比對

drive_group_default: target: '*' data_devices: size: '40TB:' db_devices: size: ':2TB'

注意：需要引號如果使用「:」分隔符，您需要使用引號括住大小，否則系統會將「:」符號解譯

為新組態雜湊。

提示：單位捷徑除了 G (十億位元組)，您還可以使用 M (百萬位元組) 或 T (兆位元組) 來指

定大小。

5.5.2.4 範例

本節包含其他 OSD 設定的範例。

範例 5.2︰簡單設定

下面的範例描述了使用相同設定的兩個節點：


20 個 HDD

廠商：Intel

型號：SSD-123-foo

大小：4 TB

2 個 SSD

廠商：Micron

型號：MC-55-44-ZX

大小：512 GB

對應的 drive_groups.yml 檔案如下所示：

drive_group_default: target: '*' data_devices: model: SSD-123-foo db_devices: model: MC-55-44-XZ

這樣的組態簡單有效。但問題是管理員將來可能要新增來自不同廠商的磁碟，而

這樣的磁碟不在可新增範圍內。您可以透過減少針對磁碟機核心內容的過濾器來

予以改進。

drive_group_default: target: '*' data_devices: rotational: 1 db_devices: rotational: 0

在上面的範例中，我們強制將所有旋轉式裝置宣告為「data devices」，將所有

非旋轉式裝置當成「shared devices」(wal、db) 使用。

如果您知道大小超過 2 TB 的磁碟機將一律做為較慢的資料裝置，則可以依大小

過濾：

drive_group_default: target: '*' data_devices: size: '2TB:'


db_devices: size: ':2TB'

範例 5.3︰進階設定

下面的範例描述了兩種不同的設定：20 個 HDD 將共用 2 個 SSD，而 10 個 SSD

將共用 2 個 NVMe。

20 個 HDD

廠商：Intel


大小：4 TB

12 個 SSD

廠商：Micron


大小：512 GB

2 個 NVMe

廠商：Samsung

型號：NVME-QQQQ-987

大小：256 GB

這樣的設定可使用如下兩個配置定義：

drive_group: target: '*' data_devices: rotational: 0 db_devices: model: MC-55-44-XZ

drive_group_default: target: '*' data_devices: model: MC-55-44-XZ db_devices:


vendor: samsung size: 256GB

範例 5.4︰包含非統一節點的進階設定

上述範例假設所有節點的磁碟機都相同，但情況並非總是如此：

節點 1-5：

20 個 HDD

廠商：Intel


大小：4 TB

2 個 SSD

廠商：Micron


大小：512 GB

節點 6-10：

5 個 NVMe

廠商：Intel


大小：4 TB

20 個 SSD

廠商：Micron


大小：512 GB

您可以在配置中使用「target」鍵來定位特定節點。Salt 定位標記可讓事情變得

簡單：


drive_group_node_one_to_five: target: 'node[1-5]' data_devices: rotational: 1 db_devices: rotational: 0

後接

drive_group_the_rest: target: 'node[6-10]' data_devices: model: MC-55-44-XZ db_devices: model: SSD-123-foo

範例 5.5︰專家設定

上述所有案例都假設 WAL 和 DB 使用相同裝置，但也有可能會在專屬裝置上部署

WAL：

20 個 HDD

廠商：Intel


大小：4 TB

2 個 SSD

廠商：Micron


大小：512 GB

2 個 NVMe

廠商：Samsung


大小：256 GB

drive_group_default: target: '*'


data_devices: model: MC-55-44-XZ db_devices: model: SSD-123-foo wal_devices: model: NVME-QQQQ-987

範例 5.6︰複雜 (和不太可能的) 設定

在以下設定中，我們嘗試定義：

由 1 個 NVMe 支援 20 個 HDD

由 1 個 SSD (db) 和 1 個 NVMe (wal) 支援 2 個 HDD

由 1 個 NVMe 支援 8 個 SSD

2 個獨立 SSD (加密)

1 個 HDD 做為備用，不應部署

共使用如下數量的磁碟機：

23 個 HDD

廠商：Intel


大小：4 TB

10 個 SSD

廠商：Micron


大小：512 GB

1 個 NVMe

廠商：Samsung


大小：256 GB


DriveGroups 定義如下所示：

drive_group_hdd_nvme: target: '*' data_devices: rotational: 0 db_devices: model: NVME-QQQQ-987

drive_group_hdd_ssd_nvme: target: '*' data_devices: rotational: 0 db_devices: model: MC-55-44-XZ wal_devices: model: NVME-QQQQ-987

drive_group_ssd_nvme: target: '*' data_devices: model: SSD-123-foo db_devices: model: NVME-QQQQ-987

drive_group_ssd_standalone_encrypted: target: '*' data_devices: model: SSD-123-foo encryption: True

在檔案的整個剖析過程中，一直會保留一個 HDD。

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

如果需要將自訂設定放入 ceph.conf 組態檔案，請參閱《管理指南》, 第 2 章「Salt

叢集管理」, 第 2.13 節「使用自訂設定調整 ceph.conf」瞭解更多詳細資料。

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

6 從舊版本升級

本章說明將 SUSE Enterprise Storage 5.5 升級至版本 6 的步驟。請注意，版本 5.5

是在版本 5 的基礎上套用了所有最新修補程式後的版本。

注意：不支援從更早的版本升級不支援從早於 5.5 的 SUSE Enterprise Storage 版本升級。您需要先升級至

SUSE Enterprise Storage 5.5 的最新版本，然後再依照本章所述的步驟操作。

6.1 升級前的注意事項

閱讀版本說明 - 版本說明提供了有關自 SUSE Enterprise Storage 上一個版本

發行後所進行的變更的其他資訊。檢查版本說明以瞭解：

您的硬體是否有特殊的注意事項。

所用的任何軟體套件是否已發生重大變更。

是否需要對您的安裝施行特殊預防措施。

版本說明還會提供無法及時編入手冊的資訊。它們還包含有關已知問題的說明。

安裝套件 release-notes-ses之後，本地的 /usr/share/doc/release-notes 目錄

中或 https://www.suse.com/releasenotes/ 網頁上會提供版本說明。

如果您先前是從版本 4 升級的，請確認升級至版本 5 的程序已成功完成：

檢查以下檔案是否存在

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

從 SES 4 升級至 5 的過程中，engulf 程序會建立該檔案。另外，會在以下

檔案中設定 configuration_init: default-import 選項

/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml

57 升級前的注意事項 SES 6

https://www.suse.com/releasenotes/

如果 configuration_init 仍設為 default-import，則表示叢集是使用

ceph.conf.import 而非 DeepSea 的預設 ceph.conf 做為其組態檔案的，後

者是透過對以下目錄中的檔案進行編譯而產生的

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

因此，您需要檢查 ceph.conf.import 中是否有任何自訂組態，並視需要將

相應組態移至以下目錄中的其中一個檔案中

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

然後，從下面的檔案中移除 configuration_init: default-import 一行

/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml

警告：預設 DeepSea 組態如果您未合併 ceph.conf.import 中的組態，並移除了

configuration_init: default-import 選項，那麼我們隨 DeepSea 一

併提供的任何預設組態設定 (在 /srv/salt/ceph/configuration/files/

ceph.conf.j2 中儲存) 都不會套用至叢集。

檢查叢集是否使用了新桶類型「straw2」：

cephadm@adm > ceph osd crush dump | grep straw

檢查是否使用了 Ceph「jewel」設定檔：

cephadm@adm > ceph osd crush dump | grep profile

如果使用的是舊 RBD 核心用戶端 (早於 SUSE Linux Enterprise Server 12

SP3)，請參閱《管理指南》, 第 12 章「RADOS 區塊裝置」, 第 12.9 節「使用

舊核心用戶端對應 RBD」。如果可能，建議升級舊 RBD 核心用戶端。

如果 openATTIC 位於管理節點上，當您升級該節點後，openATTIC 將不可用。在

您使用 DeepSea 部署新 Ceph Dashboard 前，該儀表板將不可用。

升級叢集可能需要花很長時間 - 所需時間大約為升級一部機器的時間乘以叢集節

點數。


如果某個節點執行的是先前的 SUSE Linux Enterprise Server 版本，則無法進

行升級，需要將其重新開機到新版本的安裝程式。因此，該節點提供的服務將在

一段時間內無法使用。核心叢集服務將仍然可用，例如，如果在升級期間有一個

MON 停機，至少還有兩個 MON 處於使用中狀態。但不幸的是，單一 iSCSI 閘道

這樣的單一例項服務將無法使用。

某些類型的精靈相依於其他精靈。例如，Ceph 物件閘道相依於 Ceph MON 和

Ceph OSD 精靈。建議您依照以下順序升級：

1. 管理節點

2. Ceph 監控程式/Ceph 管理員

3. 中繼資料伺服器

4. Ceph OSD

5. 物件閘道

6. iSCSI 閘道

7. NFS Ganesha

8. Samba 閘道

如果您之前是在「控訴」或「強制」模式下使用 AppArmor 的，則需要在升級

前設定 Salt Pillar 變數。由於 SUSE Linux Enterprise Server 15 SP1 預

設隨附了 AppArmor，因此 DeepSea 階段 0 中已整合 AppArmor 管理。SUSE

Enterprise Storage 6 預設會移除 AppArmor 和相關組態。如果您要保留在

SUSE Enterprise Storage 5.5 中設定的行為，請在開始升級前確認 /srv/

pillar/ceph/stack/global.yml 檔案中是否存在以下其中一行：

apparmor_init: default-enforce

或


apparmor_init: default-complain

自 SUSE Enterprise Storage 6 起，不再允許使用以數字開頭的 MDS 名稱，否

則 MDS 精靈將拒絕啟動。您可以透過執行 ceph fs status 指令來檢查精靈是否

使用了此類名稱，也可以透過重新啟動 MDS，然後檢查其記錄中是否存在以下訊

息來確認：

deprecation warning: MDS id 'mds.1mon1' is invalid and will be forbidden ina future version. MDS names may not start with a numeric digit.

如果您看到上述訊息，則需要在嘗試升級至 SUSE Enterprise Storage 6 前移轉

MDS 名稱。DeepSea 提供了一種協調程序來自動完成此移轉。它會在以數字開頭

的 MDS 名稱前加上「mds.」字首：

root@master # salt-run state.orch ceph.mds.migrate-numerical-names

提示：結合到 MDS 名稱的自訂組態如果您有結合到 MDS 名稱的組態設定，且 MDS 精靈的名稱以數字開頭，

請確認您的組態設定是否同樣適用於新名稱 (帶有「mds.」字首)。假設 /

etc/ceph/ceph.conf 檔案中包含以下範例區段：

[mds.123-my-mds] # config setting specific to MDS name with a name starting with a digitmds cache memory limit = 1073741824mds standby for name = 456-another-mds

ceph.mds.migrate-numerical-names 協調器會將 MDS 精靈名稱「123-my-

mds」變更為「mds.123-my-mds」。您需要調整組態以反映新名稱：

[mds.mds,123-my-mds] # config setting specific to MDS name with the new namemds cache memory limit = 1073741824mds standby for name = mds.456-another-mds

如此將會在移除舊 MDS 精靈前新增使用新名稱的 MDS 精靈。因此，短時間內

MDS 精靈的數量會翻倍。系統將會有一個短時暫停來進行容錯移轉，然後用戶端

才能存取 CephFS。因此，請將移轉排程在預期只有少量或沒有 CephFS 負載的時

間進行。


6.2 備份叢集資料雖然建立叢集組態和資料的備份並非強制性操作，但我們仍強烈建議備份重要的組態檔

案和叢集資料。如需更多詳細資料，請參閱《管理指南》, 第 3 章「備份叢集組態和

資料」。

6.3 從 ntpd 移轉至 chronyd

SUSE Linux Enterprise Server 15 SP1 不再使用 ntpd 來同步本地主機時間，而是

使用 chronyd。您需要移轉每個叢集節點上的時間同步精靈。您可以在升級叢集前移轉

至 chronyd，也可以先升級叢集，然後再移轉至 chronyd 。

程序 6.1︰在升級叢集前移轉至 chronyd

1. 安裝 chrony 套件：

root@minion > zypper install chrony

2. 編輯 chronyd 組態檔案 /etc/chrony.conf，並新增在 /etc/ntp.conf 中的目前

ntpd 組態中指定的 NTP 來源。

提示：有關 chronyd 組態的更多詳細資料如需如何在 chronyd 組態中包含時間來源的更多詳細資料，請參閱

https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-

ntp.html 。

3. 停用並停止 ntpd 服務：

root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service

4. 啟動並啟用 chronyd 服務：

root@minion > systemctl start chronyd.service && systemctl enable chronyd.service

5. 確認 chrony 的狀態：

root@minion > chronyc tracking

61 備份叢集資料 SES 6

https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html


程序 6.2︰在升級叢集後移轉至 chronyd

1. 在叢集升級期間，請新增以下軟體儲存庫：

SLE-Module-Legacy15-SP1-Pool

SLE-Module-Legacy15-SP1-Updates

2. 將叢集升級至版本 6。

3. 編輯 chronyd 組態檔案 /etc/chrony.conf，並新增在 /etc/ntp.conf 中的目前

ntpd 組態中指定的 NTP 來源。

提示：有關 chronyd 組態的更多詳細資料如需如何在 chronyd 組態中包含時間來源的更多詳細資料，請參閱

https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-

ntp.html 。

4. 停用並停止 ntpd 服務：

root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service

5. 啟動並啟用 chronyd 服務：

root@minion > systemctl start chronyd.service && systemctl enable chronyd.service

6. 從 ntpd 移轉至 chronyd。

7. 確認 chrony 的狀態：

root@minion > chronyc tracking

8. 移除您在升級過程中為了在系統中保留 ntpd 而新增的舊軟體儲存庫。

6.4 升級前對叢集套用修補程式

在升級前，需要對所有叢集節點套用最新的修補程式。

62 升級前對叢集套用修補程式 SES 6



6.4.1 所需的軟體儲存庫

檢查是否已在每個叢集節點上設定所需儲存庫。若要列出所有可用儲存庫，請執行以下

指令

root@minion > zypper lr

SUSE Enterprise Storage 5.5 需要：

SLES12-SP3-Installer-Updates

SLES12-SP3-Pool

SLES12-SP3-Updates

SUSE-Enterprise-Storage-5-Pool

SUSE-Enterprise-Storage-5-Updates

SUSE Linux Enterprise Server 12 SP3 上執行的 SLE-HA 上的 NFS/SMB 閘道需要：

SLE-HA12-SP3-Pool

SLE-HA12-SP3-Updates

6.4.2 儲存庫暫存系統

如果您在使用某個儲存庫暫存系統 (SMT、RMT 或 SUSE Manager)，請為目前和新的

SUSE Enterprise Storage 版本建立新的凍結修補程式層級。

如需詳細資訊，請參閱：

https://www.suse.com/documentation/sles-12/book_smt/data/

book_smt.html

https://www.suse.com/documentation/sles-15/book_rmt/data/

book_rmt.html

https://www.suse.com/documentation/suse-manager-3/index.html

63 所需的軟體儲存庫 SES 6

https://www.suse.com/documentation/sles-12/book_smt/data/book_smt.html

https://www.suse.com/documentation/sles-12/book_smt/data/book_smt.html

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

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

https://www.suse.com/documentation/suse-manager-3/index.html

6.4.3 對整個叢集套用最新的修補程式

1. 對每個 Ceph 叢集節點套用 SUSE Enterprise Storage 5.5 和 SUSE Linux

Enterprise Server 12 SP3 的最新修補程式。確認已將正確的軟體儲存庫連接至

每個叢集節點 (請參閱第 6.4.1 節「所需的軟體儲存庫」)，然後執行 DeepSea

階段 0：


2. 執行完階段 0 後，確認每個叢集節點的狀態是否包含「HEALTH_OK」。如果未包

含，請先解決問題，然後再進行後續步驟中可能的重新開機。

3. 執行 zypper ps 以檢查是否存在可能使用過時程式庫或二進位執行的程序，如果

存在，則進行重新開機。

4. 確認執行中核心是否為最新版本，如果不是，則進行重新開機。檢查以下指令的

輸出：

cephadm@adm > uname -acephadm@adm > rpm -qa kernel-default

5. 確認是否已安裝 ceph 套件為 12.2.12 或更新版本。確認是否已安裝 deepsea

套件為 0.8.9 或更新版本。

6. 如果您之前使用了任何 bluestore_cache 設定，從 ceph 12.2.10 版本

開始，這些設定將不再有效。新設定 bluestore_cache_autotune (預設

設為「true」) 會禁止手動調整快取大小。若要啟用舊行為，您需要設定

bluestore_cache_autotune=false。如需詳細資訊，請參閱《管理指南》, 第 16

章「Ceph 叢集組態」, 第 16.2.1 節「自動調整快取大小」。

6.5 確認目前環境

如果系統存在明顯問題，請修復後再開始升級。升級程序並不會修復現有的系統

問題。

檢查叢集效能。您可以使用 rados bench、 ceph tell osd.* bench 或 iperf3 等

指令。

64 對整個叢集套用最新的修補程式 SES 6

確認對閘道 (例如 iSCSI 閘道或物件閘道) 和 RADOS 區塊裝置的存取權。

記錄系統設定的特定部分，例如網路設定、磁碟分割或安裝詳細資料。

使用 supportconfig 收集重要的系統資訊，並將其儲存在叢集節點之外。

如需詳細資訊，請參閱https://www.suse.com/documentation/sles-12/

book_sle_admin/data/sec_admsupport_supportconfig.html 。

確定每個叢集節點上都有充足的可用磁碟空間。請使用 df -h 檢查可用磁碟空

間。必要時，請透過移除不需要的檔案/目錄或過時的作業系統快照來釋放磁碟空

間。如果沒有足夠的可用磁碟空間，在釋放出充足的磁碟空間前，請不要繼續升

級。

6.6 檢查叢集的狀態

開始升級程序前，請使用 cluster health 指令檢查叢集狀態。除非所有叢集節點

都報告「HEALTH_OK」，否則請不要開始升級。

確認所有服務都在執行中：

Salt Master 和 Salt Master 精靈。

Ceph 監控程式和 Ceph 管理員精靈。

中繼資料伺服器精靈。

Ceph OSD 精靈。

物件閘道精靈。

iSCSI 閘道精靈。

以下指令提供叢集狀態以及特定組態的詳細資料：

ceph -s

列印 Ceph 叢集狀態、執行中服務、資料使用率以及 I/O 統計資料的簡短摘要。

請在開始升級前確認該指令是否報告了「HEALTH_OK」。

ceph health detail

65 檢查叢集的狀態 SES 6

https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_admsupport_supportconfig.html

https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_admsupport_supportconfig.html

如果 Ceph 叢集狀態並非報告為 OK，該指令可列印詳細資料。

ceph versions

列印執行中 Ceph 精靈的版本。

ceph df

列印叢集上的總磁碟空間和可用磁碟空間。如果叢集的可用磁碟空間不到總磁碟

空間的 25%，請不要開始升級。

salt '*' cephprocesses.check results=true

列印執行中 Ceph 程序及其 PID (依 Salt Minion 排序)。

ceph osd dump | grep ^flags

確認是否存在「recovery_deletes」和「purged_snapdirs」旗標。如果不存在，

您可以透過執行以下指令來強制對所有放置群組執行整理。請注意，此強制整理

可能會對您 Ceph 用戶端的效能造成負面影響。

cephadm@adm > ceph pg dump pgs_brief | cut -d " " -f 1 | xargs -n1 ceph pg scrub

6.7 CTDB 叢集的離線升級CTDB 提供 Samba 閘道使用的叢集化資料庫。CTDB 通訊協定非常簡單，不支援節點之

間使用不同通訊協定版本進行通訊的叢集。因此需要先將 CTDB 節點置於離線狀態才能

執行升級。

6.8 依節點升級 - 基本程序為了確保核心叢集服務在升級期間可用，您需要循序逐一升級叢集節點。您可以使用兩

種方式執行節點升級：使用安裝程式 DVD，或者使用套裝作業移轉系統。

升級每個節點後，我們建議執行 rpmconfigcheck 指令來檢查是否存在任何在本地編

輯過的已更新組態檔案。如果指令傳回尾碼為 .rpmnew、 .rpmorig 或 .rpmsave 的檔

案名稱清單，請將這些檔案與目前的組態檔案進行比較，以確定沒有遺失任何本地變

更。如果需要，請更新受影響的檔案。如需處理 .rpmnew、 .rpmorig 和 .rpmsave 檔

案的詳細資訊，請參閱 https://documentation.suse.com/sles/15-SP1/single-html/

SLES-admin/#sec-rpm-packages-manage 。

66 CTDB 叢集的離線升級 SES 6

https://documentation.suse.com/sles/15-SP1/single-html/SLES-admin/#sec-rpm-packages-manage

https://documentation.suse.com/sles/15-SP1/single-html/SLES-admin/#sec-rpm-packages-manage

提示：孤立套件升級一個節點後，有一些套件將處於「孤立」狀態，沒有父儲存庫。這是因為與

python3 相關的套件不會廢棄 python2 套件。

如需有關列出孤立套件的詳細資訊，請參閱 https://

www.suse.com/documentation/sles-15/book_sle_admin/data/

sec_zypper.html#sec_zypper_softup_orphaned 。

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

1. 從 SUSE Linux Enterprise Server 15 SP1 安裝程式 DVD/影像將節點重新開

機。

2. 從開機功能表中選取升級。

3. 在選取移轉目標螢幕上，確認選取了「SUSE Linux Enterprise Server 15

SP1」，然後啟用手動調整用於移轉的儲存庫核取方塊。

圖形 6.1︰選取移轉目標

4. 選取以下模組加以安裝：

67 使用安裝程式 DVD 手動升級節點 SES 6

https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_zypper.html#sec_zypper_softup_orphaned



SUSE Enterprise Storage 6 x86_64

Basesystem Module 15 SP1 x86_64

Desktop Applications Module 15 SP1 x86_64

Legacy Module 15 SP1 x86_64

Server Applications Module 15 SP1 x86_64

5. 在之前使用的儲存庫螢幕上，確認選取了正確的儲存庫。如果未在 SCC/SMT 中註

冊系統，您需要手動新增儲存庫。

SUSE Enterprise Storage 6 需要：

SLE-Module-Basesystem15-SP1-Pool

SLE-Module-Basesystem15-SP1-Updates

SLE-Module-Server-Applications15-SP1-Pool

SLE-Module-Server-Applications15-SP1-Updates

SLE-Module-Desktop-Applications15-SP1-Pool

SLE-Module-Desktop-Applications15-SP1-Updates

SLE-Product-SLES15-SP1-Pool

SLE-Product-SLES15-SP1-Updates

SLE15-SP1-Installer-Updates

SUSE-Enterprise-Storage-6-Pool

SUSE-Enterprise-Storage-6-Updates

如果您要在移轉 SES 後將 ntpd 移轉至 chronyd (請參閱第 6.3 節「從 ntpd

移轉至 chronyd」)，請包含以下儲存庫：

SLE-Module-Legacy15-SP1-Pool

SLE-Module-Legacy15-SP1-Updates

68 使用安裝程式 DVD 手動升級節點 SES 6

SUSE Linux Enterprise Server 15 SP1 上執行的 SLE-HA 上的 NFS/SMB 閘道需

要：

SLE-Product-HA15-SP1-Pool

SLE-Product-HA15-SP1-Updates

6. 檢查安裝設定，然後按一下更新以開始安裝程序。

6.8.2 使用 SUSE 套裝作業系統移轉系統升級節點

套裝作業系統移轉系統 (DMS) 提供將安裝的 SUSE Linux Enterprise 系統從一個主

要版本升級至另一個主要版本的升級路徑。以下程序使用 DMS 將 SUSE Enterprise

Storage 5.5 升級至版本 6，其中包括從基礎 SUSE Linux Enterprise Server 12 SP3

移轉至 SUSE Linux Enterprise Server 15 SP1。

如需 DMS 的一般和詳細資訊，請參閱 https://documentation.suse.com/suse-

distribution-migration-system/1.0/single-html/distribution-migration-

system/ 。

1. 安裝移轉 RPM 套件。它們會調整 GRUB 開機載入程式，以在下次重新開機時自動

觸發升級。安裝 SLES15-SES-Migration 與 suse-migration-sle15-activation 套

件:

root@minion > zypper install SLES15-SES-Migration suse-migration-sle15-activation

2. a. 如果已在儲存庫暫存系統 (如 SCC、SMT、RMT 或 SUSE Manager) 中註冊要

升級的節點，請建立包含以下內容的 /etc/sle-migration-service.yml 檔

案：

use_zypper_migration: truepreserve: rules: - /etc/udev/rules.d/70-persistent-net.rules

b. 如果未在儲存庫暫存系統 (如 SCC、SMT、RMT 或 SUSE Manager) 中註冊要

升級的節點，請進行以下變更：

i. 建立包含以下內容的 /etc/sle-migration-service.yml 檔案：

69 使用 SUSE 套裝作業系統移轉系統升級節點 SES 6

https://documentation.suse.com/suse-distribution-migration-system/1.0/single-html/distribution-migration-system/



use_zypper_migration: falsepreserve: rules: - /etc/udev/rules.d/70-persistent-net.rules

ii. 停用或移除 SLE 12 SP3 和 SES 5 儲存庫，並新增 SLE 15 SP1 和

SES 6 儲存庫。第 6.4.1 節「所需的軟體儲存庫」中列出了相關的儲

存庫。

3. 重新開機以開始升級。在執行升級期間，您可以從主機系統上使用現有

SSH 金鑰透過 ssh 以移轉使用者的身分登入已升級節點 (如 https://

documentation.suse.com/suse-distribution-migration-system/1.0/single-

html/distribution-migration-system/ 所述)。對於 SUSE Enterprise

Storage，如果您能夠實體存取機器或可直接透過主控台存取，則還可以在系統

主控台上使用密碼 sesupgrade 以 root 身分登入。節點將在升級後自動重新開

機。

提示：升級失敗如果升級失敗，請檢查 /var/log/distro_migration.log。修復問題，重新

安裝移轉 RPM 套件，然後將節點重新開機。

6.9 升級管理節點

雖然 Salt Minion 執行的是舊版 Ceph 和 Salt，但下列指令仍有效： salt '*'

test.ping 和 ceph status

升級管理節點後，將不再安裝 openATTIC。

如果管理節點之前代管著 SMT，請將其移轉至 RMT (請參閱

https://www.suse.com/documentation/sles-15/book_rmt/data/

cha_rmt_migrate.html )。

依照第 6.8 節「依節點升級 - 基本程序」中所述的程序操作。

70 升級管理節點 SES 6




https://www.suse.com/documentation/sles-15/book_rmt/data/cha_rmt_migrate.html

https://www.suse.com/documentation/sles-15/book_rmt/data/cha_rmt_migrate.html

提示：叢集節點的狀態升級管理節點後，您可以執行 salt-run upgrade.status 指令，以檢視有關叢集

節點的有用資訊。該指令會列出所有節點的 Ceph 和作業系統版本，並會建議應

依何順序升級仍在執行舊版本的所有節點。

root@master # salt-run upgrade.statusThe newest installed software versions are: ceph: ceph version 14.2.1-468-g994fd9e0cc (994fd9e0ccc50c2f3a55a3b7a3d4e0ba74786d50) nautilus (stable) os: SUSE Linux Enterprise Server 15 SP1

Nodes running these software versions: admin.ceph (assigned roles: master) mon2.ceph (assigned roles: admin, mon, mgr)

Nodes running older software versions must be upgraded in the following order: 1: mon1.ceph (assigned roles: admin, mon, mgr) 2: mon3.ceph (assigned roles: admin, mon, mgr) 3: data1.ceph (assigned roles: storage)[...]

6.10 升級 Ceph 監控程式/Ceph 管理員節點

如果您的叢集未使用 MDS 角色，請逐一升級 MON/MGR 節點。

如果您的叢集使用 MDS 角色，且 MON/MGR 與 MDS 角色共置，您需要縮減 MDS

叢集，然後升級共置的節點。如需更多詳細資料，請參閱第 6.11 節「升級中

繼資料伺服器」。

如果您的叢集使用 MDS 角色，且它們在專屬伺服器上執行，請逐一升級所有

MON/MGR 節點，然後縮減 MDS 叢集並進行升級。如需更多詳細資料，請參閱

第 6.11 節「升級中繼資料伺服器」。

71 升級 Ceph 監控程式/Ceph 管理員節點 SES 6

注意：Ceph 監控程式升級由於 Ceph 監控程式設計存在局限性，一旦有兩個 MON 已升級至 SUSE

Enterprise Storage 6 且構成了仲裁，那麼第三個 MON (仍在執行 SUSE

Enterprise Storage 5.5) 出於某種原因重新啟動 (包括節點重新開機) 後，

將不會重新加入 MON 叢集。因此，當有兩個 MON 升級後，最好儘快升級其餘

MON。


6.11 升級中繼資料伺服器您需要縮減中繼資料伺服器 (MDS) 叢集。由於 SUSE Enterprise Storage 版本 5.5

與 6 之間的功能不相容，較舊版本的 MDS 精靈一旦發現有 SES 6 層級的 MDS 加入叢

集，他們即會關閉。因此，在 MDS 節點升級期間，必須將 MDS 叢集縮減到只有一個使

用中 MDS (沒有待命 MDS)。升級第二個節點後，就可以再次擴充 MDS 叢集。

提示在負載過重的 MDS 叢集上，您可能需要降低負載 (例如透過停止用戶端)，以便

單個使用中 MDS 就足以處理工作負載。

1. 記下 max_mds 選項的目前值：

cephadm@adm > ceph fs get cephfs | grep max_mds

2. 如果您有多個使用中 MDS 精靈 (即 max_mds > 1)，請縮減 MDS 叢集。若要縮減

MDS 叢集，請執行以下指令

cephadm@adm > ceph fs set FS_NAME max_mds 1

其中， FS_NAME 是您 CephFS 例項的名稱 (預設為「cephfs」)。

3. 找到代管某個待命 MDS 精靈的節點。查看 ceph fs status 指令的輸出，然後開

始升級此節點上的 MDS 叢集。

cephadm@adm > ceph fs status

72 升級中繼資料伺服器 SES 6

cephfs - 2 clients======+------+--------+--------+---------------+-------+-------+| Rank | State | MDS | Activity | dns | inos |+------+--------+--------+---------------+-------+-------+| 0 | active | mon1-6 | Reqs: 0 /s | 13 | 16 |+------+--------+--------+---------------+-------+-------++-----------------+----------+-------+-------+| Pool | type | used | avail |+-----------------+----------+-------+-------+| cephfs_metadata | metadata | 2688k | 96.8G || cephfs_data | data | 0 | 96.8G |+-----------------+----------+-------+-------++-------------+| Standby MDS |+-------------+| mon3-6 || mon2-6 |+-------------+

在此範例中，您需要在節點「mon3-6」或「mon2-6」上開始升級程序。

4. 升級具有待命 MDS 精靈的節點。升級過的 MDS 節點啟動後，過時的 MDS 精靈將

自動關閉。此時，用戶端可能會經歷一段短暫的 CephFS 服務停機時間。


5. 升級其餘 MDS 節點。

6. 將 max_mds 重設為所需組態：

cephadm@adm > ceph fs set FS_NAME max_mds ACTIVE_MDS_COUNT

6.12 升級 Ceph OSD針對每個儲存節點執行以下步驟：

1. 識別特定節點上的執行中 OSD 精靈：

cephadm@osd > ceph osd tree

2. 為要升級的節點上的每個 OSD 精靈設定「noout」旗標：

cephadm@osd > ceph osd add-noout osd.OSD_ID

例如：

73 升級 Ceph OSD SES 6

cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd add-noout osd.$i; done

使用以下指令進行驗證：

cephadm@osd > ceph health detail | grep noout

或

cephadm@osd > ceph –scluster: id: 44442296-033b-3275-a803-345337dc53da health: HEALTH_WARN 6 OSDs or CRUSH {nodes, device-classes} have {NOUP,NODOWN,NOIN,NOOUT} flags set

3. 透過在待升級節點上執行以下指令，為所有現有 OSD 建立 /etc/ceph/osd/*.json

檔案：

cephadm@osd > ceph-volume simple scan --force

4. 升級 OSD 節點。依照第 6.8 節「依節點升級 - 基本程序」中所述的程序操

作。

5. 啟用系統中發現的所有 OSD：

cephadm@osd > ;ceph-volume simple activate --all

提示：個別啟用各資料分割區如果您要個別啟用各資料分割區，則需要知道用於啟用相應分割區的正確

ceph-volume 指令。請以分割區的正確代號/編號取代 X1：

cephadm@osd > ceph-volume simple scan /dev/sdX1

例如：

cephadm@osd > ceph-volume simple scan /dev/vdb1[...]--> OSD 8 got scanned and metadata persisted to file:/etc/ceph/osd/8-d7bd2685-5b92-4074-8161-30d146cd0290.json--> To take over management of this scanned OSD, and disable ceph-diskand udev, run:--> ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290


輸出的最後一行包含用於啟用該分割區的指令：

cephadm@osd > ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290[...]--> All ceph-disk systemd units have been disabled to prevent OSDsgetting triggered by UDEV events[...]Running command: /bin/systemctl start ceph-osd@8--> Successfully activated OSD 8 with FSIDd7bd2685-5b92-4074-8161-30d146cd0290

6. 確認 OSD 節點在重新開機後是否將正常啟動。

7. 解決「Legacy BlueStore stats reporting detected on XX OSD(s)」訊息：

cephadm@osd > ceph –scluster: id: 44442296-033b-3275-a803-345337dc53da health: HEALTH_WARN Legacy BlueStore stats reporting detected on 6 OSD(s)

在將 Ceph 升級至 14.2.2 時通常會出現該警告。您可以透過以下設定來停用

它：

bluestore_warn_on_legacy_statfs = false

正確的修復方法是在所有由於該問題而停止的 OSD 上執行以下指令：

cephadm@osd > ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-XXX

下面的輔助程式程序檔將會對 NODE_NAME 節點上的所有 OSD 執行 ceph-

bluestore-tool repair 指令：

OSDNODE=OSD_NODE_NAME;\ for OSD in $(ceph osd ls-tree $OSDNODE);\ do echo "osd=" $OSD;\ salt $OSDNODE cmd.run 'systemctl stop ceph-osd@$OSD';\ salt $OSDNODE cmd.run 'ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-$OSD';\ salt $OSDNODE cmd.run 'systemctl start ceph-osd@$OSD';\ done

8. 對已升級節點上的每個 OSD 精靈取消設定「noout」旗標：

cephadm@osd > ceph osd rm-noout osd.OSD_ID


例如：

cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd rm-noout osd.$i; done

使用以下指令進行驗證：

cephadm@osd > ceph health detail | grep noout

注意：

cephadm@osd > ceph –scluster: id: 44442296-033b-3275-a803-345337dc53da health: HEALTH_WARN Legacy BlueStore stats reporting detected on 6 OSD(s)

9. 確認叢集狀態。其輸出將如下所示：

cephadm@osd > ceph statuscluster: id: e0d53d64-6812-3dfe-8b72-fd454a6dcf12 health: HEALTH_WARN 3 monitors have not enabled msgr2

services: mon: 3 daemons, quorum mon1,mon2,mon3 (age 2h) mgr: mon2(active, since 22m), standbys: mon1, mon3 osd: 30 osds: 30 up, 30 in

data: pools: 1 pools, 1024 pgs objects: 0 objects, 0 B usage: 31 GiB used, 566 GiB / 597 GiB avail pgs: 1024 active+clean

10. 確認所有 OSD 節點均已重新開機，且重新開機後 OSD 已自動啟動。


6.13 將 OSD 移轉至 BlueStore

OSD BlueStore 是 OSD 精靈的新後端。從 SUSE Enterprise Storage 5 開始，

它是預設的選項。與以檔案形式將物件儲存於 XFS 檔案系統中的 FileStore

相比，BlueStore 可提供更高的效能，因為它直接將物件儲存於基礎區塊裝置

中。BlueStore 還能提供 FileStore 所不具備的其他功能，例如內建壓縮和 EC 覆

寫。

具體而言，在 BlueStore 中，OSD 包含一個「wal」(預寫記錄檔) 裝置和一個「db」

(RocksDB 資料庫) 裝置。RocksDB 資料庫會儲存 BlueStore OSD 的中繼資料。依預

設，這兩部裝置將位於 OSD 所在的同一部裝置上，但也可以將它們放置在其他 (例如

速度更快的) 媒體上。

在 SUSE Enterprise Storage 5 中，FileStore 和 BlueStore 均受支援，FileStore

和 BlueStore OSD 可在單個叢集中共存。在 SUSE Enterprise Storage 升級期

間，FileStore OSD 不會自動轉換至 BlueStore。請注意，在尚未移轉至 BlueStore

的 OSD 上，將無法使用特定於 BlueStore 的功能。

在轉換至 BlueStore 之前，OSD 需要執行 SUSE Enterprise Storage 5。轉換是個緩

慢的過程，因為所有資料都需要重新寫入兩次。儘管移轉程序可能需要很長時間才能完

成，但在此期間，叢集的工作不會中斷，所有用戶端都可繼續存取叢集。但是，移轉期

間的效能勢必會下降，原因是需要重新平衡和回填叢集資料。

請執行以下程序將 FileStore OSD 移轉至 BlueStore：

提示：關閉安全措施執行移轉所需的 Salt 指令會被安全措施阻止。若要關閉這些預防措施，請執行

以下指令：

root@master # salt-run disengage.safety

在繼續操作前先重建節點：

root@master # salt-run rebuild.node TARGET

您也可以選擇個別重建每個節點。例如：

root@master # salt-run rebuild.node data1.ceph

rebuild.node 永遠會先移除節點上的所有 OSD，然後再重新建立這些 OSD。

77 將 OSD 移轉至 BlueStore SES 6

重要如果一個 OSD 無法轉換，重新執行重建會損毀已轉換的 BlueStore OSD。

如果不想重新執行重建，您可以執行以下指令：

root@master # salt-run disks.deploy TARGET

移轉至 BlueStore 之後，物件計數將保持不變，磁碟使用率也幾乎相同。

6.14 升級應用程式節點

請依以下順序升級應用程式節點：

1. 物件閘道

如果物件閘道的前端是負載平衡器，便可以在服務不中斷的情況下進行物件

閘道的滾存升級。

每次升級後，驗證物件閘道精靈是否正在執行，並使用 S3/Swift 用戶端進

行測試。


2. iSCSI 閘道

如果為 iSCSI 啟動器設定了多重路徑，便可以在服務不中斷的情況下進行

iSCSI 閘道的滾存升級。

每次升級後，驗證 lrbd 精靈是否正在執行，並使用啟動器進行測試。


3. NFS Ganesha。依照第 6.8 節「依節點升級 - 基本程序」中所述的程序操作。

4. Samba 閘道。依照第 6.8 節「依節點升級 - 基本程序」中所述的程序操作。

78 升級應用程式節點 SES 6

6.15 更新 policy.cfg 並使用 DeepSea 部署

Ceph Dashboard在管理節點上編輯 /srv/pillar/ceph/proposals/policy.cfg，並套用以下變更：

重要：無新服務在叢集升級期間，請新增新服務至 policy.cfg 檔案。請僅在完成升級後再變更

叢集架構。

1. 移除 role-openattic。

2. 將 role-prometheus 和 role-grafana 新增至安裝了 Prometheus 和 Grafana

的節點 (通常是管理節點)。

3. 現在，系統會忽略 profile-PROFILE_NAME 角色。新增新的相應角色，即 role-

storage 一行。例如，針對現有

profile-default/cluster/*.sls

新增

role-storage/cluster/*.sls

4. 同步所有 Salt 模組：

root@master # salt '*' saltutil.sync_all

5. 執行 DeepSea 階段 1 和階段 2 來更新 Salt Pillar：

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

6. 清理 openATTIC：

root@master # salt OA_MINION state.apply ceph.rescind.openatticroot@master # salt OA_MINION state.apply ceph.remove.openattic

7. 取消設定「restart_igw」粒紋，以防階段 0 重新啟動尚未安裝的 iSCSI 閘道：

Salt mastersalt '*' grains.delkey restart_igw

79 更新 policy.cfg 並使用 DeepSea 部署 Ceph Dashboard SES 6

8. 最後，執行完整的 DeepSea 階段 0-4：

root@master # salt-run state.orch ceph.stage.0root@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.4

提示：階段 3 執行期間發生「subvolume missing」錯誤DeepSea 階段 3 可能會失敗，並顯示如下錯誤：

subvolume : ['/var/lib/ceph subvolume missing on 4510-2', \'/var/lib/ceph subvolume missing on 4510-1', \[...]'See /srv/salt/ceph/subvolume/README.md']

在此情況下，您需要編輯 /srv/pillar/ceph/stack/global.yml，並新增下

面一行：

subvolume_init: disabled

然後重新整理 Salt Pillar 並重新執行 DeepSea stage.3：

root@master # salt '*' saltutil.refresh_pillar root@master # salt-run state.orch ceph.stage.3

DeepSea 成功完成 stage.3 後，Ceph Dashboard 即會執行。如需 Ceph

Dashboard 功能的詳細綜覽，請參閱《管理指南》, 第 22 章「Ceph

Dashboard」。

若要列出執行儀表板的節點，請執行以下指令：

cephadm@adm > ceph mgr services | grep dashboard

若要列出管理員身分證明，請執行以下指令：

root@master # salt-call grains.get dashboard_creds

9. 循序重新啟動物件閘道服務，以使用「beast」Web 伺服器取代過時的

「civetweb」：

80 更新 policy.cfg 並使用 DeepSea 部署 Ceph Dashboard SES 6

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

10. 繼續之前，我們強烈建議先啟用 Ceph 遙測模組。如需詳細資訊和說明，請參

閱《管理指南》, 第 10 章「Ceph 管理員模組」, 第 10.2 節「遙測模組」。

6.16 從以設定檔為基礎的部署移轉至

DriveGroups

在 SUSE Enterprise Storage 5.5 中，DeepSea 提供了一個稱為「設定檔」的方法

來描述您的 OSD 配置。自 SUSE Enterprise Storage 6 起，我們改用另一種稱為

DriveGroups 的方法 (如需更多詳細資料，請參閱第 5.5.2 節「DriveGroups」)。

注意您不必立即就移轉至新方法。如 salt-run osd.remove、 salt-run osd.replace

或 salt-run osd.purge 之類的破壞性操作仍然可用。但若要新增新 OSD，便需

要移轉至新方法。

由於這些實作的方法不同，我們未提供自動移轉路徑。不過，我們提供了各種工具

(Salt 執行程式) 來儘可能使移轉變得簡單。

6.16.1 分析目前配置

若要檢視有關目前部署的 OSD 的資訊，請使用以下指令：

root@master # salt-run disks.discover

此外，您可以檢查 /srv/pillar/ceph/proposals/profile-*/ 目錄中的檔案內容。其結

構如下所示：

ceph: storage: osds: /dev/disk/by-id/scsi-drive_name: format: bluestore /dev/disk/by-id/scsi-drive_name2: format: bluestore

81 從以設定檔為基礎的部署移轉至 DriveGroups SES 6

6.16.2 建立與目前配置相符的 DriveGroups

如需 DriveGroups 規格的更多詳細資料，請參閱第 5.5.2.1 節「規格」。

全新部署與升級場景的不同之處在於，要移轉的磁碟機已「使用過」。由於

root@master # salt-run disks.list

僅會尋找未使用的磁碟，因此請使用以下指令

root@master # salt-run disks.list include_unavailable=True

調整 DriveGroups，直至其與您目前的設定相符。如需更直觀地了解將要發生的情況，

請使用以下指令。注意，如果沒有可用磁碟，該指令將不會產生任何輸出：

root@master # salt-run disks.report bypass_pillar=True

如果您確認 DriveGroups 組態正確且您要套用新方法，請從 /srv/pillar/ceph/

proposals/profile-PROFILE_NAME/ 目錄中移除檔案，從 /srv/pillar/ceph/proposals/

policy.cfg 檔案中移除相應的 profile-PROFILE_NAME/cluster/*.sls 行，並執行

DeepSea 階段 2 以重新整理 Salt Pillar。


請執行以下指令以確認結果：

root@master # salt target_node pillar.get ceph:storageroot@master # salt-run disks.report

警告：DriveGroups 組態不正確如果未正確設定您的 DriveGroups，且您的設定中有備用磁碟，系統將依您指定

的方式部署這些磁碟。我們建議執行以下指令：

root@master # salt-run disks.report

6.16.3 OSD 部署

對於簡單的情形 (例如獨立的 OSD)，一段時間後將會發生移轉。每當您在叢集中移除

或取代 OSD 時，系統便會以基於 LVM 的新 OSD 取代該 OSD。

82 建立與目前配置相符的 DriveGroups SES 6

提示：移轉至 LVM 形式一旦節點上有一個需要取代的「舊」OSD，所有與其共用裝置的 OSD 都需要移轉

至基於 LVM 的形式。

為確保完整性，請考慮移轉整個節點上的 OSD。

6.16.4 更複雜的設定

如果您使用的是比獨立 OSD 更複雜的設定，例如專屬 WAL/DB 或加密 OSD，則僅當移

除了指定給該 WAL/DB 裝置的所有 OSD 時，才會發生移轉。這是因為 ceph-volume 指

令會在部署前在磁碟上建立邏輯磁碟區。這樣可防止使用者混用基於分割區的部署和基

於 LV 的部署。在此情況下，最好手動移除指定給 WAL/DB 裝置的所有 OSD，並使用

DriveGroups 方法重新部署它們。

83 更複雜的設定 SES 6

7 自訂預設組態

您可以變更在階段 2 產生的預設叢集組態 (請參閱DeepSea 階段描述)。例如，您可能

需要變更網路設定或管理節點上預設安裝的軟體。若要執行前一項操作，可以修改在階

段 2 之後更新的 pillar；對於後一項操作，通常可以透過建立自訂 sls 檔案並將其

新增到 pillar 來完成。如需詳細資料，請參閱以下各節。

7.1 使用自訂的組態檔案

本節列出了需要新增/變更您自己的 sls 檔案的多個任務。當您需要變更預設部署程

序時，一般會使用這樣的程序。

提示：為自訂 .sls 檔案附加字首您的自訂 .sls 檔案與 DeepSea 的 .sls 檔案屬於同一個子目錄。為了防止剛

從 DeepSea 套件中新增的檔案覆寫您的 .sls 檔案，請在您的檔案名稱前附加

custom- 字串。

7.1.1 停用部署步驟

如果您遇到一個不屬於 DeepSea 部署程序的特定任務，因而需要跳過此任務，請依照

以下範例建立一個「no-operation」檔案：

程序 7.1︰停用時間同步

1. 建立並儲存包含以下內容的 /srv/salt/ceph/time/disabled.sls：

disable time setting:test.nop

2. 編輯 /srv/pillar/ceph/stack/global.yml，新增下行，並儲存該檔案：

time_init: disabled

3. 透過重新整理 pillar 並執行以下步驟進行驗證：

84 使用自訂的組態檔案 SES 6

root@master # salt target saltutil.pillar_refreshroot@master # salt 'admin.ceph' state.apply ceph.timeadmin.ceph: Name: disable time setting - Function: test.nop - Result: Clean

Summary for admin.ceph------------Succeeded: 1Failed: 0------------Total states run: 1

注意：唯一 ID任務 ID「disable time setting」可以是在 sls 檔案中唯一的任何訊

息。您可透過指定唯一的描述來防止 ID 衝突。

7.1.2 取代部署步驟

如果需要使用自訂行為取代特定步驟的預設行為，請建立包含取代內容的自訂 sls 檔

案。

預設情況下， /srv/salt/ceph/pool/default.sls 會建立名為「demo」的 rbd 影

像。在本範例中，我們不想建立此影像，而是需要以下兩個影像：「archive1」和

「archive2」。

程序 7.2︰使用兩個自訂 RBD 影像取代 DEMO RBD 影像

1. 建立並儲存包含以下內容的 /srv/salt/ceph/pool/custom.sls：

wait: module.run: - name: wait.out - kwargs: 'status': "HEALTH_ERR" 1

- fire_event: True

archive1: cmd.run: - name: "rbd -p rbd create archive1 --size=1024" 2

- unless: "rbd -p rbd ls | grep -q archive1$" - fire_event: True

archive2:

85 取代部署步驟 SES 6

cmd.run: - name: "rbd -p rbd create archive2 --size=768" - unless: "rbd -p rbd ls | grep -q archive2$" - fire_event: True

1 wait 模組將會暫停，直到 Ceph 叢集狀態不是 HEALTH_ERR 為止。在全新安

裝中，當有足夠數量的 OSD 可用且池建立完成之前，Ceph 叢集可能會一直

保持此狀態。

2 rbd 指令不是等冪。如果在提供影像之後重新執行同一個建立指令，則

Salt 狀態將失敗。unless 陳述式可防止這種情況。

2. 若要呼叫新建的自訂檔案而不是預設檔案，需要編輯 /srv/pillar/ceph/stack/

ceph/cluster.yml，新增下行，然後儲存該檔案：

pool_init: custom


root@master # salt target saltutil.pillar_refreshroot@master # salt 'admin.ceph' state.apply ceph.pool

注意：授權建立池或影像需要有足夠的授權。 admin.ceph Minion 具有管理金鑰圈。

提示：替代方法另一種做法是變更 /srv/pillar/ceph/stack/ceph/roles/master.yml 中的變數。

使用此檔案可緩解其他 Minion 的 pillar 資料凌亂情況。

7.1.3 修改部署步驟

有時，您可能需要使用特定的步驟來執行某些額外任務。不建議您修改相關的狀態檔

案，因為這可能導致將來的升級變得複雜。應建立一個單獨的檔案來執行第 7.1.2 節

「取代部署步驟」中所述的相同額外任務。

為新的 sls 檔案提供一個描述性名稱。例如，如果除了 demo 影像以外，您還需要建

立兩個 rbd 影像，則可將檔案命名為 archive.sls。

86 修改部署步驟 SES 6

程序 7.3︰建立兩個其他 RBD 影像

1. 建立並儲存包含以下內容的 /srv/salt/ceph/pool/custom.sls：

include: - .archive - .default

提示：Include 優先順序在本範例中，Salt 將會依次建立 archive 影像和 demo 影像。本範例中的

順序並不重要。若要變更順序，請反轉 include: 指令後面的行。

您可將 include 行直接新增到 archive.sls，如此也會建立所有影像。但

是，無論將 include 行置於哪個位置，Salt 都會先處理所包含檔案中的步

驟。儘管可以使用 requires 和 order 陳述式覆寫此行為，但使用包含其

他陳述式的單獨檔案可保證順序正確，並減少出現混淆的可能性。

2. 編輯 /srv/pillar/ceph/stack/ceph/cluster.yml，新增下行，並儲存該檔案：

pool_init: custom


root@master # salt target saltutil.pillar_refreshroot@master # salt 'admin.ceph' state.apply ceph.pool

7.1.4 修改部署階段

如果需要新增完全獨立的部署步驟，請建立 3 個新檔案：用於執行指令的 sls 檔

案、協調化檔案，以及使新步驟與原始部署步驟保持一致的自訂檔案。

例如，如果在執行準備階段期間需要在所有 Minion 上執行 logrotate：

首先建立一個 sls 檔案並包含 logrotate 指令。

程序 7.4︰在所有 SALT MINION 上執行 logrotate

1. 建立一個目錄，例如 /srv/salt/ceph/logrotate。

2. 建立並儲存包含以下內容的 /srv/salt/ceph/logrotate/init.sls：

87 修改部署階段 SES 6

rotate logs: cmd.run: - name: "/usr/sbin/logrotate /etc/logrotate.conf"

3. 驗證該指令在 Minion 上是否正常運作：

root@master # salt 'admin.ceph' state.apply ceph.logrotate

由於協調化檔案需要在其他所有準備步驟之前執行，因此請將其新增到準備階段 0：

1. 建立並儲存包含以下內容的 /srv/salt/ceph/stage/prep/logrotate.sls：

logrotate: salt.state: - tgt: '*' - sls: ceph.logrotate

2. 驗證協調化檔案是否正常運作：

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

最後一個檔案是自訂檔案，其中包含附加步驟和原始步驟：

1. 建立並儲存包含以下內容的 /srv/salt/ceph/stage/prep/custom.sls：

include: - .logrotate - .master - .minion

2. 覆寫預設行為。編輯 /srv/pillar/ceph/stack/global.yml，新增下行，並儲存該

檔案：

stage_prep: custom

3. 驗證階段 0 是否正常運作：


注意：為何使用 global.yml？之所以選擇 global.yml 檔案而不選擇 cluster.yml，是因為在準備階段，所有

Minion 都不屬於 Ceph 叢集，並且無權存取 cluster.yml 中的任何設定。

88 修改部署階段 SES 6

7.1.5 階段 0 期間的更新和重新開機

在階段 0 (如需 DeepSea 階段的詳細資訊，請參閱DeepSea 階段描述) 期間，Salt

Master 和 Salt Minion 可能會選擇性地重新開機，因為新更新的套件 (例如 kernel )

要求將系統重新開機。

預設行為是安裝可用的新更新，且不將節點重新開機，即使進行核心更新時也是如此。

您可以在 /srv/pillar/ceph/stack/global.yml 檔案中新增/變更 stage_prep_master

和 stage_prep_minion 選項，以變更 DeepSea 階段 0 的預設更新/重新開機行

為。 _prep_master 用於設定 Salt Master 的階段行為， stage_prep_minion 用於設

定所有 Minion 的行為。所有可用的參數如下：

default

安裝更新而不重新開機。

default-update-reboot

安裝更新並在更新後重新開機。

default-no-update-reboot

重新開機而不安裝更新。

default-no-update-no-reboot

不安裝更新，也不重新開機。

例如，若要防止叢集節點安裝更新和重新開機，請編輯 /srv/pillar/ceph/stack/

global.yml，新增以下幾行：

stage_prep_master: default-no-update-no-rebootstage_prep_minion: default-no-update-no-reboot

提示：值和相應檔案stage_prep_master 的值對應至位於 /srv/salt/ceph/stage/0/master 中的檔案

名稱，而 stage_prep_minion 的值對應至 /srv/salt/ceph/stage/0/minion 中的

檔案：

root@master # ls -l /srv/salt/ceph/stage/0/masterdefault-no-update-no-reboot.slsdefault-no-update-reboot.slsdefault-update-reboot.sls[...]

89 階段 0 期間的更新和重新開機 SES 6

root@master # ls -l /srv/salt/ceph/stage/0/miniondefault-no-update-no-reboot.slsdefault-no-update-reboot.slsdefault-update-reboot.sls[...]

7.2 修改已探查的組態

完成階段 2 之後，您可能需要變更已探查的組態。若要檢視目前設定，請執行：

root@master # salt target pillar.items

單一 Minion 的預設組態的輸出通常類似下方所示：

---------- available_roles: - admin - mon - storage - mds - igw - rgw - client-cephfs - client-radosgw - client-iscsi - mds-nfs - rgw-nfs - master cluster: ceph cluster_network: 172.16.22.0/24 fsid: e08ec63c-8268-3f04-bcdb-614921e94342 master_minion: admin.ceph mon_host: - 172.16.21.13 - 172.16.21.11 - 172.16.21.12 mon_initial_members: - mon3 - mon1 - mon2 public_address:

90 修改已探查的組態 SES 6

172.16.21.11 public_network: 172.16.21.0/24 roles: - admin - mon - mds time_server: admin.ceph time_service: ntp

將在多個組態檔案之間分發上述設定。包含這些檔案的目錄結構在 /srv/pillar/ceph/

stack/stack.cfg 目錄中定義。以下檔案通常用於描述您的叢集：

/srv/pillar/ceph/stack/global.yml - 該檔案會影響 Salt 叢集中的所有

Minion。

/srv/pillar/ceph/stack/ceph/cluster.yml - 該檔案會影響名為 ceph 的 Ceph

叢集中的所有 Minion。

/srv/pillar/ceph/stack/ceph/roles/role.yml - 會影響 ceph 叢集中指定了特定

角色的所有 Minion。

/srv/pillar/ceph/stack/ceph/minions/MINION_ID/yml - 會影響個別 Minion。

注意：覆寫包含預設值的目錄/srv/pillar/ceph/stack/default 中存在儲存預設組態設定的平行目錄樹。請不

要變更此處的值，否則會將其覆寫。

變更所收集組態的一般程序如下：

1. 找到需要變更的組態項目的位置。例如，如果需要變更叢集網路等叢集相關設

定，請編輯檔案 /srv/pillar/ceph/stack/ceph/cluster.yml。

2. 儲存檔案。

3. 執行以下指令來驗證所做的變更：

root@master # salt target saltutil.pillar_refresh

91 修改已探查的組態 SES 6

然後輸入

root@master # salt target pillar.items

7.2.1 為 Ceph 叢集部署啟用 IPv6

由於普遍使用的網路定址是 IPv4，您需要透過自訂設定來啟用 IPv6。DeepSea 沒有自

動探查 IPv6 定址的功能。

若要設定 IPv6，請將 /srv/pillar/ceph/stack/global.yml 檔案中的 public_network

和 cluster_network 變數設定為有效的 IPv6 子網路。例如：

public_network: fd00:10::/64cluster_network: fd00:11::/64

然後執行 DeepSea 階段 2，並確認網路資訊與該設定相符。Stage 3 將產生包含必要

旗標的 ceph.conf。

重要：不支援雙堆疊Ceph 不支援雙堆疊，即無法同時在 IPv4 和 IPv6 上執行 Ceph。DeepSea 驗證

將拒絕 public_network 與 cluster_network 之間或任一變數內的不符項。下面

就是未通過驗證的範例。

public_network: "192.168.10.0/24 fd00:10::/64"

提示：避免使用 fe80::/10 link-local 位址請避免使用 fe80::/10 link-local 位址。系統會為所有網路介面都指定一個

fe80 位址，因而需要有介面限定詞才能正確進行路由。請指定為您的站台配置

的 IPv6 位址，或考慮使用 fd00::/8。這些位址是 ULA 的一部分，無法進行全

域路由。

92 為 Ceph 叢集部署啟用 IPv6 SES 6

III 安裝其他服務

8 安裝用於存取資料的服務 94

9 Ceph 物件閘道 95

10 安裝 iSCSI 閘道 102

11 安裝 CephFS 115

12 安裝 NFS Ganesha 129

8 安裝用於存取資料的服務

部署 SUSE Enterprise Storage 6 叢集後，您可能需要安裝物件閘道或 iSCSI 閘道等

附加軟體，以便存取您的資料，或者也可以在 Ceph 叢集之上部署一個叢集化檔案系

統。本章重點介紹手動安裝。如果您的叢集是使用 Salt 部署的，請參閱第 5 章「使

用 DeepSea/Salt 部署」瞭解安裝特定閘道或 CephFS 的程序。

94 SES 6

9 Ceph 物件閘道

Ceph 物件閘道是構建在 librgw 之上的物件儲存介面，為應用程式提供用於連接 Ceph

叢集的 RESTful 閘道。該閘道支援兩種介面：

S3 相容：透過與 Amazon S3 RESTful API 的某個大型子集相容的介面提供物件

儲存功能。

Swift 相容：透過與 OpenStack Swift API 的某個大型子集相容的介面提供物件

儲存功能。

物件閘道精靈預設使用「Beast」HTTP 前端。該前端使用 Boost.Beast 程式庫處理

HTTP 剖析，並使用 Boost.Asio 程式庫處理非同步網路 I/O 操作。

由於物件閘道提供與 OpenStack Swift 和 Amazon S3 相容的介面，因此具有自己的使

用者管理功能。物件閘道可將資料儲存在用於儲存來自 CephFS 用戶端或 RADOS 區塊

裝置用戶端的資料的同一個叢集中。S3 和 Swift API 共用一個通用名稱空間，因此，

您可以使用其中一個 API 寫入資料，使用另一個 API 擷取資料。

重要：DeepSea 部署的物件閘道系統會將物件閘道做為 DeepSea 角色安裝，因此，您不需要手動安裝。

若要在叢集部署期間安裝物件閘道，請參閱第 5.3 節「叢集部署」。

若要將包含物件閘道的新節點新增至叢集，請參閱《管理指南》, 第 2 章

「Salt 叢集管理」, 第 2.2 節「新增新的角色至節點」。

9.1 手動安裝物件閘道

1. 在未使用連接埠 80 的節點上安裝物件閘道。以下指令會安裝所有必需的元件：

cephadm@ogw > sudo zypper ref && zypper in ceph-radosgw

2. 如果先前的物件閘道例項中的 Apache 伺服器正在執行，請停止該伺服器並停用

相關的服務：

cephadm@ogw > sudo systemctl stop disable apache2.service

95 手動安裝物件閘道 SES 6

3. 編輯 /etc/ceph/ceph.conf，新增以下幾行：

[client.rgw.gateway_host] rgw frontends = "beast port=80"

提示如果您想將物件閘道/Beast 設定為與 SSL 加密配合使用，請對下面一行進

行相應修改：

rgw frontends = beast ssl_port=7480 ssl_certificate=PATH_TO_CERTIFICATE.PEM

4. 重新啟動物件閘道服務。

cephadm@ogw > sudo systemctl restart [email protected]_host

9.1.1 物件閘道組態

設定物件閘道需要執行數個步驟。

9.1.1.1 基本組態

設定 Ceph 物件閘道需要一個正常執行的 Ceph 儲存叢集。Ceph 物件閘道是 Ceph 儲

存叢集的用戶端。做為 Ceph 儲存叢集用戶端，它需要：

閘道例項的主機名稱，例如 gateway。

具有相應權限和金鑰圈的儲存叢集使用者名稱。

用於儲存閘道資料的池。

閘道例項的資料目錄。

Ceph 組態檔案中的例項項目。

每個例項都必須具有使用者名稱和金鑰才能與 Ceph 儲存叢集進行通訊。在以下步驟

中，我們將使用監控程式節點建立開機金鑰圈，然後基於開機金鑰圈建立物件閘道例項

使用者金鑰圈。隨後建立用戶端使用者名稱和金鑰。接下來，我們將金鑰新增至 Ceph

儲存叢集。最後，將金鑰圈分發到包含閘道例項的節點。

96 物件閘道組態 SES 6

1. 為閘道建立金鑰圈：

cephadm@adm > ceph-authtool --create-keyring /etc/ceph/ceph.client.rgw.keyringcephadm@adm > sudo chmod +r /etc/ceph/ceph.client.rgw.keyring

2. 為每個例項產生 Ceph 物件閘道使用者名稱和金鑰。例如，我們將在

client.radosgw 後面使用名稱 gateway：

cephadm@adm > ceph-authtool /etc/ceph/ceph.client.rgw.keyring \ -n client.rgw.gateway --gen-key

3. 為金鑰新增功能：

cephadm@adm > ceph-authtool -n client.rgw.gateway --cap osd 'allow rwx' \ --cap mon 'allow rwx' /etc/ceph/ceph.client.rgw.keyring

4. 建立可讓 Ceph 物件閘道存取 Ceph 儲存叢集的金鑰圈和金鑰之後，請將金鑰新

增至 Ceph 儲存叢集。例如：

cephadm@adm > ceph -k /etc/ceph/ceph.client.admin.keyring auth add client.rgw.gateway \ -i /etc/ceph/ceph.client.rgw.keyring

5. 將金鑰圈分發到包含閘道例項的節點：

cephadm@adm > scp /etc/ceph/ceph.client.rgw.keyring ceph@HOST_NAME:/home/cephcephadm@adm > ssh ceph@HOST_NAMEcephadm@ogw > mv ceph.client.rgw.keyring /etc/ceph/ceph.client.rgw.keyring

提示：使用開機金鑰圈另一種替代方法是建立物件閘道開機金鑰圈，然後基於該金鑰圈建立物件閘道金

鑰圈：

1. 在某個監控程式節點上建立物件閘道開機金鑰圈：

cephadm@mon > ceph \ auth get-or-create client.bootstrap-rgw mon 'allow profile bootstrap-rgw' \ --connect-timeout=25 \ --cluster=ceph \ --name mon. \ --keyring=/var/lib/ceph/mon/ceph-NODE_HOST/keyring \ -o /var/lib/ceph/bootstrap-rgw/keyring

2. 建立 /var/lib/ceph/radosgw/ceph-RGW_NAME 目錄以儲存開機金鑰圈：


cephadm@mon > mkdir \/var/lib/ceph/radosgw/ceph-RGW_NAME

3. 基於新建的開機金鑰圈建立物件閘道金鑰圈：

cephadm@mon > ceph \ auth get-or-create client.rgw.RGW_NAME osd 'allow rwx' mon 'allow rw' \ --connect-timeout=25 \ --cluster=ceph \ --name client.bootstrap-rgw \ --keyring=/var/lib/ceph/bootstrap-rgw/keyring \ -o /var/lib/ceph/radosgw/ceph-RGW_NAME/keyring

4. 將物件閘道金鑰圈複製到物件閘道主機：

cephadm@mon > scp \/var/lib/ceph/radosgw/ceph-RGW_NAME/keyring \RGW_HOST:/var/lib/ceph/radosgw/ceph-RGW_NAME/keyring

9.1.1.2 建立池 (選擇性)

Ceph 物件閘道需要使用 Ceph 儲存叢集池來儲存特定的閘道資料。如果建立的使用者

具有適當的權限，則閘道會自動建立池。但是，請務必在 Ceph 組態檔案中為每個池設

定適當的預設放置群組數量。

池名稱遵循 ZONE_NAME.POOL_NAME 語法。使用預設區域設定閘道時，本範例中的預設

區域名稱為「default」：

.rgw.rootdefault.rgw.controldefault.rgw.metadefault.rgw.logdefault.rgw.buckets.indexdefault.rgw.buckets.data

若要手動建立池，請參閱《管理指南》, 第 11 章「管理儲存池」, 第 11.2.2 節「建

立池」。


重要：物件閘道和糾刪碼池只能對 default.rgw.buckets.data 池執行糾刪碼操作。需要複製所有其他池，

否則將無法連接閘道。

9.1.1.3 將閘道組態新增至 Ceph

將 Ceph 物件閘道組態新增至 Ceph 組態檔案。Ceph 物件閘道組態要求您識別 Ceph

物件閘道例項。然後，指定安裝了 Ceph 物件閘道精靈的主機名稱、金鑰圈 (用於

cephx) 和記錄檔案 (選擇性)。例如：

[client.rgw.INSTANCE_NAME]host = HOST_NAMEkeyring = /etc/ceph/ceph.client.rgw.keyring

提示：物件閘道記錄檔案若要覆寫預設的物件閘道記錄檔案，請包含以下指令：

log file = /var/log/radosgw/client.rgw.INSTANCE_NAME.log

當設定用戶端類型為 Ceph 物件閘道 (radosgw) 的 Ceph 儲存叢集用戶端時，閘道例

項的 [client.rgw.*] 部分可識別 Ceph 組態檔案的此部分。後跟例項名稱。例如：

[client.rgw.gateway]host = ceph-gatewaykeyring = /etc/ceph/ceph.client.rgw.keyring

注意HOST_NAME 必須是您的機器主機名稱，不包括網域名稱。

然後關閉 print continue。如果將其設定為 true，執行 PUT 操作時可能會遇到問

題：

rgw print continue = false


若要透過子網域 S3 呼叫使用 Ceph 物件閘道 (例如 http://bucketname.hostname )，

必須在 Ceph 組態檔案的 [client.rgw.gateway] 區段下面新增 Ceph 物件閘道 DNS

名稱：

[client.rgw.gateway]...rgw dns name = HOST_NAME

此外，在使用 http://BUCKET_NAME.HOST_NAME 語法時，應考慮在用戶端機器上安裝

Dnsmasq 這樣的 DNS 伺服器。 dnsmasq.conf 檔案應包含以下設定：

address=/HOST_NAME/HOST_IP_ADDRESSlisten-address=CLIENT_LOOPBACK_IP

然後，在用戶端機器上新增 CLIENT_LOOPBACK_IP IP 位址做為第一部 DNS 伺服器。

9.1.1.4 建立資料目錄

部署程序檔可能無法建立預設的 Ceph 物件閘道資料目錄。如果尚未為 radosgw 精靈

的每個例項建立資料目錄，請予以建立。Ceph 組態檔案中的 host 變數用於確定哪個

主機執行 radosgw 精靈的每個例項。一般的格式會指定 radosgw 精靈、叢集名稱和精

靈 ID。

root # mkdir -p /var/lib/ceph/radosgw/CLUSTER_ID

使用上面的範例 ceph.conf 設定執行以下指令：

root # mkdir -p /var/lib/ceph/radosgw/ceph-radosgw.gateway

9.1.1.5 重新啟動服務並啟動閘道

為了確保所有元件都已重新載入其組態，建議您重新啟動 Ceph 儲存叢集服務。然後啟

動 radosgw 服務。如需詳細資訊，請參閱《管理指南》, 第 4 章「簡介」與《管理指

南》, 第 17 章「Ceph 物件閘道」, 第 17.3 節「操作物件閘道服務」。

服務啟動並執行後，您可以發出匿名 GET 申請，以檢查閘道是否傳回回應。向網域名

稱發出簡單的 HTTP 申請應會傳回以下回應：

<ListAllMyBucketsResult>


<Owner> <ID>anonymous</ID> <DisplayName/> </Owner> <Buckets/></ListAllMyBucketsResult>


10 安裝 iSCSI 閘道

iSCSI 是一種儲存區域網路 (SAN) 通訊協定，可讓用戶端 (稱為啟動器) 將 SCSI 指

令傳送至遠端伺服器上的 SCSI 儲存裝置 (目標)。SUSE Enterprise Storage 6 包含

一個可透過 iSCSI 通訊協定向異質用戶端 (例如 Microsoft Windows* 和 VMware*

vSphere) 開放 Ceph 儲存管理的工具。多重路徑 iSCSI 存取可讓這些用戶端實現可用

性與延展性，此外，該標準化 iSCSI 通訊協定在用戶端與 SUSE Enterprise Storage

6 叢集之間提供了一層額外的安全性隔離。該組態工具名為 ceph-iscsi。使用 ceph-

iscsi，Ceph 儲存管理員可以定義精簡佈建的高可用性複製磁碟區，其支援唯讀快照、

讀取寫入克隆，以及 Ceph RADOS 區塊裝置 (RBD) 的自動大小調整。然後，管理員可

以透過單個 ceph-iscsi 閘道主機輸出磁碟區，或透過支援多重路徑容錯移轉的多個

閘道主機來輸出。Linux、Microsoft Windows 和 VMware 主機可以使用 iSCSI 通訊

協定連接到磁碟區，因此可如任何其他 SCSI 區塊裝置一般供您使用。這表示，SUSE

Enterprise Storage 6 客戶實際上可在 Ceph 上執行具有傳統 SAN 所有功能和優勢的

完整區塊儲存基礎架構子系統，從而在未來實現蓬勃發展。

本章詳細介紹如何設定 Ceph 叢集基礎架構和 iSCSI 閘道，以便用戶端主機能夠透過

iSCSI 通訊協定，如同在本機儲存裝置上一般使用遠端儲存的資料。

10.1 iSCSI 區塊儲存

iSCSI 是 RFC 3720 中指定的、使用網際網路通訊協定 (IP) 的小型電腦系統介面

(SCSI) 指令集的一種實作。iSCSI 以服務形式實作，其中，用戶端 (啟動器) 在 TCP

連接埠 3260 上透過工作階段來與伺服器 (目標) 通訊。iSCSI 目標的 IP 位址和連接

埠稱為 iSCSI 入口網站，其中，一個目標可透過一個或多個入口網站公開。一個目標

與一個或多個入口網站的組合稱為目標入口網站群組 (TPG)。

iSCSI 的基礎資料連結層通訊協定通常為乙太網路。更具體地說，現代 iSCSI 基礎架

構使用 10 Gb 乙太網路或更快的網路實現最佳輸送量。強烈建議您在 iSCSI 閘道與後

端 Ceph 叢集之間建立 10 Gb 乙太網路連接。

102 iSCSI 區塊儲存 SES 6

10.1.1 Linux 核心 iSCSI 目標

Linux 核心 iSCSI 目標最初稱作 linux-iscsi.org 的 LIO，它是專案的原始網域和網

站。在過去一段時間，適用於 Linux 平台的 iSCSI 目標實作競爭產品不少於四個，但

LIO 做為單一 iSCSI 參考目標最終獲得了壓倒性優勢。LIO 的主流核心代碼使用簡單

但有些含糊的名稱「目標」，來區別「目標核心」與各種前端和後端目標模組。

可以說，最常用的前端模組就是 iSCSI。但是，LIO 也支援光纖通道 (FC)、透過乙太

網路的光纖通道 (FCoE) 與其他多種前端通訊協定。目前，SUSE Enterprise Storage

僅支援 iSCSI 通訊協定。

最常用的目標後端模組是能夠方便地在目標主機上重新輸出任何可用區塊裝置的模組。

此模組名為 iblock。但是，LIO 還有一個 RBD 特定的後端模組，該模組支援對 RBD

影像進行平行多重路徑 I/O 存取。

10.1.2 iSCSI 啟動器

本節簡要介紹 Linux、Microsoft Windows 和 VMware 平台上使用的 iSCSI 啟動器。

10.1.2.1 Linux

Linux 平台的標準啟動器是 open-iscsi。 open-iscsi 會啟動精靈 iscsid，然後，使

用者可以使用該精靈來探查任何給定入口網站上的 iSCSI 目標、登入到目標，以及對

應 iSCSI 磁碟區。 iscsid 會與 SCSI 中間層通訊以建立核心中區塊裝置，然後，核

心便可如處理系統上的任何其他 SCSI 區塊裝置一般處理這些裝置。您可以搭配裝置對

應程式多重路徑 ( dm-multipath ) 工具一起部署 open-iscsi 啟動器，以提供高可用性

iSCSI 區塊裝置。

10.1.2.2 Microsoft Windows 和 Hyper-V

Microsoft Windows 作業系統的預設 iSCSI 啟動器是 Microsoft iSCSI 啟動

器。iSCSI 服務可透過圖形使用者介面 (GUI) 進行設定，並支援使用多重路徑 I/O 以

提供高可用性。

103 Linux 核心 iSCSI 目標 SES 6

10.1.2.3 VMware

VMware vSphere 和 ESX 的預設 iSCSI 啟動器是 VMware ESX 軟體 iSCSI 啟動器

vmkiscsi。啟用該啟動器後，可透過 vSphere 用戶端或使用 vmkiscsi-tool 指令對其

進行設定。然後，您可以使用 VMFS 來格式化透過 vSphere iSCSI 儲存介面卡連接的

儲存磁碟區，並如同使用任何其他虛擬機器儲存裝置一般使用它們。VMware 啟動器還

支援使用多重路徑 I/O 以提供高可用性。

10.2 有關 ceph-iscsi 的一般資訊

ceph-iscsi 兼具 RADOS 區塊裝置的優勢與 iSCSI 無所不在的通用性。透過在 iSCSI

目標主機 (稱為 iSCSI 閘道) 上使用 ceph-iscsi，任何需要利用區塊儲存的應用程式

都可受益於 Ceph，即使不支援任何 Ceph 用戶端通訊協定的應用程式也不例外。而使

用者可以使用 iSCSI 或任何其他目標前端通訊協定連接至 LIO 目標，從而可以轉換針

對 RBD 儲存的所有目標 I/O。

圖形 10.1︰包含單一 ISCSI 閘道的 CEPH 叢集

ceph-iscsi 先天就具有高可用性，並支援多重路徑操作。因此，下游啟動器主機可以

使用多個 iSCSI 閘道實現高可用性和延展性。與包含多個閘道的 iSCSI 組態通訊時，

啟動器可在多個閘道之間實現 iSCSI 申請的負載平衡。如果某個閘道發生故障 (暫時

不可連接，或因為維護而停用)，則將透過另一個閘道以透明方式繼續處理 I/O。

104 有關 ceph-iscsi 的一般資訊 SES 6

圖形 10.2︰包含多個 ISCSI 閘道的 CEPH 叢集

10.3 部署考量

包含 ceph-iscsi 的最低 SUSE Enterprise Storage 6 組態由以下元件組成：

一個 Ceph 儲存叢集。該 Ceph 叢集至少包含四部實體伺服器，其中每部伺服器

至少代管八個物件儲存精靈 (OSD)。在此類組態中，有三個 OSD 節點額外充當監

控程式 (MON) 主機。

一部透過 ceph-iscsi 設定且執行 LIO iSCSI 目標的 iSCSI 目標伺服器。

一部 iSCSI 啟動器主機，執行 open-iscsi (Linux)、Microsoft iSCSI 啟動器

(Microsoft Windows) 或任何其他相容的 iSCSI 啟動器實作。

包含 ceph-iscsi 的 SUSE Enterprise Storage 6 建議生產組態由以下元件組成：

105 部署考量 SES 6

一個 Ceph 儲存叢集。一個 Ceph 生產叢集，它由任意數量 (一般是 10 個以上)

的 OSD 節點組成，其中每個節點一般執行 10-12 個物件儲存精靈 (OSD)，以及

至少三部專屬 MON 主機。

多部透過 ceph-iscsi 設定且執行 LIO iSCSI 目標的 iSCSI 目標伺服器。為實

現 iSCSI 容錯移轉和負載平衡，這些伺服器必須執行支援 target_core_rbd 模組

的核心。您可透過 SUSE Linux Enterprise Server 維護通道取得更新套件。

任意數量的 iSCSI 啟動器主機，這些主機執行 open-iscsi (Linux)、Microsoft

iSCSI 啟動器 (Microsoft Windows) 或任何其他相容的 iSCSI 啟動器實作。

10.4 安裝和組態本節介紹在 SUSE Enterprise Storage 之上安裝和設定 iSCSI 閘道的步驟。

10.4.1 將 iSCSI 閘道部署到 Ceph 叢集

您可以在 Ceph 叢集部署期間部署 iSCSI 閘道，或者使用 DeepSea 將 iSCSI 閘道新

增至現有叢集。

若要在叢集部署期間加入 iSCSI 閘道，請參閱第 5.5.1.2 節「角色指定」。

若要將 iSCSI 閘道新增至現有叢集，請參閱《管理指南》, 第 2 章「Salt 叢集管

理」, 第 2.2 節「新增新的角色至節點」。

10.4.2 建立 RBD 影像

RBD 影像建立於 Ceph 儲存中，並在隨後輸出至 iSCSI。建議您為此使用專屬的 RADOS

池。您可以在能夠使用 Ceph rbd 指令行公用程式連接到儲存叢集的任何主機上建立

磁碟區。這需要用戶端至少有一個精簡的 ceph.conf 組態檔案，以及相應的 CephX 驗

證身分證明。

若要透過 iSCSI 建立一個隨後可供輸出的新磁碟區，請使用 rbd create 指令並指定

磁碟區大小 (以 MB 為單位)。例如，若要在名為「iscsi-images」的池中建立名為

「testvol」的 100 GB 磁碟區，請執行以下指令：

cephadm@adm > rbd --pool iscsi-images create --size=102400 'testvol'

106 安裝和組態 SES 6

10.4.3 透過 iSCSI 輸出 RBD 影像

若要透過 iSCSI 輸出 RBD 影像，您可以使用 Ceph Dashboard Web 介面或 ceph-

iscsi gwcli 公用程式。在本節中，我們僅重點介紹 gwcli，並演示如何使用指令行建

立輸出 RBD 影像的 iSCSI 目標。

注意系統僅支援以下 RBD 影像功能： layering、 striping (v2)、 exclusive-

lock、 fast-diff 和 data-pool。無法輸出啟用了任何其他功能的 RBD 影像。

以 root 身分啟動 iSCSI 閘道指令行介面：

root # gwcli

移至 iscsi-targets，然後建立名為 iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol

的目標：

gwcli > /> cd /iscsi-targetsgwcli > /iscsi-targets> create iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol

透過指定閘道名稱和 IP 位址建立 iSCSI 閘道：

gwcli > /iscsi-targets> cd iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/gatewaysgwcli > /iscsi-target...tvol/gateways> create iscsi1 192.168.124.104gwcli > /iscsi-target...tvol/gateways> create iscsi2 192.168.124.105

提示使用 help 指令可顯示目前組態節點中的可用指令清單。

在池「iscsi-images」中新增名為「testvol」的 RBD 影像：

gwcli > /iscsi-target...tvol/gateways> cd /disksgwcli > /disks> attach iscsi-images/testvol

將 RBD 影像對應至目標：

gwcli > /disks> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/disksgwcli > /iscsi-target...testvol/disks> add iscsi-images/testvol

107 透過 iSCSI 輸出 RBD 影像 SES 6

注意您可以使用層級較低的工具 (例如 targetcli ) 來查詢本地組態，但無法修改組

態。

提示您可以使用 ls 指令查看組態。有些組態節點還支援 info 指令，該指令可用於

顯示更多詳細資訊。

請注意，系統預設會啟用 ACL 驗證，因此目前尚不可存取此目標。如需驗證和存取控

制的詳細資訊，請參閱第 10.4.4 節「驗證和存取控制」。

10.4.4 驗證和存取控制

iSCSI 驗證十分靈活，涵蓋了許多驗證可能性。

10.4.4.1 無驗證

「無驗證」表示任何啟動器均能存取對應目標上的任何 LUN。您可以透過停用 ACL 驗

證來啟用「無驗證」：

gwcli > /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/hostsgwcli > /iscsi-target...testvol/hosts> auth disable_acl

10.4.4.2 ACL 驗證

使用基於啟動器名稱的 ACL 驗證時，僅允許定義的啟動器進行連接。您可以透過執行

以下指令來定義啟動器：

gwcli > /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/hostsgwcli > /iscsi-target...testvol/hosts> create iqn.1996-04.de.suse:01:e6ca28cc9f20

定義的啟動器雖然能夠連接，但只能存取已明確新增至該啟動器的 RBD 影像：

gwcli > /iscsi-target...:e6ca28cc9f20> disk add rbd/testvol

108 驗證和存取控制 SES 6

10.4.4.3 CHAP 驗證

除了 ACL 以外，您還可以透過為每個啟動器指定使用者名稱和密碼來啟用 CHAP 驗

證：

gwcli > /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/hosts/iqn.1996-04.de.suse:01:e6ca28cc9f20gwcli > /iscsi-target...:e6ca28cc9f20> auth username=common12 password=pass12345678

注意使用者名稱的長度必須為 8 到 64 個字元，並且只能包含字母、「.」、

「@」、「-」、「_」或「:」。

密碼的長度必須為 12 到 16 個字元，並且只能包含字母、「@」、「-」、

「_」或「/」。

(選擇性) 您也可以在 auth 指令中指定 mutual_username 和 mutual_password 參

數，以啟用 CHAP 雙向驗證。

10.4.4.4 探查驗證和雙向驗證

探查驗證獨立於之前的驗證方法。該驗證需要身分證明才能進行瀏覽，它是選擇性設

定，可透過執行以下指令來設定：

gwcli > /> cd /iscsi-targetsgwcli > /iscsi-targets> discovery_auth username=du123456 password=dp1234567890

注意使用者名稱的長度必須為 8 到 64 個字元，並且只能包含字母、「.」「@」、

「-」、「_」或「:」。

密碼的長度必須為 12 到 16 個字元，並且只能包含字母、「@」、「-」、

「_」或「/」。

(選擇性) 您也可以在 discovery_auth 指令中指定 mutual_username 和

mutual_password 參數。

109 驗證和存取控制 SES 6

可以使用以下指令來停用探查驗證：

gwcli > /iscsi-targets> discovery_auth nochap

10.4.5 進階設定

可以為 ceph-iscsi 設定隨後將傳遞給 LIO I/O 目標的進階參數。參數分為「目標」

和「磁碟」參數。

警告除非另有說明，否則不建議將這些參數變更為使用非預設設定。

10.4.5.1 目標設定

您可以使用 info 指令檢視這些設定的值：

gwcli > /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvolgwcli > /iscsi-target...i.x86:testvol> info

還可以使用 reconfigure 指令變更設定：

gwcli > /iscsi-target...i.x86:testvol> reconfigure login_timeout 20

可用的「目標」設定包括：

default_cmdsn_depth

預設的 CmdSN (指令順序編號) 深度。限制 iSCSI 啟動器可在任何時候具有的未

處理申請數量。

default_erl

預設的錯誤復原層級。

login_timeout

登入逾時值 (以秒為單位)。

netif_timeout

110 進階設定 SES 6

NIC 故障逾時 (以秒為單位)。

prod_mode_write_protect

如果設定為 1，則阻止寫入 LUN。

10.4.5.2 磁碟設定

您可以使用 info 指令檢視這些設定的值：

gwcli > /> cd /disks/rbd/testvolgwcli > /disks/rbd/testvol> info

還可以使用 reconfigure 指令變更設定：

gwcli > /disks/rbd/testvol> reconfigure rbd/testvol emulate_pr 0

可用的「磁碟」設定包括：

block_size

基礎裝置的區塊大小。

emulate_3pc

如果設定為 1，則啟用「協力廠商複製」。

emulate_caw

如果設定為 1，則啟用「比較並寫入」。

emulate_dpo

如果設定為 1，則開啟「停用頁面輸出」。

emulate_fua_read

如果設定為 1，則啟用「強制單元讀取存取」。

emulate_fua_write

如果設定為 1，則啟用「強制單元寫入存取」。

emulate_model_alias

如果設定為 1，則使用後端裝置名稱做為模型別名。

emulate_pr


如果設定為 0，將停用 SCSI 保留 (包括永久群組保留) 支援。停用該支援

後，SES iSCSI 閘道可能會忽略保留狀態，導致要求延遲情況得到改進。

提示如果 iSCSI 啟動器不需要 SCSI 保留支援，建議將 backstore_emulate_pr

設定為 0。

emulate_rest_reord

如果設定為 0，則佇列演算法修飾詞的重新排序受限。

emulate_tas

如果設定為 1，則啟用「任務已中止狀態」。

emulate_tpu

如果設定為 1，則啟用「精簡佈建 - 取消對應」。

emulate_tpws

如果設定為 1，則啟用「精簡佈建 - 寫入相同內容」。

emulate_ua_intlck_ctrl

如果設定為 1，則啟用「單元警告聯鎖」。

emulate_write_cache

如果設定為 1，則開啟「啟用寫入快取」。

enforce_pr_isids

如果設定為 1，則強制持續保留 ISID。

is_nonrot

如果設定為 1，則支援儲存為非旋轉裝置。

max_unmap_block_desc_count

UNMAP 的最大區塊描述子數量。

max_unmap_lba_count：

UNMAP 的最大 LBA 數。

max_write_same_len


WRITE_SAME 的最大長度。

optimal_sectors

磁區中的最佳申請大小。

pi_prot_type

DIF 保護類型。

queue_depth

佇列深度。

unmap_granularity

UNMAP 細粒度。

unmap_granularity_alignment

UNMAP 細粒度對齊。

force_pr_aptpl

如果啟用該設定，無論用戶端是否透過 aptpl=1 發出了相應要求，LIO 都一律會

將永久保留狀態寫出至永久儲存區。這對 LIO 的核心 RBD 後端不會產生任何影

響，該後端永遠會保留 PR 狀態。理論上，如果有人嘗試透過 configfs 停用該

設定， target_core_rbd 選項應該會強制將其設定為「1」並拋出錯誤。

unmap_zeroes_data

影響 LIO 是否會向 SCSI 啟動器通告 LBPRZ，表示將在執行包含取消對應位元的

UNMAP 或 WRITE SAME 指令後從某個區域讀回零。

10.5 使用 tcmu-runner 輸出 RADOS 區塊裝置

影像

ceph-iscsi 支援 rbd (基於核心) 和 user:rbd (tcmu-runner) 後備儲存，這使整個

管理過程變得透明並且獨立於後備儲存。

警告：技術預覽基於 tcmu-runner 的 iSCSI 閘道部署目前以技術預覽的方式提供。

113 使用 tcmu-runner 輸出 RADOS 區塊裝置影像 SES 6

與基於核心的 iSCSI 閘道部署不同，基於 tcmu-runner 的 iSCSI 閘道不支援多重路

徑 I/O 或 SCSI 持續保留。

若要使用 tcmu-runner 輸出 RADOS 區塊裝置影像，您只需在連接磁碟時指定

user:rbd 後備儲存即可：

gwcli > /disks> attach rbd/testvol backstore=user:rbd

注意使用 tcmu-runner 時，輸出的 RBD 影像必須啟用 exclusive-lock 功能。

114 使用 tcmu-runner 輸出 RADOS 區塊裝置影像 SES 6

11 安裝 CephFS

Ceph 檔案系統 (CephFS) 是符合 POSIX 標準的檔案系統，它使用 Ceph 儲存叢集來儲

存其資料。CephFS 使用與 Ceph 區塊裝置相同的叢集系統：Ceph 物件儲存及其 S3 和

Swift API 或原生結合 ( librados )。

若要使用 CephFS，需要一個正在執行的 Ceph 儲存叢集，並至少要有一部正在執行的

Ceph 中繼資料伺服器。

11.1 支援的 CephFS 情境和指導原則

憑藉 SUSE Enterprise Storage 6，SUSE 引入了對分散式縮放元件 CephFS 的眾多使

用情境的正式支援。本節介紹硬限制，並提供建議使用案例的指導原則。

支援的 CephFS 部署必須符合以下要求：

至少有一部中繼資料伺服器。SUSE 建議部署多個具有 MDS 角色的節點。其中只

有一個節點是主動節點，其餘節點都是被動節點。從用戶端掛接 CephFS 時，請記

得在 mount 指令中指定所有 MON 節點。

用戶端是使用 cephfs 核心模組驅動程式的 SUSE Linux Enterprise Server 12

SP3 (或更新版本) 或 SUSE Linux Enterprise Server 15 (或更新版本)。不支

援 FUSE 模組。

SUSE Enterprise Storage 6 中支援 CephFS 定額，且可對 Ceph 檔案系統的任

何子目錄設定此定額。定額可限制目錄階層中指定點下所儲存的位元組或檔案數。

如需詳細資訊，請參閱《管理指南》, 第 19 章「叢集檔案系統」, 第 19.6 節

「設定 CephFS 定額」。

CephFS 支援第 11.3.4 節「檔案配置」中所述的檔案配置變更。但是，儘管

檔案系統可由任何用戶端掛接，但無法將新資料池新增到現有的 CephFS 檔案系

統 ( ceph mds add_data_pool )。只能在檔案系統已卸載時新增這些池。

至少有一部中繼資料伺服器。SUSE 建議部署多個具有 MDS 角色的節點。依預

設，其他 MDS 精靈啟動時處於待命狀態，充當使用中 MDS 的後備。系統也支援多

個使用中 MDS 精靈 (請參閱第 11.3.2 節「MDS 叢集大小」)。

115 支援的 CephFS 情境和指導原則 SES 6

11.2 Ceph 中繼資料伺服器

Ceph 中繼資料伺服器 (MDS) 儲存 CephFS 的中繼資料。Ceph 區塊裝置和 Ceph 物

件儲存不使用 MDS。POSIX 檔案系統使用者可透過 MDS 執行基本指令 (例如 ls 或

find )，因而不會對 Ceph 儲存叢集施加巨大負擔。

11.2.1 新增中繼資料伺服器

您可以依據第 5.3 節「叢集部署」中所述，在啟始叢集部署期間部署 MDS；或者依

據《管理指南》, 第 2 章「Salt 叢集管理」, 第 2.1 節「新增新的叢集節點」中所

述，將 MDS 新增到已部署的叢集。

部署 MDS 後，請在部署 MDS 的伺服器的防火牆設定中允許 Ceph OSD/MDS 服務：啟動

yast，導覽至 Security and Users (安全性與使用者) Firewall (防火牆) Allowed

Services (允許的服務)，然後在 Service to Allow (要允許的服務) 下拉式功能表中

選取 Ceph OSD/MDS。如果不允許在 Ceph MDS 節點中傳送完整流量，則即使其他操作

可以正常進行，掛接檔案系統也會失敗。

11.2.2 設定中繼資料伺服器

您可以透過在 ceph.conf 組態檔案中插入相關的選項來微調 MDS 的行為。

中繼資料伺服器設定

mon force standby active

如果設為「true」(預設值)，監控程式會將 standby-replay 模式強制設為

active 模式。在 [mon] 或 [global] 區段下設定。

mds cache memory limit

MDS 將針對其快取強制執行軟記憶體限制 (以位元組數為單位)。管理員應使用此

項設定取代舊的 mds cache size 設定。預設設為 1 GB。

mds cache reservation

MDS 快取要維護的快取保留 (記憶體或 inode)。當 MDS 開始接近其保留大小

時，會撤銷用戶端狀態，直到其快取大小縮小至可還原保留為止。預設值為

0.05。

116 Ceph 中繼資料伺服器 SES 6

mds cache size

要快取的 Inode 數量。值為 0 (預設值) 表示數量不限。建議使用 mds cache

memory limit 來限制 MDS 快取使用的記憶體數量。

mds cache mid

新項目在快取 LRU 中的插入點 (從頂部插入)。預設值為 0.7。

mds dir commit ratio

觸發 Ceph 使用完整更新而非部分更新提交的改動目錄比率。預設值為 0.5。

mds dir max commit size

觸發 Ceph 將其分解為多個更小交易的目錄更新的大小上限。預設設為 90 MB。

mds decay halflife

MDS 快取溫度的半衰期。預設值為 5。

mds beacon interval

向監控程式傳送指標訊息的頻率 (以秒計)。預設值為 4。

mds beacon grace

從監控程式未收到指標到 Ceph 宣告 MDS 延隔並可能將其取代相隔的時間。預設

值為 15。

mds blacklist interval

在 OSD 地圖中將故障 MDS 列入黑名單的期間。此設定可控制故障 MDS 精靈保留

在 OSD 地圖黑名單中的時長，但無法控制管理員手動加入黑名單的項目的保留時

長。例如， ceph osd blacklist add 指令仍將使用預設黑名單時間。預設設為 24

* 60。

mds reconnect timeout

MDS 重新啟動期間等待用戶端重新連接的間隔 (以秒計)。預設值為 45。

mds tick interval

MDS 執行內部週期任務的頻率。預設值為 5。

mds dirstat min interval

嘗試避免在樹狀結構中向上傳播遞迴統計資料的最短間隔 (以秒計)。預設值為

1。

mds scatter nudge interval

dirstat 變更向上傳播的速度。預設值為 5。

117 設定中繼資料伺服器 SES 6

mds client prealloc inos

要為每個用戶端工作階段預先配置的 Inode 數量。預設值為 1000。

mds early reply

決定 MDS 是否應允許用戶端在提交到記錄前查看要求的結果。預設值為

「true」。

mds use tmap

對目錄更新使用一般地圖。預設值為「true」。

mds default dir hash

用於跨目錄片段對檔案進行雜湊處理的函數。預設設為 2 (即「rjenkins」)。

mds log skip corrupt events

決定在記錄重播期間，MDS 是否應嘗試跳過損毀的記錄事件。預設值為

「false」。

mds log max events

我們啟動修剪前記錄中的事件數上限。設為 -1 (預設值) 表示停用上限。

mds log max segments

我們啟動修剪前記錄中的區段 (物件) 數上限。設為 -1 表示停用上限。預設值

為 30。

mds log max expiring

同時過期的區段數上限。預設值為 20。

mds log eopen size

EOpen 事件中的 Inode 數上限。預設值為 100。

mds bal sample interval

決定目錄溫度的取樣頻率 (用於制定分區決策)。預設值為 3。

mds bal replicate threshold

觸發 Ceph 嘗試將中繼資料複製到其他節點的溫度上限。預設值為 8000。

mds bal unreplicate threshold

觸發 Ceph 停止將中繼資料複製到其他節點的溫度下限。預設值為 0。

mds bal split size

觸發 MDS 將目錄分區分割為更小位元的目錄大小上限。預設值為 10000。

mds bal split rd


觸發 Ceph 分割目錄分區的目錄讀取溫度上限。預設值為 25000。

mds bal split wr

觸發 Ceph 分割目錄分區的目錄寫入溫度上限。預設值為 10000。

mds bal split bits

將目錄分區分割成的位元數。預設值為 3。

mds bal merge size

觸發 Ceph 嘗試合併相鄰目錄分區的目錄大小下限。預設值為 50。

mds bal interval

在 MDS 之間交換工作負載的頻率 (以秒計)。預設值為 10。

mds bal fragment interval

從分區可分割或合併到執行分區變更之間的延遲時間 (以秒計)。預設值為 5。

mds bal fragment fast factor

指定分區可超出分割大小的比率，達到該比率後將跳過分區間隔，立即執行分

割。預設值為 1.5。

mds bal fragment size max

觸發因 ENOSPC 錯誤而拒絕所有新項目的分區大小上限。預設值為 100000。

mds bal idle threshold

觸發 Ceph 將子樹狀結構移轉回其父項的溫度下限。預設值為 0。

mds bal mode

計算 MDS 負載的方法：

0 = 混合式。

1 = 要求率和延遲。

2 = CPU 負載。

預設值為 0。

mds bal min rebalance

觸發 Ceph 移轉的子樹狀結構溫度下限。預設值為 0.1。

mds bal min start

觸發 Ceph 搜尋子樹狀結構的子樹狀結構溫度下限。預設值為 0.2。


mds bal need min

可接受的目標子樹狀結構大小比率下限。預設值為 0.8。

mds bal need max

可接受的目標子樹狀結構大小比率上限。預設值為 1.2。

mds bal midchunk

Ceph 將移轉任何超過此目標子樹狀結構大小比率的子樹狀結構。預設值為 0.3。

mds bal minchunk

Ceph 將忽略任何小於此目標子樹狀結構大小比率的子樹狀結構。預設值為

0.001。

mds bal target removal min

觸發 Ceph 從 MDS 地圖中移除舊 MDS 目標的平衡器反覆項目數下限。預設值為

5。

mds bal target removal max

觸發 Ceph 從 MDS 地圖中移除舊 MDS 目標的平衡器反覆項目數上限。預設值為

10。

mds replay interval

處於 standby-replay 模式 (「熱待命」) 時的記錄輪詢間隔。預設值為 1。

mds shutdown check

MDS 關閉期間輪詢快取的間隔。預設值為 0。

mds thrash fragments

Ceph 會將目錄隨機分區或合併。預設值為 0。

mds dump cache on map

Ceph 會將 MDS 快取內容傾印到每個 MDS 地圖上的某個檔案中。預設值為

「false」。

mds dump cache after rejoin

復原期間重新加入快取後，Ceph 會將 MDS 快取內容傾印到檔案中。預設值為

「false」。

mds standby for name

此設定中以名稱指定的 MDS 精靈將存在一個待命 MDS 精靈。

mds standby for rank


具有此階層的 MDS 精靈將存在一個待命 MDS 精靈。預設值為 -1。

mds standby replay

決定 Ceph MDS 精靈是否應輪詢並重播使用中 MDS 的記錄(「熱待命」)。預設值

為「false」。

mds min caps per client

設定一個用戶端可具有的最小功能數。預設值為 100。

mds max ratio caps per client

設定處於 MDS 快取壓力期間，可重新呼叫的目前功能的最大比率。預設值為

0.8。

中繼資料伺服器記錄程式設定

journaler write head interval

更新記錄標題物件的頻率。預設值為 15。

journaler prefetch periods

記錄重播前讀取的分割週期數。預設值為 10。

journal prezero periods

寫入位置前置零的分割週期數。預設值為 10。

journaler batch interval

人為導致的最大額外延遲時間 (以秒計)。預設值為 0.001。

journaler batch max

一次延遲衝洗的最大位元組數。預設值為 0。

11.3 CephFS部署至少包含一部 Ceph 中繼資料伺服器的正常 Ceph 儲存叢集後，可以建立並掛接

Ceph 檔案系統。請確定用戶端可連接到網路，並具有正確的驗證金鑰圈。

11.3.1 建立 CephFS

CephFS 至少需要兩個 RADOS 池：一個用於儲存資料，另一個用於儲存中繼資料。設定

這些池時，可以考慮：

121 CephFS SES 6

對中繼資料池使用較高的複製層級，因為丟失此池中的任何資料都可能會導致整

個檔案系統無法存取。

對中繼資料池使用延遲較低的儲存，例如 SSD，因為在用戶端上執行檔案系統操

作時，這樣可以改善使用者可發現的延遲。

在 policy.cfg 中指定 role-mds 時，會自動建立所需的池。在設定中繼資料伺服器之

前，您可以手動建立池 cephfs_data 和 cephfs_metadata，以手動調整效能。如果這

些池已存在，DeepSea 將不會建立它們。

如需管理池的詳細資訊，請參閱《管理指南》, 第 11 章「管理儲存池」。

若要使用預設設定建立兩個需要用於 CephFS 的池 (例如「cephfs_data」和

「cephfs_metadata」)，請執行以下指令：

cephadm@adm > ceph osd pool create cephfs_data pg_numcephadm@adm > ceph osd pool create cephfs_metadata pg_num

您可以使用 EC 池取代複本池。建議您僅針對低效能要求和不經常發生的隨機存取

(例如冷儲存、備份和歸檔) 使用 EC 池。EC 池中的 CephFS 關係企業，並且必須

為池設定 allow_ec_overwrite 選項。您可以透過執行 ceph osd pool set ec_pool

allow_ec_overwrites true 來設定此選項。

糾刪碼會顯著增加檔案系統操作的負擔，尤其是執行小規模更新時。使用糾刪碼做為容

錯機制必然會產生這種負擔。這一代價與顯著減小的儲存空間相互抵銷。

建立池時，您可以使用 ceph fs new 指令來啟用檔案系統：

cephadm@adm > ceph fs new fs_name metadata_pool_name data_pool_name

例如：

cephadm@adm > ceph fs new cephfs cephfs_metadata cephfs_data

您可以透過列出所有可用的 CephFS 來檢查是否已建立檔案系統：

cephadm@adm > ceph fs ls name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]

建立檔案系統後，MDS 將能夠進入使用中狀態。例如，在單一 MDS 系統中：

cephadm@adm > ceph mds state5: 1/1/1 up

122 建立 CephFS SES 6

提示：更多主題您可以在《管理指南》, 第 19 章「叢集檔案系統」中找到特定任務 (例如掛

接、卸載和進階 CephFS 設定) 的更多資訊。

11.3.2 MDS 叢集大小

一個 CephFS 例項可由多個使用中 MDS 精靈提供支援。指定給 CephFS 例項的所有使

用中 MDS 精靈將在彼此之間分發檔案系統的目錄樹，以此來分散並行用戶端的負載。

若要為 CephFS 例項新增使用中 MDS 精靈，需要一個備用待命精靈。請啟動其他精靈

或使用現有待命例項。

以下指令將顯示目前主動和被動 MDS 精靈的數量。

cephadm@adm > ceph mds stat

以下指令在檔案系統例項中將使用中 MDS 的數量設定為兩個。

cephadm@adm > ceph fs set fs_name max_mds 2

若要在更新前縮小 MDS 叢集，需要執行以下兩個步驟。首先，將 max_mds 設定為只保

留一個例項：

cephadm@adm > ceph fs set fs_name max_mds 1

然後明確停用另一個使用中 MDS 精靈：

cephadm@adm > ceph mds deactivate fs_name:rank

其中 rank 為檔案系統例項的使用中 MDS 精靈的數量，範圍介於 0 到 max_mds -1 之

間。

我們建議至少保留一個 MDS 做為待命精靈。

11.3.3 MDS 叢集和更新

在 Ceph 更新期間，檔案系統例項上的功能旗標可能會發生變化 (通常在新增新功能

時發生)。不相容的精靈 (例如舊版本) 無法與不相容的功能集搭配使用，並將拒絕啟

動。這意味著更新並重新啟動一個精靈可能會導致尚未更新的其他所有精靈都將停止並

拒絕啟動。出於此原因，我們建議將使用中 MDS 叢集縮減為僅包含一個例項，並在更

新 Ceph 之前停止所有待命精靈。此更新程序的手動步驟如下所述：

123 MDS 叢集大小 SES 6

1. 使用 zypper 更新 Ceph 相關的套件。

2. 依上述說明將使用中 MDS 叢集縮減至一個例項，並在所有其他節點上使用所有待

命 MDS 精靈的 systemd 單位將它們停止：

cephadm@mds > systemctl stop ceph-mds\*.service ceph-mds.target

3. 然後再重新啟動其餘一個 MDS 精靈，以便使用更新的二進位檔案將其重新啟動。

cephadm@mds > systemctl restart ceph-mds\*.service ceph-mds.target

4. 重新啟動所有其他 MDS 精靈，並重設所需的 max_mds 設定。

cephadm@mds > systemctl start ceph-mds.target

如果您使用 DeepSea，則在階段 0 和 4 中更新 ceph 套件時，它會遵循此程序。當

用戶端掛接 CephFS 例項並且正在進行 I/O 操作時，可能會執行此程序。不過請注

意，當使用中 MDS 重新啟動時，會有一個短暫的 I/O 暫停。用戶端將自動復原。

最好在更新 MDS 叢集之前盡可能減少 I/O 負載。如此閒置的 MDS 叢集將能更快地完

成此更新。反之，在一個負載較重且具有多個 MDS 精靈的叢集上，必須預先減少負載

以防止進行中的 I/O 超出單一 MDS 精靈的負載能力。

11.3.4 檔案配置

檔案的配置可控制其內容對應至 Ceph RADOS 物件的方式。您可以使用虛擬延伸屬性或

xattrs 短暫讀取和寫入檔案的配置。

配置 xattrs 的名稱取決於檔案是一般檔案還是目錄。一般檔案的配置 xattrs 名

為 ceph.file.layout，而目錄的配置 xattrs 名為 ceph.dir.layout。範例中將使用

ceph.file.layout 名稱，處理目錄時則相應地以 .dir. 部分取代。

11.3.4.1 配置欄位

系統可識別下列屬性欄位：

pool

將在其中儲存檔案資料物件的 RADOS 池的 ID 或名稱。

124 檔案配置 SES 6

pool_namespace

資料池內物件將寫入其中的 RADOS 名稱空間。預設為空白，表示使用預設名稱空

間。

stripe_unit

在檔案的 RAID 0 分佈中使用的資料區塊大小 (以位元組計)。檔案的所有分割單

位大小都相同。最後一個分割單位通常不完整，它代表檔案末尾的資料，以及檔

案末尾至固定大小的分割單位末端未使用的「空間」。

stripe_count

構成檔案資料的 RAID 0「分割」的連續分割單位數量。

object_size

用於儲存檔案資料區塊的 RADOS 物件的大小 (以位元組計)。

提示：物件大小RADOS 會強制施加一個可設定的物件大小上限。如果您將 CephFS

物件大小增加到超出該上限的值，則寫入將失敗。OSD 設定為

osd_max_object_size，預設值為 128 MB。RADOS 物件太大可能會妨礙叢集

順利運作，因此不建議將物件大小上限指定為超出預設值的數值。

11.3.4.2 使用 getfattr 讀取配置

使用 getfattr 指令可讀取範例檔案 file 的配置資訊，並將其輸出為單個字串：

root # touch fileroot # getfattr -n ceph.file.layout file# file: fileceph.file.layout="stripe_unit=4194304 stripe_count=1 object_size=419430

讀取個別配置欄位：

root # getfattr -n ceph.file.layout.pool file# file: fileceph.file.layout.pool="cephfs_data"root # getfattr -n ceph.file.layout.stripe_unit file# file: fileceph.file.layout.stripe_unit="4194304"


提示：池 ID 或名稱讀取配置時，通常使用名稱指示池。但在極少數情況下，當剛剛建立池時，可能

會輸出 ID 而非名稱。

目錄沒有明確配置，除非對其進行了自訂。如果從未修改過配置，則嘗試讀取配置的操

作將失敗：這表示系統將使用具有明確配置的上一層目錄的配置。

root # mkdir dirroot # getfattr -n ceph.dir.layout dirdir: ceph.dir.layout: No such attributeroot # setfattr -n ceph.dir.layout.stripe_count -v 2 dirroot # getfattr -n ceph.dir.layout dir# file: dirceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 pool=cephfs_data"

11.3.4.3 使用 setfattr 寫入配置

使用 setfattr 指令可修改範例檔案 file 的配置欄位：

cephadm@adm > ceph osd lspools0 rbd1 cephfs_data2 cephfs_metadataroot # setfattr -n ceph.file.layout.stripe_unit -v 1048576 fileroot # setfattr -n ceph.file.layout.stripe_count -v 8 file# Setting pool by ID:root # setfattr -n ceph.file.layout.pool -v 1 file# Setting pool by name:root # setfattr -n ceph.file.layout.pool -v cephfs_data file

注意：清空檔案使用 setfattr 修改檔案的配置欄位時，需要清空此檔案，否則會發生錯誤。

11.3.4.4 清空配置

如果您要從範例目錄 mydir 中移除明確配置，並回復為繼承上一層目錄的配置，請執

行以下指令：


root # setfattr -x ceph.dir.layout mydir

同樣，如果您設定了「pool_namespace」屬性，現在希望修改配置以轉為使用預設名稱

空間，請執行以下指令：

# Create a directory and set a namespace on itroot # mkdir mydirroot # setfattr -n ceph.dir.layout.pool_namespace -v foons mydirroot # getfattr -n ceph.dir.layout mydirceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \ pool=cephfs_data_a pool_namespace=foons"

# Clear the namespace from the directory's layoutroot # setfattr -x ceph.dir.layout.pool_namespace mydirroot # getfattr -n ceph.dir.layout mydirceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \ pool=cephfs_data_a"

11.3.4.5 配置的繼承

檔案在建立時會繼承其父目錄的配置。但在此之後，對父目錄配置所做的變更不會影響

其子項：

root # getfattr -n ceph.dir.layout dir# file: dirceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data"

# file1 inherits its parent's layoutroot # touch dir/file1root # getfattr -n ceph.file.layout dir/file1# file: dir/file1ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data"

# update the layout of the directory before creating a second fileroot # setfattr -n ceph.dir.layout.stripe_count -v 4 dirroot # touch dir/file2

# file1's layout is unchangedroot # getfattr -n ceph.file.layout dir/file1# file: dir/file1ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data"

# ...while file2 has the parent directory's new layoutroot # getfattr -n ceph.file.layout dir/file2# file: dir/file2


ceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"

如果未為中間目錄設定配置，則所建立做為目錄後代的檔案也將繼承目錄的配置：

root # getfattr -n ceph.dir.layout dir# file: dirceph.dir.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"root # mkdir dir/childdirroot # getfattr -n ceph.dir.layout dir/childdirdir/childdir: ceph.dir.layout: No such attributeroot # touch dir/childdir/grandchildroot # getfattr -n ceph.file.layout dir/childdir/grandchild# file: dir/childdir/grandchildceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"

11.3.4.6 將資料池新增至中繼資料伺服器

若要對 CephFS 使用池，需要先將池新增至中繼資料伺服器：

cephadm@adm > ceph fs add_data_pool cephfs cephfs_data_ssdcephadm@adm > ceph fs ls # Pool should now show up.... data pools: [cephfs_data cephfs_data_ssd ]

提示：cephx 金鑰請確定您的 cephx 金鑰允許用戶端存取此新池。

然後，您可以在 CephFS 中更新目錄的配置，以使用您新增的池：

root # mkdir /mnt/cephfs/myssddirroot # setfattr -n ceph.dir.layout.pool -v cephfs_data_ssd /mnt/cephfs/myssddir

所有在該目錄中建立的新檔案現在都將繼承該目錄的配置，並會將其資料存放到新增的

池中。您可能會發現主要資料池中的物件數量會持續增加，即使檔案是在您剛才新增的

池中建立的也是如此。這是正常現象：檔案資料會儲存到配置所指定的池中，但仍會在

主要資料池中為所有檔案儲存少量中繼資料。


12 安裝 NFS Ganesha

使用 NFS Ganesha 可透過 NFS 存取物件閘道或 CephFS。SUSE Enterprise Storage 6

支援 NFS 版本 3 和 4。NFS Ganesha 在使用者空間而不是核心空間中執行，直接與物

件閘道或 CephFS 互動。

警告：跨通訊協定存取原生 CephFS 和 NFS 用戶端不受透過 Samba 獲取的檔案鎖定限制，反之亦然。

如果透過其他方式存取 CephFS 支援的 Samba 共用路徑，則依賴跨通訊協定檔

案鎖定的應用程式可能會出現資料損毀。

12.1 準備

12.1.1 一般資訊

若要成功部署 NFS Ganesha，需要將 role-ganesha 新增到 /srv/pillar/ceph/

proposals/policy.cfg。如需詳細資料，請參閱第 5.5.1 節「policy.cfg 檔案」。若

要使用 NFS Ganesha，還需要在 policy.cfg 中指定 role-rgw 或 role-mds。

儘管可以在現有的 Ceph 節點上安裝並執行 NFS Ganesha 伺服器，但還是建議您在能

夠存取 Ceph 叢集的專屬主機上執行該伺服器。用戶端主機一般不是叢集的一部分，但

需要能夠透過網路存取 NFS Ganesha 伺服器。

若要在完成啟始安裝後隨時啟用 NFS Ganesha 伺服器，請將 role-ganesha 新增至

policy.cfg，並至少重新執行 DeepSea 階段 2 和 4。如需詳細資料，請參閱第 5.3

節「叢集部署」。

NFS Ganesha 是透過 NFS Ganesha 節點上的 /etc/ganesha/ganesha.conf 檔案設定

的。但是，每次執行 DeepSea 階段 4，都會覆寫此檔案。因此，建議您編輯 Salt 使

用的範本，即 Salt Master 上的 /srv/salt/ceph/ganesha/files/ganesha.conf.j2 檔

案。如需組態檔案的詳細資料，請參閱《管理指南》, 第 21 章「NFS Ganesha：透過

NFS 輸出 Ceph 資料」, 第 21.2 節「組態」。

129 準備 SES 6

12.1.2 要求摘要

在執行 DeepSea 階段 2 和 4 來安裝 NFS Ganesha 之前，必須滿足以下要求：

至少為一個節點指定 role-ganesha。

對於每個 Minion，只能定義一個 role-ganesha。

NFS Ganesha 需要物件閘道或 CephFS 才能正常運作。

需要停用具有 role-ganesha 角色的 Minion 上基於核心的 NFS。

12.2 範例安裝此程序提供了一個範例安裝，該範例使用 NFS Ganesha 的物件閘道和 CephFS 檔案系

統抽象層 (FSAL)。

1. 先要執行 DeepSea 階段 0 和 1 (如果您尚未執行)，然後才能繼續執行此程序。


2. 執行 DeepSea 的階段 1 之後，編輯 /srv/pillar/ceph/proposals/policy.cfg 並

新增下行

role-ganesha/cluster/NODENAME

使用叢集中某個節點的名稱取代 NODENAME。

另外，請確定已指定 role-mds 和 role-rgw。

3. 至少執行 DeepSea 的階段 2 和 4。建議執行中間的階段 3。

root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.3 # optional but recommendedroot@master # salt-run state.orch ceph.stage.4

4. 透過檢查 Minion 節點上是否正在執行 NFS Ganesha 服務，以確認 NFS Ganesha

是否在運作：

root@master # salt -I roles:ganesha service.status nfs-ganeshaMINION_ID: True

130 要求摘要 SES 6

12.3 高可用性主動-被動組態

本節提供一個範例來展示如何設定 NFS Ganesha 伺服器的雙節點主動-被動組態。該設

定需要 SUSE Linux Enterprise High Availability Extension。兩個節點分別名為

earth 和 mars。

重要：服務共置自身具有容錯和負載平衡能力的服務不應在已圍籬區隔以執行容錯移轉服務的叢

集節點上執行。因此，請勿在高可用性設定中執行 Ceph 監控程式、中繼資料伺

服器、iSCSI 或 Ceph OSD 服務。

如需 SUSE Linux Enterprise High Availability Extension 的詳細資料，請參閱

https://www.suse.com/documentation/sle-ha-15/ 。

12.3.1 基本安裝

在此設定中， earth 的 IP 位址為 192.168.1.1， mars 的位址為 192.168.1.2。

此外，使用兩個浮動的虛擬 IP 位址，可讓用戶端都可連接到服務，而不管該服務在哪

個實體節點上執行。 192.168.1.10 用於透過 Hawk2 進行叢集管理， 192.168.2.1 專門

用於 NFS 輸出。如此可讓日後能更輕鬆地套用安全性限制。

以下程序說明範例安裝。https://www.suse.com/documentation/sle-ha-15/

book_sleha_quickstarts/data/art_sleha_install_quick.html 上提供了更多詳細

資料。

1. 在 Salt Master 上準備 NFS Ganesha 節點：

a. 執行 DeepSea 階段 0 和 1。


b. 在 /srv/pillar/ceph/proposals/policy.cfg 中為節點 earth 和 mars 指定

role-ganesha：

role-ganesha/cluster/earth*.sls

131 高可用性主動-被動組態 SES 6

https://www.suse.com/documentation/sle-ha-15/



role-ganesha/cluster/mars*.sls

c. 執行 DeepSea 階段 2 到 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

2. 在 earth 和 mars 上註冊 SUSE Linux Enterprise High Availability

Extension。

root # SUSEConnect -r ACTIVATION_CODE -e E_MAIL

3. 在兩個節點上安裝 ha-cluster-bootstrap ：

root # zypper in ha-cluster-bootstrap

4. a. 在 earth 上啟始化叢集：

root@earth # ha-cluster-init

b. 讓 mars 加入該叢集：

root@mars # ha-cluster-join -c earth

5. 檢查叢集的狀態。您應該會看到兩個節點都已新增到叢集中：

root@earth # crm status

6. 在這兩個節點上，停用開機時自動啟動 NFS Ganesha 服務的功能：

root # systemctl disable nfs-ganesha

7. 在 earth 上啟動 crm 外圍程序：

root@earth # crm configure

後續指令在 crm 外圍程序中執行。

8. 在 earth 上，執行 crm 外圍程序來執行以下指令，以便將 NFS Ganesha 精靈的

資源設定為 systemd 資源類型的複製：

crm(live)configure# primitive nfs-ganesha-server systemd:nfs-ganesha \op monitor interval=30scrm(live)configure# clone nfs-ganesha-clone nfs-ganesha-server meta interleave=true

132 基本安裝 SES 6

crm(live)configure# commitcrm(live)configure# status 2 nodes configured 2 resources configured

Online: [ earth mars ]

Full list of resources: Clone Set: nfs-ganesha-clone [nfs-ganesha-server] Started: [ earth mars ]

9. 使用 crm 外圍程序建立一個原始 IPAddr2：

crm(live)configure# primitive ganesha-ip IPaddr2 \params ip=192.168.2.1 cidr_netmask=24 nic=eth0 \op monitor interval=10 timeout=20

crm(live)# statusOnline: [ earth mars ]Full list of resources: Clone Set: nfs-ganesha-clone [nfs-ganesha-server] Started: [ earth mars ] ganesha-ip (ocf::heartbeat:IPaddr2): Started earth

10. 為了在 NFS Ganesha 伺服器與浮動虛擬 IP 之間建立關係，我們使用了併置和順

序約束。

crm(live)configure# colocation ganesha-ip-with-nfs-ganesha-server inf: ganesha-ip nfs-ganesha-clonecrm(live)configure# order ganesha-ip-after-nfs-ganesha-server Mandatory: nfs-ganesha-clone ganesha-ip

11. 從用戶端使用 mount 指令，以確定完成叢集設定：

root # mount -t nfs -v -o sync,nfsvers=4 192.168.2.1:/ /mnt

12.3.2 清理資源

如果其中一個節點 (例如 earth ) 上發生 NFS Ganesha 故障，請解決問題並清理資

源。如果 NFS Ganesha 在 mars 上發生故障，則只有在清理資源之後，該資源才能錯

誤回復至 earth。

若要清理資源，請執行以下指令：

root@earth # crm resource cleanup nfs-ganesha-clone earth

133 清理資源 SES 6

root@earth # crm resource cleanup ganesha-ip earth

12.3.3 設定 Ping 資源

有時，伺服器可能由於網路問題而無法連接用戶端。Ping 資源可以偵測並緩解此問

題。設定此資源的操作是選擇性的。

1. 定義 ping 資源：

crm(live)configure# primitive ganesha-ping ocf:pacemaker:ping \ params name=ping dampen=3s multiplier=100 host_list="CLIENT1 CLIENT2" \ op monitor interval=60 timeout=60 \ op start interval=0 timeout=60 \ op stop interval=0 timeout=60

host_list 是以空格字元分隔的 IP 位址清單。系統將會定期 ping 這些 IP 位

址，以檢查網路中斷問題。如果某個用戶端必須永遠能夠存取 NFS 伺服器，請將

該用戶端新增到 host_list。

2. 建立複製：

crm(live)configure# clone ganesha-ping-clone ganesha-ping \ meta interleave=true

3. 以下指令會建立 NFS Ganesha 服務的約束。當 host_list 不可存取時，此約束

會強制服務轉移到另一節點。

crm(live)configure# location nfs-ganesha-server-with-ganesha-ping nfs-ganesha-clone \ rule -inf: not_defined ping or ping lte 0

12.3.4 NFS Ganesha HA 和 DeepSea

DeepSea 不支援設定 NFS Ganesha HA。為了防止在設定 NFS Ganesha HA 之後

DeepSea 失敗，請從 DeepSea 階段 4 中排除 NFS Ganesha 服務的啟動和停止：

1. 將 /srv/salt/ceph/ganesha/default.sls 複製到 /srv/salt/ceph/ganesha/

ha.sls。

2. 從 /srv/salt/ceph/ganesha/ha.sls 中移除 .service 項目，如下所示：

134 設定 Ping 資源 SES 6

include:- .keyring- .install- .configure

3. 將下行新增到 /srv/pillar/ceph/stack/global.yml：

ganesha_init: ha

12.4 主動-主動組態本節提供簡單的主動-主動 NFS Ganesha 設定範例。該範例的目標是部署兩部放置在同

一現有 CephFS 上的 NFS Ganesha 伺服器。伺服器是兩個具有不同位址的 Ceph 叢集

節點。需要在這兩個節點之間手動分佈用戶端。此組態中的「容錯移轉」指的是在用戶

端上手動卸載並重新掛接另一部伺服器。

12.4.1 先決條件

對於該範例組態，您需要擁有以下資源：

執行中的 Ceph 叢集。如需使用 DeepSea 部署和設定 Ceph 叢集的詳細資料，請

參閱第 5.3 節「叢集部署」。

至少有一個設定好的 CephFS。如需部署和設定 CephFS 的更多詳細資料，請參

閱第 11 章「安裝 CephFS」。

兩個部署了 NFS Ganesha 的 Ceph 叢集節點。如需部署 NFS Ganesha 的更多詳

細資料，請參閱第 12 章「安裝 NFS Ganesha」。

提示：使用專屬伺服器儘管 NFS Ganesha 節點可與其他 Ceph 相關服務共用資源，我們仍建議使

用專屬伺服器，以便提升效能。

部署 NFS Ganesha 節點之後，請確認叢集是否可運作，並且存在預設的 CephFS 池：

cephadm@adm > rados lspoolscephfs_data

135 主動-主動組態 SES 6

cephfs_metadata

12.4.2 設定 NFS Ganesha

檢查兩個 NFS Ganesha 節點是否安裝了檔案 /etc/ganesha/ganesha.conf。將以下區塊

(如果尚未存在) 新增至組態檔案中，以便將 RADOS 做為 NFS Ganesha 的復原後端。

NFS_CORE_PARAM{ Enable_NLM = false; Enable_RQUOTA = false; Protocols = 4;}NFSv4{ RecoveryBackend = rados_cluster; Minor_Versions = 1,2;}CACHEINODE { Dir_Chunk = 0; NParts = 1; Cache_Size = 1;}RADOS_KV{ pool = "rados_pool"; namespace = "pool_namespace"; nodeid = "fqdn" UserId = "cephx_user_id"; Ceph_Conf = "path_to_ceph.conf"}

您可以檢查組態格式如下的現有行，以確定 rados_pool 和 pool_namespace 的值：

%url rados://rados_pool/pool_namespace/...

nodeid 選項的值對應至機器的 FQDN，並且可在現有的 RADOS_URLS 區塊中找到

UserId 和 Ceph_Conf 選項值。

由於舊版 NFS 不允許我們透過將寬限期間提前來延長伺服器重新啟動程序，我們在早

於 4.2 的版本中停用了 NFS 選項。此外，我們還停用了大多數 NFS Ganesha 快取，

因為 Ceph 程式庫已經在使用激進快取模式。

「rados_cluster」復原後端將其資訊儲存在 RADOS 物件中。儘管資料量不大，我們仍

希望其高度可用。出於此目的，我們使用 CephFS 中繼資料池，並在其中宣告一個新的

「ganesha」名稱空間，使其不同於 CephFS 物件。

136 設定 NFS Ganesha SES 6

注意：叢集節點 ID兩個主機的大多數組態都是相同的，不過，各節點「RADOS_KV」區塊中的

nodeid 選項需要設定為不同的字串。NFS Ganesha 預設會將 nodeid 設定為節

點的主機名稱。

如果您需要使用主機名稱以外的其他固定值，可以在一個節點上設定 nodeid =

'a' (範例設定)，在另一個節點上設定 nodeid = 'b'。

12.4.3 填入叢集寬限資料庫

我們需要確認叢集中的所有節點都知道彼此的存在。透過在主機之間共用的 RADOS 物

件來實現此目的。NFS Ganesha 使用此物件傳達與寬限期間有關的目前狀態。

此 nfs-ganesha-rados-grace 套件包含一個用於查詢和操縱此資料庫的指令行工具。如

果至少有一個節點上未安裝該套件，請執行以下指令加以安裝：

root # zypper install nfs-ganesha-rados-grace

我們將使用該指令來建立資料庫並新增兩個 nodeid。在本範例中，兩個 NFS Ganesha

節點分別命名為 ses6min1.example.com 和 ses6min2.example.com。在其中一個 NFS

Ganesha 主機上執行以下指令：

cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min1.example.comcephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min2.example.comcephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganeshacur=1 rec=0======================================================ses6min1.example.com Eses6min2.example.com E

此指令會建立寬限資料庫，並將「ses6min1.example.com」和

「ses6min2.example.com」新增至該資料庫。最後一個指令可傾印目前狀態。新增的主

機一律視為將強制執行寬限期間，因此會為它們設定「E」旗標。「cur」和「rec」值

顯示目前版本編號和復原版本編號，我們透過這種方式來追蹤允許主機復原的內容以及

時間。

12.4.4 重新啟動 NFS Ganesha 服務

在兩個 NFS Ganesha 節點上，重新啟動相關服務：

137 填入叢集寬限資料庫 SES 6

root # systemctl restart nfs-ganesha.service

重新啟動服務後，檢查寬限資料庫：

cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganeshacur=3 rec=0======================================================ses6min1.example.comses6min2.example.com

注意：清除了「E」旗標請注意，兩個節點均已清除其「E」旗標，表示它們不再強制執行寬限期間，並

且現在處於正常操作模式。

12.4.5 結論

完成上述所有步驟之後，您可以掛接從這兩部 NFS Ganesha 伺服器中的任意一部輸出

的 NFS，並對它們執行一般的 NFS 操作。

我們的範例組態假設，如果這兩部 NFS Ganesha 伺服器中的其中一部變為停機狀態，

您將在 5 分鐘內手動將其重新啟動。5 分鐘後，中繼資料伺服器可能會取消 NFS

Ganesha 用戶端擁有的工作階段以及與其關聯的所有狀態。如果在叢集的其餘節點進入

寬限期間之前取消該工作階段的功能，伺服器的用戶端可能無法復原其所有狀態。

12.5 更多資訊

如需詳細資訊，請參閱《管理指南》, 第 21 章「NFS Ganesha：透過 NFS 輸出 Ceph

資料」。

138 結論 SES 6

IV 以 SUSE CaaS Platform 4 為基

礎的叢集部署 (技術預覽)

13 在 SUSE CaaS Platform 4 Kubernetes 叢集上部署的 SUSE

Enterprise Storage 6 140

13 在 SUSE CaaS Platform 4 Kubernetes 叢

集上部署的 SUSE Enterprise Storage 6

警告：技術預覽在 SUSE CaaS Platform 上執行容器化 Ceph 叢集是一項技術預覽功能。請不要

在生產 Kubernetes 叢集上部署。

本章介紹如何在 SUSE CaaS Platform 4 Kubernetes 叢集上部署容器化 SUSE

Enterprise Storage 6。

13.1 考量事項

開始部署前，請考慮以下事項：

若要在 Kubernetes 中執行 Ceph，SUSE Enterprise Storage 6 會使用名為

Rook 的上游專案 (https://rook.io/ )。

Rook 可能會佔用 Kubernetes 叢集中所有節點的全部未使用磁碟，具體視組態而

定。

該設定需要特權容器。

13.2 先決條件

開始部署前，您需要具有以下資源：

執行中的 SUSE CaaS Platform 4 叢集。

連接了一些額外磁碟做為 Ceph 叢集儲存的 SUSE CaaS Platform 4 工作節點。

140 考量事項 SES 6

https://rook.io/

13.3 獲取 Rook 資訊清單Rook 協調器使用稱為資訊清單的 YAML 格式組態檔案。您所需的資訊清單包含在

rook-k8s-yaml RPM 套件中。可透過執行以下指令來安裝該套件：

root # zypper install rook-k8s-yaml

13.4 安裝Rook-Ceph 包含兩個主要元件：由 Kubernetes 執行且可用於建立 Ceph 叢集的「操作

者」，以及 Ceph「叢集」自身，由操作者建立並管理它的一部分。

13.4.1 組態

13.4.1.1 全域組態

此設定中使用的資訊清單會將所有 Rook 和 Ceph 元件都安裝在「rook-ceph」名稱空

間中。如果您需要變更該設定，請相應地將對該名稱空間的所有參考納入 Kubernetes

資訊清單。

依據您要使用的 Rook 功能，更改 common.yaml 中的「Pod 安全性規則」組態，以限

制 Rook 的安全性要求。依照資訊清單檔案中的備註操作。

13.4.1.2 操作者組態

資訊清單 operator.yaml 用於設定 Rook 操作者。通常情況下，您不需要進行變更。

如需詳細資訊，請參閱資訊清單檔案中的備註。

13.4.1.3 Ceph 叢集組態

資訊清單 cluster.yaml 負責設定將在 Kubernetes 中執行的實際的 Ceph 叢集。如需

所有可用選項的詳細描述，請參閱 https://rook.io/docs/rook/v1.0/ceph-cluster-

crd.html 中的上游 Rook 文件。

141 獲取 Rook 資訊清單 SES 6

https://rook.io/docs/rook/v1.0/ceph-cluster-crd.html

https://rook.io/docs/rook/v1.0/ceph-cluster-crd.html

Rook 預設設定為使用未透過 node-role.kubernetes.io/master:NoSchedule 污染的所

有節點，並將依照組態的放置設定執行 (請參閱 https://rook.io/docs/rook/v1.0/

ceph-cluster-crd.html#placement-configuration-settings )。下面的範例禁止此

類行為，並僅使用節點區段中明確列出的節點：

storage: useAllNodes: false nodes: - name: caasp4-worker-0 - name: caasp4-worker-1 - name: caasp4-worker-2

注意Rook 預設設定為使用每個節點上的所有可用和空的磁碟來做為 Ceph 儲存。

13.4.1.4 文件

Rook-Ceph 上游文件 (https://rook.github.io/docs/rook/master/ceph-

storage.html ) 包含有關設定更進階部署的更多詳細資訊。在進行更進階的組

態前，請參閱此文件以瞭解 Rook-Ceph 的基本知識。

如需 SUSE CaaS Platform 產品的更多詳細資料，請參閱 https://

www.suse.com/documentation/suse-caasp 。

13.4.2 建立 Rook 操作者

透過在 SUSE CaaS Platform 主節點上執行以下指令，安裝 Rook-Ceph 通用元件、CSI

角色和 Rook-Ceph 操作者：

root # kubectl apply -f common.yaml -f operator.yaml

common.yaml 將建立「rook-ceph」名稱空間、Ceph 自訂資源定義 (Custom Resource

Definitions，CRD) (請參閱 https://kubernetes.io/docs/concepts/extend-

kubernetes/api-extension/custom-resources/ )，以使 Kubernetes 可感知 Ceph

物件 (例如「CephCluster」)，以及 Rook 管理叢集特定資源所必需的 RBAC 角色

和 Pod 安全性規則 (請參閱 https://kubernetes.io/docs/concepts/policy/pod-

security-policy/ )。

142 建立 Rook 操作者 SES 6

https://rook.io/docs/rook/v1.0/ceph-cluster-crd.html#placement-configuration-settings

https://rook.io/docs/rook/v1.0/ceph-cluster-crd.html#placement-configuration-settings

https://rook.github.io/docs/rook/master/ceph-storage.html

https://rook.github.io/docs/rook/master/ceph-storage.html

https://www.suse.com/documentation/suse-caasp

https://www.suse.com/documentation/suse-caasp

https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/

https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/

https://kubernetes.io/docs/concepts/policy/pod-security-policy/

https://kubernetes.io/docs/concepts/policy/pod-security-policy/

提示：hostNetwork 和 hostPorts 的使用如果在叢集資源定義中使用 hostNetwork: true，則必須允許使用

hostNetwork。還需要在 PodSecurityPolicy 中允許使用 hostPorts。

透過在 SUSE CaaS Platform 主節點上執行 kubectl get pods -n rook-ceph 指令以確

認安裝，例如：

root # kubectl get pods -n rook-cephNAME READY STATUS RESTARTS AGErook-ceph-agent-57c9j 1/1 Running 0 22hrook-ceph-agent-b9j4x 1/1 Running 0 22hrook-ceph-operator-cf6fb96-lhbj7 1/1 Running 0 22hrook-discover-mb8gv 1/1 Running 0 22hrook-discover-tztz4 1/1 Running 0 22h

13.4.3 建立 Ceph 叢集

視需要修改 cluster.yaml 後，您便可建立 Ceph 叢集。在 SUSE CaaS Platform 主節

點上執行以下指令：

root # kubectl apply -f cluster.yaml

監看「rook-ceph」名稱空間以查看 Ceph 叢集的建立過程。您將看到 cluster.yaml

資訊清單中所設定數量的 Ceph 監控程式 (預設為 3)、一個 Ceph 管理員，以及與可

用磁碟數量一樣多的 Ceph OSD。

提示：暫存 OSD Pod在將 Ceph 叢集開機時，您會發現一些名為 rook-ceph-osd-prepare-NODE-NAME

的 Pod 在執行一段時間後會以「已完成」狀態終止。其名稱表明了這些 Pod 用

於佈建 Ceph OSD。系統不會將這些 Pod 刪除，而是將其保留下來，以便您可在

其終止後檢查其記錄。例如：

root # kubectl get pods --namespace rook-cephNAME READY STATUS RESTARTS AGErook-ceph-agent-57c9j 1/1 Running 0 22hrook-ceph-agent-b9j4x 1/1 Running 0 22hrook-ceph-mgr-a-6d48564b84-k7dft 1/1 Running 0 22hrook-ceph-mon-a-cc44b479-5qvdb 1/1 Running 0 22h

143 建立 Ceph 叢集 SES 6

rook-ceph-mon-b-6c6565ff48-gm9wz 1/1 Running 0 22hrook-ceph-operator-cf6fb96-lhbj7 1/1 Running 0 22hrook-ceph-osd-0-57bf997cbd-4wspg 1/1 Running 0 22hrook-ceph-osd-1-54cf468bf8-z8jhp 1/1 Running 0 22hrook-ceph-osd-prepare-caasp4-worker-0-f2tmw 0/2 Completed 0 9m35srook-ceph-osd-prepare-caasp4-worker-1-qsfhz 0/2 Completed 0 9m33srook-ceph-tools-76c7d559b6-64rkw 1/1 Running 0 22hrook-discover-mb8gv 1/1 Running 0 22hrook-discover-tztz4 1/1 Running 0 22h

13.5 使用 Rook 做為 Kubernetes 工作負載的

儲存

Rook 允許您使用三種不同類型的儲存：

物件儲存

物件儲存會向儲存叢集公開 S3 API，以供應用程式存放和獲取資料。如需詳細描

述，請參閱 https://rook.io/docs/rook/v1.0/ceph-object.html 。

共用檔案系統

可以使用讀取/寫入權限從多個 Pod 掛接共用檔案系統。這對於使用共用檔案系

統叢集化的應用程式非常有用。如需詳細描述，請參閱 https://rook.io/docs/

rook/v1.0/ceph-filesystem.html 。

區塊儲存

區塊儲存可讓您將儲存掛接到單個 Pod。如需詳細描述，請參閱 https://

rook.io/docs/rook/v1.0/ceph-block.html 。

13.6 解除安裝 Rook

若要解除安裝 Rook，請執行以下步驟：

1. 刪除任何佔用 Rook 儲存的 Kubernetes 應用程式。

2. 刪除您依照第 13.5 節「使用 Rook 做為 Kubernetes 工作負載的儲存」所述建

立的所有物件、檔案和/或區塊儲存產出工件。

144 使用 Rook 做為 Kubernetes 工作負載的儲存 SES 6

https://rook.io/docs/rook/v1.0/ceph-object.html

https://rook.io/docs/rook/v1.0/ceph-filesystem.html

https://rook.io/docs/rook/v1.0/ceph-filesystem.html

https://rook.io/docs/rook/v1.0/ceph-block.html

https://rook.io/docs/rook/v1.0/ceph-block.html

3. 刪除 Ceph 叢集、操作者和相關資源：

root # kubectl delete -f cluster.yamlroot # kubectl delete -f operator.yamlroot # kubectl delete -f common.yaml

4. 刪除主機上的資料：

root # rm -rf /var/lib/rook

5. 必要時，抹除 Rook 已使用的磁碟。如需更多詳細資料，請參閱 https://

rook.io/docs/rook/master/ceph-teardown.html 。

145 解除安裝 Rook SES 6

https://rook.io/docs/rook/master/ceph-teardown.html

https://rook.io/docs/rook/master/ceph-teardown.html

A 以上游「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 通知設為靜默模式。

146 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 章「Ceph 管理員模組」, 第 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 地圖。

149 SES 6

管理節點

用於執行 ceph-deploy 公用程式以在 OSD 節點上部署 Ceph 的節點。

節點

Ceph 叢集中的任何一部機器或伺服器。

規則集

用於確定池的資料放置的規則。

路由樹狀結構

該術語指的是展示接收器可執行的不同路由的任何圖表。

Ceph 特定術語

Alertmanager

用於處理 Prometheus 伺服器傳送的警示並通知最終使用者的單個二進位檔案。

Ceph 儲存叢集

用於儲存使用者資料的儲存軟體的核心集合。此類集合由 Ceph 監控程式和 OSD 組

成。

也稱為「Ceph 物件儲存」。

Grafana

資料庫分析和監控解決方案。

Prometheus

系統監控和警示工具套件。

物件閘道特定的術語

歸檔同步模組

允許建立物件閘道區域以保留 S3 物件版本歷程的模組。

150 SES 6

物件閘道

Ceph 物件儲存的 S3/Swift 閘道元件。

151 SES 6

B 文件更新

本章列出了自 SUSE Enterprise Storage 5 的最新維護更新發行以來，本文件內容

所發生的變更。您可以在 https://www.suse.com/documentation/suse-enterprise-

storage-5/book_storage_deployment/data/ap_deploy_docupdate.html 中找到適用

於先前版本的叢集部署的相關變更。

本文件在以下日期進行了更新：

第 B.1 節「SUSE Enterprise Storage 6 的維護更新文件」

第 B.2 節「2019 年 6 月 (SUSE Enterprise Storage 6 發行)」

B.1 SUSE Enterprise Storage 6 的維護更新

文件一般更新

在第 6.8 節「依節點升級 - 基本程序」中提供了執行 rpmconfigcheck 以防止

遺失本地變更的建議 (https://jira.suse.com/browse/SES-348 )。

新增了《管理指南》, 第 15 章「使用 LVM 快取提升效能」(https://

jira.suse.com/browse/SES-269 )。

新增了第 13 章「在 SUSE CaaS Platform 4 Kubernetes 叢集上部署的 SUSE

Enterprise Storage 6」(https://jira.suse.com/browse/SES-720 )。

錯誤修復

在第 6.9 節「升級管理節點」中新增了有關在升級期間監控叢集節點狀態的提

示 (https://bugzilla.suse.com/show_bug.cgi?id=1154568 )。

新增了第 6.8.2 節「使用 SUSE 套裝作業系統移轉系統升級節點」(https://

bugzilla.suse.com/show_bug.cgi?id=1154438 )。

循序排布了介紹升級的一章第 6 章「從舊版本升級」 (https://


152 SUSE Enterprise Storage 6 的維護更新文件 SES 6

https://www.suse.com/documentation/suse-enterprise-storage-5/book_storage_deployment/data/ap_deploy_docupdate.html

https://www.suse.com/documentation/suse-enterprise-storage-5/book_storage_deployment/data/ap_deploy_docupdate.html

https://jira.suse.com/browse/SES-348




https://bugzilla.suse.com/show_bug.cgi?id=1154568





針對 Ceph 14.2.4 新增了變更記錄項目 (https://bugzilla.suse.com/

show_bug.cgi?id=1151881 )。

統一了第 12 章「安裝 NFS Ganesha」中各範例中的池名稱

「cephfs_metadata」(https://bugzilla.suse.com/show_bug.cgi?

id=1148548 )。

更新了第 5.5.2.1 節「規格」，以包含更符合實際的值 (https://


在第 6.8.1 節「使用安裝程式 DVD 手動升級節點」中新增了兩個適用

於「Module-Desktop」的新儲存庫，因為我們的客戶大部分使用的是 GUI

(https://bugzilla.suse.com/show_bug.cgi?id=1144897 )。

deepsea-cli 不是 deepsea 的相依項 (在第 5.4 節「DeepSea CLI」中指出了

這一點) (https://bugzilla.suse.com/show_bug.cgi?id=1143602 )。

在第 6.1 節「升級前的注意事項」中新增了將 ntpd 移轉至 chronyd 的提示


新增了《管理指南》, 第 2 章「Salt 叢集管理」, 第 2.15 節「停用調整後的

設定檔」(https://bugzilla.suse.com/show_bug.cgi?id=1130430 )。

在第 6.16.3 節「OSD 部署」中建議移轉整個 OSD 節點 (https://


在第 6.1 節「升級前的注意事項」中新增了有關移轉 MDS 名稱的要點


B.2 2019 年 6 月 (SUSE Enterprise Storage

6 發行)一般更新

新增了第 5.5.2 節「DriveGroups」(jsc#SES-548)。

重新撰寫了第 6 章「從舊版本升級」 (jsc#SES-88)。

新增了第 7.2.1 節「為 Ceph 叢集部署啟用 IPv6」(jsc#SES-409)。

153 2019 年 6 月 (SUSE Enterprise Storage 6 發行) SES 6














將區塊儲存做為預設儲存後端 (Fate#325658)。

移除了對外部線上文件的所有參考，並以相關內容取代了這些參考

(Fate#320121)。

錯誤修復

在第 6.1 節「升級前的注意事項」中新增了有關升級期間的 AppArmor 的資訊


在第 6.1 節「升級前的注意事項」中新增了有關不支援線上升級的 CDTB 叢集

的資訊 (https://bugzilla.suse.com/show_bug.cgi?id=1129108 )。

在第 12.3 節「高可用性主動-被動組態」中新增了有關高可用性設定中 Ceph

服務共置的資訊 (https://bugzilla.suse.com/show_bug.cgi?id=1136871 )。

在第 6.8 節「依節點升級 - 基本程序」中新增了有關孤立套件的提示


在提示：在未定義 OSD 設定檔的情況下部署監控程式節點中使用 role-

storage 更新了 profile-* (https://bugzilla.suse.com/show_bug.cgi?

id=1138181 )。

新增了第 6.16 節「從以設定檔為基礎的部署移轉至 DriveGroups」(https://


新增了第 6.11 節「升級中繼資料伺服器」(https://bugzilla.suse.com/

show_bug.cgi?id=1135064 )。

在第 6.1 節「升級前的注意事項」中指出需要縮減 MDS 叢集 (https://


將組態檔案變更為 /srv/pillar/ceph/stack/global.yml (https://


更新了《管理指南》, 第 20 章「透過 Samba 輸出 Ceph 資料」的許多部分


在第 5.3 節「叢集部署」中移除了 master_minion.sls (https://


提及了 deepsea-cli 套件 (在第 5.4 節「DeepSea CLI」中) (https://


154 2019 年 6 月 (SUSE Enterprise Storage 6 發行) SES 6




















部署指南 - SUSE Enterprise Storage 6...目錄關於本指南x I SUSE ENTERPRISE STORAGE 1 1...

Documents

Transcript of 部署指南 - SUSE Enterprise Storage 6...目錄關於本指南x I SUSE ENTERPRISE STORAGE 1 1...

部署指南 - SUSE Enterprise Storage 6...目錄 關於本指南x I SUSE ENTERPRISE STORAGE 1 1...

Documents

Transcript of 部署指南 - SUSE Enterprise Storage 6...目錄 關於本指南x I SUSE ENTERPRISE STORAGE 1 1...

部署指南 - SUSE Enterprise Storage 6...目錄關於本指南x I SUSE ENTERPRISE STORAGE 1 1...

Transcript of 部署指南 - SUSE Enterprise Storage 6...目錄關於本指南x I SUSE ENTERPRISE STORAGE 1 1...