匯出 (0) 列印
全部展開

計劃移轉至 Azure

更新日期: 2014年4月

當您開始規劃移轉時,必須考慮許多關鍵因素,例如成本、商務和技術需求、時間表,以及在移轉程序期間需要的任何測試。本節提供有關計劃移轉到 Azure 時,應該考慮的一些因素和步驟的逐步解說:

作者: Steve Howard
審稿者:James Podgorski、Paolo Salvatori、Selcin Turkarslan、Stuart Ozer

成本是最需要回應的大問題,建議您在考慮內部部署應用程式移轉到 Azure 時,於早期決策及計劃程序中處理。Azure 應用程式定價取決於許多因素,例如網路流量負載、應用程式的輸入和輸出特性,以及應用程式處理的資料量。計算價格不在本主題的範圍之內。我們建議您使用 Azure 定價計算機,當您開始規劃移轉時協助估計成本。您可以在這裡找到 Azure 定價計算機。

在計算組織的成本時,請記得包含開發和測試期間的直接 Azure 成本。在內部部署開發專案中,您支付開發和測試伺服器費用。同樣地,在 Azure 環境中,您需要支付在開發和測試期間所使用資源的費用。此外,您應該計算培訓和學習成本,以及與應用程式移植到 Azure 相關聯的成本。我們建議您進行效能測試或容量計劃,預先評估您的應用程式所需容量。

Azure 可以適當滿足某些商務與技術需求。雖然這份清單並不完整,但具有這些特性的應用程式是 Azure 移轉是絕佳候選:

  • 分散式使用群:Azure 資料中心位在多個大陸。資料中心之間的互連允許需要時高效能資料散發。內容散發網路 (CDN) 和資料同步處理服務等 Azure 功能,可讓您將相關或高用量資料分散到接近使用者的多個資料中心。讓使用者點擊接近其地理位置的資料中心,可將往返距離減至最小,因此最佳化使用者經驗。

  • 可變負載:您需要購買硬體供內部部署應用程式處理尖峰負載。例如,零售 Outlet 通常會購買伺服器,以處理假期購物季的負載。同樣地,會計部門可能規劃額外的基礎結構,以處理月底或年尾結帳週期的尖峰負載。其餘時間,規劃用來處理這類尖峰負載的伺服器則使用量過低。另一方面,彈性延展架構的應用程式可以使用 Azure,在旺季時使應用程式的新執行個體上線,並在較低需求的時段,返回較低層級的處理能力和容量。如此一來,Azure 可讓您透過適當架構和管理的應用程式,只根據需要付錢租用。

  • 多租用戶:對於服務提供者,Azure 允許以許多方式在相同的基礎結構上提供應用程式服務給任何數目的客戶,因此可讓您的營運成本降至最少。

  • 專注於應用程式的需要:服務提供者特別想要將資源集中在應用程式與功能的開發,而不是維護基礎結構。Azure 可讓您免於裝載內部部署應用程式的基礎結構或傳統式裝載伺服器應用程式所需的許多管理負擔。它可讓您將資源集中在應用程式與功能的開發。

  • 將基礎結構資源需求降至最低:當您設計應用程式架構使用 Azure 所提供的彈性延展時,也可以視需要配置角色和資源執行個體。沒有先行硬體投資,也不需要在低使用量期間維護能夠處理尖峰負載的伺服器。

除了傳統平台當做服務導向的優點之外,Azure 也可以裝載虛擬機器。虛擬機器可以執行 Azure 支援的任何作業系統,也可以透過與內部部署相同的方式執行應用程式。如需支援作業系統的清單,請參閱<Azure 虛擬機器概觀>。這些虛擬機器也可以是大型應用程式架構的一部分,其中包含 Web 或背景工作角色執行個體,以及其他 Azure 元件。對於不容易移植到 Azure 的某些服務或應用程式組件,虛擬機器是移植它們的方式。如需詳細資訊,請參閱<使用 Windows Azure 虛擬機器移轉>。

在分析和設計階段,您應該識別移動到 Azure 可發揮最大作用的應用程式。然後,開始設計 Azure 實作與實作計劃。在這個階段期間,您應該規劃架構設計和時間表的大綱。

以下是計劃的一些關鍵元素:

  • 識別目前挑戰:下列清單顯示在任何重新架構需要的計劃中應該識別的部分挑戰範例:

    • 在目前架構上的目前負載,執行效能未達標準的應用程式元件:例如,如果 SQL 查詢執行效能不盡理想,您應該在移轉或進一步設計之前加以微調。您也應該重新設計和向外延展任何應用程式層元件。

    • 判斷彈性延展需求:您必須識別應用程式如何能分解成可獨立執行、獨立擴充的功能單位。

    • 不均衡的負載模式:您應該識別不均衡的負載模式,並設計應用程式向外延展以處理尖峰期間。您應該針對如何管理尖峰期到低需求期間之向外延展層級建立計劃。

    • 成長預測:通常,成長預測就是先警示 IT 部門典範變更可能是必要的。決定在何處向外延展,做為處理成長預測的方案。成長預測可能也是需要考慮典範轉移的指標,例如在某些資料倉儲中心的應用程式中,切換到大量資料分析的典範。在計劃階段中,您應該討論這些選項。請記得,您可能無法確定知道方案,直到後面的設計和實作程序。您應該列出這類偶發事件和決定因素,以便在適當的時間進行評估,例如在初始移轉期間或日後。

  • 識別技術需求:了解每個應用程式元件在尖峰和離峰時間的需求。然後,為每個元件規劃延展。每一個元件可能會有不同的延展功能和機制。技術需求可能不只是效能。例如,高可用性和災害復原需求,或最大網路延遲的需求,在規劃移轉時應該與 Azure 功能進行判定與比較。下列清單顯示一些技術需求的範例:

    • 使用關聯式儲存體:檢查儲存在關聯式資料庫中的資料。本質上真正是交易式與關聯式的資料,或需要真正交易式處理的資料應該放在關聯式儲存體中。您可以使用 Azure SQL Database (SQL Database) 或在虛擬機器中執行的 SQL Server 中儲存這種類型的資料。您可以在 Azure 資料表、Azure Blob 儲存體或 Azure 磁碟機中有效率地儲存其他類型的資料。我們建議您識別資料每個部分所需的儲存類型。

    • 選擇關聯式資料儲存體:選擇 SQL Database 或在 Azure 虛擬機器中執行的 SQL Server 取決於數個因素。如果您想要避免高可用性、負載平衡和透明容錯移轉的管理負擔,SQL Database 是最佳選項。不過,對於移轉應用程式的中繼狀態,或是 SQL Database 尚未提供某些功能的特殊案例,在 Azure 虛擬機器中執行的 SQL Server 可能是最好的方案。這些問題的答案視不同狀況和方案而定。下列清單顯示對此的一些考量:

      • 資料庫大小:Azure SQL Database Web Edition 資料庫目前的限制為 5 GB 資料,Business Edition 資料庫則限制為 150 GB 資料。若要擴充資料庫容量,請使用向外延展方法。若要瞭解 Azure 向外延展方法,請閱讀<向外擴充 Windows Azure SQL Database>。如需有關可用資料庫版本和大小的最新資訊,請參閱<Azure SQL Database 帳戶和計費>。

      • 資料庫數目:根據預設,SQL Database 針對每個訂用帳戶最多支援 6 部伺服器,而且在每部 SQL Database 伺服器中支援 150 個資料庫,包括 master 資料庫。這項限制可以擴充。如需詳細資訊,請至 Microsoft Online Services 客戶入口網站連絡客戶支援代表。

      • 跨資料庫查詢:SQL Database 目前不支援跨資料庫聯結或其他跨資料庫查詢。如果您的聯集或聯結需要來自多個 SQL Database 資料庫的資料,必須在應用程式的應用程式層中執行這個邏輯。

      • Common Language Runtime (CLR) 物件:SQL Database 目前不支援 CLR 預存程序、彙總、觸發程序或函數。您應該移植 Transact-SQL 中的預存程序、觸發程序或函數,以執行於 SQL Database。Transact-SQL 中不能在資料庫層執行的複雜邏輯或運算 (例如彙總),應該要移到應用程式層。您可以使用背景工作角色執行這類工作。

      • 資料類型:SQL Database 不支援某些 SQL Server 系統資料類型。如需最新資訊,請參閱 SQL MSDN Library 中的<資料類型 (Azure SQL Database)>。

      • 複寫:複寫類型如異動複寫或合併式複寫,無法在 SQL Database 中使用。您可以在 Azure 虛擬機器中執行的 SQL Server 設定及執行它們。您可以使用 SQL 資料同步來同步處理 SQL 資料庫執行個體之間的資料。但在需要交易一致性或複雜衝突解決的情況下,SQL 資料同步服務可能不盡理想。警告:SQL 資料同步目前僅供預覽,只是為了收集未來版本的產品回函,不應該用於實際執行環境。

      • 全文檢索搜尋:Azure SQL Database 目前不支援全文檢索搜尋。如果您的應用程式對 SQL Server 資料表中的字元資料執行全文檢索查詢,您可能會想要考慮先將資料庫移轉至 Azure 虛擬機器的 SQL Server。如需有關 Azure VM 中之 SQL Server 的詳細資訊,請參閱<移轉至 Azure 虛擬機器中的 SQL Server>主題。

      • 授權:針對所選資料庫大小,SQL Database 每月收費。在 Azure 虛擬機器中執行時,SQL Server 需要授權。

      • 登入和安全性:Windows 驗證 (整合式安全性) 不受 SQL Database 支援,但適用於 Azure 虛擬機器中執行的 SQL Server。如需更多 SQL Database 安全性方針和限制,請參閱<Azure SQL Database 安全性方針和限制>。

      • 功能同位檢查:如需有關 SQL Server 與 SQL Database 相似度和差異的詳細資訊,請參閱<SQL Database Overview>。

  • 登入和使用者安全性:透過 Azure 新的網路增強功能,來自內部部署網路的 Active Directory 網域可以擴充到 Azure。如需詳細資訊,請參閱<使用 Windows Azure 虛擬機器移轉>。如需有關 SQL Database 安全性管理的詳細資訊,請參閱<管理 Azure SQL Database 中的資料庫和登入>。

  • 應用程式分解為功能單位:識別應用程式可能分解成功能單元的位置,以便在不同的 Azure 角色或虛擬機器上執行。您可以這樣做,以產生彈性延展,並在某些應用程式不適合雲端計算時允許混合應用程式。

  • 支付卡行業 (PCI) 和其他法規需求:在將應用程式或元件移至 Azure 之前,先檢查必要憑證或需求的目前狀態。在 PCI 符合需求的這類情況下,您可能會想要從已移轉到 Azure 的應用程式和資料庫中移除某些部分,並執行混合應用程式。這允許大部分元件利用 Azure 與雲端計算的優點,同時仍然允許必要資料和應用程式部分進行嚴格制度管控和符合規範。

  • 無法在 Azure 平台裝載的關鍵元件:由於其他問題,您可能無法在公用雲端裝載某些元件或某些資料類型。識別這些元件並考慮混合應用程式。透過混合架構,您可以在 Azure 中裝載部分元件,以實現 Azure 和雲端計算的完整優點。同時針對必要資料和應用程式部分,仍然可以達到嚴格制度管控和符合規範。

一旦您定義移轉的範圍,移轉計劃中各個步驟的工作量也會變得清楚。查看每一個應用程式與資料元件,並評估開發、測試和移轉所需的時間和資源。將應用程式分解成功能單位時,平行開發這些分解元件,以產生可彈性擴充的元件。

定義專案里程碑,例如功能和效能測試,以及移轉計劃中的發行日期。隨著不同的元件備妥可用於 Azure,或者元件備妥可移動到 Azure Web 角色和背景工作角色,您的移轉可透過一系列的步驟與反覆運算執行。

已設定開發和移轉的時間表後,規劃該期間內的成長,並決定必須如何處理現有的應用程式和基礎結構。這種類型的計劃可讓您操作現有系統,直到您的移轉完成。形成這個過渡期計劃時,識別目前痛苦點,並識別必須如何處理以允許持續的作業,以及在過渡期基礎結構上,作業可透過何種規模方式繼續進行。此外,識別持續的作業所需步驟。根據特定應用程式的特性,通常這些步驟可能像是調整 SQL 查詢一樣簡單或是新增 Web 伺服器。識別偶發事件計劃,因應成長速度比預期快或非預期激增的情況。建立偶發事件計劃時,請考慮是否可以透過向外延展到 Azure 虛擬機器來處理激增或成長,因為這樣您不需要其他硬體投資,即可處理這些情況。

任何移轉計劃都應該包含完整功能測試和負載測試的計劃。測試方法的描述超出本文範圍。下列清單顯示測試時要記得的一些重點:

  • 自動測試指令碼

  • 測試應用程式各層和元件

  • 對表示系統實際比例的活動比例進行測試

  • 測試直到最高預期使用量層級或以上

我們建議您包含建置與執行測試的時間,以及修正測試所發現之問題的時間。

當您定義商務與技術需求時,識別執行成功移轉所需的資源。您可能需要在移轉中納入這些。當識別資源時,檢視三個主要區域:

  • 人事:您可能需要納入具有其他技能集的其他員工,以成功移轉您的應用程式。此外,在移轉之後,技術人員角色可能會變更,而且技巧可能需要更新。例如,請考慮帳戶管理員和服務管理員角色,以管理登入、存取、以及服務和延展等級。

  • 工具:識別開發、測試及部署 Azure 應用程式時所需的工具。如需詳細資訊,請參閱<Azure Tools for Microsoft Visual Studio>和<Azure SQL Database 工具和公用程式支援>。

  • 諮詢:您可能需要應用程式移轉特定的專門技術。移轉專家可以協助您避免常見的陷阱,節省您寶貴時間和金錢。

對於小型應用程式,Azure 管理入口網站可能足以用於 Azure 部署的管理。Azure 管理入口網站可讓您登入及管理部署與應用程式,包括變更執行個體角色的數目,以及管理 SQL 資料庫執行個體。不過,對於複雜應用程式和提供客戶服務的應用程式,Azure 管理入口網站可能不夠。

Azure 公開 REST 應用程式開發介面,可讓您以程式設計方式管理 Azure 裝載的應用程式與 VM,以及佈建和使用 Azure 儲存體。您可以撰寫管理介面,以控制 Azure 環境的延展和監視。您的移轉計劃應該包含移轉之後的應用程式管理計劃,特別是在這個管理包含自訂介面或自動化時。

如需有關用來管理 Azure 部署之 REST API 的詳細資訊,請參閱<Azure 的應用程式開發介面參考>。

另請參閱

顯示:
© 2014 Microsoft