共用方式為

本文章是由機器翻譯。

整合 Windows Azure

企業用的 Windows Azure 平台

Hanu Kommalapati

運算已經已經證明值得注意的從已建立的企業和 start-ups 攤定域機組。大部分的企業會查看定域機組運算以上只是閒置的好奇心。以撰寫本文的 IT 市場研究建議大部分企業的 IT 管理員有足夠的資源可收養定域機組運算搭配上-場所 IT 功能。

當然有 skeptical 的定域機組的人運算 ’s 履行承諾之能力。此新興的解決方案是幾乎類似於 ARPANET (precursor 網際網路) 建立 ； 許多 skeptical 研究機構 didn’t 想要加入初始的網路的害怕失去其私用資料。一旦科學家所看到的資料網路及啟用它共同作業的優點，發生沒有停止它們，其餘部分是歷程記錄。今天 ’s 大型企業，像 ARPANET skeptics，正在中進行取得熟悉中如何發生而開發架構移位運算功能是取得和操作。

感應業界趨勢和客戶要求，Microsoft 所做的龐大的辦法在定域機組運算藉由釋放 Windows Azure 平台和建置和執行工業強度服務定域機組中必要的支援服務。本文章中我將討論 Windows Azure 平台架構層級和企業級方案的需求與交集。

雲端運算

我確定有數個定義的定域機組運算，不過一個我像最是：運算能力傳遞為透過網際網路標準和通訊協定公用程式。這個定義會開啟 「 公用定域機組 」 和 「 私用的定域機組 」 概念的可能性。公用定域機組如名稱所指出可供 wields 信用卡發卡的任何人。私用的定域機組意謂獨佔使用的一個商務或企業的協會如私人定域機組 ’s 任務完成陳述式來識別。

Windows Azure 平台亞馬遜 Web 服務、 Google 應用程式引擎和 Force.com 是公用的定域機組的一些範例。如果它會善用更廣泛的虛擬化 treats 計算儲存體和網路作為同質的資源集區，並且利用營運系統的高度自動化程序啟用的統一的資源模型，大型企業執行任何私用資料中心可以呼叫私用的定域機組。

公用程式運算已被電腦自動化空間，以讓的 visionaries 的夢想，只要我可以記住。Microsoft ’s 動態系統碼計劃 (DSI) 和類似的開發案所做的粗體其他廠商的嘗試，協助提供類似公用程式的特性的資料中心操作員：高度自動化、 self-managed、 self-optimizing 及 metered 儲存、 網路功能與計算週期。願景是 laudable 時, 它就會看到混合的成功。虛擬化問世進行運算環境在現實的公用程式。虛擬化幫助提高作業系統和應用程式從實體硬體。它將它們視為資料，所以點播資料流的作業系統和其他依存的資源，到目標硬體可以開發自動化程序。

若要設定 Windows Azure 平台討論的階段，我會簡短地查看產業術語運算空間與對應 Windows Azure 平台，這些條款，所以我們可以輕易地了解定域機組中。圖 1 顯示三明治圖表的產業術語和 Windows Azure 平台的對應。我將探討各種不同的定域機組的服務型別與下列章節中的詳細其相對差異。

圖 1Windows Azure 平台是提供一個 PaaS

軟體即服務

軟體作為服務 (SaaS) 是一個軟體傳遞的商務有模型提供者或協力廠商主控應用程式，讓訂閱為基礎的客戶可以使用。SaaS 客戶使用 pay-as-you-go 為基礎的提供者 ’s 基礎結構上執行的軟體。沒有 upfront 承諾，讓客戶現在任何長期的合約。

根據契約條款，客戶可能會選擇結束隨時使用該軟體。基礎結構和軟體組態是在使用者看不到，而且因此，客戶必須支付的現成的提供的功能。SaaS 使用以高度 multi-tenant 架構，並從另一個在執行階段和其餘的邏輯分隔使用者內容是。

這個 multi-tenancy 可能是不當的某些公司由於以其商業性質，所以提供者可能會提供實際隔離的基礎結構對於這類的客戶及收費的額外成本的軟體和硬體維護相關聯。Microsoft 商務產能線上套件 (BPOS) 和 CRM 線上是很好範例 SaaS。Microsoft 也提供額外的電量這些服務的專用裝載。

後，相同的問題解決了許多企業間的協同作業應用程式已在 SaaS 空間非常成功。因為硬體和軟體組態透明給一般使用者所以沒有最小，如果任何需要的 IT 專業人員參與]。可以透過組態的使用者自訂某些 SaaS 應用程式 ； 不過，大部分不允許自訂。如此一來也最小化 SaaS 應用程式的內容中，開發人員足跡。

SaaS 可以改善應用程式，時間市場層面，並在處理序中修正通常-complained-關於商務 IT 對齊問題。在企業，到企業設計師 「 陰影 IT 」 的夢魘中 SaaS 採用的初期階段期間 (小型團隊的試算表 savvy 程式設計師附加至業務單位，例如) 可能會混亂從全企業的開發案。這是因為 SaaS 授權略過 IT 採購程序的業務單位。企業架構團隊必須實現這教育業務單位有關控管的重要性。它們也應該設計新的控管程序或修改以適應 SaaS 現有的。

目前的 IT 環境可能排除小型和中型企業從擁有必要的功能，以最佳狀態執行其業務，因為的極大的 IT 投資的負擔。SaaS 可能提供給每個公司現在都只能由大型企業價格合理的 IT 功能相同的。由於 SaaS doesn’t 需要大量的 IT 投資，它可以撫平遊戲區放企業級的小型公司內他們學會的 IT 功能。

從服務提供者觀點任何小型公司可以成為 SaaS 提供者，並與大型軟體房屋競爭。這類公司現在可以專注於代替 outlaying 珍貴的首都，用於取得及管理硬體和軟體基礎結構及其核心網域強度。

為服務的平台

SaaS 似乎公司的是正確的事，做為所有的軟體需求。不過，每一公司是產生從舊版的技術，以及從其特定的業務領域其 IT 個性中唯一的。尋找一個 SaaS 每一行的商業需求的服務通常是不可能，所以公司需要繼續建置應用程式。平台服務 (PaaS) 為填滿那些人想要建置並執行自訂的應用程式作為服務的需求。這些可能是 ISV，加值服務提供者企業的 IT 商店和需要自訂應用程式的任何人。PaaS 提供有無限附近延展性所得它們所依賴的大型的資源集區的裝載應用程式伺服器。PaaS 也提供了必要的支援服務像儲存體、 安全性、 整合基礎結構和開發工具完成的平台。

服務提供者提供了預先設定、 虛擬化應用程式伺服器的環境的應用程式可以部署由開發人員。因為服務提供者管理硬體 (修補，升級等等)，以及應用程式伺服器執行時間最小化的 IT 專業人員參與。開發人員建置應用程式，並加上附註具有資源描述元的應用程式。在部署，時佈建引擎會繫結至應用程式描述元中宣告必要的基礎結構功能。資源可能包括網路端點、 負載平衡器、 CPU 核心、 記憶體和軟體的相依性。點播延展性與硬體和應用程式伺服器管理結合讓開發人員從基礎結構考量，並讓它們將注意力集中在建置應用程式。PaaS 是通常適合全新的應用程式，如舊版應用程式通常需要大量重整以遵守沙箱規則。

為服務的基礎結構

當作服務 (IaaS) 的基礎結構是類似傳統裝載，其中一個商務將會使用裝載的環境作為上場所 DataCenter 的邏輯延伸。伺服器 (實體及虛擬) 出租臨時性不斷，IT 專業人員管理基礎結構有完整控制權的軟體組態。有些提供者甚至可能會允許彈性使得服務相較於對等的 PaaS 提供更昂貴的硬體設定中。

軟體組合可能包括作業系統、 應用程式平台、 中介軟體、 資料庫伺服器、 企業服務 busses、 協力廠商元件和架構，並管理和監視軟體。自由選擇應用程式伺服器與來源選擇開發工具的彈性。這種彈性會增加為客戶 IT 專業人員需要維護伺服器，如同它們是上場所 IT 的環境的複雜度。維護活動可能包括修補和 OS 和應用程式伺服器的負載平衡，升級的資料庫伺服器、 備份和還原及減輕風險的硬體和軟體失敗的任何其他活動的容錯移轉叢集。

開發人員將會建置、 測試和部署應用程式與伺服器的硬體和軟體組態的完整感知。通常嚴重損壞修復和業務連續性是客戶的責任。IaaS 的一個重要優點，是它可以允許以定域機組的舊版應用程式移轉。由於 IaaS 的彈性允許任何組態建構，在定域機組的提供者之間應用程式的可攜性並不容易。舊版應用程式遷移是 sweet 特別針對 IaaS，因為它允許模擬定域機組中的公司基礎結構。IaaS 彈性也可以讓需要軟體組態的重大控制項的新應用程式。例如，某些應用程式可能需要安裝協力廠商程式庫和服務，而 IaaS 允許這類安裝沒有限制。

Windows Azure 平台有時同時 promising 彈性 IaaS， 中所示的 PaaS 的所有優點圖 1.Windows Azure 平台結合計算 (商品伺服器)、 網路及存放資源的大型集區到公用程式電算環境從中客戶可以繪製資源點播和支付只使用方式。定域機組的環境的典型 Windows Azure 平台可協助避免 upfront 首都 outlays 的客戶，並允許 IT 功能成長所需的基礎。

Windows Azure 平台

Windows Azure 平台提供裝載應用程式伺服器和必要的存放裝置、 網路功能與整合基礎結構，進行建置和執行的 Windows 應用程式。大的集區中建立公用程式的電腦環境的商品硬體的仰賴 Windows Azure 平台。圖 2 顯示 [Windows Azure 平台的資源有模型虛擬化儲存體網路的位置，然後計算資源所部署視佈建在部署時設定的原則。光纖控制站是整個生態系統大腦的 aren’t 應用程式資源集區的一部份的專屬資源的集合。因為 「 光纖控制器 can’t 曾失敗，提供高度多餘的硬體和軟體環境。

圖 2**(Windows Azure 安裝程式可能會不同) 的運算基礎結構的概念式檢視**

計算資源集區組成商品資源是由光纖控制站進行容錯。光纖控制器 architected 早期偵測的應用程式失敗並產生額外的執行個體，以符合契約的服務級協議。因為 Windows Azure 環境的應用程式裝載完整的平台它可確保透過提供透過點播佈建幾乎無限的資源的應用程式系統的品質。未使用的資源會傳回至集區藉此增加使用率。資源包含保存性的虛擬化儲存體和動態重新組態的私人和公用網路路由的虛擬化網路資源運算循環。這些資源的實體的組態是由設計看不到應用程式架構設計人員和開發人員。

所以，應用程式擁有者如何執行提供這些資源？拿起電話，以及呼叫為 IT 專業像我們一樣在傳統上場所的環境中已用完問題，如大規模的 Windows Azure 平台資料中心專業人員嚴重依賴自動化少數所管理。一般的資料中心的日常操作需要沒有人力介入。Windows Azure 平台可讓應用程式的擁有者可以佈建構成資源描述元的機器可讀取模型透過必要的資源。在 Windows Azure 平台在這些資源描述元稱為服務模型。這些服務模型指定應用程式資源和它們足夠供佈建完成的執行階段基礎結構，與沒有人為參與的相依性。因為此自動化的應用程式基礎結構的佈建的時間通常是少於五分鐘。當您比較 procure 和佈建方法的典型的上場所環境時，瞭解定域機組的乘冪運算。

計算

Windows Azure 平台計算一部分是負責提供執行應用程式的 CPU 循環。若要防止任何實體的相依性基礎作業系統和硬體虛擬化環境內裝載應用程式。透過包括本機檔案，持續性儲存體的虛擬化資源來完成的應用程式的鬆散連接 (結構化和非結構化) 和診斷和檢測的資源。裝載環境實作為虛擬機器，因此任何應用程式失敗 won’t 影響相同的實體硬體上執行的其他應用程式。

應用程式會部署到 Windows Azure 平台為的角色和相關聯的可執行程式碼和資源套件。Azure 角色以宣告方式描述裝載環境的特性。啟動部署的應用程式時 Azure 佈建環境剖析服務模型、 選取預先設定的虛擬機器 (VM) 影像，根據角色類型、 將應用程式位元複製到 VM、 靴機器並啟動必要的應用程式服務。所示的服務定義圖 3 代表用來作為在本文的參考是購物清單應用程式。

圖 3Web 和背景工作角色的服務模型

ShoppingListService 定義

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="ShoppingList">
<WebRole name="ShoppingList_WebRole">
<LocalResources>
<LocalStorage name="ShoppoingList_ImageCache" sizeInMB="100" 
cleanOnRoleRecycle="false"/>
</LocalResources>
<InputEndpoints>
<InputEndpoint name="HttpIn" protocol="http" port="80" />
<InputEndpoint name="HttpsIn" protocol="https" port="443" />
</InputEndpoints>
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" />
<Setting name="DataConnectionString" />
<Setting name="ShoppinglistOut"/>
</ConfigurationSettings>
</ WebRole>
< WorkerRole name="ShoppingList_WorkerRole">
<Instances count="2" />
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" />
<Setting name="DataConnectionString" />
<Setting name="ShoppinglistIn"/>
</ConfigurationSettings>
< WorkerRole />
</ServiceDefinition>

ShoppingListService 組態

<?xml version="1.0"?>
<ServiceConfiguration serviceName="ShoppingList">
</Role>
<Role name="ShoppingList_WebRole">
<Instances count="3" />
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" value=
              "UseDevelopmentStorage=true" />
<!-- flip the commenting of the following two lines for application 
storage needs on  local dev fabric -->
<!--<Setting name="DataConnectionString" value=
                  "UseDevelopmentStorage=true" />-->
<Setting name="DataConnectionString" 
value="DefaultEndpointsProtocol=http;
AccountName=<<account name>>;AccountKey=<<account key>>" />
<Setting name="ShoppinglistOut" value="shoppinglistq"/>
</ConfigurationSettings>
</Role>
<Role name="ShoppingList_WorkerRole">
<Instances count="2" />
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" value=
              "UseDevelopmentStorage=true" />
<!-- flip the commenting of the followign two lines for local dev fabric -->
<!--<Setting name="DataConnectionString" value=
                  "UseDevelopmentStorage=true" />-->
<Setting name="DataConnectionString" 
value="DefaultEndpointsProtocol=http;
AccountName=<<account name>>;AccountKey=<<account key>>" />
<Setting name="ShoppinglistIn" value="shoppinglistq"/>
</ConfigurationSettings>
</Role></ServiceConfiguration>

所述的購物清單應用程式圖 3 要求的網頁角色的三個執行個體和兩個背景工作角色執行個體。多個網頁角色執行個體之 Web 流量會自動載入平衡，與所有的三個執行個體將會提供使用 SSL，以及每個服務模型描述的 HTTP 端點。若要避免應用程式的總失敗，光纖控制站會散佈跨越許多失敗網域配置。失敗的網域組織是很多 所示的簡化檢視比複雜圖 2.為簡單起見 ’s 起見您可以考慮關聯的網路切換及電源供應器與每個伺服器架狀為一個失敗的網域。

Per 圖 2，光纖控制站一開始會從每個失敗 domain–racks # 1]、 [# 3] 和 [# n 配置一個 Web 的角色。我將探討從幾個假設性事件的觀點來看，整個 Windows Azure 運算層可靠性。在事件 # 1、 網頁角色 # 1 和背景工作角色 # 1 而停止機架 ’s 電源故障所回應。光纖控制站啟動網頁角色 # 1 和背景工作角色 # 1 的佈建程序中可用 racks–rack # 2 和機架 # 3。有時稍後事件 # 2 發生，期間 reallocated 的網頁角色 # 1 失敗健全狀況檢查，因為應用程式失敗。現在會開始光纖控制站，配置網頁角色 # 1 至一種其他可用機架。

這些事件期間，isn’t 影響應用程式的可用性。網頁要求繼續至少一個背景工作角色會繼續提取來自佇列的交易式項目，並寫入至 Windows Azure 存放裝置時，可藉由兩個以上的 Web 角色。光纖控制器致力於完成在任何指定時間的執行個體所能獲得的三個良好的 Web 角色執行個體和兩個背景工作角色執行個體 equilibrium。在現實情況下，機架可能配有備援電源供應和網路交換器，因此角色回收並重新配置可能經常因為而發生應用程式的問題或縮放比例向上符合延展性目標。

購物清單服務模型要求兩個背景工作角色，以避免單點失敗。即使在 Web 層和批次層分離透過 Windows Azure 佇列中，仍然 ’s 要求至少兩個背景工作角色來裝載 (Host) 時效性、 關鍵性的批次服務一個很好的作法。您可能只是離開與一個背景工作角色如果您得到裝載的服務 isn’t 時效性。

圖 1 表示 Windows Azure 平台讓 PaaS 優點可完成，但在同一時間都可以取得 IaaS 的彈性。這會在未來來到啟用由 Web 的角色、 背景工作角色、 CGI 角色和其他角色的代價顯示以原則為基礎的部署模型。支援角色的清單會繼續成長以滿足客戶的多樣化的應用程式和部署需求。

成本導向定域機組的架構

架構決策可以在小型和大型企業的作業經濟效益上有深遠的影響。即使定域機組運算關於 IT 靈活度，需要的企業營運費用考量因素列入考量時架構方案。定域機組應用程式的架構必須傳遞功能和系統品質 (延展性、 可用性、 可靠性和效能)，同時在同一時間最佳化營運費用。在上場所情況下應用程式架構設計人員很少請注意儲存、 網路頻寬或成本的計算循環的成本由於這些是在組織層級所產生的資本支出。

做為範例通常最佳化應用程式儲存區 isn’t 架構設計人員 ’s 任務頂端如儲存帶有成本 aren’t 營運支出的一部份。首要場所上的系統是傳遞重要系統的品質，配置的預算內。架構系統的最佳的營運費用會成為軟體開發程序在定域機組的環境中的重要項目運算。

我將探討 Windows Azure 平台的成本模型從購物清單應用程式的觀點來看 所示圖 4.此圖表會顯示 [購物清單的邏輯架構檢視，其箭頭指出資料移動。虛線箭號表示內部資料中心頻寬消耗而實線顯示在定域機組資料中心和出的資料移動。

圖 4Windows Azure 平台應用程式電量模型

Windows Azure 平台只會考慮資料傳輸忽略本機資料傳輸資料中心內的輸入與輸出費用。任何資料寫入 Windows Azure 佇列 won’t 造成任何頻寬或存放費用為存放消耗由佇列高度暫時性。不過，佇列將會造成每個交易費。窺視 (Peek)、 讀取或寫入佇列項目會被視為一個交易。

Windows Azure 平台伺服器使用量費用會根據角色數目以及部署的應用程式的時間量而定。這表示，，即使應用程式有沒有要求從一般使用者，Windows Azure 平台帳單系統會收取每執行個體-小時角色狀態 「 暫停 」 和 「 啟動 」。  因此它建議主動精簡的作用中應用程式需求為基礎的角色數目。在時間這是手動程序 ； 但是，您可能可以自動縮放利用診斷資料和服務管理 API 為基礎應用程式延展性模式應用程式]。使用 Windows Azure 表格、 佇列和 Blob 會造成儲存帶有成本，每個資料錄上每個 GB 的月支付。請 ，參閱圖 5 的價格，Windows Azure 公開已宣佈在撰寫本文時。

圖 5Windows Azure 價格

Windows Azure 功能 電量 備註
伺服器使用狀況

小型：$ 0.12 /service-hour

中:$0.24/service-hour

大型：$0.48/service-hour

XLarge：$0.96/service-hour

與使用中的應用程式角色會決定費用。

小型：(1.6 Ghz) 1.75 GB 記憶體 (中度 IO 容量)

中:(1.6 Ghz) 3.5 GB 記憶體

大型：(1.6 Ghz) 7.0GB 記憶體

XLarge：(1.6 Ghz) 14.0GB 記憶體
Windows Azure Blob 和資料表 $ 0.15/GB 每日平均測量每個計費週期期間。它需要更多 elaboration 上如何計算費用，看到詳細資料。
異動 $ 0.01/10 K 交易 建立讀取，更新] 和 [刪除成 Windows Azure 佇列、 Blob 和資料表會被視為一個交易。
SQL Azure：Web 版 $ 9.99/月份 (1 GB RDBMS) 銷售幾個幾百項目一個小型的電子商務網站的大型應用程式或產品型錄的中繼資料。
SQL Azure：企業版 $99.99/month (10GB RDBMS) 中型企業非常有用。或者藉由資料共用，它是可以建置的應用程式有大型的資料儲存需求。
AppFabric $ 0.15/100 K 訊息作業 郵件作業可能是服務匯流排訊息]、 [存取控制的語彙基元要求] 或 [服務管理 API 呼叫。
輸入 GB $ 0.10/GB ($ 0.30 在亞洲) 將付費只有資料在資料中心和出的轉移。
輸出 GB $0.15/GB ($0.45 在亞洲) 將付費只有資料在資料中心和出的轉移。

Windows Azure 平台價格很簡單與 Blob 和資料表所使用的儲存體的一個例外狀況。帳戶 ’s Windows Azure 存放裝置使用方式以計費週期每一天，並計算每日平均值。其電量會計算出此每日平均乘以 0.15 $ / GB。例如如果您儲存一天一個 20 GB、 新增工作日兩，10 GB 新增工作日三，5 GB 及刪除 5 GB 工作日與其餘的計費週期期間沒有活動的四如下所示，價格會被計算：

((20 +10 + 5 – 5)/30) * 0.15 = $0.15

這是假設 30 天計費週期。每日取樣的儲存體將請確定具有高度暫時性的存放裝置的應用程式需要將仍然支付其儲存體使用方式的不同於計費週期結尾處只會測量系統。

如稍早提到的架構是重要的因素中運作的應用程式的成本每月。對於執行個體應用程式會產生許多資料與最新的資料 — 說出最後的兩個星期 — 所需的應用程式的功能，架構可以被強制刪除不必要的資料或要定期將它傳輸上場所的系統。您可能會更好關閉由付 onetime 頻寬成本比造成永久儲存成本。相同可以是與參考資料已不再使用中的資料集的一部份，則為 True。這種方法可能適用於已經有投資在資料保存容量的公司。

應用程式案例

我將探討 Windows Azure 平台工業強度電子商務案例的內容中的各種層面：購物清單] 應用程式。我將著重於建立雜貨清單並儲存以供稍後使用時購物在儲存區中。網路使用者介面會來撰寫購物清單，並使用 Web 服務將它儲存到 Windows Azure 存放裝置。延展性，Web 層將購物清單寫入至 Windows Azure 佇列 ； 定期，批次程序會輪詢來自佇列清單，並將其儲存至 Windows Azure 表格。若要示範真實世界解決方案方面，我將使用 Windows Azure 基礎的驗證和以角色為基礎的安全性。

圖 6在 Windows Azure 平台上的購物清單應用程式

成本導向的架構先前所討論的內容中, 各種決策會影響每月的營運費用。以下是幾個方面的架構進行之前，先必須被視為系統：

  1. 參考資料的成長率
  2. 交易式資料的成長率
  3. 擷取行為的程式碼剖析資料的速率
  4. 商務事件資料的成長率
  5. 擷取系統事件資料的速率
  6. 與產品相關的媒體內容
  7. 使用佇列對。持續性儲存體與直接互動

我的購物清單案例 didn’t 包含媒體內容量，因此，wasn’t 成本] 方程式的大因素，但它可能是非常重要考慮傳送視訊、 圖形和音訊資料流的內容網站。圖 7 顯示一般的應用程式每月的操作成本在 Windows Azure 平台上。試算表 doesn’t 包括開發、 作業支援和一般使用者的支援人員成本。

圖 7Windows Azure 營運費用計算機電子商務應用程式

定域機組運算環境會減少作業支援人員的數目，因此應該供比較上場所和定域機組之間 ROI 時。而且，它 ’s 重要包括電源並 depreciated 每個應用程式的 ROI 方程式中的資本支出。目前在-場所成本的應用程式模型通常 don’t 包含這些費用，如 ’s 很難細分電源消耗每個應用程式為基礎。是一樣的冷卻和樓面的空間。ROI 計算器可以客觀成本 breakdowns 缺少中使用根據猜測。

所示的簡單的成本計算機圖 7 估計應用程式裝載於 Windows Azure 平台上營運的費用。此 Microsoft Excel 為基礎的工具允許典型電子商務應用程式的各種輸入的參數，並計算每月的操作成本，使用 Windows Azure 平台定價 所示的資料表圖 5.請記住工具中使用的預設參數均屬虛構 ； 您必須考慮您自己的系統之前先根據工具輸出的決策。成本計算機由每個月的人數驅動，並假設特定號碼的網頁檢視] 和 [交易式和建立事件資料。Windows Azure 平台小組建立更廣泛的工具，可會計算每月的應用程式的成本，並也會比較該 Windows Azure 場所上應用程式的 TCO。可在 存取 Windows Azure TCO 工具microsoft.com/windowsazure/tco.

所示圖 7，我們虛構的應用程式中如果我們來儲存這 Windows Azure 資料表內的成本大約 $ 1,350 每月一個給定月產生 9000GB 資料。請記住 圖 7 只顯示時間點儲存體，並隨著應用程式持續運作，便會累積事件資料的費用。這類成本可以最佳化所微調的擷取如 operationally matures 應用程式的事件資料量。成本計算機由每個月的人數驅動，並使用假設許多 10 Web 角色和 3 個背景工作角色。總計的每月帳單是 $ 3,571。

或者，應用程式可以被 architected 到通道事件資料由付 onetime 頻寬成本 ($ 0.10/GB 轉移出)，到已經 depreciated 上-場所儲存系統如果存在的話。類似的策略可以套用至交易式和行為程式碼剖析資料，以避免累積存放費用。

計算費用 aren’t 累積在本質和因此有應用程式的整體營運支出影響比較小。但是，沒有機會來調整作用中 Web 和根據觀察到的擴充性設定檔，要取得臨界洩壓作業費用，請在應用程式的批次角色執行個體的數目。計算和儲存費用之間計算 [使用量可以控制在任何指定的時間] 而儲存成本取決於 can’t 能復原輕易一旦建置應用程式的架構決策。所以我的建議是取得持續性架構右邊第一次。

除了應用程式的成本模型，大型企業將密切注意到現在，我將探討的應用程式安全性。

計算安全性

企業會得出了嚴謹有關定域機組中的應用程式和資料安全性。在資料中心安全性，時基礎結構和作業系統會搞定的 Microsoft，應用程式安全性仍是應用程式擁有者的責任。我會查看應用程式的安全性，從我的購物清單 Web 應用程式的觀點來看。設定一個 Windows Azure 平台應用程式的安全性就像其上場所對應項。Windows Azure 平台提供協助開發人員將安全性整合至應用程式的各種系統元件。這些系統元件允許基本、 獨立的驗證和授權聯盟的分析藍本適用於大型企業。

基本的識別

基本身分模型時建議名稱，實作獨立的識別架構，以符合其中一個應用程式的需求或 co-located 的群組共用相同的應用程式的使用者一組，並緊密聯繫到同一個身份識別系統實作層級。Windows Azure 平台範例包含一組 ASP.NET (成員資格、 角色、 設定檔及工作階段) 的提供者可用於實作基本識別解決方案。Windows Azure ASP.NET 提供者會在包含 Windows Azure 表格及 Blob Windows Azure 存放上實作。這些提供者實作 ASP.NET 提供者合約，並運用 StorageClient API 是 Windows Azure 平台 SDK 的一部分。提供者的圖解所示 圖 8.

圖 8 Windows Azure ASP.NET 提供者

應用程式使用 Windows Azure ASP.NET 提供者以便 Web.config 檔必須移除預設提供者，包括新的修改。所示的設定變更圖 9 相近，必須對自訂 ASP.NET 提供者在上場所的情況下進行的變更。

圖 9 Windows Azure ASP.NET 提供者的 Web.config 變更

<system.web>
  ... ... ... ...
<authentication mode="Forms" />
<!-- Membership Provider Configuration -->
<membership defaultProvider="TableStorageMembershipProvider"
userIsOnlineTimeWindow="20">
<providers>
<clear/>
<add name="TableStorageMembershipProvider"
type="Microsoft...AspProviders.TableStorageMembershipProvider"
description="Membership provider using Azure storage"
applicationName="ShoppingList"
... ... ... ... ...
minRequiredNonalphanumericCharacters="0"
requiresUniqueEmail="true"
passwordFormat="Hashed"/>
</providers>
</membership>
<sessionState mode="Custom"
customProvider="TableStorageSessionStateProvider">
<providers>
<clear />
<add name="TableStorageSessionStateProvider"
type="Microsoft...AspProviders.TableStorageSessionStateProvider"
applicationName="ShoppingList"/>
</providers>
</sessionState>
<roleManager enabled="true"
defaultProvider="TableStorageRoleProvider"
cacheRolesInCookie="true"
cookieName=".ASPXROLES"
cookieTimeout="30"
... ... ... ... ...
cookieProtection="All">
<providers>
<clear/>
<add name="TableStorageRoleProvider"
type="Microsoft....AspProviders.TableStorageRoleProvider"
description="Role provider using table storage"
applicationName="ShoppingList" />
</providers>
</roleManager>
... ... ... ...
</system.web>

一旦設定 ASP.NET 提供者，驗證、 授權及使用者設定檔可以實作同樣的傳統 ASP.NET 應用程式。請注意，在 組態圖 9 包含一個 Windows Azure 儲存為基礎的工作階段提供者，允許持久的媒體上的工作階段狀態的儲存體。由於 Windows Azure 負載平衡器 don’t 支援自黏工作階段，將工作階段資料儲存在 Windows Azure 儲存體上提供更佳的使用者體驗，透過工作階段為基礎的個人化。基本身分模型是適用於有使用者識別週期 (使用者帳戶的建立、 使用方法和結案) 開始和結束在同一個應用程式的應用程式。基本的身分實作可能會選出各種不同的包括以下的原因：

  • 應用程式想要保留完整的擁有權的使用者身分識別記錄
  • 缺乏的實作聯盟識別身分存放區和支援服務的基礎結構
  • 短的週期 (比方說行銷 contests 和促銷) 與需要使用者註冊的應用程式

Windows Azure ASP.NET 提供者也可以用來驗證使用者從 AJAX 以及 Silverlight 應用程式。AJAX 可呼叫 AuthenticationService、 ProfileService 和 RoleService 類別，位於 System.Web.Extensions.dll，之內可以發行成透過 Windows Azure 網頁角色的.svc 端點。請記住這些服務需要存取 HTTP 內容特定資料的 ASP.NET 相容性。發行項標題為 「 建置與 Silverlight 第 2 部份的商務的企業應用程式 」 (msdn.microsoft.com/magazine/dd434653)，提供詳細的資訊設定從 Silverlight 或 AJAX 呼叫上述服務。

聯盟的識別模型

聯盟識別身分，就必須包括供應鏈、 價值鏈、 共同作業和社交網路功能的應用程式，以及整合在網際網路上的受歡迎的身分識別存放區的應用程式。Windows Azure ASP.NET 堆疊可以結合與 Windows 識別基礎 (WIF) 來整合與一或多個安全性語彙基元服務提供者。與啟用的 WS-Trust 和 WS-聯盟的預先建立的信任關係，協同工作 WIF。圖 10 顯示的購物清單應用程式使用兩個權杖提供者的概念性檢視 — 一個場所上，而另履行夥伴。

圖 10 多個語彙基元的服務，請註冊與 Windows Azure 應用程式

信任說明安全性權杖服務 (STS) 端點和必要 X509 憑證的簽章語彙基元要求和回應。圖 11 顯示信任圖解，XML 表示，其中將包含在購物清單應用程式組態，一次的部署。在其各自的系統中取得驗證的使用者，並產生的安全性判斷提示已標記語言 (SAML) 語彙基元取得轉寄給提出要求的應用程式。

圖 11 聯盟的信任描述元

所示圖 10，當使用者存取 Windows Azure 平台裝載購物清單應用程式上的安全 Web 內容，WIF 會將此要求轉送至購物清單 STS URL 出現在信任設定。購物清單 STS 會收集認證、 驗證對 Active Directory 使用者、 建構 Active Directory 聯盟服務 ADFS (之前稱為 「 Geneva 伺服器 」) 的協助的 SAML 語彙基元，並將它轉送至購物清單的應用程式透過 Web 瀏覽器。WIF 購物清單站台內執行 Windows Azure 上會解壓縮 SAML 宣告，並執行授權檢查。

當牽涉到多個 STSes 網站就必須實作語彙基元轉譯邏輯將各種語彙基元 (Token) 轉換成標準格式。引入新的 STS 進入系統的影響減到最少，語彙基元轉譯邏輯可 externalized 或封裝成可修改而不影響消耗它們的應用程式的元件。圖 12 WIF 配合顯示語彙基元轉譯圖解，運作方式。

圖 12 具有多個權杖提供者的聯盟的身份識別系統

將由聯盟的識別模型啟用案例如下所示：

  • 儲存區的身分識別記錄上場所的法規遵循
  • 運用現有上-場所應用程式安全性基礎結構
  • 在價值鏈和供應鏈中的夥伴與整合
  • 單一登入上場所和 Windows Azure 平台應用程式之間

通常，大型企業有已經實作驗證服務及需要來運用保障應用程式的目錄伺服器。Windows Azure 平台可讓加速應用程式部署時同時利用現有的基礎結構安全性的定域機組的運用。而且，Windows Azure 平台的設計可以讓聯盟可讓各種整合案例跨商業夥伴和值鏈結的身分識別使用。

Windows Azure 儲存體

應用程式和部署在 Windows Azure 平台上的服務可能會使用 Windows Azure 存放裝置保存性的非結構化和半結構化的內容。Windows Azure 存放區共有三種基本功能所需的建置工業強度應用程式和服務：資料表、 Blob 和佇列。Windows Azure 存放裝置 」 是 massively 可擴充且非常可靠的持續性機制，也是可供應用程式存取裝載上場所透過像 REST 業界標準 Web 服務介面。在線上隱私權為 Windows Azure 存放裝置支援 SSL HTTPS 為主的存取 (除了標準的 HTTP 通訊協定。延展性和其他系統的品質會透過組成商品伺服器硬體和磁碟陣列，這由 Windows Azure 存放裝置軟體管理的大型存放伺服陣列來達成。存放區存取為負載平衡自動為了獲得延展性和可用性的節點集。每個節點會負責了有限數量的實體儲存體。存取節點 ’s 範圍外的儲存體是透過對等介面而達成的。可靠性是由預存實體 (例如 ShoppingList) 在多個節點上重複來達成。儲存軟體可的多個複本 (在撰寫本文時的三個) 資料的自動一旦是寫入)，就會發生。儲存體支援不可部分完成的交易式寫入並只有在所有複本會都寫入磁碟機之後，將會完成交易。圖 13 顯示的商品集合儲存節點形成 Windows Azure 存放服務。

圖 13 儲存體服務

正在使用時可能會失敗任何地方任何存放裝置磁碟機，紅 「 X 」 節點數字 4] 和 [11] 所示的可能性。將一旦儲存體服務識別失敗的磁碟機，它複寫資料從運作正常的磁碟機到新的節點。時間是永遠相容複本原則在任何給定的時間點儲存體服務。如稍早提到要求流量從應用程式將會載入平衡跨多個節點。

這種架構會幫助大規模如 Windows Azure 平台的公用定域機組 PaaS 產品所需的縮放比例。所示圖 13，讓我們假設節點 4、 11 和 14 擁有初始的三個複本的資料片段。失敗的節點 4 和 11，事件時，直接，服務此要求，以及快速地把資料保持在複本健全數 re-replicating 資料到至少兩個其他節點 (節點 2 到 8)，將會繼續節點 14。

儲存安全性

Windows Azure 存放依賴上雜湊式訊息驗證碼 (HMAC) 來驗證 REST Web 要求。與 Windows Azure 存放裝置專案相關聯的共用、 秘密金鑰會與 HTTP 要求的電腦取得為 「 授權 」 標頭內嵌至 Web 要求的 256 位元組雜湊相結合。相同的程序會重複檢查正確性要求的伺服器上。Windows Azure 表格、 佇列和 Blob 所有遵循相同驗證程序，雖然內容和目標 URL 是針對每個儲存體類型不同。下列是 URL 來存取專案下的上述三種儲存功能，請說出 「 hkshoppinglist 」：

  • http(s): / / hkshoppinglist.blob.core.windows。net /
  • http(s): / / hkshoppinglist.queue.core.windows。net /
  • http(s): / / hkshoppinglist.table.core.windows。net /

在程式碼範例圖 14 顯示的應用程式部署的儲存體準備一部份的多個 Windows Azure 資料表建立。

圖 14 顯示已驗證的 Windows Azure 資料表和資料建立的虛擬程式碼

[DataServiceKey("TableName")]
Public class StorageTable
{
  Private string _tableName;
  Public string TableName
{
  get { return this._tableName; }
  set { this._tableName = value; }
}
}

Public class Customer: TableServiceEntity
{
  Public string Name { get; set; }
  Public string CustomerID { get; set; }
  public Customer()
{
  PartitionKey = "enterprise";
  RowKey = string.Format("{0:10}_{1}", DateTime.MaxValue.Ticks –
  DateTime.Now.Ticks, Guid.NewGuid());
}
}
CloudStorageAccount _storageAccount = CloudStorageAccount.FromConfigurationSetting("DataConnectionString");

Public void CreateMultipleCustomers(List<Customer> customers)
{
  TableServiceContext tsc = new
  TableServiceContext(_storageAccount.TableEndpoint.AbsoluteUri, 
  _storageAccount.Credentials);
  foreach (Customer cust in customers)
{
  tsc.AddObject("customers", cust);
}
try
{
  DataServiceResponse resp =  tsc.SaveChanges(SaveChangesOptions.Batch);
  foreach (ChangeOperationResponse cor in resp)
{
  if (cor.Error != null)
{
//cor.Headers["Location"] can be parsed to find out the failed 
//requests which can be retried after correcting the error condition
}
}
}
catch (Exception ex){ //do something with the exception }
}

protectedvoid linkCreateTables_Click(object sender, EventArgs e)
{
  labelStatus.Text = string.Empty;
try
{
  CreateTable("customers");
  CreateTable("products");
}
catch (DataServiceRequestException ex)
{
  labelStatus.ForeColor = System.Drawing.Color.Red;
  labelStatus.Text = "Error: Table creation error : " + ex.Message;
}
}
//Use ADO.NET services directly to create an Windows Azure Table
Public void CreateTableUsingContext(AzureStorageTable storageTable)
{
  TableServiceContext tsc = new
  TableServiceContext(_storageAccount.TableEndpoint.AbsoluteUri, 
  _storageAccount.Credentials); tsc.AddObject("Tables", storageTable);
try
{
  DataServiceResponse resp = tsc.SaveChanges(SaveChangesOptions.None);
//handle errors
}
catch (Exception ex){//do something here}
}
//much simpler way of creating an Windows Azure Table
  publicvoid CreateTable(string tableName)
{
CloudTableClient ctc = _storageAccount.CreateCloudTableClient();
try
{
  ctc.CreateTable(tableName);
}
catch(Exception e) { //handle exception }
}

使用 Windows Azure 資料表做為範例，我會告訴交易式的母體擴展的資料準備 Windows Azure 存放裝置的一些簡單的方法。 程式碼範例顯示建立 「 客戶 」 和 「 產品 」 資料表使用 TableServiceContext 以及 CloudTableClient 說明 REST 為基礎的互動的彈性。 在實際上您可以也精心製作未經處理的內容、 將 HMAC 附加到 Web 要求並執行 HTTP POST 至資料表的 URL 但需要大量的程式碼，而且只應學術練習為完成。 建議的方法是使用 StorageClient 也就是 Windows Azure SDK 的一部分。

CreateTableUsingContext 函式會使用 AzureStorageTable 類別產生資料表建立裝載 ADO.NET 資料服務的協助。 TableServiceContext 自動產生 HMAC，並將貼附到使用 CloudStorageAccount.Credentials 屬性中所包含的金鑰要求。

函式 CreateMultipleCustomers 中所示，Windows Azure 表格儲存體可讓批次交易圖 14. 批次不應超過 100 中給定的變更集的作業，而且單一批次不應該超過 4 MB 的大小。 如需詳細資訊請參閱 Windows Azure 存放文件。 批次交易只允許個屬於相同的磁碟分割的實體。

HMAC 產生所需的認證是在個別的 Windows Azure 角色的服務設定中指定的。 下列是本機儲存體和定域機組連接字串的格式：

本機存放區：

<Setting name="DataConnectionString"
value="UseDevelopmentStorage=true"/>

定域機組儲存：

<Setting name="DataConnectionString"
value="DefaultEndpointsProtocol=
http;AccountName=
<your account>;AccountKey=<your account key"/>

以角色為基礎的安全性，在 [Windows Azure 存放裝置] 中 ； 沒有概念，因此的已驗證的要求會儲存專案的內容中有完整存取 「 儲存體。此例外狀況是可以是公用的 [BLOB (二進位大型物件)] 容器 (匿名) 或私用。授權是應用程式會消耗儲存服務的責任。

總結

本文中我只會粗略 Windows Azure 平台的表面。我確定會有足夠的涵蓋範圍在未來有關 Microsoft SQL Azure、 AppFabric、 各種伺服器角色和此處未含蓋其他安全性案例。Windows Azure 平台是 architected 若要啟用運算的開發和主控應用程式和服務的點播公用程式在定域機組運算平台。

大的集區的商品硬體會非常可靠軟體 (透過較高程度的自動化。大規模的縮放比例的經濟的優點會透過低訂閱費傳送給消費者。訂閱者將會收取根據用途的頻寬，透過每月帳單的儲存體和運算循環週期。Windows Azure 平台附有所需的建置企業級應用程式與服務的首都或長期合約的沒有 upfront 承諾的平台元件。

Hanu Kommalapati 在 Microsoft 的平台策略顧問，他建議這個角色中建置可延展的商務應用程式在 Silverlight 和 Windows Azure 平台上的企業客戶。

多虧來檢閱本文的下列的技術專家：Vittorio Bertocci, Brad Calder, Ryan Dunn 及 Tim O’Brien