5G

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

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
Realtion Tags
多接取邊緣運算架構
第五代行動通訊技術
數據中心
智慧型平台管理介面
Redfish
軟體定義網路
WE RECOMMEND
RELATED ARTICLES
什麼是邊緣運算(Edge Computing)?
邊緣運算將原本完全由中心節點處理的大型服務,切割分散到邊緣節點,更接近用戶終端裝置,可加快資料的處理與傳送速度,減少延遲,更適合處理即時性的數據分析及服務。
[數位導覽] 5G邊緣運算  開啟你的全新體驗
GIGABYTE 將為你開啟一趟5G生活圈的數位體驗,運用智慧城市情境,以5G三大特性: eMBB大頻寬、URLLC低延遲、mMTC巨量連結為基礎,呈現動態圖文的情境解說,如大型活動的即時沉浸式體驗、智慧車聯網及自駕車、及應用於智慧城市的新服務,同時掌握關鍵技術多接取邊緣運算(MEC, Multi-access Edge Computing)架構與技嘉邊緣運算平台在5G未來中所扮演的重要角色。
5G元年 不能不知道的關鍵概念
5G通訊技術是近來討論相當熱烈的話題,由於訊號傳輸速度更快、低延遲性還有大連結等特性,讓人們開始能發展包括工業4.0、自駕車、智慧城市等等應用,不再侷限於通訊;到底什麼是5G,它與 4G 有什麼不同?在技術上有何創新、又會對未來生活帶來多大的變化?
 
 
 
 
 
 
Complete this form to download this document and subscribe to receive communications from GIGABYTE. We will process your personal information in accordance with our Privacy Policy and you may unsubscribe at any time.
Cancel
Submission Successful
Contact our sales team
Please contact us if you would like to know more about our products. For services and support, please visit eSupport.
* Inquiries:
 
* Are you a system integrator?
 
 
 
 
To ensure our emails be delivered to your inbox, please avoid using free-to-use email services such as Yahoo, Gmail, Hotmail etc.
 
 
 
 
 
 
0 / 1000
 
* We will process your personal information in accordance with our Privacy Policy and you may unsubscribe at any time.
Cancel
Submitted Successfully
Back to top
Email Sales