專利名稱：服務(wù)器負載平衡系統(tǒng)、裝置以及內(nèi)容管理裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及服務(wù)器負載平衡，特別是一種用于服務(wù)器負載平衡的系統(tǒng)和裝置，以及一種內(nèi)容管理裝置和一種用于選擇最優(yōu)服務(wù)器的內(nèi)容服務(wù)器，關(guān)于一個來自客戶端用來獲得傳送內(nèi)容的請求，例如WWW(萬維網(wǎng))內(nèi)容或者流送內(nèi)容，并且發(fā)送上述請求到達所選擇的服務(wù)器。
背景技術(shù)：
最近，在通過Internet傳送WWW內(nèi)容以及流送內(nèi)容的過程中，已經(jīng)提出了各種方法，通過將相同的內(nèi)容分配到若干服務(wù)器，用來分配服務(wù)器負載以及縮短客戶端的響應(yīng)感知時間。
當(dāng)在一個網(wǎng)絡(luò)中分配內(nèi)容的境況下，存在一個服務(wù)器負載平衡裝置是必要的，其中該服務(wù)器負載平衡裝置用來確定哪個服務(wù)器發(fā)送用于獲得內(nèi)容的客戶端請求。
常用的技術(shù)中，一種通過模擬和分配每一條用戶端請求以便于防止服務(wù)器上的額外負載及過載現(xiàn)象來為每一項服務(wù)預(yù)測一個服務(wù)器負載的裝置已經(jīng)在日本出版物平開專利No.2001-101134中公開。在上述出版物所公開的裝置中，僅需要考慮服務(wù)器負載就能選擇目的服務(wù)器，并且可為每一項服務(wù)選擇一個目的服務(wù)器。
此外，一種在客戶端中選擇目的服務(wù)器的方法也在日本出版物平開No.Heisei09-198346中公開。在上述出版物所公開的服務(wù)器選擇方法就是通過將一個選擇策略存入到目錄服務(wù)器的一條查詢消息中來處理由各個客戶端所發(fā)出的不同服務(wù)器選擇請求。收到所述查詢后，該目錄服務(wù)器根據(jù)存儲在消息中的選擇策略選擇最優(yōu)服務(wù)器，并且響應(yīng)客戶端。該方法是在客戶端一側(cè)的選擇方法，因此，該客戶端必須引入該方法。若服務(wù)器負載平衡裝置能夠支持不同的選擇標準如在上述方法中所述的，則可以使用過濾方式實現(xiàn)相同的服務(wù)而不需要改變客戶端一側(cè)的方法。
然而，在上述常見技術(shù)中存在下述問題。
首先，在一個內(nèi)容服務(wù)器中，并不需要根據(jù)各個特性對內(nèi)容進行分組，即使已經(jīng)被分組了，也僅僅是根據(jù)其靜態(tài)特性來進行分組的。
通常，通過對內(nèi)容服務(wù)器中的內(nèi)容進行安排可以很容易的通過內(nèi)容管理器對內(nèi)容服務(wù)器進行控制，并且并不是從每個內(nèi)容的特性角度來對其進行分組。例如在一條有關(guān)新聞的目錄“news”下，通常，不同的內(nèi)容例如文章、圖片，以及新聞圖像會以固定的方式來對其進行安排，它們在文件大小和媒體類型方面具有不同特性。而并不需要考慮動態(tài)特性(參數(shù))例如對每條內(nèi)容的存取頻率。這時，在客戶端一側(cè)的服務(wù)器負載平衡裝置中，若選擇相同的內(nèi)容服務(wù)器作為“/news/”內(nèi)容的目的地，則從內(nèi)容延遲得到方面來看該選中的服務(wù)器很有可能并不是最優(yōu)的服務(wù)器。因此，目的服務(wù)器的選擇應(yīng)當(dāng)由各個內(nèi)容組來進行，其中各個內(nèi)容組從內(nèi)容大小及存取頻率方面來看具有相同的特性。
其次，在服務(wù)器負載平衡裝置中，不可能依據(jù)每條內(nèi)容的特性來改變目的服務(wù)器的選擇標準，因此不會出現(xiàn)有效的負載平衡。
在常見技術(shù)中，目的服務(wù)器的選擇標準是固定的并且不能限據(jù)每一條內(nèi)容的特性加以改變。例如，若考慮到包括小內(nèi)容以及大內(nèi)容的兩種內(nèi)容時，對于小內(nèi)容情況來說，客戶端的響應(yīng)時間很大程度上取決于傳輸路徑中的延遲，而對于大內(nèi)容情況來說則是很大程度上取決于傳輸路徑中的可用帶寬。這種情況下，已有技術(shù)不能對兩種或者更多種類的內(nèi)容使用不同的選擇標準。
第三點，當(dāng)位于用戶端的各個服務(wù)器負載平衡裝置分別選擇了一個目的服務(wù)器時，負載集中在同一個服務(wù)器上，因此傳送質(zhì)量也會受到影響。
尤其是，在傳送連續(xù)介質(zhì)內(nèi)容例如流或是聲音的情況下，當(dāng)存取集中在同一服務(wù)器上時，就不能獲得所期望的傳送質(zhì)量并且必需重新選擇一個目的服務(wù)器。而且，當(dāng)所有線路在傳送期間被立刻轉(zhuǎn)換時都會出現(xiàn)擺動現(xiàn)象，如由于轉(zhuǎn)換后存取會集中在一個新的傳送服務(wù)器上而再次導(dǎo)致傳送質(zhì)量的惡化并在另一個傳送服務(wù)器上重復(fù)執(zhí)行轉(zhuǎn)換操作。
第四點，由于諸如通過內(nèi)容或者內(nèi)容組來選擇目的服務(wù)器的服務(wù)器負載平衡裝置必須在查看到來自客戶端的請求內(nèi)容后確定一個目的服務(wù)器，因此必須使用7層轉(zhuǎn)換。
如果使用7層轉(zhuǎn)換，則可以將來自客戶端的每一請求分配到為每一內(nèi)容設(shè)置的目的服務(wù)器中，但是其性能比較差，并且與使用較低層例如3層轉(zhuǎn)換和4層轉(zhuǎn)換的裝置相比較其成本較高。因此，最好就是能夠通過使用較低層轉(zhuǎn)換的裝置來實現(xiàn)相同的功能，而不需查看請求內(nèi)容。

發(fā)明內(nèi)容
為了解決上述常見技術(shù)中存在的問題，本發(fā)明的第一個目的是提供一種服務(wù)器負載平衡系統(tǒng)，一種內(nèi)容管理裝置，以及一種在內(nèi)容服務(wù)器中能夠以動態(tài)及靜態(tài)的方式根據(jù)它們的特性自動進行分組的內(nèi)容管理程序。
為了解決上述常見技術(shù)中存在的問題，本發(fā)明的第二個目的是提供一種服務(wù)器負載平衡系統(tǒng)，一種服務(wù)器負載平衡裝置，以及一種能夠根據(jù)每一內(nèi)容特性改變目的服務(wù)器選擇標準的服務(wù)器負載平衡程序。
為了解決上述常見技術(shù)中存在的問題，本發(fā)明的第三個目的是提供一種服務(wù)器負載平衡系統(tǒng)，一種服務(wù)器負載平衡裝置，一種內(nèi)容服務(wù)器，以及一種能夠適當(dāng)進行分配處理以便于防止在連續(xù)介質(zhì)內(nèi)容傳送過程中負載集中在某一指定的服務(wù)器上的內(nèi)容傳送管理程序。
為了解決上述常見技術(shù)中存在的問題，本發(fā)明的第四個目的是提供一種服務(wù)器負載平衡系統(tǒng)，一種服務(wù)器負載平衡裝置，以及一種能夠通過內(nèi)容組來選擇目的服務(wù)器而不需要7層轉(zhuǎn)換功能的服務(wù)器負載平衡程序。
根據(jù)本發(fā)明的第一方面，一種用于向多個內(nèi)容服務(wù)器中的一個客戶端分配內(nèi)容發(fā)送的服務(wù)器負載平衡系統(tǒng)，包括用于確定內(nèi)容服務(wù)器的裝置，通過至少使用關(guān)于該內(nèi)容服務(wù)器的內(nèi)容和資源信息特性而將來自客戶端的內(nèi)容傳送請求目的地傳輸給該內(nèi)容服務(wù)器。
在優(yōu)選結(jié)構(gòu)中，根據(jù)資源信息的改變再次確定向其傳送來自客戶端的內(nèi)容傳送請求的內(nèi)容服務(wù)器。
在另一優(yōu)選結(jié)構(gòu)中，所述來自客戶端的內(nèi)容傳送請求被發(fā)送到該內(nèi)容傳送請求將被發(fā)送到的內(nèi)容服務(wù)器，該內(nèi)容服務(wù)器為該內(nèi)容而設(shè)置。
在另一優(yōu)選結(jié)構(gòu)中，基于來自客戶端的信息包的目的IP地址以及目的端口號，該由客戶端請求的內(nèi)容被確認并且將該信息包發(fā)送到為所述內(nèi)容設(shè)置的內(nèi)容服務(wù)器中。
在另一優(yōu)選結(jié)構(gòu)中，內(nèi)容服務(wù)器傳送的內(nèi)容根據(jù)其特性被分成若干組，并且分成上述組的內(nèi)容被收集在一塊并分到每一組中。
根據(jù)本發(fā)明的第二方面，用于從若干內(nèi)容服務(wù)器中選擇一個向客戶端傳送內(nèi)容的內(nèi)容服務(wù)器的服務(wù)器負載平衡裝置包括用于確定內(nèi)容服務(wù)器的裝置，通過至少使用所述內(nèi)容的特性和關(guān)于所述內(nèi)容服務(wù)器的資源信息而將來自客戶端的內(nèi)容傳送請求傳輸給所述內(nèi)容服務(wù)器。
在優(yōu)選結(jié)構(gòu)中，所述資源信息至少包括一個或多個資源參數(shù)，通過使用第一資源參數(shù)來預(yù)測或提取與第一資源參數(shù)不同的第二資源參數(shù)，并且該資源信息也包括預(yù)測或提取出的第二資源參數(shù)。
在另一優(yōu)選結(jié)構(gòu)中，所述目的服務(wù)器確定裝置通過使用客戶端所請求內(nèi)容的URL或部分URL來獲得用于所述請求目的地的候選內(nèi)容服務(wù)器，并且從候選內(nèi)容服務(wù)器中確定向其傳送內(nèi)容的內(nèi)容服務(wù)器。
在另一優(yōu)選結(jié)構(gòu)中，所述部分URL是URL的詞頭即URL的報頭部分或者URL中文件的擴展名再或者是兩者的結(jié)合。
在另一優(yōu)選結(jié)構(gòu)中，通過對存在于網(wǎng)絡(luò)或用于管理內(nèi)容服務(wù)器中的內(nèi)容的內(nèi)容管理裝置中的內(nèi)容服務(wù)器進行查詢，該目的服務(wù)器確定裝置獲得用來傳送客戶端請求內(nèi)容的候選內(nèi)容服務(wù)器。
在另一優(yōu)選結(jié)構(gòu)中，通過對存在于網(wǎng)絡(luò)或用于管理內(nèi)容服務(wù)器中的內(nèi)容的內(nèi)容管理裝置中的內(nèi)容服務(wù)器進行查詢，所述目的服務(wù)器確定裝置獲取所述客戶端的特性。
在另一優(yōu)選結(jié)構(gòu)中，所述目的服務(wù)器確定裝置通過使用將由請求獲得內(nèi)容的URL或者URL的一部分生成FQDN，獲得一個用于該FQDN的IP地址列表，其中FQDN作為密鑰，并且將相應(yīng)于列表中每一IP地址的內(nèi)容服務(wù)器規(guī)定為候選服務(wù)器，用于傳送由客戶端請求的內(nèi)容。
在另一優(yōu)選結(jié)構(gòu)中，從DNS服務(wù)器獲得所述用于FQDN的IP地址列表。
在另一優(yōu)選結(jié)構(gòu)中，在將所述信息包的目的IP地址改變?yōu)閮?nèi)容服務(wù)器的IP地址之后，其中的內(nèi)容服務(wù)器被確定作為向客戶端傳送內(nèi)容的內(nèi)容服務(wù)器，一個由客戶端發(fā)送的、用來請求內(nèi)容傳送的信息包被傳輸?shù)剿鰞?nèi)容服務(wù)器。
在另一優(yōu)選結(jié)構(gòu)中，在解析了相應(yīng)于所述內(nèi)容服務(wù)器IP地址的MAC地址之后，其中的內(nèi)容服務(wù)器被確定作為向客戶端傳送內(nèi)容并將所述信息包的MAC地址改變?yōu)榻馕龊蟮腗AC地址的內(nèi)容服務(wù)器，一個由客戶端發(fā)送的、用來請求內(nèi)容傳送的信息包被傳輸?shù)剿鰞?nèi)容服務(wù)器。
在另一優(yōu)選結(jié)構(gòu)中，根據(jù)資源信息的變化，重新確定向其傳送由客戶端接收的內(nèi)容發(fā)送請求的內(nèi)容服務(wù)器。
在另一優(yōu)選結(jié)構(gòu)中，通過至少使用所述內(nèi)容的特性以及資源信息，優(yōu)先級別被設(shè)置在向其傳送由客戶端接收的內(nèi)容發(fā)送請求的各個內(nèi)容服務(wù)器中。
在另一優(yōu)選結(jié)構(gòu)中，根據(jù)所述資源信息的變化重新設(shè)置優(yōu)先級別。
在另一優(yōu)選結(jié)構(gòu)中，考慮到當(dāng)前的優(yōu)先級別，在根據(jù)各個內(nèi)容服務(wù)器的資源信息重新設(shè)置優(yōu)先級別之前，來自當(dāng)前優(yōu)先級別的波動被限制為一個常數(shù)級別，并接下來重新對優(yōu)先級別進行設(shè)置。
在另一優(yōu)選結(jié)構(gòu)中，重新設(shè)置優(yōu)先級別的時間被延遲了一段隨著概率變化的時間，并在該延遲時間重新設(shè)置優(yōu)先級別。
在另一優(yōu)選結(jié)構(gòu)中，在所述延遲時間，重新判斷是否重新設(shè)置優(yōu)先級別，并且當(dāng)確定重新設(shè)置優(yōu)先級別時，重新對優(yōu)先級別進行設(shè)置。
在另一優(yōu)選結(jié)構(gòu)中，所述服務(wù)器負載平衡裝置包括用來確定向客戶端發(fā)送內(nèi)容的內(nèi)容服務(wù)器的裝置，這是基于從客戶端接收到的、用來請求內(nèi)容傳送的信息包的目的IP地址以及目的端口號，并且將接受到的用來請求內(nèi)容發(fā)送的信息包傳輸?shù)酱_定的內(nèi)容服務(wù)器，其中FQDN唯一指示目的IP地址以及目的端口號，是通過使用接收到的信息包的目的IP地址以及目的端口號的信息來重新生成，候選內(nèi)容服務(wù)器用來將內(nèi)容發(fā)送到客戶端，該服務(wù)器是接收到的信息包的傳遞目的地并通過對使用重新生成的FQDN作為密鑰的DNS服務(wù)器進行查詢來獲得，以及從候選內(nèi)容服務(wù)器中確定用來向客戶端發(fā)送內(nèi)容的內(nèi)容服務(wù)器。
在另一優(yōu)選結(jié)構(gòu)中，通過對使用目的IP地址作為密鑰的DNS服務(wù)器進行查詢來解析FQDN，通過使用解析后FQDN以及目的端口號的信息來重新生成唯一指示目的端口號以及解析后FQDN的FQDN，通過對使用重新生成的FQDN作為密鑰的DNS服務(wù)器進行查詢來獲得一個IP地址列表，并將該列表定義為用來向客戶端發(fā)送內(nèi)容的候選內(nèi)容服務(wù)器，以及從候選內(nèi)容服務(wù)器中確定用來向客戶端發(fā)送內(nèi)容的內(nèi)容服務(wù)器。
在另一優(yōu)選結(jié)構(gòu)中，通過對使用目的IP地址作為密鑰的DNS服務(wù)器進行查詢來解析FQDN，通過對使用解析后的FQDN作為密鑰的DNS服務(wù)器進行查詢來獲得一個IP地址列表，并將該列表定義為用來向客戶端發(fā)送內(nèi)容的候選內(nèi)容服務(wù)器，以及從候選內(nèi)容服務(wù)器中確定用來向客戶端發(fā)送內(nèi)容的內(nèi)容服務(wù)器。
在另一優(yōu)選結(jié)構(gòu)中，所述服務(wù)器負載平衡裝置進一步包括用來接收來自客戶端的請求內(nèi)容發(fā)送的信息包的信息包接收裝置，以及信息包傳輸裝置，該裝置將信息包接收裝置接收到的信息包的目的IP地址重新寫入到用于將被請求內(nèi)容發(fā)送到客戶端并傳輸?shù)絻?nèi)容務(wù)器中的內(nèi)容服務(wù)器的IP地址中。
在另一優(yōu)選結(jié)構(gòu)中，所述信息包傳輸裝置對相應(yīng)于用于向客戶端發(fā)送請求內(nèi)容的內(nèi)容服務(wù)器的IP地址的MAC地址進行解析，并且在將由信息包接收裝置接收到的請求內(nèi)容傳送的信息包的目的MAC重新寫入到解析后的MAC地址中之后，將該信息包傳輸給該內(nèi)容服務(wù)器。
根據(jù)本發(fā)明的第三方面，一個用來傳送內(nèi)容的內(nèi)容服務(wù)器，包括向一個節(jié)點通知將一個計算后的實際資源值的校準值作為資源信息的裝置，用來基于關(guān)于各個服務(wù)器的資源信息選擇內(nèi)容的發(fā)送目的地。
根據(jù)本發(fā)明的另一方面，一個用來對由內(nèi)容服務(wù)器傳送的內(nèi)容進行管理的內(nèi)容管理裝置，包含用來根據(jù)內(nèi)容的特性將由內(nèi)容服務(wù)器傳送的內(nèi)容分成多個組的內(nèi)容分類裝置，以及用來在各個組中將分類到各組中的內(nèi)容集中到一塊兒的內(nèi)容分組裝置。
在另一優(yōu)選結(jié)構(gòu)中，所述內(nèi)容分類裝置根據(jù)特性對所述內(nèi)容進行分類。
在另一優(yōu)選結(jié)構(gòu)中，所述內(nèi)容分類裝置根據(jù)所述內(nèi)容特性的分類逐步變細粒度的分級結(jié)構(gòu)逐步對內(nèi)容進行分類。
在另一優(yōu)選結(jié)構(gòu)中，所述內(nèi)容分組裝置將同一目錄下的已分類內(nèi)容一塊兒集中到相同的組中。
根據(jù)本發(fā)明的另一方面，一個用來通過控制一臺計算機，分配內(nèi)容發(fā)送到多個內(nèi)容服務(wù)器中的客戶端的服務(wù)器負載平衡程序，包括一個涉及具有內(nèi)容特性與有關(guān)內(nèi)容服務(wù)器的資源信息之間對應(yīng)關(guān)系的內(nèi)容服務(wù)器的選擇標準的功能，以及一個根據(jù)所述請求內(nèi)容的特性以及資源信息、基于選擇標準確定用來發(fā)送客戶端請求內(nèi)容的內(nèi)容服務(wù)器的功能。
根據(jù)本發(fā)明的另一方面，一個用來通過控制一臺計算機，管理傳送內(nèi)容的內(nèi)容服務(wù)器的內(nèi)容傳送的內(nèi)容傳送管理程序，包括一個向一個節(jié)點通知將一個計算后實際資源值的校準值作為在這一點的可用資源信息的功能，并用來根據(jù)服務(wù)器的資源選擇內(nèi)容的傳送目的地。
根據(jù)本發(fā)明的另一方面，一個用來通過控制一臺計算機，對內(nèi)容服務(wù)器傳送的內(nèi)容進行管理的內(nèi)容管理程序，包含一個用來根據(jù)所述內(nèi)容的特性將內(nèi)容服務(wù)器傳送的內(nèi)容分成多個組的內(nèi)容分類功能，以及一個用來在各個組中將分到各組中內(nèi)容集中一塊兒的內(nèi)容分組功能。
本發(fā)明的其它目的、特征和優(yōu)點將在隨著下面的詳細描述而變得更加清楚。


本發(fā)明將隨著下面給出的詳細描述以及本發(fā)明的優(yōu)選實施例的附圖而被理解得更充分，然而這卻不造成對本發(fā)明的限制，而只是作為一種解釋和理解。
附圖中圖1為本發(fā)明第一實施例的結(jié)構(gòu)方框圖；圖2給出了依據(jù)本發(fā)明第一實施例，由一個分類策略設(shè)置單元設(shè)置的分類策略的一個例子；圖3給出了依據(jù)本發(fā)明第一實施例，由一個內(nèi)容分組單元執(zhí)行的URL重寫入處理的例子；圖4為依據(jù)本發(fā)明第一實施例內(nèi)容管理裝置的操作過程流程圖；圖5給出了實現(xiàn)本發(fā)明第一實施例的內(nèi)容管理裝置作為內(nèi)容服務(wù)器一部分的功能的一個例子；圖6給出了多個內(nèi)容服務(wù)器與本發(fā)明第一實施例的內(nèi)容管理裝置相連接的例子；圖7為本發(fā)明第二實施例的結(jié)構(gòu)方框圖；圖8為依據(jù)本發(fā)明的第二實施，用來確定由目的服務(wù)器確定策略設(shè)置單元設(shè)置的目的服務(wù)器的策略的一個例子；圖9為依據(jù)本發(fā)明第二實施例，一個注冊在請求路徑表格中的項目的例子；
圖10為依據(jù)本發(fā)明第二實施例，一個從服務(wù)器負載平衡裝置中的客戶端接收一個請求的操作過程流程圖；圖11為依據(jù)本發(fā)明第二實施例，一個在所述服務(wù)器負載平衡裝置的目的服務(wù)器確定單元中確定目的服務(wù)器的操作過程流程圖；圖12為依據(jù)本發(fā)明第二實施例，一個對注冊在所述服務(wù)器負載平衡裝置的請求路徑表格中的項目進行管理的操作過程流程圖；圖13為本發(fā)明第三實施例的結(jié)構(gòu)方框圖；圖14給出了依據(jù)本發(fā)明第三實施例，一個資源響應(yīng)策略設(shè)置單元設(shè)置的資源響應(yīng)策略的一個例子；圖15為依據(jù)本發(fā)明第三實施例，在一個內(nèi)容服務(wù)器中接收用于從服務(wù)器負載平衡裝置獲取資源的請求的操作過程流程圖；圖16為本發(fā)明第四實施例的結(jié)構(gòu)方框圖；圖17為依據(jù)本發(fā)明第四實施例一個在請求路徑表中注冊的項目的例子；圖18為依據(jù)本發(fā)明第四實施例，一個服務(wù)器負載平衡裝置的操作過程流程圖；圖19為依據(jù)本發(fā)明第四實施例，另一個服務(wù)器負載平衡裝置的操作過程流程圖，；圖20為本發(fā)明第五實施例的結(jié)構(gòu)方框圖；圖21為依據(jù)本發(fā)明第五實施例一個在信息包路徑表中注冊的項目的例子；圖22給出了依據(jù)本發(fā)明第五實施例，一個在地址/FQDN解析表格中注冊的項目的例子；圖23為依據(jù)本發(fā)明第五實施例，一個當(dāng)客戶端發(fā)送一個獲得內(nèi)容請求時的操作過程流程圖，；圖24為依據(jù)本發(fā)明第五實施例，一個在所述服務(wù)器負載平衡裝置中接收一個來自客戶端信息包的操作過程流程圖，；圖25為依據(jù)本發(fā)明第五實施例，在信息包路徑表格中生成一個項目的操作過程流程圖，；圖26給出了依據(jù)本發(fā)明第二實施例的網(wǎng)絡(luò)結(jié)構(gòu)；圖27給出了依據(jù)本發(fā)明第三實施例的網(wǎng)絡(luò)結(jié)構(gòu)；
圖28給出了依據(jù)本發(fā)明第三實施例的請求路徑表格的一個例子；以及圖29給出了依據(jù)所給出的本發(fā)明第四實施例，在請求路徑表格中生成目的服務(wù)器項目的例子。
具體實施例方式
本發(fā)明的優(yōu)選實施例將隨后參照附圖進行較詳細描述。在下面的描述中，闡明了許多細節(jié)以便于對本發(fā)明有更好的理解。然而，對本領(lǐng)域普通技術(shù)人員來說顯而易見的是，沒有這些特定的細節(jié)本發(fā)明也是可以實現(xiàn)的。其他情況，為了使本發(fā)明避免不必要的描述沒有對公知結(jié)構(gòu)進行詳細介紹。
根據(jù)圖1，本發(fā)明的第一實施例通過一個內(nèi)容服務(wù)器A1和一個內(nèi)容管理裝置B1實現(xiàn)。能夠存取內(nèi)容服務(wù)器A1上的內(nèi)容的客戶端D1通過中樞網(wǎng)絡(luò)1與內(nèi)容管理裝置B1相連接。
所述內(nèi)容服務(wù)器A1包括存儲單元A11以及動態(tài)參數(shù)存儲單元A16。所述內(nèi)容存儲單元A11存儲傳送內(nèi)容本身例如WWW內(nèi)容和流送內(nèi)容，附有內(nèi)容的程序，程序執(zhí)行所需的數(shù)據(jù)庫等等。每條內(nèi)容都根據(jù)客戶端一側(cè)的標識符來識別，例如在HTTP(超文本傳輸協(xié)議)中，各個內(nèi)容都由URL(統(tǒng)一資源定位)識別。所述動態(tài)參數(shù)存儲單元A16存儲所述動態(tài)參數(shù)(資源信息)作為動態(tài)特性例如存取頻率以及用于各個傳送內(nèi)容的CPU負載，所述參數(shù)由內(nèi)容管理裝置b1指出。通過內(nèi)容服務(wù)器A1不斷更新所述動態(tài)參數(shù)內(nèi)容。在下文中，所述資源值并不是必須為顯示存取頻率或者CPU負載的具體數(shù)字值，也可以是顯示上述程度的信息。
所述內(nèi)容管理裝置B1包括一個分類策略設(shè)置單元B11，一個內(nèi)容分類單元B12，以及一個內(nèi)容分組單元B13。該分類策略設(shè)置單元B11根據(jù)其特性(靜態(tài)特性例如內(nèi)容的類型及大小以及動態(tài)特性例如存取頻率)設(shè)置一個用來對包含在內(nèi)容存儲單元A11中的內(nèi)容進行分組的分類策略。
這里，一個分類策略包含將不同內(nèi)容大致分類的信息，例如任一媒體類型中的文件、流以及CGI(公共網(wǎng)關(guān)接口)。更進一步，其還可以包含對已分類信息進行更詳細分類的分類信息。它可以是一個分類策略例如，文件根據(jù)其大小分為大、中和小，以及根據(jù)其傳輸率將流分為高、中和低。另一情況，其可以為根據(jù)動態(tài)特性將存取頻率分類為高、中和低的一種策略。
圖2為分類策略表格101的一個例子，給出了所述分類策略設(shè)置單元B11中設(shè)置的分類策略。例如，分類成文件的內(nèi)容依據(jù)其大小被分成三組大、中和小，被分為大尺寸的組又進一步根據(jù)其存取頻率而被分為兩組高和低。更進一步，所述表格給出了各個URL，其中根據(jù)所設(shè)置策略分類的各個內(nèi)容組被一塊分組。
所述內(nèi)容分類單元B12根據(jù)分類策略設(shè)置單元B11設(shè)置的分類策略對內(nèi)容存儲單元A11中的內(nèi)容進行分類。在這次分類中，靜態(tài)參數(shù)例如類型及大小能夠由內(nèi)容本身獲得，動態(tài)參數(shù)例如存儲在動態(tài)參數(shù)存儲單元A16中的存取頻率也被涉及。例如，內(nèi)容被分為各種媒體類型，例如文件、流以及CGI。當(dāng)為了各個媒體類型設(shè)置更詳細的分類策略時，根據(jù)該策略將內(nèi)容被分成多個依據(jù)例如文件大小及存取頻率的內(nèi)容組。
所述內(nèi)容分組單元B13根據(jù)由內(nèi)容分類單元B12自動對內(nèi)容進行分類的結(jié)果對各個內(nèi)容組中的內(nèi)容進行分組，以采用URL的情況作例，通過使用內(nèi)容存儲單元A11中該內(nèi)容所位于的目錄來表示該URL。然而，由內(nèi)容分類單元B12生成的內(nèi)容組中的內(nèi)容并不總是被一起分組到同一的目錄下，但是對于客戶端D1來說要識別該內(nèi)容屬于哪一內(nèi)容組是比較困難的。因此，要執(zhí)行重新寫入URL的處理以便于在相同目錄下的同一內(nèi)容組中對內(nèi)容進行安排。
在如圖2所示分類策略表格101的一個例子中，示出了其中每個分類后的內(nèi)容組應(yīng)被一起分組的每個URL，并且例如所有被分類到CGI中的內(nèi)容以及CPU的高負載被移動到“/cgi/high-load/”目錄。
圖3用于詳細描述所述URL的重寫入處理。例如，假設(shè)初始目錄路徑為“/pub/z.exe”的內(nèi)容在根據(jù)所設(shè)置策略進行分類之后應(yīng)當(dāng)一起被分組到“/cgi/high-load/”目錄下。生成具有目錄路徑“/cgi/high-load/z.exe”的內(nèi)容作為指向“/pub/z.exe”的符號鏈接。更進一步，所有涉及“/pub/z.exe”的網(wǎng)頁中的參考鏈接在分組后被重寫入到所述目錄路徑中。
接下來，參照圖4詳細描述根據(jù)該實施例中內(nèi)容管理裝置B1中內(nèi)容的特性進行自動分組的操作。
在所述內(nèi)容管理裝置B1中，內(nèi)容分類單元B12將在分類策略設(shè)置單元B11中設(shè)置的內(nèi)容分類策略(圖4中步驟S101)讀出，并且根據(jù)讀出的分類策略將內(nèi)容存儲單元A11中的內(nèi)容分成多個媒體類型(步驟S102)。
當(dāng)將內(nèi)容分成多個媒體類型之后，所述內(nèi)容分類單元B12進一步將已經(jīng)被分為多個媒體類型的內(nèi)容分成多個內(nèi)容組(步驟S103)。該步驟根據(jù)詳細的特性例如大小以及存取頻率對內(nèi)容進行分類，涉及動態(tài)參數(shù)例如存儲于動態(tài)參數(shù)存儲單元A16中的存取頻率。
當(dāng)將內(nèi)容分為媒體類型并且將各個媒體類型中的內(nèi)容分為內(nèi)容組之后，所述內(nèi)容分組單元B13將內(nèi)容分到各個內(nèi)容組中(步驟S104)。
該實施例中，雖然將所述內(nèi)容管理裝置B1描述為一個在獨立節(jié)點中實現(xiàn)的單元，但是其還能實現(xiàn)如圖5示例的內(nèi)容服務(wù)器A1的功能。更進一步，它還可以在包括第二實施例中描述的服務(wù)器負載平衡裝置C1的某個節(jié)點上實現(xiàn)，并且它還可以具有網(wǎng)關(guān)功能。
更進一步，雖然上述敘述中已經(jīng)描述了一個內(nèi)容服務(wù)器A1與內(nèi)容管理裝置B1相連接的情況，可是多個內(nèi)容服務(wù)器A1可以同時與內(nèi)容管理裝置B1相連接，如圖6中示例，并且所述內(nèi)容管理裝置B1可以對各個內(nèi)容服務(wù)器A1中的內(nèi)容進行分類，并以此來管理內(nèi)容。
下面將對該實施例的效果進行描述。該實施例中，所述內(nèi)容管理裝置B1依據(jù)其特性自動對內(nèi)容服務(wù)器中的內(nèi)容進行分類。該實施例的一個特點就是可以依據(jù)其動態(tài)特性進行分類。
更進一步，作為分類結(jié)果而生成的內(nèi)容組被自動分組。內(nèi)容服務(wù)器中的內(nèi)容最初不是被分組到同一目錄下的各個特性。例如，從文件大小以及媒體類型角度來看具有不同特性的內(nèi)容例如文章、圖以及新聞圖片，通常都以一種混合的方式位于有關(guān)新聞的目錄“/news/”下。
該實施例能夠在同一目錄下重新建立具有相同特性的內(nèi)容組，并且當(dāng)將在隨后描述的位于客戶端一側(cè)的服務(wù)器負載平衡裝置在各個目錄下選擇最優(yōu)服務(wù)器時，對于內(nèi)容特性最合適的請求路徑能夠通過最小數(shù)目的項目實現(xiàn)。
接下來，本發(fā)明的第二實施例隨后將結(jié)合附圖進行詳細描述。參照圖7，本發(fā)明第二實施例由內(nèi)容服務(wù)器A2，服務(wù)器負載平衡裝置C1以及客戶端D1實現(xiàn)。
所述內(nèi)容服務(wù)器A2包括用于存儲多種傳送內(nèi)容的內(nèi)容存儲單元A11，請求接收/內(nèi)容響應(yīng)單元A12，以及資源響應(yīng)單元A13。
請求接收/內(nèi)容響應(yīng)單元A12接收來自客戶端D1的請求并且識別相應(yīng)內(nèi)容作為應(yīng)答。接著，它發(fā)送上述內(nèi)容到客戶端。
資源響應(yīng)單元A13應(yīng)答來自服務(wù)器負載平衡裝置C1的用于獲取資源信息的請求，并且依據(jù)所請求內(nèi)容返回資源參數(shù)例如服務(wù)器負載、連接數(shù)以及鏈接使用率。當(dāng)服務(wù)器負載平衡裝置C1沒有請求所述內(nèi)容服務(wù)器A2獲得資源信息時，該資源響應(yīng)單元A13就可以被忽略。
所述服務(wù)器負載平衡裝置C1包括一個資源獲得單元C11，一個目的服務(wù)器確定策略設(shè)置單元C12，一個目的服務(wù)器確定單元C13，一個請求路徑表格C14，一個請求接收單元C15，一個請求傳送單元C16，以及一個內(nèi)容接收/傳送單元C17。所述服務(wù)器負載平衡裝置C1可以具有例如代理服務(wù)器的功能，其中代理服務(wù)器集中管理來自客戶端的多個請求。
當(dāng)沒有任何關(guān)于內(nèi)容服務(wù)器的資源信息在請求路徑表格C14中注冊時，例如目的服務(wù)器以及其他候選服務(wù)器，所述資源獲得單元C11獲取用于注冊一個目的服務(wù)器的必要資源信息，或者獲取有關(guān)在請求路徑表格C14中注冊的目的服務(wù)器及其它候選服務(wù)器的資源信息。所述資源信息包括例如，網(wǎng)絡(luò)中的資源參數(shù)，例如網(wǎng)頁服務(wù)器的RTT(往返時間)及傳輸處理量，以及有關(guān)服務(wù)器本身的資源參數(shù)，例如網(wǎng)頁服務(wù)器的負載及連接數(shù)。這里大致有兩種獲取資源信息的方法。
一種方法就是請求信息例如CPU負載及來自內(nèi)容服務(wù)器A2自身節(jié)點的剩余帶寬以便于能夠獲得信息(主動類型)，另一種方法就是從所述內(nèi)容接收/傳送單元C17獲取用于傳送接收到的內(nèi)容的延遲以及獲取的傳輸處理量(被動類型)。通過使用該被動類型方法可以間接預(yù)測出服務(wù)器的CPU負載以及對話數(shù)量。
更進一步，還可以從已獲取的資源參數(shù)中預(yù)測或者提取出另一資源參數(shù)。例如可以考慮下列方法；(1)考慮獲取小內(nèi)容的測量時間，例如RTT，以及(2)考慮程序運行時用于獲得具有大負載的CGI內(nèi)容的時間，例如服務(wù)器負載。
所述目的服務(wù)器確定策略設(shè)置單元C12設(shè)置一個目的服務(wù)器確定策略表格103，該表格給出了依據(jù)各個內(nèi)容的特性選擇目的服務(wù)器的各個策略。
圖8給出了目的服務(wù)器確定策略表格103的一個例子，該表格示出了目的服務(wù)器確定策略設(shè)置單元C12中設(shè)置的策略。在目的服務(wù)器確定策略表格103中，對于具有文件特性的內(nèi)容組，使用了獲取內(nèi)容時的傳輸處理量，并且以具有最大傳輸處理量的服務(wù)器作為參考，并且選擇一個具有上述最大值60％或者更高的服務(wù)器作為目的服務(wù)器。對于具有CGI特性的內(nèi)容組，采用了通過服務(wù)器RTT與CPU負載相乘而獲取的數(shù)值，在該值的增加序列中選擇了3個服務(wù)器。
目的服務(wù)器確定單元C13通過使用在目的服務(wù)器確定策略設(shè)置單元C12中設(shè)置的資源參數(shù)，從由資源獲取單元C11獲取的資源參數(shù)中確定一個目的服務(wù)器。
所述請求路徑表格C14指出了由哪一個服務(wù)器來傳輸請求接收單元C15接收的請求。由目的服務(wù)器確定單元C13對表格的項目進行寫入。
圖9是指出所述請求路徑表格C14的一個例子的表格104。在表格104中，相應(yīng)于將要被請求的各個內(nèi)容的URL的目的服務(wù)器的IP地址被寫入。
例如，所述URL“//http//www.aaa.net/cgi/high/*”的項目是所述URL的詞頭表達式，表示所有具有“//http//www.aaa.net/cgi/high/”報頭的URL。對應(yīng)于該項目的請求被傳輸?shù)狡銲P地址為“10.2.5.2”的內(nèi)容服務(wù)器。URL“http//www.ccc.com/file/small/*.jpg” 的項目表示“http//www.ccc.com/file/small”下所有的內(nèi)容中具有jpg文件擴展名的內(nèi)容。一個對應(yīng)于所述項目的請求被傳輸?shù)狡銲P地址為“10.4.2.1”或“10.2.5.2”的內(nèi)容服務(wù)器。
當(dāng)這樣指定了多個目的服務(wù)器IP地址時，可以以循環(huán)的方法(round robinmethod)為每個請求選擇一個服務(wù)器，或者通過使用加權(quán)循環(huán)(weighted roundrobin)或加權(quán)無用功能，根據(jù)為各個服務(wù)器指定的權(quán)數(shù)即所述優(yōu)先級別比率來進行選擇。
所述請求接收單元C15接收來自客戶端D1的請求并且解析其中的內(nèi)容。通過解析所述請求的內(nèi)容，它能識別出客戶端D1所請求內(nèi)容的URL。更進一步，通過參照請求路徑表格C14確定一個目的服務(wù)器來傳輸所述請求，并且把其交給請求傳送單元C16。
在收到所述傳輸請求的內(nèi)容以及來自請求接收單元C15的傳輸服務(wù)器信息時，該請求傳送單元C16傳輸請求到內(nèi)容服務(wù)器A2。
所述內(nèi)容接收傳送單元C17從內(nèi)容服務(wù)器A2接收相應(yīng)于請求傳送單元C16發(fā)送的請求的答復(fù)內(nèi)容并且傳輸上述內(nèi)容到客戶端D1。
該客戶端D1發(fā)出用于獲取內(nèi)容服務(wù)器A2中的內(nèi)容的請求。該請求被發(fā)送給由服務(wù)器負載平衡裝置指定的內(nèi)容服務(wù)器A2。這里，所述客戶端D1不只是包括一個客戶端而是多個客戶端。
在根據(jù)該實施例中服務(wù)器負載平衡裝置C1的內(nèi)容特性改變選擇策略時，下面將參照圖10至圖12對選擇目的服務(wù)器的操作進行詳細描述。
首先，參照圖10對服務(wù)器負載平衡裝置C1從客戶端D1接收一個用于獲得內(nèi)容的請求時的操作進行詳細描述。
當(dāng)請求接收單元C15接收一個來自服務(wù)器負載平衡裝置中的客戶端D1的請求時，它分析該請求并且對該請求內(nèi)容的URL進行識別(圖10中步驟S201)。
由所述請求接收單元C15檢查在請求路徑表格104中是否存在對應(yīng)于所述請求內(nèi)容的項目(步驟S202)。
在步驟202中，當(dāng)存在一個對應(yīng)于上述內(nèi)容的項目時，所述請求接收單元C15讀出傳輸請求目的地的內(nèi)容服務(wù)器A2，涉及所述項目(步驟S203)。所述請求傳輸單元C16從所述請求接收單元C15中接收將要被傳輸?shù)恼埱笠约皩⒁粋鬏數(shù)膬?nèi)容服務(wù)器A2的信息，并且將該請求傳輸給內(nèi)容服務(wù)器A2(步驟S204)。
在步驟202中，當(dāng)不存在對應(yīng)于上述內(nèi)容的項目時，所述請求接收單元C15傳輸該請求到一個默認服務(wù)器(步驟S205)，為含有該請求內(nèi)容的內(nèi)容組確定一個目的服務(wù)器，并且將目的服務(wù)器的項目寫入到請求路徑表格中(步驟S206)。這里，該默認服務(wù)器表示一個對應(yīng)于所述包括該用作數(shù)據(jù)的請求的IP信息包的目的IP地址的服務(wù)器，以及一個對應(yīng)于通過使用DNS服務(wù)器解析的IP地址的服務(wù)器，出自該請求中URL的FQDN(正式域名)部分。
圖11為用于對上述步驟S206中的操作進行描述的流程圖。
由目的服務(wù)器確定單元C13識別該被請求的內(nèi)容屬于哪個內(nèi)容組并獲得相應(yīng)于該內(nèi)容組的候選服務(wù)器列表(圖11中的步驟S301)。作為該步驟中的識別/獲得方法，還有一種通過對使用請求中全部或部分URL作為密鑰的內(nèi)容管理裝置B1進行查詢的方法以及一種直接查詢內(nèi)容服務(wù)器A2的方法。這里，候選服務(wù)器表示保存內(nèi)容組的所有內(nèi)容服務(wù)器A2或者是從保存內(nèi)容組的所有內(nèi)容服務(wù)器A2中提取出來的一個服務(wù)器組。
進一步，還有一種用來識別相應(yīng)于URL的內(nèi)容組以及通過使用DNS服務(wù)器來獲得候選服務(wù)器列表的方法。在這種情況下，用于各個內(nèi)容組的唯一FQDN被需要并且將相應(yīng)于各個使用FQDN作為密鑰的IP地址的內(nèi)容服務(wù)器視為候選服務(wù)器。以生成用于各個內(nèi)容組的唯一FQDN的方法為例，當(dāng)相當(dāng)于被請求內(nèi)容的URL為“http//www.aaa.net/cgi/high/prog.cgi”時，該“high.cgi.www.aaa.net”被定義為相當(dāng)于包括該內(nèi)容的內(nèi)容組的FQDN，并且使用FQDN作為候選服務(wù)器IP地址的密鑰。
由該目的服務(wù)器確定單元C13識別該內(nèi)容組遵循目的服務(wù)器確定策略設(shè)置單元C12中的哪一條策略并讀取相應(yīng)的目的服務(wù)器確定策略(步驟S302)。作為其相應(yīng)的識別方法，以下面的兩種方法為例。
(1)在步驟S301的查詢內(nèi)容管理裝置B1過程中，一塊兒獲得該內(nèi)容組的內(nèi)容特征信息。
(2)在服務(wù)器負載平衡裝置C1中準備有一個表格，該表格中示出了相應(yīng)于各個URL的內(nèi)容特征與同其進行映射的目的端口號之間的對應(yīng)關(guān)系(例如，在其CGI中包括cgi-bin的內(nèi)容組的內(nèi)容特征為CGI并且具有目的端口號554的內(nèi)容組的內(nèi)容特征為流)。
根據(jù)在步驟S302中讀出來的目的服務(wù)器確定策略，為了確定相應(yīng)于內(nèi)容組的目的服務(wù)器，該目的服務(wù)器確定單元C13通過直接從候選服務(wù)器中獲得內(nèi)容來獲得資源，也就是檢查該無源類型資源測量是否是必須的(步驟S303)。
以該無源類型資源測量是必須的情況為例，可以出現(xiàn)為了確定目的服務(wù)器而使用資源參數(shù)例如傳送延遲及傳送內(nèi)容處理量的情況。相反，若該無源類型資源測量不是必須的，則會出現(xiàn)通過查詢來獲得資源參數(shù)例如服務(wù)器負載和鏈接帶寬以及通過使用該結(jié)果來執(zhí)行用于目的服務(wù)器確定的有效類型資源測量。換句話說，目的服務(wù)器可以以固定的方式通過無源類型資源測量和有效類型資源測量來確定。
在步驟S303，如果需要通過無源類型資源測量來檢測目的服務(wù)器，則該目的服務(wù)器確定單元C13就會將該候選服務(wù)器寫入到請求路徑表格C14中(步驟S304)。
若在步驟S304中將候選服務(wù)器寫入到請求路徑表格C14中，該請求路徑表格C14從候選服務(wù)器中選出一個內(nèi)容服務(wù)器作為請求屬于內(nèi)容組內(nèi)容的目的地。
這里，可以設(shè)置為通過循環(huán)的方法(round robin method)選擇目的地而將請求傳送給所有的候選服務(wù)器。通過將請求發(fā)送給各個候選服務(wù)器，該內(nèi)容接收/傳送單元C17可以從各個候選服務(wù)器處接收內(nèi)容并且資源獲得單元C11可以知道資源參數(shù)例如傳送延遲以及此時的傳送處理量(通過計算每小時接收到的內(nèi)容數(shù)量)(步驟S305)。
檢測是否需要有效類型資源測量(步驟S306)。也就是，如果只有步驟S305中的無源類型資源測量無法獲得足夠的資源參數(shù)，則有效類型資源測量就是必須的并在步驟S307中執(zhí)行。
若不需要通過步驟S303中的無源類型資源測量來檢測目的服務(wù)器，同時在步驟S306中判斷出有效資源檢測類型是必須的，則該目的服務(wù)器確定單元C13通過使用資源獲得單元C11來測量并獲得必須的資源參數(shù)(步驟S307)。
若在步驟S305或S307中獲得了確定目的服務(wù)器所必須的資源參數(shù)，則由目的服務(wù)器確定單元C13通過使用上述的資源參數(shù)以及在步驟S301中讀出的目的服務(wù)器確定策略來確定目的服務(wù)器(步驟S308)。這時，多個內(nèi)容服務(wù)器可被確定為目的服務(wù)器。
被確定的目的服務(wù)器的項目被寫入到請求路徑表格C14中作為相當(dāng)于內(nèi)容組的請求目的地(步驟S309)。若寫入了多個項目，則同時寫入向各個內(nèi)容服務(wù)器傳送請求的比率以及權(quán)數(shù)。
若在步驟S309中向請求路徑表格C14中寫入了目的服務(wù)器，則該步驟就轉(zhuǎn)移至保持被寫入項目的狀態(tài)(步驟S310)。
圖12為用于對上述步驟S310中的操作進行詳細描述的流程圖。
請求路徑表格C14定期的檢查是否接收到了相應(yīng)于將要在預(yù)定的時間內(nèi)保持的目的服務(wù)器項目的請求(圖12中的步驟S401)。如果在預(yù)定的時間或更多的時間內(nèi)沒有接收到任何請求，則相應(yīng)的項目將被刪掉(步驟S404)。
若在預(yù)定的時間內(nèi)接收到了一個用于項目的請求，則通過使用資源獲得單元C11來檢查對于相當(dāng)于項目的候選服務(wù)器來說在確定目的的同時該資源值是否被改變?yōu)楸阮A(yù)定的閾值還大(步驟S402)。這一檢查是為了確定在步驟S307中確定的目的服務(wù)器是否仍舊合適。若沒有變化超過了閾值，則再一次返回至步驟S401。
在步驟S402中，若變化超出了閾值，則返回至步驟S301，在這里重新執(zhí)行確定目的服務(wù)器的操作(步驟S403)。
下面將對該實施例的有益效果進行描述。
在該實施例中，服務(wù)器負載平衡裝置根據(jù)對于各個內(nèi)容組來說都不相同的策略來確定目的服務(wù)器，并將其注冊到請求路徑表格中。至今，由于根據(jù)相同的基準為每個內(nèi)容組都選擇了一個目的服務(wù)器，因此僅根據(jù)各個內(nèi)容組無法選擇出最優(yōu)服務(wù)器?？墒窃谠搶嵤├校捎谀康姆?wù)器的選擇標準是根據(jù)各個內(nèi)容組的特征而變化的，因此來自客戶端的請求會一直被傳送給最優(yōu)服務(wù)器。尤其是，通過將該實施例和根據(jù)內(nèi)容特征自動生成內(nèi)容組的第一實施例組合在一塊，可以更有效的選擇出一個服務(wù)器。
下面將參照附圖對本發(fā)明的第三實施例進行詳細的描述。
參照圖13，本發(fā)明第三實施例由內(nèi)容服務(wù)器A3和服務(wù)器負載平衡裝置C1構(gòu)成。
內(nèi)容服務(wù)器A3包括資源響應(yīng)策略設(shè)置單元A14，還包括第二實施例內(nèi)容服務(wù)器A2的結(jié)構(gòu)，并且用資源響應(yīng)單元A15代替了資源響應(yīng)單元A13。其它的部件同圖7中所示的第二實施例中的部件都相同。
為了響應(yīng)用于獲得從服務(wù)器負載平衡裝置C1接收到的資源信息的請求而使用資源響應(yīng)策略設(shè)置單元A14來設(shè)置策略。這里，該策略并沒有被用來對自身內(nèi)容服務(wù)器集中進行過多的存取。例如，若內(nèi)容服務(wù)器A3所處的狀態(tài)為自身節(jié)點的CPU負載低于10％，則可以假設(shè)它從多個服務(wù)器負載平衡裝置中接收請求資源信息的請求。同時，當(dāng)它將CPU負載10％的值返回給所有的服務(wù)器負載平衡裝置時，由各個服務(wù)器負載平衡裝置根據(jù)這個接收到的值判斷出該內(nèi)容服務(wù)器A3的CPU負載足夠低并且它們可以選擇該內(nèi)容服務(wù)器A3作為目的服務(wù)器來傳送各個請求。結(jié)果，就可以通過集中存取來快速的增加內(nèi)容服務(wù)器A3的CPU負載，但是這無法提供作為服務(wù)器的充分性能。在最壞的情況下，可能出現(xiàn)遞歸重復(fù)進行相同操作的擺動現(xiàn)象，以至于所有的已經(jīng)選擇的內(nèi)容服務(wù)器A3作為目的服務(wù)器的服務(wù)器負載平衡裝置都對服務(wù)器性能的退化進行監(jiān)測，并再次選擇另一個內(nèi)容服務(wù)器作為目的服務(wù)器，這樣做的結(jié)果就是，由于集中存取而使得該最新被選中的內(nèi)容服務(wù)器的性能再一次退化。
這里設(shè)置了一個策略，用來防止上述的對于一個指定內(nèi)容服務(wù)器的集中存取以及擺動現(xiàn)象。最為該策略的一個實例，可以考慮存在一個在預(yù)定的時間內(nèi)不返回一個預(yù)定閾值以及其上資源的策略，或者是一個在預(yù)定的閾值內(nèi)約束服務(wù)器負載平衡裝置號碼的策略，其中該裝置可以同時返回給上述資源一個給定的值。
圖14為一個資源響應(yīng)策略表格105的例子，該表格中顯示出了資源響應(yīng)策略設(shè)置單元A14中的每個策略設(shè)置。根據(jù)各種資源類型的響應(yīng)策略都被顯示在資源響應(yīng)策略表格105中。例如，對于CPU負載來說，若當(dāng)前的CPU負載為0％至30％，則將實際CPU負載兩倍的值按照30％的概率被返回(實際值按照70％的概率返回)，若為30％至60％，則將實際CPU負載1.5倍的值按照50％的概率返回，并且若為60％至100％，則返回實際值。
該資源響應(yīng)單元A15為了回答獲得來自服務(wù)器負載平衡裝置C1的資源信息的請求而返回資源參數(shù)，這種方式與第一實施例中的資源響應(yīng)單元A13一樣。但是，在返回資源時，資源響應(yīng)單元A15參照此時在資源響應(yīng)策略設(shè)置單元A14中設(shè)置的策略，并根據(jù)該策略計算將要被返回的資源值。
參照圖15，對內(nèi)容服務(wù)器A3中接收請求的操作進行詳細的描述，其中該請求用來獲得來自服務(wù)器負載平衡裝置C1的資源。
在接收到用于從服務(wù)器負載平衡裝置C1處獲得資源信息的請求時，內(nèi)容服務(wù)器A3中的資源響應(yīng)單元A15獲得了相當(dāng)于自身節(jié)點中的被請求資源參數(shù)的資源值(圖15中的步驟S501)。
該資源響應(yīng)單元A15獲得了相當(dāng)于來自資源響應(yīng)策略設(shè)置單元A14的資源參數(shù)的資源響應(yīng)策略(步驟S502)。
步驟S502之后，由資源響應(yīng)單元A15檢查它是否能夠以其本身來響應(yīng)在步驟S501中獲得的資源參數(shù)(步驟S503)。
若在步驟S503中判斷出該資源參數(shù)能夠以其本身返回，則該資源響應(yīng)單元A15將該資源參數(shù)返回給已發(fā)出獲得資源信息請求的服務(wù)器負載平衡裝置C1(S505)。
若在步驟S503中判斷出該資源參數(shù)無法以其本身返回，則該資源響應(yīng)單元A15根據(jù)相當(dāng)于資源參數(shù)的資源響應(yīng)策略來計算用于返回的資源值(步驟S504)。與資源參數(shù)相同，該計算后的響應(yīng)值被返回給已發(fā)出獲得資源信息請求的服務(wù)器負載平衡裝置C1(步驟S505)。
下面將對該實施例的有益效果進行描述。在該實施例中，內(nèi)容服務(wù)器并不是一直返回和它本身一樣的實際資源信息，而是根據(jù)設(shè)置資源響應(yīng)策略將校準后的資源值返回給各個獲得資源信息的請求，其中該信息來自位于一個網(wǎng)絡(luò)中的多個服務(wù)器負載平衡裝置。
由于每個服務(wù)器負載平衡裝置都分別確定一個目的服務(wù)器，如果象現(xiàn)有技術(shù)那樣返回實際上的資源信息，則由于有多個服務(wù)器負載平衡裝置同時選擇該內(nèi)容服務(wù)器作為目的服務(wù)器而有可能出現(xiàn)請求快速集中的情況。通過返回校準后的資源值就能夠抑制出現(xiàn)上述的請求迅速集中的情況，例如該實施例。
下面將參照附圖對本發(fā)明的第四實施例進行詳細的描述。
參照圖16，本發(fā)明第四實施例由內(nèi)容服務(wù)器A2和服務(wù)器負載平衡裝置C2構(gòu)成。
服務(wù)器負載平衡裝置C2包括權(quán)數(shù)設(shè)置單元C19，還包括第二實施例服務(wù)器負載平衡裝置C1的結(jié)構(gòu)。進一步，還用請求路徑表格C18代替了請求路徑表格C14。
請求路徑表格C18具有同第二實施例中所述的請求路徑表格C14相同的功能，但它們之間的不同之處就在于傳送權(quán)數(shù)值被附加在各個項目的每個目的服務(wù)器IP地址之后。通過使用循環(huán)等待或加權(quán)散列功能，參照指定給各個服務(wù)器的權(quán)數(shù)值的比率選擇出一個將要用于響應(yīng)請求接收單元C15的服務(wù)器。
雖然該沒有傳送請求的服務(wù)器并沒有被注冊在請求路徑表格C14中，但是用于內(nèi)容組的所有候選服務(wù)器都被注冊在該請求路徑表格C18中。這時，并不傳送請求的服務(wù)器用權(quán)數(shù)0％進行注冊。圖17以請求路徑表格C18為例示出了表格106。
該權(quán)數(shù)設(shè)置單元C19具有在請求路徑表格C18中設(shè)置/改變傳送權(quán)數(shù)值的功能。在圖17的請求路徑表格106中，“rtsp//stream.bbb.org/live/*”的各個傳送服務(wù)器IP地址“10.5.1.1”、“10.7.1.1”、“10.4.2.1”以及“10.2.5.2”都具有各自的權(quán)數(shù)值20％、20％、10％以及50％，并且該權(quán)數(shù)設(shè)置單元C19執(zhí)行將上述值分別改為例如30％、30％、20％以及20％的操作。
參照附圖18，下面將對防止服務(wù)器負載平衡裝置C2中的一個特定服務(wù)器負載集中的操作進行詳細的描述。
該目的服務(wù)器確定單元C13通過使用資源獲得單元C11為每個位于請求路徑表格C18中的項目獲得相當(dāng)于各個已注冊過目的服務(wù)器的資源(圖18中的步驟S601)。已獲得資源的類型被設(shè)置在目的服務(wù)器確定策略設(shè)置單元C12中并且對于每個項目都不相同。
若獲得了相當(dāng)于各個目的服務(wù)器的資源，側(cè)該目的服務(wù)器確定單元C13對各個服務(wù)器獲得的資源進行比較并檢查各個服務(wù)器資源值之間的差值是否超出了一個預(yù)定的閾值(步驟S602)。該檢查的基準包括，例如“對于每個服務(wù)器來說，獲得資源的最大值比最小值的兩倍還大，或者更大”以及“對于每個服務(wù)器來說，獲得傳送處理量的最大值和最小值之間的差別為1Mbps或者更多”。
若在步驟S602中各個服務(wù)器資源值之間的不同沒有超出一個預(yù)定的閾值，則在請求路徑表格C18中設(shè)置的加權(quán)數(shù)值并不發(fā)生變化，而當(dāng)其超出上述的閾值時，該權(quán)數(shù)設(shè)置單元C19會根據(jù)獲得的資源值來重新設(shè)置加權(quán)數(shù)值(步驟S603)。
例如，假設(shè)有三個目的服務(wù)器；服務(wù)器A、服務(wù)器B以及服務(wù)器C都已經(jīng)注冊過并加權(quán)數(shù)值分別為30％、50％以及20％。假設(shè)三個服務(wù)器獲得的傳送處理量分別為6Mbps、3Mbps以及1Mbps。同時，根據(jù)傳送處理量的比率將加權(quán)數(shù)值改為60％、30％以及10％。
可是從防止擺動的觀點來看，根據(jù)資源值比率突發(fā)性的改變加權(quán)數(shù)值并不可取。在上述例子的情況下，在改變權(quán)數(shù)之后，雖然對于服務(wù)器A的請求比率從30％增加至60％，可是如果在另一個服務(wù)器負載平衡裝置中對于服務(wù)器A的請求比率也類似的增加，則對服務(wù)器A的請求次數(shù)也會迅速增加并可能大大的增加服務(wù)器A傳送處理量的退化。接著，就需要再次改變加權(quán)數(shù)值并可能出現(xiàn)該加權(quán)改變操作不收斂相反卻發(fā)生擺動的情況。為了防止發(fā)生擺動的情況，提供了一種通過使用移動粒度(move_granularity)來限制加權(quán)改變比率的方法，這不需要根據(jù)資源值比率突發(fā)性的改變加權(quán)數(shù)值。該移動粒度為用于限制加權(quán)數(shù)值第一變化的參數(shù)并取值為1.0或更小。在上述的例子中，根據(jù)資源值比率將服務(wù)器A的加權(quán)數(shù)值從30％改變至60％，相當(dāng)于“移動粒度＝1.0”。例如，在上述例子中，若“移動粒度＝0.3”，則服務(wù)器A的加權(quán)數(shù)值變?yōu)?60％-30％)×0.3＝9％，并且改變后的加權(quán)數(shù)值變成39％。類似的，服務(wù)器B和服務(wù)器C的加權(quán)數(shù)值也分別變?yōu)?4％和17％。
通過使用上面所提到的移動粒度逐漸的改變加權(quán)數(shù)值，可以限制一個特定服務(wù)器接收到的請求數(shù)量的快速增加/減小并防止擺動。這里，很重要的就是不要將移動粒度的值設(shè)置為能夠?qū)е聰[動的數(shù)值。例如，可以考慮有一種采用反饋控制來自動調(diào)整移動粒度為一個值并不會發(fā)生擺動的方法。例如，可以考慮一種方法，通過使用反饋控制，自動調(diào)節(jié)移動粒度到一個不發(fā)生擺動的值。
該目的服務(wù)器確定單元周期性的在請求路徑單元C18中的各個項目執(zhí)行從S601至S603的步驟。
已經(jīng)在圖18中被描述過的操作必須使用移動粒度并調(diào)整其值使其不會導(dǎo)致擺動。這時，將對限制內(nèi)容服務(wù)器中請求數(shù)量迅速增加的方法中的操作進行詳細描述，而不是一定要調(diào)整移動粒度(也就是“移動粒度＝1.0”)。
參照圖19，至步驟S602之前的操作同圖18中所描述的相同。若在步驟S602中資源值的差別為該閾值或更大，則由確定加權(quán)數(shù)值變化時間(圖19中的步驟S604)來代替步驟S603中的立即改變加權(quán)數(shù)值。根據(jù)概率來確定改變加權(quán)數(shù)值的時間，并且例如，可以用相等的概率來確定0分鐘至10分鐘之間的時間。
在步驟S604中確定時間時，在步驟S605中再次由該資源獲得單元C11為注冊在請求路徑表格C18中每個項目中的目的服務(wù)器獲得資源。若在步驟S605中再次為每個目的服務(wù)器獲得了資源，則再次執(zhí)行同步驟S602中相同的操作并檢查各個服務(wù)器之間的資源值差距是否超出了預(yù)定的閾值(步驟S606)。
步驟S606中若服務(wù)器之間資源值的差距并沒有超出預(yù)定閾值，這就可以結(jié)束該處理過程而不需要改變設(shè)置在請求路徑表格C18中的加權(quán)數(shù)值，同時若其超出了該閾值，則由權(quán)數(shù)設(shè)置單元C19根據(jù)在步驟S605中再次獲得的資源值重新設(shè)置該加權(quán)數(shù)值(步驟S607)。
在該操作過程中，可以通過隨概率分散時間延遲重新設(shè)置加權(quán)數(shù)值的時間來對內(nèi)容服務(wù)器請求次數(shù)的迅速變化進行限制，而不需要調(diào)整移動粒度。需要在被延遲的時間內(nèi)判斷出是否要對加權(quán)數(shù)值進行重新設(shè)置，并且如果不需要重新設(shè)置，則不執(zhí)行重新設(shè)置操作，并因此限制了為改變加權(quán)數(shù)值并有效地防止擺動而進行不必要的操作。
下面將對該實施例的有益效果進行描述。
在該實施例中，分別根據(jù)獲得的資源值對服務(wù)器負載平衡裝置各個項目中目的服務(wù)器的加權(quán)數(shù)值進行改變?？梢酝ㄟ^使用移動粒度來逐步的改變加權(quán)數(shù)值，并據(jù)此來限制對內(nèi)容服務(wù)器請求次數(shù)的迅速變化。進一步，還可以通過隨概率分散時間延遲重新設(shè)置加權(quán)數(shù)值的時間來獲得相同的效果，而不需要調(diào)整移動粒度。雖然在第三實施例中對內(nèi)容服務(wù)器一側(cè)的請求次數(shù)的迅速變化進行了限制，可是在該實施例中，也可以在位于服務(wù)器負載平衡裝置的一側(cè)實現(xiàn)相同的功能，而不需要對該內(nèi)容服務(wù)器一側(cè)進行改變。
下面將參照附圖對本發(fā)明的第五實施例進行詳細的描述。
參照圖20，本發(fā)明第五實施例由內(nèi)容服務(wù)器A4、服務(wù)器負載平衡裝置C3、客戶端D2以及DNS服務(wù)器E1構(gòu)成。
該內(nèi)容服務(wù)器A4包括內(nèi)容存儲單元A11以及請求接收/內(nèi)容響應(yīng)單元A12。其各自的功能和操作都與第二實施例中的相同。
該服務(wù)器負載平衡裝置C3包括信息包接收單元C25、信息包傳送單元C20、信息包路徑表格C21、目的服務(wù)器確定單元C22以及FQDN(正式域名)解析單元C23以及地址解析單元C24。
該信息包接收單元C25接收來自客戶端D2的信息包并檢測該信息包的目的端口號。若檢測到目的端口號包括在一個預(yù)定值中間，則根據(jù)相同數(shù)據(jù)包的目的IP地址，參照注冊在信息包路徑表格C21中的項目，檢測將要向其傳送信息包的內(nèi)容服務(wù)器A4的IP地址。
信息包傳送單元C20將由信息包接收單元C25接收到的信息包的目的IP地址重新寫入到傳輸目的地內(nèi)容服務(wù)器A4的IP地址中并將該信息包傳送給內(nèi)容服務(wù)器A4。
換句話說，該信息包可以只需在第2層重新寫入報頭就能被傳送，而不需要重新寫入IP地址。作為第2層協(xié)議，若考慮到使用以太網(wǎng)(R)的情況，可以通過使用來自目的地內(nèi)容服務(wù)器A4的IP地址的APR來解析內(nèi)容服務(wù)器A4的MAC地址，并且該信息包隨著被視為目的MAC地址的解析后MAC地址被傳送出去，而不需要重新寫入信息包的目的IP地址。為了進行簡要的描述，在下文中只對傳送具有重寫IP地址的信息包的情況進行描述。
在信息包路徑表格C21中，根據(jù)由信息包接收單元C23接收到的各個信息包的目的IP地址/目的端口號分別對該傳送信息包的內(nèi)容服務(wù)器的IP地址進行注冊。
圖21示出了信息包路徑表格C21的一個例子的表格107。根據(jù)表格107，例如，目的IP地址“10.1.1.1”以及目的端口號為“7070”的信息包被傳送給目的IP地址為“20.2.2.2”或者目的IP地址為“30.3.3.3”的內(nèi)容服務(wù)器。
這時，該方法通過源IP地址/源端口號的相同組合中的散列功能來進行乘法，并根據(jù)該散列值來選擇目的服務(wù)器，為了與相同的內(nèi)容服務(wù)器建立相同的連接還不需要為每個信息包交替選擇兩個內(nèi)容服務(wù)器而采用了該方法。進一步，還有一種能夠在接收到的信息包的TCP報頭SYN標識接收之后用來傳送信息包的記錄方法，其中該信息包具有同相同服務(wù)器終端的信息包一樣的IP地址/端口號。
對于具有多個目的IP地址/目的端口號的信息包來說，由目的服務(wù)器確定單元C22來確定一個目的服務(wù)器(內(nèi)容服務(wù)器A4)。也可以采用同第二實施例目的服務(wù)器確定單元C13中所描述的相同的方法來確定目的服務(wù)器。該被確定的目的服務(wù)器被寫入到信息包路徑表格C21的項目中。
若目的服務(wù)器確定單元C22確定了就是具有多個目的IP地址/目的端口號的信息包的目的地的內(nèi)容服務(wù)器A4，則由FQDN解析單元C23查詢關(guān)于DNS服務(wù)器E1目的IP地址的FQDN。
若目的服務(wù)器確定單元C22確定了就是具有多個目的IP地址的信息包的目的地的服務(wù)器，則在FQDN解析單元C23解析完關(guān)于目的IP地址的FQDN之后，由地址解析單元C24通過使用解析過的FQDN以及信息包的目的端口號重新生成FQDN，并且對重新剛生成的FQDN的IP地址進行解析。這里，新近重新生成的FQDN對于各個目的IP地址以及各個信息包的目的端口號來說必須是唯一的，若解析后的FQDN為“aaa.com”并且信息包的目的端口號為“7070”，則它對于FQDN“port7070.aaa.com”的IP地址進行解析。這里，可以對多個IP地址進行解析并可以通過使用FQDN解析單元C23和地址解析單元C24來獲得信息包目的地候選服務(wù)器的IP地址列表。
客戶端D2包括請求發(fā)送單元D11以及地址解析單元D12。
該請求發(fā)送單元D11發(fā)出一個用來獲得作為IP信息包的內(nèi)容的請求。同時，從作為被請求內(nèi)容標識符的URL中，通過使用地址解析單元D12對相當(dāng)于URL的FQDN的IP地址進行解析，并且將該解析出來的IP地址確定作為將要發(fā)送IP信息包的目的IP地址。由URL指定的端口號也被確定為目的端口號。例如，當(dāng)發(fā)出為了獲得其URL為“http//aaa.com/pict.jpg7070”的內(nèi)容的請求，假設(shè)“aaa.com”的IP地址為“10.1.1.1”，則該請求發(fā)送單元D11就會發(fā)送目的IP地址為“10.1.1.1”以及目的端口號為“7070”的信息包。
地址解析單元D12對使用預(yù)期內(nèi)容URL中的FQDN部分作為密鑰的DNS服務(wù)器E1的IP地址進行查詢。來自DNS服務(wù)器E1的響應(yīng)可以包括多個IP地址。在這種情況下，可以使用多個項目中的一個作為相應(yīng)于FQDN的IP地址。
該DNS服務(wù)器E1包括地址/FQDN解析表格E11，地址響應(yīng)單元E12以及FQDN響應(yīng)單元13。
該地址/FQND解析表格E11涉及到何時地址響應(yīng)單元E12及FQDN響應(yīng)單元E13對正接收的地址解析請求及FQDN解析請求進行響應(yīng)，并且它包括兩部分地址解析表格108，這是“FQDN→IP地址”的轉(zhuǎn)換表格以及FQDN解析表格109，這是“IP地址→FQDN”的轉(zhuǎn)換表格。
圖22為地址/FQDN解析表格E11的一個例子。該地址/FQDN解析表格E11包括兩個表格地址解析表格108以及FQDN解析表格109。該地址/FQDN解析表格E11的一個特征就是對于地址解析表格108中的各個FQDN來說都存在多個解析的IP地址而FQDN解析表格109中對于一個IP地址來說只能解析一個FQDN。
這時，可以使用FQDN作為內(nèi)容組的標識符能夠使得服務(wù)器負載平衡裝置C3通過解析來自目的IP地址的FQDN以及從客戶端D2接收到的信息包的目的端口號來識別被請求的內(nèi)容組。進一步，可以通過解析來自FQDN的IP地址來獲得關(guān)于FQDN的候選服務(wù)器列表。也就是，只有通過對IP報頭以及傳輸層(UDP/TCP)報頭進行分析才能對被請求的內(nèi)容組進行識別，并且也不需要進一步對上層的信息進行分析。
為了回答來自另一個節(jié)點的地址解析請求，地址響應(yīng)單元E12以包括在請求消息中的FQDN作為密鑰來對地址/FQDN解析表格進行查詢并返回解析后的IP。
為了回答來自另一個節(jié)點的FQDN解析請求，F(xiàn)QDN響應(yīng)單元E13以包括在請求消息中的IP地址作為密鑰來對地址/FQDN解析表格進行查詢并返回解析后的FQDN。
在該實施例中，參照圖23對客戶端D2發(fā)送獲得內(nèi)容請求的操作進行詳細描述。
請求發(fā)送單元D11從所期望內(nèi)容的URL中提取FQDN部分(圖23中的步驟S701)。例如，假設(shè)URL為“http//aaa.com/pict.jpg7070”，則相應(yīng)的FQDN部分就是“aaa.com”。
接下來，通過地址解析單元D12對相當(dāng)于被提取出來的FQDN的IP地址進行解析(步驟S702)。這里，地址解析單元D12向以FQDN作為密鑰的DNS服務(wù)器E1發(fā)出一個地址解析請求。
最后，由請求發(fā)送單元D11發(fā)送相當(dāng)于內(nèi)容的請求信息包，該信息包具有被確定為目的IP地址的解析后IP地址(步驟S703)。
在該實施例中，參照圖24對服務(wù)器負載平衡裝置C3接收來自客戶端D2的信息包的操作進行詳細描述。
由信息包接收單元C25對接收到的信息包的目的端口號進行分析并檢查分析后的目的端口號是否同預(yù)定的值相同(圖24中的步驟S801)。
作為步驟S801的結(jié)果，若與預(yù)定值不同，則信息包接收單元C25將該接收到的信息包作為一般的信息包來進行處理(步驟S803)。也就是說，作為服務(wù)器負載平衡裝置的操作就不會進行。
作為步驟S801的結(jié)果，若與預(yù)定值相同，則信息包接收單元C25檢測在信息包路徑表格C21中是否存在一個與接收到的信息包的目的IP地址/目的端口號相對應(yīng)的項目(步驟S802)。
作為步驟S802的結(jié)果，若存在該項目，則信息包接收單元C25在信息包路徑表格C21的項目中查詢目的服務(wù)器IP地址(步驟S804)。
這時，由該信息包路徑表格C21返回相應(yīng)于接收到信息包目的IP地址/端口號的目的服務(wù)器的IP地址。這里，若注冊了多個目的服務(wù)器IP地址，則信息包路徑表格C21通過使用如上所述的散列功能、采用同相同內(nèi)容服務(wù)器建立相同連接返回目的服務(wù)器的IP地址。
在接收到來自信息包路徑表格C21的目的服務(wù)器IP地址時，由信息包接收單元C25將接收到的信息包的目的地址重新寫入到目的服務(wù)器IP地址中并向其發(fā)送該接收到的信息包(步驟S805)。
作為步驟S802的結(jié)果，若不存在該項目，由信息包接收單元C25將該接收到的信息包本身傳送至最開始的目的IP地址，而不需要改變接收到的信息包的目的IP地址(步驟S806)。進一步，還為具有相同目的IP地址/目的端口號的信息包確定最優(yōu)目的服務(wù)器并將該項目重新寫入到信息包路徑表格C21中(步驟S807)。在步驟S806之后，直到在步驟S807中將目的服務(wù)器寫入到表格C21中，即使接收到了具有相同目的IP地址/目的端口號的信息包，該信息包接收單元C25也會將信息包本身傳送給最開始的IP地址。
圖25為詳細說明步驟S807中操作的流程圖。
該目的服務(wù)器確定單元C22通過FQDN解析單元C23對用于接收到的信息包的目的IP地址的FQDN進行解析(圖25中的步驟S901)。這時，由FQDN解析單元C23向以上述IP地址作為密鑰的DNS服務(wù)器E1發(fā)出一個FQDN解析請求并接收回應(yīng)。
在步驟S901中解析FQDN時，由目的服務(wù)器確定單元C22通過使用在步驟S901中解析的FQDN以及信息包的目的端口號重新生成一個FQDN，并解析IP地址用于最近重新生成的FQDN(步驟S902)。這里，該最近重新生成的FQDN必須對于信息包目的IP地址以及目的端口號的組合來說是唯一的。例如，若解析的FQDN為“aaa.com”并且信息包的目的端口號為“7070”，則目的服務(wù)器確定單元C22對相當(dāng)于FQDN“port7070.aaa.com”的IP地址進行解析。
在步驟S902中，雖然在步驟S901中解析的FQDN以及信息包的目的端口號被用來生成一個新的FQDN并且該重新生成的FQDN被用作解析DNS服務(wù)器中IP地址的密鑰，可是還存在一種使用在步驟S901中解析的FQDN作為密鑰的方法。在這種情況下，在步驟S901中解析的FQDN本身對于被請求的內(nèi)容組來說必須是唯一的。因此，需要確定一個對于由服務(wù)器負載平衡裝置C3接收到的信息包目的IP地址中的每個內(nèi)容組都是唯一的數(shù)值。進一步，在這種情況下，在信息包路徑表格中21中，只能根據(jù)目的IP地址對目的服務(wù)器的IP地址進行注冊，而不是根據(jù)目的IP地址/目的端口號的組合。
該目的服務(wù)器確定單元C22從相應(yīng)于步驟S902解析的IP地址的服務(wù)器中確定一個目的服務(wù)器(步驟S903)。用于確定目的服務(wù)器的詳細操作同第二實施例中的相同，并在這里省略掉對它的描述。
若確定了目的服務(wù)器，則由目的服務(wù)器確定單元C22將確定服務(wù)器的IP地址寫入到信息包路徑表格中(步驟S904)。
下面將對該實施例的有益效果進行描述。
在該實施例中，服務(wù)負載平衡裝置通過使用DNS服務(wù)器，根據(jù)信息包的目的IP地址/目的端口號對被請求內(nèi)容所屬的內(nèi)容組進行識別，并且將該信息包傳送給內(nèi)容組中的最優(yōu)內(nèi)容服務(wù)器。常用的服務(wù)器負載平衡裝置必須對來自客戶端的信息包內(nèi)容進行分析并識別哪些內(nèi)容是被請求的。換句話說，常用的服務(wù)器負載平衡裝置必須使用7層轉(zhuǎn)換?？墒潜緦嵤├械姆?wù)器負載平衡裝置只需檢查信息包的目的IP地址和目的端口號就能識別出別請求的內(nèi)容。因此，這只需要使用4層轉(zhuǎn)換就能實現(xiàn)。一般的，7層轉(zhuǎn)換的處理量例如每秒鐘的連接數(shù)目較低而且其成本會更貴。如果使用該實施例的4層轉(zhuǎn)換來實現(xiàn)相同的功能，則從增強處理量和降低成本的角度來說是很有效的。
不需要指出的是該第五實施例能夠同上面提到的第一實施例中的內(nèi)容管理裝置組合在一塊。在這種情況下，代替URL組的是，將端口號設(shè)置在如圖2所示的分類策略表格中。圖3中分組后的目錄路徑可以用增加端口號的路徑來代替，“/cgi/high-load/z.exe7070”。
在下文中，將參照附圖對本發(fā)明的具體例子進行描述。
參照附圖對本發(fā)明的第一個具體實例進行描述。該例子對應(yīng)于第二實施例。
參照圖7，該例子由一個網(wǎng)絡(luò)實現(xiàn)，該網(wǎng)絡(luò)包括內(nèi)容服務(wù)器A2、服務(wù)器負載平衡裝置C1以及客戶端D1。
在圖8的目的服務(wù)器確定策略表格103中指出來的各種策略被設(shè)置在服務(wù)器負載平衡裝置C1的目的服務(wù)器確定策略設(shè)置單元C12中。在初始的狀態(tài)下，沒有項目注冊在請求路徑表格C14中。
客戶端D1將用于獲得被識別為URL“http//www.aaa.com/file/small/pict.gif”內(nèi)容的請求發(fā)送給一個服務(wù)器。
服務(wù)器負載平衡裝置C1接收請求并對請求的URL進行分析。參照請求路徑表格C14，將該請求傳送給默認內(nèi)容服務(wù)器，這是由于沒有對應(yīng)于上述URL的項目。由DNS服務(wù)器從URL“www.aaa.com”的FQDN部分解析出來的IP地址被視為默認內(nèi)容服務(wù)器。
在傳送完該請求之后，服務(wù)器負載平衡裝置C1盡量在請求路徑表格C14中生成一個相應(yīng)于URL所屬內(nèi)容組的目的服務(wù)器項目。
該目的服務(wù)確定單元C13對用于管理內(nèi)容服務(wù)器A2的內(nèi)容管理裝置進行查詢以便于獲得一個內(nèi)容組和對于URL的候選服務(wù)器列表。
在接收到給查詢時，該內(nèi)容管理裝置回答對應(yīng)于URL的內(nèi)容組具有文件特征，它被URL前綴識別為“http//www.aaa.com/file/small/*”，并且該候選服務(wù)器列表包括三部分“10.1.1.1”、“10.2.2.2”以及“10.3.3.3”。
作為獲得對應(yīng)于URL的候選服務(wù)器列表的另一種方法，該FQDN例如“small.file.www，aaa.com”可以從URL中生成，并且可以在DNS服務(wù)器中查詢以FQDN作為密鑰的相應(yīng)IP地址列表。在該例中，該DNS服務(wù)器回應(yīng)對應(yīng)于上述FQDN的IP地址包括三部分“10.1.1.1”、“10.2.2.2”以及“10.3.3.3”。
該目的服務(wù)器確定單元C13參照目的服務(wù)器確定策略設(shè)置單元C12檢測對應(yīng)于內(nèi)容組的目的服務(wù)器確定策略，并且獲得一個策略，該策略在對具有文件特性的內(nèi)容組進行內(nèi)容獲取時使用該傳送處理量，并以具有上述處理量最大值的服務(wù)器作為參照，選擇具有60％或更高參照值的服務(wù)器作為目的服務(wù)器。
為了根據(jù)獲得的策略測量來自各個候選服務(wù)器的傳送處理量，該目的服務(wù)器確定單元C13在請求路徑表格C14中注冊三個IP地址“10.1.1.1”、“10.2.2.2”以及“10.3.3.3”作為具有URL前綴“http//www.aaa.com/file/small/*”請求的目的服務(wù)器。在注冊之后，相應(yīng)于上述來自客戶端URL前綴的各個請求將被以循環(huán)的方式(round robin method)傳送給三個服務(wù)器。
為了回應(yīng)以循環(huán)的方式傳送給三個服務(wù)器的各個請求，由內(nèi)容接收/傳送單元C17接收來自內(nèi)容服務(wù)器的響應(yīng)內(nèi)容。該資源獲得單元C11通過內(nèi)容接收/發(fā)送單元C17獲得該響應(yīng)內(nèi)容的傳送處理量，并將獲得的信息傳輸給目的服務(wù)器確定單元C13。這里，假設(shè)對應(yīng)于“10.1.1.1”、“10.2.2.2”以及“10.3.3.3”的各個傳送處理量分別為1Mbps、7Mbps以及10Mbps。由于該策略就是以具有最大值的服務(wù)器作為參照，選擇具有60％或更多參照值的服務(wù)器來作為目的服務(wù)器，目的服務(wù)器確定單元C13確定相應(yīng)于“10.2.2.2”及“10.3.3.3”的兩個服務(wù)器作為目的服務(wù)器。進一步，將請求路徑表格C14中相應(yīng)于具有URL前綴“http//www.aaa.com/file/small/*”請求的目的服務(wù)器重新寫入到上述的兩個“10.2.2.2”及“10.3.3.3”中。接著，相應(yīng)于上述URL前綴的各個請求被以循環(huán)的方式傳輸給兩個服務(wù)器。
下面將參照附圖對本發(fā)明的第二個具體實例進行描述。該例子對應(yīng)于第三實施例。
參照圖26，該實例包括內(nèi)容服務(wù)器201以及服務(wù)器負載平衡裝置301至306。該內(nèi)容服務(wù)器具有同第三實施例中的內(nèi)容服務(wù)器A3相同的結(jié)構(gòu)，并且服務(wù)器負載平衡裝置301至306分別具有同服務(wù)器負載平衡裝置C1相同的結(jié)構(gòu)。
圖14的資源響應(yīng)策略表格105中所示的資源響應(yīng)策略被設(shè)置在內(nèi)容服務(wù)器201中。這里，假設(shè)當(dāng)前的CPU負載為內(nèi)容服務(wù)器201的25％。
為了確定服務(wù)器負載平衡裝置301至306中的目的服務(wù)器，假設(shè)各個服務(wù)器負載平衡裝置都立刻向內(nèi)容服務(wù)器201發(fā)出了獲得CPU負載資源的請求。
由于當(dāng)前CPU負載位于0％至30％的范圍之內(nèi)，因此對于來自第一服務(wù)器負載平衡裝置301至304的用于獲得資源的請求來說，該內(nèi)容服務(wù)器201有70％的可能返回實際CPU負載并有30％的可能返回實際CPU負載的兩倍。這里假設(shè)向服務(wù)器負載平衡裝置301至304返回實際CPU負載的25％并向服務(wù)器負載平衡裝置305至306返回實際CPU負載兩倍的50％。
若內(nèi)容服務(wù)器201向服務(wù)器負載平衡裝置301至306返回實際CPU負載的25％，由于判斷出內(nèi)容服務(wù)器201的CPU負載足夠低并且可能出現(xiàn)隨著快速增長的請求而出現(xiàn)的負載迅速增長的情況，因此所有的服務(wù)器負載平衡裝置都可以確定內(nèi)容服務(wù)器201作為目的服務(wù)器。但是在該例子中，服務(wù)器負載平衡裝置305和306判斷出內(nèi)容服務(wù)器201的CPU負載并不夠低，因此確定除了內(nèi)容服務(wù)器201以外的另一個內(nèi)容服務(wù)器作為目的服務(wù)器。因此，可以限制內(nèi)容服務(wù)器201中負載的快速增長。
下面將參照附圖對本發(fā)明的第三個具體實例進行描述。該例子對應(yīng)于第四實施例。
參照圖27，該實例包括內(nèi)容服務(wù)器202及203以及服務(wù)器負載平衡裝置307。該內(nèi)容服務(wù)器202及203分別具有同第四實施例中的內(nèi)容服務(wù)器A2相同的結(jié)構(gòu)，并服務(wù)器負載平衡裝置307具有同服務(wù)器負載平衡裝置C2相同的結(jié)構(gòu)。
在如圖28的表格110所示的服務(wù)器負載平衡裝置307中的請求路徑表格中，假設(shè)有兩個對應(yīng)于“ftp//ftp.ccc.edu/pub/*”的目的服務(wù)器IP地址“10.5.1.1”(對應(yīng)于內(nèi)容服務(wù)器202)以及“10.6.1.1”(對應(yīng)于內(nèi)容服務(wù)器203)，并且加權(quán)數(shù)值分別為90％和10％。
根據(jù)來自各個服務(wù)器的傳送處理量比率對權(quán)數(shù)進行重置，直到具有最大處理量服務(wù)器的傳送處理量小于具有最小處理量服務(wù)器的傳送處理量的兩倍。這里，假設(shè)內(nèi)容服務(wù)器202及203的處理量分別為1Mbps及9Mbps。假設(shè)“移動粒度＝1.0”，各個服務(wù)器的加權(quán)數(shù)值被重置為90％→10％以及10％→90％。在對權(quán)數(shù)進行重置之后，對各個服務(wù)器的請求傳送比率被改變了并且在下次測量傳送處理量時假設(shè)各個處理量為9Mbps及1Mbps。接著，該權(quán)數(shù)又被重置為初始值例如10％→90％以及90％→10％。該權(quán)數(shù)改變操作以及擺動的遞歸循環(huán)表示移動粒度y太大了。
因此，在該例子中考慮“移動粒度＝0.5”的情況。假設(shè)內(nèi)容服務(wù)器202及203的處理量分別為1Mbps及9Mbps，各個服務(wù)器加權(quán)數(shù)值的波動數(shù)量為移動粒度＝1.0時的一半，并且權(quán)數(shù)被重置為90％→50％以及10％→50％。在對權(quán)數(shù)進行重置之后，對于各個服務(wù)器傳送請求的比率發(fā)生了變化并在下次測量傳送處理量時假設(shè)各個處理量為7Mbps及3Mbps。類似的，各個權(quán)數(shù)值被重置為50％→60％以及50％→40％。在對權(quán)數(shù)進行重置之后，各個服務(wù)器的傳送處理量分別變?yōu)?Mbps及4Mbps，由于具有最大傳送處理量服務(wù)器的傳送處理量小于具有最小處理量服務(wù)器的傳送處理量的兩倍，因此結(jié)束權(quán)數(shù)改變操作。這樣，為了不在改變權(quán)數(shù)的操作中發(fā)生擺動現(xiàn)象，為移動粒度確定一個合適的數(shù)值是很重要的。
下面將參照附圖對本發(fā)明的第四個具體實例進行描述。該例子對應(yīng)于第五實施例。
參照圖20，該例子由一個網(wǎng)絡(luò)實現(xiàn)，該網(wǎng)絡(luò)包括內(nèi)容服務(wù)器A4、服務(wù)器負載平衡裝置C3、客戶端D2以及DNS服務(wù)器E1。
圖22中所示的地址解析表格108以及FQDN解析表格109都被注冊在DNS服務(wù)器E1中。
在初始階段，服務(wù)器負載平衡裝置C3的信息包路徑表格C21中并沒有注冊任何項目。
由客戶端D2向一個服務(wù)器發(fā)出用于獲得被識別為URL“http//www.aaa/pict.jpg7070”內(nèi)容的請求。這里，地址解析請求被發(fā)送給以URL“aaa.com”的FQDN部分作為密鑰的DNS服務(wù)器E1。DNS服務(wù)器E1返回相應(yīng)的IP地址“10.1.1.1”。客戶端D2將解析后的地址“10.1.1.1”作為目的IP地址并以具有URL中指出的目的端口號7070的信息包的形式發(fā)出請求。
該服務(wù)器負載平衡裝置C3接收來自客戶端D2的信息包，并參照信息包路徑表格C21將具有預(yù)定目的端口號的信息包傳送給一個目的服務(wù)器IP地址。在這種情況下，“7070”為預(yù)定目的端口號，并且對該信息包路徑表格C21進行檢查其結(jié)果就是其中沒有發(fā)現(xiàn)已注冊的項目，并因此將該信息包傳送給初始目的IP地址。
在傳送信息包之后，服務(wù)器負載平衡裝置C3在信息包路徑表格中生成一個相應(yīng)信息包內(nèi)容組中的目的服務(wù)器項目。即使接收到的信息包具有同上述信息包相同的目的IP地址/目的端口號，也會將該信息包傳輸給初始目的IP地址，直到生成一個目的服務(wù)器項目。
下面參照圖29對在信息包路徑表格C21中為相應(yīng)于信息包的內(nèi)容組生成一個目的服務(wù)器項目的例子進行說明?？蛻舳薉2以信息包的形式發(fā)出請求，該信息包中包括如上面的URL所指定的目的IP地址“10.1.1.1”和目的端口號“7070”。
服務(wù)器負載平衡裝置C3的目的服務(wù)器確定單元C22請求FQDN解析單元C23對以信息包的目的IP地址“10.1.1.1”為密鑰的DNS服務(wù)器E1進行FQDN解析。
在接收到該請求時，DNS服務(wù)器E1的FQDN響應(yīng)單元E13對“10.1.1.1”的回答為FQDN“aaa.com”。
目的服務(wù)器確定單元C22請求地址解析單元C24對以FQDN“port7070.aaa.com”為密鑰的DNS服務(wù)器E1進行地址解析。上述FQDN由目的端口號“7070”信息加上從DNS服務(wù)器E1返回的FQDN“aaa.com”構(gòu)成。最近剛生成的FQDN必須對于信息包的目的IP地址和目的端口號來說都是唯一的，并在另一個例子中也可以使用“7070.port.aaa.com”。相應(yīng)于要生成的FQDN的項目必須被注冊在DNS服務(wù)器E1中。
在接收到請求時，DNS服務(wù)器E1的地址響應(yīng)單元E12回答相應(yīng)于“port.7070.aaa.com”的三個地址“10.1.1.1”、“20.2.2.2”以及“30.3.3.3”。
因此，目的服務(wù)器確定單元C22就知道了目的IP地址/目的端口號“10.1.1.1/7070”的信息包具有三個候選服務(wù)器目的IP地址“10.1.1.1”、“20.2.2.2”以及“30.3.3.3”。
由目的服務(wù)器確定單元C22從候選服務(wù)器中確定一個注冊在信息包路徑表格中的目的服務(wù)器。這里，假設(shè)將在CPU負載的增序中選擇兩個服務(wù)器的策略設(shè)置為目的服務(wù)器的確定策略，并且作為查詢各個服務(wù)器的結(jié)果，相應(yīng)于“10.1.1.1”、“20.2.2.2”以及“30.3.3.3”的服務(wù)器CPU負載分別為80％、30％以及50％。
結(jié)果，對于目的IP地址/目的端口號為“10.1.1.1/7070”的信息包來說，目的服務(wù)器確定單元C22確定對應(yīng)于“20.2.2.2”以及“30.3.3.3”的服務(wù)器為目的服務(wù)器，并將上述部分都注冊到信息包路徑表格C21中(參照圖21中的信息包路徑表格107)。
在將項目注冊到信息包路徑表格C21中之后，重新將具有目的IP地址/目的端口號“10.1.1.1/7070”的信息包傳輸給IP地址為“20.2.2.2”或“30.3.3.3”的服務(wù)器。
在上述各個實施例的服務(wù)器負載平衡系統(tǒng)中，不需要說明的是服務(wù)器負載平衡裝置C1至C3中目的服務(wù)器確定策略設(shè)置單元C12、目的服務(wù)器確定單元C13及C22、FQDN解析單元C23以及地址解析單元C24的功能、內(nèi)容管理裝置B1中內(nèi)容分類單元B12以及內(nèi)容分組單元B13的功能、內(nèi)容服務(wù)器A1至A4中資源響應(yīng)單元A13及A15以及資源響應(yīng)策略設(shè)置單元A14的功能以及其它功能都可以由硬件來實現(xiàn)，并且內(nèi)容發(fā)送管理程序A39、內(nèi)容管理程序B19、服務(wù)器負載平衡程序C29、C49以及具有各種功能的D59都可以被載入到一臺計算機的存儲器中，并因此實現(xiàn)上述的系統(tǒng)。該內(nèi)容發(fā)送管理程序A39、內(nèi)容管理程序B19、以及服務(wù)器負載平衡程序C29、C49及D59都被存儲在存儲介質(zhì)中例如磁盤和半導(dǎo)體存儲器。它們被從存儲介質(zhì)中載入到計算機中來控制計算機的操作并因此實現(xiàn)上述的功能。
如上文所述，參照優(yōu)選實施例和例子對本發(fā)明進行了描述，可是本發(fā)明并不僅限于上述的實施例和例子，在本發(fā)明的范疇和精神之內(nèi)可以進行各種修改。
如上所述，根據(jù)本發(fā)明可以實現(xiàn)以下有益效果。
第一，并不需要人工將內(nèi)容服務(wù)器中的內(nèi)容分類及分組為多個有相同特征的內(nèi)容。
這是由于在內(nèi)容管理裝置中設(shè)置了將內(nèi)容分類/分組為相同內(nèi)容的策略，并因此能夠根據(jù)內(nèi)容服務(wù)器中內(nèi)容的靜態(tài)/動態(tài)特征自動對其進行自動分組。
第二，在服務(wù)器負載平衡裝置中，根據(jù)內(nèi)容特征的最優(yōu)化請求路徑可以通過最小項目號碼來實現(xiàn)。
這是由于該內(nèi)容管理裝置能夠根據(jù)其中的靜態(tài)/動態(tài)特征自動對內(nèi)容服務(wù)器中的內(nèi)容進行分組以及分類。
第三，經(jīng)過服務(wù)器負載平衡裝置，來自客戶端的請求可以根據(jù)被請求內(nèi)容的特征而被傳送給最優(yōu)服務(wù)器。
這是由于服務(wù)器負載平衡裝置根據(jù)取決于各個特征的選擇標準來為各個內(nèi)容組確定一個目的服務(wù)器，將確定的目的服務(wù)器注冊到請求路徑表格中并識別哪個內(nèi)容組中包括來自客戶端的請求內(nèi)容，因此將該請求傳送給相應(yīng)內(nèi)容組的目的服務(wù)器。
第四，可以限制客戶端向內(nèi)容服務(wù)器發(fā)送請求的快速增長并防止目的服務(wù)器確定操作中出現(xiàn)擺動的情況，而不需要集中在服務(wù)器負載平衡裝置的請求路徑表格中。
這是首先由于在響應(yīng)來自多個服務(wù)器負載平衡裝置的用于獲得資源信息的請求時(其中這些裝置位于內(nèi)容服務(wù)器的一個網(wǎng)絡(luò)中)，并不總是返回實際資源信息而是返回根據(jù)設(shè)置資源響應(yīng)策略校正過的資源值，因此，可以限制服多個服務(wù)器負載平衡裝置同時選擇相同的內(nèi)容服務(wù)器作為目的服務(wù)器。
其次由于在服務(wù)器負載平衡裝置中，根據(jù)獲得的資源數(shù)值對各個項目目的服務(wù)器的加權(quán)數(shù)值進行改變，并利用移動粒度使得加權(quán)數(shù)值平緩的變化，因此能夠限制服多個服務(wù)器負載平衡裝置同時選擇相同的內(nèi)容服務(wù)器作為目的服務(wù)器。
再次由于在服務(wù)器負載平衡裝置中，并不是根據(jù)獲得的資源數(shù)值立即對用于各個項目目的服務(wù)器的加權(quán)數(shù)值進行重置，而是由隨概率分布的時間延遲重置加權(quán)數(shù)值的時間，并且如果需要的話，可以在延遲的時間對加權(quán)數(shù)值進行重置，因此，可以限制服多個服務(wù)器負載平衡裝置同時選擇相同的內(nèi)容服務(wù)器作為目的服務(wù)器。
第五，服務(wù)器負載平衡裝置能夠使用4層轉(zhuǎn)換來從客戶端向最優(yōu)內(nèi)容服務(wù)器引導(dǎo)請求而不需要使用7層轉(zhuǎn)換，因此能夠改進服務(wù)器負載平衡裝置的性能以及降低成本。
這是由于在服務(wù)器負載平衡裝置中，通過使用DNS服務(wù)器，從來自客戶端信息包的目的IP地址/目的端口號中識別出含有被請求內(nèi)容的內(nèi)容組，并將該信息包傳送給相應(yīng)內(nèi)容組的最優(yōu)內(nèi)容服務(wù)器，因此能夠越過對從來自客戶端信息包的內(nèi)容(URL等等)的分析。
雖然參照典型的實施例對本發(fā)明進行了說明，但是對于本領(lǐng)域內(nèi)的技術(shù)人員來說可以理解的是，在不脫離本發(fā)明的精神和范疇的情況下，上述的以及多種其它的變化、刪節(jié)以及增補都是可以進行的。因此，本發(fā)明不應(yīng)被理解為僅限于上述的特定實施例而是應(yīng)該包括在含有及等同于附加的權(quán)利要求列出的特征范圍內(nèi)能實現(xiàn)的所有可能的實施例。
權(quán)利要求
1.一種用于向多個內(nèi)容服務(wù)器中的一個客戶端分配內(nèi)容發(fā)送的服務(wù)器負載平衡系統(tǒng)，包括用于確定所述內(nèi)容服務(wù)器的裝置，通過至少使用關(guān)于該內(nèi)容服務(wù)器的內(nèi)容和資源信息特性而將來自客戶端的內(nèi)容傳送請求目的地傳輸給該內(nèi)容服務(wù)器。
2.如權(quán)利要求1所給出的服務(wù)器負載平衡系統(tǒng)，其特征在于根據(jù)所述資源信息的變化再次確定向其傳送來自所述客戶端的內(nèi)容傳送請求的所述內(nèi)容服務(wù)器。
3.如權(quán)利要求1所給出的服務(wù)器負載平衡系統(tǒng)，其特征在于所述來自客戶端的內(nèi)容傳送請求被發(fā)送到所述內(nèi)容傳送請求將被發(fā)送到的所述內(nèi)容服務(wù)器，所述內(nèi)容服務(wù)器為所述內(nèi)容而設(shè)置。
4.如權(quán)利要求1所給出的服務(wù)器負載平衡系統(tǒng)，其特征在于基于來自所述客戶端的信息包的目的IP地址以及目的端口號，該由客戶端請求的內(nèi)容被確認并且將該信息包發(fā)送到為所述內(nèi)容設(shè)置的所述內(nèi)容服務(wù)器中。
5.如權(quán)利要求1所給出的服務(wù)器負載平衡系統(tǒng)，其特征在于所述內(nèi)容服務(wù)器傳送的內(nèi)容根據(jù)其特性被分成若干組，并且分成上述組的所述內(nèi)容被收集在一塊并分到每一組中。
6.用于從多個內(nèi)容服務(wù)器中選擇一個傳送內(nèi)容到客戶端的內(nèi)容服務(wù)器的服務(wù)器負載平衡裝置，包括通過至少使用所述內(nèi)容的特性和關(guān)于所述內(nèi)容服務(wù)器的資源信息而確定將來自客戶端的內(nèi)容傳送請求傳輸給所述內(nèi)容服務(wù)器的裝置。
7.如權(quán)利要求6所給出的服務(wù)器負載平衡裝置，其特征在于所述資源信息至少包括一個或多個資源參數(shù)，通過使用第一資源參數(shù)來預(yù)測或提取與第一資源參數(shù)不同的第二資源參數(shù)，并且該資源信息也包括預(yù)測或提取出的所述第二資源參數(shù)。
8.如權(quán)利要求6所給出的服務(wù)器負載平衡裝置，其特征在于所述目的服務(wù)器確定裝置通過使用客戶端所請求內(nèi)容的URL或部分URL來獲得用于所述請求目的地的候選內(nèi)容服務(wù)器，并且從所述候選內(nèi)容服務(wù)器中確定向其傳送內(nèi)容的內(nèi)容服務(wù)器。
9.如權(quán)利要求8所給出的服務(wù)器負載平衡裝置，其特征在于所述部分URL是URL的詞頭即URL的報頭部分或者URL中文件的擴展名再或者是兩者的結(jié)合。
10.如權(quán)利要求6所給出的服務(wù)器負載平衡裝置，其特征在于通過對存在于所述網(wǎng)絡(luò)或用于管理所述內(nèi)容服務(wù)器中的內(nèi)容的內(nèi)容管理裝置中的所述內(nèi)容服務(wù)器進行查詢，該目的服務(wù)器確定裝置獲得用來傳送客戶端請求內(nèi)容的所述候選內(nèi)容服務(wù)器。
11.如權(quán)利要求6所給出的服務(wù)器負載平衡裝置，其特征在于通過對存在于所述網(wǎng)絡(luò)或用于管理所述內(nèi)容服務(wù)器中的內(nèi)容的內(nèi)容管理裝置中的所述內(nèi)容服務(wù)器進行查詢，所述目的服務(wù)器確定裝置獲取所述客戶端的特性。
12.如權(quán)利要求6所給出的服務(wù)器負載平衡裝置，其特征在于所述目的服務(wù)器確定裝置通過使用將由所述請求獲得內(nèi)容的URL或者URL的一部分生成FQDN，獲得一個用于該FQDN的IP地址列表，其中FQDN作為密鑰，并且將相應(yīng)于所述列表中每一IP地址的內(nèi)容服務(wù)器規(guī)定為所述候選服務(wù)器，用于傳送由客戶端請求的所述內(nèi)容。
13.如權(quán)利要求12所給出的服務(wù)器負載平衡裝置，其特征在于從DNS服務(wù)器獲得所述用于所述FQDN的所述IP地址列表。
14.如權(quán)利要求6所給出的服務(wù)器負載平衡裝置，其特征在于在將一個信息包的目的IP地址改變?yōu)閮?nèi)容服務(wù)器的IP地址之后，其中的內(nèi)容服務(wù)器被確定作為向客戶端傳送內(nèi)容的內(nèi)容服務(wù)器，所述由客戶端發(fā)送的、用來請求內(nèi)容傳送的信息包被傳輸?shù)剿鰞?nèi)容服務(wù)器。
15.如權(quán)利要求6所給出的服務(wù)器負載平衡裝置，其特征在于在解析了相應(yīng)于所述內(nèi)容服務(wù)器IP地址的MAC地址之后，其中的內(nèi)容服務(wù)器被確定作為向客戶端傳送內(nèi)容并將所述信息包的MAC地址改變?yōu)榻馕龊蟮腗AC地址的內(nèi)容服務(wù)器，所述由客戶端發(fā)送的、用來請求內(nèi)容傳送的信息包被傳輸?shù)剿鰞?nèi)容服務(wù)器。
16.如權(quán)利要求6所給出的服務(wù)器負載平衡裝置，其特征在于根據(jù)所述資源信息的變化，重新確定向其傳送由客戶端接收的所述內(nèi)容發(fā)送請求的所述內(nèi)容服務(wù)器。
17.如權(quán)利要求6所給出的服務(wù)器負載平衡裝置，其特征在于通過至少使用所述內(nèi)容的特性以及資源信息，優(yōu)先級別被設(shè)置在向其傳送由客戶端接收的所述內(nèi)容發(fā)送請求的各個內(nèi)容服務(wù)器中。
18.如權(quán)利要求17所給出的服務(wù)器負載平衡裝置，其特征在于根據(jù)所述資源信息的變化重新設(shè)置優(yōu)先級別。
19.如權(quán)利要求18所給出的服務(wù)器負載平衡裝置，其特征在于考慮到當(dāng)前的優(yōu)先級別，在根據(jù)各個內(nèi)容服務(wù)器的資源信息重新設(shè)置優(yōu)先級別之前，來自當(dāng)前優(yōu)先級別的波動被限制為一個常數(shù)級別，并接下來重新對優(yōu)先級別進行設(shè)置。
20.如權(quán)利要求6所給出的服務(wù)器負載平衡裝置，其特征在于所述重新設(shè)置優(yōu)先級別的時間被延遲了一段隨著概率變化的時間，并在該延遲時間重新設(shè)置優(yōu)先級別。
21.如權(quán)利要求20所給出的服務(wù)器負載平衡裝置，其特征在于在所述延遲時間，重新判斷是否重新設(shè)置優(yōu)先級別，并且當(dāng)確定重新設(shè)置所述優(yōu)先級別時，重新對優(yōu)先級別進行設(shè)置。
22.如權(quán)利要求6所給出的服務(wù)器負載平衡裝置，包括用來確定向客戶端發(fā)送內(nèi)容的內(nèi)容服務(wù)器的裝置，這是基于從客戶端接收到的、用來請求內(nèi)容傳送的信息包的目的IP地址以及目的端口號，并且將接收到的用來請求所述內(nèi)容發(fā)送的信息包傳輸?shù)剿龃_定的內(nèi)容服務(wù)器，其中FQDN唯一指示目的IP地址以及目的端口號，并通過使用接收到的信息包的目的IP地址以及目的端口號的信息來重新生成，候選內(nèi)容服務(wù)器用來將內(nèi)容發(fā)送到客戶端，該服務(wù)器是接收到的信息包的傳遞目的地并通過對使用重新生成的FQDN作為密鑰的DNS服務(wù)器進行查詢來獲得，以及從候選內(nèi)容服務(wù)器中確定用來向客戶端發(fā)送內(nèi)容的所述內(nèi)容服務(wù)器。
23.如權(quán)利要求22所給出的服務(wù)器負載平衡裝置，其特征在于通過對使用所述目的IP地址作為密鑰的所述DNS服務(wù)器進行查詢來解析所述FQDN，通過使用所述解析后FQDN以及目的端口號的信息來重新生成唯一指示所述目的端口號以及解析后FQDN的FQDN，通過對使用重新生成的FQDN作為密鑰的DNS服務(wù)器進行查詢來獲得一個IP地址列表，并將該列表定義為用來向客戶端發(fā)送內(nèi)容的候選內(nèi)容服務(wù)器，以及從所述候選內(nèi)容服務(wù)器中確定用來向客戶端發(fā)送內(nèi)容的所述內(nèi)容服務(wù)器。
24.如權(quán)利要求22所給出的服務(wù)器負載平衡裝置，其特征在于通過對使用目的IP地址作為密鑰的DNS服務(wù)器進行查詢來解析FQDN，通過對使用解析后的FQDN作為密鑰的DNS服務(wù)器進行查詢來獲得一個IP地址列表，并將該列表定義為用來向客戶端發(fā)送內(nèi)容的候選內(nèi)容服務(wù)器，以及從候選內(nèi)容服務(wù)器中確定用來向客戶端發(fā)送內(nèi)容的所述內(nèi)容服務(wù)器。
25.如權(quán)利要求22所給出的服務(wù)器負載平衡裝置，包括所述服務(wù)器負載平衡裝置進一步包括用來接收來自客戶端的請求內(nèi)容發(fā)送的信息包的信息包接收裝置，以及信息包傳輸裝置，該裝置將信息包接收裝置接收到的信息包的目的IP地址重新寫入到用于將被請求內(nèi)容發(fā)送到客戶端并傳輸?shù)剿鰞?nèi)容服務(wù)器中的內(nèi)容服務(wù)器的IP地址中。
26.如權(quán)利要求25所給出的服務(wù)器負載平衡裝置，其特征在于所述信息包傳輸裝置對相應(yīng)于用于向客戶端發(fā)送請求內(nèi)容的所述內(nèi)容服務(wù)器的IP地址的MAC地址進行解析，并且在將由信息包接收裝置接收到的請求所述內(nèi)容傳送的信息包的目的MAC重新寫入到解析后的MAC地址中之后，將該信息包傳輸給該內(nèi)容服務(wù)器。
27.一個用于傳送內(nèi)容的內(nèi)容服務(wù)器，包括向一個節(jié)點通知將一個計算后的實際資源值的校準值作為資源信息的裝置，用來基于關(guān)于各個服務(wù)器的資源信息的選擇內(nèi)容的發(fā)送目的地。
28.一個用來對由內(nèi)容服務(wù)器傳送的內(nèi)容進行管理的內(nèi)容管理裝置，包括用來根據(jù)內(nèi)容的特性將由所述內(nèi)容服務(wù)器傳送的內(nèi)容分成多個組的內(nèi)容分類裝置，以及用來在各個組中將分類到各組中的內(nèi)容集中到一塊兒的內(nèi)容分組裝置。
29.如權(quán)利要求28所給出的內(nèi)容管理裝置，其特征在于所述內(nèi)容分類裝置根據(jù)特性對所述內(nèi)容進行分類。
30.如權(quán)利要求28所給出的內(nèi)容管理裝置，其特征在于所述內(nèi)容分類裝置根據(jù)所述內(nèi)容特性的分類逐步變細粒度的分級結(jié)構(gòu)逐步對內(nèi)容進行分類。
31.如權(quán)利要求28所給出的內(nèi)容管理裝置，其特征在于所述內(nèi)容分組裝置將同一目錄下的已分類內(nèi)容一塊兒集中到相同的組中。
32.一個用來通過控制一臺計算機，分配內(nèi)容發(fā)送到多個內(nèi)容服務(wù)器中的客戶端的服務(wù)器負載平衡程序，包括一個涉及具有內(nèi)容特性與有關(guān)內(nèi)容服務(wù)器的資源信息之間對應(yīng)關(guān)系的所述內(nèi)容服務(wù)器的選擇標準的功能，以及一個根據(jù)所述請求內(nèi)容的特性以及資源信息、基于所述選擇標準確定用來發(fā)送客戶端請求內(nèi)容的內(nèi)容服務(wù)器的功能。
33.一個用來通過控制一臺計算機，管理傳送內(nèi)容的內(nèi)容服務(wù)器的內(nèi)容傳送的內(nèi)容發(fā)送管理程序，包括一個向一個節(jié)點通知將一個計算后實際資源值的校準值作為在這一點的可用資源信息的功能，并用來根據(jù)服務(wù)器的資源選擇內(nèi)容的傳送目的地。
34.一個用來通過控制一臺計算機，對內(nèi)容服務(wù)器傳送的內(nèi)容進行管理的內(nèi)容管理程序，包含一個用來根據(jù)所述內(nèi)容的特性將內(nèi)容服務(wù)器傳送的內(nèi)容分成多個組的內(nèi)容分類功能，以及一個用來在各個組中將分到各組中內(nèi)容集中一塊兒的內(nèi)容分組功能。
全文摘要
一種用于向多個內(nèi)容服務(wù)器中的一個客戶端分配內(nèi)容發(fā)送的服務(wù)器負載平衡系統(tǒng)，包括一個目的服務(wù)器確定策略設(shè)置單元，用來為了確定用于對各個內(nèi)容特性傳送內(nèi)容的內(nèi)容服務(wù)器而設(shè)置選擇標準，以及一個目的服務(wù)器確定單元，用來根據(jù)所請求內(nèi)容的特性所對應(yīng)的選擇標準確定傳送來自客戶端的請求內(nèi)容的內(nèi)容服務(wù)器。
文檔編號G06F15/00GK1450765SQ03128628
公開日2003年10月22日 申請日期2003年3月5日 優(yōu)先權(quán)日2002年3月5日
發(fā)明者藤田范人, 巖田淳 申請人:日本電氣株式會社