TIPC在嵌入式集群系統(tǒng)中的應(yīng)用與優(yōu)化*

施 思，葉建芳，何 睿

(東華大學(xué) 信息科學(xué)技術(shù)學(xué)院，上海 201600)

0 引言

目前嵌入式系統(tǒng)應(yīng)用廣泛，其與網(wǎng)絡(luò)的結(jié)合早已成為發(fā)展的大趨勢(shì)。嵌入式系統(tǒng)是一個(gè)實(shí)時(shí)系統(tǒng)，具有實(shí)時(shí)系統(tǒng)的根本特點(diǎn)。嵌入式系統(tǒng)通信的實(shí)時(shí)性問(wèn)題不單指嵌入式系統(tǒng)本身的實(shí)時(shí)性，更包括各種嵌入式設(shè)備互連通信的網(wǎng)絡(luò)和應(yīng)用的實(shí)時(shí)性，包括協(xié)議層面的實(shí)時(shí)性保證和應(yīng)用層面的實(shí)時(shí)性處理。

傳統(tǒng)的TCP/IP將大把的精力花在保證數(shù)據(jù)傳送的可靠性及流量控制上，在設(shè)計(jì)時(shí)考慮了互聯(lián)網(wǎng)傳輸延時(shí)大、傳輸差錯(cuò)率較高等特性，過(guò)于復(fù)雜且需要大量的系統(tǒng)資源，而嵌入式設(shè)備本身資源緊張，對(duì)實(shí)時(shí)性要求又較高，而且TCP無(wú)法實(shí)現(xiàn)高優(yōu)先級(jí)包的有效傳輸，因而傳統(tǒng)的TCP/IP協(xié)議并不能滿足這類系統(tǒng)的要求[1-2]。

TIPC(Transparent Inter Process Communication protocol)專門為集群間通信設(shè)計(jì)，具有良好的實(shí)時(shí)性[3]。本文將TIPC作為通信協(xié)議移植入嵌入式集群系統(tǒng)內(nèi)部網(wǎng)絡(luò)，提出基于TIPC高可用系統(tǒng)的設(shè)計(jì)方案，針對(duì)其短數(shù)據(jù)包吞吐量較低的問(wèn)題提出優(yōu)化設(shè)計(jì)。

1 TIPC概述

TIPC是一種透明的進(jìn)程間通信協(xié)議，將確認(rèn)/重傳、擁塞與流控等機(jī)制放在鏈路層實(shí)現(xiàn)從而減少消息響應(yīng)時(shí)間[4]。TIPC流式套接字通信的建立與拆除僅需3次報(bào)文的交互，同一節(jié)點(diǎn)內(nèi)采用Netlink[5]從而優(yōu)化了內(nèi)部的通信。節(jié)點(diǎn)間多條平行鏈路支持Load Sharing(負(fù)載分擔(dān))和Active/Standby(主/備)兩種模式，Active/Standby用于冗余保護(hù)，Load Sharing則類似于MPTCP[6]。實(shí)驗(yàn)表明TIPC在節(jié)點(diǎn)間的通信速度比TCP快大約35%，在節(jié)點(diǎn)內(nèi)通信時(shí)，其優(yōu)勢(shì)更為明顯。

TIPC網(wǎng)絡(luò)由一組節(jié)點(diǎn)組成，網(wǎng)絡(luò)嚴(yán)格分層，圖1為TIPC網(wǎng)絡(luò)拓?fù)洹＞W(wǎng)絡(luò)中每個(gè)節(jié)點(diǎn)都有一個(gè)由區(qū)域號(hào)、集群號(hào)和節(jié)點(diǎn)號(hào)組成的節(jié)點(diǎn)網(wǎng)絡(luò)地址，一般標(biāo)記為。除網(wǎng)絡(luò)地址外，TIPC為上層應(yīng)用提供了一種透明的邏輯服務(wù)地。兩者的映射關(guān)系以分布式數(shù)據(jù)庫(kù)的形式存于每一個(gè)節(jié)點(diǎn)的名字表中。

圖1 TIPC網(wǎng)絡(luò)拓?fù)?/p>

2 TIPC在嵌入式集群系統(tǒng)中的應(yīng)用

2.1 TIPC網(wǎng)絡(luò)系統(tǒng)的搭建

本文以某通信公司自主研發(fā)的10U OTN產(chǎn)品為研究背景，模型如圖2所示。該產(chǎn)品設(shè)計(jì)有多個(gè)卡槽用于插放板卡，即為TIPC網(wǎng)絡(luò)中的節(jié)點(diǎn)。主控卡A和B為雙機(jī)熱備，構(gòu)成一個(gè)HA。

圖2 板級(jí)間TIPC網(wǎng)絡(luò)的構(gòu)建

根據(jù)圖2所示的網(wǎng)絡(luò)規(guī)劃完成系統(tǒng)中所有節(jié)點(diǎn)的網(wǎng)絡(luò)地址和套接字接口的邏輯地址分配，如圖3所示。實(shí)驗(yàn)中僅使能了部分接口和板卡。

圖3 系統(tǒng)地址分配

2.2 基于TIPC的高可用系統(tǒng)設(shè)計(jì)

為防止控制節(jié)點(diǎn)故障而導(dǎo)致整個(gè)系統(tǒng)癱瘓，一般設(shè)計(jì)主控節(jié)點(diǎn)的熱備保護(hù)。主控節(jié)點(diǎn)A處于工作狀態(tài)時(shí)，B處于備用狀態(tài)，A一旦出現(xiàn)問(wèn)題，B隨即接替A的工作。系統(tǒng)高可用性遵循的是木桶原理：木桶的容量取決于最短的那根木塊。為實(shí)現(xiàn)系統(tǒng)的高可用性[7]，除主控節(jié)點(diǎn)的熱備保護(hù)外，系統(tǒng)還需為通信鏈路設(shè)計(jì)冗余保護(hù)。高可用系統(tǒng)規(guī)劃如圖4所示。

圖4 系統(tǒng)的高可用性實(shí)現(xiàn)

2.2.1節(jié)點(diǎn)的高可用設(shè)計(jì)

TIPC邏輯服務(wù)地址可用于主控節(jié)點(diǎn)熱備保護(hù)中的透明切換。主控卡設(shè)置兩種不同instance值的接口，instance=0的接口用于與業(yè)務(wù)卡通信，另一類instance 的接口用于主控卡間通信。A和B擁有一些共同的虛擬接口,如{X,0}，{Y,0}。業(yè)務(wù)卡并不關(guān)注A和B何為備用卡，只需向{X, 0}, {Y, 0}等虛擬接口傳送消息。當(dāng)A處于工作狀態(tài)時(shí)，A和B均可獲取來(lái)自業(yè)務(wù)卡的消息，由A進(jìn)行消息的響應(yīng)，B處于沉默狀態(tài)；當(dāng)主控卡A由于某種原因發(fā)生故障時(shí)，備用卡B隨即啟用并代替A響應(yīng)業(yè)務(wù)卡。上述整個(gè)過(guò)程中A和B之間的切換對(duì)于業(yè)務(wù)卡而言是全透明的。

2.2.2通信鏈路的高可用性設(shè)計(jì)

TIPC中多Link的機(jī)制具備類似MPTCP的功能。Link在創(chuàng)建時(shí)可指定優(yōu)先級(jí)(Link Priority)。節(jié)點(diǎn)間同時(shí)存在多條Link時(shí)，Link Priority決定了它們之間的關(guān)系。Link間的關(guān)系分為兩種：負(fù)載分擔(dān)(Load Sharing)以及主備保護(hù)(Active/Standby)。當(dāng)Link優(yōu)先級(jí)相同時(shí)，進(jìn)行負(fù)載分擔(dān)；當(dāng)Link優(yōu)先級(jí)不同時(shí)，高優(yōu)先級(jí)的Link為Active狀態(tài)，低優(yōu)先級(jí)的Link為Standby狀態(tài)。利用TIPC多Link的機(jī)制完成系統(tǒng)中不同類型流量的分流管控和冗余保護(hù)。如圖4所示，主控卡A和B設(shè)計(jì)有兩塊網(wǎng)卡分別為eth1和eth2，業(yè)務(wù)卡僅有一塊網(wǎng)卡eth1，所有eth1均接到同一背板交換芯片上，而主控卡的eth2連接至另一塊背板交換芯片，即所有eth1共用背板總線1，eth2共用背板總線2。為隔離主控卡之間的流量與主控卡業(yè)務(wù)卡之間的流量，可在主控卡上為eth1和eth2設(shè)置不同的優(yōu)先級(jí)，eth2優(yōu)于eth1。如圖5所示，在主控卡A和主控卡B之間存在兩條鏈路，分別為L(zhǎng)ink1(1.1.101:eth1—1.1.102:eth1)和Link2(1.1.101:eth2—1.1.102:eth2)。Link1的優(yōu)先級(jí)為9，Link2的優(yōu)先級(jí)為10，故Link1處于備用(standby)狀態(tài)，Link2處于活躍(active)狀態(tài)。兩節(jié)點(diǎn)之間的流量傳輸由Link2負(fù)責(zé)，當(dāng)Link2出現(xiàn)故障時(shí)，Link1狀態(tài)轉(zhuǎn)為active，從而實(shí)現(xiàn)鏈路冗余保護(hù)。

圖5 TIPC的鏈路冗余

3 板級(jí)間通信環(huán)境中TIPC的優(yōu)化

研究發(fā)現(xiàn)，相比TCP/IP，TIPC在通信的實(shí)時(shí)性上有明顯的優(yōu)勢(shì)，但當(dāng)傳輸?shù)南⑹谴罅康男?shù)據(jù)報(bào)文時(shí)，TIPC的吞吐量不及TCP/IP。這一現(xiàn)象的原因在于TCP協(xié)議中使用Nagle算法[8]，該算法很好地解決了網(wǎng)絡(luò)環(huán)境較差情況下短幀泛濫的問(wèn)題。Nagle算法是一種自適應(yīng)的組塊技術(shù)，用確認(rèn)的到達(dá)來(lái)觸發(fā)其余數(shù)據(jù)的傳輸，它沒有引入額外的延時(shí)，且能有效減少網(wǎng)絡(luò)上小數(shù)據(jù)包的流量。

TIPC中存在一種稱之為消息捆綁 (Message Bundling) 的機(jī)制。不同于純粹的組包技術(shù)，Message Bundling捆綁的不是data，而是包含TIPC頭部在內(nèi)的消息，因此在帶寬利用率上并不會(huì)有很大的提高。而且Message Bundling是用于擁塞的快速恢復(fù)而不是避免擁塞。

3.1 Nagle算法

Nagle算法針對(duì)的是連接的發(fā)送方，在TCP中原理如下：連接中的第一個(gè)發(fā)送數(shù)據(jù)包到達(dá)緩沖區(qū)后直接發(fā)送。在已經(jīng)傳輸?shù)臄?shù)據(jù)還沒有被確認(rèn)的情況下，發(fā)送方的應(yīng)用程序發(fā)生了后續(xù)數(shù)據(jù)，并照常送到輸出緩沖區(qū)，但這時(shí)并不直接發(fā)送后續(xù)報(bào)文段，而是等到有足夠的數(shù)據(jù)填滿一個(gè)達(dá)到最大長(zhǎng)度MSS(Maximum Segment Size，最大分段大小)的報(bào)文段之后或者在此期間接收到上一個(gè)數(shù)據(jù)包的ACK信息后再把緩沖區(qū)中的等待數(shù)據(jù)一起發(fā)送出去，如果新的數(shù)據(jù)包長(zhǎng)度本身大于MSS，則直接發(fā)送。

利用MATLAB建立簡(jiǎn)單的發(fā)送接收模型，分析Nagle算法如何根據(jù)網(wǎng)絡(luò)擁塞和數(shù)據(jù)流量情況自適應(yīng)地對(duì)短包進(jìn)行合理打包發(fā)送。模型的建立并非本文重點(diǎn)，故不詳述。圖6和圖7分別為網(wǎng)絡(luò)良好和一般情況下基于Nagle算法模型和普通模型的分析結(jié)果。數(shù)據(jù)接收曲線中，橫坐標(biāo)表示第i個(gè)應(yīng)用數(shù)據(jù)到達(dá)發(fā)送緩沖區(qū)的時(shí)間，記為ti，縱坐標(biāo)表示應(yīng)用數(shù)據(jù)到達(dá)接收端的時(shí)間，記為tai。數(shù)據(jù)傳輸曲線中，橫坐標(biāo)表示應(yīng)用數(shù)據(jù)包編號(hào)，縱坐標(biāo)表示每個(gè)數(shù)據(jù)包從到達(dá)發(fā)送緩沖區(qū)到傳送至接收端的時(shí)間，記為t_trani，則t_trani=tai-ti。網(wǎng)絡(luò)情況較好時(shí)，兩個(gè)模型的表現(xiàn)基本一致，應(yīng)用數(shù)據(jù)到達(dá)緩沖區(qū)后都能及時(shí)發(fā)送并到達(dá)接收端。當(dāng)網(wǎng)絡(luò)環(huán)境一般或較差時(shí)，在普通發(fā)送模型中，每個(gè)應(yīng)用數(shù)據(jù)包不論大小均需添加一個(gè)報(bào)文頭后發(fā)送，增加了網(wǎng)絡(luò)負(fù)擔(dān)。從圖7可以看出每個(gè)數(shù)據(jù)包的傳輸時(shí)間t_trani越來(lái)越大并呈現(xiàn)發(fā)散的趨勢(shì)，而在Nagle模型中依舊能保持t_trani≈C，維持在一個(gè)較小的范圍內(nèi)并保持收斂。分析結(jié)果表明，在網(wǎng)絡(luò)帶寬資源相對(duì)有限時(shí)，Nagle算法能通過(guò)合理的數(shù)據(jù)包組塊提升網(wǎng)絡(luò)利用率，降低通信延時(shí)。

圖6 網(wǎng)絡(luò)良好時(shí)模型表現(xiàn)

圖7 網(wǎng)絡(luò)一般時(shí)模型表現(xiàn)

圖8 TIPC Link level 植入Nagle

3.2 Nagle算法在TIPC中的植入

TIPC在結(jié)構(gòu)上被分為3個(gè)層次：Connection Level、Link Level和Bear Level。不同于TCP/IP模型，TIPC的流控、確認(rèn)/重傳等機(jī)制主要在Link Level層實(shí)現(xiàn)，stream類型的TIPC連接在Connection Level也有部分這類機(jī)制。

Link Level的確認(rèn)是基于報(bào)文的。link每接收一個(gè)TIPC報(bào)文，不論是何種類型，計(jì)數(shù)器unacked_window加1，當(dāng)超過(guò)預(yù)設(shè)值TIPC_MIN_LINK_WIN時(shí)隨即返回一個(gè)Link_State報(bào)文給對(duì)端，該報(bào)文中攜帶確認(rèn)序列號(hào)。當(dāng)本端link上發(fā)送了任意一個(gè)TIPC報(bào)文(除廣播報(bào)文外)至對(duì)端后，都會(huì)將unacked_window重置為0。

每一個(gè)link都有一個(gè)發(fā)送緩沖隊(duì)列，當(dāng)長(zhǎng)度大于TIPC_MIN_LINK_WIN時(shí)，則認(rèn)為該link發(fā)生了擁塞。一旦link發(fā)生了擁塞，之后需要追加到該link 發(fā)送緩沖隊(duì)列中的數(shù)據(jù)需要進(jìn)行過(guò)濾篩選之后才會(huì)被追加到發(fā)送隊(duì)列，并且追加的方式也會(huì)有所不同，依據(jù)為數(shù)據(jù)包的優(yōu)先級(jí)，如LOW 優(yōu)先級(jí)的數(shù)據(jù)會(huì)直接被丟棄。

TCP的Nagle以同一TCP connection中上一個(gè)報(bào)文的ACK信息和待發(fā)數(shù)據(jù)長(zhǎng)度作為判定是否需要組包的依據(jù)。本文設(shè)計(jì)的TIPC Nagle在Link Level實(shí)現(xiàn)，根據(jù)同一link中前第TIPC_MIN_LINK_WIN個(gè)報(bào)文的ACK信息、同一Connection Level中待發(fā)數(shù)據(jù)包的長(zhǎng)度以及用戶數(shù)據(jù)的優(yōu)先級(jí)作為判定是否需要組包的依據(jù)，流程如圖8所示,虛線部分為植入Nagle而添加的處理流程。當(dāng)link發(fā)送隊(duì)列長(zhǎng)度大于TIPC_MIN_LINK_WIN時(shí)，即對(duì)端未及時(shí)發(fā)送ACK，將發(fā)送隊(duì)列同一connection上待發(fā)送的數(shù)據(jù)進(jìn)行組塊，判斷數(shù)據(jù)的優(yōu)先級(jí)，如果不是高優(yōu)先級(jí)數(shù)據(jù)則遵循原來(lái)的流程進(jìn)行數(shù)據(jù)包的處理，否則判斷隊(duì)列長(zhǎng)度和待發(fā)數(shù)據(jù)包的長(zhǎng)度，當(dāng)同時(shí)滿足發(fā)送隊(duì)列長(zhǎng)度小于TIPC_MAX_LINK_WIN，待發(fā)數(shù)據(jù)長(zhǎng)度大于MSS時(shí)，直接發(fā)送數(shù)據(jù)，否則依然遵循原來(lái)的流程。

3.3 結(jié)果分析

分別建立基于TCP和TIPC的server和client，由server向client連續(xù)發(fā)送1 000個(gè)僅含1 B的應(yīng)用數(shù)據(jù)，通過(guò)Wireshark抓取報(bào)文，并分析帶寬利用情況。圖9中自上而下分別為TCP、TIPC、Bundling TIPC以及Nagle TIPC模式下網(wǎng)絡(luò)流量情況。在TCP協(xié)議中由于采用了Nagle算法，應(yīng)用數(shù)據(jù)被打包發(fā)送，網(wǎng)絡(luò)帶寬的利用率達(dá)59.7%。在未經(jīng)改進(jìn)的TIPC中，網(wǎng)絡(luò)帶寬的利用率僅為2.2%；采用Message Bundling后，利用率提高為3.3%；在Link Level植入Nagle后，利用率可提高至22.5%，極大地提高了網(wǎng)絡(luò)帶寬的利用率。

圖9 網(wǎng)絡(luò)流量情況統(tǒng)計(jì)

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

本文提出了基于TIPC的高可用強(qiáng)實(shí)時(shí)嵌入式集群系統(tǒng)的設(shè)計(jì)方案。結(jié)合應(yīng)用數(shù)據(jù)的優(yōu)先級(jí)設(shè)計(jì)具有TIPC特色的Nagle算法并植入Link層中，提高了網(wǎng)絡(luò)狀態(tài)不佳時(shí)帶寬資源的利用率。

[1] 肖謙. 基于慢啟動(dòng)改進(jìn)的TCP擁塞控制算法研究[J]. 科技展望,2017,27(1):1-2.

[2] 王彬.TCP/IP網(wǎng)絡(luò)擁塞控制策略研究[D].杭州：浙江大學(xué),2004.

[3] 馮鵬斐，辛陽(yáng). Linux TIPC網(wǎng)絡(luò)協(xié)議棧的分析與改進(jìn) [C]//中國(guó)電子學(xué)會(huì)信息論分會(huì)，中國(guó)電子學(xué)會(huì)第十六屆信息論學(xué)術(shù)年會(huì)論文集,2009:781-787.

[4] 冀映輝，蔡煒，蔡惠智.TIPC透明進(jìn)程間通信協(xié)議研究和應(yīng)用[J]. 計(jì)算機(jī)系統(tǒng)應(yīng)用,2010,19(3):76-79，11.

[5] 周莉，柯健，顧小晶. Netlink套接字在Linux系統(tǒng)通信中的應(yīng)用研究[J]. 計(jì)算機(jī)與現(xiàn)代化,2007(3):109-111.

[6] Cao Yuanlong, Chen Shengyang, Liu Qinghua, et al. QoE-driven energy-aware multipath content delivery approach for MPTCP-based mobile phones[J]. China Communications,2017,14(2):90-103.

[7] 繆劍斌. 基于LVS的高可用負(fù)載均衡集群系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].北京：北京郵電大學(xué)，2010.

[8] NAGLE J. RFC896-Congestion control in IP/TCP internetworks[Z].Internet Engineering Task Force, 1984.