Download PDF version of this article PDF

新管理层

自治计算正在彻底改变我们管理复杂系统的方式。

DUNCAN JOHNSTON-WATT，ENIGMATEC

在全球竞争日益激烈的环境中，企业面临着降低运营成本的巨大压力。与此同时，它们必须具备快速响应动荡市场带来的商机的敏捷性。

利用 IT 获得竞争优势对于公司的成功至关重要，而最大限度地利用其 IT 基础设施对于降低成本至关重要。此外，构建能够处理峰值活动并提供充分的业务连续性备份的系统是一项先决条件，这会增加资本成本和运营成本。

实施共享 IT 基础设施或服务网格，使 IT 资源能够动态地提供，以满足不同业务部门的需求，这对 CIO 来说是一个引人注目的业务主张。然而，实际实施这种架构具有挑战性，而且通常与其运营相关的管理开销会抵消任何资本成本的节省。

一种解决方案是采用我们称之为高效计算架构的方法，它结合了 24/7 全天候运营这种服务网格所需的必要配置、虚拟化和自动化组件。

在本文中，我们重点关注管理服务网格中运行的应用程序的自动化组件。此组件通常被称为 EMS（执行管理系统）。它使面向业务的需求（如服务级别目标）能够映射到业务流程或策略，这些流程或策略在硬件、操作系统和应用程序堆栈级别协调 IT 资源。

我们研究了我们使用 POM（面向流程的中间件）平台构建的 EMS 实现的基础知识及其与自治计算的关系。POM 是 MOM（面向消息的中间件）的下一代。MOM 虚拟化数据分发，而 POM 虚拟化流程执行，优化业务流程或在本例中为运营流程在高度分布式计算环境中的执行。

服务网格

当今全球企业 CIO 面临的主要挑战是在支持一个不断变化且受到日益严格的监管审查的环境的同时，最大限度地利用其 IT 资源。他们的任务是降低其 IT 基础设施的总拥有成本——在全球竞争日益激烈和贸易利润率不断下降的世界中，这是一项业务迫在眉睫的任务——与此同时，市场波动性加剧，商业机会和客户需求瞬息万变，运营弹性至关重要。

实施企业级 IT 平台的要求可以通过以下特征来指定

• 利用率——最大限度地利用 IT 资源，包括服务器、存储和网络带宽，同时承认必须提供适当的运营弹性和隔离（其参数可能由行业监管机构指定和强制执行）。

• 敏捷性——动态地调整 IT 资源的用途，以满足跨多个时区运营的多个业务线不断变化的需求，同时适当关注公司的整体业务优先级。

• 可扩展性——动态配置 IT 资源以满足公司整体业务不断变化的需求，确保提供适当的 IT 资源，但不会浪费。

传统上，各个业务线都拥有自己的 IT 平台，确保资源随时可用以满足峰值工作负载并支持故障转移条件。虽然这种方法满足了对 IT 资源的随时需求，但在利用率方面效率低下，并且在企业级别缺乏灵活性和可扩展性。实际上，IT 资源通常保持空闲或几乎未被利用，给公司带来巨大成本。

为了实现经济高效的 IT 资源配置方法，公司正在寻求构建共享基础设施，利用行业标准硬件组件（如刀片服务器和对称多处理集群），这些组件能够支持多种异构操作系统（例如，Linux、Solaris、Microsoft Windows）和应用程序环境。

这些共享基础设施或服务网格被动态地分区和分配，以满足多个业务线在 IT 资源需求变化时的需求。服务网格内的 IT 组件根据任何给定时间应用程序组合的需求进行电源开启和关闭以及用途调整。

然而，为了使这种服务网格架构可行，需要管理功能来仲裁资源冲突并确定跨业务线及其应用程序环境的优先级。此外，这些优先级不能被视为静态参数，并且可能会根据业务需求和其他因素（如一天中的时间）而变化。

支撑此管理功能的是一组要求或 SLA（服务级别协议），这些协议指定了业务线所需的 IT 资源以及他们维护的特定应用程序。服务网格管理功能会查阅这些 SLA，并将其映射到企业级别业务部门强制执行的一组优先级，以确定在任何时间以尽力而为为基础分配哪些资源。

高效计算架构

服务网格管理功能在无需操作员干预的情况下，通过实施服务级别自动化来优化 IT 资源的动态利用率。在这种情况下，EMS 的作用是在策略驱动的管理的支持下提供此服务级别自动化。EMS 可以被认为是将典型企业 IT 基础设施中找到的所有组件绑定在一起的粘合剂

这创建了整体高效计算架构，如图 1.1 所示

从业务经理的角度来看，EMS 通常配置为管理应用程序级别、业务线级别和服务网格级别的资源。在每个级别，对 IT 资源的需求都会通知给层次结构中的下一级别。

为了交付企业级闭环解决方案，EMS 需要与图 2 中显示的所有组件集成。为了有效地检测和管理这些组件，EMS 需要是分布式的。我们的方法是使用 POM 平台来实现此目的。

可以将在 IT 基础设施的某些方面定义管理的策略建模为一组由各种场景触发的工作流或运营流程，其中运营流程是运营域中的业务流程。POM 平台虚拟化流程执行，优化这些流程在高度分布式计算环境中的运行时执行。它通过分析这些流程并将其分解为组成部分来实现此目的，然后将这些组成部分部署并约束为靠近受管理资源运行。

自治计算

IBM 设想的自治计算概念2是对生物自主神经系统的有意参考，该系统自动调节生物体的心率、体温和其他核心功能。自治计算的目标是通过创建能够自我配置、自我修复、自我优化和自我保护而无需人工干预的自治计算机系统来模拟此系统。

自治计算系统由自治元素组成。这些是逻辑构造，它们监控系统的某些方面，分析其输出并采取特定操作来调整它，以便整个系统能够满足特定的业务目标，通常以 SLA 的形式表示。

自治元素是自组织的。它们可以相互发现、独立运行、根据需要协商或协作，并组织自身，以便系统整体的新兴分层管理既反映自下而上的资源需求，又反映自上而下的业务导向资源应用，以实现特定目标。

EMS 和自治计算

使用面向流程的中间件平台构建的 EMS 可以被视为自治计算系统。利用这样的平台使我们能够通过创建和部署自组织、完全冗余的 EMS 代理，将服务网格管理的复杂问题分解为组成部分，其中每个代理都是一个自治元素。

在他们的里程碑式论文《自治计算的愿景》中，Jeffrey Kephart 和 David Chess 观察到“将自治元素视为代理，将自治系统视为多代理系统清楚地表明，面向代理的架构概念将至关重要。”3 面向流程的 EMS 认识到并利用了代理和自治元素之间的这种二元性，使用自治策略驱动的管理来交付服务级别自动化。

与传统的“任务控制” IT 管理方法相比，这种方法具有显著优势，在传统方法中，事件集中关联，操作手动启动。它不仅最大限度地减少了网络流量，而且还确保在灾难恢复场景中，EMS 将继续运行，因为它是一个分布式对等系统。

实际上，如果发生网络中断，并且 IT 基础设施的一部分（如数据中心）被隔离，则面向流程的 EMS 将自动拆分为两个实例，每个实例都能够从其角度正确处理中断。例如，与隔离的数据中心关联的 EMS 实例可以启动策略，以优雅地关闭它负责的任何生产服务，因为它知道其对等方将在基础设施中其他地方的备份资源上启动这些服务。

EMS 代理是自治元素

如图 2 所示，自治元素由一个或多个受管理元素以及根据某些规则或策略管理其行为的自治管理器组成。受管理元素必须支持传感器和执行器接口。传感器接口指定受管理元素可以发出的指标，自治管理器可以监控这些指标。执行器接口指定自治管理器可以调用的操作，以更改受管理元素的行为。

在面向流程的 EMS 实现中，受管理元素可以是 EMS 代理，也可以是连接到 IT 基础设施中某些组件的 EMS 适配器。有时称为 BME（基本受管理元素），这些与 IT 资源的集成点与公共信息模型中混凝土受管理元素的概念非常相似。

在经典的自治计算中，自治管理器负责实施控制回路，通常称为闭环，它响应来自受管理元素的事件，并可能因此更改或影响它们的行为（参见图 3）。

自治管理器由四个主要功能组成，称为 MAPE（监控、分析、计划和执行）。

自治元素表示一个逻辑单元，并且可以呈现其自己的受管理元素接口，并受另一个自治管理器的自治管理。例如，想象一个负责控制系统刀片温度的自治管理器 (TempControlME)。这将与几个 BME 相关联，用于检测温度 (TempBME) 和控制温度 (FanBME)。TempControlME 将报告其在控制温度方面的相对成功或失败，并提供一种根据其他条件调节不同温度级别的方法（参见图 4）。

除了使用其传感器接口作为报告机制（例如，通过发出合成指标）之外，自治元素还可以检测到它不熟悉的情况。然后，它可以选择通过其传感器接口升级此情况。

另一个常见场景是，自治管理器无法控制或访问完成计划所需的特定资源。它可能需要升级对更多资源的请求，以某种方式识别自己，以便在这些资源可用时通过其执行器接口收到通知。相反，自治元素可以通告其服务并充当另一个自治元素的委托（参见图 5）。

在面向流程的 EMS 中，EMS 服务是自治管理器的直接模拟。它由一组关联的受管理元素和一组编码为工作流的策略构成。它还呈现其自己的传感器和执行器方法。

EMS 服务实现构成自治管理器的标准 MAPE 元素

管理服务网格

面向流程的 EMS 将管理空间视为受管理元素和自治管理器的有组织层次结构，该层次结构反映了 IT 组织的结构方式，因此升级和委托的概念是建模交互的自然方式。

例如，在投资银行中，EMS 应用程序代理管理每个机构股票应用程序，并将其资源需求发布到管理此业务部门的 EMS 业务代理。同样，管理信用衍生品和固定收益应用程序的 EMS 应用程序代理将其各自的资源需求通知给其 EMS 业务代理（参见图 6）。

EMS 应用程序代理和 EMS 业务代理都可以配置为维护一些本地余量，但资源最终归 EMS 服务网格代理所有。此代理将资源租赁给 EMS 业务代理，而 EMS 业务代理又可以将资源租赁或委托给各个 EMS 应用程序代理。

服务网格代理和业务代理的主要功能都是通过优先考虑资源分配和解决资源冲突来执行业务 SLA，并在必要时指示其域中的 EMS 代理采取行动（例如，如果确定了更高优先级的需求且短期内没有足够的备用容量来满足此请求，则让出资源）。

各个 EMS 应用程序代理的主要功能是管理其各个应用程序堆栈的横向扩展和横向缩减，并计算在其应用程序或服务在可接受的技术 SLA 范围内运行所需的资源。

EMS 服务网格代理

EMS 服务网格代理支持标准传感器/执行器接口，这有助于其与标准网络和系统监控工具或负责实施公司业务连续性/灾难恢复策略等更高阶策略的 EMS 代理集成。它有四个关键责任领域

服务器池管理。EMS 服务网格代理拥有并跟踪服务器并维护其服务器池。它识别新服务器何时联机并将这些服务器添加到池中。它处理预测性故障和例行维护，在适当情况下取消分配服务器，使其脱机并将其从池中删除。

业务线管理。EMS 服务网格代理拥有其每个 EMS 业务代理的生命周期（例如，它跟踪每个业务线的状态，如果它无法满足其最低运营要求，它将暂停其运营）。

资源分配。EMS 服务网格代理充当资源代理。它处理 EMS 业务代理资源更新或提示，这些更新或提示表示为最小、当前和理想资源需求；并且它确定实际资源分配（例如，如果 EMS 业务代理增加了其理想需求，则 EMS 服务网格代理尝试通过从服务网格服务器池租赁所需的资源来匹配此需求，从而确保 EMS 业务代理保持其首选余量）。

资源争用。在极不可能发生的情况下，由于服务网格上的异常需求，EMS 服务网格代理无法完全满足特定的 EMS 业务代理资源请求，它将自动应用策略来根据业务经理接受的 SLA 解决此资源冲突。

资源争用算法

EMS 服务网格代理首先确定优先级较低的现有资源分配子集。然后，它迭代负责管理这些较低优先级资源分配的 EMS 业务代理，直到它们让出足够的资源来满足请求。

可以调整此算法以广度优先方式运行（在这种情况下，它尝试为所有较低优先级的业务部门维护最小分配）或深度优先方式运行（在这种情况下，它从较低优先级的业务部门回收所需的所有资源，从最低优先级开始，并可能导致服务暂停）。

在任何次优情况下——当没有足够的可用资源时——EMS 服务网格代理的目标是尝试通过确保实际分配超过共享状态中持有的上次已知当前需求来为 EMS 业务代理提供一些余量。如果失败，它会尝试确保至少满足最低要求；否则，它会指示 EMS 业务代理暂停其业务线，直到有足够的资源可用。

EMS 业务代理

EMS 业务代理负责管理业务线级别的资源。它有五个关键责任领域

资源管理。EMS 业务代理跟踪其业务线内各个应用程序的资源需求。它尝试维护足够的余量来响应来自这些应用程序的对更多资源的被动请求，但其主要目标是通过始终为其应用程序提供足够的余量来抢占这些请求。这种提前预测性资源分配是通过应用从分析历史使用模式和了解日内使用模式以及外部事件（例如，美国财政部公告）的影响中得出的规则来实现的。

资源分配。EMS 业务代理维护由 EMS 服务网格代理租赁给它的本地服务器资源池。它支持标准操作

请注意，由于让出资源可能需要一些时间，因此 EMS 业务代理会异步处理此问题。因此，在此请求完成后，将向 EMS 服务网格代理发送 yielded(resourceID) 消息。作为良好公民，EMS 业务代理也被期望释放它不再需要的资源，从而有效地将其返回到服务网格服务器池。它通过向 EMS 服务网格代理发送未经请求的 released(resourceID) 消息来指示它已完成此操作。

资源需求。EMS 业务代理负责向 EMS 服务网格代理提供以下关键指标

资源争用。在极不可能发生的情况下，由于服务网格上的异常需求，EMS 业务代理无法完全满足特定的 EMS 应用程序代理资源请求，它将自动应用策略来根据 SLA 解决此资源冲突，并使用先前描述的资源争用算法的细粒度变体。

标准生命周期管理。EMS 业务代理支持标准生命周期操作 start()、suspend()、resume() 和 stop()。它还会报告其状态。此接口使 EMS 服务网格代理能够拥有和管理业务线的生命周期。

EMS 应用程序代理

在复杂的多层应用程序中，EMS 应用程序将遵循与 EMS 业务代理类似的模式，并承担管理本地应用程序级别资源、维护本地余量等的责任。这种分形基础设施管理模式是 EMS 等自治系统的特征。

EMS 应用程序代理还实施适当的横向扩展和横向缩减策略，以维护其技术/性能 SLA。有许多标准基础设施设计模式，例如计算网格（主/工作节点）和应用程序网格（逻辑分区）。

语义工作负载管理

面向流程的 EMS 使实现策略驱动的语义工作负载管理等策略变得简单明了。SLA 用于确保关键应用程序以利用业务需求以及技术资源优化的方式分布在服务网格中。

高效计算解决方案

面向流程的 EMS 应将策略设计与策略执行相结合，以自动化数据中心运营的所有方面，为当今复杂数据中心日益增长的需求提供强大的解决方案。它应该能够取代容易出错的脚本和手动程序，并且可以自动化任何级别的系统，从优雅地关闭服务器到将整套应用程序移动到灾难恢复站点。

它应该提供全面的设计时工作台，以方便捕获、测试和维护运营工作流作为强大的、可重用的策略。它应该提供一个运行时环境，该环境能够立即检测到故障或需求变化，并协调自动执行维护系统性能所需的策略，同时优化利用率并显著降低运营风险。

EMS 与第三方中间件、监控、配置和虚拟化技术或集成服务网格管理的集成交付了一种高效计算解决方案。

参考文献

  1. Gentzsch, W., Iwano, K., Johnston-Watt, D., Minhas, M. A., and Yousif, M. 2005. 自适应自治计算系统：行业观点。在第三届自适应和自治计算系统国际研讨会论文集，哥本哈根，丹麦（8 月 24-25 日）。
  2. IBM 自治计算研究； http://www.research.ibm.com/autonomic/。
  3. Kephart, J., and Chess, D. 2003. 自治计算的愿景。IEEE Computer 36(1): 41-50。

DUNCAN JOHNSTON-WATT 是 Enigmatec Corporation (http://www.enigmatec.net) 的主要创始人。他在开发大规模系统方面拥有超过 15 年的经验技术开发经验。作为金融服务行业 Java 企业技术的早期采用者，他于 2000 年 4 月获得 Computerworld Smithsonian 奖提名。Duncan 拥有牛津大学计算学硕士学位。

acmqueue

最初发表于 Queue 第 4 卷，第 2 期——
在 数字图书馆 中评论本文




更多相关文章

Mark A. Overton - IDAR 图
UML 是表示面向对象设计的实际标准。它在记录设计方面做得很好，但它有一个严重的问题：它的图表没有传达人类需要知道的内容，使其难以理解。这就是为什么大多数软件开发人员仅在被迫时才使用 UML 的原因。人们根据控制层次结构来理解组织，例如公司。当面对人员或对象的组织时，通常首先要问的问题是：“谁在控制这一切？” 令人惊讶的是，UML 没有一个对象控制另一个对象的概念。因此，在每种类型的 UML 图中，似乎没有一个对象比其邻居具有更大或更小的控制权。


Eric Bouwers, Joost Visser, Arie Van Deursen - 获得您衡量的
软件指标 - 有用的工具还是浪费时间？对于每一位珍视软件系统这些数学抽象的开发人员，都有一位开发人员认为软件指标的发明只是为了让项目经理忙碌。软件指标是非常强大的工具，可以帮助您实现目标，但正确使用它们非常重要，因为它们也具有使项目团队士气低落并将开发导向错误方向的能力。


Derek Miers - 最佳实践 (BPM)
正如 BPM（业务流程管理）技术与传统的应用程序支持方法明显不同一样，BPM 开发的方法论也与传统的软件实施技术明显不同。以 CPI（持续流程改进）作为 BPM 的核心学科，推动公司工作的模型不断发展。事实上，最近的研究表明，公司至少每季度微调一次基于 BPM 的应用程序（有时甚至每年八次）。关键在于，没有所谓的“完成”流程；需要多次迭代才能产生高效的解决方案。每个工作的基于 BPM 的流程都只是未来的起点。


James Champy - 人员和流程
当我和 Mike Hammer 在 1992 年出版《企业再造工程》时，我们了解了真正的业务流程变革将对人员产生的影响。我说“真正的”流程变革，是因为管理人员使用“再造工程”一词来描述任何和所有的公司变革计划。一位被误导的高管告诉我，他的公司不知道如何进行真正的再造工程；因此，它只是裁减了大型部门和业务部门的规模，并期望留下的人能够弄清楚如何完成他们的工作。可悲的是，这就是一些公司仍然实践流程再设计的方式：让人们过度劳累和士气低落，而客户体验到糟糕的服务和低质量。



© 保留所有权利。

© . All rights reserved.