鄭小蘭

(福州理工學院，福建 福州 350506)

0 引 言

霧計算技術作為云計算技術的延伸主要部署在靠近用戶側(cè)。為提升霧架構的QoE，通常將載荷的計算移至本地實施。然而這樣卻付出了開銷的代價。為此業(yè)界對此展開了相關研究。文獻[1]提出了基于最小篩選的均衡機制(MB)。主張通過統(tǒng)計整個霧系統(tǒng)所有服務器節(jié)點的用戶提請連接數(shù)，進而鎖定連接規(guī)模最小的那個服務器節(jié)點來應對霧用戶發(fā)起的任務請求?；贛B算法思路，文獻[2]設計了基于權重最小化的均衡機制(WMB)。該機制考慮到了霧系統(tǒng)中服務器設備負載能力多變的客觀情況而引入了權重參量。然而每一次霧用戶提請任務的持續(xù)時間和任務所需消耗開銷資源存在變數(shù)。對于每一個服務器設備而言，即便其和霧用戶之間的響應連接與權重參量呈一定的比例關系，卻依舊存在響應連接規(guī)模和負載能力不匹配的情形。故提出基于約束的自適應QoE算法設計。旨在以縮短霧用戶等待計算響應時長為約束探討服務器節(jié)點與任務請求的優(yōu)化適配機制。

1 方案分析

自適應QoE算法目標是最小化響應終端用戶任務請求的時延代價[3]。此處將算法部署的體系依次分為三層，分別是云數(shù)據(jù)中心層、霧節(jié)點層、終端用戶層。在霧終端用戶向距離其最接近的霧節(jié)點發(fā)起任務請求后，霧系統(tǒng)開始對霧節(jié)點展開計算資源評估。若評估結(jié)果顯示無法受理任務請求則將該任務請求轉(zhuǎn)發(fā)給與此霧節(jié)點相鄰的其他霧層服務器，如此循環(huán)評估直至遍歷到合適的霧服務器節(jié)點。若算得該霧節(jié)點具有足夠的開銷則可用于響應任務請求。用于響應任務請求的霧服務器將最終計算結(jié)果送至霧層中最接近于霧用戶的那個霧服務器，進而將霧計算數(shù)值響應給發(fā)起任務請求的霧用戶。要是霧層無法遍歷到合適的霧節(jié)點，此任務請求將被向上提交到云數(shù)據(jù)中心層。經(jīng)云層服務器節(jié)點計算處理后將結(jié)果下發(fā)至與該云節(jié)點最為接近的霧層中的霧服務器，然后再響應給霧終端用戶。

2 算法設計和部署

評估一個服務器節(jié)點能否有足夠的開銷用于自適應地應對霧用戶提請的任務計算請求，需綜合分析下列幾種情形。情形A：當CAll/σAll小于C(Ni)/σ(Ni)且RAll/σAll小于R(Ni)/σ(Ni)時，說明當前節(jié)點屬于重載情形；情形B：當CAll/σAll大于C(Ni)/σ(Ni)且RAll/σAll大于R(Ni)/σ(Ni)時，說明當前節(jié)點屬于輕載情形；情形C：當CAll/σAll大于C(Ni)/σ(Ni)且RAll/σAll小于R(Ni)/σ(Ni)，說明此時當前節(jié)點的連接規(guī)模雖小然而載荷度卻依舊很大；情形D：當CAll/σAll小于C(Ni)/σ(Ni)且RAll/σAll大于R(Ni)/σ(Ni)，說明此時當前節(jié)點的連接規(guī)模雖大載荷度卻反而很小。出現(xiàn)后面兩種情形主要緣于SDN數(shù)據(jù)流呈現(xiàn)突發(fā)[5]特征，用戶提請的任務請求規(guī)模、任務持續(xù)時長、服務器瞬時開銷資源均是動態(tài)隨機所致。

部署自適應QoE算法時可定義一個數(shù)組用于容納情形B和情形D下的節(jié)點，逐個遍歷數(shù)組中的節(jié)點直至為空。然后開始重新評估服務器的參數(shù)R(Ni)、RNull(Ni)、σ(Ni)、RAll、σAll、CAll，評估后若符合情形B和情形D的條件則可以放入數(shù)組內(nèi)用于應對霧用戶提請的任務計算請求。

圖1 三種算法下的服務器載荷占用比

圖2 三種算法下的服務器閑置負載占比

3 算法實施

基于約束的自適應QoE算法以終端霧用戶可接受的等候時延為前提來降低服務器轉(zhuǎn)發(fā)任務請求的頻率。從QoE時延角度出發(fā)，應統(tǒng)籌考慮三種情形下霧層服務器執(zhí)行任務請求時節(jié)點進行任務轉(zhuǎn)發(fā)操作的頻次，并盡可能地讓任務請求在霧層中就能夠得到順利的響應。基于此思想，整個算法的實施過程做如下規(guī)劃：

初始化自適應QoE算法各指標參量Mi、Ci、Bi并定義一個數(shù)組后，首先通過評估R(Ni)、RNull(Ni)進而求出σ(Ni)。其次，分別計算出σAll、CAll、RAll然后分析RAll/σAll和R(Ni)/σ(Ni)關系。如果前者小于后者，則返回至第一步驟；反之將Ni存放到數(shù)組內(nèi)。隨后判斷數(shù)組內(nèi)的節(jié)點是否為空。若非空數(shù)組則返回執(zhí)行步驟一；若為空數(shù)組再分析是否還有終端用戶發(fā)起任務請求。如果仍有則重返步驟一，如果沒有待執(zhí)行的任務請求則終止計算。

4 算法測試

選用Matlab作為自適應QoE算法的測試[6]環(huán)境。為云層配置15GHz的計算能力，霧層中霧服務器的計算能力配置為f(GHz)=[f1,…,fm]=[1.5、1、2.5、0.7、0.6、0.9、0.8、0.5]，一次任務傳輸?shù)臅r延設置為Dt(s)=[0.02、0.17、0.1、0.19、0.09、0.1、0.08、0.06]。并為霧服務器f1和霧終端配置0.05s的任務傳輸時延。

圖1曲線是三種算法機制下節(jié)點受理相同用戶任務請求連接規(guī)模時，節(jié)點表現(xiàn)出的載荷占用比。由于MB算法并未顧及終端用戶提請任務計算請求的數(shù)據(jù)規(guī)模，一味地將任務轉(zhuǎn)發(fā)給連接數(shù)最少的節(jié)點來受理。這勢必導致服務器節(jié)點載荷占用比的變化起伏不定。WMB雖然克服了MB所忽略的關鍵環(huán)節(jié)但未考慮到隨機突發(fā)特征環(huán)境下，終端用戶提請的任務數(shù)據(jù)規(guī)模存在多變情形所引發(fā)的載荷變化情況。QoE算法則是調(diào)用那些當前載荷度低于所有節(jié)點平均載荷度的節(jié)點。因此節(jié)點載荷度依然以最小的變化幅度徘徊在系統(tǒng)均值左右。

圖2所示三條曲線描述了三種算法機制下的同一個終端用戶發(fā)起任務計算請求后，服務器節(jié)點表現(xiàn)出的閑置負載占比變化情況。顯而易見，由于只考慮用戶請求連接規(guī)模忽略了不同節(jié)點性能存在差異問題，MB算法機制下的節(jié)點在載荷占比指標上很容易出現(xiàn)兩個極端，要么很小要么很大，因此負載起伏不定。WMB算法思想是在MB基礎上引入權重系數(shù)用于動態(tài)計算某些節(jié)點的優(yōu)越性能。此機制下的節(jié)點載荷占比雖總體較為均衡但卻付出了系統(tǒng)開銷的代價。相比之下本文構思的QoE算法通過統(tǒng)籌考察節(jié)點的權重系數(shù)、連接規(guī)模、載荷度等來客觀地動態(tài)地評估所有節(jié)點的載荷使用情況。QoE機制下的節(jié)點載荷占比基本徘徊在系統(tǒng)均值附近。

5 結(jié) 語

QoE算法的構思是從全局角度出發(fā)以時延控制為目標，為霧用戶設計的一種自適應能力較強的算法方案。該方案通過引入權重參數(shù)為任務請求合理地計算出可用于響應的服務器節(jié)點。評估結(jié)果表明相對于傳統(tǒng)研究方案，該QoE算法的部署具有良好的普適性。