SDN創新局　Google強力背書

當企業汲汲營營踏進雲端世界後，很容易就會體認到，光是實現伺服器虛擬化、儲存虛擬化，其實還不夠，且兩項技術的實踐難度，也還在可受控制的範圍內，剩下來最棘手的部分，無疑就是網路這一環。

只要一談論雲端運算，企業IT人員立即湧上腦海的頭號技術要務，十之八九都是伺服器虛擬化，而當此項技術推展到一定階段後，緊接著就會透過相關管理工具的採用，逐步建立所謂的自動化機制。

接下來，有感於大量虛擬機器所挾帶的龐大資料存取需求，難免凸顯現有儲存架構之不足，於是為了優化應用服務的執行性能，便會著手導入儲存虛擬化；更有甚者，一些較晚啟動雲端建置的企業，在規劃專案內容時，一出手便是同時實施運算、儲存等兩項虛擬化技術。

做到這裡，夠了嗎？理論上是夠的，但要不了多久，企業往往就會發現一個現象，隨著部署新應用服務的頻率提高，資料量也加大，此時即會被迫反覆重置網路設定，而且還不時因為傳遞大量資料而拖垮網路效能，尤其雲端應用規模愈大的企業或服務供應商，此類情況尤其明顯。

看到這裡，或許有人備感納悶，相較於運算、儲存這兩大環節，網路明明相對穩定成熟，按理說問題理應較少，無奈在於網路這一塊，不僅可能出現上述令人苦惱的現象，且在面臨多租戶(Multi-Tenancy)環境時，還經常出現瓶頸，時時扮演衝擊雲端應用效能的殺手，真不知諸如此類的難題，應該如何化解？莫非得趕緊推動網路虛擬化？而當前有哪些主流技術，最有助於實現網路虛擬化願景？

傳統網路架構　罩門一一浮現
意欲探究解決之道，不妨先從傳統網路架構的罩門開始說起。以目前舉世所見，最大規模著手顛覆傳統架構的Google為例，以往最感困擾之處，在於每回在新的應用服務上線之前，皆須大費周章針對旗下多不勝數的交換器或路由器，不厭其煩地進行CLI設定，而且為了擔心IP、Routing或防火牆出現設定錯誤情事，就莫名其妙造成網路癱瘓，因此在搞定一切設定事宜後，亦需要進行詳細的測試，如此耗時費工，難免延宕了新與服務的開通時程。

撇開Google這般網路巨擘不談，即使是一般規模稍大的企業，也一樣會在網路這一層吃足苦頭。主因在於，傳統VLAN的可配置上限，走到頂端就是4,096個ID，若在傳統IT環境，這個極限值也還夠用，但對於高度虛擬化的資料中心來說，「屈屈」4,096個ID，卻是明顯不足的。此時該如何是好？似乎別無他法，只能從VLAN Trunking下手尋求解決之道，但即使如此，用戶還是難以真正打通「任督二脈」，而且容易製造新的問題，因為當所有交換機形成了一顆相互連接的樹，彼此難免需要一番學習適應，很快就會把TCAM記憶體空間用滿，因而導致網路趨於不穩。

值此時刻，Google的革新之道，無疑將帶給世人莫大啟發；而該公司的做法，便是將資料中心網路基礎架構全面轉換到OpenFlow，也因此而造就迄今全球最大的「軟體定義網路(Software-defined Networks；SDN)」。

Google臨門一腳　無異為SDN強力背書
看到這裡，相信對SDN的背景稍有認識的人士，難免認為Google實在大膽。此乃由於，OpenFlow這個至今仍未甩脫實驗性質的技術，打從2006年經由史丹佛大學發表到現在，不過歷經了不到7年的時間，尚無前人將之大舉運用在商業環境，而Google竟決意揮別沿用數十年的傳統網路技術，願意朝向這個新生兒放手一搏，背後隱含的意義著實重大。

一來，大如Google的業者，都膽敢把吃飯傢伙押注在OpenFlow及SDN之上，顯見他們勢必經過仔細盤算，反覆驗證了此項技術確實可行，才會信心滿滿地做出決定，這也意謂著，SDN已非理論性、概念性的產物，而是真的可以付諸實踐；其次，在這場「豪賭」的背後，似乎也充分吐露，在虛擬化、雲端化的世界裡，傳統網路架構真的愈來愈寸步難行，不趕緊做一番「了斷」，日後包袱勢將愈來愈大。

究竟SDN為何物？顧名思義，即是揚棄過往的Routing Table，改以控制軟體所設定的政策，來主宰一切的封包傳遞路徑；說得更具體一些，就是藉由軟體式控制器，一舉取代掉傳統網路設備的「大腦」－作業系統加功能單元，繼而取得「導航」的主控權，它不再遷就於層層輾轉的網路架構，也無須繞行過去曲曲折折的羊腸小徑，而是比從前更具智慧，懂得透過持續不斷的模擬試算，在封包的來源地與目的地之間，演算出傳輸效率最佳的路徑。至於OpenFlow，則是賴以實踐SDN的交換技術。

反觀傳統網路設備，最主要的問題在於，隨著廠牌與供應商的不同，一來會產生一個個獨一無二的作業系統，二來也會根據各自的作業系統，繁衍出一個個獨一無二的特殊應用IC(Application-specific IC；ASIC)，並由ASIC來執行Routing Table的演算任務。

單就上述的來龍去脈觀之，不難讓人理解，過去的網路設備充斥了封閉氣息，各自都有各自的獨門秘技，所以在看似大一統的業界標準協定外，尚埋藏了許多不盡相容的阻礙，這些由來已久的路障，無疑正是拖累網路傳輸效能的關鍵所在，這些問題，過去或許尚在人們容忍的範圍之內，但到了虛擬化、雲端化世代，從前若隱若現的「攔路虎」，將更加清晰可見！

因為傳統的階層式架構、Spanning Tree協定，猶如盤根錯節，實在塑造了太多的延遲(Latency)現象；試想，假如企業基於某些不得不然的因素，亟欲將駐留在某台實體伺服器的20個虛擬機器，即時遷移到另一台主機，卻壞在網路根本認不得Mac位址或VLAN編號，所以無法直接支援這般遷移動作，還需要勞煩網管人員以手動方式更改一切設定，其間所耗費的可觀時間，便有可能導致大量金流的憑空消失，教企業主怎能忍受？唯有以SDN形塑出最扁平、最饒富彈性的新架構，把VLANs、ACL、QoS、PVLANs或Service Routing等繁瑣協定通通拋開，才可望化解這一切的扞格。

而且坦白來說，一直以來，企業之所以為建設資料中心而付出龐大成本，某種程度上，也是被逼得替上述要價不菲的ASIC買單所致，再加上這些東西如影隨形，不管Core、Aggregation或Access等不同階層所在多有，加總起來的財務負擔，難免讓原本頗具利潤或效益空間的網路應用服務，硬生生被擠壓成為蠅頭小利。如今有了軟體控制器當做大腦，ASIC便無存在必要，可使交換器蛻變成僅須聽候差遣的Dump Pipe，只管好單純的Forwarding任務即可，一來一往之間，網路建置成本落差之大，也可望讓企業主眉開眼笑。

綜此，憑藉OpenFlow與SDN作為網路控制樞紐，隨時計算最佳路徑，任憑交換器暫時遭逢壅塞狀況，也能隨即接收到軟體的指示，自動轉向另一條暢通道路，繼續執行Forwarding任務，致使封包傳輸速度顯著提升；唯有如此，方能有助於企業加快雲端應用服務遞送的效率，即使肇因於大量行動裝置、巨量資料，突然爆出事前難以預期的流量，抑或川流不息的服務請求，都可藉由SDN展現靈活身段，透過始終優異如常的交換品質，有效克服一切考驗。