<del id="aymay"></del>
SDN可以將你帶到現(xiàn)有網(wǎng)絡(luò)沒有到過的地方，但你可能要重新考慮轉(zhuǎn)發(fā)表。
SDN被認為是企業(yè)實現(xiàn)完全虛擬化網(wǎng)絡(luò)的主要途徑，乃至實現(xiàn)完全虛擬數(shù)據(jù)中心的主要方式。
所有這些虛擬化的主要好處之一是規(guī)模。不受硬件限制，SDN環(huán)境將能夠根據(jù)用戶的變化而變化，這帶來了隨時隨地實現(xiàn)數(shù)據(jù)連接的時代。
然而，如果是這樣的話，為什么還有這么多圍繞虛擬網(wǎng)絡(luò)平臺的可擴展性限制的問題出現(xiàn)呢?
轉(zhuǎn)發(fā)表限制
事實證明，雖然控制平面和轉(zhuǎn)發(fā)平面的分離可以帶來很多好處，但虛擬網(wǎng)絡(luò)仍然受到轉(zhuǎn)發(fā)表能力的限制，虛擬網(wǎng)需要轉(zhuǎn)發(fā)表來記錄推動數(shù)據(jù)包到其最終目的地所需要的MAC地址和其他網(wǎng)絡(luò)數(shù)據(jù)。事實上，隨著來自物理層基礎(chǔ)設(shè)施以及快速變化的虛擬基礎(chǔ)設(shè)施的命令和請求充斥著轉(zhuǎn)發(fā)表，這種挑戰(zhàn)會不斷增加。到目前為止，我們已經(jīng)開發(fā)了一些技術(shù)來解決這個問題，例如最短路徑橋接和IP式數(shù)據(jù)包淹沒，但問題是現(xiàn)在的虛擬網(wǎng)絡(luò)平臺是否能夠為企業(yè)提供可擴展性。
顯然，我們可以想到的第一種解決方案是改進流量表本身。這是Corsa Technology公司在其新的OpenFlow硬件數(shù)據(jù)平面(DP6420和DP6440)中采取的方法，這兩個數(shù)據(jù)平面旨在用于數(shù)據(jù)中心和運營商環(huán)境中。該設(shè)備提供本地OpenFlow 1.3支持，并能夠處理多個流量表和數(shù)百萬流量，支持快速創(chuàng)建流量表以及每秒配置數(shù)萬流量修改。它們還支持多種網(wǎng)絡(luò)端口配置，包括48x10GbE、4x40GbE和4x100GbE。
如果數(shù)萬流量命令變成了數(shù)千萬(企業(yè)很可能會部署超大規(guī)模架構(gòu))呢?你怎樣能夠容納(以合理的成本)大量TCP連接和UDP流量?其實這些問題是你無法承受的，你應(yīng)該使用目前在大多數(shù)2層和3層網(wǎng)絡(luò)交換機部署的基于目的地的轉(zhuǎn)發(fā)方法。通過智能架構(gòu)，SDN設(shè)備能夠通過自動查詢和API編程來進行正確的配置。轉(zhuǎn)發(fā)表本身的變化速度其實微乎其微。事實上，你會看到比現(xiàn)在更小的轉(zhuǎn)發(fā)表，因為控制器會不斷地切除死鏈接，而不是覆蓋MAC地址到每個虛擬交換機。
