大資料難題帶來按需支配的雲網路解決方案

隨著資料中心和雲環境中的大型資料不斷增長，如何管理同時傳輸數百萬條記錄的網路成為前所未有亟待解決的問題。

這不僅僅是資料規模的問題--在涉及大型資料網路解決方案時，不僅是資料規模確實不能小覷，而且工作量也是如此。 大型資料環境不能簡單的按照過去的資料基礎架構來運作。 鑒於運行大型資料應用軟體的複雜性和速度，大型資料需要適合自己的解決方案。

「傳統」的資料分析體系結構假設資料的來源有限，他們有大量的時間將資料存儲在正確資料庫的正確表格當中。 當涉及到諸如推特，臉譜和谷歌所使用的網路和應用軟體時，這種對待常規資料庫體系結構的方法就好比將單個燈泡插在核反應爐上一樣問題立顯。

為了克服在短時間內處理大容量資料的障礙，大型資料使用者設計了兩種不同的方法來解決這種問題。 首先是部署大規模即時資料庫，比如BigTable, OpenDremel, MongoDB或者Cassandra。 這些資料庫都共用非關聯的特性：他們不依賴標準化查詢語言（因此他們又被稱為"NoSQL"），他們也不能滿足關聯資料庫中所有資料都必須滿足的ACID需求。

另外一種解決方案是流量分析資料庫，諸如Hadoop，通過篩選大容量資料進行分類來達到目的。

這就意味著網路和周圍基礎架構關注的中心將從優化存儲向優化搜索轉移。 也必須這麼做，因為存儲在典型的大型資料環境中已經被大大的簡化了，所有的重點是將資料分類來滿足有用的資料集，然後用於深層結論的分析。

但不幸的是，這種基礎方法只能應用於普通的大型資料網路。 在占地20000平方英尺的資料中心裡，用來匹配這些資料解決方案的方法是多種多樣的。 每種方法都有其必須被解決的固有問題。 舉例來說，Hadoop使用代表單點故障大型資料管理器的NameNode體系結構來應對非常敏感的資料。 如果NameNode設備對網路不起作用了，整個Hadoop系統也就癱瘓了，這就給網路系統管理員來保障特殊伺服器的正常運行造成了很大的壓力。

當然還有非網路的解決方案。 舉例來說，來自DataStax公司的產品Brisk就是要在Apache Cassandra的即時性能與Hadoop的分析能力之間搭建一座橋樑。 Brisk將Hadoop的檔案系統與Cassandra合併在一起，這就意味著不再會出現單點故障的問題。

大型資料和網路架構

這兩種選擇只是來自潛在大型資料體系結構的冰山一角。 單就這些解決方案的網路架構來說差異就已經非常之大了。 那麼網路管理者如何應對每天越來越多的大型資料呢？

諸如OpenFlow這樣的解決方案能有所説明。 OpenFlow是Open Networking Foundation產品的網路基礎架構協定。 Open Networking Foundation存在的原因就是要執行這種圍繞軟體定義網路概念的協定OpenFlow。

軟體定義網路的設計是為了解決諸如下面描述的這類問題：與構建一招吃遍天下的網路解決方案並迫使應用軟體使用這種解決方案來解決問題的方法不同，應用軟體本身就能定義網路拓撲。 OpenFlow通過簡化硬體和網路管理，能説明網路系統管理員更加輕鬆的根據軟體定義網路的規則來配置他們的網路，從而降低大型資料網路的網路管理成本。

OpenFlow是一種低級別標準，不過廠商已經開始尋找將他們自己的軟體設于OpenFlow之上的可能性。 舉例來說，是否能設計出一種網路管理工具能感知網路流量和資訊包工作負載的突然性大規模遷移，自動轉換配置來做出補償，當工作量完成後又返回「正常」模式呢？ 其實如果這種方法能得到廣泛的普及，OpenFlow將對「雲網路」--隨需效用網路設定有所説明。

這種方式非常重要。 標準拓撲結構下的交換器和路由器無法實現我們在此探討的頻寬。 網路本身逐漸成為大型資料解決方案的組成部分，諸如思科系統公司IOS產品線極力推廣的此類網路即平臺解決方案應用正在變得越來越普遍。 面對如此的複雜程度和資料規模，靈活的光纖連接方式正在快速成為網路架構的新寵。

OpenFlow解決方案將説明網路系統管理員按照需求自動控制網路光纖的規模和形態，就像幾年前讓流量按照意想不到的方式實現一樣。

這是一種網路管理者必須適應的方式。 雲計算的大規模應用（公有雲，私有雲或者混合雲）和大型資料應用軟體將在不久的將來滲入到每一家企業的應用環境當中。

(責任編輯：蒙遺善)