轉載自：http://xiaoquqi.github.io/blog/2015/06/28/ceph-performance-optimization-summary/
優化方法論
做任何事情還是要有個方法論的，“授人以魚不如授人以漁”的道理吧，方法通了，所有的問題就有了解決的途徑。通過對公開資料的分析進行總結，對分佈式存儲系統的優化離不開以下幾點：
1. 硬件層面
- 硬件規劃
- SSD選擇
- BIOS設置
2. 軟件層面
- Linux OS
- Ceph Configurations
- PG Number調整
- CRUSH Map
- 其他因素
硬件優化
1. 硬件規劃
- Processor
ceph-osd進程在運行過程中會消耗CPU資源，所以一般會爲每一個ceph-osd進程綁定一個CPU核上。當然如果你使用EC方式，可能需要更多的CPU資源。
ceph-mon進程並不十分消耗CPU資源，所以不必爲ceph-mon進程預留過多的CPU資源。
ceph-msd也是非常消耗CPU資源的，所以需要提供更多的CPU資源。
- 內存
ceph-mon和ceph-mds需要2G內存，每個ceph-osd進程需要1G內存，當然2G更好。
- 網絡規劃
萬兆網絡現在基本上是跑Ceph必備的，網絡規劃上，也儘量考慮分離cilent和cluster網絡。
2. SSD選擇
硬件的選擇也直接決定了Ceph集羣的性能，從成本考慮，一般選擇SATA SSD作爲Journal，Intel® SSD DC S3500 Series基本是目前看到的方案中的首選。400G的規格4K隨機寫可以達到11000 IOPS。如果在預算足夠的情況下，推薦使用PCIE SSD，性能會得到進一步提升，但是由於Journal在向數據盤寫入數據時Block後續請求，所以Journal的加入並未呈現出想象中的性能提升，但是的確會對Latency有很大的改善。
如何確定你的SSD是否適合作爲SSD Journal，可以參考SÉBASTIEN HAN的Ceph: How to Test if Your SSD Is Suitable as a Journal Device?，這裏面他也列出了常見的SSD的測試結果，從結果來看SATA SSD中，Intel S3500性能表現最好。
3. BIOS設置
- Hyper-Threading(HT)
基本做雲平臺的，VT和HT打開都是必須的，超線程技術(HT)就是利用特殊的硬件指令，把兩個邏輯內核模擬成兩個物理芯片，讓單個處理器都能使用線程級並行計算，進而兼容多線程操作系統和軟件，減少了CPU的閒置時間，提高的CPU的運行效率。
- 關閉節能
關閉節能後，對性能還是有所提升的，所以堅決調整成性能型(Performance)。當然也可以在操作系統級別進行調整，詳細的調整過程請參考鏈接，但是不知道是不是由於BIOS已經調整的緣故，所以在CentOS 6.6上並沒有發現相關的設置。
1
|
|
簡單來說，NUMA思路就是將內存和CPU分割爲多個區域，每個區域叫做NODE,然後將NODE高速互聯。 node內cpu與內存訪問速度快於訪問其他node的內存，NUMA可能會在某些情況下影響ceph-osd。解決的方案，一種是通過BIOS關閉NUMA，另外一種就是通過cgroup將ceph-osd進程與某一個CPU Core以及同一NODE下的內存進行綁定。但是第二種看起來更麻煩，所以一般部署的時候可以在系統層面關閉NUMA。CentOS系統下，通過修改/etc/grub.conf文件，添加numa=off來關閉NUMA。
1
|
|
軟件優化
1. Linux OS
- Kernel pid max
1
|
|
- Jumbo frames, 交換機端需要支持該功能，系統網卡設置纔有效果
1
|
|
永久設置
1 2 |
|
- read_ahead, 通過數據預讀並且記載到隨機訪問內存方式提高磁盤讀操作，查看默認值
1
|
|
根據一些Ceph的公開分享，8192是比較理想的值
1
|
|
- swappiness, 主要控制系統對swap的使用，這個參數的調整最先見於UnitedStack公開的文檔中，猜測調整的原因主要是使用swap會影響系統的性能。
1
|
|
- I/O Scheduler，關於I/O Scheculder的調整網上已經有很多資料，這裏不再贅述，簡單說SSD要用noop，SATA/SAS使用deadline。
1 2 |
|
- cgroup
這方面的文章好像比較少，昨天在和Ceph社區交流過程中，Jan Schermer說準備把生產環境中的一些腳本貢獻出來，但是暫時還沒有，他同時也列舉了一些使用cgroup進行隔離的原因。
- 不在process和thread在不同的core上移動(更好的緩存利用)
- 減少NUMA的影響
- 網絡和存儲控制器影響 - 較小
- 通過限制cpuset來限制Linux調度域(不確定是不是重要但是是最佳實踐)
- 如果開啓了HT，可能會造成OSD在thread1上，KVM在thread2上，並且是同一個core。Core的延遲和性能取決於其他一個線程做什麼。
這一點具體實現待補充！！！
2. Ceph Configurations
[global]
| 參數名 | 描述 | 默認值 | 建議值 |
|---|---|---|---|
| public network | 客戶端訪問網絡 | 192.168.100.0/24 | |
| cluster network | 集羣網絡 | 192.168.1.0/24 | |
| max open files | 如果設置了該選項，Ceph會設置系統的max open fds | 0 | 131072 |
- 查看系統最大文件打開數可以使用命令
1
|
|
[osd] - filestore
| 參數名 | 描述 | 默認值 | 建議值 |
|---|---|---|---|
| filestore xattr use omap | 爲XATTRS使用object map，EXT4文件系統時使用，XFS或者btrfs也可以使用 | false | true |
| filestore max sync interval | 從日誌到數據盤最大同步間隔(seconds) | 5 | 15 |
| filestore min sync interval | 從日誌到數據盤最小同步間隔(seconds) | 0.1 | 10 |
| filestore queue max ops | 數據盤最大接受的操作數 | 500 | 25000 |
| filestore queue max bytes | 數據盤一次操作最大字節數(bytes) | 100 << 20 | 10485760 |
| filestore queue committing max ops | 數據盤能夠commit的操作數 | 500 | 5000 |
| filestore queue committing max bytes | 數據盤能夠commit的最大字節數(bytes) | 100 << 20 | 10485760000 |
| filestore op threads | 併發文件系統操作數 | 2 | 32 |
- 調整omap的原因主要是EXT4文件系統默認僅有4K
- filestore queue相關的參數對於性能影響很小，參數調整不會對性能優化有本質上提升
[osd] - journal
| 參數名 | 描述 | 默認值 | 建議值 |
|---|---|---|---|
| osd journal size | OSD日誌大小(MB) | 5120 | 20000 |
| journal max write bytes | journal一次性寫入的最大字節數(bytes) | 10 << 20 | 1073714824 |
| journal max write entries | journal一次性寫入的最大記錄數 | 100 | 10000 |
| journal queue max ops | journal一次性最大在隊列中的操作數 | 500 | 50000 |
| journal queue max bytes | journal一次性最大在隊列中的字節數(bytes) | 10 << 20 | 10485760000 |
- Ceph OSD Daemon stops writes and synchronizes the journal with the filesystem, allowing Ceph OSD Daemons to trim operations from the journal and reuse the space.
- 上面這段話的意思就是，Ceph OSD進程在往數據盤上刷數據的過程中，是停止寫操作的。
[osd] - osd config tuning
| 參數名 | 描述 | 默認值 | 建議值 |
|---|---|---|---|
| osd max write size | OSD一次可寫入的最大值(MB) | 90 | 512 |
| osd client message size cap | 客戶端允許在內存中的最大數據(bytes) | 524288000 | 2147483648 |
| osd deep scrub stride | 在Deep Scrub時候允許讀取的字節數(bytes) | 524288 | 131072 |
| osd op threads | OSD進程操作的線程數 | 2 | 8 |
| osd disk threads | OSD密集型操作例如恢復和Scrubbing時的線程 | 1 | 4 |
| osd map cache size | 保留OSD Map的緩存(MB) | 500 | 1024 |
| osd map cache bl size | OSD進程在內存中的OSD Map緩存(MB) | 50 | 128 |
| osd mount options xfs | Ceph OSD xfs Mount選項 | rw,noatime,inode64 | rw,noexec,nodev,noatime,nodiratime,nobarrier |
- 增加osd op threads和disk threads會帶來額外的CPU開銷
[osd] - recovery tuning
| 參數名 | 描述 | 默認值 | 建議值 |
|---|---|---|---|
| osd recovery op priority | 恢復操作優先級，取值1-63，值越高佔用資源越高 | 10 | 4 |
| osd recovery max active | 同一時間內活躍的恢復請求數 | 15 | 10 |
| osd max backfills | 一個OSD允許的最大backfills數 | 10 | 4 |
[osd] - client tuning
| 參數名 | 描述 | 默認值 | 建議值 |
|---|---|---|---|
| rbd cache | RBD緩存 | true | true |
| rbd cache size | RBD緩存大小(bytes) | 33554432 | 268435456 |
| rbd cache max dirty | 緩存爲write-back時允許的最大dirty字節數(bytes)，如果爲0，使用write-through | 25165824 | 134217728 |
| rbd cache max dirty age | 在被刷新到存儲盤前dirty數據存在緩存的時間(seconds) | 1 | 5 |
關閉Debug
3. PG Number
PG和PGP數量一定要根據OSD的數量進行調整，計算公式如下，但是最後算出的結果一定要接近或者等於一個2的指數。
Total PGs = (Total_number_of_OSD * 100) / max_replication_count
例如15個OSD，副本數爲3的情況下，根據公式計算的結果應該爲500，最接近512，所以需要設定該pool(volumes)的pg_num和pgp_num都爲512.
1 2 |
|
4. CRUSH Map
CRUSH是一個非常靈活的方式，CRUSH MAP的調整取決於部署的具體環境，這個可能需要根據具體情況進行分析，這裏面就不再贅述了。
5. 其他因素的影響
在今年的(2015年)的Ceph Day上，海雲捷迅在調優過程中分享過一個由於在集羣中存在一個性能不好的磁盤，導致整個集羣性能下降的case。通過osd perf可以提供磁盤latency的狀況，同時在運維過程中也可以作爲監控的一個重要指標，很明顯在下面的例子中，OSD 8的磁盤延時較長，所以需要考慮將該OSD剔除出集羣：
1
|
|
osd fs_commit_latency(ms) fs_apply_latency(ms)
0 14 17
1 14 16
2 10 11
3 4 5
4 13 15
5 17 20
6 15 18
7 14 16
8 299 329
ceph.conf
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 |
|