CN107710683A - 弹性即服务 - Google Patents

Abstract

本文中公开的系统和方法涉及创建在系统上运行的服务的依赖关系的服务目录，其中第一服务的实例依赖于第二服务的实例。依赖关系的目录包括与服务之间的连接相关联的元数据。该系统注入针对所有级别的依赖关系的故障。监测该系统，以检测由故障产生的失效。所注入的故障选自传输层故障、存储器压力、处理器压力、存储装置压力、虚拟机重启和虚拟机关闭。监测域名服务，以标识为这些服务解析的名称。然后使用与所解析的名称相关的信息、利用附加依赖关系连续地更新服务目录。可以以有引导的方式注入故障，其中故障的范围随着时间逐步增加，以标识系统中的失效点。

Description

弹性即服务

背景技术

现在很常见的是，大量软件应用在包括分布式服务器网络的云平台上或者在本地企业数据中心上作为服务来运行。对这些服务的要求是要保持对客户和租户的高度可用性。由于基于云的应用的分布式性质以及这些服务的部件之间的重要的相互依赖关系，满足这个要求是一个复杂的问题。

用于测试数据中心中的服务的可用性的常用方法是手动创建服务的故障模型，并且然后分析各种部件失效的影响。这种方法有几个缺点。如果功能、架构和/或依赖关系经常变化，则创建准确的故障模型需要花费时间并且会变得过于昂贵。当很多因素影响复杂的分布式系统的功能时，手动创建的故障模型可能会遗漏这些因素的很多组合。人为错误以及缺乏关于每个部件的所有依赖关系的知识可能会导致客户影响较大的重要失效无法被包括在故障模型中。另外，针对不经常更新的不同部件而独立创建的故障模型可能无法检测到单独的服务之间的新的依赖关系，并且很可能会错过很多失效情况。

因此，由于现代软件的快速发展和部署使得新的依赖关系在不知不觉中被添加和移除，上述方法变得不实用。

发明内容

提供发明内容部分是为了以简化的形式介绍将在以下具体实施方式部分中进一步描述的一些概念。发明内容部分无意标识所要求保护的主题的关键特征或重要特征，也无意限制所要求保护的主题的范围。

现有系统的故障注入方法使用专注于使待测试机器发生故障的强力和粗糙过程。然而，在现实世界中，故障本质上并不全是布尔形式的(即故障更复杂，无论部件运行还是发生故障)。不能通过仅仅使选定部件失效来测试或评估瞬态和退化的故障。本文中公开的实施例提供了有针对性的精确故障注入，其允许自动引入真实世界的瞬态降级。

实施例提供了系统和方法，其允许开发者和服务提供者在任何给定时刻获得服务的部件之间的依赖关系的精确图或映射，以获知依赖关系的类型以及获知失效部件可能会对使用该服务的客户的影响。

本文中公开的系统和方法涉及创建在系统上运行的服务的依赖关系的服务目录，其中第一服务的实例依赖于第二服务的实例。依赖关系的目录包括与服务之间的连接相关联的元数据。该系统注入针对所有级别的依赖关系的故障。监测该系统，以检测由故障产生的失效。所注入的故障选自包括以下各项的有限故障集合：传输层故障、存储器压力、处理器压力、存储装置压力、虚拟机重启和虚拟机关闭。监测域名服务，以标识为这些服务解析的名称。然后使用与所解析名称相关的信息、利用附加依赖关系连续地更新服务目录。可以以有引导的方式注入故障，其中故障的范围随着时间逐步增加，以标识该系统中的失效点。

附图说明

为了进一步阐述本发明实施例的上述以及其他优点和特征，将参考附图对本发明的实施例进行更具体的描述。可以理解，这些附图仅描绘了本发明的典型实施例，并且因此不应当被认为是对其范围的限制。将通过使用附图，以更多特征和细节来描述和解释本发明，在附图中：

图1是提供云计算服务或分布式计算服务的示例数据中心100的高级框图。

图2是示出根据一个实施例的服务目录的创建和更新的框图。

图3是示出根据一个实施例的故障注入的框图。

图4是用于测试服务、网络或计算系统的弹性的系统的简化图。

图5图示了服务依赖关系的示例图。

图6是示出用于评估系统的弹性的方法的流程图。

具体实施方式

图1是提供云计算服务或分布式计算服务的示例数据中心100的高级框图。多个服务器101由数据中心管理控制器102管理。负载均衡器103将请求和工作负载分布在服务器101上，以避免单个服务器变得不堪重负的情况并且使数据中心100中的资源的可用容量和性能最大化。路由器/交换机104支持服务器101之间的数据通信以及数据中心100与外部资源和用户之间的经由外部网络105的数据通信，外部网络105可以是例如局域网(LAN)或因特网。

服务器101可以是独立的计算设备，和/或它们可以被配置为很多服务器设备的机架中的单独的刀片(blade)。服务器101具有管理与其他数据库实体的通信的输入/输出(I/O)连接器106。每个服务器101上的一个或多个主机处理器107运行主机操作系统(O/S)108，该主机操作系统(O/S)108支持多个虚拟机(VM)109。每个VM 109可以运行自己的O/S，使得服务器上的每个VM O/S 110不同或相同或是两者的组合。VM O/S 110可以是例如相同O/S的不同版本(例如，不同VM运行操作系统的不同的当前版本和旧版本)。附加地或备选地，VM O/S 110可以由不同的制造商提供(例如，一些VM运行操作系统，而其他VM运行操作系统)。每个VM 109然后可以运行一个或多个应用(App)111。每个服务器101还包括可以由主处理器107和VM 109访问和使用的存储装置112(例如，硬盘驱动器(HDD))和存储器113(例如，RAM)。

数据中心100提供池化资源，客户或租户可以根据需要在这些资源上动态地提供和缩放应用，而不必增加更多的服务器或附加的网络。这允许租户获得所需要的计算资源，而无需在每应用、自组网的基础上采购、提供和管理基础架构。云计算数据中心100允许租户动态地扩展或缩减资源以满足当前业务需求。此外，数据中心运营商可以向租户提供基于使用情况的服务，以便在他们需要使用资源时仅支付他们使用的资源。例如，租户可以最初使用服务器101-1上的一个VM 109来运行他们的应用111。当需求增加时，数据中心100可以根据需要激活同一服务器101-1上和/或新服务器101-N上的附加VM 109。如果之后需求下降，这些附加VM 109可以被停用。

数据中心100可以提供有保证的可用性、灾难恢复和备份服务。例如，数据中心可以将服务器101-1上的一个VM 109指定为租户的应用的主要位置，并且在第一VM或服务器101-1失效的情况下，可以激活相同或不同服务器上的第二VM 109以作为备用或备份。数据库管理器102将传入的用户请求从主VM自动转移到备份VM，而不需要租户介入。虽然数据中心100被图示为单个位置，但是将理解，服务器101可以被分布到全球的多个位置以提供附加冗余和灾难恢复能力。此外，数据中心100可以是向单个企业用户提供服务的本地私有系统、或者可以是向多个不相关的客户和租户提供服务的公共可访问的分布式系统、或者可以是两者的组合。

域名系统(DNS)服务器114将域名和主机名称解析为数据中心100中的所有角色、应用和服务的IP地址。DNS日志115维护关于哪些域名已经按角色被解析的记录。应当理解，本文中使用DNS作为一个示例，并且可以使用其他名称解析服务和域名记录服务来标识依赖关系。例如，在其他实施例中，可以是IP或分组嗅探、代码插装或代码追踪。

数据中心健康监测116监测数据中心100中的物理系统、软件和环境的健康状况。当数据中心100中的服务器、刀片、处理器或应用被检测到问题时或者当出现网络带宽或通信问题时，健康监测116向数据中心管理器提供反馈问题。

本文中公开的实施例降低了与构建和维护数据中心100的部件之间的依赖关系的图或映射相关联的成本，并且在一个或多个部件以各种方式失效的情况下整体提高对系统的影响的理解。这种方法使所有手动操作几乎最小化为零，因此使人为错误的风险最小化。该问题可能分为两大部分。首先，系统中的所有依赖关系都会被自动发现并且始终保持最新状态。其次，具有可变参数的有限数目的故障自动并且定期被注入到所有依赖关系和连接中。现有的监测工具被用来测量所注入的故障的影响。

服务目录

系统中的所有服务的目录或图被自动创建并且保持始终最新。服务目录包含服务之间的依赖关系图，并且包括关于服务和连接的附加元数据。目录为系统中的每个服务或角色标识角色类型以及与该角色通信的所有端点。例如，该目录可以标识诸如存储、认证、监测等服务或角色。通信的类型例如包括紧耦合与宽松耦合、超文本传输协议(HTTP)、HTTP安全(HTTPS)或者任何其他通信协议。附加信息和元数据可以由服务所有者输入，但是服务目录始终是最新的。服务目录可用于由其他应用使用。当依赖关系发生变化时，可能会通知受影响的服务的所有者。

图2是示出根据一个实施例的服务目录的创建和更新的框图。依赖关系图创建器/更新器201从DNS日志202接收输入，其可以是由以下DNS服务器创建的日志，该DNS服务器正在解析该系统中正被分析的角色的名称和地址。DNS日志202可以标识例如与该系统中的每个角色或服务通信的端点。每次一个名称被解析时，这指示一个服务或角色正在与该端点通信，DNS服务器上的监测代理可以更新DNS日志202。另外，服务开发者可以提供输入203，诸如对于特定服务或关于服务的元数据的已知依赖关系。依赖关系图创建器/更新器201创建可用于外部应用、诸如故障注入应用等的服务目录204。

故障注入系统

故障注入系统用于将有限数目的公知的故障引入到系统中。系统的健康监测服务用于检测这些故障的影响。能够被注入的故障类型包括例如传输层(OSI参考模型层4)故障、存储器压力、处理器压力、存储装置/硬盘驱动器压力、VM重启和VM关闭。这些故障通过各种参数而定期被注入到由服务目录发现的依赖关系和连接中。

简单监测捕获了内部服务级别协议(SLA)违规，并且被用于检测所注入的故障的影响。注入可以在所有级别的依赖关系下执行，这在当前工具中通常被遗漏，因为完整的依赖关系图不是最新的并且对于复杂的系统而言几乎是难以获知的。

使用所提出的方法，预期只需要几个小时就可以安装和配置服务目录和故障注入系统。一旦完成，开发和运行该系统的工程师将拥有清晰可靠的系统依赖关系图、以及该系统的弹性和可用性级别。服务可以被应用到任何环境，包括私有云和公共云服务、数据中心和在本地运行的服务。

图3是示出根据一个实施例的故障注入的框图。系统故障由故障注入服务301施加。要注入的故障的类型和故障注入的时间基于服务目录302来选择。服务目录提供角色列表以及所有它们各自的依赖关系，包括与每个角色交互的所有端点。使用这些信息，将不同的故障注入到系统中。

在一个实施例中，注入两个主要类别的故障。一类涉及网络连接，由此通过断开或延迟从服务目录中选择的角色和端点之间的通信303来引入错误。另一类涉及角色实例，由此基于角色实例的类型注入故障。这些故障诸如通过注入存储器压力304、处理器压力305等而特定于角色类型。故障被注入到角色实例上、或者被注入用于角色实例、或者被注入到角色所依赖的通信链路上。

例如，存储器压力可以被施加到角色实例，以去除50％的角色实例的80％的存储器。因此，故障注入301将所选择的角色实例的一半的可用存储器减少了80％。健康监测服务然后检测故障的结果，并且该角色被评估是否具有弹性、是否正确检测到这个问题、是否正确缓解该问题，等等。

故障可以以几种方式被注入给角色。不同的策略可以用于为不同类型的角色注入故障。例如，可以以确定性的、随机的或有引导的方式注入故障。

确定性故障注入涉及用已知故障参数来注入已知故障。例如，对于网络通信，网络故障可以被注入为以毫秒为单位的预先选择的延迟，或者处理器压力故障可以作为预先选择的负载被注入到已知数目的处理器(例如，80％的负载)上。

随机故障注入涉及针对随机数目的角色注入随机数目的故障。

有引导的故障注入涉及针对所选择的数目的部件或实例注入所选择的故障，并且然后稳定地增加故障的范围(例如，增加部件数目、角色数目、压力量、延迟量等)，直到检测到失效。例如，可以注入一个处理器故障，其中50％的处理器压力被施加到单个机器，并且因此受影响的机器数目稳定地增加到2、4、8…个机器，直到检测到失效。在这样的有引导或确定性的故障注入中，受影响的角色或机器的数目、压力量或其他参数稳定地增加，直到标识出目标服务或角色的突破点。此外，当接近并且最终达到断点时，可以观察服务对该故障的反应(即如何标识和缓解该故障)。

参考图4，示出了用于测试服务、网络或计算系统的弹性的系统的简化图。系统401支持多个主机处理器402。系统401可以是单独的服务器或刀片、或者可以表示多个分布式部件。主机处理器402根据需要访问硬盘驱动器(HDD)存储装置403和随机存取存储器(RAM)404，以读取/写入数据和软件指令。系统401可以经由网络405、通过输入/输出(I/O)连接器406与其他部件通信。网络405可以是任何公共网络或专用网络，诸如因特网、内联网、广域网(WAN)、局域网(LAN)等。

主机操作系统(O/S)407运行在主机处理器402上并且支持运行VM O/S 409的VM408。服务410的一个或多个实例在VM408上运行。服务实例410可以与相关服务实例410通信或者与在其他VM 408上或在经由网络405访问的远程服务器上运行的其他服务(未示出)通信。

健康监测管理器411是被配置为观察系统401的操作并且经由终端412将操作状态信息报告给诸如服务提供商、租户或客户等用户的应用。故障注入管理器413是将故障注入到系统401中的应用。故障注入管理器413可以使用服务目录414来确定要注入哪些故障。终端412可以提供到故障注入管理器413的接口，用于监测和/或配置被注入到系统401中的故障。健康监测管理器411和/或故障注入管理器413可以是在系统401上或在单独的部件上运行的服务。

健康监测管理器411例如可以是检测系统401中的失效的事件管理系统。在检测到失效时，事件管理系统可以在终端413上发出警报，这可能成为一个事件。当观察到失效并且达到指定的事件级别时，可以停止故障注入，从而服务提供商可以调查该失效并且纠正系统和/或服务对该故障的响应。

系统401可以是测试环境，该测试环境具有与在现场系统中发现的相同的硬件和服务依赖关系。在现场系统上引入服务之前，该服务对故障注入的反应将在测试环境中被评估。备选地，系统401可以表示生产环境的测试片段，该测试片段已经被隔离以应用服务评估并且不支持实时业务。

使用服务目录414，在观察到一个服务中的失效之后，服务提供者可以标识对发生故障的服务具有依赖关系或者具有到发生故障的服务的连接的其他服务。这允许服务提供商确定其他服务如何受特定服务的失效的影响。服务目录提供与哪些其他服务可能受这个特定服务的失效影响有关的指导。服务目录提供依赖关系的目录。使用这个目录，可以在多个级别评估失效的影响。例如，可以验证故障在从依赖关系目录中标识出的多个依赖关系级别上具有级联影响。

当故障被注入到系统中时，检测失灵或故障。如果失灵足够持久或足够大，则失灵可能会上升到错误的水平。如果失灵确实变成错误，则该系统将尝试处理这个错误。如果错误未被恰当处理或未被解决，则它将变成失效，这是系统或服务的不期望的行为。由故障注入管理器413注入到系统中的故障预期会变为失效，从而可以标识服务的断点。健康监测管理器411的目的是在系统异常或停机时标识这样的失效。

图5示出了服务依赖关系500的示例图。服务A依赖于服务B和C两者。服务C依赖于服务D，这表示服务A间接地依赖于服务D。服务A-D可以在系统401中的各种主机处理器402上运行。例如，服务A可以是依赖于通信服务B和存储服务C的VM服务。存储服务C还可以依赖于高速缓存服务D。角色A-D之间的服务依赖关系500可以基于DNS调用而被确定和映射，以解析用于在这些角色之间调用的名称和地址。

当故障被注入到系统中时，服务D可能最终失效，这将由健康监测管理器411检测到。一旦检测到失效，故障注入管理器413将停止注入故障，使得失效的影响可以被评估。服务D的失效会影响服务C，而不影响服务B。例如，如果高速缓存服务D失效，则存储服务C会受到影响，但是通信服务B不会受到影响。VM服务A也将间接地受到服务D的失效的影响。使用服务目录映射，可以确定服务D失效对其他服务A-C的影响，即在多个依赖关系级别上的级联失效。

图6是示出用于评估系统的弹性的方法的流程图。在步骤601中，为在系统上运行的服务创建依赖关系的服务目录，其中第一服务的实例依赖于第二服务的实例。依赖关系目录还包括与服务之间的连接相关联的元数据。在步骤602中，向系统中注入故障。故障被选择为针对系统中的所有级别的依赖关系。所注入的故障可以从有限的故障集合中选择，例如包括传输层故障、存储器压力、处理器压力、存储装置压力、虚拟机重启和虚拟机关闭。故障可以以有引导的方式被注入，其中故障的范围随着时间逐步增加，以标识系统中的失效点。例如，所注入的故障可以与相关服务之间的通信相关联，或者可以涉及角色实例。

在步骤603中，监测系统以检测由故障产生的失效。在步骤604中，标识系统失效。在步骤605中，停止故障注入。在步骤606中，标识与所注入的故障相关联的服务。

一种示例系统包括：运行两个或更多个服务的实例的至少一个处理器，其中第一服务的实例依赖于第二服务的实例。故障注入管理器被配置为在系统中引入故障诱导条件。健康监测管理器被配置为检测系统中的失效。故障注入管理器还被配置为当故障诱导条件引起第二服务的实例失效时，将第一服务标识为易受故障诱导条件的影响。有利的是，故障注入管理系统通过自动标识和测试被监测系统中的所有依赖关系来提高被监测系统的可靠性。

该系统还可以包括被配置为标识服务实例之间的依赖关系的依赖关系图管理器。例如，依赖关系图管理器可以被配置为使用目录名称服务、IP嗅探、分组嗅探、代码插装或代码追踪来标识服务实例之间的依赖关系。在目录名称服务中被解析的名称可以被存储到目录名称服务日志。依赖关系图管理器可以被配置为通过实时地分析已经在目录名称服务中已经被解析的名称来连续地更新服务实例依赖关系。

例如，可以从传输层故障、存储器压力、处理器压力、存储装置压力、虚拟机重启和虚拟机关闭中选择故障诱导条件。故障注入管理器可以被配置为通过增加故障诱导条件直到失效发生，以有引导的方式引入故障诱导条件。

一种用于测试系统的弹性的示例方法包括：为在系统上运行的服务创建依赖关系的服务目录，其中第一服务的实例依赖于第二服务的实例，依赖关系的目录还包括与服务之间的连接相关联的元数据；在系统中注入故障，故障针对所有级别的依赖关系；以及监测系统以检测由故障产生的失效。

所注入的故障可以选自有限的故障集合。有限的故障集合例如可以包括传输层故障、存储器压力、处理器压力、存储装置压力、虚拟机重启和虚拟机关闭。

示例方法还可以包括监测域名服务以标识服务的解析名称；并且使用与解析名称有关的信息、利用附加依赖关系来更新服务目录。

示例方法还可以包括以有引导的方式注入故障，其中故障的范围随着时间逐步增加以标识系统中的失效点。这些故障可以在所有级别的依赖关系下被注入。

示例方法还可以包括：标识系统失效；停止故障注入；并且标识与所注入的故障相关联的服务。所注入的故障可以与相依赖的服务之间的通信相关联。注入的故障可以涉及角色实例。

另一示例系统可以包括：处理器；以及包含程序的存储器，该程序当在处理器上被执行时执行用于标识系统故障状况的影响的操作，该操作包括：为在系统上运行的服务创建依赖关系的服务目录，其中第一服务的实例依赖于第二服务的实例，依赖关系的目录还包括与服务之间的连接相关联的元数据；在系统中注入故障，故障针对所有级别的依赖关系；以及监测系统以检测由故障产生的失效。所注入的故障可以从传输层故障、存储器压力、处理器压力、存储装置压力、虚拟机重启和虚拟机关闭中选择。该操作还可以包括监测域名服务以标识服务的解析名称；并且使用关于解析名称的信息、利用附加依赖关系来更新服务目录。该操作还可以包括以有引导的方式注入故障，其中故障的范围随着时间逐步增加，以标识系统中的失效点。

在一些实施例中，程序可以在计算机可读介质(CRM)上，这样的计算机可读介质排除了传播信号。计算机可读介质可以是可以由计算机访问的任何可用介质，并且包括易失性和非易失性介质以及可移除和不可移除介质，但是排除传播信号。作为示例而非限制，计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储器、磁带盒、磁带、磁盘存储器或其他磁存储设备或者可以用于存储所需信息并且可以由计算机访问的任何其他介质。通信介质通常以诸如载波或其他传输机制等调制数据信号来体现计算机可读指令、数据结构、程序模块或其他数据，并且包括任何信息传递介质。术语“调制数据信号”是指一个或多个特征以使得能够在信号中对信息进行编码的方式来被设置或改变的信号。作为示例而非限制，通信介质包括诸如有线网络或直接有线连接等有线介质、以及诸如声学、RF、红外线和其他无线介质等无线介质。以上任何的组合也可以被包括在计算机可读介质的范围内。计算机可读介质可以被体现为计算机程序产品，诸如存储在计算机存储介质上的软件。

尽管已经用对结构特征和/或方法动作特定的语言来描述本主题，但是应当理解，在所附权利要求中限定的主题不一定限于上文描述的具体特征或动作。相反，上述的具体特征和动作被公开为实现这些权利要求的示例形式。

Claims (15)

1.一种系统，包括：

至少一个处理器，运行两个或更多个服务的实例，其中第一服务的实例依赖于第二服务的实例；

故障注入管理器，被配置为在所述系统中引入故障诱导条件；

健康监测管理器，被配置为检测所述系统中的失效；以及

其中所述故障注入管理器还被配置为在所述故障诱导条件引起所述第二服务的实例失效时，将所述第一服务标识为易受所述故障诱导条件的影响。

2.根据权利要求1所述的系统，还包括：

依赖关系图管理器，被配置为标识服务实例之间的依赖关系。

3.根据权利要求2所述的系统，其中所述依赖关系图管理器被配置为使用目录名服务、IP嗅探、分组嗅探、代码插装或代码追踪来标识服务实例之间的依赖关系。

4.根据权利要求2所述的系统，其中已经在目录名服务中被解析的名称被存储到目录名服务日志。

5.根据权利要求2所述的系统，其中所述依赖关系图管理器被配置为通过实时地分析已经在所述目录名服务中被解析的名称来连续地更新所述服务实例依赖关系。

6.根据权利要求1所述的系统，其中所述故障诱导条件选自包括以下的组：

传输层故障、存储器压力、处理器压力、存储装置压力、虚拟机重启和虚拟机关闭。

7.根据权利要求1所述的系统，其中所述故障注入管理器被配置为通过增加所述故障诱导条件直到失效发生，以有引导的方式引入所述故障诱导条件。

8.一种方法，包括：

为在系统上运行的服务创建依赖关系的服务目录，其中第一服务的实例依赖于第二服务的实例，所述依赖关系目录还包括与所述服务之间的连接相关联的元数据；

在所述系统中注入故障，所述故障针对所有级别的所述依赖关系；以及

监测所述系统以检测由所述故障产生的失效。

9.根据权利要求8所述的方法，其中所注入的所述故障选自有限的故障集合。

10.根据权利要求9所述的方法，其中所述有限的故障集合包括：

传输层故障、存储器压力、处理器压力、存储装置压力、虚拟机重启和虚拟机关闭。

11.根据权利要求8所述的方法，还包括：

监测域名服务，以标识所述服务的解析名称；以及

使用关于所述解析名称的信息，利用附加依赖关系来更新所述服务目录。

12.根据权利要求8所述的方法，还包括：

以有引导的方式注入所述故障，其中所述故障的范围随着时间逐步增加，以标识所述系统中的失效点。

13.根据权利要求8所述的方法，其中所述故障在所有级别的所述依赖关系下被注入。

14.根据权利要求8所述的方法，还包括：

标识系统失效；

停止所述故障注入；以及

标识与所注入的故障相关联的服务。

15.根据权利要求8所述的方法，其中所注入的所述故障与相依赖的服务之间的通信相关联。