Landing Zone常見的網路架構規劃 | Google Cloud

前言

在著陸區(Landing Zone)在規劃時，在上一篇文章[1]的網路架構分享是以Shared VPC為例，但是在現實生活中，總是有各種前人留下的歷史共業或公司規範、作業考量而不能使用Shared VPC來集中管理雲端環境的網路架構。

因此常見的網路架構設計主要取決於以下因素:

• 集中或分散控制: 您要選擇下列選項之一，視您組織的偏好而定:
• • 集中控制：對IP位址、不同工作負載之間的路由和防火牆實施集中控制。
  • 分散控制：讓您的團隊在營運自己的環境和構建環境內網路元素時，有更大的自主權。
• 地端或混合雲連接選項: 本文件中討論的所有網路設計都通過Cloud VPN或Cloud Interconnect從地端提供對雲端環境的訪問。但是，一些網路架構設計要求您並行設置多個連接，而另一些設計使用相同的連接。
• 安全要求: 您的組織可能要求Google Cloud中的流量都先通過集中式網路設備[2](次世代防火牆、入侵偵測系統/入侵防禦系統（IDS/IPS）、Web 應用程式防火牆 (WAF)…等)。
• • 此關於安全要求的約束也會影響您的VPC的網路設計。
• 可擴展性: 基於您要部署的工作負載數量以及它們將消耗的虛擬機器(VM)、內部負載平衡器和其他資源的數量，某些設計架構可能更適合您的組織。

以下是google提供的決策樹，依照需求區分成四種不同最常見的網路架構：

架構一：Shared VPC network for each environment

大多數使用案例都可以此網路架構。

此設計為您在 Google Cloud 中的每個部署環境(開發、測試和生產)使用獨立的Shared VPC[3]網路。您會新增一個Host projects(Shared VPC)的VPC切出子網，分享給其他Service project(服務)的專案使用，這種設計使您可以集中管理網路資源，並確保在不同環境之間提供網路隔離。

當符合以下情況時使用此設計:

• 您想要集中控制防火牆和路由規則。
• 您需要簡單、可擴展的基礎設施。
• 您需要集中式的IP 位址管理(以便切割不同部門的權限，研發部門不會擁有網路相關權限)。

當符合以下情況時應避免使用此設計:

• 您希望開發團隊擁有完全的自主權，包括管理自己的防火牆規則、路由和對等其他團隊網路的能力。
• 您需要使用次世代防火牆設備的第7層檢測。

左圖範例展示了以下內容:

• 內部網路橫跨兩個地理位置。
• 內部網路透過冗餘的Cloud Interconnect連接至兩個獨立的Shared VPC，一個用於生產環境，另一個用於開發環境。
• 生產和開發環境都使用不同的VLAN attachments連接到兩個Cloud Interconnect。
• 每個Shared VPC都有service projects來部署工作負載。
• 防火牆規則在host project中進行集中管理。
• 開發環境與生產環境具有相同的VPC結構。

架構注意事項：Shared VPC network for each environment

1. 根據設計，來自不同VPC的分支網路無法互相通信。
2. 不過，如果特定工作負載必須相互通信，您可以透過地端controlled channels傳輸數據，也可以使用 Cloud Storage或 Pub/Sub等在應用程式之間共享數據。
3. 避免透過 VPC Network Peering 直接連接分離的環境，因為這會增加環境之間意外混合資料的風險。

架構二：Hub-and-spoke topology with centralized appliances

此網路架構使用中心(hub)-輻射(spoke)拓撲結構。架構中的中心網路包含一組連接到輻射網路的網路虛擬設備(appliance VMs, 例如次世代防火牆)，在輻射網路中會包含組織內的工作負載。

工作負載、內部部署網路或互聯網之間的流量會經過虛擬設備進行檢測和過濾。

當符合以下情況時使用此設計:

• 需要在不同的工作負載或應用程序之間進行第7層流量檢測。
• 有公司指定的安全設備供應商處理所有流量。

當符合以下情況時應避免使用此設計:

• 大多數工作負載不需要第7層流量檢測。
• 希望 Google Cloud 上的工作負載之間不進行通訊
• 您只需要對流向地端網路的流量進行第 7 層檢查。

左圖範例展示了以下內容:

• 一個生產環境包括一個hub VPC網路和多個spoke VPC網路，這些spoke VPC網路中部署了企業的工作負載。
• spoke VPC網路透過VPC Network Peering與hub VPC網路相連。
• hub VPC網路在managed instance group中有多個虛擬設備。流向managed instance group的流量從內部到達Load Balancer。

• Cloud Interconnect將 transit VPC網路連接到企業內部。
• 地端網路使用單獨的 VLAN attachments 連線透過相同的Cloud Interconnects進行連線。
• 中轉VPC網路連接到虛擬設備上的單獨網路接口，這使您可以使用設備檢測和過濾到和來自這些網路的所有流量。
• 開發環境使用和生產環境相同的網路結構。
• 此設置不使用源網路位址轉換(source network address translation, SNAT)。由於 Google Cloud 使用Symmetric hashing[4]，所以不需要 SNAT。。

架構注意事項：Hub-and-spoke topology with centralized appliances

1. 根據設計，來自不同VPC的分支網路無法互相通信。 不過，您可以使用VPC Network Peering在分支網路(spoke networks)之間設定直接對等互連，也可以使用Cloud Storage或Pub/Sub等讓應用程式之間可以共用資料。
2. 為了在虛擬設備在工作負載之間通訊時保持低延遲，虛擬設備盡量與工作負載位於同一區域。
3. 防火牆規則可以限制包含工作負載的分支網路(spoke networks)內的連線。對於中央防火牆規則，您可以使用Hierarchical firewall policies[5]。
4. 在此架構中，建議使用 VPC Network Peering 來連接中心網路(hub VPC)和分支網路(spoke VPC)，因為VPC Network Peering增加最小的架構複雜性。
5. 分支網路(spoke VPC)的最大數量受到以下限制：

• • 每個VPC網路的 VPC Network Peering connections 的數量限制(default:25個)。
  • internal TCP/UDP Load Balancing的forwarding rules的最大數量

6. 如果預計會達到上述限制，您可以透過 Cloud VPN 連接分支網路(spoke VPC)。 但使用 Cloud VPN 會增加額外的成本和複雜性，每個Cloud VPN tunnel 也有頻寬限制。

架構三：Hub-and-spoke topology without appliances

此網路設計也使用中心(hub)-輻射(spoke)拓撲結構，中心網路(hub VPC)直接和地端網路下相連，工作負載一樣部署於輻射網路(spoke VPC)。流量不會經過網路虛擬設備進行檢測和過濾。

由於 VPC Network Peering是無法遞移(non-transitive)的，所以輻射網路之間不能直接相互通信。

non-transitive:
如果VPC A和VPC Ｂ建立了VPC Network Peering， 因此VPC A和VPC Ｂ的運算資源可以互相連接，此時VPC Ｂ和VPC C建立了VPC Network Peering，雖然VPC Ｂ和VPC C的運算資源可以互相連接，但是VPC A和VPC Ｃ無法直接透過VPC Ｂ互相連接。

當符合以下情況時使用此設計:

• 希望 Google Cloud 上的工作負載或環境完全不使用內部 IP 地址相互通信，但希望它們共用與地端網路的連線。
• 希望讓團隊自主管理自己的防火牆和路由規則。

當符合以下情況時應避免使用此設計:

• 工作負載的流量需要進行第7層檢測。
• 希望集中管理路由和防火牆規則。
• 希望來自地端服務的流量可以在對輻射網路之間的受託管服務相互通信。

左圖範例展示了以下內容:

• 生產環境包括一個中心網路(hub VPC)和多個輻射網路(spoke networks)，這些輻射 VPC 中包含工作負載。
• 輻射網路(spoke networks)通過 VPC Network Peering 與中心網路(hub VPC)相連。
• 到地端的連接透過Cloud Interconnect和中心網路(hub VPC)相連。
• 開發環境與生產環境具有相同的架構。

架構注意事項：Hub-and-spoke topology without appliances

1. 根據設計，來自不同VPC的分支網路無法互相通信。 不過，您可以使用VPC Network Peering在分支網路(spoke networks)之間設定直接對等互連，也可以使用Cloud Storage或Pub/Sub等讓應用程式之間可以共用資料。
2. 這種網路架構通常用於團隊自主行動且對防火牆和路由規則沒有集中控制的環境。
3. 然而，該設計的規模受到以下限制：

• • 每個VPC網路的 VPC Network Peering connections 的數量限制(default:25個)。
  • Network Load Balancer的forwarding rules的最大數量

因此，這種設計通常不適用擁有許多獨立工作負載的大型組織。

作為設計架構的變體，您可以使用 Cloud VPN 來取代 VPC 網路對等互連。 Cloud VPN 可讓您增加spoke networks數量，但會增加每個Cloud VPN tunnel的頻寬限制，並增加複雜性和成本。

架構四：Expose services in a consumer-producer model with Private Service Connect

在此網路設計中，每個團隊或工作負載都擁有自己的 VPC 網路。每個 VPC 網路都是獨立管理的，並使用 Private Service Connect 公開所有需要從VPC網路外部訪問的服務。

當符合以下情況時使用此設計:

• 工作負載只通過定義的端點與彼此和內部部署環境進行通信。
• 希望團隊之間的環境相互獨立並自行管理自己的 IP 位址空間、防火牆和路由規則。

當符合以下情況時應避免使用此設計:

• 服務和應用程式之間的通信使用許多不同的ports或channels。
• 工作負載之間的通信使用 TCP 或 UDP 以外的協議。
• 需要在工作負載之間進行第7層流量檢測。

上圖範例展示了以下內容:

• 獨立的工作負載位於各自獨立的項目和 VPC 網路中。
• 一個 VPC 網路中的client-side虛擬機可以通過 Private Service Connect endpoint[6]連接到另一個 VPC 網路中的工作負載。
• Private Service Connect endpoint連接到服務所在 VPC 網路中的service attachment[6]。
• service attachment通過Cloud Load Balancing連接到工作負載。
• client-side虛擬機可以透過以下方式訪問地端網路位置的工作負載:
• • Private Service Connect endpoint到中轉網路(Transit VPC)中的service attachment。
  • service attachment 使用 Cloud Interconnect 連接到地端網路。
• 地端網路client-side虛擬機也可以訪問中轉網路(Transit VPC)中的endpoint，這些Private Service Connect endpoint連接到工作負載 VPC 網路中的service attachment。

網路架構部署時的最佳實踐

1. 使用custom mode VPC networks 並刪除 default 網路，以避免與地端的網路產生 IP overlapping的狀況。
2. 對需要存取外網的資源使用 Cloud NAT 來限制外部的訪問，並減少使用public IP。
3. 使用 Cloud Interconnect，請確保遵循non-critical 或 production-level applications的建議配置，使用冗餘的架構來滿足服務的 SLA。
4. • 也可以透過 Cloud VPN 達到冗餘。
4. 透過使用organization policy[8]限制從 VPC 對外網的直接訪問。
5. 使用hierarchical firewall policies[9]在organization-level或folder-level繼承一致的組織防火牆策略。
6. 遵循地端網路和 Google Cloud 之間 hybrid DNS 的 DNS 最佳實踐[10]。

結語

和第一篇[1]提到的Landing Zone相似，除了Landing Zone是動態的之外，在設計網路架構時也是動態且可調整的，通常會依據組織的文化、地端的環境、預算的考量、搬遷到雲的工作負載...等而有所不同，組織在規劃上雲實踐Landing Zone時還是要參考專家的建議或是尋求partner/原廠的協助喔!!

如果你喜歡這篇文章歡迎幫我按愛心鼓勵一下喔!~閱讀愉快!~

延伸閱讀

相關連結

[1] https://vocus.cc/article/6555cd53fd897800010afc7b

[2] https://cloud.google.com/architecture/architecture-centralized-network-appliances-on-google-cloud#:~:text=Typical%20use%20cases%20for%20virtual%20appliances%20that%20traffic%20is%20routed%20through%20include%20the%20following%3A

[3] https://cloud.google.com/vpc/docs/shared-vpc

[4] https://cloud.google.com/load-balancing/docs/internal/ilb-next-hop-overview#symmetric-hashing

[5] https://cloud.google.com/firewall/docs/firewall-policies

[6] https://cloud.google.com/vpc/docs/configure-private-service-connect-producer

[7] https://cloud.google.com/architecture/best-practices-vpc-design#custom-mode

[8]https://cloud.google.com/architecture/landing-zones/implement-network-design#limit_external_access_by_using_an_organization_policy

[9] https://cloud.google.com/firewall/docs/firewall-policies

[10]https://cloud.google.com/dns/docs/best-practices

[11] https://cloud.google.com/architecture/landing-zones/decide-network-design#best_practices_for_network_deployment