作者： Colin Jao 饒康立 – VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化暨分散式安全防護技術方案的介紹與推廣。

在本次系列網誌首先我們談到軟體定義網路方案的要件：網路能夠被『集中管理配置』以及『提供開放API供外部系統呼叫』。接著在前篇網誌我們也和大家討論兩種不同的硬體式SDN方案的比較、方案優勢及較不適用的情境。接著這邊我們要和大家說明第三種SDN方案形式：網路虛擬化SDN方案，或是一般業界常稱的Overlay-SDN方案。

在網路虛擬化SDN方案，網路控制器並非直接控制底層的硬體交換器，而是透過一些封裝協定如VXLAN / NVGRE / STT / Geneve等方式，將上層的邏輯網路封裝 (overlay) 後，於底層的硬體交換器上進行實際的傳輸。控制器在這邊通常控制的是在虛擬環境Hypervisor / Container Host或甚至作業系統內的軟體構件，然後由這層軟體構件以上來構築邏輯網路方案。VMware NSX / Nuage等廠商的方案主要是屬於這一種。

圖說：第三類SDN方案：網路虛擬化SDN

在這類SDN方案內，邏輯網路的管理與配置都是在軟體環境內，底層的硬體交換器需要存在，但僅負責不同Host間，經封裝後的網路封包轉發。底層的網路設備可以是任何廠牌、任何型號，只要能讓各台vSphere之間IP能通，而且有打開Jumbo Frame讓封裝後的網路封包能通過即可。底層的硬體設備，是傳統的三層式架構、近幾年的Fabric架構或是最新的SDN架構，對上方的方案都沒有影響，僅需要是一個能提供高頻寬、穩定、低延遲的底層高速傳輸環境即可。

因此，在這邊我們能看出這類Overlay-SDN方案的優勢包含了下列幾點：

對於虛擬環境與新應用架構直接支援：這類的方案直接將網路功能放置在離業務環境最近的地方，或許是虛擬環境的Hypervisor，或後續支援的在container host上。公有雲架構內，甚至可直接將功能構件放置於機器作業系統內。對於大部分已經大量虛擬化，或後續導入container架構、混合雲架構的企業用戶，使用此類方案能直接支援在虛擬化環境以及新架構應用內的網路管理與可視性。

完整達成2-7層網路方案原生支援與整合：Overlay-SDN方案的網路功能不是用硬體晶片做的，而是在軟體環境內利用kernel process或是虛機的方式來建立。因此，運算能力與資源不是問題，不僅僅二層三層的網路交換路由，四層以上的Stateful服務，如Firewall / Load Balancer / NAT / VPN…等等，都能夠很容易地在同一方案內實現。這代表，用戶能夠用單一的介面、單一的管理方式、共同的API、無需整合的環境下，就能直接取得資料中心內所需要，二層到七層的完整網路與安全服務。

開放的硬體架構選擇，大幅降低部署成本與提升彈性，現有網路環境無需異動即可導入SDN：如前談到，Overlay-SDN架構內，底層的網路設備主要提供一個高頻寬、穩定、低延遲的傳輸環境。這代表著，如果客戶現在的網路環境已經很穩定好用頻寬也足夠，比如說之前花了大錢用Cisco Nexus 752打造的環境，此時要在上面部署這類Overlay-SDN方案是完全沒有問題，當然也不需要重新採購、重建現有的底層硬體網路。想像一下，如果企業目前的重點是要建立一個測試雲，或是要強化目前虛擬化資源池的安全防護，因為這個理由要重建資料中心網路，不是很奇怪嗎？

那反過來，這類的Overlay-SDN方案有沒有缺點？當然有的。目前我們所看到的這類方案，都不能直接控制實體交換器，也就是說，企業這邊的實體設備，像是Power這類的Unix機器、NAS、未被虛擬化的x86資料庫與業務機器等等，如果所接取的實體交換器要集中管理，這類方案目前還做不到。我認為這類Overlay-SDN廠商如果要依循前篇所提到的第二類方案，去控制ONIE合規的交換器，絕對是技術上做得到。但目前確實在短期內，沒有看到有明確的Roadmap出來。

不過同樣地問一個問題：這些實體設備們，就算再重要好了。基本上，在企業內都是一次性安裝，後續很少有二次異動。不常變更網路、很少自動化。那…要在上面裝SDN幹什麼？每次有用戶質疑VMware NSX不支援實體設備的SDN，我就用這個問題反問。結果，到現在也沒有人能告訴我，到底在他們的環境內，這些實體設備要用SDN的使用情境是要做什麼勒～～

本篇我們把網路虛擬化SDN方案的優缺點和大家進行報告。所以在下一篇網誌，我們要討論最後一個問題：這三種不同方案間的最佳使用情境，到底是什麼。