決定 Google Cloud 登陸區的網路設計

Last reviewed 2024-10-31 UTC

設計登陸區時，您必須選擇適合貴機構的網路設計。本文件說明四種常見的網路設計，協助您選擇最符合貴機構需求的選項，以及貴機構偏好的集中式或分散式控管方式。本文適用於為貴機構的指定區域建立網路設計的網路工程師、架構師和技術實務人員。

本文是一系列登陸頁面的系列文章之一。

選擇網路設計

您選擇的網路設計主要取決於下列因素：

  • 集中或分散式控管：視貴機構偏好設定而定，請選擇下列其中一種：
    • 集中控管網路，包括不同工作負載之間的 IP 位址、路由和防火牆。
    • 讓團隊享有更大的自主權，自行執行環境，並在各自的環境中建構網路元素。
  • 內部部署或混合雲連線選項：本文討論的所有網路設計，均可透過 Cloud VPN 或 Cloud Interconnect，提供從內部部署存取雲端環境的連線。不過，某些設計需要同時設定多個連線，而其他設計則會為所有工作負載使用相同的連線。
  • 安全性規定：貴機構可能需要在 Google Cloud 中，將不同工作負載之間的流量傳送至集中式網路設備，例如下一代防火牆 (NGFW)。這項限制會影響您的虛擬私有雲 (VPC) 網路設計。
  • 擴充性：根據您要部署的工作負載數量，以及虛擬機器 (VM)、內部負載平衡器和其他資源的數量，某些設計可能比其他設計更適合貴機構。

網路設計的決策點

下列流程圖顯示您必須做出的決策，才能為貴機構選擇最佳網路設計。

網路設計的決策。

上圖會引導您回答下列問題：

  1. 您是否需要在Google Cloud的不同工作負載之間使用網路設備進行第 7 層檢查？
  2. 您的許多工作負載是否需要地端連線？
    • 如果有，請前往決策點 4。
    • 如果沒有，請繼續進行下一個問題。
  3. 您的工作負載是否可以在服務供應者和消費者模型中，使用私人端點進行通訊？
  4. 您是否想集中管理防火牆和路由？

這張圖表旨在協助您做出決策，但通常情況下，多個設計都可能適合貴機構。在這些情況下，建議您選擇最適合用途的設計。

網路設計選項

以下各節將說明四種常見的設計選項。我們建議在大多數用途中採用選項 1。本節所討論的其他設計是適用於特定組織邊緣案例需求的替代方案。

最適合您用途的網路也許是結合本節所述多種設計選項的元素。舉例來說，您可以在軸輻式結構中使用共用虛擬私有雲網路，以便進行更佳的協作、集中控管，並限制 VPC 輻射線的數量。或者，您也可以在共用虛擬私有雲拓樸中設計大部分工作負載，但將少數工作負載隔離在不同的虛擬私有雲網路中，這些工作負載只會透過少數已定義的端點，使用 Private Service Connect 公開服務。

選項 1：為每個環境建立共用虛擬私有雲網路

我們建議在大多數用途中採用這類網路設計。此設計會針對您在Google Cloud 中建立的每個部署環境(開發、測試和實際工作環境) 使用個別的共用虛擬私有雲網路。這項設計可讓您集中管理通用網路中的網路資源，並在不同環境之間提供網路隔離功能。

在下列情況下使用這項設計：

  • 您希望集中控管防火牆和路由規則。
  • 您需要簡單且可擴充的基礎架構。
  • 您需要集中式 IP 位址空間管理。

在下列情況下，請避免採用這項設計：

  • 您希望開發團隊擁有完全自主權，包括管理自己的防火牆規則、路由，以及與其他團隊網路建立對等連線的權限。
  • 您需要使用 NGFW 設備進行第 7 層檢查。

下圖為此設計的實作範例。

選項 1 圖表。

上圖顯示以下內容：

  • 內部部署網路分布在兩個地理區域。
  • 內部部署網路會透過備援 Cloud Interconnect 執行個體連線至兩個獨立的共用虛擬私有雲網路，一個用於實際工作環境，另一個用於開發環境。
  • 實際工作環境和開發環境會透過不同的VLAN 連結連結至兩個 Cloud Interconnect 執行個體。
  • 每個共用虛擬私有雲都有服務專案，用於代管工作負載。
  • 防火牆規則會在主專案中集中管理。
  • 開發環境的 VPC 結構與實際工作環境相同。

根據設計，一個環境的流量無法到達另一個環境。不過，如果特定工作負載必須彼此通訊，您可以允許資料透過受控的內部部署管道進行轉移，或是透過 Google Cloud 服務 (例如 Cloud Storage 或 Pub/Sub) 在應用程式之間分享資料。建議您避免直接透過 VPC 網路配對連線至分隔環境，因為這會增加在兩個環境之間意外混淆資料的風險。在大型環境之間使用虛擬私人雲端網路對等互連功能，也會增加在對等互連和對等互連群組中達到虛擬私人雲端網路配額的風險。

如要瞭解詳情，請參考下列資源：

如要實作這個設計選項，請參閱「建立選項 1：為每個環境建立共用虛擬私有雲網路」一文。

選項 2：使用集中式裝置的輻射狀拓撲

這項網路設計採用軸輻式拓撲。軸心 VPC 網路包含一組設備 VM (例如 NGFW)，這些設備 VM 會連線至包含工作負載的輻射狀 VPC 網路。工作負載、內部部署網路或網際網路之間的流量會透過設備 VM 轉送，以便進行檢查和篩選。

在下列情況下使用這項設計：

  • 您需要在不同工作負載或應用程式之間進行第 7 層檢查。
  • 您有公司規定，指定所有流量的安全性設備供應商。

在下列情況下，請避免採用這項設計：

  • 您不需要為大部分工作負載啟用第 7 層檢查。
  • 您希望 Google Cloud 上的工作負載完全不互相通訊。
  • 您只需要針對前往內部網路的流量進行第 7 層檢查。

下圖為此模式的實作範例。

選項 2 圖表。

上圖顯示以下內容：

  • 實際工作環境，其中包含中樞虛擬私有雲網路和多個輪輻虛擬私有雲網路，其中包含工作負載。
  • 輪輻 VPC 網路會透過虛擬私有雲網路對等互連連線至中樞 VPC 網路。
  • 中樞虛擬私有雲網路在受控執行個體群組中有多個虛擬機器設備執行個體。傳送至受管理執行個體群組的流量會經過內部直通式網路負載平衡器。
  • 輻射狀 VPC 網路會透過虛擬設備，使用內部負載平衡器做為下一個躍點的靜態路徑互相通訊。
  • Cloud Interconnect 會將傳遞虛擬私有雲端網路連線至內部部署位置。
  • 內部部署網路會透過相同的 Cloud Interconnect 連結，使用不同的 VLAN 連結。
  • 傳輸虛擬私有雲網路會連線至虛擬設備上的個別網路介面，讓您使用設備檢查及篩選所有傳入和傳出這些網路的流量。
  • 開發環境的 VPC 結構與實際工作環境相同。
  • 這項設定不會使用來源網路位址轉譯 (SNAT)。 Google Cloud 使用對稱雜湊，因此不需要 SNAT。詳情請參閱「對稱雜湊」。

根據設計，來自一個輪輻網路的流量無法抵達另一個輪輻網路。不過，如果特定工作負載必須彼此通訊，您可以使用虛擬私有雲網路對等互連，在輻射網路之間設定直接對等互連，也可以透過 Cloud Storage 或 Pub/Sub 等 Google Cloud 服務，在應用程式之間共用資料。

為確保機器在工作負載之間通訊時維持低延遲，機器必須位於與工作負載相同的地區。如果您在雲端部署中使用多個區域，則可為每個區域的每個環境建立一組裝置和一個中樞 VPC。或者，您也可以使用路徑中的網路標記，讓所有執行個體與最近的裝置通訊。

防火牆規則可限制包含工作負載的輻射狀虛擬私有雲網路中的連線。管理工作負載的團隊通常也會管理這些防火牆規則。如要使用集中式政策，您可以使用階層式防火牆政策。如果您需要讓中央網路團隊完全控管防火牆規則，請考慮使用 GitOps 方法，在所有 VPC 網路中集中部署這些規則。在這種情況下，請將 IAM 權限限制為僅限可變更防火牆規則的管理員。如果有多個團隊在輻射狀結構中部署，輻射狀虛擬私有雲網路也可以是共用虛擬私有雲網路。

在這個設計中，我們建議您使用 VPC 網路對等互連連線樞紐 VPC 網路和輻射 VPC 網路，因為這樣可降低複雜度。不過，輻條的數量上限受下列因素限制：

  • 來自單一虛擬私人雲端網路的VPC 網路對等互連連線 數量限制。
  • 對等互連群組限制，例如每個對等互連群組內部 TCP/UDP 負載平衡的轉送規則數量上限。

如果您預期會達到這些上限，可以透過 Cloud VPN 連線至輻射狀網路。使用 Cloud VPN 會增加額外成本和複雜度，且每個 Cloud VPN 通道都有頻寬限制。

如要瞭解詳情，請參考下列資源：

如要實作這項設計選項，請參閱「建立選項 2：使用集中式裝置的輻射狀拓撲」一文。

選項 3：不含裝置的樞紐式拓撲

這個網路設計也採用軸輻式拓撲，其中軸 VPC 網路會連線至內部部署網路，而輻 VPC 網路則包含工作負載。由於虛擬私有雲網路對等互連無法遞移，因此輪輻網路無法直接互相通訊。

在下列情況下使用這項設計：

  • 您希望工作負載或環境 Google Cloud 不要使用內部 IP 位址互相通訊，但希望它們共用內部部署連線。
  • 您想讓團隊自行管理防火牆和路由規則。

在下列情況下，請避免採用這項設計：

  • 您需要在工作負載之間進行第 7 層檢查。
  • 您希望集中管理路由和防火牆規則。
  • 您需要從地端部署服務到透過其他虛擬私有雲網路對等互連連線至輪輻的代管服務的通訊，因為虛擬私有雲網路對等互連不是遞移的。

下圖為此設計的實作範例。

選項 3 圖表。

上圖顯示以下內容：

  • 實際工作環境，其中包含中樞虛擬私有雲網路和多個輪輻虛擬私有雲網路，其中包含工作負載。
  • 輪輻 VPC 網路會透過虛擬私有雲網路對等互連連線至中樞 VPC 網路。
  • 連線至內部部署位置會經過中樞 VPC 網路中的 Cloud Interconnect 連線。
  • 內部部署網路會透過不同的 VLAN 連結連線至 Cloud Interconnect 執行個體。
  • 開發環境的虛擬私有雲端網路結構與實際工作環境相同。

根據設計，來自一個輪輻網路的流量無法到達另一個輪輻網路。不過，如果特定工作負載必須彼此通訊，您可以使用虛擬私有雲網路對等互連，在輻射網路之間設定直接對等互連，也可以透過 Cloud Storage 或 Pub/Sub 等 Google Cloud 服務，在應用程式之間共用資料。

這種網路設計通常用於團隊自主運作且沒有集中控管防火牆和路由規則的環境。不過，這項設計的規模受到下列限制：

因此，這項設計通常不適用於在 Google Cloud上有許多個別工作負載的大型機構。

您可以使用 Cloud VPN 取代虛擬私有雲網路對等互連，這也是設計的變化版本。Cloud VPN 可讓您增加輻條數量，但會為每個通道新增頻寬限制，並增加複雜性和成本。使用自訂公告路徑時，Cloud VPN 也會允許輻射點之間的轉接，而不需要直接連結所有輻射點網路。

如要瞭解詳情，請參考下列資源：

如要實作這個設計選項，請參閱「建立選項 3：不含裝置的樞紐輻射拓撲」一文。

選項 4：使用 Private Service Connect 在消費者-生產端模式中公開服務

在這個網路設計中，每個團隊或工作負載都會取得自己的 VPC 網路，這也可能是共用虛擬私人雲端網路。每個虛擬私有雲網路都會獨立管理，並使用 Private Service Connect 公開需要從虛擬私有雲網路外部存取的所有服務。

在下列情況下使用這項設計：

  • 工作負載只會透過定義的端點彼此通訊，以及與內部環境通訊。
  • 您希望各團隊彼此獨立，並自行管理各自的 IP 位址空間、防火牆和路由規則。

在下列情況下，請避免採用這項設計：

  • 服務和應用程式之間的通訊會使用許多不同的通訊埠或管道，或是經常變更通訊埠和管道。
  • 工作負載之間的通訊會使用 TCP 或 UDP 以外的通訊協定。
  • 您需要在工作負載之間進行第 7 層檢查。

下圖為此模式的實作範例。

選項 4 圖表。

上圖顯示以下內容：

  • 個別工作負載位於不同的專案和虛擬私有雲網路中。
  • 一個 VPC 網路中的用戶端 VM 可以透過 Private Service Connect 端點連線至另一個 VPC 網路中的工作負載。
  • 端點會連結至服務所在的 VPC 網路中的服務連結。如果端點已設定為全域存取，服務附件可能會位於與端點不同的區域。
  • 服務連結會透過 Cloud Load Balancing 連線至工作負載。
  • 工作負載虛擬私有雲中的用戶端可以存取位於地端的工作負載，如下所示：
    • 端點會連線至轉接 VPC 網路中的服務連結。
    • 服務附件會透過 Cloud Interconnect 連線至內部部署網路。
  • 內部應用程式負載平衡器會連結至服務附件，並使用混合網路端點群組，在內部端點之間平衡流量負載。
  • 地端用戶端也可以存取轉接虛擬私有雲網路中的端點，這些端點會連線至工作負載虛擬私有雲網路中的服務連結。

如要瞭解詳情，請參考下列資源：

如要實作這個設計選項，請參閱「建立選項 4：使用 Private Service Connect 在消費者-生產者模型中公開服務」。

網路部署最佳做法

選擇最適合用途的最佳網路設計後，建議您實施下列最佳做法：

如需更多資訊，請參閱「虛擬私人雲端設計的最佳做法與參考架構」。

後續步驟