CEPH集羣操做入門--配置

時間 2020-07-21

原文原文鏈接

概述

Ceph存儲集羣是全部Ceph部署的基礎。基於RADOS，Ceph存儲集羣由兩種類型的守護進程組成：Ceph OSD守護進程（OSD）將數據做爲對象存儲在存儲節點上; Ceph Monitor（MON）維護集羣映射的主副本。 Ceph存儲集羣可能包含數千個存儲節點。最小系統將至少有一個Ceph Monitor和兩個Ceph OSD守護進程用於數據複製。

Ceph文件系統，Ceph對象存儲和Ceph塊設備從Ceph存儲集羣讀取數據並將數據寫入Ceph存儲集羣。

配置和部署

Ceph存儲集羣有一些必需的設置，但大多數配置設置都有默認值。典型部署使用部署工具來定義集羣並引導監視器。有關ceph-deploy的詳細信息，請參閱部署。

配置

存儲設備

概述

有兩個Ceph守護進程將數據存儲在磁盤上：html

Ceph OSD（或Object Storage Daemons）是Ceph中存儲大部分數據的地方。通常而言，每一個OSD都由單個存儲設備支持，如傳統硬盤（HDD）或固態硬盤（SSD）。 OSD還能夠由多種設備組合支持，例如用於大多數數據的HDD和用於某些元數據的SSD（或SSD的分區）。集羣中OSD的數量一般取決於將存儲多少數據，每一個存儲設備的大小以及冗餘的級別和類型（複製或糾刪碼）。前端

Ceph Monitor守護程序管理集羣狀態，如集羣成員和身份驗證信息。對於較小的集羣，只須要幾GB，但對於較大的集羣，監控數據庫能夠達到幾十甚至幾百GB。node

準備硬盤

Ceph 注重數據安全，就是說， Ceph 客戶端收到數據已寫入存儲器的通知時，數據確實已寫入硬盤。使用較老的內核（版本小於 2.6.33 ）時，若是日誌在原始硬盤上，就要禁用寫緩存；較新的內核沒問題。算法

用 hdparm 禁用硬盤的寫緩衝功能。shell

sudo hdparm -W 0 /dev/hda 0

在生產環境，咱們建議操做系統和OSD數據分別放到不一樣的硬盤。若是必須把數據和系統放在同一硬盤裏，最好給數據分配一個單獨的分區。數據庫

OSD後端

OSD能夠經過兩種方式管理它們存儲的數據。從Luminous 12.2.z版本開始，新的默認（和推薦）後端是BlueStore。在Luminous以前，默認（也是惟一的選項）是FileStore。json

BLUESTORE

BlueStore是一種專用存儲後端，專爲管理Ceph OSD工做負載的磁盤數據而設計。在過去十年中，使用FileStore支持和管理OSD的經驗激發了它的動力。關鍵的BlueStore功能包括：bootstrap

直接管理存儲設備。 BlueStore使用原始塊設備或分區。這避免了可能限制性能或增長複雜性的任何中間抽象層（例如XFS等本地文件系統）。
使用RocksDB進行元數據管理。咱們嵌入了RocksDB的鍵/值數據庫，以便管理內部元數據，例如從對象名到磁盤上的塊位置的映射。
完整數據和元數據校驗和。默認狀況下，寫入BlueStore的全部數據和元數據都受一個或多個校驗和的保護。在未經驗證的狀況下，不會從磁盤讀取數據或元數據或將其返回給用戶。
內聯壓縮。在寫入磁盤以前，能夠選擇壓縮寫入的數據。
多設備元數據分層。 BlueStore容許將其內部日誌（預寫日誌）寫入單獨的高速設備（如SSD，NVMe或NVDIMM）以提升性能。若是有大量更快的存儲空間可用，內部元數據也能夠存儲在速度更快的設備上。
高效的寫時複製。 RBD和CephFS快照依賴於在BlueStore中高效實現的寫時複製克隆機制。這能爲常規快照和erasure coded pools（依賴於克隆以實現有效的兩階段提交）實現更高效的IO。

FILESTORE

FileStore是在Ceph中存儲對象的傳統方法。它依賴於標準文件系統（一般爲XFS）與鍵/值數據庫（傳統上爲LevelDB，現爲RocksDB）的組合，用於某些元數據。FileStore通過了充分測試並普遍用於生產，但因爲其總體設計和依賴傳統文件系統來存儲對象數據而遭受許多性能缺陷。雖然FileStore一般可以在大多數POSIX兼容的文件系統（包括btrfs和ext4）上運行，但咱們只建議使用XFS。 btrfs和ext4都有已知的漏洞和缺陷，它們的使用可能會致使數據丟失。默認狀況下，全部Ceph配置工具都將使用XFS。後端

OSD 守護進程有賴於底層文件系統的擴展屬性（ XATTR ）存儲各類內部對象狀態和元數據。底層文件系統必須能爲 XATTR 提供足夠容量， btrfs 沒有限制隨文件的 xattr 元數據總量； xfs 的限制相對大（ 64KB ），多數部署都不會有瓶頸； ext4 的則過小而不可用。使用 ext4 文件系統時，必定要把下面的配置放於 ceph.conf 配置文件的 [osd] 段下；用 btrfs 和 xfs 時能夠選填。api

filestore xattr use omap = true

配置Ceph

概述

你啓動 Ceph 服務時，初始化進程會把一系列守護進程放到後臺運行。 Ceph存儲集羣運行兩種守護進程：

Ceph 監視器（ ceph-mon ）
Ceph OSD守護進程（ ceph-osd ）

要支持 Ceph 文件系統功能，它還須要運行至少一個 Ceph元數據服務器（ ceph-mds ）；支持 Ceph 對象存儲功能的集羣還要運行網關守護進程（ radosgw ）。爲方便起見，各種守護進程都有一系列默認值（不少由 ceph/src/common/config_opts.h 配置），你能夠用 Ceph 配置文件覆蓋這些默認值。

選項名稱

全部Ceph配置選項都有一個惟一的名稱，由用小寫字符組成的單詞組成，並用下劃線（_）字符鏈接。

在命令行中指定選項名稱時，能夠使用下劃線（_）或短劃線（ - ）字符進行互換（例如， - mon-host至關於--mon_host）。

當選項名稱出如今配置文件中時，也能夠使用空格代替下劃線或短劃線。

配置來源

每一個Ceph守護程序，進程和庫將從如下列出的幾個源中提取其配置。當二者都存在時，列表中稍後的源將覆蓋列表中較早的源。

編譯後的默認值
監視器集羣的集中配置數據庫
存儲在本地主機上的配置文件
環境變量
命令行參數
由管理員設置的運行時覆蓋

Ceph進程在啓動時所作的第一件事就是解析經過命令行，環境和本地配置文件提供的配置選項。而後鏈接監視器集羣，檢測配置是否可用。一旦完成檢測，若是配置可用，守護程序或進程啓動就會繼續。

BOOTSTRAP選項
因爲某些配置選項會影響進程聯繫監視器，認證和恢復集羣存儲配置，所以可能須要將它們存儲在本地節點上並設置在本地配置文件中。這些選項包括：

mon_host，集羣的監視器列表
mon_dns_serv_name（默認值：ceph-mon），用於經過DNS檢查以識別集羣監視器的DNS SRV記錄的名稱
mon_data，osd_data，mds_data，mgr_data以及相似的選項用來定義守護程序存儲其數據的本地目錄
keying，ketfile，and/or key，可用於指定用於向監視器進行身份驗證的身份驗證憑據。請注意，在大多數狀況下，默認密鑰環位置位於上面指定的數據目錄中。

在絕大多數狀況下，這些的默認值是合適的，但mon_host選項除外，它標識了集羣監視器的地址。當DNS用於識別監視器時，能夠徹底避免本地ceph配置文件。任何進程能夠經過選項--no-mon-config以跳過從集羣監視器檢索配置的步驟。這在配置徹底經過配置文件管理或監視器集羣當前已關閉但須要執行某些維護活動的狀況下很是有用。

配置

任何給定的進程或守護程序對每一個配置選項都有一個值。可是，選項的值可能會因不一樣的守護程序類型而異，甚至是相同類型的守護程序也會有不一樣的配置。Ceph選項存儲在監視器配置數據庫或本地配置文件中被分組爲多個部分，以指示它們應用於哪些守護程序或客戶端。

這些部分包括：

[global]

　　描述：全局下的設置會影響Ceph存儲集羣中的全部daemon和client。
　　示例：

log_file = /var/log/ceph/$cluster-$type.$id.log

[mon]

　　描述：mon下的設置會影響Ceph存儲集羣中的全部ceph-mon守護進程，並覆蓋全局中的相同設置。
　　示例：mon_cluster_log_to_syslog = true

[mgr]

　　說明：mgr部分中的設置會影響Ceph存儲羣集中的全部ceph-mgr守護程序，並覆蓋全局中的相同設置。
　　示例：mgr_stats_period = 10

[osd]

　　描述：osd下的設置會影響Ceph存儲集羣中的全部ceph-osd守護進程，並覆蓋全局中的相同設置。
　　示例：osd_op_queue = wpq

[mds]

　　描述：mds部分中的設置會影響Ceph存儲集羣中的全部ceph-mds守護程序，並覆蓋全局中的相同設置。
　　示例：mds_cache_size = 10G

[client]

　　描述：客戶端下的設置會影響全部Ceph客戶端（例如，掛載的Ceph文件系統，掛載的Ceph塊設備等）以及Rados Gateway（RGW）守護程序。
　　示例：objecter_inflight_ops = 512

還能夠指定單個守護程序或客戶端名稱。例如，mon.foo，osd.123和client.smith都是有效的節名。

任何給定的守護程序都將從全局部分，守護程序或客戶端類型部分以及指定名稱的部分中提取其設置。指定名稱部分中的設置優先，例如，若是在同一源（即，在同一配置文件中）的global，mon和mon.foo中指定了相同的選項，則將使用mon.foo值。

請注意，本地配置文件中的值始終優先於監視器配置數據庫中的值，而無論它們出如今哪一個部分。

元變量

元變量能夠顯着簡化Ceph存儲集羣配置。當在配置值中設置元變量時，Ceph會在使用配置值時將元變量擴展爲具體值。 Ceph元變量相似於Bash shell中的變量擴展。Ceph支持如下元變量：

$cluster

　　描述：擴展爲Ceph存儲羣集名稱。在同一硬件上運行多個Ceph存儲集羣時頗有用。
　　例如：

/etc/ceph/$cluster.keyring

　　默認值：CEPH

$type

　　描述：擴展爲守護進程或進程類型（例如，mds，osd或mon）
　　例如：

/var/lib/ceph/$type

　　描述：擴展爲守護程序或客戶端標識符。對於osd.0，這將是0; 對於mds.a，它將是a。
　　例如：

/var/lib/ceph/$type/$cluster-$id

$host

　　描述：擴展爲運行進程的主機名。

$name

　　描述：擴展爲

$type.$id

　　例如：

/var/run/ceph/$cluster-$name.asok

$ pid

　　描述：擴展爲守護進程pid。
　　例如：

/var/run/ceph/$cluster-$name-$pid.asok

配置文件

默認的 Ceph 配置文件位置相繼排列以下：

$CEPH_CONF（CEPH_CONF環境變量所指示的路徑）;
-c path / path（-c命令行參數）;
/etc/ceph/ceph.conf
〜/.ceph/配置
./ceph.conf（就是當前所在的工做路徑。
僅限FreeBSD系統， /usr/local/etc/ceph/$cluster.conf

Ceph配置文件使用ini樣式語法。您能夠經過前面的註釋添加註釋，使用'＃'或';'。

監控配置數據庫

監視器集羣管理整個集羣能夠使用的配置選項數據庫，從而爲整個系統提供簡化的中央配置管理。絕大多數配置選項能夠而且應該存儲在此處，以便於管理和透明。少數設置可能仍須要存儲在本地配置文件中，由於它們會影響鏈接到監視器，驗證和獲取配置信息的能力。在大多數狀況下，這僅限於mon_host選項，儘管經過使用DNS SRV記錄也能夠避免這種狀況。

監視器存儲的配置選項有全局部分，守護程序類型部分或特定守護程序部分中，就像配置文件中的選項同樣。此外，選項還能夠具備與其關聯的掩碼，以進一步限制該選項適用於哪些守護進程或客戶端。掩碼有兩種形式：

類型:location：其中type是CRUSH屬性，如rack或host，location是該屬性的值。例如，host：foo將選項限制爲在特定主機上運行的守護程序或客戶端。
class:device-class ：其中device-class是CRUSH設備類的名稱（例如，hdd或ssd）。例如，class：ssd會將選項僅限制爲SSD支持的OSD。（此掩碼對非OSD守護進程或客戶端沒有影響。）

設置配置選項時，能夠是由斜槓（/）字符分隔的服務名稱，掩碼或二者的組合。例如，osd / rack：foo意味着foo機架中的全部OSD守護進程。查看配置選項時，服務名稱和掩碼一般分爲單獨的字段或列，以便於閱讀。

命令

如下CLI命令用於配置集羣：

ceph config dump

　　將轉儲集羣的整個配置數據庫。

ceph config get <who>

　　將轉儲特定守護程序或客戶端（例如，mds.a）的配置，存儲在監視器的配置數據庫中。

ceph config set <who> <option> <value>

　　將在監視器的配置數據庫中設置配置選項。

ceph config show <who>

　　將顯示正在運行的守護程序的報告運行配置。若是還有正在使用的本地配置文件或者在命令行或運行時覆蓋了選項，則這些設置可能與監視器存儲的設置不一樣。選項值的來源將做爲輸出的一部分進行報告。

ceph config assimilate-conf -i <input file> -o <output file>

　　將從輸入文件中提取配置文件，並將任何有效選項移動到監視器的配置數據庫中。任何沒法識別，無效或沒法由monitor控制的設置都將以存儲在輸出文件中的縮寫配置文件的形式返回。此命令對於從舊配置文件轉換爲基於監視器的集中式配置很是有用。

help

您能夠經過如下方式得到特定選項的幫助：

ceph config help <option>

請注意，這將使用已經編譯到正在運行的監視器中的配置架構。若是您有一個混合版本的集羣（例如，在升級期間），您可能還想從特定的運行守護程序中查詢選項模式：

ceph daemon <name> config help [option]

例如

[root@node1 ~]# ceph config help log_file log_file - path to log file (std::string, basic) Default (non-daemon): Default (daemon): /var/log/ceph/$cluster-$name.log Can update at runtime: false See also: [log_to_stderr,err_to_stderr,log_to_syslog,err_to_syslog]

或

[root@node1 ~]# ceph config help log_file -f json-pretty { "name": "log_file", "type": "std::string", "level": "basic", "desc": "path to log file", "long_desc": "", "default": "", "daemon_default": "/var/log/ceph/$cluster-$name.log", "tags": [], "services": [], "see_also": [ "log_to_stderr", "err_to_stderr", "log_to_syslog", "err_to_syslog" ], "enum_values": [], "min": "", "max": "", "can_update_at_runtime": false }

level屬性能夠是basic，advanced或dev中的任何一個。開發選項供開發人員使用，一般用於測試目的，不建議操做員使用。

運行時修改

在大多數狀況下，Ceph容許您在運行時更改守護程序的配置。此功能對於增長/減小日誌記錄輸出，啓用/禁用調試設置，甚至用於運行時優化很是有用。

通常來講，配置選項能夠經過ceph config set命令以一般的方式更新。例如，在特定OSD上啓用調試日誌級別：

ceph config set osd.123 debug_ms 20

請注意，若是在本地配置文件中也自定義了相同的選項，則將忽略監視器設置（其優先級低於本地配置文件）。

覆蓋參數值

您還能夠使用Ceph CLI上的tell或daemon接口臨時設置選項。這些覆蓋值是短暫的，由於它們隻影響正在運行的進程，而且在守護進程或進程從新啓動時被丟棄/丟失。

覆蓋值能夠經過兩種方式設置：

1.從任何主機，咱們均可以經過網絡向守護進程發送消息：

ceph tell osd.123 config set debug_osd 20

tell命令還能夠接受守護程序標識符的通配符。例如，要調整全部OSD守護進程的調試級別：

ceph tell osd.* config set debug_osd 20

2.從進程運行的主機開始，咱們能夠經過/ var / run / ceph中的套接字直接鏈接到進程：

ceph daemon <name> config set <option> <value>

例如

ceph daemon osd.4 config set debug_osd 20

請注意，在ceph config show命令輸出中，這些臨時值將顯示爲覆蓋源。

查看運行參數值

您能夠使用ceph config show命令查看爲正在運行的守護程序設置的參數。例如：

ceph config show osd.0

將顯示該守護進程的（非默認）選項。您還能夠經過如下方式查看特定選項：

ceph config show osd.0 debug_osd

或查看全部選項（即便是那些具備默認值的選項）：

ceph config show-with-defaults osd.0

您還能夠經過管理套接字從本地主機鏈接到該守護程序來觀察正在運行的守護程序的設置。例如：

ceph daemon osd.0 config show

將轉儲全部當前設置：

ceph daemon osd.0 config diff

將僅顯示非默認設置（以及值來自的位置：配置文件，監視器，覆蓋等），以及：

ceph daemon osd.0 config get debug_osd

將報告單個選項的值。

經常使用設置

概述

單個Ceph節點能夠運行多個守護進程。例如，具備多個驅動器的單個節點能夠爲每一個驅動器運行一個ceph-osd。理想狀況下，某些節點只運行特定的daemon。例如，一些節點能夠運行ceph-osd守護進程，其餘節點能夠運行ceph-mds守護進程，還有其餘節點能夠運行ceph-mon守護進程。

每一個節點都有一個由主機設置標識的名稱。監視器還指定由addr設置標識的網絡地址和端口（即域名或IP地址）。基本配置文件一般僅爲每一個監視器守護程序實例指定最小設置。例如：

[global] mon_initial_members = ceph1 mon_host = 10.0.0.1

主機設置是節點的短名稱（即，不是fqdn）。它也不是IP地址。在命令行中輸入hostname -s以檢索節點的名稱。除非您手動部署Ceph，不然請勿將主機設置用於初始監視器之外的任何其餘設置。在使用chef或ceph-deploy等部署工具時，您不能在各個守護程序下指定主機，這些工具將在集羣映射中爲您輸入適當的值。

網絡

有關配置與Ceph一塊兒使用的網絡的詳細討論，請參閱網絡配置參考。

監控

Ceph生產集羣一般使用至少3個Ceph Monitor守護程序進行部署，以確保監視器實例崩潰時的高可用性。至少三（3）個監視器確保Paxos算法能夠肯定哪一個版本的Ceph Cluster Map是法定人數中大多數Ceph監視器的最新版本。

注意您能夠使用單個監視器部署Ceph，但若是實例失敗，則缺乏其餘監視器可能會中斷數據服務可用性。

Ceph監視器一般偵聽端口6789.例如：

[mon.a] host = hostName mon addr = 150.140.130.120:6789

默認狀況下，Ceph但願您將如下列路徑存儲監視器的數據：

/var/lib/ceph/mon/$cluster-$id

您或部署工具（例如，ceph-deploy）必須建立相應的目錄。在徹底表達元變量和名爲「ceph」的集羣的狀況下，上述目錄將評估爲：

/var/lib/ceph/mon/ceph-a

有關其餘詳細信息，請參閱「監視器配置參考」。

認證

Bobtail版本的新功能：0.56

對於Bobtail（v 0.56）及更高版本，您應該在Ceph配置文件的[global]部分中明確啓用或禁用身份驗證。

auth cluster required = cephx auth service required = cephx auth client required = cephx

此外，您應該啓用message signing（消息簽名）。升級時，咱們建議先明確禁用身份驗證，而後再執行升級。升級完成後，從新啓用身份驗證。有關詳細信息，請參閱Cephx配置參考。

OSD

Ceph生產集羣一般部署Ceph OSD守護進程，通常一個OSD守護進程運行在一個存儲驅動器上。典型部署指定jorunal大小。例如：

[osd] osd journal size = 10000 [osd.0] host = {hostname} #manual deployments only.

默認狀況下，Ceph但願您使用如下路徑存儲Ceph OSD守護程序的數據：

/var/lib/ceph/osd/$cluster-$id

您或部署工具（例如，ceph-deploy）必須建立相應的目錄。在徹底表達元變量和名爲「ceph」的集羣的狀況下，上述目錄將評估爲：

/var/lib/ceph/osd/ceph-0

您能夠使用osd數據設置覆蓋此路徑。咱們不建議更改默認位置。在OSD主機上建立默認目錄。

ssh {osd-host} sudo mkdir /var/lib/ceph/osd/ceph-{osd-number}

osd數據路徑理想地致使具備硬盤的安裝點，該硬盤與存儲和運行操做系統和守護進程的硬盤分開。若是OSD用於操做系統磁盤之外的磁盤，請準備與Ceph一塊兒使用，並將其安裝到剛剛建立的目錄中：

ssh {new-osd-host} sudo mkfs -t {fstype} /dev/{disk} sudo mount -o user_xattr /dev/{hdd} /var/lib/ceph/osd/ceph-{osd-number}

咱們建議在運行mkfs時使用xfs文件系統。（不建議使用btrfs和ext4，再也不測試。）有關其餘配置詳細信息，請參閱OSD配置參考。

心跳

在運行時操做期間，Ceph OSD守護進程檢查其餘Ceph OSD守護進程並將其發現報告給Ceph Monitor。您沒必要提供任何設置。可是，若是您遇到網絡延遲問題，則可能但願修改設置。

有關其餘詳細信息，請參閱配置Monitor / OSD Interaction。

日誌/調試

有時您可能會遇到Ceph須要修改日誌記錄輸出和使用Ceph調試的問題。有關日誌輪換的詳細信息，請參閱調試和日誌記錄。

ceph.conf示例

[global] fsid = {cluster-id} mon initial members = {hostname}[, {hostname}] mon host = {ip-address}[, {ip-address}] #All clusters have a front-side public network. #If you have two NICs, you can configure a back side cluster #network for OSD object replication, heart beats, backfilling, #recovery, etc. public network = {network}[, {network}] #cluster network = {network}[, {network}] #Clusters require authentication by default. auth cluster required = cephx auth service required = cephx auth client required = cephx #Choose reasonable numbers for your journals, number of replicas #and placement groups. osd journal size = {n} osd pool default size = {n} # Write an object n times. osd pool default min size = {n} # Allow writing n copy in a degraded state. osd pool default pg num = {n} osd pool default pgp num = {n} #Choose a reasonable crush leaf type. #0 for a 1-node cluster. #1 for a multi node cluster in a single rack #2 for a multi node, multi chassis cluster with multiple hosts in a chassis #3 for a multi node cluster with hosts across racks, etc. osd crush chooseleaf type = {n}

運行多集羣

使用Ceph，您能夠在同一硬件上運行多個Ceph存儲集羣。與在具備不一樣CRUSH規則的同一羣集上使用不一樣池相比，運行多個羣集可提供更高級別的隔離。單獨的羣集將具備單獨的監視器，OSD和元數據服務器進程。使用默認設置運行Ceph時，默認羣集名稱爲ceph，這意味着您將在/ etc / ceph默認目錄中保存Ceph配置文件，文件名爲ceph.conf。

有關詳細信息，請參閱ceph-deploy new。 .. _ceph-deploy new：../ ceph-deploy-new

運行多個羣集時，必須爲羣集命名並使用羣集名稱保存Ceph配置文件。例如，名爲openstack的集羣將在/ etc / ceph缺省目錄中具備文件名爲openstack.conf的Ceph配置文件。

羣集名稱必須僅包含字母a-z和數字0-9。

單獨的集羣意味着單獨的數據磁盤和日誌，它們不在集羣之間共享。 cluster元變量表明集羣名稱（即前面例子中的openstack）。各類設置使用cluster元變量，包括：

keyring
admin socket
log file
pid file
mon data
mon cluster log file
osd data
osd journal
mds data
rgw data

建立默認目錄或文件時，應在路徑中的適當位置使用羣集名稱。例如：

sudo mkdir /var/lib/ceph/osd/openstack-0 sudo mkdir /var/lib/ceph/mon/openstack-a

在同一主機上運行監視器時，應使用不一樣的端口。默認狀況下，監視器使用端口6789.若是已使用端口6789使用監視器，請爲其餘羣集使用不一樣的端口。

ceph -c {cluster-name}.conf health ceph -c openstack.conf health

網絡設置

概述

網絡配置對構建高性能 Ceph存儲來講至關重要。 Ceph 存儲集羣不會表明 Ceph客戶端執行請求路由或調度，相反， Ceph 客戶端（如塊設備、 CephFS 、 REST 網關）直接向 OSD 請求，而後OSD爲客戶端執行數據複製，也就是說複製和其它因素會額外增長集羣網的負載。

咱們的快速入門配置提供了一個簡陋的 Ceph配置文件，其中只設置了監視器 IP 地址和守護進程所在的主機名。若是沒有配置集羣網，那麼 Ceph 假設你只有一個「公共網」。只用一個網能夠運行 Ceph ，可是在大型集羣裏用單獨的「集羣」網可顯著地提高性能。

咱們建議用兩個網絡運營 Ceph 存儲集羣：一個公共網（前端）和一個集羣網（後端）。爲此，各節點得配備多個網卡

運營兩個獨立網絡的考量主要有：

性能： OSD 爲客戶端處理數據複製，複製多份時 OSD 間的網絡負載勢必會影響到客戶端和 Ceph 集羣的通信，包括延時增長、產生性能問題；恢復和重均衡也會顯著增長公共網延時。
安全：大多數人都是良民，不多的一撮人喜歡折騰拒絕服務攻擊（ DoS ）。當 OSD 間的流量失控時，歸置組不再能達到 active + clean 狀態，這樣用戶就不能讀寫數據了。挫敗此類攻擊的一種好方法是維護一個徹底獨立的集羣網，使之不能直連互聯網；另外，請考慮用消息簽名防止欺騙攻擊。

防火牆

守護進程默認會綁定到6800：7300間的端口，你能夠更改此範圍。更改防火牆配置前先檢查下iptables配置。

sudo iptables -L

某些Linux發行版規矩拒絕除SSH以外全部網絡接口的的全部入站請求。例如：

REJECT all -- anywhere anywhere reject-with icmp-host-prohibited

你得先刪掉公共網和集羣網對應的這些規則，而後再增長安全保護規則。

監視器默認監聽6789端口，並且監視器老是運行在公共網。按下例增長規則時，要把{iface}替換爲公共網接口（如eth0，eth1等等），{ip-address}替換爲公共網IP，{netmask}替換爲公共網掩碼。

sudo iptables -A INPUT -i {iface} -p tcp -s {ip-address}/{netmask} --dport 6789 -j ACCEPT

MDS服務器會監聽公共網6800以上的第一個可用端口。須要注意的是，這種行爲是不肯定的，因此若是你在同一主機上運行多個OSD或MDS，或者在很短的時間內重啓了多個守護進程，它們會綁定更高的端口號;因此說你應該預先打開整個6800-7300端口區間。按下例增長規則時，要把{iface}替換爲公共網接口（如eth0 ，eth1等等），{ip-address}替換爲公共網IP，{netmask}替換爲公共網掩碼。

sudo iptables -A INPUT -i {iface} -m multiport -p tcp -s {ip-address}/{netmask} --dports 6800:7300 -j ACCEPT

OSD守護進程默認綁定從6800起的第一個可用端口，須要注意的是，這種行爲是不肯定的，因此若是你在同一主機上運行多個OSD或MDS，或者在很短的時間內重啓了多個守護進程，它們會綁定更高的端口號。一主機上的各個OSD最多會用到4個端口：
　　1.一個用於和客戶端，監視器通信;
　　2.一個用於發送數據到其餘OSD;
　　3.兩個用於各個網卡上的心跳;

當某個守護進程失敗並重啓時沒釋放端口，重啓後的進程就會監聽新端口。你應該打開整個6800-7300端口區間，以應對這種可能性。

若是你分開了公共網和集羣網，必須分別爲之設置防火牆，由於客戶端會經過公共網鏈接，而其餘OSD會經過集羣網鏈接。按下例增長規則時，要把{iface}替換爲網口（如eth0，eth1等等），{ip-address}替換爲公共網或集羣網IP，{netmask}替換爲公共網或集羣網掩碼。例如：

sudo iptables -A INPUT -i {iface} -m multiport -p tcp -s {ip-address}/{netmask} --dports 6800:7300 -j ACCEPT

若是你的元數據服務器和OSD在同一節點上，能夠合併公共網配置。

Ceph網絡

Ceph 的網絡配置要放到 [global] 段下。前述的 5 分鐘快速入門提供了一個簡陋的 Ceph 配置文件，它假設服務器和客戶端都位於同一網段， Ceph 能夠很好地適應這種情形。然而 Ceph 容許配置更精細的公共網，包括多 IP 和多掩碼；也能用單獨的集羣網處理 OSD 心跳、對象複製、和恢復流量。不要混淆你配置的 IP 地址和客戶端用來訪問存儲服務的公共網地址。典型的內網經常是 192.168.0.0 或 10.0.0.0 。

若是你給公共網或集羣網配置了多個 IP 地址及子網掩碼，這些子網必須能互通。另外要確保在防火牆上爲各 IP 和子網開放了必要的端口。Ceph用CIDR法表示子網，如10.0.0.0/24。

配置完幾個網絡後，能夠重啓集羣或挨個重啓守護進程.Ceph守護進程動態地綁定端口，因此更改網絡配置後無需重啓整個集羣。

公共網絡
要配置公共網絡，請將如下選項添加到Ceph配置文件的[global]部分。

[global] # ... elided configuration public network = {public-network/netmask}

集羣網絡
若是聲明羣集網絡，OSD將經過羣集網絡路由心跳，對象複製和恢復流量。與使用單個網絡相比，這能夠提升性能。要配置羣集網絡，請將如下選項添加到Ceph配置文件的[global]部分。

[global] # ... elided configuration cluster network = {cluster-network/netmask}

咱們但願沒法從公共網絡或Internet訪問羣集網絡以加強安全性。

Ceph Daemon

有一個網絡配置是全部守護進程都要配的：各個守護進程都必須指定主機，Ceph也要求指定監視器IP地址及端口。一些部署工具（如ceph-deploy，Chef）會給你建立配置文件，若是它能勝任那就別設置這些值。主機選項是主機的短名，不是全資域名FQDN，也不是IP地址。在命令行下輸入主機名-s獲取主機名。

[mon.a] host = {hostname} mon addr = {ip-address}:6789 [osd.0] host = {hostname}

您沒必要爲守護程序設置主機IP地址。若是您具備靜態IP配置而且公共和集羣網絡都在運行，則Ceph配置文件能夠爲每一個守護程序指定主機的IP地址。要爲守護程序設置靜態IP地址，如下選項應出如今ceph.conf文件的守護程序實例部分中。

[osd.0] public addr = {host-public-ip-address} cluster addr = {host-cluster-ip-address}

單網卡OSD，雙網絡集羣

通常來講，咱們不建議用單網卡OSD主機部署兩個網絡。然而這事能夠實現，把公共地址選擇配在[osd.n]段下便可強制OSD主機運行在公共網，其中n是其 OSD號。另外，公共網和集羣網必須互通，考慮到安全因素咱們不建議這樣作。

網絡配置選項

網絡配置選項不是必需的，Ceph假設全部主機都運行於公共網，除非你特地配置了一個集羣網。

公共網

公共網配置用於明確地爲公共網定義IP地址和子網。你能夠分配靜態IP或用public addr覆蓋public network選項。

public network 描述:公共網（前端）的 IP 地址和掩碼（如 192.168.0.0/24 ），置於 [global] 下。多個子網用逗號分隔。 類型:{ip-address}/{netmask} [, {ip-address}/{netmask}] 是否必需:No 默認值:N/A public addr 描述:用於公共網（前端）的 IP 地址。適用於各守護進程。 類型:IP 地址 是否必需:No 默認值:N/A

集羣網

集羣網配置用來聲明一個集羣網，並明確地定義其 IP 地址和子網。你能夠配置靜態 IP 或爲某 OSD 守護進程配置 cluster addr 以覆蓋 cluster network 選項。

cluster network 描述:集羣網（後端）的 IP 地址及掩碼（如 10.0.0.0/24 ），置於 [global] 下。多個子網用逗號分隔。 類型:{ip-address}/{netmask} [, {ip-address}/{netmask}] 是否必需:No 默認值:N/A cluster addr 描述:集羣網（後端） IP 地址。置於各守護進程下。 類型:Address 是否必需:No 默認值:N/A

綁定

綁定選項用於設置 OSD 和 MDS 默認使用的端口範圍，默認範圍是 6800:7300 。確保防火牆開放了對應端口範圍。

你也可讓 Ceph 守護進程綁定到 IPv6 地址。

ms bind port min 描述:OSD 或 MDS 可綁定的最小端口號。 類型:32-bit Integer 默認值:6800 是否必需:No ms bind port max 描述:OSD 或 MDS 可綁定的最大端口號。 類型:32-bit Integer 默認值:7300 是否必需:No. ms bind ipv6 描述:容許 Ceph 守護進程綁定 IPv6 地址。 類型:Boolean 默認值:false 是否必需:No

主機

Ceph 配置文件裏至少要寫一個監視器、且每一個監視器下都要配置 mon addr 選項；每一個監視器、元數據服務器和 OSD 下都要配 host 選項。

mon addr 描述:{hostname}:{port} 條目列表，用以讓客戶端鏈接 Ceph 監視器。若是未設置， Ceph 查找 [mon.*] 段。 類型:String 是否必需:No 默認值:N/A host 描述:主機名。此選項用於特定守護進程，如 [osd.0] 。 類型:String 是否必需:Yes, for daemon instances. 默認值:localhost

不要用 localhost 。在命令行下執行 hostname -s 獲取主機名（到第一個點，不是全資域名），並用於配置文件。用第三方部署工具時不要指定 host 選項，它會自行獲取。

TCP

Ceph 默認禁用 TCP 緩衝。

ms tcp nodelay 描述:Ceph 用 ms tcp nodelay 使系統儘快（不緩衝）發送每一個請求。禁用 Nagle 算法可增長吞吐量，但會引進延時。若是你遇到大量小包，能夠禁用 ms tcp nodelay 試試。 類型:Boolean 是否必需:No 默認值:true ms tcp rcvbuf 描述:網絡套接字接收緩衝尺寸，默認禁用。 類型:32-bit Integer 是否必需:No 默認值:0 ms tcp read timeout 描述:若是一客戶端或守護進程發送請求到另外一個 Ceph 守護進程，且沒有斷開再也不使用的鏈接，在 ms tcp read timeout 指定的秒數以後它將被標記爲空閒。 類型:Unsigned 64-bit Integer 是否必需:No 默認值:900 15 minutes.

認證設置

概述

cephx協議已經默認開啓。加密認證要耗費必定計算資源，但一般很低。若是您的客戶端和服務器網絡環境至關安全，並且認證的負面效應更大，你能夠關閉它，一般不推薦您這麼作。若是禁用了認證，就會有篡改客戶端/服務器消息這樣的中間人攻擊風險，這會致使災難性後果。

部署情景

部署Ceph集羣有兩種主要方案，這會影響您最初配置Cephx的方式。 Ceph用戶大多數第一次使用ceph-deploy來建立集羣（最簡單）。對於使用其餘部署工具（例如，Chef，Juju，Puppet等）的集羣，您將須要使用手動過程或配置部署工具來引導您的監視器。

CEPH-DEPLOY

使用ceph-deploy部署集羣時，您沒必要手動引導監視器或建立client.admin用戶或密鑰環。您在Storage Cluster快速入門中執行的步驟將調用ceph-deploy爲您執行此操做。

當您執行ceph-deploy new {initial-monitor（s）}時，Ceph將爲您建立一個監視密鑰環（僅用於引導監視器），它將爲您生成一個初始Ceph配置文件，其中包含如下身份驗證設置，代表Ceph默認啓用身份驗證：

auth_cluster_required = cephx auth_service_required = cephx auth_client_required = cephx

當您執行ceph-deploy mon create-initial時，Ceph將引導初始監視器，檢索包含client.admin用戶密鑰的ceph.client.admin.keyring文件。此外，它還將檢索密鑰環，使ceph-deploy和ceph-volume實用程序可以準備和激活OSD和元數據服務器。

當您執行ceph-deploy admin {node-name}時（注意：首先必須安裝Ceph），您將Ceph配置文件和ceph.client.admin.keyring推送到節點的/ etc / ceph目錄。您將可以在該節點的命令行上以root身份執行Ceph管理功能。

手動部署

手動部署集羣時，必須手動引導監視器並建立client.admin用戶和密鑰環。要引導監視器，請按照 Monitor Bootstrapping中的步驟操做。監視器引導的步驟是使用Chef，Puppet，Juju等第三方部署工具時必須執行的邏輯步驟。

啓用/禁用CEPHX

爲監視器，OSD和元數據服務器部署密鑰時需啓用Cephx。若是你只是打開/關閉Cephx，你沒必要重複bootstrapping程序。

啓用Cephx

啓用cephx後，Ceph將在默認搜索路徑（包括/etc/ceph/ceph.$name.keyring）裏查找密鑰環。你能夠在Ceph配置文件的[global]段裏添加keyring選項來修改，但不推薦。

在禁用了cephx的集羣上執行下面的步驟來啓用它，若是你（或者部署工具）已經生成了密鑰，你能夠跳過相關的步驟。

1.建立client.admin密鑰，併爲客戶端保存此密鑰的副本：

ceph auth get-or-create client.admin mon 'allow *' mds 'allow *' osd 'allow *' -o /etc/ceph/ceph.client.admin.keyring

警告：此命令會覆蓋任何存在的/etc/ceph/client.admin.keyring文件，若是部署工具已經完成此步驟，千萬別再執行此命令。多加當心！

2.建立監視器集羣所需的密鑰環，並給它們生成密鑰。

ceph-authtool --create-keyring /tmp/ceph.mon.keyring --gen-key -n mon. --cap mon 'allow *'

3.把監視器密鑰環複製到ceph.mon.keyring文件，再把此文件複製到各監視器的mon數據目錄下。好比要把它複製給名爲ceph集羣的mon.a，用此命令：

cp /tmp/ceph.mon.keyring /var/lib/ceph/mon/ceph-a/keyring

4.爲每一個MGR生成密鑰，{$ id}是OSD編號：

ceph auth get-or-create mgr.{$id} mon 'allow profile mgr' mds 'allow *' osd 'allow *' -o /var/lib/ceph/mgr/ceph-{$id}/keyring

5.爲每一個 OSD 生成密鑰， {$id} 是 MDS 的標識字母：

ceph auth get-or-create osd.{$id} mon 'allow rwx' osd 'allow *' -o /var/lib/ceph/osd/ceph-{$id}/keyring

6.爲每一個 MDS 生成密鑰， {$id} 是 MDS 的標識字母：

ceph auth get-or-create mds.{$id} mon 'allow rwx' osd 'allow *' mds 'allow *' mgr 'allow profile mds' -o /var/lib/ceph/mds/ceph-{$id}/keyring

7.把如下配置加入 Ceph 配置文件的 [global] 段下以啓用 cephx 認證：

auth cluster required = cephx auth service required = cephx auth client required = cephx

8.啓動或重啓Ceph集羣

禁用Cephx

下述步驟描述瞭如何禁用Cephx。若是你的集羣環境相對安全，你能夠減免認證耗費的計算資源，然而咱們不推薦。可是臨時禁用認證會使安裝，和/或排障更簡單。

1.把下列配置加入Ceph配置文件的[global]段下便可禁用cephx認證：

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

2.啓動或重啓Ceph集羣

配置選項

啓動

auth cluster required 描述:若是啓用了，集羣守護進程（如 ceph-mon 、 ceph-osd 和 ceph-mds ）間必須相互認證。可用選項有 cephx 或 none 。 類型:String 是否必需:No 默認值:cephx. auth service required 描述:若是啓用，客戶端要訪問 Ceph 服務的話，集羣守護進程會要求它和集羣認證。可用選項爲 cephx 或 none 。 類型:String 是否必需:No 默認值:cephx. auth client required 描述:若是啓用，客戶端會要求 Ceph 集羣和它認證。可用選項爲 cephx 或 none 。 類型:String 是否必需:No 默認值:cephx.

密鑰

若是你的集羣啓用了認證， ceph 管理命令和客戶端得有密鑰才能訪問集羣。

給 ceph 管理命令和客戶端提供密鑰的最經常使用方法就是把密鑰環放到 /etc/ceph ，經過 ceph-deploy 部署的 Cuttlefish 及更高版本，其文件名一般是ceph.client.admin.keyring （或 $cluster.client.admin.keyring ）。若是你的密鑰環位於 /etc/ceph 下，就不須要在 Ceph 配置文件裏指定 keyring 選項了。

咱們建議把集羣的密鑰環複製到你執行管理命令的節點，它包含 client.admin 密鑰。

你能夠用 ceph-deploy admin 命令作此事，手動複製可執行此命令：

sudo scp {user}@{ceph-cluster-host}:/etc/ceph/ceph.client.admin.keyring /etc/ceph/ceph.client.admin.keyring

確保給客戶端上的ceph.keyring設置合理的權限位（如chmod 644）。

你能夠用 key 選項把密鑰寫在配置文件裏（不推薦），或者用 keyfile 選項指定個路徑。

keyring 描述:密鑰環文件的路徑。 類型:String 是否必需:No 默認值:/etc/ceph/$cluster.$name.keyring,/etc/ceph/$cluster.keyring,/etc/ceph/keyring,/etc/ceph/keyring.bin keyfile 描述:到密鑰文件的路徑，如一個只包含密鑰的文件。 類型:String 是否必需:No 默認值:None key 描述:密鑰（密鑰文本），最好別這樣作。 類型:String 是否必需:No 默認值:None

DAEMON KEYRINGS
管理用戶或部署工具（例如，ceph-deploy）能夠以與生成用戶密鑰環相同的方式生成守護進程密鑰環。默認狀況下，Ceph將守護進程密鑰環存儲在其數據目錄中。默認密鑰環位置以及守護程序運行所需的功能以下所示。

ceph-mon Location: $mon_data/keyring Capabilities: mon 'allow *' ceph-osd Location: $osd_data/keyring Capabilities: mgr 'allow profile osd' mon 'allow profile osd' osd 'allow *' ceph-mds Location: $mds_data/keyring Capabilities: mds 'allow' mgr 'allow profile mds' mon 'allow profile mds' osd 'allow rwx' ceph-mgr Location: $mgr_data/keyring Capabilities: mon 'allow profile mgr' mds 'allow *' osd 'allow *' radosgw Location: $rgw_data/keyring Capabilities: mon 'allow rwx' osd 'allow rwx'

監視器密鑰環（即 mon. ）包含一個密鑰，但沒有能力，且不是集羣 auth 數據庫的一部分。

守護進程數據目錄位置默認格式以下：

/var/lib/ceph/$type/$cluster-$id

例如， osd.12 的目錄會是：

/var/lib/ceph/osd/ceph-12

你能夠覆蓋這些位置，但不推薦。

簽名

在 Bobtail 及後續版本中， Ceph 會用開始認證時生成的會話密鑰認證全部在線實體。然而 Argonaut 及以前版本不知道如何認證在線消息，爲保持向後兼容性（如在同一個集羣裏運行 Bobtail 和 Argonaut ），消息簽名默認是關閉的。若是你只運行 Bobtail 和後續版本，可讓 Ceph 要求籤名。

像 Ceph 認證的其餘部分同樣，客戶端和集羣間的消息簽名也能作到細粒度控制；並且能啓用或禁用 Ceph 守護進程間的簽名。

cephx require signatures 描述:若設置爲 true ， Ceph 集羣會要求客戶端簽名全部消息，包括集羣內其餘守護進程間的。 類型:Boolean 是否必需:No 默認值:false cephx cluster require signatures 描述:若設置爲 true ， Ceph 要求集羣內全部守護進程簽名相互之間的消息。 類型:Boolean 是否必需:No 默認值:false cephx service require signatures 描述:若設置爲 true ， Ceph 要求籤名全部客戶端和集羣間的消息。 類型:Boolean 是否必需:No 默認值:false 
cephx sign messages 描述:若是 Ceph 版本支持消息簽名， Ceph 會簽名全部消息以防欺騙。 類型:Boolean 默認值:true

生存期

auth service ticket ttl
描述:Ceph 存儲集羣發給客戶端一個用於認證的票據時分配給這個票據的生存期。 類型:Double 默認值:60*60

Monitor設置

概述

理解如何配置Ceph監視器是構建可靠的Ceph存儲集羣的重要方面，任何Ceph集羣都須要至少一個監視器。一個監視器一般至關一致，可是你能夠增長，刪除，或替換集羣中的監視器

背景

監視器們維護着集羣運行圖的「主副本」，就是說客戶端連到一個監視器並獲取當前運行圖就能肯定全部監視器、 OSD 和元數據服務器的位置。 Ceph 客戶端讀寫 OSD 或元數據服務器前，必須先連到一個監視器，靠當前集羣運行圖的副本和 CRUSH 算法，客戶端能計算出任何對象的位置，故此客戶端有能力直接連到 OSD ，這對 Ceph 的高伸縮性、高性能來講很是重要。監視器的主要角色是維護集羣運行圖的主副本，它也提供認證和日誌記錄服務。 Ceph 監視器們把監視器服務的全部更改寫入一個單獨的 Paxos 例程，而後 Paxos 以鍵/值方式存儲全部變動以實現高度一致性。同步期間， Ceph 監視器能查詢集羣運行圖的近期版本，它們經過操做鍵/值存儲快照和迭代器（用 leveldb ）來進行存儲級同步

自0.58版以來已棄用
在0.58及更早版本中，Ceph監視器每一個服務用一個Paxos例程，並把運行圖存儲爲文件。

CLUSTER MAPS

集羣運行圖是多個圖的組合，包括監視器圖、 OSD 圖、歸置組圖和元數據服務器圖。集羣運行圖追蹤幾個重要事件：哪些進程在集羣裏（ in ）；哪些進程在集羣裏（ in ）是 up 且在運行、或 down ；歸置組狀態是 active 或 inactive 、 clean 或其餘狀態；和其餘反映當前集羣狀態的信息，像總存儲容量、和使用量。

當集羣狀態有明顯變動時，如一 OSD 掛了、一歸置組降級了等等，集羣運行圖會被更新以反映集羣當前狀態。另外，監視器也維護着集羣的主要狀態歷史。監視器圖、 OSD 圖、歸置組圖和元數據服務器圖各自維護着它們的運行圖版本。咱們把各圖的版本稱爲一個 epoch 。

運營集羣時，跟蹤這些狀態是系統管理任務的重要部分。

MONITOR QUORUM

本文入門部分提供了一個簡陋的 Ceph 配置文件，它提供了一個監視器用於測試。只用一個監視器集羣能夠良好地運行，然而單監視器是一個單故障點，生產集羣要實現高可用性的話得配置多個監視器，這樣單個監視器的失效纔不會影響整個集羣。

集羣用多個監視器實現高可用性時，多個監視器用 Paxos 算法對主集羣運行圖達成一致，這裏的一致要求大多數監視器都在運行且夠成法定人數（如 1 個、 3 之 2 在運行、 5 之 3 、 6 之 4 等等）。

mon force quorum join 描述：強制監視器加入仲裁，即便它先前已從MAP中刪除 類型：Boolean 默認值：false

一致性

你把監視器加進 Ceph 配置文件時，得注意一些架構問題， Ceph 發現集羣內的其餘監視器時對其有着嚴格的一致性要求。儘管如此， Ceph 客戶端和其餘 Ceph 守護進程用配置文件發現監視器，監視器卻用監視器圖（ monmap ）相互發現而非配置文件。

一個監視器發現集羣內的其餘監視器時老是參考 monmap 的本地副本，用 monmap 而非 Ceph 配置文件避免了可能損壞集羣的錯誤（如 ceph.conf 中指定地址或端口的拼寫錯誤）。正由於監視器把 monmap 用於發現、並共享於客戶端和其餘 Ceph 守護進程間， monmap可嚴格地保證監視器的一致性是可靠的。

嚴格的一致性也適用於 monmap 的更新，由於關於監視器的任何更新、關於 monmap 的變動都是經過稱爲 Paxos 的分佈式一致性算法傳遞的。監視器們必須就 monmap 的每次更新達成一致，以確保法定人數裏的每一個監視器 monmap 版本相同，如增長、刪除一個監視器。 monmap 的更新是增量的，因此監視器們都有最新的一致版本，以及一系列以前版本。歷史版本的存在容許一個落後的監視器跟上集羣當前狀態。

若是監視器經過配置文件而非 monmap 相互發現，這會引進其餘風險，由於 Ceph 配置文件不是自動更新並分發的，監視器有可能不當心用了較老的配置文件，以至於不認識某監視器、放棄法定人數、或者產生一種 Paxos 不能肯定當前系統狀態的情形

初始化監視器

在大多數配置和部署案例中，部署 Ceph 的工具能夠幫你生成一個監視器圖來初始化監視器（如 ceph-deploy 等），一個監視器須要的選項：

文件系統標識符： fsid 是對象存儲的惟一標識符。由於你能夠在一套硬件上運行多個集羣，因此在初始化監視器時必須指定對象存儲的惟一標識符。部署工具一般可替你完成（如 ceph-deploy 會調用相似 uuidgen 的程序），可是你也能夠手動指定 fsid 。
監視器標識符：監視器標識符是分配給集羣內各監視器的惟一 ID ，它是一個字母數字組合，爲方便起見，標識符一般以字母順序結尾（如 a 、 b 等等），能夠設置於 Ceph 配置文件（如 [mon.a] 、 [mon.b] 等等）、部署工具、或 ceph 命令行工具。
密鑰：監視器必須有密鑰。像 ceph-deploy 這樣的部署工具一般會自動生成，也能夠手動完成。

配置

要把配置應用到整個集羣，把它們放到 [global] 下；要用於全部監視器，置於 [mon] 下；要用於某監視器，指定監視器例程，如 [mon.a] ）。按慣例，監視器例程用字母命名。

[global] [mon] [mon.a] [mon.b] [mon.c]

最小配置

Ceph 監視器的最簡配置必須包括一主機名及其監視器地址，這些配置可置於 [mon] 下或某個監視器下。

[mon] mon host = hostname1,hostname2,hostname3 mon addr = 10.0.0.10:6789,10.0.0.11:6789,10.0.0.12:6789

[mon.a] host = hostname1 mon addr = 10.0.0.10:6789

這裏的監視器最簡配置假設部署工具會自動給你生成 fsid 和 mon. 密鑰。一旦部署了 Ceph 集羣，監視器 IP 地址不該該更改。然而，若是你決意要改，必須嚴格按照更改監視器 IP 地址來改。

客戶端也能夠使用DNS SRV記錄找到監視器

集羣 ID

每一個 Ceph 存儲集羣都有一個惟一標識符（ fsid ）。若是指定了，它應該出如今配置文件的 [global] 段下。部署工具一般會生成 fsid 並存於監視器圖，因此不必定會寫入配置文件， fsid 使得在一套硬件上運行多個集羣成爲可能。

fsid 描述:集羣 ID ，一集羣一個。 類型:UUID 是否必需:Yes. 默認值:無。若未指定，部署工具會生成。

若是你用部署工具就不能設置

初始成員

咱們建議在生產環境下最少部署 3 個監視器，以確保高可用性。運行多個監視器時，你能夠指定爲造成法定人數成員所需的初始監視器，這能減少集羣上線時間。

[mon] mon initial members = a,b,c

mon initial members 描述:集羣啓動時初始監視器的 ID ，若指定， Ceph 須要奇數個監視器來肯定最初法定人數（如 3 ）。 類型:String 默認值:None

數據

Ceph提供Ceph監視器存儲數據的默認路徑。爲了在生產Ceph存儲集羣中得到最佳性能，咱們建議在Ceph OSD守護進程和Ceph Monitor在不一樣主機和驅動器上運行。因爲leveldb使用mmap（）來編寫數據，Ceph Monitors常常將內存中的數據刷新到磁盤，若是數據存儲與OSD守護進程共存，則可能會干擾Ceph OSD守護進程工做負載。

在Ceph版本0.58及更早版本中，Ceph Monitors將其數據存儲在文件中。這種方法容許用戶使用ls和cat等經常使用工具檢查監控數據。可是，它沒有提供強大的一致性。

在 Ceph 0.59 及後續版本中，監視器以鍵/值對存儲數據。監視器須要 ACID 事務，數據存儲的使用可防止監視器用損壞的版本進行恢復，除此以外，它容許在一個原子批量操做中進行多個修改操做。

通常來講咱們不建議更改默認數據位置，若是要改，咱們建議全部監視器統一配置，加到配置文件的 [mon] 下。

mon data 描述：監視器的數據位置。 類型：String 默認值：/var/lib/ceph/mon/$cluster-$id mon data size warn 描述：當監視器的數據存儲超過15GB時，在羣集日誌中發出HEALTH_WARN。 類型：整型 默認值：15 * 1024 * 1024 * 1024 * mon data avail warn 描述：當監視器數據存儲的可用磁盤空間小於或等於此百分比時，在羣集日誌中發出HEALTH_WARN。 類型：整型 默認值：30 mon data avail crit 描述：當監視器數據存儲的可用磁盤空間小於或等於此百分比時，在羣集日誌中發出HEALTH_ERR。 類型：整型 默認值：5 mon warn on cache pools without hit sets 描述：若是緩存池未配置hit_set_type值，則在集羣日誌中發出HEALTH_WARN。有關詳細信息，請參閱hit_set_type。 類型：Boolean 默認值：true mon warn on crush straw calc version zero 描述：若是CRUSH的straw_calc_version爲零，則在集羣日誌中發出HEALTH_WARN。有關詳細信息，請參閱CRUSH map tunables。 類型：Boolean 默認值：true mon warn on legacy crush tunables 描述：若是CRUSH可調參數太舊（早於mon_min_crush_required_version），則在集羣日誌中發出HEALTH_WARN 類型：Boolean 默認值：true mon crush min required version 描述：羣集所需的最小可調參數版本。有關詳細信息，請參閱CRUSH map tunables。 類型：String 默認值：firefly mon warn on osd down out interval zero 描述：if mon osd down out interval is zero，則在集羣日誌中發出HEALTH_WARN。在leader上將此選項設置爲零的行爲與noout標誌很是類似。在沒有設置noout標誌的狀況下很難弄清楚集羣出了什麼問題可是現象差很少，因此咱們在這種狀況下報告一個警告。 類型：Boolean 默認值：true mon cache target full warn ratio 描述：cache_target_full和target_max_object之間，咱們開始警告 類型：float 默認值：0.66 mon health data update interval 描述：仲裁中的監視器與其對等方共享其健康狀態的頻率（以秒爲單位）。 （負數禁用它） 類型：float 默認值：60 mon health to clog 描述：按期啓用向羣集日誌發送運行情況摘要。 類型：Boolean 默認值：true mon health to clog tick interval 描述：監視器將健康摘要發送到羣集日誌的頻率（以秒爲單位）（非正數禁用它）。 若是當前運行情況摘要爲空或與上次相同，則監視器不會將其發送到羣集日誌。 類型：整型 默認值：3600 mon health to clog interval 描述：監視器將健康摘要發送到羣集日誌的頻率（以秒爲單位）（非正數禁用它）。 不管摘要是否更改，Monitor都將始終將摘要發送到羣集日誌。 類型：整型 默認值：60

存儲容量

Ceph 存儲集羣利用率接近最大容量時（即 mon osd full ratio ），做爲防止數據丟失的安全措施，它會阻止你讀寫 OSD 。所以，讓生產集羣用滿可不是好事，由於犧牲了高可用性。 full ratio 默認值是 .95 或容量的 95% 。對小型測試集羣來講這是很是激進的設置。

Tip:監控集羣時，要警戒和 nearfull 相關的警告。這意味着一些 OSD 的失敗會致使臨時服務中斷，應該增長一些 OSD 來擴展存儲容量。

在測試集羣時，一個常見場景是：系統管理員從集羣刪除一個 OSD 、接着觀察重均衡；而後繼續刪除其餘 OSD ，直到集羣達到佔滿率並鎖死。咱們建議，即便在測試集羣裏也要規劃一點空閒容量用於保證高可用性。理想狀況下，要作好這樣的預案：一系列 OSD 失敗後，短期內不更換它們仍能恢復到 active + clean 狀態。你也能夠在 active + degraded 狀態運行集羣，但對正常使用來講並很差。

下圖描述了一個簡化的 Ceph 集羣，它包含 33 個節點、每主機一個 OSD 、每 OSD 3TB 容量，因此這個小白鼠集羣有 99TB 的實際容量，其 mon osd full ratio 爲 .95 。若是它只剩餘 5TB 容量，集羣就不容許客戶端再讀寫數據，因此它的運行容量是 95TB ，而非 99TB 。

在這樣的集羣裏，壞一或兩個 OSD 很日常；一種罕見但可能發生的情形是一個機架的路由器或電源掛了，這會致使多個 OSD 同時離線（如 OSD 7-12 ），在這種狀況下，你仍要力爭保持集羣可運行並達到 active + clean 狀態，即便這意味着你得在短時間內額外增長一些 OSD 及主機。若是集羣利用率過高，在解決故障域期間也許不會丟數據，但極可能犧牲數據可用性，由於利用率超過了 full ratio 。故此，咱們建議至少要粗略地規劃下容量。

肯定羣集的兩個數字：OSD的數量和集羣的總容量

若是將羣集的總容量除以羣集中的OSD數，則能夠找到羣集中OSD的平均平均容量。考慮將該數字乘以您指望在正常操做期間同時失敗的OSD數量（相對較小的數量）。最後將羣集的容量乘以所有比率，以達到最大運行容量; 而後，減去那些預期會故障的OSD從而計算出合理的full ratio。用更多數量的OSD故障（例如，一組OSD）重複上述過程，以獲得合理的near full ratio。

如下設置僅適用於羣集建立，而後存儲在OSDMap中。

[global] mon osd full ratio = .80 mon osd backfillfull ratio = .75 mon osd nearfull ratio = .70

mon osd full ratio 描述：OSD被視爲已滿以前使用的磁盤空間百分比。 類型：float 默認值：0.95 mon osd backfillfull ratio 說明：在OSD被認爲太滿而沒法backfill以前使用的磁盤空間百分比。 類型：float 默認值：0.90 mon osd nearfull ratio 描述：在OSD被認爲接近滿以前使用的磁盤空間百分比。 類型：float 默認值：0.85

若是一些 OSD 快滿了，但其餘的仍有足夠空間，你可能配錯 CRUSH 權重了。

這些設置僅適用於羣集建立期間。以後須要使用ceph osd set-almostfull-ratio和ceph osd set-full-ratio在OSDMap中進行更改

心跳

Ceph 監視器要求各 OSD 向它報告、並接收 OSD 們的鄰居狀態報告，以此來掌握集羣。 Ceph 提供了監視器與 OSD 交互的合理默認值，然而你能夠按需修改

監視器存儲同步

當你用多個監視器支撐一個生產集羣時，各監視器都要檢查鄰居是否有集羣運行圖的最新版本（如，鄰居監視器的圖有一或多個 epoch 版本高於當前監視器的最高版 epoch ），過一段時間，集羣裏的某個監視器可能落後於其它監視器太多而不得不離開法定人數，而後同步到集羣當前狀態，並重回法定人數。爲了同步，監視器可能承擔三種中的一種角色：
　　1.Leader: Leader 是實現最新 Paxos 版本的第一個監視器。
　　2.Provider: Provider 有最新集羣運行圖的監視器，但不是第一個實現最新版。
　　3.Requester: Requester 落後於 leader ，重回法定人數前，必須同步以獲取關於集羣的最新信息。

有了這些角色區分， leader就能夠給 provider 委派同步任務，這會避免同步請求壓垮 leader 、影響性能。在下面的圖示中， requester 已經知道它落後於其它監視器，而後向 leader 請求同步， leader 讓它去和 provider 同步。

新監視器加入集羣時有必要進行同步。在運行中，監視器會不定時收到集羣運行圖的更新，這就意味着 leader 和 provider 角色可能在監視器間變幻。若是這事發生在同步期間（如 provider 落後於 leader ）， provider 能終結和 requester 間的同步。

一旦同步完成， Ceph 須要修復整個集羣，使歸置組回到 active + clean 狀態。

mon sync trim timeout 描述: 類型: Double 默認： 30.0

mon sync heartbeat timeout 描述: 類型: Double 默認： 30.0
 mon sync heartbeat interval 描述: 類型: Double 默認： 5.0
 mon sync backoff timeout 描述: 類型: Double 默認： 30.0
 mon sync timeout 描述: Number of seconds the monitor will wait for the next update message from its sync provider before it gives up and bootstrap again. 類型: Double 默認： 60.0
 mon sync max retries 描述: 類型: Integer 默認： 5
 mon sync max payload size 描述: The maximum size for a sync payload (in bytes). 類型: 32-bit Integer 默認： 1045676
 paxos max join drift 描述: 在咱們必須首先同步監控數據存儲以前的最大Paxos迭代。 當監視器發現其對等體遠遠超過它時，它將首先與數據存儲同步，而後再繼續。 類型: Integer 默認： 10
 paxos stash full interval 描述: 多久（在提交中）存儲PaxosService狀態的完整副本。 當前此設置僅影響mds，mon，auth和mgr PaxosServices。 類型: Integer 默認： 25
 paxos propose interval 描述: Gather updates for this time interval before proposing a map update. 類型: Double 默認： 1.0
 paxos min 描述: The minimum number of paxos states to keep around 類型: Integer 默認： 500
 paxos min wait 描述: The minimum amount of time to gather updates after a period of inactivity. 類型: Double 默認： 0.05
 paxos trim min 描述: Number of extra proposals tolerated before trimming 類型: Integer 默認： 250
 paxos trim max 描述: The maximum number of extra proposals to trim at a time 類型: Integer 默認： 500
 paxos service trim min 描述: The minimum amount of versions to trigger a trim (0 disables it) 類型: Integer 默認： 250
 paxos service trim max 描述: The maximum amount of versions to trim during a single proposal (0 disables it) 類型: Integer 默認： 500
 mon max log epochs 描述: The maximum amount of log epochs to trim during a single proposal 類型: Integer 默認： 500
 mon max pgmap epochs 描述: The maximum amount of pgmap epochs to trim during a single proposal 類型: Integer 默認： 500
 mon mds force trim to 描述: Force monitor to trim mdsmaps to this point (0 disables it. dangerous, use with care) 類型: Integer 默認： 0
 mon osd force trim to 描述: Force monitor to trim osdmaps to this point, even if there is PGs not clean at the specified epoch (0 disables it. dangerous, use with care) 類型: Integer 默認： 0
 mon osd cache size 描述: The size of osdmaps cache, not to rely on underlying store’s cache 類型: Integer 默認： 10
 mon election timeout 描述: On election proposer, maximum waiting time for all ACKs in seconds. 類型: Float 默認： 5
 mon lease 描述: The length (in seconds) of the lease on the monitor’s versions. 類型: Float 默認： 5
 mon lease renew interval factor 描述: mon lease * mon lease renew interval factor will be the interval for the Leader to renew the other monitor’s leases. The factor should be less than 1.0. 類型: Float 默認： 0.6
 mon lease ack timeout factor 描述: The Leader will wait mon lease * mon lease ack timeout factor for the Providers to acknowledge the lease extension. 類型: Float 默認： 2.0
 mon accept timeout factor 描述: The Leader will wait mon lease * mon accept timeout factor for the Requester(s) to accept a Paxos update. 
　　　　　　　　　　It is also used during the Paxos recovery phase for similar purposes. 類型: Float 默認： 2.0
 mon min osdmap epochs 描述: Minimum number of OSD map epochs to keep at all times. 類型: 32-bit Integer 默認： 500
 mon max pgmap epochs 描述: Maximum number of PG map epochs the monitor should keep. 類型: 32-bit Integer 默認： 500

mon max log epochs 描述: Maximum number of Log epochs the monitor should keep. 類型: 32-bit Integer 默認： 500

時鐘

Ceph守護進程將關鍵消息傳遞給彼此，必須在守護進程達到超時閾值以前處理這些消息。若是Ceph監視器中的時鐘不一樣步，則可能致使許多異常。例如：

1.守護進程忽略收到的消息（例如，時間戳過期）
2.當沒有及時收到消息時，超時/延遲觸發超時。

你應該在全部監視器主機上安裝 NTP 以確保監視器集羣的時鐘同步。

時鐘漂移即便還沒有形成損壞也能被 NTP 感知， Ceph 的時鐘漂移或時鐘誤差警告即便在 NTP 同步水平合理時也會被觸發。提升時鐘漂移值有時候尚可容忍，然而不少因素（像載荷、網絡延時、覆蓋默認超時值和監控器存儲同步選項）都能在不下降 Paxos 保證級別的狀況下影響可接受的時鐘漂移水平。

Ceph 提供了下列這些可調選項，讓你本身琢磨可接受的值。

clock offset 描述: 時鐘能夠漂移多少，詳情見 Clock.cc 。 類型: Double 默認： 0 自0.58版以來已棄用。 mon tick interval 描述: 監視器的心跳間隔，單位爲秒。 類型: 32-bit Integer 默認： 5 mon clock drift allowed 描述: 監視器間容許的時鐘漂移量 類型: Float 默認： .050 mon clock drift warn backoff 描述: 時鐘偏移警告的退避指數。 類型: Float 默認： 5 mon timecheck interval 描述: 和 leader 的時間偏移檢查（時鐘漂移檢查）。單位爲秒。 類型: Float 默認： 300.0 mon timecheck skew interval 描述: 當leader存在skew時間時，以秒爲單位的時間檢查間隔（時鐘漂移檢查）。 類型: Float 默認： 30.0

客戶端

mon client hunt interval 描述: 客戶端每 N 秒嘗試一個新監視器，直到它創建鏈接 類型: Double 默認： 3.0 mon client ping interval 描述: 客戶端每 N 秒 ping 一次監視器。 類型: Double 默認： 10.0 mon client max log entries per message 描述: 某監視器爲每客戶端生成的最大日誌條數。 類型: Integer 默認： 1000 mon client bytes 描述: 內存中容許存留的客戶端消息數量（字節數）。 類型: 64-bit Integer Unsigned 默認： 100ul << 20

pool設置

從版本v0.94開始，支持池標誌，容許或禁止對池進行更改。

若是以這種方式配置，監視器也能夠禁止刪除池。

mon allow pool delete 描述: If the monitors should allow pools to be removed. Regardless of what the pool flags say. 類型: Boolean 默認： false osd pool default flag hashpspool 描述: 在新池上設置hashpspool標誌 類型: Boolean 默認： true osd pool default flag nodelete 描述: 在新池上設置nodelete標誌。 防止以任何方式刪除使用此標誌的池。 類型: Boolean 默認： false osd pool default flag nopgchange 描述: 在新池上設置nopgchange標誌。 不容許爲池更改PG的數量。 類型: Boolean 默認： false osd pool default flag nosizechange 描述: 在新池上設置nosizechange標誌。 不容許更改池的大小。 類型: Boolean 默認： false

雜項

mon max osd 描述: 集羣容許的最大 OSD 數量。 類型: 32-bit Integer 默認： 10000 mon globalid prealloc 描述: 爲集羣和客戶端預分配的全局 ID 數量。 類型: 32-bit Integer 默認： 100 mon subscribe interval 描述: 同步的刷新間隔（秒），同步機制容許獲取集羣運行圖和日誌信息。 類型: Double 默認： 86400 mon stat smooth intervals 描述: Ceph將平滑最後N個PG地圖的統計數據。 類型: Integer 默認： 2 mon probe timeout 描述: 監視器在bootstrapping以前等待查找peers對等體的秒數。 類型: Double 默認： 2.0 mon daemon bytes 描述: 給mds和 OSD 的消息使用的內存空間（字節）。 類型: 64-bit Integer Unsigned 默認： 400ul << 20 mon max log entries per event 描述: 每一個事件容許的最大日誌條數。 類型: Integer 默認： 4096 mon osd prime pg temp 描述: Enables or disable priming the PGMap with the previous OSDs when an out OSD comes back into the cluster.
With the true setting the clients will continue to use the previous OSDs until the newly in OSDs as that PG peered. 類型: Boolean 默認： true mon osd prime pg temp max time 描述: 當OSD返回集羣時，監視器應花費多少時間嘗試填充PGMap。 類型: Float 默認： 0.5 mon osd prime pg temp max time estimate 描述: Maximum estimate of time spent on each PG before we prime all PGs in parallel. 類型: Float 默認： 0.25 mon osd allow primary affinity 描述: 容許在osdmap中設置primary_affinity。 類型: Boolean 默認： False mon osd pool ec fast read 描述: 是否打開池上的快速讀取。若是在建立時未指定fast_read，它將用做新建立的erasure pool的默認設置。 類型: Boolean 默認： False mon mds skip sanity 描述: Skip safety assertions on FSMap (in case of bugs where we want to continue anyway).
Monitor terminates if the FSMap sanity check fails, but we can disable it by enabling this option. 類型: Boolean 默認： False mon max mdsmap epochs 描述: The maximum amount of mdsmap epochs to trim during a single proposal. 類型: Integer 默認： 500 mon config key max entry size 描述: config-key條目的最大大小（以字節爲單位）
類型: Integer 默認： 4096 mon scrub interval 描述: How often (in seconds) the monitor scrub its store by comparing the stored checksums with the computed ones of all the stored keys. 類型: Integer 默認： 3600*24 mon scrub max keys 描述: The maximum number of keys to scrub each time. 類型: Integer 默認： 100 mon compact on start 描述: Compact the database used as Ceph Monitor store on ceph-mon start.
A manual compaction helps to shrink the monitor database and improve the performance of it if the regular compaction fails to work. 類型: Boolean 默認： False mon compact on bootstrap 描述: Compact the database used as Ceph Monitor store on on bootstrap.
Monitor starts probing each other for creating a quorum after bootstrap. If it times out before joining the quorum, it will start over and bootstrap itself again. 類型: Boolean 默認： False mon compact on trim 描述: Compact a certain prefix (including paxos) when we trim its old states. 類型: Boolean 默認： True mon cpu threads 描述: Number of threads for performing CPU intensive work on monitor. 類型: Boolean 默認： True mon osd mapping pgs per chunk 描述: We calculate the mapping from placement group to OSDs in chunks. This option specifies the number of placement groups per chunk. 類型: Integer 默認： 4096 mon osd max split count 描述: Largest number of PGs per 「involved」 OSD to let split create.
When we increase the pg_num of a pool, the placement groups will be split on all OSDs serving that pool. We want to avoid extreme multipliers on PG splits. 類型: Integer 默認： 300 mon session timeout 描述: Monitor will terminate inactive sessions stay idle over this time limit. 類型: Integer 默認： 300

經過DNS查看操做監視器

從版本11.0.0開始，RADOS支持經過DNS查找監視器。

這樣，守護進程和客戶端在其ceph.conf配置文件中不須要mon主機配置指令。

使用DNS SRV TCP記錄客戶端能夠查找監視器。

這容許在客戶端和監視器上進行較少的配置。使用DNS更新能夠使客戶端和守護程序瞭解監視器拓撲中的更改。

默認狀況下，客戶端和守護程序將查找名爲ceph-mon的TCP服務，該服務由mon_dns_srv_name配置指令配置。

mon dns srv name 描述: the service name used querying the DNS for the monitor hosts/addresses 類型: String 默認： ceph-mon

心跳設置

概述

完成初始Ceph配置後，您能夠部署並運行Ceph。當您執行諸如ceph health或ceph -s之類的命令時，Ceph Monitor會報告Ceph存儲集羣的當前狀態。 Ceph Monitor經過每一個Ceph OSD守護進程本身的報告，以及從Ceph OSD Daemons接收有關其相鄰Ceph OSD守護進程狀態的報告，瞭解Ceph存儲羣集。若是Ceph Monitor沒有收到報告，或者它收到Ceph存儲集羣中的更改報告，Ceph Monitor會更新Ceph集羣映射的狀態。

Ceph爲Ceph Monitor / Ceph OSD Daemon交互提供合理的默認設置。可是，您能夠覆蓋默認值。如下部分描述了Ceph監視器和Ceph OSD守護進程如何交互以監視Ceph存儲羣集。

心跳驗證

各 OSD 每 6 秒會與其餘 OSD 進行心跳檢查，用 [osd] 下的 osd heartbeat interval 可更改此間隔、或運行時更改。若是一個 OSD 20 秒都沒有心跳，集羣就認爲它 down 了，用 [osd] 下的 osd heartbeat grace 可更改寬限期、或者運行時更改。

死亡OSD上報

默認狀況下，在Ceph監視器確認報告的Ceph OSD守護進程已關閉以前，須要來自不一樣主機的兩個Ceph OSD守護進程向Ceph監視器報告另外一個Ceph OSD守護進程已關閉。可是，全部報告故障的OSD都有可能存放在機架中，而且鏈接到另外一個OSD時出現問題。爲了不這種誤報，咱們認爲報告失敗的對等體是整個羣集中潛在的「子羣集」的代理，一樣具備相似的滯後性。顯然不是全部狀況都是這樣，但有時會幫助咱們優雅校訂錯誤。 mon osd報告子樹級別用於經過CRUSH映射中的共同祖先類型將對等體分組到「子集羣」中。默認狀況下，只須要來自不一樣子樹的兩個報告來報告另外一個Ceph OSD守護進程。你能夠經過在ceph配置文件裏的[mon]部分下添加mon osd min down reporter和mon osd reporter subtree level設置或在運行時設置值。

報告互連失敗

若是一OSD守護進程不能和配置文件中定義的任何OSD創建鏈接，它會每30秒向監視器索要一次最新集羣運行圖，你能夠在[osd]下設置osd mon heartbeat interval來更改這個心跳間隔，或者運行時更改

報告本身的狀態

若是一 OSD 在 mon osd report timeout 時間內沒向監視器報告過，監視器就認爲它 down 了。OSD 守護進程會向監視器報告某些事件，如某次操做失敗、歸置組狀態變動、 up_thru 變動、或它將在 5 秒內啓動。你能夠設置 [osd] 下的 osd mon report interval min 來更改最小報告間隔，或在運行時更改。 OSD 守護進程每 120 秒會向監視器報告其狀態，不管是否有值得報告的事件。在 [osd] 段下設置 osd mon report interval max 可更改OSD報告間隔，或運行時更改。

配置

心跳選項應該置於配置文件的 [global] 段下。

監視器選項

mon osd min up ratio 描述: 在把 OSD 標記爲 down 前，保持處於 up 狀態的 OSD 最小比例。 類型: Double 默認： .3 mon osd min in ratio 描述: 在把 OSD 標記爲 out 前，保持處於 in 狀態的 OSD 最小比例 類型: Double 默認： .75 mon osd laggy halflife 描述: The number of seconds laggy estimates will decay. 類型: Integer 默認： 60*60 mon osd laggy weight 描述: The weight for new samples in laggy estimation decay. 類型: Double 默認： 0.3 mon osd laggy max interval 描述: Maximum value of laggy_interval in laggy estimations (in seconds). 
Monitor uses an adaptive approach to evaluate the laggy_interval of a certain OSD. This value will be used to calculate the grace time for that OSD. 類型: Integer 默認： 300 mon osd adjust heartbeat grace 描述: If set to true, Ceph will scale based on laggy estimations. 類型: Boolean 默認： true mon osd adjust down out interval 描述: If set to true, Ceph will scaled based on laggy estimations. 類型: Boolean 默認： true mon osd auto mark in 描述: Ceph 將把任何啓動中的 OSD 標記爲在集羣中（ in ）。 類型: Boolean 默認： false mon osd auto mark auto out in 描述: 把正在啓動、且被自動標記爲 out 狀態的 OSD 標記爲 in 類型: Boolean 默認： true mon osd auto mark new in 描述: 把正在啓動的新 OSD 標記爲 in 。 類型: Boolean 默認： true mon osd down out interval 描述: 在 OSD 中止響應多少秒後把它標記爲 down 且 out 。 類型: 32-bit Integer 默認： 600 mon osd down out subtree limit 描述: Ceph不會自動標記的最小CRUSH單位類型。例如，若是設置爲host，若是host的全部OSD都關閉，Ceph將不會自動標記這些OSD。
類型: String 默認： rack mon osd report timeout 描述: 在聲明無響應的Ceph OSD守護進程down以前的寬限期（以秒爲單位）。 類型: 32-bit Integer 默認： 900 mon osd min down reporters 描述: 報告Ceph OSD守護進程down所需的最小Ceph OSD守護進程數。 類型: 32-bit Integer 默認： 2 mon osd reporter subtree level 描述: In which level of parent bucket the reporters are counted. 
The OSDs send failure reports to monitor if they find its peer is not responsive. And monitor mark the reported OSD out and then down after a grace period. 類型: String 默認： host

OSD選項

osd heartbeat address 描述: OSD 用於心跳的網絡地址 類型: Address 默認： The host address. osd heartbeat interval 描述: 一個OSD探測它的鄰居的間隔時間（秒） 類型: 32-bit Integer 默認： 6 osd heartbeat grace 描述: Ceph OSD守護進程沒有顯示Ceph存儲集羣認爲它已關閉的心跳所通過的時間。 必須在[mon]和[osd]或[global]部分中設置此設置，以便MON和OSD守護程序均可以讀取它。 類型: 32-bit Integer 默認： 20 osd mon heartbeat interval 描述: OSD 沒有鄰居時多久探測一次監視器 類型: 32-bit Integer 默認： 30 osd mon report interval 描述: 監視器容許 OSD 報告的最大間隔，超時將認爲 OSD 掛了（ down ）。 類型: 32-bit Integer 默認： 5 osd mon ack timeout 描述: 等待Ceph Monitor確認統計請求的秒數。 類型: 32-bit Integer 默認： 30

OSD設置

概述

你能夠經過配置文件調整 OSD ，僅靠默認值和極少的配置 OSD 守護進程就能運行。最簡 OSD 配置需設置 osd journal size 和 host ，其餘幾乎都能用默認值。

Ceph 的 OSD 守護進程用遞增的數字做標識，按慣例以 0 開始，以下：

osd.0 osd.1 osd.2

在配置文件裏， [osd] 段下的配置適用於全部 OSD ；要添加針對特定 OSD 的選項（如 host ），把它放到那個 OSD 段下便可，如

[osd] osd journal size = 5120 [osd.0] host = osd-host-a [osd.1] host = osd-host-b

常規配置

下列選項可配置一 OSD 的惟一標識符、以及數據和日誌的路徑。 Ceph 部署腳本一般會自動生成 UUID 。咱們不建議更改數據和日誌的默認路徑，由於這樣會增長後續的排障難度。

日誌尺寸應該大於指望的驅動器速度和 filestore max sync interval 之乘積的兩倍；最多見的方法是爲日誌驅動器（一般是 SSD ）分區並掛載好，這樣 Ceph 就能夠用整個分區作日誌。

osd uuid 描述: OSD 的全局惟一標識符（ UUID ）。 類型: UUID 默認： The UUID. Note: osd uuid 適用於單個 OSD ， fsid 適用於整個集羣。
 osd data 描述: OSD 數據存儲位置，你得建立並把數據盤掛載到其下。咱們不推薦更改默認值。 類型: String 默認： /var/lib/ceph/osd/$cluster-$id osd max write size 描述: 一次寫入的最大尺寸，MB。 類型: 32-bit Integer 默認： 90 osd max object size 描述: 一個object最大大小（字節）bytes. 類型: 32-bit Unsigned Integer 默認： 128MB osd client message size cap 描述: 內存裏容許的最大客戶端數據消息。 類型: 64-bit Unsigned Integer 默認： 500MB default. 500*1024L*1024L osd class dir 描述: RADOS 類插件的路徑。 類型: String 默認： $libdir/rados-classes

文件系統選項

Ceph構建並安裝文件系統用於Ceph OSD

osd mkfs options {fs-type} 描述: 爲 OSD 新建 {fs-type} 類型的文件系統時使用的選項。 類型: String Default for xfs: -f -i 2048 Default for other file systems: {empty string} For example:: osd mkfs options xfs = -f -d agcount=24 osd mount options {fs-type} 描述: 掛載 {fs-type} 類型的文件系統做爲 OSD 數據目錄時所用的選項。 類型: String Default for xfs: rw,noatime,inode64 Default for other file systems: rw, noatime For example:: osd mount options xfs = rw, noatime, inode64, logbufs=8

日誌選項

默認狀況下，Ceph指望你把OSD日誌存入如下路徑

/var/lib/ceph/osd/$cluster-$id/journal

使用單一設備類型（例如，旋轉驅動器）時，應該共同使用日誌：邏輯卷（或分區）應與數據邏輯卷位於同一設備中。

當使用快速（SSD，NVMe）設備與較慢設備（如旋轉驅動器）的混合時，將日誌放在更快的設備上是有意義的，而數據徹底佔用較慢的設備。

默認的osd日誌大小值是5120（5GB），但它能夠更大，在這種狀況下須要在ceph.conf文件中設置：

osd journal 描述: OSD 日誌路徑，能夠是一個文件或塊設備（ SSD 的一個分區）的路徑。若是是文件，要先建立相應目錄。咱們建議用 osd data 之外的獨立驅動器。 類型: String 默認： /var/lib/ceph/osd/$cluster-$id/journal osd journal size 描述: 日誌大小（MB） 類型: 32-bit Integer 默認： 5120

監視器OSD交互

Ceph OSD守護進程檢查對方的心跳並按期向監視器報告。在許多狀況下，Ceph能夠使用默認值。可是，若是您的網絡存在延遲問題，則可能須要採用更長的時間間隔。有關心跳的詳細討論，請參閱心跳。

數據放置

有關詳細信息，請參見Pool＆PG Config Reference。

SCRUBBING

除了爲對象複製多個副本外，Ceph還要洗刷歸置組確認數據完整性。這種洗刷相似對象存儲層的fsck，對每一個歸置組，Ceph生成一個全部對象的目錄，並比對每一個主對象及其副本以確保沒有對象丟失或錯配。輕微洗刷（天天）檢查對象尺寸和屬性，深層洗刷（每週）會讀出數據並用校驗和方法確認數據完整性。

洗刷對維護數據完整性很重要，但會影響性能;你能夠用下列選項來增長或減小洗刷操做。

osd max scrubs 描述: Ceph OSD守護進程的最大同步清理操做數。 類型: 32-bit Int 默認： 1 osd scrub begin hour 描述: 清理的下限時間 類型: Integer in the range of 0 to 24 默認： 0 osd scrub end hour 描述: 能夠執行預約清理時的上限時間。 與osd scrub begin hour一塊兒定義了一個時間窗口，能夠在其中進行擦洗。 可是，不管時間窗口是否容許，只要放置組的擦洗間隔超過osd scrub max interval都將進行擦洗。 默認： 24 osd scrub during recovery 描述: 在恢復期間容許擦洗。 將此設置爲false將禁用在有活動恢復時安排新的清理（和深度清理）。 若是已經開始將繼續執行。 這有助於減輕集羣繁忙時上的負載。 類型: Boolean 默認： true osd scrub thread timeout 描述: The maximum time in seconds before timing out a scrub thread. 類型: 32-bit Integer 默認： 60 osd scrub finalize thread timeout 描述: The maximum time in seconds before timing out a scrub finalize thread. 類型: 32-bit Integer 默認： 60*10 osd scrub load threshold 描述: 標準化的最大負載。 當系統負載（由getloadavg（）/online cpu numbers）高於此數字時，Ceph不會擦除。  類型: Float 默認： 0.5 osd scrub min interval 描述: 當Ceph存儲集羣負載較低時，擦除Ceph OSD守護程序的最小間隔（秒）。 類型: Float 默認： Once per day. 60*60*24 osd scrub max interval 描述: 不管羣集負載如何，擦除Ceph OSD守護進程的最大間隔（秒）。 類型: Float 默認： Once per week. 7*60*60*24 osd scrub chunk min 描述: 在單個操做期間要擦除的最小數量的對象存儲塊。 Ceph在擦洗期間阻止寫入單個塊。 類型: 32-bit Integer 默認： 5 osd scrub chunk max 描述: 單個操做期間要擦除的最大對象存儲塊數。 類型: 32-bit Integer 默認： 25 osd scrub sleep 描述: 在擦洗下一組塊以前休眠的時間。 增長此值將減慢整個清理操做，同時客戶端操做受影響較小 類型: Float 默認： 0 osd deep scrub interval 描述: 深度」清理的間隔（徹底讀取全部數據）。 osd scrub load threshold不會影響此設置。 類型: Float 默認： Once per week. 60*60*24*7 osd scrub interval randomize ratio 描述: 在給某一歸置組調度下一個洗刷做業時，給 osd scrub min interval 增長個隨機延時，這個延時是個小於 osd scrub min interval * osd scrub interval randomized ratio 的隨機值。
　　　　 因此在實踐中，這個默認設置會把洗刷操做隨機地散佈到容許的時間窗口內，即 [1, 1.5] * osd scrub min interval 。 類型: Float 默認： 0.5 osd deep scrub stride 描述: 深層洗刷時的讀取尺寸 類型: 32-bit Integer 默認： 512 KB. 524288

操做選項

osd op queue 描述：這設置了用於在OSD中優先化操做的隊列類型。全部隊列都具備嚴格的子隊列，該隊列在正常隊列以前出列。 原始的PrioritizedQueue（prio）使用令牌桶系統，當有足夠的令牌時，它將首先使高優先級隊列出列。若是沒有足夠的令牌可用，則隊列將從低優先級出列到高優先級。 WeightedPriorityQueue（wpq）將全部優先級與其優先級相關聯，以防止任何隊列出現飢餓。若是少數OSD比其餘OSD更加過載，WPQ應該會有所幫助。 新的基於OpClassQueue（mclock_opclass）的mClock根據它們所屬的類（recovery, scrub, snaptrim, client op, osd subop）對操做進行優先級排序。 而且，基於ClientQueue（mclock_client）的mClock還包含客戶端標識符，以促進客戶端之間的公平性。參閱QoS Based on mClock。須要重啓。 類型：String 有效選擇：prio，wpq，mclock_opclass，mclock_client 默認值：PRIO osd op queue cut off 描述：這將選擇將哪些優先級操做發送到嚴格隊列和普通隊列。 設置爲low將全部replication操做和更高級別的操做發送到strict隊列，而設置爲high將replication acknowledgement操做和更高級別的操做發送到strict隊列。 若是羣集中的一些OSD很是繁忙，將此設置爲高，並將osd op queue設置中與wpq結合使用時，應該會有所幫助。 處理複製流量很是繁忙的OSD可能會在沒有這些設置的狀況下使主要客戶端流量在這些OSD上匱乏。須要重啓。 類型：String 有效選擇: low, high 默認值: low osd client op priority 描述：爲客戶端操做設置的優先級。它與osd recovery op priority關聯。 類型：32位整數 默認值：63 有效範圍：1-63 osd recovery op priority 描述：爲恢復操做設置的優先級。它與osd client op priority關聯。 類型：32位整數 默認值：3 有效範圍：1-63 osd scrub priority 描述：爲清理操做設置的優先級。它與 osd client op priority相關。 類型：32位整數 默認值：5 有效範圍：1-63 osd snap trim priority 描述：爲snap trim操做設置的優先級。它與osd client op priority相關。 類型：32位整數 默認值：5 有效範圍：1-63 osd op thread timeout 描述：Ceph OSD守護進程操做線程超時（秒）。 類型：32位整數 默認值：15 osd op complaint time 描述：在指定的秒數事後，操做becomes complaint worthy。 類型：float 默認值：30 osd disk threads 描述：磁盤線程數，用於執行後臺磁盤密集型OSD操做，例如scrubbing 和snap trimming。 類型：32位整數 默認值：1 osd disk thread ioprio class 描述：警告：僅當osd disk thread ioprio class和osd disk thread ioprio priority都設置爲非默認值時纔會使用它。 ioprio_set(2) I/O scheduling class設置磁盤線程。 可接受的值是空字符串，be或rt。空閒類意味着磁盤線程的優先級低於OSD中的任何其餘線程。這對於在忙於處理客戶端操做的OSD上減慢擦除很是有用。 be是默認值，與OSD中的全部其餘線程具備相同的優先級。 rt表示磁盤線程優先於OSD中的全部其餘線程。 注意：僅適用於Linux內核CFQ調度程序。從Jewel版本開始磁盤iothread再也不執行擦除，請參閱osd priority options。 類型：String 默認值：空字符串 osd disk thread ioprio priority 說明：警告：僅當osd disk thread ioprio class和osd disk thread ioprio priority都設置爲非默認值時纔會使用它。 它設置磁盤線程的ioprio_set(2) I/O scheduling priority，範圍從0（最高）到7（最低）。 若是給定主機上的全部OSD都處於空閒狀態而且競爭I / O（即因爲控制器擁塞），則能夠使用它將一個OSD的磁盤線程優先級下降到7，以便優先級爲0的另外一個OSD能夠具備優先級。 注意：僅適用於Linux內核CFQ調度程序。 類型：整數，範圍爲0到7，若是不使用爲-1。 默認值：-1 osd op history size 描述：跟蹤已完成操做的最大數量。 鍵入：32位無符號整數 默認值：20 osd op history duration 描述：最先完成的操做跟蹤。 鍵入：32位無符號整數 默認值：600 osd op log threshold 描述：一次顯示多少個操做日誌。 類型：32位整數 默認值：5

基於MCLOCK的QOS

Ceph對mClock的使用目前正處於試驗階段。

核心概念

Ceph的QoS支持使用基於dmClock算法的排隊調度器來實現。該算法按權重比例分配Ceph集羣的I / O資源，並實施最小預留和最大限制的約束，使服務能夠公平地競爭資源。目前，mclock_opclass操做隊列將涉及I / O資源的Ceph服務劃分爲如下幾類：

client op：客戶端發出的iops
osd subop：主OSD發佈的iops
snap trim：快照修剪相關請求
pg recovery：與恢復相關的請求
pg scrub：與擦洗相關的請求

並使用如下三組標記對資源進行分區。換句話說，每種服務類型的由三個標籤控制：

reservation：爲服務分配的最小IOPS。
limitation：爲服務分配的最大IOPS。
weight：若是額外容量或系統超額訂購，則按比例分配容量。

在Ceph運營中，評級爲「cost」。而且爲這些「成本」消耗分配用於服務各類服務的資源。所以，例如，只要須要，服務的預留越多，保證擁有的資源就越多。假設有兩種服務：恢復和客戶端操做：

恢復：（r：1，l：5，w：1）
客戶操做：（r：2，l：0，w：9）

上述設置確保恢復每秒服務的請求數不會超過5個，即便它須要服務，而且沒有其餘服務與之競爭。可是，若是客戶端開始發出大量I / O請求，它們也不會耗盡全部I / O資源。只要有任何此類請求，就始終爲恢復做業分配每秒1個請求。所以，即便在高負載的羣集中，恢復做業也不會匱乏。與此同時，客戶端操做系統能夠享受更大部分的I / O資源，由於它的權重爲「9」，而其競爭對手爲「1」。對於客戶端操做，它不受limit setting設置限制，所以若是沒有正在進行恢復，它能夠利用全部資源。

與mclock_opclass一塊兒，另外一個名爲mclock_client的mclock operation queue可用。它根據類別劃分操做，但也根據發出請求的客戶端對它們進行劃分。這不只有助於管理在不一樣類別的操做上花費的資源分配，還有助於確保客戶之間的公平性。

當前實現注意：當前的實驗實現不強制執行限制值。做爲第一個近似值，咱們決定不阻止進入操做序列器的操做。

MCLOCK的細節

reservation 和limit 值具備每秒請求單位。然而，weight在技術上不具備單元而且weight是相對的。所以，若是一類請求的權重爲1而權重爲9，那麼後一類請求應該以9比1的比率執行。

即便權重沒有單位，算法爲請求分配權重，所以必須謹慎選擇其值。若是權重爲W，則對於給定類別的請求，下一個請求將具備1 / W的權重標記加上先前的權重標記或當前時間，以較大者爲準。這意味着若是W太大而1 / W過小，則可能永遠不會分配計算的標籤，由於它將得到當前時間的值。最終的教訓是重量值不該該太大。它們應該在每秒預期服務的請求數量之下。

CAVEATS

有一些因素能夠減小Ceph中mClock操做隊列的影響。首先，對OSD的請求按其放置組標識符進行分片。每一個分片都有本身的mClock隊列，這些隊列既不會交互也不會在它們之間共享信息。能夠使用配置選項osd_op_num_shards，osd_op_num_shards_hdd和osd_op_num_shards_ssd來控制分片數。較少數量的分片會增長mClock隊列的影響，但可能會產生其餘有害影響。

其次，請求從操做隊列傳輸到操做序列器，在操做序列器中執行真正的處理。操做隊列是mClock所在的位置，mClock肯定要傳輸到操做序列器的下一個操做。操做序列器中容許的操做數是一個複雜的問題。通常來講，咱們但願在序列器中保留足夠的操做數，以便在等待磁盤和網絡訪問完成其餘操做時，老是在某些操做上完成工做。另外一方面，一旦操做轉移到操做序列器，mClock就再也不能控制它。所以，爲了最大化mClock的影響，咱們但願儘量少地在操做序列器中進行操做。

影響操做序列器中操做數的配置選項爲bluestore_throttle_bytes，bluestore_throttle_deferred_bytes，bluestore_throttle_cost_per_io，bluestore_throttle_cost_per_io_hdd和bluestore_throttle_cost_per_io_ssd。

影響mClock算法影響的第三個因素是咱們正在使用分佈式系統，其中對多個OSD進行請求，而且每一個OSD具備（能夠具備）多個分片。然而，咱們目前正在使用的mClock算法不是分佈式的（dmClock是mClock的分佈式版本）。

目前，各類組織和我的正在嘗試使用mClock，咱們但願您能在ceph-devel郵件列表中分享您對mClock和dmClock實驗的體驗。

osd push per object cost 描述：服務一個push操做的開銷 類型：無符號整數 默認值：1000 osd recovery max chunk 描述：恢復操做能夠攜帶的數據塊的最大大小。 類型：無符號整數 默認值：8 MiB osd op queue mclock client op res 描述: 客戶端操做的reservation 類型：float 默認值：1000.0 osd op queue mclock client op wgt 描述：客戶端操做的權重。 類型：float 默認值：500.0 osd op queue mclock client op lim 描述：客戶端操做的limit。 類型：float 默認值：1000.0 osd op queue mclock osd subop res 描述：osd subop的保留。 類型：float 默認值：1000.0 osd op queue mclock osd subop wgt 描述：osd subop的權重。 類型：float 默認值：500.0 osd op queue mclock osd subop lim 描述：osd subop的限制。 類型：float 默認值：0.0 osd op queue mclock snap res 描述：snap trimming的reservation 。 類型：float 默認值：0.0 osd op queue mclock snap wgt 描述：snap trimming的權重。 類型：float 默認值：1.0 osd op queue mclock snap lim 描述：snap trimming的限制。 類型：float 默認值：0.001 osd op queue mclock recov res 描述： the reservation of recovery. 類型: Float 默認值: 0.0 osd op queue mclock recov wgt 描述： the weight of recovery. 類型: Float 默認值: 1.0 osd op queue mclock recov lim 描述： the limit of recovery. 類型: Float 默認值: 0.001 osd op queue mclock scrub res 描述： the reservation of scrub jobs. 類型: Float 默認值: 0.0 osd op queue mclock scrub wgt 描述： the weight of scrub jobs. 類型: Float 默認值: 1.0 osd op queue mclock scrub lim 描述： the limit of scrub jobs. 類型: Float 默認值: 0.001

BACKFILLING

當集羣新增或移除 OSD 時，按照 CRUSH 算法應該從新均衡集羣，它會把一些歸置組移出或移入多個 OSD 以回到均衡狀態。歸置組和對象的遷移會致使集羣運營性能顯著下降，爲維持運營性能， Ceph 用 backfilling 來執行此遷移，它能夠使得 Ceph 的回填操做優先級低於用戶讀寫請求。

osd max backfills 描述： 每一個OSD容許的最大回填數 類型： 64-bit Unsigned Integer 默認值： 1 osd backfill scan min 描述： 每次回填的最小對象數目 類型： 32-bit Integer 默認值： 64 osd backfill scan max 描述： 每次回填的最大對象數目 類型： 32-bit Integer 默認值： 512 osd backfill retry interval 描述： 回填重試請求間隔 類型： Double 默認值： 10.0

OSD MAP

OSD映射反映了在羣集中運行的OSD守護進程。隨着時間的推移， map epochs的數量增長。 Ceph提供了一些設置，以確保Ceph在OSD MAP變大時表現良好。

osd map dedup 描述： 啓用刪除OSD映射中的重複項。 類型： Boolean 默認值： true osd map cache size 描述： 緩存中保存的OSD map數目 類型： 32-bit Integer 默認值： 500 osd map cache bl size 描述： OSD守護進程中內存中OSD map緩存的大小。 類型： 32-bit Integer 默認值： 50 osd map cache bl inc size 描述： OSD守護進程中內存中OSD映射緩存增量尺寸。 類型： 32-bit Integer 默認值： 100 osd map message max 描述： 每一個 MOSDMap 圖消息容許的最大條目數量。 類型： 32-bit Integer 默認值： 100

RECOVERY

當集羣啓動、或某 OSD 守護進程崩潰後重啓時，此 OSD 開始與其它 OSD 們創建鏈接，這樣才能正常工做。

若是某 OSD 崩潰並重生，一般會落後於其餘 OSD ，也就是沒有同歸置組內最新版本的對象。這時， OSD 守護進程進入恢復模式並檢索最新數據副本，並更新運行圖。根據 OSD 掛的時間長短， OSD 的對象和歸置組可能落後得厲害，另外，若是掛的是一個失效域（如一個機櫃），多個 OSD 會同時重生，這樣恢復時間更長、更耗資源。

爲保持運營性能， Ceph 進行恢復時會限制恢復請求數、線程數、對象塊尺寸，這樣在降級狀態下也能保持良好的性能

osd recovery delay start 描述： 對等關係創建完畢後， Ceph 開始對象恢復前等待的時間（秒）。 類型： Float 默認值： 0 osd recovery max active 描述： 每一個 OSD 一次處理的活躍恢復請求數量，增大此值能加速恢復，但它們會增長集羣負載。 類型： 32-bit Integer 默認值： 3 osd recovery max chunk 描述： 一次推送的數據塊的最大尺寸。 類型： 64-bit Unsigned Integer 默認值： 8 << 20 osd recovery max single start 描述： OSD恢復時將從新啓動的每一個OSD的最大恢復操做數。 類型： 64-bit Unsigned Integer 默認值： 1 osd recovery thread timeout 描述： 恢復現成超時時間 類型： 32-bit Integer 默認值： 30 osd recover clone overlap 描述： Preserves clone overlap during recovery. Should always be set to true. 類型： Boolean 默認值： true osd recovery sleep 描述： 下次恢復或回填操做前的睡眠時間（以秒爲單位）。增長此值將減慢恢復操做，同時客戶端操做受影響較小。 類型： Float 默認值： 0 osd recovery sleep hdd 描述： 下次恢復或硬盤迴填操做以前的休眠時間（以秒爲單位）。 類型： Float 默認值： 0.1 osd recovery sleep ssd 描述： 下次恢復以前或回填SSD休眠的時間（以秒爲單位）。 類型： Float 默認值： 0 osd recovery sleep hybrid 描述： 當osd數據在HDD上而且osd日誌在SSD上時，下一次恢復或回填操做以前的休眠時間（以秒爲單位）。 類型： Float 默認值： 0.025

TIERING

osd agent max ops 描述：高速模式下每一個分層代理的最大同時刷新操做數。 類型：32位整數 默認值：4 osd agent max low ops 描述：低速模式下每一個分層代理的最大同時刷新操做數。 類型：32位整數 默認值：2

雜項

osd snap trim thread timeout 描述： snap trim線程超時時間 類型： 32-bit Integer 默認值： 60*60*1 osd backlog thread timeout 描述： backlog線程超時時間 類型： 32-bit Integer 默認值： 60*60*1 osd default notify timeout 描述： OSD默認通知超時（以秒爲單位）。 類型： 32-bit Unsigned Integer 默認值： 30 osd check for log corruption 描述： 檢查日誌文件是否損壞。計算消耗大。 類型： Boolean 默認值： false osd remove thread timeout 描述： remove OSD thread超時時間 類型： 32-bit Integer 默認值： 60*60 osd command thread timeout 描述： command thread超時時間 類型： 32-bit Integer 默認值： 10*60 osd command max records 描述： Limits the number of lost objects to return. 類型： 32-bit Integer 默認值： 256 osd fast fail on connection refused 描述： 若是啓用此選項，則鏈接的對等設備和MON會當即標記崩潰的OSD（假設已崩潰的OSD主機存活）。禁用restore，代價是在I / O操做中OSD崩潰時可能存在長I / O停頓。 類型： Boolean 默認值： true

BlueStore設置

設備

BlueStore管理一個，兩個或（在某些狀況下）三個存儲設備。

在最簡單的狀況下，BlueStore使用單個（主）存儲設備。存儲設備一般做爲一個總體使用，BlueStore直接佔用完整設備。該主設備一般由數據目錄中的塊符號連接標識。

數據目錄掛載成一個tmpfs，它將填充（在啓動時或ceph-volume激活它時）全部經常使用的OSD文件，其中包含有關OSD的信息，例如：其標識符，它所屬的集羣，以及它的私鑰。

還能夠使用兩個額外的設備部署BlueStore：

WAL設備（在數據目錄中標識爲block.wal）可用於BlueStore的內部日誌或預寫日誌。只有設備比主設備快（例如，當它在SSD上而且主設備是HDD時），使用WAL設備是有用的。
數據庫設備（在數據目錄中標識爲block.db）可用於存儲BlueStore的內部元數據。 BlueStore（或者更確切地說，嵌入式RocksDB）將在數據庫設備上放置儘量多的元數據以提升性能。若是數據庫設備填滿，元數據將寫到主設備。一樣，數據庫設備要比主設備更快，則提供數據庫設備是有幫助的。

若是隻有少許快速存儲可用（例如，小於1GB），咱們建議將其用做WAL設備。若是還有更多，配置數據庫設備會更有意義。 BlueStore日誌將始終放在可用的最快設備上，所以使用數據庫設備將提供與WAL設備相同的優點，同時還容許在其中存儲其餘元數據。

單個設備上配置bluestore

ceph-volume lvm prepare --bluestore --data <device>

指定WAL設備和/或數據庫設備，

ceph-volume lvm prepare --bluestore --data <device> --block.wal <wal-device> --block.db <db-device>

注意 - data 能夠是使用vg / lv表示法的邏輯卷。其餘設備能夠是現有邏輯卷或GPT分區

部署

雖然有多種方法能夠部署Bluestore OSD，但這裏有兩個常見的用例，能夠幫助闡明初始部署策略：

BLOCK (DATA) ONLY

若是全部設備都是相同的類型，例如全部設備都是HDD，而且沒有快速設備來組合這些設備，那麼僅使用此方法部署而且不將block.db或block.wal分開是有意義的。對單個/ dev / sda設備的lvm調用以下所示：

ceph-volume lvm create --bluestore --data /dev/sda

若是已經爲每一個設備建立了邏輯卷（1個LV使用100％的設備），則對名爲ceph-vg / block-lv的lv的lvm調用以下所示：

ceph-volume lvm create --bluestore --data ceph-vg/block-lv

BLOCK AND BLOCK.DB

若是混合使用快速和慢速設備（旋轉和固態），建議將block.db放在速度更快的設備上，而塊（數據）則放在較慢的設備上（旋轉驅動器）。 block.db的大小應該儘量大，以免性能損失。 ceph-volume工具目前沒法自動建立，所以須要手動建立卷組和邏輯卷。

對於下面的示例，假設有4個旋轉驅動器（sda，sdb，sdc和sdd）和1個固態驅動器（sdx）。首先建立卷組：

$ vgcreate ceph-block-0 /dev/sda $ vgcreate ceph-block-1 /dev/sdb $ vgcreate ceph-block-2 /dev/sdc $ vgcreate ceph-block-3 /dev/sdd

如今建立邏輯卷：

$ lvcreate -l 100%FREE -n block-0 ceph-block-0 $ lvcreate -l 100%FREE -n block-1 ceph-block-1 $ lvcreate -l 100%FREE -n block-2 ceph-block-2 $ lvcreate -l 100%FREE -n block-3 ceph-block-3

咱們正在爲四個慢速旋轉設備建立4個OSD，所以假設/ dev / sdx中有200GB SSD，咱們將建立4個邏輯卷，每一個50GB：

$ vgcreate ceph-db-0 /dev/sdx $ lvcreate -L 50GB -n db-0 ceph-db-0 $ lvcreate -L 50GB -n db-1 ceph-db-0 $ lvcreate -L 50GB -n db-2 ceph-db-0 $ lvcreate -L 50GB -n db-3 ceph-db-0

最後，使用ceph-volume建立4個OSD：

$ ceph-volume lvm create --bluestore --data ceph-block-0/block-0 --block.db ceph-db-0/db-0 $ ceph-volume lvm create --bluestore --data ceph-block-1/block-1 --block.db ceph-db-0/db-1 $ ceph-volume lvm create --bluestore --data ceph-block-2/block-2 --block.db ceph-db-0/db-2 $ ceph-volume lvm create --bluestore --data ceph-block-3/block-3 --block.db ceph-db-0/db-3

使用混合旋轉和固態驅動器設置時，爲Bluestore建立足夠大的block.db邏輯卷很是重要。一般，block.db應具備儘量大的邏輯卷。

建議block.db大小不小於塊的4％。例如，若是塊大小爲1TB，則block.db不該小於40GB。

若是不使用快速和慢速設備的混合，則不須要爲block.db（或block.wal）建立單獨的邏輯卷。 Bluestore將在塊空間內自動管理這些內容。

緩存自動調節

當tc_malloc配置爲內存分配器而且啓用了bluestore_cache_autotune設置時，能夠將Bluestore配置爲自動調整其緩存大小。

默認狀況下，此選項當前已啓用。 Bluestore將嘗試經過osd_memory_target配置選項將OSD堆內存使用量保持在指定的目標大小。這是一種盡力而爲的算法，緩存的收縮率不會小於osd_memory_cache_min指定的數量。高速緩存比率基於優先級的層次來選擇。若是不提供優先級信息，則將bluestore_cache_meta_ratio和bluestore_cache_kv_ratio選項用做回退。

bluestore_cache_autotune 描述： 在遵循最小值的同時自動調整分配給不一樣bluestore緩存的比率。 類型： Boolean 是否必須： Yes 默認值 True osd_memory_target 描述： 當tcmalloc可用且啓用了緩存自動調整時，將嘗試將這麼多字節映射到內存中。 注意：這可能與進程的RSS內存使用不徹底匹配。雖然進程映射的堆內存總量一般應該接近此目標，但沒法保證內核實際上將回收未映射的內存。 在最初的開發過程當中，發現一些內核致使OSD的RSS內存超過映射內存高達20％。 然而，假設當存在大量內存壓力時，內核一般可能更積極地回收未映射的內存。 類型： Unsigned Integer 是否必須： Yes 默認值 4294967296 bluestore_cache_autotune_chunk_size 描述： 啓用高速緩存自動調節時分配給高速緩存的塊大小（以字節爲單位）。當autotuner將內存分配給不一樣的緩存時，它將以chunk的形式分配內存。
這樣作是爲了不在堆大小或自動調整的高速緩存比率有輕微波動時evictions 類型： Unsigned Integer 是否必須： No 默認值 33554432 bluestore_cache_autotune_interval 描述： 啓用高速緩存自動調節後從新平衡的的間隔。將間隔設置得過小會致使CPU使用率太高和性能降低。 類型： Float 是否必須： No 默認值 5 osd_memory_base 描述： 啓用tcmalloc和緩存自動調整時，估計OSD所需的最小內存量（以字節爲單位）。這用於幫助自動調整器估計高速緩存的預期聚合內存消耗。 類型： Unsigned Interger 是否必須： No 默認值 805306368 osd_memory_expected_fragmentation 描述： 啓用tcmalloc和緩存自動調整時，估計內存碎片的百分比。這用於幫助自動調整器估計高速緩存的預期聚合內存消耗。 類型： Float 是否必須： No 默認值 0.15 osd_memory_cache_min 描述： 啓用tcmalloc和緩存自動調整時，設置用於緩存的最小內存量。注意：將此值設置得過低會致使明顯的緩存抖動。 類型： Unsigned Integer 是否必須： No 默認值 134217728 osd_memory_cache_resize_interval 描述： 啓用tcmalloc和緩存自動調整時，調整緩存大小間隔（秒）。此設置更改bluestore可用於緩存的總內存量。注意：將間隔設置得過小會致使內存分配器抖動並下降性能。 類型： Float 是否必須： No 默認值 1

手動調節緩存

BlueStore緩存的每一個OSD消耗的內存量由bluestore_cache_size配置選項決定。若是未設置該配置選項（即，保持爲0），則根據是否將HDD或SSD用於主設備（由bluestore_cache_size_ssd和bluestore_cache_size_hdd配置選項設置），使用不一樣的默認值。

BlueStore和Ceph OSD的其他部分目前最好可以地嚴格預算內存。除了配置的高速緩存大小以外，還有OSD自己消耗的內存，而且一般因爲內存碎片和其餘分配器開銷而產生一些開銷。

配置的高速緩存內存預算能夠經過幾種不一樣的方式使用：

Key/Value 元數據（即RocksDB的內部緩存）
BlueStore元數據
BlueStore數據（即最近讀取或寫入的對象數據）

高速緩存內存使用狀況由如下選項控制：bluestore_cache_meta_ratio，bluestore_cache_kv_ratio和bluestore_cache_kv_max。專用於數據的緩存部分是1.0減去meta和kv比率。專用於kv元數據的內存（RocksDB緩存）由bluestore_cache_kv_max限制。

bluestore_cache_size 描述： BlueStore將用於其緩存的內存量。若是爲零，則將使用bluestore_cache_size_hdd或bluestore_cache_size_ssd。 類型： Unsigned Integer 是否必須： Yes 默認值 0 bluestore_cache_size_hdd 描述： 當由HDD支持時，BlueStore將用於其緩存的默認內存量。 類型： Unsigned Integer 是否必須： Yes 默認值 1 * 1024 * 1024 * 1024 (1 GB) bluestore_cache_size_ssd 描述： 當SSD支持時，BlueStore將用於其緩存的默認內存量。 類型： Unsigned Integer 是否必須： Yes 默認值 3 * 1024 * 1024 * 1024 (3 GB) bluestore_cache_meta_ratio 描述： 專用於元數據的緩存比率。 類型： Floating point 是否必須： Yes 默認值 .01 bluestore_cache_kv_ratio 描述： 專用於鍵/值數據的緩存比率（rocksdb）。 類型： Floating point 是否必須： Yes 默認值 .99 bluestore_cache_kv_max 描述： 用於鍵/值數據（rocksdb）的最大緩存量。 類型： Unsigned Integer 是否必須： Yes 默認值 512 * 1024*1024 (512 MB)

校驗

BlueStore校驗全部寫入磁盤的元數據和數據。元數據校驗和由RocksDB處理並使用crc32c。數據校驗和由BlueStore完成，能夠使用crc32c，xxhash32或xxhash64。默認值爲crc32c，取值適合大多數用途。

完整數據校驗和確實增長了BlueStore必須存儲和管理的元數據量。在可能的狀況下，例如，當客戶端指示數據被順序寫入和讀取時，BlueStore將校驗更大的塊，但在許多狀況下，它必須爲每4千字節數據塊存儲校驗和值（一般爲4個字節）。

經過將校驗和截斷爲兩個或一個字節，能夠使用較小的校驗和值，從而減小元數據開銷。權衡的是，隨着校驗和越小，檢測不到隨機錯誤的機率越高，從大約32位（4字節）校驗的四十億分之一到16位（ 2字節）校驗的1/65536，和8位（1字節）校驗的1/256。經過選擇crc32c_16或crc32c_8做爲校驗和算法，能夠使用較小的校驗和值。

校驗和算法能夠經過每一個池的csum_type屬性或global config選項設置。例如

ceph osd pool set <pool-name> csum_type <algorithm>

bluestore_csum_type 描述：要使用的默認校驗和算法。 類型：String 要求：有 有效設置：none，crc32c，crc32c_16，crc32c_8，xxhash32，xxhash64 默認值：crc32c

內聯壓縮

BlueStore內聯壓縮支持snappy，zlib和lz4。lz4壓縮插件在官方發行版中不是分佈式版本。

BlueStore中的數據是否被壓縮是由壓縮模式和與寫入操做相關的任何提示的組合決定的。壓縮模式能夠是：

none：從不壓縮數據。
passive：除非寫入操做具備可壓縮的提示集，不然不要壓縮數據。
aggressive：壓縮數據，除非寫入操做具備不可壓縮的提示集。
force：嘗試壓縮數據，不管如何。

有關可壓縮和不可壓縮IO提示的更多信息，請參閱rados_set_alloc_hint().

請注意，不管模式如何，若是數據塊的大小未充分減少，則不會使用它，而且將存儲未壓縮的原始數據。例如，若是bluestore compression required ratio設置爲.7，則壓縮數據必須是原始大小（或更小）的70％。

compression mode, compression algorithm, compression required ratio, min blob size, and max blob size能夠經過每一個存儲池屬性或global config選項設置。池屬性能夠設置爲：

ceph osd pool set <pool-name> compression_algorithm <algorithm> ceph osd pool set <pool-name> compression_mode <mode> ceph osd pool set <pool-name> compression_required_ratio <ratio> ceph osd pool set <pool-name> compression_min_blob_size <size> ceph osd pool set <pool-name> compression_max_blob_size <size>

bluestore compression algorithm 描述： 若是未設置每一個存儲池的compression_algorithm屬性，則使用默認壓縮（若是有）。因爲在壓縮少許數據時CPU負擔較高，所以不建議對bluestore使用zstd。 類型： String 是否必須： No 有效值： lz4, snappy, zlib, zstd 默認值 snappy bluestore compression mode 描述： 若是池的compression_mode屬性未設置，將使用默認模式 類型： String 是否必須： No 有效值： none, passive, aggressive, force 默認值 none bluestore compression required ratio 描述： 壓縮比率必須達到這個值才進行壓縮 類型： Floating point 是否必須： No 默認值 .875 bluestore compression min blob size 描述： 比這個還小的chunk不進行壓縮.池設置compression_min_blob_size覆蓋這個值. 類型： Unsigned Integer 是否必須： No 默認值 0 bluestore compression min blob size hdd 描述： 旋轉設備最小blob大小 類型： Unsigned Integer 是否必須： No 默認值 128K bluestore compression min blob size ssd 描述： SSD最小blob大小 類型： Unsigned Integer 是否必須： No 默認值 8K bluestore compression max blob size 描述： 大於此尺寸的chunk會被分割成小塊再盡心壓縮，池屬性 compression_max_blob_size設置覆蓋此值 類型： Unsigned Integer 是否必須： No 默認值 0 bluestore compression max blob size hdd 描述： 旋轉設備最大blob尺寸 類型： Unsigned Integer 是否必須： No 默認值 512K bluestore compression max blob size ssd 描述： SSD最大blob尺寸 類型： Unsigned Integer 是否必須： No 默認值 64K

SPDK使用

若是要將NVME SSD用於SPDK驅動程序，則須要準備好系統。有關詳細信息，請參閱SPDK document。

SPDK提供了一個自動配置設備的腳本。用戶能夠以root身份運行腳本：

$ sudo src/spdk/scripts/setup.sh

而後，您須要在此指定NVMe設備的設備選擇器，併爲bluestore_block_path指定「spdk：」前綴。例如，用戶能夠找到Intel PCIe SSD的設備選擇器：

$ lspci -mm -n -D -d 8086:0953

設備選擇器的形式爲DDDD:BB:DD.FF 或 DDDD.BB.DD.FF，而後設置：

bluestore block path = spdk:0000:01:00.0

其中0000:01:00.0是上面lspci命令輸出中找到的設備選擇器。

若是要爲每一個節點運行多個SPDK實例，則必須指定每一個實例將使用的dpdk內存大小（以MB爲單位），以確保每一個實例使用本身的dpdk內存

在大多數狀況下，咱們只須要一個設備用做data，db，db wal。咱們須要確認如下配置：

bluestore_block_db_path = "" bluestore_block_db_size = 0 bluestore_block_wal_path = "" bluestore_block_wal_size = 0

不然，當前實現將符號文件設置爲內核文件系統位置，並使用內核驅動程序發出DB/WAL IO。

FileStore設置

filestore debug omap check 描述:　　 打開對同步檢查過程的調試。代價很高，僅用於調試。 類型:　　 Boolean 是否必需: No 默認值:　　0

擴展屬性

擴展屬性（ XATTR ）是配置裏的重要部分。一些文件系統對 XATTR 字節數有限制，另外在某些狀況下文件系統存儲 XATTR 的速度不如其餘方法。下面的選項讓你用獨立於文件系統的存儲方法，或許能提高性能。

Ceph 擴展屬性用底層文件系統的 XATTR （若是沒有尺寸限制）存儲爲 inline xattr 。若是有限制，如 ext4 限制爲 4KB ，達到 filestore max inline xattr size 或 filestore max inline xattrs 閥值時一些 XATTR 將存儲爲鍵/值數據庫（也叫 omap ）。

filestore max inline xattr size 描述： 每一個對象存儲在文件系統中的XATTR的最大大小（即XFS，btrfs，ext4等）。不該該大於文件系統能夠處理的大小。默認值0表示使用特定於底層文件系統的值。 類型： Unsigned 32-bit Integer 是否必須： No 默認值： 0 filestore max inline xattr size xfs 描述： 存儲在XFS文件系統中的XATTR的最大大小。僅在filestore max inline xattr size == 0時使用 類型： Unsigned 32-bit Integer 是否必須： No 默認值： 65536 filestore max inline xattr size btrfs 描述： 存儲在btrfs文件系統中的XATTR的最大大小。僅在filestore max inline xattr size == 0時使用。 類型： Unsigned 32-bit Integer 是否必須： No 默認值： 2048 filestore max inline xattr size other 描述： 存儲在其餘文件系統中的XATTR的最大大小。僅在filestore max inline xattr size == 0時使用。 類型： Unsigned 32-bit Integer 是否必須： No 默認值： 512 filestore max inline xattrs 描述： 每一個對象的文件系統中存儲的最大XATTR數。默認值0表示使用特定於底層文件系統的值。 類型： 32-bit Integer 是否必須： No 默認值： 0 filestore max inline xattrs xfs 描述： 每一個對象存儲在XFS文件系統中的最大XATTR數。僅在filestore max inline xattrs == 0時使用。 類型： 32-bit Integer 是否必須： No 默認值： 10 filestore max inline xattrs btrfs 描述： 每一個對象存儲在btrfs文件系統中的最大XATTR數。僅在filestore max inline xattrs == 0時使用。 類型： 32-bit Integer 是否必須： No 默認值： 10 filestore max inline xattrs other 描述： 每一個對象存儲在其餘文件系統中的最大XATTR數。僅在filestore max inline xattrs == 0時使用。 類型： 32-bit Integer 是否必須： No 默認值： 2

同步間隔

filestore 須要週期性地靜默寫入、同步文件系統，這建立了一個提交點，而後就能釋放相應的日誌條目了。較大的同步頻率可減少執行同步的時間及保存在日誌裏的數據量；較小的頻率使得後端的文件系統能優化歸併較小的數據和元數據寫入，所以可能使同步更有效。

filestore max sync interval 描述: 同步 filestore 的最大間隔秒數。 類型: Double 是否必需: No 默認值: 5 filestore min sync interval 描述: 同步 filestore 的最小間隔秒數。 類型: Double 是否必需: No 默認值: .01

回寫器

filestore 回寫器強制使用 sync file range 來寫出大塊數據，這樣處理有望減少最終同步的代價。實踐中，禁用「 filestore 回寫器」有時候能提高性能。

filestore flusher 描述:啓用 filestore 回寫器。 類型:Boolean 是否必需:No 默認值:false Deprecated since version v.65. filestore flusher max fds 描述:設置回寫器的最大文件描述符數量。 類型:Integer 是否必需:No 默認值:512 Deprecated since version v.65. filestore sync flush 描述:啓用同步回寫器。 類型:Boolean 是否必需:No 默認值:false Deprecated since version v.65. filestore fsync flushes journal data 描述:文件系統同步時也回寫日誌數據。 類型:Boolean 是否必需:No 默認值:false

隊列

filestore queue max ops 描述： 文件存儲操做接受的最大併發數，超過此設置的請求會被阻塞。 類型： Integer 是否必須： No. 對性能影響最小 默認值： 50 filestore queue max bytes 描述： 一次操做的最大字節數 類型： Integer 是否必須： No 默認值： 100 << 20

超時

filestore op threads 描述： 容許並行操做文件系統的最大線程數 類型： Integer 是否必須： No 默認值： 2 filestore op thread timeout 描述： 文件系統操做線程超時 (秒). 類型： Integer 是否必須： No 默認值： 60 filestore op thread suicide timeout 描述： commit操做超時時間（秒），超時將取消提交  類型： Integer 是否必須： No 默認值： 180

B-TREE FILESYSTEM

filestore btrfs snap 描述： 對 btrfs filestore 啓用快照功能。 類型： Boolean 是否必須： No. Only used for btrfs. 默認值： true filestore btrfs clone range 描述： 容許 btrfs filestore 克隆操做排隊。 類型： Boolean 是否必須： No. Only used for btrfs. 默認值： true

日誌

filestore journal parallel 描述： 容許並行記日誌，對 btrfs 默認開。 類型： Boolean 是否必須： No 默認值： false filestore journal writeahead 描述： 容許預寫日誌，對 xfs 默認開。 類型： Boolean 是否必須： No 默認值： false

雜項

filestore merge threshold 描述： 併入父目錄前，子目錄內的最小文件數。注：負值表示禁用子目錄合併功能。 類型： Integer 是否必須： No 默認值： -10 filestore split multiple 描述： (filestore_split_multiple * abs(filestore_merge_threshold) + (rand() % filestore_split_rand_factor)) * 16是分割爲子目錄前某目錄內的最大文件數 類型： Integer 是否必須： No 默認值： 2 filestore split rand factor 描述： 添加到拆分閾值的隨機因子，以免一次發生太多文件存儲拆分。有關詳細信息，請參閱filestore split multiple。
這隻能在現有的osd離線時經過ceph-objectstore-tool的apply-layout-settings命令更改。 類型： Unsigned 32-bit Integer 是否必須： No 默認值： 20 filestore update to 描述： 限制文件存儲自動升級到指定版本。 類型： Integer 是否必須： No 默認值： 1000 filestore blackhole 描述： 丟棄任何討論中的事務。 類型： Boolean 是否必須： No 默認值： false filestore dump file 描述： 存儲事務轉儲的文件。 類型： Boolean 是否必須： No 默認值： false filestore kill at 描述： 在第n次機會後注入失敗 類型： String 是否必須： No 默認值： false filestore fail eio 描述： eio失敗/崩潰。 類型： Boolean 是否必須： No 默認值： true

日誌設置

Ceph 的 OSD 使用日誌的緣由有二：速度和一致性。

速度：日誌使得 OSD 能夠快速地提交小塊數據的寫入， Ceph 把小片、隨機 IO 依次寫入日誌，這樣，後端文件系統就有可能歸併寫入動做，並最終提高併發承載力。所以，使用 OSD 日誌能展示出優秀的突發寫性能，實際上數據尚未寫入 OSD ，由於文件系統把它們捕捉到了日誌。
一致性： Ceph 的 OSD 守護進程須要一個能保證原子操做的文件系統接口。 OSD 把一個操做的描述寫入日誌，而後把操做應用到文件系統，這使得原子更新一個對象（例如歸置組元數據）。每隔一段 filestore max sync interval 和 filestore min sync interval 之間的時間， OSD 中止寫入、把日誌同步到文件系統，這樣容許 OSD 修整日誌裏的操做並重用空間。若失敗， OSD 從上個同步點開始重放日誌。

OSD 守護進程支持下面的日誌選項：

journal dio 描述： 啓用direct i/o。須要將journal block align設置爲true。 類型： Boolean 是否必須： Yes when using aio. 默認值： true journal aio Changed in version 0.61: Cuttlefish 描述： 使用libaio異步寫日誌. Requires journal dio 設爲 true. 類型： Boolean 是否必須： No. 默認值： Version 0.61 and later, true. Version 0.60 and earlier, false. journal block align 描述： 塊對齊寫. dio and aio須要. 類型： Boolean 是否必須： Yes when using dio and aio. 默認值： true journal max write bytes 描述： 一次寫入日誌的最大尺寸 類型： Integer 是否必須： No 默認值： 10 << 20 journal max write entries 描述： 一次寫入日誌的最大條目 類型： Integer 是否必須： No 默認值： 100 journal queue max ops 描述： 隊列裏容許的最大操做數 類型： Integer 是否必須： No 默認值： 500 journal queue max bytes 描述： 隊列一次操做容許的最大尺寸 類型： Integer 是否必須： No 默認值： 10 << 20 journal align min size 描述： 當負載大於指定最小值時對齊 類型： Integer 是否必須： No 默認值： 64 << 10 journal zero on create 描述： 文件存儲在mkfs期間用0填充整個日誌。 類型： Boolean 是否必須： No 默認值： false

Pool，PG和CRUSH設置

當你建立存儲池並給它設置歸置組數量時若是你沒指定，Ceph 就用默認值。咱們建議更改某些默認值，特別是存儲池的副本數和默認歸置組數量，能夠在運行 pool 命令的時候設置這些值。你也能夠把配置寫入 Ceph 配置文件的 [global] 段來覆蓋默認值。

[global] # By default, Ceph makes 3 replicas of objects. If you want to make four # copies of an object the default value--a primary copy and three replica # copies--reset the default values as shown in 'osd pool default size'. # If you want to allow Ceph to write a lesser number of copies in a degraded # state, set 'osd pool default min size' to a number less than the # 'osd pool default size' value. osd pool default size = 3 # Write an object 3 times. osd pool default min size = 2 # Allow writing two copies in a degraded state. # Ensure you have a realistic number of placement groups. We recommend # approximately 100 per OSD. E.g., total number of OSDs multiplied by 100 # divided by the number of replicas (i.e., osd pool default size). So for # 10 OSDs and osd pool default size = 4, we'd recommend approximately # (100 * 10) / 4 = 250. osd pool default pg num = 250 osd pool default pgp num = 250

mon max pool pg num 描述： 每一個池的最大放置組數。 類型： Integer 默認： 65536 mon pg create interval 描述： 在同一個Ceph OSD守護進程中建立PG間隔秒數。 類型： Float 默認： 30.0 mon pg stuck threshold 描述： 多長時間無響應的 PG 才認爲它卡住了 類型： 32-bit Integer 默認： 300 mon pg min inactive 描述： 若是PG的數量保持非活動狀態超過mon_pg_stuck_threshold設置，則在羣集日誌中發出HEALTH_ERR。非正數意味着禁用，永遠不會進入ERR。 類型： Integer 默認： 1 mon pg warn min per osd 描述： 若是每一個（in）OSD的平均PG數低於此數，則在羣集日誌中發出HEALTH_WARN。 （非正數會禁用此功能） 類型： Integer 默認： 30 mon pg warn max per osd 描述： 若是每一個（in）OSD的平均PG數高於此數，則在羣集日誌中發出HEALTH_WARN。 （非正數會禁用此功能） 類型： Integer 默認： 300 mon pg warn min objects 描述： 若是集羣中的對象總數低於此數量時不警告 類型： Integer 默認： 1000 mon pg warn min pool objects 描述： 存儲池對象數目低於此數量時不警告 類型： Integer 默認： 1000 mon pg check down all threshold 描述： 當檢查全部PG的時候，down OSD的比例不低於這個比例 類型： Float 默認： 0.5 mon pg warn max object skew 描述： 若是某個池的平均對象數目大於mon pg warn max object skew乘以整個池的平均對象數目，則在集羣日誌中發出HEALTH_WARN。 （非正數會禁用此功能） 類型： Float 默認： 10 mon delta reset interval 描述： 在咱們將pg delta重置爲0以前不活動的秒數。咱們跟蹤每一個池的已用空間的增量，例如，這會讓咱們更容易理解恢復的進度或緩存的性能層。可是，若是某個池沒有報告任何活動，咱們只需重置該池的增量歷史記錄。 類型： Integer 默認： 10 mon osd max op age 描述： 在咱們get concerned以前的最大操做時間（使其成爲2的冪）。若是請求被阻止超過此限制，將發出HEALTH_WARN。 類型： Float 默認： 32.0 osd pg bits 描述： 每一個Ceph OSD守護進程給PG的bit數。 類型： 32-bit Integer 默認： 6 osd pgp bits 描述： 每一個Ceph OSD守護進程給PGPs的bit數。 類型： 32-bit Integer 默認： 6 osd crush chooseleaf type 描述： CRUSH規則中用於chooseleaf的存儲桶類型。使用序數排名而不是名稱。 類型： 32-bit Integer 默認： 1. 一般是包含一個或多個Ceph OSD守護進程的host osd crush initial weight 描述： 新添加的osds進入crushmap的初始權重 類型： Double 默認： 以TB爲單位的容量大小爲權重 osd pool default crush rule 描述： 建立複製池時使用的默認CRUSH規則。 類型： 8-bit Integer 默認： -1表示「選擇具備最低數字ID的規則並使用該規則」。這是爲了在沒有規則0的狀況下使池建立工做。 osd pool erasure code stripe unit 描述： 設置糾刪池的對象條帶塊的默認大小（以字節爲單位）。大小爲S的每一個對象將被存儲爲N個條帶，每一個數據塊接收條帶單元字節。 每一個條帶將被單獨編碼/解碼。糾刪配置文件中的stripe_unit設置能夠覆蓋此選項。 類型： Unsigned 32-bit Integer 默認： 4096 osd pool default size 描述： 設置池中對象的副本數。默認值一樣用於ceph osd pool set {pool-name} size {size} 類型： 32-bit Integer 默認： 3 osd pool default min size 描述： 設置池中對象的最小寫入副本數，以確認對客戶端的寫入操做。若是不知足最小值，Ceph將不會確認寫入客戶端。此設置指示降級模式下運行時最少有多少副本數量。 類型： 32-bit Integer 默認： 0表示沒有特定的最小值。若是爲0，則最小值爲 size - (size / 2). osd pool default pg num 描述： 池的默認PG數 類型： 32-bit Integer 默認： 8 osd pool default pgp num 描述： 池的放置的默認pgp數。 PG和PGP應該相等。 類型： 32-bit Integer 默認： 8 osd pool default flags 描述： 新池的默認標誌。 類型： 32-bit Integer 默認： 0 osd max pgls 描述： The maximum number of placement groups to list. A client requesting a large number can tie up the Ceph OSD Daemon. 類型： Unsigned 64-bit Integer 默認： 1024 Note: 默認就好 osd min pg log entries 描述： 修剪日誌文件時要維護的最小放置組日誌數。 類型： 32-bit Int Unsigned 默認： 1000 osd default data pool replay window 描述： OSD等待客戶端重放請求的時間（以秒爲單位） 類型： 32-bit Integer 默認： 45 osd max pg per osd hard ratio 描述： 在OSD拒絕建立新PG以前，羣集容許的每一個OSD的PG數量的比率。若是服務的PG數超過osd max pg per osd hard ratio * mon max pg per osd，OSD將中止建立新的PG。 類型： Float 默認： 2

消息設置

通用設置

ms tcp nodelay 描述： 在messenger tcp會話上禁用nagle算法。 類型： Boolean 是否必須： No 默認： true ms initial backoff 描述： 出錯時重連的初始等待時間 類型： Double 是否必須： No 默認： .2 ms max backoff 描述： 出錯重連時等待的最大時間 類型： Double 是否必須： No 默認： 15.0 ms nocrc 描述： 禁用網絡消息的 crc 校驗， CPU 不足時可提高性能 類型： Boolean 是否必須： No 默認： false ms die on bad msg 描述： 調試選項，無需配置 類型： Boolean 是否必須： No 默認： false ms dispatch throttle bytes 描述： Throttles等待分派的消息的閾值。 類型： 64-bit Unsigned Integer 是否必須： No 默認： 100 << 20 ms bind ipv6 描述： 若是想讓守護進程綁定到 IPv6 地址而非 IPv4 就得啓用（若是你指定了守護進程或集羣 IP 就沒必要要了） 類型： Boolean 是否必須： No 默認： false ms rwthread stack bytes 描述： 堆棧尺寸調試選項，不要配置. 類型： 64-bit Unsigned Integer 是否必須： No 默認： 1024 << 10 ms tcp read timeout 描述： 控制信使在關閉空閒鏈接以前等待的時間（以秒爲單位）。 類型： 64-bit Unsigned Integer 是否必須： No 默認： 900 ms inject socket failures 描述： 調試選項，無需配置 類型： 64-bit Unsigned Integer 是否必須： No 默認： 0

ASYNC MESSENGER OPTIONS

ms async transport type 描述： Async Messenger使用的傳輸類型。能夠是posix，dpdk或rdma。 Posix使用標準TCP / IP網絡，是默認設置。其餘運輸多是實驗性的，支持可能有限。 類型： String 是否必須： No 默認： posix ms async op threads 描述： 每一個Async Messenger實例使用的初始工做線程數。應該至少等於副本的最大數，但若是您的CPU核心數量不足和/或您在單個服務器上託管了大量OSD，則能夠減小它。 類型： 64-bit Unsigned Integer 是否必須： No 默認： 3 ms async max op threads 描述： 每一個Async Messenger實例使用的最大工做線程數。當機器具備有限的CPU數量時設置爲較低的值，而當CPU未充分利用時設置爲較高的值（即，在I / O操做期間，一個或多個CPU始終處於100％負載狀態） 類型： 64-bit Unsigned Integer 是否必須： No 默認： 5 ms async set affinity 描述： 設置爲true以將Async Messenger工做程序綁定到特定CPU核心。 類型： Boolean 是否必須： No 默認： true ms async affinity cores 描述： 當ms async set affinity爲true時，此字符串指定Async Messenger工做程序如何綁定到CPU核心。
例如，"0,2"將workers ＃1和＃2分別綁定到CPU核心＃0和＃2。注意：手動設置關聯時，請確保不將workers 分配給做爲超線程或相似技術的效果而建立的虛擬CPU處理器，由於它們比常規CPU核心慢。 類型： String 是否必須： No 默認： (empty) ms async send inline 描述： 直接從生成消息的線程發送消息，而不是從Async Messenger線程排隊和發送。已知此選項會下降具備大量CPU內核的系統的性能，所以默認狀況下禁用此選項。 類型： Boolean 是否必須： No 默認： false

常規設置

fsid 描述： 文件系統 ID，每集羣一個。 類型： UUID 是否必須： No. 默認： N/A. 一般由部署工具生成。 admin socket 描述： 在某個守護進程上執行管理命令的套接字，無論 Ceph 監視器團體是否已創建。 類型： String 是否必須： No 默認： /var/run/ceph/$cluster-$name.asok pid file 描述： mon、osd、mds 將把它們的 PID 寫入此文件，其名爲 /var/run/$cluster/$type.$id.pid 。
如名爲Ceph的集羣，其 ID爲a的mon進程將建立 /var/run/ceph/mon.a.pid 。若是是正常中止的，pid file 就會被守護進程刪除；若是進程未進入後臺運行（即啓動時加了 -f 或 -d 選項），它就不會建立 pid file 。 類型： String 是否必須： No 默認： No chdir 描述： Ceph 進程一旦啓動、運行就進入這個目錄，默認推薦 / 類型： String 是否必須： No 默認： / max open files 描述： 若是設置了， Ceph 存儲集羣啓動時會設置操做系統的 max open fds （即文件描述符最大容許值），這有助於防止耗盡文件描述符。 類型： 64-bit Integer 是否必須： No 默認： 0 fatal signal handlers 描述： 若是設置了，將安裝 SEGV 、 ABRT 、 BUS 、 ILL 、 FPE 、 XCPU 、 XFSZ 、 SYS 信號處理器，用於產生有用的日誌信息。 類型： Boolean 默認： true

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。