【圖文教程】打造高性能、高可靠的塊存儲(chǔ)系統(tǒng)

2015-09-23 09:35:42

云計(jì)算 分布式存儲(chǔ)有出色的性能，可以扛很多故障，能夠輕松擴(kuò)展，所以我們使用Ceph構(gòu)建了高性能、高可靠的塊存儲(chǔ)系統(tǒng)，并使用它支撐公有云和托管云的云主機(jī)、云硬盤服務(wù)。由于使用分布式塊存儲(chǔ)系統(tǒng)，避免了復(fù)制鏡像的過(guò)程，所以云主機(jī)的創(chuàng)建時(shí)間可以縮短到10秒以內(nèi)，而且云主機(jī)還能快速熱遷移，方便了運(yùn)維人員對(duì)物理服務(wù)器上硬件和軟件的維護(hù)。

塊存儲(chǔ)系統(tǒng)

分布式存儲(chǔ)有出色的性能，可以扛很多故障，能夠輕松擴(kuò)展，所以我們使用Ceph構(gòu)建了高性能、高可靠的塊存儲(chǔ)系統(tǒng)，并使用它支撐公有云和托管云的云主機(jī)、云硬盤服務(wù)。

由于使用分布式塊存儲(chǔ)系統(tǒng)，避免了復(fù)制鏡像的過(guò)程，所以云主機(jī)的創(chuàng)建時(shí)間可以縮短到10秒以內(nèi)，而且云主機(jī)還能快速熱遷移，方便了運(yùn)維人員對(duì)物理服務(wù)器上硬件和軟件的維護(hù)。

用戶對(duì)于塊存儲(chǔ)系統(tǒng)最直觀的感受來(lái)源于云硬盤服務(wù)，現(xiàn)在我們的云硬盤的特點(diǎn)是：

• 每個(gè)云硬盤***支持 6000 IOPS和170 MB/s的吞吐率，95%的4K隨機(jī)寫操作的延遲小于2ms 。
• 所有數(shù)據(jù)都是三副本，強(qiáng)一致性，持久性高達(dá)10個(gè)9。
• 創(chuàng)建、刪除、掛載、卸載都是秒級(jí)操作。
• 實(shí)時(shí)快照。
• 提供兩種云硬盤類型，性能型和容量型。

軟硬件配置

經(jīng)過(guò)多輪的選型和測(cè)試，并踩過(guò)無(wú)數(shù)的坑之后，我們選擇了合適我們的軟件和硬件。

軟件

硬件

• 從SATA磁盤到SSD，為了提高IOPS和降低Latency。
• 從消費(fèi)級(jí)SSD到企業(yè)級(jí)SSD，為了提高可靠性。
• 從RAID卡到HBA卡，為了提高IOPS和降低Latency。

最小部署架構(gòu)

隨著軟硬件的升級(jí)，需求的調(diào)整， 我們的部署架構(gòu)也不斷在演進(jìn)，力求在成本、性能、可靠性上達(dá)到***平衡點(diǎn)。

最小規(guī)模部署中有12個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)上有3塊SSD。節(jié)點(diǎn)上有2個(gè)萬(wàn)兆口和1個(gè)千兆口，虛擬機(jī)網(wǎng)絡(luò)和存儲(chǔ)網(wǎng)絡(luò)使用萬(wàn)兆口，管理網(wǎng)絡(luò)使用千兆口。每個(gè)集群中都有3個(gè)Ceph Monitor節(jié)點(diǎn)。

輕松擴(kuò)展

云計(jì)算的好處是極強(qiáng)的擴(kuò)展性，作為云計(jì)算的底層架構(gòu)，也需要有快速的Scale-out能力。在塊存儲(chǔ)系統(tǒng)的部署架構(gòu)中，可以以12臺(tái)節(jié)點(diǎn)為單位進(jìn)行擴(kuò)展。

改造OpenStack

原生的OpenStack并不支持統(tǒng)一存儲(chǔ)，云主機(jī)服務(wù)Nova、鏡像服務(wù)Glance、云硬盤服務(wù)Cinder的后端存儲(chǔ)各不相同，造成了嚴(yán)重的內(nèi)耗。我們把這三大服務(wù)的后端統(tǒng)一起來(lái)，進(jìn)行高效管理，解決了虛擬機(jī)創(chuàng)建時(shí)間長(zhǎng)和鏡像風(fēng)暴等問(wèn)題，還能讓虛擬機(jī)隨便漂移。

原生的OpenStack

改造后的OpenStack

使用原生的OpenStack創(chuàng)建虛擬機(jī)需要1~3分鐘，而使用改造后的OpenStack僅需要不到10秒鐘時(shí)間。這是因?yàn)閚ova-compute不再需要通過(guò)HTTP下載整個(gè)鏡像，虛擬機(jī)可以通過(guò)直接讀取Ceph中的鏡像數(shù)據(jù)進(jìn)行啟動(dòng)。

我們還增加兩個(gè)OpenStack沒(méi)有的功能: QoS 和 共享云硬盤。云計(jì)算的另外一個(gè)好處是租戶資源隔離，所以必備QoS。共享云硬盤可以掛載給多臺(tái)云主機(jī)，適用于數(shù)據(jù)處理的場(chǎng)景。

我們還使用了OpenStack的multi-backend功能，支持多種云硬盤類型，現(xiàn)在我們的云硬盤類型有性能型、容量型，可以滿足數(shù)據(jù)庫(kù)和大文件應(yīng)用。

#p#

高性能

存儲(chǔ)系統(tǒng)主要的性能指標(biāo)是IOPS和Latency。我們對(duì)于IOPS的優(yōu)化已經(jīng)達(dá)到了硬件的瓶頸，除非更換更快的固態(tài)硬盤或者閃存卡，或者是改變整個(gè)架構(gòu)。我們對(duì)于Latency的優(yōu)化也快接近完成，可以達(dá)到企業(yè)級(jí)存儲(chǔ)的水平。

復(fù)雜的I/O棧

整個(gè)塊存儲(chǔ)系統(tǒng)有著長(zhǎng)長(zhǎng)的I/O棧，每個(gè)I/O請(qǐng)求要穿過(guò)很多線程和隊(duì)列。

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

優(yōu)化操作系統(tǒng)的參數(shù)可以充分利用硬件的性能。

CPU

• 關(guān)閉CPU節(jié)能模式
• 使用Cgroup綁定Ceph OSD進(jìn)程到固定的CPU Cores上

Memory

• 關(guān)閉NUMA
• 設(shè)置vm.swappiness=0

Block

• 設(shè)置SSD的調(diào)度算法為deadline

FileSystem

• 設(shè)置掛載參數(shù)”noatime nobarrier”

優(yōu)化Qemu

Qemu作為塊存儲(chǔ)系統(tǒng)的直接消費(fèi)者，也有很多值得優(yōu)化的地方。

• Throttle: 平滑的I/O QoS算法
• RBD: 支持discard和flush
• Burst: 支持突發(fā)請(qǐng)求
• Virt-scsi: 支持多隊(duì)列

優(yōu)化Ceph

我們對(duì)于Ceph的優(yōu)化是重頭戲，有很多問(wèn)題也是時(shí)間長(zhǎng)、規(guī)模上去之后才暴露出來(lái)的。

#p#

高可靠性

存儲(chǔ)需要高可靠性，保證數(shù)據(jù)可用并且數(shù)據(jù)不丟失。因?yàn)槲覀兊募軜?gòu)中沒(méi)有使用UPS和NVRAM，所以寫請(qǐng)求的數(shù)據(jù)都是落到三塊硬盤之后才返回，這樣***限度地保證了用戶的數(shù)據(jù)安全。

如何計(jì)算持久性

持久性是數(shù)據(jù)丟失的概率，可以用于度量一個(gè)存儲(chǔ)系統(tǒng)的可靠性，俗稱 “多少個(gè)9”。數(shù)據(jù)的放置(DataPlacement)決定了數(shù)據(jù)持久性，而Ceph的CRUSH MAP又決定了數(shù)據(jù)的放置，因此CRUSH MAP的設(shè)置決定了數(shù)據(jù)持久性。但是，即時(shí)我們知道需要修改CRUSH MAP的設(shè)置，但是我們應(yīng)該怎么修改CRUSH MAP的設(shè)置呢，我們?cè)撊绾斡?jì)算數(shù)據(jù)持久性呢?

我們需要一個(gè)計(jì)算模型和計(jì)算公式，通過(guò)以下資料，我們可以構(gòu)建一個(gè)計(jì)算模型和計(jì)算公式。

• Reliability model
• 《CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data》
• 《Copysets: Reducing the Frequency of Data Loss in Cloud Storage》
• 《Ceph的CRUSH數(shù)據(jù)分布算法介紹》

最終的計(jì)算公式是： P = func(N, R, S, AFR)

• P: 丟失所有副本的概率
• N: 整個(gè)Ceph Pool中OSD的數(shù)量
• R: 副本數(shù)
• S: 在一個(gè)Bucket中OSD的個(gè)數(shù)
• AFR: 磁盤的年平均故障率

這個(gè)計(jì)算模型是怎么樣得到計(jì)算公式的呢?下面是4個(gè)步驟。

1. 先計(jì)算硬盤發(fā)生故障的概率。
2. 定義哪種情況下丟失數(shù)據(jù)不能恢復(fù)。
3. 計(jì)算任意R個(gè)OSD發(fā)生故障的概率。
4. 計(jì)算Ceph丟失PG的概率。

硬盤發(fā)生故障的概率是符合泊松分布的：

• fit = failures in time = 1/MTTF ~= 1/MTBF = AFR/(24*365)
• 事件概率 Pn(λ,t) = (λt)n e-λt / n!

Ceph的每個(gè)PG是有R份副本的，存放在R個(gè)OSD上，當(dāng)存有這個(gè)PG的R個(gè)OSD都發(fā)生故障時(shí)，數(shù)據(jù)是不可訪問(wèn)的，當(dāng)這R個(gè)OSD都損壞時(shí)，數(shù)據(jù)是不可恢復(fù)的。

計(jì)算一年內(nèi)任意R個(gè)OSD發(fā)生相關(guān)故障概率的方法是：

1. 計(jì)算一年內(nèi)有OSD發(fā)生故障的概率。
2. 在Recovery時(shí)間內(nèi)，(R-1)個(gè)OSD發(fā)生故障的概率。
3. 以上概率相乘，就是一年內(nèi)任意R個(gè)OSD發(fā)生相關(guān)故障概率，假設(shè)是 Pr。
4. N個(gè)OSD中，任意R個(gè)OSD的組合數(shù)是C(R, N)。

因?yàn)檫@任意R個(gè)OSD不一定存有同一個(gè)PG的副本，所以這任意R個(gè)OSD發(fā)生故障并不會(huì)導(dǎo)致數(shù)據(jù)不可恢復(fù)，也就是不一定會(huì)導(dǎo)致數(shù)據(jù)丟失。

假設(shè)每個(gè)PG對(duì)應(yīng)一組OSD(有R個(gè)OSD， 稱之為Copy Set)，有可能多個(gè)PG對(duì)應(yīng)同一組OSD。假設(shè)有M個(gè)不同的Copy Set， M是一個(gè)非常重要的數(shù)字。

我們?cè)賮?lái)對(duì)Copy Set進(jìn)行精確的定義：Copy Set上至少有一個(gè)PG的所有副本，當(dāng)這個(gè)Copy Set損壞時(shí)，這個(gè)PG的所有副本也會(huì)丟失，這個(gè)PG上的所有數(shù)據(jù)就不可恢復(fù)。所以Ceph丟失數(shù)據(jù)的事件就是Ceph丟失PG， Ceph丟失PG就是有一個(gè)Copy Set發(fā)生損壞，一個(gè)Copy Set丟失的概率就是 P = Pr * M / C(R, N) 。

持久性公式就是個(gè)量化工具，它可以指明努力的方向。我們先小試牛刀，算一下默認(rèn)情況下的持久性是多少?

假設(shè)我們有3個(gè)機(jī)架，每個(gè)機(jī)架上有8臺(tái)節(jié)點(diǎn)，每個(gè)幾點(diǎn)上有3塊硬盤，每個(gè)硬盤做一個(gè)OSD，則一共有72個(gè)OSD。

默認(rèn)的crush map設(shè)置如下所示

通過(guò)持久性公式，我們得到下面的數(shù)據(jù)。

默認(rèn)情況下，持久性有8個(gè)9，已經(jīng)比一般的RAID5、RAID10要高，和RAID6差不多，但是還不能滿足公有云的要求，因?yàn)楣性频囊?guī)模很大，故障事件的數(shù)學(xué)期望也會(huì)很大，這就逼著我們盡量提高持久性。

提高持久性的方法有很多，比如增加副本數(shù)，使用Erase Code等。不過(guò)這些方法都有弊端，增加副本數(shù)勢(shì)必會(huì)擴(kuò)大成本;使用Erase Code會(huì)導(dǎo)致Latency提高，不適合于塊存儲(chǔ)服務(wù)。在成本和Latency的制約下，還有什么辦法可以提高持久性呢?

前面我們已經(jīng)得到一個(gè)量化公式 P = Pr * M / C(R, N)， 我們從量化公式入手，去提高持久性(也就是降低P)。要想降低P， 就得降低Pr、M，或者是提高C(R, N)。因?yàn)镃(R, N)已經(jīng)確定，我們只能降低Pr和M。

降低恢復(fù)時(shí)間

從Pr的定義可以知道Pr與恢復(fù)時(shí)間有關(guān)，恢復(fù)時(shí)間越短，Pr的值越低。那么恢復(fù)時(shí)間跟什么有關(guān)系呢？

我們需要增加更多的OSD用于數(shù)據(jù)恢復(fù)，以便減少恢復(fù)時(shí)間。目前host bucket不能增加更多的OSD，這是因?yàn)橹鳈C(jī)的網(wǎng)絡(luò)帶寬限制和硬盤插槽限制。解決辦法是從CRUSH MAP入手，增加一種虛擬的Bucket: osd-domain， 不再使用host bucket。

通過(guò)使用osd-domain bucket，我們把持久性提高了10倍，現(xiàn)在持久性有9個(gè)9。

減少Coepy Set個(gè)數(shù)

如何減少Copy Set的個(gè)數(shù)呢?Copy Sets是和PG的映射有關(guān)的，我們從CRUSH MAP的規(guī)則和條件入手，減少Copy Set的個(gè)數(shù)。解決辦法增加虛擬的Bucket: replica-domain， 不再使用rack bucket。每個(gè)PG必須在一個(gè)replica-domain上，PG不能跨replica-domain，這樣可以顯著減少Copy Set的個(gè)數(shù)。

通過(guò)使用replica-domain，現(xiàn)在的持久性有10個(gè)9，持久性比默認(rèn)的crush map設(shè)置提高了100倍。

#p#

自動(dòng)化運(yùn)維

Ceph的運(yùn)維比較費(fèi)心，稍有差池，整個(gè)云平臺(tái)都會(huì)受到影響，因此我們覺(jué)得運(yùn)維的目標(biāo)是可用性：

減少不必要的數(shù)據(jù)遷移，進(jìn)而減少slow requests，保證SLA。

部署

我們整個(gè)云平臺(tái)都是使用Puppet部署的，因此我們使用了Puppet去部署Ceph。一般Ceph的安裝是分階段的：

1. 安裝好Ceph Monitor集群。
2. 格式化Disk，使用文件系統(tǒng)的UUID去注冊(cè)O(shè)SD， 得到OSD ID。
3. 根據(jù)OSD ID去創(chuàng)建數(shù)據(jù)目錄，掛載Disk到數(shù)據(jù)目錄上。
4. 初始化CRUSH MAP。

Puppet只需要完成前三步，第四步一般根據(jù)具體情況用腳本去執(zhí)行。因?yàn)镺SD ID是在執(zhí)行過(guò)程中得到的，而Puppet是編譯后執(zhí)行，這是一個(gè)悲傷的故事，所以puppet-ceph模塊必須設(shè)計(jì)成retry的。

相比eNovance和Stackforge的puppet-ceph模塊，我們的puppet-ceph模塊的優(yōu)點(diǎn)是：

• 更短的部署時(shí)間
• 支持Ceph所有的參數(shù)
• 支持多種硬盤類型
• 使用WWN-ID替代盤符。

維護(hù)

升級(jí)Ceph的過(guò)程很簡(jiǎn)單，三條命令就可以搞定：

1. ceph osd set noout #避免在異常情況下不可控
2. ceph osd down x #提前mark down， 減少slow request
3. service ceph restart osd.x

更換硬件或者升級(jí)內(nèi)核時(shí)需要對(duì)機(jī)器進(jìn)行重啟，步驟也很簡(jiǎn)單:

1. 把這臺(tái)機(jī)器上的虛擬機(jī)遷移到其他機(jī)器上
2. ceph osd set noout
3. ceph osd down x #把這個(gè)機(jī)器上的OSD都設(shè)置為down狀態(tài)
4. service ceph stop osd.x
5. 重啟機(jī)器

擴(kuò)展集群的時(shí)候需要非常小心，因?yàn)樗鼤?huì)觸發(fā)數(shù)據(jù)遷移：

1. 設(shè)置crush map
2. 設(shè)置recovery options
3. 在凌晨12點(diǎn)觸發(fā)數(shù)據(jù)遷移
4. 觀察數(shù)據(jù)遷移的速度，觀察每個(gè)機(jī)器上網(wǎng)口的帶寬，避免跑滿
5. 觀察slow requests的數(shù)量

你總會(huì)碰到硬盤損壞的時(shí)候，替換硬盤時(shí)需要非常小心，你要小心的設(shè)置crush map，你要保證要替換硬盤過(guò)程中replica-domain的weight的值是不變的，這樣才能保證不必須要的數(shù)據(jù)遷移。

監(jiān)控

Ceph自家的Calamari長(zhǎng)得不錯(cuò)，但是不夠?qū)嵱?，而且它的部署、打包還不完善，在CentOS上還有一些BUG，我們只能繼續(xù)使用原有的工具。

• 收集：使用diamond，增加新的colloctor，用于收集更詳細(xì)的數(shù)據(jù)。
• 保存：使用graphite，設(shè)置好采集精度和保存精度。
• 展示：使用grafana，挑了十幾個(gè)工具，發(fā)現(xiàn)還是grafana好看好用。
• 報(bào)警：zabbix agent && ceph health

我們根據(jù)Ceph軟件架構(gòu)對(duì)每個(gè)OSD分成了很多個(gè)throttle層，下面是throttle模型：

有了throttle model，我們可以對(duì)每個(gè)throttle進(jìn)行監(jiān)控，我們?cè)赿iamond上增加了新的collector用于對(duì)這些throttle進(jìn)行監(jiān)控，并重新定義了metric name。

***，我們可以得到每個(gè)OSD每層throttle的監(jiān)控?cái)?shù)據(jù)。但平時(shí)只會(huì)關(guān)注IOPS、吞吐率、OSD Journal延遲、讀請(qǐng)求延遲、容量使用率等。

事故

在云平臺(tái)上線已經(jīng)快一年了，我們遇到的大小事故有：

• SSD GC問(wèn)題，會(huì)導(dǎo)致讀寫請(qǐng)求的Latency非常大，飆到幾百毫秒。
• 網(wǎng)絡(luò)故障，會(huì)導(dǎo)致Monitor把OSD設(shè)置為down狀態(tài)。
• Ceph Bug， 會(huì)導(dǎo)致OSD進(jìn)程直接崩掉。
• XFS Bug， 會(huì)導(dǎo)致集群所有OSD進(jìn)程直接崩掉。
• SSD 損壞。
• Ceph PG inconsistent。
• Ceph數(shù)據(jù)恢復(fù)時(shí)把網(wǎng)絡(luò)帶寬跑滿。

總體來(lái)說(shuō)，Ceph是非常穩(wěn)定和可靠的。

【本文來(lái)源：運(yùn)維幫微信號(hào)】
 

標(biāo)題名稱：【圖文教程】打造高性能、高可靠的塊存儲(chǔ)系統(tǒng)
網(wǎng)頁(yè)鏈接：http://m.5511xx.com/article/cdopgos.html