专利名称：跨层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·克恩, 袁利华 申请人:微软公司