怎么在私有云語境下定義VPC

這篇文章將為大家詳細講解有關怎么在私有云語境下定義VPC，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

日前，ZStack推出了新一版網絡架構 VPC 2.0，作為ZStack 2.3.0版本中的重磅功能，VPC 2.0 提供全面而強大的網絡功能支持，包括：靈活的網絡配置，安全可靠的邏輯隔離，以及開啟分布式路由功能，優化東西向網絡流量、不同子網之間不通過云路由器直接完成互聯互通等高級策略，可滿足豐富的網絡場景實現。

VPC經過多年的市場教育和實踐，大部分公有云用戶已經接受了公有云中 VPC 是必不可少的基礎組件。但是對于私有云和混合云領域來說，如何保障業務安全？如何充分利用云的潛力？是否還是沿用過去的虛擬化的設計經驗，目前尚無定數。

ZStack在私有云和混合云技術和產品上又做了哪些嘗試？VPC2.0是如何解決網絡靈活性、擴展性業務需求的？如何在私有云語境下定義VPC？

Q1：VPC2.0在私有云和混合云建設中，解決什么樣的問題和痛點，以及其最佳應用場景？

在ZStack VPC1.0里，其VPC的概念和設計主要來源于公有云對隔離性的設計，在現網接入、網絡靈活性等諸多方面有所欠缺，在面向復雜的私有云、混合云場景不能完全滿足我們的需求，因此ZStack對網絡模型進行了大量改造，著重提高了靈活性、易用性和性能。

目前IaaS產品VPC大多來自公有云，著重于安全和隔離性，ZStack VPC 2.0在安全性和隔離性的基礎上大量考慮了用戶的實際使用場景、軟硬結合的使用場景、利舊的場景等，在現有的VPC1.0基礎上帶來了功能豐富還易用的VPC2.0，它能夠滿足企業從幾十臺虛擬機的小規模應用到幾萬臺虛擬機的大規模部署，并將完整對接混合云VPC，完成私有云VPC的一次全新定義。

Q2：VPC2.0 給用戶帶來的主要價值是？

• 靈活的網絡配置

• 安全可靠的隔離

• 豐富的網絡場景

• 更低的管理成本

• 更高的網絡性能

Q3：VPC技術會朝著什么樣的方向發展，下一步產品在網絡方面會進行哪些優化？

下一步首先是在更加開放的網絡功能上。我們希望能將網絡功能做成一個平臺開放出去，不只是有我們提供的網絡服務，來自各家廠商的無論NFV、防火墻、監控等產品都能無縫接入到ZStack云平臺之中，這樣才能更進一步的提升效率、降低用戶的使用、運維成本。目前OPNFV等組織、OpenDaylight等項目都做過一些工作，但距離可交付給用戶還有相當的距離。

其次是更加的自動化。目前混合云開通、隧道建立不可避免的還存在一些手工的過程，這是目前用戶需要等待多的步驟，也是最容易出錯的步驟，將來我們希望能夠通過引入例如 SDWAN等技術將這個過程更加高效化，并能夠夠細致、直觀的展示給客戶當前網絡的狀態、質量，能夠讓用戶“傻瓜化”的進行查錯、管理。

接下來，我們為您詳細解讀ZStack VPC 2.0設計思路與架構。

安全

當用戶使用公有云時，其第一考慮的往往是安全。去年一年來不斷的發生了各類安全事件，使得用戶心生躊躇，這樣的問題在私有云中是不存在的——從機柜到電源都完全在企業自己控制下，而且往往在出口部署了高昂的網絡安全設備，相比將數據走在和別人共用的網線上，這一做法自然更好保證企業的專屬網絡和數據，但也給用戶帶來不小的運維成本。

所以如何在保證安全的前提下減少用戶的安全運維成本是我們的第一個考量。要知道網絡隔離和彈性計算天然是對立的——隔離的越細致，快速擴容、服務編排、資源回收往往越難，而且這個難度會隨業務的數量指數增長。

以往我們可能認為出口部署防火墻足以抵擋一切攻擊——如同在一片暴風雨中間設一個城堡，外墻越修越高，試圖抵擋一切攻擊。

但是實際上，隨著 SaaS 服務的興起、企業互聯網以及介入企業內網的設備越來越多，這種設計越來越難以難以維系：

企業對外的數據和網絡入口越來越多，比如網站、員工 VPN、購買的 SaaS 服務、對外的 API 服務、用于所開發的網站 App 或手機 App 而提供的數據通道，甚至員工自行連入的手機都可能存在安全隱患，這樣企業需要設置的外墻越來越多也越來越高；

應用的爆發式增長，過去，一個應用的擴容可能是以月為單位甚至季度為單位計的，一次上架可能在數月內都足夠支撐業務增長，而現在互聯網的快速爆發下，應用一旦獲得好評，可能會飛速傳播，這樣對計算能力擴容提出極高要求，而人為配合網絡變更極易出錯出漏；

數據的爆發式增長帶來的混合云需求，與業務的增長并行的，是存儲需求的增長，以及數據價值的不斷提高，越來越多的企業對存儲有更為豐富的需求——除了傳統的 SAN、NAS，還有一些業務可能需要超高性能，一些業務需要對象存儲，還有冷熱分離，大量的日志存儲等等要求。此時完全自購設備是很不劃算的，對接公有云組成混合云無疑是哥可行選擇，但對網絡要求更復雜了。

在這種現狀下，Google 提出了 BeyondCorp 的安全架構，其基本思想是：安全隔離不再基于 IP、MAC 而是應用、賬戶訪問控制不再是靜態的，而是動態的、自動跟隨的限制業務間相互訪問的權限甚至協議，但這種先進的安全架構如何應用到企業呢？私有云如何幫助客戶完成這些安全目標呢？我們看一個 ZStack 架構下的網絡設計。

二層隔離

對于所有網絡隔離來說，隔離最徹底的，莫過于二層網絡隔離，然而傳統二層網絡隔離基于 VLAN 或 802.1ad，前者可供使用的域少，而后者配置過于麻煩。還好 ZStack 從 2.0 就提供了 VXLAN 作為網絡隔離技術。

與市面上大多數哦 IaaS 不同，ZStack 提供了極為靈活豐富的方法來配置 VXLAN 網絡，ZStack 將 VXLAN 的 Underlay 網絡 Overlay 網絡記為 VXLAN Pool 和 VXLAN Network，前者用于加載到集群、加載 VNI Range 等等，并且在加載時可以選擇 VTEP 的地址段，ZStack 就會自動尋找到合適的 VTEP 地址并加載。

每一個集群可以使用不同的 VTEP 地址段，管理員可以任意劃定 VNI 范圍，并將這個 Pool 共享給最終用戶或部門的運維管理人員，再在之上創建 VXLAN 網絡。整個過程高度自動化和靈活——甚至服務器上 VTEP 所需要的地址由于某些原因被修改，只需要在 ZStack 界面上重連物理機即可自動同步！

在生產實踐中，可以將需要的業務單獨部署 VXLAN，也可以將 VXLAN 劃分給業務部門供其自由配置，保證其最底層的網絡隔離——無論底層的 ARP 欺騙抑或高層的服務嗅探都不可能突破這一關卡。

自定義路由

從 ZStack 2.1 開始我們提供路自定義路由這一功能，這一功能咋看之下與安全毫無關系，實則不然。

首先，在公有云中公網往往比較好定義——一定就是 Internet，唯一區別是可能是電信網絡或聯通網絡或 BGP 網絡等等。而私有云則不然，私有云中內網一定是部署業務的網絡而公網卻不一定是 Internet，例如下圖中的架構：

假設我們有兩個 VPC 部署了三個業務，其中應用和數據庫為了性能考慮放在了一個 VPC，而 Web 服務是一個公共服務在一個單獨的 VPC 中，此時應用服務可以通過云路由，走自定義路由走到 VPC2，這里 VPC2 運用了我們的云路由支持多公網的功能，這一功能一定是和自定義路由相互配合使用的。

此外，如何保障數據庫的安全？不被滲透或探測？安全組是一方面，另一方面為了防止探測流量和意外的路由導致數據庫被外部發現，我們還可以在 ZStack 中指定黑洞路由：

這樣可以徹底的保證數據庫服務的地址段不會泄漏到 VPC 之外了。

考慮到復雜網絡的路由復雜性，ZStack 還提供了 API 供管理員查看云路由中哪些路由條目正在生效，哪些路由條目雖然配置但實際上是不生效的。

基于源的安全組

傳統安全組基于 IP、協議和端口，這樣的安全組除了策略跟隨（虛擬機任意漂移不影響其安全策略的生效）之外很難說比傳統 ACL 有多少優勢，與 zone based firewall 都略顯單薄。

但是 ZStack 自 2.1 起提供了基于源的安全組，也就是安全組可以當作一個安全域來使用，ZStack 可以自動識別來自不同安全組的流量，從而做到靈活的訪問控制而無需反復設置 IP 或網段，減少出錯，提高效率。

如上圖，我們可以針對源安全組來設置安全組規則，例如安全組 1 可以配置當源來自安全組 2 時開放哪些端口，來自安全組 3 時開放那些端口。

其他

此外，ZStack 還有其他很多安全技術例如源地址過濾以防止 IP、MAC 地址偽造，DHCP 服務器防偽造避免用戶從錯誤的服務器上獲取地址等等。通過這些技術的有效運用，管理員可以根據自己的需求和實際環境配置做夠安全、可信的網絡。

私有云和公有云不同，這些系統的設置和使用都是可以由用戶自己配置和使用的，用戶與此同時可以接入一些既有的安全設備例如 WAF、防火墻、流量清洗等等，可以參考下面的內容。

靈活

對于公有云，一切規則是由供應商決定的，供應商往往會根據自身的考慮或者技術的局限而定義這些規則，一方面會導致云上的網絡使用和傳統存在很多不同，一些管理操作帶來不便，例如公有云的數據庫帶來了 scale 的方便，但也帶來了調試的不便；另一方面容易形成對其資源的使用形成 all in，例如可能我們只想使用公有云上的數據庫，但為此將業務虛擬機也只好遷到云上，隨之而來的還要遷移存儲系統、備份系統甚至一套相配套的內容，帶來了很多不便。

而當我們設計一款私有云時，這一切都需要考慮，而不是以一句“客戶需要設計 Cloud Native”的理由認為客戶的需求不合理。特別是 ZStack 是一個產品化的私有云，產品會不斷升級，既要添加新的功能和場景，又要兼容舊的設計和使用，甚至是用戶不合理的使用。

ZStack VPC 2.0 在靈活性上帶來了下面這些亮點：

多網絡服務復用地址

對于中小型的私有云，一個常見需求是——公有網絡的 IP 地址不夠用，特別是這個共有網絡是一個真的 Internet 上 IPv4 地址時。

ZStack 為用戶提供了豐富的網絡服務，包括但不限于彈性 IP、負載均衡、IPSec VPN、端口轉發、SNAT 等等，而與此同時用戶的 IP 地址卻可能捉襟見肘，比如用戶只有一個地址但既想要用 SNAT 開放虛擬機到公網的訪問，又想用其作為 IPSec 的地址連接混合云。

這個需求在數據平面是可行的，但對云平臺的控制平面卻做出很大挑戰，云平臺要很好的協調每個服務對 IP 的需求，將其合理的配置到云路由上。從 ZStack 2.3.0 開始，我們支持了一個 IP 同時用在負載均衡、IPSec、端口轉發、SNAT 等所有不要求獨占 IP 的服務上！而且用戶可以任意劃定其端口的使用，從此將 VIP 從一個網絡屬性，徹底開放成為一個可以池化的資源，大大解放了私有云對 IP 的使用。

此外，考慮到每個服務使用不同的端口（SNAT 外），ZStack 里還可以對每個端口做不同的 QoS，達到既對 VIP 本身可以做 QoS，同時可以對不同服務做 QoS 的能力。

物理網絡接入

在私有云中，既有設備或既有網絡的接入同樣是無法繞開的問題。一來企業要避免投資浪費，二來短時間內很多軟件的實現在性能或功能上都無法與硬件相媲美，例如應用交付控制器 ADC、流量清洗設備等等。

為了解決物理設備的接入，ZStack 提供了多公網、自定義路由、多網卡、VXLAN 網關等多種方案。其中前兩者前面有所介紹，多網卡很好理解。基于 VXLAN 網關的方案則是因為 ZStack 采用標準的 VXLAN 協議，因此其他使用 VXLAN 協議的網絡設備理論上都可以與 ZStack 的 VTEP 協商構成同一個 VXLAN Underlay 網絡，達到虛擬網絡與物理網絡混合的效果。

很多時候，云網技術會通過 DVR 來優化流量，造成偽造網關帶來的一系列問題，從而造成運維復雜度上升甚至部分需求無法實現，這個問題在 ZStack 中是不存在的，具體將在下面分布式路由中介紹。

網絡服務跟隨

在很多云中，網絡服務定義在 VPC 中，實現在云路由之上，這樣云路由成為 VPC 的關鍵角色，公有云中往往避免直接暴露給用戶云路由，而像私有云也往往將云路由的相關操作列為一個關鍵操作——用戶不能隨意刪除或卸載，否則可能會導致網絡服務的消失。

而 ZStack 中卻有所不同，我們認為用戶的網絡服務創建是面向業務的，也是服務于業務的（特別是彈性 IP、端口轉發等），此時如果我們想將虛擬機轉移到另一個 VPC 或者刪除掉云路由就丟失網絡服務是不可取的。我們通過實現網絡服務跟隨，達到了，網絡服務一旦創建，將跟隨這個虛擬機而非云路由，如果這個云路由被刪除，一旦重新創建或加載，所有網絡服務將自動重新應用——這就像從此的 NAT 規則不再依賴一個實際的防火墻，而是直接于你的業務綁定，即使換一個防火墻、重建一個防火墻，系統總會嘗試幫你恢復業務，達到資源的真正池化、無依賴、完全靈活。

如上圖，雖然網絡服務定義在云路由上，但最終其用于 VM2，所以 VM2 不消失，無論云路由發生什么變化，網絡服務最終會應用在 VM2 上。

性能

雖然不像公有云那樣單區域承載百萬臺甚至更多虛擬機，但私有云也并非沒有性能要求，甚至隨著用戶的需求變化，我們需要能夠適應用戶從小到大的規模要求，小規模時不浪費額外資源，大規模時也要有方案與之應對。

特別是云路由接入多個子網后，其上的流量由于企業對東西向流量的需求可能會變得很大，如果一個云路由成為整個網絡的性能瓶頸是不被用戶接受的，除了單點問題之外，性能上的占用也很可觀。

傳統的網絡協議將整個過程一般都定義為集中式的，例如 DHCP 服務器、例如路由網關，而且集中控制也帶來實現上的便利性——特別是 SNAT、路由表這些服務，而一些服務我們發現它其實可以通過一些手段做分布式的優化，而且其重要性也值得我們去這樣做，例如 DHCP 和網關。

分布式 DHCP

ZStack 從最早的 Flat 網絡即支持了分布式 DHCP，但云路由網絡是集中式的 DHCP，從 2.1 開始，我們開始將云路由網絡 DHCP 改為分布式的設計，并繼承到了 VPC 網絡之中。

分布式路由

分布式路由是 ZStack VPC 2.0 中一個極為重點的功能。與業界一些 DVR 的實現對規模有限制甚至很脆弱難以應用到生產不同，ZStack VPC 2.0 在設計之初就經過了精心的考慮，因此它有著以下的特點：

無先驗知識

無消息隊列

無網關欺騙

無集中式控制器

即時開關

首先，無先驗知識是指整個流量優化系統無需從 ZStack 數據庫拉取信息。為什么這個很重要呢？因為 ZStack 設計原則里有很重要的一點，就是管控面與數據面的分離，管控面的故障不會擴散到數據面上，任何情況下優先保證用戶業務的不受影響。

在這種設計原則下，我們自然不能去拉取 ZStack 數據庫的信息——即使所有網絡信息都記錄在了 ZStack 數據庫上，但一來不能保證數據庫的永久不宕機，二來數據庫的數據其實是不能真實的反應網絡狀態的，用戶隨時可能修改自己的 IP、創建虛擬網卡等等。

其次，無消息隊列。OpenStack 中 DVR 的控制數據通過消息隊列執行最終被認為是一個欠考慮的設計，因為消息隊列既有著容量限制還存在自身的可靠性問題，因此 ZStack DVR 拋棄了消息隊列，實現了一種私有協議為 ZSNP（ZStack Network Protocol），通過這個協議直接在 IP 層上傳遞消息，并實現了無需知道虛擬機所在 Host 的信息的前提下將信令直接投遞到 Host 上所在 Agent 的功能。

第三，無網關欺騙。傳統的 DVR 都是基于網關欺騙實現的，這種想法非常直接——既然我要做網關，那肯定要實現一個偽網關，與此同時帶來的，就是防止網關泄漏、偽網關與真網關的判斷等等一系列問題，而且很容易造成用戶自定義的路由難以實現、物理設備不好接入。

而 ZStack 希望在做分布式路由時，一要可靠，二要盡量避免影響用戶的使用習慣，因此實現了無網關欺騙的無狀態流量優化，從而完整兼容過去的所有功能，用戶也可以透明的享受分布式路由帶來的好處。

第四是沒有集中控制器。在傳統的 DVR 設計中除了與 CMS 數據庫交互外，還會往往有集中化控制器這一問題，那么一旦控制器失效，輕則無法優化流量，重則網絡中斷，也是用戶所萬萬無法接受的。

在 ZStack VPC 中，流量優化由在云路由中的 Agent 發起，每個 Agent 只關心自己所在云路由上的流量，因此不存在系統單點，而且這樣的 Agent 類似于一種旁掛機制而非直連，那么即使 Agent 掛掉，也不會導致網絡失效。而是已優化流量會逐漸回退到傳統集中式路徑上。

最后，一個很有意思的功能是 ZStack VPC 的分布式路由可以由用戶自行決定是否開啟，而且通過前面原理的介紹我們可以知道這種開關是分布在每個云路由上的，用戶可以選擇部分云路由開啟而部分關閉，而且這種開啟即時生效，關閉也會在規則老化后徹底回退到傳統路徑。

此外 ZStack VPC 2.0 還有著大量潛力尚待挖掘——例如基于優化數據的網絡連接探測、優化流量統計等等，將在未來的版本逐步推出。

關于怎么在私有云語境下定義VPC就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。