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