Windows Azure Storage(WAS)是微軟Azure雲計算的基礎存儲設施，為Azure上層產品提供包括Blob、Table、Queue在內的統一存儲服務，命名縮寫WAS倒是與AWS有幾分相似，乍看起來很容易混淆。

該專欄接下來的幾篇將根據WAS發表的論文對WAS做較為詳細的解讀，由於論文信息量比較大，我會將其拆解為四個部分分別介紹，包括：

  • 整體架構：主要介紹WAS的整體架構以及對各個模塊作簡要說明
  • 模塊解析：主要介紹以下幾個子模塊：

    • StreamLayer解析：介紹WAS的文件存儲層架構極其相關技術
    • PartitionLayer解析：介紹WAS的邏輯存儲層架構極其相關技術
    • FrontEnd解析：介紹WAS的前端接入層的設計

WAS作為Azure雲計算的底層存儲設施已經在2008年左右便開始在生產環境提供服務，迄今已10年有餘，其架構的合理性應該得到了較為充分的驗證，同時作為公有雲的核心設施，不太可能發生大的架構調整，因此，該論文雖然發表時間已經較長，但是仍值得仔細研讀(個人還是對Microsoft的工程能力挺嘆服的)。

好了，話不多說，我們直入主題，本文主要介紹WAS的整體架構。我們就不再介紹WAS到底是個什麼產品以及扮演什麼角色了，這些信息均可以在論文中找到相關介紹。

整體架構

首先，用戶很多時候不太會直接與WAS打交道，而是通過其包裝的其他雲產品來使用WAS(如ECS、對象存儲、表格存儲、消息隊列等)。通過URL來訪問WAS服務。URL形式為：

https://AccountName.service.core.windows.net

這裡面幾個關鍵的部分：

  • AccountName：使用公有雲服務的賬號名稱，這由客戶通過控制台創建，一旦創建，該賬號的存儲位置便確定好，因此，通過AccountName，Azure的DNS服務便可以將流量定位至特定的存儲區域
  • service：Azure服務名稱

我們從底之上梳理WAS架構：

  • Storage Stamp：我們可以稱之為存儲單元，一般是位於同一個數據中心內的一堆存儲節點構成的存儲集群
  • LocationService：顧名思義，WAS的位置服務，管理全局所有StorageStamp，統計StorageStamp的負載等信息，創建Account時根據負載決定將Account創建至哪個StorageStamp，LocationService也是多級集群以實現服務高可用
  • DNS：根據AccountName查找其所在的StorageStamp，LocationService決定了AccountName所屬的StorageStamp後會將該信息同步至DNS

接下來重點分析下StorageStamp架構。

Storage Stamp

存儲單元，一般是位於同一個數據中心內的一堆存儲節點構成的存儲集群。而Azure作為一個全球雲服務，形成了Region、DataCenter、Storage Stamp一個樹形結構的存儲拓撲結構：

按照論文描述，每個Storage Stamp由10~20個Rack(機架)構成，每個Rack內放置18個高密度存儲節點，總的存儲容量約為2PB左右，時至今日，恐怕早已突破10PB大關。因此，每個Storage Stamp內便是一個獨立自治的分散式存儲系統，通過StorageStamp的橫向擴展來實現系統容量的進一步提升。

作為一個功能完備的統一存儲單元，Storage Stamp又按照功能層次劃分為以下幾個組件：

  • Stream Layer：文件存儲層
  • PartitionLayer：負責為統一存儲提供更高層次的語義抽象
  • Fronts-End：前端接入層，無狀態，負責路由請求至特定節點
  • VIP：虛擬ip層，負責將請求負載均衡至各前端接入層節點

同樣，我們逐一簡單介紹這幾個組件，由於篇幅關係，本文不作深究。

Stream Layer

該層提供數據存取服務，之所以成為Stream Layer，是因為其不解釋數據語義，僅僅將上層數據當做位元組流，但需要提供數據存儲格式組織、數據可靠性。可用性等一些列分散式存儲系統該有的功能。

Partition Layer

WAS作為統一存儲平台，其提供各種存儲產品形態，有Blob存儲、表格存儲、消息隊列等，Partition Layer

便是設計作為統一的存儲抽象層，將所有的產品統一為通用存儲需求並與Stream Layer對接。

Frons-End

前端接入層，無狀態，負責路由請求至Partition Layer特定節點

VIP

虛擬ip層，負責將請求負載均衡至各前端接入層節點


推薦閱讀：
相关文章