該文同時發表在盛大遊戲G雲微信公衆號，粘貼於此，方便各位查閱
Ceph，相信很多IT朋友都聽過。因爲搭上了Openstack的順風車，Ceph火了，而且越來越火。然而要用好Ceph卻也不是件易事，在QQ羣裏就經常聽到有初學者抱怨Ceph性能太爛，不好用。事實果真如此嗎！如果你採用Ceph的默認配置來運行你的Ceph集羣，性能自然不能如人意。俗話說，玉不琢,不成器；Ceph也有它的脾性，經過良好配置優化的Ceph性能還是不錯的。下文簡單分享下，盛大遊戲G雲在Ceph優化上的一些實際經驗，如有錯誤之處，歡迎指正。
下文的Ceph配置參數摘自Ceph Hammer 0.94.1 版本
Ceph配置參數優化
首先來看看Ceph客戶端與服務端的交互組件圖：
Ceph是一個統一的可擴展的分佈式存儲，提供Object,Block及file system三種訪問接口；它們都通過底層的librados與後端的OSD交互；OSD是Ceph的對象存儲單元，實現數據的存儲功能。其內部包含衆多模塊，模塊之間通過隊列交換消息，相互協作共同完成io的處理；典型模塊有：網絡模塊Messenger，數據處理模塊Filestore,日誌處理模塊FileJournal等。
面對衆多的模塊，Ceph也提供了豐富的配置選項，初步統計Ceph有上千個配置參數，要配置好這麼多參數，難度有多大可想而知。G雲內部主要使用Ceph Block Storage,即：Ceph rbd；下文的配置參數優化也就限於rbd客戶端（librbd）和OSD端。
下面先來看看客戶端的優化
rbd客戶端配置優化
當Ceph作爲虛擬機塊存儲使用時，Qemu是通過librbd，這個客戶端庫與Ceph集羣交互的；與其相關的配置參數基本都以rbd_爲前綴。可以通過如下命令獲取librbd的當前配置：
//path/to/socket指向某個osd的admin socket文件
#> ceph --admin-daemon {path/to/socket} config show | grep rbd
下面對其中的某些配置參數進行詳細說明：
rbd cache: 是否使能緩存，默認情況下開啓。rbd cache size:最大的緩存大小，默認32MBrbd cache max dirty:緩存中髒數據的最大值，用來控制回寫，不能超過rbd cache size，默認24MBrbd cache target dirty:開始執行回寫的髒數據大小，不能超過rbd cache max dirty，默認16MBrbd cache max dirty age: 緩存中單個髒數據的最大緩存時間，避免因爲未達到回寫要求髒數據長時間存在緩存中，默認1s
點評：開啓Cache能顯著提升順序io的讀寫性能，緩存越大性能越好；如果容許一定的數據丟失，建議開啓。
rbd cache max dirty object:最大的Object對象數，默認爲0，表示通過rbd cache size計算得到，librbd默認以4MB爲單位對磁盤Image進行邏輯切分，每個chunk對象抽象爲一個Object；librbd中以Object爲單位來管理緩存，增大該值可以提升性能。
點評：在ceph-0.94.1中該值較小，建議按照ceph-0.94.4版本中的計算公式增大該值，如下：
obj = MIN(2000, MAX(10, cct->_conf->rbd_cache_size / 100 / sizeof(ObjectCacher::Object)));
我配置的時候取 sizeof(ObjectCacher::Object) = 128, 128是我基於代碼估算的
Object對象大小
rbd cache writethrough until flush:默認爲true，該選項是爲了兼容linux-2.6.32之前的virtio驅動，避免因爲不發送flush請求，數據不回寫；設置該參數後，librbd會以writethrough的方式執行io，直到收到第一個flush請求，才切換爲writeback方式。
點評：如果您的Linux客戶機使用的是2.6.32之前的內核建議設置爲true，否則可以直接關閉。
rbd cache block writes upfront：是否開啓同步io，默認false,開啓後librbd要收到Ceph OSD的應答才返回。
點評： 開啓後，性能最差，但是最安全。
rbd readahead trigger requests: 觸發預讀的連續請求數，默認爲10rbd readahead max bytes: 一次預讀請求的最大io大小，默認512KB，爲0則表示關閉預讀rbd readahead disable after bytes: 預讀緩存的最大數據量，默認爲50MB，超過閥值後，librbd會關閉預讀功能，由Guest OS處理預讀（防止重複緩存）；如果爲0，則表示不限制緩存。
點評：如果是順序讀io爲主，建議開啓
objecter inflight ops: 客戶端流控，允許的最大未發送io請求數，超過閥值會堵塞應用io，爲0表示不受限objecter inflight op bytes:客戶端流控，允許的最大未發送髒數據，超過閥值會堵塞應用io，爲0表示不受限
點評：提供了簡單的客戶端流控功能，防止網絡擁塞；在宿主網絡成爲瓶頸的情況下，
rbd cache中可能充斥着大量處於發送狀態的io，這又會反過來影響io性能。沒有特殊需要的話，不需要修改該值；當然如果帶寬足夠的話，可以根據需要調高該值
rbd ssd cache: 是否開啓磁盤緩存，默認開啓rbd ssd cache size:緩存的最大大小，默認10Grbd ssd cache max dirty:緩存中髒數據的最大值，用來控制回寫，不能超過rbd ssd cache size，默認7.5Grbd ssd cache target dirty:開始執行回寫的髒數據大小，不能超過rbd cache max dirty，默認5Grbd ssd chunk order:緩存文件分片大小，默認64KB = 2^16rbd ssd cache path:緩存文件所在的路徑
點評：這是盛大遊戲G雲自己開發的帶掉電保護的rbd cache,前面四個參數與前述
rbd cache *含義相似，rdb ssd chunk size定義緩存文件的分片大小，是緩存文件的最小分配/回收單位，分片大小直接影響緩存文件的使用效率；在運行過程中librbd也會基於io大小動態計算分片大小，並在合適的時候應用到緩存文件.
上面就是盛大遊戲G雲在使用Ceph rbd過程中，在客戶端所做優化的一些經驗，如有錯誤還請多多批評指正，也歡迎各位補充。繼續來看看OSD的調優
OSD配置優化
Ceph OSD端包含了衆多配置參數，所有的配置參數定義在src/common/config_opts.h文件中，當然也可以通過命令查看集羣的當前配置參數：
#> ceph --admin-daemon {path/to/socket} config show
由於能力有限，下面僅分析常見的幾個配置參數：
osd op threads:處理peering等請求的線程數osd disk threads:處理snap trim，replica trim及scrub等的線程數filestore op threads：io線程數
點評：相對來說線程數越多，併發度越高，性能越好；然如果線程太多，頻繁的線程切換也會影響性能；所以在設置線程數時，需要全面考慮節點CPU性能，OSD個數以及存儲介質性質等。通常前兩個參數設置一個較小的值，而最後一個參數設置一個較大的值，以加快io處理速度。在發生peering等異常時可以動態的調整相關的值。
filestore op thread timeout:io線程超時告警時間filestore op thread suicide timeout：io線程自殺時間，當一個線程長時間沒有響應，Ceph會終止該線程，並導致OSD進程退出
點評： 如果io線程出現超時，應結合相關工具/命令分析(如：
ceph osd perf)，是否OSD所在的磁盤存在瓶頸，或者介質故障等
ms dispatch throttle bytes:Messenger流控，控制DispatcherQueue隊列深度，0表示不受限
點評：
Messenger處在OSD的最前端，其性能直接影響io處理速度。在Hammer版本中，io請求添加到OSD::op_shardedwq纔會返回，其他一些請求會直接添加到DispatchQueue中；爲避免Messenger成爲瓶頸，可以將該值設大點
osd_op_num_shards:默認爲5，OSD::op_shardedwq中存儲io的隊列個數osd_op_num_threads_per_shard: 默認爲2，爲OSD::op_shardedwq中每個隊列分配的io分發線程數
點評：作用於
OSD::op_shardedwq的總線程數爲：osd_op_num_shards*osd_op_num_threads_per_shard, 默認爲10；io請求經由Messenger進入，添加到OSD::op_shardedwq後，由上述分發線程發送給後端的filestore處理。視前端網絡（如：10Gbps）和後端介質性能(如：SSD)，可考慮調高該值。
filestore_queue_max_ops:控制filestore中隊列的深度，最大未完成io數filestore_queue_max_bytes:控制filestore中隊列的深度，最大未完成io數據量filestore_queue_commiting_max_ops:如果OSD後端的文件系統支持檢查點，則filestore_queue_max_ops+filestore_queue_commiting_max_ops作爲filestore中隊列的最大深度，表示最大未完成io數filestore_queue_commiting_max_bytes:如果OSD後端的文件系統支持檢查點，則filestore_queue_max_bytes+filestore_queue_commiting_max_bytes作爲filestore中隊列的最大深度，表示最大未完成io數據量
點評： filestore收到前述分發線程遞交的io後，其處理過程首先會受到filestore隊列深度的影響；如果隊列中未完成io超過設置閥值，請求將會堵塞。所以調高該值是不個很明智的選擇。
journal_queue_max_ops: 控制FileJournal中隊列的深度，最大未完成日誌io數journal_queue_max_bytes: 控制FileJournal中隊列的深度，最大未完成日誌io數據量
點評： filestore收到前述分發線程遞交的io後，還會受到FileJournal隊列的影響；如果隊列中未完成io超過設置閥值，請求同樣會堵塞；通常，調高該值是個不錯的選擇；另外，採用獨立的日誌盤， io性能也會有不少的提升
journal_max_write_entries: FileJournal一次異步日誌io最大能處理的條目數journal_max_write_bytes: FileJournal一次異步日誌io最大能處理的數據量
點評： 這兩個參數控制日誌異步io每次能處理的最大io數，通常要根據日誌文件所在磁盤的性能來設置一個合理值
filestore_wbthrottle_enable:默認爲true，控制OSD後端文件系統刷新filestore_wbthrottle_*_bytes_start_flusher:xfs/btrfs文件系統開始執行回刷的髒數據filestore_wbthrottle_*_bytes_hard_limit: xfs/btrfs文件系統允許的最大髒數據，用來控制filestore的io操作filestore_wbthrottle_*_ios_start_flusher:xfs/btrfs文件系統開始執行回刷的io請求數filestore_wbthrottle_*_ios_hard_limit:xfs/btrfs文件系統允許的最大未完成io請求數，用來控制filestore的io操作filestore_wbthrottle_*_inodes_start_flusher:xfs/btrfs文件系統開始執行回刷的對象數filestore_wbthrottle_*_inodes_hard_limit:xfs/btrfs文件系統允許的最大髒對象，用來控制filestore的io操作
點評：*_start_flusher參數定義了刷新xfs/btrfs文件系統髒數據閥值，以將磁盤緩存更新到磁盤；*_hard_limit參數會影響filestore的io操作，堵塞
filestore op thread線程。所以設置一個較大的值性能會有提升
filestore_fd_cache_size: 對象文件句柄緩存大小filestore_fd_cache_shards: 對象文件句柄緩存分片個數
點評：緩存文件句柄能加快文件的訪問速度，個人建議緩存所有的文件句柄，當然請記得調高系統的句柄限制，以免句柄耗盡
filestore_fiemap: 開啓稀疏讀寫特性
點評： 開啓該特性，有助於加快克隆和恢復速度
filestore_merge_threshold: pg子目錄合併的最小文件數filestore_split_multiple: pg子目錄分裂乘數，默認爲2
點評：這兩個參數控制pg目錄的合併與分裂，當目錄下的文件數小於
filestore_merge_threshold時，該目錄的對象文件會被合併到父目錄；如果目錄的文件數大於filestore_merge_threshold*16*filestore_split_multiple,該目錄會分裂成兩個子目錄。設置合理的值可以加快對象文件的索引速度
filestore_omap_header_cache_size: 擴展屬性頭緩存
點評： 緩存對象的擴展屬性_
Header對象，減少對後端leveldb數據庫的訪問，提升查找性能
純屬拋磚引玉，結合個人的實踐經驗，上文給出了Ceph的一些配置參數設置建議，希望能給大家一些思路。Ceph的配置還是比較複雜的，是一項系統工程，各個參數的配置需要綜合考慮各節點的網絡情況，CPU性能，磁盤性能等等因素，歡迎大家留言討論！:-)