可軟體定義程式的儲存邏輯二——Energy適應性的分布式儲存系統

可軟體定義程式的儲存邏輯二——Energy適應性的分布式儲存系統

這個論文[3]提出了一個靈活的、可擴充的分布式儲存系統，給它取名字flexStore。這個分布式儲存系統可以非常好的適應資料中心中不停變化的能源，給去重的虛擬機器磁碟IO存取帶來很好的效能。研究人員研究並提出了一種智能的控制來對付資料中心供電的限制，因為有可能存放裝置陣列的節點密度增加了，也有可能綠色能源和傳統能源混合一起給資料中心供電。在這個儲存架構中最重要的一個組件就是處於架構當中的策略引擎（policy engine），他是一個軟體層，給應用程式提供自訂效能需求的介面，當然也提供能源相關的策略。然後策略引擎通過不斷調整儲存資源分派的方式，將這些策略在儲存系統中實施。

最後他們還做了一些實驗。實驗表明這個系統可以很好的適應工作負載（workload）和供電限制的變化，系統的目標是最小化這個變化對效能的影響。原型還顯示這個適應性的備份策略在供電充足的情況下，可以減少大概65%的IO延遲，而在供電不足的情況下可以減少大於40%的IO延遲。

note: 我在之前的那個可軟體定義程式的儲存邏輯的那個部落格中，是這麼描述那個論文的：“ 這篇論文和IOFlow相比較，更加註重軟體定義程式儲存的架構（是利用已有的架構來建立新的架構，然後使用已有的協議），而不是像IOFlow那樣注重通訊的協議。並且，這個架構還是軟體定義程式環境的架構，而不僅僅是儲存的架構，不過全文注重說了儲存（更有挑戰性）...”那個文章比較全面的定義了軟體定義程式儲存的架構，並且和SDE結合在一起;而這個論文專註於energy adaptive的replica系統。

green energy

首先介紹了一個叫做可擴充儲存架構（scale-out storage architecture）的技術，在這種架構中，效能和可靠性至關重要，所以往往需要在多個節點中複製某個資料區塊，但是多副本消耗了更多的資源，給資料中心帶來了增大的cost。除了複製策略，資料中心也可能用到網路RAID技術，但是這種技術在資源消耗方面更加昂貴，也會影響在高負載情形下的效能。

除了效能和可靠性，對於資料中心的儲存系統，能耗也是一個至關重要的因素。有一個調查顯示儲存能耗在整個資料中心的能耗中佔40%以上。所以現在大型研究都在尋求綠色能源來供給，而綠色能源的使用給資料中心的供電情況帶來了變化，考慮到綠色能源的特點，能源的充足和缺乏在不停的變化著，有時候能源可能會缺乏。比如google有一個green計劃，他的首頁是這麼說的：

“在 Google，我們一直致力於全部使用可再生能源來支援我們的企業運營。除了考慮可以帶來的環境效益外，我們也把可再生能源視為一種商業機遇，並持續投資以加速其發展。我們相信，通過使用可再生能源來支援網路運作，我們將為每個人創造更美好的未來。”

 

所以資料中心架構和服務需要適應這種綠色能源（green）的變化性和不確定性，當綠色能源供給不足的時候，且作為備份的常規能源電網也不可用時，即使如此，效能的下降也需要在讓人能夠接受的程度。而當綠色能源充足時，就完全不需要消耗常規能源（來自電網）。這種靈活的操作對於將綠色能源整合到資料中心是非常重要的。對於這種需求，這些研究者先前已經研究過EAC（ENERGY ADAPTIVE COMPUTING），在資料中心中提供智能控制，關閉過度供給的能源並且自動適應變化的可用的能源供給。軟體定義程式儲存SDS的出現為儲存提供了更好的管理介面，本文提出的flexStore就是一個軟體定義程式的能自適應和管理儲存資源的系統。

系統設計目標、架構和原型實現

在green energy的資料中心，為了容災，虛擬機器備份是很重要的，當使用的green energy的能源充足，備份數可以多一點，當能源不足時，我們也可以通過適當的減少虛擬機器的備份數量來適應能源的備份。那麼怎麼樣的調整，才能使在滿足能源的要求時，使得效能的減少最少來保證QoS呢？這也是這個flexStore架構的目標。為了達到這個目標，我們需要首先分析一下能源和效能的關係。

 

虛擬機器去重

為什麼虛擬機器需要去重？因為資料中心有很多的虛擬機器，但是往往虛擬機器走著相同的作業系統和配置，所以存放的時候可以去重，可以大量的減少磁碟空間。

去重一般來說怎麼做？

去重有哪些難度？

很多論文中都提到了，比如[1][2]。但不是寫作此文的目的。

 

虛擬機器副本模型

為了資料的安全和資料中心的容錯性，一般會給虛擬機器建立幾個副本，但是為了效能或者容錯性的不同，有幾個不同的模型，這裡給出了三種模型。

強一致性：寫操作，當全部副本都寫入後，再返回；

弱一致性：寫操作，當一個副本寫入後就返回，只有需要換副本的時候，再複製；

flexstore模型：寫操作，當一個副本寫入後就返回，每隔一定的時間同步複本。

 

A：效能和能源的關係

資料中心副本的使用是為了資料的容災，另一方面是為了虛擬機器Server Load Balancer的需要。在多虛擬機器的情況下，隨著資料副本的增加，IO延遲會減少（多虛擬機器分布式的訪問replica，replica越多，IO隊列越小，IO延遲越小），但是副本的增大使得能源消耗增加。所以在使用綠色能源的資料中心，能源的限制導致了資料副本數的減少，IO延遲增大。如果能源充足的話，資料可以有足夠的副本數，也就不會影響資料的延遲。

如所示。隨著VM副本數的增加，IO延遲變小，能量的消耗變大。

 

在使用虛擬化的大型資料中心中，一個很具體的應用就是：虛擬機器去重，然後多副本儲存在下層的儲存系統中。我們考慮虛擬機器環境的工作方式，設計了flexStore架構（要保證虛擬機器磁碟的效能，也要做到去重）。

 

B：flexStore的組件

flexStore的組件2。這個論文按照data plane和Control plane的方式來介紹flexStore的組件。Data plane是異構的儲存系統with 不同類型的存放裝置，而Control plane控制平面提供了可程式化的介面使得可以控制資料的放置和布局。

資料中心虛擬機器的環境和虛擬機器管理按照下面描述的Metadata 管理和Chunk storage 所述。

Metadata管理：中繼資料管理器組件放在FUSE檔案系統上面（這個檔案系統用來存放 VM 的disk chunks），這個檔案系統還需要執行去重的功能，也作為“適配器”層為虛擬機器提供“塊語義“。

Chunk storage: VM的disk劃分為chunk object存放在下層的存放裝置上面，傳統的儲存系統為了使用儲存通常使用LUN（Block Storage）或者NAS 卷（檔案儲存體）的統一介面，而flexStore通常使用replica的介面。這個儲存系統是一個分布式的Object Storage Service系統（SHA1 hash）。flexStore儲存系統給一個chunk提供幾個備份。虛擬機器在某個時候只分配給某個副本，並且讀寫那個副本。

 

那麼data plane做了什麼呢？虛擬機器的卷建立好了之後，虛擬機器就可以直接讀寫這個卷了。Host上面會有必要的裝置驅動或者hypervisor來和不同的儲存系統進行通訊。這個驅動的主要作用就是將VM的塊請求傳遞給下層的儲存系統。另外data plane中還包含計數器和monitor，來監控讀寫請求的數目，以及相關的延遲，然後把監控到的資料傳遞給Policy engine，PE(Policy engine)再根據系統的情況按照某些演算法自動執行相關的策略。也提供了介面使得可以控制平面可以控制資料的layout，比如在energy不充足的時候將資料整合到更少的磁碟上面去，這些介面對應著控制平面的（migratedata across storage devices/replicas等）。

 

原型實現Metadata manager

? Chunk 儲存：replica

? FUSE模組（VM的磁碟掛載在FUSE目錄中）

? Process：當VM執行任何vdisk的IO操作時，metadata manager會將這個IO請求轉化為固定大小的chunk（SHA1 Hash）；在記憶體中維持一個hashmap；metadata manager通過thrift client和儲存系統互動。

 

底層儲存系統（storage system）

? Thrift server和中繼資料管理的thrift client互動（key-valve：SHA1 雜湊值和儲存的chunk）

? 也和policy engine的client互動

通過getLogSize() API來得到new chunk 的amount，並且告知policy engine的client（Log用來儲存新的chunk，當同步的時候只有這些new chunk才同步）；而Policy engine client的相關策略比如data transfer傳遞給儲存系統。

 

Policy engine

? 分布式的：每個host上面的client+central coordinator

? Client：和meta data manager互動來收集資訊：比如VM disk file的訪問次數，磁碟節點的訪問次數，然後將這些local state告知central

? client+central coordinator：維持a global view of the system:儲存節點數，活躍的host數目和可用的power

? Central coordinator定期向client搜集資訊。然後將global資訊反饋給client，client再選擇the list loaded nodes來儲存data或者move data。

? Client 會在以下情況發起data transfer操作：

1）replica上面不同步的資料大小超過閾值

2）replica上的load超過了閾值

3）VM disk的IO延遲超過了閾值

4）the replica 要關閉了，或者一個新的replica要開啟了。

實際的資料轉移只發生在nodes之間。

 

 

C:適應的副本一致性（和energy相關）演算法

 

副本總是需要同步的，而在flexStore模型系統中，我們讓副本每隔一定的周期（假設這裡是當某個replica的log檔案（new chunks）大小達到了閾值，然後這個replica開始diverging，這個replica的其他副本開始和它同步）。當滿足這個副本的power和頻寬的條件下，怎樣分流才能夠使得分流最大，也就是說能同步的replica越多，會使得workload的QoS越大。這裡採用的適應性的副本一致性演算法也就是要解決這樣一個問題。

考慮一個有N個副本的資料中心，如所示，虛擬機器被分配給一個replica，而且這個replica負責虛擬機器的讀寫。當新的chunk加入這個replica，這個replica還要不停的分流，使得其他的副本保持一致性。

 

論文中對這個演算法描述的很清楚，大概如下：

這 是一個整數線性規劃問題，當N=2/3的時候，policy engine可以在很快的時間內求得最優解......

 

實驗和評價

 

實驗環境是Amazon的IaaS平台:

? 4 EC2 M1.xlarge instances that have 4vCPUs and 15 GB of RAM each as the storage nodes which ran the storage software

? 8 EC2 M1.large instances that have 2 vCPUs and 7.5 GB of RAM each were used as hosts on which the metadata manager component and the distributed policy engine module ran

? All EC2 instances ran Ubuntu Server 13.04 as the operating system.

? A maximum of 4 VMs on each of the hosts.

 

兩種workload：Fio和MSR Cambridge trace

Fio：壓力測試

MSR Cambridge trace：類比真實環境中的資料

去重率：25%-75%

? Fio： a standard benchmark to evaluate file system workloads

? MSR Cambridge trace： The traces were collected over a period of 7 days from 36 different volumes in a Microsoft datacenter。

? each VM replayed one out of the four traces. The use of real workload traces in the evaluations helps to demonstrate the behavior of flexStore in a real datacenter.

 

 

實驗1：系統 tradeoff

 

 

可以看出：副本越多，IO延遲越小。通過這個實驗可以發現：增加副本數可以減少多少IO延遲；從這個實驗可以讓我們知道怎麼配置系統：因為減少的能源讓系統的副本數變少, 我們需要動態精確的知道系統的效能變化，並作出相應的權衡。

 

實驗2:自適應的一致性

 

儲存系統某個服務於VM的replica的logfile的大小（閾值）可以是個變數，通過圖6我們知道：logfile大小為100M的時候，讀寫IO延遲最小，於是就選擇這個logfile的大小當做是閾值（因為這個值會使得workload的read IO延遲最小）。然後實驗測試了strong，weak和flexstore（用前面測試出來的這個logfile閾值）三種一致性模型的平均IO延遲。發現strong模型會使得寫延遲很大，根據前面的分析這是顯而易見的。而weak模型和flexStore的模型讀寫延遲差不多，當然改變那個logfile的大小可能會對實驗結果有一些影響。

 

實驗3：cache的影響在VM的host端增大記憶體的大小，也就是增大了cache buffer。這樣測試發現cache大的情況平均延遲比記憶體小的時候小一些。

VM的去重率和儲存節點的cache大小也是影響延遲的一個很重要的因素。如果記憶體一樣大，去重率為75%的比25%的延遲小，因為去重率高，肯定會有很多重複的資料在cache中，這樣就可以減少cache不命中了。然後儲存節點的RAM 記憶體越大，也表示這裡的buffer cache越大，在相同去重率的情況下也將會導致更小的延遲。

 

實驗4：energy adaptation實驗對比了weak和 flexStore兩種情況下對能源的適應，也就是當能源緊張的時候，副本數變少，這個時候IO延遲就會增大，但是weak模型會在一段時間內變得很大，然後再降下去（和 flexStore一瞬間後增長到的一樣），然後或者能源充足了，這個時候 flexstore的IO延遲也就是突然變小了（而weak的這個時間要長的多），因為weak模型的其他關閉的replica沒有總是在update，而 flexStore的replica即使斷電了，update也總是要進行的（利用grown能源），並且像SSD這樣的裝置也不怎麼耗電。

 

 

另外當我們在計算一致性模型的時候我們發現其實分配給IO和同步的資源是可以相互制約的，所以我們通過在能源改變的時候，調節IO頻寬，這也可以改變延遲。如果能夠最佳化頻寬，則能夠帶來更小的延遲。

。。。

為減少datacenter能耗的其它研究

寫卸載技術（write offloading technique）[4]是為了將處於spun down狀態的磁碟(為了減少資料中心的能源的消耗，將某些磁碟處於spun down狀態（我猜就是讓這些磁碟處於休息狀態吧）)的寫請求重新導向到別的存放裝置，之後等這個裝置再次工作了再將這個資料區塊寫回，總之是為了減少能源消耗的問題。

也有些人提出了MAID技術[5]，來代替原來的高效能RAID技術，同時又可以減少能耗。在一個系統中有一些作為cache的磁碟來儲存熱資料，而其他的非cache磁碟可以保持spun-down狀態。

還有的研究設計了分布式的檔案系統，最佳化資料在儲存節點中的布局，使得有些節點在沒有必要的時候可以關閉，以此來減少能耗[6]。以及一種去中心化的SAN去重技術[]。和前面這些提到的為了減少能耗的技術不同的是，flexStore能夠更加靈活動態去適應能源的變化。