專利名稱：跨層2域的負載平衡的制作方法
跨層2域的負載平衡背景負載平衡器可以是可以將一組請求分布在能夠處理請求的一組服務器上的網絡基礎設施的關鍵部件。常規的負載平衡器可以包括各對設備，每一對設備都是專用硬件。因為使用專用硬件，所以常規的負載平衡器往往花費大量金錢。另一缺點是它們使用按比例擴大策略單對負載平衡器可以應對受硬件容量限制的多個并發請求。購買包含具有更多容量的硬件的更強大的負載平衡器才能處理附加的請求。在緩解網絡中的流量瓶頸方面， 直接服務器返回(DSR)優化是有用的。然而，常規的負載平衡器的缺點是這種技術是通常限于網絡的單個虛擬局域網(VLAN)。概述本申請涉及網絡配置，且尤其涉及可擴展負載平衡網絡配置。一種實現包括被耦合到可擴展負載平衡系統的外部客戶機。可擴展負載平衡系統包括被配置為對來自該外部客戶機的分組流的各單獨的傳入分組進行封裝的負載平衡層。該負載平衡層被進一步配置為將傳入分組路由到系統上的各目標設備。各目標設備可以跨多個IP子網。各傳入分組可以在到達各單獨的目標設備之前穿過負載平衡層的一個或多個負載平衡器。各單獨的目標設備可以被配置為將分組流的至少一些傳出分組路由到外部客戶機而不穿過一個或多個負載平衡器中的任何一個。附圖簡述附圖示出了本申請中傳達的概念的實現。所示實現的特征可通過參考以下結合附圖的描述來更容易地理解。只要可行，各附圖中相同的附圖標記用來指代相同的元素。 此外，每一個附圖標記的最左邊的數字傳達其中首次引入該附圖標記的附圖及相關聯的討論。
圖1-圖5示出可以采用根據一些實現的各概念中的一些的網絡環境。圖6示出可以采用根據一些實現的各概念中的一些的可擴展負載平衡體系結構。圖7-圖8示出根據各概念的一些實現的在圖1-圖6中介紹的一些組件。圖9示出根據一些實現的與各概念中的一些相一致的散列映射技術。圖10和圖11示出根據一些實現的可以實現可擴展負載平衡概念中的一些的流程圖。詳細描述介紹/概覽網絡負載平衡器可以通過將傳入分組分類成會話并將各單獨的會話的分組流量分發給所選擇的資源(例如，服務器)來幫助增強網絡中的資源的利用。為了輔助緩解在負載平衡器處分組流量的瓶頸，可以利用諸如直接服務器返回(DSR)等優化技術。DSR允許來自網絡的傳出分組流量繞過負載平衡器而不是如同傳入分組流量那樣穿過它。然而，這種技術通常限于網絡的單個虛擬局域網(VLAN)。相反，圖1示出各概念中的一些的高級視圖。網絡示例
圖1示出其中外部客戶機102可以經由因特網106與可擴展負載平衡系統104通信的網絡環境100。負載平衡或分散可以被認為是聯網設備可以將流量分散在一組有效下一跳的任何合適手段。可擴展負載平衡系統104可以包括因為可以支持在110處指示的本質上無限量的目標設備而可擴展的負載平衡功能層108。在這種情況中，術語‘本質上無限’可以一般地意指控制可擴展負載平衡系統104的實體所期望的那樣多的目標設備。舉例來說，目標設備的數量可以是數萬個或數十萬個或更多個。負載平衡功能層108被配置為使得來自外部客戶機102的通信可以穿過，且被負載平衡功能分發到各單獨的目標設備，如箭頭112所指示。然而，由箭頭114表示的返回通信不需要在回到外部客戶機102的路徑上穿過負載平衡功能層108。簡言之，一些實現可以利用層2域間分組傳輸技術來實現負載平衡功能108。在一些情況中，這些層2域間分組傳輸技術可以允許跨越多個IP子網使用諸如DSR等的負載平衡優化技術，且由此允許使用本質上無限的目標設備110。出于可擴展性和其他原因，使用網際協議的網絡可以將共享它們的IP地址中的普通位前綴的主機劃分到IP子網中。通常，單個子網的范圍限于單個VLAN的范圍。允許使用帶有來自不同的子網的網際協議(IP) 地址的目標設備110可以消除用于負載平衡器的先前設計的顯著限制。個體IP子網可以與可擴展負載平衡系統104的若干層2域中的一個相關聯。在一個或多個實施方式中，可以使用例如IP-in-IP(在IP里面封裝IP)封裝來封裝分組流的個體傳入分組。這可以例如由負載平衡功能108的多路復用器(MUX或Mux)來完成。通過在到達個體目標設備之前穿過負載平衡功能108，經封裝的傳入分組可以被路由到在可擴展負載平衡系統104上的資源或目標設備110。在至少一些實施方式中，負載平衡功能可以使用諸如DSR等的優化技術來減少/最小化負載平衡功能上的分組流流量。目標設備(例如，服務器)可以與多個IP子網或VLAN相關聯且因而跨越多個IP子網或VLAN。與個體目標設備相關聯的組件(例如，軟件組件)可以解封所接收的傳入分組以便獲得IP信息。然后，可以將結果(傳出分組)從可擴展負載平衡系統104路由到外部客戶機102(例如，接收傳入分組中的一個或多個的客戶機)而不穿過(即穿越)負載平衡功能108。簡要地，可擴展負載平衡系統104可以啟用新的功能，包括與負載分散和無償地址解析協議(G-ARP)相關聯的功能。下面詳細敘述這些概念。圖2示出根據一個或多個實施方式的另一示例網絡環境200。網絡環境200提供可以實現上面參考圖1介紹的概念的示例結構或組件。網絡環境200可以包括經由因特網 106或其他網絡與可擴展負載平衡系統204通信的外部客戶機202。可擴展負載平衡系統 204可以包括一組路由器206、一組動態負載平衡器(DLB) 208和一組目標設備210。在這個實例中，該組路由器206表現為路由器206(1)和206(n)。該組DLB 208表現為分別包括多路復用器(即，MUX) 212(1)和212 (η)的DLB 208(1)和208 (η)。該組目標設備210表現為應用服務器214(1)和214 (η)以及本地負載平衡器216 (1)和216 (η)。在218處概括示出的虛線箭頭示出在可擴展負載平衡系統204的各組件之間的潛在通信路徑。粗實線箭頭220 (1)和220 (2)示出通過網絡環境200從外部客戶機202到應用服務器214(1)的兩個潛在的分組流路徑。粗實線箭頭222表示從應用服務器214(1)到外部客戶機202的返回分組流路徑。舉例來說，粗箭頭220(1)和220( 可以表示來自外部客戶機202的由應用服務器214(1)處理的搜索查詢。因而，應用服務器214(1)可以被稱為‘目標設備’。盡管在這里目標設備是應用層應用服務器，但應明白和理解，該示例目標設備可以另外或替代地是另一類型的目標設備，如本地負載平衡器——例如應用層負載平衡器。值得注意的是，盡管傳入分組流(即，粗箭頭220(1)和220( )穿過該組DLB 208 的成員，但傳出返回分組流(即，粗箭頭22 并不必定穿過負載平衡器而是改為繞過DLB。 結果，可以減少在DLB中的一個或多個處的分組流流量的瓶頸或使其最小化。在至少一些實施方式中，這可以通過利用DSR優化技術來實現。下面描述示例DSR優化技術。在至少一些實施方式中，DLB 208(1)和208 (η)中的一個或多個上的MUX 212(1) 和/或212(n)可以使用IP-in-IP(IP中IP)封裝來將分組流發送給目標設備210。盡管提供了具體的封裝示例，但封裝可以是用于對分組進行定址以便沿著路徑或路徑的一部分傳輸的任何手段。另外，目標設備上的解封組件222 (1)-222 (η)可以解封傳入分組流的一個或多個分組并將結果(即，傳出分組流)發送回去給外部客戶機202。在一種情況中，可以在目標設備210上將解封組件222 (1) -222 (η)表示成可由目標設備的處理器執行的軟件組件。在這種實現中，路由器206可以使用等價多路徑(ECMP)來將分組負載分散在DLB 208的MUX 212(1)和212(n)上。進一步，MUX可以向發送給目標設備210的各分組提供一致散列。在各實現中的一些中，可以在諸如服務器等各單獨的設備上實現DLB 208和目標設備210。舉例來說，諸如服務器等單個計算設備可以包括帶有MUX 212(1)和應用服務器 214(1)的DLB 208(1)。在其他實現中，DLB可以在與各目標設備分開的設備上。在操作中，在這一示例中的DLB 208中的每一個可以被配置為提供用于管理虛擬 IP-直接IP(VIP-DIP)映射的VIP到DIP映射(例如，VIP — {槽！，槽2，槽3，· · ·，槽N})的應用程序接口(API)。各單獨的槽被分配給DIP。單個DIP可以在這種VIP到DIP映射中出現多次。這種VIP到DIP映射可以被稱為VipMap (虛擬ip映射)。盡管以上被描述為在單個VIP地址和一列DIP地址之間的映射，但應理解，每一地址也可以與端口號(例如，諸如端口 80等傳輸控制協議(TCP)端口)相關聯。在這種廣義化中，VIP地址或VIP地址和端口號可以被映射到包括作為單獨的DIP地址或DIP地址和端口號的條目的列表。單個DIP地址可以出現多次，它可以單獨地、或與不同的端口號一起、 或與相同的端口號、以任何組合一起出現。也可以存在映射到各DIP和各DIP、端口號組合的相同列表的多個VIP或多個VIP、端口號組合。DLB 208的各單獨的MUX 212 (1)-212 (η) 可以各自被配置為對來自各單獨的傳入分組流分組的首部字段進行散列并將各單獨的分組發送給與目標設備210相關聯的適當的IP地址。例如，考慮示例傳入分組。DLB中的一個或兩者可以通過計算下式來對示例傳入分組散列并選擇槽(例如，{槽工，槽2，槽3，...， 槽Ν}槽i =散列(分組首部字段)模N其中N是VIP-DIP映射中的槽的數量。然后，(各)DLB的MUX可以將示例傳入分組發送給槽i中所指示的地址。這種設計的潛在優點是作為同一流(例如，其中所有分組共享IP源地址、IP目的地地址、TCP源端口、TCP目的地端口和IP協議號的相同5元組的 TCP流)的一部分的各分組可以被轉發給相同的目標設備210，而不管哪個DLB 208處理該分組。
圖3示出提供對以上所描述的網絡環境200的替代方案的又一示例網絡環境300。 簡言之，網絡環境300類似于網絡環境200。然而，在網絡環境300中，本地負載平衡器 (LLB)可以被認為是在DLB和目標設備之間的居間層。具體地，網絡環境300包括經由因特網或其他網絡306與可擴展網絡平衡系統304通信的外部客戶機302。網絡平衡系統304 包括路由器層308、DLB層310、LLB層312和目標設備層314。在這種情況中，目標設備層 314 包括應用服務器 314 (1)-314 (n)。LLB 層 312 包括 LLB 312 (1)-312 (η) 解封組件316 (1)-316 (η)分別駐留在LLB 312 (1)-312 (η)上。在這種配置中，可以將外部客戶機的通信封裝在DLB層310處，且當在LLB層312處收到時就解封。然后，可以將該通信轉發給適當的應用服務器314(1)-314(η)。到外部客戶機302的任何返回通信可以分別繞過DLB層310和LLB層312。繞過DLB層和LLB層可以避免潛在瓶頸和/或為傳入的通信保留系統資源。圖4示出可擴展負載平衡系統的網絡環境400的各組件的又一高級示例。在這個實例中，這些組件包括查詢生成器402(1)-402 (η)、接入路由器(AR) 404 (1)-404 (η)、層 2聚集交換機406 (1)-406 (η)和架頂式(ToR)交換機408 (1)-408 (η)。各ToR可以與諸如 MUX(M)、健康監視器(H)、服務器(S)、負載平衡器(B)等各種服務器機架組件進行通信。對于提供特定服務的VIPl，各AR 404 (1)-404 (η)可以被配置為具有N個路線，這些路線中的每一個將其下一跳指向具有相同成本的中間IP(IIP)地址(ΙΙΡ1至ΙΙΡΝ)。在該AR上，各路線都可以是該VIP的下一跳。因此，該AR可以在N個IIP地址中均勻地分發流量。這些路線可以被配置成該AR上的具有相等規格的靜態路線(即，等價靜態路線(下面參考圖5討論))。替代地，可以經由與該AR具有適當會話的路由協議(例如，邊界網關協議(BGP)或開放最短路徑優先(OSPF))發言者(speaker)來動態地建立這些路線。另外，該AR可以被配置為通告該VIP。可以跨各MUX (M)劃分各IIP。除了其自己的IP地址 (MIP)之外，MUX也可以被配置為帶有一個或多個IIP地址，以使得它可以應答對所配置的 IIP的ARP請求。因此，單獨的MUX可以接收所轉發的流量中的一份。一旦接收到分組，該單獨的MUX可以運行一致散列算法以便選擇一個活動的DLB來轉發該流量。基于相同的一組活動DLB，MUX可以使用相同的一致散列算法。因此，可以將分組轉發給相同的DLB而不管哪個MUX從AR 404 (1)-404 (η)接收到它。注意，在向該池添加或從中移除新的DLB時，這可以觸發一些本地配置改變；然而，可以保持現有的連接。圖5示出用于配置N個等價靜態路線的網絡環境500和關聯的技術。在這種情況中，網絡環境500包括接入路由器404(1)(在圖4中已介紹)、IIP(I)-IIP(n)、MUX 212 (1)-212 (η)和DLB 208 (1)-208 (η)(在圖2中已介紹)。網絡環境500可為每一 VIP配置N個等價靜態路線。這些等價靜態路線的下一跳指向中間IP(IIP)地址IIP(I)-IIP(Ii)。 可以從獨立于VIP池和DIP池的分開的地址池取出這些IIP地址。這種實現也可以開啟負載分散以使得流量將被平均分發給這N個IIP地址。在另一實施方式中，可以使用諸如到各路由器的BGP連接等路由協議來將活躍的且取得每一 VIP的分組的MUX通知給它們。各種實現可以解決在各MUX模塊來來往往時如何保留長期運行連接的問題。在一些實現中所利用的一種方法可以是保留在每一 MUX處處理的各單獨的流的狀態，并在各單獨的MUX被添加到可擴展負載平衡系統時將此狀態的副本提供給各單獨的MUX。為了在不斷開現有連接的情況下處理MUX的添加或移除，一個替代方案是在每當由任何MUX第一次處理新連接時創建狀態信息。可以在各MUX之間或者通過對等機制直接地共享這一狀態或者通過將這一狀態發送給邏輯上集中式的存儲來間接地共享這一狀態，需要處理連接的各分組的任何MUX可以從該邏輯上集中式的存儲確定其他MUX已經將該連接的各分組發送到的 DIP。一種要求少得多的狀態共享且因此更加可擴展的替代實現是，MUX或者使用VIP 和DIP之間的當前映射(即，VipMap)來轉發分組或者處于它們從使用一個VipMap (V)來轉發分組改變為使用另一 VipMap (V’ )來轉發分組的過渡時間段中。在這種實施方式中， 可以使得各MUX就V、V’和它們的當前過渡狀態達成一致(即是說，它們是處于在V和V’ 之間的過渡狀態中還是它們都已經對所有分組僅使用V’而開始)。在不處于過渡時，所有 MUX使用當前的VipMap來轉發所有分組。在處于過渡時，每當它們看到新連接的分組(例如，TCP SYN分組)時，MUX創建一段本地狀態。在轉發與指示新連接的那些分組不同的分組時，MUX查看它是否擁有該連接的狀態。如果它擁有狀態，則MUX使用新VipMap V’來轉發該分組，否則它使用舊VipMap V來轉發該分組。簡言之，在至少一些配置中，MUX 212 (1)-212 (η)可以具有下列主要組件(1)向路由器主張擁有一 IIP并接收該IIP的流量的IIP模塊，(2)確定哪個DLB208(l)-208(n) 轉發該流量的一致散列模塊，(3)修改分組的分組重寫器，(4)本地DLB監視器。在各種實現中，可以在容易獲得的(即，商品)服務器上和/或在路由器上實現這些組件中的任何或全部。下面參考圖6-圖8更詳細地描述各MUX組件。IIP 模塊(IIP(I)-IIP(η))可以負責通過 ARP 協議將 MUX 212 (1)-212 (η)注冊到路由器。基本上，IIP模塊可以在路由器上建立IIP地址和MUX MAC地址的IP-MAC映射。考慮示例函數‘bool AddIP (IP Address iip)，在這一示例函數中，IIP地址可作為次級IP地址合計在MUX接口上。注意，MUX可能具有多個次級IP地址。‘AddlPO’可以使得MUX網絡棧發送3個無償ARP (G-ARP)請求，這些無償ARP請求可以更新路由器的ARP 表(或觸發其自身上的IP地址沖突檢測)。出于解釋的目的，考慮示例函數“RemovelP(IPAddress iip) ”此示例函數可以從 MUX接口移除IIP地址。還考慮示例函數“SendARP()”。此示例函數可以強制發送G-ARP 請求。這一 G-ARP請求可以作為IIP-MAC映射的正確性的預防措施而發送。G-ARP和地址沖突檢測在將IP地址添加到該接口時，操作系統(OS)可以廣播G-ARP (在同一 L2域內)。 此G-ARP請求可以請求它正在主張的IP地址。如果沒有其他機器以此IP地址應答，則可以成功添加該IP地址。否則，可以檢測到IP地址沖突，且MUX棧可以阻止該機器主張此IP 地址。如果另一MUX已經主張該IIP(例如故障切換)且未能移除它，則這種情況可以發生。 可以通過外部措施(例如切斷防護機器)來應對這種場景。出于示例的目的，在新MUX MUX “B”需要代替MUX “A” (例如，因為MUX A的計劃停機時間和/或在MUX A處的系統故障)時，該新MUX B可以將MUX A的(各)IIP添加到其自己的接口。在至少一種實施方式中，例如上面所述的模塊可以將分組流定向到服務器池中的一個或多個有狀態模塊中，其中有狀態模塊可以保持每個流狀態。在這種情況中，入站分組可以流過從客戶機到模塊到有狀態模塊到處理相關聯的請求的目標服務器的路線。出站流可以流過從目標服務器到有狀態模塊到客戶機的路線。在有狀態模塊處的每個流狀態可以允許各單獨的有狀態模塊應用流級策略以便支持附加的負載平衡特征。具體而言，有狀態模塊可以，例如，檢查cookies或URL以便將到目標服務器的負載平衡自定義為取決于應用、客戶機請求和/或服務器和網絡元件的角色和/或負載和/或狀況。此實施方式是有益的，這是因為它可以將CPU和狀態密集的工作量分散到必要多的服務器。在至少一種實施方式中，該模塊可以使其到有狀態模塊的路由適應為取決于比 TCP/IP首部和應用首部中攜帶的首部信息更深的信息。具體而言，為了支持直接訪問函數， 例如在Windows 7 中，該模塊可以學習或參與密碼協議，從而允許對分組的各部分進行解密。然后，有狀態模塊對目標服務器的選擇可以取決于這些經解密的部分。該機制可以被構建為使得目標服務器將出站流返回給能夠(且可能最適合)處理它的有狀態模塊。這可以受益于使用可編程CPU來實現該模塊。在至少一種實施方式中，該模塊可以在諸如網際協議(IP)選項等分組首部的某一部分中包括原始目的地地址，并將該分組發送給目標設備。目標設備可以從分組首部提取這一信息并使用它來將傳出分組直接發送給源(例如，外部客戶機)，其中分組中的一些不穿過該模塊。圖6示出可以實現上文和下文所描述的概念的示例可擴展負載平衡系統體系結構600。在這種情況中，可擴展負載平衡系統體系結構600可以包括可擴展負載平衡管理器 602、在604處表示的MUX角色和在606處表示的DIP角色。負載平衡系統體系結構600還可以包括健康監視器608、健康探頭(probe) 610和路由管理器612。MUX角色604可以涉及在用戶模式616中操作的MUX控制器614和在內核模式620中操作的MUX驅動程序618。 DIP角色606可以涉及在用戶模式624中操作的DIP控制器622和在內核模式628中操作的解封驅動程序626。可擴展負載平衡管理器602可以被認為是與可擴展負載平衡系統體系結構600交互的入口點。可擴展負載平衡管理器602可以提供可以被用來管理可擴展負載平衡概念的實例的API。可以使用XML配置或API來指定可擴展負載平衡實例。可擴展負載平衡管理器602可以負責在MUX機器上配置VIP:DIP映射并確保MUX 機器保持同步。此外，在向池添加DIP或從中優雅地移除DIP時，可擴展負載平衡管理器 602還可以便于保留長期運行的連接。下面參考圖9更詳細地描述這種特征。為了增加可用性，可以復制可擴展負載平衡管理器602且可以使用主可擴展負載平衡管理器選擇算法來確保狀態的一致性。MUX角色604可以被配置為帶有一個或多個中間IP地址(IIP)。如上面參考圖4 所描述的，諸如路由器404(1)等路由器可以被配置為向一組IIP轉發去往VIP的分組。被配置為帶有給定IIP的MUX將執行向該IIP轉發的分組的MUX處理。MUX控制器614可以控制MUX驅動程序618。MUX控制器可以導出由可擴展負載平衡管理器602用來控制該MUX的web服務API。在一些實現中，MUX控制器可以執行下列功能1.將VIP:DIP下載到驅動程序；2.向該驅動程序告知長期運行的連接；
3.從該驅動程序收集統計數據；4.在網絡接口上配置IIP ；5.在網絡上發出針對所指定的IIP的G-ARP分組，以便由路由器或網絡上的其他主機將向該IIP轉發的任何分組吸引到該MUX。MUX驅動程序618可以實現基礎分組修改功能。MUX驅動程序可以對傳入分組的首部字段進行散列，基于散列值和當前VIP映射來拾取針對它的DIP，以及封裝該分組以供傳輸。除了映射之外，MUX驅動程序618還可以維持散列的高速緩存每一 VIP的所有長期運行連接的DIP映射。DIP控制器622可以控制DIP機器上的解封驅動程序626。類似于Mux控制器614， DIP控制器622可以導出由可擴展負載平衡管理器602用來控制和查詢DIP機器的web服務API。在一些實現中，DIP控制器622可以執行下列功能1.在回送接口上配置各VIP ；2.配置用于所指定的VIP的解封；3.查詢DIP機器以尋找當前活動的連接；4.查詢DIP機器的健康(取決于健康監視器實現，這是可選的)。解封驅動程序6 可以解封去往所指定的VIP的IP-in-IP分組。這一特征幫助避免斷開與具體應用的正在進行的通信。例如，如果存在正在使用原始套接字來發送 IP-in-IP的應用(例如，虛擬專用網VPN應用)，則解封驅動程序6 不解封那些。路由管理器612可以負責在向池添加或從中移除MUX機器時配置路由器。路由管理器可以使用諸如OSPF或BGP等路由協議或接口來在各路由器上配置靜態路線。健康監視器608可以負責維持MUX和DIP機器的健康狀態，且可能負責在請求處理中所涉及的路線。為此，健康監視器可以監視一個或多個網絡參數，這些參數在確定網絡和/或網絡組件的健康時是有價值的。可擴展負載平衡管理器602可以將健康監視器608 用作關于MUX和DIP的健康信息的權威源。如果健康監視器608向可擴展負載平衡管理器 602通知健康改變事件，則可擴展負載平衡管理器可以采取向相應的池添加或從中移除該節點的適當動作。從一個角度來看，健康監視器608可以被用來監視MUX、DLB的健康和/或到這些機器的路線。在至少一些實現中，健康監視器608可以包括三個模塊VPN撥號器、MUX監視器和DLB監視器。DLB可以提供HTTP接口。健康監視器608可以采用各種健康探頭610來確立目標組件的健康。例如，健康監視器可以發送“http get”以便從DLB獲取小的文本/ xml文件。如果該文件包含健康監視器和DLB所達成一致的‘魔術詞(magic word) ’，則健康監視器可以認為該DLB已啟動且正在運行，并確定DLB或MUX是否正在如所預期的那樣運行。此外，在至少一些實施方式中，健康監視器組件可以存在于分開的設備上而不是MUX 設備上。健康探頭610可以由健康監視器608使用。舉例來說，健康監視器可以使用各種健康探頭來完成其作業。健康探頭610可以主動地監視目標機器的健康的一個方面，例如， Ping探頭監視機器的連接性和活性。其他健康探頭可以簡單地查詢機器/角色以得到其健康——該機器/角色可以負責維護其健康的記錄，探頭只是周期性地查詢它。
如果HTTP探頭是成功的，則這可以指示所有事物都開啟且正在運行。但是由于它在TCP上運行，所以DLB臨時地用光了套接字或其他資源是可能的。在拒絕服務(DoQ攻擊期間，DLB在持續時間周期內用光了資源(例如，套接字)也是可能的。對此的一種解決方案可以是維持持久的HTTP連接。然而，大多數服務器/瀏覽器實現將使得持久的TCP連接超時。例如，一些瀏覽器可以在60秒之后使得持久連接超時。因此，健康監視器準備在持久連接被關閉的情況下重建該持久連接，且不必將持久連接的關閉看作是指示DIP故障。如果另一 MUX可以接管故障的MUX，則由于所有MUX運行相同的一致散列函數，所以各分組將被轉發給相同的DLB。因此，該流(例如，TCP連接)不會被中斷。一分開的MUX池可以被用作活動MUX的熱備份。一旦檢測到MUX故障，健康監視器608就可以開始一個或多個MUX以便接管故障MUX的各IIP。在同一時刻，健康監視器可以切斷該故障MUX。為了處理MUX的計劃停機時間，可以使用與用于熱備份的技術相似的技術。由于MUX以無狀態模式操作，一些實現可以在從該MUX排出了所有分組之后安全地切斷該MUX。在至少一種實施方式中，可以通過有狀態MUX映射過渡來處理DLB計劃停機時間。1. MUX 正在使用使用 DLB (D)的 VipMap (V)；2.向MUX通知DLB (D)在T時刻停機；3. MUX 計算不使用 DLB (D)的新 VipMap (V，)；4. MUX將驅動程序置于(V- > V’過渡模式)；5.在過渡中，保持狀態表，且每一 TCP SYN將在表中造成新條目；a.如果分組與狀態表中的一條目匹配，則它是新的流且因此使用V’ ；b.否貝丨J，使用舊的V;注意在這一過渡時間段期間，任何新的流將切換到新VipMap (V’)，從而避開了 DLB (D)。6. DLB(D)保持對(到VIP的)活動TCP連接的數量進行計數。在計數器達到0 時，它向MUX通知該過渡已完成。7.替代地，MUX可以將長期運行連接標識為不與狀態表中的任何條目相匹配的連接。8.在達到時間T時，強加過渡V- > V’。MUX將基于V’來轉發所有流量。在一種實施方式中，經由下列步驟來處理MUX計劃停機時間1.在新 MUX(M，)上設置 VipMap ；2.設置舊MUX(M)以便將所有VIP流量轉發給M’，M’照常將流量轉發給DLB ；3.從舊的 MUX(M)移除 IIP ；4.將IIP添加到新MUX (M')；以及，5.路由器應開始向新MUX轉發。在至少一種實施方式中，健康監視器608可以將周期性的探頭發送給MUX和DLB 以便監視非預期故障。在觀察到DLB故障時，健康監視器可以指示MUX更新其VipMap以便避免使用故障的DLB。在觀察到MUX故障時，健康監視器可以指示在同一 VLAN中的另一 MUX 安裝該IIP(且使用G-ARP來向路由器通告)。在至少一種實施方式中，健康監視器可以每兩秒發送Ke印Alive (保持活動)探頭，且在3次連續失敗之后通告MUX/DLB死亡。
為了實現用于關鍵任務VIP的快速MUX故障切換(<< 1秒)，可以利用每一 IIP 的MUX虛擬組。這種快速故障切換的成本可以是在正常操作期間更多使用網絡。可以使用下列步驟用來為VIP管理MUX和IIP :A.每一 IIP可以是多播地址。每一 VIP具有被分配給它的一組MUX。B.該組的主MUX是該IIP的實際持有者。C.主MUX向該組的所有成員發送它是此VIP的活動MUX的多播通告。以高速率 (<< 1秒)發送這一通告。這一通告也防止其他MUX開始新的主MUX選舉過程。D.由于IIP可以是多播地址，所以上游路由器將它所接收到的每一分組復制到該 VIP組中的各MUX成員(主MUX和所有備份MUX)。Ε.所指定的備份MUX將這些分組存儲所指定的時間T。F.主MUX對這些分組執行負載平衡功能并將它們轉發給各DLB。G.如果在給定的時間T內沒有接收到主MUX活動的通告，則所指定的備份MUX將開始負載平衡并轉發其緩沖區中的所有分組。H.這一組中的各備份MUX將開始新的主MUX選舉過程。在一些配置中，所指定的備份MUX可以變成新的主MUX。I.步驟G可以使得DLB兩次接收一些分組，但是TCP足夠好地容忍重復分組和暫時的分組丟失。注意，只要上游路由器活動且執行良好，就可以不發生分組丟失。圖7示出根據一個或多個實施方式的MUX 212(1)(在圖2中已介紹)的示例配置。 圖7和圖8 —起示出如何沿著路徑封裝和解封各分組。圖7涉及用戶模式702和內核模式704，但是集中于由MUX的在內核模式中的MUX 驅動程序618提供的功能。在這種情況中，MUX驅動程序被實現為網絡棧的IP層的擴展。在這一示例中，由MUX驅動程序618例如從應用服務器接收分組706。該分組包括在708處的源客戶機地址和在710處的目的地VIP地址。分組遷移通過物理網絡接口卡 (NIC)層712和網絡驅動程序接口規范(NDIS)層714。該分組由IP層718中的MUX驅動程序的轉發器716來處理。該轉發器封裝分組706以便生成分組720。此分組包括由源MUX 地址722和目的地DIP地址7 封裝的在708處的源客戶機地址和在710處的目的地VIP 地址。因而，以給出它是來自MUX212(1)而不是來自客戶機708的印象的方式將原始分組 706封裝在分組720中。MUX 212(1)可以實現也稱為VIP:DIP映射的層4負載平衡。可以由層1將來自客戶機的流量發送到各MUX節點中的一個(通常經由等價多路徑(ECMP)路由)。在MUX 212(1)接收到分組706時，它可以將各分組首部字段進行散列(在散列哪些字段方面是靈活的)且可以基于此散列來拾取DIP。(下面參考圖9描述此過程的示例)。然后，該MUX 可以將原始分組706封裝在新的IP首部中，該新的IP首部將所選擇的DIP指示為目的地 (艮P，目的地DIP地址724)并將該MUX指示為源IP地址。(替代地，MUX可以將原始發送者用作源IP。)負載平衡集群中的各MUX節點可以使用相同的散列函數。此外，MUX節點可以在 DIP的添加和優雅刪除期間維持狀態。這可以允許將給定流的各分組轉發給下一層中的相同服務器而不考慮哪個MUX接收該分組。圖8示出上面參考圖6介紹的DIP角色606的示例。簡言之，在這種情況中，DIP解封驅動程序擬6可以對圖7中所介紹的經封裝分組720執行解封。在這種配置中，將DIP 解封驅動程序被實現成網絡棧的IP層的擴展。如上所述，圖7提供用于在傳輸路徑的前端處實現封裝的示例，圖8提供在后端處解封上面介紹的原始分組706的示例。在這一示例中，解封驅動程序6 可以接收經封裝的分組720。一旦經封裝的分組在路徑上行進且準備好傳輸給目的地VIP地址710，解封驅動程序就可以移除封裝(即，源 MUX地址722和目的地DIP地址724)以便產生分組706。上面所描述的MUX 212(1)和DIP角色606可以與本發明的各概念一起使用以便于諸如分組706等分組的封裝，該分組706與帶有位置地址(S卩，目的地DIP 724)的應用地址(即，目的地VIP地址710)相關聯，以使得分組706可以在層3基礎設施上傳輸且最終被遞送到層2目的地VIP地址710。此外，經封裝的分組可以在由該封裝所定義的路徑上行進，且可以容易地為隨后的分組重新選擇所選擇的路徑以便避免擁塞。此外，這種配置可以便于網絡節點池(即，可擴展負載平衡系統104、204和/或 304的各組件)的免中斷(或減少的中斷)的生長和縮小。簡言之，可擴展負載平衡系統狀態不傾向于是靜態的。舉例來說，更多的應用服務器可以上線和/或各應用服務器可以下線，交換機可以來來往往，通信可被發起和結束等等。本發明的各概念可以允許從現有的可擴展負載平衡系統映射到新的可擴展負載平衡系統映射的優雅過渡。舉例來說，本發明的各概念可以跟蹤現有映射的現有或正在進行的通信。在利用反映可擴展負載平衡系統針對新通信的改變的新映射的同時，一些實現可以嘗試利用現有映射來維持那些正在進行的通信的連續性。然后，這些實現可以以相對無縫的方式從舊映射‘優雅地’過渡到新映射。圖9示出將散列空間映射到DIP池的示例方法900。舉例來說，該映射可以允許從VIP池移除DIP而不中斷對不去往受影響的DIP的流量。舉例來說，在902處示出在散列空間(即，可能的散列值)和可用的DIP的池之間的第一映射。在904處示出在該散列空間和可用的DIP的不同的池的第二映射。在這種情況中，第二映射904作為如在906處所示的DIP 1停機(即，變得不可用)的結果而發生。最初參見第一映射902，各散列值在 908(1)、908(2)、和 908(3)處被映射到 DIP 1，在 910 (1)、910 (2)和 910 (3)處被映射到 DIP 2，在 912 (1)、912 (2)、和 912 (3)處被映射到 DIP3，且在 914 (1)、914 (2)和 914 (3)處被映射到DIP 4。因而，以可以減少或避免瓶頸的方式在可用的DIP當中分配各散列值。在906處在DIP 1消失的情況下，這一實現以避免突然使得任何單獨的可用DIP 過載的方式在剩余的可用DIP之間重新分配DIP 1的負載。舉例來說，在第二映射904中， 在第一映射902中的散列的在908(1)處被映射到DIP 1的第一部分被重新分配給DIP 2， 如在916處所指示。DIP 1的第二部分908 (2)被重新分配給DIP3，如在918處所指示。DIP 1的第三部分908 C3)被重新分配給DIP 4，如在920處所指示。因而，這一實現以可以避免使得任何其余DIP過載且由此避免了潛在地造成與過載的DIP相關聯的瓶頸的平衡方式無縫地將分組流從如第一映射902中所示的四路分布重新分配成第二映射904中所示的三路分布。出于更詳盡的解釋的目的，考慮具有確定VIP到一個或多個應用服務器(DLB)的映射的VIP-DIP映射M的MUX (例如MUX 212⑴)。現在考慮其中要將M改變成M’的場景。 利用所描述的技術，可以將M優雅地改變成M’。由于可以存在長壽命的連接，所以可選地， 可以定義最后期限T。然后，一旦達到T或者一旦完成了優雅改變，該MUX就可以將M改變成M，。下面描述的僅是將M優雅地改變成M’的方式一個示例對于分組P，MUX可以計算H(P)和H’⑵兩者，其中可以使用映射M來計算H⑵ 且可以使用映射M’來計算H’ (P)0-如果H(P) = H，(P)，則轉發給H (P)等效于轉發給H，(P)；-如果H(P)！ = H’(P)且P是SYN(TCP SYN分組，其可以發起TCP連接)，則P可以被用來建立新的連接，該新連接應去往H’(P)，且插入散列⑵(hash (P)) —H’⑵也可以被插入到狀態表S，以使得此流可以被認為是已經被移到M，；-如果H(P) ！ = H’ (P)且P不是SYN，并且散列(P)不在S中，則這可以是正在進行的到H(P)的連接的一部分，因此繼續到H(P)；-如果H(P)！ =H’(P)且P不是SYN，并且散列(P)在S中，則這可以是正在進行的已經被移到M’的連接的一部分，因此繼續到H’ (P)；-在達到T或所有DLB告知過渡已完成時，可以將映射從M改變為M，，且可以對狀態表S進行轉儲清除。相應地，DLB可被告知相同的M->M’過渡，且然后，則它可以計算它(即，該DLB) 是否受到此過渡的影響。如果DLB確定它正在被過渡出去，則它可以優雅地耗盡它擁有的連接。對于持久的HTTP連接，DLB HTTP服務器可以禁用‘HTTP Keepalive' (HTTP保活)。 如此，DLB HTTP服務器可以使用FIN來終止(TCP FIN分組，其結束TCP連接)底層TCP連接。FIN可以被認為是TCP首部中指示此分組的發送者想要終止連接的標志。外部客戶機可以重啟連接。然而，這將可能開始新的握手，對于該新的握手，MUX可以將該新的TCP連接路由到新的DLB。替代地，可以類似于下面描述的所建立的TCP連接來處理持久的HTTP連接。-在過渡時間段期間，所建立的TCP連接可以是寂靜的或繁忙的，且可以預期HTTP 關閉它。一些可能的動作是· 1.令TCP連接在客戶機側超時。基本上，此技術僅僅忽略這些TCP連接。· 2.在達到時間T時向客戶機強制發送TCP RST以便告知該客戶機。發送RST 不要求具有正確的序列號。因而，此技術可以只是枚舉“已建立的”連接且結束所有已建立的連接。· 3. MUX可以維持持久連接的狀態，直到DLB確定已經終止受過渡影響的各連接。-在打開TCP套接字的數量是0時，可以告知MUX可以從該池安全移除該節點。總之，本發明的各實現可以使用IP-in-IP封裝以便可以跨越可能全部目標設備而不僅是子網來使用DSR。此外，可以按需將負載平衡器實現為可擴展邏輯層。各概念也可以在系統過渡期間保留連接。舉例來說，在優雅地過渡各連接的同時，可以添加或移除DIP、 可以重新平衡負載并且/或者可以調整系統容量。可以在MUX層實現一致散列以便允許可擴展性并允許移除故障的DIP而不保持狀態。此外，系統監視、控制和/或管理功能可以與負載平衡功能位于一處。這可以允許主MUX確保在各MUX之間的地址連續性以及其他潛在的優點。第一方法示例
圖10示出根據一個或多個實施方式的參考VIP的DIP池的擴展來描述與保留長期運行連接相關聯的示例的各步驟或動作的方法1000的流程圖。可以結合任何合適的硬件、軟件(例如，包括固件)或其任何組合實現該方法。在一些情況中，該方法可以被存儲在可由計算設備的處理器執行以便執行該方法的計算機可讀存儲介質上。此外，可以重復該方法的各步驟中的一個或多個任何次數。另外或替代地， 在至少一些實施方式中可以省略各步驟中的一個或多個。在步驟1002，標識網絡或可擴展負載平衡系統的新連接。在至少一些實施方式中， 這可以通過查找TCP SYN來完成。在步驟1004，保持新連接的狀態。在步驟1006，對現有或舊連接使用現有或舊散列，且可對新連接使用新散列。在步驟1008，查詢各DIP。在至少一些實施方式中，這可以包括查詢DIP以便得到要保持的長期運行連接。替代地，負載平衡系統可以通過解釋分組首部來確定活動連接。在步驟1010，使新連接的狀態過期。在步驟1012，使所保持的連接的狀態過期。在至少一些實施方式中，這可以包括在所保持的連接在DIP處終止時使得所保持的連接的狀態過期。出于解釋性目的提供方法1000，且不應以限制方式來理解方法1000。舉例來說， 在過渡期間可以采用的替代方法可以利用下列算法1.通過解釋分組首部(例如查找TCP SYN)來標識新連接發起分組；2.如果它是新連接發起分組，則僅根據新映射來發送它；3.否則根據舊映射和新映射兩者發送該分組；4.通過詢問DIP或跟蹤在某一時間段期間在負載平衡器處的狀態來標識舊連接；5.根據舊映射發送舊連接且根據新映射發送新連接；以及6.在超時之后或在舊連接在DIP上終止時，使得關于舊連接的狀態過期。第二方法示例圖11示出描述示例方法1100的各步驟或動作的流程圖。可以結合任何合適的硬件、軟件(例如，包括固件)或其任何組合實現該方法。在一些情況中，該方法可以被存儲在可由計算設備的處理器執行以便執行該方法的計算機可讀存儲介質上。此外，可以重復該方法的各步驟中的一個或多個任何次數。另外或替代地，在至少一些實施方式中可以省略各步驟中的一個或多個。在步驟1102，可以將各網絡分組分散在一系列模塊之間。在至少一種實施方式中， 各模塊是被配置為在服務器上和/或在路由器中實現的MUX模塊。除了可以將到一目的地的各分組遞送到包含處理該目的地的各分組所需要的狀態的MUX模塊之外，分散可以無視各分組的各單獨的特性。在至少一些實施方式中，使用ECMP路由器將各單獨的網絡分組分散在各模塊之間。在步驟1104，網絡分組可以被封裝在各單獨的模塊。在至少一些實施方式中，該分組的封裝包括IP-in-IP封裝和/或保留該分組被發送到的一個或多個VIP地址。在這一點上，應注意，在此描述的各技術的可能有價值的特征與以下相關聯基于各分組的特性 (例如，5元組，IP源地址、IP目的地地址、IP協議號、TCP源端口和/或TCP目的地端口) 封裝各網絡分組，以使得作為同一請求的一部分的各分組在一些實施方式中可以全部由同一目標設備處理，而不管哪個MUX模塊封裝了該分組。在步驟1106，可以使用在各模塊之間共享的狀態來選擇將各網絡分組封裝到的目標設備。在至少一些實施方式中，在各模塊之間共享的狀態是一致散列函數的鍵空間。另外或替代地，在至少一些實施方式中，可以響應于目標設備的故障而改變在各模塊之間共享的狀態。在步驟1108，可以從各模塊轉發各網絡分組。在步驟1110，可以監視目標設備、MUX模塊、路由器的健康和在各組件之間的路線。結論盡管已經用對結構特征和/或方法論動作來說專用的語言描述了關于負載平衡場景的各技術、方法、設備、系統等等，但應理解，在所附權利要求中限定的主題并不必定限于所描述的具體特征或動作。相反，這些具體特征和動作是作為實現所要求保護的方法、設備、系統等等的示例性形式而公開的。
權利要求
1.一種其上存儲有指令的計算機可讀存儲介質，所述指令在被處理設備執行時執行以下動作將網絡分組分散在一系列模塊之間(1102)；在各單獨的模塊處封裝所述各網絡分組(1104)；使用在所述系列的各模塊之間共享的狀態來選擇將所述網絡分組封裝到的目標設備 (1106)；以及從所述一系列模塊轉發所述網絡分組(1108)。
2.如權利要求1所述的計算機可讀存儲介質，其特征在于，在所述系列的各模塊之間共享的狀態是一致散列函數的鍵空間。
3.如權利要求1所述的計算機可讀存儲介質，其特征在于，使用等價多路徑路由來將各單獨的網絡分組分散在所述系列的各模塊之間。
4.如權利要求1所述的計算機可讀存儲介質，其特征在于，還包括監視所述目標設備的健康。
5.如權利要求1所述的計算機可讀存儲介質，其特征在于，響應于所述目標設備的故障來改變在所述系列的各模塊之間共享的狀態。
6.如權利要求1所述的計算機可讀存儲介質，其特征在于，在不造成所提供的服務的停機時間的情況下基于負載參數或一個或多個其他參數中的一個或多個來動態地改變所述系列中的多個模塊。
7.如權利要求1所述的計算機可讀存儲介質，其特征在于，所述目標設備是一組目標設備的成員，且在其中接收到所述組的一個或多個現有目標設備將變得不可用或一個或多個新的目標設備可用的指示的情況下，過渡到將與將來通信相關聯的網絡分組分散到新的一組目標設備的配置，同時繼續將與正在進行的通信相關聯的網絡分組發送給所述一組目標設備。
8.如權利要求1所述的計算機可讀存儲介質，其特征在于，封裝所述分組包括網際協議(IP)-in-IP 封裝。
9.如權利要求6所述的計算機可讀存儲介質，其特征在于，封裝所述分組保留所述分組被發送到的一個或多個虛擬IP地址。
10.一個系統(104)，包括被配置為對來自外部客戶機設備(102)的分組流的各單獨的傳入分組進行封裝的負載平衡層(108)，所述負載平衡層(108)還被配置為將所述傳入分組路由到所述系統(104) 的目標設備(110)，其中所述目標設備(110)跨一個或多個網際協議(IP)子網，且其中所述傳入分組在到達各單獨的目標設備(210)之前穿過所述負載平衡層(108)的一個或多個負載平衡器O08)；以及，所述各單獨的目標設備(210)被配置為將所述分組流的至少一些傳出分組路由(222) 到所述外部客戶機設備(10 而不穿過所述一個或多個負載平衡器O08)中的任何一個。
11.如權利要求11所述的系統，其特征在于，所述負載平衡層被配置為利用網際協議 (IP)-in-IP封裝或分組修改及IP選項中的一個或兩者來封裝所述各單獨的傳入分組。
12.如權利要求11所述的系統，其特征在于，所述負載平衡層包括至少一個動態負載平衡器和至少一個多路復用器，且其中所述至少一個多路復用器被配置為封裝所述各單獨的傳入分組。
13.如權利要求11所述的系統，其特征在于，所述負載平衡層包括至少一個多路復用器，且其中所述至少一個多路復用器被配置為利用IP-in-IP封裝來封裝所述各單獨的傳入分組。
14.如權利要求11所述的系統，其特征在于，所述各單獨的目標設備包括被配置為解封來自所述負載平衡層的分組的解封組件，或其中各單獨的目標設備跨多個虛擬局域網。
15.如權利要求11所述的系統，其特征在于，所述一個或多個負載平衡器包括被配置為提供用于管理所述負載平衡層的虛擬IP(VIP)到直接IP(DIP)映射的應用程序接口的動態負載平衡器。
全文摘要
本申請涉及網絡配置，且尤其涉及可擴展負載平衡網絡配置。一種實現包括被耦合到可擴展負載平衡系統的外部客戶機。可擴展負載平衡系統包括被配置為對來自該外部客戶機的分組流的各單獨的傳入分組進行封裝的負載平衡層。該負載平衡層還被配置為將傳入分組路由到系統上的目標設備。各目標設備可以跨越多個IP子網。各傳入分組可以在到達各單獨的目標設備之前穿過負載平衡層的一個或多個負載平衡器。各單獨的目標設備可以被配置為將分組流的至少一些傳出分組路由到外部客戶機而不穿過一個或多個負載平衡器中的任何一個。
文檔編號H04L29/06GK102449963SQ201080023822
公開日2012年5月9日 申請日期2010年5月28日 優先權日2009年5月28日
發明者A·格林伯格, D·馬爾茨, P·帕特爾, R·克恩, 袁利華 申請人:微軟公司