Windows Azure Storage論文解讀

• • • 整體架構
    • 文件流層 stream layer
    • • 存儲引擎
      • • 存儲優化
    • 分區層 Partition Layer
    • • 存儲引擎
    • WAS總結

---

WAS是微軟開發的云存儲系統，提供Blob、Table、Queue三種類型的服務，它廣泛部署于微軟內部。其論文發表于2011年SOSP。

整體架構

WAS主要分為兩個部分：定位服務（Location Service LS）和存儲區（Storage Stamp）

• 定位服務管理用戶到存儲區之間的映射，負責負載均衡，并且服務跨地域、高可用
• 存儲區分為三層：
  • 文件流層（stream layer）：處理底層的文件存儲，分布式replication、管理extent等等，可以看做是存儲引擎。
  • 分區層（Partition Layer）：訪問文件流層獲取文件，對上層提供blob、table、queue服務。
  • 前端層（Front-End Layer）：由一些列無狀態的web服務器組成，接受請求完成驗證之后，轉發到partition layer。

因為WAS跨存儲區，所以其使用了兩種復制方式：

Intra-Stamp Replication：在一個stamp內，使用synchronous replication保證強一致。每個成功的寫操作必須保證所有的副本都同步成功。

Inter-Stamp Replication：垮stamp使用asynchronous replication，異步復制，實現異地容災。

文件流層 stream layer

文件流層提供類似文件系統的命名空間和API，所有的寫操作只能是追加。文件流層中的文件稱為流（streams）。每個流包含一系列的extent，每個extent由多個block組成。

block是獨具讀寫的最小單位。每個block最大不超過4M。stream layer會對block計算checksum。讀取操作總是給定某個block的邊界。每次讀取都會檢查checksum。系統后臺也會每隔一段時間校驗block的checksum。

extent是文件流層數據復制、負載均衡的基本單位，每個extent有三個副本。每個extent默認1GB，如果存儲大對象，就會用很多個extent。

stream layer有一個stream manager，負責監控extent存儲節點，管理文件到extent的映射關系，垃圾回收、負載均衡等等。通過paxos實現高可用。

存儲引擎

WAS中的流文件只允許追加，不允許更改。追加操作是原子的，數據追加到Block中，客戶端可以緩存多個請求之后一次提交給stream layer，客戶端需要保證冪等性重試。

對于追加產生的重復數據，WAS這樣處理：

對于元數據和log，通過他們的事務編號（transaction sequence）去重。

對于行數據流（row data streams）：只有最后一個追加成功的會被索引，之前重復的會被垃圾回收。

WAS的追加流程如下：

如果客戶端沒有緩存需要的extent信息，或者extent已經被sealed(縫合)了，客戶端向steam manager請求獲取extent

SM通過一定的策略，如負載均衡、副本分配等，分配一定數量的extent到存儲節點EN（extent node），其中一個extent是主副本（這種方式寫時才分配三副本，SM可以根據當前系統的狀態動態調整新的部分的位置，并且不需要像GFS那樣主chunk需要維持lease）

客戶端知道主副本之后，將請求發送到主副本，主副本執行以下操作：

決定追加的數據塊在extent中的位置

定序：如果有多個客戶端向同一個extent并發追加，主副本需要確定追加順序（元數據索引）（不知道這個確定順序會不會有瓶頸，畢竟1G也比較大了）

將數據塊寫入主副本

主副本將請求發送給備副本，備副本鏈式轉發給其他備副本，其他的備副本按照主副本確定的順序追加寫入。

備副本寫成功后回應主副本

如果所有的主副本都成功，主副本應答客戶端追加成功。

追加過程中如果某副本出現錯誤，客戶端追加請求會失敗，這時候客戶端會聯系SM，SM根據當前集群狀況，首先seal失敗的extent，然后創建新的extent用來提供追加請求。SM處理副本故障的平均時間在20ms左右，新的extent創建成功之后，追加操作可以繼續。WAS通過這種錯誤處理的方式，實現強一致。

每個extent副本都維護了已經提交的數據長度（commit length），如果出現異常，每個副本當前的長度可能不一致，SM縫合時首先選擇獲取所有副本的commit length，如果副本之間不一致，SM將選擇最小的長度作為縫合長度，如果某副本出現異常，等該節點重啟之后，其上的extent會從其他節點上同步數據。

文件流層保證以下兩點：

只要記錄被豬價并成功相應客戶端，從任何一個副本都能讀取到相同的數據。

即使追加過程中出現故障，一旦extent被縫合，從任何一個被縫合的副本中都能讀到相同的數據。

存儲優化

extent存儲面臨兩大問題：

如何保證磁盤調度公平

避免磁盤隨機寫操作

WAS的優化點如下：

如果SM發現某個存儲節點的IO被阻塞時間超過100ms，則將新的請求調度到其他存儲節點。

由于一個存儲節點（磁盤）有很多個extent，不同extent的并發追加會導致磁盤出現很多隨機寫，降低寫性能。因此存儲節點采用單獨的日志盤（journal drive），存儲節點收到的追加請求會順序的寫入日志盤，然后針對同一個extent文件的多個連續寫入合并成一個寫操作，再真正落盤

通過EC（Erasure coding），將extent中的數據條帶化落盤。這個和HDFS類似。

分區層 Partition Layer

分區層建立在文件流層之上，用于提供Table、Blob、Queue等數據服務。分區層的一個重要特性是提供強一致性并保證事務操作順序。

分區層內部支持一種成為對象表（Object Table，OT）的數據結構，用來存儲對象到extent的映射，OT被動態的劃分為多個連續的范圍（RangePartition，對應Bigtable的子表），并分散到不同的Partition Server上，范圍區間不想不重疊。另外，分區層中還有一張全局的Schema表（Schema Table），保證所有的對象表格的shema信息，即每個OT包含的每個列的名字、數據類型以及屬性。這些表是持久化到存儲區的。

通過這種方式，WAS支持了很多的數據類型，包括：bool、binary string、DataTime、duoble、GUID、int32、int64、DictionaryType、BlobType。

Partition Layer也存在Partition Server和Partition Master，Partition Master通過Lock Service選主。每個PS與Lock Service之間存在Lease，如果PS出現故障，PM需要首等待PS上的Lease過期，才能將他原來的服務分配出去。

存儲引擎

WAS分區層中的操作與Bigtable基本類似。用戶的寫操作首先追加到操作日志（commit log strema）中，接著修改內存表（memory table），等到內存表達到一定大小之后，執行快照（checkpoint），PS還會將多個小快照合并成一個大快照（對應Bigtable中的minor/major compaction），并且PS上會緩存數據，還會有布隆過濾器優化讀請求。也存在負載均衡和分區的分裂與合并。

與Bigtable不同點如下：

WAS中每個分區有都有對應的commit log文件，而bigtable中，每個Tablet Server上的所有子表共享一個操作日志文件。

WAS中每個分區維護各自的元數據，PM只負責管理每個分區之間的關系。而bigtable通過根表（root table）和元數據表（meta table），將所以的元數據統一在一起。

WAS中存儲類型較多，從數值到blob都支持。

WAS總結

WAS整體架構借鑒GFS+Bigtable，并有所創新：

WAS使用1G的extent從而減少元數據

WAS保證每個副本之間的強一致性

WAS將范圍分區的操作寫到不同的操作日志中。

總結

以上是生活随笔為你收集整理的Windows Azure Storage论文解读的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。