預測：多雲

Windows Azure 部署網域

約瑟夫 · 富爾茨

最近，我一直在認真考慮很多思想到應用程式的部署。原來的應用程式，獲取故障容忍和升級路徑的矩陣有點棘手 — — 更難的是當應用程式具有服務、 Web UI 和後端過程的混合。添加的地理分佈和物流成為更令模糊不清。

在大型 IT 組織、 任何 Web 或應用程式的最低部署伺服器往往涉及地理上分隔的兩個伺服器。這很容易移動四個伺服器如果兩個伺服器指定為期望的負載和你有相同的設置與鏡像網站 （當然，資料庫和其他支援的伺服器基礎結構可以推數仍較高)。如果公司服務多個位置，例如，北美和歐洲、 中東和非洲 (EMEA) 嗎？現在安裝程式獲取複製到大西洋兩岸的什麼車削成八個伺服器為土力工程處容錯移轉和轉移資產更接近消費者開始作為兩個 Web 伺服器。

最終，所有這些伺服器上部署的應用程式，一切都暢 — — 然後有些冒失的開發人員創建新的功能，想要更新部署。

你可以想像，需要規劃確定的順序，伺服器會排出連接、 獲取更新和測試，，然後放回池中的好一些。有些人花晚升級計畫，通過工作，這甚至是時有沒有真正的問題。

Windows Azure 消除不需要升級計畫，但它不會採取很多通過處理大部分是作為織物的一部分升級的複雜性。在本專欄中，我要去蓋故障的域和升級的域，並編寫代碼來部署跨應用升級的稍微有點。

故障和升級域

Windows Azure 包括故障的域和升級的域，這兩個幾乎完全由它們的名稱描述的概念。故障域定義的應用程式部署的物理單位和機架一級中通常分配的。通過將故障域放置在不同機架中，你單獨的應用程式部署到硬體不夠，不太可能都將會在同一時間失敗的實例。進一步，一個故障域中的失敗不應沉澱另一種的失敗。具有兩個配置實例的角色部署時，可確保織物，實例在兩個不同的故障域中成長。不幸的是，與故障域，您可以使用多少個域或如何將角色分配給它們沒有控制。

升級域是另一回事。您對這些域的控制，可以通過一次升級實例組跨部署執行增量或輪流升級。而故障域是有關物理部署的角色，則升級域涉及的邏輯部署。因為升級域是角色的邏輯分組，單個 Web 應用程式很容易存在五個不同的升級域分為只有兩個單獨的物理部署 （故障域） 中。在此情況下，要更新的 Web 應用程式，您可能更新組 0 （0 升級域） 中的所有角色，然後第一組中的所有角色，等等。您可以通過更新一次更新的每個域中的各個角色一行使有限的更多控制。

總之，將分成故障的至少兩個域的應用程式需要多個實例。要使跨整個農場更容易升級 Web 應用程式中，角色組合到邏輯分組在同一時間進行更新。

查看部署配置

Windows Azure 管理主控台顯示更新域的列，但不是故障域的列 （請參見圖 1)。（請注意，升級域和更新域是可互換的術語。文檔通常指的是升級域，但在 API 中，它被稱為更新域）。

圖 1 Windows 天藍色的管理主控台

在圖 1你可以看到我的四個部署中的數位由 0 至 3。預設情況下，Windows Azure 為每個服務使用五更新域，並為它們分配中迴圈的樣式。這是您可以通過向 ServiceDefinition 元素的 upgradeDomainCount 屬性分配所需的數量的升級域更改服務定義檔中。你會發現連結的 Web 和工人的角色，在架構的每個 msdn.microsoft.com/library/ee758711。要強制使用僅三個升級域的 WebRole，例如，您設置的 upgradeDomainCount 服務定義檔中：

<ServiceDefinition name="<service-name>" xmlns=”https://schemas.microsoft.com/ServiceHosting/2008/10/
      ServiceDefinition” upgradeDomainCount="3">
  <WebRole name="<web-role-name>" vmsize="[ExtraSmall|Small|Medium|Large|ExtraLarge]"
    enableNativeCodeExecution="[true|false]">
    ...
</WebRole>
</ServiceDefinition>

這很重要，因為您的計畫和執行，最終會影響更新域的數量。不幸的是，沒有讓你看到故障域分配的列。通過編寫少量代碼，但是，你可以回力有點上部署和見兩個更新域和故障域分配，作為幕圖 2 顯示。

圖 2 查找角色資訊

protected void GetRoleInfo()
{
  List<RoleInfo> RoleInfos = new List<RoleInfo>();

  foreach (var role in RoleEnvironment.Roles)
  {
    RoleInfo info = new RoleInfo();
    info.RoleName = role.Value.Name;

    foreach (RoleInstance roleInstance in role.Value.Instances)
    { 
      info.InstanceId = roleInstance.Id;
      info.FaultDomain = roleInstance.FaultDomain.ToString();
      info.UpgradeDomain = roleInstance.UpdateDomain.ToString();
           
    }
    RoleInfos.Add(info);
  }
  GridView1.DataSource = RoleInfos;
  GridView1.DataBind();

}

此代碼不顯示小的類定義存儲有關的資訊。不幸的是，雖然我有這種好的嵌套的迴圈所經歷的角色和實例，API 允許返回只運行代碼的特定實例相關的資料頁中運行的代碼。因此，則代碼將產生小網格的只是當前 WebRole 中的資訊 （見圖 3)，沒有任何其他實例的資訊。

圖 3 當前 WebRole 資訊

此代碼提供快速查看當前 WebRole 的故障和升級域，但您需要使用獲得部署其餘 URI 來獲得更全面的資料。它返回部署，除其他外，包含的元素的 XML，<Configuration/> 和每個 <RoleInstances/>。一旦你已經讀取配置，可以更改它，並把它放回去。看看我在 2010 年 10 月的專欄 (msdn.microsoft.com/magazine/gg232759） 的顯示的相同的操作將在這裡涉及很多的例子。

升級策略

有兩種基本策略更新 Windows Azure 部署：就地升級和虛擬 IP （或貴賓） 交換。VIP 換用更簡單的方法是，允許完全測試的新的或更新的應用程式之前的大門向公眾。此外，應用程式可以運行滿負荷一樣是活。如果有問題換用完成時，您可以快速到位以前的版本回雖然目前正在努力新的部署。

你會發現很好的參考，描述什麼可以和不能做在每個部署模型中 bit.ly/x7lRO4。下麵是可能會強制選擇的點：

• 就地更新或刪除和部署所需的更改的類型或終結點的數量時。
• VIP 交換或刪除和部署所需，當更改角色名稱或更新域的計數，或減少本地資源的大小。

除了這些點和一些 SDK 版本注意事項，它是你來決定。

換用過渡和生產環境的 VIP 是一個很好的解決方案，對許多人來說如果沒有最，案件時推出的新版本。有時，這是唯一的方法，以保持網站大多是可用狀態，同時進行更改，但如果您要升級大型部署，造就另一個全面部署可能會非常麻煩。也是與部署的完整副本相關的成本 — — 計算一小時收費的每個部署實例和正在運行的兩個副本，然後將其他計算時間。

在 Web 場如今，更新的一般推出通過一個農場通過以下兩種：一次以一台伺服器離線、 升級、 使伺服器連線和它回到農場的池 ； 或成段劃分農場和排水一段上的連接一次，然後升級每個段，使它連線和它回到農場，並最後移到下一段。

第二種模式像就地更新工程。然而，越升級域使用越多模式類似于第一個選項。使用更多的升級域的好處是，在整個升級過程中的網站容量減少僅由段的大小。

傳統的非雲部署面臨的主要挑戰是雲計算部署相同的：當您執行輪流升級，將運行混合的版本的應用程式。實例可能會提供不同的視覺效果，使用不同的資料和服務的連接，等等。這可能會導致網站錯誤或甚至是不合要求的使用者體驗，並可能為您的業務，在完全不能接受。此外，它對確保在劇中有多個版本時，將運行應用程式的開發和測試團隊將一個沉重的負擔。

如果您不能使用 VIP 交換和可用性要求排除刪除和部署，你該怎麼辦？您可以嘗試使用更新的只有兩個域和執行就地更新，這樣就可以使部署過程中運行的應用程式的單個版本。缺點：您的網站容量的一半在過渡期間將不可用。

在網格圖 4 可能會説明您考慮哪種方法雇用在執行升級。

圖 4 升級決策矩陣

就地升級

執行升級管理主控台內，並通過編寫腳本的能力方面取得了不錯的進步。部署相對較少數量的中型組織小，這是最簡單的方法管理通過 Windows Azure 管理主控台中顯示更新圖 5。

圖 5 Windows 天藍色的管理主控台

你可以看到在螢幕的左上角，手動升級正在運行。這就需要按一下開始按鈕，啟動升級的每個域的過程 — — 這就是它的手動部分。一旦開始更新，主控台顯示在每個域，在實例中怎麼示圖 6。

圖 6 更新活動

手冊 》，點擊式方法很適合較小型的部署。對於較大的部署或那些凡要自動化生成測試部署過程中，您應選擇編寫腳本的方法。您可以自動執行過程使用 CSManage 命令列工具，您可以從下載 bit.ly/A6uQRi。CSManage 將啟動升級，然後步行通過命令列從一次升級一個更新域的過程。雖然這是很有説明，是有一定可以只完成直接使用其他 API 的精細控制。

自訂您的升級戰略與故障域

如果因為某種原因你決定不更新域步行 0 – n，而是計畫使用您自己的起始點或命令，你要看一看的更新和故障域組合。在網格圖 7 使明顯如果你要更新升級的域 1，在更新期間出現故障的故障域 0，網站將會徹底癱瘓。不過，這通常應包括面料、 和網格顯示是否更新發生的順序，總有不同的故障運行的域。

圖 7 域矩陣

這裡的教訓是規劃，過程中考慮的潛在後果並不"修理"已經工作的東西。

接近尾聲了

當你設計一個 Windows Azure 的應用程式時，您需要考慮部署體系結構。Windows Azure 提供保證應用程式將不斷裂由於對單個硬體故障，同時提供了一種簡單、 自動增量更新部署方法織物的功能。儘管如此，支援就地更新是一定要在應用程式中設計 — — 和被推的更新。

您可以更新使用 VIP 交換或雙升級域、 就地計畫哪裡不能支援全地方更新 Windows Azure 服務。最後，有的使用者介面和程式設計方式控制的部署和更新，這樣，您可以執行計畫的更新或甚至使用生成測試部署的時間表或計畫的更新。

約瑟夫 · 富爾茨 是軟體架構師，在惠普公司，作為 HP.com 全球 IT 組的一部分工作。他以前是微軟使用其頂級企業和 ISV 客戶定義的體系結構和設計解決方案的軟體架構師。

多虧了以下的技術專家審查這篇文章： 唐格洛弗