CN102571906B

CN102571906B - 打补丁期间机器的高可用性

Info

Publication number: CN102571906B
Application number: CN201110339912.8A
Authority: CN
Inventors: A·霍普曼; Z·罗森菲尔德; M·K·温德尔; P·西梅克; E·R·莱尔马; D·巴尔-卡斯彼; T·塞维尔米什; M·卢斯安诺夫
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2010-10-20
Filing date: 2011-10-19
Publication date: 2014-09-10
Anticipated expiration: 2031-10-19
Also published as: CN102571906A; SG189385A1; WO2012054160A3; US20120102480A1; SG10201508633UA; WO2012054160A2

Abstract

本发明公开了打补丁期间机器的高可用性。云管理器被用于对用在在线服务(诸如在线内容管理服务)内的物理机和虚拟机进行打补丁。云管理器有助于对将软件补丁应用于网络内的机器(物理和虚拟)进行调度，以使得在机器正被打补丁的同时维持在线服务的可用性。将要被打补丁的机器划分成数个组，这些组在不同时间被打补丁。一般而言，将组划分成高可用独立机器组，以使得当前未被打补丁的组中的一个或多个继续提供正被打补丁的组的服务。可并行地对每个组内的机器(物理和虚拟)进行打补丁。

Description

打补丁期间机器的高可用性

技术领域

本发明涉及计算机技术，尤其涉及打补丁期间机器的高可用性。

背景技术

基于web的应用包括位于web服务器上的文件和存储于数据库中的数据。例如，存在大量位于不同网络中的服务器，以处理针对该服务的通信量。对包括大量服务器的在线服务的部署、升级、打补丁和操作进行管理是一种耗时的过程，该过程需要很大的操作人员队伍，这些人员队伍会经历人为错误。

发明内容

提供本发明内容以便以简化形式介绍在以下具体实施方式中进一步描述的一些概念。本发明内容并非旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。

云管理器被用于对用在在线服务内的物理机和虚拟机进行打补丁。云管理器有助于对将软件补丁应用于网络内的机器(物理和虚拟)进行调度，以使得在机器正被打补丁的同时维持在线服务的可用性。将要被打补丁的机器划分成数个组，这些组在不同时间被打补丁。一般而言，将组划分成高可用独立机器组，以使得当前未被打补丁的组中的一个或多个继续提供正被打补丁的组的服务。可并行地对每个组内的机器(物理和虚拟)进行打补丁。

附图说明

图1示出了用于管理与诸如内容管理服务之类的在线服务相关联的网络的云管理器系统；

图2示出了包括管理器和相关联的数据库的云管理器；

图3示出了存储在数据库的行内的示例性作业记录；

图4示出了用于网络的示例系统，该网络包括用于在线服务的前端和后端服务器；

图5示出计算机的计算机体系结构；

图6示出了用于对在在线服务内使用的机器进行打补丁的补丁系统。

图7示出用于对在线系统中的机器进行打补丁的过程。

具体实施方式

现将参考附图来描述各实施例，在附图中类似的标号代表类似的元素。

一般而言，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、组件、数据结构和其它类型的结构。也可使用其它计算机系统配置，包括手持式设备、多处理器系统、基于微处理器或可编程消费电子产品、小型计算机、大型计算机等等。也可使用在其中任务由通过通信网络链接的远程处理设备执行的分布式计算环境。在分布式计算环境中，程序模块可位于本地和远程存储器存储设备两者中。

图1示出了用于管理与在线服务相关联的网络的云管理系统。系统100示出了云管理器105，该云管理器105被连接到可能分布在世界各地的不同网络并对其进行管理。网络中的每个被配置成为一个或多个承租人(例如客户、顾客)提供内容服务。这些网络可以被主存(host)在云服务内和/或内部部署(on-premises)数据中心内。云管理器105用于对这些网络进行部署、配置和管理。云管理器被配置为通过可容忍间歇性网络故障的幂等且异步的应用web服务应用程序编程接口(API)150来接收请求。

如所示的，云管理器105包括工作管理器110、机器管理器115、应用专用管理器120、脚本130以及诸如数据存储140(例如，数据库)之类的中央储存库。未包括在所示管理器之一内的功能可以驻留在云管理器的某个其他位置。根据一个实施例，应用管理器120是SharePoint承租人管理器，该管理器包括SharePoint专用逻辑。

工作管理器110管理任务的执行，并且启用对较长时间运行的任务的调度和重试。工作管理器110启动存储在作业队列112中的作业并且跟踪运行中的作业。当已经流逝了预定的时间时，工作管理器110可以自动地取消任务并且执行与该任务相关的某些进一步处理。根据一个实施例，作业队列112中的任务由工作管理器110通过调用一个或多个脚本130来执行。例如，可以使用诸如微软的之类的脚本语言来对由工作管理器110执行的任务进行编程。每个脚本可以作为新进程运行。尽管将每个脚本作为新进程来执行可以具有相当高的CPU开销，但是该系统是可伸缩的，并且帮助为每次脚本执行确保干净的环境，加上在脚本完成时进行完全的清理。

机器管理器115被配置成管理网络(例如网络1、网络2、网络3)中的物理机器。一般而言，机器管理器115理解网络、物理机器、虚拟机(VM)、VM镜像(VHD)等等。机器管理器不必牢固绑定于网络内运行的特定服务，而是在“角色”方面跟踪网络中的各种组件。例如，可以通过API 150请求机器管理器115在网络3上部署具有版本12.34.56.78的“Foo”型VM。响应于对云管理器105的请求，机器管理器115对位于网络3上的合适物理机器进行定位，并且根据与VM的角色相关联的VM镜像来配置VM。使用具有版本12.34.56.78的Foo型VHD来配置物理机器，该VHD被存储在诸如数据存储140之类的数据存储内。在网络内使用的镜像也可以存储在其他位置处，诸如用于所述网络中的一个或多个网络的本地数据共享中。可以运行脚本来执行VHD在物理机器上的安装以及用于执行任何部署后的配置。机器管理器115跟踪每个网络的机器配置。例如，机器管理器115可以跟踪VM的角色(VM的类型)、VM的状态(供应中(Provisioning)、运行中、已停止、已故障)、版本以及VM是否存在于给定场(farm)中(这隐含了其网络)。

脚本130被配置为存储将要执行以便既本地地为云管理器105执行工作又远程地在所述网络中的一个或多个网络上执行工作的脚本。脚本130中的一个或多个还可以存储在其他位置。例如，将要在网络(例如网络1、网络2、网络3)上执行的脚本可以本地地存储到该网络。这些脚本可用于许多不同目的。例如，所述脚本可以用于执行：对所述网络中的一个或多个网络中的机器的配置，改变之前配置的机器上的设定，添加新的VM，添加新的数据库，将数据从一个机器移动到另一个，移动承租人，改变模式等。根据一个实施例，这些脚本是微软的脚本。也可以使用其他编程实施方式。例如，可以使用编译和/或前期绑定编程语言来实现该功能。然而，脚本是一种表达将要执行的任务中的许多个的相当精确的语言。用诸如C#的编程语言对其等价物进行编程将常常需要冗长得多的实施方式。脚本还被后期绑定，这意味着可以以多个版本的底层代码库为目标，而不必不断地链接到不同的接口DLL。使用PowerShell脚本将允许进程由云管理器105本地地启动，云管理器105进而可以启动远程机器(即，所附连的网络之一中的物理机器)上的进程。还可以使用其他技术来启动远程机器上的进程，诸如安全Shell(SSH)等。

云管理器105正在管理的应用专用信息由应用管理器120来执行。根据一个实施例，应用专用信息与微软有关。由此，应用管理器120被配置为了解SharePoint承租人、站点集合等。

每个网络可以被配置成用于承租人的专用网络和/或服务于一个以上客户的多承租人网络。网络可以包括变化数目的物理机/虚拟机，物理机/虚拟机的配置在部署之后也变化。一般而言，只要未超过联网极限(例如，负载平衡器和网络交换机)，网络就可以继续增长。例如，网络可以从十个服务器开始，并且之后扩充为一百个或更多个服务器。可以给网络内的物理机分配类或类型。例如，所述机器中的某些机器可以是计算机器(用于web前端和应用服务器)，而其他机器可以是与计算机器相比配备有更多存储的存储机器。根据一实施例，云管理器105用多个版本的镜像文件来配置网络内的机器。根据一实施例，场常常具有相同版本的镜像文件。

根据一个实施例，在网络内由云管理器系统100通过虚拟化机器并且管理该网络内部独立地行动的“场”来管理软件极限。每个网络可以包括一个或多个场(例如，参见网络1)。根据一个实施例，网络被认为是经网络负载平衡的机器的单个群集，所述机器向外部世界展示一个或多个VIP(虚拟IP)并且可以将通信路由到网络内的任何机器。网络中的机器通常是紧耦合的，并且具有最小等待时间(即＜1ms的查验(ping)等待时间)。

场是用于对需要紧密绑定关系的应用进行协调的机器的基本分组。例如，内容场可以部署在每个网络内以用于诸如Microsoft的内容管理应用。一般而言，每一个场中的那组机器一起提供web服务和应用服务器功能。通常，场内的机器运行相同构建的应用程序(即SharePoint)并且共享公共的配置数据库以服务特定的承租人和站点集合。

场可以包含异构的虚拟机组。云管理器105在数据存储140内维护“场目标”，该场目标是每个场的每种角色的机器的目标数目。一些角色包括内容前端、内容中央管理员、内容计时器服务、联合中央管理员、联合应用服务器等。例如，内容场是处理传入的顾客请求的基本SharePoint场。联合服务场包含可以跨场运行的诸如搜索和简档存储这样的SharePoint服务。场可以用于主存大容量公共因特网站点。某些场可以包含一组活动目录服务器和供应端口监控程序(Provisioning Daemon)。云管理器105自动地部署网络中的虚拟机和/或停用网络中的虚拟机，以帮助满足所定义的目标。这些场目标可以自动地和/或手动地来配置。例如，场目标可以响应于活动和容量需求的改变而改变。网络场——每个网络存在一个包含可以作为整个网络的资源容易地横向扩展的所有VM角色的网络场。

云管理器web服务API 150被设计为在可大规模伸缩的全局服务的上下文中工作。该API假定：任何网络请求可能在传送中失败和/或挂起。对云管理器105的调用被配置为是幂等的。换言之，可以对云管理器105进行多次相同的调用(只要参数是相同的)而不改变结果。

云管理器105被设计成在向任何给定的请求返回响应之前进行非常少的处理(＜10ms，＜50ms)。云管理器105维护记录以跟踪当前请求。例如，云管理器105更新本地数据库中的记录，并且若需要则稍后调度“作业”以执行更长的活动。

云管理器跟踪作为用于在网络内部署新机器的模板的镜像(诸如，虚拟盘镜像)。镜像引用可以存储在诸如数据库140的数据库中和/或某个其他位置。镜像可以存储在对其上将部署镜像的网络而言是本地的一个或多个共享的数据存储中。根据一个实施例，每个映像都包括：虚拟机(VM)角色类型，其指定映像可以部署的VM的类型；该映像应当使用的处理器的数目；将分配给该映像的RAM的量；用于找出附近安装点的网络ID(使得它们不会通过跨数据中心链接被反复地复制)；以及可以被部署代码用于访问VHD的共享路径。

一般而言，由云系统100所管理的网络中的机器不是以传统方式通过下载数据并且将该数据合并到机器上的现有软件中来升级的。相反，机器是通过用已更新的VHD替换VHD来更新的。例如，当场需要新版本的软件时，部署安装了该新版本的新场。当部署新场时，将承租人从旧场移动到该新场。以此方式，由于升级造成的停机时间被最小化，并且场中的每个机器具有已被测试的相同版本。当虚拟机需要升级时，机器上的VM可以被删除并且被配置为运行所需服务的VM所代替。

尽管对现有软件的升级不是最优的，但是网络内的某些服务器使用原地升级的传统更新过程。例如，活动目录域控制器是通过更新服务器上的当前软件而不完全替换机器上的映像来升级的。在一些实例中，云管理器也可以原地升级。

图2示出了包括管理器和相关联的数据库的云管理器。如所示的，云管理器200包括工作管理器210、工作数据库215、机器管理器220、机器数据库225、承租人管理器230、承租人数据库235、私密数据库245、以及web服务API 240。

一般而言，将在云管理系统(例如系统100)内使用的数据库的大小调整为实现高性能。例如，数据库(诸如，工作数据库215、机器数据库225、承租人数据库235和私密数据库245)不能超过预定义的大小限制(例如30GB、50GB、100GB等)。根据一实施例，调整数据库的大小以使得其小得足以放入物理机的存储器中。这有助于高读取I/O性能。还可以基于对于一应用程序(诸如，与SQL服务器交互时)的性能来选择数据库的大小。还可以调整用在场中的数据库的大小以实现高性能。例如，它们的大小可以被调整为能放入主机的存储器中和/或被调整为使得备份操作、移动操作、复制操作、恢复操作一般在预定的时间段内执行。

云管理器200将云管理器数据划分成四个数据库。工作数据库215用于工作管理器。机器数据库225用于机器管理器220。承租人数据库235用于承租人管理器230，并且私密数据库245用于存储敏感信息，诸如系统账户和口令信息、凭证、证书等。数据库可以位于相同的服务器上，或者跨服务器分割。根据一实施例，每个数据库被镜像以获得高可用性，并且是SQL数据库。

云管理器200被配置为使用缩减的SQL特征组与数据库交互以便有助于在数据库升级期间提供云管理器200的可用性。例如，尝试避免外来密钥或已存储的过程。外来密钥可能使模式变化变得困难并且导致意料之外的失效情况。已存储的过程将应用程序中的更多个放置在数据库本身中。

尝试最小化与SQL服务器的通信，因为与底层操作的成本相比，往返可能是昂贵的。例如，如果当前SQL服务器到单个数据库的全部交互被包装在单个往返中，则常常是效率高得多的。

极少在数据库(215，225，235)内使用限制条件。一般而言，限制条件在其有助于在没有额外查询的情况下提供具有正确类型的错误处理的简单更新时是有益的。例如，完全合格的域名(FQDN)表具有对“名称”施加的限制条件，以帮助防止承租人意外地试图主张与已经被分配给不同承租人的FQDN相同的FQDN。

当添加索引时使用警告。索引通常以写入操作的额外I/O为代价来改善读取性能。由于数据库内的数据主要是驻留在RAM上的，因此即使全表扫描仍然是相对快的。根据一实施例，一旦查询模式已经稳定就可以添加索引，并且可以根据所提出的索引来确定性能改善。根据一实施例，如果添加索引将可能花费长时间，则可以指定“ONLINE＝ON(在线＝开启)”选项，以使得在最初构该建索引时表不被锁定。

根据一实施例，可以执行对云管理器内数据库的升级而不导致云管理器系统停机。换言之，即使在云管理器升级期间，云管理器继续处理已接收的请求。由此，对模式作出的改变应与之前的模式兼容。在升级云管理器所使用的web服务器之前进行SQL模式升级。当web服务器升级时，它们可以开始使用数据库中所启用的新特性。数据库升级被限制以使得升级中所涉及的操作是快速和有效的。例如，可以添加表，并且可以向现有列添加新的可空列。可以在表的结尾处添加新的列。一般而言，避免对数据库的耗时操作。例如，在存在大量数据时，在创建时间向新添加的列添加缺省值可能是非常耗时的操作。然而，添加可空列(nullable column)是非常快速的操作。如上面所讨论的，允许添加新的索引，但是在添加新的限制条件时应当采取警告，以帮助保证模式升级不会破除现有数据。例如，当添加限制条件时，该限制条件可以被设置为如下状态：该限制条件不被检查并且避免对现有行和潜在的错误进行高成本的验证。旧表和未使用的列在新版本被使用并且云管理器不访问这些表和列以后被移除。

一般而言，每个数据库中的单个行用于指示任务和/或所需状态。例如，承租人数据库235为每个承租人包括单个行。给定的承租人可以包括所需版本(Required Version)记录。该记录用于帮助保证：该承租人被放置在运行所需版本的场上。例如，对于要停留在SharePoint 14 SP1上的承租人1而言，该承租人的所需版本可以被设置为“14.1”，并且包括14.1的任何版本都将匹配并且任何其他版本(例如14.2.xxxx)都将不匹配。承租人记录可以包括其他项目，诸如已授权的用户数目、限额(例如所允许的总数据使用、每用户的数据使用等)、时间限制等。某个组织可能具有代表不同地理位置、组织或容量的多个承租人。根据一实施例，将承租人彼此隔开而没有(经由外联网或其他特性)对用户的明确邀请。

根据一个实施例，每个承租人都被锁定到一专用网络中。承租人被保持为相对于一小组数据库而言是本地化的。承租人或者是小的(小于将填充一个数据库的程度)，在这种情况下，该承租人处于与其他承租人共享的恰好一个数据库中。这意味着共享该数据库的所有承租人需要同时升级。当承租人变大时，其可被移动到其自己的专用数据库，并且现在可以具有一个以上、但是不与其他承租人共享的数据库。在一个或多个专用数据库中维护大承租人有助于减少需要在单次升级中同时升级的数据库的数目。

类似地，工作数据库215包括关于每个作业的单个行。机器数据库225可包括关于每个物理机、VM、场等的行。例如，机器管理器数据库225可以包括版本字符串。根据一实施例，网络内的每个VHD、场和VM具有相关联的版本字符串。

根据一个实施例，云管理器包括简单日志系统，该简单日志系统可以被配置为为每个web服务调用记录日志条目。可以实现包括如所期望的那样少和/或多的特性的日志系统。一般而言，日志系统被用于度量使用和性能剖析。

根据实施例，web服务API 240是使用带有ASP.net的SOAP构建的。API中的各种web方法遵循两种主要模式——获取(Get)和更新(Update)。一般而言，更新方法将数据结构作为输入，并且返回相同的结构作为输出。输出结构返回数据库中底层对象的当前状态，其中如果验证或其他业务逻辑改变了某些性质或者以其他方式填充了附加的性质(例如记录ID或由云管理器计算出的其他值)，则该底层对象可能不同于输入对象。更新方法用于初始对象创建以及随后的更新。换言之，对web服务API 240的调用者可以简单地请求它们想要的配置并且它们不需要跟踪对象是否已经存在。另外，这意味着更新是幂等的，因为相同的更新调用可以进行两次，其中效果相同使其仅仅发生一次。根据一实施例，更新方法可以包括LastUpdated(最近更新)属性。当存在LastUpdated属性时，若LastUpdated的值与当前存储在数据库中的值不匹配，则云管理器200拒绝更新。某些更新方法包括在对方法的第一次调用时被设置的并且在对方法的其他调用时未被设置的属性。

云管理器200被配置为避免使用回调(callback)。由于回调可能是不可靠的，因此与云管理器200交互的客户可以在他们想要检查更新状态时使用web服务API来检查对象状态。根据实施例，对更新方法的调用导致云管理器200将底层对象的状态设置为“供应中(Provisioning)”，并且当更新完成时，状态被设置为“活动(Active)”。

图3示出了存储在数据库的行内的示例性作业记录。如所示的，记录300包括作业标识符302、类型304、数据306、所有者308、步骤310、上一次运行312、期满时间314、下次时间316、状态318以及状况320。

一般而言，针对所请求执行的每个任务，云管理器在数据库350(例如，图2中的工作数据库215)中创建记录。

作业标识符302用于为所请求的任务指定唯一标识符。

类型304指定要执行的任务。例如，类型可以包括将要执行的脚本的名称。例如，当任务是要运行名称为“DeployVM.ps1”的脚本时，则数据306可以包括标识符(例如“-VMID 123”)。这允许将新任务类型添加到系统，而不需要对该系统的已编译或其他二进制部分进行任何改变。

数据306用于存储与任务相关联的数据。例如，数据可以被设置为将在其上执行任务的承租人、机器、网络、VM等。数据306还可以存储数据库中的值所被设置成的一个或多个值。执行任务的过程可以注意作业记录以查看所需机器数目被设置为何值。脚本使用数据库中的值来执行操作。

所有者308指定过程/执行该过程的机器。例如，当云管理器机器开始执行作业时，该机器使用机器的ID来更新记录的所有者308部分。

步骤310提供对当前脚本的步骤的指示。例如，脚本可以将任务划分成任何数目的步骤。当该进程完成该脚本的步骤时，步骤310被更新。进程还可以查看步骤310以确定在脚本中要执行什么步骤并且避免必须重新执行之前已完成的步骤。

上一次运行312提供上一次启动脚本的时间。每次启动脚本时，更新上一次运行时间。

期满时间314是指示该进程应当何时终止的时间。根据实施例，期满时间是在进程被启动之后的预定的时间量(例如5分钟、10分钟...)。期满时间可以通过经由web服务API的请求进程来更新。

下次时间316是指示任务下次应当何时执行的时间。例如，进程可以在完成某步骤之后停止，并且被指示等待直到所指定的下次时间316以恢复处理。

状态318指示当前状态，并且状况320指示作业的状况(例如，已创建、已挂起、已恢复、执行中、已删除)。

如果数据库中的重复行具有相同的任务类型和数据值，则它们可以在执行之前被移除。例如，可以进行多个请求以执行存储在数据库的多个行中的相同的任务。

作业可以具有与其相关联的一个或多个锁355。如果锁不可用，则作业将不被调度运行，直到锁可用。这些锁可以以许多不同的方式来配置。例如，锁可以基于互斥、信号量等。一般而言，互斥防止代码被一个以上线程同时执行，并且信号量将共享资源的同时使用的数目限制在最大数目。根据实施例，锁是表示资源的字符串。该资源可以是任何类型的资源。例如，锁可以是场、机器、承租人等。一般而言，锁被用于延迟一个或多个任务的执行。每个作业可以指定其在运行以前需要的一个或多个锁。作业可以在其操作期间的任何时间释放锁。当存在锁时，作业不被调度。需要一个以上锁的作业一次请求所需的全部锁。例如，已经持有锁的作业可以不请求附加的锁。这样的模式有助于防止由多个作业间的循环锁依赖性造成的可能的死锁情况。

图4示出了用于网络的示例系统400，该网络包括用于在线服务的前端和后端服务器。示例性系统400包括客户机402和404、网络406、负载平衡器408、WFE服务器410、412、414以及后端服务器416-419。可使用更多或更少的客户机、WFE、后端服务器、负载平衡器和网络。另外，由系统400中的组件所提供的功能中的某些可以由其他组件来执行。例如，某些负载平衡可以在WFE中执行。

在示例实施例中，客户机402和404是诸如台式计算机、膝上型计算机、终端计算机、个人数字助理或蜂窝电话设备的计算设备。客户机402和404可包括输入/输出设备、中央处理单元(“CPU”)、数据存储设备和网络设备。在本申请中，术语客户机和客户机计算机互换地使用。

WFE 410、412和414可由客户机402和404经由负载平衡器408通过网络406访问。如所讨论的，服务器可以在场中配置。后端服务器416对WFE 410、412和414是可访问的。负载平衡器408是专用网络设备和/或一个或多个服务器计算机。负载平衡器408、420、WFE 410、412和414以及后端服务器416可包括输入/输出设备、中央处理单元(“CPU”)、数据存储设备和网络设备。在示例实施例中，网络406是因特网，并且客户机402和404可以远程地访问WFE 410、412和414以及连接到WFE 410、412和414的资源。

在示例实施例中，系统400是在线的、基于浏览器的文档协作系统。在线的、基于浏览器的文档协作系统的一个示例是来自美国华盛顿州雷蒙德市的微软公司的Microsoft在系统400中，后端服务器416-419中的一个或多个是SQL服务器，例如，来自美国华盛顿州雷蒙德市的微软公司的SQL服务器。

WFE 410、412和414提供客户机402和404与后端服务器416-419之间的接口。负载平衡器408、420将请求从客户机402和404引导到WFE 410、412和414，以及从WFF引导到后端服务器416-419。负载平衡器408使用诸如WFE利用率、到WFE的连接数目和总体WFE性能之类的因素来确定哪个WFE服务器接收客户机请求。类似地，负载平衡器420使用诸如后端服务器利用率、到服务器的连接数目和总体性能这样的因素来确定哪个后端服务器接收请求。

客户请求的示例可以是访问存储在后端服务器之一上的文档，编辑存储在后端服务器(例如416-419)上的文档，或者将文档存储在后端服务器上。当负载平衡器408通过网络406接收客户机请求时，负载平衡器408确定WFE服务器410、412和414中的哪个接收该客户机请求。类似地，负载平衡器420确定后端服务器416-419中的哪一个从WFE服务器接收请求。后端服务器可以被配置为存储一个或多个承租人(即顾客)的数据。

现在参考图5，将描述在各实施例中利用的计算机500的说明性计算机体系结构。图5所示的计算机体系结构可被配置为服务器、台式或移动计算机，并且包括中央处理单元5(“CPU”)、包括随机存取存储器9(“RAM”)和只读存储器(“ROM”)11的系统存储器7、以及将存储器耦合至中央处理单元(“CPU”)5的系统总线12。

基本输入/输出系统存储在ROM 11中，所述基本输入/输出系统包含帮助在诸如启动期间在计算机内元件之间传递信息的基本例程。计算机500还包括大容量存储设备14，用于存储操作系统16、应用程序10、数据存储24、文件、以及与云系统100的执行和同云系统100的交互相关的云程序26。

大容量存储设备14通过连接至总线12的大容量存储控制器(未示出)连接到CPU 5。大容量存储设备14及其相关联的计算机可读介质为计算机500提供非易失性存储。虽然此处包含的计算机可读介质的描述针对诸如硬盘或CD-ROM驱动器等大容量存储设备，但是计算机可读介质可以是计算机100可以访问的任何可用介质。

作为示例而非限制，计算机可读介质可包括计算机存储介质和通信介质。计算机存储介质包括以存储如计算机可读指令、数据结构、程序模块或其它数据等信息的任何方法或技术来实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质还包括，但不限于，RAM、ROM、可擦除可编程只读存储器(“EPROM”)、电可擦可编程只读存储器(“EEPROM”)、闪存或其它固态存储器技术、CD-ROM、数字多功能盘(“DVD”)或其它光存储、磁带盒、磁带、磁盘存储或其它磁性存储设备、或能用于存储所需信息且可以由计算机500访问的任何其它介质。

根据各实施例，计算机500可以使用通过诸如因特网的网络18至远程计算机的逻辑连接在联网环境中操作。计算机500可以通过连接至总线12的网络接口单元20来连接到网络18。网络连接可以是无线的和/或有线的。网络接口单元20也可用于连接到其它类型的网络和远程计算机系统。计算机500还可以包括用于接收和处理来自多个其他设备的输入的输入/输出控制器22，这些设备包括键盘、鼠标或者电子指示笔(图5中未示出)。类似地，输入/输出控制器22可以向显示屏28、打印机或其它类型的输出设备提供输出。

如上面简要提到的，多个程序模块和数据文件可以存储在计算机500的大容量存储设备14和RAM 9内，包括适于控制联网计算机的操作的操作系统16，比如华盛顿州雷蒙德市的微软公司的操作系统。大容量存储设备14和RAM 9还可以存储一个或多个程序模块。具体而言，大容量存储设备14和RAM 9可以存储诸如云程序26的执行与云系统相关的任务的一个或多个应用程序。

图6示出了用于对在在线服务内使用的机器进行打补丁的补丁系统。云管理器605用于为在线服务部署、配置、打补丁和管理网络。云管理器被配置为通过不能依靠可靠网络的幂等且异步的应用程序web服务应用程序编程接口(API)620来接收请求。

如所示的，云管理器605包括工作管理器110、机器管理器115、应用专用管理器120、脚本130、数据库612、补丁615、和web服务API 620。根据一个实施例，应用管理器120是SharePoint承租人管理器，该管理器包括SharePoint专用逻辑。

使用API 620的请求可用于在跨不同网络(网络1、网络2)的各种拓扑结构中管理和部署服务器。尽管仅示出了两个网络，但是一般可以管理许多更多的网络(例如十个、一百个、一千个、一万个等)。云管理器605运行，并且可以与上面所示和所描述的云管理器系统类似地来配置。web服务API 620包括用于从工作管理器110、机器管理器115和应用管理器120请求服务的方法。例如，可以使用API 620作出请求，以便更新数据库中的承租人、添加新的SQL服务器、部署补丁、部署新的场、添加新的机器、更新VM、获得数据存储内的值等。

Web服务API 620被设计为在可大规模可缩放全局服务的上下文中工作。由于网络请求被假定为是本来不可靠的，因此API假定任一网络请求可能失效和/或停留在传送中。使用web服务API 620的请求被配置为是幂等的。换言之，可以使用web服务API 620作出具有相同参数的相同调用，而不改变结果。

云管理器605被设计成在向任何给定的请求返回响应之前进行非常少的处理(＜10ms，＜50ms)。云管理器605维护记录以跟踪当前请求。例如，云管理器605更新本地数据库(诸如数据库612)中的记录，并且若需要则稍后调度“作业”以执行更长的活动。一旦参数和作业信息被提交到数据库之后，响应就被发送给请求者。根据实施例，web服务API 620是使用具有ASP.net的SOAP构建的。

补丁615被配置成存储将被应用于一个或多个(物理和虚拟的)机器的补丁。所使用的和/或将被部署到一个或多个网络中的机器里的一个或多个上的虚拟硬盘(VHD)镜像也可被存储在包括补丁的数据存储中和/或被存储在某一其他位置。根据一实施例，使用MICROSOFT VHD文件格式，该格式指定可以驻留在封装在单个文件内的本机主文件系统上的虚拟机硬盘。可将应用于特定网络内的映像移动到全局共享645和/或对网络为本地的网络共享(例如，网络共享632和网络共享642)。将补丁存储在网络共享上将节省部署补丁的时间，因为减小了网络通信时间。

如所讨论的，网络中的机器可通过安装新VHD和/或将补丁应用于机器上的现有软件来升级。可出于不同的目的而提供补丁。一些补丁对于在线服务中的机器的操作/安全性而言是关键的，而其他补丁可能是非关键的且对于应用而言是随意的。例如，零天补丁可被用于安装将被尽可能快地安装的关键软件更新，而其他非关键补丁可被检查，随后被批准的补丁可被自动地应用于机器。

软件打补丁可能需要机器在补丁的应用期间被重新引导一次或多次。例如，一个补丁可首先被安装，这要求在另一补丁可被应用于机器之前重新引导该机器。此重新引导/补丁周期可继续进行直至不再有补丁要被应用。云管理器605尝试对针对物理和虚拟机器的网络中的机器进行的打补丁进行协调，该物理和虚拟机器一起工作以提供在线服务以使得服务的总体可用性作为整体被维护。

每个网络(例如，网络1、网络2)可包括被配置成具有用以执行数个角色的冗余度的大量机器。例如，第一数目个机器(例如，20)可被配置成提供第一角色，第二数目个机器可被配置成提供第二角色(例如，30)，第三数目个机器可被配置成提供第三角色(例如，12)等。换言之，多个机器被配置成对于在线服务执行相同角色，以使得正执行该角色的机器子集的故障不会导致此角色对于在线服务的性能的完全故障。

可在在线服务的操作和部署的许多阶段期间使用打补丁。例如，当VHD正被创建时，可将补丁应用于该VHD以使得它们在分发时生产准备就绪(production-ready)。当对物理机进行镜像时，在使得它们可为在线服务所用之前可能需要对它们进行打补丁。可能需要对机器的现有部署进行打补丁以确保它们的正在进行的顺从性。

可在各个时间将补丁递送给云管理器605和/或更新服务，诸如更新服务610。例如，可在特定时间(即，两周一次、每月一次等)发布非关键补丁，而关键补丁一旦可用就可发布它们。根据实施例，更新服务610是来自微软公司的Windows Server Update Services(WSUS)。WSUS辅助管理员管理发布的补丁的分发。虽然更新服务610被示为在云管理器605以及网络1和网络2的内部，但是更新服务610可被包括在网络和/或云管理器605的一个或多个中。

当接收到非关键补丁时，被授权的用户(即，系统管理员)可检查补丁并批准/不批准部署它们。管理员可决定不部署非关键的某些补丁。在批准过程之后，被批准的补丁可被调度来安装。补丁可被存储在不同的位置处。例如，补丁可被存储在本地网络共享(例如，网络共享632、网络共享642)中和/或全局网络共享中。最初，补丁可被存储在一个位置处，并在随后被提供到另一位置。例如，可将补丁从补丁615移至与补丁将被部署到其上的网络相关联的网络共享。

当发布关键补丁(即，零天补丁)时，存在很少的可用来对那些补丁执行验证并将它们应用到网络内的机器的时间。但接收到关于零天补丁的通知时，云管理器620和/或更新服务610可调度补丁来部署。

根据实施例，每一个网络中的机器被加入到遵循组策略对象(GPO)的相同域。GPO管理那些机器上的更新服务610的行为。例如，GPO可指定：当新的更新在没有自动安装这些更新的情况下可用时，域内的机器被设置成下载这些新的更新。在机器遵循GPO且没有自动安装的情况下，可控制补丁到机器的应用，以使得在打补丁期间维护在线服务的可用性。执行对补丁的调度和应用，以使得在线服务内提供的功能的停机时间被最小化。

关键补丁可被自动配置成在特定时间被部署和/或在被接收到之际被部署。云管理器605可被配置成在确定应用补丁的次序之后触发对这些补丁的安装。

在不同的时间将补丁应用于机器组，而并非在单个时间向正等待将被打补丁的所有机器应用补丁。标识等待将被打补丁的机器并将这些机器划分成数个组，这些组是高可用性独立组。高可用性独立物理机组是这样的物理机集合：该物理机集合的任一个上没有属于相同场且还具有相同虚拟机角色的VM。例如，如果有为SQL的三个机器且机器1被镜像到机器2上，而机器3也被镜像到机器2上，随后机器1和机器3可在同时被打补丁，但不对机器2打补丁。一般而言，当存在对于在线服务执行相同角色的两个或更多机器时，不在相同时间对它们进行打补丁。如此，存在对于在线服务执行角色的至少一个机器。

可使用不同的方法来确定对每个组进行打补丁的时间表。例如，当当前负载对于等待被打补丁的组而言较低时，可在同时对一个或更多个组进行打补丁。当当前负载对于等待被打补丁的组而言较高时，可每次仅对单个组进行打补丁。根据实施例，按顺序每次一个地对每个组进行打补丁，直至所有组都被打补丁。可并行地对每个组内的机器进行打补丁。类似地，当同时对两个或更多个组进行打补丁时，打补丁可并行地进行。还标识组内每个机器上要打补丁的VM。对要打补丁的VM的标识是基于VM的类型和角色。也可并行地对每个机器上的VM进行打补丁。

一些补丁要求安装第一补丁并且在可安装第二补丁之前重新引导机器。在已将补丁安装到机器上之后，更新服务610和/或云管理器可被用于确定是否需要重新引导机器。一旦机器被备份且在重新引导之后运行(若有需要)，则检查机器以查看是否有任何更多的待决补丁要被应用。此过程重复进行，直至机器无需应用任何更多补丁。当没有要应用的待决补丁时，机器被认为被打了补丁。如果补丁失败，则机器可从操作中被移除或者在尝试应用补丁之前回退到先前状态。当移除机器时，另一机器可被配置成取代它。

图7示出用于对在线系统中的机器进行打补丁的过程。

当阅读对在此提供的例程的讨论时，应当理解，各实施例的逻辑操作被实现为(1)运行于计算系统上的一系列计算机实现的动作或程序模块，和/或(2)计算系统内互连的机器逻辑电路或电路模块。取决于实现本发明的计算系统的性能要求，可以选择不同的实现。因此，所例示的并且构成此处所描述的实施例的逻辑操作被不同地表示为操作、结构设备、动作或模块。这些操作、结构设备、动作和模块可用软件、固件、专用数字逻辑以及它们的任何组合来实现。

在启动操作之后，过程700行进至操作710，在那里接收补丁。如所讨论的，补丁可以是关键补丁或非关键补丁。关键补丁将尽可能快地被应用，而非关键补丁可被检查并被调度成在更方便的时间来应用。

移至操作720，确定接收对补丁的应用的机器。例如，仅机器的一部分可能需要应用补丁。

行进至操作730，将要被打补丁的机器划分成数个机器组。进行划分被用来帮助确保将补丁应用于机器不会导致对在线服务的总体可用性的破坏。根据实施例，机器可被划分成数个组，这些组是高可用性独立组。物理机的高可用性独立组是这样的物理机集合：该物理机集合的任一个上没有属于相同场且还具有相同虚拟机角色的VM。

行进至操作740，确定对机器进行打补丁的时间表。时间表被用来确定对机器组进行打补丁的次序以及何时开始对机器组进行打补丁。接收到关键补丁可触发对补丁的立即调度和应用。非关键补丁可在它们被授权来应用之前通过检查过程。一般而言，关键补丁可被尽快可实行地应用，而非关键补丁可在更方便的时间被应用。根据实施例，在不同时间对每个组打补丁。

转到操作750，可对机器组内的机器进行打补丁。根据实施例，可同时并行地对组中的每个机器进行打补丁。也可按顺序对机器进行打补丁。当组内的每个机器已被打补丁且被重新引导(若需要)时，过程移至判定操作760。

在判定操作760，关于是否有更多组要被打补丁作出确定。当有更多组要打补丁，则过程返回到操作750。当没有任何更多组要被打补丁时，过程移至结束块并返回处理其他动作。

以上说明书、示例和数据提供了对本发明的组成部分的制造和使用的全面描述。因为可以在不背离本发明的精神和范围的情况下做出本发明的许多实施例，所以本发明落在所附权利要求的范围内。

Claims

1.一种用于对在线服务中的机器进行打补丁的方法，包括：

接收要应用于包括网络的在线服务中的机器的补丁；其中所述补丁是关键补丁和非关键补丁中的至少一个（710）；

确定所述网络中的至少一个内接收对所述补丁的应用的所述机器（720）；其中所确定的机器包括对所述在线服务执行相同角色的多个机器；以及

在将所述补丁应用于所述多个机器的其余部分之前将所述补丁自动应用于执行所述相同角色的多个机器的一部分（750）；

其中，所述方法还包括：

将所确定的机器划分成机器组，以使得对所述在线服务执行相同角色的机器被划分在所述组的至少两个之间（730）；

根据时间表将所述补丁应用于所述机器，以对所述组中的每一个进行打补丁。

2.如权利要求1所述的方法，其特征在于，还包括确定所述机器中的每一个上要接收对所述补丁的应用的任何虚拟机（720）。

3.如权利要求1所述的方法，其特征在于，所述补丁是由更新服务（610）来接收的，并且所述根据时间表将所述补丁应用于所述机器，以对所述组中的每一个进行打补丁的步骤是由所述更新服务来执行的。

4.如权利要求1所述的方法，其特征在于，所述网络内的所述机器遵循对何时应用所述补丁实施限制的组策略（610）。

5.如权利要求1所述的方法，其特征在于，还包括检查要应用于所述组内的所述机器的附加补丁，以及在将所述补丁应用于下一组之前将所述附加补丁应用于所述组中的所述机器（740）。

6.一种用于对在线服务的机器进行打补丁的方法，包括：

确定所述网络中的至少一个内接收对所述补丁的应用的所述机器（720）；其中所确定的机器包括对所述在线服务执行相同角色的多个机器；

调度何时将所述补丁应用于所述组（740）；以及

根据所述调度按顺序将所述补丁自动应用于所述组的每一个（750）。

7.一种用于对提供在线服务的机器进行打补丁的系统，包括：

处理器和计算机可读介质（5）；

存储在所述计算机可读介质上并在所述处理器上执行的操作环境（16）；

被耦合到不同的网络的云管理器（105），用于管理对机器的部署和对所述网络的配置，以及自动调度何时将补丁应用于所述在线服务中的机器；以及

所述不同的网络的每一个中的数据库（200），用于存储将被应用于所述网络内的机器的所述补丁；

其中，所述系统被配置成执行动作，所述动作包括：

确定所述网络中的至少一个内接收对所述补丁的应用的所述机器；其中所确定的机器包括对所述在线服务执行相同角色的多个机器（720）；

将所确定的机器划分成机器组，以使得对所述在线服务执行相同角色的机器被划分在所述组的至少两个之间（730）；以及

在将所述补丁应用于所述组的另一部分之前将所述补丁自动应用于所述组的一部分（750）。

8.如权利要求7所述的系统，其特征在于，自动应用所述补丁包括并行地将所述补丁自动应用于所述组中的每一个内的机器中的每一个（750）。

9.如权利要求7所述的系统，其特征在于，还包括检查要应用于所述组内的所述机器的附加补丁，以及在将所述补丁应用于下一组之前将所述附加补丁应用于所述组中的所述机器（750）。

10.一种用于对在线服务的机器进行打补丁的系统，包括：

用于接收要应用于包括网络的在线服务中的机器的补丁；其中所述补丁是关键补丁和非关键补丁中的至少一个（710）的装置；

用于确定所述网络中的至少一个内接收对所述补丁的应用的所述机器（720）的装置；其中所确定的机器包括对所述在线服务执行相同角色的多个机器；

用于将所确定的机器划分成机器组，以使得对所述在线服务执行相同角色的机器被划分在所述组的至少两个之间（730）的装置；

用于调度何时将所述补丁应用于所述组（740）的装置；以及

用于根据所述调度按顺序将所述补丁自动应用于所述组的每一个（750）的装置。