思科訴諸UCS架構 構築大數據運算與網路平台

思科大中華區數據中心高級技術顧問馮志良

工欲善其事，必先利其器，不管企業勾勒的大數據應用多麼璀璨奧妙，都必須備妥運算、儲存與網路等必要基礎平台，才能踏出第一步；而且大數據應用成敗，往往取決於使用者體驗(UX)優劣，即使應用程式寫得再好，若基礎平台不健全，亦將拖累應用執行效能，無緣獲致最終使用者青睞，顯見基礎架構之重要。

思科(Cisco)大中華區數據中心高級技術顧問馮志良指出，幾年前，伴隨大量非結構化數據興起，而人們逐漸意識到箇中蘊藏價值，才赫然發現無法運用傳統技術善加處理，因而使Hadoop、NoSQL與MPP關聯式資料庫等技術躍為新寵；在2009年當時，企業一來基於嚐試心態，二來參考他人應用經驗，紛紛以開源碼軟體搭配便宜硬體，建構小型隔離環境，以支撐Hadoop運行。

惟爾後隨著一個個Hadoop節點擴增，從原本的寥寥3~5個，漲升為數十個、上百個，企業開始承受吃重的管理暨維運壓力；著眼於此，在Hadoop生態圈饒富盛名的Cloudera公司，在HadoopWorld 2015大會提出呼籲，企業宜以「Fat Node」取代過往「Thin Node」，改採企業級的強效基礎平台，才足以有效應付諸如Impala、Drill、Hbase…等等嶄新大數據應用的驅動需求，也更易於運用有限人力，提升管理效率。

思科CPA架構  全然呼應Fat Node訴求

思科基於巨量資料處理需求打造的UCS通用平台架構(CPA)，完全呼應Fat Node趨勢。馮志良表示，綜觀CPA架構，內含伺服器、網路與管理軟體等完備機能，並針對Hadoop、NoSQL與MPP等不同應用情境，提供多種參考設定套餐；例如因應需要高效能的NoSQL或MPP應用，建議採用4分之1機架的UCS解決方案，內含2台UCS 6248交換器、8台C220 M4伺服器，以及6顆400GB容量的SAS固態硬碟，反觀講求大容量的Hadoop環境，則建議採用全機架UCS方案，內含2台UCS 6296交換器、16台C220 M4伺服器，再加上12顆4TB容量7,200轉SATA硬碟。

另一方面，企業意欲實踐完整的巨量資料分析應用，其分析範疇，勢必不可能長久侷限於Web或Machine Log等非結構化數據，亦需納入既有線上交易處理(OLTP)資料，意謂Hadoop叢集架構，不可能永遠孤立於企業現有應用環境之外，兩者必須整合。但談到整合，問題就來了，以傳統企業應用環境而論，不時可見刀鋒伺服器、SAN交換器等配備，走的是分享式儲存架構，然而巨量資料叢集卻是以機架式伺服器為主，採用伺服器內部儲存空間。

針對前述落差，思科CPA藉由Unified Fabric，確使刀鋒、機架等不同型式主機得於相同網路並存運作，先解決網路層面的整合，再透過UCS伺服器上的虛擬介面卡(VIC)，以管理方式任意切割出虛擬網路卡、虛擬HBA，巧妙營造LAN與SAN分流效果，如此一來，巨量資料叢集的資料來源，即可不限定於伺服器內部儲存空間，而是在SAN環境，意即Hadoop節點也能存取SAN裡頭的資料。

妙用服務設定檔  打通OLTP、Hadoop資源藩籬

馮志良接著說，根據Cloudera公司分析，部署Hadoop的最大問題，通常在於設定與配置方面的錯誤，特別是NIC Teaming，UCS用戶藉由虛擬網路卡、UCS Fabric Failover等機制，便可巧妙規避此一風險，無需費心執行Teaming、綁定等程序，便能自動切換。

更重要的，CPA內含的UCS Manager，本身兼具刀鋒、機架等不同型式主機的管理介面，且提供極為關鍵的服務設定檔(Service Profile)功能，可將伺服器的身份元素，包括IP位址、MAC位址、BIOS與WWN(World Wide Name)，抽象成為動態Template，在此前提下，如果企業遭逢OLTP環境運算能量不足，即可輕易徵調Hadoop節點資源，使Hadoop節點快速變身為企業應用運算節點，方便企業隨需挪移運用OLTP、Hadoop彼此計算資源，提升整體IT投資效益。

另值得一提，藉助思科ACI軟體定義網路(SDN)機制，輔以堪稱ACI建構基石的Nexus 9000系列交換器，據此建立一個實驗場景，在此運行巨量資料應用，緊接著將相同應用接入友商廠牌交換器，結果ACI所展現的效能高出三成，意即搭配友商設備需時10小時執行完畢的應用，改採Nexus 9000，僅需7小時便可大功告成，此乃由於，ACI支援獨特的Flowlet Switching技術，會自動找尋不壅塞的路徑行走。由此觀之，一旦結合ACI、UCS，可望建立強大的企業等級巨量資料叢集環境。