Ceph入門教程

夜尽天明bylaw發表於2024-05-14

是什麼？

Ceph 是儲存的未來；在傳統系統無法提供的領域，Ceph 的設計能夠表現出色。透過可擴充套件、智慧、可靠且高度可用的儲存軟體，利用您的資料做出更好的業務決策並實現卓越運營。 Ceph 支援物件、塊和檔案儲存，所有這些都在一個統一的儲存系統中。
憑藉 Ceph 的適應性，無論您的解決方案是在本地、公有云、私有云還是容器本機中，您的叢集都可以隨時支援您現在和將來的所有應用程式和資料儲存需求。

特點

  1. 可擴充套件性
    Ceph 能夠快速擴充套件，而無需其他解決方案所需的典型停機時間。使用先進的 CRUSH 演算法，Ceph 克服了所有可擴充套件性挑戰，引領了實現真正靈活、具有令人難以置信的彈性的大規模儲存的道路。停止依賴昂貴的、特定於供應商的硬體和鎖定合同。擺脫遺留限制。隨著業務規模的擴大，儲存叢集呈指數級增長。 Ceph 是一種可擴充套件、經濟高效的解決方案，可應對企業市場、學術機構等領域快速且不可預測的資料增長。

  2. 可靠性
    資料是不可替代的，因此儲存系統的可靠性和精細管理至關重要。使用 Ceph 實現安心； Ceph 具有自我管理和自我修復功能，可以在您意識到問題之前發現並糾正問題。在您的儲存叢集中，Ceph Monitor 和 Manager 守護程序進行協調，以提高互連繫統之間的可靠性和資料可用性。 CRUSH 演算法降低了單點故障、效能瓶頸和可擴充套件性限制的風險，建立了可靠且高效能的儲存解決方案，適合不斷增長的企業市場。

  3. 高效能
    Ceph 的配置和部署可以完全根據您的需求進行定製，而不會影響效能。將 Ceph 應用到您現有的儲存設定中，或者使用廣泛可用的商用硬體建立新叢集，以實現行業領先的可靠性和可擴充套件性，而無需花費傳統的專有 ICT 基礎設施。 傳統儲存系統面臨著延遲、複雜的資料重複過程以及特定的、不靈活的物理基礎設施的需求，而 Ceph 卻能保持高效能和可擴充套件性。 作為軟體定義的儲存系統，Ceph 旨在最大限度地提高有效性和效能，無論其執行在何種基礎設施上。

架構

Ceph 在單個統一系統中提供物件、塊和檔案儲存

物件儲存

Ceph RGW 物件儲存服務提供業界領先的 S3 API 相容性以及一組強大的安全性、分層和互操作性功能。使用 S3 或 Swift 物件儲存的應用程式可以在單個資料中心內利用 Ceph 的可擴充套件性和效能，或者聯合全球多個 Ceph 叢集來建立具有廣泛的複製、遷移和其他資料服務集的全域性儲存名稱空間。

塊儲存

Ceph RBD（RADOS 塊裝置）塊儲存將虛擬磁碟條帶化到 Ceph 儲存叢集內的物件上，將資料和工作負載分佈到所有可用裝置上，以實現極高的可擴充套件性和效能。 RBD磁碟映象採用精簡配置，同時支援只讀快照和可寫克隆，並且可以非同步映象到其他資料中心的遠端Ceph叢集以進行災難恢復或備份，使Ceph RBD成為公共/私有云中塊儲存的首選和虛擬化環境。

檔案系統

Ceph 檔案系統 (CephFS) 是一個強大、功能齊全、符合 POSIX 標準的分散式檔案系統即服務，具有快照、配額和多叢集映象功能。 CephFS 檔案在 Ceph 儲存的物件之間進行條帶化，以實現極高的規模和效能。 Linux 系統可以透過基於 FUSE 的客戶端或 NFSv4 閘道器本地掛載 CephFS 檔案系統。

CRUSH演算法

CRUSH（可擴充套件雜湊下的受控複製）演算法透過自動複製確保組織的資料安全和儲存可擴充套件。使用 CRUSH 演算法，Ceph 客戶端和 Ceph OSD 守護程序能夠跟蹤儲存物件的位置，避免依賴中央查詢表的架構固有的問題。

可靠的自主分散式物件儲存 (RADOS)

RADOS（可靠的自主分散式物件儲存）旨在利用裝置智慧來分散由數千個儲存裝置組成的叢集中的一致資料訪問、冗餘儲存、故障檢測和故障恢復的複雜性。 RADOS 專為 PB 級儲存系統而設計：此類系統必然是動態的，因為它們隨著新儲存的部署和舊裝置的退役而逐漸增長和收縮。 RADOS 確保資料分佈有一致的檢視，同時保持對資料物件的一致讀寫訪問。

元件介紹

  • 監視器：Ceph 監視器 (ceph-mon) 維護叢集狀態圖，包括監視器圖、管理器圖、OSD 圖、MDS 圖和 CRUSH 圖。這些對映是 Ceph 守護程序相互協調所需的關鍵叢集狀態。監視器還負責管理守護程式和客戶端之間的身份驗證。為了實現冗餘和高可用性，通常需要至少三個監視器。
  • 管理器：Ceph 管理器守護程序 (ceph-mgr) 負責跟蹤執行時指標和 Ceph 叢集的當前狀態，包括儲存利用率、當前效能指標和系統負載。 Ceph Manager 守護程序還託管基於 python 的模組來管理和公開 Ceph 叢集資訊，包括基於 Web 的 Ceph 儀表板和 REST API。通常至少需要兩名管理器才能實現高可用性。
  • Ceph OSD：物件儲存守護程序（Ceph OSD、ceph-osd）儲存資料，處理資料複製、恢復、重新平衡，並透過檢查其他 Ceph OSD 守護程序的心跳來向 Ceph 監視器和管理器提供一些監視資訊。通常至少需要三個 Ceph OSD 才能實現冗餘和高可用性。
  • MDS：Ceph 後設資料伺服器（MDS、ceph-mds）儲存 Ceph 檔案系統的後設資料。 Ceph 後設資料伺服器允許 CephFS 使用者執行基本命令（如 ls、find 等），而不會給 Ceph 儲存叢集帶來負擔。
    Ceph 將資料作為物件儲存在邏輯儲存池中。使用 CRUSH 演算法，Ceph 計算哪個歸置組 (PG) 應包含該物件，以及哪個 OSD 應儲存該歸置組。 CRUSH 演算法使 Ceph 儲存叢集能夠動態擴充套件、重新平衡和恢復。

部署要求

CPU

CephFS 後設資料伺服器 (MDS)

  • 是 CPU 密集型的。
  • 它們是單執行緒的，在高時脈頻率 (GHz) 的 CPU 上效能最佳。
  • MDS 伺服器不需要大量 CPU 核心，除非它們還託管其他服務

在 Ceph 的早期版本中，我們會根據每個 OSD 的核心數量提出硬體建議，但是每個 osd 的核心數量指標不再像每個 IOP 的週期數和每個 OSD 的 IOPS 數量那樣有用。例如，藉助 NVMe OSD 驅動器，Ceph 可以輕鬆利用真實叢集上的 5 個或 6 個核心，以及單個 OSD 上最多 14 個獨立的核心。因此，每個 OSD 的核心數不再像以前那樣緊迫。選擇硬體時，請選擇每個核心的 IOPS。（IOPS比核心數重要）

監視器節點和管理器節點對 CPU 的要求不高，只需要適度的處理器。如果您的主機除了 Ceph 守護程序之外還將執行 CPU 密集型程序，請確保您有足夠的處理能力來執行 CPU 密集型程序和 Ceph 守護程序。 （OpenStack Nova 是 CPU 密集型程序的一個示例。）

我們建議您在單獨的主機（即，不是您的 Monitor 和 Manager 節點的主機）上執行非 Ceph CPU 密集型程序，以避免資源爭用。如果您的叢集部署了 Ceph 物件閘道器，並且節點有足夠的資源，RGW 守護程序可能會與您的 Mon 和 Manager 服務共存

MEM

一般來說，RAM 越大越好。對於中等規模的叢集來說，Monitor/Manager 節點使用 64GB 就可以了；對於具有數百個 OSD 的較大叢集，建議使用 128GB。
監視器和管理器守護程式記憶體使用量隨著叢集的大小而變化。請注意，在啟動時以及拓撲更改和恢復期間，這些守護程序將需要比穩態操作期間更多的 RAM，因此請規劃峰值使用情況。對於非常小的叢集，32 GB 就足夠了。對於最多 300 個 OSD 的叢集，需要使用 64GB。對於使用（或將增長到）更多 OSD 構建的叢集，您應該配置 128GB。您可能還需要考慮調整以下設定：

  • mon_osd_cache_size
  • rocksdb_cache_size

CephFS 後設資料守護程序記憶體利用率取決於其快取的配置大小。我們建議大多數系統至少使用 1 GB。請參閱 mds_cache_memory_limit。
不建議將 osd_memory_target 設定為低於 2GB。 Ceph 可能無法將記憶體消耗保持在 2GB 以下，並且效能可能會極其緩慢。 將記憶體目標設定在 2GB 到 4GB 之間通常可行，但可能會導致效能下降：除非活動資料集相對較小，否則可能需要在 IO 期間從磁碟讀取後設資料。 4GB 是 osd_memory_target 的當前預設值。此預設值是針對典型用例選擇的，旨在平衡 RAM 成本和 OSD 效能。 當有許多（小）物件或處理大（256GB/OSD 或更多）資料集時，將 osd_memory_target 設定為高於 4GB 可以提高效能。對於快速 NVMe OSD 來說尤其如此。

資料儲存

OSD 需要大量儲存驅動器空間來儲存 RADOS 資料。我們建議最小驅動器大小為 1 TB（磁碟大小）。遠小於 1 TB 的 OSD 驅動器使用其後設資料容量的很大一部分，而小於 100 GB 的驅動器根本不起作用。

強烈建議至少為 Ceph Monitor 和 Ceph Manager 主機以及 CephFS 後設資料伺服器後設資料池和 Ceph 物件閘道器 (RGW) 索引池配置（企業級）SSD，即使 HDD 是為批次 OSD 資料進行配置。

仔細考慮較大磁碟的每 GB 成本優勢。我們建議將磁碟驅動器的價格除以 GB 數，得出每 GB 成本，因為較大的驅動器可能會對每 GB 成本產生重大影響。例如，售價為 75.00 美元的 1 TB 硬碟每 GB 成本為 0.07 美元（即 75 美元/1024 = 0.0732）。相比之下，售價為 150.00 美元的 3 TB 磁碟的每 GB 成本為 0.05 美元（即 150 美元/3072 = 0.0488）。在前面的示例中，使用 1 TB 磁碟通常會使每 GB 成本增加 40%，從而大大降低叢集的成本效率。

在單個 SAS / SATA HDD 上託管多個 OSD 並不是一個好主意。
在單個驅動器上託管帶有監視器、管理器或 MDS 資料的 OSD 也不是一個好主意。
對於旋轉磁碟，SATA 和 SAS 介面日益成為更大容量的瓶頸。另請參閱儲存網路行業協會的總擁有成本計算器。

儲存驅動器受到尋道時間、訪問時間、讀寫時間以及總吞吐量的限制。這些物理限制會影響整體系統效能，尤其是在恢復期間。我們建議為作業系統和軟體使用專用（最好是映象）驅動器，併為主機上執行的每個 Ceph OSD 守護程序使用一個驅動器。許多“OSD 速度慢”問題（當它們不是由硬體故障引起時）是由於在同一驅動器上執行作業系統和多個 OSD 引起的。另請注意，當今的 22TB HDD 使用與十年前的 3TB HDD 相同的 SATA 介面：透過同一介面壓縮的資料量是其七倍以上。因此，當使用 HDD 作為 OSD 時，大於 8TB 的驅動器可能最適合儲存對效能完全不敏感的大檔案/物件。

固態硬碟

使用固態硬碟 (SSD) 時，Ceph 效能會大大提高。這減少了隨機訪問時間並減少了延遲，同時提高了吞吐量。 SSD 每 GB 的成本比 HDD 更高，但 SSD 的訪問時間通常至少比 HDD 快 100 倍。 SSD 避免了繁忙叢集中的熱點問題和瓶頸問題，並且在全面評估 TCO 時，它們可能會提供更好的經濟效益。值得注意的是，對於給定的 IOPS 數量，SSD 的攤銷驅動器成本比 HDD 低得多。 SSD 不會受到旋轉或尋道延遲的影響，除了提高客戶端效能之外，它們還大大提高了叢集更改的速度和客戶端影響，包括新增、刪除 OSD 或監視器或發生故障時的重新平衡。 SSD 沒有移動機械部件，因此不受 HDD 的許多限制。但 SSD 確實有很大的侷限性。在評估SSD時，重要的是要考慮順序和隨機讀寫的效能。

我們建議探索使用 SSD 來提高效能。但是，在對 SSD 進行重大投資之前，我們強烈建議您檢視 SSD 的效能指標並在測試配置中測試 SSD 以衡量效能。

相對便宜的 SSD 可能會吸引您的經濟意識。謹慎使用。選擇與 Ceph 配合使用的 SSD 時，可接受的 IOPS 並不是唯一要考慮的因素。廉價SSD往往是一種虛假經濟：它們可能會經歷“懸崖”，這意味著在最初的爆發之後，一旦有限的快取被填滿，持續效能就會大幅下降。還要考慮耐用性：額定為每天 0.3 次驅動器寫入（DWPD 或同等）的驅動器對於專用於某些型別的順序寫入（主要是讀取）資料的 OSD 來說可能沒問題，但對於 Ceph Monitor 任務來說不是一個好的選擇。企業級 SSD 最適合 Ceph：它們幾乎總是具有斷電保護 (PLP) 功能，並且不會遭受客戶端（桌面）模型可能遇到的急劇斷電的影響。

當使用單個（或映象對）SSD 用於作業系統啟動和 Ceph Monitor/Manager 目的時，建議最小容量為 256GB，並且建議至少為 480GB。建議採用額定值為 1+ DWPD（或 TBW（寫入太位元組）的等效值）的驅動器型號。但是，對於給定的寫入工作負載，比技術要求更大的驅動器將提供更高的耐用性，因為它實際上具有更大的過度配置。我們強調企業級驅動器最適合生產使用，因為與適用於更輕和間歇性工作週期的客戶端（桌面）SKU 相比，它們具有斷電保護和更高的耐用性。

歷史上，SSD 對於物件儲存來說成本過高，但 QLC SSD 正在縮小差距，提供更高的密度、更低的功耗和更少的冷卻功耗。此外，透過將 WAL+DB 解除安裝到 SSD 上，HDD OSD 的寫入延遲可能會得到顯著改善。許多 Ceph OSD 部署不需要耐用性高於 1 DWPD（又名“讀取最佳化”）的 SSD。 3 DWPD 級別的“混合用途”SSD 通常對於此目的來說是多餘的，並且成本要高得多。

將 SSD 與 Ceph 結合使用時，請確保分割槽正確對齊。不正確對齊的分割槽的資料傳輸速度比正確對齊的分割槽慢。有關正確分割槽對齊的更多資訊以及展示如何正確對齊分割槽的示例命令，請參閱 Werner Fischer 關於分割槽對齊的部落格文章。

Ceph 提高 CephFS 檔案系統效能的一種方法是將 CephFS 後設資料的儲存與 CephFS 檔案內容的儲存分開。 Ceph 為 CephFS 後設資料提供了預設的後設資料池。您永遠不必為 CephFS 後設資料手動建立池，但可以為僅包含 SSD 儲存介質的 CephFS 後設資料池建立 CRUSH 對映層次結構。有關詳細資訊，請參閱 CRUSH 裝置類。

您不需要 RoC（支援 RAID）HBA。 ZFS 或 Linux MD 軟體映象可以很好地提高啟動卷的永續性。使用 SAS 或 SATA 資料驅動器時，放棄 HBA RAID 功能可以縮小 HDD 和 SSD 介質成本之間的差距。此外，使用 NVMe SSD 時，不需要任何 HBA。當考慮整個系統時，這還減少了 HDD 與 SSD 的成本差距。即使打折後，精美的 RAID HBA 加板載快取加電池備份（BBU 或超級電容器）的初始成本也很容易超過 1000 美元 - 這一總和與 SSD 成本相當。如果購買年度維護合同或延長保修期，無 HBA 的系統每年的成本可能會減少數百美元。

The Ceph blog is often an excellent source of information on Ceph performance issues. See Ceph Write Throughput 1 and Ceph Write Throughput 2 for additional details.

Benchmark

BlueStore 使用 O_DIRECT 開啟儲存裝置並頻繁發出 fsync() 以確保資料安全地儲存到介質上。您可以使用 fio 評估驅動器的低階寫入效能。例如，4kB隨機寫入效能測量如下：

fio --name=/dev/sdX --ioengine=libaio --direct=1 --fsync=1 --readwrite=randwrite --blocksize=4k --runtime=300

企業級 SSD 和 HDD 通常包含斷電保護功能，可確保執行時斷電時的資料永續性，並使用多級快取來加速直接或同步寫入。這些裝置可以在兩種快取模式之間切換——使用 fsync 重新整理到持久介質的易失性快取，或同步寫入的非易失性快取。 這兩種模式可透過“啟用”或“禁用”寫入（易失性）快取來選擇。當啟用易失性快取時，Linux 使用“回寫”模式的裝置，當禁用時，它使用“直寫”模式。 預設配置（通常：啟用快取）可能不是最佳的，並且透過禁用此寫入快取，OSD 效能可能會在增加 IOPS 和減少提交延遲方面得到顯著提高。 因此，鼓勵使用者如前所述使用 fio 對其裝置進行基準測試，併為其裝置保留最佳快取配置。


The cache configuration can be queried with hdparm, sdparm, smartctl or by reading the values in /sys/class/scsi_disk/*/cache_type, for example:
hdparm -W /dev/sda

/dev/sda: write-caching =  1 (on)# sdparm --get WCE /dev/sda
    /dev/sda: ATA       TOSHIBA MG07ACA1  0101WCE           1  [cha: y]# smartctl -g wcache /dev/sda
smartctl 7.1 2020-04-05 r5049 [x86_64-linux-4.18.0-305.19.1.el8_4.x86_64] (local build)Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.orgWrite cache is:   Enabled# cat /sys/class/scsi_disk/0\:0\:0\:0/cache_type
write back
The write cache can be disabled with those same tools:
hdparm -W0 /dev/sda

/dev/sda: setting drive write-caching to 0 (off) write-caching =  0 (off)sdparm --clear WCE /dev/sda
    /dev/sda: ATA       TOSHIBA MG07ACA1  0101smartctl -s wcache,off /dev/sda
smartctl 7.1 2020-04-05 r5049 [x86_64-linux-4.18.0-305.19.1.el8_4.x86_64] (local build)Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org=== START OF ENABLE/DISABLE COMMANDS SECTION ===Write cache disabled
In most cases, disabling this cache using hdparm, sdparm, or smartctl results in the cache_type changing automatically to “write through”. If this is not the case, you can try setting it directly as follows. (Users should ensure that setting cache_type also correctly persists the caching mode of the device until the next reboot as some drives require this to be repeated at every boot):
echo "write through"  /sys/class/scsi_disk/0\:0\:0\:0/cache_type

hdparm -W /dev/sda

/dev/sda: write-caching =  0 (off)

網路

在資料中心內配置至少 10 Gb/s 的網路，無論是在 Ceph 主機之間還是在客戶端與 Ceph 叢集之間。強烈建議跨單獨的網路交換機進行網路鏈路主動/主動繫結，以提高吞吐量並容忍網路故障和維護。請注意您的繫結雜湊策略會跨連結分配流量。

透過 1 Gb/s 網路複製 1 TB 資料需要三個小時，透過 1 Gb/s 網路複製 10 TB 資料需要三十個小時。但透過 10 Gb/s 網路複製 1 TB 只需要 20 分鐘，透過 10 Gb/s 網路複製 10 TB 只需一小時。 請注意，40 Gb/s 網路鏈路實際上是四個並行的 10 Gb/s 通道，而 100 Gb/s 網路鏈路實際上是四個並行的 25 Gb/s 通道。因此，也許有點違反直覺，與 40 Gb/s 網路相比，25 Gb/s 網路上的單個資料包的延遲稍低。

一些部署工具使用 VLAN 來使硬體和網路佈線更易於管理。使用 802.1q 協議的 VLAN 需要支援 VLAN 的網路卡和交換機。該硬體增加的費用可以透過網路設定和維護方面的運營成本節省來抵消。當使用 VLAN 處理叢集和計算堆疊（例如 OpenStack、CloudStack 等）之間的 VM 流量時，使用 10 Gb/s 乙太網或更好的乙太網具有額外的價值；截至 2022 年，40 Gb/s 或越來越多的 25/50/100 Gb/s 網路對於生產叢集來說很常見。

架頂式 (TOR) 交換機還需要到核心/主幹網路交換機或路由器的快速且冗餘的上行鏈路，通常至少為 40 Gb/s。

您的伺服器機箱應該有一個底板管理控制器 (BMC)。著名的例子有 iDRAC (戴爾)、CIMC (思科 UCS) 和 iLO (HPE)。管理和部署工具也可能廣泛使用 BMC，尤其是透過 IPMI 或 Redfish，因此請考慮帶外網路的安全性和管理的成本/效益權衡。虛擬機器管理程式 SSH 訪問、VM 映像上傳、作業系統映像安裝、管理套接字等可能會給網路帶來巨大的負載。執行多個網路可能看起來有點大材小用，但每個流量路徑都代表著潛在的容量、吞吐量和/或效能瓶頸，您在部署大規模資料叢集之前應該仔細考慮這些瓶頸。

如果您正在使用單個儲存驅動器執行 OSD 節點，請為 OSD 建立一個與包含作業系統的分割槽分開的分割槽。我們建議作業系統和 OSD 儲存使用單獨的驅動器。

系統要求

部署

Cephadm

是一個可用於安裝和管理 Ceph 叢集的工具。

  • cephadm 僅支援 Octopus 和更新版本。
  • cephadm 與編排 API 完全整合，並完全支援用於管理叢集部署的 CLI 和儀表板功能。
  • cephadm 需要容器支援（以 Podman 或 Docker 的形式）和 Python 3。

Rook

部署和管理在 Kubernetes 中執行的 Ceph 叢集，同時還可以透過 Kubernetes API 管理儲存資源和配置。
我們推薦 Rook 作為在 Kubernetes 中執行 Ceph 或將現有 Ceph 儲存叢集連線到 Kubernetes 的方式。

  • Rook 僅支援 Nautilus 和更新版本的 Ceph。
  • Rook 是在 Kubernetes 上執行 Ceph 或將 Kubernetes 叢集連線到現有（外部）Ceph 叢集的首選方法。
  • Rook 支援 Orchestrator API。完全支援 CLI 和儀表板中的管理功能。

ceph-ansible

使用 Ansible 部署和管理 Ceph 叢集。

  • Ceph-ansible 得到了廣泛部署。
  • ceph-ansible 未與 Nautilus 和 Octopus 中引入的 Orchestrator API 整合，這意味著 Nautilus 和 Octopus 中引入的管理功能和儀表板整合在透過 ceph-ansible 部署的 Ceph 叢集中不可用

ceph-deploy 沒有得到積極維護。
它沒有在比 Nautilus 新的 Ceph 版本上進行測試。
它不支援 RHEL8、CentOS 8 或更新的作業系統。

cephadm安裝步驟

要求

  • Python 3
  • Systemd
  • Podman or Docker for running containers
  • Time synchronization (such as Chrony or the legacy ntpd)
  • LVM2 for provisioning storage devices

安裝cephadm

Cephadm 透過引導單個主機、擴充套件叢集以包含任何其他主機，然後部署所需的服務來建立新的 Ceph 叢集。

There are two ways to install cephadm:

1. a curl-based installation method
CEPH_RELEASE=18.2.0 # replace this with the active releasecurl --silent --remote-name --location https://download.ceph.com/rpm-${CEPH_RELEASE}/el9/noarch/cephadm
Ensure the cephadm file is executable:
chmod +x cephadm
This file can be run directly from the current directory:
./cephadm <arguments...>
  1. distribution-specific installation methods
#In Ubuntu:
apt install -y cephadm
#In CentOS Stream:
dnf search release-ceph
dnf install --assumeyes centos-release-ceph-reef
dnf install --assumeyes cephadm
#In Fedora:
dnf -y install cephadm
#In SUSE:
zypper install -y cephadm

注意這兩種方式是互斥的，不能在同一個叢集中使用兩種安裝方式

更新cephadmin

./cephadm add-repo --release reef
./cephadm install
#Confirm that cephadm is now in your PATH by running which or command -v:
which cephadm
#A successful which cephadm command will return this:
/usr/sbin/cephadm

Bootstrap

建立新 Ceph 叢集的第一步是在 Ceph 叢集的第一臺主機上執行 cephadm bootstrap 命令。在 Ceph 叢集的第一臺主機上執行 cephadm bootstrap 命令的行為會建立 Ceph 叢集的第一個 Monitor 守護程序。您必須將 Ceph 叢集第一臺主機的 IP 地址傳遞給 ceph bootstrap 命令，因此您需要知道該主機的 IP 地址。

執行bootstrap命令：
cephadm bootstrap --mon-ip *<mon-ip>*

這個命令執行如下操作：

  • 在本地主機上為新叢集建立監視器和管理器守護程式。
  • 為 Ceph 叢集生成新的 SSH 金鑰並將其新增到 root 使用者的 /root/.ssh/authorized_keys 檔案中。
  • 將公鑰的副本寫入 /etc/ceph/ceph.pub。
  • 將最小配置檔案寫入 /etc/ceph/ceph.conf。需要此檔案與 Ceph 守護程序進行通訊。
  • 將 client.admin 管理（特權！）金鑰的副本寫入 /etc/ceph/ceph.client.admin.keyring。
  • 將 _admin 標籤新增到引導主機。預設情況下，任何具有此標籤的主機都將（也）獲得 /etc/ceph/ceph.conf 和 /etc/ceph/ceph.client.admin.keyring 的副本。

更多關於bootstrap的資訊：

  • 預設情況下，Ceph 守護程序將其日誌輸出傳送到 stdout/stderr，該日誌輸出由容器執行時（docker 或 podman）拾取並（在大多數系統上）傳送到 Journald。如果您希望 Ceph 將傳統日誌檔案寫入 /var/log/ceph/$fsid，請在引導期間使用 --log-to-file 選項。
  • 當（Ceph 叢集外部）公共網路流量與（Ceph 叢集內部）叢集流量分開時，較大的 Ceph 叢集效能最佳。內部叢集流量處理 OSD 守護程序之間的複製、恢復和心跳。您可以透過向 bootstrap 子命令提供 --cluster-network 選項來定義叢集網路。此引數必須是採用 CIDR 表示法的子網（例如 10.90.90.0/24 或 fe80::/64）。
  • cephadm bootstrap 寫入訪問新叢集所需的 /etc/ceph 檔案。這個中心位置使得安裝在主機上的 Ceph 軟體包（例如，可以訪問 cephadm 命令列介面的軟體包）可以找到這些檔案。 然而，使用 cephadm 部署的守護程序容器根本不需要 /etc/ceph。使用 --output-dir 選項將它們放在不同的目錄中（例如，.）。這可能有助於避免與同一主機上的現有 Ceph 配置（cephadm 或其他）發生衝突。
  • 您可以將任何初始 Ceph 配置選項傳遞到新叢集，方法是將它們放入標準 ini 樣式配置檔案中並使用 --config 選項。例如：
cat <<EOF > initial-ceph.conf
[global]
osd crush chooseleaf type = 0
EOF

$ ./cephadm bootstrap --config initial-ceph.conf ...

  • --ssh-user 選項可以指定 cephadm 將使用哪個 SSH 使用者連線到主機。關聯的 SSH 金鑰將新增到 /home//.ssh/authorized_keys。您使用此選項指定的使用者必須具有無密碼 sudo 訪問許可權。
  • 如果您使用來自需要登入的登錄檔的容器映像，則可以新增引數：
    • --registry-json
      {"url":"REGISTRY_URL", "username":"REGISTRY_USERNAME", "password":"REGISTRY_PASSWORD"}

Cephadm 將嘗試登入到此登錄檔，以便它可以拉取您的容器，然後將登入資訊儲存在其配置資料庫中。新增到叢集的其他主機也將能夠使用經過身份驗證的容器登錄檔。

ENABLE CEPH CLI

Cephadm 不需要在主機上安裝任何 Ceph 軟體包。但是，我們建議啟用對 ceph 命令的輕鬆訪問。做這件事有很多種方法：

  • cephadm shell 命令在安裝了所有 Ceph 軟體包的容器中啟動 bash shell。預設情況下，如果在主機上的 /etc/ceph 中找到配置和金鑰環檔案，它們將被傳遞到容器環境中，以便 shell 發揮完整功能。請注意，在 MON 主機上執行時，cephadm shell 將從 MON 容器推斷配置，而不是使用預設配置。如果給出 --mount ，則主機 （檔案或目錄）將出現在容器內的 /mnt 下：
    cephadm shell
  • 要執行 ceph 命令，您還可以執行如下命令：
    cephadm shell -- ceph -s
  • 您可以安裝 ceph-common 軟體包，其中包含所有 ceph 命令，包括 ceph、rbd、mount.ceph（用於掛載 CephFS 檔案系統）等：
cephadm add-repo --release reef
cephadm install ceph-common
  • 確認 ceph 命令可透過以下方式訪問：
    ceph -v
  • 確認 ceph 命令可以連線到叢集及其狀態：
ceph status
Adding hosts

按照新增主機中的說明將所有主機新增到叢集。 預設情況下，ceph.conf 檔案和 client.admin 金鑰環的副本儲存在所有具有 _admin 標籤的主機上的 /etc/ceph 中。該標籤最初僅應用於引導主機。我們建議為一臺或多臺其他主機指定 _admin 標籤，以便在多臺主機上輕鬆訪問 Ceph CLI（例如，透過 cephadm shell）。要將 _admin 標籤新增到其他主機，請執行以下形式的命令：

ceph orch host label add *<host>* _admin

ADDING ADDITIONAL MONS

典型的 Ceph 叢集具有三到五個分佈在不同主機上的 Monitor 守護程序。如果叢集中有五個或更多節點，我們建議部署五個監視器。大多數叢集不會從七個或更多監視器中受益。 請按照部署其他監視器來部署其他 MON。

ADDING STORAGE

To add storage to the cluster, you can tell Ceph to consume any available and unused device(s):
ceph orch apply osd --all-available-devices

部署OSDS文件

ENABLING OSD MEMORY AUTOTUNING
預設情況下，cephadm 在載入程式上啟用 osd_memory_target_autotune，並將 mgr/cephadm/autotune_memory_target_ratio 設定為總主機記憶體的 0.7。

請參閱自動調整 OSD 記憶體。

要使用 TripleO 部署超融合 Ceph，請參閱 TripleO 文件：場景：部署超融合
Ceph 在叢集硬體並非由 Ceph（融合基礎設施）專用的其他情況下，請減少 Ceph 的記憶體消耗，如下所示：

# converged only:
ceph config set mgr mgr/cephadm/autotune_memory_target_ratio 0.2

然後啟用記憶體自動調整：
ceph config set osd osd_memory_target_autotune true

使用CEPH，至此ceph叢集已經搭建好了，需要根據實際業務情況來啟用不同的功能

  • To use the Ceph Filesystem, follow Deploy CephFS.
  • To use the Ceph Object Gateway, follow Deploy RGWs.
  • To use NFS, follow NFS Service
  • To use iSCSI, follow Deploying iSCSI

文章中很多參見連結在從其他文件複製過來的時候丟了，建議參考官網文件對照。
完整的安裝步驟可以參考其他博文

相關文章