剖析SDN設備硬體架構　專屬／開放型各有考量

除了網路虛擬化 NSX也可以是SDN

首先，必須要能夠集中管理配置，管理者不用到不同的設備、Console、管理介面去做分別的網路與安全設定。在圖2內，NSX可以由單一集中管理介面設定在用戶資源池內的所有網路功能，不必到不同介面去進行配置。

▲ 圖2 NSX經由單一集中管理介面，即可設定用戶資源池內的所有網路功能。

而且，管理者可以直接利用API來指揮NSX進行配置，如圖3所示。

▲ 圖3 利用API來指揮NSX進行配置。

而當然，一個具備API的軟體定義網路，當然也能透過雲平台，如圖4所示以vRealize Automation搭配NSX來進行配置。

▲ 圖4 以vRealize Automation搭配NSX進行配置。

必須要符合能夠「集中管理」、「程序化」兩個條件才能被稱為軟體定義網路，可以說是業界的共識。但接下來，各家廠商怎麼做出其認知的軟體定義網路方案，方式就南轅北轍了，控制轉發層不見得分離，方案不一定走開放架構。

接下來的文章與下篇投稿內容，將會和大家討論三種業界中不同的SDN方案作法：專屬式硬體SDN架構、開放式硬體SDN架構，以及網路虛擬化SDN方案。

認識專屬型硬體式SDN

首先，第一種稱為專屬型的硬體式SDN方案，許多大家熟悉的企業硬體網路廠商SDN方案都廣義地屬於這一類，如圖5所示。這一類方案會具備此廠商專屬的SDN控制器提供集中的網路組態管理以及對外API的接入口，而此SDN控制器僅會控制此廠商，甚至特定型號的實體交換器。

▲ 圖5 第一類SDN方案：專屬型硬體SDN。

以這類SDN方案來說，能夠透過交換器上硬體晶片提供低延遲、高頻寬的大量網路封包轉發，而且達成多台網路交換器的集中配置，並透過API與外掛程式（Plugin）整合常見的雲平台（如vRealize Automation、Openstack等等）或敏捷式開發組態管理工具（如Ansible、Puppet、Chef）。這類廠商通常都已經是網路硬體設備大廠，是企業信任且已經在使用的資料中心網路廠商。

基於硬體晶片的SDN方案能夠把網路二層三層功能做得很好很快速，但有兩個問題：資料中心內的網路功能僅需要考慮二層三層嗎？這一類方案能夠進行虛擬化環境或Container的管理運作嗎？

通常資料中心內二層三層的快速轉發是所謂的Stateless服務，一個個網路封包能夠很快速地藉由ASIC晶片或TCAM Table在不同機器間進行高速的轉送。但資料中心的上層服務通常都必須具備連線狀態（Stateful），需要大量記憶體來處理連線紀錄。防火牆功能必須具備連線表（Connection Table），負載平衡器需要Session Table，NAT功能需要NAT連線表，還有VPN功能等等，而這類功能基本上就不是硬體晶片擅長的部分，在業界通常都是以CPU/Memory來處理。

所以問題來了：當用戶希望以軟體定義方式提供「所有」的資料中心網路功能時，他們會發現硬體式SDN方案能提供的是網路二層三層，交換與路由的SDN整合。但談到防火牆、負載平衡器、NAT等等上層服務時，就不是這類硬體晶片方案擅長的部分，而需要和其他的方案整合，大幅增加環境的複雜度以及一堆客製、版本不合、功能缺乏的問題。

而其二，當轉發層是硬體交換機，此時這類方案對於虛擬化方案或新穎的Container方案之管理及可視性就大幅降低了。硬體交換機要怎麼看到兩個虛機間的封包傳輸？兩個在同一個Host內的Container交換，硬體交換機要怎麼控制？

在現代化資料中心，業務虛擬化比例經常都接近80%以上甚至到100%的環境，此類硬體SDN方案的應用情境就極度縮減了，或是又必須搭配很多的Agent-based方案來進行控制。而同樣地，這是這類方案在架構上就有先天不易支援虛擬化或容器架構的弱點。

但此類硬體SDN方案是有重要使用情境的：如果大家現在要建新的資料中心，或是現有資料中心的核心網路要進行提升，企業原本就會有專案預算進行實體交換器的採購。與其採用傳統架構、分散手動管理的網路交換器，IT肯定會考慮是不是在建立資料中心核心網路的同時，也導入軟體定義網路方案來達成集中管理的目的，更進一步搭配後續可能會導入的雲平台∕自動化方案。也因此，在全球或台灣一些大型的建廠或新建資料中心的資訊專案內，常是這類專屬硬體式方案的活躍時機。

簡介開放型硬體式SDN

同時有另一種趨勢，可稱其為開放型的硬體SDN方案，如圖6所示，代表的廠商包括Big Switch Networks以及Cumulus Networks。

▲ 圖6 第二類SDN方案：開放型硬體SDN。

這一類方案，SDN廠商提供的是控制器，但底層的網路交換器則提供開放、標準的選擇，或是大家常用所謂的「白牌交換器」來稱呼。這些白牌交換器包括大家熟知的智邦（Accton）、廣達（Quanta）、Dell等通常會遵循開放的標準如ONIE（Open Network Installation Environment），所有遵循這個標準的交換器都能透過Cumulus或是Big Switch Networks方案進行集中式的控管。下面的鏈結內列出了目前所有支援ONIE標準的交換器廠商與型號：

http://www.opencompute.org/wiki/Networking/ONIE/HW_Status

因為此類白牌交換器採用標準、開放的硬體配置以及公版的晶片，所以這類方案在價格上即使把控制器端納入，與第一類方案比較，通常也是較為低廉。第一類方案內擅長的網路二層三層快速轉發、集中管理、程序化配置也都是此類方案能夠達成的優勢，也因此，大家可能逐漸在一些IT新聞上看到部分大型的雲資料中心開始大量地導入此種方案。

但同樣地，因為第二類方案也著重在硬體交換器的集中管理與配置，第一類方案遭受到的弱項：網路四到七層的服務缺乏，虛擬環境∕Container環境的管理與可視性，也同樣是這類方案的弱點。

可以這麼說，第一類方案（專屬式硬體SDN方案）及第二類方案（開放式硬體SDN方案）彼此間是競爭者，而適用的場景均集中在建立新資料中心或提升現有資料中心的核心網路底層。

待續

在下期投稿內，將繼續討論第三種分類「網路虛擬化SDN方案」，或是一般來說業界所稱的Overlay-SDN方案架構與使用情境，以及這三種不同方案間的最佳使用情境，到底是什麼？

＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，持有VCIX-NV、VCAP-DTD、CCIE、CISSP等證照，目前致力於網路虛擬化、軟體定義網路暨分散式安全防護技術方案的介紹與推廣。＞