使用者VPC網絡資源規劃

1. VPC概述

專有網絡VPC可以幫助使用者基于阿裡雲建構出一個隔離的雲上網絡環境，并可以自定義IP 位址範圍、不同網段、路由表和網關等。此外，也可以通過專線連接配接方式實作雲上VPC與傳統IDC的互聯，建構混合雲業務。基于以上VPC的優秀特性，使用者可以通過點選滑鼠等簡單操作，一分鐘内便可“傳遞”一整套網絡平台，大大節約使用者網絡基礎設施建設的成本和時間。

2. VPC規劃背景

對于專有網絡VPC，使用者可以完全掌握自己的虛拟網絡資源的管理和操作，結合使用者業務實際場景進行建立。然而，當使用者在專有雲上根據資源申請規範建立VPC執行個體時，有時對建立平台資源的容量和使用者自身業務的聯系比較模糊，進而産生種種疑問。例如某使用者考慮業務上雲前，需要建立多少個VPC？每個VPC建立多少個vswitch？每個VPC建立需要使用多少個位址段？VPC網絡内資源能被哪些網絡通路？該預留多少資源為未來的業務拓展做準備等一些問題。

反之，如不考慮規劃環節，直接建立或許能短期确實能解決當時的使用者業務需求，但随着使用者業務的開拓和發展，業務通路的流量不斷加大，業務資料量逐漸增加，雲資源飽和等問題會逐漸顯現。針對這些問題，要麼删除重建，要麼業務系統遷移，而且在解決過程中仍需考慮業務資料遷移的穩定性和安全性，時時刻刻保障業務在不中斷不故障的情況下正常運作。種種問題追根溯源是當初規劃設計不合理，導緻重複的工作量或風險，最終發出一聲早知如此何必當初的感歎。

總而言之，良性的資源規劃能讓使用者業務和平台系統更加穩固，運作更加長遠和高效。非良性的資源規劃，後期發生種種的大小問題隻是機率問題。是以我們要用架構師的思維意識去思考，去解決萬事“開頭”的問題，即首次規劃的問題。

本篇文章旨在介紹VPC建立執行個體資源前的規劃與評估，貼合使用者自身業務場景，進而合理有序的規劃建立VPC和後續雲資源。本文内容僅做參考，不可作為具體解決方案使用。不同行業不同項目情況不同，是以使用者可參考本文具體問題具體分析。

3. 行業網絡架構

3.1 規劃設計背景

圖1:金融行業典型的整體網絡邏輯結構

完整的網絡系統架構需要考慮使用者自身業務實際情況。如上圖所示，圖中展現的是某金融行業典型的整體網絡邏輯結構。在實際應用中，網絡架構需要遵循以下設計原則：

階層化設計：每個層可以看作是園區網内一個具有特定角色和功能的結構定義良好的子產品，階層化的設計結構，易于擴充和維護，降低了設計的複雜度和難度。
子產品化設計：每個子產品對應一個部門、功能或業務區域，可根據網絡規模靈活擴充，部門或區域内部調整涉及範圍小，容易進行問題定位。
備援設計：雙節點備援性設計可以保證裝置級可靠，适當的備援提高可靠性，但過度的備援不便于運作維護。
對稱性設計：網絡的對稱性便于業務部署，拓撲直覺，便于協定設計和分析。

專有雲網絡架構（如上圖專有雲區域）也是根據以上原則進行設計的。VPC網絡是在實體網絡基礎上疊加的一種虛拟網絡，首先運用一種基于Overlay的技術，其技術核心是重新建構邏輯網絡平面，其技術手段的關鍵是采用隧道技術實作L2oIP的封裝。通過隧道實作各虛拟機之間的二層直連，實作大二層網絡結構。其次，Overlay網絡僅僅為邏輯上的二層直連網絡。其依賴的實體網絡是傳統的路由網絡，該路由網絡是三層到邊緣的網絡。

圖2:VPC邏輯隔離結構

通過以上介紹，已基本了解網絡規劃設計的重要性。而做為實體網絡架構之上的VPC虛拟網絡，又是整個雲網絡規劃中的重要部分，前面概述介紹雲網絡使用者可自定義的特殊性，是以該規劃更貼近于使用者的業務。

是以本文特别提醒，在建立VPC資源執行個體時，一定要多結合使用者業務的實際情況，一旦建立好後就很難更改了。

3.2 VPC資源規劃原則

VPC的資源規劃基本遵循以下幾個主要原則：

規劃安全性：建立VPC資源的執行個體、資料、通路等安全性的保障。
對外互訪性：VPC資源需要有已授權的外部通路權限，對未授權的不做通路。
資源預留性：對于業務的發展帶來的雲資源擴充，需提供預留白間。
資源共享性：VPC執行個體級的資源是否需要被其它的部門共享通路。

3.3 業務評估要素

結合VPC資源規劃原則及自身業務情況，本節将以在使用者使用者的角度評估建立VPC資源前的各種業務因素。具體業務因素如下：

業務用途：使用者的業務劃分是否區分生産和測試環境等類别？
業務互訪：使用者生産或測試業務内的子系統有無強互訪需求？
業務規模：使用者業務系統的規模決定了雲平台執行個體資源的數量？
位址預留：使用者業務拓展需考慮未來兩到三年的VPC容量位址的預留？
VPC差別：使用者相同業務劃分在同一個VPC下，不同業務劃分在不同VPC下？
vswitch差別：使用者相同業務的子系統劃分在同vswitch下，相同業務但不同子系統劃分在不同vswitch下？
對外互訪：使用者雲上業務是否有對雲外并網通路需求？如何避免位址沖突？
公私模式：使用者雲上業務是“公有雲模式”還是“私有雲模式”，VPC與其它網絡互訪的差別？
五元組：使用者雲上業務是否具備五元組級安全通路控制能力？
流量控制：使用者雲上業務與雲上其它業務互訪，是繞雲外專門防火牆做流管控，還是雲内指定打通?
執行個體共享：總部機關使用者業務的資源執行個體是否需要與分支機關的資源執行個體共享?
命名規範：使用者雲上業務的執行個體級資源命名是否有規範要求？
容災特性：容災多可用區場景下，使用者業務應用是否需要進行備援？

4. VPC資源規劃

根據下面業務評估要素所提出的論點問題，後續将逐一給出建議性的解決方案。

4.1 業務用途

問題

使用者的業務劃分是否區分生産和測試環境等類别？

圖3:VPC業務用途分類

4.2 業務互訪

使用者生産或測試業務内的子系統有無強互訪需求？

圖4:VPC執行個體資源互訪

使用者生産業務或測試業務内如有兩個及以上子業務，且存在強依賴互訪關系，建議将兩個系統劃分到同一個VPC下。而生産VPC和測試VPC除非特殊業務需求，一般是強隔離。生産測試通常不建議做互訪打通。

此外業務互訪還涉及與使用者側的互訪，這就涉及VPC并網的操作，其并網操作規範又明細涉及鍊路規範、位址路由規範、安全組規範、增删操作規範、并網視窗要求、并網後測試等規範，這裡就不重點展開介紹，如對此感興趣可聯系本文作者。

優點

能直接互訪。
避免了多次網絡打通變更。
減少網絡資料通路路徑的排障點。

4.3 業務規模

使用者業務系統的規模決定了雲平台執行個體資源的數量？

圖5:VPC多vswitch規模

首先，即使隻使用一個VPC，也盡量使用至少兩個vswitch，并且将兩個交換機分布在不同可用區，這樣可以實作跨可用區容災。
其次，使用多少個vswitch還和使用者業務系統規模、系統規劃、資料量有關。如果前端系統都可以被公網通路并且都有主動通路公網的需求，考慮到容災，可将不同的前端系統部署在不同的vswitch下，而後端系統部署在另外的vswitch下。

資源功能準确
業務職能分類清晰

注釋

可用區是指在同一地域内，電力和網絡互相獨立的實體區域，在同一地域内可用區與可用區之間内網互通。

4.4 位址預留素

使用者業務拓展需考慮未來兩到三年的VPC容量位址的預留？

圖6:VPC位址規劃預留

在業務滿足目前需求的前提下，考慮未來業務的發展預期，一般未來業務發展通常可預見一到三年範圍内為參考，五年以上待定。需預留幾個大段空閑位址段容量。例如VPCA.B.C.0/23，建立時擴充更新為A.B.C.0/20。這樣從2個C變成16個C，剩餘14個C做備用給未來三年的資源業務使用。

避免執行個體位址資源飽和，引起資源鏟掉重部或遷移到新創的大段位址。

VPC一旦建立，私網位址段不可以更換

4.5 業務異同

使用者相同業務類别，劃分在同一個VPC下，不同業務劃分在不同VPC下？

圖7:VPC使用者業務環境分類

根據使用者不同且沒有依賴關系的業務，建議規劃獨立VPC，進行隔開，不建議全部在同一個VPC内或同一個vswitch内。

安全隔離
靈活管理
友善運維
VPC并網範圍精确

4.6 vswitch差別

使用者相同業務的子系統劃分在同vswitch下，相同業務但不同子系統劃分在不同vswitch下？

圖8:VPC使用者資源分類

例如，vswitch-1下部署ecs，vswitch-2部署rds等。

rds經典網絡類型可根據實際需求去部署。

位址比較在統一範圍。
友善區間位址段位址管理。
識别度高，位址區間固定。

4.7 對外互訪

使用者雲上業務是否有對雲外并網通路需求？如何避免位址沖突？

圖9:VPC使用者資源互訪

列舉出有對外通路需求的VPC，并将該類位址進行“私有雲模式”，該類的VPC位址段使用不同網段。

建立VPC資源前要考慮下使用者側的網絡位址段、雲内位址段、以及其它VPC的位址段。盡量不要有相同或位址重疊的現象。

避免因位址産生沖突，導緻相同位址段“二選一”。
避免多一層nat位址轉換層的維護。
避免業務通路受到影響。

補充

“公有雲模式”，公有雲上的VPC互相之間沒有關聯關系。任意定義網絡資源都不影響其他的VPC的通路或被通路需求。
“私有雲模式”，VPC互相之間有位址段的關聯關系，建立時需要考慮别的VPC位址段是否一緻。否則業務互相通路時會因位址相同而沖突，引起網絡不通。

4.8 公私模式

使用者雲上業務是否确定“公有雲模式”還是“私有雲模式”，VPC與其它網絡互訪的差別？

圖10:VPC使用者環境公私網互訪

公有雲模式：所有VPC内保持絕對隔離和獨立，沒有任何VPC與VPC、VPC與IDC之間的互訪需求。全部采用公網位址為源通路的方式，類似現在的公有雲。

私有雲模式：VPC對外有互訪需求，前提是位址段不沖突。

兩種模式二選一，選了公網位址（資料流經過ISW）就不能私網（資料流經過CSW），遵循公私網原理。

“公有雲模式”對于使用者來說，不用顧慮雲内全量位址相同的問題。
“私有雲模式”：位址不需要像公有雲中間經過一層位址轉換，直接尋址路由可達。

4.9 五元組

使用者雲上業務是否有五元組級安全通路控制需求？

圖11:VPC内部資源對外安全通路

有的使用者業務有高安全等級的要求，使用者業務端到端限制，使用五元組進行流控，做精确端級通路控制。

ECS：安全組
SLB/RDS：白名單
使用者IDC：業務資料流經過雲邊界，建議使用安全防火牆。

安全管理
通路控制

4.10 流量控制

使用者雲上業務與雲上其它業務互訪，是繞雲外專門防火牆做流管控，還是雲内指定打通?

圖12:VPC資源對外流量管控通路

使用者提出雲内VPC流量必須經過防火牆管控。

方式一：

做雲外繞行變更，資料流經過雲邊界使用者側防火牆。并通過防火牆做流控，控制流量的出和入方向。
方式二：

雲内做高速通道打通，中間會經過位址轉換，終端級做流控。

經過防火牆，安全政策限制更加完善，需使用者維護。
運用高速通道，流量繞行節點少，延遲相對較低。

4.11 執行個體共享

總部使用者業務的資源執行個體是否需要與分部的資源執行個體共享?

圖13:VPC資源對上下級部門通路

例如總部為一級部門，分部為二級部門。

使用者需求：

1.分部要看到總部的執行個體資源，則需要開通VPC共享。

2.分部不能看到總部的執行個體資源，則不需要開通VPC共享。

鑒權隔離

DT或ASCM，一級部門能夠看到二/三/四級部門建立的所有VPC内資源。上級部門隻對下級部門有讀寫權限。

不開通共享，則三級部門看不到二級部門的資源；

開通共享，則三級部門能夠看到二級部門的資源。

以上内容均需根據使用者的實際需求來定，例如省級使用者需通路地市級使用者的資源，而地市級不需要通路省級的資源或同等地市級的資源。

4.12 命名規範

使用者雲上業務的執行個體及資源是否有規範要求？

圖14:VPC資源命名規劃

随着使用者需求擴大，VPC逐漸增多。如果一個項目使用20個VPC，或每個VPC内都有大量的雲執行個體資源，便需運用VPC的命名規範，通過規範進一步增強執行個體的可讀性。

參考VPC命名規範：xxx業務_xxx系統_xxx服務

例如：

生産環境_考勤系統_人臉識别服務。命名：SCHJ_kqxt_RlsbServer
測試環境_測試系統_鑒權服務。命名：TEST_cs_JQServer

增強識别度
避免誤操作

4.13 容災特性

容災多可用區場景下，使用者業務應用是否需要進行備援？

圖15:VPC資源備援規劃

多region環境下，建立不同region的VPC，業務分别部署在不同region場景下，ecs等執行個體資源相應部署。

單region多zone環境下，建立VPC後再建立不同vswitch部署在不同zone下，業務分别部署在相同vpc下不同zone下，ecs等執行個體資源相應部署。

資源高可用
業務高可用
有效保障使用者資料安全

5. 規劃連連看

如果你是項目運維onwer，請根據以下使用者項目特征，該如何選擇合适的規劃推薦給使用者？

通過對以上要素點的逐一解析，已基本掌握了VPC資源規劃執行個體的能力，現在我們做個小遊戲：連連看。假如你是項目的架構師，你會建議使用者如何選擇。

如圖，以金融行業不同性質機關為例，通過連線的形式比對要素。通過使用者業務特征和13個要素的互聯做比對，加深對VPC資源規劃的了解。

圖16：連連看

圖中箭頭是作者盡量貼合實際場景後給出的參考答案，專有雲和公有雲的VPC規劃基本适用。答案有很多種，更加準确的答案還需讀者自己去思考去摸索。

你連對了嗎？

我們是阿裡雲智能全球技術服務-SRE團隊，我們緻力成為一個以技術為基礎、面向服務、保障業務系統高可用的工程師團隊；提供專業、體系化的SRE服務，幫助廣大客戶更好地使用雲、基于雲建構更加穩定可靠的業務系統，提升業務穩定性。我們期望能夠分享更多幫助企業客戶上雲、用好雲，讓客戶雲上業務運作更加穩定可靠的技術，您可用釘釘掃描下方二維碼，加入阿裡雲SRE技術學院釘釘圈子，和更多雲上人交流關于雲平台的那些事。