OpenFlow交換機就是OpenFlow交換機，如果用OpenFlow交換機不是結(jié)合SDN的方式來使用，而是用其實現(xiàn)傳統(tǒng)的基于MAC的二層轉(zhuǎn)發(fā)或者基于IP的三層轉(zhuǎn)發(fā)，那么就沒有必要折騰了，何必哪?費力費錢還沒有收益。尤其是運營商，對于OpenFlow的態(tài)度，盡管他們又各種各樣的設(shè)備管理和維護(hù)問題，但是如同他們不自研網(wǎng)絡(luò)設(shè)備，再加上錢多人懶，是不會對運營商網(wǎng)絡(luò)做出什么SDN方面的改進(jìn)的，除了某些項目名稱。
OpenFlow交換機就是基于流標(biāo)項的轉(zhuǎn)發(fā)，可以結(jié)合SDN被用于結(jié)合業(yè)務(wù)的轉(zhuǎn)發(fā)，無需考慮MAC學(xué)習(xí)，無需考慮是否有路由，而是用戶或者管理員根據(jù)自己的需要來配置交換機。所以利用BMC或者M(jìn)VL的傳統(tǒng)商用交換芯片來做OpenFlow的開發(fā)，會導(dǎo)致表項容量小、OpenFlow標(biāo)準(zhǔn)支持不完全、對交換芯片其他處理流程組件浪費的現(xiàn)象。
OpenFlow像衛(wèi)峰書中講的那樣，SDN和OpenFlow關(guān)系，二者是不能劃等號的。例如OpenStack中，如果Neutron下的plugin用Linux bridge，那么這個就不是SDN了嗎?顯然答案為仍然是SDN網(wǎng)絡(luò)。SDN我理解的是一種思想，而不是一種方案或者功能。所以網(wǎng)絡(luò)很多做法都是和SDN有著扯不清的關(guān)系，但是這個絕非像某些大的互聯(lián)網(wǎng)公司扯自己的產(chǎn)品硬跟SDN掛鉤那樣，因為他們的產(chǎn)品開發(fā)時研發(fā)和測試人員腦袋里連SDN的概念都沒有聽說過，現(xiàn)在國內(nèi)互聯(lián)網(wǎng)公司和很多的設(shè)備商都還只是停留在觀望和接觸的狀態(tài)，并沒有什么實質(zhì)的SDN產(chǎn)品或者方案。并且SDN并不代表完全脫離硬件，有的云計算公司對于網(wǎng)絡(luò)虛擬化中有一些硬件參與就不認(rèn)可是SDN，難道說要全世界的人都用一臺服務(wù)器，里面的每人用的虛擬機都用虛擬端口通信才算是真的SDN嗎?這個邏輯充滿了荒謬。SDN只是一種思想，一種站在用戶角度、站在管理員角度可以參與管理和控制網(wǎng)絡(luò)底層轉(zhuǎn)發(fā)決策需求的滿足和實現(xiàn)。底層轉(zhuǎn)發(fā)的實現(xiàn)是否是純軟件或者有多大程度的硬件參與并不重要。如果一個人堅持這么認(rèn)為，我只能說這個人不懂SDN。而OpenFlow交換機提供的基于流標(biāo)項的轉(zhuǎn)發(fā)方式，正是SDN用硬件作為底層轉(zhuǎn)發(fā)時所需要的，因此可以說OpenFlow交換機是SDN底層用硬件實現(xiàn)的一種方式，而虛擬網(wǎng)絡(luò)里采用OpenVswitch互通虛擬機則是用OpenFlow流表實現(xiàn)SDN思想的一種純軟件方案。
OpenFlow作為SDN底層實現(xiàn)的一個理想選擇，在轉(zhuǎn)發(fā)層面確實有很多優(yōu)勢，但是個人認(rèn)為也有很多需要注意的點：
如前文所述，將控制平面和轉(zhuǎn)發(fā)平面進(jìn)行分離，減少了控制點，增加了控制平面的負(fù)擔(dān)，需要比以往有更強的CPU計算能力的設(shè)備才能堪重負(fù);SDN強調(diào)管理員在管理網(wǎng)絡(luò)方面的能力，這些無疑對管理員的技能和對所管理的業(yè)務(wù)熟悉度有了更高一步的要求，這點與網(wǎng)絡(luò)設(shè)備智能化、自動化、傻瓜化的發(fā)展思想多少是有點相悖的;OpenFlow的多表項為業(yè)務(wù)實現(xiàn)提供了靈活性，但是這無疑增加了設(shè)備的成本，并且為交換芯片驅(qū)動開發(fā)人員在軟件中記錄和維護(hù)配置表項、容錯等研發(fā)工作提供相當(dāng)大的復(fù)雜度;OpenFlow在轉(zhuǎn)發(fā)層面相比于傳統(tǒng)方式有了很大提高，應(yīng)該是先兼容以前所有的轉(zhuǎn)發(fā)方式，但是現(xiàn)在的標(biāo)準(zhǔn)中，還有很多傳統(tǒng)轉(zhuǎn)發(fā)方式支持但是OpenFlow中不支持的，比如我要實現(xiàn)某個出端口中SIP=1.1.1.1的報文全丟棄，標(biāo)準(zhǔn)中暫時沒有出現(xiàn)匹配出端口的的內(nèi)容，希望OpenFlow標(biāo)準(zhǔn)盡快得到完善;傳統(tǒng)交換機中還有很多非產(chǎn)生直接轉(zhuǎn)發(fā)意義或動作方面的功能，比如流控、隊列調(diào)度、WRED等方面都要涉及交換芯片MMU，而這些OpenFlow是很難對各個廠家通過標(biāo)準(zhǔn)而統(tǒng)一的，所以O(shè)penFlow標(biāo)準(zhǔn)化方面還有很多的工作要做;虛擬機、iptables為了提高物理服務(wù)器CPU的利用率，出現(xiàn)了使用虛擬機的概念，這樣一臺物理設(shè)備有多臺虛擬機，分別“計算”處理不同的數(shù)據(jù)，如果物理服務(wù)器是多核的情況下，可以說是真正的并行計算不同的數(shù)據(jù)。當(dāng)一臺物理機內(nèi)有很多虛擬機時，虛擬機的通信和隔離就有了需求，因為可能在一臺物理機內(nèi)的虛擬機承載著不同的業(yè)務(wù)，而承載相同業(yè)務(wù)的虛擬機分布在多臺物理機上。打個比方，中國每個城市是一臺物理機，每個城市里的企事業(yè)單位是不同虛擬機;同一臺物理機的每個企事業(yè)單位之間是無法用自己的內(nèi)網(wǎng)直接通信的，他們必須都將內(nèi)網(wǎng)地址轉(zhuǎn)化為外網(wǎng)地址才能在公網(wǎng)上交互數(shù)據(jù);而每個企事業(yè)單位可能有很多分地，比如可能騰訊在北京有幾個地方，而在廣州、深圳和上海還有分地，所有騰訊的這些分地內(nèi)網(wǎng)都是想通的，其他企事業(yè)單位在任何處的公司里都可以通過內(nèi)網(wǎng)轉(zhuǎn)換后利用外網(wǎng)訪問騰訊提供在公網(wǎng)的服務(wù)，這個就是不同虛擬機之間的隔離和互通。如果阿里內(nèi)網(wǎng)的一臺設(shè)備，想SSH到騰訊的一臺內(nèi)網(wǎng)機器上，必須給騰訊的這臺設(shè)備賦予一個公網(wǎng)的IP，且通常情況下，從阿里這臺設(shè)備上發(fā)出的報文到達(dá)騰訊內(nèi)網(wǎng)時，會通過一種功能將報文的目的IP從公網(wǎng)地址轉(zhuǎn)成騰訊的內(nèi)網(wǎng)IP地址，這種功能就是NAT。為了進(jìn)制這種現(xiàn)象的發(fā)生，騰訊的內(nèi)網(wǎng)可以通過iptables配置這臺設(shè)備進(jìn)制外網(wǎng)ssh連接。iptables是云計算中虛擬機常用的技術(shù)，NAT是iptables的一個功能子集，就像對報文丟棄是OpenFlow規(guī)則中動作的一種一樣。而云計算是把所有相關(guān)的管理節(jié)點和計算節(jié)點進(jìn)行多虛一，看做是一個大的整體并進(jìn)行統(tǒng)一的資源管理和調(diào)度;在所有的這些物理機上的虛擬機之間的通信和隔離，有很多種實現(xiàn)方案，但從技術(shù)方案上說基本都是二層vlan隔離或者對vlan數(shù)目要求過多時的vxlan方案及nvgre方案。拿OpenStack舉例，Neutron下面的plugin僅官方支持的就有十來種之多，還有很多非官方維護(hù)的，OVS的一出現(xiàn)就受到關(guān)注有其道理;因為最初虛擬機之間的隔離是采用Linux bridge技術(shù)，非常的不靈活而且配置無法模板化，對于搭建復(fù)雜的虛擬網(wǎng)絡(luò)是無法滿足的;并且對于虛擬網(wǎng)絡(luò)的調(diào)試、監(jiān)控、故障定位都是非常不便的，而且搭建復(fù)雜拓?fù)涞墓δ芤埠芏酂o法滿足;Openvswitch的出現(xiàn)解決了這些問題，并引入了QOS、鏡像、CFM、netflow等功能，而且它還可以支持OpenFlow標(biāo)準(zhǔn)，最重要的是有一套用C語言的開源實現(xiàn);導(dǎo)致其在網(wǎng)絡(luò)虛擬化里得到了很大的重視。這部分內(nèi)容在論文《Extending Networking into the Virtualization Layer》和《VirtualSwitching in an Era of Advanced Edges》有非常詳細(xì)的介紹。
OpenStackOpenStack現(xiàn)在是一個非常火的開源社區(qū)，官方有大量的資料和大牛貢獻(xiàn)代碼及文檔。但是從國內(nèi)的分享來看，大部分是基于如何搭建出某種簡單的環(huán)境，尤其是網(wǎng)絡(luò)這塊如何搭建，以保證能建立虛擬機后在虛擬機內(nèi)部可以正確的訪問各種網(wǎng)絡(luò)，但是從介紹來看絕大多數(shù)的分享者對OpenStack的底層技術(shù)并不了解，甚至出現(xiàn)了兩臺云主機在兩個vlan就無法ping通的實驗。因為網(wǎng)絡(luò)虛擬化在OpenStack進(jìn)行商業(yè)活動中提供服務(wù)的重要性，每年的OpenStack會議都有大量的會議在討論網(wǎng)絡(luò)相關(guān)的技術(shù)。而此時也是SDN體現(xiàn)價值的一個重要案例。OpenStack的缺點已經(jīng)被各種吐槽，我個人認(rèn)為OpenStack為了獲取最廣泛的支持，采取了吸納百家的策略，就是現(xiàn)在項目眾多，耦合性也越來越大;最麻煩的是，對于計算、網(wǎng)絡(luò)和存儲的虛擬化，它不是采用了一種經(jīng)過考慮后慎重選擇一種最有前途的然后進(jìn)行專注和持續(xù)積累的方式，而是選擇了每種技術(shù)都支持且經(jīng)過抽象封裝了一層中間層，這就導(dǎo)致的問題是OpenStack的專注無法集中，開發(fā)者的力量被分散，代碼需要經(jīng)過多次的封裝，自然也就效率非常低下。商業(yè)版本除了修正其固有的BUG外，還必須解決上述問題。
VXLAN/NVGREVXLAN和NVGRE的兩種方案都是為了解決大二層中Vlan ID個數(shù)不夠的問題，除了衛(wèi)峰所述的封裝導(dǎo)致的傳輸效率降低和負(fù)載均衡受影響外，還會對硬件設(shè)備的要求上有進(jìn)一步提高，據(jù)我所知，現(xiàn)在BCM或MVL幾乎只有一兩款芯片產(chǎn)品支持，這對OpenFlow的本意來說本身就是個挑戰(zhàn);更別說那些通過收購其他網(wǎng)絡(luò)公司來完善自己產(chǎn)品布局的某些企業(yè)下這些收購后的子公司，他們的產(chǎn)品更是在SDN上沒有什么大的進(jìn)展。
從ACL中吸收了經(jīng)驗而改進(jìn)形成的OpenFlow規(guī)則，結(jié)合現(xiàn)在盛行的SDN概念，已經(jīng)開出了很多花朵，但是這些花朵能否最后能秋季成熟還是個未知數(shù)。但是OpenFlow確實在QOS分類、實現(xiàn)ACL的防火墻的安全功能、在現(xiàn)有網(wǎng)絡(luò)上對新協(xié)議進(jìn)行試驗都是十分有效的。SDN是一個對現(xiàn)有網(wǎng)絡(luò)考慮了兼容性的框架，如果結(jié)合具體的業(yè)務(wù)需求，將OpenFlow的規(guī)則利用起來，必能給客戶帶來收益，給云計算、設(shè)備商和芯片商等企業(yè)帶來發(fā)展的機會和激烈的競爭。OpenFlow到底是會革命成功大放光彩，還是僅是一種過渡形態(tài)的曇花一現(xiàn)，可能后者的概率要大一些。
轉(zhuǎn)型的最終目的 -提質(zhì)降本增效
分享到微信 ×
打開微信，點擊底部的“發(fā)現(xiàn)”，
使用“掃一掃”即可將網(wǎng)頁分享至朋友圈。