网络业务管理和负载平衡的系统和方法

专利名称：网络业务管理和负载平衡的系统和方法
技术领域：
本发明涉及分布计算环境中的网络业务管理和负载平衡的系统和方法。
背景技术：
为服务诸如超文本标记语言(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日
发明者罗伯特·布弗恩, 考持·维, 雷蒙德·斯塔塔 申请人:雅塔公司