物聯(lián)網(wǎng)邊緣計(jì)算服務(wù)容災(zāi)算法分析與驗(yàn)證

黎 明，李 露，郭榮佐

(四川師范大學(xué) 計(jì)算機(jī)科學(xué)學(xué)院，四川 成都 610101)

0 引 言

有限的網(wǎng)絡(luò)帶寬、云計(jì)算能力的不足已經(jīng)無(wú)法滿足物聯(lián)網(wǎng)應(yīng)用的低延遲要求[1],新興的邊緣計(jì)算是其有效解決方案[2]。然而，邊緣服務(wù)的可靠性是亟待解決的問(wèn)題，服務(wù)可靠性的重要方面，就是服務(wù)數(shù)據(jù)的容災(zāi)特性[3]。為提高服務(wù)的可靠性，以克服邊緣服務(wù)的不穩(wěn)定性，就需要提高其服務(wù)的容災(zāi)特性。

國(guó)內(nèi)外研究者們對(duì)邊緣計(jì)算的可靠性研究[4-6]，在小范圍的故障時(shí)可提高系統(tǒng)可靠性，而對(duì)地震、洪災(zāi)等不可抗災(zāi)難則是無(wú)效的。近年來(lái)，研究者們研究了基于集中式云計(jì)算的容災(zāi)。Alexander Lenk等[7]提出了一種將云中的分布式系統(tǒng)復(fù)制到另一個(gè)云的新方法。Yu Wan等[8]設(shè)計(jì)了一種用于備份HDFS數(shù)據(jù)的系統(tǒng)，能夠以高速實(shí)現(xiàn)客戶端與遠(yuǎn)程服務(wù)器之間的備份和恢復(fù)。Wang等[9]分析了云托管企業(yè)應(yīng)用程序的災(zāi)難恢復(fù)，提出一種調(diào)度算法。由此，現(xiàn)有研究主要針對(duì)集中式云計(jì)算中心而建立一套備份容災(zāi)系統(tǒng)[10]，但物聯(lián)網(wǎng)邊緣計(jì)算的邊緣服務(wù)器較密集，必須研究適合于物聯(lián)網(wǎng)邊緣計(jì)算特點(diǎn)的容災(zāi)方案和容災(zāi)算法。

綜上，為解決物聯(lián)網(wǎng)邊緣計(jì)算的服務(wù)容災(zāi)問(wèn)題，以確保邊緣服務(wù)器上的數(shù)據(jù)安全性，提出一種基于站點(diǎn)協(xié)作的容災(zāi)方案，并對(duì)該容災(zāi)方案的算法進(jìn)行設(shè)計(jì)。同時(shí)，通過(guò)多臺(tái)虛擬機(jī)模擬邊緣服務(wù)器，搭建一個(gè)小型容災(zāi)系統(tǒng)，對(duì)所提出的容災(zāi)算法的執(zhí)行延遲時(shí)間以及系統(tǒng)可靠性與增加中間件的方案進(jìn)行比較，突出本文算法的優(yōu)越性。

1 物聯(lián)網(wǎng)邊緣服務(wù)容災(zāi)架構(gòu)

物聯(lián)網(wǎng)概念從提出到應(yīng)用，其體系結(jié)構(gòu)亦在不斷進(jìn)行演化和變遷，僅集中式物聯(lián)網(wǎng)已由5層系統(tǒng)結(jié)構(gòu)演變?yōu)槿龑幽Ｊ?，又由三層向多層模式轉(zhuǎn)化。在集中式三層/多層物聯(lián)網(wǎng)體系結(jié)構(gòu)中，感知層數(shù)據(jù)通過(guò)網(wǎng)絡(luò)層傳輸?shù)皆浦行倪M(jìn)行處理；而云中心存儲(chǔ)能力不足、骨干網(wǎng)絡(luò)帶寬需求高等問(wèn)題，已成為物聯(lián)網(wǎng)發(fā)展和應(yīng)用的瓶頸。

隨著邊緣計(jì)算概念的提出和不斷發(fā)展，以使物聯(lián)網(wǎng)由集中式向邊緣計(jì)算模式進(jìn)化。物聯(lián)網(wǎng)邊緣計(jì)算在靠近感知層增加邊緣服務(wù)節(jié)點(diǎn)，能夠?qū)Υ蟛糠謹(jǐn)?shù)據(jù)進(jìn)行處理、卸載與計(jì)算任務(wù)調(diào)度等，從而使車聯(lián)網(wǎng)、增強(qiáng)現(xiàn)實(shí)和工業(yè)物聯(lián)網(wǎng)等延遲敏感型應(yīng)用成為可能。此外，通過(guò)靠近用戶的邊緣服務(wù)節(jié)點(diǎn)處理數(shù)據(jù)，減少傳到云中心的數(shù)據(jù)流量，從而降低云中心數(shù)據(jù)存儲(chǔ)量和減少網(wǎng)絡(luò)帶寬等。物聯(lián)網(wǎng)邊緣計(jì)算的邊緣服務(wù)容災(zāi)是針對(duì)邊緣服務(wù)節(jié)點(diǎn)層，通過(guò)邊緣服務(wù)節(jié)點(diǎn)間協(xié)作而成為一個(gè)自組織的容災(zāi)子系統(tǒng)，以實(shí)現(xiàn)系統(tǒng)遭遇區(qū)域性災(zāi)害時(shí)的保護(hù)數(shù)據(jù)，同時(shí)，提高邊緣服務(wù)的可靠性、延伸服務(wù)的連續(xù)性。因此，增加邊緣服務(wù)節(jié)點(diǎn)后的物聯(lián)網(wǎng)邊緣計(jì)算體系結(jié)構(gòu)，如圖1(a)所示。

圖1 物聯(lián)網(wǎng)邊緣服務(wù)容災(zāi)架構(gòu)

物聯(lián)網(wǎng)邊緣計(jì)算的邊緣服務(wù)容災(zāi)后，容災(zāi)體系結(jié)構(gòu)如圖1(b)所示。容災(zāi)組成架構(gòu)中的源服務(wù)器(source server，Ss)，在用戶購(gòu)買容災(zāi)服務(wù)時(shí)，由通信人員指定，主要為用戶提供相關(guān)服務(wù),并將用戶數(shù)據(jù)同步或異步復(fù)制到災(zāi)備服務(wù)器；近距離災(zāi)備服務(wù)器(short-range disaster recovery server,S-DRS)，由Ss根據(jù)相鄰服務(wù)器的鏈路情況選擇，正常情況下，Ss將數(shù)據(jù)同步復(fù)制到S-DRS，保證在節(jié)點(diǎn)或網(wǎng)絡(luò)故障時(shí)RPO、RTO接近0，Ss故障時(shí)，S-DRS 接替其工作，具體如何切換到備用服務(wù)器不是本項(xiàng)工作的內(nèi)容，可參考Ayari等[11]的研究；遠(yuǎn)距離災(zāi)備服務(wù)器(remote disaster recovery server, R-DRS)通過(guò)相鄰最遠(yuǎn)的服務(wù)器之間傳遞Req數(shù)據(jù)報(bào)協(xié)作得到，用于異地保存Ss的數(shù)據(jù)，在發(fā)生區(qū)域性災(zāi)難時(shí)，如地震、洪水、停電等，能夠根據(jù)用戶需求，不同程度地保護(hù)數(shù)據(jù)不被丟失。S-DRS 和R-DRS同時(shí)也作為其他用戶的Ss，每個(gè)邊緣服務(wù)器處于熱備用狀態(tài)，不會(huì)浪費(fèi)邊緣服務(wù)器的計(jì)算能力。

2 容災(zāi)算法

基于提出的容災(zāi)架構(gòu)，設(shè)計(jì)了相應(yīng)的容災(zāi)算法。本部分從DR(disaster recovery)數(shù)據(jù)報(bào)的格式、算法描述兩方面對(duì)算法進(jìn)行設(shè)計(jì)。

2.1 DR數(shù)據(jù)報(bào)格式

DR數(shù)據(jù)報(bào)是本文容災(zāi)算法中數(shù)據(jù)報(bào)的總稱，如表1所示，DR數(shù)據(jù)報(bào)中各個(gè)部分的含義如下：

Sid：源服務(wù)器的IP地址。Sid與普通網(wǎng)絡(luò)的IP地址不同，當(dāng)搜尋R-DRS時(shí)，中間的邊緣服務(wù)器不能修改Sid，僅符合Sid的邊緣服務(wù)器返回ReqACK應(yīng)答數(shù)據(jù)報(bào)，則返回該應(yīng)答的邊緣服務(wù)器即為R-DRS。

Did：目標(biāo)IP地址。

Type：DR數(shù)據(jù)報(bào)的類型，共有以下4種。

Message：普通的數(shù)據(jù)報(bào)。

ASK：鄰接服務(wù)器間間歇互發(fā)的測(cè)試服務(wù)可達(dá)性的問(wèn)候數(shù)據(jù)報(bào)，并以此更新服務(wù)器的鏈路信息表。

Req：尋找R-DRS時(shí)發(fā)送的詢問(wèn)數(shù)據(jù)報(bào)。

ReqACK：對(duì)于Req數(shù)據(jù)報(bào)，若當(dāng)前服務(wù)器滿足容災(zāi)的距離要求，則返回ReqACK應(yīng)答數(shù)據(jù)報(bào)給源服務(wù)器。

Time：DR數(shù)據(jù)報(bào)發(fā)送的時(shí)間戳。

Distance：當(dāng)前邊緣服務(wù)器到Ss的鏈路距離。

Dmax：容災(zāi)的距離要求，由用戶購(gòu)買容災(zāi)服務(wù)的等級(jí)決定。

Data：數(shù)據(jù)部分。

表1 DR數(shù)據(jù)報(bào)格式

2.2 數(shù)據(jù)庫(kù)表

服務(wù)器鄰接狀態(tài)表(tblNeighbor,tblNB)，用于保存服務(wù)器到相鄰服務(wù)器的鏈路距離，見表2。Neighbor為鄰接服務(wù)器的IP地址，d為到對(duì)應(yīng)鄰接服務(wù)器之間的距離。具體如何得到在下一節(jié)的算法描述中介紹。

表2 tblNB

服務(wù)器容災(zāi)信息表(tblDisasterRecovery,tblDR)，用于保存服務(wù)器的容災(zāi)對(duì)象，即服務(wù)器作為用戶的源服務(wù)器，則為該用戶添加一條數(shù)據(jù)，其結(jié)構(gòu)見表3。UserIP為用戶的IP地址，IsDR表示該用戶是否購(gòu)買了容災(zāi)服務(wù)，Dmax為該用戶對(duì)容災(zāi)距離的要求，S-DRS和R-DRS分別為相應(yīng)服務(wù)器的IP地址。UserIP、IsDR和Dmax這3項(xiàng)是在用戶購(gòu)買容災(zāi)服務(wù)時(shí)告知通信人員，通信人員將信息插入數(shù)據(jù)庫(kù)表中，此時(shí)S-DRS和R-DRS為空，Ss通過(guò)執(zhí)行相關(guān)的容災(zāi)算法，得到S-DRS和R-DRS。

表3 tblDR

2.3 算法描述

本文采用基于事件的方式呈現(xiàn)算法，分別對(duì)建立tblNB表、建立tblDR表和處理Message數(shù)據(jù)報(bào)進(jìn)行描述。

2.3.1 建立tblNB表

在createtblNB算法中，首先建立一個(gè)tblNB表，然后創(chuàng)建一個(gè)子線程，函數(shù)接口為receiveASK，主線程每隔 10 s 向相鄰服務(wù)器發(fā)送ASK數(shù)據(jù)報(bào)。receiveASK函數(shù)監(jiān)聽當(dāng)前服務(wù)器端口為9900處的數(shù)據(jù)報(bào)，計(jì)算接收到的數(shù)據(jù)報(bào)中的時(shí)間戳與當(dāng)前時(shí)間戳之差，結(jié)合數(shù)據(jù)傳輸速率，估算出相鄰兩個(gè)服務(wù)器間的距離d，若當(dāng)前tblNB表中的Neighbor不包含接收到數(shù)據(jù)報(bào)的Sid，則將Sid和對(duì)應(yīng)的距離d插入tblNB表中，若包含，則更新距離d的值，同時(shí)，若長(zhǎng)時(shí)間未再次收到表中鄰接服務(wù)器的ASK數(shù)據(jù)報(bào)，則將其從表中刪除。實(shí)現(xiàn)tblNB表在初始時(shí)的建立以及鏈路變化后的更新。其流程如圖2所示。

圖2 建立tblNB表的流程

建立tblNB表:

(1) create table tblNB

(2) create thread(reciveASK,&host)#線程監(jiān)聽ASK并更新tblNB

(3)whiletruethen

(4) wait 10 s #發(fā)送ASK間隔時(shí)間，可根據(jù)用戶情況修改

(5)Forip in tblNB.Neighborthen

(6) Send ASK to Neighbor

(7)EndFor

(8)EndWhile

2.3.2 建立tblDR表

在create算法中，創(chuàng)建了一個(gè)tblDR表并插入了一條UserIP為‘192.168.56.109’的數(shù)據(jù)。源服務(wù)器通過(guò)遍歷tblNB表得到S-DRS和最遠(yuǎn)的鄰接服務(wù)器(farthest adjacent server,Fas)，再向Fas發(fā)送Req數(shù)據(jù)報(bào)，等待符合要求的服務(wù)器返回ReqACK數(shù)據(jù)報(bào)。接收到Req數(shù)據(jù)報(bào)的服務(wù)器，根據(jù)數(shù)據(jù)報(bào)中的Dmax和Distance，以及自身的存儲(chǔ)能力，判斷是否滿足容災(zāi)要求，若滿足則返回ReqACK數(shù)據(jù)報(bào)，源服務(wù)器接收到ReqACK數(shù)據(jù)報(bào)則更新tblDR表中的R-DRS。其流程如圖3所示。

圖3 建立tblDR表的流程

建立tblDR表:

(1) create table tblDR

(2) insert (UserIp,IsDR,Dmax) into tblDR

(3)IfS-DRS and R-DRS is nullthen

(4) S-DRS←selecttblNB#查詢最近鄰接服務(wù)器

(5) Fas,d←selecttblNB#查詢最遠(yuǎn)鄰接服務(wù)器和對(duì)應(yīng)距離

(6) sendReq to Fas

(7) listening ReqACK #監(jiān)聽ReqACK數(shù)據(jù)報(bào)

(8) tblDR.R-DRS←ReqACK.Sid

(9)EndIf

2.3.3 處理Message數(shù)據(jù)報(bào)

接收到Message數(shù)據(jù)報(bào)保存到“server_data”文件中。然后判斷該數(shù)據(jù)報(bào)是否來(lái)自鄰接服務(wù)器，若是，則是作為S-DRS接收到該數(shù)據(jù)，不需要做其它操作；否則，將數(shù)據(jù)再寫入“server_data_temp”文件，調(diào)用handle_Message函數(shù)處理數(shù)據(jù)，將數(shù)據(jù)同步備份到S-DRS、將“server_data_temp”中的數(shù)據(jù)異步備份到R-DRS并清空“server_data_temp”文件中的數(shù)據(jù)，保證每次備份的數(shù)據(jù)不重復(fù)。其流程如圖4所示。

圖4 處理Message數(shù)據(jù)報(bào)

處理Message數(shù)據(jù):

(1)Whiletruethen

(2) Listening Message #監(jiān)聽Message

(3) Save Message.data to ‘server_data’ #保存數(shù)據(jù)

(4)IfMessage.Sid not exits in tblNBthen#Message來(lái)自用戶

(5) Write Data.data to ‘server_data_temp’

(6) create thread(backup to R-DRS)#異步備份并清空‘server_data_temp’文件

(7) send Message to S-DRS #同步備份

(8)EndIf

(9)EndWhile

由上可知，算法的相鄰服務(wù)器之間通過(guò)交換相關(guān)數(shù)據(jù)報(bào)，建立相鄰的鏈路信息表，依次向相鄰遠(yuǎn)端服務(wù)器發(fā)送詢問(wèn)R-DRS的數(shù)據(jù)報(bào)，根據(jù)返回結(jié)果建立容災(zāi)服務(wù)表，最后根據(jù)容災(zāi)服務(wù)表對(duì)用戶的數(shù)據(jù)進(jìn)行同步和異步的備份。該容災(zāi)算法可實(shí)現(xiàn)[12]，實(shí)現(xiàn)時(shí)，僅對(duì)尋找S-DRS、D-DRS以及數(shù)據(jù)備份過(guò)程進(jìn)行設(shè)計(jì)即可。

3 算法分析與驗(yàn)證

3.1 算法分析

3.1.1 時(shí)間消耗

在分析算法時(shí)間消耗時(shí)，假設(shè)鏈路材質(zhì)與距離等引起的傳輸延遲不計(jì)。

(1)建立tblNB表：時(shí)間消耗主要是發(fā)送和更新時(shí)查詢數(shù)據(jù)庫(kù)的時(shí)間。假設(shè)建立tblNB表的執(zhí)行時(shí)間為T1，相鄰服務(wù)器的數(shù)量為n，查詢tblNB表中一條數(shù)據(jù)的時(shí)間為t。則：T1=nt。

(2)建立tblDR表：時(shí)間消耗主要是遍歷tblNB表、發(fā)送Req數(shù)據(jù)報(bào)和等待ReqACK數(shù)據(jù)報(bào)。根據(jù)(1)中的假設(shè)，得到遍歷tblNB表的執(zhí)行時(shí)間為2nt。假設(shè)傳輸平均速率為v，則發(fā)送Req并等待接收ReqACK數(shù)據(jù)報(bào)的執(zhí)行時(shí)間為2(Dmax/v)，則建立tblDR表的執(zhí)行時(shí)間T2=2nt+2Dmax/v。

(3)處理Message數(shù)據(jù)報(bào)的時(shí)間消耗：主要是將數(shù)據(jù)分別同步、異步備份到S-DRS和R-DRS。根據(jù)上面的假設(shè)，發(fā)送到S-DRS的執(zhí)行時(shí)間T3=d/v+t； 同時(shí)，發(fā)送到R-DRS的執(zhí)行時(shí)間T4=Dmax/v+t。

綜上，執(zhí)行該算法的總時(shí)間為

T總=T1+T2+T3+T4=
nt+2nt+2Dmax/v+d/v+t+Dmax/v+t=
3nt+2t+3Dmax/v+d/v

(1)

式中：v和d的值取決于邊緣計(jì)算的鏈路設(shè)計(jì)，在邊緣服務(wù)器部署后是不變的，同時(shí)，查詢表中一條數(shù)據(jù)的時(shí)間t也是不變的，則執(zhí)行時(shí)間T總隨n的增加呈線性增長(zhǎng)。

3.1.2 空間消耗

tblNB表的大小與相鄰服務(wù)器數(shù)量相關(guān)，而數(shù)量n最多不過(guò)百條，在系統(tǒng)上所占的開銷很小。

tblDR表的大小與用戶數(shù)量有關(guān)，當(dāng)前服務(wù)器作為某一用戶的源服務(wù)器，該服務(wù)器便會(huì)新增一條相應(yīng)的記錄，由于邊緣服務(wù)器的密集部署，一個(gè)邊緣服務(wù)器負(fù)責(zé)的周圍區(qū)域并不會(huì)很大，所以tblDR表所需的開銷也很小。

處理Message數(shù)據(jù)報(bào)的空間消耗主要是保存用戶數(shù)據(jù)的“server_data”和“server_data_temp”文件，“server_data”文件是必要的，則空間的額外開銷主要是“server_data_temp”文件。

綜上，該算法所需系統(tǒng)的空間消耗主要是“server_data_temp”文件，而“server_data_temp”文件的內(nèi)容在每次向R-DRS異步備份后被清空，其大小取決于異步備份的間隔時(shí)間以及在此時(shí)間內(nèi)用戶的使用情況。這是一個(gè)NP難問(wèn)題，因?yàn)椴⒉荒茴A(yù)測(cè)用戶在此時(shí)間內(nèi)的使用情況。只能通過(guò)減小時(shí)間間隔來(lái)使“server_data_temp”文件所需空間更小，但是時(shí)間間隔的縮小必然會(huì)增加網(wǎng)絡(luò)流量負(fù)擔(dān)，將在后面的算法驗(yàn)證中得到“server_data_temp”文件大小與間隔時(shí)間以及用戶請(qǐng)求數(shù)量之間的關(guān)系圖，管理人員可根據(jù)邊緣設(shè)備的存儲(chǔ)能力以及用戶使用情況來(lái)設(shè)置異步備份的時(shí)間間隔。

3.1.3 系統(tǒng)可靠性

在本文提出的容災(zāi)架構(gòu)中，系統(tǒng)的失效率受邊緣節(jié)點(diǎn)以及鏈路故障影響，由于邊緣節(jié)點(diǎn)和鏈路只存在正常與故障兩種狀態(tài)，故采用故障樹(fault tree analysis，F(xiàn)TA)的方法來(lái)分析系統(tǒng)的失效率。

系統(tǒng)失效是在Ss、S-DRS、R-DRS服務(wù)同時(shí)故障的情況下發(fā)生，Ss、S-DRS、R-DRS服務(wù)故障分別是在對(duì)應(yīng)的邊緣服務(wù)器故障或到用戶的某一鏈路故障時(shí)出現(xiàn)，而邊緣服務(wù)器故障可能是硬件的損壞或自然災(zāi)害導(dǎo)致。此外，由于Ss、S-DRS距離很近，可以假定Ss和S-DRS同時(shí)遭遇自然災(zāi)害的破壞。基于此，對(duì)系統(tǒng)可靠性進(jìn)行故障樹建模如圖5所示。

圖5 容災(zāi)系統(tǒng)失效的故障樹

假設(shè)Ss、S-DRS、R-DRS服務(wù)器故障的概率分別為PM4、PM5、PM6，Ss、S-DRS、R-DRS服務(wù)故障的概率分別為PM1、PM2、PM3，整體系統(tǒng)失效的概率為PA01。根據(jù)FTA分析可得如下公式

PM4=Px1+Px2,PM5=Px1+Px2,PM6=Px1+Px4

(2)

PM1=kPx3+PM4=kPx3+Px1+Px2

(3)

PM2=mPx3+PM5=mPx3+Px1+Px2

(4)

PM3=nPx3+PM6=nPx3+Px1+Px4

(5)

PA01=PM1PM2PM3=(kPx3+Px1+Px2)
(mPx3+Px1+Px2)(nPx3+Px1+Px4)

(6)

式中:k、m、n分別代表Ss、S-DRS、R-DRS到用戶的鏈路數(shù)，與用戶的距離直接相關(guān)，此外，由圖1的物聯(lián)網(wǎng)邊緣服務(wù)容災(zāi)架構(gòu)可知，R-DRS到用戶的距離遠(yuǎn)大于Ss和S-DRS到用戶的距離，所以k≈m?n。

3.2 算法驗(yàn)證

實(shí)驗(yàn)基于Debian9.6.0系統(tǒng)，使用Python2以及內(nèi)置的sqlite3，采用socket通信編程實(shí)現(xiàn)。實(shí)驗(yàn)在同一局域網(wǎng)內(nèi)完成，共使用6臺(tái)虛擬機(jī)，模型如圖6所示，用戶默認(rèn)的Ss是“192.168.56.101”。根據(jù)實(shí)驗(yàn)的模型，通過(guò)ASK數(shù)據(jù)報(bào)建立tblNB表。設(shè)置用戶“192.168.56.109”的容災(zāi)距離要求為1 000 000，通過(guò)tblNB表以及Req數(shù)據(jù)報(bào)，得到用戶的S-DRS是“192.168.56.103”，R-DRS是“192.168.56.105”。下面將從時(shí)間、空間消耗以及系統(tǒng)的可靠性對(duì)算法分析進(jìn)行驗(yàn)證。

圖6 實(shí)驗(yàn)?zāi)Ｐ?/p>

3.2.1 時(shí)間消耗驗(yàn)證

首先模擬了相鄰服務(wù)器之間發(fā)送ASK數(shù)據(jù)報(bào)、監(jiān)聽ASK數(shù)據(jù)報(bào)并更新tblNB表的過(guò)程。在實(shí)驗(yàn)中，忽略數(shù)據(jù)報(bào)在鏈路上的傳輸時(shí)間以及發(fā)送ASK的間隔時(shí)間，得到發(fā)送和處理一條ASK數(shù)據(jù)報(bào)的執(zhí)行時(shí)間分別為10 ms、20 ms，則T1=30n(ms)。

然后模擬了建立tblDR表的過(guò)程，根據(jù)圖6的實(shí)驗(yàn)?zāi)Ｐ?，在虛擬機(jī)上運(yùn)行了createDR函數(shù)，根據(jù)時(shí)間戳之差，得到了在該模型中建立tblDR表所需時(shí)間約為T2=5300ms。

最后，模擬了備份數(shù)據(jù)的過(guò)程，忽略鏈路延遲，在虛擬機(jī)的理想狀態(tài)下，得到了備份一條數(shù)據(jù)到S-DRS的執(zhí)行時(shí)間為10 ms，備份一條數(shù)據(jù)到R-DRS的執(zhí)行時(shí)間20 ms。由于備份到R-DRS是異步進(jìn)行，則處理數(shù)據(jù)的延遲時(shí)間僅跟T3有關(guān)。假設(shè)用戶的請(qǐng)求包含N個(gè)數(shù)據(jù)報(bào)，則在處理每條數(shù)據(jù)時(shí)，算法的執(zhí)行時(shí)間T3=10N(ms)。

綜上，因?yàn)橹挥性诔跏蓟瘯r(shí)才需要建立tblNB和tblDR表，則算法在初始和真正運(yùn)行的執(zhí)行延遲時(shí)間分別為T初=30n+5300；T延=10N。

本文算法的初始時(shí)間消耗隨相鄰服務(wù)器數(shù)量增加的變化，如圖7所示。同時(shí)，將本文算法的執(zhí)行時(shí)間和文獻(xiàn)[5]中增加中間件方案的執(zhí)行時(shí)間進(jìn)行對(duì)比。顯然，本文算法雖然在初始化時(shí)需要消耗較多的時(shí)間，但是，在相鄰的邊緣服務(wù)器數(shù)量小于15臺(tái)時(shí)，本文算法的執(zhí)行延遲時(shí)間遠(yuǎn)低于文獻(xiàn)[5]中的方案，如圖8所示。

圖7 初始時(shí)間消耗

圖8 執(zhí)行延遲時(shí)間對(duì)比

3.2.2 空間消耗驗(yàn)證

在實(shí)驗(yàn)中，通過(guò)向tblNB表中插入多條數(shù)據(jù)，發(fā)現(xiàn)數(shù)據(jù)庫(kù)DRserver.db的大小并不是每插入一條數(shù)據(jù)便增長(zhǎng)，當(dāng)插入的數(shù)據(jù)小于233條時(shí)，通過(guò)”ls-l”命令查看到DRserver.db的大小為12 288字節(jié)，超過(guò)233條時(shí)，DRserver.db的大小增長(zhǎng)到20 480字節(jié)，可見，DRser-ver.db的大小是按照8192字節(jié)增長(zhǎng)。顯然，在本文提出的容災(zāi)架構(gòu)中，tblNB表和tblDR表中的數(shù)據(jù)均不會(huì)超過(guò)223條，則數(shù)據(jù)庫(kù)所占空間大小為12 288字節(jié)。對(duì)于”server_data_temp”臨時(shí)文件，所占空間的大小由間隔時(shí)間以及用戶的請(qǐng)求頻率決定，假設(shè)異步備份間隔時(shí)間為t，請(qǐng)求頻率為V(次/s)，每次請(qǐng)求包含數(shù)據(jù)量為N條，由TCP/IP通信協(xié)議可知，數(shù)據(jù)報(bào)每條不超過(guò)1460(Byte)。則文件所需大小為：S=(V*N*1460)/1024(Mbyte)。 通過(guò)模擬實(shí)驗(yàn),得到了臨時(shí)文件大小在不同的間隔時(shí)間內(nèi)隨用戶請(qǐng)求數(shù)量的變化，單位是Mbytes。在實(shí)際應(yīng)用中，異步備份間隔時(shí)間可根據(jù)用戶的使用情況以及用戶對(duì)容災(zāi)系統(tǒng)的級(jí)別要求選擇，容災(zāi)級(jí)別具有彈性。如圖9所示。

圖9 文件所占空間變化

3.2.3 可靠性驗(yàn)證

假設(shè)系統(tǒng)失效故障樹的基本事件情況見表4，在之后的實(shí)驗(yàn)中將在此假設(shè)的基礎(chǔ)上進(jìn)行。最終得出的結(jié)果通過(guò)對(duì)比得到，所以數(shù)值本身的大小對(duì)算法分析無(wú)影響，只需關(guān)注數(shù)值之間的大小。

基于以上假設(shè)，對(duì)式(6)進(jìn)行MATLAB仿真，由于k≈m?n， 可以假設(shè)k=m∈(1,10)，n∈(10,50)，得到系統(tǒng)失效率如圖10所示。

表4 故障樹的基本事件情況

對(duì)文獻(xiàn)[5]中增加中間件的方案進(jìn)行故障樹建模，如圖11所示。假設(shè)邊緣節(jié)點(diǎn)和簇頭服務(wù)故障的概率分別為PM21、PM22，邊緣節(jié)點(diǎn)和簇頭故障的概率分別為PM23和PM24，增加中間件方案的失效率為PA02。根據(jù)FTA分析得到如下公式

圖10 本文算法

PM23=PM24=Px1+Px2

(7)

PM21=PM23+Px3=Px1+Px2+kPx3

(8)

PM22=PM24+Px3=Px1+Px2+mPx3

(9)

PA02=PM21PM22=(Px1+Px2+kPx3)(Px1+Px2+mPx3)

(10)

圖11 增加中間件方案

由于邊緣節(jié)點(diǎn)與簇頭到用戶的鏈路數(shù)幾乎相同，可以假設(shè)k=m∈(1,10)， 通過(guò)MATLAB仿真得到如圖12所示關(guān)系。

圖12 增加中間件方案

由圖10與圖12對(duì)比可知，本文設(shè)計(jì)的容災(zāi)算法在系統(tǒng)失效率上平均低于文獻(xiàn)[5]方案的系統(tǒng)失效率，本文算法的可靠性更高。

4 容災(zāi)性能分析

4.1 網(wǎng)絡(luò)負(fù)載

本文采用iptables統(tǒng)計(jì)端口流量，得到了在建立tblNB表時(shí)，網(wǎng)絡(luò)負(fù)載隨著相鄰服務(wù)器數(shù)量增加的變化，如圖13所示。

圖13 網(wǎng)絡(luò)負(fù)載變化

在該表中，一條是Ss在9900端口處的INPUT/OUTPUT流量，另一條是該處的總計(jì)流量。由圖13可知，ASK數(shù)據(jù)報(bào)僅以每秒幾十字節(jié)進(jìn)行傳送，對(duì)網(wǎng)絡(luò)的負(fù)載影響很小；結(jié)合實(shí)際需求，調(diào)整發(fā)送ASK的間隔時(shí)間，以降低網(wǎng)絡(luò)負(fù)載或提高更新表的速度。

建立tblDR表時(shí)，網(wǎng)絡(luò)負(fù)載僅發(fā)送一條Req數(shù)據(jù)報(bào)和接收一條ReqACK數(shù)據(jù)報(bào)，且建立tblDR表僅在初始化時(shí)進(jìn)行。Message數(shù)據(jù)報(bào)是用戶的數(shù)據(jù)報(bào)。該算法下僅ASK數(shù)據(jù)報(bào)是額外的開銷，但對(duì)整個(gè)方案在網(wǎng)絡(luò)負(fù)載上對(duì)通信的影響是非常小的。

4.2 RPO

RPO(recovery point objective)是針對(duì)數(shù)據(jù)丟失的指標(biāo)，指災(zāi)難發(fā)生時(shí)刻與最后一次備份的時(shí)間間隔。S-DRS同步復(fù)制Ss的數(shù)據(jù)，若只有Ss故障，數(shù)據(jù)的丟失接近于0。R-DRS異步復(fù)制Ss的數(shù)據(jù)，若Ss與S-DRS同時(shí)故障，則數(shù)據(jù)的丟失主要取決于在異步備份的間隔時(shí)間內(nèi)，用戶傳輸?shù)絊s的數(shù)據(jù)。

圖14 丟失數(shù)據(jù)變化

5 結(jié)束語(yǔ)

邊緣計(jì)算的興起是必然的，主要探討基于邊緣計(jì)算特性的容災(zāi)算法。通過(guò)邊緣服務(wù)器本身進(jìn)行容災(zāi)，突破傳統(tǒng)容災(zāi)的局限性，降低容災(zāi)成本和復(fù)雜性，提高容災(zāi)服務(wù)質(zhì)量。通過(guò)算法分析和實(shí)驗(yàn)驗(yàn)證，從執(zhí)行時(shí)間延遲和可靠性突出該算法的優(yōu)越性，同時(shí)，也從空間消耗、網(wǎng)絡(luò)負(fù)載、RPO驗(yàn)證了該算法的可行性。通過(guò)合理地部署邊緣服務(wù)器，優(yōu)化容災(zāi)方案，為邊緣服務(wù)器的部署提供容災(zāi)措施。當(dāng)然，該方案亦存在不足，如在Ss選擇R-DRS時(shí)，若Req數(shù)據(jù)報(bào)未按單方向發(fā)送，可能導(dǎo)致累加的鏈路距離遠(yuǎn)遠(yuǎn)大于Ss與R-DRS之間的地理距離，不過(guò)這種隱患很少出現(xiàn)，亦或存在其它方面的不足，下一步將從這些不足入手，進(jìn)行深入研究。