背景技术
现今,因特网被广泛地用于向使用浏览器的用户传送应用程序。因特网还被用于Web上贸易,其中各个消费者和企业使用Web来购买各种货物和服务。事实上,某些公司仅在Web上供应货物和服务,而其他公司则使用Web来扩展他们的领域。
关于这些贸易活动以及其它活动,企业和其它内容供应商使用服务器来处理来自不同用户的请求。各种架构被用来处理这些请求。通常,其中具有群集中的的一组服务器(“服务器群(server farm)”)的分布式架构被用来处理请求。在这样的服务器群***中,服务器组在用户看来就像是单个服务器。负载平衡机制可被用于确定服务器群中的哪个服务器将被用于处理送往该服务器群的各种请求。
配置和维护服务器群内的各种服务向来就是一个难题。随着给定服务器群中的所采用的服务器总体数量的增长,该问题被加剧。为了适当地维护服务器群内的服务器,各服务器必须不时地被更新。这些更新包括由服务器所提供的配置数据和服务,从而确保服务器的每一个的某些设置相对于彼此同步,并且接近实时地保持对存在于服务器群的服务器上的各种服务和应用程序的理解。
遗憾的是,执行服务器管理的当前技术无法提供能够对服务器群内的服务器进行***和全面管理的内聚性方法。例如,一个组织中的典型的因特网***结合多个Web服务器来实现高度可靠的和可升级的方式。这种群实现中的Web服务器必须进行一致配置,因为它们支持同一组逻辑内容。然而,随着时间的流逝,服务器群可能需要使用针对特定用户需要的解决方案(“客户解决方案”)来更新。例如,可能需要将新的应用程序组件应用于服务器群中的服务器。然而,因为单独的服务器具有其自身的逻辑和物理特性,这些服务器的管理员通常不具有执行一个操作的能力以及不具有一致地应用该操作到服务器群中的多个服务器的能力。结果,服务器群的管理员必须访问每个服务器并分别在每个服务器上部署客户解决方案。
客户解决方案的这种单独部署引起了一些问题。首先,如果多个服务器用于支持同一逻辑内容,则在每个服务器上单独地部署客户解决方案可导致不一致问题。服务器上的解决方案的不一致部署可引发对同一逻辑内容的非预期操作。第二,管理员在分别对各个服务器部署多个解决方案的期间可能出错。结果,这些错误在服务器中将自身表现为不一致且难以诊断的问题。对于管理员而言,确保多个服务器就它们所部署的解决方案的状态彼此一致是困难的。因此,期望为服务器群中的服务器集中存储诸如应用程序设置和解决方案的所有配置数据。还期望可将集中存储的配置数据基于请求以一致的方式自动地部署到服务器群中的所有服务器中。
发明内容
本发明通过提供用于在服务器群上部署解决方案来解决上述需要。本发明的另一个方面是提供为服务器群中的所有配置数据的主副本(master copy)的配置数据库。配置数据库可包括为该服务器群收集的包含解决方案的逻辑对象的解决方案存储(solution store)。这些逻辑对象包括解决方案的二进制表示,以及诸如解决方案的状况的关于该解决方案的信息,例如解决方案是否已被部署到服务器群。
本发明的另一个方面提供了用于向解决方案存储提交解决方案的多个机制。这些机制可使用命令行工具或Web接口来向服务器群提交解决方案。Web接口可在远离服务器群的***上。较佳地,每个被提交的解决方案扩展一个配置对象模型,该模型允许在不需要开发者了解或更改配置数据库的模式的情况下,将解决方案添加到解决方案存储。提交解决方案可能需要对解决方案存储的特定访问权。被提交的解决方案可能还需要通过一些验证核对以便确保解决方案在逻辑上正确、没有病毒或另外与服务器群环境兼容。无法通过验证核对的解决方案将不被部署在服务器群上。
本发明的又一个方面允许服务器群的管理员检查所提交的解决方案的列表,以便选择向服务区群中的所有服务器部署所提交的解决方案的一个或多个。一旦选择了解决方案,则可立刻进行解决方案的部署。解决方案的部署还可延迟到稍后的时间来进行,例如在服务器群的使用率较低的午夜。
在服务器群中的服务器的每一个上的定时器服务用于在包括多个服务器的服务器群上部署解决方案。定时器服务可以用两个阶段来部署解决方案。在第一阶段,定时器服务从配置数据库中检索解决方案包(bundle)、拆开解决方案包以及将解决方案文件存储到服务器上的指定目录中。在第二阶段,定时器服务在服务器上安装解决方案。具有比定时器服务更高特权的***服务(“管理服务(Admin Service)”)可用于将解决方案安装到服务器***的特权区域。当完成解决方案的安装时,定时器服务向配置数据库发送安装完成消息。较佳地,如果解决方案已被成功地安装在所有服务器上,则配置数据库将更新解决方案的状况,例如从“将要部署”到“已部署”。然后,每个服务器将执行解决方案文件中的定制解决方案代码。
总之,本发明提供了一种***和方法,使得解决方案的开发者能够将用于服务器群的解决方案提交到服务器群中的集中位置,同时服务器群的管理员可独立地选择是否部署这些解决方案以及何时部署。结果,可将用于服务器群的解决方案一致且自动地部署到服务器群中的所有服务器。
根据本发明的一方面,提供了一种服务器群,包括:中央数据库,用来存储用于所述服务器群的解决方案;以及多个服务器,其中每个服务器包含用于自动地将一个或多个所述解决方案部署到所述服务器的服务;其中,所述服务器群还包括使所述服务器群中的服务器与已被部署到所述多个服务器的所述一个或多个解决方案同步的同步机制,其中所述服务器是从所述多个服务器之一与所述服务器群的新服务器构成的一组服务器中选择。
根据本发明的另一方面,提供了一种用于在包括多个服务器的服务器群中部署解决方案的计算机实现方法,包括:将向所述服务器群提交的解决方案存储在中央数据库中;当接收到请求时,标识用于部署到所述多个服务器的所述解决方案的一个或多个;以及将所述一个或多个解决方案部署到所述多个服务器;其中,所述方法还包括使所述服务器群中的服务器与已被部署到所述多个服务器的所述一个或多个解决方案同步,其中所述服务器是从由所述多个服务器之一与所述服务器群的新服务器构成的一组服务器中选择。
本概要被提供用于以简化形式介绍将在以下具体描述中进一步描述的概念的精选。本概要并非旨在标识所要求保护的主题的关键特征或本质特征,也并非旨在用于帮助确定所要求保护的主题的范围。
示例性实施例的详细描述
图1示出了可在其中实现本发明的一个示例性实施例的数据处理***的网络100的图示。数据处理***的网络100包括网络102,该网络102是用于在数据处理***的网络100内连接在一起的各种设备与计算机之间提供通信链接的介质。网络102可包括诸如有线或无线通信链接、光纤电缆等的连接。
如图1中所示,数据处理***的网络100包括至少一个服务器群104和多个客户机108-112,所有这些都连接到网络102。服务器群104一般被呈现为用于处理请求的单个服务器或“虚拟”服务器的一组服务器构成。客户机108、110和112是服务器群104的客户机。这些客户机108、110和112可以是例如个人计算机或网络计算机。一般而言,服务器群104向客户机108-112提供诸如引导文件、操作***镜像、应用程序、Web内容的数据。数据处理***的网络100可包括未示出的附加服务器、客户机和其它设备。
在所示示例中,数据处理***的网络100是因特网,其中网络102表示使用TCP/IP协议族来彼此通信的网络和网关的全球范围的集合。在因特网的中心处是主节点或主机之间的高速数据通信线路的主干。这些节点或主机包括路由数据和消息的成千上万的商业、政府、教育和其它计算机***。网络数据处理***100还可实现为诸如内联网、局域网(LAN)或广域网(WAN)等许多不同类型的网络。图1旨在作为示例,而无意作为本发明的架构上的限制。
图2是根据本发明的一个示例性实施例的服务器群104的框图。如图2中所示,服务器群104包括诸如202A、202B、202C等彼此通过通信***212通信的多个服务器。通信***212用于处理发向服务器群104的路由请求和响应。通信***212可采用包括例如总线、网络、共享存储器等在内的各种。
服务器群104可包括连接到通信***212并且用于接收从网络102发往服务器群104的请求的负载管理器214。这些请求可包括从客户机108-112(图1)接收的请求,并且可包括例如对网页、文件以及其它内容的请求。负载管理器214操作向用于将请求分布到服务器202A-202C以便处理。实质上,负载管理器214操作用于确保服务器群104的服务器202A-202C中没有一个多余地承担由服务器群104作出的请求。
在本发明的实施例中,服务器群104包括基本上存储用于服务器群104的所有配置数据的配置数据库218。在本发明的实施例中,配置数据库218是服务器群中的所有配置数据的主副本,从而使得相同的信息在服务器群104中的一组服务器上可用。配置数据库218可操作地连接到通信***212以便使得配置数据能被发送到服务器群104中的服务器202A-202C的每一个。配置数据库218用于管理服务器202A-202C的每一个的配置设置。因此,配置数据库218起到用于必须被改变和/或添加到服务器群104的各个服务器202A-202C的任意配置设置的中央存储库的作用。提供配置数据库218消除了必须手动更新和/或添加服务器202A-202C的配置设置的需要。除存储关于服务器拓扑的信息之外,配置数据库218还可存储诸如安全策略、反病毒定义(antivirusdefinition)、语言设置等的应用程序专用设置。在本发明的实施例中,配置数据可存储一个或多个解决方案,它们可应用到服务器群104中的服务器。解决方案包括包含应用程序代码、定义或本地化资源的、可指导服务器提供特定内容或服务的打包文件。较佳地,如图3中所示,配置数据库218可包括命名为解决方案存储300的独特单元。解决方案存储300可包括一组逻辑对象。每个逻辑对象包括表示解决方案的二进制文件以及关于每个解决方案的状况的状态信息,诸如解决方案是否已被选择用于部署,或者解决方案是否已部署等。
服务器群104还可包括至少一个内容存储220。类似于服务器群104的其它操作要素,内容存储220可操作地连接到通信***212以便使得存储在内容存储220内的信息能够被分布到服务器群104的各个组件。在本发明的示例性实施例中,内容存储220包含用于服务器群104中的服务器的数据。这些数据包括文档、数据项、讨论(discussion)、任务等。内容存储220连同配置数据库218一起操作以提供与服务器202A-202C的一个或多个的给定配置的改变具体相关的内容。在本发明的示例性实施例中,内容存储220不与配置数据库218接口。配置数据库218包含哪个内容数据库存储用于服务器的数据的映射。结果,无需查询服务器群104中的每个内容存储220来查看内容存储是否包含用于服务器群104中一特定服务器的内容。
在本发明的示例性实施例中,服务器群104是可任意扩展的。这包括服务器群104可用服务器202A-202C之外的多个服务器进行任意扩展。另外,服务器群104可包括用于存储服务器群104中的多个服务器的数据的多个内容存储220。
具体地,本发明的实施例使得能够通过多个传输机制将解决方案添加到配置数据库218和/或解决方案存储300。图3示出了通过其可将解决方案提交或添加到配置数据库218的示例性传输机制。一个示例性传输机制是命令行接口301。另一个示例性传输机制是Web接口304。Web接口304可在服务器群的外部,并且通过网络102与配置数据库218通信。这种Web接口304提供了用于提交解决方案的远程技巧。用于将解决方案与配置数据库218结合成整体的其它替代传输机制包括使用远程程序调用或SOAP接口以便于服务器群104的解决方案的自动地提交和部署。
在本发明的示例性实施例中,所提交的解决方案扩展一个配置对象模型302,该模型能够任意扩展配置数据库218。该配置对象模型302使得用户在无需用户了解或更改配置数据库218的模式情况下,能够扩展或更新用于服务器群104的配置数据。在本发明的一个示例性实施例中,配置对象模型302包括基于.Net对象的类。用户可用特定的配置数据通过子类化或实例化该基类来扩展该基类。然后,这些数据被集成到配置数据库218中。结果,用户仅需要通过配置对象模型302来向配置数据库218添加不同类型的数据。用户无需了解或更改配置数据库218的模式。在本发明的一个示例性实施例中,包含用于应用程序的配置信息的对象是或者从命名为例如PersistedObject的基类派生或者为其所包含。当更新时,该类将序列化(serialize)为所有字段都用“持久化”属性标记的XML,并且将该XML二进制大型对象写入配置数据库218中。该基类包含用来对其所有基类型的成员、对其它PersistedObject或者两者之一的集合序列化的代码。这种设计使得包含用于服务器群104的配置数据的新的对象能够按需被添加到配置数据库218中。
在本发明的示例性实施例中,不管传输机制如何,将解决方案提交到配置数据库218的开发者或管理员必须具有访问配置数据库218的特定权限。没有这些特定权限,则开发者或管理员无法将解决方案提交到配置数据库218。另外,在本发明的示例性实施例中,仅当所提交的解决方案通过特定验证核对以确保解决方案在逻辑上正确、没有病毒或另外与服务器群104兼容时,才部署所提交的解决方案。
因而,配置数据库218和/或解决方案存储300为存储由服务器群104的开发者和/或管理员提交的解决方案提供了集中位置。可保证将解决方案提交到配置数据库218,而与从配置数据库218部署该解决方案的能力无关。这种分离使得服务器群104的管理员能够允许开发者提交解决方案同时保留在部署这些提交之前独立地审查这些提交的能力。
本发明的实施例自动地将给定解决方案部署到诸如服务器群104的服务器群中的多个服务器。本发明的实施例提供了用于查询以及将解决方案从配置数据库218下拉到服务器群104中的服务器的基于拉式(pull-based)的机制。在本发明的示例性实施例中,这种基于拉式的机制通过包含在服务器群104中的每个服务器中的定时器服务来实现。定时器服务查询配置数据库218以便同步任何未决的改变。这些未决的改变包括对解决方案存储300或运行于整个服务器群104上的一组定时器作业的任何改变。使用这种基于拉式的机制避免需要打开诸如服务器202A的服务器上的附加TCP/IP端口以与配置数据库218通信的需要。通过无需附加打开端口,由于没有向黑客、病毒或其它攻击形式暴露可能的入口从而获得较少的风险。图4示出了用于查询或从配置数据库218下拉解决方案的基于拉式的机制的一个示例性实现。如图4中所示,服务器202A包含定时器服务402。在工作中,定时器服务402查询配置数据库218和/或解决方案存储300以确定哪个解决方案(如果有)需要被部署到服务器群104以及由此到服务器202A。
在本发明的实施例中,服务器群104的管理员可检查解决方案存储300中所提交的解决方案的列表。管理员可选择部署所提交的解决方案的一个或多个,并且可选择对服务器群104中的一组服务器进行,或者对整个服务器群进行。
在本发明的实施例中,管理员还可选择尽可能快的合理部署(“立即部署(immediate deployment)”)或在稍后的时间部署(“延迟部署(delayeddeployment)”)解决方案。当服务器群104中仅有一个服务器或当无需延迟部署解决方案存储300中的解决方案时,立即进行解决方案存储300中的解决方案的部署。存在两种立即部署。在一个服务器的服务器群的情形中,在管理员发出部署请求的同一***中进行立即部署。不需要诸如定时器服务402的基于拉式的机制。在多个服务器的服务器群104中,立即部署首先使用作为通信机制的定时器服务402来通知服务器群104中的其它服务器的定时器服务开始部署。当管理员希望在多个服务器的服务器群104中延迟部署解决方案时,例如直至服务器群104的使用率较低的午夜,则解决方案的部署称为延迟部署。定时器服务402被用在延迟部署中。
在本发明的示例性实施例中,定时器服务以两个阶段执行解决方案的部署。在第一阶段,定时器服务402指导服务器202A从配置数据库218检索解决方案包、拆开解决方案包以及将解决方案文件存储到服务器202A的指定目录中。一旦服务器群104中的所有服务器已一致地部署解决方案,且没有发生失败,则定时器服务402启动第二阶段。在第二阶段期间,定时器服务402安装解决方案文件、执行用于服务器202A的任何定制解决方案代码以及更新配置数据库218中的配置信息。如果服务器群104中的一个或多个服务器无法适当地部署解决方案,则不对配置数据库218中的配置信息产生影响。
在本发明的示例性实施例中,定时器服务402使用受限的特权来部署解决方案。这种受限的特权使得定时器服务402能够与配置数据库218通信或对其更新,但不能对其上运行定时器服务402的服务器202A上的实体进行操作。这种分离确保定时器服务402不接收超出所需的安全特权。然而,对于诸如将解决方案安装到服务器中的特权区域中的操作而言,定时器服务402的受限特权是不足的。在这种情况中,定时器服务402与命名为管理服务(Admin Service)404的第二服务通信。管理服务404对服务器202A具有提升的特权,并且可将解决方案安装到服务器202A中的特权区域。
本发明的一些实施例还提供了同步机制,该机制使得管理员能够从配置数据库218下拉经更新的解决方案并将该解决方案应用到服务器群104中的诸如服务器202A的特定服务器。此机制使得管理员能够修正服务器群104中的特定服务器,或者配备刚加入服务器群104的新服务器以使该服务器与服务器群104中的其它服务器保持同步。同步机制将解决方案存储300中的一组所部署的解决方案与已本地部署在特定服务器上的一组文件及改变作比较,并且从解决方案存储300下载丢失的文件或改变。同步机制可用于通过使其与解决方案存储300中向服务器群104中的所有服务器指定的状态一致来修正服务器的状态。同步机制还可允许管理员明确地选择更新一个或多个服务器,而并非使用定时器服务402来向服务器群104中的所有服务器部署解决方案。
在本发明的一个实施例中,管理员还可选择取消已部署在服务器群104中的所有服务器上的解决方案。解决方案的取消与上述解决方案部署相反。取消操作请求服务器群104中的所有服务器移除一个或多个已部署的解决方案。较佳地,取消操作不包括从配置数据库218移除解决方案。
图5A-5B包括表示用于将解决方案部署到服务器群中的服务器的一个示例性进程500的流程图。在本发明的一些实施例中,当解决方案被提交到服务器群中的配置数据库时,解决方案经历验证。解决方案的验证包括确定解决方案是否在逻辑上正确、是否没有病毒或另外是否与服务器群环境兼容。这样,进程500通过验证任何所提交的解决方案来开始。参见框502。然后,进程500继续进行确定验证是否成功。参见判决框504。如果验证失败,则进程500前进到继续端A。如果判决框504的答复为是,表示验证成功,则解决方案准备好部署。或者,在解决方案要部署到服务器群之前,所提交的解决方案经历验证进程。
如上所述,当管理员选择解决方案进行部署时,解决方案的部署可立即发生。解决方案的部署还可调度成在诸如服务器群的使用率较低的午夜的稍后的时间。进程500允许诸如管理员的用户调度解决方案的部署。参见框506。将解决方案部署到服务器群中的所有服务器。因而,进程500经历以判决框508开始且以判决框518结束的循环以将解决方案部署到服务器群中的每个服务器。在循环中,进程500首先确定服务器是否已从运行于服务器上的诸如图4中所述的定时器服务402的定时器服务接收到调用。参见判决框508。如果答复为否,则进程500不再前进。如果判决框的答复为是,表示服务器已从要部署解决方案的定时器服务接收到调用,则进程继续进行允许服务器从集中存储用于服务器群的解决方案的配置数据库中检索解决方案。参见框510。然后,服务器将包含在所下载的解决方案中的文件打开到服务器中的适当目录。参见框512。当需要时,进程500允许服务器中的诸如图4中所述的管理服务404的管理服务来为解决方案引导安装进程。参见框514。安装进程将解决方案文件复制到适当的目录并设置适当的解决方案配置。当结束安装进程时,定时器服务向配置数据库发送消息指示解决方案已被部署并安装在服务器上。参见框516。然后,进程500检查是否在服务器群中有另一个服务器需要部署解决方案。参见判决框518。如果答复为是,则进程500返回到判决框508以认证其是否开始为其它服务器部署解决方案。如果框518的答复为否,表示服务器群中没有服务器再需要部署解决方案,则进程500前进到继续端B。
在本发明的实施例中,仅当解决方案通过验证时,才对服务器群中的所有服务器部署解决方案。因此,当解决方案无法通过验证时,从继续端A(图5B)向用户——例如请求在服务器群上部署解决方案的管理员——发送消息,以指示解决方案的验证失败。参见框520。结果,存在于服务器群中的服务器上的任何解决方案文件将被删除,尽管配置数据库较佳地仍保留此解决方案包。参见框522。然后,进程500退出,而解决方案并未被部署到服务器群中的任何服务器。
相反。当已在服务器群中的所有服务器上成功地部署并安装解决方案,则服务器执行任何定制的解决方案代码,并且该配置数据库将更新其与该解决方案相关的数据。例如,配置数据库中的解决方案的状况可从“将要部署”变成“已部署”。因此,当服务器群中的服务器已成功地安装解决方案时,进程500从继续端B(图5B)继续进行以更新与该解决方案相关的配置数据库。参见框524。然后,进程500继续进行以允许服务器群中的所有服务器执行与解决方案相关联的任何定制解决方案代码。然后,进程500结束。
虽然已示出并描述了本发明的示例性实施例,但是应当理解,可对本文作出各种改变而不背离本发明的精神和范围。