從傳統(tǒng)運(yùn)維到云運(yùn)維演進(jìn)歷程之軟件定義存儲(chǔ)（三）上

上回書講完了部署，部署完成之后，就開始了無休止的調(diào)優(yōu)，對于Ceph運(yùn)維人員來說最頭痛的莫過于兩件事：一、Ceph調(diào)優(yōu)；二、Ceph運(yùn)維。調(diào)優(yōu)是件非常頭疼的事情，下面來看看運(yùn)維小哥是如何調(diào)優(yōu)的，運(yùn)維小哥根據(jù)網(wǎng)上資料進(jìn)行了一個(gè)調(diào)優(yōu)方法論（調(diào)優(yōu)總結(jié)）。

企業(yè)建站必須是能夠以充分展現(xiàn)企業(yè)形象為主要目的，是企業(yè)文化與產(chǎn)品對外擴(kuò)展宣傳的重要窗口，一個(gè)合格的網(wǎng)站不僅僅能為公司帶來巨大的互聯(lián)網(wǎng)上的收集和信息發(fā)布平臺(tái)，成都創(chuàng)新互聯(lián)公司面向各種領(lǐng)域：垃圾桶等網(wǎng)站設(shè)計(jì)、成都全網(wǎng)營銷解決方案、網(wǎng)站設(shè)計(jì)等建站排名服務(wù)。

關(guān)卡三：部署調(diào)優(yōu)關(guān)之調(diào)優(yōu)（一）

難度：五顆星

優(yōu)化方法論

通過對網(wǎng)上公開資料的分析進(jìn)行總結(jié)，對Ceph的優(yōu)化離不開以下幾點(diǎn)：

硬件層面· 硬件規(guī)劃· SSD選擇· BIOS設(shè)置操作系統(tǒng)層面· Linux Kernel· 內(nèi)存· Cgroup網(wǎng)絡(luò)層面· 巨型幀· 中斷親和· 硬件加速Ceph層面· Ceph Configurations· PG Number調(diào)整

硬件優(yōu)化

1、硬件規(guī)劃· Processor

ceph-osd進(jìn)程在運(yùn)行過程中會(huì)消耗CPU資源，所以一般會(huì)為每一個(gè)ceph-osd進(jìn)程綁定一個(gè)CPU核上。當(dāng)然如果你使用EC方式，可能需要更多的CPU資源。

ceph-mon進(jìn)程并不十分消耗CPU資源，所以不必為ceph-mon進(jìn)程預(yù)留過多的CPU資源。

ceph-msd也是非常消耗CPU資源的，所以需要提供更多的CPU資源。

· 內(nèi)存

ceph-mon和ceph-mds需要2G內(nèi)存，每個(gè)ceph-osd進(jìn)程需要1G內(nèi)存，當(dāng)然2G更好。

· 網(wǎng)絡(luò)規(guī)劃

萬兆網(wǎng)絡(luò)現(xiàn)在基本上是跑Ceph必備的，網(wǎng)絡(luò)規(guī)劃上，也盡量考慮分離cilent和cluster網(wǎng)絡(luò)。

2、SSD選擇

硬件的選擇也直接決定了Ceph集群的性能，從成本考慮，一般選擇SATA SSD作為Journal，Intel SSD DC S3500 Series（http://www.intel.com/content/www/us/en/solid-state-drives/solid-state-drives-dc-s3500-series.html）基本是目前看到的方案中的首選。400G的規(guī)格4K隨機(jī)寫可以達(dá)到11000 IOPS。如果在預(yù)算足夠的情況下，推薦使用PCIE SSD，性能會(huì)得到進(jìn)一步提升，但是由于Journal在向數(shù)據(jù)盤寫入數(shù)據(jù)時(shí)Block后續(xù)請求，所以Journal的加入并未呈現(xiàn)出想象中的性能提升，但是的確會(huì)對Latency有很大的改善。

如何確定你的SSD是否適合作為SSD Journal，可以參考SéBASTIEN HAN的Ceph: How to Test if Your SSD Is Suitable as a Journal Device?（http://www.sebastien-han.fr/blog/2014/10/10/ceph-how-to-test-if-your-ssd-is-suitable-as-a-journal-device/），這里面他也列出了常見的SSD的測試結(jié)果，從結(jié)果來看SATA SSD中，Intel S3500性能表現(xiàn)最好。

3、BIOS設(shè)置

（1）Hyper-Threading(HT)

使用超線程（Hyper-Threading）技術(shù)，可以實(shí)現(xiàn)在一個(gè)CPU物理核心上提供兩個(gè)邏輯線程并行處理任務(wù)，在擁有12個(gè)物理核心的E5 2620 v3中，配合超線程，可以達(dá)到24個(gè)邏輯線程。更多的邏輯線程可以讓操作系統(tǒng)更好地利用CPU，讓CPU盡可能處于工作狀態(tài)?；咀鲈破脚_(tái)的，VT和HT打開都是必須的，超線程技術(shù)(HT)就是利用特殊的硬件指令，把兩個(gè)邏輯內(nèi)核模擬成兩個(gè)物理芯片，讓單個(gè)處理器都能使用線程級并行計(jì)算，進(jìn)而兼容多線程操作系統(tǒng)和軟件，減少了CPU的閑置時(shí)間，提高的CPU的運(yùn)行效率。

圖1 打開超線程

（2）關(guān)閉節(jié)能

很多服務(wù)器出于能耗考慮，在出場時(shí)會(huì)在BIOS中打開節(jié)能模式，在節(jié)能模式下，CPU會(huì)根據(jù)機(jī)器負(fù)載動(dòng)態(tài)調(diào)整頻率。但是這個(gè)動(dòng)態(tài)調(diào)頻并不像想象中的那么美好，有時(shí)候會(huì)因此影響CPU的性能，在像Ceph這種需要高性能的應(yīng)用場景下，建議關(guān)閉節(jié)能模式。關(guān)閉節(jié)能后，對性能還是有所提升的。

圖2關(guān)閉節(jié)能

當(dāng)然也可以在操作系統(tǒng)級別進(jìn)行調(diào)整，詳細(xì)的調(diào)整過程請參考鏈接（http://www.servernoobs.com/avoiding-cpu-speed-scaling-in-modern-linux-distributions-running-cpu-at-full-speed-tips/），但是不知道是不是由于BIOS已經(jīng)調(diào)整的緣故，所以在CentOS 6.6上并沒有發(fā)現(xiàn)相關(guān)的設(shè)置。

for CPUFREQ in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do [ -f $CPUFREQ ] || continue; echo -n performance > $CPUFREQ; done

（3）NUMA

簡單來說，NUMA思路就是將內(nèi)存和CPU分割為多個(gè)區(qū)域，每個(gè)區(qū)域叫做NODE,然后將NODE高速互聯(lián)。 node內(nèi)cpu與內(nèi)存訪問速度快于訪問其他node的內(nèi)存，NUMA可能會(huì)在某些情況下影響ceph-osd（http://lists.ceph.com/pipermail/ceph-users-ceph.com/2013-December/036211.html）。解決的方案，一種是通過BIOS關(guān)閉NUMA，另外一種就是通過cgroup將ceph-osd進(jìn)程與某一個(gè)CPU Core以及同一NODE下的內(nèi)存進(jìn)行綁定。但是第二種看起來更麻煩，所以一般部署的時(shí)候可以在系統(tǒng)層面關(guān)閉NUMA。

圖3 關(guān)閉NUMA

CentOS系統(tǒng)下，通過修改/etc/grub.conf文件，添加numa=off來關(guān)閉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.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM   biosdevname=0 numa=off

操作系統(tǒng)優(yōu)化

1、Linux Kernel

Linux操作系統(tǒng)在服務(wù)器市場中占據(jù)了相當(dāng)大的份額，各種發(fā)行版及其衍生版在不同領(lǐng)域中承載著各式各樣的服務(wù)。針對不同的應(yīng)用環(huán)境，可以對Linux的性能進(jìn)行相應(yīng)的調(diào)整，性能調(diào)優(yōu)涵蓋了虛擬內(nèi)存管理、I/O子系統(tǒng)、進(jìn)程調(diào)度系統(tǒng)、文件系統(tǒng)等眾多內(nèi)容，這里僅討論對于Ceph性能影響顯著的部分內(nèi)容。

在Linux的各種發(fā)行版中，為了保證對硬件的兼容和可靠性，很多內(nèi)核參數(shù)都采用了較為保守的設(shè)置，然而這無法滿足我們對于高性能計(jì)算的需求，為了Ceph能更好地利用系統(tǒng)資源，我們需要對部分參數(shù)進(jìn)行調(diào)整。

（1）調(diào)度

Linux默認(rèn)的I/O調(diào)度一般針對磁盤尋址慢的特性做了專門優(yōu)化，但對于SSD而言，由于訪問磁盤不同邏輯扇區(qū)的時(shí)間幾乎是一樣的，這個(gè)優(yōu)化就沒有什么作用了，反而耗費(fèi)了CPU時(shí)間。所以，使用Noop調(diào)度器替代內(nèi)核默認(rèn)的CFQ。操作如下：

echo noop > /sys/block/sdX/queue/scheduler

而機(jī)械硬盤設(shè)置為：

echo deadline > /sys/block/sdX/queue/scheduler

（2）預(yù)讀

Linux默認(rèn)的預(yù)讀read_ahead_kb并不適合RADOS對象存儲(chǔ)讀，建議設(shè)置更大值：

echo “8192” > /sys/block/sdX/queue/read_ahead_kb

（3）進(jìn)程數(shù)量

OSD進(jìn)程需要消耗大量進(jìn)程。關(guān)于內(nèi)核PID上限，如果單服務(wù)器OSD數(shù)量多的情況下，建議設(shè)置更大值：

echo 4194303 > /proc/sys/kernel/pid_max

調(diào)整CPU頻率，使其運(yùn)行在最高性能下：

echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor >/dev/null2、內(nèi)存

（1）SMP和NUMA

SMP（Symmetric Multi Processor）架構(gòu)中，所有的CPU共享全部資源，如總線、內(nèi)存和I/O等。多個(gè)CPU之間對稱工作，無主從或從屬關(guān)系。每個(gè)CPU都需要通過總線訪問內(nèi)存，整個(gè)系統(tǒng)中的內(nèi)存能被每個(gè)CPU平等（消耗時(shí)間相同）的訪問。然而，在CPU數(shù)量不斷增加后，總線的壓力不斷增加，最終導(dǎo)致CPU的處理能力大大降低。

NUMA架構(gòu)體系中由多個(gè)節(jié)點(diǎn)組成，每個(gè)節(jié)點(diǎn)有若干CPU和它們獨(dú)立的本地內(nèi)存組成，各個(gè)節(jié)點(diǎn)通過互聯(lián)模塊（CrossbarSwitch）進(jìn)行訪問，所以每個(gè)CPU可以訪問整個(gè)系統(tǒng)的內(nèi)存。但是，訪問本地內(nèi)存的速度遠(yuǎn)比訪問遠(yuǎn)程內(nèi)存要快，導(dǎo)致在進(jìn)程發(fā)生調(diào)度后可能需要訪問遠(yuǎn)端內(nèi)存，這種情況下程序的效率會(huì)大大降低。

Ceph目前并未對NUMA架構(gòu)的內(nèi)存做過多優(yōu)化，在日常使用過程中，我們通常使用2～4顆CPU，這種情況下，選擇SMP架構(gòu)的內(nèi)存在效率上還是要高一些。如果條件允許，可以通過進(jìn)程綁定的方法，在保證CPU能盡可能訪問自身內(nèi)存的前提下，使用NUMA架構(gòu)。

（2）SWAP

當(dāng)系統(tǒng)中的物理內(nèi)存不足時(shí)，就需要將一部分內(nèi)存非活躍（inactive）內(nèi)存頁置換到交換分區(qū)（SWAP）中。有時(shí)候我們會(huì)發(fā)現(xiàn)，在物理內(nèi)存還有剩余的情況下，交換分區(qū)就已經(jīng)開始被使用了，這就涉及到kernel中關(guān)于交換分區(qū)的使用策略，由vm.swappiness這個(gè)內(nèi)核參數(shù)控制，該參數(shù)代表使用交換分區(qū)的程度：當(dāng)值為0時(shí)，表示進(jìn)可能地避免換頁操作；當(dāng)值為100時(shí)，表示kernel會(huì)積極的換頁，這會(huì)產(chǎn)生大量磁盤IO。因此，在內(nèi)存充足的情況下，我們一般會(huì)將該參數(shù)設(shè)置為0以保證系統(tǒng)性能。設(shè)定Linux操作系統(tǒng)參數(shù)：vm.swappiness=0，配置到/etc/sysctl.conf。

（3）內(nèi)存管理

Ceph默認(rèn)使用TCmalloc管理內(nèi)存，在非全閃存環(huán)境下，TCmalloc的性能已經(jīng)足夠。全閃存的環(huán)境中，建議增加TCmalloc的Cache大小或者使用jemalloc替換TCmalloc。

增加TCmalloc的Cache大小需要設(shè)置環(huán)境變量，建議設(shè)置為256MB大?。?/p>TCMALLOC_MAX_TOTAL_THREAD_CACHE_BYTES=268435456

使用jemalloc需要重新編譯打包Ceph，修改編譯選項(xiàng)：

–with-jemalloc–without-tcmalloc3、Cgroup

Cgroups是control groups的縮寫，是Linux內(nèi)核提供的一種可以限制、記錄、隔離進(jìn)程組（process groups）所使用的物理資源（如CPU、Memory、IO等）的機(jī)制。最初由Google的工程師提出，后來被整合進(jìn)Linux內(nèi)核。Cgroups也是LXC為實(shí)現(xiàn)虛擬化所使用的資源管理手段，可以說沒有Cgroups就沒有LXC。Cgroups內(nèi)容非常豐富，展開討論完全可以單獨(dú)寫一篇，這里我們簡單說下Cgroups在Ceph中的應(yīng)用。

說到Cgroups，就不得不說下CPU的架構(gòu)，以E5-2620 v3為例（見圖4）：整顆CPU共享L3緩存，每個(gè)物理核心有獨(dú)立的L1和L2緩存，如果開啟超線程后兩個(gè)邏輯CPU會(huì)共享同一塊L1和L2，所以，在使用Cgroups的時(shí)候，我們需要考慮CPU的緩存命中問題。

圖4 E5 2620 v3 CPU拓?fù)鋱D

查看CPU的拓?fù)?，可以通過hwloc工具（http://www.open-mpi.org/projects/hwloc/）來辨別CPU號(hào)碼與真實(shí)物理核心的對應(yīng)關(guān)系。例如在配置2個(gè)Intel(R) Xeon(R) CPU E5-2680 v2的服務(wù)器，CPU拓?fù)洌?/p>Machine (64GB)  NUMANode L#0 (P#0 32GB)    Socket L#0 + L3 L#0 (25MB)      L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0        PU L#0 (P#0)        PU L#1 (P#20)      L2 L#1 (256KB) + L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1        PU L#2 (P#1)        PU L#3 (P#21)

      L2 L#2 (256KB) + L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2

        PU L#4 (P#2)

        PU L#5 (P#22)

      L2 L#3 (256KB) + L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3

        PU L#6 (P#3)

        PU L#7 (P#23)

      L2 L#4 (256KB) + L1d L#4 (32KB) + L1i L#4 (32KB) + Core L#4

        PU L#8 (P#4)

        PU L#9 (P#24)

      L2 L#5 (256KB) + L1d L#5 (32KB) + L1i L#5 (32KB) + Core L#5

        PU L#10 (P#5)

        PU L#11 (P#25)

      L2 L#6 (256KB) + L1d L#6 (32KB) + L1i L#6 (32KB) + Core L#6

        PU L#12 (P#6)

        PU L#13 (P#26)

      L2 L#7 (256KB) + L1d L#7 (32KB) + L1i L#7 (32KB) + Core L#7

        PU L#14 (P#7)

        PU L#15 (P#27)

      L2 L#8 (256KB) + L1d L#8 (32KB) + L1i L#8 (32KB) + Core L#8

        PU L#16 (P#8)

        PU L#17 (P#28)

      L2 L#9 (256KB) + L1d L#9 (32KB) + L1i L#9 (32KB) + Core L#9

        PU L#18 (P#9)

        PU L#19 (P#29)

    HostBridge L#0

      PCIBridge

        PCIBridge

          PCIBridge

            PCI 8086:1d6a

      PCIBridge

        PCI 8086:1521

          Net L#0 “eno1”

        PCI 8086:1521

          Net L#1 “eno2”

        PCI 8086:1521

          Net L#2 “eno3”

        PCI 8086:1521

          Net L#3 “eno4”

      PCIBridge

        PCI 1000:0079

          Block L#4 “sda”

          Block L#5 “sdb”

          Block L#6 “sdc”

          Block L#7 “sdd”

          Block L#8 “sde”

      PCIBridge

        PCI 102b:0522

          GPU L#9 “card0”

          GPU L#10 “controlD64”

      PCI 8086:1d02

        Block L#11 “sr0”

  NUMANode L#1 (P#1 32GB)

    Socket L#1 + L3 L#1 (25MB)

      L2 L#10 (256KB) + L1d L#10 (32KB) + L1i L#10 (32KB) + Core L#10

        PU L#20 (P#10)

        PU L#21 (P#30)

      L2 L#11 (256KB) + L1d L#11 (32KB) + L1i L#11 (32KB) + Core L#11

        PU L#22 (P#11)

        PU L#23 (P#31)

      L2 L#12 (256KB) + L1d L#12 (32KB) + L1i L#12 (32KB) + Core L#12

        PU L#24 (P#12)

        PU L#25 (P#32)

      L2 L#13 (256KB) + L1d L#13 (32KB) + L1i L#13 (32KB) + Core L#13

        PU L#26 (P#13)

        PU L#27 (P#33)

      L2 L#14 (256KB) + L1d L#14 (32KB) + L1i L#14 (32KB) + Core L#14

        PU L#28 (P#14)

        PU L#29 (P#34)

      L2 L#15 (256KB) + L1d L#15 (32KB) + L1i L#15 (32KB) + Core L#15

        PU L#30 (P#15)

        PU L#31 (P#35)

      L2 L#16 (256KB) + L1d L#16 (32KB) + L1i L#16 (32KB) + Core L#16

        PU L#32 (P#16)

        PU L#33 (P#36)

      L2 L#17 (256KB) + L1d L#17 (32KB) + L1i L#17 (32KB) + Core L#17

        PU L#34 (P#17)

        PU L#35 (P#37)

      L2 L#18 (256KB) + L1d L#18 (32KB) + L1i L#18 (32KB) + Core L#18

        PU L#36 (P#18)

        PU L#37 (P#38)

      L2 L#19 (256KB) + L1d L#19 (32KB) + L1i L#19 (32KB) + Core L#19

        PU L#38 (P#19)

        PU L#39 (P#39)

    HostBridge L#7

      PCIBridge

        PCI 8086:10fb

          Net L#12 “enp129s0f0”

        PCI 8086:10fb

          Net L#13 “enp129s0f1”

由此可見，操作系統(tǒng)識(shí)別的CPU號(hào)和物理核心是一一對應(yīng)的關(guān)系，在對程序做CPU綁定或者使用Cgroups進(jìn)行隔離時(shí)，注意不要跨CPU，以便更好地命中內(nèi)存和緩存。另外也看到，不同HostBridge的對應(yīng)PCI插槽位置不一樣，管理著不同的資源，CPU中斷設(shè)置時(shí)候也需要考慮這個(gè)因素。

總結(jié)一下，使用Cgroups的過程中，我們應(yīng)當(dāng)注意以下問題：

· 防止進(jìn)程跨CPU核心遷移，以更好的利用緩存；

· 防止進(jìn)程跨物理CPU遷移，以更好的利用內(nèi)存和緩存；

· Ceph進(jìn)程和其他進(jìn)程會(huì)互相搶占資源，使用Cgroups做好隔離措施；

· 為Ceph進(jìn)程預(yù)留足夠多的CPU和內(nèi)存資源，防止影響性能或產(chǎn)生OOM。尤其是高性能環(huán)境中并不能完全滿足Ceph進(jìn)程的開銷，在高性能場景（全SSD）下，每個(gè)OSD進(jìn)程可能需要高達(dá)6GHz的CPU和4GB以上的內(nèi)存。

因?yàn)閮?yōu)化部分涉及內(nèi)容較多，所以分為兩篇文章來講述，希望本文能夠給予Ceph新手參考，請讀者見仁見智，預(yù)知后事如何，請期待《部署調(diào)優(yōu)關(guān)卡之調(diào)優(yōu)二》。

分享標(biāo)題：從傳統(tǒng)運(yùn)維到云運(yùn)維演進(jìn)歷程之軟件定義存儲(chǔ)（三）上
當(dāng)前地址：http://bm7419.com/article2/gejhoc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供營銷型網(wǎng)站建設(shè)、用戶體驗(yàn)、網(wǎng)站維護(hù)、移動(dòng)網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)公司、商城網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)