專利名稱：一種通信方法和系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種通信技術(shù)，尤其涉及一種互聯(lián)網(wǎng)領(lǐng)域內(nèi)的通信方法和系統(tǒng)。
背景技術(shù)：
隨著互聯(lián)網(wǎng)技術(shù)的快速發(fā)展，使用互聯(lián)網(wǎng)通信的人數(shù)也在飛速地攀升，這時，在互 聯(lián)網(wǎng)領(lǐng)域中的通信中，常常有許多不確定因素會導(dǎo)致通信故障，如，服務(wù)器故障等。為確保 通信的安全可靠，在現(xiàn)有技術(shù)中，有如下幾種方案。方案一、基于DNS (Domain Name System,域名系統(tǒng))輪詢的負載均衡如圖1所示，在該方案中，服務(wù)器池中的每一個服務(wù)器都是用一個獨立的 IPdnternet Protocol,網(wǎng)際協(xié)議)地址提供服務(wù)，客戶機經(jīng)由互聯(lián)網(wǎng)、核心L2/L3交換機 向DNS服務(wù)器請求解析所訪問的服務(wù)的域名時，DNS服務(wù)器將服務(wù)器池中的全部服務(wù)器的 IP地址都返回給用戶。不同的客戶端軟件會按照自身的規(guī)則選擇一個IP地址作為本次訪 問請求的目標(biāo)服務(wù)器地址。之后，客戶機和這臺服務(wù)器作點對點通信。然而，在該方案中存在以下缺點1、沒有一個用于檢查服務(wù)器服務(wù)健康狀態(tài)的設(shè)備或主機，服務(wù)器發(fā)生故障后，網(wǎng) 絡(luò)管理者無法得知這一情況。2、服務(wù)器與DNS服務(wù)之間沒有通信協(xié)調(diào)。某個服務(wù)器發(fā)生故障時，用戶仍然可以 從DNS服務(wù)中得到故障服務(wù)器的IP地址。因此，該用戶無法獲得正常的服務(wù)。3、在正常的維護工作中，從服務(wù)器池中撤出服務(wù)器會對用戶產(chǎn)生短期的影響。因 為DNS服務(wù)的數(shù)據(jù)更新和同步需要一個較長的時間過程，此時用戶可能會訪問到已經(jīng)撤下 的服務(wù)器的IP地址上。方案二、商業(yè)四層交換方案之inline (帶內(nèi)工作)模式如圖2所示，在該方案中，商用四層交換解決方案中的inline模式是采用“網(wǎng)關(guān)” 式的網(wǎng)絡(luò)結(jié)構(gòu)。服務(wù)器使用兩個四層(L4)交換機，其中，一臺交換機作為主用，假設(shè)為L4 交換機A;另一臺交換機作為備用，假設(shè)為L4交換機B。在兩臺四層交換機(即L4交換機 A和L4交換機B)之間需要一條專用的線纜連接用來同步更新用戶終端和服務(wù)器之間的網(wǎng) 絡(luò)連接狀態(tài)。四層交換機的IP地址為自身的默認網(wǎng)關(guān)?？蛻魴C通過互聯(lián)網(wǎng)、核心L2/L3交 換機對服務(wù)器的訪問被DNS服務(wù)器定向到四層交換機的IP地址，四層交換機接到訪問請求 后，將按照一定的輪換算法從服務(wù)器池中選擇某個服務(wù)器。以該服務(wù)器的IP地址為目標(biāo)地 址，以用戶的IP地址為源地址，將用戶的訪問請求轉(zhuǎn)發(fā)給該服務(wù)器。服務(wù)器想要將結(jié)果數(shù) 據(jù)回傳給用戶，就必須傳送給服務(wù)器的默認網(wǎng)關(guān)(四層交換機)。四層交換機收到服務(wù)器要 回傳給用戶的數(shù)據(jù)后，以自己的IP地址為源地址，用戶的IP地址為目標(biāo)地址，將數(shù)據(jù)回傳 給用戶。這樣，在用戶端看來，四層交換機就是服務(wù)器。四層交換機會定期模擬用戶的訪問請求發(fā)送給每一臺服務(wù)器池中的服務(wù)器，故障 的服務(wù)器會由此被四層交換機發(fā)現(xiàn)。四層交換機只會將真實用戶的請求轉(zhuǎn)發(fā)到正常的服務(wù) 器上，并可以按照網(wǎng)絡(luò)管理者的配置報告每個服務(wù)器的健康狀態(tài)。
然而，在該方案中存在以下缺點1.四層交換機必須處理用戶和服務(wù)器之間的全部網(wǎng)絡(luò)流量，這要求四層交換機具 有很高的性能，也意味著很高的成本。2.四層交換機的性能必須隨著用戶和服務(wù)器的增加而增加，也意味著成本隨之增 加。3.由于四層交換機A本身的單點故障風(fēng)險，所以四層交換機B必須時刻保留有足 夠的空余性能以應(yīng)對四層交換機A可能發(fā)生的故障。而如果四層交換機B上本身有承載其 它的四層交換服務(wù)，那么四層交換機A也必須時刻保留足夠的空余性能以應(yīng)對四層交換機 B可能發(fā)生的故障。也就是說四層交換機A和四層交換機B的總承載量之和不能超過四層 交換機A和四層交換機B性能之和的一半。4.用戶終端和服務(wù)器之間的網(wǎng)絡(luò)流量需要兩次經(jīng)過交換機，這使得交換機的負載 加倍。方案三、商業(yè)四層交換方案之單臂模式如圖2所示，商用四層交換解決方案中的單臂模式是采用類似于“單向網(wǎng)關(guān)”的網(wǎng) 絡(luò)結(jié)構(gòu)。用戶對服務(wù)器的訪問被DNS服務(wù)器定向到四層交換機的IP地址。四層交換機接到 訪問請求后，將按照一定的輪換算法從服務(wù)器池中選擇某個服務(wù)器，然后以用戶的IP地址 為源IP地址，仍然以原始的目的IP地址(四層交換機本身的IP)為目的IP地址，但是以目 標(biāo)服務(wù)器的MAC地址為目的地址轉(zhuǎn)發(fā)此以太網(wǎng)幀(frame)。服務(wù)器端的特殊設(shè)置是將四層 交換機本身的IP地址(數(shù)據(jù)報文中的目的IP)綁定在自身的一個非廣播型的網(wǎng)絡(luò)設(shè)備上， 比如Ioopback (回環(huán)網(wǎng)絡(luò)設(shè)備)或dummy(啞網(wǎng)絡(luò)設(shè)備)類設(shè)備。這樣，由于用戶請求中的 目的IP地址在服務(wù)器本身上也存在，服務(wù)器在收到四層交換機轉(zhuǎn)發(fā)過來的以太網(wǎng)幀后，將 按照普通的正常流程來處理。由于服務(wù)器看到的用戶請求中的源IP地址是真實的用戶本 身的IP地址，所以服務(wù)器將要返回的結(jié)果數(shù)據(jù)按照默認路由返給核心的三層交換機，而三 層交換機按照路由表將數(shù)據(jù)直接回傳給用戶。這樣，就實現(xiàn)了“單臂模式”的四層交換負載 均衡。四層交換機會定期模擬用戶的訪問請求發(fā)送給每一臺服務(wù)器池中的服務(wù)器，存在 故障的服務(wù)器會由此被四層交換機發(fā)現(xiàn)。四層交換機只會將用戶的請求轉(zhuǎn)發(fā)到正常工作的 服務(wù)器上，并可以按照網(wǎng)絡(luò)管理者的配置報告每個服務(wù)器的健康狀態(tài)。由于在這種網(wǎng)絡(luò)結(jié)構(gòu)中，四層交換機A本身存在單點故障風(fēng)險，所以需要另一臺 同樣性能規(guī)格的四層交換機B來做后備，四層交換機A和四層交換機B之間還需要一條專 用的線纜連接用來同步更新用戶和服務(wù)器之間的網(wǎng)絡(luò)連接狀態(tài)。然而，在該方案中存在以下缺點1.四層交換機仍然必須處理用戶到服務(wù)器方向的全部網(wǎng)絡(luò)流量，這仍然要求四層 交換機具有很高的性能。2.四層交換機的性能仍然必須隨著用戶和服務(wù)器的增加而增加，也意味著成本也 隨之增加。3.四層交換機A本身仍然存在單點故障風(fēng)險，四層交換機B必須時刻保留有足夠 的空余性能以應(yīng)對四層交換機A可能發(fā)生的故障。而如果四層交換機B上本身承載其他的 四層交換服務(wù)，那么四層交換機A也必須時刻保留有足夠的空余性能以應(yīng)對四層交換機B可能發(fā)生的故障。也就是說四層交換機A和四層交換機B的總承載量之和不能超過四層交 換機A和四層交換機B性能之和的一半。4.如圖2所示，用戶到服務(wù)器方向的網(wǎng)絡(luò)流量需要兩次經(jīng)過交換機，仍然使得交 換機的負載增加?？傊?，現(xiàn)有的通信系統(tǒng)存在通信效率低、成本高的問題。

發(fā)明內(nèi)容
本發(fā)明的實施例提供了一種通信方法和裝置，可解決現(xiàn)有通信系統(tǒng)通信效率低、 成本高的問題。本發(fā)明的實施例提供了一種通信系統(tǒng)，包括交換機、應(yīng)用服務(wù)器和管理服務(wù)器。所 述應(yīng)用服務(wù)器，用于接收交換機和/或管理服務(wù)器轉(zhuǎn)發(fā)的用戶請求，并處理該請求，將處理 結(jié)果發(fā)給交換機；所述交換機，用于將應(yīng)用服務(wù)器的處理結(jié)果轉(zhuǎn)發(fā)給用戶，并在管理服務(wù)器 的控制下將用戶請求轉(zhuǎn)發(fā)至目的地址對應(yīng)的應(yīng)用服務(wù)器或管理服務(wù)器；所述管理服務(wù)器， 用于監(jiān)控應(yīng)用服務(wù)器的狀態(tài)，并根據(jù)應(yīng)用服務(wù)器的狀態(tài)和預(yù)定規(guī)則控制交換機的數(shù)據(jù)轉(zhuǎn) 發(fā)，以便在應(yīng)用服務(wù)器故障時，使交換機將發(fā)往該故障應(yīng)用服務(wù)器的用戶請求轉(zhuǎn)發(fā)給管理 服務(wù)器。本發(fā)明實施例還提供了一種通信方法，包括步驟交換機接收用戶請求，并在管理 服務(wù)器的控制下將用戶請求轉(zhuǎn)發(fā)至目的地址對應(yīng)的應(yīng)用服務(wù)器或管理服務(wù)器；管理服務(wù) 器監(jiān)控應(yīng)用服務(wù)器的狀態(tài)，并根據(jù)應(yīng)用服務(wù)器的狀態(tài)和預(yù)定規(guī)則控制交換機的數(shù)據(jù)轉(zhuǎn)發(fā)， 以便在應(yīng)用服務(wù)器故障時，使交換機將發(fā)往該故障應(yīng)用服務(wù)器的用戶請求轉(zhuǎn)發(fā)給管理服務(wù) 器；應(yīng)用服務(wù)器接收交換機和/或管理服務(wù)器轉(zhuǎn)發(fā)的用戶請求，并處理該請求，將處理結(jié)果 發(fā)給交換機，并由交換機將應(yīng)用服務(wù)器的處理結(jié)果轉(zhuǎn)發(fā)給用戶。本發(fā)明的實施例通過管理服務(wù)器監(jiān)控應(yīng)用服務(wù)器的狀態(tài)，并根據(jù)應(yīng)用服務(wù)器的狀 態(tài)和預(yù)定規(guī)則控制交換機的數(shù)據(jù)轉(zhuǎn)發(fā)，以便在應(yīng)用服務(wù)器故障時，使交換機將發(fā)往該故障 應(yīng)用服務(wù)器的用戶請求轉(zhuǎn)發(fā)給管理服務(wù)器，可實現(xiàn)服務(wù)器的負載均衡、服務(wù)器故障屏蔽、自 身故障屏蔽、用戶透明模式訪問、故障恢復(fù)自愈合五項功能；由于在本發(fā)明的通信系統(tǒng)中， 在正常通信過程中，管理服務(wù)器不參與用戶終端與應(yīng)用服務(wù)器之間通信過程，只有在應(yīng)用 服務(wù)器故障時才參與通信系統(tǒng)的管理工作，因此，本發(fā)明的通信系統(tǒng)自身的負載，與用戶的 數(shù)量、訪問量無關(guān)，與應(yīng)用服務(wù)器的數(shù)量無關(guān)，只與服務(wù)器的故障率和故障恢復(fù)時間有關(guān)； 這樣就徹底解決了交換性能的提升與日益增長的網(wǎng)絡(luò)流量之間的矛盾，開辟了一個新型的 應(yīng)用模式。


圖1示出了現(xiàn)有技術(shù)的一種通信系統(tǒng)；圖2示出了現(xiàn)有技術(shù)的另一種通信系統(tǒng)；圖3示出了本發(fā)明實施例的主/備關(guān)系協(xié)商選舉模塊的流程；圖4示出了本發(fā)明實施例的以太網(wǎng)數(shù)據(jù)幀轉(zhuǎn)發(fā)模塊的流程；圖5示出了本發(fā)明實施例的ARP代理模塊的流程；圖6為本發(fā)明實施例的健康檢查模塊的流程；
圖7為本發(fā)明實施例的通信系統(tǒng)；圖8為本發(fā)明實施例的通信方法。
具體實施例方式為了便于本領(lǐng)域一般技術(shù)人員理解和實現(xiàn)本發(fā)明，現(xiàn)結(jié)合附圖描繪本發(fā)明的實施 例。實施例一本實施例提供了一種通信系統(tǒng)，其包括應(yīng)用服務(wù)器、交換機和管理服務(wù)器，下面分 別介紹它們的結(jié)構(gòu)和邏輯關(guān)系。應(yīng)用服務(wù)器，用于接收交換機和/或管理服務(wù)器轉(zhuǎn)發(fā)的用戶請求，并處理該請求， 將處理結(jié)果發(fā)給交換機。應(yīng)用服務(wù)器至少為一臺，優(yōu)選地，在本發(fā)明實施例中，應(yīng)用服務(wù)器為多臺，這些服 務(wù)器的功能是相同的，即為網(wǎng)絡(luò)用戶提供服務(wù)。而具體服務(wù)的功能可以根據(jù)安裝部署相應(yīng) 的應(yīng)用程序去實現(xiàn)。應(yīng)用服務(wù)器經(jīng)由交換機連接到其它網(wǎng)絡(luò)，比如INTERNET互聯(lián)網(wǎng))，本 文以下皆以INTERNET為例。來自INTERNET上的網(wǎng)絡(luò)用戶發(fā)起的用戶請求被交換機轉(zhuǎn)發(fā)給 應(yīng)用服務(wù)器，服務(wù)器返回的數(shù)據(jù)結(jié)果也經(jīng)由交換機回傳給遠端INTERNET上的用戶。在軟件層次上，應(yīng)用服務(wù)器的配置分成兩部分，一部分是服務(wù)配置，另一部分是管 理配置。服務(wù)配置是指服務(wù)器響應(yīng)用戶發(fā)出的請求返回結(jié)果數(shù)據(jù)的軟件配置。在本發(fā)明通 信系統(tǒng)中，用戶仍然需要從DNS服務(wù)獲得相應(yīng)服務(wù)的應(yīng)用服務(wù)器的IP地址列表。我們在此 將這些IP取名為ServicelPs，簡稱SVCIP，SVCIP與應(yīng)用服務(wù)器并不是一一對應(yīng)的，例如， 多個或一個SVCIP可以對應(yīng)一個應(yīng)用服務(wù)器。當(dāng)DNS服務(wù)中僅指配了一個SVCIP時，在服 務(wù)器池中的每一臺應(yīng)用服務(wù)器上都要配置該IP地址；當(dāng)DNS服務(wù)中指配了多個SVCIP時， 每一臺應(yīng)用服務(wù)器都要配置上全部的SVCIP。需要說明的是，為了避免IP地址沖突，應(yīng)用 服務(wù)器將SVCIP (—個或多個)綁定在其非廣播型的網(wǎng)絡(luò)接口上，比如Ioopback設(shè)備或是 dummy設(shè)備。這樣，每一臺應(yīng)用服務(wù)器都能對以任意SVCIP為目的的請求做出響應(yīng)。每一 臺應(yīng)用服務(wù)器上配置的SVCIP都是一樣的，無論有多少個SVCIP，為了區(qū)別每一臺應(yīng)用服務(wù) 器，就每一臺應(yīng)用服務(wù)器而言，必須再配置上一個不同與其他應(yīng)用服務(wù)器的IP用于定位某 一臺應(yīng)用服務(wù)器。我們在此將這些個IP取名叫krverlPs，簡稱SVRIP。每個應(yīng)用服務(wù)器 都有自己獨立的SVRIP，并且只有一個。SVRIP負擔(dān)著全部的管理工作，必須綁定在應(yīng)用服 務(wù)器的廣播型的物理網(wǎng)絡(luò)接口上，應(yīng)用服務(wù)器使用這個網(wǎng)絡(luò)接口連接到交換機，SVRIP和 SVCIP必須處于不同的子網(wǎng)(廣播域)中。交換機，用于將應(yīng)用服務(wù)器的處理結(jié)果轉(zhuǎn)發(fā)給用戶，并在管理服務(wù)器的控制下將 用戶請求轉(zhuǎn)發(fā)至目的地址對應(yīng)的應(yīng)用服務(wù)器或管理服務(wù)器。交換機是具有網(wǎng)絡(luò)數(shù)據(jù)交換功能的專用網(wǎng)絡(luò)設(shè)備。交換機一方面將各種網(wǎng)絡(luò)服務(wù) 器連接在一起，另一方面又和其它網(wǎng)絡(luò)(比如INTERNET)互聯(lián)。在本發(fā)明的通信系統(tǒng)中，交 換機將應(yīng)用服務(wù)器和管理服務(wù)器以及INTERNET連通，使得三者可以在“受控”的前提下相 互通信。受控是指信息傳輸?shù)哪康牡乜梢员唤粨Q機改變，而具體的改變策略又是根據(jù)初始 配置和各個設(shè)備的具體工作狀態(tài)共同確定的。在軟件技術(shù)層次上，所有應(yīng)用服務(wù)器的網(wǎng)絡(luò)接入都最終劃歸到交換機上的同一個
6VLAN(Virtual Local Area Network，虛擬局域網(wǎng))中。這個VLAN上綁有兩個IP地址，根 據(jù)它們相應(yīng)的掩碼，劃定出了兩個IP子網(wǎng)。這兩個子網(wǎng)用于分別覆蓋SVRIP和SVCIP，我們 把覆蓋SVRIP的子網(wǎng)叫做krver subnet，簡稱SVRNET ；把覆蓋SVCIP的子網(wǎng)叫做Service subnet,簡稱SVCNET。VLAN上的兩個IP也就成為了這兩個子網(wǎng)的默認網(wǎng)關(guān)地址，分別取名 叫作krver GateWay和krv ice GateWay，簡稱SVRGW和SVCGW。需要說明的是，雖然是在 同一個VLAN上，SVRNET和SVCNET沒有任何的重疊部分，它們是兩個獨立的廣播域?？偨Y(jié) 一下，SVRIP屬于SVRNET，其默認網(wǎng)關(guān)IP是SVRGW ；SVCIP屬于SVCNET，其默認網(wǎng)關(guān)IP是 SVCGff ；這兩個IP子網(wǎng)都在同一個VLAN上。管理服務(wù)器，用于監(jiān)控應(yīng)用服務(wù)器的狀態(tài)，并根據(jù)應(yīng)用服務(wù)器的狀態(tài)和預(yù)定規(guī)則 控制交換機的數(shù)據(jù)轉(zhuǎn)發(fā)，以便在應(yīng)用服務(wù)器故障時，使交換機將發(fā)往該故障應(yīng)用服務(wù)器的 用戶請求轉(zhuǎn)發(fā)給管理服務(wù)器。管理服務(wù)器是一個或多個獨立于應(yīng)用服務(wù)器的服務(wù)器設(shè)備，管理服務(wù)器是整個系 統(tǒng)的核心部分，它們對整個系統(tǒng)的工作進行指揮調(diào)度。在任何時刻，管理服務(wù)器都在監(jiān)控整 個系統(tǒng)各個設(shè)備的工作狀況。當(dāng)某個設(shè)備發(fā)生故障時，管理服務(wù)器會在第一時間發(fā)現(xiàn)這個 故障，對系統(tǒng)的整體配置進行修改，并利用自身的承載力彌補這一故障造成的性能和功能 上的損失，使得整體系統(tǒng)的應(yīng)用服務(wù)連續(xù)可用。在用戶看來，應(yīng)用服務(wù)沒有發(fā)生故障或中 斷，而對于系統(tǒng)管理維護者，可以有足夠的時間更換或修復(fù)故障的設(shè)備。根據(jù)本發(fā)明實施例，優(yōu)選地，管理服務(wù)器的數(shù)量可以在2臺到254臺之間任意選 擇，典型的配置為4臺。構(gòu)成管理服務(wù)器的硬件可以是普通的X86架構(gòu)的微型電子計算機。 操作系統(tǒng)軟件方面，管理服務(wù)器需要安裝提供公開的核心源代碼的操作系統(tǒng)，這一要求是 源于部分管理服務(wù)器應(yīng)用邏輯的代碼需要工作在操作系統(tǒng)的核心態(tài)，也就是說作為操作系 統(tǒng)核心的一部分來運行。這需要在現(xiàn)有的操作系統(tǒng)核心代碼的部分功能實現(xiàn)上作擴充修 改，在下文中會詳細描述。在物理連接方面，管理服務(wù)器使用一個網(wǎng)絡(luò)接口連接到交換機。其所處的VLAN與 應(yīng)用服務(wù)器相同。管理服務(wù)器上按照功能模塊劃分如下1、多臺管理服務(wù)器之間的主/備關(guān)系協(xié)商選舉模塊2、以太網(wǎng)數(shù)據(jù)幀轉(zhuǎn)發(fā)模塊3、ARP代理模塊4、健康檢查模塊下面參照附圖描述各個功能模塊的過程。如圖3所示，當(dāng)系統(tǒng)采用多臺管理服務(wù)器時，管理服務(wù)器包括主/備關(guān)系協(xié)商選舉 模塊，其用于向其它管理服務(wù)器組播本管理服務(wù)器上每個工作資源的優(yōu)先級，并通過組播 數(shù)據(jù)獲得其它管理服務(wù)器上每個工作資源的優(yōu)先級，根據(jù)各個管理服務(wù)器的每個工作資源 的優(yōu)先級的高低來決定本管理服務(wù)器上每個工作資源的工作狀態(tài)。主/備關(guān)系協(xié)商選舉模 塊的工作步驟如下步驟301、各個管理服務(wù)器組播自己的每個工作資源的優(yōu)先級。所述工作資源包 括BCIP、VSIP。步驟302、各個管理服務(wù)器由組播信息獲取其它管理服務(wù)器的每個工作資源的優(yōu)
7先級。步驟303、各個管理服務(wù)器判斷自己的工作資源的優(yōu)先級是否最高，若是，執(zhí)行步 驟304，否則，執(zhí)行步驟305。步驟304、設(shè)置本管理服務(wù)器的該工作資源為工作狀態(tài)，以便本管理服務(wù)器通過該 工作資源收發(fā)信息。步驟305、設(shè)置本管理服務(wù)器的該工作資源為待機狀態(tài)。如圖4所示，數(shù)據(jù)幀轉(zhuǎn)發(fā)模塊用于獲取并轉(zhuǎn)發(fā)包含有用戶請求的以太網(wǎng)幀。首先 是按照系統(tǒng)正常工作狀態(tài)構(gòu)建轉(zhuǎn)發(fā)向量表和連接狀態(tài)表，而后實時接收健康檢查模塊對轉(zhuǎn) 發(fā)向量表的更新數(shù)據(jù)并實時接受其它管理服務(wù)其對連接狀態(tài)表的更新數(shù)據(jù)，并根據(jù)本管理 服務(wù)器的工作資源狀態(tài)確定是否進行數(shù)據(jù)幀轉(zhuǎn)發(fā)操作，同時還要組播自身在連接狀態(tài)表產(chǎn) 生的變化信息。本發(fā)明的數(shù)據(jù)轉(zhuǎn)發(fā)機制同樣適用其它類型的網(wǎng)絡(luò)，所述轉(zhuǎn)發(fā)向量表的更新 數(shù)據(jù)包括BSVCIP、SVCIP、SVRIP和轉(zhuǎn)發(fā)規(guī)則(即，SVCIP與SVRIP之間的對應(yīng)關(guān)系)，所述 連接狀態(tài)表的更新數(shù)據(jù)包括UDP會話狀態(tài)、ICMP消息問答狀態(tài)和用戶和應(yīng)用服務(wù)器之間的 TCP連接狀態(tài)。數(shù)據(jù)幀轉(zhuǎn)發(fā)模塊工作步驟如下步驟401、讀取SVCIP、SVRIP和轉(zhuǎn)發(fā)表，所述轉(zhuǎn)發(fā)表包括正常工作的應(yīng)用服務(wù)器的 SVRIP。并建立轉(zhuǎn)發(fā)向量表和連接狀態(tài)表。步驟402、實時接收本管理服務(wù)器健康檢查模塊對轉(zhuǎn)發(fā)向量表的更新數(shù)據(jù)，并實時 接收其它管理服務(wù)其對連接狀態(tài)表的更新數(shù)據(jù)。步驟403、判斷本管理服務(wù)器的工作資源是否為工作狀態(tài)，若是，則執(zhí)行步驟404， 否則執(zhí)行步驟402。步驟404、接收交換機轉(zhuǎn)發(fā)的用戶請求，并按照某種算法，如輪詢、隨機、哈希映射 等算法，根據(jù)轉(zhuǎn)發(fā)向量表對用戶的請求數(shù)據(jù)幀執(zhí)行轉(zhuǎn)發(fā)操作，以便將本應(yīng)由故障應(yīng)用服務(wù) 器承擔(dān)的用戶請求轉(zhuǎn)發(fā)給正常的應(yīng)用服務(wù)器。用戶請求可根據(jù)SVCIP來確定。步驟405、組播連接狀態(tài)表的更新變化數(shù)據(jù)，以便在本管理服務(wù)器故障時其它管理 服務(wù)器接管轉(zhuǎn)發(fā)工作過程中不會導(dǎo)致網(wǎng)絡(luò)連接(比如tcp連接)中斷。如圖5所示，ARP代理模塊接收其它網(wǎng)絡(luò)設(shè)備對某IP地址的ARP查詢請求，并將 該IP地址對應(yīng)的MAC地址返回該網(wǎng)絡(luò)設(shè)備，所述ARP查詢用于獲得與SVCIP對應(yīng)的MAC地 址，所述網(wǎng)絡(luò)設(shè)備包括交換機，ARP代理模塊的工作步驟如下步驟501、讀取SVRIP列表，利用ARP協(xié)議獲得SVRIP對應(yīng)的MAC列表。步驟502、構(gòu)建SVCIP與MAC的對應(yīng)表(SVCIP-MAC表)。步驟503、接收健康檢查模塊的消息實時更新SVCIP-MAC表。如，當(dāng)SVCIP發(fā)生變 化時，SVCIP-MAC表也要發(fā)生變化。步驟504、判斷本管理服務(wù)器的工作資源是否為工作狀態(tài)，若是，則執(zhí)行步驟505， 否則執(zhí)行步驟503。步驟505、接收其它網(wǎng)絡(luò)設(shè)備用于獲得與SVCIP對應(yīng)的MAC地址的ARP查詢，并將 該MAC地址返回該網(wǎng)絡(luò)設(shè)備。所述網(wǎng)絡(luò)設(shè)備包括交換機。如圖6所示，健康檢查模塊用于檢查應(yīng)用服務(wù)器的狀態(tài)，以甄別故障應(yīng)用服務(wù)器 和正常工作的應(yīng)用服務(wù)器，借助ARP代理模塊，將SVCIP中原來被對應(yīng)到故障應(yīng)用服務(wù)器的 MAC地址的部分IP用管理服務(wù)器的VSIP所對應(yīng)的MAC地址替換，該替換結(jié)果最終表達在交換機的ARP表中，其工作步驟如下步驟601、讀取SVRIP列表，并模擬用戶訪問應(yīng)用服務(wù)器，以發(fā)現(xiàn)故障應(yīng)用服務(wù)器 及正常工作的應(yīng)用服務(wù)器。步驟602、將故障應(yīng)用服務(wù)器的IP按照某種算法，如輪詢、隨機、哈希映射等算法， 用管理服務(wù)器的VSIP替換，以構(gòu)建出新的SVRIP列表。步驟603、利用ARP協(xié)議獲得新的SVRIP對應(yīng)的MAC列表。步驟604、將正常工作的應(yīng)用服務(wù)器的SVRIP發(fā)送給數(shù)據(jù)幀轉(zhuǎn)發(fā)模塊。
步驟605、將SVCIP對應(yīng)的MAC地址發(fā)送給ARP代理模塊。步驟606、發(fā)送報警信息，并返回步驟601。下面對系統(tǒng)的整個運作原理進行說明在正常的(optimal)工作狀態(tài)下，管理服務(wù)器并不轉(zhuǎn)發(fā)用戶與應(yīng)用服務(wù)器之間的 通信數(shù)據(jù)。在前面講到過，任何一臺應(yīng)用服務(wù)器都能以任意SVCIP的身份提供服務(wù)，那么管 理服務(wù)器在這個情形下只需要按照一定的輪詢算法將用戶請求引導(dǎo)致某一臺應(yīng)用服務(wù)器 即可，而不用關(guān)心用戶請求中的目標(biāo)IP地址。管理服務(wù)器使用標(biāo)準(zhǔn)ARP協(xié)議完成這個工 作。當(dāng)用戶對某一 SVCIP的訪問請求抵達交換機時，遵照RFC擬6，交換機會在該SVCIP的可 直達路由端口所在的VLAN內(nèi)廣播一條ARP解析請求。由于SVCIP綁定在應(yīng)用服務(wù)器的非 廣播型的網(wǎng)絡(luò)接口上，該接口不會收到任何廣播信息，所以任何應(yīng)用服務(wù)器都不會對此ARP 解析請求做出回應(yīng)。然而，管理服務(wù)器上設(shè)有一個廣播型的網(wǎng)絡(luò)接口與該VLAN連接，這樣， 管理服務(wù)器就能夠接收到該ARP解析請求。然后管理服務(wù)器上的“ARP代理模塊”開始工 作，遵照RFC1027，按照預(yù)先人工配置的對應(yīng)關(guān)系(SVCIP與應(yīng)用服務(wù)器之間的關(guān)系)，選取 應(yīng)用服務(wù)器的SVRIP所在的網(wǎng)絡(luò)接口的MAC地址回應(yīng)給交換機。交換機在得到結(jié)果后，將 用戶的請求傳送到該應(yīng)用服務(wù)器的SVRIP所在的網(wǎng)絡(luò)接口上。由于用戶請求中的目的IP 地址(某個SVCIP)在應(yīng)用服務(wù)器本身上也存在，應(yīng)用服務(wù)器在收到該以太網(wǎng)幀后，將按照 普通的正常流程來處理。由于應(yīng)用服務(wù)器看到的用戶請求中的源IP地址是真實的用戶本 身的IP，所以應(yīng)用服務(wù)器將要返回的結(jié)果數(shù)據(jù)按照默認路由返給交換機，而交換機按照路 由表將數(shù)據(jù)直接回傳給用戶。這樣，就實現(xiàn)了在管理服務(wù)器不參與轉(zhuǎn)發(fā)的情形下的網(wǎng)絡(luò)通需要進一步說明的是，交換機會緩存ARP地址對照表一段時間，例如本發(fā)明的交 換機緩存ARP地址對照表4小時，在這一期間內(nèi)，交換機不會再廣播詢問而是直接使用自己 的緩存數(shù)據(jù)。也就是說，管理服務(wù)器在回應(yīng)ARP詢問這一工作上的資源消耗極少，可以忽略 不計。每個管理服務(wù)器上的一個廣播型的網(wǎng)絡(luò)接口都連接到SVCNET所在的VLAN，該網(wǎng)絡(luò) 接口上綁定的IP屬于SVCNET。由于該IP的作用是接收和回應(yīng)ARP廣播請求，我們稱之為 Broadcast IP簡稱BCIP。各個管理服務(wù)器的BCIP可以相同也可以不同，在下文中有解釋。當(dāng)多臺管理服務(wù)器協(xié)同工作時，為了避免ARP回應(yīng)沖突，同一時刻只能由一臺管 理服務(wù)器來處理來自交換機的ARP詢問請求。此時管理服務(wù)器靠“主/備選舉協(xié)商模塊”來 解決這個問題。主/備選舉協(xié)商模塊每隔一段時間組播(Multicast) —個以太網(wǎng)幀，其接收 者被配置為全部的管理服務(wù)器，同時也就能接收來自其它管理服務(wù)器的此類以太網(wǎng)幀。這 種機制實現(xiàn)了多臺管理服務(wù)器之間“工作資源”所有權(quán)的選舉協(xié)商，該以太網(wǎng)幀中包含有兩 部分信息，一部分是工作資源，另一部分是優(yōu)先級。典型的工作資源如IP地址，工作資源可
9以是包含一個IP地址，也可以是包含多個IP地址。各臺管理服務(wù)器在同一工作資源對應(yīng) 的優(yōu)先級被配置為不同的數(shù)值。這樣，對于某一個工作資源，通過使本管理服務(wù)器的優(yōu)先級 與收到的其它管理服務(wù)器組播的在的優(yōu)先級進行比較，管理服務(wù)器可以得知自己是否是對 該工作資源具有最高優(yōu)先級的管理服務(wù)器。如果是，管理服務(wù)器會將該工作資源置為活動 狀態(tài)，同時處理與該資源有關(guān)的一切工作任務(wù)；如果不是最高的優(yōu)先級，管理服務(wù)器會將該 工作資源置為休眠狀態(tài)，同時不處理任何與該資源有關(guān)的工作任務(wù)。在響應(yīng)ARP詢問請求這一工作上，管理服務(wù)器的工作資源就是BCIP。每個管理服 務(wù)器上都配有BCIP，BCIP可以相同也可以不同。只有優(yōu)先級最高的管理服務(wù)器才會“使用” 它的BCIP，進入工作狀態(tài)，既回應(yīng)ARP詢問請求。而其它的低優(yōu)先級的管理服務(wù)器會將各自 的BCIP保持在“休眠”狀態(tài)，既不處理任何與之相關(guān)的網(wǎng)絡(luò)信息，包括單播、組播和廣播。這 樣既不會出現(xiàn)IP沖突，也不會產(chǎn)生工作沖突。當(dāng)然最高優(yōu)先級的管理服務(wù)器發(fā)生故障時， 它已經(jīng)不能再向其它管理服務(wù)器組播自己的優(yōu)先級，原來的在BCIP這個資源上是次高優(yōu) 先級的管理服務(wù)器通過組播(multicast)方式發(fā)現(xiàn)它自己現(xiàn)在已經(jīng)是最高的優(yōu)先級了，于 是它激活自己的BCIP，進入工作狀態(tài)，在組播方式，管理服務(wù)器交流選舉信息，一段時間內(nèi)， 可能是幾秒鐘，對于某個工作資源，F(xiàn)8服務(wù)器收到其它管理服務(wù)器組播過來的優(yōu)先級數(shù)值， 如果都小于其自身對于該工作資源的優(yōu)先級設(shè)定值，管理服務(wù)器就會激活或保持該工作資 源為工作狀態(tài)。需要進一步說明的是，主/備選舉協(xié)商模塊工作在操作系統(tǒng)的內(nèi)核態(tài)，其實現(xiàn)代 碼與操作系統(tǒng)的網(wǎng)絡(luò)功能模塊代碼是一體的。這樣做的目的是為了保證當(dāng)管理服務(wù)器發(fā)生 部分軟件故障時，其應(yīng)用功能部分(例如回應(yīng)ARP)和選舉功能部分能夠保持一致的狀態(tài)， 既“能用都能用，不能用都不能用”。從而避免了出現(xiàn)管理服務(wù)器進入“選舉優(yōu)勝”卻功能失 效的狀態(tài)。如前文所述，在每一臺管理服務(wù)器的上，BCIP所在的網(wǎng)絡(luò)接口連接到SVCNET所在 的VLAN。而在這個網(wǎng)絡(luò)接口上，除了 BCIP和該網(wǎng)口自身固件中的MAC地址外，還綁定有額 外的IP地址和MAC地址；這些額外的IP地址屬于SVRNET，取名叫做Virtual Server IP，簡 稱VSIP ；而額外的MAC地址的取名叫做Virtual Server MAC，簡稱VSMAC。VSIP和VSMAC是 一一對應(yīng)的關(guān)系，每一對都構(gòu)成了一個工作資源。每一臺管理服務(wù)器都擁有“自己的” VSIP 和VSMAC，同時也必須擁有其它管理服務(wù)器的全部VSIP和VSMAC。管理服務(wù)器之間仍然是 使用“主/備選舉協(xié)商模決”來分載這些工作資源，上句話中的“自己的”的意思就是該資 源在默認配置中對應(yīng)在“主/備選舉協(xié)商模塊”中的優(yōu)先級與其它管理服務(wù)器比是最高的。每一臺管理服務(wù)器都關(guān)注每一臺應(yīng)用服務(wù)器的工作狀態(tài)，這個功能稱作“健康檢 查”。管理服務(wù)器通過設(shè)置健康檢查模塊來實現(xiàn)這一功能，管理服務(wù)器的健康檢查模塊可 以被配置為定期地將模擬用戶的訪問請求發(fā)送給每一臺應(yīng)用服務(wù)器，具體的訪問請求用例 可由系統(tǒng)管理者自行定義。對于能夠正?；貞?yīng)健康檢查測試的應(yīng)用服務(wù)器，健康檢查模 塊將應(yīng)用服務(wù)器在當(dāng)前配置中對應(yīng)SVCIP匯總成一個列表，名字叫做Active SVCIP，簡稱 ASVCIP。對于有故障的應(yīng)用服務(wù)器，健康檢查模塊也將應(yīng)用服務(wù)器在當(dāng)前配置中對應(yīng)SVCIP 匯總成一個列表，名字叫做Bad SVCIP,簡稱BSVCIP。顯然e ASVCIP U e BSVCIP = e SVCIP依照前文，“管理服務(wù)器上的ARP代理模塊按照預(yù)先人工配置的對應(yīng)關(guān)系，選取應(yīng)用服務(wù)器的SVRIP所在的網(wǎng)絡(luò)接口的MAC地址來回應(yīng)交換機對SVCIP的ARP解析請求?！?。但 是，當(dāng)BSVCIP出現(xiàn)時，意味著該應(yīng)用服務(wù)器發(fā)生故障不能提供服務(wù)，也意味著訪問BSVCIP 用戶即將遇到一個“無法連接服務(wù)器”的錯誤。為了避免用戶遇到這種狀況，管理服務(wù)器的 健康檢查模塊必須在第一時間處理這個問題，具體處理方法是按照一個預(yù)定的、盡可能均 衡的分配順序，將BSVCIP依次對應(yīng)到VSMAC，其效果趨向于每個VSMAC對應(yīng)的BSVCIP數(shù)量 一樣；之后，將這組新的對應(yīng)關(guān)系信息發(fā)送給ARP代理模塊；與此同時，將ASVCIP列表發(fā)送 給數(shù)據(jù)幀轉(zhuǎn)發(fā)模塊。ARP代理模塊收到更新信息后，立即將其覆蓋合并到默認的SVCIP-MAC 對應(yīng)表中，并以ARP Advertising的形式廣播全部的新SVCIP-MAC對應(yīng)表，其目的是通知交 換機將訪問目標(biāo)地址為BSVCIP的網(wǎng)絡(luò)流量轉(zhuǎn)向到管理服務(wù)器本身。與此同時，管理服務(wù)器 的數(shù)據(jù)幀轉(zhuǎn)發(fā)模塊收到了新的ASVCIP列表，隨即用它覆蓋原有的可用應(yīng)用服務(wù)器列表，按 照其自身的轉(zhuǎn)發(fā)規(guī)則繼續(xù)轉(zhuǎn)發(fā)工作。至此，健康檢查模塊完成了一個完整工作周期，并循環(huán) 開始下一個工作周期。數(shù)據(jù)幀轉(zhuǎn)發(fā)模塊的工作內(nèi)容是將所有的目標(biāo)MAC是自己本機上擁有的(通常是 VSMAC)并且目標(biāo)IP是SVCIP(通常是BSVCIP)的以太網(wǎng)幀，輪詢轉(zhuǎn)發(fā)給ASVCIP所對應(yīng)的 MAC地址所在的服務(wù)器(應(yīng)用服務(wù)器)。這句話比較難以理解，通俗的說就是“把本應(yīng)由故 障應(yīng)用服務(wù)器承擔(dān)的網(wǎng)絡(luò)服務(wù)請求轉(zhuǎn)發(fā)給正常的應(yīng)用服務(wù)器”。如前文所述，每個應(yīng)用服務(wù) 器都被配置成了能夠以任意一個SVCIP服務(wù)的狀態(tài)，所以應(yīng)用服務(wù)器不會“在意”網(wǎng)絡(luò)訪問 請求是來自用戶還是來自管理服務(wù)器，也不會“在意”其目標(biāo)IP是哪個SVCIP。而返回的 網(wǎng)絡(luò)流量則是根據(jù)用戶的來源IP走默認路由直接送給了交換機，并不經(jīng)過管理服務(wù)器。這 樣，數(shù)據(jù)幀轉(zhuǎn)發(fā)模塊只需要機械地轉(zhuǎn)發(fā)，而不需要記錄每一個網(wǎng)絡(luò)連接的狀態(tài)(如TCP的 狀態(tài))，也不需要處理返回的網(wǎng)絡(luò)流量，所以管理服務(wù)器的性能開銷很少。需要進一步說明 的是，數(shù)據(jù)幀轉(zhuǎn)發(fā)模塊一直處于工作狀態(tài)，其要轉(zhuǎn)發(fā)的來源網(wǎng)絡(luò)流量是否存在完全是由ARP 代理模塊控制的。這樣一來，用戶訪問到BSVCIP的網(wǎng)絡(luò)流量被均勻地轉(zhuǎn)發(fā)到了 ASVCIP的服務(wù)器上， 對用戶的服務(wù)得到了保證，而管理服務(wù)器自身也始終保持著最低的負載——只處理故障服 務(wù)器的進入方向的網(wǎng)絡(luò)流量。如圖7所示，下面再完整地解說一下各個工作狀態(tài)的變遷。假設(shè)預(yù)定規(guī)則為預(yù)設(shè)四臺管理服務(wù)器遇到若干個應(yīng)用服務(wù)器故障時的工作接手順序為D > C > B > A > D > C...方向循環(huán)，以達到盡可能的負載均衡；預(yù)設(shè)四臺管理服務(wù)器遇到自身故障時，對于總體調(diào)度這項工作的交接順序(選舉 優(yōu)先級)為A接D，B接A，C接B，D接C ；預(yù)設(shè)四臺管理服務(wù)器遇到自身故障時，對于原先承擔(dān)著的處理應(yīng)用服務(wù)器故障的 工作，其交接順序(選舉優(yōu)先級)為A接B，B接C，C接D，D接A。在上述預(yù)定規(guī)則中，盡可能做到處理服務(wù)器故障的工作要盡可能分配均勻，而自 身故障時，總體調(diào)度工作向后交接，處理應(yīng)用服務(wù)器故障的工作則向前交接。下面完整地解 說一下各個工作狀態(tài)的變遷。一、正常狀態(tài)設(shè)初始狀態(tài)為全部設(shè)備工作正常。本發(fā)明實施例的通信系統(tǒng)工作過程如下管理服務(wù)器A響應(yīng)交換機的工作調(diào)度詢問；
交換機把用戶終端的網(wǎng)絡(luò)流量直接轉(zhuǎn)發(fā)給應(yīng)用服務(wù)器；應(yīng)用服務(wù)器把返回的網(wǎng)絡(luò)流量經(jīng)由交換機回傳給用戶；管理服務(wù)器B，C，D處于空閑狀態(tài)。二、故障狀態(tài)1設(shè)初始狀態(tài)為應(yīng)用服務(wù)器1發(fā)生故障。本發(fā)明實施例的通信系統(tǒng)工作過程如下四臺管理服務(wù)器均監(jiān)測到應(yīng)用服務(wù)器1發(fā)生故障；根據(jù)預(yù)定規(guī)則管理服務(wù)器A負責(zé)整體工作調(diào)度；管理服務(wù)器A在網(wǎng)絡(luò)上廣播相應(yīng)的以太網(wǎng)地址變更信息，按照預(yù)定規(guī)則，交換機 隨即將用戶對故障應(yīng)用服務(wù)器1的訪問請求轉(zhuǎn)發(fā)到管理服務(wù)器D ；交換機把用戶訪問到正常應(yīng)用服務(wù)器的來源網(wǎng)絡(luò)流量直接轉(zhuǎn)發(fā)給正常工作的應(yīng) 用服務(wù)器；管理服務(wù)器D將交換機轉(zhuǎn)來的用戶的網(wǎng)絡(luò)訪問流量再次經(jīng)由交換機轉(zhuǎn)發(fā)給其它 的正常工作的應(yīng)用服務(wù)器；正常工作的應(yīng)用服務(wù)器把返回的網(wǎng)絡(luò)流量經(jīng)由交換機回傳給用戶；管理服務(wù)器B，C處于空閑狀態(tài)。三、故障狀態(tài)2設(shè)初始狀態(tài)為應(yīng)用服務(wù)器1發(fā)生故障；管理服務(wù)器A發(fā)生故障。本發(fā)明實施例的 通信系統(tǒng)工作過程如下管理服務(wù)器B，C，D均監(jiān)測到應(yīng)用服務(wù)器1發(fā)生故障；根據(jù)預(yù)定規(guī)則管理服務(wù)器B取代管理服務(wù)器A接手整體工作調(diào)度；根據(jù)預(yù)定規(guī)則管理服務(wù)器D接手管理服務(wù)器A上的處理故障應(yīng)用服務(wù)器的工作， 該工作包括原來存在的以及今后可能被分配過來的工作；管理服務(wù)器D在網(wǎng)絡(luò)上廣播相應(yīng) 的以太網(wǎng)地址變更信息，交換機隨即將用戶訪問故障應(yīng)用服務(wù)器的網(wǎng)絡(luò)流量轉(zhuǎn)發(fā)給管理服 務(wù)器D;交換機仍舊將用戶訪問故障應(yīng)用服務(wù)器1的網(wǎng)絡(luò)流量轉(zhuǎn)發(fā)到管理服務(wù)器D ；交換機把用戶訪問正常應(yīng)用服務(wù)器的流量直接轉(zhuǎn)發(fā)給正常工作的應(yīng)用服務(wù)器；管理服務(wù)器D將交換機轉(zhuǎn)來的用戶的網(wǎng)絡(luò)訪問流量再次經(jīng)由交換機轉(zhuǎn)發(fā)給其它 的正常工作的應(yīng)用服務(wù)器正常工作的應(yīng)用服務(wù)器把返回的網(wǎng)絡(luò)流量經(jīng)由交換機回傳給用戶；管理服務(wù)器C處于空閑狀態(tài)；四、故障狀態(tài)3設(shè)初始狀態(tài)為應(yīng)用服務(wù)器1，2發(fā)生故障；管理服務(wù)器A發(fā)生故障。本發(fā)明實施例 的通信系統(tǒng)工作過程如下管理服務(wù)器B，C，D均監(jiān)測到應(yīng)用服務(wù)器1，2發(fā)生故障；根據(jù)預(yù)定規(guī)則管理服務(wù)器B繼續(xù)負責(zé)整體工作調(diào)度；根據(jù)預(yù)定規(guī)則管理服務(wù)器D接手管理服務(wù)器A來處理故障應(yīng)用服務(wù)器的工作，雖 然目前沒有工作負載；交換機將用戶訪問故障應(yīng)用服務(wù)器1的網(wǎng)絡(luò)流量轉(zhuǎn)發(fā)到管理服務(wù)器D ；管理服務(wù)器B在網(wǎng)絡(luò)上廣播相應(yīng)的以太網(wǎng)地址變更信息，交換機隨即將用戶訪問故障應(yīng)用服務(wù)器2的網(wǎng)絡(luò)流量轉(zhuǎn)發(fā)到空閑的管理服務(wù)器C ；交換機把用戶訪問到正常應(yīng)用服務(wù)器的來源網(wǎng)絡(luò)流量直接轉(zhuǎn)發(fā)給正常工作的應(yīng) 用服務(wù)器；管理服務(wù)器D將交換機轉(zhuǎn)來的用戶的網(wǎng)絡(luò)訪問流量再次經(jīng)由交換機轉(zhuǎn)發(fā)給其它 的正常工作的應(yīng)用服務(wù)器；管理服務(wù)器C將交換機轉(zhuǎn)來的用戶的網(wǎng)絡(luò)訪問流量再次經(jīng)由交換機轉(zhuǎn)發(fā)給其它 的正常工作的應(yīng)用服務(wù)器；正常工作的應(yīng)用服務(wù)器把返回的網(wǎng)絡(luò)流量經(jīng)由交換機回傳給用戶；非故障的管理服務(wù)器全部處于有工作負載狀態(tài)，但是管理服務(wù)器B的負載很輕。五、故障狀態(tài)4:設(shè)初始狀態(tài)為應(yīng)用服務(wù)器1，2，3發(fā)生故障；管理服務(wù)器A發(fā)生故障。本發(fā)明實施 例的通信系統(tǒng)工作過程如下管理服務(wù)器B，C，D均監(jiān)測到應(yīng)用服務(wù)器1，2，3發(fā)生故障；根據(jù)預(yù)定規(guī)則管理服務(wù)器B繼續(xù)負責(zé)整體工作調(diào)度；根據(jù)預(yù)定規(guī)則管理服務(wù)器D接手管理服務(wù)器A來處理故障應(yīng)用服務(wù)器的工作，雖 然目前沒有工作負載；交換機將用戶訪問故障應(yīng)用服務(wù)器1的網(wǎng)絡(luò)流量轉(zhuǎn)發(fā)到管理服務(wù)器D ；交換機將用戶訪問故障應(yīng)用服務(wù)器2的網(wǎng)絡(luò)流量轉(zhuǎn)發(fā)到管理服務(wù)器C ；管理服務(wù)器B在網(wǎng)絡(luò)上廣播相應(yīng)的以太網(wǎng)地址變更信息，交換機隨即將用戶訪問 故障應(yīng)用服務(wù)器3的網(wǎng)絡(luò)流量轉(zhuǎn)發(fā)給相對負載很低的管理服務(wù)器B上；交換機把用戶訪問到正常應(yīng)用服務(wù)器的流量直接轉(zhuǎn)發(fā)給正常工作的應(yīng)用服務(wù) 器；管理服務(wù)器D將交換機轉(zhuǎn)來的用戶的網(wǎng)絡(luò)訪問流量再次經(jīng)由交換機轉(zhuǎn)發(fā)給其它 的正常工作的應(yīng)用服務(wù)器；管理服務(wù)器C將交換機轉(zhuǎn)來的用戶的網(wǎng)絡(luò)訪問流量再次經(jīng)由交換機轉(zhuǎn)發(fā)給其它 的正常工作的應(yīng)用服務(wù)器；管理服務(wù)器B的另外一項工作是將交換機轉(zhuǎn)來的用戶的網(wǎng)絡(luò)訪問流量再次經(jīng)由 交換機轉(zhuǎn)發(fā)給其它的正常工作的應(yīng)用服務(wù)器；正常工作的應(yīng)用服務(wù)器把返回的網(wǎng)絡(luò)流量經(jīng)由交換機回傳給用戶；非故障的管理服務(wù)器全部處于有工作負載狀態(tài)；六、故障狀態(tài)5設(shè)初始狀態(tài)為應(yīng)用服務(wù)器1，2，3，4發(fā)生故障；管理服務(wù)器A發(fā)生故障。本發(fā)明實 施例的通信系統(tǒng)工作過程如下管理服務(wù)器B，C，D均監(jiān)測到應(yīng)用服務(wù)器1，2，3，4發(fā)生故障；根據(jù)預(yù)定規(guī)則管理服務(wù)器B繼續(xù)負責(zé)整體工作調(diào)度；根據(jù)預(yù)定規(guī)則交換機將用戶訪問故障應(yīng)用服務(wù)器1的網(wǎng)絡(luò)流量轉(zhuǎn)發(fā)到管理服務(wù) 器D;交換機將用戶訪問故障應(yīng)用服務(wù)器2的網(wǎng)絡(luò)流量轉(zhuǎn)發(fā)到管理服務(wù)器C ；交換機將用戶訪問故障應(yīng)用服務(wù)器3的網(wǎng)絡(luò)流量轉(zhuǎn)發(fā)到管理服務(wù)器B ；
13
管理服務(wù)器B在網(wǎng)絡(luò)上廣播相應(yīng)的以太網(wǎng)地址變更信息，交換機隨即將用戶訪問 故障應(yīng)用服務(wù)器4的網(wǎng)絡(luò)流量轉(zhuǎn)發(fā)向管理服務(wù)器A ；但是由于管理服務(wù)器A處于故障狀態(tài)， 并且其處理應(yīng)用服務(wù)器故障這部分工作早已被管理服務(wù)器D接手，所以最終交換機將用戶 訪問故障應(yīng)用服務(wù)器4的網(wǎng)絡(luò)流量轉(zhuǎn)發(fā)給管理服務(wù)器D ；交換機把用戶訪問到正常應(yīng)用服務(wù)器的流量直接轉(zhuǎn)發(fā)給正常工作的應(yīng)用服務(wù) 器；管理服務(wù)器D將交換機轉(zhuǎn)來的用戶的網(wǎng)絡(luò)訪問流量再次經(jīng)由交換機轉(zhuǎn)發(fā)給其它 的正常工作的應(yīng)用服務(wù)器管理服務(wù)器C將交換機轉(zhuǎn)來的用戶的網(wǎng)絡(luò)訪問流量再次經(jīng)由交換機轉(zhuǎn)發(fā)給其它 的正常工作的應(yīng)用服務(wù)器管理服務(wù)器B的另外一項工作是將交換機轉(zhuǎn)來的用戶的網(wǎng)絡(luò)訪問流量再次經(jīng)由 交換機轉(zhuǎn)發(fā)給其它的正常工作的應(yīng)用服務(wù)器正常工作的應(yīng)用服務(wù)器把返回的網(wǎng)絡(luò)流量經(jīng)由交換機回傳給用戶；非故障的管理服務(wù)器全部處于有工作負載狀態(tài)，其中管理服務(wù)器D的負載相對較 尚；七、故障狀態(tài)6設(shè)初始狀態(tài)為某四臺應(yīng)用服務(wù)器1，2，3，4發(fā)生故障；管理服務(wù)器A，B發(fā)生故障。 本發(fā)明實施例的通信系統(tǒng)工作過程如下管理服務(wù)器C，D均監(jiān)測到應(yīng)用服務(wù)器1，2，3，4發(fā)生故障；根據(jù)預(yù)定規(guī)則管理服務(wù)器C取代管理服務(wù)器B接手總體工作調(diào)度；根據(jù)預(yù)定規(guī)則管理服務(wù)器D接手管理服務(wù)器B上的處理故障應(yīng)用服務(wù)器的工作， 包括原來存在的以及今后可能被分配過來的工作；根據(jù)預(yù)定規(guī)則交換機將用戶訪問故障應(yīng)用服務(wù)器1、4的網(wǎng)絡(luò)流量轉(zhuǎn)發(fā)到管理服 務(wù)器D;交換機將用戶訪問故障應(yīng)用服務(wù)器2的網(wǎng)絡(luò)流量轉(zhuǎn)發(fā)到管理服務(wù)器C ；管理服務(wù)器D在網(wǎng)絡(luò)上廣播相應(yīng)的以太網(wǎng)地址變更信息，交換機隨即將用戶訪問 故障應(yīng)用服務(wù)器3的網(wǎng)絡(luò)流量由原先的轉(zhuǎn)發(fā)給管理服務(wù)器B改為轉(zhuǎn)發(fā)給管理服務(wù)器D ；交換機把用戶訪問到正常應(yīng)用服務(wù)器的來源網(wǎng)絡(luò)流量直接轉(zhuǎn)發(fā)給正常工作的應(yīng) 用服務(wù)器；管理服務(wù)器D將交換機轉(zhuǎn)來的用戶的網(wǎng)絡(luò)訪問流量再次經(jīng)由交換機轉(zhuǎn)發(fā)給其它 的正常工作的應(yīng)用服務(wù)器；管理服務(wù)器C的另外一項工作是將交換機轉(zhuǎn)來的用戶的網(wǎng)絡(luò)訪問流量再次經(jīng)由 交換機轉(zhuǎn)發(fā)給其它的正常工作的應(yīng)用服務(wù)器；正常工作的應(yīng)用服務(wù)器把返回的網(wǎng)絡(luò)流量經(jīng)由交換機回傳給用戶；非故障的管理服務(wù)器全部處于有工作負載狀態(tài)，管理服務(wù)器D的負載相對較高；以上是各個故障狀態(tài)的工作調(diào)度的舉例描述。需要指出的是，故障發(fā)生的情況是 隨機出現(xiàn)的，并不一定是按照上文中的“故障狀態(tài)1、2、3、4、5、6”的順序發(fā)生。對于其它情 況的故障發(fā)生順序，整個管理系統(tǒng)仍然按照預(yù)設(shè)的規(guī)則調(diào)度工作。對于故障恢復(fù)后的設(shè)備， 管理系統(tǒng)通過健康檢查機制和工作資源選舉機制確認其能夠正常工作后，會將原先屬于該設(shè)備的工作負載“返還”，最終在所有故障設(shè)備都恢復(fù)正常工作后，使得整體系統(tǒng)也還原到 了初始工作狀態(tài)。實施例二如圖8所示，本實施例提供了一種通信方法，包括步驟步驟801、交換機接收用戶請求，并在管理服務(wù)器的控制下將用戶請求轉(zhuǎn)發(fā)至目的 地址對應(yīng)的應(yīng)用服務(wù)器或管理服務(wù)器。步驟802、管理服務(wù)器監(jiān)控應(yīng)用服務(wù)器的狀態(tài)，并根據(jù)應(yīng)用服務(wù)器的狀態(tài)和預(yù)定規(guī) 則控制交換機的數(shù)據(jù)轉(zhuǎn)發(fā)，以便在應(yīng)用服務(wù)器故障時，使交換機將發(fā)往該故障應(yīng)用服務(wù)器 的用戶請求轉(zhuǎn)發(fā)給管理服務(wù)器。步驟803、應(yīng)用服務(wù)器接收交換機和/或管理服務(wù)器轉(zhuǎn)發(fā)的用戶請求，并處理該請 求，將處理結(jié)果發(fā)給交換機，并由交換機將應(yīng)用服務(wù)器的處理結(jié)果轉(zhuǎn)發(fā)給用戶。由于管理服務(wù)器自身的主/備選舉協(xié)商模塊的功效，無論是健康檢查、網(wǎng)絡(luò)轉(zhuǎn)發(fā) 還是ARP代理，這些工作都會隨著對工作資源的選舉協(xié)商在多臺管理服務(wù)器上動態(tài)遷移， 直至最后一臺管理服務(wù)器發(fā)生故障，任何工作都不會收到影響。而且，當(dāng)管理服務(wù)器由故障 狀態(tài)恢復(fù)時，主/備選舉協(xié)商模塊即可自動重新分配工作資源，以達成管理服務(wù)器之間的 負載均衡。本發(fā)明的通信系統(tǒng)實現(xiàn)了服務(wù)器的負載均衡、服務(wù)器故障屏蔽、自身故障屏蔽、用 戶透明模式訪問、故障恢復(fù)自愈合五項功能；由于在本發(fā)明的通信系統(tǒng)中，在正常通信過程 中，管理服務(wù)器不參與用戶終端與應(yīng)用服務(wù)器之間通信過程，只有在應(yīng)用服務(wù)器故障時才 參與通信系統(tǒng)的管理工作，這種工作方式稱作“帶外監(jiān)控、故障介入”工作模式，因此，本發(fā) 明的通信系統(tǒng)自身的負載，與用戶的數(shù)量、訪問量無關(guān)，與應(yīng)用服務(wù)器的數(shù)量無關(guān)，只與服 務(wù)器的故障率和故障恢復(fù)時間有關(guān)；這樣就徹底解決了交換性能的提升與日益增長的網(wǎng)絡(luò) 流量之間的矛盾，開辟了 一個新型的應(yīng)用模式。由于本發(fā)明的通信系統(tǒng)采用了“帶外監(jiān)控、故障介入”的工作方式，管理服務(wù)器無 須處理用戶和正常應(yīng)用服務(wù)器之間的網(wǎng)絡(luò)通信數(shù)據(jù)，對于故障時的應(yīng)用服務(wù)器，管理服務(wù) 器也只需要處理用戶發(fā)送過來的網(wǎng)絡(luò)通信數(shù)據(jù)。所以對管理服務(wù)器自身的硬件性能要求很 低，管理服務(wù)器可以使用與應(yīng)用服務(wù)器同檔次的硬件，其自身的硬件成本遠遠低于“帶內(nèi)工 作”形式的交換系統(tǒng)的硬件成本。由于本發(fā)明的通信系統(tǒng)采用“帶外監(jiān)控、故障介入”的工作方式，用戶和正常應(yīng)用 服務(wù)器之間的網(wǎng)絡(luò)通信數(shù)據(jù)只需被交換機處理一次。相對于“商業(yè)四層交換方案之inline 模式”節(jié)省了 50%的交換機的網(wǎng)絡(luò)資源；相對于“商業(yè)四層交換方案之單臂模式”節(jié)省了 25%的交換機的網(wǎng)絡(luò)資源。由于本發(fā)明的通信系統(tǒng)采用“帶外監(jiān)控、故障介入”的工作方式，所以管理服務(wù)器 自身的性能無須隨用戶或應(yīng)用服務(wù)器的增加而增加，對管理服務(wù)器的性能需求只與應(yīng)用服 務(wù)器的故障量和故障恢復(fù)時間相關(guān)。這使得本發(fā)明的交換服務(wù)在性能上從應(yīng)用服務(wù)中剝離 開來。所以，理論上，本發(fā)明通信系統(tǒng)可以承載任意大小的網(wǎng)絡(luò)流量而不增加四層交換部分 的硬件成本投入。雖然通過實施例描繪了本發(fā)明，但本領(lǐng)域普通技術(shù)人員知道，在不脫離本發(fā)明的 精神和實質(zhì)的情況下，就可使本發(fā)明有許多變形和變化，本發(fā)明的范圍由所附的權(quán)利要求來限定。
權(quán)利要求
1.一種通信系統(tǒng)，其特征在于，包括交換機、應(yīng)用服務(wù)器和管理服務(wù)器，所述應(yīng)用服務(wù)器，用于接收交換機和/或管理服務(wù)器轉(zhuǎn)發(fā)的用戶請求，并處理該請求， 將處理結(jié)果發(fā)給交換機；所述交換機，用于將應(yīng)用服務(wù)器的處理結(jié)果轉(zhuǎn)發(fā)給用戶，并在管理服務(wù)器的控制下將 用戶請求轉(zhuǎn)發(fā)至目的地址對應(yīng)的應(yīng)用服務(wù)器或管理服務(wù)器；所述管理服務(wù)器，用于監(jiān)控應(yīng)用服務(wù)器的狀態(tài)，并根據(jù)應(yīng)用服務(wù)器的狀態(tài)和預(yù)定規(guī)則 控制交換機的數(shù)據(jù)轉(zhuǎn)發(fā)，以便在應(yīng)用服務(wù)器故障時，使交換機將發(fā)往該故障應(yīng)用服務(wù)器的 用戶請求轉(zhuǎn)發(fā)給管理服務(wù)器。
2.根據(jù)權(quán)利要求1所述的系統(tǒng)，其特征在于，所述管理服務(wù)器為2至254臺。
3.根據(jù)權(quán)利要求2所述的系統(tǒng)，其特征在于，所述管理服務(wù)器為4臺。
4.根據(jù)權(quán)利要求2或3所述的系統(tǒng)，其特征在于，所述管理服務(wù)器包括主/備關(guān)系協(xié)商 選舉模塊，其用于向其它管理服務(wù)器組播本管理服務(wù)器的工作資源的優(yōu)先級，并獲得其它 管理服務(wù)器的工作資源的優(yōu)先級，根據(jù)各個管理服務(wù)器的優(yōu)先級確定本管理服務(wù)器工作資 源的工作狀態(tài)。
5.根據(jù)權(quán)利要求4所述的系統(tǒng)，其特征在于，所述主/備選舉協(xié)商模塊工作在操作系統(tǒng) 的內(nèi)核態(tài)。
6.根據(jù)權(quán)利要求1至3其中任一項所述的系統(tǒng)，其特征在于，所述管理服務(wù)器具體包括數(shù)據(jù)幀轉(zhuǎn)發(fā)模塊，用于接收交換機轉(zhuǎn)發(fā)的用戶請求，并根據(jù)轉(zhuǎn)發(fā)表對所述用戶請求執(zhí) 行數(shù)據(jù)幀轉(zhuǎn)發(fā)操作，以便將本應(yīng)由故障應(yīng)用服務(wù)器承擔(dān)的用戶請求轉(zhuǎn)發(fā)給正常的應(yīng)用服務(wù)ο
7.根據(jù)權(quán)利要求1至3其中任一項所述的系統(tǒng)，其特征在于，所述管理服務(wù)器具體包括地址解析協(xié)議代理模塊用于接收網(wǎng)絡(luò)設(shè)備的ARP查詢，該ARP查詢用于獲得與SVCIP 對應(yīng)的MAC地址，并將該MAC地址返回該網(wǎng)絡(luò)設(shè)備。
8.根據(jù)權(quán)利要求7所述的系統(tǒng)，其特征在于，所述網(wǎng)絡(luò)設(shè)備包括交換機。
9.根據(jù)權(quán)利要求1至3其中任一項所述的系統(tǒng)，其特征在于，所述管理服務(wù)器具體包括健康檢查模塊，用于檢查應(yīng)用服務(wù)器的狀態(tài)，以發(fā)現(xiàn)故障應(yīng)用服務(wù)器及正常工作的應(yīng) 用服務(wù)器，將故障應(yīng)用服務(wù)器的IP用管理服務(wù)器的VSIP替換。
10.一種通信方法，其特征在于，包括步驟交換機接收用戶請求，并在管理服務(wù)器的控制下將用戶請求轉(zhuǎn)發(fā)至目的地址對應(yīng)的應(yīng) 用服務(wù)器或管理服務(wù)器；管理服務(wù)器監(jiān)控應(yīng)用服務(wù)器的狀態(tài)，并根據(jù)應(yīng)用服務(wù)器的狀態(tài)和預(yù)定規(guī)則控制交換機 的數(shù)據(jù)轉(zhuǎn)發(fā)，以便在應(yīng)用服務(wù)器故障時，使交換機將發(fā)往該故障應(yīng)用服務(wù)器的用戶請求轉(zhuǎn) 發(fā)給管理服務(wù)器；應(yīng)用服務(wù)器接收交換機和/或管理服務(wù)器轉(zhuǎn)發(fā)的用戶請求，并處理該請求，將處理結(jié) 果發(fā)給交換機，并由交換機將應(yīng)用服務(wù)器的處理結(jié)果轉(zhuǎn)發(fā)給用戶。
全文摘要
本發(fā)明的實施例提供了一種通信方法和裝置，可解決現(xiàn)有通信系統(tǒng)通信效率低、成本高的問題。所述通信系統(tǒng)包括交換機、應(yīng)用服務(wù)器和管理服務(wù)器。所述應(yīng)用服務(wù)器，用于接收交換機和/或管理服務(wù)器轉(zhuǎn)發(fā)的用戶請求，并處理該請求，將處理結(jié)果發(fā)給交換機；所述交換機，用于交換數(shù)據(jù)；所述管理服務(wù)器，用于監(jiān)控應(yīng)用服務(wù)器的狀態(tài)，并根據(jù)應(yīng)用服務(wù)器的狀態(tài)和預(yù)定規(guī)則控制交換機的數(shù)據(jù)轉(zhuǎn)發(fā)，以便在應(yīng)用服務(wù)器故障時，使交換機將發(fā)往該故障應(yīng)用服務(wù)器的用戶請求轉(zhuǎn)發(fā)給管理服務(wù)器。根據(jù)本發(fā)明，可實現(xiàn)服務(wù)器的負載均衡、服務(wù)器故障屏蔽、自身故障屏蔽、用戶透明模式訪問、故障恢復(fù)自愈合五項功能；并徹底解決了交換性能的提升與日益增長的網(wǎng)絡(luò)流量之間的矛盾。
文檔編號H04L29/12GK102130776SQ201010002599
公開日2011年7月20日 申請日期2010年1月19日 優(yōu)先權(quán)日2010年1月19日
發(fā)明者王乃超 申請人:新浪網(wǎng)技術(shù)(中國)有限公司