1 SES 和 Ceph #
SUSE Enterprise Storage 是基於 Ceph 技術的分散式儲存系統，旨在提高延展性、可靠性和效能。Ceph 叢集可在通用網路 (例如乙太網路) 中的商用伺服器上執行。此類叢集可以順利地擴展至數千部伺服器 (下文稱為「節點」) 並擁有 PB 級的處理能力。與使用配置表來儲存和擷取資料的傳統系統相反，Ceph 使用決定性演算法來為資料配置儲存空間，且不採用任何集中式資訊結構。Ceph 的假設是，在儲存叢集中的硬體新增或移除屬於常例，而非例外情況。Ceph 叢集可將資料分發和重新分發、資料複製、故障偵測和復原等管理任務自動化。Ceph 既可自我修復，又可自我管理，因此降低了管理負荷和預算負擔。
本章提供 SUSE Enterprise Storage 7 的高階綜覽，並簡要介紹一些最重要的元件。
1.1 Ceph 特性 #
Ceph 環境具有以下特性：
- 可延展性
Ceph 可延伸至數千個節點，並可管理 PB 級的儲存。
- 商用硬體
無需特殊的硬體即可執行 Ceph 叢集。若需要詳細資料，請參閱第 2 章 「硬體要求和建議」
- 自我管理
Ceph 叢集可自我管理。新增、移除節點或節點發生故障時，叢集可自動重新分發資料。此外，它還能識別超載的磁碟。
- 無單一故障點
重要的資訊不會單獨儲存在叢集中的某個節點上。您可設定備援數量。
- 開放原始碼軟體
Ceph 是一套開放原始碼軟體解決方案，獨立於特定的硬體或廠商。
1.2 Ceph 核心元件 #
若要充分利用 Ceph 的強大功能，需要瞭解一些基本的元件和概念。本節介紹經常在其他章節中提及的 Ceph 的某些組成部分。
1.2.1 RADOS #
Ceph 的基本元件稱為 RADOS (可靠自主分散式物件儲存) 。該元件負責管理叢集中儲存的資料。Ceph 中的資料通常以物件的形式儲存。每個物件由識別碼和資料組成。
RADOS 提供以下方法來存取涉及許多使用案例的儲存物件：
- 物件閘道
物件閘道是 RADOS 物件儲存的 HTTP REST 閘道。使用該閘道可以直接存取 Ceph 叢集中儲存的物件。
- RADOS 區塊裝置
您可以如存取任何其他區塊裝置一樣，存取 RADOS 區塊裝置 (RBD)。例如，可將這些裝置與
libvirt組合使用，以實現虛擬化。- CephFS
Ceph 檔案系統是符合 POSIX 標準的檔案系統。
libradoslibrados是一個程式庫，可與許多程式設計語言搭配使用，以建立能夠直接與儲存叢集互動的應用程式。
librados 由物件閘道和 RBD 使用，而 CephFS
直接與 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 精靈：
- 管理節點
管理節點是執行相應指令來管理叢集的一種 Ceph 叢集節點。管理節點是 Ceph 叢集的中心點，因為它透過查詢叢集其餘節點的 Salt Minion 服務並提供指示來管理其餘節點。
- Ceph 監控程式
Ceph 監控程式 (通常縮寫為 MON) 節點負責維護有關叢集健康狀態、所有節點的地圖和資料分發規則的資訊 (請參閱第 1.2.2 節 「CRUSH」)。
如果發生故障或衝突，叢集中的 Ceph 監控程式節點會依據多數原則確定哪些資訊是正確的。為了構成有效的多數，建議您設定奇數數量的 Ceph 監控程式節點，並至少設定三個這樣的節點。
如果使用多個站點，應在奇數個站點之間分發 Ceph 監控程式節點。每個站點的 Ceph 監控程式節點數應滿足以下要求：當有一個站點發生故障時，50% 以上的 Ceph 監控程式節點仍保持正常執行。
- Ceph 管理員
Ceph 管理員會從整個叢集收集狀態資訊。Ceph 管理員精靈與 Ceph 監控程式精靈一同執行。它會提供附加的監控功能，並與外部監控和管理系統連接。它還包含其他服務。例如，Ceph Dashboard Web UI 與 Ceph 管理員在同一節點上執行。
Ceph 管理員不需要額外設定，只需確定它在執行即可。
- Ceph OSD
Ceph OSD 是一個精靈，負責處理屬於實體或邏輯儲存單位 (硬碟或分割區) 的物件儲存裝置。物件儲存裝置可以是實體磁碟/分割區，也可以是邏輯磁碟區。此外，該精靈還會處理資料複製，並在新增或移除節點後進行重新平衡。
Ceph OSD 精靈與監控程式精靈通訊，並為其提供其他 OSD 精靈的狀態。
若要使用 CephFS、物件閘道、NFS Ganesha 或 iSCSI 閘道，還需要其他節點：
- 中繼資料伺服器 (MDS)
CephFS 中繼資料儲存在自己的 RADOS 池中 (請參閱第 1.3.1 節 「池」)。中繼資料伺服器充當中繼資料的智慧型快取層，會視需要對存取進行序列化。如此，無需明確同步，即可允許許多用戶端進行並行存取。
- 物件閘道
物件閘道是 RADOS 物件儲存的 HTTP REST 閘道。它與 OpenStack Swift 和 Amazon S3 相容，具有自己的使用者管理功能。
- NFS Ganesha
使用 NFS Ganesha 可透過 NFS 存取物件閘道或 CephFS。該元件在使用者空間而不是核心空間中執行，直接與物件閘道或 CephFS 互動。
- iSCSI 閘道
iSCSI 是一種儲存網路通訊協定，可讓用戶端將 SCSI 指令傳送至遠端伺服器上的 SCSI 儲存裝置 (目標)。
- Samba 閘道
Samba 閘道提供對 CephFS 上所儲存資料的 Samba 存取途徑。
1.3 Ceph 儲存結構 #
1.3.1 池 #
Ceph 叢集中儲存的物件放置在池中。對外部環境而言，池代表叢集的邏輯分割區。對於每個池，可以定義一組規則，例如，每個物件必須有多少個複製項。池的標準組態稱為複本池。
池通常包含多個物件，但也可以將其設定為充當類似 RAID 5 的作用。在此組態中，物件連同其他編碼區塊一起儲存在區塊中。編碼區塊包含備援資訊。管理員可以定義資料和編碼區塊的數量。在此組態中，池稱為糾刪碼池或 EC 池。
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
監控程式節點。
儘管 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，以還原複製層級。
如果將包含新 OSD 的新節點新增到叢集，叢集地圖將會發生變更。然後，CRUSH 函數將傳回物件的不同位置。接收新位置的物件將被重新定位。此程序將平衡使用所有 OSD。
1.4 BlueStore #
從 SES 5 開始，系統使用 BlueStore 做為 Ceph 的新預設儲存後端。BlueStore 的效能優於 FileStore，具有全資料檢查總數及壓縮功能。
它可管理一至三部儲存裝置。在最簡單案例中，BlueStore 會使用一個主要儲存裝置。該裝置通常被分割為兩部分：
一個名為 BlueFS 的較小分割區，用於執行 RocksDB 所需的類似檔案系統的功能。
其餘部分通常是一個較大的分割區，佔用了裝置的剩餘空間。它直接由 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 裝置填滿，中繼資料將溢出至主要裝置，這會嚴重降低 OSD 的效能。
您可以使用 ceph daemon osd.ID perf
dump 指令來檢查 WAL/DB 分割區是否即將填滿及溢出。slow_used_bytes
值顯示即將溢出的資料數量：
cephuser@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 自身擁有大量線上文件。對於本手冊中未介紹的主題，請參閱 https://docs.ceph.com/en/octopus/。
由 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 套裝作業系統廠商對用戶端提供支援。