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

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

本文是登陸區系列文章之一。

選擇網路設計

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

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

網路設計的決策點

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

網路設計決策。

上圖會引導您思考下列問題：

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

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

網路設計選項

以下各節說明四種常見的設計選項。我們建議在大多數情況下使用選項 1。本節討論的其他設計是替代方案，適用於特定機構的特殊情況需求。

最適合您用途的網路，也可能結合本節討論的多個設計選項元素。舉例來說，您可以在軸輻式拓撲中使用共用虛擬私有雲網路，以利協作、集中控管，並限制虛擬私有雲輻射網路的數量。或者，您可能會在共用虛擬私有雲拓撲中設計大部分工作負載，但將少數工作負載隔離在個別虛擬私有雲網路中，只透過使用 Private Service Connect 的幾個已定義端點公開服務。

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

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

符合下列條件時，請使用這個設計：

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

如果符合下列條件，請避免採用這種設計：

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

下圖為這項設計的實作範例。

選項 1 的示意圖。

上圖顯示下列項目：

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

根據設計，一個環境的流量無法抵達另一個環境。不過，如果特定工作負載必須彼此通訊，您可以在地端透過受控管道允許資料傳輸，也可以使用 Cloud Storage 或 Pub/Sub 等服務在應用程式之間共用資料。 Google Cloud 建議您避免透過 VPC 網路對等互連直接連結不同的環境，因為這樣會增加環境間資料意外混用的風險。在大型環境之間使用虛擬私有雲網路對等互連，也會增加達到對等互連和對等互連群組虛擬私有雲配額的風險。

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

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

選項 2：中樞輻射拓撲，搭配集中式設備

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

符合下列條件時，請使用這個設計：

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

如果符合下列條件，請避免採用這種設計：

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

下圖顯示這個模式的實作範例。

選項 2 圖表。

上圖顯示下列項目：

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

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

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

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

在這個設計中，我們建議您使用虛擬私有雲網路對等互連，連結中樞虛擬私有雲網路和輻射虛擬私有雲網路，因為這樣可將複雜度降到最低。不過，輪輻數量上限會受到下列因素限制：

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

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

如要實作這個設計選項，請參閱「建立選項 2：採用集中式裝置的輪輻拓撲」。

選項 3：不含設備的輻射型拓撲

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

符合下列條件時，請使用這個設計：

  • 您希望 Google Cloud 中的工作負載或環境完全不要使用內部 IP 位址互相通訊，但希望這些工作負載或環境共用內部部署連線。
  • 您希望團隊能自主管理自己的防火牆和路由規則。

如果符合下列條件，請避免採用這種設計：

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

下圖為這項設計的實作範例。

選項 3 圖表。

上圖顯示下列項目：

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

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

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

因此，如果大型機構在 Google Cloud上有許多獨立工作負載，通常不會採用這種設計。

您也可以使用 Cloud VPN，取代虛擬私有雲網路對等互連。Cloud VPN 可讓您增加輪輻數量，但會限制每個通道的頻寬，並增加複雜度和成本。使用自訂公告路徑時，Cloud VPN 也允許輻射網路之間的遞移性，不必直接連線所有輻射網路。

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

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

選項 4：在消費者/生產者模型中，透過 Private Service Connect 公開服務

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

符合下列條件時，請使用這個設計：

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

如果符合下列條件，請避免採用這種設計：

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

下圖顯示這個模式的實作範例。

選項 4 的圖表。

上圖顯示下列項目：

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

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

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

網路部署最佳做法

為您的用途選擇最佳網路設計後，建議您採用下列最佳做法：

詳情請參閱「虛擬私有雲設計的最佳做法與參考架構」。

後續步驟