改善硬體限制- OpenFlow

OpenFlow讓Google從容面對急遽升高的網路需求

根據 Arbor network 的報導(註1),在 2007 年時,Google 產生的網路流量在全球網路流量的佔比僅約 1%,而在 2010 年時 Google 的佔比已將近 7% 。面對網際網路的普及以及本身快速成長的頻寬需求, Google 首當其衝的需尋找能應付現今網路流量成長與訊務工程管理的解決方案。

 

在瞭解中央訊務工程管理 (Centralized traffic engineering),以及軟體定義網路 (Software Defined Networking,簡稱SDN) 的優勢後, Google 於 2012 年開始逐步更換現有網路硬體至 OpenFlow 架構。Google 的廣域網路 (WAN) 系統由兩個主要骨幹 (backbone) 網路組成,分別為面對一般使用者主要承載用戶流量的骨幹網路稱為 I-Scale,以及 Google 串聯各個資料中心 (Data Center) 用於內部傳輸的網路系統稱為 G-Scale。兩個主幹網路的需求與訊務的特性有即大的不同, Google 決定在 G-Scale 網路佈署以OpenFlow 為核心的 SDN。

針對 G-scale 網路, Google 採用三階段實行 OpenFlow 網路架構,第一階段於 2010 年春季展開,將網路架構分兩批次轉換,逐次測試並升級至 OpenFlow 架構;至 2011 年中的第二階段,Google 啟動較為基礎的軟體定義網路 (Software Defined Networking),並引入更多網路流量測試新建的 OpenFlow 網路架構;至 2012 年上半年,Google 已將所有數據資料中心的骨幹網路依 OpenFlow 網路架設,同時將網路傳輸移轉為中央訊務工程管理來控制。外部的複製排程器 (copy scheduler) 也已能與 OpenFlow 控制器相互作用,並完成大型資料複製 (large data copies) 的排程。

在逐步步入 OpenFlow 架構後,Google 的資訊傳輸流量不斷的被擴大及優化。

Google 施行軟體定義網路 (SDN) 後,不曾再有封包遺失 (packet loss) 及容量衰減 (capacity degradation) 的問題,同時也保有簡單及高保真度 (fidelity) 的測試環境,可在軟體中模擬整個骨幹網路的運作,更能享有無中斷的軟體升級 (hitless software upgrade),而大部分的軟體升級也無需涉及交換器硬體的更新。

而雖然現有運行時間仍太短而無法量化轉換至 OpenFlow 系統的好處,但 Google 已感受到 OpenFlow 提升了整體網路環境的穩定性,同時也可預見 OpenFlow 更大幅優化網路傳輸的可能性,尤其在點對點的傳輸,能進行更有彈性的管理。

Google 的升級已證實無論是 OpenFlow 或是 SDN (Software Defined Networking) 皆已能在現行企業網路環境下實行。OpenFlow 不僅能簡化網路管理 (network management),也將大量的功能部署 (feature deployment) 變為可能。目前 Google 數據中心的 WAN 皆已成功的轉換至 OpenFlow 系統,不僅提升了網路的管理化程度,也進一步的降低現有成本。

 

註1:Arbor network 的報導來源: http://ddos.arbornetworks.com/2010/10/google-breaks-traffic-record/