← 回到筆記2026-07-11

MGN 原理及使用方式 (workshop & why)

說明 AWS MGN 的初始設定、Agent 安裝、測試執行個體與 cutover 的流程和原理。

發佈 ~11 分鐘 #MGN

Overall Workflow

初始設定

MGN 基本配置：啟用及設置 replication template

名詞解釋

  1. Replication Template：決定資料如何被複製，之後每台新加入的 source server 都會自動套用這份設定。裡面包含的內容涵蓋 staging subnet、replication server 機型、data routing/throttling、EBS 加密、安全群組、標籤等。
    • Data Routing：預設走公網進行複製，但如果要使用 VPN/DX 等私有連線複製，則需選擇「Use private IP」選項切換
    • Throttling：避免複寫把你客戶端的頻寬吃滿，導致正常業務流量受影響
    1. 計算 TCP 埠 1500 所需的頻寬 → MGN 使用 TCP port 1500 進行複製
    2. AWS 複製代理程式消耗多少頻寬？
    3. 如何控制用於複製的頻寬？
  2. Staging subnet：是複寫機制實際運作的地方，AWS 會在這裡啟動輕量的 Replication Server（t3.small），接收來源伺服器抄過來的資料並寫進 EBS 磁碟區；測試、轉換啟動時，也會在這裡短暫啟動 Conversion Server 把資料轉成可開機的快照

  1. 在該地區初次使用時會需要建立對應的 IAM roles，點選 set up service 後會自動設置完 replication template

  2. 自動設置的 replication template

  3. Replication template 可設置的內容

  4. 需注意 quota 裡面最多可使用的 source server 數量預設為 150

VPC Endpoints

為確保 end to end 都走加密、私有通道，因此要在 staging subnet 裡面新增 MGN / S3 / EC2 等 VPC endpoints

  1. AWS MGN VPC interface endpoint：由安裝在來源伺服器上的 AWS 複製代理程式和暫存子網路中的 AWS MGN 複製和轉換伺服器共同使用
  2. Amazon EC2 VPC interface endpoint：僅由暫存子網路中的 AWS MGN 複製和轉換伺服器使用
  3. Amazon S3 VPC interface endpoint：僅需要讓內部部署代理程式透過 VPN 或 Direct Connect 與暫存 VPC 通訊，然後連接到 Amazon S3 儲存貯體（讓地端 server 抓得到 S3 裡面的 agent script）
  4. Amazon S3 VPC gateway endpoint：僅用於暫存區域伺服器（複製、轉換）存取 Amazon S3
  5. Route53 Resolver 入站端點：僅需要讓來源伺服器的代理程式能夠從來源伺服器解析 VPC 端點的私有 DNS 名稱

新增 MGN endpoint 時要記得選取正確的 VPC & staging subnet

設置 MGN Agent IAM Role

建立一個 Role，attach 這個 policy AWSApplicationMigrationAgentInstallationPolicy，並且 trust 要使用 MGN 的 Account ID，命名為 MGN_Agent_Installation_Role

Default Launch Template

等於預設啟動的 EC2 launch template

Post-launch Template

真正啟動 EC2 之後要執行的動作，像是直接 SSM agent 或者進行 DR 備份等

配置和部署

Source Servers 安裝 MGN Agent

Installing the AWS Replication Agent on Linux servers - AWS Transform MGN

agent 裡面做了類似 iam role anywhere 的機制，使用 x.509 憑證來確保 agent 不需到期重複驗證（有自動輪替效果）

1. 確認地端堡壘機與 AWS 網路連通

  • 測試控制層路徑：堡壘機 → S3 VPC endpoint（443）、堡壘機 → MGN VPC endpoint（443）
  • 額外測試資料層路徑：telnet/nc 到 Replication Server 的 TCP 1500（這條才是實際複製會用到的路徑，光測 443 不夠）
  • 確認堡壘機能透過 Route53 Resolver 入站端點解析到這些 VPC endpoint 的私有 DNS 名稱

2. 用 IAM Roles Anywhere 讓堡壘機取得暫時憑證

  • 前提：需先建立 Trust Anchor（綁定 CA）+ Profile（指向目標角色）
  • MGN_Agent_Installation_Role 的信任政策要改成信任 rolesanywhere.amazonaws.com，並用條件式限定來源為特定 Trust Anchor ARN（不能沿用原 workshop 那份「信任此帳戶」的寫法）
  • Roles Anywhere 的 CreateSession 一次到位直接換回目標角色的暫時憑證，不是「先變身分、再 assume」的兩段式流程
  • 角色本身維持只掛 AWSApplicationMigrationAgentInstallationPolicy，符合最小權限

3. 下載安裝腳本

  • 在堡壘機執行 wget，來源為該區域的 MGN 安裝腳本 S3 位置
  • 決定分送方式：複製到各 source server（收斂 S3 開通面到堡壘機一台）vs. 各 source server 自行 wget（官方預設寫法，但每台都要能連到 S3 endpoint）
  • 若選擇分送模式，仍需在步驟 4 安裝指令中帶 S3 endpoint 參數，讓安裝程式執行期間額外的 S3 呼叫也走私有路徑（複製檔案本身不足以完全去除對 S3 的依賴）

4. 帶憑證與 endpoints 執行 aws-replication-installer-init

  • 必要參數：-region、-aws-access-key-id、-aws-secret-access-key、-aws-session-token（暫時憑證專用）
  • 私有路徑參數：-endpoint（MGN 端點，需為雙棧端點）+ S3 endpoint 參數（避免對外開防火牆）
  • 執行後進入磁碟識別/選擇階段，確認識別到的磁碟與預期一致再繼續

Add source server 的介面上也會幫你組好下載 agent 的指令（但要自己填 access key id/session token）

當確認 source server 安裝並啟動 agent 後，可以在 MGN 的 source servers 列表看到啟用的主機

現在這個階段 server 已經開始抄寫

抄寫會分成兩階段 (1) 初始同步 (2) 寫入過濾器，第一階段會將整顆磁碟複製到 replication server 上，第二階段會偵測磁碟 I/O，有變更的才會進行修改。如果變更量超過 250MB，會退回去讀整顆磁碟；同時也會在 console 上看到 backlog 的狀態

更新 Target Instance 設置

可以依據不同 source server 更新各自的 launch settings，查看路徑如下

  1. 左側選單選擇 Source servers 後，點選其中一個主機名稱以查看伺服器詳細資訊

  2. 選擇 Launch settings 可以看到 default launch template 的設置，可以在這邊做修改。當然也可以使用 cli 等工具進行批次調整

App & Waves

Applications

為了提供業務需求而一起運作的 server group，這些 server 之間存在 dependencies，例如 backend server + DB 的組合，必須網路聯通才有辦法正確運作。這些 servers 必須要一起遷移，才能在 production 環境繼續正確運作

可以把多個 servers 加到單一個 application 裡面

Waves

計劃在指定期間內一起遷移的 Application group。Waves 中的 applications 不一定具有相依性，通常可以將低優先級的 applications 放在第一波次進行遷移，確認路徑、SOP 後，再以更穩定的流程去遷移高優先級 wave 中的 applications

可以把多個 applications 加到單一個 wave 裡面

測試和驗證

MGN 搬遷生命週期

  • Not Ready - 伺服器正在進行初始同步過程，尚未準備好進行測試。根據網路頻寬和來源伺服器的大小，此過程可能需要幾小時到幾天的時間。

  • Ready for testing - 伺服器已成功添加到應用程式遷移服務，且初始同步已完成。現在可以為此伺服器啟動測試或轉換執行個體。

  • Test in progress - 目前正在為此伺服器啟動測試執行個體。

  • Ready for cutover - 此伺服器已經過測試，現在可以啟動轉換執行個體。

  • Cutover in progress - 目前正在為此伺服器啟動轉換執行個體。

  • Cutover complete - 此伺服器已轉換。此伺服器上的所有資料都已遷移到轉換執行個體。

啟動測試執行個體

Question：跟正式 cutover 差在哪？

底層技術路徑一模一樣（同一套 Launch Conversion Server → 轉換成可開機快照 → 啟動執行個體的流程，用的也是同一份 launch settings）。真正的差異在「目的」跟「後續動作」，不是技術機制：

  • Test：純驗證用途，source server 正常運作、複寫持續進行，不影響正式環境；驗證完通常會把這個 test instance 終止掉。
  • Cutover：這是要成為正式環境的那一個；發起前建議先關閉 source server；官方文件也提到，每次執行新的轉換時，MGN 會先刪除先前啟動的測試執行個體及相依資源，再啟動反映最新狀態的新轉換執行個體；轉換完成後接的是 finalize（而非單純終止）。
  • Console 上的生命週期狀態也不同：Ready for testing → Test in progress，是一條路；Ready for cutover → Cutover in progress → Cutover complete，是另一條路，兩者不會混在一起。

  1. 一旦伺服器在 AWS MGN 主控台上的狀態變更為「Ready for testing」，您就可以啟動該伺服器的測試執行個體。

  2. 選擇要以測試模式啟動的執行個體。您可以選擇對應於 WordPress 應用程式的兩個伺服器。選擇右上角的 Test and cutover，然後選擇 Launch test instance。

  3. 這將把遷移生命週期的狀態更改為「Test in progress」

  4. 可以在遷移儀表板上檢查測試狀態。選擇清單中的任何伺服器以進入該伺服器的遷移儀表板

下一步應該是驗證已啟動的伺服器，以確保轉換過程已完成。但在我們可以驗證測試執行個體之前，我們必須等待10-15分鐘讓已啟動的任務完成。

在此期間，我們將對來源伺服器進行額外的變更，為下一個遷移步驟（最終轉換）做準備。然後我們將回到新啟動的測試執行個體的驗證，並繼續進行遷移生命週期。

Post-launch command

使用步驟如下：

  1. Console 設定 Post-launch Template SSM 整合（開啟執行的開關）

    建議直接開啟 Post-launch actions，會自動啟用 SSM agent

    啟用後可以選擇要哪些階段執行 post-launch actions

  2. 把腳本複製到 source server 的固定路徑（放進去要被執行的內容，也會被 MGN 抄去 target）

  3. target instance 開機時，SSM 自動化去那個固定路徑撿腳本執行

    • Linux 路徑：/boot/post_launch/
    • Windows 路徑：C:\Program Files (x86)\AWS Replication Agent\post_launch\

驗證測試執行個體

啟動測試執行個體將需要約 10-15 分鐘才能完成。一旦啟動任務完成，您應該在 AWS 應用程式遷移服務 主控台的來源伺服器清單中看到以下更新，並在警示欄中看到綠色的 Launched 狀態

在此步驟中，我們將驗證新啟動的測試執行個體具有正確的配置，並能夠在 AWS 上啟動。這包括：

  • 檢查所有執行個體是否通過系統狀態檢查和執行個體狀態檢查（2/2 檢查）在 Amazon EC2 主控台中

  • 驗證目標 AWS 配置是否正確：

    • 執行個體已在正確的目標子網路中啟動，並使用正確的安全群組
    • 執行個體類型和大小、EBS 磁碟區類型、IAM 設定檔角色正確指派

  • 使用 AWS Systems Manager 登入並執行額外測試，例如檢查任何特定的作業系統層級配置（系統驅動程式、網路配置等）

  • 最後，在完成所有檢查後，將所有來源伺服器標記為「Ready for cutover」

轉換 / Cutover

Note：AWS MGN 遷移最佳實務建議在最終轉換前至少兩週完成所有測試和驗證活動

Question：為啥要先 stop source server 再去做 cutover？

  1. 執行 cutover 時，MGN 會從 staging 區抄來的**資料當下 snapshot **在目標區啟動 cutover instance。因此若有資料持續寫入 source server，新寫入的那段資料會遺失，不會跟去 cutover instance 上
    • 官方文件：每次轉換時，AWS MGN 會先刪除先前啟動的測試執行個體及相依資源，接著啟動一個反映來源伺服器最新狀態的新轉換執行個體。轉換完成後，資料複寫會照常繼續——但來源伺服器上新增或修改的資料，會被傳輸到暫存區子網路，而不會再進到轉換過程中啟動的那個轉換執行個體裡。
  2. 由於 block level replication 不會管你程式邏輯、檔案狀態、資料庫是不是寫到一半，因此沒關服務就直接 cutover 很可能會發生在「資料寫入到一半的狀態」，導致 cutover instance 抄出來的東西是壞的、沒辦法讓應用正常運作

Reference：Migration workflow - AWS Transform MGN

  1. Stop source servers
  2. Launch cutover instances
  3. Validate application
  4. Finalize cutover

2. Launch cutover instances

  1. 一旦伺服器處於 **Ready for cutover **狀態，在右上角的下拉式選單中選擇 Test and cutover，選擇 Launch cutover instances

    如果看到 無法啟動轉換執行個體 訊息：前往左側的啟動歷史記錄選單並驗證先前的啟動任務是否已完成，等待終止任務完成，然後再次啟動轉換執行個體。

  2. 這會將所選伺服器的 **Migration lifecycle **狀態更改為 Cutover in progress

    由於關閉了 source servers，因此在各個 source server 的 alerts 和 data replication status 欄位都會顯示 Stalled 狀態

  3. 在測試或轉換啟動期間，可以監控 AWS MGN 任務歷史記錄的進度

  4. 點擊 Job 之後可以檢視詳細的 job log 及狀態、完成時間等資訊

    包含此啟動任務中的所有來源伺服器及其個別狀態的清單

4. Finalize cutover

為避免 MGN agent 在 cutover 之後持續抄寫、儲存複製的資料（暫存區的 EBS）產生額外費用，需要在 cutover 後進行 Finalize cutover 的動作。

這個動作會終止、刪除為了支援這些來源伺服器複寫而建立的所有 AWS 資源，時限是在 90 分鐘內完成；已啟動的 Test 或 Cutover instance 不會被終止；而 Replication Agent 會在 10 分鐘內收到解除安裝指令。[ref]

Note：上面說會移除 replication agent 的是 FinalizeCutover 這個 API，至於 console 上要做到這件事則需要點選 source server > Actions > Disconnect from service

當轉換成功完成時，應用程式遷移服務主控台將顯示轉換已完成。

Note：最後還有一個「Archive」的動作可以做，不過就只是單純不會繼續顯示在 MGN 介面上，技術面意義不大，單純整理介面用的功能

← 回到筆記