文章段落
雲端搬遷方法有哪些?不同情境下該如何選擇合適的搬遷方式?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 實作教學