適合5G應用的伺服器並不是只有頻寬更大這麼簡單

Jul 01, 2019 by GIGABYTE

行動網路畢竟只是「道路」，路變寬，車子也要快，不是單純佈署5G網路就可以了，提供服務的伺服器需要「靠的更近」。

拜美中貿易戰連帶讓全世界一同「關心」華為的5G布局之所賜，隨著越來越多電信營運商與手機製造商推出「宣稱對應5G的產品和服務」，傳說已久的「10Gbit/s等級」理論頻寬與「一毫秒以下」網路延遲，看似不再是遙不可及的夢想。當然這些在2020年Release-16問世前，Release-15中「為了適應早期的商業部署」的5G規範第一階段，站在時代浪頭的白老鼠們的使用者體驗是否令人滿意，那又是另一回事了。

但問題來了，我們要大費周章佈署5G拿來做什麼？目前看來，5G的高資料傳輸速率和超低延遲的用途，不外乎實際的虛擬實境（VR）和擴增實境（AR），或著追求執行自動化、機器與機器之間密切互動的物聯網環境，而方興未艾的人工智慧自動駕駛，例如道路上的自動車彼此通過5G連續不斷地相互通訊以最佳化車距與車速，更是不可能被放過的殺手級應用—起碼砸大錢投資基礎設施的電信營運商，絕對希望大家相信這的確是不可抗拒的未來，否則他們就血本無歸了。

但行動網路畢竟只是「道路」，路變寬，車子也要快，不是單純佈署5G網路就可以了，提供服務的伺服器需要「靠的更近」，才能克竟全功。

詞彙學習：
《帶您了解什麼是5G》
《什麼是人工智慧(Artificial Intelligence)？》

縮短服務的延遲依舊很重要

說到資料中心和雲端服務的反應時間是否重要，就不得不回過頭看看二十一世紀初期，那個Google剛崛起的年代，在高效能汎用處理器領域曾稍縱即逝的「創意」：簡單微架構的多核心、多執行緒處理器，其中以Sun（被Oracle併購）的「Throughput Computing」概念的首款處理器UltraSPARC T1（代號Niagara），與DEC在2000年提出的八核心Alpha “Piranha” 最具代表性。

支撐這些獨樹一幟處理器架構的理論基礎，不外乎「網站與資料庫的效能瓶頸，不是處理器本身的運算效能，而是記憶體和I/O的延遲」、「1990年代開始追求指令執行平行化的處理器，執行單元越寬、指令管線越深，結果更昂貴更複雜更耗電，複雜的分支預測機制也難以應付物件導向高階程式語言的行為模式」等等，所以不如打造多核心多執行緒「相互掩護」的架構，提昇整體的輸出量。

這些論述乍看之下似乎很合理，又很剛好的，任職於Google的Luiz André Barroso（現任Google Maps的工程副總裁，他的著作 “The Datacenter as a Computer” 是資料中心領域不可不讀的大作）在ACM（Association Computing Machinery）所發表一篇文章「An Economic Case for Chip Multiprocessing」，也倡議著這樣的「理念」。此時此刻，外界就非常看好Sun的新型態處理器將大量進駐雲端巨人的機房，而這麼多年來，Google自行研發高效能處理器的謠言更是從來沒有停止過。

但這些美好的猜想，通通都沒有發生。Google的資料中心還是滿滿的Intel處理器，絕大多數還是經過精密計算後、最具成本效益的桌上型版本，而且連「可能會影響單執行緒效能」的超執行緒都不需要。（當然現在情況就不見得一樣了）

為什麼？這背後的商業邏輯，跟Google為何吃飽沒事要自己打造Chrome瀏覽器是一致的。你可能當下已經大腦當機：資料中心使用什麼處理器和我們使用什麼瀏覽器，根本八竿子打不著。

但是當你回頭想想「Google靠什麼賺錢」時，你就會想通了：他們希望使用者可以在最短的時間內，接觸到最多的廣告，對於服務反應時間更是斤斤計較，也因此，資料中心的伺服器需要有極佳的單執行緒效率，瀏覽器必須有更快的速度，而Google自行佈建網路基礎設施，連當眾人還在清談SDN（軟體定義網路）時，鴨子划水、不動聲色就在2014年就啟動基於SDN的B4廣域網路，都是基於相同的商業邏輯而做出的決定。同理可證，為何Google會認真考慮在資料中心導入IBM的Power？因為地球上再也沒有其他處理器廠商可以做出單執行緒效能比Intel AMD更好的產品了。

縮短延遲，真的很重要

帶你了解更多5G三大特性
《URLLC低延遲-智慧車聯網行進安全A+ 運務效率Up!》
《eMBB大頻寬-360度沉浸式VR 改寫你對距離的定義》
《mMTC大連結-打造萬物互聯智慧城》

遠水救不了近火

我們在談論儲存應用的文章，提到「靠的越近，速度越快」，不只適用於資料中心內部，對於「提供服務的伺服器該放在哪個位置」更是舉足輕重，特別是追求即時性的應用場景，像新興物聯網領域中，無人機、自駕車、機器人、擴增實境、虛擬實境等，根本無法容忍透過網路網路傳輸資料到雲端的時間成本，總不能都快撞車了還得等雲端資料中心告訴你該不該踩煞車吧。

如果你的腦子還轉不過來，想想Google在眾人不知不覺中已經在資料中心佈署了歷經三個世代的人工智慧TPU（張量處理器），還是得另外做出個放在終端設備的Edge TPU，就會想通了：遠水救不了近火，尤其當資料量越來越誇張的時候。人類在二十一世紀初期花了超過十年的時間，將越來越多的服務搬到雲上，現在又開始站在人工智慧的浪潮上，以「邊緣運算」為名，再一個一個放下來，將運算放在更靠近資料來源的本地區網。

邊緣伺服器分而治之

工研院發展的5G iMEC（intelligent Mobile Edge Computing）行動網路邊緣雲平台，就佈署在行動網路邊緣與鄰近5G基地台的位置，提供雲端運算能力和應用服務管理。由於應用服務鄰近使用者，因此可以有效降低服務的延遲時間，同時資料於行動網路邊緣進行運算，可以有效降低網路傳輸的資料負載。

工研院的5G iMEC行動網路邊緣雲平台就運行於標準化的硬體上，提供APP上架、下架、生命週期與流量規則的管理服務，並可於佈建於兼具Hypervisor虛擬機（OPNFV）與Container（Kubernetes）的混合式NFV平台，提供APP多樣的運行環境進而滿足不同類型應用服務的需求。

邊緣運算對伺服器管理的影響

但邊緣運算的復活，讓管理的伺服器多了一層，也帶來更複雜的伺服器管理，這時候就得分成兩個層面來探討：單一高密度伺服器的內部管理，與同時維運大量伺服器群的橫向擴展（Scale-Out）環境。在IPMI誕生的年代，根本難以想像今日的資料中心，動輒數以萬計的Container在數以千計伺服器之間「流動」的壯觀場面。

單一伺服器內的管理就是行之有年的IPMI（Intelligent Platform Management Interface），也是業界最標準的頻外（Out-Of-Band）管理規格，相較於被管理伺服器必須處於開機狀態並載入作業系統的頻內（In-Band）管理，IPMI之類的頻外管理，可以在伺服器處於關機的狀態，遠端進行重開機等修復工作。在2004年IPMI 2.0問世後，可重新導向遠端伺服器畫面文字到管理者電腦上的Serial-over-LAN (SOL) 功能，更催生了大量具備虛擬iKVM的IPMI機板管理控制器（BMC，Baseboard Management Controller），讓管理者可享受遠端「隔空操作」伺服器的便利性。

不過當佈署高密度伺服器又該怎麼辦？總不可能一個運算節點就要塞一個專屬的乙太網路埠、遠距離一台一台用KVM去管吧？技嘉科技的H系列伺服器可透過搭載的Aspeed 中央管理控制器(CMC)，進行機箱層級以及單一節點層級的系統狀態監控，透過CMC連接埠串接每個節點的Aspeed遠端控制晶片BMC，使得管理所有節點只需透過一個CMC連接埠，而不需要4個MLAN連接埠，減少了機櫃頂端交換機所需要的佈線配置及連接埠數量。

但IPMI畢竟是早期的頻外管理標準，更不是為了同時管理大量伺服器而生，僅限於最基本的管理功能項目，如開機、關機、重啟、溫度等，也甚少IPMI BMC供應商自行擴展功能，導致管理者仍需要仰賴頻內管理工具。而DMTF（分佈式管理任務組，Distributed Management Task Force）在2014年首度提出的Redfish規範，結合RESTful應用程式界面、常見的HTTP與比XML更簡潔的JSON資料格式，更能有效融合現今網際網路與Web服務環境。

講的白話一點，你可以直接使用網路瀏覽器（或基於瀏覽器的圖形使用者界面）查看來自Redfish服務的資料，可以直接使用Python撰寫伺服器管理程式（程式設計師對此一定很有感），可以在作業系統上執行運行應用程式與管理工具，包括伺服器開機前的階段，就連接Redfish的管理服務。總之，「軟體定義管理」的Redfish提供了比IPMI更安全、更可支援多節點、可管理到更多細項（如NVDIMM）的替代品，在未來更會延伸至儲存設備領域，高效駕馭超融合基礎架構的資料中心。

技嘉伺服器管理軟體（GSM）是兼容IPMI或Redfish應用程式介面、可遠端進行多重伺服器管理的平台，搭配以下套件來提供全方位平台管理：GSM Server（藉由圖形化瀏覽器操作軟體，透過機台的伺服器遠端控制晶片來進行多重伺服器監控與管理）、GSM CLI（藉由命令列輸入操作，透過機台的伺服器遠端控制晶片來進行多重伺服器監控與管理）、GSM Agent（安裝於每一台技嘉伺服器節點，透過系統層面來獲取每個節點的額外資訊，如處理器、記憶體、硬碟、匯流排，並將收集的資料交付予伺服器遠端控制晶片，讓GSM Server或GSM CLI存取應用）、GSM Mobile（於移動裝置上使用的遠端管理軟體，同時支援安卓或蘋果iOS系統）、GSM Plugin（允許用戶使用VMware vCenter來遠端監控管理伺服器），無須昂貴複雜的一線外商大廠管理系統，諸如種種，均遠非IPMI BMC內建的「網頁」所能望其項背。

其實2004年發表IPMI 2.0時，就有不少伺服器廠商「不太甘願」馬上支援新規格，而寧願等待DMTF研擬中的新規範，而Redfish的出現，象徵著伺服器管理標準的巨大進步—即使相隔了超過十年。

高度的汎用性確保最高的投資報酬率

長期關心技術發展的讀者，絕對可以慢慢察覺到：這難道不就是NFV（網路功能虛擬化，Network Function Virtualization）的例證嗎？NFV將多種不同類型的網路專屬硬體與計算密集的網路服務，進行廣泛的虛擬化後，再佈署到通用伺服器上，降低網路建設與營運成本，和軟體定義儲存的精神有著異曲同工之妙。

回過頭來，既然NFV的核心精神在於汎用性，那其佈署的伺服器平台亦不可免俗的須具備優異的擴充彈性，才能更加適應不同的應用環境，並有著最長的使用壽命，以得到最高的投資報酬率。為超融合機構架構量身訂做的技嘉H281-PE0，四個節點個別可提供3組短版(Low-Profile)與一組OCP（Open Computing Platform，Facebook主導）規格附加卡插槽，可完美整合工研院iMEC行動網路邊緣雲平台。

無論是軟體定義儲存、超融合運算基礎架構、NFV，都是高密度伺服器可以大展身手的領域，而這些都建立於過去十多年來無數技術的嘗試、累積與實踐，值得你多看幾眼，而「適合5G應用的伺服器」，也並不是只有頻寬更大這麼簡單。《了解更多：讓你更全面了解5G MEC Networking Platform》