實戰指導：Ceph存儲性能優化總結
最近一直在忙著搞Ceph存儲的優化和測試，看了各種資料，但是好像沒有一篇文章把其中的方法論交代清楚，所以呢想在這里進行一下總結，很多內容并不是我原創，只是做一個總結。如果其中有任何的問題，歡迎各位噴我，以便我提高。
優化方法論
做任何事情還是要有個方法論的，“授人以魚不如授人以漁”的道理吧，方法通了，所有的問題就有了解決的途徑。通過對公開資料的分析進行總結，對分布式存儲系統的優化離不開以下幾點：
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上并沒有發現相關的設置。
- for CPUFREQ in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do [ -f $CPUFREQ ] || continue; echo -n performance > $CPUFREQ; done
- NUMA
簡單來說，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。
- kernel /vmlinuz-2.6.32-504.12.2.el6.x86_64 ro root=UUID=870d47f8-0357-4a32-909f-74173a9f0633 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM biosdevname=0 numa=off
#p#
軟件優化
1. Linux OS
- Kernel pid max
- echo 4194303 > /proc/sys/kernel/pid_max
- Jumbo frames, 交換機端需要支持該功能，系統網卡設置才有效果
- ifconfig eth0 mtu 9000
***設置
- echo "MTU=9000" | tee -a /etc/sysconfig/network-script/ifcfg-eth0
- /etc/init.d/networking restart
read_ahead, 通過數據預讀并且記載到隨機訪問內存方式提高磁盤讀操作，查看默認值
- cat /sys/block/sda/queue/read_ahead_kb
根據一些Ceph的公開分享，8192是比較理想的值
- echo "8192" > /sys/block/sda/queue/read_ahead_kb
- swappiness, 主要控制系統對swap的使用，這個參數的調整***見于UnitedStack公開的文檔中，猜測調整的原因主要是使用swap會影響系統的性能。
- echo "vm.swappiness = 0" | tee -a /etc/sysctl.conf
- I/O Scheduler，關于I/O Scheculder的調整網上已經有很多資料，這里不再贅述，簡單說SSD要用noop，SATA/SAS使用deadline。
- echo "deadline" > /sys/block/sd[x]/queue/scheduler
- echo "noop" > /sys/block/sd[x]/queue/scheduler
- cgroup
這方面的文章好像比較少，昨天在和Ceph社區交流過程中，Jan Schermer說準備把生產環境中的一些腳本貢獻出來，但是暫時還沒有，他同時也列舉了一些使用cgroup進行隔離的原因。
- 不在process和thread在不同的core上移動(更好的緩存利用)
- 減少NUMA的影響
- 網絡和存儲控制器影響 - 較小
- 通過限制cpuset來限制Linux調度域(不確定是不是重要但是是***實踐)
- 如果開啟了HT，可能會造成OSD在thread1上，KVM在thread2上，并且是同一個core。Core的延遲和性能取決于其他一個線程做什么。
這一點具體實現待補充!!!
2. Ceph Configurations
[global]
- 查看系統***文件打開數可以使用命令
- cat /proc/sys/fs/file-max
[osd] - filestore
- 調整omap的原因主要是EXT4文件系統默認僅有4K
- filestore queue相關的參數對于性能影響很小，參數調整不會對性能優化有本質上提升
[osd] - journal
- 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 op threads和disk threads會帶來額外的CPU開銷
[osd] - recovery tuning
[osd] - client tuning
關閉Debug
#p#
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.
- ceph osd pool set volumes pg_num 512
- ceph osd pool set volumes pgp_num 512
4. CRUSH Map
CRUSH是一個非常靈活的方式，CRUSH MAP的調整取決于部署的具體環境，這個可能需要根據具體情況進行分析，這里面就不再贅述了。
5. 其他因素的影響
在今年的(2015年)的Ceph Day上，海云捷迅在調優過程中分享過一個由于在集群中存在一個性能不好的磁盤，導致整個集群性能下降的case。通過osd perf可以提供磁盤latency的狀況，同時在運維過程中也可以作為監控的一個重要指標，很明顯在下面的例子中，OSD 8的磁盤延時較長，所以需要考慮將該OSD剔除出集群：
- ceph osd perf
osd fs_commit_latency(ms) fs_apply_latency(ms)
- 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
- [global]
- fsid = 059f27e8-a23f-4587-9033-3e3679d03b31
- mon_host = 10.10.20.102, 10.10.20.101, 10.10.20.100
- auth cluster required = cephx
- auth service required = cephx
- auth client required = cephx
- osd pool default size = 3
- osd pool default min size = 1
- public network = 10.10.20.0/24
- cluster network = 10.10.20.0/24
- max open files = 131072
- [mon]
- mon data = /var/lib/ceph/mon/ceph-$id
- [osd]
- osd data = /var/lib/ceph/osd/ceph-$id
- osd journal size = 20000
- osd mkfs type = xfs
- osd mkfs options xfs = -f
- filestore xattr use omap = true
- filestore min sync interval = 10
- filestore max sync interval = 15
- filestore queue max ops = 25000
- filestore queue max bytes = 10485760
- filestore queue committing max ops = 5000
- filestore queue committing max bytes = 10485760000
- journal max write bytes = 1073714824
- journal max write entries = 10000
- journal queue max ops = 50000
- journal queue max bytes = 10485760000
- osd max write size = 512
- osd client message size cap = 2147483648
- osd deep scrub stride = 131072
- osd op threads = 8
- osd disk threads = 4
- osd map cache size = 1024
- osd map cache bl size = 128
- osd mount options xfs = "rw,noexec,nodev,noatime,nodiratime,nobarrier"
- osd recovery op priority = 4
- osd recovery max active = 10
- osd max backfills = 4
- [client]
- rbd cache = true
- rbd cache size = 268435456
- rbd cache max dirty = 134217728
- rbd cache max dirty age = 5
總結
優化是一個長期迭代的過程，所有的方法都是別人的，只有在實踐過程中才能發現自己的，本篇文章僅僅是一個開始，歡迎各位積極補充，共同完成一篇具有指導性的文章。
原文鏈接：http://xiaoquqi.github.io/blog/2015/06/28/ceph-performance-optimization-summary/
