匯出 (0) 列印
全部展開

實作 Azure 移轉計劃

更新日期: 2014年4月

Azure 是在 Microsoft 資料中心託管的網際網路規模運算和服務平台。透過 Azure,開發人員和管理員不需要實作基礎軟體和硬體基礎結構,因為所有基礎的作業系統、硬體、網路、儲存資源和平台更新都是由 Microsoft 自動負責處理。

我們強烈建議,在您移轉應用程式到雲端之後,請對您的應用程式執行功能和效能測試,就像是針對所有新部署的應用程式一樣執行。因為 Azure 與內部部署平台不同,當您實作移轉時,必須考慮下列重要議題:

請注意,此主題的焦點主要是 Azure 雲端服務。如需有關使用 Azure 虛擬機器的 SQL Server 進行移轉的初步指引,請參閱<使用 Windows Azure 虛擬機器移轉>。

作者: Kun Cheng, Steve Howard
參與者:Selcin Turkarslan

當您的應用程式移轉到雲端時,您必須知道如何測試及偵錯應用程式,確定它在雲端中如預期般運作。以下是您可以用來測試應用程式的方法清單:

  • Azure Tools for Microsoft Visual Studio:您可以建置應用程式,然後使用 Azure Tools 隨附的計算模擬器和儲存體模擬器,在本機執行和偵錯這個應用程式。這可讓您先在本機開發應用程式,再將該應用程式發行至 Azure。Azure Tools for Microsoft Visual Studio 擴充 Visual Studio 2010,讓您透過計算和儲存體模擬器 (提供大部分 Azure 功能) 來測試應用程式。我們建議您在早期功能測試階段中執行這類測試。如需詳細資訊,請參閱 Azure Tools for Microsoft Visual Studio

  • SQL Server Data Tools:SQL Server Data Tools (SSDT) 在 Visual Studio 2010 內提供整合式環境,可用來設計資料庫、建立或編輯資料庫物件和資料,或查詢所有支援的 SQL 平台,包含外部部署 Azure SQL Database 與內部部署 Microsoft SQL Server 2012。它可讓您使用本機預設資料庫或 Azure SQL Database,透過檢查應用程式的關聯式資料存取組件,來測試資料庫專案方案。如需詳細資訊,請參閱 SQL Server Data Tools注意:Azure Tools for Microsoft Visual Studio 和 SSDT 都可讓您執行應用程式 (具有離線和線上資料來源) 的基本功能和相容性測試。為了測試真正雲端應用程式的所有層面 (包括功能、效能和延展性),您必須在部署及執行應用程式的 Azure 中進行模擬測試。

  • 自動測試架構:許多現有的應用程式已經有自動測試架構,可用來確定應用程式的所有元件或功能如預期般運作。當應用程式在 Azure 上執行時,自動測試架構不一定會根據其設計方式運作。如果自動測試架構需要從內部部署執行,但是可以透過定義的端點連接到 Azure 的應用程式,它可能仍然有效。否則,我們建議您在 Azure 裝載自動測試架構與應用程式,以減輕潛在的連接中斷與延遲問題。

  • Visual Studio 負載測試:如果應用程式沒有現有的自動測試架構,建議您建立新的自動測試架構,並使用 Visual Studio 負載測試,進行多個並行使用者的模擬測試。

在測試、預備與生產階段之間,您應該嘗試盡量將實際移交時間降到最低。大型資料庫從內部部署複製到 Azure,可能需要幾個小時或幾天。此外,在完全移轉現有資料所需的時間內,一直要關閉應用程式是不太可能的。因此,您必須有計劃,將因為移交而產生的停機時間降至最低。請注意,移交表示執行最後 Azure 移轉的所需時間。移交之前,請查看您的資料表,並決定哪些資料表包含靜態資料,哪些資料表包含移交期間可能變更的資料。對於靜態資料,在移交期間不需要移動任何資料。不過,如果對於在移交期間特定資料表中的資料是否可能變更有任何疑慮,您的系統必須包含邏輯,來移轉移交之後的所有變更。我們也建議您考慮內部部署系統的所有資料是否需要先移轉至雲端,然後在 Azure 讓應用程式上線。如果應用程式可以先上線並允許資料之後趕上,可以排除任何停機時間。

不過,如果在 Azure 上線之前,Azure 的資料必須與內部部署的資料保持一致,請考慮將移交期間必須移轉的資料量降到最低,因為這有助於將實際移交所需的停機時間減至最少。在某些情況下,移交之前先移動部分資料,然後在實際移交之後移動其餘資料,可能是適當的。在這類情況下,您的移轉計劃應該明確識別必須先移轉的資料以及可在移交之後移轉的剩餘資料。這可讓您的應用程式以較少的停機時間,即可在 Azure 上線,因為在您移轉其餘的資料時應用程式可以處於生產狀態。您可以使用下列資料同步處理方法,在移交之前執行資料移轉:

SQL 資料同步 (預覽)服務會為 SQL 資料庫 (SQL Server 和 SQL 資料庫) 提供資料同步處理功能。此服務目前具有兩項主要功能:

  • 在內部部署 虛擬機器建立 資料庫與 SQL 資料庫 執行個體之間同步處理資料,讓內部部署和以雲端為基礎的應用程式能夠運用相同的資料。

  • 在兩個或多個 SQL 資料庫 執行個體之間同步處理資料。這些執行個體可以位於相同資料中心、不同資料中心或不同地區。

在下列情況下,SQL 資料同步 (預覽)是同步處理內部部署資料庫及 SQL 資料庫 執行個體的絕佳選項:

  • 您需要執行應用程式平行測試。

  • 您需要在所有內部部署資料作業最後移動到 之前,平行執行應用程式。

  • 當移轉到 時,您需要執行內部部署應用程式,同時最少停機時間是必要的。

  • 您需要在內部部署和 應用程式之間進行連續資料同步處理,做為混合式方案的一部分。

請注意,為了追蹤累加式資料變更,SQL 資料同步 (預覽)會在設定同步處理群組時,針對同步處理的每一個資料表,新增變更追蹤資料表。使用 SQL 資料同步 (預覽)時,您的空間規劃必須考慮到變更追蹤資料表。此外,同步處理設定之後,您不應該對同步處理之資料表的資料表結構或主索引鍵進行變更,除非您重新初始化同步處理群組。在需要中繼或進行中資料同步處理的情況下,SQL 資料同步 (預覽)不是最佳選項。

警告: SQL 資料同步 (預覽)目前僅供預覽,以收集產品使用意見作為未來版本的基礎,而不應使用於實際執行環境。

如需有關 SQL 資料同步 (預覽)的詳細資訊,請參閱<SQL 資料同步 (預覽)>。

您可以使用複寫、鏡像或記錄傳送,從內部部署 SQL Server 將資料移至其他內部部署 SQL Server 或移至 Azure 虛擬機器的 SQL Server 執行個體。不過,您無法使用它們對 Azure SQL Database 移入或移出資料。如需詳細資訊,請參閱複寫和記錄傳送資料庫鏡像和記錄傳送

為了讓移交時傳送資料所需的時間縮到最短,您應該在移交之前將盡可能多一點資料移至 Azure 平台。您可以建立自訂 ETL 作業,將已變更的資料從內部部署系統移至 Azure 環境。從內部部署 SQL Server 2008 或更新版本移轉時,我們建議您使用異動資料擷取或變更資料追蹤,確保所有已變更的資料 (而且不超過變更資料) 實際上會從內部部署資料庫移至 Azure SQL Database 執行個體。如需有關這兩項功能的詳細資訊,請參閱《SQL Server 線上叢書》中的追蹤資料變更。如果資料庫不使用異動資料擷取或變更資料追蹤,您需要為變更和已移轉的資料建立追蹤系統。在所有情況下,在實際移交時要移轉的資料最少,是讓實際移交所需的停機時間減至最少的關鍵。

使用 DAC,您可以從 SQL Server 執行個體匯出資料並放入 Azure Blob 儲存體中,接著匯入至 Azure SQL Database。您可以透過 DAC 設定資料表應該匯入或匯出的篩選。不過,您無法設定資料列層級篩選。因此,DAC 適用於完整資料表放入單一資料庫內,但不適用於向外擴充的資料庫。在需要進行中資料同步處理的情況下,DAC 不是移轉應用程式資料的最佳選項。如需詳細資訊,請參閱《SQL 線上叢書》中的匯出資料層應用程式

建立資料庫備份的目的是要讓您從管理錯誤、應用程式錯誤造成的資料遺失或資料中心的總遺失中還原。在 Azure SQL Database 中備份和還原資料的作業與內部部署 SQL Server 不同,而且必須使用一些可用的資源和工具。因此,為了可靠地使用備份和還原作業進行復原,您需要擬定 Azure SQL Database 備份和還原策略。有三大類問題是 Azure SQL Database 執行個體可能需要解決的:

  • 基礎結構或硬體故障:在資料中心中,可能會發生硬體故障。例如,執行 Azure SQL Database 執行個體的實體節點可能當機。

  • 應用程式或使用者產生的問題或失敗:使用者或應用程式可能會對資料進行不必要的變更。這種情況可能就需要還原作業。例如,使用者可能會修改屬於錯誤客戶的部分資料。

  • 資料中心設備遺失:目前的 Azure SQL Database 服務等級協定明確將 Microsoft 合理控制之外的因素列為例外狀況,例如災害。萬一發生災害,資料中心可能會損毀,以致資料庫無法從本機複本或站台上備份還原。

最後您需要決定就有關 Azure SQL Database 資料中心內儲存的資料,願意容忍哪個風險層級。如需有關可用備份和還原工具以及如何建立災害復原策略的詳細資訊,請參閱 MSDN Library 中的<Azure SQL Database 業務持續性>文件。

您可以遵循下列方法,實際移轉應用程式到 Azure:

  • 平行執行:使用這個方法時,應用程式可在內部部署和 Azure 上平行執行。這可讓您先在 Azure 中進行應用程式即時測試,然後應用程式才變成完全依賴雲端。您的測試應該包含 (但不限制於) 下列:功能測試、效能測試和延展性測試。在 Azure 上完成新系統的完整測試之後,請執行最後的資料移轉,並關閉內部部署系統。

  • 暫停及移交:當所有資料需要在 Azure 完全上線之前先同步處理時,這種方法適用。使用這種方式,必須先在 Azure 完成所有功能和效能測試。然後,使用上述其中一個資料同步處理方法,設定您的系統將資料複寫到 Azure 環境。我們建議您透過在最後移交之前針對最後一次同步處理或 ETL 作業所需的時間降到最低,將資料保持盡可能接近已同步處理。當移交到 Azure 時間到時,請關閉內部部署系統,執行最後一次資料同步處理,並在 Azure 上啟動應用程式。

另請參閱

顯示:
© 2014 Microsoft