用于提供动态托管服务管理的方法和系统

摘要

运营因特网的托管服务提供商以便跨不同的客户帐户和/或不同地理位置(80)提供托管服务的动态管理。许多单个服务器被分配到为该客户帐户定义的公用管理组，这些服务器被配置为访问该客户帐户所特有的软件和数据，以为该客户帐户提供托管服务。系统自动监视每个管理组中的服务器的性能和运行状况。为响应自动监视，将第一管理组(52a)中的至少一台服务器自动和动态地重新分配到第二个管理组(52b)。每个管理组都包括本地决策软件程序，该程序与主决策软件程序进行通信，主决策软件程序确定何时以及如何为响应使用需求、可用的资源和针对不同客户帐户的服务等级协议动态地向不同的管理工作组重新分配服务器。

说明书

技术领域

本发明通常涉及数据处理业务领域。更具体来说，本发明涉及用于跨不同的客户帐户和/或不同地理位置提供托管服务的动态管理的方法和系统。

发明背景

因特网的爆炸性增长在很大程度上是由诸如因特网服务提供商(ISP)、应用程序服务提供商(ASP)、独立软件供应商(ISV)、企业解决方案提供商(ESP)、托管服务提供商(MSP)之类的商业性的服务提供商和托管机构的出现推动的。虽然对这些业务中的每个服务提供的准确的服务集没有明确的定义，但是这些服务提供商和托管机构通常提供定制的服务，以满足客户的在应用程序托管、站点开发、电子商务管理和服务器部署方面的一些、大多数或全部需求，以便赚取安装费用和定期的费用。例如，在服务器部署的情况下，费用通常基于客户为托管该客户的应用程序或网站指定的特定的硬件和软件配置。对于本发明，术语“托管服务”包含此一系列服务提供商和托管机构提供的各种类型的这些服务。为方便起见，此一系列服务提供商和托管机构应该统称为托管服务提供商(HSP)。

商业性的HSP向用户提供对因特网上托管的应用程序的访问，如同电话公司向客户提供通过国际电话网络与他们计划的通话者的连接一样。HSP用来托管他们提供的应用程序和服务的计算机设备通常被称为服务器。服务器的最简单的形式可以是个人计算机，它通过网络接口连接到因特网，并运行为满足客户或该服务器的客户端作出的请求而设计的特定软件。对于可以被HSP用来提供托管服务的所有提供模式，大多数HSP使用连接到内部网络的服务器的集合，该集合通常被称为“服务器场”，每一台服务器都执行独有的任务或者服务器组分摊多个任务的负载，如邮件服务器、Web服务器、访问服务器、记帐和管理服务器。例如，在托管网站的情况下，具有较小的网站的客户常常聚集到单个Web服务器中并由单个Web服务器提供支持。然而，较大的网站通常在只为该站点提供服务的专用Web服务器上托管。有关因特网和HSP的一般背景信息，请参阅GeoffHuston，ISP生存指南：运行有竞争力的ISP的策略(1999)。

随着对因特网服务的需求越来越大，需要更大的容量才能满足这种需求。一种解决方案是利用功能更强大的计算机系统作为服务器。使用大型机和中型计算机系统作为服务器来服务于大型网站和企业网络。大多数HSP正倾向于不利用这些更大的计算机系统，因为这样的系统的费用高、复杂并缺少灵活性。相反，HSP更愿意利用服务器场，其中包括大量的单个个人计算机服务器，它们连接到公用因特网连接或调制解调器库，有时还访问公用磁盘驱动器集。例如，当HSP添加新的托管服务客户时，一个或多个个人计算机服务器被手动地添加到HSP服务器场，并为该客户加载适当的软件和数据(例如，Web内容)。如此，HSP只部署为支持其当前客户级别所需要的该硬件级别。同样重要的是，HSP可以向其客户收取初装费，该费用可以补偿大部分硬件成本。通过利用这种方法，HSP不必预先为具有空闲容量的大型计算机系统花费费用，空闲容量不会为HSP产生直接的收入。与客户都从单个更大的大型机享受服务的情况相比，服务器场解决方案还为跨不同的客户维护安全和数据完整性的问题提供了更方便的解决方案。如果针对一个客户的所有服务器只加载针对该客户的软件，并且只连接到针对该客户的数据，那么该客户的信息的安全性可以通过物理隔离来得到确保。

对于HSP，可以为帐户提供很多的软件记帐程序包，并收取这些计量服务的费用，如来自tens.com的XaCCT和来自inovaware.com的HSP Power。已经开发了其他软件程序以帮助管理HSP网络，如来自lightspeedsystems.com的IP Magic、来自resonate.com的Internet Services Management 和来自luminate.com的MAMBA。HSP的管理和运营也是诸如1999年4月19日的互联网研讨会中的Hursti，Jani“访问网络和服务提供的管理”之类的文章和研讨会的主题。典型的提供各种配置的硬件、软件、维护和为以每月缴费方式提供商业性级别的因特网访问和网站托管支持的HSP的示例可以在rackspace.com找到。

到目前为止，HSP构建他们的服务器场的方法有两种。一种方法是使用单个制造商提供的同源个人计算机系统(硬件和软件)组。另外一个方法是使用许多不同的制造商提供的个人计算机系统。同源方法为HSP提供了只须支持单个服务器平台的优点，但同时也将HSP限制于此单个服务器平台。使用不同的制造商提供的系统的异源方法更加灵活，并为HSP提供了为给定客户或任务利用最适合的服务器硬件和软件平台的优点，但这种灵活性是以复杂性以及与维护多个服务器平台关联的支持挑战增大为代价的。

不管使用哪一种方法来建立服务器场，对这样的服务器场的实际物理管理总的来说还是相同的。当客户需要增加或减少为他们的帐户提供的服务量时，HSP将手动地在HSP服务器场的直接连接到该客户的网站的数据存储和网络互相连接的部分添加服务器或从中删除服务器。在需要添加服务的情况下，典型的过程将是下列情况的某些变种：(a)从托管服务客户那里收到更改服务级别的订单，(b)HSP购买新的服务器硬件以满足请求的更改，(c)HSP的人员从物理上在服务器场所在的位置安装新服务器硬件，(d)将新服务器硬件的电缆添加到该站点的数据存储和网络连接，(e)将服务器硬件的软件加载到服务器，HSP的人员执行一系列初始化步骤以针对此客户帐户的要求配置软件，以及(f)新安装的和完全配置的服务器加入到针对客户的帐户提供托管服务的服务器的现有管理组。无论是哪一种情况，每一个服务器场都被分配给了特定的客户，并必须被配置为满足来自该客户帐户的预期的最大需求。

最初，需要重新启动给定客户帐户的管理组中的某些或所有现有的服务器才能完成此过程的最后一个步骤，因为现有的服务器中的指针和表将需要手动地更新以反映在管理组中添加新服务器这一情况。这一要求决定了服务器硬件中的更改只能在诸如星期日深夜之类的定义明确的服务窗口定期发生。最近，已经开发和扩展了诸如MicrosoftWindows 2000、Microsoft Cluster Server、Oracle Parallel Server、Windows网络负载平衡服务(NLB)之类的软件和类似的程序，以自动使新服务器随时加入到现有的管理组，而不是在这些定义明确的窗口。

在美国专利No.5,951,694中描述了新服务器如何自动加入到现有的管理组的示例。在此专利中，由网关服务器维护的映射表中表示了管理组中的所有服务器。映射表标识了管理组的不同的服务组，如邮件服务组、数据库服务组、访问服务器组等。网关服务器基于映射表将对管理组的请求路由到适当的服务组。新服务器可以通过在该服务器上加载适当的软件组件来添加到其中一个服务组，在此之后，网关服务器将识别新服务器，并将它添加到映射表，并使用为每一个服务组维护的事务日志使新服务器与该服务组中的其余服务器保持同步。或者，如果一个服务组的工作负载特别重，另一个服务组的负载轻，则可以将服务器从一个服务组切换到另一个组。该专利描述了一个在专用的管理服务器上执行的软件例程，该软件使用负载平衡方案修改映射表，以确保对该管理组的请求在组成管理组的各种服务组中更均衡地分布。

很多专利描述了在单个群集或管理组中的服务器中平衡工作负载的技术。美国专利No.6,006,529描述了包括受主服务器控制的安全性和心跳信号布局的软件群集，在此，给所有群集成员分配了一个公用IP地址，并在该群集内执行负载平衡。美国专利Nos.5,537,542、5,948,065和5,974,462描述了具有共享数据空间的多系统计算机处理系统的各种工作负载平衡布局。将工作负载在多台服务器中分布还可以通过在客户端和服务器之间插入中间系统来完成。美国专利No.6,097,882描述了在客户端和服务器之间插入的复制器系统以透明地基于服务器可用性和工作负载在客户端和服务器之间重定向IP数据包。

还使用了各种技术来协调单个群集中的多台计算机或服务器的操作。美国专利No.6,014,669描述了单个群集中的多台服务器的使用锁定步骤分布式配置文件来执行的群集操作。美国专利No.6,088,727描述了一个共享数据空间多计算机环境中的群集控制。其他专利描述了如何使用输入/输出空间的单个映像来协调多台计算机。美国专利No.5,832,222描述了如何使用输入/输出空间的单个映像来协调地理上分散的计算机系统。美国专利No.6,067,545描述了具有共享元数据管理、复制配置数据库和域负载平衡的分布式文件系统，可使服务器在配置数据库的控制下加入和离开单个域。

尽管这些方法改进了管理组、域或共享数据空间内的服务器的管理，但是没有能力将这些技术扩展到为公用操作系统或公用共享数据空间定义的并与它们链接的服务器组之外。一般来讲，这种限制没有被视为问题，因为所有这些方法是针对在单个公司的计算机网络内管理和实现的较大的企业计算系统的。尽管这些方法可以被HSP用来管理分配到给定客户的特定帐户的服务器，但是这些方法中没有一个方法可使HSP管理向不同的客户的多个帐户提供托管服务的一组服务器。

还已经开发出了用于管理更大的企业计算系统的运行的系统，如来自Hewlett-Packard的OpenView、来自Computer Associates的Unicenter TNG、来自IBM的Tivoli、来自Laminate的Mamba，以及来自BMC Software，Inc.的Patrol。一般来讲，这些系统侧重于在单个公司或机构内运行的大量计算机遇到的清单管理和软件部署控制问题。这些操作管理系统中的一些系统包括性能监视解决方案，通过网络查询机构内的服务器的性能，以确定对其他资源或负载再分布的需求。类似的“通过网络”方法也用于提供集中的报告和管理功能。计划供HSP使用的这种类型的操作管理系统的一个很好的示例是Tivoli服务提供管理平台，该平台包括用户管理模块、软件分发模块、清单模块、企业控制台、安全性模块、企业管理器模块，该模块在网络中的组件被添加到网络之后提供所有这些组件的可自定义的视图，可使工作负载在共享公用数据空间的服务器中均衡的工作负载计划程序。所有这些模块都使用“通过网络”通信方案进行操作，该方案涉及网络中的各种节点上的代理，它们收集状态和事件信息并报告到其他模块。一旦新节点的硬件组件从物理上被添加到网络，Tivoli服务提供管理平台的各种模块可以更自动地接管和管理那些组件。然而，从物理上将新节点的硬件添加到网络的过程本质上仍然是一个手动过程，可以以与前面描述的相同方式来完成。

在管理组成计算机系统的物理硬件方面，已经开发了各种方法以自动补偿计算机网络内的硬件组件的故障。美国专利No.5,615,329描述了冗余硬件布局的典型示例，该布局使用专用的分开的主要和辅助计算机系统实现了远程数据卷影，在主要计算机系统发生故障的情况下，辅助计算机系统接管主要计算机系统。这些类型的镜像或卷影布局的问题是，它们的价格昂贵并且造成浪费，特别是辅助计算机系统在等待主要计算机系统的故障的待机模式下是空闲的。美国专利No.5,696,895描述了针对此问题的一个解决方案，在该解决方案中，有一系列服务器，每一台服务器都运行它们自己的任务，但每一台服务器还都被指定在其他服务器中某一台服务器发生故障的情况下充当该服务器的备份。这种布局可使任务由两台服务器执行以在备份服务器上继续，虽然性能会下降。这种类型的解决方案的其他示例包括Epoch Point of Distribution(POD)服务器设计和USI Complex WebService。用于提供这些服务的硬件组件是预定义的计算pod，包括负载平衡软件，该软件还可以补偿管理组内的硬件组件的故障。即使在使用这样的预定义的计算pod的情况下，对这样的pod的物理准备并安装到管理组可能会花一个星期才能完成。

所有这些解决方案都可以基于现有的硬件计算容量来自动管理和平衡工作负载并绕开管理组内的硬件故障；然而，还没有开发出能够将更多硬件资源自动部署到管理组的解决方案。如果预先知道对管理组内的更多硬件资源的潜在需求，最常见的解决方案是基于对该组的资源的预测的最高需求来预先配置硬件资源。尽管这一解决方案可使管理组在峰值需求期间作出相应的响应，但是为满足这种峰值需求分配的额外硬件资源在大多数其他时间得不到充分使用。结果，提供管理组的托管服务的成本由于该组的硬件资源利用不足而增大。

对更多托管服务的需求的一个解决方案是Cable&Wireless提供的Internet Shock Absorber(ISA)服务。ISA服务将客户的静态Web内容分发到位于Cable & Wireless Internet主干网上各个存在点(POP)的一个或多个缓存服务器。对此静态Web内容的请求可以被定向到缓存服务器和各个POP位置以从为该客户提供托管服务的管理组中的服务器中免除该功能。然而，缓存静态Web内容是作为通过因特网分发信息的组成部分自然发生的一件事。在有大量的用户从给定的IP地址请求静态信息的情况下，将此信息缓存在因特网上的多个位置是常见的。本质上，ISA服务可使客户主动地在因特网上启动静态Web内容的缓存。尽管这一解决方案具有改善提供静态Web内容的性能的潜力，但是这一解决方案不适用于涉及交互式或动态信息内容的很多其他类型的托管服务。

虽然对管理HSP的方式作出了有效的增强，虽然已经开发了许多程序和工具以帮助HSP网络的运营，但是HSP用来创建和维护服务器场的物理资源的基本技术没有发生太大的变化。因此需要提供一种更有效的运营HSP的方式，该方式可以改进管理服务器场的物理资源的方式。

发明内容

本发明是用于以这样的方式运营因特网的托管服务提供商的方法和系统，以便跨不同的客户帐户和/或不同地理位置提供托管服务的动态管理。对于许多客户帐户中的每一个客户帐户，许多单个服务器被分配到为该客户帐户定义的公用管理组。每一个管理组都被配置为访问该客户帐户所特有的软件和数据，以便为该客户帐户提供因特网提供托管服务。系统自动监视每个管理组中的服务器的性能和运行状况。为响应自动监视，将第一管理组中的至少一台服务器自动和动态地重新分配到第二个管理组。服务器的自动和动态重新分配是通过这样的方式完成的：为重新分配的服务器设置初始化指针以访问第二管理组的客户帐户所特有的软件和数据，然后重新初始化重新分配的服务器以使它们在重新启动时加入到第二管理组。优选情况下，每一管理组中的服务器的性能和运行状况通过专门用来跨管理组地连接服务器的单独的带外通信信道来监视。每个管理组都包括本地决策软件程序，该程序与主决策软件程序进行通信，主决策软件程序确定何时以及如何为响应使用需求、可用的资源和与每一客户帐户签定的服务等级协议动态地向不同的管理工作组重新分配服务器。

在一个实施例中，用于为多个客户帐户提供托管服务的动态管理的系统至少包括五台在操作上连接到一个内联网的服务器。每一台服务器都包括主机管理电路，该电路为通信信道至少提供内联网之外的其他服务器中的至少一台。至少有四台服务器执行本地决策软件程序，该程序监视服务器并跨通信信道传达状态信息。至少有两台服务器被分配到第一客户帐户的第一管理组，并被配置访问此第一客户帐户所特有的软件和数据，以便通过因特网为该客户帐户提供托管服务；其他服务器中至少有两台服务器被分配到第二客户帐户的第二管理组，并被配置访问此第二客户帐户所特有的软件和数据，以便通过因特网为该客户帐户提供托管服务。优选情况下，至少有一台服务器执行主决策软件程序，该程序从其他服务器收集状态信息，并至少响应状态信息将第一管理组中的至少一台服务器动态地重新分配到第二管理组。

与仅限于在单个客户帐户的环境内工作或要求大型而昂贵的计算机系统和公用操作系统或共享数据空间的现有的负载平衡系统不同的是，本发明能够动态地跨多个不同的客户帐户重新分配服务器，以便以比较经济而灵活的服务器场布局提供托管服务。本发明的支持多个客户的多个管理组的能力可以在不同的客户帐户之间进行智能和动态的服务器资源分配。

附图说明

图1是托管服务提供商的服务器场的现有技术布局的简化方框图。

图2是托管多个客户帐户的现有技术服务器场的服务器容量与因特网通信之间的关系的图形表示。

图3是根据本发明的服务器场的布局的简化方框图。

图4是类似于图3的简化方框图，显示了将服务器从第一客户帐户动态重新分配到第二客户帐户以解决硬件故障。

图5是类似于图3的简化方框图，显示了将服务器从第一客户帐户动态重新分配到第二客户帐户以解决使用需求增大的情况。

图6是根据本发明的服务器场的组件的首选实施例的方框图。

图7是根据本发明的服务器场的硬件的首选实施例的一个分解透视图。

图8是显示本发明为给定客户帐户利用的各个软件层的层次型关系的方框图。

图9是跨不同的地理位置实现的本发明的实施例的方框图。

图10是当托管多个客户帐户时本发明的服务器场的服务器容量与因特网通信之间的关系的图形表示。

图11是显示本发明的主决策软件程序的首选实施例的方框图。

图12是一个给定客户帐户的三个不同的服务等级协议布局的图形表示。

图13是本发明的多站点实施例的服务器容量与因特网通信之间的关系的图形表示。

图14是显示控制网络交换机和存储单元连接的主决策软件程序的方框图。

图15是显示本地决策软件程序的首选实施例的方框图。

图16是在不同的负载条件下本地决策软件程序的各个测量模块中的工作负载测量的图形表示。

图17是本地决策软件程序请求向管理组中添加服务器或从管理组中删除服务器生成的决策面的图形表示。

具体实施方式

参考图1，该图显示了一个托管服务提供商的现有的服务器场20的一个简化功能视图。这样的服务器场通常是使用现成的硬件和软件组件构建的，这些组件被静态地配置为支持给定客户帐户的托管服务要求。在此实施例中，托管服务提供商的服务器场20支持四个不同客户帐户的托管服务。服务器场20通过网络交换机/路由器24连接到因特网22。网络交换机24又连接到内部网络交换机/路由器26，它们在给定客户帐户的前端/内容服务器28和后端/计算服务器30之间构成了Intranet。所有前端/内容服务器28和后端/计算服务器30都连接到包含该客户帐户所特有的数据和软件的磁盘系统32。取决于服务器28、30的硬件的物理性质，磁盘系统32可以位于服务器外壳内，或者磁盘系统32可以位于直接连接到每一台服务器28、30或附属到多台服务器28、30的物理上分离的单元中作为存储附属网络(SAN)或网络附属存储(NAS)配置。

尽管此布局很好地使用现成的硬件来构建可以为多个独立的客户帐户提供托管服务的服务器场20，但是这种类型的布局中暴露了多个严重的问题。这些问题中最严重的问题是在不同的客户帐户之间分配和部署系统资源的一般性静态的性质。为了在此复合体内配置和管理单个客户帐户，HSP的管理员需要基于该客户的需求的预期要求将诸如服务器、磁盘、网络链接之类的系统资源的某些固定级别专用于特定的客户帐户。

例如，假设为任何给定客户帐户设计了相对简单的网站以使在预期的峰值负载下，客户帐户可能要求三台前端服务器28以处理用户的请求和四处理器后端服务器30以处理这些请求生成的数据库查询/更新。对于这种类型的网站，可以使用基于硬件的技术，如F5 Big-IP、Cisco Local Director或Foundry ServerIron，或使用基于软件的解决方案，如Windows负载平衡服务(WLBS)或等效的软件跨前端/内容服务器28均衡地分布用户请求。此外，后端数据库/计算服务器30通常形成群集以提供某些级别的容错。有许多软件产品，如MicrosoftCluster Server、Oracle Parallel Server等，它们可使具有多台服务器的网站克服在正常操作期间可能发生的硬件故障。此外，诸如TivoliEnterprise、HP OpenView、等等之类的系统监视工具可以当在服务器场20内检测到故障时给管理员发出通知。虽然这些工具可以适用于在给定站点的单个客户帐户内管理托管服务，但是这些工具中没有一个可以用于跨不同的客户帐户管理托管服务。

在此例的情况下，假设此客户帐户的网站是为处理每分钟5000个事务的峰值负载设计的电子商务站点。此外，还假设服务器场20中的其余客户帐户的网站是为分别处理每分钟10,000、15,000和5000个事务的峰值负载设计的。如图2所示，必须设计和配置每一个客户帐户以处理预期的峰值负载可能会导致整个服务器场20内的容量严重浪费。尽管处理多个客户帐户的服务器场20可能具有额外的聚合容量，但是一个帐户中的此额外的容量无法被用来响应另一个帐户中的硬件故障或峰值负载意外增大的情况。为特定客户帐户配置的资源专用于该帐户并且只专用于该帐户。在第一客户帐户的其中一台前端服务器28发生硬件故障的情况下，Web通信将被路由到其余的前端服务器28。如果客户帐户在发生硬件故障之前忙并且Web通信在发生故障之后保持不变或增大，那么其余的前端服务器28将由于服务它们以前的工作负载以及从故障服务器重定向的额外通信而很快被超载。在最佳的情况下，用于服务器场20的系统管理软件将发现服务器发生故障，并通过寻呼机和/或电子邮件发送一则消息到站点管理员，指出服务器发生了故障。如果站点管理员及时地接收到消息并位于该站点上，那么站点管理员可以从物理上除去发生故障的硬件组件，安装为此目的库存的备用硬件组件，重新连接新的硬件组件，为该客户帐户配置和安装适当的软件，并使新硬件组件重新加入到其余的前端服务器28。此过程可以有希望在不足一个小时的时间内完成。如果消息不能及时地接收到，如果站点管理员不位于服务器场所在的站点，或者如果没有库存的备用硬件可用来替换故障部件，那么此过程甚至要花更长的时间。在此期间，对于访问客户帐户的用户的响应时间下降，在这段时间内，客户帐户越来越容易发生另一个硬件故障。

在对客户帐户的需求增大并超过为该客户帐户配置的预期的峰值需求的情况下，负载平衡设备没有资源可用来重新分布此增大的Web通信。所有的服务器28、30将在峰值容量下运行。结果是显著地降低对客户帐户的响应时间并可能出现对无法及时地处理的请求的“服务不可用”响应。尽管无法及时地向消费者提供服务是人所不希望的，但也许易管理的，在其他环境中的企业的问题，为网站生成“服务不可用”消息的额外问题是，如果这样的消息不论什么原因而持续存在，因特网可能开始将此信息传播到网络中的很多中间节点。结果，由于这些中间节点理解网站“不可用”而将把后面的请求转发到其他网站。一旦客户帐户饱和或超载，不仅接收到“服务不可用”消息的消费者得不到服务，而且许多其他消费者也可能无法访问该网站。

现在参考图3，下面将描述用于向多个客户帐户提供托管服务的动态管理的服务器场40。与现有的服务器场20一样，服务器场40包括网络交换机44以便在服务器场40和因特网22之间建立互连。然而，与现有的服务器场20不同的是，服务器46的成员是在引擎组管理器48的控制之下管理的。每一台服务器46都通过网络交换机44以编程方式连接到因特网和连接到磁盘存储系统50的无状态计算设备。在一个实施例中，服务器46通过光纤通道存储区域网(SAN)连接到磁盘存储系统50。或者，服务器46可以通过网络附属存储(NAS)布局、可切换的纵横布局或任何类似的互连技术连接到磁盘存储系统50。

如图4和5所示，引擎组管理器48负责在多个客户帐户之间自动分配无状态的服务器46，然后为分配的帐户配置这些服务器。这是通过如下方式来执行的：将给定客户帐户的服务器分配到为该客户帐户定义的并被配置为访问该客户帐户所特有的软件和数据的公用管理组52。正如下文将要描述的，引擎组管理器48自动监视每一个管理组，并响应自动监视将第一管理组52-a中的服务器46′自动和动态地重新分配到第二管理组52-b。这是通过这样的方式完成的：使用引擎组管理器48为从第一管理组52-a重新分配的服务器46′设置初始化指针以访问第二管理组52-b的客户帐户所特有的软件和数据，然后重新初始化重新分配的服务器46′以使重新分配的服务器46′加入到第二管理组52-b。与用于向服务器场20中添加硬件资源或从中去除硬件资源的现有过程不同的是，本发明可以使重新分配的服务器46′在几分钟内即可对新的管理组52可用。基本上，使重新分配的服务器46′回到联机状态所需要的唯一有效的时间将是重新启动服务器46′所需要的时间以及负载平衡和/或群集软件识别重新启动的服务器所需要的所有时间。可以理解，负载平衡软件在前端/内容服务器上比较常见，而群集软件或群集软件和负载平衡软件的组合在后端/计算服务器中使用比较常用。将使用术语“负载平衡软件”来指这些可能的组合中的任何组合。

在一个实施例中，重新分配的服务器46′自动加入到第二管理组，因为第二管理组52-b的软件包括负载平衡软件，该软件响应回到联机状态(即重置和接通电源)或回到脱机状态(即重置和关闭电源)的服务器自动将服务器添加到管理组或从中去除服务器。如前所述，这种负载平衡软件今天已广为人们所熟知并广泛使用；然而，现有的负载平衡软件只能够向单个管理组添加服务器或从中除去服务器。在此实施例中，引擎组管理器48利用当前市场上可以买到的负载平衡应用程序软件的功能以便跨不同的管理组52动态地重新分配服务器46′。或者，单个管理组的操作系统软件内的代理或子程序可以负责一旦重新分配的服务器46′回到联机状态即将重新分配的服务器46′集成进入到第二管理组52-b。在另一个实施例中，引擎组管理器48可以将更新发布到每一个管理组52的可用服务器列表中。

优选情况下，引擎组管理器48将管理组52的每一台服务器46中的指针设置到启动映像软件和配置文件的适当的副本，包括为该管理组52建立的操作系统和应用程序。当重新分配的服务器46′被重新启动时，其指针已经被引擎组管理器48重置以指向第二管理组52-b的启动映像软件和配置文件，而不是第一管理组52-a的启动映像软件和配置文件。

一般来说，每一个管理组52都表示特定的客户帐户的服务器场40提供的网站或类似的托管服务。虽然不同的客户帐户可以由同一企业或相关的商业性实体支付费用，但是可以理解，与给定客户帐户关联的，因此与给定管理组52关联的数据和软件将是该客户帐户所特有的。与利用大型机系统向多个客户提供托管服务并使用单个公用操作系统实现大型计算机系统的资源的分时的服务提供商不同的是，每一个管理组52都包括独有的软件，包括不扩展到已经分配到管理组52的服务器46之外的传统的操作系统软件。本发明的分布式方法允许使用可以安装在相对便宜的单个服务器上的较简单的传统软件应用程序和操作系统。如此，组成管理组52的单个元素可以由市场上可以买到的相对便宜的硬件服务器和标准软件程序组成。

图6和7显示了根据本发明的服务器场40的组件和硬件的首选实施例。虽然是就此硬件来对本发明的首选实施例进行描述的，但是可以理解，本发明的概念同样适用于使用所有传统的服务器实现的服务器场，包括当前的1U或2U封装式服务器，如果那些服务器具有主机管理电路或者其等效物，如下文所述。

优选情况下，服务器场40的硬件是可扩展的引擎100，它由大量的市场上可以买到的服务器板102组成，每一个服务器板都作为位于省电和压缩的机柜110内的引擎刀片132。引擎刀片132垂直地位于机柜110的正面112，并可以拆卸。位于机柜110的中间带孔平面130向所有引擎刀片132提供公用电源并控制外围信号。每一个引擎刀片132的I/O信号通过带孔平面130中的孔连接到位于机柜110后部的接口卡134。I/O信号将通过适当的接口卡134并通过网络交换机44连接到因特网22或磁盘存储50。优选情况下，这些不同的通信路径使用单独的接口卡134。

可扩展的引擎由于通用的刀片托架结构103可以容纳同一机柜110中的不同类型的服务器板102。市场上可以买到的不同类型的主板102安装在通用刀片托架结构103上，该托架结构103提供了到机柜110的一致的机械接口。专门设计的可以插入到各种类型的主板102的PCI主机板可以通过带孔平面130连接到接口卡134。冗余热交换高效率电源144连接到带孔平面130上的通用电源信号。主机板104包括管理电路，该电路通过模拟ATX电源管理协议将电源信号分配到该引擎刀片132的服务器板102。可更换的风扇盘140安装在引擎刀片132下面以冷却引擎100。优选情况下，机柜110容纳底板组合128中的多行引擎刀片132，底板组合128包括一对彼此层叠在一起并位于电源机架146顶部的子底板129，电源机架146拥有电源144。优选情况下，机柜110还将包括安装在机架上的以太网网络交换机44和147和通过光纤通道网络连接到磁盘驱动器50的存储变换机149。

可以理解，尽管是这样描述本发明的：单个机柜110包含引擎刀片132以及服务器板102，它们与适当的应用程序软件一起构成了各种服务器46，这些服务器被分配到第一管理组52-a，和第二管理组52-b，每一个管理组都至少有两个引擎刀片132，但是，服务器场40也可以容纳任意数量的客户的管理组52，这要取决于服务器场40中的服务器46的总数。优选情况下，多个机柜110可以集成到一起以增加给定位置的服务器46的总数。正如将要讨论的，还可以将位于不同地理位置的多个机柜110链接在一起作为在引擎组管理器48控制之下运行的单个服务器场40的组成部分。

在首选的实施例中，每一个引擎刀片132的服务器板102可以安装有Intel、SPARC或PowerPC设计的最新处理器，每一个处理器都可以支持诸如Windows NT、Windows 2000、Linux或Solaris之类的标准操作系统环境。每一个引擎刀片132都可以容纳一个或多个服务器板102，并且每一个服务器板都可以根据当前ATX形状因数或者将来业界可能接受的新的形状因数的单处理器或多处理器设计。优选情况下，通信信道106是作为控制器区域网络(CAN)总线实现的，该总线与网络交换机44或存储交换机149的通信路径分开。还提供第二个错误备份通信信道106′以确保组管理器软件48的容错和冗余通信路径。

在传统的服务器中，指针和启动配置信息是由服务器板上的手动开关设置的或硬编码到服务器板上的PROM芯片组，或存储在服务器板可访问的本地硬盘上的固定位置。主机板104上的管理电路具有适当的挂钩挂到服务器板102，以使主机管理电路实际提供指针和其他启动配置信息。引擎刀片132还可以包括本地硬盘107，可以通过主机板104访问该硬盘，以使存储在本地硬盘107上的信息可以由主机板通过通信信道106进行配置。此外，主机板104优选情况下包括电源管理电路108，该电路能通过模拟ATX电源管理序列来控制服务器板102的电源应用，从而使机柜1 10使用公用电源。优选情况下，后信道以太网交换机147还允许在服务器场40内的各种服务器板102之间传递应用程序和数据信息，而不必通过因特网22传递这些通信。

在首选的实施例中，每个机柜110都最多可以包含32个引擎刀片132。在此配置中，网络交换机44和147可以包括来自Foundry的两个32电路交换以太网网络路由器。优选情况下，网络交换机44和147允许在服务器46和网络交换机44和147之间进行重新配置以便通过更改服务器的IP地址动态地进行调整。就磁盘存储单元50而论，有两个方案。首先，可以在引擎刀片132和磁盘存储单元50之间以纵横开关149的形式插入独有的硬件和软件，它们将抽象出基础SAN存储硬件配置的详细信息。在这种情况下，磁盘存储单元50和每个刀片132之间的链接将通过一组软件API被传递到纵横开关149。或者，可使用市场上可以买到的光纤通道交换机或RAID存储箱来在刀片132和磁盘存储单元50之间动态地建立连接。在这两个方案中，引擎组管理器48内的一层软件对服务器刀片132和网络交换机147和磁盘存储单元50之间的连接执行必要的配置调整。在另一个实施例中，服务器46的一部分可以永久地连接到网络交换机或磁盘存储单元来降低交换机成本，如果服务器场40的给定部分支持的一组客户帐户将始终包括无法被重新分配的服务器46的基本数量。在这种情况下，每个管理组52的服务器46的基本数量可以永久地连接到该管理组52的关联的网络交换机149和磁盘存储单元50。

再参考图4和5，可以看出，本发明的服务器场系统40可以动态地管理向多个客户帐户提供的托管服务。可以看出，至少有五台服务器46在操作上连接到Intranet54。优选情况下，Intranet是在将服务器46连接到因特网22相同的网络交换机44上构成的或在将服务器46彼此连接的诸如网络交换机147之类的类似的网络交换机上构成的。每一台服务器46在主机板104上具有管理电路，该电路给通信信道106至少提供与网络交换机44和/或147形成的Intranet 54分开的其他服务器46之一。

至少有四台服务器46被配置为执行本地决策软件程序70，该程序监视服务器46并跨通信信道106传达状态信息。这些服务器46中至少有两台服务器被分配到第一客户帐户的第一管理组，并被配置为访问第一客户帐户所特有的软件和数据，以通过因特网为该客户帐户提供托管服务。至少有另外两台服务器46被分配到第二客户帐户的第二管理组，并被配置访问第二客户帐户所特有的软件和数据，以通过因特网为该客户帐户提供托管服务。至少有一台服务器46执行主决策软件程序72，该程序从在其他服务器46上执行的本地决策软件程序70收集状态信息。在一个实施例中，一对服务器46使用容错协调软件连接到一起以构成主决策软件程序的容错/冗余处理平台。如下文所述，主决策软件程序72至少响应从本地决策软件程序70收集的状态信息将第一管理组52-a中的至少一台服务器46′动态地重新分配到第二管理组52-b。

两个管理组52的服务器46可以以为给定客户帐户指定的任何配置来排列。如图3所示，管理组52-b的三台服务器46被配置为前端服务器，单台服务器46被配置为此客户帐户的后端/计算服务器。为响应第二管理组52-b的客户帐户的高峰期间使用活动的剧烈增大，主决策软件程序72确定有必要将当前用作第一管理组52-a的服务器的服务器46′重新分配为作为第二管理组52-b的后端/计算服务器来使用。下面将结合对本地决策软件程序72的操作的描述来描述此决策是如何取得的首选实施例。在刚刚描述的过程之后，主决策软件程序72指示将重新分配的服务器46′动态地重新分配到第二管理组52-b，如图4所示。

虽然本发明的首选实施例是通过将第一管理组52-a中的服务器46′重新分配到第二管理组52-b来描述的，应该理解，本发明还可以提供一个可用的服务器46′的公用池，该公用池中的服务器当前不分配到给定管理组52并可以进行重新分配，而不一定要求将它们从工作管理组52中撤出。例如，可以建立具有三十二台服务器46的服务器场40以给四个不同的客户帐户中的每一个客户帐户分配六台服务器，一台服务器46执行主决策软件程序72，以及其余的最初未分配的七台服务器46建立一个池56，并可以分配到为该服务器场定义的四个管理组52中的任何组。由于根据本发明向管理组中分配服务器的工作是在服务器场40的正在运行期间动态完成的，本发明的首选实施例使用此池56作为一个缓冲，而没有必要首先将重新分配的服务器46′从其现有的管理组52，从而进一步缩短将重新分配的服务器46′加入管理组52所需要的时间。在一个实施例中，池56可以同时有暖服务器和冷服务器。暖服务器是已经配置给特定的管理组52的服务器46，因此要使该暖服务器加入管理组，没有必要将它重新启动。冷服务器是未配置给特定的管理组52的服务器，因此要使冷服务器加入到管理组，必须将它重新启动。

还应理解，重新分配的服务器46′可以一个一个地分配到新的管理组或作为具有多台重新分配的服务器46′的组同时从第一管理组52-a重新分配到第二管理组52-b。在如何对网络交换机44、147和存储交换机149进行配置以适应这样的动态重新分配的环境中，还应理解，如果必须减少网络交换机44、147和/或存储交换机149上的可动态配置的端口的数量或者如果这样做是理想的话，多台服务器46可以作为一个组一起重新分配。

本发明的一个比较明显的优点是将一个管理组52-a中的服务器重新配置给第二管理组52-b的过程将从重新分配的服务器46′清除与第一管理组的特定客户帐户关联的所有状态，然后才能将该服务器作为第二管理组52-b的组成部分来投入运行。这就提供了一个自然而非常有效的安全机制，以预防故意或无意地访问不同客户帐户的数据。除非服务器46或46′是给定管理组52-a的成员，否则该服务器将没有办法访问不同的管理组52-b的数据或信息。本发明不是采用在利用共享存储器空间和/或公用操作系统跨不同的客户帐户提供托管服务的大型机服务器或其他更大的服务器系统中必须实现的复杂而存在潜在问题的软件安全功能，而是保持了在传统的服务器场布局中常见的在客户帐户之间采用简单的物理隔离的优点，不但可以这样做，而且还可以在需要或有机会更好地使用某硬件的情况下使该硬件得到自动和动态的重新配置。这种重新配置的授权和控制的唯一访问点是通过主决策软件程序72并通过带外通信信道106。

如图14所示，优选情况下，每一台服务器46在主决策软件程序72控制之下以编程方式连接到因特网22。主决策软件程序72还切换重新分配的服务器46′以在操作上连接到存储第二管理组的客户帐户所特有的软件和数据的磁盘存储单元的一部分。优选情况下，由于考虑到安全、故障隔离和带宽隔离因素，使用通过网络交换机44与Intranet 54分离的带外通信信道106，以便至少传达主决策软件程序72利用的状态信息的一部分。在首选的实施例中，通信信道106是在机柜106内以1Mb/s的带宽运行的串行控制器区域网络(CAN)总线，辅助主干网还在不同的机柜106之间以1Mb/s带宽运行。可以理解，具有使用Internet协议(IP)协议进行通信的单独的Intranet可以用作通信信道106，代替诸如CAN总线之类的串行管理接口，虽然这样的实施例对于连接到主机板104的通信信道106所需要的通信的级别和复杂性是超标准设计。尽管可以作为Intranet 54的组成部分来实现通信信道106，但是因为安全、故障隔离和带宽隔离方面的原因，这样的方式不是首选的。

图8显示了本发明为给定客户帐户利用的各种数据和软件层的一个实施例的层次型关系的方框图。客户数据和数据库60构成了这种层次结构的基本层。也可以集成Web数据管理软件层62以跨构成存储系统50的存储单元的多个实例来管理客户数据60。群集和/或负载平衡应用程序软件64构成了通常被认为是客户的网站的软件和数据的最顶层。负载平衡软件66将多台服务器46作为公用管理组52的组成部分组合在一起。还存在传统的操作系统软件68的多个实例，每一台服务器46上都有一个。或者，负载平衡软件66和操作系统软件68可以作为单个管理组52内的公用软件程序包的组成部分来集成。在传统的操作系统软件68的上面，是本发明的引擎操作软件48，用于跨多个客户帐户52-a和52-b来管理资源。

在如图9所示的本发明的一个实施例中，分配到第一管理组52-a的服务器46位于第一个站点80，分配到第二管理组52-b的服务器位于地理上距离第一个站点80比较远的第二个站点82。在此实施例中，该系统进一步包括至少将第一管理组52-a的数据自动复制到第二站点82的布局。在首选的实施例中，使用与网络交换机44分离的通信信道84将第一站点80中的磁盘存储单元50-a的数据复制到第二站点82中的磁盘存储单元50-b。此布局具有双重目的。首先，数据的复制提供了冗余和备份保护，从而在第一站点80发生灾难的情况下进行灾难恢复。其次，第二站点82中的数据复制还可使本发明在可用的服务器池中包括位于第二站点82中的服务器46，主决策软件程序72可以通过动态地将这些服务器重新分配到第一管理组52-a用它们来满足对第一个客户的托管服务的需求增大的情况。

优选情况下，第一站点80和第二站点82的主决策软件程序72之间的协调，是通过使用与每个站点的主决策软件程序72进行通信的全局决策软件例程86来完成的。这种模块化布局可使主决策软件程序72侧重于管理给定站点中的服务器资源，并延伸这样的概念：让每个站点80、82从全局决策软件例程86请求额外的场外服务，或提供可用的场外服务，其方式与本地决策软件程序70请求额外服务器的方式相同，在给定站点使服务器可用于重新分配到主决策软件程序70。

优选情况下，本发明的多站点实施例利用市场上可以买到的SAN或NAS存储网络软件来实现两层数据冗余和复制层次结构。如图9所示，在第一站点80中的磁盘存储单元50维护了第一客户帐户的客户数据的工作版本74。使用诸如数据镜像、数据卷影或RAID数据保护之类的冗余数据保护来建立第一站点80的第一客户帐户的客户数据的备份版本76。网络软件利用通信信道84生成位于第二站点82的第一客户帐户的客户数据的第二备份版本78。优选情况下，使用与网络交换机44到因特网22的连接分离的通信信道84可以提供冗余通信路径，并最大限度地降低生成第二备份版本78所必需的后台通信活动的影响。或者，位于第二站点82的第一客户帐户的客户数据的备份版本78可以通过网络交换机44和因特网22进行路由。在另一个实施例中，客户数据的额外备份版本可以在额外的站点位置进行复制以进一步扩展系统的功能，以将未充分使用服务器资源的客户帐户的服务器重新分配到需要这些资源的客户帐户。

如图10所示，本发明的从未充分使用服务器资源的客户帐户的服务器重新分配到需要这些资源的客户帐户的能力，可以使服务器场40的资源向多个客户帐户提供托管服务，从而得到更有效的使用。对于每一个客户帐户91、92、93、94和95，向每个客户帐户完全分配了服务器46，以便为每个客户帐户维护相对稳定的少量超负荷带宽。与现有的服务器场不同的是，目前，对分配到给定客户帐户的硬件资源的更改是以小时、天或星期为单位来进行的，而本发明可以实现对按需要动态地分配的服务器资源进行以分钟为单位的更改。图10还显示了利用多个不同地理位置来放置服务器场40的各个部分的优点。可以看出，由于站点位置80和站点位置82之间的时区之间的时差，客户帐户94和95的使用高峰的时间，与其他客户帐户91、92和93的使用高峰的时间不同。本发明可以利用这些使用高峰的时间差来将起伏的服务器容量从活动不频繁的其他站点位置分配到处于使用高峰期间的站点位置。

在如图13所示的本发明的多站点配置的一个实施例中，至少有三个分离的站点位置80、82和84，优选情况下，它们位于彼此之间距离至少为24除N+1个小时的位置，其中N表示多站点配置中的不同的站点位置的数量。在具有三个分离的站点位置80、82和84的实施例中，优选情况下，站点位置彼此之间的距离为八个小时。这种地理位置上的分离实现的时差允许位于所有三个站点的客户帐户的使用模式通过在给定位置的每一台服务器不能够利用从一个或多个其他位置动态地重新分配的服务器所需要的数量不足的情况下由服务器的总数汇集和服务。当站点位置80体验到夜间使用级别时这样做的优点更加明显，此站点位置80中的服务器可以动态地重新分配到体验到白天使用级别的站点位置82。同时，站点位置84体验傍晚使用级别，可能适合或者也可能不适合将服务器从此位置重新分配到另一个位置或执行相反的操作。一般来讲，站点位置是这样安排的：以便首先从位于较晚的时区(即该站点的东边)的站点位置借容量，并使多余的容量对位于较早的时区(即该站点的西边)的站点位置可用。根据过去的使用模式和预测的使用模式来建立其他首选项。

现在参考图11，将描述主决策软件程序72的首选实施例。主决策软件程序72包括资源数据库150、服务等级协议数据库152、主决策逻辑模块154和调度模块156。主决策逻辑模块154可以访问资源数据库150和服务等级协议数据库152，并将状态信息与资源数据库150和服务等级协议数据库152中的信息进行比较以确定是否动态地将服务器从第一客户帐户重新分配到第二客户帐户。调度模块156在操作上链接到主决策逻辑模块154，以便在主决策逻辑模块154发出指示时动态地重新分配服务器，其方式是，使用通信信道106为重新分配的服务器46′设置初始化指针以访问第二管理组52-b的客户帐户所特有的软件和数据并重新初始化重新分配的服务器46′以使至少一台服务器加入到管理组52-b。优选情况下，调度模块156包括针对每一台服务器46的一组连接规则160和一组个性模块162。连接规则160提供将特定服务器46连接到给定网络交换机44或数据存储单元50的指令。个性模块162描述了要添加到客户帐户的管理工作组的服务器板102的特定软件配置的详细信息。一旦调度模块146确定需要重新分配服务器，它将评估连接规则160集和一组个性模块162以确定如何构建将调度到该特定管理组52的服务器46。

了解本发明如何动态地跨不同的帐户提供托管服务的另一个方式是视服务器46的一部分为分配到许多虚拟服务器的池，可以有选择性地配置这些服务器以访问特定管理组52的软件和数据。当调度模块146确定需要向特定的管理组52添加服务器46时，它就从虚拟服务器池中自动将一台服务器分配到该管理组。相反，如果调度模块确定一个管理组可以放弃其一台服务器46，则该放弃的服务器将被添加到可用于重新分配到不同管理组的虚拟服务器池。当从此角度来看本发明时，则可以看出，组管理器软件48运行以用此许多虚拟服务器池中的服务器实时或按需要地“制造”或创建一个或多台虚拟服务器。如前所述，虚拟服务器的池可以是暖池或冷池，或它们的任何组合。根据连接规则160集和个性模块162制造或构建虚拟服务器以便让需要的管理组利用。

在此实施例中，主决策逻辑模块152在操作上连接到管理控制台158，该控制台可以显示有关主决策软件程序的信息，并接受帐户维护并将进程信息更新到各种数据库。记帐软件模块160集成到引擎组管理器48中，以便基于向给定客户帐户分配的服务器跟踪记帐。优选情况下，当基于客户的服务等级协议服务器被动态地重新分配到某客户帐户时，向该客户帐户收取较高的托管服务费率。

图12显示了一个给定客户帐户的三个不同的服务等级协议布局的图形表示。在此实施例中，为在诸如一个月之类的给定时间段提供托管服务而签定了服务等级协议。在显示的第一级别170中，客户帐户具有为640,000个同时的连接支持托管服务的容量。如果客户帐户不需要重新分配服务器以支持大于第一级别170承诺的容量的容量，那么将向该客户收取承诺的容量的该级别的安装费用。在显示的第二级别172中，客户帐户可以被动态地扩展到第一级别172的容量双倍的容量。在首选的实施例中，一旦引擎组管理器48已经动态地将服务器重新分配到客户帐户以便支持第二级别172的容量，以满足高于预期的使用高峰的需求，将向客户帐户为需要额外使用的那段时间收取更高的费率。此外，还可以向客户帐户收取一次性费用，以便启动第二级别172表示的较高的服务级别。在一个实施例中，第二服务级别172的费用的费率是第一级别170的费率的许多倍。第二级别172表示在给定的一段时间内客户可用的有保证的扩展级别。最后，第三级别174提供了可选的额外的扩展服务级别，可以运用该级别为客户帐户提供托管服务。在此实施例中，第三级别174提供了第一级别170的服务级别多许多倍的服务级别。在一个实施例中，为了提供此扩展的额外服务级别，主机系统使用如前所述的多站点布局以便引进所需要的服务器数量，以便满足此级别的服务。优选情况下，向客户帐户收取重新分配到此客户帐户的扩展的额外服务的时间段的第二高费率。在一个实施例中，在向某客户帐户提供扩展的额外第三服务级别174的给定时间段内，第三服务级别174的费用的费率是第一级别170的许多倍。此外，也可以向客户帐户收取一次性费用，以便在给定时间段内随时启动第三服务级别174。在给定时间段结束时，客户可以修改给定客户帐户的服务级别。

如图12所示，服务等级协议响应给定客户帐户的较高的预期使用高峰从第一时间段到第二时间段增大50％。优选情况下，给定客户帐户的服务等级协议的时间段将以月为单位，可以向客户提出建议，是否愿意在未来的记帐时间段更改服务等级协议。虽然此示例是以同时的连接来演示的，应该理解，给定客户帐户的服务等级协议可以以各种性能测量来签定，如同时的连接、命中率、传输的数据量、事务的数量、连接时间、不同的应用软件程序利用的资源、产生的收入或它们的任何组合。还可以理解，服务等级协议可以为诸如前端服务器、后端服务器、网络连接或磁盘存储单元之类的不同的资源类型提供不同的承诺级别。

现在参考图15，将描述本地决策软件程序70的首选的实施例的方框图。一系列测量模块180、181、182、183和184中每一个模块都对运行本地决策软件程序70的特定服务器的操作执行独立的评估。这些测量模块的输出被提供到本地决策软件程序70的聚合器模块190。预测器模块192为各种请求产生预期的响应时间和概率。借助于服务等级协议数据库152中的主决策软件程序72提供的优先级输194，模糊推理系统196确定是否作出为管理组52添加引擎刀片104的请求，或是否作出从管理组52放弃或除去引擎刀片的提议。然后添加或除去刀片的请求通过通信信道106被传达到主决策软件程序72。在一个实施例中，聚合器模块190在给定管理组52内的每一台服务器46上执行，并且预测器模块192和模糊推理模块196只在给定管理组52内的单个服务器46上执行，各种测量模块180-184的输出通过通信信道106被传递到指定的服务器46。在另一个实施例中，聚合器模块190、预测器模块192和模糊推理模块196可以在给定管理组内的多台服务器上执行，以便达到冗余或分布式处理产生添加或除去刀片的请求所必需的信息。

优选情况下，聚合器模块190根据下列公式完成跨各种测量模块180-184的平衡操作：

B_k＝[(∑T_ki/w_k)-min_k]*100/(max_k-min_k)-50

i＝1到w_k

其中T_ki是测量类型k的第i个请求所需要的时间，w_k是测量类型k的窗口大小，min_k是测量类型k的预期最小时间，而max_k是为测量类型k容忍的最大时间。然后，平衡的请求率B_k被传递到预测器模块192和本地决策软件程序70的模糊推理模块196。将设置测量类型k的窗口大小以最大限度地降低任何测量模块180-184的无用的入侵，而同时允许及时地并适当地响应对管理组52的使用需求的增大。

图16显示了在不同的负载条件下各个测量模块180-184中的工作负载测量的样本。可以看出，没有任何单个工作负载测量提供预期的响应时间和该响应时间的概率的持续可预测的估计。如此，模糊推理模块196必须考虑三个基本参数：各种请求的预测的响应时间、这些请求的优先级，以及它们的发生概率。模糊推理模块196将所有这三个考虑因素综合起来以作出确定，是否请求添加刀片或从管理组52中除去刀片。下面是一个模糊推理规则的示例：

如果(优先级较高)并且(概率较大)并且(预期的响应时间太高)，那么(请求额外的刀片)。

优选情况下，模糊推理模块196的最终结果将产生决策面，该表面反映在预期的响应时间内请求额外服务器的需要与此管理组52的该响应时间的概率。图17显示了这样的决策面的示例。

本发明的说明部分受到版权法的保护。版权所有者允许对本发明的说明进行传真复制作为专利和商标办公室文件或记录，但其他方式将保留所有版权。

虽然描述了本发明的自动系统的首选实施例，但是可以理解，可以作出很多更改和变化，本发明的范围将由权利要求进行定义。