若干種技術(shù)組成了完整的站點到站點恢復(fù)和多站點負(fù)載分布解決方案。在客戶端到服務(wù)器通信中，客戶端先尋找服務(wù)器的IP 地址，然后與服務(wù)器進行通信。發(fā)現(xiàn)服務(wù)器之后，客戶端與服務(wù)器通信，執(zhí)行事務(wù)處理。事務(wù)處理的

若干種技術(shù)組成了完整的站點到站點恢復(fù)和多站點負(fù)載分布解決方案。在客戶端到服務(wù)器通信中，客戶端先尋找服務(wù)器的IP 地址，然后與服務(wù)器進行通信。發(fā)現(xiàn)服務(wù)器之后，客戶端與服務(wù)器通信，執(zhí)行事務(wù)處理。事務(wù)處理的數(shù)據(jù)保存在數(shù)據(jù)中心內(nèi)。將客戶端請求路由到相應(yīng)服務(wù)器的任務(wù)在數(shù)據(jù)中心前端完成。在分布式數(shù)據(jù)中心環(huán)境中，必須將最終用戶請求路由到正在運行相應(yīng)應(yīng)用的數(shù)據(jù)中心。位于分布式數(shù)據(jù)中心前端的技術(shù)稱為請求路由。

站點選擇

多數(shù)應(yīng)用都使用某種形式的地址解析獲得需要與之通信的服務(wù)器的IP 地址。利用地址解析方法與服務(wù)器或主機通信的應(yīng)用包括Web 瀏覽器、telnet 和用戶桌面上的瘦型客戶端。獲得IP 地址之后，這些應(yīng)用將根據(jù)應(yīng)用要求以安全或非安全方式與服務(wù)器連接，以便執(zhí)行事務(wù)處理。

地址解析還可以包含服務(wù)器健康狀態(tài)跟蹤。跟蹤服務(wù)器狀態(tài)使地址解析機制能夠選擇最適合處理客戶端請求的服務(wù)器，以便提高解決方案的可用性。在遠(yuǎn)程數(shù)據(jù)中心部署了完成相同任務(wù)的冗余服務(wù)器的分布式數(shù)據(jù)中心環(huán)境中，可以在地址解析過程中將客戶端引導(dǎo)到相應(yīng)的數(shù)據(jù)中心。這種通過跟蹤服務(wù)器健康狀態(tài)將客戶端引導(dǎo)到相應(yīng)服務(wù)器的方法稱為請求路由。

將客戶端與相應(yīng)數(shù)據(jù)中心相連的站點選擇方法共有三種：

基于DNS 的請求路由

? HTTP 重定向

? 基于BGP/IGP的路徑狀態(tài)注入（RHI ） ?

基于DNS 的站點選擇

如圖1所示，第一種解決方案基于DNS 。通常情況下，與服務(wù)器連接時，第一步是將域名解析成IP 地址?？蛻舳说慕馕鲞^程將變成對本地DNS 服務(wù)器的DNS 請求，然后，DNS 服務(wù)器將沿著DNS 服務(wù)器等級結(jié)構(gòu)逐級向上，通過互聯(lián)網(wǎng)/內(nèi)部網(wǎng)上直到到達目的DNS 服務(wù)器為止。最后，目標(biāo)DNS 服務(wù)器將公布IP 地址。

圖1 基本DNS 操作

?

?

?

?

?

?

? 客戶端請求對www.foo.com 進行解析； DNS 代理將請求發(fā)送至根DNS ，根DNS 返回對于foo.com 的根DNS 的地址； DNS 代理將請求發(fā)送至對于foo.com 的根DNS ，該DNS 返回對于foo.com 的授權(quán)DNS 服務(wù)器的IP 地址； DNS 代理將請求發(fā)送至foo.com 的授權(quán)DNS 服務(wù)器，該DNS 返回對于www.foo.com 的IP 地址； DNS 代理將請求發(fā)送至www.foo.com 的授權(quán)DNS 服務(wù)器，該DNS 返回Web 服務(wù)器的IP 地址； DNS 代理向客戶端返回Web 服務(wù)器的IP 地址； 客戶端建立與Web 服務(wù)器的連接。

在最底層，DNS 提供深入到域結(jié)構(gòu)和子域結(jié)構(gòu)中的名稱到地址映射關(guān)系的分布式數(shù)據(jù)庫，每個域由權(quán)威名稱服務(wù)器獨立管理。名稱服務(wù)器將名稱到地址的對應(yīng)關(guān)系保存在資源記錄中。每條記錄包含相關(guān)的存活時間（TTL ）字段，以便確定其它名稱服務(wù)器保存該項的時間。

名稱服務(wù)器實施重復(fù)性或遞歸性查詢。

重復(fù)性查詢或者從本地數(shù)據(jù)庫返回查詢的答案（A 記錄），或者指向能夠回答查詢的另一臺名稱服務(wù)器（NS 記錄）；

? 遞歸性查詢將查詢完成名稱解析所需要的所有其它名稱服務(wù)器，并返回最終答案（A 記錄）。 ?

等級結(jié)構(gòu)中的多數(shù)名稱服務(wù)器只收發(fā)迭代性查詢。但是，本地名稱服務(wù)器通常接受來自客戶端的遞歸性查詢。遞歸性查詢將大部分解析負(fù)擔(dān)都放在一臺名稱服務(wù)器上。

在遞歸性查詢中，客戶端解析器首先向名稱服務(wù)器發(fā)出遞歸請求，要求名稱服務(wù)器提供某個域名的信息。然后，名稱服務(wù)器必須要么向客戶端提供所需的數(shù)據(jù)，要么返回錯誤信息，說明被請求的數(shù)據(jù)或者域名不存在。由于請求是遞歸性的，

名稱服務(wù)器不能將請求方引導(dǎo)到另一臺名稱服務(wù)器。如果名稱服務(wù)器非授權(quán)不能提供被請求的數(shù)據(jù)，它必須請求另一臺名稱服務(wù)器提供答案。它可以向其它名稱服務(wù)器發(fā)出遞歸性請求，迫使它們找到并返回答案（并傳遞關(guān)系）。當(dāng)然，DNS 代理也可以發(fā)送重復(fù)性請求，轉(zhuǎn)而由其它名稱服務(wù)器完成名稱解析任務(wù)。當(dāng)前的實施方案傾向于使用后一種方法，即根據(jù)引導(dǎo)一步步找到答案。

迭代性解析對被請求名稱服務(wù)器的要求較低。在迭代性解決方案中，名稱服務(wù)器只將它知道的最佳答案告知請求方，而不作進一步請求。

被請求的名稱服務(wù)器首先查詢自己的本地數(shù)據(jù)，包括高速緩存，看是否能找到被請求數(shù)據(jù)。如果找不到數(shù)據(jù)，它將盡最大努力為查詢方提供數(shù)據(jù)，幫助查詢方繼續(xù)執(zhí)行解析過程。通常情況下，它提供的數(shù)據(jù)是其它名稱服務(wù)器的名稱和地址。 在迭代性解析中，客戶端的解析器首先查詢本地的名稱服務(wù)器，然后由本地名稱服務(wù)器查詢眾多其它名稱服務(wù)器，以便為解析器找到答案。解析器查詢的每臺名稱服務(wù)器都將它引導(dǎo)到DNS 名稱域的下一層，即更接近答案的下一臺名稱服務(wù)器。最后，本地名稱服務(wù)器將查詢可提供數(shù)據(jù)的權(quán)威名稱服務(wù)器，并返回答案。 HTTP 重定向

目前，很多應(yīng)用都具有瀏覽器前端。由于瀏覽器的內(nèi)部已經(jīng)集成了HTTP 重定向，因而能夠在主服務(wù)器發(fā)生故障之后與備用服務(wù)器通信。在HTTP 重定向過程中，客戶端只經(jīng)歷一次地址解析過程。當(dāng)主服務(wù)器不可訪問時，客戶端將被重定向到備用服務(wù)器，而不需要重復(fù)地址解析過程。

一般情況下，HTTP 重定向的執(zhí)行過程如下。HTTP 擁有將用戶重定向到新位置的機制，稱為HTTP 重定向或HTTP-307（HTTP 重定向返回代碼）。獲得服務(wù)器的IP 地址之后，客戶端將建立與服務(wù)器的TCP 連接。首先，服務(wù)器將分析得到請求的第一個HTTP ?，F(xiàn)在，服務(wù)器可以看到被請求的實際內(nèi)容以及客戶端的IP 地址。如果需要重定向，服務(wù)器將向客戶端發(fā)出HTTP 重定向（307）請求，從而將客戶端引導(dǎo)到擁有被請求內(nèi)容的站點。之后，客戶端將與新主機建立TCP 連接，并請求提供實際內(nèi)容。

HTTP 重定向機制如圖2所示。

圖2 HTTP重定向的基本操作方式

HTTP 重定向的優(yōu)點：

可以看到被請求的內(nèi)容；

? 能看到客戶端的IP 地址，有利于在多站點負(fù)載分布中選擇最適合客戶端的站點。 ?

HTTP 重定向的缺點：

為完成重定向操作，客戶端永遠(yuǎn)都必須先進入主站點，然后再轉(zhuǎn)移到其它站點；

? 存在書簽標(biāo)定問題，用戶可以將瀏覽器標(biāo)記為某個站點，但不能是全球的http://www.foo.com站點，從而繞過了請求路由器系統(tǒng)；

? HTTP 重定向只適用于HTTP 流量，某些應(yīng)用由于沒有瀏覽器前端，因而不支持HTTP 重定向。 ?

路由健康注入

路由健康注入（RHI ）是一種機制，它允許兩個數(shù)據(jù)中心使用同一個IP 地址。這意味著同一個IP 地址（主機路徑）被發(fā)布為不同的metric 。上游路由器可以同時看到兩條路徑，并將metric 更好的路徑插入到其路由表中。當(dāng)設(shè)備啟用RHI 時，它將在VIP 可用時將靜態(tài)路徑注入到設(shè)備的路由表中。當(dāng)VIP 失效時，該靜態(tài)路徑將刪除。如果設(shè)備發(fā)生了故障，上游路由器使用的另一條路徑將到達服務(wù)器，從而實現(xiàn)高可用性。值得注意的是，只有當(dāng)服務(wù)器運行正常時，設(shè)備才公布主機路徑。

注意由于多數(shù)路由器不向互聯(lián)網(wǎng)傳送主機路徑信息，因此，公布主機路由的RHI 通常只限于在內(nèi)部網(wǎng)中使用。

同一個IP 地址還可以從稱為備用位置但metric 不同的另一個位置公布。這種機制與前面介紹的方法非常相似，惟一的不同是路徑能夠用不同metric 公布。 對于支持互聯(lián)網(wǎng)用戶的應(yīng)用，可以在互聯(lián)網(wǎng)邊緣匯總主機路徑，然后重新分布到BGP 。這些路徑可以利用思科BGP 的有條件宣告特性從備用位置宣告。只要IP 地址在主站點有效，或者與多家電信運營商的鏈接有效，并且不從備用站點公布IP 地址，這種方式就可以正常操作。

RHI 的優(yōu)點包括：

快速收斂（IGP 收斂）；

? 自我控制，不依賴于內(nèi)容路由設(shè)備；

? 適用于業(yè)務(wù)連續(xù)性和災(zāi)難恢復(fù)解決方案；

? 單一IP 地址。 ?

RHI 的缺點包括：

? 不能用于站點到站點負(fù)載均衡，因為路由表只有一個條目。通常只用于主用/備用配置。

支持平臺

思科的很多產(chǎn)品都支持分布式數(shù)據(jù)中心的請求路由。這些產(chǎn)品的功能各不相同。支持這些功能的所有產(chǎn)品包括：

?

?

?

?

? 全球站點選擇器（GSS 4480） 分布式導(dǎo)向器 分布式導(dǎo)向器和IOS SLB/DFP WebNS 與全球服務(wù)器負(fù)載均衡 Cat6K 平臺的內(nèi)容交換模塊

全球站點選擇器

思科GSS 4480能夠?qū)崿F(xiàn)分布式數(shù)據(jù)中心的負(fù)載均衡。GSS 能夠與服務(wù)器負(fù)載均衡產(chǎn)品互操作，例如Cisco CSS 11000和CSS 11500內(nèi)容服務(wù)交換機以及Cisco Catalyst? 6500系列交換機的內(nèi)容交換模塊（CSM ）。

思科GSS 4480產(chǎn)品提供以下主要功能：

為思科的內(nèi)容交換機提供可以擴展的專用硬件平臺，通過檢測站點中斷或站點擁塞，保證應(yīng)用永遠(yuǎn)可用；

? 利用不同的站點選擇算法，改善全球數(shù)據(jù)中心或站點選擇過程； ? 提供集中子域管理，作為現(xiàn)有DNS 基礎(chǔ)設(shè)施的補充。 ?

利用思科GSS 4480，由于企業(yè)能夠在主數(shù)據(jù)中心發(fā)生故障時將客戶端引導(dǎo)至備用數(shù)據(jù)中心，因而能部署互聯(lián)網(wǎng)和內(nèi)部網(wǎng)應(yīng)用。思科GSS 4480能夠連續(xù)監(jiān)控多個數(shù)據(jù)中心的服務(wù)器負(fù)載均衡設(shè)備的負(fù)載和狀態(tài)，并將客戶端重定向至負(fù)載較低的數(shù)據(jù)中心。每個數(shù)據(jù)中心的負(fù)載情況由用戶確定。

GSS 的主要特性和優(yōu)點如下：

?

?

?

?

?

? 為電子商務(wù)應(yīng)用提供站點持續(xù)性； 提供對災(zāi)難恢復(fù)和多站點部署部署至關(guān)重要的架構(gòu)； 提供對DNS 解析過程的集中指揮和控制； 提供對DNS 請求的專門處理，以提高性能和可擴展性； 提供DNS 快速處理特性。思科GSS 4480可以實時地根據(jù)本地DNS 與多個站點之間的RTT ，將客戶端引導(dǎo)至距離最近的數(shù)據(jù)中心； 支持基于Web 的圖形用戶界面（GUI ）和向?qū)В珊喕渲谩?/p>

圖3 GSS的基本操作方式

圖3所示是GSS 的基本操作方式，各步驟內(nèi)容如下：

GSS 檢測服務(wù)器狀態(tài)，以便了解服務(wù)器的狀態(tài)和負(fù)載情況；

? 客戶端請求解析HTTP 請求中的URL ；

? 本地DNS 服務(wù)器執(zhí)行DNS 查詢，GSS 根據(jù)預(yù)定算法返回IP 地址； ? 客戶端與服務(wù)器連接。 ?

分布式導(dǎo)向器

思科分布式導(dǎo)向器是一種基于DNS 的技術(shù)，能夠?qū)崿F(xiàn)設(shè)立在多個地點或獨立拓?fù)渲械臄?shù)據(jù)中心之間的負(fù)載均衡。其目標(biāo)是將客戶端引導(dǎo)至最適合或最好的數(shù)據(jù)中心，使用的方法是通過導(dǎo)向器響應(yīng)協(xié)議（DRP ）與網(wǎng)絡(luò)上的其它思科路由器通信。 如果沒有分布式導(dǎo)向器，最終用戶需要利用輪循DNS 以循環(huán)方式與不同的服務(wù)器相連。由于DNS 不了解網(wǎng)絡(luò)拓?fù)浠蚍?wù)器可用性，因而會使最終用戶與遠(yuǎn)距離或不可用的服務(wù)器相連，從而降低訪問性能，提高傳輸成本。最后，由于循環(huán)DNS 以循環(huán)方式向服務(wù)器分布服務(wù)，因而只能平等對待所有服務(wù)器，致使功能低下的服務(wù)器不堪重負(fù)，功能強大的服務(wù)器（通常比較昂貴）則任務(wù)不飽滿。無論是基于TCP 還是UDP 的IP 服務(wù)，都可以使用分布式導(dǎo)向器分布。

例如，由于能夠利用智能監(jiān)控服務(wù)器狀態(tài)，分布式導(dǎo)向器能夠依據(jù)客戶端到服務(wù)器拓?fù)溧徑群?或客戶端到服務(wù)器鏈路延遲（往返時間RTT ）的大小，透明地將最終用戶服務(wù)請求引導(dǎo)至最適合的服務(wù)器，最終提高最終用戶感受到的訪問性能，并降低按需撥號路由環(huán)境中的傳輸成本。

思科分布式導(dǎo)向器在執(zhí)行負(fù)載分布時，能夠通過服務(wù)器可用性、相對的客戶端到服務(wù)器拓?fù)溧徑龋ā熬嚯x”）和客戶端到服務(wù)器鏈路延遲大小確定“最佳”服務(wù)器。換言之，用戶只需要一個子域名稱或全局資源定位符（URL ）嵌入式主機名稱，就能訪問一組分布式服務(wù)器，而不需要從很多的可能站點中進行選擇?？傊?，思科分布式導(dǎo)向器能夠利用網(wǎng)絡(luò)中的智能自動、動態(tài)、有效地為用戶挑選出“最佳”服務(wù)器。

分布式導(dǎo)向器利用導(dǎo)向器響應(yīng)協(xié)議（DRP ）——由思科系統(tǒng)公司開發(fā)的一種基于UDP 的應(yīng)用——執(zhí)行以下兩種任務(wù)：

從DRP 服務(wù)器代理查詢分布式服務(wù)器與客戶端之間的BGP 和IGP 路由表指標(biāo)，確定客戶端到服務(wù)器的拓?fù)溧徑?。關(guān)于這些DRP 指標(biāo)，我們將在本文的后面部分討論。

? 從DRP 服務(wù)器代理查詢客戶端到服務(wù)器鏈路延遲指標(biāo)。關(guān)于循環(huán)時間DRP 指標(biāo)的使用，我們將在本文的后面部分討論。 ?

分布式導(dǎo)向器的基本操作方式如圖4所示。

圖4 分布式導(dǎo)向器的基本操作方式

DD 檢測服務(wù)器狀態(tài)，以便了解服務(wù)器的運行狀況；

? 客戶端請求解析www.foo.com ；

? 本地DNS 服務(wù)器執(zhí)行迭代性DNS 查詢，DD 在按照配置咨詢DRP 代理之后返回IP 地址；

? 客戶端與服務(wù)器相連，完成事務(wù)處理。 ?

分布式導(dǎo)向器、IOS-SLB 和動態(tài)反饋協(xié)議

如前所述，分布式導(dǎo)向器利用各種指標(biāo)將客戶端引導(dǎo)至相應(yīng)的全球服務(wù)器群或分布式數(shù)據(jù)中心。運行動態(tài)反饋協(xié)議（DFP ）的IOS-SLB 向分布式導(dǎo)向器環(huán)境提供其它屬性，以便確定哪個站點最適合處理客戶端的請求。

Cisco IOS 服務(wù)器負(fù)載均衡（SLB ）特性是提供服務(wù)器負(fù)載均衡功能的Cisco IOS 軟件解決方案。服務(wù)器和負(fù)載均衡設(shè)備通過DFP 機制向分布式導(dǎo)向器提供關(guān)于設(shè)備負(fù)載狀況的反饋。分布式導(dǎo)向器利用這種反饋靈活地將客戶端引導(dǎo)至負(fù)載最低的數(shù)據(jù)中心。

WebNS 和全球服務(wù)器負(fù)載均衡

Cisco 11000系列內(nèi)容服務(wù)交換機（CSS ）利用全球服務(wù)器負(fù)載均衡（GSLB ）和網(wǎng)絡(luò)鄰近度方法，將內(nèi)容請求分布到多個站點。

Cisco 11000系列CSS 能夠通過GSLB 將內(nèi)容請求分布到多個站點，并利用內(nèi)容智能根據(jù)被請求的內(nèi)容和內(nèi)容的所在地分布請求。網(wǎng)絡(luò)鄰近度是GSLB 的增強版本，能夠根據(jù)到達內(nèi)容使用者所在位置的全程時間選擇距離最近或最靠近的Web 站點。顯然，網(wǎng)絡(luò)鄰近度的全球持續(xù)性很高，因為只要網(wǎng)絡(luò)拓?fù)浔３植蛔儯瑏碜阅硞€位置的所有請求的鄰近度計算都是相同的。

WebNS 還提供可以擴展的解決方案，在不犧牲鄰近度或GSLB 的前提下提供粘性站點選擇。在這種增強版本中，管理員能夠利用粘性數(shù)據(jù)庫配置D 代理的粘性時間。TTL 值的范圍在幾分鐘到幾天之間。

內(nèi)容服務(wù)交換機執(zhí)行的基本GSLB 操作如圖5所示。

圖5 使用內(nèi)容服務(wù)交換機執(zhí)行的基本GSLB 操作

每個CSS 檢測服務(wù)器狀態(tài)，以便了解服務(wù)器的運行狀況，并利用TCP 連接交換服務(wù)器可用性信息；

? 客戶端請求解析www.foo.com ；

? 本地DNS 服務(wù)器執(zhí)行迭代性DNS 請求，CSS 根據(jù)配置返回IP 地址； ? 客戶端與服務(wù)器連接，完成事務(wù)處理。 ?

Catalyst 6000的內(nèi)容交換模塊

思科內(nèi)容交換模塊（CSM ）將第四到七層高級內(nèi)容交換集成到Cisco Catalyst 6500系列或Cisco 7600系列互聯(lián)網(wǎng)路由器中。CSM 提供高性能、高可用性負(fù)載均衡，并能夠充分利用平臺中固有的全部第二層、第三層和QoS 特性。CSM 不但能直接與思科分布式導(dǎo)向器通信，執(zhí)行GSLB 功能，還支持DFP 和RHI 特性。 利用CSM 執(zhí)行路徑狀態(tài)注入的方式如圖6所示。當(dāng)CSM 上的RHI 啟用之后，CSM 將把靜態(tài)路徑注入MSFC 的路由表中，然后由MSFC 重新分布。

圖6 帶RHI 的CSM

?

?

?

?

? 每個CSM 檢測服務(wù)器狀態(tài)，如果服務(wù)器可用，則將靜態(tài)路徑注入MSFC 路由表，并與兩臺Catalyst 6500的各種指標(biāo)一同發(fā)布（相同的IP 地址與兩個位置的不同指標(biāo)一同發(fā)布）； 主機路徑被傳輸?shù)缴嫌温酚善?，指?biāo)最好的路徑將得到上游路由器的采用； 客戶端請求解析www.foo.com ； 本地DNS 服務(wù)器執(zhí)行迭代性DNS 查詢，返回IP 地址； 客戶端與適當(dāng)?shù)腤eb 服務(wù)器相連，因為發(fā)布的路徑的指標(biāo)更好。 結(jié)論