作者:楊雨
“MTU的值設置多少合適呢?現(xiàn)在最佳實踐是設置到9000。”
“其實OpenFlow只是一個概念,從這幾年SDN的發(fā)展來看,它并沒有成為一個事實的標準。”
“大規(guī)模云平臺對SDN的要求,第一是網絡基礎架構要可擴展,第二是控制器可擴展,第三是數(shù)據(jù)平面無集中式單點,第四是跨集群的擴展網絡。”
“在基礎架構上,如果用Tungsten Fabric,只要是用于生產環(huán)境的話,選擇IP CLOS架構就行,沒必要再去折騰Fabric等二層架構。”
“Tungsten Fabric的本質是基于MPLS VPN的SDN。”
“跨集群的互聯(lián),或者叫多云互聯(lián),主要有兩種模式:基于控制器之間的互聯(lián),基于Cloud Gateway之間的互聯(lián)。”
本文整理自TF中文社區(qū)技術代表楊雨在TF中文社區(qū)“2020第一次Meetup”上的演講,分享Tungsten Fabric對大規(guī)模云平臺的支持。本文已經主辦方和演講者審閱授權發(fā)布。
在TF中文社區(qū)1月7日的“2020第一次Meetup”活動上,來自Tungsten Fabric技術研發(fā)和一線使用者、關注多云互聯(lián)的從業(yè)者、開源SDN的愛好者們互相切磋、支招,現(xiàn)場氣氛熱烈,精彩內容不斷。Tungsten Fabric在中國的廣泛應用正在越來越真切地走來。
本次演講及TF中文社區(qū)“2020第一次Meetup”活動資料,請在“TF中文社區(qū)”公眾號后臺點擊“會議活動-Meetup”領取。
今天的分享偏技術一些,首先我們來看SDN的本質,然后從Tungsten Fabric架構上解析為什么比OVS更好,為什么能支撐更大的場景。
先來看云對網絡的要求。首先是租戶隔離,IaaS就是多租戶,對于地址重用的要求,以VLAN的傳統(tǒng)方式也是可以實現(xiàn)的。另外,傳統(tǒng)VXLAN的協(xié)議或OVS的協(xié)議,只提供二層隔離的能力,沒有三層隔離的能力,只要你的機器綁到外網IP,或者綁到公共的路由層面上,三層是可以互通的,所以說在租戶隔離的層面,也有三層隔離的需求。
其次,云需要網絡支持虛擬機跨機柜的遷移。VXLAN的話還要跨數(shù)據(jù)中心大二層,不是說不可以實現(xiàn),但除了網絡要求,還有存儲的要求,比較難。虛擬機跨機柜的遷移,最難的是什么?傳統(tǒng)網絡架構,就是接入-匯聚-核心,路由器以下都是二層架構,機器可以在不同機架上遷移,但一個數(shù)據(jù)中心,云足夠大的時候,二層基礎網絡是支撐不了整個云的,不同機架在不同三層里面,這時虛擬機做遷移就要要求IP地址不能變。
另外,還有網絡功能和服務的要求。在云上面都是共享的資源池,如果以負載均衡為例,將一個性能強大的硬件負載均衡虛擬化給多個租戶使用,還是切換成小的負載均衡虛擬機實例給不同租戶使用?這里就提出網絡虛擬化和網絡功能虛擬化的需求,來支撐IaaS的運行。
網絡虛擬化,主要應用的是Overlay的技術,是SDN用到的其中一個技術,用的比較多、比較標準的技術,包括VXLAN、GRE、STT、GENEVE,以及Tungsten Fabric用到的MPLSoverUDP和MPLSoverGRE,主要的方式,是把二層的幀在vTEP上進行三層封裝,通過VXLAN隧道傳輸?shù)綄Χ恕?/p>
這樣做的好處是,增加了租戶的數(shù)量,傳統(tǒng)VLAN是4096,如果VXLAN就是2的24次方;其次底層傳輸基于IP網絡,擴展性遠大于二層網絡,使得網絡能擴展,虛擬機在不同物理網段上遷移。但同樣也帶來一些工作,如何讓兩邊的設備建立通信?第一建立VXLAN隧道,這是SDN控制器要做的事,第二是交換兩邊的MAC地址信息。
TF中文社區(qū)3月Meetup活動,將聚焦Tungsten Fabric與K8s的集成,由重量級嘉賓分享Tungsten Fabric與K8s的部署和實踐,詳細演示操作過程,并解答關于Tungsten Fabric和K8s的一切問題。關注“TF中文社區(qū)”公眾號,后臺點擊“會議活動-Meetup”領取。
有兩個VM,在兩個不同的主機上,就是通過Overlay來解決二層通信問題的。比如ESX1要和ESX2通信,ping的時候首先發(fā)ARP請求,那對應的MAC地址是多少?對于VXLAN來說就要有一張轉發(fā)表,MAC2需要通過VTEP2的IP,去做一個封包,再傳輸?shù)絍TEP2,解封裝后,再傳輸?shù)较鄳臋C器里去。怎么建立這個轉發(fā)表?就是SDN需要去做的事情。
一種是自學習,只要VM1發(fā)了一個ARP請求,到達vTEP網關,它就會去洪泛請求,廣播到和它建立隧道的vTEP節(jié)點上去,看誰反饋ARP reply,就知道對端的IP地址,可以建立一個轉發(fā)表。但這樣會有很多消耗,ARP地址也有老化的過程,一旦老化,就需要重新去學,直觀體驗是ping包時間會很長。如果是大規(guī)模的網絡,頻繁洪泛,會對網絡可靠性帶來很大的挑戰(zhàn)。
SDN大部分情況下是和云管平臺做結合,知道在這個虛擬化服務器上,有哪些虛擬機,提前把MAC地址表或轉發(fā)表下發(fā)到vTEP設備上,這就是SDN控制平面要做的事情。
在Open vSwitch這個方案里面,就是通過數(shù)據(jù)庫和RabbitMQ,去下發(fā)一個OVSDB的命令,建立相應的流表,讓虛擬機知道要往哪兒走。Tungsten Fabric也有相應的機制,后面會介紹。
數(shù)據(jù)平面的作用,就是根據(jù)轉發(fā)表,對二層的幀進行轉發(fā),另外進行封包和解包。這里提一下MTU,這是這個二層的值,幀的transfer unit,為什么要設置很大?首先VXLAN協(xié)議會增加一些Hdr,UTP的Hdr,VXLAN的Hdr,封包的時候如果不做處理的話會超過1500,網卡會不發(fā)這個幀。早期做OpenStack經常會遇到trouble shooting的MTU問題,后來解決方案是通過DHCP的Agenter,設置了一個參數(shù),如果網卡MTU是1500,就默認為14XX,自動降低,這樣虛擬機的數(shù)據(jù)幀才能通過二層網卡。那么MTU的值設置多少合適呢?現(xiàn)在最佳實踐是設置到9000。在vTEP這一塊就是封包和轉發(fā),根據(jù)實際測試,如果增加MTU值,對吞吐量有很大的提高。
剛才說了SDN做的事情,控制下發(fā)轉發(fā)表和傳輸,接下來說一下SDN的分類。按流派來區(qū)分,SDN可分為軟件和硬件,區(qū)別就是vTEP是在vRouter上,還是在交換機的硬件轉發(fā)上,看解封包在哪里。硬件一般都是私有協(xié)議,像Cisco用的就是OPFlex。軟件也有很多不同的項目,其中Tungsten Fabric是最產品化的一個。
按照控制器分類,有集中式和分布式。集中式的控制器有OpenFlow、OVSDB,以及Tungsten Fabric使用XMPP(一個聊天的協(xié)議)。我們可以把Neutron的Open vSwitch理解為OVSDB協(xié)議,Neutron是通過RabbitMQ把信令下發(fā)到具體的計算節(jié)點,計算節(jié)點的OVS Agent通過OVSDB的命令,把相應的流表增加到OVSDB交換機。
分布式的控制器,比如EVPN-VXLAN,就是使用了MP-BGP。
大家覺得哪種形式的控制器會更好一點呢?目前用OpenDaylight的項目有哪些?華為,華三等都在用,其控制器的SDN架構就是參照OpenFlow來做的。有些廠商自己有研發(fā)能力,基于自身的硬件設備,可以開發(fā)一個比較完善的產品。但在開源社區(qū),很少看到一個成功的OpenDaylight項目,只是提供了一個框架和一些組件,不能很快基于開源項目run起來。其實OpenFlow只是一個概念,從這幾年SDN的發(fā)展來看,它并沒有成為一個事實的標準。
反而是OVSDB起來了,應用在Neutron軟件的控制,還有交換機的控制上。比如Tungsten Fabric早期的BMS實現(xiàn),虛擬機要和裸機通信,裸機通過VLAN TAG,上到TOR交換機,再通過VLAN到VXLAN的轉換,到達虛擬網絡。其中VLAN到VXLAN的轉換,就是通過OVSDB協(xié)議下發(fā)的。你的交換機,理論上只要支持OVSDB協(xié)議,就可以做BMS場景。
我自己更傾向于這種分布式的控制器。因為集中式的永遠會有瓶頸,無論是軟件瓶頸,還是性能瓶頸。而EVPN-VXLAN的核心協(xié)議是MP-BGP,BGP的擴展性有多大?看看現(xiàn)在Internet骨干網,跑的就是BGP協(xié)議。
MP-BGP的協(xié)議,通過控制器下發(fā)流表信息,再通過BGP協(xié)議去交互,使用的時候只要針對你的相應架構,去做相應BGP協(xié)議的擴展性設計就可以。
針對Tungsten Fabric來說,其實是集中式和分布式兩種流派的融合,既用到集中式的架構,在對外的連接上,又采用了分布式控制器的技術。
總結大規(guī)模云平臺對SDN的要求,第一是網絡基礎架構要可擴展。如果采用二層架構,瓶頸就是在基礎架構上,受限于交換機的端口數(shù),二層交換機采用生成樹協(xié)議,對于大規(guī)模網絡平臺,如果運維水平較差,接出一個環(huán)路出來,就很危險。
第二,控制器是可擴展的。無論集中式還是分布式,在架構上一定是可擴展的,至于能支持多大的量,就是代碼實現(xiàn)的問題了。
第三,數(shù)據(jù)平面無集中式單點。談到SDN的實際應用,運維是一個比較大的挑戰(zhàn),無論是做開發(fā)還是做運維出身的人,最重要的是理解虛擬機之間,虛擬機到外網之間,數(shù)據(jù)流量是怎樣的?應該通過什么命令去看這些流量,去trouble shooting,就像以前傳統(tǒng)網絡運維怎么去抓包一樣。對于擴展性來說,要實現(xiàn)傳統(tǒng)網絡的SNAT、floating IP等,每個項目都有不同的實現(xiàn)方式,實現(xiàn)過程中沒有單點的話,在架構上就是可以擴展的。
第四,跨集群的擴展網絡。架構上無論怎樣擴展,總是有極限的,對于一個單集群來說,總會到達一個瓶頸。如果要建一個更大的集群,可以橫向擴展多個集群出來,形成一個大的資源池。那么面臨的問題是,網絡是否需要互通。如果部署一個高可用業(yè)務,跨集群的情況如何做互通,主流的一些高可用組件,需要跨兩個集群二層互通,都需要SDN去支持這樣的需求。
在基礎架構上,如果用Tungsten Fabric,只要是用于生產環(huán)境的話,選擇IP CLOS架構就行,沒必要再去折騰Fabric等二層架構。IP CLOS可以帶來足夠的擴展性和高性能,包括沒有供應商鎖定,建完以后基本不需要再動。
Leaf就是架頂式交換機,下面是子網,不同機架用不同子網,上層通過三層網關路由做通信,最主要的就是Leaf Spine之間三層怎么交互。瞻博網絡有個文檔介紹IP CLOS的白皮書,對OSPF、ISIS、BGP進行了控制平面上的對比,最佳建議是用eBGP來做交互。
Tungsten Fabric的本質是基于MPLS VPN的SDN。原來的VPN是解決多個site之間的互聯(lián),控制平面是BGP協(xié)議。到了數(shù)據(jù)中心里面,云之間的互聯(lián),一個物理機可以看做一個site,不同物理機之間借助VPN建立不同的隧道來打通,這就是Tungsten Fabric的本質。不同之處在于控制平面,Tungsten Fabric用的是集中式的控制器并通過XMPP協(xié)議控制vRouter的路由表。
簡單看一下Tungsten Fabric的功能架構,在多云支持上,包括VMware、OpenStack容器、BMS;網絡功能上,二層網絡、三層網絡、DHCP、DNS、QoS、防火墻、LB等都是支持的。
在部署的時候,控制器主要分為兩種節(jié)點,一種是Analytics Cluster分析節(jié)點,主要做流的可視化。另外一種Controller節(jié)點用來控制網絡,分為Configuration和Control Node,前者提供API,對接Neutron等云管平臺,API通過創(chuàng)建一個pod,在Configuration上記錄數(shù)據(jù)庫,轉換成相應的IF-MAP,控制器通過XMPP命令在vRouter上創(chuàng)建相應的接口,再把接口信息傳給不同的vRouter或外部網關及硬件設備,控制器核心協(xié)議是BGP協(xié)議。
控制器在整個Tungsten Fabric里就是一個router reflector,把所有的二層接口、MAC接口信息,三層路由信息全部存在這里,分發(fā)到不同的vRouter上面。對于云內的vRouter,用XMPP推送,對于云外的Gateway等,通過BGP推送。
其中,NETCONF協(xié)議不是用來推送路由信息的,主要用于和網絡硬件設備的一些配置下發(fā)。比如Tungsten Fabric中增加一個BMS服務器接入到Tungsten Fabric管理的虛擬網絡,Tungsten Fabric中的Device Manager會通過NETCONF將VLAN接口的配置和下發(fā)到TOR交換機,通過NETCONF建立接口。然后Tungsten Fabric控制器再通過OVSDB協(xié)議或EVPN-VXLAN協(xié)議去配置相應的VLAN-VXLAN的橋接網關。如果需要把虛擬網絡擴展到Gateway,NETCONF也會幫助創(chuàng)建相應的Routing instance配置。路由層面的交換信息,還是通過BGP來實現(xiàn)。
TF中文社區(qū)3月Meetup活動,將聚焦Tungsten Fabric與K8s的集成,由重量級嘉賓分享Tungsten Fabric與K8s的部署和實踐,詳細演示操作過程,并解答關于Tungsten Fabric和K8s的一切問題。關注“TF中文社區(qū)”公眾號,后臺點擊“會議活動-Meetup”領取。
Tungsten Fabric用到的數(shù)據(jù)庫,都是最近8年才有的,比如分布式數(shù)據(jù)庫的Cassandra、Zoo Keeper、RabbitMQ,在架構上是高可用、可擴展的,具體能擴展到多大的量,還是要看代碼實現(xiàn)。反過來看Neutron,本質就是一個數(shù)據(jù)庫,記錄了所有的信息,把所有的流表下發(fā)下去。
Tungsten Fabric的數(shù)據(jù)平面主要是通過vRouter來做轉發(fā),vRouter agent在user namespace的進程,安排控制器基于XMPP連接拿到一些信息,再下發(fā)到kernel的轉發(fā)平面。這里提供了二層隔離和三層隔離的功能,如果說同一個網絡的虛擬機,接在同一個vRouter下面,雙方的通信就在這里完成。不同租戶的網絡虛擬機,接了不同的VRF、Routing instance,也是不能通信的。
vRouter內置了很多網絡功能,比如DNS。Tungsten Fabric的DNS會根據(jù)主機的DNS配置來解析,如果遇到問題,可以檢查一下主機的DNS有沒有問題。DHCP應答也在這里,Neutron就不一樣,專門有一個DHCP agent跑在一個節(jié)點上,OVS在大規(guī)模情況下,如果接了超過1500個接口,基本上就會出現(xiàn)丟包,并且經常出問題。
Security Group在OVS的實現(xiàn)是通過和linux bridge關聯(lián)的iptables實現(xiàn)的,而在vRouter就是通過內置的ACL功能實現(xiàn)。Network Policy就是一個分布式的防火墻。Floating IP也是在vRouter做了一個NAT出去。
這里多談一下Link-Local,它的場景是什么?作為一個云服務商,要向客戶提供NTP服務、ATP、YUM源、等公共服務。怎么讓虛擬機在虛擬網絡內訪問到一個公共服務呢?一種方式是把這些網絡的路由打通,因為需要一個VTEP出口,通過cloud gateway把公共路由導進去,這樣帶來一個問題,所有ATP流量、下載流量都要通過cloud gateway,流量會跟大。Tungsten Fabric提供一個Link-Local的模式,就是一個169.254的地址,在網絡標準里只有一跳。在OpenStack虛擬機或AWS虛擬機里面,metadata服務就是通過169.254提供的。本機沒有這個路由,到網關上對地址做一層NAT,本機的NAT就會訪問到配置的Link-Local映射,繼而訪問到內部的服務。
在沒有增強的前提下,實測Neutron的OVS VXLAN的性能(只做MTU的優(yōu)化),最多達到兩個千兆的性能。而vRouter在不做任何優(yōu)化的前提下,能達到七、八千兆的性能。當然也可以利用DPDK、Smart NIC來做優(yōu)化,或者利用SR-IOV的透傳功能。
再來看看Tungsten Fabric的Packet交互。無論是同網段還是不同網段,虛擬機之間的交互,都是在vRouter層面轉發(fā)的,不會經過一個集中式的gateway。所以在虛擬機之間的數(shù)據(jù)交互層面,是沒有單點的。
另外一個比較重要的場景是SNAT。在OpenStack里面,如果虛擬機接了一個vRouter,可以通過vRouter的SNAT功能去訪問external的網段。Tungsten Fabric本身其實不提供SNAT,但也實現(xiàn)了SNAT功能,通過NS router(跑在計算節(jié)點的一個IP tables)做一個SNAT的轉發(fā),如果虛擬機要訪問一個非本網關的網絡,先到gateway,轉發(fā)后,再通過vRouter連接external的網絡。這里NS router的創(chuàng)建,需要OpenStack nova的scheduler來配合。
對于每一個網絡,都會有一個router去做轉發(fā),如果量太大,瓶頸可能就在NS router這里,但不會影響其它的網絡。
只要不在云內,都可以叫外網,要出外網有兩種方式:第一種是Floating IP,在vRouter做了一個NAT,把NAT后的IP通過MPLS over GRE的隧道,發(fā)布到Cloud Gateway的某個VRF里面,和外網通信。
第二種外部互聯(lián)的場景,假如要提供一個云服務,可以針對不同的運營商做不同的flouting IP,如果做L3 VPN或L2 VPN的專線接入服務,可以通過cloud gateway接入到不同的MPLS網絡,再把虛擬網絡路由到相應的VRF,整個就都連通了。這也是Tungsten Fabric強大的地方,MPLS VPN是和傳統(tǒng)的網絡天然互聯(lián)互通的。
跨集群的互聯(lián),或者叫多云互聯(lián),主要有兩種模式。
第一種是基于控制器之間的互聯(lián),把VPN、網絡和接口的信息,通過控制器之間建立EBGP連接來傳輸,這種方案叫Federation。
兩邊的vRouter只要三層可達就可以,比如一邊的B1要訪問另一邊的B3,兩邊是不同的控制器和VPN,MPLS VPN有個route target,一邊export一邊import,路由表看到另一邊的路由,進行路由信息交互,從而建立二層或者三層連接。Federation的方案是在控制器層面實現(xiàn)的,比較適合于同一個地域,同一個數(shù)據(jù)中心,有比較近的連接的情況。
第二種模式是通過cloud gateway之間的互聯(lián),把網絡的不同VRF,在cloud gateway之間建立EBGP鄰居,手動配置去import或export不同的RT,實現(xiàn)跨云的連接。需要注意的是,兩邊是不同的集群,IP地址管理不一樣的,分配地址的時候,要避免IP地址的重疊。
最后,和Neutron OVS進行對標的話,Tungsten Fabric可以說是完勝的。
基礎網絡方面,Tungsten Fabric可以擴展,Neutron OVS目前只能用二層網絡,無論集中式還是分布式,floating IP下沉到計算節(jié)點這一層,目前的組件里都沒有成熟的BGP方案,能夠把floating IP發(fā)布到邊界網關,OVS DVR和邊界網關只能通過二層連接。
對比架構方面,Tungsten Fabric是可擴展的,3個節(jié)點性能不夠,可以擴展到5個節(jié)點。Neutron OVS雖然是一個高可用架構,通過MySQL集群實現(xiàn)數(shù)據(jù)庫高可用,通過K8s實現(xiàn)API高可用,但計算邏輯不是分布式的,嚴重依賴RabbitMQ。如果使用DVR模式,每個計算節(jié)點要部署四個agent,帶來更多的topic,對RabbitMQ的性能是很大的挑戰(zhàn),只要出現(xiàn)一個RabbitMQ宕機或網絡抖動,會馬上執(zhí)行集群恢復機制,導致RabbitMQ很快死掉。
另外,在轉發(fā)平面上,Open vSwitch的性能沒有vRouter好;Tungsten Fabric的網絡功能更豐富,而Neutron的Octavia等原生LBaaS組件也有待成熟;多云互聯(lián)方面Tungsten Fabric基于MPLS VPN;和網絡設備的交互方面,Neutron只有ironic的networking generic switc driver,Tungsten Fabric支持BGP、NETCONF、EVPN-VXLAN等,基于標準的協(xié)議,涵蓋了瞻博網絡、思科、華為、銳捷等廠商的設備。
今天就先分享到這里。謝謝大家!
本次演講及TF中文社區(qū)“2020第一次Meetup”活動資料,請在“TF中文社區(qū)”公眾號后臺點擊“會議活動-Meetup”領取。
申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！
