危機和幽靈在雲中對大數據的工作負載的性能影響

上周,兩個行業安全漏洞的細節,被稱為危機和幽靈,被釋放。這些事跡使cross-VM和跨平台攻擊通過允許不可信程序掃描其他程序的內存。

在磚上,用戶可以執行任意代碼的唯一地方是在虛擬機運行Apache火花集群。在VM, cross-customer隔離處理水平。磚上運行的雲提供商,Azure和AWS,都宣布他們修補管理程序,防止cross-VM攻擊。磚取決於我們的雲提供商提供安全隔離的虛擬機監控程序在虛擬機和應用程序更新應足以防止演示跨租戶攻擊。

除了安全影響,可能我們的用戶最關心程度的緩解策略引入的性能下降。在夜間績效基準,我們注意到一些變化1月3日,當利用披露。我們初步評估,我們發現一個小退化AWS 3%在大多數情況下,5%的在某一特定情況下,虛擬機監控程序的更新。我們沒有包括初步評估在Azure因為我們沒有曆史數據,我們需要有信心關於這樣一個評估。

在這篇文章中,我們分析了潛在的性能造成的影響為危機和幽靈程序移植,使用我們的夜間性能基準。在一個後續的博客外,我們還提供利用的概述和緩解策略。

介紹

大數據應用程序最resource-demanding雲計算工作負載。對於我們的一些客戶,一個小減速係beplay体育app下载地址統可能導致數百萬美元增加預算。這些功績,關心安全後迫切的問題是:多少後將大數據負載減速hypervisor緩解由雲提供商應用補丁?

正如前麵所提到的,我們注意到一個小高峰後,1月3日在我們的內部性能指示板。偶爾會造成峰值隨機變異的來源,所以我們必須等到我們有更多的數據以堅實的得出結論。現在,我們有了更多的數據點,它已經變得更加明顯,管理程序更新對大數據的工作負載性能影響。

危機的緩解策略和幽靈影響代碼路徑執行虛擬函數調用和上下文切換(如線程切換、係統調用、磁盤I / O, I / O和網絡中斷)。

我們所知,沒有報告存在工作量大數據係統在雲中運行,通常運動從桌麵或服務器應用程序非常不同的代碼路徑。雖然有很多的報告從“對性能的影響可以忽略不計”63%放緩FS-Mark我們已經看到最近的例子是7%到23%的Postgres的退化,我們的一些客戶擔心他們會觀察Apabeplay体育app下载地址che引發類似的性能影響。

然而,盡管都是數據係統,引發的數據平麵(執行者)看起來一點也不像Postgres。項目的主要目標之一鎢在火花2.0是消除盡可能多的虛擬函數分派代碼生成。這個,有幸運的副作用減少危機的影響和幽靈應對當前的火花的執行。

火花的控製平麵(司機)觸發操作可以影響更多的移植。例如,網絡rpc觸發上下文切換和控製平麵的代碼往往執行更多的虛擬功能分派(由於使用麵向對象編程和功能成為megamorphic)。好消息是,司機隻負責調度和協調,並總體上較低的CPU利用率。因此,我們預計不如事務性數據庫係統性能退化引發像Postgres。

方法

之前的基準測試結果,我們首先分享我們如何進行這種分析,利用夜間性能基準。

工作負載:我們的夜間基準包括數以百計的查詢,包括所有99 TPC-DS查詢,運行在兩種最流行的大數據在AWS實例類型的工作負載(r3和i3)。這些查詢用例覆蓋不同的火花,從交互式查詢掃描少量的數據深度分析掃描大量的查詢。總體來說,它們代表了大數據雲中的工作負載。

回到過去:部分原因公共基準測量這些程序補丁非常稀疏的影響是雲供應商應用程序更改利用被披露後不久,和現在沒有辦法回到過去並執行控製實驗應用補丁的機器。我們大多數科學計量需要運行相同的工作負載對一個針對修補應用補丁的數據中心和數據中心。缺席,我們利用夜間性能基準分析退化。

噪音:另外一個挑戰就是,雲計算本質上是嘈雜的,是任何共享資源和分布式係統。網絡或存儲性能可能隨時間因不同的資源利用率。下麵的圖表顯示了去年基準配置的運行時,任何程序之前修複。如圖表所示,即使沒有任何已知的重大更新,我們可以看到巨大的變化從運行運行性能。

因此,我們需要一個足夠數量的去除噪聲的影響。因此我們不能使用一個運行,甚至2分,最後的性能配置。

幸運的是,我們確實有夜間運行績效基準,我們積累了7天1月3日之前和之後的數據(日期似乎AWS補丁適用於我們的係統)。每天,數以百計的查詢是運行在多個集群配置和版本,所以總體來說我們有成千上萬的查詢。

隔離效果的軟件更改:雖然這些基準主要用來跟蹤性能回歸軟件開發的目的,我們也運行舊版本的火花,建立性能基線。使用這些舊版本,我們可以隔離軟件改進的效果。

我們也有額外的版本冒煙測試,運動更全麵的配置和實例類型的矩陣,但他們並不經常運行。我們沒有這些測試報告數據,因為我們覺得沒有足夠的數據點建立強有力的結論。

退化在Amazon Web服務

在AWS,我們觀察到一個小自1月4日性能下降到5%。i3-series實例類型,我們在本地緩存數據NVMe ssd (磚緩存),我們觀察到一個退化高達5%。r3-series實例類型,基準工作隻讀取數據從遠程存儲(S3),我們觀察到一個更小的增加3%。i3實例類型的比例更大的衰退是由係統調用執行的大量閱讀當地SSD的緩存。

下麵的圖表顯示之前和之後的1月3日在AWS r3-series(內存優化)和i3-series集群(基於存儲優化)。這兩個測試都使用固定和集群大小相同的運行時版本。基準數據的平均值代表完整的運行時每天,總共7天前1月3日之前(藍色)和1月3日7天後(紅色)。我們排除1月3日,以防止部分結果。如前所述,i3-series有磚緩存啟用本地ssd,導致大約一半的總執行時間(速度)r3-series相比的結果。

鑒於上述數據,有人可能會懷疑v i係列的不同退化。年代——r是由於不同的實例配置(和架構生成),或者由於磚緩存。我們不能回到過去,重複測試沒有補丁在雲中,隔離的影響磚緩存,我們首次運行的性能相比第一個查詢r3和i3,發現,兩個同樣執行。也就是說,額外的退化是由於緩存。NVMe SSD緩存,CPU利用率更高,火花每秒處理更多的數據,並觸發更多的I / O,比沒有緩存。然而,更新和存儲優化i3-series緩存完全相同的基準在大約一半的時間。

接下來是什麼?

雖然很難是結論性的由於缺乏控製實驗中,我們觀察到一個小的性能下降(2 - 5%)在AWS管理程序更新。我們期望這種影響降低補丁實現改善隨著時間的推移。

然而,我們還沒有完成。整個事件仍在發生。管理程序更新應用的雲供應商隻減輕cross-VM攻擊。整個行業正致力於緩解策略在內核和處理層次,以防止用戶應用程序掃描內存他們不應該被允許。

我們的雲計算廠商的快速反應這個問題重申磚的核心原則,移動雲計算數據處理使安全問題迅速發現,減輕和固定。

即使我們的安全體係結構不依賴於內核或流程級別隔離,謹慎的態度我們也采取及時措施修補漏洞在這些層麵。我們執行控製性能影響的實驗,但我們還沒有感覺到我們已經收集足夠的數據報告。我們將盡快更新。