2 硬體要求和建議 #
Ceph 的硬體要求在很大程度上取決於 IO 工作負載。在開始進行詳細規劃時，應考慮以下硬體要求和建議。
一般情況下，本節所述的建議是按程序提出的。如果同一部機器上有多個程序，則需要提高 CPU、RAM、磁碟和網路要求。
2.1 網路綜覽 #
Ceph 有以下幾個邏輯網路：
名為
公用網路的前端網路。名為
叢集網路的可信內部網路 (後端網路)。這是選擇性的。閘道的一個或多個用戶端網路。此為選擇性網路，不在本章的討論範圍之內。
公用網路是 Ceph 精靈相互之間以及與其用戶端之間進行通訊的網路。這表示所有 Ceph 叢集流量都透過該網路傳輸 (設定叢集網路時除外)。
叢集網路是 OSD 節點之間的後端網路，用於執行複製、重新平衡和復原操作。如果設定了此選擇性網路，則理想情況下，它將提供兩倍於公用網路的頻寬 (預設為三向複製)，因為主 OSD 會透過此網路向其他 OSD 傳送兩個複本。公用網路位於用戶端和閘道之間，用於在其中一端與監控程式、管理員、MDS 節點、OSD 節點進行通訊。監控程式、管理員和 MDS 節點也會使用該網路與 OSD 節點進行通訊。
2.1.1 網路建議 #
我們建議使用具有足夠頻寬的單一容錯網路，以滿足您的需求。對於 Ceph 公用網路環境，我們建議使用透過 802.3ad (LACP) 進行結合的兩個結合 25 GbE (或更快的) 網路介面。這被視為 Ceph 的最小設定。如果您還使用叢集網路，則建議您使用四個結合 25 GbE 網路介面。結合兩個或更多網路介面可透過連結聚總提供更高的輸送量，並可提供備援連結和交換器，進而提高了容錯性和可維護性。
您還可以建立 VLAN 來隔離透過結合傳輸的不同類型的流量。例如，您可以建立一個結合來提供兩個 VLAN 介面，一個用於公用網路，另一個用於叢集網路。但在設定 Ceph 網路時不需要這樣做。如需結合介面的詳細資料，請參閱 https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-network.html#sec-network-iface-bonding。
透過將元件隔離到故障網域中，可以提高容錯性。為了提高網路的容錯性，可從兩個單獨的網路介面卡 (NIC) 結合一個介面，以在單個 NIC 出現故障時提供保護。同樣，在兩個交換器之間建立一個結合可在單個交換器出現故障時提供保護。建議您向網路設備廠商諮詢，以構造所需的容錯層級。
其他管理網路設定 (例如可實現 SSH、Salt 或 DNS 網路分隔的設定) 未經過測試亦不受支援。
如果儲存節點是透過 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.1.1.1 將私人網路絡新增至執行中叢集 #
如果您在 Ceph 部署期間未指定叢集網路，則系統假設使用的是單一公用網路環境。儘管 Ceph 可在公用網路中正常運作，但如果您設定了另一個私人叢集網路，Ceph 的效能和安全性將會得到提升。若要支援兩個網路，每個 Ceph 節點上至少需有兩個網路卡。
需要對每個 Ceph 節點套用以下變更。對小型叢集執行此操作的速度相對較快，但如果叢集包含數百甚至數千個節點，則此程序可能十分耗時。
使用以下指令設定叢集網路：
root #ceph config set global cluster_network MY_NETWORK重新啟動 OSD 以結合到指定的叢集網路：
root #systemctl restart ceph-*@osd.*.service檢查私人叢集網路在 OS 層級是否如預期般運作。
2.1.1.2 不同子網路中的監控節點 #
如果監控程式節點位於多個子網路中 (例如，位於不同的機房並由不同的交換器提供服務)，則您需要以 CIDR 表示法指定其公用網路位址。
cephuser@adm > ceph config set mon public_network "MON_NETWORK_1, MON_NETWORK_2, MON_NETWORK_N例如：
cephuser@adm > ceph config set mon public_network "192.168.1.0/24, 10.10.0.0/16"
如果依據本節中所述為公用 (或叢集) 網路指定了多個網路區段，則這些子網路中的每一個子網路都必須能夠路由到其他所有子網路，否則，不同網路區段上的 MON 與其他 Ceph 精靈將無法通訊，並且叢集將隨之分裂。此外，如果您使用防火牆，請確定在 iptables 中包含每個 IP 位址或子網路，並視需要在所有節點上為其開啟連接埠。
2.2 多架構組態 #
SUSE Enterprise Storage 支援 x86 和 Arm 架構。考慮每個架構時，請務必注意從每個 OSD 的核心數、頻率和 RAM 的角度進行，不同的 CPU 架構在大小調整方面並無實際差異。
與較小的 x86 處理器 (非伺服器) 一樣，效能較低的基於 Arm 的核心可能無法提供最佳體驗，特別是用於糾刪碼池時。
在整份文件中，使用 SYSTEM-ARCH 代替 x86 或 Arm。
2.3 硬體組態 #
為了獲得最佳產品體驗，建議您從推薦的叢集組態開始。對於測試叢集或效能要求較低的叢集，我們記錄了所支援的最低叢集組態。
2.3.1 最低叢集組態 #
最低產品叢集組態包括：
至少四個實體節點 (OSD 節點)，支援服務併置
做為結合網路的雙 10 Gb 乙太網路
一個獨立管理節點 (可以在外部節點上虛擬化)
詳細組態如下：
具有 4 GB RAM、四個核心和 1 TB 儲存容量的獨立管理節點。通常是 Salt Master 節點。Ceph 服務和閘道 (例如 Ceph 監控程式、中繼資料伺服器、Ceph OSD、物件閘道或 NFS Ganesha) 在管理節點上不受支援，因為它需要單獨協調叢集更新和升級程序。
至少四個實體 OSD 節點，每個節點有八個 OSD 磁碟，相關要求請參閱第 2.4.1 節 「最低要求」。
應調整叢集總容量的大小，以便即使有一個節點不可用，已用總容量 (包括備援) 也不超過 80%。
三個 Ceph 監控程式例項。出於延遲原因，需要從 SSD/NVMe 儲存來執行監控程式，而不是透過 HDD 執行。
監控程式、中繼資料伺服器和閘道可以併置在 OSD 節點上，請參閱第 2.12 節 「共用一部伺服器的 OSD 和監控程式」以瞭解監控程式併置。如果併置服務，則需要將記憶體和 CPU 要求相加。
iSCSI 閘道、物件閘道和中繼資料伺服器至少需要增量 4 GB RAM 和四個核心。
如果您使用的是 CephFS、S3/Swift、iSCSI，則至少需要兩個各自角色 (中繼資料伺服器、物件閘道、iSCSI) 的例項才能實現備援和可用性。
這些節點將專用於 SUSE Enterprise Storage，並且不得用於任何其他實體、容器化或虛擬化工作負載。
如果虛擬機器中部署了任何閘道 (iSCSI、物件閘道、NFS Ganesha、中繼資料伺服器等)，則這些虛擬機器不得代管在為其他叢集角色提供服務的實體機器上。(這並非必要，因為它們可做為併置服務受到支援。)
在核心實體叢集之外的監管程式上將服務部署為虛擬機器時，必須考慮故障網域以確保備援。
例如，不要在同一個監管程式上部署多個同類角色，例如多個 MON 或 MDS 例項。
在虛擬機器之內部署時，請務必確定節點具有強大的網路連接性和良好的工作時間同步。
監管程式節點必須足夠大，以避免受到其他佔用 CPU、RAM、網路和儲存資源的工作負載的干擾。
2.3.2 建議的生產叢集組態 #
一旦您擴充了叢集，建議將 Ceph 監控程式、中繼資料伺服器和閘道重新定位到不同的節點，以獲得更好的容錯性。
七個物件儲存節點
單一節點不超出總儲存容量的 15% 左右。
應調整叢集總容量的大小，以便即使有一個節點不可用，已用總容量 (包括備援) 也不超過 80%。
25 Gb 乙太網路或以上，進行結合，一個用於內部叢集網絡，另一個用於外部公用網路。
每個儲存叢集有 56 個以上的 OSD。
如需進一步建議，請參閱第 2.4.1 節 「最低要求」。
專屬的實體基礎架構節點。
三個 Ceph 監控程式節點：4 GB RAM，四核處理器，RAID 1 SSD 磁碟。
如需進一步建議，請參閱第 2.5 節 「監控程式節點」。
物件閘道節點：32 GB RAM，八核處理器，RAID 1 SSD 磁碟。
如需進一步建議，請參閱第 2.6 節 「物件閘道節點」。
iSCSI 閘道節點：16 GB RAM，八核處理器，RAID 1 SSD 磁碟。
如需進一步建議，請參閱第 2.9 節 「iSCSI 閘道節點」。
中繼資料伺服器節點 (一個使用中/一個熱待命)：32 GB RAM，八核處理器，RAID 1 SSD 磁碟。
如需進一步建議，請參閱第 2.7 節 「中繼資料伺服器節點」。
一個 SES 管理節點：4 GB RAM，四核處理器，RAID 1 SSD 磁碟。
2.3.3 多重路徑組態 #
如果要使用多重路徑硬體，請確定 LVM 會在組態檔案中的 devices 區段下看到
multipath_component_detection = 1。可以透過 lvm
config 指令進行此項檢查。
另外，確定 LVM 透過 LVM 過濾器組態過濾裝置的 mpath 元件。此為主機特定。
不建議這樣做，只有在無法設定 multipath_component_detection = 1
時才應考慮這樣做。
如需多重路徑組態的詳細資訊，請參閱 https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-multipath.html#sec-multipath-lvm。
2.4 物件儲存節點 #
2.4.1 最低要求 #
以下 CPU 建議針對獨立於 Ceph 使用的裝置：
每個旋轉式磁碟 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的更多詳細資料，請參閱第 28.4.1 節 「設定自動快取大小調整」。OSD 磁碟採用 JBOD 組態或個別的 RAID-0 組態。
OSD 記錄可以存放在 OSD 磁碟上。
OSD 磁碟應該專門由 SUSE Enterprise Storage 使用。
作業系統專屬的磁碟和 SSD，最好採用 RAID 1 組態。
如果此 OSD 主機將代管用於快取分層的快取池的一部分，則至少應再額外配置 4 GB RAM。
Ceph 監控程式、閘道和中繼資料伺服器可以存放在物件儲存節點上。
出於磁碟效能考慮，OSD 節點是裸機節點。OSD 節點上不應執行其他工作負載，除非它是 Ceph 監控程式和 Ceph 管理員的最低設定。
依據 6:1 的 SSD 記錄與 OSD 的比率為記錄提供 SSD。
確定 OSD 節點沒有對應任何網路區塊裝置，例如 iSCSI 或 RADOS 區塊裝置影像。
2.4.2 最小磁碟大小 #
需要在 OSD 上執行以下兩種類型的磁碟空間：用於 WAL/DB 裝置的空間以及用於儲存資料的主要空間。WAL/DB 的最小 (預設) 值為 6 GB。資料的最小空間為 5 GB，因為系統會自動為小於 5 GB 的分割區指定權數 0。
因此，儘管 OSD 的最小磁碟空間為 11 GB，但不建議使用小於 20 GB 的磁碟，即使在測試中也是如此。
2.4.3 BlueStore 的 WAL 和 DB 裝置的建議大小 #
我們建議為 WAL 裝置保留 4 GB。對於大多數工作負載而言，建議的 DB 大小為 64 GB。
重要對於高負載部署，建議使用更大的 DB 磁碟區，特別是在 RGW 或 CephFS 使用率較高的情況下。如果需要，請保留一些容量 (槽) 來安裝更多硬體，以提供更大的 DB 空間。
如果您打算將 WAL 和 DB 裝置置於同一磁碟，建議您為這兩個裝置使用一個分割區，而不是為每個裝置使用單獨的分割區。這樣，Ceph 便可以使用 DB 裝置來執行 WAL 操作。這對於磁碟空間的管理也會更有效，因為 Ceph 只會在需要時才會為 WAL 使用 DB 分割區。另一個好處是，WAL 分割區填滿的可能性很小，當該分割區未完全利用時，其空間並不會浪費，而是用於 DB 操作。
若要與 WAL 共用 DB 裝置，請不要指定 WAL 裝置，而是僅指定 DB 裝置。
如需指定 OSD 配置的詳細資訊，請參閱第 13.4.3 節 「使用 DriveGroups 規格新增 OSD。」。
2.4.4 用於 WAL/DB 分割區的 SSD #
固態硬碟 (SSD) 不包含移動部件。這可以減少隨機存取時間和讀取延遲，同時加快資料輸送量。由於 SSD 的每 MB 價格大大高於旋轉型硬碟，SSD 只適用於較小規模的儲存。
如果將 WAL/DB 分割區儲存在 SSD 上，並將物件資料儲存在獨立的硬碟上，OSD 的效能會得到大幅提高。
由於 WAL/DB 分割區佔用的空間相對較少，因此可以多個 WAL/DB 分割區共用一個 SSD 磁碟。請注意，共用的 WAL/DB 分割區每多一個，SSD 磁碟的效能就會相應下降一分。不建議在同一個 SSD 磁碟中共用 6 個以上的 WAL/DB 分割區，或者在 NVMe 磁碟中共用 12 個以上的 WAL/DB 分割區。
2.4.5 磁碟的最大建議數量 #
您可以在一部伺服器上使用所允許的任意數量的磁碟。規劃每部伺服器的磁碟數量時，需要考慮以下幾點：
網路頻寬：在一部伺服器中使用的磁碟越多，執行磁碟寫入操作時必須透過網路卡傳輸的資料就越多。
記憶體：系統會將超過 2 GB 的 RAM 用於 BlueStore 快取。當
osd_memory_target設為預設值 4 GB 時，該起始快取大小對於旋轉式媒體而言是比較合理的。如果使用 SSD 或 NVME，請考慮增加快取大小以及為每個 OSD 配置的 RAM，以便最大限度地提高效能。容錯：如果整部伺服器發生故障，則伺服器包含的磁碟越多，叢集暫時丟失的 OSD 就越多。此外，為了確保複製規則的執行，需要將發生故障伺服器中的所有資料複製到叢集中的其他節點。
2.5 監控程式節點 #
至少需要三個 MON 節點。監控程式數量應永遠為奇數 (1+2n)。
4 GB RAM。
具有四個邏輯核心的處理器。
強烈建議您為監控程式使用 SSD 或其他速度足夠快的儲存類型，特別是針對每個監控程式節點上的
/var/lib/ceph路徑，因為最低核准人數可能不穩定且磁碟延遲較高。建議提供兩個採用 RAID 1 組態的磁碟來進行備援。建議為監控程式程序使用獨立的磁碟，或者至少是獨立的磁碟分割區，以防止記錄檔案增大等問題導致監控程式的可用磁碟空間不足。每個節點只能有一個監控程式程序。
僅當有足夠的硬體資源可用時，才支援混用 OSD、MON 或物件閘道節點。這意味著，對於所有服務需提高相應要求。
與多個交換器結合的兩個網路介面。
2.6 物件閘道節點 #
物件閘道節點至少應具有 6 個 CPU 核心和 32 GB RAM。如果將其他程序併置在同一部機器上，則需要提高相應要求。
2.7 中繼資料伺服器節點 #
中繼資料伺服器節點的適當大小取決於特定使用案例。一般而言，中繼資料伺服器需要處理的開啟檔案越多，所需要的 CPU 和 RAM 就越多。以下是最低要求：
為每個中繼資料伺服器精靈指定 4 GB 的 RAM。
結合網路介面。
2.5 GHz CPU，至少具有兩個核心。
2.8 管理節點 #
至少需要 4 GB RAM 和四核 CPU。其中包括在管理節點上執行 Salt Master。對於包含數百個節點的大型叢集，建議提供 6 GB RAM。
2.9 iSCSI 閘道節點 #
iSCSI 閘道節點至少應具有 6 個 CPU 核心和 16 GB RAM。
2.10 SES 和其他 SUSE 產品 #
本節包含有關將 SES 與其他 SUSE 產品整合的重要資訊。
2.10.1 SUSE Manager #
SUSE Manager 與 SUSE Enterprise Storage 未整合，因此 SUSE Manager 目前無法管理 SES 叢集。
2.11 名稱限制 #
一般情況下，Ceph 不支援在組態檔案、池名稱、使用者名稱等內容中使用非 ASCII 字元。設定 Ceph 叢集時，建議您在所有 Ceph 物件/組態名稱中僅使用簡單的英數字元 (A-Z、a-z、0-9) 和最少量的標點符號 (「.」、「-」、「_」)。
2.12 共用一部伺服器的 OSD 和監控程式 #
儘管從技術上講可以在測試環境中的同一部伺服器上執行 OSD 和 MON，但強烈建議您在生產環境中為每個監控程式節點使用獨立的伺服器。這樣做的主要原因在於效能 — 叢集包含的 OSD 越多，MON 節點需要執行的 I/O 操作就越多。另外，當 MON 節點與 OSD 之間共用一部伺服器時，OSD I/O 操作便將成為監控程式節點的限制因素。
另一個考慮因素是，是否要在 OSD、MON 節點與伺服器上的作業系統之間共用磁碟。答案非常簡單：如果可能，請將一個獨立的磁碟專門用於 OSD，並將一部獨立的伺服器用於監控程式節點。
儘管 Ceph 支援基於目錄的 OSD，但 OSD 應永遠具有一個專屬磁碟，而不能與作業系統共用一個磁碟。
如果確實有必要在同一部伺服器上執行 OSD 和 MON 節點，請將一個獨立磁碟掛接至
/var/lib/ceph/mon 目錄以在該磁碟上執行 MON，這樣可以稍微提升一些效能。