天天看點

從傳統運維到雲運維演進曆程之軟體定義存儲(三)下

上回書講到了運維小哥的調優方法論(上),對于Ceph運維人員來說最頭痛的莫過于兩件事:一、Ceph調優;二、Ceph運維。調優是件非常頭疼的事情,下面來看看運維小哥是如何調優的。

關卡二:部署調優關之調優(二)

難度:五顆星

優化方法論

通過對網上公開資料的分析進行總結,對Ceph的優化離不開以下幾點:

硬體層面

硬體規劃

SSD選擇

BIOS設定

作業系統層面

Linux Kernel

記憶體

Cgroup

網絡層面

巨型幀

中斷親和

硬體加速

Ceph層面

Ceph Configurations

PG Number調整

網絡層面優化

這裡把網絡部分的優化獨立出來寫,主要原因是網絡通信在Ceph的工作流程中被大量使用到。Ceph距今已經有10餘年的曆史,時至今日,Ceph各個元件間的通信依然使用10年前的設計:基于多線程模型的網絡通信,每個終端包含讀和寫兩個線程, 負責消息的接受和發送。在預設三副本的情況下,用戶端的每次寫請求需要至少6次網絡通信。作為Ceph的基石,接下來我們将讨論網絡優化在Ceph中的應用。

任何時候通過一個套接字(socket)來讀寫資料時,都會使用一個系統調用(system call),這個調用将觸發核心上下文切換(Context Switch),下面描述了一個典型的系統調用流程:

1)Ceph程序調用send()函數發送消息。

2)觸發0x80中斷,由使用者态切換至核心态。

3)核心調用system_call()函數,進行參數檢查,根據系統調用好獲得對應的核心函數。

4)執行核心函數,發送資料封包。

5)核心函數執行完畢,切換回核心态。

6)Socket()調用完成。

整個資料發送/接受需要觸發兩次上下文切換,以及若幹次記憶體拷貝,這些操作會消耗大量的時間,我們優化的思路就是減少這些時間損耗。在處理網絡IO時需要CPU消耗大量的計算能力,是以我們希望CPU盡可能少的處理這些瑣碎的IO任務,有足夠的處理能力運作Ceph叢集,我們主要讨論使用巨型幀、中斷親和等技術加速網絡IO。

1.巨型幀

以太網誕生以來,其幀結構一直就沒有發生過大的改變。預設情況下,以太網的MTU(Maximum Transmission Unit)是1500位元組。預設情況下以太網幀是1522 位元組,包含1500位元組的負載、14位元組的以太網頭部、4位元組的CRC、4位元組的VLAN Tag,超過該大小的資料包會在被拆封成更多資料包,巨型幀是長度大于1522位元組的以太網幀,通過調整MTU(通常我們會調整到9000)來減少網絡中資料包的個數,減輕網絡裝置處理標頭的額外開銷。設定MTU需要本地裝置和對端裝置同時開啟,開啟巨型幀後,可以極大地提高性能。

2.中斷親和

前面提到了當我們要進行網絡IO時,會觸發系統中斷。預設情況下,所有的網卡中斷都交由CPU0處理,當大量網絡IO出現時,處理大量網絡IO中斷會導緻CPU0長時間處于滿負載狀态,以緻無法處理更多IO導緻網絡丢包等并發問題,産生系統瓶頸。Linux 2.4核心之後引入了将特定中斷綁定到指定的CPU的技術,稱為中斷親和(SMP IRQ affinity)。

Linux中所有的中斷情況在檔案/proc/interrupt中記錄:

從傳統運維到雲運維演進曆程之軟體定義存儲(三)下

 中斷記錄情況

3.硬體加速 

在大多數情況下,CPU需要負責伺服器中幾乎所有的資料處理任務,事實上CPU并不如我們想象中的那樣強大,在大量的資料進行中往往顯得力不從心,于是便有了硬體加速技術。硬體加速能夠将計算量比較大的工作配置設定給專門的硬體裝置處理,比如常見的使用視訊硬體解碼加速等,在Ceph中,我們主要使用網卡完成對于網絡資料處理的加速。

TCP協定處理網絡流量,需要占用大量CPU和記憶體資源,為了節省伺服器資源的消耗,衆多廠商開始在網卡中内置協處理器,将計算任務移交給協處理器完成,即TCP解除安裝引擎(TCP offload Engine,TOE)。TOE目前主要能協助完成以下工作:

(1)協定處理

普通網卡處理網絡IO的很大一部分壓力都來自于對TCP/IP協定的處理,例如對IP資料包的校驗處理、對TCP資料流的可靠性和一緻性處理。TOE網卡可以将這些計算工作交給網卡上的協處理器完成。

(2)中斷處理

上面講到,在通用網絡IO的處理方式上,普通網卡每個資料包都要觸發一次中斷,TOE網卡則讓每個應用程式完成一次完整的資料處理程序後才出發一次中斷,顯著減輕服務對中斷的響應負擔。

(3)減少記憶體拷貝

普通網卡先将接收到的資料在伺服器的緩沖區中複制一份,經系統處理後配置設定給其中一個TCP連接配接,然後,系統再将這些資料與使用它的應用程式相關聯,并将這些資料由系統緩沖區複制到應用程式的緩沖區。TOE網卡在接收資料時,在網卡内進行協定處理,是以,它不必将資料複制到伺服器緩沖區,而是直接複制到應用程式的緩沖區,這種資料傳輸方式減少了部分記憶體拷貝的消耗。

在Linux中,可以使用ethtool檢視網卡狀态或設定網卡參數。

從傳統運維到雲運維演進曆程之軟體定義存儲(三)下

使用ethtool檢視網卡狀态

使用指令ethtool -K em1 tso on打開tcp-segmentation-offload,檢視tcp-segmentation-offload已經打開(on)。

從傳統運維到雲運維演進曆程之軟體定義存儲(三)下

使用ethtool打開tcp-segmentation-offload

Ceph層面優化

以上部分主要圍繞着硬體、作業系統、網絡進行優化,下面圍繞Ceph的本身參數進行調優,Ceph将很多運作參數作為配置項儲存在配置檔案中,Ceph為我們提供了相當詳細的配置參數供使用者在不同場景下的調整和優化。

1.Ceph Configurations

[global]全局參數以及參數描述,可以通過linux指令sysctl來設定max open files的值fs.file-max。

從傳統運維到雲運維演進曆程之軟體定義存儲(三)下

osd部分filestore參數,調整omap的原因主要是EXT4檔案系統預設僅有4K。

filestore queue相關的參數對于性能影響很小,參數調整不會對性能優化有本質上提升

從傳統運維到雲運維演進曆程之軟體定義存儲(三)下

[osd] -journal相關參數,Ceph OSD程序在往資料盤上刷資料的過程中,是停止寫操作的。

從傳統運維到雲運維演進曆程之軟體定義存儲(三)下

[osd] – osd config tuning相關參數,增加osd op threads和disk threads會帶來額外的CPU開銷。

從傳統運維到雲運維演進曆程之軟體定義存儲(三)下

[osd] – recovery tuning相關參數。

從傳統運維到雲運維演進曆程之軟體定義存儲(三)下

[osd] – client tuning相關參數

從傳統運維到雲運維演進曆程之軟體定義存儲(三)下

2.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

下面的Ceph參數配置是我們在使用過程中逐漸積累的一個優化後的配置,可以基于下面的配置對Ceph叢集進行參數調優。

[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

因為優化部分涉及内容較多,是以分為兩篇文章來講述,至此Ceph部署調優關卡講述完畢,希望本關卡能夠給予Ceph新手參考,請讀者見仁見智,預知後事如何,請期待《性能測試關卡》。

本文轉自Devin 51CTO部落格,原文連結:http://blog.51cto.com/devingeng/1860807

繼續閱讀