本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
使用 AWS Application Migration Service 進行遷移
AWS 使用 的大多數大型lift-and-shift遷移AWS Application Migration Service
此區塊層級複寫方法不支援網路連接儲存 (NAS)、共用磁碟機，例如網路檔案系統 (NFS) 共用，或通用網際網路檔案系統 (CIFS)/伺服器訊息區塊 (SMB) 共用。它僅支援在遷移時直接連接到遷移系統的區塊層級儲存。（如需詳細資訊，請參閱 SAN/NAS 支援的 Application Migration Service 常見問答集。) 這限制了透過 Application Migration Service 複寫對大多數叢集系統的適用性，因為大多數叢集依賴於各種實作的共用儲存。如需詳細資訊，請參閱此頁面的優缺點章節。
區塊層級複寫方法需要您在作業系統 (OS) AWS 層級安裝複寫代理程式，且該代理程式僅支援以 Windows 或 Linux 作業系統為基礎的 x86 平台 （請參閱 Application Migration Service 支援的作業系統)。Non-x86 平台超出此遷移方法的範圍。其中包括 ARM、RISC/CISC 系統、PowerPC 變化、pSeries、iSeries、zSeries 等 IBM 系統及其個別作業系統，例如 AIX、HP-UX、Solaris、Linux for PowerPC、大型主機上的 zLinux，以及其他非 x86 架構。
AWS 複寫代理程式可在作業系統堆疊中虛擬檔案系統裝置驅動程式*的層級運作，擷取要寫入基礎區塊層級裝置 （包括磁碟機、硬碟和直接連接的 SAN 裝置） 的任何資料區塊，如以下問題下方的 Application Migration Service 常見問答集頁面所述：
* 請參閱 Wikipedia 中檔案系統
優點
對於任何規模的lift-and-shift遷移，Application Migration Service 有許多優點：
-
複寫很容易設定 （不需要陡峭的學習曲線）。
-
透過在來源機器上推出代理程式，可以快速擴展。
-
您可以使用雲端遷移工廠
自動執行大多數手動任務、管理多台機器以及協調遷移波次。 -
它支援各種 x86 作業系統架構。
-
它支援任何類型的來源環境 （內部部署資料中心、任何其他雲端或其他） AWS 區域。
-
它與應用程式無關，因此支援在來源伺服器上執行的任何應用程式。
-
不需要任何授權或購買。 AWS 提供隨pay-as-you-go定價，因此您只需在不使用長期合約或複雜授權的情況下為服務付費。Application Migration Service 為每個伺服器提供 90 天的免費期間，這足以進行大多數遷移。如需詳細資訊，請參閱 AWS 網站上的 AWS Application Migration Service 定價
。
缺點
當您使用 Application Migration Service 等區塊層級複寫工具時，您可能會遇到下列極端情況和需要考慮的因素：
-
Application Migration Service 不支援掛載的共用檔案系統或共用儲存裝置，例如 NAS，包括 CIFS/SMB 和 NFS 檔案系統。如需有關 NAS 或共用檔案系統複寫方法的詳細資訊，請參閱 MGN 複寫代理程式以在大型遷移中遷移 NFS 共用
(AWS re：Post 文章） 和遷移共用檔案系統 (AWS 規範性指導模式）。 AWS -
Application Migration Service 不支援具有共用儲存體的大多數叢集檔案伺服器或資料庫叢集組態，因為該共用儲存體透過裝置驅動程式層呈現至作業系統層級的限制。例如，不支援具有 Storage Space Direct (S2D) 選項的 Microsoft SQL Server 叢集。不過， 您仍然可以使用 Application Migration Service 來複寫具有共用區塊儲存的其他類型叢集系統， 例如 Windows Server 容錯移轉叢集 (WSFC) 中容錯移轉叢集執行個體 (FCI) 組態中的共用儲存， 如部落格文章所述，AWS 使用 CloudEndure Migration 將 Microsoft Windows 叢集遷移至
， 從外部 SAN 陣列公開的儲存體 (iSCSI 連線）， 和某些 Microsoft SQL Server Always On 可用性群組 (AAG) 叢集。一般而言，Application Migration Service 支援從伺服器複寫區塊層級裝置，其中儲存裝置在遷移期間完全存在於伺服器上。( AWS 複寫代理程式必須安裝在伺服器上，且代理程式必須能看見裝置才能複寫。) 不過，所有這些案例都需要非常特定的程序，並導致更長的切換時段。 -
資料變更率較高的系統 (例如 OLTP 資料庫) 可能具有更高的效能或網路需求，這會讓遷移工作變得複雜。
-
網路頻寬必須足以滿足規劃遷移和切換時段內傳輸的資料量。這是因為 Application Migration Service 不提供離線運送選項，與 不同AWS Snowball
。 -
遷移需要在幾分鐘的 RTO 內有一小段停機時間。Application Migration Service 使用 EBS 快照做為遷移程序的一部分，而從這類快照建立的新 EBS 磁碟一開始的效能會較差。對於部分資料庫讀取模式，這可能會增加有效切換時段，直到遷移的資料庫達到最佳效能。
最適合的案例
Application Migration Service 幾乎可完全涵蓋任何lift-and-shift遷移，但缺點不大，如前兩個章節所述。此工具可以處理大多數極端情況 (例如資料庫叢集)，只要這些系統所需的較長切換時段符合您的遷移要求。
下列各部分更深入地介紹了兩種案例：
-
具有多個遷移波次的大規模遷移
-
需要最短停機時間的單一應用程式遷移
具有多個遷移波次的大規模遷移
大規模遷移的範例是資料中心退出，其特徵為大小和速度需求。它通常也涉及特定的時間限制，例如資料中心的租賃合約結束。在這種情況下，規模決定方法。遷移波次由應用程式 (包括資料庫) 確定和分組，每個波次都具有規劃的準備、遷移和最終切換階段以及特定的停機時間要求。
在每個遷移波動中，資料庫伺服器最好使用 Application Migration Service 區塊層級複寫大規模移動，但下列可能需要不同遷移方法的特殊情況除外：
-
大多數叢集資料庫系統
-
變更率超過可用網路輸送量的資料庫系統 (這可能會導致複寫延遲)
對於每種特殊情況，請考慮您的停機時間要求和使用其他遷移工具所涉及的工作量之間的權衡。在某些情況下，對所有系統使用相同的遷移方法會更容易，而不是使用單獨的工具和為特定系統建立不同的程序。如果 Application Migration Service 不支援特定系統的停機時間需求，建議您改用 Migration 與原生資料庫工具一節中所述的其中一種方法。
單一應用程式遷移
單一應用程式案例代表了一種用於遷移單一業務關鍵應用程式的精細方法，此應用程式在遷移期間需要最短或接近零的停機時間，或者是一些此類應用程式。相對於先前 （大規模遷移） 案例的速度和規模需求，遷移的範圍可能會有所不同，具體取決於業務關鍵性和停機時間需求。如果應用程式允許在 Application Migration Service 的 RTO 內停機，其處理方式應與先前所述的任何大規模遷移相同。
不過，在切換時間必須盡可能接近最小值的情況下，例如，當遷移的資料庫的讀取模式需要很長的時間才能完整運作，且切換時段必須保持很小，您應該考慮更詳細且精細的方法。一般來說，該方法涉及額外的步驟和要求，需要更多的精力和時間。其中一個步驟是將資料庫遷移與應用程式伺服器遷移分開，並使用下一節中描述的資料庫遷移工具來保持來源資料庫和目標資料庫同步。您可以使用各種方法來實現同步。每個方法都有優缺點，並涉及停機時間和同步複雜性之間的不同權衡。不過，保持來源環境與目標環境之間的資料庫同步可讓您取消資料庫層與應用程式層的連結。假設應用程式伺服器不會在本機存放持久性資料，而是將所有內容傳遞至資料庫層，同步也會移除應用程式層的停機時間限制。
解耦資料庫和應用程式層可讓您使用 Application Migration Service 遷移應用程式伺服器，如上一個案例所示。目標應用程式伺服器可以在目標環境中啟動，而來源系統仍在工作，處理資料並將其儲存在資料庫層中。由於資料庫層已與目標同步，因此切換時間很短，只涉及切換網路，並將客戶請求從舊來源系統重新導向至目標環境。您可以使用多種方法來執行此操作：遵循藍/綠部署的指引，通常透過切換 DNS 端點、使用加權 DNS 區域、使用 AWS Global Accelerator
