雲端搬遷方法有哪些？4大方法滿足常見的企業上雲情境

雲端搬遷方法有哪些？不同情境下該如何選擇合適的搬遷方式？Cloud Ace 除了針對4大常見的上雲情境規劃相對應的搬遷方案，也整理了自帶 Windows 授權上雲需注意的要點，快跟著我們一起尋找合適的搬遷方式吧！

雲端搬遷4大方法與適用情境

在《企業為什麼要上雲？上雲前的3大評估點及雲端6大優點》中，我們整理了企業上雲前的3大評估重點，若評估完後確定要搬遷上 Google Cloud Platform（GCP），那第一步就是確認現有的系統環境。不同的環境有不同的搬遷方法，其中影響程度最大的就是機器數量。機器數量少時可利用較簡易的工具和方法執行；機器數量多則可利用 GCP 的各種工具加速整體搬遷流程。

雲端搬遷情境1：僅1~2台虛擬機器

若今天公司只有1~2台虛擬機器（VM），則可將 VMware 的 VMDK 檔案，或 Hyper-V 的 VHD 檔案匯入 GCP 轉換為 Image ，再用 Image 建立虛擬機器即可。如果是使用 Virtual Box 的 OVA 或 OVF 檔案格式，也可匯入 GCP 成為一台完整的虛擬機器。

另外若是實體機，則能使用 VMware vCenter Converter（原 VMware Converter），將實體機上的作業系統轉換成 VMDK 檔案後直接匯入 GCP。這種直接匯入檔案的方式雖然最簡單，但要注意成功率很低，因為這種做法類似硬生生地把機器照原有樣子搬遷上雲，未考慮相容性問題。另外，如果機器有使用 LVM（Logical Volume Management）則無法直接上雲，所以直接匯入檔案時如因不明原因匯入失敗，請考慮下一個方法。

雲端搬遷情境2：多台虛擬機器

這種狀況 Cloud Ace 一般建議使用 GCP 的 Migrate for Compute Engine。它會在地端 VMware 環境建立一台 Migrate Connector 主機，待主機向 GCP 註冊完畢後，呈現出地端所有可遷移的主機清單。此時我們可透過 GCP Console，先針對多台主機設定不同的搬遷波次 （Wave），再針對不同波次設定搬遷目的地與主機規格等資訊，最後再開始搬遷。

Migrate Connector 會將地端主機資料持續複製到 GCP，而使用者在 GCP Console 上就會看到一台新的主機，待資料複製完成會呈現 Active（Idle）狀態，這時就可以按下 Test-Clone 來確認上雲的主機是否有任何問題。若 Test-Clone 確認無誤，則可正式按下 Cut-Off 鍵讓雲端上的主機成為正式的機器。完整操作教學可參考《雲端遷移 AWS 至 GCP，Migrate for Compute Engine 實作教學》。

其中要注意的是，原本在地端的機器是透過 VMware 管理主機，Migrate for Compute Engine 搬遷後就會是一台 GCP 的主機。除了會幫忙安裝 Guest Environment 讓主機可以與整個 GCP 環境相容，相關的 Log 和 Metric 也都會傳送到 Cloud Logging 和 Cloud Monitoring ，讓使用者像擁有雲端原生的主機。

雲端搬遷情境3：數十台以上虛擬機器

若我們在地端有大量的 VMware 主機，或是 vCenter 的規模龐大且想要在 GCP 上沿用 VMware 環境，則可考慮使用 VMware Engine。Google 提供專屬的 VMware SDDC 硬體和 VMware 授權，會直接在 GCP Project 上建立一個 vCenter， 讓使用者操作起來就像在地端管理 vCenter。

而在搬遷上，我們必須先建立 Cloud VPN 或 Cloud Interconnect 連接兩邊的 VMware 環境，接著透過 VMware 提供的 HCX 將 VM 從地端環境遷移到 Google Cloud VMware Engine。這種方式要注意的是，在 GCP 上使用 VMware 環境，除了運行環境所需的硬體資源外，也需要負擔 VMware 的相關授權費用。

雲端搬遷情境4：單體式架構

接下來這部分與主機數量無關，如果我們的地端環境已運行多年，所有的程式都串接在一起形成所謂的單體式（Monolithic）架構，要搬遷會相當困難。因為多台主機間可能會有資料一致性的需求，若搬遷過程造成資料傳輸中斷或不一致，會很難排除故障。通常這種架構不會建議直接進行搬遷，而是先執行程式碼重構，將原本把所有功能寫在同一組程式碼的設計，依照功能逐一拆分。

如果同一台主機內有前端網頁、內部程式邏輯甚至是資料庫，首先一定會把資料庫抽離到外部，讓主機上的程式成為無狀態（Stateless）服務。如此一來可確保主機產生的問題不會去拖累到後端資料庫，而資料庫本身也能透過 Cloud SQL 設定自動備份和高可用性（High Availability），遇到問題時也能快速容錯移轉（Failover）。

接著再將網頁（Web）與程式（AP）分開，讓不同的主機負責各自的功能，比較好的架構甚至會在網頁與程式中間加一層內部負載平衡（Internal Load Balancer） 。因為 Web 和 AP 都有可能是負載較重的一方，所以除了最前端會架設負載平衡外，Web 和 AP 間也有負載平衡，這樣兩者就可依當下的負載各自進行自動擴充（Autoscale），確保主機運行的穩定。

以上還只是初步的拆分，真正的拆分會把系統的各項功能再拆分到不同主機，讓每個功能可獨立運作，這樣即使某個功能因異常而停止，也不會拖累到其他功能，達到真正的微服務化。該功能也可自動修復，不需要固定有人工介入。更新也能有滾動式更新（Rolling Update）機制，或是部署錯誤可立即退回原來的版本，達到基本的 CI/CD。

雲端搬遷注意事項：自帶 Windows 授權

此外有一點跟搬遷方式無關但要特別注意的是，許多企業會使用微軟的授權作業系統 Windows Server，雖然可自帶授權上雲（Bring Your Own License），但要注意必須使用單一租戶群節點（Sole-tenant nodes），也就是在專用的硬體主機上運行自備的授權，而單一租戶群節點目前最小規格也要 60 個 vCPU，因此費用較高。若有大量自備授權，可將所有的 Windows Server 都集中在單一租戶群節點上運行，但如果只有少數授權卻用相同方式就會非常不划算，因此建議直接使用 Google 提供的 Windows 授權即可。

結論

以上提到的各種搬遷方式雖然都能在網路上找到相關介紹文件，但當中都有一些須特別留意的技術細節，對沒有相關經驗的人而言也有一定程度的學習門檻，另外在操作時如遭遇意外狀況，也需額外花時間排除與修復。因此 Cloud Ace 建議有搬遷上雲需求的使用者，可尋找專業合作夥伴協助，將搬遷過程中的風險降到最低，並最大化搬遷上雲的優點。

以上就是雲端搬遷至 GCP 的4大方法，和給自帶 Windows 授權上 GCP 者的小提醒，針對文章內容如有任何問題都歡迎在下方留言。最後，若想更了解 GCP，或有技術服務相關需求也都歡迎填寫表單聯繫我們。

▋延伸閱讀：

・GCP 是什麼？可以拿來吃嗎？完整介紹 Google Cloud Platform
・GCP 如何計費？就像水電費一樣
・第一次開 GCP VM 就上手！Compute Engine 開機教學
・企業為什麼要上雲？上雲前的3大評估點及雲端6大優點
・雲端遷移 AWS 至 GCP，Migrate for Compute Engine 實作教學