陳云煒 李偉波 陳蔡濤

睿哲科技股份有限公司

在OpenStack云平臺中，對資源的監(jiān)控與計量是確保云平臺穩(wěn)定運行的標(biāo)準(zhǔn)配置，也恰恰是日常最讓人煩惱的問題。尤其在公有云平臺中，對資源的監(jiān)控與計量不僅可以向業(yè)務(wù)使用者展現(xiàn)業(yè)務(wù)對資源的使用情況，還可以成為按需計費模式下的計費依據(jù)，但是監(jiān)控數(shù)據(jù)的準(zhǔn)確性、實時性以及海量監(jiān)控數(shù)據(jù)的處理、儲存和索引性能等都具有挑戰(zhàn)性的工作。說到運維監(jiān)控，大家熟知的有Zabbix、Cacti、Nagios等傳統(tǒng)的開源運維監(jiān)控系統(tǒng)；這些監(jiān)控系統(tǒng)都很強(qiáng)大也很靈活，從普通的業(yè)務(wù)使用上來說，經(jīng)過相關(guān)的配置、插件定制甚至是二次開發(fā)，完全可以完成對系統(tǒng)資源的監(jiān)控與計量功能。但這些監(jiān)控系統(tǒng)畢竟是獨立的監(jiān)控系統(tǒng)，并沒有與OpenStack云平臺進(jìn)行契合，在OpenStack云平臺中增刪業(yè)務(wù)資源時，這些監(jiān)控系統(tǒng)是無感知的，也就是不能自動地對OpenStack云平臺的資源進(jìn)行自動監(jiān)控。并且OpenStack是一個多租戶的云平臺，以上這些開源的監(jiān)控系統(tǒng)中要做到不同租戶的資源數(shù)據(jù)分別監(jiān)控與計量以及索引，還是比較復(fù)雜的。所幸OpenStack社區(qū)有Ceilometer項目來實現(xiàn)OpenStack集群資源監(jiān)控與計量的功能。Ceilometer項目從OpenStack Folsom版本開始發(fā)布，經(jīng)過不斷的迭代，功能也逐漸豐富，包含了監(jiān)控、計量與告警等功能，并且通過OpenStack的endpoint RESTful API以及消息隊列，可以非常好地與OpenStack中的其他項目相結(jié)合，實現(xiàn)分租戶的自動化的資源監(jiān)控和計量。然而由于Ceilometer在運行性能上的一些原因，社區(qū)逐漸地Ceilometer項目進(jìn)行了功能的拆分：Ceilometer主要實現(xiàn)資源數(shù)據(jù)的采集，將計量和數(shù)據(jù)存儲功能分拆成為Gnocchi項目，將告警功能拆分成為Aodh項目。本文僅涉及Ceilometer數(shù)據(jù)采集和Gnocchi數(shù)據(jù)處理和存儲兩個部分，并且基于OpenStack Ocata版及之后版本的Ceilometer和Gnocchi進(jìn)行分析。

二、Ceilometer與Gnocchi架構(gòu)

1．Ceilometer架構(gòu)和基本概念

在OpenStack中Ceilometer主要負(fù)責(zé)數(shù)據(jù)采集，其采用類似于agent加server的結(jié)構(gòu)，大致的架構(gòu)如下圖1所示：

圖 1

其數(shù)據(jù)采集是由agent端來完成的，在Ceilometer中有compute、central、ipmi等類型的agent，一般常用的是compute和central兩種類型的agent：

Compute agent：負(fù)責(zé)收集OpenStack部署中各個計算節(jié)點上VM實例的資源使用數(shù)據(jù)。Compute agent須在每個計算節(jié)點上安裝，并且需要與虛擬機(jī)管理程序（Hypervisor）進(jìn)行密切的交互以獲得VM虛擬機(jī)實例的相關(guān)資源數(shù)據(jù)。不同類型的Hypervisor提供了不同的API，因此Compute agent所能收集的數(shù)據(jù)受限于Hypervisor API所能提供的數(shù)據(jù)類型。

Central agent：負(fù)責(zé)輪詢公共RESTful API，以收集未通過消息隊列發(fā)布消息的OpenStack組件的相關(guān)資源情況，還可以通過SNMP收集硬件相關(guān)的資源。例如：OpenStack Networking、OpenStack Object Storage、OpenStack Block Storage等資源的使用情況均由Central agent輪詢RESTful API來進(jìn)行收集。

IPMI agent：負(fù)責(zé)收集OpenStack部署的各個計算節(jié)點上的IPMI傳感器數(shù)據(jù)和Intel節(jié)點管理器數(shù)據(jù)。此agent需要節(jié)點安裝了ipmitol程序以支持IPMI數(shù)據(jù)收集。

Ceilometer agent采集到的數(shù)據(jù)需要發(fā)送到server端進(jìn)行匯總、分析和儲存，在ceilometer中數(shù)據(jù)的發(fā)送方式是由publisher來定義和處理的，收集到的每種類型的數(shù)據(jù)都可以使用一個或多個publisher發(fā)送，在OpenStack的Ocata版本中，Ceilometer agent采集到的數(shù)據(jù)依然默認(rèn)是采用notifier：／／類型的publisher發(fā)送到消息隊列中。Ceilometer agent采集到的原始數(shù)據(jù)稱為Meter，Meter是資源使用的某個計量項，它的屬性包括：名稱（name）、單位 （unit）、類型（cumulative：累計值，delta：變化值、gauge：離散或者波動值）以及對應(yīng)的資源屬性等；某些數(shù)據(jù)在采集到時可能還不符合相關(guān)格式，因此可以在發(fā)送數(shù)據(jù)前進(jìn)行一些轉(zhuǎn)換，這個轉(zhuǎn)換稱為Transformer，一條Meter數(shù)據(jù)可以經(jīng)過多個Transformer處理后再由publisher發(fā)送，流程簡圖如下圖2所示：

圖 2

在消息隊列中由Ceilometer collector充當(dāng)一個server的角色來消費消息隊列中的收集到的監(jiān)控數(shù)據(jù)消息。Ceilometer collector可將采集到的數(shù)據(jù)進(jìn)一步加工和處理，然后將數(shù)據(jù)通過HTTP方式發(fā)送到Gnocchi組件中進(jìn)行處理和儲存，并且后續(xù)的數(shù)據(jù)索引讀取也是由Gnocchi進(jìn)行處理。但Ceilometer也保留了舊版本的一些功能，可以選擇舊版本Ceilometer的方式將數(shù)據(jù)直接存入一些數(shù)據(jù)庫中。

2．Gnocchi架構(gòu)和基本概念

Gnocchi 提供數(shù)據(jù)存儲服務(wù)，是一個時間序列數(shù)據(jù)庫，為Ceilometer提供存儲后端，致力于解決Ceilometer應(yīng)用中所面臨的大規(guī)模存儲和索引時間序列數(shù)據(jù)的性能問題。Gnocchi不僅解決了大規(guī)模時間序列數(shù)據(jù)存取的性能問題，同時還把OpenStack云平臺中多租戶等特性考慮在內(nèi)。引用Gnocchi官方的一張圖，其架構(gòu)如下圖3所示：

圖 3

由以上架構(gòu)圖可以看出Gnocchi主要有兩個核心部件：API和Metricd，并且依賴于三個外部組件：Measure Storage、Aggregate Storage、Index。

Measure Storage：measures是Gnocchi對數(shù)據(jù)的第三層劃分，是實際的監(jiān)控數(shù)據(jù)。因此Measure Storage用于保存實際監(jiān)控數(shù)據(jù)，并且是臨時保存的，在Gnocchi處理后會刪除其中已處理的數(shù)據(jù)。

Aggregate Storage：首先要理解Aggregate是什么。Gnocchi采用了一種獨特的時間序列存儲方法：它不是存儲原始數(shù)據(jù)點，而是在存儲它們之前對它們按照預(yù)定義的策略進(jìn)行聚合計算，僅保存處理后的數(shù)據(jù)。所以Gnocchi在讀取這些數(shù)據(jù)時會非常快，因為它只需要讀取預(yù)先聚合計算好的結(jié)果。因此Aggregate Storage是用于保存用戶時間看到的聚合計算后的結(jié)果數(shù)據(jù)。

Index：通常是一個關(guān)系型數(shù)據(jù)庫，用于索引resources和metrics，以使得可以快速地從Measure Storage或Aggregate Storage中取出所需要的數(shù)據(jù)。

API：即gnocchi－api服務(wù)進(jìn)程，通過Indexer和Storage的driver，提供查詢和操作ArchivePolicy，Resource，Metric，Measure的接口，并將新到來的Measure存入Measure Storage。

Metricd：即gnocchi－metricd服務(wù)進(jìn)程，根據(jù)Metric定義的ArchivePolicy規(guī)則，周期性地從Measure Storage中匯總聚合計算measures，以及對Aggregate Storage中的數(shù)據(jù)執(zhí)行數(shù)據(jù)聚合計算和清理過期數(shù)據(jù)等動作，并將聚合的結(jié)果數(shù)據(jù)保存到Aggregate Storage。

結(jié)合圖2和圖3來看，在Ceilometer collector中收集到的數(shù)據(jù)通過Gnocchi這個publisher發(fā)到到gnocchi－api，再由gnocchi－api將收集到的數(shù)據(jù)寫入到Measure Storage。Metricd會周期性地檢索Measure Storage是否有數(shù)據(jù)需要處理，并將Measure Storage中的數(shù)據(jù)依次取出進(jìn)行聚合計算，在將計算結(jié)果保存到Aggregate Storage后也將Measure Storage中已處理的measures原始數(shù)據(jù)刪除。

在Gnocchi中，將API和Metricd均設(shè)計成無狀態(tài)的服務(wù)，因此可以很方便地進(jìn)行橫向擴(kuò)展。并且對于運行的gnocchi－metriccd守護(hù)程序或gnocchi－API端點的數(shù)量沒有限制，可以根據(jù)系統(tǒng)的負(fù)載大小調(diào)整相關(guān)服務(wù)進(jìn)程的數(shù)量即可提升系統(tǒng)的處理能力。

三、Ceilometer與Gnocchi的實踐與優(yōu)化

上文簡述了Ceilometer和Gnocchi的基本架構(gòu)和一些基本概念，下文將講述這兩個組件在實際系統(tǒng)中的一些應(yīng)用，以及遇到的一些問題和解決方法。

1．Ceilometer的實踐與優(yōu)化

Ceilometer的部署按照官方文檔進(jìn)行安裝和配置，一般在控制節(jié)點運行ceilometer－central、ceilometer－collector和ceilometer－notification服務(wù)、在計算節(jié)點運行ceilometer－compute服務(wù)。然而官方默認(rèn)的配置并不能完全符合我們的業(yè)務(wù)需求，需要進(jìn)一步優(yōu)化配置。

首先，Ceilometer agent所需要收集的數(shù)據(jù)是由polling．yaml配置文件來定義的，配置文件路徑為：／etc／ceilometer／polling．yaml，而默認(rèn)的配置是執(zhí)行所有定義在ceilometer Python包entry＿points．txt中的收集器來收集發(fā)送所有數(shù)據(jù)：

圖 4

然而這個“全量”的配置可能會導(dǎo)致ceilometer agent代碼層面的錯誤，使得收集數(shù)據(jù)的流程中斷。尤其是對于Ceilometer的Compute agent，上文講到，Ceilometer的Compute agent所能收集的數(shù)據(jù)受限于Hypervisor API所能提供的數(shù)據(jù)類型，而ceilometer entry＿points．txt中定義了所有不同平臺的收集器，那么肯定會有一些收集器不適用當(dāng)前平臺環(huán)境的，從而導(dǎo)致在執(zhí)行這些收集器時程序出錯：

圖 5

從數(shù)據(jù)層面來看，我們應(yīng)該只收集那些業(yè)務(wù)系統(tǒng)關(guān)心的數(shù)據(jù)；因為收集過多的無用數(shù)據(jù)時會給傳輸、處理和儲存都帶來額外的性能開銷，尤其是在使用消息隊列傳輸監(jiān)控數(shù)據(jù)時，消息隊列中大量的消息堆積將會導(dǎo)致消息隊列服務(wù)占用大量的內(nèi)存。因此，我們需要優(yōu)化配置，定制化地執(zhí)行收集器收集我們所需的數(shù)據(jù)。例如，在計算節(jié)點，我們?nèi)绻麅H需收集實例虛擬機(jī)的CPU、內(nèi)存、磁盤還有虛擬網(wǎng)卡的資源使用情況，并根據(jù)各種資源的所需求的實時性定制其發(fā)送數(shù)據(jù)的頻率，簡要配置示例如下圖6所示：

圖 6

其中的interval是發(fā)送數(shù)據(jù)間隔，單位是秒。而meters則是需要收集的數(shù)據(jù)類型，其參數(shù)值需要根據(jù)當(dāng)前Ceilometer所能收集的數(shù)據(jù)類型來設(shè)定，當(dāng)前Ceilometer所支持采集的數(shù)據(jù)類型在／etc／ceilometer／gnocchi＿resources．yaml文件中的metrics域所定義，其值同時會對應(yīng)到Gnocchi中的資源類型，然后才可以在后續(xù)的Gnocchi中檢索和處理。

其次的優(yōu)化是我們需要增加Ceilometer collector的進(jìn)程數(shù)。在上文中提及，在OpenStack Ocata版本中，ceilometer agent收集到的數(shù)據(jù)依然是先通過消息隊列發(fā)送給ceilometer collector處理然后再發(fā)送到Gnocchi。而在Ceilometer中collector默認(rèn)的進(jìn)程數(shù)（即collector workers數(shù)量）是1，當(dāng)集群的虛擬機(jī)數(shù)量越來越多時以及采集的數(shù)據(jù)量越來越大時，因Ceilometer collector處理消息速度過慢就會出現(xiàn)消息堆積的情況，由于collector響應(yīng)不及時還可能導(dǎo)致大量的Unacked消息的出現(xiàn)，如下圖7：

圖 7

出現(xiàn)此類情況后可通過修改／etc／ceilometer／ceilometer．conf的配置，增加collector的workers進(jìn)程數(shù)即可解決。Collector的workers進(jìn)程數(shù)可根據(jù)集群的規(guī)模以及收集的數(shù)據(jù)量以及數(shù)據(jù)上報頻率來設(shè)定，建議在滿足消息隊列中的消息不會持續(xù)堆積的情況下再增加1～2個workers進(jìn)程，以滿足未來一段時間內(nèi)集群虛擬機(jī)不斷增加所帶來的監(jiān)控數(shù)據(jù)增長。

而在OpenStack Ocata版本之后的Ceilometer中，還可以通過修改所有Ceilometer agent中的／etc／ceilometer／pipeline．yaml配置文件，將其中的publishers從notifier：／／改為gnocchi：／／，然后ceilometer agent收集到的數(shù)據(jù)即可直接發(fā)送到Gnocchi的API中，不再需要Ceilometer collector作中轉(zhuǎn)，避免了通過消息隊列發(fā)送給Ceilometer collector處理再轉(zhuǎn)發(fā)到Gnocchi帶來的額外性能消耗：

圖 8

2．Gnocchi的實踐與優(yōu)化

Gnocchi是一個致力于解決Ceilometer應(yīng)用中所面臨的大規(guī)模存儲和索引時間序列數(shù)據(jù)的性能問題的組件，因此在Gnocchi中涉及到比較多關(guān)于性能方面的參數(shù)。

首先是Gnocchi API，其API不僅承擔(dān)了接收上報的原始監(jiān)控數(shù)據(jù)并儲存到Measure Storage的任務(wù)，還承擔(dān)著業(yè)務(wù)系統(tǒng)通過API從Aggregate Storage索引和取出所需數(shù)據(jù)的任務(wù)。在生產(chǎn)環(huán)境中，Gnocchi API一般以WSGI或uWSGI應(yīng)用的形式來運行，可通過Apache的mod＿wsgi來運行g(shù)nocchi－api，官方的默認(rèn)配置如下圖9：

圖 9

可根據(jù)集群規(guī)模的大小調(diào)整單個API實例中的進(jìn)程數(shù)和線程數(shù)來提高API的并發(fā)量；并且Gnocchi API是無狀態(tài)的，因此在集群規(guī)模較大時，可通過部署多個gnocchi－api實例，然后通過負(fù)載均衡分發(fā)請求到每個gnocchi－api，以此提升gnocchi－api的并發(fā)量。

然后是Gnocchi的Metricd，即gnocchi－metricd服務(wù)進(jìn)程，是Gnocchi中最核心的部分。gnocchi－metricd不僅負(fù)責(zé)了周期性地到Measure Storage中取出并計算聚合新的監(jiān)控數(shù)據(jù)，還負(fù)責(zé)了按照預(yù)定策略，周期性地到Aggregate Storage中重新計算聚合舊的監(jiān)控數(shù)據(jù)，并且刪除已過期的監(jiān)控數(shù)據(jù)。因此gnocchi－metricd服務(wù)屬于計算與I／O都是密集型的進(jìn)程，需要配置好恰當(dāng)?shù)膅nocchi－metricd workers進(jìn)程數(shù)。如果gnocchi－metricd進(jìn)程數(shù)過少，則會導(dǎo)致Measure Storage有大量的meansures積壓，并且也會導(dǎo)致Aggregate Storage中有待重新計算聚合的meansures出現(xiàn)積壓，可在OpenStack控制節(jié)點中執(zhí)行g(shù)nocchi status命令查看gnocchi－metricd當(dāng)前的數(shù)據(jù)處理狀態(tài)，如圖10：

圖 10

一般來說，gnocchi－metricd的workers進(jìn)程數(shù)應(yīng)該在滿足meansures不會持續(xù)增加的情況下再增加2個以上的workers進(jìn)程，以滿足未來一段時間內(nèi)集群虛擬機(jī)不斷增加所帶來的監(jiān)控數(shù)據(jù)增長。gnocchi－metricd服務(wù)也是無狀態(tài)的，因此在集群規(guī)模較大時，可通過在多個機(jī)器上部署gnocchi－metricd實例，然后協(xié)同處理集群的meansures監(jiān)控數(shù)據(jù)。

然后是Gnocchi中依賴的一個Index數(shù)據(jù)庫和兩個存儲數(shù)據(jù)的Storage。Index可選MySQL或PostgreSQL等關(guān)系型數(shù)據(jù)庫，并且其保存的數(shù)據(jù)是規(guī)整的關(guān)系數(shù)據(jù)，僅用于查詢索引，數(shù)據(jù)量不會很大，因此一般不會出現(xiàn)性能瓶頸。而Measure Storage和Aggregate Storage承載了Gnocchi的大部分的I／O操作，在海量監(jiān)控數(shù)據(jù)前，其性能至關(guān)重要。Gnocchi官方支持的Measure Storage和Aggregate Storage類型有普通的本地文件File、Ceph、Swift、Amazon S3等，在Gnocchi 4．0版本中還增加了Redis。官方的配置中推薦使用Ceph作為Measure Storage和Aggregate Storage，而在實踐的過程中發(fā)現(xiàn)，如果Gnocchi 4．0以下的版本直接使用性能一般的Ceph集群來當(dāng)作Measure Storage和Aggregate Storage時，在運行一段時間后就可能會出現(xiàn)一些奇怪的性能問題。如圖11，Ceph集群會頻繁地出現(xiàn)OSD ops blocked的警告，甚至出現(xiàn)OSD 自動down的問題：

圖 11

進(jìn)而查看OSD的日志發(fā)現(xiàn)OSD之間有大量的heartbeat check no reply以heartbeat＿map出現(xiàn)had timed out的情況：

圖 12

圖 13

在此情況下Ceph集群幾乎在一種不可用狀態(tài)，大量的讀寫請求被Blocked，運行在Ceph集群中的虛擬機(jī)和Cinder Volume也大量失去了響應(yīng)，而此時gnocchi－api和gnocchi－metricd日志中也出現(xiàn)大量的rados讀寫Ceph集群超時的錯誤：

圖 14

在此類情況下需要把gnocchi－api和gnocchi－metricd進(jìn)程退出，并把Ceph中存儲gnocchi數(shù)據(jù)的pool刪除，待數(shù)據(jù)重新平衡才可恢復(fù)。

通過調(diào)試和摸索，發(fā)現(xiàn)其原因是Ceph對海量小文件的存儲支持還比較差，尤其是在多副本的情況下儲存Gnocchi的監(jiān)控數(shù)據(jù)，其總數(shù)據(jù)量是成倍的增加，究其原因這還得從Ceph的存儲原理來進(jìn)行分析。首先需要了解在Ceph中是以O(shè)bject來儲存文件的，Object的大小由RADOS限定（通常為2MB或者4MB），當(dāng)文件超過這個容量大小之后就會按照每個Object的容量對文件進(jìn)行拆分，每個對象都會有一個唯一的OID用于尋址，由ino與ono生成，ino即是文件的File ID，用于在全局唯一標(biāo)示每一個文件，而ono則是分片的編號。Ceph分割文件為對象后并不會直接將對象存儲進(jìn)OSD中，因為對象的size很小，在一個大規(guī)模的集群中可能有數(shù)以億計個對象，這么多對象光是遍歷尋址，速度就已經(jīng)很緩慢了。因此Ceph中引入PG（Placement Group）的概念，這是一個邏輯上的組，Object通過crush算法映射到一組OSD上，每個PG里包含完整的副本關(guān)系，比如3個數(shù)據(jù)副本分布到一個PG里的3個不同的OSD上。下面引用Ceph論文中的一張圖（圖15）可以比較直觀地理解，將文件按照指定的對象大小分割成多個對象，每個對象根據(jù)hash映射到某個PG，然后再根據(jù)crush算法映射到后端的某幾個OSD上：

圖 15

不同的對象有可能落到同一個PG里，在Ceph實現(xiàn)里，當(dāng)PG存在op（operations）時，在OSD的處理線程中就會給PG加鎖，一直到queue＿transactions里把事務(wù)放到j(luò)ournal的隊列里（以filestore為例）才釋放PG的鎖。從這里可以看出，對于同一個PG里的不同對象，是通過PG鎖來進(jìn)行并發(fā)的控制，好在這個過程中沒有涉及到對象的I／O，效率還是很高的；對于不同PG的對象，可以直接進(jìn)行并發(fā)訪問。

在Ceph中，每一個pool的PG數(shù)都是在創(chuàng)建pool的時候根據(jù)集群規(guī)模大小計算得出的合理值來設(shè)置的，也就是說每一個pool里的PG數(shù)是有限的。在Gnocchi的監(jiān)控數(shù)據(jù)中，每條數(shù)據(jù)的內(nèi)容都很小，并且每條監(jiān)控數(shù)據(jù)就是一個Object，當(dāng)海量小文件存到一個PG數(shù)量較少的Ceph pool中時，就會出現(xiàn)單個PG中包含太多的Object的情況，雖然PG鎖的效率很高，但是在大量小文件讀寫時依然有可能出現(xiàn)處理不過來的情況，從而就會出現(xiàn)op blocked。

另一方面，OSD端處理op時是將op劃分為多個shard，然后每個shard里可以配置多個線程，PG按照取模的方式映射到不同的shard里進(jìn)行處理。一般來說，系統(tǒng)給每個OSD配置的處理線程都是比較少的，如果Gnocchi pool的PG在OSD端一直占用大量處理線程，那么其他Ceph pool的 PG的op就會處于等待處理狀態(tài)，這時也會出現(xiàn)op blocked的情況，而OSD線程占用嚴(yán)重時甚至可能導(dǎo)致OSD進(jìn)程異常退出。在OSD端，除了將數(shù)據(jù)寫入磁盤（Filestore）外還需要寫入文件的Extended Attributes （XATTRs）到文件系統(tǒng)或omap（Object Map）中，面對海量的小文件讀寫，OSD的壓力I／O壓力會明顯增重。

因此在Gnocchi中的數(shù)據(jù)量達(dá)到一定程度時，就可能會對Ceph存儲集群產(chǎn)生不利的影響。在出現(xiàn)這種情況下，以下是一些解決的方案：

方案一：在Gnocchi 4．0以下的版本中，使用Swift或本地文件File作為Measure Storage和Aggregate Storage。亦或者使用Swift或本地文件File作為Measure Storage，而Aggregate Storage繼續(xù)使用Ceph；因為Measure Storage中保存的是原始的監(jiān)控數(shù)據(jù)，數(shù)據(jù)的文件條目量大并且都是小文件，而Aggregate Storage中保存的是聚合計算后的結(jié)果數(shù)據(jù)，數(shù)據(jù)量相對較小。但如果Ceph集群的性能不是很好，尤其是Ceph中的OSD數(shù)量較少時，并且監(jiān)控的數(shù)據(jù)量相對較大，以及需要保存較長一段時間時，不建議使用Ceph。

方案二：升級OpenStack中的Gnocchi版本到4．0及以上，繼續(xù)使用Ceph作為Measure Storage和Aggregate Storage。Gnocchi在4．0及之后的版本代碼中做了優(yōu)化，當(dāng)使用Ceph作為Measure Storage時，Measure Storage中保存的measures是保存在Ceph OSD的omap中而不是OSD的Object文件，omap中的數(shù)據(jù)是保存在Leveldb、Rocksdb等數(shù)據(jù)庫中，所以measures的數(shù)據(jù)并不會寫到磁盤中，以此緩解OSD的I／O壓力。Aggregate Storage中的數(shù)據(jù)依然是保存為Ceph的Object文件。但是在小型Ceph集群中，如果監(jiān)控數(shù)據(jù)量比較大時，依然會對Ceph集群產(chǎn)生一定的性能影響。

方案三：升級OpenStack中的Gnocchi版本到4．0及以上，使用Redis作為Measure Storage，使用Swift或Ceph作為Aggregate Storage。此方案性能最優(yōu)，因為Measure Storage中保存的measures文件量大但容量小，measures需要經(jīng)過gnocchi－api寫入Measure Storage，gnocchi－metricd讀出處理，然后gnocchi－metricd從Measure Storage刪除等步驟。使用Redis這個內(nèi)存型的數(shù)據(jù)庫不僅可以解決Measure Storage海量小文件讀寫頻繁的需求，并且內(nèi)存高速I／O帶寬的優(yōu)勢使得gnocchi－api和gnocchi－metricd在I／O處理上性能更高，系統(tǒng)并發(fā)性能更好。

四、結(jié)語

以上對Ceilometer監(jiān)控數(shù)據(jù)采集和Gnocchi數(shù)據(jù)處理的架構(gòu)和流程作了簡要的分析，并且分析了筆者在將Gnocchi和Ceph存儲結(jié)合使用時出現(xiàn)的一些問題，這些問題在出現(xiàn)在生產(chǎn)環(huán)境中是非常致命的，不僅導(dǎo)致大規(guī)模的業(yè)務(wù)不可用，甚至還可能導(dǎo)致數(shù)據(jù)丟失的風(fēng)險。因此在搭建OpenStack集群時，預(yù)先按照集群規(guī)模、采集的數(shù)據(jù)量等等規(guī)劃好監(jiān)控數(shù)據(jù)的保存方案，對生產(chǎn)環(huán)境上線后的穩(wěn)定性意義深遠(yuǎn)。

審核編輯：符乾江