CN102664746A - 用于分布式数据中心各分量的在全局上健全且一致的配置管理 - Google Patents

Abstract

本发明涉及用于分布式数据中心各分量的在全局上健全且一致的配置管理。数据中心配置需要被管理。配置引擎(CE)管理群集和/或数据中心的配置数据。CE允许用户登出、编辑、以及登入各配置分量。通过数据合同在各配置分量之间放置版本化的接口。CE支持确保跨各配置分量和版本的全局一致性的约束表达式，将数据中心中的变更与各配置分量中的结构变更隔离，并启用部分配置分支以允许启用配置回退的活动快照。CE确保在登入时各类型是一致的并且各约束是被满足的，以首先消除不健全或不一致的配置。在数据中心中的活动的配置变更时，可对一时间窗口同时部署配置的多个版本。在这些过渡窗口期间，配置的托管集合被准许具有多个活动的版本，以反映数据中心中的真实情况。

Description

用于分布式数据中心各分量的在全局上健全且一致的配置管理

技术领域

本发明涉及数据中心配置。

发明内容

在第一方面，一组计算机可使用指令提供一种更新数据中心配置的方法。数据中心配置被组织成在全局上一致的各配置分量。开发人员希望变更一分量的配置数据。该开发人员下载配置的活动集合的副本并作出所需变更。从开发人员接收该配置分量的经修改版本。作出该经修改的配置分量与数据中心配置的已提交版本是否在全局上一致的判定。如果经修改的配置分量是一致的，则将它被接受到数据中心配置的托管集合中，并且如果不一致则被拒绝。对于更高级的操作，开发人员可以在变更被归并回主分支中之前在配置数据的部分分支中执行这些变更。在数据中心中的活动的配置变更时，可对一时间窗口同时部署配置的多个版本。在这些过渡窗口期间，配置的托管集合被准许具有多个活动的版本，以反映数据中心中的真实情况。

附图说明

以下参考附图详细描述本发明的一些说明性实施例，附图中：

图1描绘了根据本发明的一实施例的示例性操作环境；

图2描绘了根据本发明的一实施例的示例性操作环境；

图3描绘了根据本发明的一实施例的示例性配置管理环境；

图4描绘了根据本发明的一实施例的示例性配置数据；

图5描绘根据本发明的一实施例的方法；

图6描绘根据本发明的一实施例的方法；

图7描绘根据本发明的一实施例的方法；以及

图8-12描绘根据本发明的一实施例的数据中心配置。

具体实施方式

此处用细节来描述本发明的一些实施例的主题以满足法定要求。然而，该描述本身并非旨在必定限制权利要求的范围。相反，所要求保护的主题可结合其他当前或未来技术按照其他方式来具体化，以包括不同的步骤或类似于本文中所描述的步骤的步骤组合。术语不应被解释为暗示本文所公开的各步骤之中或之间的任何特定次序，除非且除了在明确描述个别步骤的次序的时候。

本发明技术尤其采用以下形式：包含在一个或多个计算机可读介质上的方法、系统或指令集。计算机可读介质包括易失性和非易失性介质，可移动的和不可移动的介质，并设想可由计算设备读取的介质。计算机可读介质包括可用于存储信息的任何介质。存储的信息的示例包括计算机可使用指令、数据结构、程序模块以及其他数据表示。介质示例包括RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)、全息介质或其他光盘存储、磁带盒、磁带、磁盘存储、以及其他磁存储设备。这些技术可瞬间、临时或永久地存储数据。

首先具体参考图1，示出了用于实现本发明的一实施例的示例性操作环境，并将其概括地指定为计算设备100。计算设备100仅是合适的计算环境的一个示例。

本发明的一实施例可以在由计算机或诸如个人数据助理或其他手持式设备之类的其他机器执行的计算机代码或机器可使用指令(包括诸如程序模块之类的被包含在计算机可读介质上的计算机可执行指令)的一般上下文中描述。一般而言，包括例程、程序、对象、组件、数据结构等的程序模块指的是执行特定任务或实现特定抽象数据类型的代码。本发明的一实施例可以在各种系统配置中实施，包括手持式设备、消费电子产品、通用计算机、更专用计算设备等等。本发明的一实施例也可以在其中任务由通过通信网络链接的远程处理设备执行的分布式计算环境中实施。

参考图1，计算设备100包括直接或间接耦合以下设备的总线110：存储器112、一个或多个处理器114、一个或多个呈现组件116、输入/输出端口118、输入/输出组件120、和说明性电源122。总线110可以是一条或多条总线(诸如地址总线、数据总线、或其组合)。虽然为了清楚起见利用线条示出了图1的各框，但是实际上，各组件的轮廓并不是那样清楚，并且比喻性地来说，线条更精确地将是灰色的和模糊的。例如，可以将诸如显示设备等呈现组件认为是I/O组件。而且，处理器具有存储器。可以认识到，这是本领域的特性，并且重申，图1的图示只是例示可结合本发明的一个或多个实施方式来使用的示例性计算设备。诸如“工作站”、“服务器”、“膝上型计算机”、“手持式设备”等分类之间没有区别，它们全部都被认为是在图1的范围之内的并且被称为“计算设备”。

计算设备100通常包括各种计算机可读介质。作为示例而非限制，计算机可读介质可以包括随机存取存储器(RAM)；只读存储器(ROM)；电可擦除可编程只读存储器(EEPROM)；闪存或其他存储器技术；CDROM、数字多功能盘(DVD)或其它光或全息介质；磁带盒、磁带、磁盘存储或其它磁存储设备；或可用于对所需信息进行编码并且可由计算设备100访问的任何其他介质。

存储器112包括易失性和/或非易失性存储器形式的计算机存储介质。存储器可以是可移动的，不可移动的，或两者的组合。示例性硬件设备包括固态存储器、硬盘驱动器、光盘驱动器等等。计算设备100包括从诸如存储器112或I/O组件120之类的各种实体读取数据的一个或多个处理器。呈现组件116向用户或其他设备呈现数据指示。示例性呈现组件包括显示设备、扬声器、打印组件、振动组件等等。

I/O端口118允许计算设备100在逻辑上耦合至包括I/O组件120的其他设备，其中某些设备可以是内置的。说明性组件包括话筒、操纵杆、游戏垫、碟形卫星天线、扫描仪、打印机、无线设备等等。

大规模联网系统是在用于运行应用程序和维护数据以用于商务和操作功能的各种环境中使用的常见系统，并且可被称为数据中心。数据中心可以提供各种服务(例如，web应用、电子邮件服务、搜索引擎服务、以及其他)。这些大规模联网系统通常包括遍及该数据中心分布的大量节点，其中每一节点类似物理机或在物理主机上运行的虚拟机。

现在参考图2，示出了用于实现本发明的一实施例的示例性操作环境，并将其大致指定为环境200。环境200仅是合适的操作环境的一个示例。

环境200包括群集210和群集212。在一实施例中，群集是如同单个单元一样操作的一组独立计算机或服务器。群集210包括多个服务器214并且群集212包括多个服务器216。在一个实施例中，环境200可包括多个群集。在另一实施例中，环境200可包括单个群集。在一实施例中，环境200中群集的数量可以随时间改变。虽然群集210和212被描绘成包括多个服务器，但在一些实施例中，群集210和212中的任一个或两者可各自只包括单个服务器。

在一实施例中，群集1210和群集212位于同一地理位置。在另一实施例中，群集210和群集212在地理上分开。

数据中心是通常被用来运行应用程序和维护业务数据及操作功能的大规模联网系统。数据中心可以同时向多个客户提供各种服务(例如，web应用、电子邮件服务、搜索引擎服务、以及其他)。这些大规模联网系统通常包括遍及该数据中心分布的大量资源，其中许多物理机以及主存在这些物理机上的虚拟机通过诸如路由器、交换机、以及负载平衡器等物理网络设备链接在一起。在数据中心主存多个承租者(例如，客户程序)时，这些资源被最优地从该同一数据中心分配给不同的承租者。

数据中心可包括一个或多个群集。在一实施例中，群集210可以构成第一数据中心210，且群集212可以构成另一数据中心212。在另一实施例中，即使群集210和群集212在地理上分开，群集210和群集212也可以一起构成一数据中心。

诸如数据中心210和212等数据中心需要大量配置，这些配置需要被管理。该配置描述物理和逻辑资源、需要交互以管理数据中心的相关联的系统的集合、以及应当在数据中心内实施的策略。随着数据中心的大小以及其中的功能增长，所需的配置集合也增长，它横跨多个分量和格式、涉及各种各样的配置人工产物(例如，包含配置设置的值的文件)。

跨各个策略和人工产物为不同类的数据中心资产(例如，测试、预生产、以及生产)提供统一性会通过简化每当扩充或变更配置人工产物的配置功能时确定将要影响什么其他组件的任务而降低复杂度和风险。以跨各种配置人工产物一致的方式来定义设置和值会方便面向方面(aspect-oriented)的配置审计(例如，全局安全策略的审计)。

提供跨各配置人工产物一致的格式会最小化在审阅配置和/或进行全局配置审阅时对领域专业知识的需求。在配置设置变更时，对这些变更从开发人员专用的测试环境到团队级测试环境、到预生产和生产的流程进行管理是重要的。防止变更不适当地过快地传播到后续环境也是重要的，因为这将潜在地引入造成问题的未经测试的配置的风险，或引入开发出与较早部署的配置不兼容的新版本配置的风险。

另一方面，未能传播变更会造成使用不能为较新部署的资产所用的陈旧配置或配置的旧版本。如果多个团队对配置人工产物作出变更，则这些人工产物在某一时刻的快照可能提供不一致的数据。在从多个位置使用配置人工产物时，错误或恶意更改或删除这些人工产物的风险会增加。不一致的配置可以部署在多个数据中心资源上，从而留下了各分量不能正确运作的时间窗口。

在配置被持续地修订和部署时，跟踪各版本之间相关联的配对是有益的，使得将数据中心软件健全地回退到解耦的环境中的先前的已知良好状态成为可能(减轻较新版本中的问题或复制旧环境来进行调查)。

进一步参考图2，配置引擎218管理群集210和212的配置数据。在一些实施例中，配置引擎218管理多个群集，而在其他实施例中，它只管理单个群集。配置引擎218可以管理多个数据中心中的单个数据中心。配置引擎218可以驻留在服务器上、在服务器集合上、或在其他类型的网络设备上。配置引擎218可以位于一特定设施处，或可以分布在更宽广的地区中。配置引擎218允许用户登出(check out)、编辑、以及登入(check in)配置值，这些配置值被组织在所谓的配置分量中。它还允许用户或其他程序查询配置值。

配置引擎218支持确保跨各配置分量和版本的全局一致性的约束表达式，将数据中心中的变更与各配置分量中的结构变更隔离，并启用部分配置分支以允许启用配置回退的活动快照。例如，这些约束可以防止多个组织(fabric)群集在它们的清单中各自列出同一节点。一些全局约束相当简单(例如，如果各群集与灾难恢复的各复制对相关联，则与该对的每一元素相关联的伙伴群集必须是该对的另一元素)。配置引擎还允许过渡模糊性(即，在过渡期间不同版本的同时实现)，以便即使在非原子装配(rollout)期间也启用严格的环境协调。

配置引擎218确保在登入时各类型是一致的并且各约束是被满足的，以首先消除系统中存在不健全的或不一致的配置的可能性。它允许在可能不同所有者跨全局应用这些规则以及分量本地约束的情况下跨各配置分量的经组织的(orchestrated)提交(即，经协调的更新)。被登入或配置引擎218中存在但实际上不存在于数据中心中的配置数据被称为“已提交的”，而“已部署”指的是在数据中心中实际使用的配置数据。

现在参考图3，示出了用于本发明的一实施例中的示例性配置管理环境，并将其大致指定为配置管理环境300。配置管理环境300只是合适的配置管理环境的一个示例。

配置引擎310由多个开发人员312、314及316访问。在一个实施例中，配置引擎310管理配置数据集318并执行上述功能。配置数据318可包括用于一个或多个群集和一个或多个数据中心的配置设置。开发人员312、314及316可以是负责维护和更新一数据中心和/或各不同的数据中心的配置数据318的工程人员、技术人员、以及其他人。例如，在一实施例中，开发人员312维护配置数据318的与第一数据中心相关的一部分，而开发人员314维护配置数据318的与不同的数据中心相关的一部分。

配置引擎310允许配置所有者(例如，开发人员312、314及316)将配置数据318分解成分开的、面向方面的各配置分量，如分量A 320和分量B 322。配置分量是与配置的不同方面(如物理资产、逻辑资产、记账策略、安全策略、每分量策略、以及数据中心配置的其他方面)相对应的配置数据集。这一分开对所有权进行分类并降低在所有者作出变更时要考虑的复杂度。所有者作出的主要变更被隔离到该分量的方面。受影响的那些分量评估并批准任何连锁反应，而未受影响的分量完全未更新并且因而未被偶然地变更。

通过数据合同在各配置分量之间放置版本化的接口。例如，如图3所示，分量A 320包括接口版本N 324以及接口版本N+1326。接口版本N+1326是最新的接口版本。各版本化的接口描述特定配置分量的消费者可查询的经命名的类型化的设置。生产者(例如，开发人员)在他们作出接口变更时不影响消费者，因为消费者以他们自己的步调迁移到较新接口版本。一旦所有消费者迁移到新版本，生产者就随时间使旧接口版本引退。

绑定到一接口的配置数据也是版本化的。对类型化的设置的使用会在将该数据提供给(或登入到)配置引擎310时而非在部署期间在消费该数据时启用一致性检查。这允许对配置问题的早期检测。对版本化的配置数据的使用消除了在多个开发人员作出变更的情况下的定时和同步问题。配置的消费者可以在他们想要的任何时刻检索正确的、版本化的数据。

接口的一特征是所绑定的数据可以按独立于如何查询该数据的方式来表示。具体而言，它可以更紧凑并且因而更易于审阅且进而确保是正确的。具体而言，配置引擎310允许各种选项，如使用继承、条件、或默认值来用于紧凑的人类可审阅的定义。作为示例，配置的一个方面可以定义各数据中心之间的记账率。接口可以指定：

DCxDC→记账率，

即，提供两个数据中心名称(例如，DCA、DCB、DCC、或DCD)并得到记账率，这易于查询。一个可能的定义是表：

	DCA	DCB	DCC	DCD
					DCA	0	4	4	7
DCB	4	0	4	7
					DCC	4	4	0	7
DCD	7	7	7	0

该表指定任何两个数据中心的记账率，但人类难以审阅，因为它所编码的规则是隐式的并且该表可变得很大。基于条件和默认值的一更清楚、更紧凑的定义的示例用C类句法来提供(注意，在该具体示例中没有示出继承，并且注意，可以使用诸如XML等其他表示)：

这一定义是较不易错的并且在添加新数据中心时较易于扩展。

配置分量还可包含数据的绑定到一接口版本的多个确切版本。这允许各值跨各确切版本来变更，只要作为每一确切版本来绑定的数据与接口(以及全局约束)一致。如图3所示，接口版本N 324包括绑定数据M 332和绑定数据M+1334。接口版本和绑定确切版本构成二层版本化方案。

分量B 322示出具有显式的版本化的依赖关系的二层版本化。如图所示，配置分量B 322依赖于配置分量A 320的接口版本N 324和接口版本N+1326。这分别由箭头328和330来示出(箭头至少依赖关系，而非数据流)。如此，分量B 322具有对分量A 320的显式依赖关系(例如通过包括对配置分量A 320的嵌入查询)，这意味着绑定到分量B 322的数据依赖于分量A 320的接口类型或数据。

配置引擎310确保查询在登入时是合式的，并且确保跨各上游分量的全局约束和类型是一致的。换言之，用户不能绑定新确切版本，除非它向接口中的每一成员返回的值的类型与接口声明相一致。它还确保绑定到该确切版本的数据与全局约束相一致。使用显式的版本化的依赖关系(由系统在登入时进行确认)来实现二层版本化使得良好定义的确切版本能被检索。隐式约束的示例是夸各接口版本的相同属性必须具有相同的值(即，如果属性“CompA.PropertyA(分量A.属性A)”具有值“one(一)”)，则无论用来进行查询的接口的版本是什么都必须返回值“one”。

通过使依赖关系在二层版本化的第一层中是显式的和版本化的，分量所有者可以引入可由消费者以适合他们的步调来采用的版本化的接口变更-这确保在评估各相关分量时接口变更不会造成故障。因为绑定到各确切版本的数据中的变更必须与接口的类型和全局约束相一致，所以确切版本变更不会造成下游故障并且因而可以在任何时间发生。因为约束(其是确切版本的一部分)由其分量的接口版本的依赖关系来限制，所以它只可以约束它可“看见”的事物。因此，下游约束不需要被重新评估，因为它们不会已变更。这是拥有显式依赖关系的一个益处。

因为约束是全局性的，所以它们可以影响多个配置分量。因此，为了作出特定的全局变更，在单个经组织的提交中原子地更新多个配置分量是必要的。

环境协调是开发人员或程序对实际上部署的配置值与配置值的预期集合相匹配进行确认的过程。在部署单个配置版本时，这是容易的-它是直接的检查过程，假定可以获取预期和实际值。然而，在进行非原子装配时，严格地这样做是较困难的——可能预期有两个或更多个不同的配置版本，每一个版本具有一组可能的不同的值。

配置引擎310通过使用称为过渡模糊性的特征来启用严格的环境协调。在任何给定时间，在配置引擎中，一组确切版本被标记为头版本(即，针对接口版本的当前、活动数据绑定)。分量的每一确切版本可包括需要为真的约束。如果所有分支中的所有分量的所有头确切版本的所有约束成立，则配置数据是全局一致的。

接口中可存在零个头版本，在这种情况下，接口根本不能被查询。最常见的是，将有一个头版本，在这种情况下，在评估期间返回版本的各值，除非调用者指定了更具体版本。

配置引擎310支持两个或更多个头确切版本。如图3所示，参考分量A 320，接口版本N 324具有绑定数据M+1334的头版本。接口版本N+1326包括绑定数据M 336和头版本绑定数据M+1338，它们分别对应于绑定数据M 332和绑定数据M+1334。但接口版本N+1326还包括绑定数据M+2340作为头版本。

在接口版本包括两个头版本时，配置引擎310在内部检查绑定数据的内容并在评估时返回一组值。在这些值跨各头版本等效时，返回单个共同值。在这些值跨各头版本不同时，返回一组不同的可能的值。

因为各配置分量可彼此依赖，所以这一组不同的可能的值是跨各分量来串接的(在每一步骤折叠相同的值)，直至向调用者返回最终结果。向调用者保证返回预期值的最小集合。即使在配置值处于过渡中的开发期间，这也确保了严格的环境协调(即，可能的预期值的最小集合的验证)。这将在图3的情况下发生，其中分量B 322依赖于分量A 326的接口版本N+1326，接口版本N+1326具有两个头版本。

在开发人员希望修改一个或多个配置分量时，这些分量通常是配置数据的更大集合的一部分。该更大集合可被称为配置数据的主分支或父分支。开发人员可以选择要包括在部分分支(即，子分支)中的分量，该部分分支包含从父分支所选的分量的副本，但不包括配置数据的整个集合的副本。

示出了部分分支342，它包括配置分量A 344。在这种情况下，开发人员选择了主分支中的配置分量A 320来包括在部分分支342中。配置分量A 344是配置分量A 320的副本，并且包括接口版本N 324和接口版本N+1326的副本以及这些接口版本中的每一个的绑定数据的各版本。

部分分支342继承主分支的非分支配置分量的视图，即对于未被包括在部分分支中的其他配置分量，部分分支342指回主分支。实际上，部分分支中的分量可以“看见”主分支中的其他分量，因而无需包括主分支的所有配置数据(同样，无需复制对数据中心的物理资源进行建模的配置数据)。因而，部分分支342使开发人员能够修改配置分量A 344而不影响主分支中的各配置分量，同时仍然维持构建和部署整个产品的能力。

例如，开发人员可能想要为接口版本添加绑定数据的新版本。如图所示，部分分支342中的配置分量A 344已被开发人员修改为包括绑定数据M+3346，绑定数据M+3346是接口版本N+1348的绑定数据的新头版本。

在经修改的分支的配置分量A 344就绪时，它被集成(或复制)到主分支中。配置引擎310同时检测在主分支中作出的变更，并要求开发人员理解并解决这些归并冲突。

现在参考图4，示出了用于本发明的一实施例中的示例性配置数据，并将其概括指定为配置数据400。配置数据400仅是合适的配置数据的一个示例。

参考图4，描绘了父分支410。在一个实施例中，父分支410自身可以是更大分支的一部分。在另一实施例中，父分支410可以是主分支，在这种情况下，它包括由配置引擎管理的整个数据中心或网络的配置数据。父分支410包括配置分量(“分量”)412、分量414、以及其他分量416、418和420。

分量412包括动态枚举(enum)420。在一实施例中，动态枚举是由配置引擎310在登入时实施的一种类型的约束。动态枚举类型可以与特定数量的配置分量相关联，或与配置分量内的函数(或映射)的参数相关联。在一实施例中，动态枚举类型表达一组资产，如动态枚举420中存在的一组群集(如群集A、群集B以及群集C)。在其他实施例中，动态枚举可以是数据中心、群集、特殊承租者、以及预期在群集被构建或引退时随时间增长或减小的任何其他一组资产的列表。动态枚举的概念是存在可被查询的特定一类事物，并且该类中的成员关系可以变化，但可以预先声明该选择将跨该类的所有成员总是有效的。

动态枚举类型表达可能的值的有限集。另外，从类型的观点来看，对可能的值的该集合的添加和减少是不透明的。因为，动态枚举是不透明的类型(即，该类型的细节是隐藏的)，所以可以在不需要分量接口中的变更的情况下来配置资产。这将数据中心中的变更(例如，新资产的添加、旧资产的移除)与配置分量中的结构变更隔离。

换言之，动态枚举的内容可以变更而不影响拥有它的分量的接口版本或不影响依赖于拥有它的分量的各分量的绑定。因为动态枚举类型是不透明的，所以对配置引擎中存在的资产集合进行增长或缩小而不影响不直接依赖该枚举内的值的配置分量是可能的。

分量414依赖于分量412的接口版本X(未示出)，因为可用于分量414的查询被定义在分量412的接口版本X中。在一实施例中，分量414可以查询分量412以确定动态枚举420中的给定群集是快还是慢。

子部分分支422包括分别作为父分支410中的分量412和414的副本的分量424和426。分量426被修改以查询动态枚举420中的给定群集是快、中等、还是慢。

图3的配置引擎310允许子分支中的动态枚举的限制对通过解耦的环境的配置流进行建模。即，父分支可以对动态枚举中的所有资产进行建模，而子分支只对这些资产的子集进行建模。这使得工程人员能够以如下方式设计和测试子分支中的配置变更：声明并实施所有全局约束，但只对该分支中存在的资产子集进行。如图4所示，子分支422限制动态枚举428的范围以使得它只列出群集A。一些全局约束相当简单(例如，如果各群集与灾难恢复的各复制对相关联，则与该对的每一元素相关联的伙伴群集必须是该对的另一元素)。

在查询是针对来自子分支的父分支中的配置分量来发出的情况下，动态枚举参数的值被限制于匹配子分支中已知的一组值，并且对于该资产子集，所返回的结果必须存在且被正确地类型化。实施所有全局约束，除动态枚举424只允许群集A的新配置设置的定义之外(即，开发人员不需要在部署周期中的早期用每一群集的值来填充新配置设置)。在一实施例中，动态枚举的限制是显式的。显式限制允许验证受限枚举中未包括的数据仍然处于完全枚举中(与只忽略该限制之外的每一事物相对)，这尤其允许更容易地发觉打字错误。

因此，动态枚举允许全局约束只应用于整合中的该群集集合，这进而允许在对所有生产群集定义所需值的完整集合之前在整合中部署新配置版本。动态枚举使配置引擎310能够保证所有所需配置在新实例可被添加到枚举之前已被提供给该实例，即在将新资产添加到数据中心之前用值填充了所有所需设置。

例如，这将确保新构建的群集的每一所需配置值在该群集被投入生产之前已被准备。动态枚举将群集和承租者生存期与每一分量版本的生存期隔离，而仍然允许分量所有者声明每群集所需的特定配置设置。

因而，开发人员可以独立地对配置进行确认(即，新证书的添加)，提前这样做会非常昂贵，因为父分支410中可能存在数百生产群集。

随着变更被向上集成通过父分支，可能检测到新类型的归并冲突(动态枚举约束确认失败)，该冲突作为集成的一部分将必须由父分支所有者来校正。以此方式，从一个解耦环境渐进地传播到下一个的配置变更可在配置引擎中被建模，从而使工程人员能够高效地与资产的小型集合一起工作，同时仍然允许在使用大量资产进行生产时对一致性的完全保证。

除确保全局约束与父分支中的各分量一致之外，配置引擎310还确保全局约束与跨所有分支的各分量一致。这造成以下系统：其中登入到每一分支中的配置总是有效——会违反这一不变量的任何变更必须被校正，可能跨作为经组织的提交的多个分量和分支来校正。这允许开发人员在子分支中开发新配置，而不影响处理父分支的其他开发人员。

随着跨各分支来集成配置变更，动态枚举增长得覆盖每一分支中表示的群集，从而在分开的解耦的环境中独立地确保全局一致性。对动态枚举的使用有效地将配置接口与资产管理解耦。

这还允许开发人员分支到特定一组配置分量，并且将这些分量作为一类活动快照来维护。即，该组配置分量被维护在必须总是与父分支中存在的其他分量相一致的版本专用的子分支中。这意味着，所保留的版本可以总是被部署到群集，同时知晓它将以健全且一致的方式与独立地前移或后移的其他配置版本进行互操作。所分支的配置版本可能必须稍微变更，但只确保满足全局约束——不因而新特征或策略。

现在参考图5，描绘了根据本发明的一实施例的方法，并且概括地指定为方法500。方法500仅是合适方法的一个示例。在步骤510，数据中心配置数据被组织成包括与数据中心配置的各方面相对应的配置数据的各配置分量。

在步骤512，将配置分量提供给开发人员，这使得开发人员能够在与主配置数据分开的环境中修改该配置分量。在步骤514，从开发人员接收该配置分量的经修改版本。

在步骤516，作出与接口所定义的查询是否合式有关的确定，即配置分量对于接口中的每一成员所返回的各值的类型是否与接口声明相一致。在步骤518，在确定查询合式时，经修改的配置分量作为新确切版本被接受到数据中心配置的托管集合中。在步骤520，在确定查询不合式时，拒绝经修改的配置分量。

假定经修改的配置分量被接受，在步骤522，从开发人员接收对提交新请求版本的请求。在步骤524，作出与新确切版本是否在全局上与数据中心配置一致有关的确定。对照该新数据来评估可能变更或已被引入的任何约束以验证全局一致性得到维持。

在步骤526，在确定新确切版本在全局上一致时，接受该请求并且该新确切版本变成头确切版本。此时，对数据进行查询的任何开发人员将接收到该经修改的数据。另一方面，在确定新确切版本不在全局上一致时，在步骤528，拒绝该请求。

在其他实施例中，在步骤512向开发人员提供配置分量可包括生成配置数据的包括该配置分量的部分分支。该部分分支引用未包括在该部分分支中的数据中心配置，从而使开发人员能够确认对该分量的变更与数据中心配置的其他部分相一致。

现在参考图6，描绘了根据本发明的一实施例的方法，并且概括地指定为方法600。方法600仅是合适方法的一个示例。在步骤610，提供配置数据的主分支，其包括数据中心的配置数据。在步骤612，提供主分支中的配置分量。该配置分量是与数据中心配置的一方面相对应的配置数据集。该配置分量需要指定一列数据中心资产的配置值，并且该配置分量包括对主分支中的其他配置分量的依赖关系。

在步骤614，向开发人员提供(或登出)配置数据的部分分支。该部分分支是主分支的一部分的副本并且包括该配置分量的副本。该部分分支中的配置分量的副本可供开发人员修改。在步骤616，向部分分支提供对主分支的访问，使得该配置分量的副本对其他配置分量的依赖关系在无需将该其他配置分量包括在该部分分支中的情况下实现。

在步骤618，数据中心资产的列表被限于该列表的子集。如果该列表中的一数据中心资产不处于该列表的该子集中，则部分分支中的配置分量不需要指定该数据中心资产的配置值。如上所述，这是动态枚举的一个功能。在一实施例中，该限制是显式的，并且验证包括检查未包括在该受限枚举中的数据的一致性。

在步骤622，从开发人员接收(或登入)该配置分量的经修改版本。在步骤624，作出该经修改的配置分量与数据中心配置的已提交版本在全局上一致的判定。在步骤626，在确定经修改的配置分量在全局上与数据中心配置的已提交版本相一致时，接受该经修改的配置分量。随后，该经修改的配置分量可用于由请求来自该分支的数据的相同或其他开发人员进行开发。在变更旨在变成数据中心的默认值的情况下，在经组织的提交之前它们必须也被集成到主分支。

现在参考图7，描绘了根据本发明的一实施例的方法，并且概括地指定为方法700。方法700仅是合适方法的一个示例。在步骤710，提供配置数据的父分支，其包括数据中心的配置数据。在步骤712，将配置数据组织成各分量，这些分量包括使一个分量能够查询另一分量以寻找配置设置的接口。与该查询相关联的数据需要符合所定义的数据类型。

在步骤714，响应于来自第一开发人员的请求，生成配置数据的第一子分支。该第一子分支包括作为父分支中的分量的副本的第一分量。在步骤716，将第一子分支提供给第一开发人员。随后，第一开发人员能够修改第一分量。

在步骤718，响应于来自第二开发人员的请求，生成配置数据的第二子分支。第二子分支包括第二分量，其中第二分量是父分支中另一分量的副本。在步骤720，将第二子分支提供给第二开发人员。

在步骤722，从开发人员接收第一分量的经修改版本。在步骤724，在接收到分量时，验证(A)第一分量中的数据的数据类型与父分支中的各分量相一致，(B)第一分量满足全局配置约束，(C)与第一分量相关联的查询合式，以及(D)第一分量中的数据的数据类型与第二子分支中的各分量相一致。

图8-12示出根据本发明的一实施例的组件依赖关系以及该依赖关系如何与配置变更的实现相关的真实世界示例。在一实施例中，当客户在数据中心中运行他们的应用时，根据他们使用的计算、存储、以及网络带宽而向他们收费。如果连接处于与该应用相同的数据中心内，则网络带宽使用是免费的。然而，如果网络流量去往数据中心之外，则带宽使用会造成按千兆字节传输数据的收费。此外，收费取决于流量的地理源和目的地而变化。例如，带宽在亚洲比在北美洲更贵。因此，如果源或目的地处于亚洲中的数据中心内，传输每千兆字节的收费将更高。

在一实施例中，带宽跟踪器测量在数据中心中运行的应用所使用的带宽。为了对它所测量的网络流量的源和目的地进行正确分类，使用一组网络范围(即，IP地址范围)来对带宽跟踪器进行编程。列出每一数据中心，并且对于每一数据中心，对位于该数据中心中的一组IP地址进行声明。以此方式，在带宽跟踪器观察到流入或流出所主存的应用的流量时，它可以记录必要的数据来在该客户的每月账单上生成带宽相关收费。

带宽跟踪器使用被称为机器配置文件(MCF)的文件中的网络范围。MCF具有特定格式，并且带宽跟踪器的代码知道如何使用该格式的数据。如果该格式有变化，则带宽跟踪器的代码必须紧跟该格式变化而变化，以便它可以继续利用MCF。MCF包含各类数据，包括但不限于IP范围。MCF中的各数据字段的值变化以反映位于数据中心中的一组物理资产的变化以及管控对这些资产的使用的测量的变化。

网络范围是从由网络服务组管理的分开的数据库中导出的。网络服务组负责协调所使用的所有IP地址的购买和管理。网络服务组按由预算和运营过程管控的其自己的时间表来更新这一IP范围数据库。IP范围数据库中作出的变更和带宽跟踪器的各周期性版本之间没有协调。然而，每当生成新MFC时，它应当包含IP范围的最新集合以确保记账准确性。

以上讨论描述了两种配置依赖关系，它们在图8中示出。图8描绘了根据本发明的一实施例的数据中心配置，并且被大致指定为数据中心配置800。数据中心配置800包括带宽跟踪器代码810、MCF数据812、MCF接口版本1.0814、IP范围数据816、以及IP范围接口版本1.0 818。

在一实施例中，如上所述，MCF数据812是依赖于被存储在不同的配置人工产物(网络服务IP范围数据816)中的数据的一个配置人工产物。此外，带宽跟踪器代码810依赖于MCF数据812的格式。带宽跟踪器代码810声明对MCF接口版本1.0 814的依赖关系(粗箭头820)。该接口版本描述MCF数据812的格式。MCF接口版本1.0814进而随时间被绑定到(虚线822)MCF数据812的若干版本。MCF数据812的每一版本的内容是不同的，但每一版本符合MCF接口版本1.0 814中的格式约束，从而确保带宽跟踪器代码810将能够使用该数据。

MCF进而依赖于(粗箭头824)IP范围接口版本1.0 818，IP范围接口版本1.0 818进而随时间绑定到(虚线826)IP范围数据816的多个版本。MCF数据812包含嵌入查询828，嵌入查询828经由在IP范围接口版本1.0 818中声明的机制从IP范围分量中自动检索IP范围数据816的最新更新版本。即使IP范围数据816频繁变更，MCF数据812中的查询也将总是以它知道如何使用的格式检索有效结果，因为IP范围接口版本1.0 818是一致的

因为接口版本是一致的，所以绑定到这些接口版本的数据的具体值可以根据数据的每一类别的不同所有者的不同过程和时间表来变更。同时，在这些底层值变更时该数据的使用者不必做任何工作，因为它们只依赖于在接口版本中声明的格式。

图9是描绘根据本发明的一实施例的数据中心配置的框图，并且被概括指定为数据中心配置900。数据中心配置900包括带宽跟踪器代码810、MCF数据812、MCF接口版本1.0 814、IP范围数据816、以及IP范围接口版本1.0 818，它们中的每一个也在图8中描绘。数据中心配置900还包括IP范围数据910和IP范围接口版本2.0 912。

参考图9，在一个实施例中，开发人员决定将数据中心从使用IPv4协议切换到IPv6协议。IP范围数据816随后将需要具有新格式。开发人员将声明新IP范围接口版本2.0 912。一开始，它将处于旧版本旁边，如图9所示。

此时，没有分量依赖于IP范围接口版本2.0 912。最终，在拥有MCF数据812的团队开始考虑它时，该MCF分量可以产生展示除IPv4网络范围之外的IPv6网络范围的新MCF接口版本。参考图10，一框图描绘根据本发明的一实施例的数据中心配置，并且被概括指定为数据中心配置1000。除在图9中描绘的各项之外，数据中心配置1000包括MCF数据1010和MCF接口版本2.0 1012。

此时，拥有带宽跟踪器的开发人员团队修改带宽跟踪器代码810，以使得它停止依赖于只展示IPv4范围的MCF的接口版本(MCF接口版本1.0 814)，并开始依赖于展示IPv4和IPv6两者的IP范围的MCF接口版本(MCF接口版本2.0 1012)。这在图11中示出。参考图11，一框图描绘根据本发明的一实施例的数据中心配置，并且被概括指定为数据中心配置1100。数据中心配置1100包括在图10中描绘的各项，除了作为被开发人员团队修改的结果，带宽跟踪器代码810被描绘成依赖于MCF接口版本2.0 1012而非MCF接口版本1.0814之外。

在一实施例中，为了降低他们的维护负担，负责MCF的团队可使MCF版本1.0引退，如图12所示。参考图12，一框图描绘根据本发明的一实施例的数据中心配置，并且被概括指定为数据中心配置1200。数据中心配置1200包括在图11中描绘的各项，除了作为已被负责该MCF的团队引退的结果的MCF接口版本1.0 814及其绑定数据(MCF数据812)之外。

以上示例示出以下几点：

因为不同类别的数据由不同团队根据不同过程和时间表来维护，所以将配置分解成可被独立维护的各分开的配置分量是方便的；

各配置分量可彼此依赖，并且代码也可依赖于配置分量；

各接口版本之间的一致的、显式地声明的依赖关系集合可以将不同的分量(以及负责维护它们的团队)与它们所依赖的数据的格式变更相隔离，而同时仍然允许底层数据(或值)在任何时间点变更；

新接口版本的引入允许以如下方式渐进地包括格式变更：这些变更不会使任何消费者中断；以及

在接口版本不再被任何分量依赖时，它可被引退并且不再需要被维护。

所描绘的各组件以及未示出的组件的许多不同的安排都是可能的，而不背离所附权利要求书的精神和范围。已带着说明而非限制的意图描述了本技术。在阅读本发明之后或由于阅读了本发明，替换实施例将变得对本发明的读者显而易见。可完成实现上述的替换装置而不脱离所附权利要求书的范围。某些特征和子组合是有用的，并且可以使用而无需参考其他特征和子组合并且被认为是在权利要求书的范围之内的。

Claims (15)

1.一种其上包括计算机可执行指令的计算机可读介质，所述计算机可执行指令在被执行时执行一种更新数据中心配置的方法，所述方法包括：

将所述数据中心配置组织(510)成各配置分量，其中所述配置分量是与所述数据中心配置的各方面相对应的各配置数据集，并且其中所述配置分量包括定义可由所述配置分量的使用者来查询的命名的、类型化的配置设置的接口；

将配置分量提供(512)给开发人员，其中所述配置分量可供所述开发人员与所述数据中心配置分开地修改；

从所述开发人员接收(514)所述配置分量的经修改版本(“经修改的配置分量”)；

确定(516)所述配置分量的接口是否是合式的；

在所述接口合式时，将所述经修改的配置分量接受(518)到数据中心配置的托管集合中，其中所述经修改的配置分量可用于部署；

在所述经修改的配置分量不合式时，拒绝(520)所述经修改的配置分量。

2.如权利要求1所述的介质，其特征在于，确定所述接口是否是合式的包括确定所述配置分量返回的值是否与所述接口中定义的配置设置相一致。

3.如权利要求1所述的介质，其特征在于，所述方法还包括：

接收(522)对提交所述经修改的配置分量的请求；

确定(524)所述经修改的配置分量与所述数据中心配置的已提交版本是否在全局上一致；

在所述经修改的配置分量与所述数据中心配置的已提交版本在全局上一致时，将所述经修改的配置分量接受(526)到数据中心配置的托管集合中，其中所述经修改的配置分量可用于由另一开发人员部署；以及

在所述经修改的配置分量与数据中心配置的已提交版本不在全局上一致时，拒绝(528)所述经修改的配置分量。

4.如权利要求1所述的介质，其特征在于，所述方法还包括生成配置数据的部分分支，其中所述部分分支包括所述配置分量，其中所述部分分支引用该部分分支中未包括的数据中心配置，并且其中通过将所述部分分支提供给所述开发人员来将所述配置分量提供给所述开发人员。

5.如权利要求3所述的介质，其特征在于，确定所述经修改的配置分量与所述数据中心配置的已提交版本是否在全局上一致包括确定所述经修改的配置分量是否满足跨各配置分量实施的配置约束。

6.如权利要求1所述的介质，其特征在于，所述方法包括生成包括构成配置数据的保留版本的一组配置分量的第二部分分支，其中该组配置分量作为版本专用部分分支来维护，其中所述版本专用部分分支需要与父分支的当前版本中的各配置分量相一致。

7.一种其上包括计算机可执行指令的计算机可读介质，所述计算机可执行指令在被执行时执行一种更新数据中心配置数据的方法，所述方法包括：

提供(610)配置数据的主分支，该主分支包括所述数据中心配置数据；

提供(612)配置分量，其中所述配置分量被包括在所述主分支中，其中配置分量是与所述数据中心配置的一方面相对应的配置数据集，其中所述配置分量需要指定一列数据中心资产的配置值，并且其中所述配置分量包括对所述主分支中的其他配置分量的依赖关系；

将配置数据的部分分支提供(614)给开发人员，其中所述部分分支是所述主分支的一部分的副本，其中所述部分分支包括所述配置分量的副本，并且其中所述配置分量的副本可供所述开发人员修改；

向所述部分分支提供(616)对所述主分支的访问，其中所述配置分量的副本对所述其他配置分量的依赖关系是在无需将所述其他配置分量包括在所述部分分支中的情况下实现的；

在(618)所述部分分支中，将所述数据中心资产的列表限于所述数据中心资产列表的子集(“受限列表”)，其中如果所述数据中心资产列表中的一数据中心资产不在所述受限列表中，则所述部分分支中的配置分量不需要指定该数据中心资产的配置值；

从所述开发人员接收(622)所述配置分量的经修改版本(“经修改的配置分量”)；

确定(624)所述经修改的配置分量与数据中心配置的已提交版本在全局上一致；以及

在所述经修改的配置分量与所述数据中心配置的已提交版本在全局上一致(626)时，将所述经修改的配置分量接受到数据中心配置的托管集合中，其中所述经修改的配置分量可用于部署。

8.如权利要求7所述的介质，其特征在于，所述配置分量包括定义可由所述配置分量的使用者来查询的命名的、类型化的配置设置的接口。

9.如权利要求8所述的介质，其特征在于，确定所述经修改的配置分量与所述数据中心配置的已提交版本在全局上一致包括验证所述经修改的配置分量与不处于所述受限列表中的数据中心资产相一致。

10.如权利要求7所述的介质，其特征在于，所述开发人员对所述部分分支的修改与所述数据中心配置数据相隔离。

11.如权利要求7所述的介质，其特征在于，确定所述经修改的配置分量与所述数据中心配置的已提交版本在全局上一致包括验证所述经修改的配置分量与第二部分分支中的配置分量相一致。

12.一种其上包括计算机可执行指令的计算机可读介质，所述计算机可执行指令在被执行时执行一种对数据中心的配置数据的独立的、同时的修改进行管理的方法，所述方法包括：

提供(710)配置数据的父分支，所述父分支包括所述数据中心的配置数据；

将所述配置数据组织(712)成各分量，其中所述分量包括使一个分量能够查询另一分量以寻找配置设置的接口，其中与所述查询相关联的数据符合数据类型；

响应于来自第一开发人员的请求，生成(714)配置数据的第一子分支，其中所述第一子分支包括第一分量，其中所述第一分量是所述父分支中的一分量的副本，并且其中对所述子分支中的第一分量的修改不影响所述父分支；

将所述第一子分支提供(716)给所述第一开发人员，其中使得所述第一开发人员能够修改所述第一分量；

响应于来自第二开发人员的请求，生成(718)配置数据的第二子分支，其中所述第二子分支包括第二分量，其中所述第二分量是所述父分支中的另一分量的副本；

将所述第二子分支提供(720)给所述第二开发人员，其中使得所述第二开发人员能够修改所述第二分量；

从所述第一开发人员接收(722)所述第一分量，其中所述第一分量已被修改；以及

在接收到所述第一分量时，

(A)验证(724)所述第一分量中的数据的数据类型与所述父分支中的各分量相一致，

(B)验证(724)所述第一分量满足全局配置约束，

(C)验证(724)与所述第一分量相关联的查询是合式的；以及

(D)验证(724)所述第一分量中的数据的数据类型与所述第二子分支中的各分量相一致。

13.如权利要求12所述的介质，其特征在于，验证所述数据类型与所述父分支中的各分量相一致包括验证跨各上游分量的数据类型是一致的。

14.如权利要求12所述的介质，其特征在于，验证查询是合式的包括验证所述查询对所述接口中的每一成员所返回的值的类型与接口声明相一致。

15.如权利要求12所述的介质，其特征在于，分量是与所述数据中心配置的一方面相对应的配置数据集，并且其中所述方面是物理资产、逻辑资产、以及策略之一。

Images