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

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

創(chuàng)新互聯(lián)建站主要業(yè)務(wù)有網(wǎng)站營銷策劃、成都做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)、微信公眾號開發(fā)、成都微信小程序、html5、程序開發(fā)等業(yè)務(wù)。一次合作終身朋友，是我們奉行的宗旨；我們不僅僅把客戶當(dāng)客戶，還把客戶視為我們的合作伙伴，在開展業(yè)務(wù)的過程中，公司還積累了豐富的行業(yè)經(jīng)驗(yàn)、全網(wǎng)整合營銷推廣資源和合作伙伴關(guān)系資源，并逐漸建立起規(guī)范的客戶服務(wù)和保障體系。 

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

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

ZStack在私有云和混合云技術(shù)和產(chǎn)品上又做了哪些嘗試？VPC2.0是如何解決網(wǎng)絡(luò)靈活性、擴(kuò)展性業(yè)務(wù)需求的？如何在私有云語境下定義VPC？

Q1：VPC2.0在私有云和混合云建設(shè)中，解決什么樣的問題和痛點(diǎn)，以及其最佳應(yīng)用場景？

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

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

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

• 靈活的網(wǎng)絡(luò)配置

• 安全可靠的隔離

• 豐富的網(wǎng)絡(luò)場景

• 更低的管理成本

• 更高的網(wǎng)絡(luò)性能

Q3：VPC技術(shù)會朝著什么樣的方向發(fā)展，下一步產(chǎn)品在網(wǎng)絡(luò)方面會進(jìn)行哪些優(yōu)化？

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

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

接下來，我們?yōu)槟敿?xì)解讀ZStack VPC 2.0設(shè)計(jì)思路與架構(gòu)。

安全

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

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

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

但是實(shí)際上，隨著 SaaS 服務(wù)的興起、企業(yè)互聯(lián)網(wǎng)以及介入企業(yè)內(nèi)網(wǎng)的設(shè)備越來越多，這種設(shè)計(jì)越來越難以難以維系：

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

應(yīng)用的爆發(fā)式增長，過去，一個(gè)應(yīng)用的擴(kuò)容可能是以月為單位甚至季度為單位計(jì)的，一次上架可能在數(shù)月內(nèi)都足夠支撐業(yè)務(wù)增長，而現(xiàn)在互聯(lián)網(wǎng)的快速爆發(fā)下，應(yīng)用一旦獲得好評，可能會飛速傳播，這樣對計(jì)算能力擴(kuò)容提出極高要求，而人為配合網(wǎng)絡(luò)變更極易出錯(cuò)出漏；

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

在這種現(xiàn)狀下，Google 提出了 BeyondCorp 的安全架構(gòu)，其基本思想是：安全隔離不再基于 IP、MAC 而是應(yīng)用、賬戶訪問控制不再是靜態(tài)的，而是動(dòng)態(tài)的、自動(dòng)跟隨的限制業(yè)務(wù)間相互訪問的權(quán)限甚至協(xié)議，但這種先進(jìn)的安全架構(gòu)如何應(yīng)用到企業(yè)呢？私有云如何幫助客戶完成這些安全目標(biāo)呢？我們看一個(gè) ZStack 架構(gòu)下的網(wǎng)絡(luò)設(shè)計(jì)。

二層隔離

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

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

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

在生產(chǎn)實(shí)踐中，可以將需要的業(yè)務(wù)單獨(dú)部署 VXLAN，也可以將 VXLAN 劃分給業(yè)務(wù)部門供其自由配置，保證其最底層的網(wǎng)絡(luò)隔離——無論底層的 ARP 欺騙抑或高層的服務(wù)嗅探都不可能突破這一關(guān)卡。

自定義路由

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

首先，在公有云中公網(wǎng)往往比較好定義——一定就是 Internet，唯一區(qū)別是可能是電信網(wǎng)絡(luò)或聯(lián)通網(wǎng)絡(luò)或 BGP 網(wǎng)絡(luò)等等。而私有云則不然，私有云中內(nèi)網(wǎng)一定是部署業(yè)務(wù)的網(wǎng)絡(luò)而公網(wǎng)卻不一定是 Internet，例如下圖中的架構(gòu)：

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

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

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

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

基于源的安全組

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

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

如上圖，我們可以針對源安全組來設(shè)置安全組規(guī)則，例如安全組 1 可以配置當(dāng)源來自安全組 2 時(shí)開放哪些端口，來自安全組 3 時(shí)開放那些端口。

其他

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

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

靈活

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

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

ZStack VPC 2.0在靈活性上帶來了下面這些亮點(diǎn)：

多網(wǎng)絡(luò)服務(wù)復(fù)用地址

對于中小型的私有云，一個(gè)常見需求是——公有網(wǎng)絡(luò)的 IP 地址不夠用，特別是這個(gè)共有網(wǎng)絡(luò)是一個(gè)真的 Internet 上 IPv4 地址時(shí)。

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

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

此外，考慮到每個(gè)服務(wù)使用不同的端口（SNAT 外），ZStack 里還可以對每個(gè)端口做不同的 QoS，達(dá)到既對 VIP 本身可以做 QoS，同時(shí)可以對不同服務(wù)做 QoS 的能力。

物理網(wǎng)絡(luò)接入

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

為了解決物理設(shè)備的接入，ZStack 提供了多公網(wǎng)、自定義路由、多網(wǎng)卡、VXLAN 網(wǎng)關(guān)等多種方案。其中前兩者前面有所介紹，多網(wǎng)卡很好理解?；?VXLAN 網(wǎng)關(guān)的方案則是因?yàn)?ZStack 采用標(biāo)準(zhǔn)的 VXLAN 協(xié)議，因此其他使用 VXLAN 協(xié)議的網(wǎng)絡(luò)設(shè)備理論上都可以與 ZStack 的 VTEP 協(xié)商構(gòu)成同一個(gè) VXLAN Underlay 網(wǎng)絡(luò)，達(dá)到虛擬網(wǎng)絡(luò)與物理網(wǎng)絡(luò)混合的效果。

很多時(shí)候，云網(wǎng)技術(shù)會通過 DVR 來優(yōu)化流量，造成偽造網(wǎng)關(guān)帶來的一系列問題，從而造成運(yùn)維復(fù)雜度上升甚至部分需求無法實(shí)現(xiàn)，這個(gè)問題在 ZStack 中是不存在的，具體將在下面分布式路由中介紹。

網(wǎng)絡(luò)服務(wù)跟隨

在很多云中，網(wǎng)絡(luò)服務(wù)定義在 VPC 中，實(shí)現(xiàn)在云路由之上，這樣云路由成為 VPC 的關(guān)鍵角色，公有云中往往避免直接暴露給用戶云路由，而像私有云也往往將云路由的相關(guān)操作列為一個(gè)關(guān)鍵操作——用戶不能隨意刪除或卸載，否則可能會導(dǎo)致網(wǎng)絡(luò)服務(wù)的消失。

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

如上圖，雖然網(wǎng)絡(luò)服務(wù)定義在云路由上，但最終其用于 VM2，所以 VM2 不消失，無論云路由發(fā)生什么變化，網(wǎng)絡(luò)服務(wù)最終會應(yīng)用在 VM2 上。

性能

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

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

傳統(tǒng)的網(wǎng)絡(luò)協(xié)議將整個(gè)過程一般都定義為集中式的，例如 DHCP 服務(wù)器、例如路由網(wǎng)關(guān)，而且集中控制也帶來實(shí)現(xiàn)上的便利性——特別是 SNAT、路由表這些服務(wù)，而一些服務(wù)我們發(fā)現(xiàn)它其實(shí)可以通過一些手段做分布式的優(yōu)化，而且其重要性也值得我們?nèi)ミ@樣做，例如 DHCP 和網(wǎng)關(guān)。

分布式 DHCP

ZStack 從最早的 Flat 網(wǎng)絡(luò)即支持了分布式 DHCP，但云路由網(wǎng)絡(luò)是集中式的 DHCP，從 2.1 開始，我們開始將云路由網(wǎng)絡(luò) DHCP 改為分布式的設(shè)計(jì)，并繼承到了 VPC 網(wǎng)絡(luò)之中。

分布式路由

分布式路由是 ZStack VPC 2.0 中一個(gè)極為重點(diǎn)的功能。與業(yè)界一些 DVR 的實(shí)現(xiàn)對規(guī)模有限制甚至很脆弱難以應(yīng)用到生產(chǎn)不同，ZStack VPC 2.0 在設(shè)計(jì)之初就經(jīng)過了精心的考慮，因此它有著以下的特點(diǎn)：

無先驗(yàn)知識

無消息隊(duì)列

無網(wǎng)關(guān)欺騙

無集中式控制器

即時(shí)開關(guān)

首先，無先驗(yàn)知識是指整個(gè)流量優(yōu)化系統(tǒng)無需從 ZStack 數(shù)據(jù)庫拉取信息。為什么這個(gè)很重要呢？因?yàn)?ZStack 設(shè)計(jì)原則里有很重要的一點(diǎn)，就是管控面與數(shù)據(jù)面的分離，管控面的故障不會擴(kuò)散到數(shù)據(jù)面上，任何情況下優(yōu)先保證用戶業(yè)務(wù)的不受影響。

在這種設(shè)計(jì)原則下，我們自然不能去拉取 ZStack 數(shù)據(jù)庫的信息——即使所有網(wǎng)絡(luò)信息都記錄在了 ZStack 數(shù)據(jù)庫上，但一來不能保證數(shù)據(jù)庫的永久不宕機(jī)，二來數(shù)據(jù)庫的數(shù)據(jù)其實(shí)是不能真實(shí)的反應(yīng)網(wǎng)絡(luò)狀態(tài)的，用戶隨時(shí)可能修改自己的 IP、創(chuàng)建虛擬網(wǎng)卡等等。

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

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

而 ZStack 希望在做分布式路由時(shí)，一要可靠，二要盡量避免影響用戶的使用習(xí)慣，因此實(shí)現(xiàn)了無網(wǎng)關(guān)欺騙的無狀態(tài)流量優(yōu)化，從而完整兼容過去的所有功能，用戶也可以透明的享受分布式路由帶來的好處。

第四是沒有集中控制器。在傳統(tǒng)的 DVR 設(shè)計(jì)中除了與 CMS 數(shù)據(jù)庫交互外，還會往往有集中化控制器這一問題，那么一旦控制器失效，輕則無法優(yōu)化流量，重則網(wǎng)絡(luò)中斷，也是用戶所萬萬無法接受的。

在 ZStack VPC 中，流量優(yōu)化由在云路由中的 Agent 發(fā)起，每個(gè) Agent 只關(guān)心自己所在云路由上的流量，因此不存在系統(tǒng)單點(diǎn)，而且這樣的 Agent 類似于一種旁掛機(jī)制而非直連，那么即使 Agent 掛掉，也不會導(dǎo)致網(wǎng)絡(luò)失效。而是已優(yōu)化流量會逐漸回退到傳統(tǒng)集中式路徑上。

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

此外 ZStack VPC 2.0 還有著大量潛力尚待挖掘——例如基于優(yōu)化數(shù)據(jù)的網(wǎng)絡(luò)連接探測、優(yōu)化流量統(tǒng)計(jì)等等，將在未來的版本逐步推出。

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

分享題目：怎么在私有云語境下定義VPC
文章源于：http://bm7419.com/article32/gigjsc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、服務(wù)器托管、響應(yīng)式網(wǎng)站、網(wǎng)站制作、微信小程序、網(wǎng)站收錄

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)