[翻譯圖書] Moving Applications to the Cloud on the Microsoft Windows Azure Platform – 3

Windows Azure中的儲存

===========================

Windows Azure為結構化的資料和非結構化的資料都提供了可擴充的儲存服務. 基於以下的原因, 這裡的儲存服務被認為是可擴充的.
•  應用程式可以擴充它的儲存到上百TB的資料.
•  儲存服務可以擴充資料訪問以便獲得在訪問上的更佳的效能, 擴充的方式取決於使用資料的模式.

 

即使經常被結合起來使用, 實際上儲存服務是獨立於任何hosted services的. 訪問Windows Azure的儲存是通過基於REST的API完成的. 這意味著許多支援HTTP棧的用戶端都可以訪問儲存服務. 在實踐中, 將你的資料與Windows Azure中的儲存服務結合起來, 能夠達到最佳的效能. 與hosted service一樣, 儲存服務也是可以容錯的, 並且同樣具有高可靠性. 在Windows Azure中儲存的每一個bit的資料都即在資料中心中複製過, 也在不同地理位置的資料中心之間複製過. 資料損毀是被持續地監視著的, 同樣的是對你的資料的保護和複製(目前, 任意你的資料都有三分拷貝.)

 

所有的資料都是通過遵循REST慣例的http請求來訪問的. .NET framework包括了很多可以與不同抽象層次的基於REST的service進行互動的library, 舉個抽象層次的例子, WCF資料服務, 或是通過WebRequest類進行的直接的HTTP請求.

 

Windows Azure的SDK還包括專門定製的用戶端library, 可以提供對所有Windows Azure服務的領域模型(domain models ). 基於REST的服務也被應用在許多其他的平台上, 比如說JAVA, PHP, 和Ruby. 幾乎所有的programming stack都可以搞定與Windows Azure儲存服務相互動的HTTP請求. 

Windows Azure儲存有四種類型: blobs, drives, tables, 和queues.

要訪問Windows Azure的儲存, 你必須有個在Windows Azure門戶網站http://windows.azure.com介面建立的storage account.

 

Storage Account是與某個具體的地理位置相關聯的. 目前, 每一個storage account可以儲存高達100TB的資料, 這100T的資料可以由任意的blob, table, queue和drive組成. 如果你願意, 你可以擁有任意多的storage account, 然而, 預設情況下你可以建立最多5個storage account(譯者注: 表面上看這句話說的自相矛盾, 是不是說要超過這個限度就要多交錢呢?)

預設地, 所有對Windows Azure儲存的訪問都必須經過認證. 每個儲存賬戶都有兩個256bit的對稱金鑰.

 

Blobs

---------------------

通體上說, blob提供了對大塊資料的訪問, 大塊資料舉例, 圖片, 視頻, 文檔, 和代碼. subscription中的每個storage account都可以有任意數量的container, 其中每個container都可以擁有任意數量的blobs. 儲存的限制是在賬戶層級的, 而不是任何具體的container或blob資料. blobs是通過遵循如下格式的URL來引用的:

http(s)://<storage account name>.blob.core.windows.net/<container>/<blob name>

 

Windows Azure的blob儲存支援root container的概念. 這在當你需要只通過指定domain name就訪問blob資料的時候是很有用的. Windows Azure保留的blob名字"$rootdenotes "是個特例. 下面的URL指定了一個出現在賬戶為"myaccount"的, 名為“mypicture.jpg” 的blob資料.

http://myaccount.blob.core.windows.net/$root/mypicture.jpg

這與下面的URL是等價的.

http://myaccount.blob.core.windows.net/mypicture.jpg

你可以命名你的blog, 從而使得它們看起來像是屬於一個有層次的命名空間, 但事實上, 命名空間是扁平的. 比如說, 下面的是一個blob的引用, 這個引用看起來像是暗示了一個等級化了的結構.

http://myaccount.blob.core.windows.net/pictures/trips/seattle/spaceneedle.jpg 

你也許會誤認為由名為“pictures”, “trips”, 和“seattle”的檔案夾組成了一個等級結構, 但事實上, 所有的路徑的分段其實都是blob本身名字的一部分而已. 換句話說, container的名字是“pictures” , blob的名字是 “trips/seattle/spac-eneedle.jpg”.

 

Container和blob都可以按照name/value pair的格式儲存最大8Kb的中繼資料,. 除了建立, 更新, 刪除操作之外, 你還能夠執行針對blob的更多特別定製的操作, 比如說拷貝, snapshot, 或租賃.

Container表現得就如同是一種blob儲存的安全邊界一樣. 預設地, 所有對blob儲存的訪問都要求一個密鑰. 然而, 你可以針對某個container設定安全規則來修改這種行為, 從而允許匿名訪問. 這裡的安全訪問檢驗規則是container層級的, 只針對blob的訪問規則. container層級的訪問與虛擬遍曆和發現container內所有的blob. Blob-only訪問需要明確blob的Uniform Resource Identifier (URI). 如果訪問規則被移除了, 那麼預設的行為改為再次要求提供密鑰.

 

為了高效的分發blob內容, Windows Azure提供了content delivery network (CDN) (內容傳遞網路). CDN將經常被訪問的blog資料存放區到距離使用blob的應用程式近的地方. 比如, 如果一個視頻在亞洲使用者中特別受歡迎, 那麼CDN會移動這個blob資料到地理上距離使用者更近的伺服器上. CDN是一個顯式可選的blob特性. 使用這個特性會對你的帳單有影響, 即不是免費的. Figure 3 說明了blob是如何儲存的. 一個賬戶持有blob container. 可以有多個container跟一個賬戶關聯. container中持有blob資料.

 

Blob資料可以被分為兩種類型: block blobs (塊blob)和page blobs (頁blob).

Block Blobs

每一個block blog都可以儲存高達200GB的資料, 這麼大塊的資料被分為4MB大小的資料區塊. Block blob是為stream(流)資料負載而最佳化了的.  它們對大塊的資料的表現很好, 比如說流媒體視頻, 圖片, 文檔, 和代碼. block blob的操作適合用於安全地上傳大量資訊. 比如說, 你可以使用API來並行地上傳資料區塊. 並且, 如果有錯誤發生, 你還可以恢複具體的某個資料區塊的上傳, 而不是整個資料集的上傳都要恢複.

 

比如說, 如果你上傳了一個10G的檔案到blob儲存中, 你可以把它拆分成4MB大小的塊. 之後你就可以使用PubBlock函數來獨立地上傳每一塊(或者為了增大輸送量, 可以與其他塊平行上傳). 最後, 你可以通過PubBlockList函數書寫所有的這些塊成為一個可讀的blob中. Figure4描述了這個例子.

 

Page Blobs

Page Blob有預定義的尺寸上限, 最大1TB, 由一系列的頁面組成, 每個頁面大小是512位元組. Page blob的最佳用途是隨機訪問用於讀/寫的IO. 距離如PutPage方法的寫操作必須與一個頁保持對齊. 相反的, 讀操作, 比如GetPage方法, 能夠發生在某範圍內的任何地址上. Page Blob的收費是按照實際包含的資訊量而收取的, 而不是它為你保留的空間的大小. 如果你建立了1GB的包含兩個page的blob, Windows Azure會收取你1KB的資料的錢. Figure5描述了基本的page blob讀寫操作.

 

Windows Azure Drives

-------------------------------------

Windows Azure Drives (磁碟機)是按照NTFS格式化的單卷虛擬硬碟磁碟機. 一個單獨的role執行個體可以排他地以讀寫入模式映射一個磁碟機, 或者許多執行個體可以同時以唯讀方式映射到一個磁碟機. 這兩種選項是不能合并的, 即二選一. 典型地, 一個執行個體(instance)以讀寫入模式映射一個磁碟機, 然後定期為該drive抓取snapshot. 這個snapshot之後能夠被同時以唯讀方式被其他執行個體所映射. 由於Windows Azure的磁碟機的底層儲存是page blob, 磁碟機在被一個計算節點映射後, 所有由這個節點所寫的資訊都將被序列化到這個blob中. 獲得磁碟機的租賃(lease)後, 就可以寫資料到blob中了. Lease(租賃)是Windows Azure儲存的並發控制機制之一. 本質上說, 就是一個blob上的鎖(lock). Windows Azure的磁碟機對遺留下來的依賴於NTFS檔案系統和標準IO庫的老應用程式是很有用的. Page Blob上的所有操作都對Windows Azure Drive是可用的.

Figure 6 illustrates a Windows Azure drive.

Windows Azure Drive對於在一個role中啟動並執行代碼是可訪問的. 寫到Windows Azure磁碟機中的資料是儲存到一個page blob中的, 而這個page blob是Windows Azure Blob service定義的, 並且page blob是緩衝在本地檔案系統中的.

 

Windows Azure Tables

--------------------------------------------

Windows Azure table提供了可擴充的結構化儲存方式. Table與一個storage account關聯. Windows Azure Tables不像典型的關聯式資料庫中的表. 它們沒有實現relationship, 也沒有schema. 相反, 每個儲存在table中的entity都可以有一個不同的組成不同類型的屬性集, 比如說string orint. Table的更新和刪除使用了Optimistic concurrency , 而Optimistic concurrency 基於時間戳記的. Optimistic concurrency 假設並發違反(concurrency violations )的情形不頻繁, 並簡單地禁止任何引發concurrency violations 的更新或刪除動作. Figure7描述了table 儲存.

儲存在table中的所有實體(entity)都擁有三個屬性: 一個PartitionKey, 一個RowKey, 和一個系統控制的屬性-LastUpdate. 實體是由PartitionKey 和RowKey兩個屬性唯一標識的. LastUpdate屬性是用來最佳化並發訪問的.

Windows Azure監控PartitionKey 屬性, 並在活動足夠多的時候自動擴充table. 潛在地, 它能夠通過在table中分布entity從而擴充table到上千個儲存節點. PartitionKey 還確保了某些相關聯的實體們總是放在一起的. 這意味著, 為partition key選擇一個好的索引值是非常重要的. PartitionKey 和RowKey的組合唯一標識了任何table中給定的entity.

指定了PartitionKey 和RowKey屬性的對Windows Azure Table的一個查詢只會返回一條entity. 任何其他類型的查詢可能返回許多entity, 因為查詢的條件並不保證合格結果唯一. Windows Azure table儲存返回在page中的資料(目前每次查詢最多返回1000條entity記錄). 如果需要取回更多資料, 返回的結果集中會包含可以被用於取回下個page的資料的continuation token (繼續令牌).

Continuation tokens 直到沒有更多資料空間可用了才會被返回回來. Table目前並不支援任何的彙總函式(aggregation function), 比如說Sum, 或Count. 即使你可以數一下行數, 或對某些列求和, 多數的這些操作都是在用戶端搞定的, 並且需要掃描整個table的內容, 這種操作代價會比較大. 你應該考慮其他的方式, 比如預先計算好, 預先儲存你需要的資料. 或者提供某些逼近真實情況的估計值.

 

對單個table的, 單個partition中的資料, tranction是支援的. 比如說, 你在一個單獨原子操作中能建立, 刪除, 或更新entity. 這種原子操作也被稱作 batch operation(大量操作). Batch的有效載荷的上限是4MB. 與table互動有很多種API. 最高等級的API使用WCF資料服務. 在最低的層次, 你可以使用Windows Azure暴露出來的REST endpoint. 

 

Windows Azure Queues

-------------------------------------

與你可以用來儲存資料的blob和table不同, Queue是用來完成其他的意圖的. 主要的用途就是允許web role跟worker role通訊, 通知和約定工作這兩種用途比較典型.

Queue提供了序列化的非同步訊息, 其中每個message(訊息)最大可以有8KB長. 從queue中擷取訊息的應用程式應該被設計為等冪的(idempotent), 因為訊息能被不止一次地被處理. 等冪的意思是一個操作可以被執行多次而不會改變結果. 擷取訊息的應用程式還應該被設計為可以讀取毒訊息(poison messages). 一條毒訊息包含不正常的資料, 不正常的資料能夠引發queue processor丟出異常.  結果是該訊息不被處理, 保留在queue中, 並且下一次想要處理它的嘗試會再一次失敗. Figure 8描述了queue儲存. 圖中可見,storage account可以包含queue, 從而包含訊息.

SDK中包含了一個實現了更高層次的抽象的domain模型. 你還可以使用REST endpoint來與queue互動.

 

SQL Azure

--------------------------------

SQL Azure是一個雲端式的關聯式資料庫管理系統(RDBMS). 目前它特點集中需要執行transaction的特性上. 比如說, 他提供了index, view, trigger, 還有stored procedures. 訪問本地SQL Server的應用程式不需要什麼修改(如果有的話, 也是一點點)就能使用SQL Azure. 客戶還可以使用on-premise的軟體, 比如說SQL Server Reporting Services來與SQL Azure協同工作.

你能通過許多種方式串連到SQL Azure上, 比如ADO, .NET, PHP, 或ODBC. 這意味著你今天用於開發資料庫應用程式的方法跟SQL Azure的一樣. 本質地, 如果你有一個放在雲端的資料庫, 你只需要簡單地修改一下連接字串即可.

 

應用程式可以跟資料庫一起在雲端, 也可以在on-premise中, 串連到位於雲中的資料庫. 第一個選項被叫做code near, 第二種叫做code far. 不管應用程式在那裡, 它都是用名為Tabular Data Stream (TDS) 的在TCP/IP協議之上的協議來訪問資料. 這跟訪問本地SQL Server資料庫的協議是一樣的. SQL Azure包括一個安全特性, 該安全特效能夠限制特定IP範圍的機器來訪問資料庫. 這樣, 你就可以指定期望的訪問資料庫的機器的IP, 從而在網路層次拒絕掉其他的所有請求.

 

要訪問SQL Azure, 你必須在http://sql.azure.com建立一個賬戶. 每個賬戶可以有一個或多個邏輯伺服器, 這些伺服器被實現為一個地理位置的多台物理伺服器. 每個邏輯伺服器可以有一個或多個資料庫, 這些資料庫被實現為分區的資料(partitioned data ), 分布在多台物理機上.

首先, 你在SQL Azure伺服器管理介面建立一個資料庫, 這個管理介面在web portal可以找到. 你還可以使用例如SQL Server Management Studio 的工具來建立資料庫, 添加元素(user-defined objects, tables, views, 和indexes), 或者修改防火牆設定.

SQL Azure三種DB的尺寸選擇, 1 GB, 10 GB, 和50 GB. 你的站但是基於資料庫大小的, 而不是你實際儲存的資料量.

 

Management Services

------------------------------------

Windows Azure的主要目的是讓應用程式擁有者的生活變得簡單. 達到這個目標的方法之一是提供一層自動化的服務管理. 通過這種服務, 開發人員建立應用程式, 部署它到雲端. 開發人員還佈建服務配置和約束. 這些動作完成之後, Windows Azure負責運行服務和維護該服務的健康狀態. Windows Azure還提供了執行許多操作的能力, 比如說監控應用程式和管理storage account, 管理hosted service, service deployments和affinity group. 你既可以通過web portal來執行這些操作, 或者通過基於REST的API來編程來執行動作. API使用與web portal不同的認證方式. 所有的編程調用都是用x509用戶端認證來進行認證. 使用者可以上傳任何合法的x509認證到Windows Azure developer portal門戶網站, 之後使用它作為用戶端進行API調用時使用的認證認證.

 

注意: 這裡討論的Windows Azure management API指的是專門為Windows Azure組件(計算和儲存)而開放的API. 平台的其他API(比如SQL Azure和AppFabric)有他們自己的一套管理介面.