數十年前，計算機科學家兼網絡作家Andrew S. Tanenbaum諷刺標準過多難以選擇，當然現在也是如此，比如軟件定義網絡模型的數量也很多。但是在考慮部署軟件定義網絡（SDN）或者試點之前，首先需要選擇要支持哪一種SDN模型。選擇錯誤就會浪費時間和成本，甚至可能將基于SDN的產品置于不利之地。在這里云端衛士將會與大家探討三種主要的SDN模型，闡述基本目標、機制以及每一種的缺陷。
SDN解析：網絡虛擬化模型
市場上最簡單的SDN模型就是網絡虛擬化模型，因初創公司Nicira流行，該公司2012年被VMware收購。網絡虛擬化的主要目標是消除LAN分區限制（這種限制存在于虛擬LAN（VLAN）標準中），通過在一些基于以太網的虛擬網絡架構中實現多播解決可擴展性問題。
為了實現這一點，網絡虛擬化平臺增加了一些軟件元素，通常而言是hypervisor，但是云構建軟件（比如OpenStack）也要通過創建VLAN的接口被修改，這個VLAN建立在傳統以太網頂部運行的隧道之上。網絡設備和運營完全不受影響，理論上數以萬計的虛擬網絡可以通過這種形式創建。
網絡虛擬化的最大好處就是支持多租戶云，而且不需要改變網絡自身。這種SDN模型在云網絡機制中可以輕松映射流行的虛擬化接口，比如OpenStack的Quantum或者大多數支持網絡分配的云DevOps工具。最終易于集成網絡配置和云服務配置。
最大的劣勢在于虛擬網絡處于網絡層之上，簡單地表現為網絡設備流量。這些設備無法優先考慮單獨的虛擬網絡或者報告他們的狀態，除非進行深度包檢測，來鑒定虛擬網絡報頭。由于作為云服務堆棧一部分的軟件創建了虛擬網絡，虛擬網絡只能同虛擬機鏈接，而非用戶和設備。
SDN解析：“漸進式”方法
第二種SDN模型可以稱之為“漸進式”模型。這種模型的目標就是加強網絡軟件控制和運營，但是是在當前網絡技術的邊界之內。為了實現這一點，網絡服務提供商可能需要對標，比如VXLAN、GRE、BGP和MPLS，并且用這些標準將網絡分區，成為虛擬社群，并且管理流量和服務質量。提供商可能需要將自身的解決方案結合到一套管理接口中，這套接口可以為云環境所用，通過DevOps工具或者云虛擬接口。
實施了這種SDN模型的網絡設備，完全集成網絡運營、FCAPS管理和網絡監控。常規流量工程原則適用，而且虛擬網絡理論上可以從服務器擴展到用戶，只要設備支持所選標準。
大多數SDN廠商目前實施了上面提到的所有網絡標準，但是一些可能并不能在所有設備上可用。這也是這種漸進式模型缺陷中的第一點，因此提供商需要評估現有設備支持的標準。目前為止更大的問題是具體的廠商提供的漸進式SDN模型，可能并不能同其他廠商的設備完全交互。這種方法也可能需要在管理系統以及云虛擬網絡或者DevOps接口之間進行特定集成，如果廠商不提供這些，運營商就會面臨風險。
SDN解析：OpenFlow模型
最后這種SDN模型就是OpenFlow模型，也是和SDN屬于最緊密相關的一個。OpenFlow取代了交換機或者路由器中傳統的、基于發現的轉發表創建，取而代之的是集中控制轉發，也意味著一個集中控制器項目對應每一個設備的轉發表。這樣做為中央控制節點提供了完整的規則，如網絡如何分段或者虛擬化，流量如何管理等。任何控制器和支持OpenFlow兼容版本的交換機的結合都可以用于這種SDN模型。
最后這種SDN模型最大的好處就是這種模型是基于SDN的概念來建立的。早起試用測試和部署認為OpenFlow能夠改善網絡有效性和可靠性，同時增加網絡利用率，因此減少了基礎架構成本和運營開支。如果OpenFlow交換機能逐漸普遍化，未來網絡就可能通過開放硬件構建，成本極低。這種模式的缺陷就是目前缺少所有必備組件的功能細節。OpenFlow為大多數主流交換機和路由器所支持，但是不一定能夠實現同傳統協議一樣的吞吐量。當然，支持OpenFlow的這種機制并不會顯著降低交換機成本。
現在有開源和商用的OpenFlow控制器可用，但是能做的比發送命令到交換機創建路徑、管理容量多不了多少。需要一套更高層級的管理應用。這些必須通過北向API連接到OpenFlow控制器，這些API并沒有標準化。早期OpenFlow實現需要運營商集成多重組件來創造功能軟件定義的網絡，并沒有完全的商業包可用。
三種模型哪種最佳？
云提供商糾結于VLAN的分段限制，或者面臨著VLAN的多播問題，首先可能關注虛擬化網絡的SDN模型。這種模型也能夠覆蓋漸進式SDN模型，盡管協調管理接口人存在很多問題。在數據中心網絡設備中投資體量巨大的提供商可能更傾向于這種方式來避免冗余成本。未來的主流發展方向應該會傾向于OpenFlow，因此應該關注支持OpenFlow的服務和設備提供商，尤其是在部署新設備的時候。
京公網安備 11010502049343號