雲端遷移 AWS 至 GCP,Migrate for Compute Engine 實作教學

雲端遷移 AWS 至 GCP,Migrate for Compute Engine 實作教學

雲端遷移 AWS 至 GCP 卻不知該如何開始嗎?針對虛擬機器的搬遷,GCP 的 Migrate for Compute Engine 是個很方便的搬遷工具。而它具備可還原的搬遷測試環境並讓使用者掌握即時的遷移進度,讓我們有更安心的遷移體驗!下面就一起來看看 AWS 主機遷移至 GCP 的實際操作方式吧!

什麼是 Migrate for Compute Engine?

在雲端化的時代,各家公司都積極地將自家產品或服務放上雲端,或是在不同的公有雲端平台中自在選擇,進而提升其 HA 與全球佈局彈性。而在這樣的情景下,如何能快速且穩定地從不同來源搬遷服務便成為一大議題。

在服務的搬遷上,我們可依據服務的規模將其分成大規模的虛擬機器單台虛擬機器搬遷兩種作業規模,以下我們將針對單台虛擬機器搬遷來做探討。而從一台虛擬機器的作用,我們又可再將其分為計算資源的搬遷儲存資源的搬遷兩類。

GCP 針對計算資源也就是一般的虛擬機器提供了 Migrate for Compute Engine(M4CE)服務;而針對儲存資源也就是所謂的資料庫提供了 Migration Jobs 服務,這裡就讓我們來談談如何使用 M4CE 來進行雲對雲的搬遷吧。

Migrate for Compute Engine 實作架構

在本次的操作練習裡,我們將使用 M4CE 從 AWS 將一台裝配了 EC2 主機搬遷至 GCP,而在開始操作前,我們先來了解一下 M4CE 在這個過程中所扮演的角色和與其搭配使用的服務。從下面的架構圖中我們可以看到,被紅色框線所選取的服務即是 M4CE 於搬遷過程中所生成並運作的節點,在整個搬遷的過程中,M4CE 透過 Manager 來控管權限操作與節點的生成

AWS 與 GCP 的網路環境間,M4CE 透過 Cloud VPN 作為傳輸資料的通道,從 AWS 生成的 Importer 節點將欲搬遷的 EC2 實例關機並生成 Snapshot 傳輸,而後於 GCP 端重新啟動該 Snapshot。

在資料遷移上則是透過生成兩個 Edge Node 在搬遷過程中 Stream 資料流,並作為取消遷移的資料處理工具,最後於遷移完成後結束工作。以上就是運用 M4CE 過程中的大體步驟與節點介紹,下面來帶大家進行實際的操作。

使用 Migrate for Compute Engine 的前置作業

在開始操作搬遷前,我們需要一個已在 AWS 上建置完成的 VPC 網路環境,並設置一個基礎的 EC2 虛擬機器以及安裝基本的 Web Server 如 Nginx,用於測試移轉成果。

另外在 GCP 也創建一個欲移轉到的 Project 與 VPC 網路環境,並創建一個後續給予 VPN 使用的 Static IP。而後就是從創建 Site to Site VPN 開始到完成單一虛擬機移轉的操作啦!

請先準備以下資源:
1. 一個 GCP 與 AWS 帳戶(用來操作以下實作內容)。
2. 一個作為搬遷目的地的 GCP Project 與 VPC 網路環境。
3. 一個 GCP 端的 Static IP。
4. 一個用於搬遷的 AWS EC2 實例與 VPC 網路環境。

建立 Site to Site VPN

要從不同的網路環境傳輸資料,建立 VPN 是一個常見的做法,而在 AWS 與 GCP 的網路傳輸上,我們就要來建立一個 Site to Site VPN。在這段操作裡面,我們要來回地操作 AWS 與 GCP 環境,開通相關的服務來為兩邊建立穩定的連線機制,以確保兩邊能透過 Internal IP 進行定位。

AWS GCP_雲端環境示意圖

要在 AWS 端開通 VPN 服務,我們分別需要設置作為 GCP 對接窗口 Customer Gateway(CGW),和作為 VPC 出入口Virtual Private Gateway(VPG)

於 CGW 端我們要讓 AWS 認知 GCP 的 VPN Static IP,所以這裡先填入預先準備的 GCP Static IP,後續創建 GCP VPN 時再對接起來。VPG 作為 AWS VPC 的出入口,在創建完成後直接綁定到預先準備的 VPC 就可以了。

VPN 建置步驟1:
1. 選擇 VPC > Virtual Private Network(VPN) > Customer Gateways 分頁標籤。
2. 點擊 Create Customer Gateway 開啟創建頁面。
3. 輸入自定義的 CGW 名稱,並於 Routing 選擇 Static
4. IP Address 欄位填入 GCP 保留的 Static IP
5. 按下 Create Customer Gateway 完成 CGW 的創建。
6. 選擇 VPC > Virtual Private Network(VPN) > Virtual Private Gateways 分頁標籤。
7. 點擊 Create Virtual Private Gateway 開啟創建頁面。
8. 輸入自定義的 VPG 名稱,並於 ASN 選擇 Amazon default ASN
9. 按下 Create Virtual Private Gateway 完成 VPG 的創建。
10. 選擇剛創建的 VPG 並點選 Actions > Attach to VPC
11. 選擇欲搬遷 EC2 實例所在的 VPC 並點選 Yes, Attach 完成綁定。

截圖自:Amazon Web Services Console 介面
© 2021, Amazon Web Services, Inc. or its affiliates.

在完成 CGW 與 VPG 的創建後,我們就可以來建構 AWS 端的 VPN 設定了。透過將 CGW 與 VPG 指定給 VPN 來完成兩端的對接,並透過給予 GCP 端目的地 Subnet 的 IP Range 來使 AWS 能透過 VPN 認知 GCP Subnet IP。

在完成 AWS 端 VPN 後,我們可以從 AWS 下載其 VPN 的 Config 檔,內涵兩組 Tunnel 資料,以供後續 GCP 使用。

VPN 建置步驟2:
1. 選擇 VPC > Virtual Private Network(VPN) > Site-to-Site VPN Connections 分頁標籤。
2. 點擊 Create VPN Connection 開啟創建頁面。
3. 輸入自定義的 VPN 名稱,並填入先前創立的 VPGCGW
4. 於 Routing Options 選擇 Static
5. 於 Static IP Prefixes 填入 GCP 目的地 Subnet IP Range
6. 點擊 Create VPN Connection 來完成 VPN 設定。
7. 選擇剛創建的 VPN 並點擊 Download Configuration 開啟下載頁面。
8. 於 Vender 選擇 Generic,Platform 選擇 Generic,Software 選擇 Vender Agnostic
9. 按下 Download 以下載 .txt 設定文件,可以在裡面找到兩組通道的 Pre-Shared keyVirtual Private Gateway IP

截圖自:Amazon Web Services Console 介面
© 2021, Amazon Web Services, Inc. or its affiliates.

接著我們回到 GCP 來建立這一側的 VPN 通道。與 AWS 不同的是,GCP 的 VPN 並不需設定 VPG 或 CGW,而是直接指定 VPC 和與 AWS 對接的 Static IP,並將在 AWS VPN 獲得的 Tunnel 資料進行對接,進而完成雙方的接通作業。

這裡要特別提醒的是,你可以只創建一個 Tunnel 來傳輸資料,但雙方會一直發 Email 提醒你單一通道的資料傳輸風險,所以這裡還是建議大家建立兩條 Tunnel

VPN 建置步驟3:
1. 選擇 Hybrid Connectivity > VPN 分頁標籤。
2. 點擊 VPN SETUP WIZARD 開啟建立畫面。
3. 選擇 Classic VPN,並按下 CONTINUE 鍵。
4. 輸入自定義 VPN 名稱,並選擇搬遷目的地之 VPC 與 Subnet,最後填入預留的 Static IP。
5. 創建兩條 Tunnel,分別於 Remote peer IP AddressIKE pre-shared key 欄位填入 AWS VPN config 文件內的兩組 Tunnel 參數。
6. 於 IKE version 選擇 IKEv1
7. 於 Routing options 選擇 ROUTE-BASED,並填入 AWS 搬遷目標所在 VPC 的 CIDR IP
8. 按下 Create 完成創建。

截圖自:Google Cloud Platform Console 介面
©2021 Google

創建 AWS 側 Migrate for Compute Engine 作業環境

確認 VPN 通道的傳輸順利後,我們就要來開始為 M4CE 建立於 AWS 側的操作環境了。為了要讓 M4CE 能在 AWS 端創建 Migrate Importer,我們需要透過 AWS Cloud Formation 創建一個堆棧(stack),讓堆棧來為我們準備所需要的環境。

Migrate 堆棧建置流程:
1.下載頁面下載 CloudFormation Stack 檔。
2. 於 AWS Console 開啟 CloudFormation 介面,並點擊 Create stack 鍵。
3. 選擇 Template is ready
4. 選擇 Upload a template file
5. 上傳剛剛下載的 VxCF-GA-V3-IAMONLY.rev1.json 檔案,並按下 Next 鍵。
6. 設定自定義堆棧名稱,並選擇目標所在 VPC,並按下 Next 鍵。
7. 勾選確認 AWS CloudFormation 會創建 IAM 資源,點擊 Create stack 完成創建。

截圖自:Amazon Web Services Console 介面
© 2021, Amazon Web Services, Inc. or its affiliates.

創建 AWS Migrate 權限使用者

創建完成的 CloudFormation Stack 會為我們的 AWS 設置一個 Policy 並綁定到一個新創建的 Group,我們只要再新創建一個 User 並加入到這個 Group,就可以獲得一個具備 M4CE 在 AWS 操作權限的 User 了。最後我們只要把這個 User 相關的資料以 .csv 格式下載下來,等到 GCP 端 M4CE 創建的時候就能賦予對應的權限。

Migrate 堆棧建置流程:
1. 選擇 Identity and Access Management(IAM)> Access management > Users 分頁標籤。
2. 點擊 Add User 開啟創建頁面。
3. 設定用戶名稱並勾選 Access key – Programmatic access,點擊 Next: Permissions
4. 選擇 Add user to group
5. 下方勾選剛剛 CloudFormation 為我們創建的 gcp-migrate-manager-stack-VelosMgrGroup-… 群組。
6. 完成創建後,點擊 Download .csv 下載 User 資料。

截圖自:Amazon Web Services Console 介面
© 2021, Amazon Web Services, Inc. or its affiliates.

階段注意事項:
在要搬遷的 VM 上,要先安裝一個 Google Compute Engine 的驅動程式,不然之後搬遷過去會出現錯誤。請點選此連結,依搬遷的作業系統做選擇並確實安裝。

GCP Firewall 設置

完成 AWS 端的所有設置後,接下來我們要確保之後 M4CE 在操作過程中能無阻礙的傳輸資料,所以我們要在 GCP 設置相對應的防火牆,相關防火設置可以依照官方文件指示並參照下圖範例,但記得要開啟 https 的防火設置來讓後面的 M4CE 操作介面能正常被開啟。

截圖自:Google Cloud Platform Console 介面
©2021 Google

運用 Migrate for Compute Engine 進行雲端搬遷

終於要進到本篇的正題了,從這階段開始我們要在 GCP 創建 Migrate Manager,透過 Web Console 來設定 AWS 來源端的相關資訊與 GCP 創建網路環境的指認,而後透過 Migrate Wave 與 Runbook 的設置,來定義搬遷環境的合適資源與搬遷流程控管,那麼話不多說我們就開始搬吧!

創建 Migration Manager

Migration Manager 目前在 GCP 有兩個版本類型,分別是 5.X 4.X 的版本,前者提供 HTTPS、Interconnection、VPN 等方式傳輸 On-premise 資源,而後者則沒有提供 HTTPS 傳輸服務,但卻可以搬遷 AWS、Azure 與 On-premise 來源。當然,兩者在搬遷方式上有些許的差異,在這裡我們就先不贅述,直接使用 4.X 版本來操作跨雲搬遷。

作為控管整個搬遷的中心,Migration Manager 在創建的過程中需要為它指定其運算資源的設置位置與網路環境,這裡可設定與當前專案相同即可。依照官方預設的防火設置需要給予 fw-velosmanager 標籤,確保網路環境正常運行,而這裡還有一個非常重要的設置重點,就是在這個階段我們要創建兩個 Service Account 來提供後續運作所需的權限,在這裡 GCP 已經為我們整理好需要給予的權限,直接指定名稱即可。

Migrate Manager 創建步驟:
1. 選擇 Compute Engine > Virtual machines > Migrate for Compute Engine 分頁標籤。
2. 第一次使用時需要啟用 VM Migration API 並且於右上角點選 SWITCH TO V4.X
3. 啟用 Migrate for Compute Engine required APIs 並點擊 DEPLOY MIGRATION MANAGER
4. 於 Configure network connectivity 分頁最下方勾選 Yes, I have complete… 網路設置前置作業確認。
5. 於 Migration manager VM instance 分頁設置欲創建的 Migrate Manager VM 名稱、版本(這裡使用4.11.6)、VPC 網路。
6. 於 Network tags 輸入 fw-velosmanager
7. 於 Service Accounts 分別創建 migrate-managercloud-extension Service Account。
8. 設定 Migration manager 密碼與加密密碼。

截圖自:Google Cloud Platform Console 介面
©2021 Google

登入 Migrate Manager Web Console

接下來我們要透過剛剛創建的 Migration Manager VM 開啟 Web Console。我們直接點選 VM instances 分頁,複製剛剛創建的 VM External IP,從瀏覽器以 HTTPS 方式開啟 Web Console。

開啟後會直接彈出登入視窗,於 Username 輸入 「apiuser」,Password 則是剛剛設定的密碼,按下 Sign in 後同意開啟 Stackdriver 相關服務,即可登入操作頁面。

截圖自:GCP Migrate Manager Web Console 頁面
©2021 Google

設置 Source Cloud Detail 與 Credential

進來後我們首先要操作來源端就是 AWS 雲端的相關設置,這裡會分成兩塊,分別是 Cloud CredentialsCloud Details。前者是指派我們先前創建的 AWS IAM User,後者則是設定 AWS 端 Importer 的創立位置。透過這兩者的設置,讓 M4CE 能有權限並知道要在哪裡設置 Workers(Importer)。

Source Cloud 設置步驟:
1. 點選左上方 Cloud Credentials 分頁,並點擊 Create 開啟設置視窗。
2. 於 Cloud Provider 選擇 AWS
3. Credentials Name 輸入自定義名稱。
4. Region 選擇欲搬遷之專案所在 Region
5. Access Key 與 Secret Key 填入之前創建 IAM User 所下載 .csv 的對應內容。
6. 點選左上方 Cloud Details 分頁,並點擊 Create 開啟設置視窗。
7. 於 Cloud Provider 選擇 AWS
8. 於 Name 輸入自定義名稱。
9. Credentials 選擇剛剛創建的 Credential。
10. 選擇 AWS 來源端要放置 Worker 的 Region、VPC、Security Group 和 Subnet。
11. 完成建立。

截圖自:GCP Migrate Manager Web Console 頁面
©2021 Google

設置 Target Cloud Extension

設定完來源端的網路與 Worker 設定後,我們要來設定 GCP 端的 Worker 工作環境了。在這個階段,有一點要特別注意的地方,由於 Cloud Extension 所生成的兩個 Node 分別需要 500 GB 的開機容量。所以針對設置 Worker 的 Region,必須要開啟其 Persistent SSD quota 至 2 TB 以上才能順利的執行這個步驟。

Target Cloud 設置步驟:
1. 進入 Target Cloud 頁面,並點選 Create 開啟 Cloud Extension 設定頁面。
2. 選取要遷移至的 ProjectRegionVPC
3. 於 Edge Nodes Network Tags 填入預設的 fw-velostrata 標籤。
4. 於 Default Network Tags for Workloads 填入預設的 fw-workload 標籤。
5. 於 Default Destination Project for Workloads 選擇當前使用 Project。
6. 開啟 Cloud Extension 設置欄,輸入自定義名稱。
7. Service Account for Edge Nodes 選擇前面創建的 Extension Service Account
8. Cloud Extension Size 這裡選擇 Small 就可以了。
9. 開啟 Zones 設置欄,選擇隨意兩個 Zone,相關的 Subnet 選擇目的地的 Subnet 就行了。
10. 設置完成後,可以透過右側的 Health Checks 查看 Cloud Extension 生成狀況。

截圖自:GCP Migrate Manager Web Console 頁面
©2021 Google

設置 Migration Waves

相關的工具與環境設定都處理好後,按照搬遷作業的邏輯,我們就要來計畫搬遷的動作啦!在 M4CE 中是以 Wave 作為每次搬遷動作的單位,每一個 Wave 會依照與 Wave 匹配的 Runbook 來執行動作,而 Runbook 則是一個描述搬遷 VM 資訊的 .csv 檔。

在這裡有個要特別提醒大家,Runbook 是透過來源端 VM 身上的 Tag 來過濾出需要搬遷的 VM,所以我們必須要先在來源端設定好 VM,這樣 M4CE 才能查找得到目標。接著我們要修改 Runbook 的 RunGroup ,定義執行的群組編號,讓 Wave 能正確的使用 Runbook。

Migration Waves 設置步驟(一):
1. 點選 Generate Runbook 並選擇 AWS 做為 Source。
2. Source Cloud Details 選擇剛剛創建的 Cloud Detail。
3. Filter by Source Tag 填入於 AWS EC2 上定義的 Tag Name,Value 填入 * 代表全部。
4. Target Cloud Extension 選擇前面創建的 Extension。
5. 勾選 Populate with Cloud Extension Defaults
6. 創建完成會自動下載 Runbook.csv 檔。
7. 開啟 .csv 檔,將 RunGroup 欄位從 -1 改成 1

截圖自:GCP Migrate Manager Web Console 頁面
©2021 Google

剛剛初步設置完了 Runbook,現在我們要以這個 Runbook 創建 Wave,此外還有件很重要的事情。上面提到 M4CE 會依據 Runbook 所給予的創建指示去建構目的地端的 VM,所以在 Runbook 內除了執行的群組外,還有一個非常重要的欄位就是 Target Instance Type

這個欄位會指定生成的 VM Machine Type,讀者如果有注意到的話,會發現該欄位預設是空白的。但不要擔心,M4CE 有提供簡易的方法協助我們找到合適的規格,並為我們檢查 Runbook 的設置使否有缺失。

Migration Waves 設置步驟(二):
1. 點選 New Wave 開啟創建 Wave 視窗。
2. 輸入自定義名稱並上傳剛下載的 Runbook.csv 檔案。
3. 選擇創建的 Wave 並點擊 Action > Right-Sizing,開啟設置選單。
4. 選擇 Get Recommendations 並按下 OK 來下載新的 Runbook.csv。
5. 開啟新的 Runbook.csv ,拉到最後會有 PerfOptRec_type_1-3PerfOptRec_cost_1-3 兩種欄位共三組。
6. 選擇 PerfOptRec_cost 最小的 type 資料,並貼到 TargetInstanceType 中。
7. 儲存 .csv 檔後,點擊 Action > Update Runbook,上傳新的 Runbook.csv。
8. 點擊 Action > Validate 認證 Runbook 設置完整性。
9. 看到 Wave 中 Validation Status 顯示 Passed 代表準備作業完成。

截圖自:GCP Migrate Manager Web Console 頁面
©2021 Google

執行 Migration Jobs

終於所有準備動作都完成了,接下來我們只要執行對應的步驟就能完成整個搬遷的動作了,但在開始執行前,我們先來了解一下 M4CE 在搬遷過程中的 Full Migration、Detach、Cleanup 三大階段。要分成三個階段來完成搬遷動作是因為 M4CE 除了遷移過程的狀態追蹤外,另外一個重要功能就是測試搬遷,而要能夠測試搬遷,就要考量到資料的儲存與還原

因此在我們操作的第一個步驟:Full Migration 階段,會執行我們前面提過的 Snapshot 製作與 VM 建置,但存在於磁碟中的資料並不會直接複製過來,而是透過 Streaming 的方式,以 A、B 兩個工作節點來做存取與傳導,並以 Cache 的形式存在獨立的 Persistent Disk 中。

所以在這階段我們是可以還原搬遷操作的,因為大量的資料還沒有被複製過來, M4CE 只要把 Snapshot 建置的 VM 刪除即可。而從 Detach 階段開始,在確認搬遷後的結果都沒有問題後,我們就可以執行 Detach 到 Cleanup 的步驟,這兩個步驟執行後都沒有辦法還原,只能一條路走到尾。

因為在 Detach 步驟中,我們會斷開與來源的 Streaming,並斷開 A、B 節點對 Persistent Disk 的掌握,然後將其與搬遷完成之 VM 綁定,使 VM 可以獨立運行。而 Cleanup 步驟簡單來說就是收尾的動作,將搬遷過程中產生的服務與暫存清理,避免資源浪費。

接著我們就來操作 Full Migration 的步驟吧,執行起來很簡單,只要選擇對應的 Wave ,並從 Action 選擇 Full Migrate 就可以執行了,很簡單吧!如果想看搬遷的工作記錄,可以透過 Monitor 的 Migrate Status 看到百分比進度,也可以在 AWS EC2 頁面看到搬遷的 VM 被關機了,並生成了一個 Importer。

而在 GCP 這端,也可以透過 VM instances 頁面看到創立的兩個節點與一個 Exporter 正在運行,最後會看到目標 VM 被確實地搬遷到 GCP 並自動執行開機作業。

截圖自:GCP Migrate Manager Web Console 頁面
©2021 Google

我們可以透過給搬遷過來的 VM 一個 External IP 來測試連線狀況,可以看到 Web Server 正常運行。在確認搬遷完成後,我們就可以一樣透過 Wave 的 Action 去依序選擇 Detach 與 Cleanup,在這些動作執行完後,就算是完成一波精彩的搬遷了!

截圖自:GCP Migrate Manager Web Console 頁面
©2021 Google

以上就是運用 M4CE 進行的跨雲搬遷的教學。雖然這次示範的是從 AWS 上將 VM 搬移至 GCP,但其實除了雲對雲的搬遷,從地端上雲也可以透過 M4CE 來完成喔!以上,如果針對文章有任何問題都歡迎下方留言提問,有其他關於雲端搬遷或 GCP 的疑問或需求也都歡迎聯絡我們喔!

延伸閱讀:

【GCP教學】第一次開 Google VM 就上手 – Compute Engine 操作簡介
【GCP教學】第一次開Google VM要注意什麼?Compute Engine開機詳細介紹
使用 Google VM 的5大常見錯誤 – 有一種叫忘記關機!
【GCP教學】如何輕鬆備份 GCP 上 VM 的資料?快照 Snapshot 自動備份設定教學

Cloud Ace 研討會主頁

William Wang

擅長資訊整合方案規劃,且在雲端部署、物聯網、XR 及網頁應用開發領域均有涉獵。過去曾任大專院校與推廣教育產業的兼任講師,具備豐富的資訊技術教學經驗並擅長透過生動的描述讓複雜資訊易於吸收。

發佈留言