規劃虛擬伺服器的遷移波次，位於 IBM Cloud VPC

透過映射虛擬機器（ VM ）的依賴關係、估算進度速度，並為應用程式堆疊排定切換時段，來規劃 IBM Cloud VPC 的遷移階段。

依賴性規劃

在開始遷移之前，您需要映射下列應用程式的相依性：

以層級為基礎：

  • 網頁層級 → 應用程式層級
  • 應用程式層 → 資料庫層
  • 資料庫層 → 共用儲存與服務

交叉應用：

  • 鑑別
  • 監視
  • Backup
  • 日誌聚合
  • DNS 和 NTP

發現的工具：

  • VMware vRealize Network Insight ( ) vRNI
  • 應用程式依賴關係對應工具
  • 網路流量分析
  • 應用程式擁有者的手動文件

針對每個虛擬伺服器，在遷移計劃中記錄下列資訊：

  • 入站依賴
  • 出站依賴
  • 共用資源

測試移動波設計

您的第一波移民潮是測試（試行）潮。 要成功實施測試波形，您必須遵守下列資訊：

正確表示您的虛擬伺服器：

  • 單磁碟版 Linux 虛擬伺服器
  • 多磁碟 Linux 虛擬伺服器
  • 單磁碟 Windows 虛擬伺服器
  • 多磁碟 Windows 虛擬伺服器
  • 具有依賴性的應用程式（3 層應用程式）

使用「最低風險」選項：

  • 在非生產環境中執行遷移。 或者，使用維護視窗較大的生產環境。
  • 瞭解應用程式的回滾程序。

執行完整的遷移：

  • 對您選擇的方法進行完整的端對端測試
  • 附註 移轉時間與估計時間
  • 發現測試中未發現的問題

成功移轉的標準：

  • 所有虛擬伺服器都成功啟動
  • 應用程式正常運作
  • 網路連線已驗證
  • 績效達到或超過基準
  • 資料不會遺失或損毀
  • 移轉文件完整且準確

波浪結構指引

基於子網路的群組：

請記住，您不能在 VMware 和 VPC 之間延伸子網路。 這表示您需要執行下列動作：

  • 依子網路群組虛擬伺服器
  • 一次性遷移整個子網路，或知道您需要重新 IP 某些虛擬伺服器
  • 及早規劃子網路至 VPC 子網路對應

多層應用程式的應用程式堆疊群組：

  • 如果可能的話，一次過遷移整個堆疊。
  • 如果您的遷移過於龐大，請先從資料庫遷移，然後再遷移應用程式，如此類推。
  • 透過 IBM Cloud Transit Gateway，維持已遷移與未遷移層級之間的連通性。

針對依賴感知排序的應用程式堆疊群組：

  • 首先遷移基礎架構服務 (DNS、監控、備份)。
  • 在需要的應用程式之前遷移共用服務。
  • 考慮每個波浪的影響，並考慮一旦失敗時的影響。

平行遷移功能：

方法 3 即時網路傳輸(建議使用於 Scale) 在這方面表現優異：

  • 提供多個 Worker 虛擬伺服器實體
  • 同時遷移多個虛擬伺服器
  • 受限於網路頻寬和工作者虛擬伺服器實例資源
  • 典型值：每個 Worker 虛擬伺服器實例有 4-8 個並發移轉

測試波範例結構

以下範例顯示 50 台虛擬伺服器的遷移。

第 0 波（測試）：5 台虛擬伺服器

  • 1x 單碟 Linux (方法 1 測試)
  • 1x 多磁碟 Linux (方法 2 測試)
  • 1x 單磁碟 Windows (使用 sysprep 的方法 1)
  • 1x 多磁碟 Windows (方法 2，含 virt-v2v )
  • 1x 3 層測試應用程式 (方法 2 和 3，全堆疊)

第 1 波（基礎架構）：8 台虛擬伺服器

  • DNS 伺服器
  • 監視伺服器
  • 跳躍主機或堡垒伺服器
  • 遷移至 VPC 檔案儲存的共用檔案伺服器

第 2 波 (應用程式 A)：12 台虛擬伺服器

  • 資料庫層 (3 個虛擬伺服器)
  • 應用程式層級 (6 個虛擬伺服器)
  • 網頁層級 (3 個虛擬伺服器)
  • 子網路 10.50.10.0/24 → VPC 子網路 10.240.10.0/24

第 3 波 (應用程式 B)：10 台虛擬伺服器

  • 結合資料庫與應用程式層級 (4 個虛擬伺服器)
  • 網頁層級 (6 個虛擬伺服器)
  • 子網路 10.50.20.0/24 → VPC 子網路 10.240.20.0/24

第 4 波 (應用程式 C)：15 台虛擬伺服器

  • 大型多層應用程式
  • 子網路 10.50.30.0/24 → VPC 子網路 10.240.30.0/24

切換時段設計

每個波浪都需要一個明確的切換窗口。

切割前時間表（7 天至轉移日）：

  • 完成波浪計畫和運行簿
  • 確認 Transit Gateway 連線
  • 提供工作者虛擬伺服器實體和目標磁碟區
  • 與利害關係人溝通切換時間窗
  • 減少遷移服務的 DNS TTL
  • 通知使用者維護視窗

切換執行 ( T-0 )

以下資訊描述切換階段。

第 1 階段：暫停與遷移（0-4 小時）

  1. 耗盡連線 - 從負載平衡器移除連線，並等待會話關閉。
  2. 優雅地停止應用程式
  3. 關閉虛擬伺服器或從 Live ISO 啟動方法 3
  4. 開始磁碟傳輸
  5. 監控轉移進度

第二階段：轉型與提供（4-6 小時）

  1. 如果需要，執行 virt-v2v，以注入驅動程式
  2. 驗證磁碟傳輸 (fdisk、校驗和值)
  3. 從 Worker 清空緩衝區並離開卷
  4. 從遷移的磁碟區建立虛擬伺服器實體
  5. 啟動虛擬伺服器執行個體

第 3 階段：驗證與切換（6-8 小時）

  1. 啟動虛擬伺服器實體，並在需要時透過 VNC 主控台存取
  2. 驗證網路設定，必要時進行調整
  3. 開始應用
  4. 功能測試（應用程式可正常運作、資料可存取）
  5. 新增至負載平衡器並更新 DNS
  6. 監視應用程式效能

第 4 階段：穩定（第 8-12 小時）

  1. 監控問題
  2. 驗證外部連線
  3. 檢查應用程式日誌是否有錯誤
  4. 比較績效與基線

遷移回溯決策點：

  • 階段 1 之後：輕鬆回復 (重新啟動 VMware 虛擬伺服器)
  • 第 2 階段後：中等難度 (捨棄虛擬伺服器實體、重新啟動 VMware 虛擬伺服器、還原 DNS)
  • 第 3 階段之後: 困難 (可能在 VPC 中有新的資料，需要將資料同步回 VMware )

設計建議：定義明確的去、不去檢查點。 範例：

  • 在第 2 階段之後，如果超過 20% 的虛擬伺服器實體無法啟動，請執行回退。
  • 在第 3 階段之後，如果應用程式功能測試失敗，請執行回退。
  • 第 4 階段之後，如果效能比基準低 30%以上，請進行調查，但不要執行回退。

移動速度估計

估計每個虛擬伺服器的遷移時間，以規劃實際的波形大小和視窗。 以下的時間表是可以達成的，但您需要在實際遷移之前先在 PoC。

時間元件：

使用方法 1-2 估計出口時間：

  • 100 GB 虛擬伺服器：20-30 分鐘
  • 500 GB 虛擬伺服器：2-3 小時
  • 取決於 VMware 儲存效能

傳輸時間預估：

  • 網路：100 GB = 20-25 分鐘
  • 網路：500 GB = 90-120 分鐘
  • 有壓縮的方法 3：由於壓縮，速度通常快 2 或 3 倍

轉換時間估計與 virt-v2v:

  • Linux:5-10 分鐘
  • 視窗：10-20 分鐘
  • 取決於工作者虛擬伺服器實例效能

供應時間預估：

  • 虛擬伺服器實例建立：5 分鐘
  • 開機與網路設定：5-10 分鐘

時間估計範例：

小型 Linux 虛擬伺服器 (1 個磁碟、100 GB、方法 3)：

  • 沒有輸出：0 分鐘
  • 壓縮轉移：25 分鐘
  • 變身：5 分鐘
  • 佈建：10 分鐘
  • 總計：40 分鐘

大型 Windows 虛擬伺服器時間估計，使用方法 2，使用 4 個磁碟，總容量為 1 TB：

  • 出口：3 小時
  • 轉機：2 小時
  • 變身 ( virt-v2v )：20 分鐘
  • 佈建：10 分鐘
  • 總計：5.5 小時

同時使用方法 3、4 估計時間的平行移轉效率：

  • 4x 並行遷移的 100 GB 虛擬伺服器
  • 各 30 分鐘
  • 總浪費時間：35 分鐘，包括啟動和關閉時間

與遷移 4x 100 GB 的虛擬伺服器相比，您可以連續遷移：

總浪費時間為 120 分鐘

在這種情況下，並行性可讓您的效能提升 3 - 4 倍。