跨云管理和故障查找的制作方法

xiaoxiao2020-7-22  3

【专利下载】Tel:18215660330

跨云管理和故障查找的制作方法
【专利摘要】本文描述了向应用提供横跨两个或更多个云的能力的云管理系统,同时允许将分布式应用作为单个应用来进行操作、管理、以及故障查找。该系统提供跨各数据中心通信以执行并对应用的在不同的位置处运行的各实例的知识进行集中的基础结构。该系统所提供的基础结构监视该应用和各云之间的连接,具有知道问题是否处于应用内或是因为各云之间的连接的智能。该系统协调跨多个云平台/位置的管理功能。因而,该云管理系统创建跨多个云的单个监视和故障查找接口和知识以及执行结构,使得分布在多个云的各应用可被更容易地监视、管理以及调试。
【专利说明】跨云管理和故障查找
【背景技术】
[0001 ] 数据中心提供用于运行大型应用的服务器。企业通常使用数据中心来运行核心业务功能,诸如销售、营销、人力资源、记账、产品目录等。数据中心还可以运行诸如网站、web服务、电子邮件主机、数据库等面向顾客的应用,以及许多其他应用。数据中心通常是通过确定预期峰值负载并提供服务器、网络基础结构、冷却和其他资源以处理峰值负载水平来构建的。数据中心非常昂贵且在非峰值时间未被充分利用是公知的。就用于监视和执行对数据中心的维护的装备和人员两者而言,数据中心还涉及相对高的管理费用。由于几乎每一公司都使用某种数据中心,因此存在跨世界的组织所执行的许多冗余功能。
[0002]出现了云计算作为传统数据中心的一种优化。云被定义成通过网络可用的、可针对企业的至少一些传统数据中心功能提供服务的资源集(例如,处理、存储或其他资源)。云通常涉及抽象层,使得云的应用和用户可能不知道在其中运行应用的具体硬件、该硬件位于何处等。这允许云运营商在使资源交替进出服务、维护等方面而言的某种附加的自由度。云可以包括公共云(诸如MICROSOFT TM Azure>Amazon Web Services及其他),以及私有云(诸如由Eucalyptus Systems'MICROSOFT TM及其他所提供的那些云)。公司已开始供应企业可放置在其自己的数据中心中的设备(例如,MICROSOFT TM Azure设备)以连接具有变化的云功能级别的数据中心。
[0003]即使当基于云的资源被利用时,具有数据中心的企业在增建大型数据中心时也招致巨大的成本。企业通常仍然计划了 “最差情况”的峰值情形并由此包括许多硬件,其中至少一些硬件在额外处理容量、额外存储空间等方面很少被使用或未被充分利用。该额外资源量为很少的回报招致高成本。使用场所内基于云的计算的顾客期望能够针对峰值容量时间、针对灾难恢复情形或仅针对容量管理而使用另一兼容云(例如,其自身在另一位置的第二实例、微软的公共云等)中的容量。与为最差情况的情形而增建然后为冗余而翻倍相比,这样做便宜得多。另外,他们期望能够管理(例如,故障查找、操作)分散在多个云的应用。当前,应用、云管理、以及故障查找没有跨各个云或其他数据中心来操作。

【发明内容】

[0004]本文描述了向应用提供跨两个或更多个云(它可跨很大距离)的能力的云管理系统,同时允许将分布式应用作为单个应用来进行操作、管理、以及故障查找。该系统提供跨各数据中心通信以执行并对应用的在不同的位置处运行的各实例的知识进行集中的基础结构。在一些情况下,该系统提供企业可将其置于它自己的私有数据中心中的计算设备,同时经由该计算设备提供统一管理,该私有数据中心允许管理员将至少一些应用负载分布在公共云或其他分开的位置。该系统所提供的基础结构监视该应用和各云之间的连接两者,具有知道问题是处于应用内还是因为各云之间的连接的智能。该系统协调跨多个云平台/位置的管理功能。如果管理员想要调试该应用,则该系统允许通过无缝的统一接口来在正确的位置处进行实况调试。因而,该云管理系统创建跨多个云的单个监视和故障查找接口和知识以及执行“结构”,使得跨多个云分布的各应用可被更容易地监视、管理以及调试。[0005]提供本概述以便以简化形式介绍将在以下详细描述中进一步描述的一些概念。本概述并不旨在标识所要求保护主题的关键特征或必要特征,也不旨在用于限制所要求保护主题的范围。
【专利附图】

【附图说明】
[0006]图1示出在一个实施例中在与管理基础结构相关联的两个云中运行的应用。
[0007]图2是示出在一个实施例中的云管理系统的各组件的框图。
[0008]图3是示出在一个实施例中云管理系统的用于处理来自管理工具的访问来自分布式应用实例的数据的请求的处理的流程图。
[0009]图4是示出在一个实施例中云管理系统的用于从远程应用实例的位置处报告回数据并在远程应用实例的位置处处理故障查找请求的处理的流程图。
【具体实施方式】
[0010]本文描述了向应用提供跨两个或更多个云(它可跨很大距离)的能力的云管理系统,同时允许将分布式应用作为单个应用来进行操作、管理、以及故障查找。该系统提供跨各数据中心通信以执行并对应用的在不同的位置处运行的各实例的知识进行集中的基础结构。例如,该系统可以集中日志记录、性能跟踪以及其他管理功能,而不管该应用在何处运行。在一些情况下,该系统提供企业可将其置于它自己的私有数据中心中的计算设备,同时经由该计算设备提供统一管理,该私有数据中心允许管理员将至少一些应用负载分布在公共云或其他分开的位置。
[0011]该云管理系统所提供的基础结构监视该应用和各云之间的连接两者,具有知道问题是否处于应用内或是因为各云之间的连接的智能。该系统协调跨多个云平台/位置的管理功能(从一个云的基础结构,任务被协调以跨两个或更多个云执行)。如果管理员想要调试该应用,则该系统允许通过无缝的统一接口来在正确的位置处进行实况调试。因而,该云管理系统创建跨多个云的单个监视和故障查找接口和知识以及执行“结构”,使得分布在多个云的各应用可被更容易地监视、管理以及调试。
[0012]图1示出在一个实施例中在与管理基础结构相关联的两个云中运行的应用。在一些实施例中,云管理系统使用一个云中的基础结构来影响应用(和/或管理员),该云具有所有位置处的数据/访问所有位置处的数据以能够完全对该应用进行监视/故障查找。作为示例,考虑具有在两个云(在图1中示为云110和云150)中运行的实例的应用。云110包括包含基础结构130的微软TMAzure设备实例120。设备实例120包括运行角色140和角色145的应用实例125。第二云150包括运行角色160和角色170的应用实例155。第二云150还包括基础结构180。应用实例120知道这些角色中的每一个并且知道它们是同一应用的一部分。每一位置处的基础结构管道允许设备实例120检索与在第二云150处执行的角色160和角色170有关的信息。该系统可分布任一单独的角色、整个应用、或这两者。有了所有管理数据(例如,来自应用、机器、以及基础结构的日志),该系统可通过应用预定义的健康规则来评估该应用的健康,如同所有角色在本地一样。该系统还可查看跨这些位置的基础结构健康以及其间的连接190,以评估该应用或基础结构/网络是否发生了问题。
[0013]类似地,在需要自动或手动故障查找或补救步骤时,云110中的基础结构130可与z? 150中的基础结构180进彳丁协调以提供故障查找和调试支持。例如,该系统结构可以达到各个位置以执行应用范围的更新、关闭等。本领域普通技术人员将明白执行跨位置控制的多种方式。例如,基础结构130可直接控制基础结构180,基础结构130可请求基础结构180代表基础结构130来执行,等等。同样,有了操作员/管理员故障查找工具(例如,监视可视化、警报、日志以及配置数据查看,等等),应用和基础结构的位置是可用的并且在逻辑上被显示,但不涉及分开的工具和来自管理员的脑力体操来合在一起。例如,在对所有角色的数据进行故障查找和查看时,如果管理员105的下一步是使用一个或多个工具195来查看应用的日志或开始与角色实例的远程会话,则该系统直接连接管理员105,而不管该角色处于何处。
[0014]该云管理系统的设计提供了服务跨多个云/位置的简化且一致的运行。该系统将“计算资源”的定义从服务器(数据中心以外)移至因特网的一部分(数据中心和它们之间的连接)。这允许在服务层定义、监视以及管理服务层协定(SLA)——这是服务所有者通常最关心的。
[0015]在一些实施例中,云管理系统与云迁移系统协作,在需要时云迁移系统将应用从一个位置无缝地迁移到另一位置,称为爆发(bursting)。云迁移系统通过检测峰值负载条件并且自动地将计算移至另一资源(并移回)以及通过跨两个或更多云提供计算并且在一个站点处发生灾难的情况下完全移至一个站点来提供容量管理和灾难恢复。这允许企业为持续的负载水平而计划本地资源,并且针对峰值或其他不常见的负载利用基于云的资源。在许多情况下,企业的业务是这样的:一年的特定时间较忙碌,并且仅在那些时间需要额外资源。例如,税务规划企业在四月中旬特别忙碌,电子商务站点在感恩节和圣诞节前后经历假日高峰。云迁移系统监视数据中心内的负载,并且检测指示当前负载正接近该数据中心的容量的阈值。例如,系统可以监视中央处理单元(CPU )使用、存储器使用、存储使用、网络带宽以及其他度量,以确定数据中心对当前负载处理得有多好。系统还可以观察趋势(例如,资源使用的加速度速率)以确定是否已经达到或即将达到阈值。
[0016]在检测到该阈值将被达到时,云迁移系统促进至少某一数据中心负载至另一数据中心或基于云的资源的有序移动。例如,系统可以将某一峰值负载迁移至公共云。由于云定价模型可能变化,因此系统可以在决策中考虑成本因素。例如,系统可以偏好在企业数据中心处托管尽可能多的负载以降低成本,而仅将云资源利用到满足客户机请求所需的程度。系统还可以提供管理和监视工具,这些管理和监视工具为信息技术(IT)人员提供一致的体验,而不管特定负载在哪里运行(例如,在企业内本地地运行或使用云公开地运行)。该系统还可以提供规划工具以帮助决定供高负载期间移至其他资源的适当工作负载或应用。例如,应用可以具有使其较适于或较不适于迁移的各种顺应性/规章或联网/设计限制。该系统还可在数据中心/网络级处作为灾难恢复体系结构而被用于在灾难情况下管理快速的工作负载转移。如果数据中心资源持久地发生故障,则系统可以迅速且高效地将附加负载迁移至云或其他资源,以使得数据中心的客户机不受或少受该故障的影响。由此,云迁移系统允许企业构建针对稀有额外负载利用其他资源的、更小且更高效的数据中心。
[0017]在应用被从一个位置迁移到另一位置时,该云管理系统与云迁移系统一起工作来提供无缝管理和故障查找。如上所述,云迁移系统可以在临时(即,爆发)或永久(即,灾难恢复)的基础上在数据中心与云之间移动资源。临时移动包括在短的一段时间内爆发应用或其他负载,以处理超出数据中心容量的峰值或其他高负载。临时移动可以包括爆发整个应用、或将应用的负载拆分到两个或更多个位置。永久移动包括因数据中心中的硬件故障、更持久的容量需求增长、使用动态负载平衡全局地分发应用的希望等而导致的较长期的迁移。以下是其中系统可被企业使用的若干示例情形。
[0018]在第一示例中,企业将应用负载爆发至公共云以管理容量。公司决策者(B卩,CEO、CFO、或营销/销售副总)和数据中心系统管理员决定以下方式将更加成本高效且提供更好的客户体验:在他们每年使用/通信量的排名前三的峰值天水平将一些工作爆发到公共云,并且使他们自己的数据中心(可能具有云设备)维持在他们的每月峰值使用水平。他们与云提供者签署关于将工作爆发至云以及何时及会有多少工作的项目估计的业务协议。其帐户被建立并且信息被输入至云设备。在规划阶段期间,管理员使用来自云提供者的确保连接正确地工作的测试应用来运行测试。管理员然后在容量管理工具中设置将容量保持在指定级别的各容量值(例如,阈值)以启动对各应用的爆发。管理员进入该工具以进一步指定在这一情况下那些有资格移动的应用(例如,临时移动没有规章问题,良好的技术配合)。
[0019]某一天,使用超出限制并且系统自动地将各应用移至公共云。在监视/使用系统中抛出以下警告:容量何时在所启动的5%的爆发内,系统何时爆发,系统爆发了什么,以及系统何时拿回应用。保留所移动的全部计算资源和/或存储的显式日志,并且警告管理员进入其公共云帐户进行记账。在企业数据中心组和管理中的定期容量规划会议上审阅对被标记为可移动的爆发参数和应用的审阅。
[0020]在第二示例中,企业将各应用拆分到各个云以管理容量。这一情形类似于上述情形,除了所移动的应用的类型更复杂而因此被拆分出以进行不同的优先级区分以外。公司决定与云提供者具有关系以将各应用拆分至云(一种形式的爆发)。在这一情况下,大型应用被预标识成猝发候选。当容量达到阈值时,100个工作者实例中的50个被自动地移至公共云。该应用现在拆分到两个设备实例(即,云实例),而全部监视和记账数据被发送至起始实例以使其能被集中管理。企业自身数据中心中的云设备具有用于帮助调试拆分应用的可能问题(例如,联网问题、网络带宽/等待时间问题、结构通信等)的故障查找工具。当容量情形在设备上平息下来时,则50个工作者实例被移回设备并且再次作为正常运作的应用。
[0021]在另一示例中,云提供者决定从一个群集暴发至另一群集。公共云容量规划团队决定芝加哥数据中心中的群集临界充满,但想要维持高利用率。当利用率到达90%时,他们设置爆发至西海岸数据中心中未被充分利用的群集。管理员进入容量管理工具并且将适当的顾客/应用(例如,具有低的数据使用)选作移动候选。某一天,芝加哥群集的使用达到阈值,并且系统自动地将所选择的应用(例如,群集的应用中的10%)移至西海岸数据中心一天。随着使用返回该阈值以下,系统将应用移回芝加哥。该系统抢先向指定监视团队通知该暴发以使其能够回答顾客的问题。
[0022]在另一示例中,该系统被用于跨云的公文包管理。企业决定在其云设备上高效地管理容量,他们想要将全部需求可变的应用放在公共云中而将其需求恒定的应用放在该设备或本地数据中心资源上(并且由此能够以更高利用率运行该设备)。尽管他们想要拆分其计算资源,但他们仍然想要跨其全部应用的健康的全局视图、使其应用开发者以相同方式管理各应用、并且跨这两者维持部门级记账的单个视图(例如,向顾客销售组、内部IT、B2B销售等分配什么成本)。企业能够针对公共云设置聚集帐户(其中相同组作为设备),并且取得记账数据以在他们一侧进行集成。类似地,他们能够取得访问在其中运行其应用的平台的公共云监视数据的应用编程接口(API)以及应用级监视,使得其网络操作中心(NOC)对企业的计算活动状态具有完整且一致的视图。
[0023]在另一示例中,企业使用动态负载平衡来设置全局分布的应用。企业顾客想要跨两个或更多个云实例管理容量,并且使他们的大量负载处于独立的但地理上分布的各实例中(例如,具有都服务德国查询的美国和英国数据中心的Bing (必应)搜索)。在正常环境下,全局通信量管理者向每一位置发送50%的通信量。当负载在主要位置处变高时,该系统指示负载平衡器向英国系统发送75%的通信量,由此从美国云实例中释放容量,从而将其带到可接受级。当容量返回正常时,系统告诉负载平衡器返回50/50的拆分。对此的变体是公共云被用作辅助数据中心(比如说,顾客站点的负载为1%而设备为其余99%)。在灾难或因其他原因移动来自顾客站点的负载的情况下,100%的通信量被转移至公共云。
[0024]在另一示例中,企业已达到其数据中心的容量并且需要额外计算资源,但尚不具有用于花费在扩展该数据中心的可用资产。在该情况下,公司可以使用公共云供溢出,直到它们能够完成硬件购买。
[0025]图2是示出在一个实施例中的云管理系统的各组件的框图。系统200包括位置管理组件210、位置数据存储220、工具接口组件230、一个或多个管理工具240、数据迁移组件250、故障查找组件260、以及记账组件270。这些组件中的每个都在此予以更详细讨论。
[0026]位置管理组件210管理与应用的各实例在其中运行的多个数据中心位置有关的信息。组件210包括描述如何达到每一位置的信息、可用于检索管理信息的连接、具有相关联的安全证书的用于每一位置的用户账户、从中收集故障查找信息并发送故障查找命令的应用和数据中心组件,等等。位置管理组件210接收描述应用负载的任何迁移或从一个数据中心/云到另一个的爆发的信息,并更新所管理的信息使得组件210具有该应用在其中运行的所有位置的完整画面。这允许系统200呈现该完整画面并使得应用的管理统一,而不管应用在何处运行或在多少位置处运行。在条件改变和分发各应用时,位置管理组件210可以呈现具有全面的一组管理数据的管理工具。
[0027]位置数据存储220存储描述应用的各实例在其中运行的各位置的信息。数据存储220可以包括一个或多个文件、文件系统、硬盘驱动器、数据库、基于云的存储服务、或用于持久存储与系统200的各会话之间的信息的其他设施。所存储的信息可包括连接信息、用户角色、管理数据的源、可用日志文件、以及与分布到多个位置的应用的管理或故障查找有关的任何其他信息。
[0028]工具接口组件230向系统200提供接口,一个或多个工具通过该接口可访问应用的管理和故障查找信息。该接口可以包括一个或多个网页、web服务、应用编程接口(API)、或管理员或工具通过其可以直接地或通过程序来访问系统200的管理和故障查找信息的其他接口。在一些实施例中,工具接口组件230提供初始连接点以供工具访问与位于企业的私有数据中心内的云计算设备处的应用有关的信息。该设备可以管理应用负载到公共云或其他数据中心的迁移和分布,并向收集管理信息或提供应用故障查找的工具提供中心联系点。
[0029]一个或多个管理工具240连接到工具接口组件230以访问管理信息或执行应用故障查找。工具可包括日志查看器、报告工具、调试工具、或显示与正在运行的应用有关的信息或者帮助解决正在运行的应用的问题的其他工具。管理工具240可包括被设计成与本地应用一起工作的工具,且系统200向该工具提供描述在多个位置处运行的不具有该工具的知识的分布式应用的信息。这允许使用管理员所依赖的现有工具,即使在将自动应用负载迁移引入数据中心或云中时。在其他情况下,工具可被专门编写成理解分布式应用,并提供与多个位置有关的特定管理信息或故障查找。工具接口组件230可以提供多个接口,管理工具240通过这些接口使用每一工具所理解的范例来连接到系统200。
[0030]数据迁移组件250将应用在其中运行的一个或多个远程位置处的管理信息迁移回该应用的本地(home)位置。本地位置可包括私有数据中心、位置或云计算设备、或该应用在稳定条件下在其中正常运行的其他位置。在达到特定负载水平(例如,峰值或周期性爆发)时,该应用可将一些负载迁移到一个或多个其他数据中心或公共云以帮助满足客户机请求。这些其他位置如本地位置一样生成管理数据,如日志文件、事务数据等,并且数据迁移组件250将这一数据迁移回本地位置或提供从本地位置对该数据的访问,使得管理工具240能够向管理员提供该应用的活动的全面画面。
[0031]故障查找组件260在一个或多个位置处对该应用执行故障查找任务。故障查找可包括调试、处理测试数据、或其他形式的确定应用是否正确地操作。故障查找一般在本地位置处很好理解,但随着应用开始横跨多个数据中心或云而变得更加复杂。云管理系统200通过提供统一接口来使管理工具240和管理员与这一复杂性隔离开,其中工具和管理员通过该统一接口访问管理信息并执行多个位置处的故障查找。因而,如果管理工具允许管理员在本地位置处的应用代码的特定片段处放置断点或从该特定片段处接收跟踪信息,则故障查找组件260使得在该应用的基于远程云的实例处也一样容易地这样做。工具和管理员甚至可不知道该应用在其中运行的所有位置,而仍然可执行管理任务,如同该应用只在本地位置处执行一样。
[0032]记账组件270报告与应用在其中运行的一个或多个位置有关的记账信息。一个常见的管理任务是管理计算成本,并且公共云通常基于与工作负载有关的度量(例如,计算时间、所使用的存储空间,等等)来收费。对管理员而言,收集各应用实例在各位置处造成的成本的画面可能是有用的,并且云管理系统200可任选地提供记账组件270以收集这一类型的信息,使得该信息可通过管理工具和报告来被报告。
[0033]在其中面实现了云管理系统的计算设备可包括中央处理单元、存储器、输入设备(例如,键盘和指示设备)、输出设备(例如,显示设备),以及存储设备(例如,磁盘驱动器或其他非易失性存储介质)。存储器和存储设备是可以是编码有实现或启用该系统的计算机可执行指令(如软件)的计算机可读存储介质。此外,数据结构和消息结构可被存储或经由诸如通信链路上的信号等数据传输介质传送。可以使用各种通信链路,诸如因特网、局域网、广域网、点对点拨号连接、蜂窝电话网络等。
[0034]该系统的实施例可以在各种操作环境中实现,这些操作环境包括个人计算机、月艮务器计算机、手持式或膝上型设备、多处理器系统、基于微处理器的系统、可编程消费电子产品、数码相机、网络PC、小型计算机、大型计算机、包括上述系统或设备等中任一种的分布式计算环境、机顶盒、片上系统(SOC)等。计算机系统可以是蜂窝电话、个人数字助理、智能电话、个人计算机、可编程消费电子设备、数码相机等。
[0035]该系统可以在由一个或多个计算机或其他设备执行的诸如程序模块等计算机可执行指令的通用上下文中描述。一般而言,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。通常,程序模块的功能可在各个实施例中按需进行组合或分布。
[0036]图3是示出在一个实施例中云管理系统的用于处理来自管理工具的访问来自分布式应用实例的数据的请求的处理的流程图。在框310中开始,该系统从管理工具接收访问与在一个或多个数据中心中运行各实例的应用有关的管理数据的请求。例如,性能监视工具可以请求描述该应用正在处理多少客户机请求、该应用的资源使用的状态信息,或者来自该应用的其他信息。该系统可通过该系统展示给各工具的用于请求管理数据的API来接收工具请求。该API可包括用于访问管理数据的统一接口,而不管各应用实例在何处运行或在多少位置处运行。
[0037]在框320中继续,该系统标识满足接收到的请求的一个或多个类型的管理数据。例如,该系统可以确定该请求要求该应用的每一实例所产生的日志信息。标识所请求的数据允许该系统确定从每一应用实例收集哪些信息或该数据是否已经在本地从由每一应用实例推送到中心位置的数据中进行了收集。
[0038]在框330中继续,该系统确定包括所述应用的两个或更多个实例的应用分布。该分布确定该应用在何处运行以及该系统将在何处找到用于满足该请求的管理数据。该系统可包括跟踪描述应用负载去往/始自其他数据中心的每一爆发或其他迁移的信息的数据存储,使得该系统知道各应用实例在其中运行的每一位置。在接收到管理工具请求后,这一信息运行该系统确定从何处收集管理数据。
[0039]在框340中继续,该系统从每一分布式应用实例收集用于满足该请求的管理数据。各实例可包括本地私有数据中心、远程私有数据中心、私有云计算设施、公共云计算设施、其他私有数据中心所提供的备用资源等中的实例。该系统联系该应用的每一实例或访问先前从每一实例发送的包含用于满足接收到的管理工具请求的信息(如性能数据、故障,等等)的信息。
[0040]在框350中继续,该系统可任选地向一个或多个远程应用实例发送一个或多个故障查找命令。例如,如果一个位置正经历故障,则管理员可使用管理工具来请求附加跟踪信息、发送一个或多个测试请求、或执行其他类型的调试。远程应用实例实现故障查找命令并将所请求的数据报告回管理工具可访问该信息的中心位置。
[0041]在框360中继续,该系统统一所收集的数据以提供对接收到的管理工具请求的统一响应。以此方式,管理工具不必被编写成包括对该工具所管理的应用的各种可能分布的理解。该系统因而可按需将应用从一个位置自由地迁移到一个或多个位置以处理应用负载,同时仍然向管理员提供直截了当的管理和故障查找体验。
[0042]在框370中继续,该系统响应于接收到的管理工具请求来报告所收集的和经统一的管理数据。该系统可通过从中接收到请求的接口或通过通知接口或用于向工具提供数据的其他设施,来发送该数据。在框370之后,这些步骤结束。
[0043]图4是示出在一个实施例中云管理系统的用于从远程应用实例的位置处报告回数据并在远程应用实例的位置处处理故障查找请求的处理的流程图。在框410中开始,该系统接收对来自应用的客户机的请求所生成的负载的一部分进行处理的远程应用实例处的管理数据。管理数据可包括性能数据、日志信息、出错详细信息、统计信息、销售历史、或对管理该应用有用的应用操作的其他指示。
[0044]在框420中继续,该系统确定该应用的在其中管理员可访问该应用的在各分布式远程位置处运行的多个实例所报告的管理数据的本地位置。在应用实例创建后,该实例可从本地位置接收指定可在何处联系本地位置以及该应用实例是该应用的远程实例的配置信息。该系统可将各应用迁移到多个位置以处理峰值负载、在处理离开峰值并且因而较便宜的位置处执行低优先级任务,或出于管理员所确定的其他原因。该应用可具有该应用在其中正常运行的本地位置,并且可在一个或多个分布式远程位置处处理峰值或其他负载。
[0045]在框430中继续,该系统将接收到的管理数据从远程应用实例发送到该应用的所确定的本地位置。该系统可将在各分布式实例处生成的数据周期性地迁移回本地位置,使得管理数据在该本地位置处一个位置中可用,以方便管理员和管理工具。该系统还可按需或在各工具请求时(参见例如图3)迁移数据。在一些情况下,该系统可在短期内将应用负载爆发到远程位置,并随后在负载被迁移回本地位置并且远程实例结束时收集与该应用的执行有关的信息。
[0046]在框440中继续,该系统可任选地从在本地位置处运行的管理工具接收故障查找请求以对远程应用实例进行故障查找。故障查找请求可包括调试断点、对详细跟踪信息的请求、或者用于执行故障查找动作的其他命令或请求。
[0047]在框450中继续,该系统响应于接收到的故障查找请求来执行一个或多个故障查找动作。该动作可包括设置调试断点、上调日志水平、向该应用发送测试数据、或执行该请求所指定的用于确定该应用是否正确地操作的任何其他动作。
[0048]在框460中继续,该系统响应于接收到的故障查找请求来将故障查找结果发送到本地位置。通过提供用于远程地执行故障查找命令的设施,该系统允许在本地位置处操作的故障查找工具对各应用实例进行故障查找而不管各实例在何处运行,并且允许该系统将该应用的各实例无缝地迁移到各位置而不中断管理员对该应用进行管理和故障查找的能力。在框460之后,这些步骤结束。
[0049]在一些实施例中,云管理系统通过修改域名服务(DNS)记录来来迁移应用负载。该系统可以修改DNS服务器以将传入客户机请求指向一个或多个新目的地网际协议(IP)地址,以便引导负载从源数据中心离开而到达目标数据中心/云。全局流量管理器(GTM)通常将客户机指向最近的服务器以处理其请求,并且这些方案可被修改以基于负载或其他条件来重定向流量。由此,当一个数据中心变得过载或接近容量时,该系统可以通知GTM将至少一些客户机请求引导至可处理该过量负载的新位置。类似地,该系统可以提供管理工具可向其寄送管理请求的且连接到各应用实例(而不管它们位于何处)的DNS或其他地址。
[0050]在一些实施例中,在迁移条件减轻之后,云管理系统将日志和其他数据从目标计算资源迁回。例如,在一段峰值负载之后,该系统可以将所有的应用负载迁回原始数据中心,并且将目标数据中心处所生成的信息(诸如,应用日志)拉回原始数据中心以供稍后分析。对于一些应用,跟踪客户机请求可能是规章顺应性问题或仅对调试和报告有用。在任一种情况下,在源位置处合并这些日志可能是成功迁回源位置的一部分。
[0051]在一些实施例中,云管理系统在源计算资源与一个或多个目标计算资源之间动态地分配可变的应用负载量。例如,该系统可以动态地路由请求以使源计算资源保持在全容量或接近全容量,而仅将源计算资源不能成功地处理的请求发送至外部计算资源。这样的决定可以是成本、数据安全或其他考虑的问题,以迁出仅仅所需的应用负载或者将应用负载放置在能最便宜地或最高效地执行它们的地方。在一些情况下,决定可以基于各应用的规章要求。例如,服从保健或其他记录法律的应用可具有与它们可在其中操作的数据中心/ Z?有关的约束。
[0052]在一些实施例中,云管理系统提供灾难恢复的各种选项。在一些情况下,该系统可以使外部数据中心处的资源加入,以监视主数据中心断供。如果外部数据中心变得不能联系到主数据中心,则外部数据中心可以确定发生了灾难并且将应用负载移至外部数据中心。在过去的系统中,组织维护200%的所需容量(以大量花费)以便成功地处理灾难是典型的。使用该云管理系统,组织可以将较少量的可用容量维持在第二位置处(例如,10%),并且在发生故障的情况下可以按需迅速地请求更多。与保险很相似,云提供者的所有客户机同时发生故障并且请求高容量备用的可能性是低的,使得多个客户机可以共享要在主要资源发生故障的情况下使用的一组冗余的辅助资源。该系统还可在灾难恢复之后重新确定管理工具和故障查找资源的本地位置以指向新位置,使得管理继续是未中断的。
[0053]从前面的描述中将明白,云管理系统的各特定实施例在本文中只是为了说明的目的进行了描述,但是在不偏离本发明的精神和范围的情况下,可以进行各种修改。因此,本发明只受所附权利要求限制。
【权利要求】
1.一种计算机实现的用于处理来自管理工具的访问来自各分布式应用实例的应用管理数据的请求的方法,所述方法包括: 从应用管理工具接收访问与在一个或多个数据中心中运行各实例的应用有关的管理数据的请求; 标识满足所接收到的请求的一个或多个类型的管理数据; 确定包括所述应用的两个或更多个实例的应用分布; 从每一分布式应用实例收集用于满足所述请求的管理数据; 统一所收集的数据以提供对接收到的管理工具请求的统一响应;以及 响应于所接收到的管理工具请求来报告所收集的和经统一的管理数据, 其中前述步骤由至少一个处理器来执行。
2.如权利要求1所述的方法,其特征在于,接收所述管理请求包括通过展示给工具的用于请求管理数据的程序性应用编程接口(API)来接收所述工具请求。
3.如权利要求1所述的方法,其特征在于,所述API包括用于访问管理数据而无需工具理解各应用实例在何处运行或在多少位置处运行的统一接口。
4.如权利要求1所述的方法,其特征在于,接收所述管理请求包括从性能监视工具接收访问描述一个或多个应用实 例的操作的状态信息的请求。
5.如权利要求1所述的方法,其特征在于,标识各类管理数据包括确定所述请求要求所述应用的每一实例所产生的信息。
6.如权利要求1所述的方法,其特征在于,标识各类管理数据包括确定从每一应用实例收集哪些信息以及所述数据是否已经在本地从由每一应用实例推送到中心位置的数据中进行了收集。
7.如权利要求1所述的方法,其特征在于,确定所述应用的分布包括确定所述应用在何处运行以及所述系统将在何处找到用于满足所述请求的管理数据。
8.如权利要求1所述的方法,其特征在于,收集管理数据包括访问私有数据中心中的至少一个实例和云计算设施中的至少一个实例。
9.如权利要求1所述的方法,其特征在于,收集管理数据包括联系所述应用的每一实例以满足接收到的管理工具请求。
10.如权利要求1所述的方法,其特征在于,还包括向一个或多个远程应用实例发送一个或多个故障查找命令,其中所述远程应用实例执行所述故障查找命令并将所请求的数据报告回所述管理工具能访问所述信息的中心位置。
11.如权利要求1所述的方法,其特征在于,统一所收集的数据包括将数据格式化以使得管理工具不必被编写成包括对所述工具所管理的应用的各种可能的分布的理解。
12.如权利要求1所述的方法,其特征在于,统一所收集的数据包括将数据格式化以使得所述系统能按需将所述应用从一个位置自由地迁移到一个或多个位置以处理应用负载,同时仍然向管理员提供一致的管理和故障查找体验。
13.如权利要求1所述的方法,其特征在于,报告所述数据包括通过在其上接收到所述请求的接口来将所述数据发送到所述管理工具。
14.一种用于跨云管理和故障查找的跨云计算的计算机系统,所述系统包括: 被配置成执行包含在以下组件内的软件指令的处理器和存储器;位置管理组件,所述位置管理组件管理与应用的各实例在其中运行的多个数据中心位置有关的信息; 位置数据存储,所述位置数据存储存储描述所述应用的各实例在其中运行的各位置的信息; 工具接口组件,所述工具接口组件向所述系统提供接口,一个或多个工具通过所述接口能访问所述应用的管理和故障查找信息; 一个或多个管理工具,所述一个或多个管理工具连接到所述工具接口组件以访问管理信息或执行应用故障查找; 数据迁移组件,所述数据迁移组件将所述应用在其中运行的一个或多个远程位置处的管理信息迁移回所述应用的本地位置;以及 故障查找组件,所述故障查找组件在一个或多个位置处对所述应用执行一个或多个故障查找任务。
15.如权利要求14所述的系统,其特征在于,所述工具接口组件提供初始连接点以供各工具访问与位于企业的私有数据中心内的云计算设备处的应用有关的信息。
【文档编号】G06F15/16GK103548009SQ201280024366
【公开日】2014年1月29日 申请日期:2012年5月18日 优先权日:2011年5月20日
【发明者】K·C·艾耶, E·B·沃森 申请人:微软公司

最新回复(0)