從 AWS 遷移至 Google Cloud:從 Amazon EC2 遷移至 Compute Engine

Last reviewed 2024-11-20 UTC

Google Cloud 提供工具、產品、指南和專業服務,協助您將虛擬機器 (VM) 和相關資料從 Amazon Elastic Compute Cloud (Amazon EC2) 遷移至 Compute Engine。本文將討論如何設計、實作及驗證從 Amazon EC2 遷移至 Compute Engine 的計畫。

本文的討論內容適用於雲端管理員,旨在提供規劃及實作遷移程序的詳細資訊。此外,這份指南也適合評估遷移機會的決策人員,以及想瞭解遷移作業可能樣貌的使用者。

本文是從 AWS 遷移至Google Cloud 的系列文章之一,其他文章包括:

如要進行這項遷移作業,建議您按照「遷移至 Google Cloud:開始使用」一文所述的遷移架構操作。 Google Cloud

以下是遷移流程圖。

列出四個階段的遷移路徑。

您可能會從來源環境遷移至 Google Cloud ,並進行一系列的疊代作業,例如先遷移部分工作負載,再遷移其他工作負載。針對每次個別的遷移疊代作業,您會遵循一般遷移架構的各個階段:

  1. 評估及探索工作負載和資料。
  2. 規劃並奠定 Google Cloud的基礎。
  3. 將工作負載和資料遷移至 Google Cloud。
  4. 最佳化 Google Cloud 環境。

如要進一步瞭解這個架構的各個階段,請參閱「遷移至 Google Cloud:開始使用」。

為設計有效的遷移計畫,建議您驗證計畫的每個步驟,並確保您有復原策略。如要驗證遷移計畫,請參閱「遷移至 Google Cloud:驗證遷移計畫的最佳做法」。

評估來源環境

在評估階段,您會決定將來源環境遷移至 Google Cloud的需求和依附元件。

評估階段是您能否成功遷移的關鍵。您必須深入瞭解要遷移的工作負載、工作負載的要求和依附元件,以及您目前的環境。此外,您還必須知道要從何踏出第一步,以成功規劃並執行 Google Cloud遷移作業。

評估階段包含下列工作:

  1. 建立鉅細靡遺的工作負載清單。
  2. 根據工作負載的屬性和依附元件將工作負載編目。
  3. 訓練並教導您的團隊使用 Google Cloud。
  4. 在 Google Cloud上建立實驗和概念驗證。
  5. 計算目標環境的總持有成本 (TCO)。
  6. 為工作負載選擇遷移策略。
  7. 選擇遷移工具。
  8. 定義遷移計畫和時程。
  9. 驗證遷移計畫。

如要進一步瞭解評估階段和這些工作,請參閱「遷移至 Google Cloud:評估及探索工作負載」。以下各節內容皆以該文件為依據。

建立 Amazon EC2 執行個體清單

如要設定遷移範圍,請建立 Amazon EC2 執行個體清單。然後,您可以使用清查結果,評估在這些執行個體上部署工作負載的部署和作業程序。

如要建立 Amazon EC2 執行個體的清單,建議使用 Migration Center,這個統合式平台可協助您加快從目前環境遷移至Google CloudGoogle Cloud,完成端對端雲端旅程。您可以使用 Migration Center 在 AWS 上執行資產探索作業

Migration Center 和 Migration Center 用戶資產評估器 CLI 提供的資料,可能無法完整擷取您感興趣的維度。在這種情況下,您可以將該資料與其他資料收集機制的結果整合,這些機制是根據 AWS API、AWS 開發人員工具和 AWS 命令列介面建立。

除了從 Migration Center 和 Migration Center 用戶資產評估器 CLI 取得的資料外,請考慮要遷移的每個 Amazon EC2 執行個體,並提供下列資料點:

  • 部署地區和區域。
  • 執行個體類型和大小。
  • 執行個體啟動時使用的 Amazon Machine Image (AMI)。
  • 執行個體主機名稱,以及其他執行個體和工作負載如何使用這個主機名稱與執行個體通訊。
  • 執行個體標記,以及中繼資料和使用者資料。
  • 執行個體虛擬化類型。
  • 執行個體購買選項,例如隨選購買或 Spot 購買。
  • 執行個體如何儲存資料,例如使用執行個體儲存空間和 Amazon EBS 磁碟區。
  • 執行個體用戶群設定。
  • 執行個體是否位於特定放置群組中。
  • 執行個體是否位於特定自動調度群組中。
  • 執行個體所屬的安全群組。
  • 涉及執行個體的任何 AWS Network Firewall 設定。
  • 執行個體上執行的工作負載是否受到 AWS Shield 和 AWS WAF 保護。
  • 您是否要控管執行個體的處理器狀態,以及執行個體上執行的工作負載如何取決於處理器狀態。
  • 執行個體 I/O 排程器的設定。
  • 如何將執行個體上執行的工作負載公開給在 AWS 環境中執行的用戶端 (例如其他工作負載) 和外部用戶端。

評估部署和作業程序

請務必清楚瞭解部署和作業程序。這些程序是準備及維護實際工作環境和其中執行工作負載的實務做法,也是不可或缺的一環。

部署和作業程序可能會建構工作負載運作所需的構件。因此,您應收集各個構件類型的相關資訊。例如,構件可以是作業系統套件、應用程式部署套件、作業系統映像檔、容器映像檔或其他項目。

除了構件類型,請考慮如何完成下列工作:

  • 開發工作負載。評估開發團隊建構工作負載的流程。舉例來說,開發團隊如何設計、編碼及測試工作負載?
  • 產生要在來源環境中部署的構件。如要在來源環境中部署工作負載,您可能需要產生可部署的構件 (例如容器映像檔或作業系統映像檔),或是自訂現有構件 (例如安裝及設定軟體,藉此自訂第三方作業系統映像檔)。收集有關如何產生這些構件的資訊,有助於確保產生的構件適合在Google Cloud中部署。
  • 儲存構件。如果您在來源環境的構件登錄中產生構件並儲存,則必須在 Google Cloud 環境中提供這些構件。您可以採用下列策略:

    • 在環境之間建立通訊管道:讓目標環境可存取來源環境中的構件。Google Cloud
    • 重構構件建構程序:完成來源環境的次要重構,以便在來源環境和目標環境中儲存構件。這種做法可讓您在目標 Google Cloud環境中實作構件建構程序之前,先建構構件存放區等基礎架構,進而支援遷移作業。您可以直接採用這種做法,也可以先建立通訊管道,再採用這種做法。

    如果來源和目標環境都有可用的構件,您就能專注於遷移作業,不必在目標環境中實作構件建構程序,做為遷移作業的一部分。 Google Cloud

  • 掃描並簽署程式碼。在構件建構程序中,您可能會使用程式碼掃描功能,防範常見的安全性漏洞和非預期的網路曝光,並使用程式碼簽署功能,確保只有受信任的程式碼會在環境中執行。

  • 在來源環境中部署構件。產生可部署的構件後,您可能會在來源環境中部署這些構件。建議您評估每個部署程序。這項評估可確保您的部署程序與 Google Cloud相容。此外,您也能瞭解最終重構程序所需的作業量。舉例來說,如果部署程序只適用於來源環境,您可能需要重構這些程序,才能以 Google Cloud 環境為目標。

  • 注入執行階段設定。您可能會為特定叢集、執行階段環境或工作負載部署作業注入執行階段設定。設定可能會初始化環境變數和其他設定值,例如密鑰、憑證和金鑰。為確保執行階段設定注入程序可在 Google Cloud上運作,建議您評估來源環境中執行的工作負載設定方式。

  • 記錄、監控及剖析。評估您現有的記錄、監控和剖析程序,瞭解如何監控來源環境的健康狀態、感興趣的指標,以及您如何使用這些程序提供的資料。

  • 驗證。評估您在來源環境中進行驗證的方式。

  • 佈建及設定資源。為準備來源環境,您可能已設計及實作佈建和設定資源的程序。舉例來說,您可能會使用 Terraform 和設定管理工具,在來源環境中佈建及設定資源。

規劃及建立基礎

在規劃和建構階段,您會佈建及設定基礎架構,以執行下列操作:

  • 滿足環境中的工作負載需求。 Google Cloud
  • 連線來源環境和 Google Cloud 環境,完成遷移作業。

規劃和建構階段包含下列工作:

  1. 建立資源階層。
  2. 設定 Google Cloud身分與存取權管理 (IAM)。
  3. 設定帳單資訊。
  4. 設定網路連線。
  5. 強化安全性。
  6. 設定記錄、監控和快訊功能。

如要進一步瞭解各項工作,請參閱「遷移至 Google Cloud:規劃及建構基礎」。

遷移工作負載

如要將工作負載從 Amazon EC2 遷移至 Compute Engine,請完成下列步驟:

  1. 將 VM 從 Amazon EC2 遷移至 Compute Engine。
  2. 將 VM 磁碟遷移至 Persistent Disk。
  3. 向用戶端公開在 Compute Engine 上執行的工作負載。
  4. 重構部署和作業程序,以Google Cloud 為目標,而非 Amazon EC2。

下列各節將詳細說明這些工作。

將您的 VM 遷移至 Compute Engine

如要將 VM 從 Amazon EC2 遷移至 Compute Engine,建議使用Migrate to Virtual Machines 這項全代管服務。詳情請參閱「使用 Migrate to VMs 進行遷移」。

在遷移過程中,Migrate for VMs 會遷移 Amazon EC2 執行個體目前的狀態,但必要設定變更除外。如果 Amazon EC2 執行個體執行自訂 Amazon EC2 AMI,Migrate for VMs 會將這些自訂項目遷移至 Compute Engine 執行個體。不過,如要讓基礎架構可重現,您可能需要透過建構 Compute Engine 作業系統映像檔,在部署和作業程序中套用同等自訂項目,詳情請參閱本文後續內容。

將 VM 磁碟遷移至 Persistent Disk

您也可以使用 Migrate to VMs,將來源 Amazon EC2 VM 的磁碟遷移至永久磁碟,且 Amazon EC2 VM 上執行的工作負載只會短暫中斷。詳情請參閱「遷移 VM 磁碟並將其連結至新的 VM」一文。

舉例來說,您可以將附加至 Amazon EC2 VM 的資料磁碟遷移至永久磁碟,然後附加至新的 Compute Engine VM。

公開在 Compute Engine 上執行的工作負載

將 Amazon EC2 執行個體遷移至 Compute Engine 執行個體後,您可能需要佈建及設定 Google Cloud環境,才能向用戶端公開工作負載。

Google Cloud 提供安全可靠的服務和產品,可將工作負載公開給用戶端。對於在 Compute Engine 執行個體上執行的工作負載,您可以為下列類別設定資源:

  • 防火牆
  • 流量負載平衡
  • DNS 名稱、區域和記錄
  • DDoS 防護和網頁應用程式防火牆

針對每個類別,您可以先實作基準設定,類似於您在對等類別中設定 AWS 服務和資源的方式。然後,您可以疊代設定,並使用 Google Cloud 服務提供的其他功能。

下列各節說明如何佈建及設定這些類別中的Google Cloud 資源,以及這些資源如何對應至類似類別中的 AWS 資源。

防火牆

如果您已設定 AWS 安全性群組和 AWS Network Firewall 政策與規則,可以設定 Cloud Next Generation Firewall 政策與規則。您也可以佈建 VPC Service Controls 規則,控管虛擬私有雲內的網路流量。您可以使用 VPC Service Controls 控制 Compute Engine 執行個體的輸出流量,並協助降低資料竊取風險。

舉例來說,如果您使用 AWS 安全性群組允許或拒絕連線至 Amazon EC2 執行個體,可以設定類似的虛擬私有雲 (VPC) 防火牆規則,套用至 Compute Engine 執行個體。

如果您使用 SSH 或 RDP 等遠端存取通訊協定連線至 Amazon EC2 VM,可以移除 VM 的公開 IP 位址,並透過 Identity-Aware Proxy (IAP) 遠端連線至 VM。IAP TCP 轉送功能可讓您建立加密通道。您可以使用通道將 SSH、RDP 和其他網際網路流量轉送至 VM,不必為 VM 指派公開 IP 位址。由於 IAP 服務的連線來自保留的公開 IP 位址範圍,因此您需要建立相符的 VPC 防火牆規則。如果您有 Windows 型 VM,且已開啟 Windows 防火牆,請確認 Windows 防火牆未設定為封鎖來自 IAP 的 RDP 連線。詳情請參閱「遠端桌面通訊協定疑難排解」一文。

流量負載平衡

如果您已在 AWS 環境中設定 Elastic Load Balancing (ELB),可以設定 Cloud Load Balancing 分散網路流量,進而提升 Google Cloud工作負載的可擴充性。Cloud Load Balancing 支援多種全域和區域負載平衡產品,可在OSI 模型的不同層級運作,例如傳輸層和應用程式層。您可以選擇負載平衡產品, 滿足工作負載的需求。

Cloud Load Balancing 也支援設定傳輸層安全標準 (TLS) 來加密網路流量。 為 Cloud Load Balancing 設定 TLS 時,您可以根據需求使用自行管理或 Google 代管的 TLS 憑證

DNS 名稱、區域和記錄

如果您在 AWS 環境中使用 Amazon Route 53,可以透過以下方式使用 Google Cloud:

舉例來說,如果您使用 Amazon Route 53 註冊網域,可以將網域註冊轉移至 Cloud Domains。同樣地,如果您使用 Amazon Route 53 設定公開和私人 DNS 區域,可以將該設定遷移至 Cloud DNS

DDoS 防護和網頁應用程式防火牆

如果您在 AWS 環境中設定了 AWS Shield 和 AWS WAF,可以使用 Google Cloud Armor 保護工作負載,防範 DDoS 攻擊和常見的漏洞利用。 Google Cloud

重構部署和營運程序

重構工作負載後,請重構部署和作業程序,以執行下列操作:

  • 在 Google Cloud 環境中佈建及設定資源,而不是在來源環境中佈建資源。
  • 建構及設定工作負載,並部署至 Google Cloud,而非部署至來源環境。

您已在本程序的評估階段收集這些程序的相關資訊。

您需要為這些程序考量的重構類型,取決於您設計及實作這些程序的方式。重構作業也取決於您希望每個程序最終達到什麼狀態。舉例來說,你可以嘗試下列做法:

  • 您可能已在來源環境中實作這些程序,並打算在 Google Cloud中設計及實作類似程序。舉例來說,您可以重構這些程序,改用 Cloud BuildCloud DeployInfrastructure Manager
  • 您可能已在來源環境以外的其他第三方環境中實作這些程序。在這種情況下,您需要重構這些程序,以 Google Cloud 環境為目標,而非來源環境。
  • 結合上述做法。

重構部署和作業程序可能相當複雜,需要投入大量心力。如果您嘗試在工作負載遷移期間執行這些工作,工作負載遷移作業可能會變得更加複雜,而且您可能會面臨風險。評估部署和作業程序後,您可能已瞭解這些程序的設計和複雜程度。如果您預估需要大量心力才能重構部署和作業程序,建議您考慮將這些程序重構作業納入獨立專案。

如要進一步瞭解如何在 Google Cloud上設計及實作部署程序,請參閱:

本文著重於部署程序,這些程序會產生要部署的構件,並將構件部署至目標執行階段環境。重構策略很大程度上取決於這些程序的複雜程度。以下列出可能的重構策略:

  1. 在 Google Cloud上佈建構件存放區。舉例來說,您可以使用 Artifact Registry 儲存構件和建構依附元件。
  2. 重構建構程序,將構件儲存在來源環境和 Artifact Registry 中。
  3. 重構部署程序,在目標Google Cloud 環境中部署工作負載。舉例來說,您可以先在 Google Cloud中部署一小部分工作負載,並使用儲存在 Artifact Registry 中的構件。然後逐步增加在 Google Cloud中部署的工作負載數量,直到所有要遷移的工作負載都在Google Cloud上執行為止。
  4. 重構建構程序,只將構件儲存在 Artifact Registry 中。
  5. 如有必要,請將舊版構件從來源環境的存放區遷移至 Artifact Registry,以便部署。例如,您可以將容器映像檔複製到 Artifact Registry。
  6. 不再需要來源環境中的存放區時,請將其停用。

為方便在遷移期間發生非預期問題時進行回溯,您可以在遷移至 Google Cloud 的過程中,將容器映像檔同時儲存在目前的構件存放區 Google Cloud 。最後,在來源環境停用程序中,您可以重構容器映像檔建構程序,只在Google Cloud 中儲存構件。

雖然這可能不是遷移作業成功的關鍵,但您可能需要將舊版構件從來源環境遷移至 Google Cloud的構件存放區。舉例來說,如要支援將工作負載回復至任意時間點,您可能需要將舊版構件遷移至 Artifact Registry。詳情請參閱「從第三方登錄檔遷移映像檔」。

如果您使用 Artifact Registry 儲存構件,建議您設定控管機制,確保構件存放區安全無虞,例如存取控管、防止資料外洩、漏洞掃描和二進位授權。詳情請參閱「控管存取權及保護構件」。

最佳化環境 Google Cloud

最佳化是遷移的最後階段。在這個階段,您會反覆執行最佳化工作,直到目標環境符合最佳化需求為止。每次疊代的步驟如下:

  1. 評估目前的環境、團隊和最佳化迴圈。
  2. 建立最佳化需求和目標。
  3. 最佳化環境和團隊。
  4. 調整最佳化迴圈。

重複這個程序,直到達成最佳化目標為止。

如要進一步瞭解如何最佳化 Google Cloud 環境,請參閱「遷移至 Google Cloud:最佳化環境」和「Google Cloud 架構完善的架構:效能最佳化」。

後續步驟

貢獻者

作者:Marco Ferrari | 雲端解決方案架構師