網絡業務管理和負載平衡的系統和方法

專利名稱：網絡業務管理和負載平衡的系統和方法
技術領域：
本發明涉及分布計算環境中的網絡業務管理和負載平衡的系統和方法。
背景技術：
為服務諸如超文本標記語言(HTML)頁面、文本文件、圖像、音頻和視頻等的靜態文檔而初始創建了萬維網。其連接全球數百萬計用戶的容量已經引起世界變革。開發者很快意識到使用網絡服務動態內容的價值。通過向站點增加應用邏輯以及數據庫連通性，不管有多少用戶站點能夠支持與每個個體用戶的個人化交互。我們將這種站點稱為“動態站點，，或“web應用”，而把僅具有靜態文檔的站點稱為“靜態站點”。今天要看見一個完全靜態的站點是非常罕見的。現在的大多數站點都是動態的并且包含靜態內容以及動態代碼。 例如，amazon. com、eBay, com以及Myspace. com者β是眾所周知的云力態web站點(web應用) 的例子。參見圖1，靜態站點145包含web服務器150和靜態文檔160。當web瀏覽器110 通過因特網140發送請求120時，web服務器150提供相應的文檔作為對客戶端的響應130。與之相反，圖2示出了 web應用(“動態網站”)的體系結構。動態網站基礎設施 245不僅包括web服務器250 (以及相關的靜態文檔25 ，而且還包括諸如應用服務器260 以及數據庫服務器275的中間件。應用邏輯265在應用服務器260上運行，并且數據庫服務器275在應用服務器260上管理對數據觀0的訪問。為了使web應用成功，其主機基礎設施必須滿足性能、縮放性以及可獲得性的要求。“性能”是指應用對用戶交互的響應性。“縮放性”是指應用在負載需求增加情況下的執行能力。“可獲得性”是指應用交付連續不間斷服務的能力。隨著因特網用戶數量的指數增長，接入需求會更容易地排在單個服務器計算機的性能之前。一種解決性能、縮放性以及可獲得性的有效途徑是將web應用裝在多個服務器 (服務器簇)上，或者有時將包括文檔、數據、代碼以及全部其他軟件的整個應用復制到兩個不同的數據中心(站點鏡像)，并且在這些服務器(或者站點)間對客戶端請求進行負載平衡。負載平衡遍布以上負載的多個服務器。如果一個服務器失敗，則負載平衡機制將業務從失敗的服務器移走，以便使得該站點仍處于運行中。對于服務器簇和站點鏡像二者，已經開發了多種負載均衡機制。它們在其特定上
5下文中工作良好。但是服務器簇和站點鏡像二者具有顯著的限制。兩種方式都提供“固定量”的基礎設施容量，但是web應用上的負載不是固定的。在實際中，沒有“合適”量的基礎設施提供給web應用，因為當存在業務尖峰時，應用上的負載在短時間段內可能在從零到數百萬的點擊之間擺動。當提供不足時，應用可能執行得較差，或者甚至變得不可用。當提供過多時，浪費了提供過多的容量。為了節約，許多web操作員停止購買顯著比需求多的容量。今天，許多數據中心服務器的利用率低于20%是常見的，導致了容量的顯著浪費。近幾年來，作為有效和更靈活的計算方式，已經出現了云計算。根據維基百科，云計算是指“對于可變服務使用基于因特網(即，云)的計算機技術。它是一種動態可縮放的計算方式，并常常在其中提供虛擬資源作為因特網上的服務。用戶不需要知曉、專長于、或控制支持它們的‘云’中的技術基礎設施。”術語“云”是基于在計算機網絡圖中如何對它的描述的比喻，并且是它掩蓋的復雜的基礎設施的抽象表示。在本文中，我們使用術語“云計算”來指代基于網絡的計算基礎設施的利用，基于網絡的計算基礎設施包括許多互聯的計算節點以提供某種類型的服務，其中每個節點可以使用像虛擬化和web服務的技術。云自身的內部工作對用戶而言被隱蔽。使云計算能夠進行的技術之一是虛擬化。維基百科對“虛擬化”的解釋為“虛擬化是廣義的術語，指計算機資源的抽象”。它包括“平臺虛擬化”和“資源虛擬化”。“平臺虛擬化”將操作系統與底層平臺資源分開，而“資源虛擬化”將具體的系統資源虛擬化，例如存儲體、命名空間和網絡資源等。VMWare公司提供基于底層硬件資源“虛擬化”計算機操作系統的虛擬化軟件。通過虛擬化，人們可以使用軟件啟動、停止和管理計算環境中的“虛擬機器”(VM)節點。每個“虛擬機器”表現得就像從外部角度來看的常規計算機一樣。盡管“虛擬機器”自身僅是在“真正”計算機上運行的軟件程序，人們可以向其安裝軟件，從其刪除文件和在其上運行程序。使云計算能夠進行的另一技術是產品硬件的可獲得性以及產品硬件的低成本和強計算能力。現在人們可以用幾百美元獲得一臺比二十多年前花費十倍成本獲得的機器功能更加強大的計算機。盡管個體產品機器自身可能不可靠，但是將許多個體產品機器放到一起可以產生極其可靠和強大的系統。Amazom. com的彈性計算云(EC^)是通過虛擬化軟件使用數千產品機器形成極其強大的計算基礎設施的云計算環境的例子。通過利用產品硬件和虛擬化，云計算能夠增加數據中心效率、增強操作靈活性和降低成本。但是，因為頻繁的節點停止和啟動，在像Amazom EC2的云計算環境中運行web 應用對業務管理和負載平衡產生了新的要求。在服務器簇和站點鏡像的情況中，停止服務器或服務器故障是例外。對應的負載平衡機制還被設計為將這種情況處理為例外。在云計算環境中，服務器重新引導和服務器關閉被假設為除例外的常見情形。由于云系統利用產品硬件，所以個體節點不可靠的假設是針對云系統設計的核心。還存在啟動或停止節點的商業原因以增加資源利用并降低成本。自然地，云計算環境所需的業務管理和負載平衡系統必須響應于這些節點狀態的改變。對于簇和站點鏡像，已經開發了各種負載平衡技術。在現有技術中，為改進應用性能和縮放性，服務器簇是眾所周知的途徑。該構思是將單個服務器節點替換為應用體系結構中的多個服務器。因為多個服務器分擔應用負載，所以性能和縮放性二者都得到改進。如果服務器之一出現故障，則其他服務器承擔起工作，從而防止可用性的丟失。圖3示出一個例子，其中多個web服務器形成web服務器群350，多個應用服務器形成應用服務器群360， 并且多個數據庫服務器形成數據庫服務器群380。負載平衡器340添加到體系結構中以使負載分布到不同服務器。負載平衡器340還檢測節點故障，并且如果服務器出現故障，則將請求重新路由到其余服務器。存在來自諸如 Cisco、Foundry、Networks、F5 Networks、Citrix System 等公司的可用的硬件負載平衡器。流行的軟件負載平衡器包括Apache HTTP服務器的mocLproxy和 HAProxy0在專利7，480，705和7，346，695等中描述了實現服務器簇的負載平衡的例子。但是，這樣的負載平衡技術針對相同數據中心中的負載平衡，對頻率節點狀態改變的響應不好，并要求購買、安裝和維護特殊的軟件或硬件。在專利7，325，109,7, 203，796和7，111，061等描述了比服務器簇更高級的增強應
用可用性的方法稱為“站點鏡像”。其將包括文檔、代碼、數據、web服務器軟件、應用服務器軟件、數據庫服務器軟件等等的整個應用復制到另一地理位置，創建兩個地理分離的彼此鏡像的站點。與服務器簇相比，站點鏡像具有下列優點即使在一個站點完全失敗時，也能夠提供服務器的可用性。但是它比服務器簇復雜，因為它要求兩個站點之間的數據同步。被稱為“全局負載平衡設備”的硬件設備典型地用于多個站點間的負載平衡。但是，該設備獲得非常昂貴，并且該系統安裝非常昂貴。而且，對于大多數應用來說，先期投資很高，管理安裝需要專門技術知識，并且進行變化費時。持續的維護也昂貴。最后，全局負載平衡設備的集合形成單點故障。已經結合內容交付網絡(⑶N)開發了第三種負載平衡方法。像Akamai和 Limelight Networks之類的公司操縱包括戰略上布局在全球的成千上萬的服務器的全球內容交付體系結構。這些服務器緩存由其客戶(內容提供商)產生的web站點內容(靜態文檔)。當用戶請求這樣的web站點內容時，路由機制發現合適的服務該請求的緩存服務器。通過使用內容交付服務，用戶接收更好的內容性能，因為內容是從較接近用戶的邊緣服務器交付的。在內容交付的背景下，已經開發了多種用于負載平衡和業務管理的技術。例如，專禾Ij 6，108，703,7, 111，061、和7，251，688說明了產生網絡地圖和將網絡地圖提供給域名系統(DNS)并接著選擇合適的內容服務器來服務用戶請求的方法。專利6，754，699、 7，032，010、和7，346，676公開了將認證DNS服務器與客戶端DNS服務器列表關聯并接著基于諸如延遲的度量返回合適的內容服務器的方法。盡管這些技術已經成功，但是仍設計它們來管理用于緩存內容交付網絡的服務器的業務。而且，這些技術不能實時響應負載平衡和失效備援狀態改變，因為DNS結果通常被緩存至少一“生存期(TTL) ”時間段，并且因此改變不可見，直到TTL超期為止。剛出現的云計算環境向負載平衡和失效備援提出了新挑戰。在云計算環境中，上述一些服務器節點可以是“虛擬機器(VM) ”。這些“虛擬機器”表現得就像常規的物理服務器。事實上，客戶端甚至不知道服務器應用是在代替物理服務器的“虛擬機器”上運行的。 這些“虛擬機器”可以成簇，或者在不同的數據中心被鏡像，就像傳統的方法一樣以增強應用的縮放性。但是，與傳統的成簇或站點鏡像不同，這些虛擬機器可以使用純計算機軟件來啟動、停止和管理，所以更容易管理它們且更容易地進行改變。但是，從業務管理的視點看云計算中服務器節點的頻繁啟動和停止增加了新要求。因此，期望提供一種負載平衡和業務管理系統，其有效地將業務定向到多個服務器節點，實時響應服務器節點啟動和停止，同時增強應用性能、縮放性和可用性。還期望提供一種在云計算環境中容易實施、容易維護以及工作良好的負載平衡系統。

發明內容
總的來說，在一個方面，本發明提供一種在運行網絡可接入計算機服務的計算節點組提供負載平衡和失效備援的方法。該方法包括提供計算機服務，其中所述計算機服務存在于在所述計算節點組包含的一個或多個服務器上，并且經由第一網絡可被客戶端接入；提供包括多個業務處理節點和負載平衡裝置的第二網絡，并且其中所述負載平衡裝置被配置為在運行所述計算機服務的所述計算節點組提供負載平衡；提供重定向網絡業務的裝置，該網絡業務包括客戶端請求從所述第一網絡向所述第二網絡接入所述計算機服務； 提供選擇所述第二網絡的業務處理節點的裝置，所述第二網絡接收所述重定向的網絡業務，并且經由所述重定向網絡業務的裝置重定向所述網絡業務到所述業務處理節點，所述網絡業務包括所述客戶端請求接入所述計算機服務；對于接入所述計算機服務的每個客戶端請求，經由所述負載平衡裝置確定在由所述業務處理節點運行所述計算機服務的所述計算節點組的最優計算節點；以及經由所述第二網絡由所述業務處理節點將所述客戶端請求路由到所述最優計算節點。實現本發明的該方面可以包括下述的一個或多個所述負載平衡裝置是負載平衡和失效備援算法。所述第二網絡是強加在所述第一網絡之上的疊加網。所述業務處理節點檢查所述重定向網絡業務并將所有源自相同的客戶端會話的客戶端請求路由到相同的最優計算節點。所述方法還可以包括將針對源自該相同客戶端會話的客戶端請求的來自計算機服務的響應定向到第二網絡的業務處理節點，并接著將業務處理節點的響應定向到該相同的客戶端。經由第一網絡內的域名接入所述網絡可接入的計算機服務，并且其中所述重定向網絡業務的裝置分析所述網絡可接入計算機服務的所述域名為所述第二網絡的所述業務處理節點的IP地址。所述網絡可接入計算機服務是經由第一網絡內的域名接入的，并且其中所述重定向網絡業務的裝置將CNAME添加到所述網絡可接入計算機服務的所述域名的域名服務(DNS)記錄中，并分析CNAME為所述第二網絡的所述業務處理節點的IP 地址。所述網絡可接入計算機服務是經由第一網絡內的域名接入的，并且其中所述第二網絡還包括域名服務器(DNQ節點，并且其中所述DNS節點接收所述域名的客戶端DNS查詢， 并且分析所述網絡可接入計算機服務的所述域名為所述第二網絡的所述業務處理節點的 IP地址。基于到該請求發起的客戶端的所述業務處理節點的地理周邊選擇所述業務處理節點。基于與所述第二網絡的所述業務處理節點的負載條件相關的度量來選擇所述業務處理節點。基于與所述第二網絡的所述業務處理節點的性能統計相關的度量來選擇所述業務處理節點。基于到所述業務處理節點的映射客戶端的粘性會話表來選擇所述業務處理節點。 基于所述負載平衡算法確定所述最優計算節點，并且其中所述負載平衡算法利用最優計算節點性能、最低計算成本、輪叫或加權業務分配作為計算規則。所述方法還包括提供監視裝置，用于監視所述業務處理節點和所述計算節點的狀態。在檢測到失敗的業務處理節點或失敗的計算節點時，分別將實時網絡業務重定向到非失敗的業務處理節點或將客戶端請求路由到非失敗的計算節點。基于來自所述監控裝置的反饋實時確定所述最優計算節點。所述第二網絡包括虛擬機器節點。所述第二網絡通過動態調整業務處理節點的數量來縮放其
8處理容量和網絡容量。所述計算機服務是web應用、web服務或電子郵件服務。總的來說，在另一個方面，本發明提供一種在運行網絡可接入計算機服務的計算節點組提供負載平衡和失效備援的系統。該系統包括在計算節點組和多個客戶端之間提供網絡連接的第一網絡；計算機服務，其中所述計算機服務處于所述計算節點組包括的一個或多個服務器上，并經由所述第一網絡可被客戶端接入；并且包括多個業務處理節點和負載平衡裝置的第二網絡。所述負載平衡裝置被配置為在運行所述計算機服務的所述計算節點組提供負載平衡。該系統還包括重定向網絡業務的裝置，該網絡業務包括客戶端請求從所述第一網絡向所述第二網絡接入所述計算機服務；選擇所述第二網絡的業務處理節點的裝置，所述第二網絡接收所述重定向的網絡業務；對于接入所述計算機服務的每個客戶端請求，經由所述負載平衡裝置確定在由所述業務處理節點運行所述計算機服務的所述計算節點集中的最優計算節點的裝置；以及經由所述第二網絡由所述業務處理節點將所述客戶端請求路由到所述最優計算節點的裝置。該系統還包括實時監視裝置，在業務路由中提供用于選擇最優業務處理節點和最優計算節點的實時狀態數據，由此最小化由個體節點的失敗引起的服務破壞。本發明的優點可以是以下的一個或多個。本發明采用商品硬件(而不是特定硬件設備)上的軟件，并提供執行全局業務管理的服務。因為其提供web交付服務，更容易采用和更容易維護。不需要購買特殊的硬件或軟件，并且不必安裝和維護。與現有技術的負載平衡方法相比，本發明的系統成本利用效率高且總的來說是靈活的。與內容交付網絡的負載平衡技術不同，本發明被設計為提供動態web應用的業務管理，其內容不可被緩存。服務器節點可以在一個數據中心、多個數據中心中或者可以在不同的地理位置上分布。而且，這些服務器節點的一些可以是運行在云計算環境中的“虛擬機器”。本發明是可縮放的、容錯的業務管理系統，其執行負載平衡和失效備援。業務管理系統內的個體節點的失敗不會引起系統的失敗。本發明被設計為在商品硬件上運行，并且作為經由因特網交付的服務而被提供。系統是水平可縮放的。通過僅向系統增加更多的業務處理節點可以增加計算能力。該系統特別適于節點停止和啟動是經常出現的諸如云計算環境的計算環境的業務管理和負載平衡。而且，本發明還考慮會話粘性，從而當要求會話粘性時，來自相同的客戶端會話的請求可以持續地被路由到相同的計算節點。會話粘性，也稱為“IP地址持久化”或“服務器親和力”，意味著源自相同的客戶端不同會話請求將總是被路由到多服務器環境中的相同的服務器。對多種多樣的web應用要求“會話粘性”以運行正確的功能。本發明應用的例子包括以下的一些如圖5所示的，定向在相同數據中心內的不同服務器上運行的多個復制的web應用例程中的請求；如圖6所示的，對運行在多個站點 (數據中心)上的復制的web應用例程之間進行負載平衡；如圖7所示的，在云計算環境中向節點定向業務。在圖7中，這些節點示出為“虛擬機器(VM) ”節點。管理運行在云計算環境中的到3層(3-tierecOweb應用的業務。每一層(web服務器、應用服務器、數據庫服務器)包含多個VM例程，如圖8所示。管理多服務器環境中到郵件服務器的業務。例如，圖 9示出了這些郵件服務器也作為VM節點運行在計算云中。如圖20所示，本發明還可以用于提供經由因特網交付的點播服務到站點操作員以幫助他們改進他們的web應用性能、可縮放性和可獲得性。服務提供商HOO管理和操作全局基礎設施H40，提供web性能相關的服務，包括監視、負載平衡、業務管理、縮放和失效備援等等。如圖20所示，為了用戶購買、配置和管理來自服務提供商的服務，全局基礎設施具有管理和配置用戶界面(UI)H30。客戶包括擁有和管理web應用H50的web操作員H10。 Web應用H50可以部署在一個數據中心，或在幾個數據中心，在一個位置或在多個位置，或作為虛擬機器運行在分布的云計算環境中。H40提供包括監視、業務管理、負載平衡和失效備援的服務給web應用H50，這產生了向web用戶H20交付更好的性能、更好的縮放性和更好的可用性。反過來，對于使用該服務，web操作員HlO向服務提供商HOO支付費用。結合下面的附圖和說明，給出本發明的一個或多個實施例的細節。本發明的其他特點、目的和優點將從優選實施例、附圖的下面描述以及從權利要求書中是顯而易見的。


圖1是靜態站點的框圖；圖2是典型web應用(“動態web站點”)的框圖；圖3示出經由負載平衡設備在簇環境中的負載平衡的框圖(現有技術)。圖4示出經由全局負載平衡設備在兩個鏡像站點之間的負載平衡的示意圖(現有技術)；圖5A是本發明第一實施例的示意圖；圖5B是圖5A的云路由系統的框圖；圖5C是圖5A的系統中的業務處理管線的框圖；圖5是本發明用于運行在位于相同數據中心的不同服務器上的多個復制web應用例程的業務負載平衡的例子的示意圖；圖6是本發明用于運行在位于不同數據中心的不同服務器上的多個復制web應用例程的業務負載平衡的例子的示意圖；圖7是本發明用于運行在云計算環境中的“虛擬機器(VM)節點”上的多個復制web 應用例程的業務負載平衡的例子的示意圖；圖8是使用本發明管理運行在云計算環境中的3-層web應用的業務的例子的示意圖；圖9是使用本發明管理運行在云計算環境中的郵件服務器的業務的例子的示意圖；圖10是被稱為“Yottaa”的本發明的實施例的示意圖；圖11示出圖10的^ttaa如何處理客戶端請求的流程圖；圖12示出圖10的^ttaa業務管理節點的體系結構的框圖；圖13示出如何使用本發明從3-層web應用服務HTTP請求；圖14示出了使用本發明的業務管理系統的應用交付網絡的各種功能塊；圖15示出了 ^ttaa業務管理節點的生命周期；圖16示出了 ^ttaa管理器節點的體系結構；圖17示出了 ^ttaa管理器節點的生命周期；圖18示出了 ^ttaa監視器節點的體系結構；圖19示出了使用本發明提供全局地理負載平衡的例子；以及
圖20示出了使用本發明提供經由因特網向web站點操作員提供改進的web性能服務的例子。
具體實施例方式本發明利用重疊虛擬網絡提供具有運行在相同數據中心或不同數據中心中的不同服務器上的多個復制例程的聯網計算機服務的業務管理和負載平衡。業務處理節點部署在物理網絡上，通過該物理網絡客戶端將業務運送到正運行網絡應用的數據中心。這些業務處理節點被稱為“業務處理單元”(TPU)。TPU部署在不同的位置，每一個位置形成一個計算云。所有TPU —起形成被稱為“云路由網絡”的“虛擬網絡”。 業務管理機制截獲定向到網絡應用的所有客戶端業務并將其重定向到TPU。TPU執行負載平衡并將業務定向到運行網絡應用的合適的服務器。每一個TPU具有特定量的帶寬和處理容量。這些TPU彼此經由底層網絡而連接，形成第二虛擬網絡。通過合并所有TPU的帶寬和處理容量，該虛擬網絡處理特定量的帶寬和處理容量。當業務增長到特定級別時，作為增加其處理能力以及帶寬容量的方法，虛擬網絡啟動更多的TPU。當業務級別減少到特定閾值時，虛擬網絡關閉一些TPU以降低其處理和帶寬容量。參照圖5A，虛擬網絡包括部署在云；340、云350和云360的位置的節點。每一個云包括運行用于業務管理、業務清理和相關數據處理的專業軟件的節點。從功能的角度，虛擬網絡包括截獲和重定向網絡業務的業務管理系統330、執行接入控制、故障檢測、故障預防和減輕阻斷攻擊(DOS)的業務處理系統334、以及聚集來自不同源的數據并提供全局決定支持的全局數據處理系統332。聯網的計算機服務運行在位于多個站點(即分別是站點A 580以及站點B 590)的多個服務器(即服務器550和服務器591)。客戶端500經由網絡 370接入該網絡服務。客戶端500向站點A 580的web服務器550中的網絡服務發出HTTP請求535。 HTTP請求535被業務管理系統(TMQ 330截獲。代替將該請求直接路由到其上正運行該應用的目標服務器陽0( “目標服務器”)，業務管理系統330將該請求重定向到“最優”業務處理單元(TPU)342進行處理。更具體地，如圖5A所示，業務管理系統330咨詢全局數據處理系統332并選擇“最優”業務處理單元342以便向其路由該請求。通過特定應用來定義 “最優”，諸如地理位置是最近的、就網絡距離/延遲而言是最近的、是性能最佳的節點、就成本而言是最廉價的節點、或者根據特定算法計算的幾個因素的組合。接著業務處理單元342 截獲HTTP請求，執行負載平衡功能并確定用于處理HTTP請求的“最優”服務器。通過運行負載平衡和失效備援來執行負載平衡。在一些情況中，TPU將該請求直接路由到目標服務器。在其他情況中，TPU將該請求路由到另外的業務處理單元，該另外的業務處理單元最終能將該請求路由到目標服務器，諸如路由到TPU 342至TPU 352然后到服務器550。云路由網絡本發明調節(leverage)云路由網絡。通過背景技術，我們使用術語“云路由網絡” 來指代包括在底層物理網絡的各種位置上布置的業務處理節點的虛擬網絡。這些業務處理節點運行專業業務處理軟件來執行諸如業務重定向、業務分離、負載平衡、業務檢查、業務清理、業務優化、路由選擇、路由優化等等的功能。這些節點的典型配置包括在各種云計算數據中心的虛擬機器。這些云計算數據中心提供物理基礎設施以動態添加或移除節點，其還使得虛擬網絡能縮放其處理容量和網絡帶寬容量。云路由網絡包括將網絡業務重定向到其業務處理單元(TPU)的業務管理系統330、檢查和處理網絡業務的業務處理機制334以及聚集來自不同源的數據并提供全局決定支持和配置及管理系統的裝置的全局數據數據存儲庫(store) 332。大多數節點是運行專業業務處理軟件的虛擬機器。每個云自身是位于相同數據中心(或相同地理位置)的節點集合。一些節點執行業務管理。一些節點執行業務處理。一些節點執行監視和數據處理。一些節點執行調整虛擬網絡容量的管理功能。一些節點執行接入管理和安全控制。這些節點彼此經由底層網絡370連接。兩個節點之間的連接可以包含底層網絡中的許多物理鏈路和中繼，但是這些鏈路和中繼一起形成概念上的“虛擬鏈路”，概念上直接連接這兩個節點。所有這些虛擬鏈路一起形成虛擬網絡。每一個節點僅具有固定量的帶寬和處理容量。該虛擬網絡的容量是所有節點容量的和，并且因此云路由網絡在任何給定時刻僅具有固定量的處理和網絡容量。該固定量的容量對于業務需求來說可能不足或過度。通過調節單個節點的容量或通過添加或移動節點，虛擬網絡能夠調整其處理能力以及其帶寬容量。參照圖5B，云路由系統400的功能組件包括業務管理接口單元410、業務重定向單元420、業務路由單元430、節點管理單元440、監視單元450以及數據資料庫460。業務管理接口單元410包括管理用戶界面(UI)412以及管理API 414。業務處理本發明使用網絡服務處理業務，并因此僅交付“條件”業務給目標服務器。圖5A 示出典型的業務處理服務。當客戶端500向運行在服務器550、591上的網絡服務發出請求時，云路由網絡在下列步驟中處理請求1、業務管理服務330截獲該請求并將該請求路由到TPU節點340、350和360 ；2、TPU節點檢查應用特定策略并執行如圖5C所示的管線處理；3、如果必須，使用全局數據資料庫進行數據收集和關于決定支持的數據分析；4、如果必須，將客戶端請求路由到下一 TPU節點，即從TPU 342到352 ；以及接著5、將請求發送到“最優”服務器381進行處理。更具體地，當客戶端發送請求到服務器(例如，客戶向web瀏覽器輸入web URL以接入web站點)時，缺省因特網路由機制將該請求通過網絡中繼沿特定網絡路徑從客戶端路由到目標服務器(“缺省路徑”)。使用云路由網絡，如果存在多個服務器節點，則云路由網絡首先從多個服務器節點選擇“最優”服務器節點作為目標服務器節點以服務該請求。該服務器節點選擇處理考慮包括以下的因素負載平衡、性能、成本以及地理接近性等等。其次，代替通過缺省路徑，業務管理服務將該請求重定向到該重疊網絡內的“最優”業務處理單元(TPU)。通過系統路由策略來定義“最優”，諸如地理位置是最近的、最具成本效率的、 或者幾個因素的組合。如果需要，該“最優”TPU還將該請求路由到云路由網絡內的第二“最優” TPU。針對性能和可靠性原因，這兩個TPU節點使用最佳可獲得或最優傳輸機制來彼此通信。接著第二“最優”節點可以將該請求路由到第三“最優”節點等等。該處理可以在云路由網絡中重復，直到該請求最終到達目標服務器為止。該組“最優” TPU節點一起形成業務延其行進的“虛擬”路徑。該虛擬路徑是這樣選擇的優化諸如性能、成本、碳足跡、或幾個因素的組合的特定路由測量，這樣是最優的。當服務器響應時，該響應通過云路由網絡內的相似的管線處理直到其到達客戶端。處理縮放和網絡縮放本發明還使用虛擬網絡執行處理縮放和帶寬縮放以響應業務需求改變。云路由網絡經由其監視服務監視業務需求、負載條件、網絡性能和各種其他因素。 當滿足特定條件時，其動態地啟動合適位置的新節點并將負載擴展到這些新節點以響應增加的需求，或者關閉一些現存的節點響應于減少的業務需求。該最后結果是云路由網絡動態調整其處理和網絡容量以將交付最優結果同時去除不必要的容量浪費和碳足跡。而且，云路由網絡能夠快速地從“故障”中恢復。當諸如節點失敗和鏈路失敗之類的故障出現時，該系統檢查問題并通過新節點或選擇替代的路由來從其恢復。結果，盡管個體組件可能不可靠，但是整個系統是高可靠的。業務重定向本發明包括被稱為“業務重定向”的機制，其截獲客戶端請求并將其重定向到業務處理節點。以下列表包括業務截獲和重定向機制的幾個例子。但是，該列表并不意欲排他。 本發明意欲包括各種業務重定向手段。1、代理服務器設置大多數客戶端支持被稱為“代理服務器設置”的特征，其允許客戶端指定中繼業務到目標服務器的代理服務器。當配置代理服務器時，所有客戶端請求被發送到代理服務器，代理服務器接著將該業務在目標服務器和客戶端之間中繼。2、DNS重定向當客戶端試圖經由其主機名接入網絡服務時，主機名需要被解析成IP地址。該主機名到IP地址的解析通過使用域名服務器(DNS)系統來實現。通過實現將客戶端主機名解析請求解析成合適的業務處理節點的IP地址而不是目標服務器節點的 IP地址的定制的DNS系統，DNS重定向能夠提供從業務截獲到重定向的透明方式。3、HTTP重定向存在內置到HTTP協議的“重定向”指令，其允許服務器告訴客戶端向不同的服務器發送請求。4、網絡地址映射可以配置特定設備以將在特定目的地的業務“重定向”到不同目的地。該特征由不同的應用(諸如網關設備)和軟件產品支持。人們可以配置這樣的設備來執行業務重定向功能。監視云路由網絡包含向云路由網絡提供必須的數據作為操作基礎的監視服務720，如圖5C所示。各種實施例實現用于監視的各種技術。下面列出幾種監視技術的例子。1、因特網控制消息協議(ICMP)Ping 經由網絡配發送以檢測路由和節點狀態的小IP分組；2、跟蹤程序(traceroute)通常用于檢查網絡路由條件的技術；3、主機代理運行在收集有關主機的數據的主計算機上的嵌入代理；4、web性能監視監視器節點，用作正常用戶代理，周期性地向web服務器發送 HTTP請求并處理來自web服務器的HTTP請求。監視器節點沿著諸如DNS解析時間、請求時間、響應時間、頁加載時間、請求數量、Java腳本文件數量或頁足跡等等的途徑來記錄度量。5、安全監視監視器節點周期性地掃描目標系統的安全弱點，諸如周期性地進行網絡端口掃描和網絡服務掃描，以確定哪些端口是公開可接入的以及哪些網絡服務正在運行，并且還確定是否存在弱點。
13
6、內容安全監視監視器節點周期性地緩慢行進于站點，并掃描其內容以檢測感染內容，諸如惡意軟件、間諜軟件、不期望的成人內容或病毒等等。上述例子用于說明的目的。本發明是不可知的(agnostic)并且包括廣泛不同的監視方式。本發明的實施例可以使用上述用于監視不同目標系統的技術之一或組合，即使用ICMP、跟蹤程序以及主機代理來監視云路由網絡自身、使用web性能監視、網絡安全監視以及內容安全監視來監視諸如web應用的目標網絡服務的可獲得性、性能和安全。數據處理系統(DPS)聚集來自諸如監視服務的數據并將所有其他服務全局可見性提供給這樣的數據。負載平衡和業務管理的示例在下面說明中，術語“^ttaa服務”是指實現業務管理和負載平衡的本發明的系統。圖5說明了負載平衡從客戶端到在相同數據中心的不同服務器上運行的多個復制web應用例程的業務的例子。參照圖5，業務重定向機制利用DNS重定向機制。為了接入web服務器550，客戶端機器500需要首先解析web服務器550的IP地址。客戶端500 發送出DNS請求510，并且^ttaa服務520以DNS響應515進行應答。DNS響應515向在 ^ttaa服務520內運行的業務處理節點解析HTTP請求530的域名。結果，到web服務器 550的HTTP請求530被重定向到^ttaa服務520內運行的業務處理節點。該節點還將該請求轉發到web服務器群550內的web服務器之一，并最終處理該請求。類似地，數據中心中的web服務器節點550和應用服務器560也可以使用^ttaa服務520以接入它們的通信目標。圖6示出了 ^ttaa服務620重定向和負載平衡從客戶端500、600向在不同數據中心550、650的不同服務器上運行的多個復制web應用例程的業務的例子。圖7說明^ttaa服務720重定向和負載平衡運行在云計算環境750中的“虛擬機器”(VM)節點755上的多個復制web應用例程的業務的例子。當客戶端機器700請求云 750提供的服務時，Yottaa服務720選擇該云內的最合適的虛擬機器節點以服務該請求。圖8說明^ttaa服務820重定向和負載平衡從客戶端800到運行在云計算環境中的3-層web應用的業務的例子。每一層(web服務器850、應用服務器860、數據庫服務器870)包含多個VM例程。圖9說明^ttaa服務920重定向和負載平衡從客戶端900到多服務器環境中的郵件服務器955的業務的例子。該郵件服務器可以作為計算云950中的VM節點運行。本發明使用域名系統(DNS)以通過在DNS主機名查詢中提供期望的處理節點的因特網協議(IP)地址來獲得業務重定向。結果，客戶端請求被重定向到期望的處理節點，接著該處理節點將該請求路由到目標計算節點進行處理。在客戶端要求接入復制網絡資源的任何情形下可以使用這種技術。其將客戶端請求定向到合適的復制資源，從而從性能角度看到該復制資源的路由是好的。而且，本發明還考慮會話粘性。當要求會話粘性時，來自相同客戶端會話的請求被持續地路由到相同的服務器計算節點。會話粘性，本領域也稱為“IP 地址持續性”或“服務器親和性”，意味著來自相同客戶端會話的不同請求將總是被路由到多服務器環境中的相同服務器。針對不同的web應用要求“會話粘性”以使功能正確。通過檢查在圖10所示的被命名為“Yottaa”的本發明的實施例來更好地理解本發明的技術細節。^ttaa包含功能部件包括業務處理單元(TPU)節點A45、A65 Jottaa業務管理(YTM)節點A30、A50、A70、Yottaa管理器節點A38、A58、A78以及^ttaa監視器節點 A32、A52、A72。在該例子中，計算服務運行在諸如網絡計算環境A20中的服務器A47和A67 的多個服務器計算節點上。該系統包含一起負責重定向從客戶端機器到網絡A20中的服務器計算節點的列表的業務的多個YTM節點。每個YTM節點包含DNS模塊。上級YTM節點和下級YTM節點一起形成分級DNS樹，分級DNS樹通過考慮諸如節點負載條件、地理接近性和網絡性能的因素將主機名解析成合適的所選擇的“最優”TPU節點的IP地址。而且，每一個TPU節點選擇向其轉發客戶端請求的“最優”的服務器計算節點。基于考慮諸如節點可獲性、性能和會話粘性(如果需要)的因素來選擇“最優”的服務器計算節點。結果，在服務器計算節點列表中對客戶端請求進行負載平衡，在一些服務器計算節點失敗時應該提供實時失效備援保護。參照圖10，使用本發明將客戶端請求重定向到特定服務器節點的工作流包括下面的步驟。1、客戶端AOO向本地DNS服務器發送請求以解析運行計算機服務的服務器的主機名(1)。如果本地DNS服務器不能解析主機名，則將其轉發到上級YTM節點A3(K2)。上級 YTM節點A30接收來自客戶端DNS服務器AlO的請求以解析該主機名。2、上級YTM節點A30選擇下級YTM節點列表并將它們的地址返回到客戶端DNS服務器A10(3)。該列表的大小通常是3-5并且如果可能上級YTM試圖確認所返回的列表跨越兩個不同的數據中心。下級YTM的選擇是根據可重復的路由策略決定的。當上級YTM應答 DNS查詢請求時，其根據路由策略設置長的生存時間值(例如，一天，幾天或甚至更長)。3、客戶端DNS服務器AlO依次向所返回的下級YTM節點A50查詢主機名的名稱解析(4)。下級YTM節點A50利用監視器節點A52收集的數據選擇“最優”的TPU節點并返回該TPU節點的IP地址到客戶端DNS服務器AlO (5)。4、客戶端AOO接著向TPU A45發送請求(7)。當所選擇的TPU節點A45接收到客戶端請求時，它首先檢查來看看是否要求會話粘性支持。如果要求會話粘性，它通過咨詢粘性會話表A48進行檢查來看看根據先前的請求的先前選擇的服務器計算節點是否存在。該搜索僅需在本地區域進行。如果先前選擇的服務器計算節點存在，則立即返回該服務器計算節點。如果先前選擇的服務器計算節點不存在，則TPU節點根據特定的負載平衡和失效備援策略選擇“最優”的服務器計算節點A47 (8)。而且，如果應用要求會話粘性，則選擇的服務器計算節點和客戶端被添加到粘性會話表A48以備將來參考。服務器A47接著處理該請求并將響應發送回TPU A45 (9)，并且TPU A45將其發送到客戶端AOO (10)。在業務重定向和負載平衡處理中使用的組合了設置的不同TTL值和負載平衡策略的YTM DNS節點的分級結構導致了獲得業務管理的任務，即性能加速、負載平衡和失效備援。本實施例的基于DNS的方式僅是如何能實現業務管理的例子，并且在任何方面上其不將本發明限制在該具體實現上。本發明的一個方面在于其是容錯的且高速響應節點狀態改變。當下級YTM節點啟動時，它從其配置數據中發現上級YTM列表并將其可用性自動通知它們。結果，上級YTM 節點將該新節點添加到接收DNS請求的節點的列表中。當從管理器節點接收到下級YTM節點關閉通知事件時，上級YTM節點將關閉節點從其列表中移除。因為針對DNS查詢請求返回多個YTM節點，所以一個YTM節點變為關閉將不會導致DNS查詢失敗。而且，因為從下級 YTM節點返回的短的TTL值，所以服務器節點失敗將對任何用戶是透明的。如果要求粘性會話支持，則這些目前連接到該失敗的服務器節點的用戶可以獲得一錯誤。但是甚至對于這些用戶，在TTL逾期后其將不能短期恢復。當管理器節點檢測到服務器節點失敗時，它通知本地區域中的下級YTM節點并且這些YTM節點立即將該服務器節點從路由列表中移除。 而且，如果一些上級節點關閉，因為上級YTM節點返回的長的TTL值，所以大多數DNS查詢將不注意該失敗。只要在請求的主機名的DNS記錄中的至少一個上級YTM節點仍在運行， 則在TTL逾期后對失敗的上級節點的查詢將仍會是成功的。當服務器計算節點停止或啟動時，監視器節點立即檢測其狀態改變。這樣的信息使得TPU節點能響應節點狀態改變進行實時路由調整。本發明的另一方面在于它是高效且可縮放的。因為上級YTM返回長的TTL值，并且因特網上的DNS服務器執行DNS緩存，所以大多數DNS查詢將直接轉向下級YTM節點，并且因此在上級YTM節點上的實際負載是很低的。而且上級YTM節點不需要彼此通信，并且因此通過向系統添加新節點，系統的容量線性增加。只要在本地區域中粘性會話列表是可接入的，則下級YTM節點也不需要彼此通信。當添加新的YTM節點時，其僅需要與少量上級 YTM節點以及少量管理器節點通信，并且容量也線性增加。具體地，圖10示出了 ^ttaa服務的體系結構以及解析從位于北美的客戶端機器 AOO到其最近的服務器例程A47的請求的步驟。同樣地，來自位于亞洲的客戶端機器A80的請求被定向到接近A80的服務器A67。如果應用請求粘性會話支持，則系統使用粘性會話列表來路由從相同客戶端會話到持續服務器計算節點的請求。系統“Yottaa”部署在網絡A20上。網絡可以是局域網、無線網、諸如因特網的廣域網等等。應用運行在被圖中標注為“服務器”的節點上，諸如服務器A47和服務器A67。 ^ttaa將全部這些服務器例程常常是根據地理接近性或網絡接近性分成不同區域。每一個 YTM節點管理服務器節點列表。例如，YTM節點A50管理區域A40中的服務器，諸如服務器 A47。在網絡上，Yottaa部署幾種類型的邏輯節點，包括TPU節點A45、A65、Yottaa業務管理(YTM)節點諸如A30、A50和A70、Yottaa管理器節點諸如A38、A58和A78、Yottaa監視器節點諸如A32、A52和A72。注意，在實際實現中，不要求將這些類型的邏輯節點分離成三種實體，在實際部署中它們中的兩個或它們的全部可以組合到同一物理節點中。存在兩種類型的YTM節點上級YTM節點(諸如A30)和下級YTM節點(諸如A50 和A70)。它們結構相同但功能不同。通過節點自身的配置來定義YTM節點是上級節點還是下級節點。每一個YTM節點都包含DNS模塊。例如，YTM A50包含DNS A55。而且，如果主機名要求粘性會話支持(如web操作員定義的)，則針對每一個應用的主機名創建粘性會話列表(諸如A48和A68)。該粘性會話列表由管理該應用的服務器節點的相同列表的YTM 節點共享。在某種意義上，上級YTM節點通過向下級YTM節點定向DNS請求來向它們提供服務。在級聯形式中，每個下級YTM節點向其自己的“下級"YTM節點組提供類似的服務，類似于典型的DNS拓撲中的DNS樹。使用這樣的級聯樹結構，系統防止了節點由于太多的請求而崩潰，保證了每一個節點的性能并僅通過增加更多的節點能擴展到覆蓋整個因特網。圖10結構性地示出了在一個地理區域中客戶端如何被定向到“最近”的服務器節點。通過特定應用的系統路由策略確定“最近”的含義。當客戶端A00想連接到服務器時，
16在解析客戶端DNS請求中發生如下步驟1、客戶端AOO向其本地DNS服務器AlO發送DNS查詢請求；2、本地DNS服務器AlO (如果其不能直接解析該請求)向上級YTM A30(實際上， 運行在A30內部的DNS模塊A35)發送該請求。YTM A30的選擇基于系統配置，即針對請求的主機名，YTM A30配置在DNS記錄中；3、在從AlO接收到請求時，上級YTM A30將下級YTM節點列表返回到A10。根據當前路由策略選擇該列表，諸如選擇地理上最接近客戶端本地DNS AlO的YTM節點；4、AlO接收該響應，并向所返回的下級YTM節點之一 A50發送主機名解析請求；5、下級YTM節點A50接收該請求，根據其路由策略返回“最優”TPU節點的IP地址列表。在這種情況中，選擇并返回TPU節點A45，因為它地理上最接近客戶端DNS AlO ；6、AlO將所接收的IP地址列表返回到客戶端AOO ；7、AOO向TPU節點A45發送其請求；8,TPU節點A45從客戶端AOO接收請求并選擇諸如服務器A47的“最優”服務器節點以向其轉發該請求；9、服務器A47接收該轉發的請求，處理該轉發的請求并返回響應；10、TPU節點A45向客戶端AOO發送該響應。類似地，位于亞洲的客戶端A80被路由到替代的服務器A65。^ttaa服務向web操作員提供基于web的用戶界面(UI)進行系統配置以針對他們的web應用使用^ttaa服務。web操作員也能夠使用諸如基于網絡的應用編程接口 (API)調用或由服務提供商直接修改配置文件之類的其他方法。使用^ttaa web UI作為例子，web操作員執行下列步驟1、輸入目標web應用的主機名，例如www, yottaa. com 2、輸入目標web應用運行于其上的服務器計算節點的IP地址(如果存在web應用已經直接由web操作員部署的服務器)；3、響應于業務需求增加和相關的配置參數，配置^ttaa是否應該開始新的服務器例程。而且，如果容量超過特定閾值的需求，配置^ttaa是否應該關閉服務器節點；4、向目標web應用的主機名的DNS記錄添加所提供的上級^ttaa節點名稱；5、配置諸如應用是否要求粘性會話支持，會話逾期值、路由策略等等的其他參數。一旦^ttaa系統接收到上述信息，則它執行建立其服務的必須動作以最優化目標web應用的業務負載平衡。例如，一旦接收到主機名和目標服務器節點的靜態IP地址， 系統就將這樣的信息傳播給所選擇的下級YTM節點(使用當前的路由策略)，從而當接收到 DNS查詢請求時，至少一些下級YTM節點能夠將主機名解析成IP地址。圖11示出了使用^ttaa服務如何路由請求的處理流程。當客戶端想連接到諸如 www, example, com的主機時，它需要首先解析主機名的IP地址。為此，它查詢它的本地DNS 服務器。本地DNS服務器首先檢查這樣的主機名是否被緩存并且根據在前的解析是否仍有效。如果是，則返回緩存的結果。如果否，則客戶端DNS服務器針對mm. example, com向預配置的作為上級YTM節點的DNS服務器發布請求。上級YTM節點根據針對該應用配置的可重復的路由策略返回下級YTM節點的列表。在接收到所返回的YTM DNS節點的返回列表時， 客戶端DNS服務器需要查詢這些節點直到返回所解析的IP地址為止。因此，它向列表中之一的下級YTM節點發送請求。下級YTM接收該請求，并接著它基于當前的路由策略和節點監視狀態信息選擇“最優”TPU節點列表。返回所選擇的“最優”TPU節點的IP地址。結果， 客戶端向“最優” TPU節點之一發送請求。所選擇的“最優” TPU節點接收該請求。首先，它確定該應用是否要求粘性會話支持。在定制的^ttaa服務的初始建立期間通常由web操作員配置應用是否要求粘性會話支持。這樣的初始改變隨后可以改變。如果不要求粘性會話支持，則TPU節點選擇正運行應用www, example, com的、根據當前的路由策略和服務器計算節點監視數據選擇的“最優”服務器計算節點。如果要求粘性會話支持，則TPU節點首先使用主機名或URL(此情況中，www, example, com)以及客戶端的IP地址作為關鍵信息(key) 查找粘性會話列表中的條目。如果發現這樣的條目，在粘性會話列表中的該條目的逾期時間被更新為當前時間加上預配置的會話逾期值。當web操作員執行^ttaa服務的初始配置時，他向系統輸入會話逾期超時值，諸如一小時。如果沒有發現條目，則TPU節點根據當前路由策略選擇“最優”服務器計算節點，創建具有合適的關鍵信息以及逾期信息的條目， 并將該條目輸入到粘性會話列表中。最后，TPU節點向所選擇的“最優”服務器計算節點轉發客戶端請求進行處理。如果在查詢下級YTM節點的過程中接收到錯誤，則客戶端DNS服務器將查詢列表中的下一個TPU節點。所以個體下級YTM節點的失敗對于客戶端而言是不可見的。類似地，如果在連接至所返回的“最優”TPU節點之一的IP地址中存在錯誤，則客戶端將試圖連接到列表中的下一個IP地址，直到成功地進行連接為止。上級YTM節點通常對于它返回的結果設置長的生存時間(TTL)值。這樣做最小化了上級節點的負載并減少了來自客戶端DNS服務器的查詢數量。另一方面，下級YTM節點通常設置短的TTL值，使得系統很快響應TPU節點狀態改變。通過清除過期條目來周期性地清理粘性會話列表。在自從上一查詢后的整個會話逾期期間不存在從相同的客戶端的針對相同應用的客戶端請求時，條目過期。在粘性會話情形中，如果持續性IP地址的服務器節點關閉，則^ttaa監視器節點檢測服務器失敗并通知其相關的管理器節點。相關的管理器節點通知相應的YTM節點。接著這些YTM節點從粘性會話列表中移除該條目。TPU節點將自動地向走在前面的不同的服務器節點轉發業務。 而且，對于粘性會話情形，^ttaa聰明地管理關閉的服務器節點以消除針對連接到計劃關閉的服務器節點的這些用戶的服務中斷。它等待直到在該服務器節點上的所有用戶會話在最終關閉節點例程之前都已經逾期為止。^ttaa調節設計到因特網的DNS系統中的遺留的縮放性。它在每一步驟中還提供多個冗余級別(除了 DNS查詢需要持續性IP地址的粘性會話情形外)。而且，系統使用多層DNS層次體系，從而它自然地將負載散布到不同的YTM節點，以有效地分布負載且高度可縮放，同時能夠調節針對不同節點的TTL值并響應于節點狀態變化。圖12示出了 ^ttaa業務管理節點的功能塊，如圖示為C00。節點包括DNS模塊C10，執行標準DNS功能；狀態探頭模塊C60，監視該YTM節點自身的狀態并響應于狀態詢問；管理UI模塊C50，使系統管理者在需要時直接管理該節點；虛擬機器管理器C40(可選)，能夠管理網絡上的虛擬機器節點；以及路由策略模塊C30，管理路由策略。路由策略模塊可以按照需要加載不同的路由策略。模塊C30的部分是用于路由策略的接口，并且該模塊的另一部分提供DNS查詢過程期間的粘性會話支持。而且，YTM節點COO包括配置模塊 C75、節點例程DB C80以及數據存儲庫模塊C85。
圖15示出了 YTM節點如何工作。當YTM節點引導時，它從其環境、配置文件、例程 DB等等中讀取初始化參數。在該過程中，它按照需要采用合適的動作，諸如針對不同應用加載特定路由策略。而且，如果存在初始化參數中指定的管理器節點，則YTM節點向這樣的管理器節點發送啟動可用性事件。因此，這些管理器節點向該YTM節點傳遞服務器節點列表，并分配監視器節點以監視該YTM節點的狀態。下面，YTM節點進行檢查確定根據其配置參數它是否是上級YTM。如果它是上級YTM，則節點進入請求處理的主循環，直到最終接收到關閉請求或出現節點失敗為止。當接收關閉命令時，該節點向其相關的管理器節點通知關閉事件、記錄該事件并接著執行關閉。如果它不是上級YTM節點，則它通過向如在節點配置數據中指定的上級YTM節點的指定列表發送啟動可用性事件而繼續其初始化。當上級YTM節點從下級YTM節點接收到啟動可用性事件時，它執行下列動作1、向路由列表添加下級YTM節點，從而將來的DNS請求可被路由到該下級YTM節點2、如果下級YTM節點沒有已經建立的相關管理器節點(如由啟動可用性事件消息指示的)，則根據上級YTM節點自身的路由策略選擇管理器節點列表，并將該管理器節點列表返回到下級YTM節點。當下級YTM節點從上級YTM節點接收到該管理器節點列表時，它通過向列表中的每一個管理器節點發送啟動可用性事件進行狀態更新而繼續其初始化。當管理器節點從下級YTM節點接收到啟動可用性事件時，它分配監視器節點以監視該YTM節點的狀態。而且， 管理器節點向YTM節點返回在該管理器(實際的監視通過該管理器的相關監視器節點執行)管理之下的服務器節點的列表。當下級YTM節點從管理器節點接收到服務器節點列表時，該信息被添加到由該YTM節點管理的被管理的服務器節點列表中，從而將來的DNS請求可被路由到該列表中的服務器。在YTM節點完成建立其管理的服務器節點列表之后，它進入請求處理的主循環。 例如.如果接收到DNS請求，則根據針對目標主機名和客戶端DNS服務器的路由策略， YTM節點從其管理的節點返回一個或多個節點。.如果該請求是來自管理器節點的節點關閉事件，則從被管理節點列表中除去該節點。.如果接收到節點啟動事件，則將該新節點添加到被管理節點列表中。最后，如果接收到關閉請求，則YTM節點向其相關的管理器節點以及上級YTM節點通知其關閉，向其本地存儲器存儲必要的狀態，記錄事件并關閉。圖16示出了 ^ttaa管理器節點的功能塊。它包括請求處理器模塊F20，處理從網絡上的其他^ttaa節點的接收的請求；虛擬機器(VM)管理器模塊F30，能夠用于管理虛擬機器例程；管理用戶界面(UI)模塊F40，能夠用于本地的配置節點；以及狀態探頭模塊 F50，監視該節點自身的狀態并響應狀態詢問。可選地，如果監視器節點被組合到該節點，則管理器節點還包括節點監視器模塊F10，保持被監視節點的列表并根據當前監視策略周期性地輪詢列表中的節點。圖17示出了 ^ttaa管理器節點如何工作。當它啟動時，它從其環境、配置文件、 例程DB等等中讀取配置數據和初始化參數。在該過程中采取合適的動作。接著它向如在其節點配置數據或初始化參數中指定的父管理器節點的列表發送啟動可用性事件。當父管理器節點接收到啟動可用性事件時，它將該新節點添加到它“管理”下的節點列表中，并“分配” 一些相關的監視器節點以通過向這些監視器節點發送相應請求監視該新節點的狀態。接著該父管理器節點通過以一些服務器節點的列表進行響應來將這些服務器節點的管理責任交付給新管理節點。當子管理器節點接收到期望其繼續管理責任的服務器節點列表時，它將它的一些相關的監視器節點分配來進行服務器節點列表的性能監視和狀態輪詢。如果沒有指定父管理器節點，則期望^ttaa管理器根據其配置數據創建其服務器節點列表。接著，管理器節點完成其初始化并進入其請求處理的主處理循環。如果請求是來自YTM節點的啟動可用性事件，則它將YTM節點添加到監視列表中， 并以針對其分配YTM節點進行業務管理的服務器列表進行應答。注意，通常，可以向多個 YTM節點分配相同的服務器節點進行路由。如果請求是關閉請求，則它向其父管理器節點通知關閉，記錄事件并接著執行關閉。如果從監視器節點報告節點錯誤請求，則管理器節點將該錯誤節點從其列表中移除(或將其移動到不同的列表)，記錄事件并可選擇地報告事件。 如果錯誤節點是服務器節點，則管理器節點通知丟失的該服務器節點的相關的YTM節點， 并且如果配置如此進行并滿足特定條件的話，它試圖重新啟動該節點或開始新的服務器節點ο本發明的一個應用是向web站點操作員提供因特網上交付的點播內容以幫助他們改善他們的web應用性能、縮放性和可用性，如圖20所示。服務提供商HOO管理和操縱提供web性能相關的服務的全局基礎設施H40，包括監視、負載平衡、業務管理、縮放和失效備援等等。全局基礎設施還具有管理和配置用戶界面(UI)H30，如圖19所示，用于客戶訂購、配置和管理服務提供商的服務。客戶包括擁有和管理web應用H50的web操作員H10。 Web應用H50可以部署在一個數據中心、幾個數據中心、一個位置、多個位置，或者作為分布式云計算環境中虛擬機器運行。H40提供包括監視、業務管理、負載平衡、失效備援等的服務給web應用H50，向web用戶H20提供具有交付更好性能、更好縮放性和更好可用性的效果。反過來，對于使用該服務，web管理員HlO向服務提供商HOO支付費用。內容交付網絡在全局上通常使用成千上萬的服務器，并且需要盡可能多的接入點 (point of presence POP)。于此不同，本發明需要被部署到僅僅幾個或幾十個位置。而且， 本發明意欲管理服務器業務的服務器通常部署在僅僅幾個數據中心，或者有時部署在僅僅一個數據中心。已經描述了本發明的幾個實施例。但是，應該理解的是，在不背離本發明的精神和范圍的前提下，可以進行各種修改。因此其他實施例在下述權利要求書的范圍之內。
20
權利要求
1.一種在運行網絡可接入計算機服務的計算節點組提供負載平衡和失效備援的方法， 包括提供計算機服務，其中所述計算機服務存在于在所述計算節點組包含的一個或多個服務器上，并且經由第一網絡可被客戶端接入；提供包括多個業務處理節點和負載平衡裝置的第二網絡，并且其中所述負載平衡裝置被配置為在運行所述計算機服務的所述計算節點組提供負載平衡；提供重定向網絡業務的裝置，該網絡業務包括客戶端請求從所述第一網絡向所述第二網絡接入所述計算機服務；提供選擇所述第二網絡的業務處理節點的裝置，所述第二網絡接收所述重定向的網絡業務，并且經由所述重定向網絡業務的裝置重定向所述網絡業務到所述業務處理節點，所述網絡業務包括所述客戶端請求接入所述計算機服務；對于接入所述計算機服務的每個客戶端請求，經由所述負載平衡裝置確定在由所述業務處理節點運行所述計算機服務的所述計算節點組的最優計算節點；以及經由所述第二網絡由所述業務處理節點將所述客戶端請求路由到所述最優計算節點。
2.如權利要求1所述的方法，其中所述負載平衡裝置包括負載平衡和失效備援算法。
3.如權利要求1所述的方法，其中所述第二網絡包括強加在所述第一網絡之上的疊加網。
4.如權利要求1所述的方法，其中所述業務處理節點檢查所述重定向網絡業務并將所有源自相同的客戶端會話的客戶端請求路由到相同的最優計算節點。
5.如權利要求1所述的方法，其中經由第一網絡內的域名接入所述網絡可接入的計算機服務，并且其中所述重定向網絡業務的裝置分析所述網絡可接入計算機服務的所述域名為所述第二網絡的所述業務處理節點的IP地址。
6.如權利要求1所述的方法，其中所述網絡可接入計算機服務是經由第一網絡內的域名接入的，并且其中所述重定向網絡業務的裝置將CNAME添加到所述網絡可接入計算機服務的所述域名的域名服務(DNQ記錄中，并解析CNAME為所述第二網絡的所述業務處理節點的IP地址。
7.如權利要求1所述的方法，其中所述網絡可接入計算機服務是經由第一網絡內的域名接入的，并且其中所述第二網絡還包括域名服務器(DNQ節點，并且其中所述DNS節點接收所述域名的客戶端DNS查詢并且解析所述網絡可接入計算機服務的所述域名為所述第二網絡的所述業務處理節點的IP地址。
8.如權利要求1所述的方法，其中基于到該請求發起的客戶端的所述業務處理節點的地理周邊選擇所述業務處理節點。
9.如權利要求1所述的方法，其中基于與所述第二網絡的所述業務處理節點的負載條件相關的度量來選擇所述業務處理節點。
10.如權利要求1所述的方法，其中基于與所述第二網絡的所述業務處理節點的性能統計相關的度量來選擇所述業務處理節點。
11.如權利要求1所述的方法，其中基于到所述業務處理節點的映射客戶端的粘性會話表來選擇所述業務處理節點。
12.如權利要求2所述的方法，其中基于所述負載平衡算法確定所述最優計算節點，并且其中所述負載平衡算法利用最優計算節點性能、最低計算成本、輪叫或加權業務分配計算規則之一。
13.如權利要求1所述的方法，其中所述業務處理節點包括虛擬機器節點。
14.如權利要求1所述的方法，其中所述第二網絡包括在不同的地理位置分配的業務處理節點。
15.如權利要求1所述的方法，還包括提供監視裝置，用于監視所述業務處理節點和所述計算節點的狀態。
16.如權利要求15所述的方法，其中在檢測到失敗的業務處理節點或失敗的計算節點時，分別將實時網絡業務重定向到非失敗的業務處理節點或將客戶端請求路由到非失敗的計算節點。
17.如權利要求15所述的方法，其中基于來自所述監控裝置的反饋實時確定所述最優計算節點。
18.如權利要求1所述的方法，其中所述第二網絡通過動態調整業務處理節點的數量來實時縮放其處理容量和網絡容量。
19.如權利要求1所述的方法，其中所述計算機服務包括web應用、web服務或電子郵件服務之一。
20.一種在運行網絡可接入計算機服務的計算節點組提供負載平衡和失效備援的系統，包括在計算節點組和多個客戶端之間提供網絡連接的第一網絡；計算機服務，其中所述計算機服務處于所述計算節點組包括的一個或多個服務器上， 并經由所述第一網絡可被客戶端接入；包括多個業務處理節點和負載平衡裝置的第二網絡，并且其中所述負載平衡裝置被配置為在運行所述計算機服務的所述計算節點組提供負載平衡；重定向網絡業務的裝置，該網絡業務包括客戶端請求從所述第一網絡向所述第二網絡接入所述計算機服務；選擇所述第二網絡的業務處理節點的裝置，所述第二網絡接收所述重定向的網絡業務，對于接入所述計算機服務的每個客戶端請求，經由所述負載平衡裝置確定在由所述業務處理節點運行所述計算機服務的所述計算節點組的最優計算節點的裝置；以及經由所述第二網絡由所述業務處理節點將所述客戶端請求路由到所述最優計算節點的裝置。
21.如權利要求20所述的系統，其中所述負載平衡裝置包括負載平衡和失效備援算法。
22.如權利要求20所述的系統，其中所述第二網絡包括強加在所述第一網絡之上的疊加網。
23.如權利要求20所述的系統，還包括所述業務處理節點檢查所述重定向網絡業務的裝置以及將所有源自相同的客戶端會話的客戶端請求路由到相同的最優計算節點的裝置。
24.如權利要求20所述的系統，其中經由第一網絡內的域名接入所述網絡可接入的計算機服務，并且其中所述重定向網絡業務的裝置分析所述網絡可接入計算機服務的所述域名為所述第二網絡的所述業務處理節點的IP地址。
25.如權利要求20所述的系統，其中所述網絡可接入計算機服務是經由第一網絡內的域名接入的，并且其中所述重定向網絡業務的裝置將CNAME添加到所述網絡可接入計算機服務的所述域名的域名服務(DNQ記錄中，并解析CNAME為所述第二網絡的所述業務處理節點的IP地址。
26.如權利要求20所述的系統，其中所述網絡可接入計算機服務是經由第一網絡內的域名接入的，并且其中所述第二網絡還包括域名服務器(DNQ節點，并且其中所述DNS節點接收所述域名的客戶端DNS查詢并且解析所述網絡可接入計算機服務的所述域名為所述第二網絡的所述業務處理節點的IP地址。
27.如權利要求20所述的系統，其中基于到該請求發起的客戶端的所述業務處理節點的地理周邊選擇所述業務處理節點。
28.如權利要求20所述的系統，其中基于與所述第二網絡的所述業務處理節點的負載條件相關的度量來選擇所述業務處理節點。
29.如權利要求20所述的系統，其中基于與所述第二網絡的所述業務處理節點的性能統計相關的度量來選擇所述業務處理節點。
30.如權利要求20所述的系統，其中基于到所述業務處理節點的映射客戶端的粘性會話表來選擇所述業務處理節點。
31.如權利要求21所述的系統，其中基于所述負載平衡算法確定所述最優計算節點， 并且其中所述負載平衡算法利用最優計算節點性能、最低計算成本、輪叫或加權業務分配計算規則之一。
32.如權利要求20所述的系統，其中所述業務處理節點包括虛擬機器節點。
33.如權利要求20所述的系統，其中所述第二網絡包括在不同的地理位置分配的業務處理節點。
34.如權利要求20所述的系統，還包括監視裝置，并且其中所述監視裝置監視所述業務處理節點和所述計算節點的狀態。
35.如權利要求34所述的系統，其中在所述監視裝置檢測到失敗的業務處理節點或失敗的計算節點時，所述系統分別將實時網絡業務重定向到非失敗的業務處理節點或將客戶端請求路由到非失敗的計算節點。
36.如權利要求34所述的系統，其中基于來自所述監控裝置的反饋實時確定所述最優計算節點。
37.如權利要求20所述的系統，其中所述第二網絡通過動態調整業務處理節點的數量來實時縮放其處理容量和網絡容量。
38.如權利要求20所述的系統，其中所述計算機服務包括web應用、web服務或電子郵件服務之一。
全文摘要
一種在運行網絡可接入計算機服務的計算節點組提供負載平衡和失效備援的方法，包括提供計算機服務，其中所述計算機服務存在于在所述計算節點組包含的一個或多個服務器上，并且經由第一網絡可被客戶端接入；提供包括多個業務處理節點和負載平衡裝置的第二網絡，并且其中所述負載平衡裝置被配置為在運行所述計算機服務的所述計算節點組提供負載平衡；提供重定向網絡業務的裝置，該網絡業務包括客戶端請求從所述第一網絡向所述第二網絡接入所述計算機服務；提供選擇所述第二網絡的業務處理節點的裝置，所述第二網絡接收所述重定向的網絡業務，并且經由所述重定向網絡業務的裝置重定向所述網絡業務到所述業務處理節點，所述網絡業務包括所述客戶端請求接入所述計算機服務；對于接入所述計算機服務的每個客戶端請求，經由所述負載平衡裝置確定在由所述業務處理節點運行所述計算機服務的所述計算節點集中的最優計算節點；以及經由所述第二網絡由所述業務處理節點將所述客戶端請求路由到所述最優計算節點。
文檔編號H04L12/56GK102439913SQ201080017922
公開日2012年5月2日 申請日期2010年2月26日 優先權日2009年2月27日
發明者羅伯特·布弗恩, 考持·維, 雷蒙德·斯塔塔 申請人:雅塔公司