Windows Azure Storage設計原理,微軟azure存儲架構

Windows Azure Storage設計原理,微軟azure存儲架構

Windows Azure Storage設計原理

Windows Azure Storage(WAS)是微軟提供的雲存儲服務。

WAS設計的主要目標

強一致性，號稱CAP都能滿足

提供全球統一的存儲服務

提供完善的異地容災支持

WAS的名字空間

WAS提供三種存儲抽象，分別是表格（Table）、消息隊列（Queue）、文件（Blob），WAS存儲的每個對象（表格裏的一行、隊列裏的一條消息、一個文件）都對應一個全局唯一的資源URI，其中AccountName爲用戶賬戶，service爲存儲服務類型（table、queue、blob中的一種）。

http(s)://https://AccountName.1.core.windows.net/PartitionName/ObjectName

對於Table，PartitionName爲表名，ObjectName爲表內行的primary key

對於Queue，PartitioinName爲隊列名字，ObjectName爲隊列裏消息的id

對於Blob，ObjectName爲文件名，PartitionName與ObjectName相同

WAS總體架構

WAS藉助DNS服務來實現全局存儲服務，Location Service負責管理用戶的賬戶信息，當用戶註冊了一個WAS賬戶後，Location Service會爲用戶分配一或多個stamp來提供存儲服務，同時更新DNS裏的記錄，將https://AccountName.1.core.windows.net解析到stamp對應的訪問入口。

WAS裏stamp類似於集羣的概念，請看下圖，MS在全球有多個機房，每個機房會部署多個WAS存儲集羣（stamp），stamp內部通過副本機制來保證數據安全性，stamp間會有數據備份機制，用於異地容災，比如stamp001在美國、歐洲、亞洲的機房各有一份數據，任意一個機房故障，都能從其他機房的對等stamp裏讀到用戶數據。

一個stamp典型的規模，1020個機架，每個機架18個存儲節點，約提供2PB的存儲空間；下一代WAS，每個stamp將提供30PB的存儲空間（猜想主要是單塊盤存儲空間增加）。

Stamp內部架構

單個stamp內部，主要分爲三個層次

Stream Layer：提供可靠的文件存儲（類比GFS)

Partion Layer:提供Table、Queue、Blob存儲的邏輯抽象，實際數據存儲依賴Stream Layer(類比bigtable）

Front End：存儲資源訪問代理，接受用戶的請求，通過Partition Layer獲取到數據，返回給用戶

Stream Layer設計

Stream Layer可以理解爲提供可靠存儲的分佈式文件系統，提供層次性的命名空間，如下圖，Stream Layer存儲的Foo文件。

Foo文件由多個extent組成（類似GFS裏的block的概念，但非定長，每個extent存儲時對應一個NTFS文件），extent由多個block組成。extent創建時，會對應多個副本，客戶端可以不斷以block爲單位（1或多個block）向extent追加數據，每個block會計算一份校驗信息用於檢查數據完整性，每次從extent讀取數據時，都需要讀取整個block的數據來校驗數據完整性；每個extent還對應一個index文件，用於映射[extent，offset]到block。（partition layer來說，它會維護每個對象存儲在stream layer的[文件，extent，offset]作爲對象的位置索引信息。）

Stream Layer主要包含Stream Manager(SM，相當於元數據服務器)和Extent Node（EN，相當於存儲節點）。

SM的主要職責：

維護名字空間以及所有文件及extent的狀態

管理所有EN的運行狀態

爲EN創建和分配extent

當有EN宕機時，複製缺少副本的extent

對只讀的extent進行earsure code編碼

extent一旦創建，便不可更改，只能追加數據，當extent到達一定長度時，客戶端（Partition Layer）可以將extent封裝(seal)起來，封裝後的extent不能再被更新，如果文件要繼續追加數據，客戶端可以向SM請求創建新的extent，然後往新的extent裏追加數據，在SM看來，文件就是由多個extent順序連接而成。

extent的多個副本中，有一個是master，其它的副本是slave，每次針對extent的追加操作，客戶端都會將請求發快遞至master，由master完成整個追加過程，master負責對所有的追加操作進行排序，然後決定追加操作在extent上的偏移（offset信息），同時請求多個slave在同樣的offset上往extent追加數據，當所有副本都追加成功時，才認爲追加操作成功。

如果在追加的過程種出現錯誤（只有部分副本追加成功），Stream Layer與客戶端（Partition Layer）的約定是，客戶端進行重試或是封裝當前extent（以多個副本中extent的commit length最小的爲準，commit length表示當前extent追加了多少數據），創建新的extent來追加數據。這個約定也意味着，同一個條記錄可能在extent上追加多次，這就要求上層業務能夠處理這種重複的記錄。

Stream Layer的一些優化：

對封裝後的extent（只讀）進行earsure code編碼，用於節省存儲空間。

接收到讀請求時，如果當前EN有很多請求在排隊，或是有請求排隊超過一定時間，則直接拒絕服務，讓客戶端重試其它副本

每個EN使用一塊單獨的盤（通常是ssd）做日誌盤（cache），當EN執行追加操作時，會將請求的數據先追加到日誌盤，同時寫到EN上的數據盤（不刷盤，等待OS後臺刷盤）。

Partition Layer設計

Partition Layer在Stream Layter的基礎上抽象出Table、Queue存儲邏輯，主要由Partition Manager（PM)和Partition Server（PS)組成，PM是管理節點，負責維護一個全局的試圖，而實際的讀寫操作都由PS完成。

爲了方便描述，這裏以存儲Table爲例說明。爲了向用戶提供表格的語義，在Partition layer會有一個有序的大表，存儲所有用戶的所有數據，每一行對應用戶存儲的一條表記錄，考慮這張表非常大，單個server不可能服務過來，這張表被劃分成很多個Range，然後均分到多個PS上，而PM維護一張Range==gt;PS的映射表，Front End接受到用戶請求時，會先從PM拿到映射表，然後將請求定向至負責對應range的PS上，Front End拿到映射表後會緩存在本地，並在映射表變化時更新。

每個PS會負責多個Range的數據，PS實際不存儲數據，數據存儲是由底層的Stream Layer完成，每個Range包含一個用於存儲操作日誌的Commit Log文件和一個存儲行數據的Row Data文件；同時Range被加載後，還會產生一些內存的數據結構。

Memory Table：內存表，記錄對於該range的每一次更新。

Index Cache：表索引的緩存，索引每行數據在Row Data文件裏的偏移位置。

Row Data Cache:行緩存，緩存行數據，與Index Cache分離的原因主要是儘量讓所有Index的數據都能加載到內存。

當有新的行要寫到某個Range時，首先會將行數據追加到Commit Log裏，然後將行數據寫到Memory Table，這時就可以向客戶端(Front End）返回寫成功。當Memory Table使用的內存超出閾值時，會做一次checkpoint操作，將Memory Table裏的數據寫至Row Data文件。

當Range裏的數據太多時，會導致負責該Range的PS負載很高，這時PM可以將一些大的Range進行分裂，就部分Range交由負載較低的PS負責（PS本身不持久化數據，PS只需要加載Range對應的元數據即可服務針對該Range的請求）；相反，當某些Range由於數據刪除導致數據很少時，PM可以將相鄰的Range進行合併；最終使得各個PS的負載儘量均衡。

特別聲明：以上文章內容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關於作品內容、版權或其它問題請於作品發表後的30日內與ESG跨境電商聯繫。