【背景】
在現代云平臺中,存儲設備,如基于閃存的固態硬盤(SSD)已經被虛擬化為全系統的共享資源,以提供跨越多個應用實例的存儲服務。這使得云平臺能夠通過在多個多租戶虛擬機(VM)之間進行分片來有效利用存儲容量和帶寬。為了提高云平臺中的資源效率,供應商提供可驅逐的虛擬機(即Spot VMs或Harvest VMs)。這些可驅逐的虛擬機允許用戶以低優先級使用未分配的資源,也就是說,可驅逐的虛擬機的資源可以在任何時候被普通的虛擬機所回收。最近的研究通過用基于啟發式的收集方法改進可驅逐虛擬機的資源分配和調度來推進這項技術。
現有的云平臺通過在多租戶應用之間按需切分存儲資源,有效地利用了存儲資源。然而,我們的研究披露,云存儲在分配和未分配的存儲方面仍然嚴重利用不足。盡管云供應商已經開發了采集技術,允許可驅逐的虛擬機(VM)使用未分配的再資源,但這些技術不能直接應用于存儲資源,因為缺乏對存儲設備的空間、帶寬和數據安全隔離的系統支持。
在本文中,我們提出了BlockFlex,一個基于學習的存儲采集框架,它可以在現代云平臺中以細粒度的方式采集可用的基于閃存的存儲資源。我們重新思考了存儲虛擬化的抽象,并為可驅逐的虛擬機實現了分配和未分配的存儲的透明采集。BlockFlex探索了啟發式和基于學習的方法,以最大限度地提高存儲利用率,同時在存儲設備層面確保常規和可驅逐虛擬機之間的性能和安全隔離。我們利用可編程的固態硬盤(SSD)開發BlockFlex,并通過各種數據中心工作負載證明其效率。
【問題】
1. 資源采集技術無法直接使用到外部存儲資源中
許多工作提出通過資源采集技術采集云上的內存和CPU資源供資源緊張的節點使用,從而提升系統的資源利用率。然而,先前關于資源采集的工作主要集中在CPU和內存資源上,這些資源不能直接應用于云存儲。包含以下三點原因。首先,目前的云存儲虛擬化方法不支持存儲采集,資源的動態重新分配是不可行的。第二,云存儲通常存儲敏感的應用數據,這就需要對存儲分配和取消分配進行仔細的管理。第三,由于塊擦除和元數據更新,云存儲可能會遭受巨大的收割開銷,這需要特定的優化來實現高效的存儲收割。
2. 現有的云平臺中存儲資源沒有被充分利用
這篇文章對從流行的云平臺中收集到的事件追蹤的研究顯示,存儲I/O在未分配(未出售)和分配的存儲方面仍然明顯利用不足。例如,這篇文章發現40%的云存儲服務器有25%的存儲沒有被分配,而分配的存儲的I/O利用率平均低于33%(見圖1)。云平臺中的存儲利用率低下是由于已分配的存儲資源利用率低下和大量未分配的資源造成的。這篇文章根據阿里巴巴和谷歌的開源云trace來進行存儲利用率研究。這些追蹤記錄跟蹤了虛擬機和物理服務器上分配的存儲資源的使用情況。阿里巴巴的云trace包含了4K服務器在8天內的虛擬機使用記錄,而谷歌的云trace是從12.5K服務器在29天內收集的。由于不同的云trace強調了云存儲使用的不同方面(例如,存儲容量、I/O帶寬、服務器利用率和虛擬機利用率)。
圖1 分配的云存儲的帶寬利用率
如圖1所示,所有虛擬機的分配存儲的帶寬利用率都低于33%,所有虛擬機在整個生命周期內的平均帶寬利用率為9.2%。對于通常承載多個虛擬機的物理服務器,我們得到一個類似的趨勢:物理存儲設備的帶寬利用率低于31%,平均帶寬利用率為8.6%。如圖2所示,20%的虛擬機幾乎沒有使用其分配的存儲容量,50%的虛擬機平均只使用了26.4%的分配存儲容量,而只有20%的虛擬機使用了高達90%的分配存儲。
圖2 分配的云存儲的容量利用率
【存儲資源可采集性探索】
可采集的存儲資源包含兩個來源:未分配的存儲和已分配的存儲。這篇文章分析了已分配和未分配的虛擬機中的可用存儲隨時間的變化,并檢查(1)是否可以從虛擬機中的存儲資源中采集一部分存儲資源;(2)采集的存儲資源可以持續多長時間;(3)可以采集多少存儲資源。
1.已分配的存儲資源:考慮到一個假設的采集型虛擬機從普通虛擬機中請求不同比例(10%、25%和50%)的存儲帶寬,調查有多少臺服務器有這樣的可用帶寬,以及這些資源可用于采集的時間。如圖3所示,超過91%的服務器在12小時內有可采集的帶寬,大約76%的服務器在3天內有可采集的帶寬。當我們在較短的時間內(即少于12小時)采集存儲時,可用服務器的部分始終很高。這是由于分配的虛擬機的存儲利用率一直很低,如圖1所示。
圖3 已分配的存儲資源可采集性
2. 未分配的存儲資源:給定一個假設的采集型虛擬機,要求不同的存儲容量(128GB、256GB和512GB),我們分析有多少臺服務器可以滿足這個采集虛擬機的請求,以及可用的存儲能持續多久。如圖4所示,32%的服務器可以滿足12小時的128GB存儲容量的要求。如果 harvest VM 請求的存儲時間較短,比如 1 小時,50% 的服務器可以滿足請求。隨著 harvest VM 增加要求的存儲容量,可采集的服務器的數量會減少。
圖4 未分配的存儲資源可采集性
【方法和設計】
1.設計目標
這篇文章提出了BlockFlex來支持高效的外存資源采集,設計目標如下:
- 存儲采集應該滿足采集虛擬機的存儲需求,同時盡量減少普通虛擬機的意外搶占。
- 存儲采集對上層虛擬機來說應該是透明的,以盡量減少對虛擬機和應用程序的改變,并促進其生產部署。
- 在提高全局存儲利用率的同時,存儲采集應該對普通虛擬機產生最小的負面影響,以保證云服務的質量。
- 當它從已分配和未分配的存儲中臨時分配未使用的數據塊給采集的虛擬機時,存儲采集應確保數據安全。
圖5展示了BlockFlex系統架構圖。為了管理采集的存儲,一個新的抽象名為ghost vSSD(gSSD)被提出,位于軟件定義的閃存之上。ghost vSSD可以連接到創建的vSSD上,因此,不需要對虛擬機進行修改。BlockFlex將在每個vSSD中部署一個預測器。對于采集的虛擬機,BlockFlex將預測其需要的存儲容量和帶寬,以及需求將持續多久。對于常規虛擬機,BlockFlex將預測它們的可用存儲容量和帶寬,以及它們的可用時間。對于未使用的存儲資源,BlockFlex將使用兩種基于啟發式的方法來預測可用于采集的持續時間。基于預測,BlockFlex將進行最適合的匹配,并將未使用的存儲分配給采集的虛擬機。如果資源搶占發生在采集的虛擬機上(由錯誤預測引起),BlockFlex將把采集的存儲釋放給普通的虛擬機,并處理不同場景下的異常情況。
圖5 BlockFlex的系統架構圖
2. 存儲采集的新抽象
BlockFlex提供了新的存儲資源抽象gSSD。BlockFlex允許常規vSSD主動創建gSSD,并將其添加到由vSSD管理器管理的gSSD池中,而不是在請求時采集存儲空間(見圖5)。當vSSD的預測器預測它將有可用的存儲資源用于采集時,它就會創建一個gSSD。這些預測是定期發生的(默認情況下是每三分鐘一次)。為了創建一個新的gSSD,BlockFlex將從vSSD中獲取空閑塊并為它們創建一個映射表。盡管一個gSSD的閃存塊可以從vSSD中獲取,但相應的gSSD和vSSD不會共享這些獲取的閃存塊(如圖6所示)。因此,不需要在運行時在gSSD和vSSD之間同步映射表項。
圖6 gSSD抽象
如圖7所示,為了便于快速查找gSSD,在vSSD管理器中把gSSD組織在一組列表中,并考慮在三個方面進行排序:存儲帶寬、容量和可用于采集的時間。根據觀察來優化列表:(1)存儲帶寬和容量與一個vSSD中可用的通道數量相關;(2)每個gSSD的可用采集時間需要定期更新;以及(3)不會在gSSD的生命周期內更新最大存儲容量和帶寬。因此,如圖7所示,BlockFlex維護一組按<容量、帶寬>排序的gSSD列表。在每個列表中,gSSD按其過期時間從最遠的一個到最近的一個進行排序。有一個定時器定期運行(默認情況下每15分鐘一次)來更新gSSD池中的過期時間。對于過期但尚未分配給任何采集的虛擬機的gSSD,BlockFlex將從列表中刪除它們。
圖7 gSSD管理方式
在收到存儲采集的請求后,BlockFlex將檢查gSSD池,以確定與請求的存儲容量、帶寬和可用于采集的時間最適合的匹配。BlockFlex使用最適合的匹配策略來盡量減少存儲資源的浪費。這些請求的參數來自于部署在相應采集虛擬機的vSSD中的預測器。由于gSSD池是排序的,我們使用二進制搜索,首先找到與請求的存儲容量和帶寬相匹配的相應列表。之后,我們走過這個列表,直到確定一個可用的gSSD,其過期時間與要求的可采集時間相匹配。
當采集的虛擬機完成其工作時,采集的gSSD將被回收到vSSD管理器的池中。在gSSD回收時,vSSD的地址映射表中的相應條目將被刪除。BlockFlex將檢查gSSD是否會很快過期(即默認情況下在30分鐘內)。如果是,BlockFlex將擦除閃存塊以保證數據安全,并刪除gSSD實例。否則,BlockFlex將把該gSSD添加到gSSD池中,以供將來使用。由于擦除操作很昂貴,BlockFlex利用SSD的通道并行性來并行執行。
3. 儲存采集的預測
對于未分配(未售出)的虛擬機,采用一種基于啟發式的方法,基于對云平臺中未分配存儲的特征的研究。云計算供應商通常會過度配置虛擬機,為他們的服務提供彈性。他們以不同的存儲容量保留不同的常規虛擬機。常見的尺寸包括128GB、256GB和512GB,以簡化VM的管理和部署。根據本文的研究,它們的可用性因其容量而異。我們使用相同存儲容量的未售出的虛擬機先前可用時間的直方圖,給每個未售出的虛擬機標記一個預測的雙倍時間。例如,對于存儲容量為512GB的未售出的虛擬機,我們可以將其中的20%作為gSSD,其可用時間為12小時,20%為6小時,其余為1小時。這種分布可以根據相應云平臺的啟發式研究而改變。這些gSSD大小的分布取決于為未售出的虛擬機配置的存儲容量。
作者預測分配的虛擬機的可采集存儲資源,以及采集的虛擬機的需求存儲資源。由于對分配的虛擬機和采集的虛擬機的預測都是由其工作負載決定的,它們使用相同的基于學習的方法,但學習參數不同。作者使用長短期記憶(LSTM)模型來開發我們的預測器,因為它們在時間序列預測方面的優勢和相對低的開銷。LSTM的輸入是收集自帶寬、IOPS(如maxiops、miniops)和存儲利用率的統計措施。默認情況下,BlockFlex每三分鐘使用之前15分鐘收集到的統計數據對模型進行訓練。這引入了最小的性能和內存開銷。帶寬預測器和容量預測器都使用相同的LSTM模型,但我們對其學習率和隱藏層大小進行了略微不同的調整,以提高準確性(如圖8所示)。這些預測器將分別產生預測的帶寬(以通道為單位)和預測的容量(以GB為單位)。
圖8 預測器的工作流程
【實驗結果】
實驗性能對比包含兩個方面,分別為存儲資源利用率和性能。存儲資源利用率包含容量、帶寬和未分配資源利用率。
容量利用率:圖9展示了對未充分利用的存儲容量的影響。作者將使用BlockFlex時的平均和最大利用率與沒有收割的虛擬機的基線利用率進行比較。我們看到所有虛擬機的平均利用率提高了1.25倍(43%對54%的利用率),而那些存儲利用率低于60%的虛擬機的平均利用率提高了1.75倍(20%對35%)。這顯示了BlockFlex可以獲得的好處,特別是在從存儲利用率低的虛擬機中采集閃存塊時。
圖9 存儲資源利用率實驗圖
帶寬利用率:圖10展示了從帶寬的角度來分析未被充分利用的存儲資源。結果顯示,所有的虛擬機都有1.34倍(22%對30%)的穩定改進。BlockFlex還將最大利用率提高了1.27倍(53% vs. 66%)。與利用不足的存儲一樣,通過不完全利用常規虛擬機的帶寬來避免重占。這表明BlockFlex可以從未被充分利用的資源中改善云存儲的帶寬和容量利用率。
圖10 帶寬利用率實驗圖
未分配資源利用率:圖10展示了通過采集未分配的虛擬機來提高利用率。BlockFlex將總體利用率提高了1.17倍(69%對81%)。利用率低于60%的服務器提高了1.42倍(45% vs. 64%)。對于利用不足和未分配的存儲資源,我們平均觀察到1.25倍的改善,這表明BlockFlex可以顯著利用利用不足和未出售的存儲資源來提高利用率。對于利用率極低的情況(低于60%),觀察到平均1.48倍的改善。這表明BlockFlex可以成功地將可采集的存儲資源與采集的虛擬機的需求相匹配。
圖11 未分配資源利用率實驗圖
性能:圖12展示了BlockFlex帶來的性能改善。通過采集額外的通道,采集的虛擬機的帶寬得到了明顯的改善。當將已售方案與靜態方案進行比較時,工作負載性能平均提高了16-51%。對于非賣出方案,由于缺乏對常規VM的干擾,存儲帶寬提高了22-60%。PageRank的改進效果最好,因為其工作負載在I/O上花費的時間比TeraSort或ML Prep工作負載多。未出售方案比已售方案平均提供了6%的額外帶寬改進。當我們將其轉化為端到端的執行時間時,我們看到使用已售存儲的平均性能提高了20%,而使用未售存儲的性能提高了25%。這表明在利用已售或未售存儲時,BlockFlex可以為IO密集型應用獲得顯著的性能優勢。額外的閃存通道可以使寫量大的工作負載受益,因為增加了I/O的并行性。對于ML Prep和PageRank工作負載,我們看到在采集5分鐘后,增加了10-21%。在整整60分鐘后,讀取帶寬的平均增長趨于穩定,并達到22-60%的整體改善。
圖12 性能實驗圖
【總結】
這篇文章引入了外存存儲資源采集BlockFlex,這是一種提升存儲資源利用率的方法,可以提升系統的性能。BlockFlex是基于對現有的云存儲場景下,對存儲資源利用率的觀察發現利用率偏低,從而設計新的存儲抽象,提升系統資源利用率。通過實驗,BlockFlex在各種云存儲負載下對外存的利用率上都有優勢。同時,BlockFlex討論了由于存儲采集導致的異常情況,并提出將異常錯誤暴露給用戶處理。最終,BlockFlex在存儲資源利用率和性能上有很大改進。
審核編輯:湯梓紅
-
存儲
+關注
關注
13文章
4499瀏覽量
87048 -
SSD
+關注
關注
21文章
2947瀏覽量
119077 -
固態硬盤
+關注
關注
12文章
1498瀏覽量
58237 -
存儲設備
+關注
關注
0文章
166瀏覽量
19133
原文標題:存儲資源采集,高效利用資源!
文章出處:【微信號:SSDFans,微信公眾號:SSDFans】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
如何解釋Xilinx ISE的資源利用率數據?
如何獲得每個塊的路由資源利用率?
提升現網網絡資源的利用率和網絡承載能力的方法
如何去實現一種CPU利用率及堆棧檢測統計
openEuler資源利用率提升之道02:典型應用下的效果
openEuler 資源利用率提升之道 03:rubik 混部引擎簡介
openEuler 資源利用率提升之道 04:CPU 搶占和 SMT 隔離控制
CPU利用率問題求解
活性物質利用率
關于Swarm和Mesos資源利用率優化實踐分析

評論