設計工作負載架構

Last reviewed 2024-07-24 UTC

本文可協助您設計工作負載,盡量減少日後擴充工作負載,以及將工作負載遷移至其他 Google Cloud 區域或跨區域遷移工作負載時的影響。如果您打算執行上述任何活動,或是正在評估未來執行的可能性,並想瞭解相關工作內容,這份文件都能提供實用的參考資料。

本文件是系列文章之一:

如果您事先未規劃跨區域遷移或擴展至多個區域,本系列指南也很有幫助。在這種情況下,您可能需要花費額外心力,為跨區域遷移作業和擴展至多個區域,準備基礎架構、工作負載和資料。

本文將協助您完成下列事項:

  1. 準備登陸區
  2. 準備將工作負載遷移至其他區域
  3. 準備運算資源
  4. 準備資料儲存資源
  5. 準備停用來源環境

準備登陸區

本節著重於跨區域遷移時,您必須考量的事項,以擴充登陸區 (也稱為雲端基礎)。

第一步是重新評估現有登陸區的各個層面。您必須先建立登陸區,才能遷移任何工作負載。雖然您可能已為代管工作負載的區域建立登陸區,但登陸區可能不支援在其他區域部署工作負載,因此必須擴展至目標區域。部分現有的登陸區可能採用某種設計,可支援其他區域,且不需要大幅修改登陸區 (例如身分和存取權管理或資源管理)。不過,網路或資料等其他因素可能需要您為擴充功能進行規劃。重新評估時,請考量工作負載的主要需求,以便設定一般基礎,並在遷移期間稍後進行專門設定。

企業考量

就產業和政府標準、法規和認證等層面而言,將工作負載移至其他區域可能會有不同的要求。在位於不同國家/地區的 Google 區域執行的工作負載,必須遵守該國家/地區的法律和法規。此外,不同產業標準可能對在國外執行的工作負載有特定要求 (尤其是安全性方面)。由於 Google Cloud 區域是為了在單一國家/地區執行資源而建構,有時為了遵守特定法規,工作負載會從其他 Google 區域遷移至該國家/地區。執行這些「國內」遷移作業時,請務必重新評估在內部部署環境中執行的資料,確認新區域是否允許將資料遷移至 Google Cloud。

身分與存取權管理

規劃遷移作業時,您可能不需要為已使用 Google Cloud的區域規劃許多身分和存取權變更。資源的身分決策和存取權通常取決於資源的性質,而非資源的執行區域。 Google Cloud 您可能需要考量以下事項:

  • 團隊設計:有些公司會安排不同團隊處理不同資源。工作負載遷移至其他區域時,由於資源結構有所變更,因此可能需要由其他團隊負責特定資源,這時就應相應調整存取權。
  • 命名慣例:雖然命名慣例可能不會對功能造成任何技術影響,但如果定義的資源命名慣例參照特定區域,則可能需要考慮。舉例來說,如果已有多個複製地區 (例如 Compute Engine 虛擬機器 (VM)),且這些地區是以地區為前置碼命名 (例如 europe-west1-backend-1),在遷移過程中,為避免混淆,或更糟的是,破壞依賴特定命名慣例的管道,請務必變更名稱以反映新區域。

連線與網路

網路設計會影響遷移作業的執行方式,因此請務必先解決這項設計問題,再規劃如何遷移工作負載。

請注意,與 Google Cloud 的地端連線是您在遷移時必須重新評估的因素之一,因為這類連線的設計可能與特定區域有關。其中一個例子是雲端互連,透過 VLAN 連結連線至特定區域的 Google Cloud 。您必須先變更 VLAN 連結的連線區域,再停用該區域,以免產生區域間流量。另一個考量因素是,如果您使用合作夥伴互連網路,遷移區域有助於選取不同的實體位置,將 VLAN 連結連線至該位置 Google Cloud。如果您使用 Cloud VPN,並決定在遷移作業中變更子網路位址,也必須重新設定路由器,以反映新的網路。

雖然 Google Cloud 上的虛擬私有雲 (VPC) 是全域資源,但單一子網路一律會繫結至區域,因此您無法在遷移後將同一子網路用於工作負載。由於子網路的 IP 不得重疊,如要保留相同位址,請建立新的 VPC。如果您使用 Cloud DNS,這個程序會簡化,因為 Cloud DNS 可以運用 DNS 對等互連等功能,在停用舊區域前,為遷移的工作負載轉送流量。

如要進一步瞭解如何以 Google Cloud為基礎建構應用程式,請參閱「遷移至 Google Cloud:規劃及建構基礎」。

準備將工作負載遷移至其他區域

無論您是在 Google Cloud 上設定基礎架構,並打算稍後遷移至其他區域,或已在 Google Cloud上,且需要遷移至其他區域,都必須確保工作負載能以最簡單的方式遷移,以減少工作量並降低風險。為確保所有工作負載都處於可遷移的狀態,建議您採取下列做法:

  • 偏好容易複製的網路設計,並與特定網路拓撲鬆散耦合。Google Cloud 提供多種產品,協助您將目前的網路設定與使用該網路的資源分離。這類產品的例子是 Cloud DNS,可讓您將內部子網路 IP 與 VM 解除連結。
  • 設定支援多區域或全域設定的產品。 如果產品支援涉及多個區域的設定,通常可簡化遷移至其他區域的程序。
  • 考慮使用代管服務,透過代管跨區域備用資源儲存資料。 如本文後續章節所述,部分受管理服務允許您在不同區域建立副本,通常是為了備份或高可用性。這項功能對於在不同區域之間遷移資料非常重要。

部分 Google Cloud 服務的設計宗旨是支援多區域部署全球部署。您不需要遷移這些服務,但可能需要調整部分設定。

準備運算資源

本節將概略說明 Google Cloud 的運算資源,以及為遷移至其他地區所做的設計原則。

本文件著重於下列 Google Cloud 運算產品:

Compute Engine

Compute Engine 是 Google Cloud的服務,可為客戶提供 VM。

如要將 Compute Engine 資源從一個區域遷移至另一個區域,除了網路考量外,您還必須評估各種因素。

建議您採取下列做法:

  • 檢查運算資源:變更 VM 的代管區域時,您可能會遇到的第一個限制是新目標區域的 CPU 平台可用性。如要在遷移期間變更機器系列,請確認目前 VM 的作業系統支援該系列。一般來說,這個問題會擴及所有 Google Cloud 運算服務 (部分新地區可能沒有 Cloud RunCloud GPU 等服務),因此在規劃遷移作業前,請務必確認目的地地區提供您所需的所有運算服務。
  • 設定負載平衡和調度資源:Compute Engine 支援在 Compute Engine 執行個體之間平衡流量,並根據需求自動從 MIG 新增或移除虛擬機器。建議您設定負載平衡和自動調度,提高環境的可靠性和彈性,避免自行管理解決方案的負擔。如要進一步瞭解如何設定 Compute Engine 的負載平衡和資源調度,請參閱「負載平衡和資源調度」。
  • 使用區域 DNS 名稱:為降低跨區域服務中斷的風險,建議您使用區域 DNS 名稱,在環境中透過 DNS 名稱識別虛擬機器。 Google Cloud 預設會為 Compute Engine 虛擬機器使用區域 DNS 名稱。如要進一步瞭解 Compute Engine 內部 DNS 的運作方式,請參閱內部 DNS 總覽。為方便日後跨區域遷移,並提升設定的可維護性,建議您將區域 DNS 名稱視為設定參數,以便日後變更。
  • 使用相同的代管執行個體群組 (MIG) 範本: Compute Engine 可讓您建立區域性 MIG, 自動在區域內的多個可用區中佈建虛擬機器。如果您在舊區域使用範本,可以在新區域使用相同範本部署 MIG。

GKE

Google Kubernetes Engine (GKE) 可協助您在 Kubernetes 上部署、管理及調度容器化工作負載。

如要準備遷移 GKE 工作負載,請考量下列設計要點和 GKE 功能:

  • Cloud Service Mesh: Istio 網格的代管實作。為叢集採用 Cloud Service Mesh,可讓您進一步控管叢集的網路流量。Cloud Service Mesh 的主要功能之一,是讓您在兩個叢集之間建立服務網格。您可以利用這項功能,在新的區域中建立 GKE 叢集並新增至服務網格,規劃從一個區域到另一個區域的遷移作業。使用這種方法,您可以在新叢集中開始部署工作負載,並逐步將流量導向這些工作負載,以便測試新部署項目,同時還能編輯網格路由來還原。
  • Config Sync: 這項 GitOps 服務以開放原始碼核心為基礎,可讓叢集操作人員和平台管理員從單一來源部署設定。Config Sync 可支援一或多個叢集,讓您使用單一可靠來源設定叢集。您可以使用這項 Config Sync 功能,將現有叢集的設定複製到新區域的叢集,並視需要為該區域自訂特定資源。
  • GKE 備份: 這項功能可讓您定期備份叢集永久資料,並將資料還原至相同或新的叢集。

Cloud Run

Cloud Run 提供輕量型方法,可在 Google Cloud上部署容器。Cloud Run 服務是區域資源,會複製到所在區域的多個可用區部署 Cloud Run 服務時,您可以選擇要部署執行個體的區域,然後使用這項功能在不同區域部署工作負載。

VMware Engine

Google Cloud VMware Engine 是一項全代管服務,可讓您在 Google Cloud執行 VMware 平台。VMware 環境會在Google Cloud 裸機基礎架構 Google Cloud 上以原生方式執行,包括 vSphere、vCenter、vSAN、NSX-T、HCX 和相應工具。

如要將 VMware Engine 執行個體遷移至其他地區,請在新地區建立私有雲,然後使用 VMware 工具移動執行個體。

規劃遷移作業時,也請將 Compute Engine 環境中的 DNS 和負載平衡納入考量。VMware Engine 使用 Google Cloud DNS,這項代管 DNS 託管服務可提供發布至公用網際網路的權威 DNS 託管服務、可供虛擬私有雲網路顯示的不公開區域,以及 DNS 轉送和對等互連,用於管理虛擬私有雲網路上的名稱解析。您的
遷移計畫可支援多區域負載平衡和 DNS 設定的測試。

準備資料儲存資源

本節將概述Google Cloud 上的資料儲存空間資源,以及準備遷移至其他區域的基本概念。

Google Cloud 上已有的資料可簡化遷移作業,因為這表示已有解決方案可代管這些資料,無須任何轉換,或可代管於 Google Cloud。

將資料庫資料複製到其他區域,並在其他位置還原資料,是災難復原 (DR) 的常見模式。因此,本文所述的部分模式會採用 DR 機制,例如資料庫備份與復原。

本文說明下列受管理服務:

本文假設您使用的儲存空間解決方案是與運算資源位於同一區域的執行個體。

Cloud Storage

Cloud Storage 提供 Storage 移轉服務,可自動將檔案從不同系統移轉至 Cloud Storage。可用於將資料複製到其他區域進行備份,也能用於區域間的遷移作業。

Cloud SQL

Cloud SQL 提供關聯式資料庫服務,可代管不同類型的資料庫。Cloud SQL 提供跨區域複寫功能,可將執行個體資料複寫到不同區域。這項功能是備份及還原 Cloud SQL 執行個體的常見模式,但您也可以將其他區域的第二個備用資源升級為主要備用資源。您可以使用這項功能在第二個區域建立唯讀副本,然後在遷移工作負載後,將其升級為主要副本。一般來說,對於資料庫,代管服務可簡化資料複寫程序,方便您在遷移期間於新區域建立副本。

您也可以使用資料庫移轉服務處理遷移作業,將不同來源的 SQL 資料庫遷移至 Google Cloud。支援的來源也包括其他 Cloud SQL 執行個體,但只能移轉至不同區域,無法移轉至不同專案。

Filestore

如本文稍早所述,Filestore 的備份與還原功能可讓您建立檔案共用的備份,並還原至其他區域。這項功能可用於執行區域對區域遷移。

Bigtable

Cloud SQL 相同,Bigtable 支援複製。您可以使用這項功能,複製上述模式。請查看Bigtable 位置清單,確認服務是否適用於目標區域。

此外,與 Filestore 相同,Bigtable 也支援備份和還原。與 Filestore 相同,您可以使用這項功能建立備份,並在新區域的其他執行個體中還原備份,藉此實作遷移作業。

最後一個選項是匯出資料表,例如匯出至 Cloud Storage。這些匯出作業會將資料存放在其他服務中,然後即可匯入區域中的執行個體。

Firestore

Firestore 位置可能與專案中的 App Engine 存在關聯,在某些情況下,Firestore 執行個體會強制設為多區域。在這些遷移情境中,也必須將 App Engine 納入考量,才能為 Firestore 設計合適的解決方案。事實上,如果您已有 App Engine 應用程式,且位置為 us-central
europe-west,Firestore 資料庫就會視為多區域。

如果您使用區域位置,並想遷移至其他位置,可以透過代管匯出與匯入服務,使用 Cloud Storage 值區匯入及匯出 Firestore 實體。這個方法可用於將執行個體從一個區域移至另一個區域。另一個選項是使用 Firestore 備份與還原功能。相較於匯入及匯出,這個選項的費用較低,也更簡單明瞭。

準備停用來源環境

您必須先做好準備,才能停用來源環境並切換至新環境。

整體來說,在停用來源環境前,請先考量下列事項:

  • 新環境測試:將流量從舊環境切換到新環境前,您可以先進行測試,驗證應用程式是否正確。除了可對新遷移的應用程式進行傳統單元和整合測試外,還有不同的測試策略。新環境可視為軟體的新版本,流量遷移作業則可透過常見模式 (例如用於驗證的 A/B 測試) 實作。另一種做法是在來源環境和新環境中複製傳入流量,檢查函式是否保留。
  • 規劃停機時間:如果您選取藍綠遷移等遷移策略,將流量從一個環境切換至另一個環境,請考慮採用計畫性停機時間。停機時間可讓您更妥善地監控轉換作業,並避免用戶端發生無法預測的錯誤。
  • 回溯:視採用的流量遷移策略而定,如果新環境發生錯誤或設定錯誤,可能需要實作回溯。如要回溯環境,您必須先建立監控基礎架構,偵測新環境的狀態。

您必須先在新區域進行擴充測試,並在新區域上線且沒有錯誤,才能關閉第一個區域的服務。建議您在確定新遷移的區域沒有問題前,先保留第一個區域的備份一段時間。

此外,如果沒有現成的解決方案,您也應考慮是否要將舊區域升級為災難復原網站。這種做法需要額外設計,才能確保網站穩定可靠。如要進一步瞭解如何正確設計及規劃 DR,請參閱「災難復原規劃指南」。

後續步驟

貢獻者

作者:Valerio Ponza | 技術解決方案顧問

其他貢獻者: