国产成人精品无码青草_亚洲国产美女精品久久久久∴_欧美人与鲁交大毛片免费_国产果冻豆传媒麻婆精东

15158846557 或 在線咨詢 在線咨詢
15158846557 或 在線咨詢
所在位置： 首頁 > 營銷資訊 > 網(wǎng)站運營 > 網(wǎng)絡虛擬化協(xié)議GENEVE

網(wǎng)絡虛擬化協(xié)議GENEVE

時間：2023-06-27 11:36:01 | 來源：網(wǎng)站運營

時間：2023-06-27 11:36:01 來源：網(wǎng)站運營

網(wǎng)絡虛擬化協(xié)議GENEVE：去年看到過一篇文章[1]，說是通過OpenVSwitch的測試，GENEVE的性能要略優(yōu)于VXLAN。我相信大多數(shù)人的反應可能跟我的第一反應一樣，這不又是一種Overlay協(xié)議嗎？為什么性能會更好？難道有什么黑科技？我們這次來分析一下GENEVE有什么不一樣。

網(wǎng)絡虛擬化

要說清楚來龍去脈，需要從網(wǎng)絡虛擬化開始說起。網(wǎng)絡虛擬化（Networking Virtualization）是在一個underlay網(wǎng)絡上劃分出多個overlay網(wǎng)路。原本只支持一套網(wǎng)絡的設備，通過網(wǎng)絡虛擬化，現(xiàn)在可以用來支持多套網(wǎng)絡。網(wǎng)絡虛擬化本身不是一個新的技術，從其誕生之日起，各種各樣的協(xié)議就被提出，遠的有VLAN（IEEE 802.1Q）、MPLS（RFC3031），近的有VXLAN（RF7348）、NVGRE（RFC7637），STT。那究竟是網(wǎng)絡虛擬化的什么特性，導致了這么多相關的協(xié)議被提出？

如果我們把網(wǎng)絡中的所有節(jié)點看成一個分布式系統(tǒng)，那么underlay網(wǎng)絡為這個分布式系統(tǒng)的各個節(jié)點提供了網(wǎng)絡連接。而各種各樣的網(wǎng)絡虛擬化協(xié)議，則為這個分布式系統(tǒng)的各個節(jié)點提供了通信所使用的協(xié)議。比如說，在一個云環(huán)境里面，所有的服務器共同組成了一個部署虛機的分布式系統(tǒng)。underlay網(wǎng)絡連接這個分布式系統(tǒng)的各個節(jié)點（各個服務器），而網(wǎng)絡虛擬化協(xié)議用來封裝各個節(jié)點之間傳遞的數(shù)據(jù)（虛機之間的網(wǎng)絡數(shù)據(jù)）。

虛機間的網(wǎng)絡數(shù)據(jù)基本都是以太幀，但是不同的應用場景，系統(tǒng)規(guī)模，對于協(xié)議的要求也不一樣。所以才會有這么多網(wǎng)絡虛擬化協(xié)議。目前的各種網(wǎng)絡虛擬化的協(xié)議，本質上來說都是一樣的。那就是，以一定的格式封裝原始網(wǎng)絡數(shù)據(jù)，再輔以一定的元數(shù)據(jù)（metadata），來實現(xiàn)附加的功能。元數(shù)據(jù)對于網(wǎng)絡虛擬化來說不是一個陌生的概念，網(wǎng)絡標識符（Virtual Network Identifier，VNI）就是一種元數(shù)據(jù)。通過VNI可以識別并隔離多個租戶（tenant）網(wǎng)絡。

現(xiàn)在比較流行的網(wǎng)路虛擬化協(xié)議是VXLAN，有24bit的VNI，可以對應1600萬個不同的tenant網(wǎng)絡。VXLAN的提出常常說是為了解決VLAN（12bit VNI）所提供的租戶網(wǎng)絡數(shù)不夠的問題。現(xiàn)在來看1600萬這個數(shù)字是足夠大了，但是能保證以后一直夠用嗎？因為在VLAN被提出的時候，4000多個租戶網(wǎng)絡已經(jīng)很夠用了。只是隨著云計算和數(shù)據(jù)中心規(guī)模的發(fā)展，漸漸變的不夠用。那么激進點看，隨著技術的發(fā)展，24bit的VNI會不會也有不夠用的一天？

退一步說，就算24bit的VNI是夠用的，現(xiàn)在一些新的應用需要網(wǎng)絡虛擬化協(xié)議里面攜帶其他的元數(shù)據(jù)。例如加入port ID來作為安全規(guī)則的識別符。假設port ID是16bit，那24bit的VNI只剩下8bit用來標識租戶網(wǎng)絡，這明顯是不夠用的。

所以，盡管現(xiàn)有的網(wǎng)絡虛擬化協(xié)議能滿足當前的需求，但是隨著技術的發(fā)展和使用場景的變化，并不能保證它們能夠一直滿足需求。解決辦法有兩種，一種是到時候再定義新的協(xié)議，另一種是定義一種靈活，可擴展的網(wǎng)絡虛擬化協(xié)議。GENEVE采用的是后者。

GENEVE

GENEVE這個單詞對應的是瑞士城市日內(nèi)瓦，但是這個網(wǎng)絡協(xié)議本身與日內(nèi)瓦應該沒什么關系。這個單詞是Generic Network Virtualization Encapsulation的簡稱，對應中文是通用網(wǎng)絡虛擬化封裝，由IETF草案定義[2]。

GENEVE的作者稱，他們考慮了所有可能的應用場景，發(fā)現(xiàn)一個固定長度的元數(shù)據(jù)（例如前面提到的VNI）不能適應所有可能的場景。同時，他們也參考了其他一些常青的協(xié)議，例如BGP，LLDP，IS-IS。這些協(xié)議已經(jīng)存在幾十年了，并且現(xiàn)在還很流行。背后的原因在于，這些協(xié)議并不是一成不變，而是隨著技術的發(fā)展，支持了新功能的擴展。例如BGP，最基本的路由選擇算法一直沒有改變，但是卻從只支持IPv4到支持IPv6，VPNv4,VPNv6等其他地址族。

所以，他們提出了一種網(wǎng)絡虛擬化協(xié)議，這個協(xié)議的元數(shù)據(jù)本身是可擴展的。這樣，就算需求變化了，這個協(xié)議也能擴展以滿足需求。這個協(xié)議就是GENEVE。

在實現(xiàn)上，GENEVE與VXLAN類似，仍然是Ethernet over UDP，也就是用UDP封裝Ethernet。VXLAN header是固定長度的（8個字節(jié)，其中包含24bit VNI），與VXLAN不同的是，GENEVE header中增加了TLV（Type-Length-Value），由8個字節(jié)的固定長度和0~252個字節(jié)變長的TLV組成。GENEVE header中的TLV代表了可擴展的元數(shù)據(jù)。我們來看一下GENEVE header：

性能考慮

從協(xié)議格式可以看出，GENEVE與其他網(wǎng)絡虛擬化協(xié)議的主要區(qū)別在于一個長度可變的header。這使得GENEVE變得靈活，可擴展。但是可擴展和高性能從來都是矛盾的。因為可擴展意味著更多的元數(shù)據(jù)來支持更多的功能，而高性能卻要求更少的數(shù)據(jù)傳輸和處理。對此GENEVE定義了O和C位（參見上面協(xié)議格式分析），使得Endpoint能夠更靈活的處理數(shù)據(jù)，以減少額外的元數(shù)據(jù)對性能帶來的影響。

控制層考慮

盡管某些網(wǎng)絡虛擬化協(xié)議里面包含了對控制層的描述，例如VXLAN（RFC7348）就包含了一個基于組播的learn-flood控制層，但是在實際使用中，這些協(xié)議通常只被當做數(shù)據(jù)格式的描述。試問多少人知道RFC7348里面有基于組播的flood-learn？

另外，在VXLAN的使用過程中，控制層可能有很多種，例如EVPN，例如SDN controller。這兩種控制層比基于組播的控制層要流行的多。而所有這些控制層之間的差別是巨大的。

所以，GENEVE的作者認為，GENEVE應該只關注協(xié)議數(shù)據(jù)格式。他們力求設計一種適用于多種控制層的協(xié)議，而非只針對某一種控制層。這樣就算控制層變化了，協(xié)議本身也不至于被棄用。

underlay負載均衡考慮

幾乎所有的underlay網(wǎng)絡（例如CLOS架構）都會利用多條等價路徑（ECMP）來提高傳輸?shù)牟l(fā)性。我們把兩個虛機之間的一個傳輸層連接稱為一個數(shù)據(jù)流。為了達到最好的負載均衡的性能，不同的數(shù)據(jù)流應當被分布到不同的線路上。而相同的數(shù)據(jù)流應當被分到同一個線路上，這樣才能保證數(shù)據(jù)的順序，減少不必要的確認重傳。

對于GENEVE來說，因為Ethernet Frame被封裝在UDP里面，ECMP設備看到的不是虛機的IP/MAC，而是Tunnel Endpoint的IP/MAC。每個Tunnel Endpoint可能連接多個不同的虛機，而對于兩個相同Tunnel Endpoint之間的網(wǎng)絡流量，在underlay網(wǎng)絡上唯一能看到的不一樣的地方就是外層UDP的source port。因此，GENEVE規(guī)定，使用外層UDP的source port用來標識實際的數(shù)據(jù)流。首先，對于同一個數(shù)據(jù)流來說，外層UDP的source port應該是一樣的，其次這個UDP source port，應該根據(jù)實際的數(shù)據(jù)流計算得出，例如根據(jù)數(shù)據(jù)流的五元組。這樣，ECMP設備不需要讀取內(nèi)層報文的信息，只需要根據(jù)外層UDP的source port，就能完成ECMP的路徑選擇算法。而這個時候的UDP source port，也不再標識一個UDP連接，而是用來標識overlay的數(shù)據(jù)流。為了減少重復，GENEVE協(xié)議認為應該使用source port的整個16bit（而不是常用的50000-65535）。

兼容性考慮

如果你熟悉VXLAN或者NVGRE的協(xié)議格式，你可能已經(jīng)發(fā)現(xiàn)了，如果不考慮Variable Length Options，GENEVE與VXLAN還有NVGRE是不沖突的。特別是VXLAN，也是將Ethernet Frame封裝在UDP里面，這樣，一些現(xiàn)有的針對VXLAN的優(yōu)化，例如硬件offload，RSS，可以直接應用在GENEVE上。

OVN

OpenVSwitch的衍生項目OVN（Open Virtual Network）應該是GENEVE的最大擁躉。本文最開始提到的文章[1]，也是出自OVN的開發(fā)人員。根據(jù)OVN的文檔[3]，OVN只支持GENEVE和STT作為網(wǎng)絡虛擬化協(xié)議。這是因為OVN除了24bit的VNI之外，還要在overlay數(shù)據(jù)中傳輸15bit的源網(wǎng)絡端口，和16bit的目的網(wǎng)絡端口，以支持更高效的ACL和組播。GENEVE因為是可擴展的，自然是支持傳遞額外的元數(shù)據(jù)。STT因為本身的元數(shù)據(jù)是64bit的，也放得下OVN想要傳遞的內(nèi)容。至于其他的協(xié)議，例如VXLAN，NVGRE，是沒有可能滿足OVN的需求。

我們再回過頭來看看[1]，為什么測試結果顯示GENEVE性能要略優(yōu)于VXLAN。由于VXLAN的普及，目前支持GENEVE的硬件不多，所以測試都是在支持VXLAN RSS的網(wǎng)卡上進行。并且在測試中，GENEVE還額外傳遞了OVN所需的15bit的源網(wǎng)絡端口，和16bit的目的網(wǎng)絡端口，也就是說，GENEVE傳遞的數(shù)據(jù)更多。

盡管有這些因素的存在，GENEVE的結果要好于VXLAN。首先，這個結果表明了，GENEVE能很好的兼容VXLAN，因為就算是VXLAN的主場，GENEVE最后還是贏了。但是兼容性并不能解釋最后的現(xiàn)象，文章本身也沒有分析原因，只是提到了UDP checksum。OVN默認打開了GENEVE上的UDP checksum。因為Linux系統(tǒng)內(nèi)核的一些優(yōu)化，使得GENEVE數(shù)據(jù)包被網(wǎng)卡收到之后，網(wǎng)卡會計算并驗證外層UDP的checksum。如果驗證通過了，網(wǎng)卡會匯報給系統(tǒng)內(nèi)核。這樣系統(tǒng)內(nèi)核在解析GENEVE時，將不再計算內(nèi)層報文的任何checksum。相應的網(wǎng)絡數(shù)據(jù)處理會更快一些。而VXLAN協(xié)議規(guī)定外層UDP的checksum應該為0，這樣外層UDP的checksum就沒有辦法被驗證，而內(nèi)層報文的checksum需要再計算一遍，相應的網(wǎng)絡數(shù)據(jù)處理就要慢一點。

[1] https://blog.russellbryant.net/2017/05/30/ovn-geneve-vs-vxlan-does-it-matter/

[2] https://tools.ietf.org/html/draft-ietf-nvo3-geneve-06

[3] http://www.openvswitch.org//support/dist-docs/ovn-architecture.7.html



關鍵詞：協(xié)議,虛擬,網(wǎng)絡

74
73
25
news

版權所有? 億企邦 1997-2025 保留一切法律許可權利。

為了最佳展示效果，本站不支持IE9及以下版本的瀏覽器，建議您使用谷歌Chrome瀏覽器。 點擊下載Chrome瀏覽器
關閉