CN109947557A - 用于云平台的分布式生命周期管理 - Google Patents

用于云平台的分布式生命周期管理 Download PDF

Info

Publication number
CN109947557A
CN109947557A CN201811563133.4A CN201811563133A CN109947557A CN 109947557 A CN109947557 A CN 109947557A CN 201811563133 A CN201811563133 A CN 201811563133A CN 109947557 A CN109947557 A CN 109947557A
Authority
CN
China
Prior art keywords
cloud platform
node
platform
established
automatically
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201811563133.4A
Other languages
English (en)
Other versions
CN109947557B (zh
Inventor
T·伊斯特林
K·M·拜尔利
M·A·谢茨
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Enterprise Development LP
Original Assignee
Hewlett Packard Enterprise Development LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Enterprise Development LP filed Critical Hewlett Packard Enterprise Development LP
Publication of CN109947557A publication Critical patent/CN109947557A/zh
Application granted granted Critical
Publication of CN109947557B publication Critical patent/CN109947557B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5055—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering software capabilities, i.e. software resources associated or available to the machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5072—Grid computing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Mathematical Physics (AREA)
  • Debugging And Monitoring (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • User Interface Of Digital Computer (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Stored Programmes (AREA)

Abstract

本发明涉及用于云平台的分布式生命周期管理。示例系统包括多个节点，每个节点包括处理器和存储操作系统映像的副本的非暂时性机器可读介质。操作系统映像的每个副本可以包括云平台应用的最小工件集，以及生命周期管理器程序指令，该生命周期管理器程序指令在由该节点中的任一个执行时实例化相应节点的生命周期管理器。生命周期管理器可以被配置为响应于接收到平台集群创建请求，自动地建立包括作为唯一成员的相应节点的云平台应用的云平台，然后邀请其他节点加入云平台。生命周期管理器还可以被配置为响应于接收到加入由该节点中的另一个建立的云平台应用的已建立的云平台的邀请，自动地将相应节点集成到该已建立的云平台中。

Description

用于云平台的分布式生命周期管理
背景技术
云平台可用于向客户提供云服务。云平台由在底层硬件基础架构上运行的云平台应用形成。云服务包括例如软件即服务(SaaS)、平台即服务(PaaS)、基础架构即服务(IaaS)等。
附图说明
图1示出了部署的云平台的示例。
图2A-图3C示出了处于各个部署阶段的示例云平台。具体地，图2A示出了节点处于就绪状态的初始部署阶段。图2B示出了第二部署阶段，其中云平台具有一个成员节点。图2C示出了第三部署阶段，其中第二成员节点已集成到云平台中。图3A示出了第四部署阶段，其中云平台包括三个成员节点。图3B示出了第五部署阶段，其中云平台包括多于三个成员节点。图3C示出了第六部署阶段，其中云平台包括N个成员节点。
图4是示出了用于初始设置平台设置的示例过程的过程流程图。
图5是示出了用于集成到云平台中的示例过程的过程流程图。
图6是示出了用于响应缩放事件的示例过程的过程流程图。
图7是示出了用于维护云平台的示例过程的过程流程图。
图8示出了存储示例生命周期管理器程序指令的示例非暂时性机器可读介质。
具体实施方式
1–定义
云平台。如本文所使用的，云平台是用于动态提供云服务的分布式计算系统(计算集群)。云平台由云平台应用的运行时(runtime)实例和底层硬件基础架构形成。
云平台应用。如本文所使用的，云平台应用是用于建立和管理云平台的分布式应用。如本文所使用的，分布式应用是具有可以在多个节点上以分布式方式运行的组件的应用。商业可获得的云平台应用的示例包括Kubernetes、Mesos和OpenStack。
节点。如本文所使用的，节点是包括能够执行存储在非暂时性机器可读介质上的程序指令的至少一个(虚拟化或物理)处理器的任何(虚拟化或物理)计算设备。节点还可以包括(虚拟或物理的)附加组件，诸如内存(例如，前述非暂时性机器可读介质)、输入/输出单元、控制器、外围设备、存储设备等。例如，节点可以是虚拟机(VM)、服务器、刀片服务器系统的刀片、可组合基础架构设备的计算模块、融合(或超融合)设备的计算节点、机架式(rack-scale)系统的计算节点、片上系统(SoC)、个人计算机、包含处理器的印刷电路板等。多个不同的物理节点可以容纳在相同底盘中，尽管不一定是这种情况。多个不同节点还可以共享它们的一些或全部组件–例如，可以说虚拟机共享虚拟机被虚拟化的底层物理硬件。
工件。如本文所使用的，工件(artifact)是作为计算机程序的部分或由计算机程序可以使用的任何一份数字信息。工件的示例包括可执行二进制文件、源文件、脚本、表、库、文档和任何其他数字数据。
操作系统映像。如本文所使用的，操作系统映像是包括用于控制节点的操作的工件的映像(例如，磁盘映像)。
服务。如本文所使用的，服务是云平台的功能或功能组。例如，服务可以包括API服务、域名系统服务、调度程序服务、分布式密钥值库服务、平台工作者(也称为从属或下属)服务等。
角色。如本文所使用的，角色是由节点提供(或将提供)的服务的组合。角色可以(但不一定必须)由特定名称指定。角色可以(但不一定必须)与诸如Ansible playbook的配置管理脚本相关联。
2–部署、维护和改变云平台
云平台的生命周期管理是指部署、维护和缩放云平台的功能中的任何一种(或任何组合)。部署、维护和缩放云平台可能是复杂且昂贵的工作。特别是，许多部署、维护和缩放云平台的途径可能需要IT专业人员(或专业人员的团队)的大量时间和精力，这可能导致云平台的高运营成本。例如，在部署云平台的许多途径中，可能需要具有所使用的特定云平台应用知识的IT专业人员来设计系统的整体配置(例如，确定系统需要哪些角色或服务，确定哪些节点应分配哪些角色/服务，确定在哪些节点上安装哪个软件等)，然后配置系统中的每个节点。作为另一个示例，在许多途径中，日常维护任务和故障需要IT专业人员的手动诊断和干预。作为另一示例，在初始部署之后缩放系统在一些途径中不支持，或者在其他途径中经由通过IT专业人员手动重新配置节点来实现。
因此，本文公开了可以简化和降低部署、维护和缩放云平台的成本的技术。例如，在本文描述的示例中，可以通过提供智能节点来部署云平台，该智能节点能够自动地自组装到期望的平台中，维护平台，并且动态地扩大或缩小平台，伴随最少的手动干预并且没有集中式自上而下的控制。节点可以是“智能的”，其中，除了其他之外，它们各自可以包括示例生命周期管理程序(“LCM”)，该生命周期管理程序自动地与其他节点的LCM一起工作以协作地控制云平台的部署、维护和缩放。
具体地，在一些示例中，可以通过提供上述智能节点的集合并指示节点中的一个开始自组装平台来部署云平台。该第一节点可以建立将其自身作为唯一成员的云平台，并自动地邀请其他节点进入该平台。当每个节点加入该平台时，它的LCM可以自动地确定应如何配置该节点以提供尽可能最佳的平台。在这样做时，节点的LCM可以经由分布式决策制定过程彼此协调，以确保实现平台的期望的整体配置。例如，LCM可以基于期望的最终状态(例如，指定的容错)和当前可用的资源来识别平台当前需要哪些角色，并且可以确定哪些节点应该扮演哪些角色。可以从一开始就为每个节点提供包含建立成熟的云平台所需的所有工件的映像，并且因此任何节点都能够承担云平台的任何所需角色。每个节点的LCM可以自动地配置它的节点以承担它已选择的角色。因此，平台通过从一个初始成员节点开始并随着其他节点加入而增长并且配置和重新配置其自身来自组装。因此，在一些示例中，除了为系统提供资源(例如，节点)并指示节点中的一个开始自组装平台之外，不需要手动干预来部署平台。
另外，在一些示例中，一旦部署了云平台，节点的LCM可以自动地实施平台的维护，包括例如识别和实施周期性平台维护任务、识别和修复故障等。例如，每个节点的LCM可以监控系统的状态，并且响应于可能需要修复措施(诸如在另一节点上重新启动服务)的故障事件(诸如服务故障)，节点的LCM可以经由分布式决策来决定哪个节点应该采取动作。作为另一示例，每个节点的LCM可以监控平台维护任务队列，并且节点的LCM可以经由分布式决策来决定哪个节点应该实施哪个平台维护任务。因此，在一些示例中，对于这种系统维护不需要大量手动干预。
此外，在一些示例中，可以通过向系统添加或从系统移除节点来容易地扩大或缩小系统，其中节点的LCM根据变化自动地确定如何配置(或重新配置)节点。例如，每个节点的LCM可以监控系统中节点的添加或移除，并且响应于节点的移除或添加，节点的LCM可以经由分布式决策来决定如何根据变化配置或重新配置节点。因此，在一些示例中，不需要大量手动干预来缩放平台。
在本文描述的示例中，节点形成协作系统，其中对系统的配置(初始的和正在进行的配置两者)的控制(经由它们的LCM)在节点之间分布。这与替代途径形成对比，在替代途径中，节点的配置被主实体(诸如配置管理主机)以自上而下的方式控制。此外，如上所述，本文描述的示例提供了一种本质上自我部署和自我维持的系统，该系统可以动态地扩大或缩小(从单个节点到许多节点)，并且可以容忍任何节点的故障并且在没有外部干预的情况下修复那些故障。
3-示例云平台
图1示出了示例云平台100。示例云平台100由云平台应用20的运行时实例、分布式密钥值库(DKVS：distributed key value store)30和多个节点40形成。节点40通过通信媒体和(虚拟或物理)网络设备(未示出)可通信地彼此连接。节点40协作以通过执行与其相关联的相应程序指令来实例化云平台应用20和DKVS30的运行时实例。
云平台应用20是用于从资源(例如，节点40)的集合建立云平台(例如，云平台100)并管理该平台的分布式应用。因为它是分布式应用，所以云平台应用20包括可以由多个节点40以分布式方式执行的多个组件(然而，该能力不排除云平台应用20还完全由单个节点40运行，如在具有一个成员节点40的云平台100的情况中那样)。跨越节点40的云平台应用20的组件的分布在图1中由跨越节点40的云平台应用20概念性地示出。云平台应用20的组件可包括例如API服务器、域名系统服务、调度程序、分布式密钥值库服务器(或代理)、平台工作者(也称为从属或下属)服务等。在完全部署的平台100中，云平台应用20的每个组件通过作为云平台100的部分的节点40中的至少一个运行，组件可以(但不一定必须)由多个节点40运行，并且节点40可以(但不一定必须)运行与其他节点40相同的组件。任何云平台应用可以用作云平台应用20，包括商业上可用的云平台应用，诸如Kubernetes、Mesos和OpenStack。
DKVS 30是逻辑存储卷，其中节点40可以存储密钥值对。DKVS 30由节点40执行的DKVS应用(未示出)创建和管理。DKVS 30由存储卷支持，该存储卷为诸如节点40的相应存储卷43或在可通过网络(未示出)访问节点40的节点40外部的存储卷(未示出)。DKVS 30可以被云平台100用于例如存储和传送：平台配置信息、平台健康/状态信息和平台维护任务队列。任何DKVS应用都可用于建立DKVS 30，包括商业上可获得的DKVS应用，诸如etcd。
节点40可以各自包括处理器41、内存42、存储卷43、生命周期管理器(“LCM”)500、云平台应用20的本地组件以及DKVS应用的本地组件。给定节点40的LCM 500可以由执行LCM程序指令501的那个节点40的处理器41形成，这将在下面参考图8进行描述。如上所述，给定节点40的处理器41还可以执行云平台应用20的本地组件的程序指令，并且可以执行DKVS应用的本地组件的程序指令。
更具体地，每个节点40是(虚拟化或物理)计算设备，其包括能够执行存储在非暂时性机器可读介质(诸如(虚拟化或物理)内存42)上的指令的至少一个(虚拟化或物理)处理器41。节点40还可以包括可以持久地存储节点40的数据的(虚拟化或物理)存储卷43。节点40还可以包括(虚拟或物理)附加组件，诸如输入/输出单元、控制器、外围设备、存储设备等。例如，节点40可以是虚拟机(VM)、服务器、刀片服务器系统的刀片、可组合基础架构设备的计算模块、融合(或超融合)设备的计算节点、机架式系统的计算节点、片上系统(SoC)、个人计算机、包含处理器的印刷电路板等。多个不同的物理节点40可以容纳在相同底盘中，尽管不一定是这种情况。多个不同节点40还可以共享它们的一些或全部组件。
处理器41可以包括能够执行机器可读指令的任何电路(或从该电路虚拟化)，诸如中央处理单元(CPU)、微处理器、微控制器设备、数字信号处理器(DSP)等。
内存42可以包括处理器41可以读取程序指令的任何非暂时性机器可读介质(或从该非暂时性机器可读介质虚拟化)，包括诸如随机存取存储器(RAM)(例如，DRAM、SRAM等)的易失性介质和/或诸如非易失性RAM(NVRAM)(例如，闪存、忆阻器RAM、电阻型RAM、相变存储器、3D XPoint存储器等)的持久性(非易失性)介质。
存储卷43可以包括任何能够持久存储数字数据的存储设备(或从该存储设备虚拟化)，诸如硬盘驱动器、固态驱动器(例如，闪存驱动器)、磁带驱动器、光盘等。
每个节点40可以各自提供有操作系统映像400的副本。操作系统映像400可以存储在例如存储卷43中。操作系统映像400的每个副本可以至少包括建立云平台应用20的期望云平台100所需的云平台应用20的所有工件(在此称为云平台应用20的“最小工件集”)。换句话说，提供有最小工件集的单个节点40将能够建立将自身作为唯一成员节点40的全功能云平台100。工件可以包括例如云平台应用20的可执行二进制文件。工件还可以包括例如云平台应用20的文件、库和其他数据。操作系统映像400还可以包括建立云平台所需的最低限度之外的云平台应用的附加工件。另外，在一些示例中，操作系统映像400可以包括LCM程序指令501。
应当理解，构成云平台100的最小工件集的内容取决于期望建立的云平台100的类型。云平台应用20可以能够建立多个不同类型的云平台100，并且各自可以具有其自己的最小工件集。管理员或其他管理实体可以确定期望的云平台100的类型，并且因而确定该云平台100需要哪些工件，例如作为创建(或获取)操作系统映像400的部分。
在一些示例中，包括在操作系统映像400中的云平台应用20的每个软件组件以安装状态被包括，但是可以静止直到并且除非需要它。在一些示例中，单个云平台应用20可以能够形成多种类型的云平台(例如，基于容器的SaaS平台、基于VM的PaaS/IaaS平台等)，在这种情况下，操作系统映像400可以包括云平台应用20可以建立的一种、多种或所有类型的云平台的工件。
例如，如果云平台应用20是Kubernetes，则建立一个示例类型的基于Kubernetes容器的云平台所需的最小工件集包括：Kubernetes API服务器组件、Kubernetes DNS组件、Kubernetes调度程序组件、Kubernetes Minion组件、容器运行时接口组件(例如，Docker、runc、clear container、rkt)、注册表组件(例如，Docker Registry)、覆盖网络组件(例如，flannel)和计算机操作系统(例如，linux OS)。
作为另一示例，如果云平台应用20是Mesos，则建立一个示例类型的基于Mesos容器的云平台所需的最小工件集包括：mesos-master组件、mesos-agent组件、mesos-dns组件、调度程序组件、DKVS(例如，zookeeper)、容器运行时(例如，Docker、runc、clearcontainer、rkt)、java组件和计算机操作系统(例如，linux OS)。
作为另一示例，如果云平台应用20是OpenStack，则建立一个示例类型的OpenStack VM自动售货云平台所需的最小工件集包括：nova stack组件(例如，nova api、nova scheduler、nova compute等)、cinder组件、neutron组件和keystone组件。
用于针对所有节点40使用相同操作系统映像400的上述途径可以与替代途径形成对比，在替代途径中在不同节点上提供云平台应用的不同组件。例如，在大多数云平台中，云平台应用的不同服务安装在不同节点上(例如，可以根据它们预期角色为不同节点提供不同的操作系统映像)。换句话说，在替代途径中，虽然建立云平台所需的云平台应用的每个组件都存在于系统中的某个位置，但并非每个节点都具有每个组件。因此，与本文描述的示例形成对比，在这样的替代途径中，某人可能需要花费时间和精力来确定每个角色需要多少，哪些节点应该扮演哪些角色，以及哪些组件应该安装在哪些节点上。
如上所述，每个节点40包括LCM 500，该LCM 500可以通过运行LCM程序指令501形成。LCM程序指令501可以存储在节点40的存储卷43中并且加载到节点40的内存42中用于执行。在一些示例中，除了用于云平台应用20的最小工件集之外，LCM程序指令501被包括在提供给每个节点40的操作系统映像400中。每个节点的LCM 500控制云平台100的初始部署、缩放和维护，如下面更详细描述的。
如上所述，节点40可以包括可以是物理或虚拟化的一些组件(诸如“处理器”、“内存”、“存储卷”等)。通常，出于本公开的目的，组件是物理的还是虚拟化的并不重要。因此，本文和所附权利要求中对未指定“物理”或“虚拟”的节点40的任何组件的任何引用应被理解为允许组件的物理和虚拟化类型两者(以任何组合)。然而，节点40的任何虚拟化组件必然从底层物理硬件虚拟化。因此，本文或在所附权利要求中对节点的给定组件的叙述必然意味着与给定组件相对应的物理硬件存在于系统中的某处，其中给定组件或者与对应的物理硬件是同一个或从对应的物理硬件虚拟化。注意，物理硬件和进行虚拟化的虚拟组件之间不一定是一对一的比率(一个虚拟组件可以跨越多个物理组件，或者多个虚拟组件可以共享一个物理组件)。因此，例如，本文或所附权利要求中的叙述，诸如“系统包括多个节点，每个节点包括处理器”应理解为至少意味着：(A)每个节点具有物理处理器或虚拟处理器，以及(B)如果任何节点包括虚拟处理器，则系统包括虚拟处理器被虚拟化的至少一个物理处理器(不一定由任何特定节点拥有)。
4.示例生命周期管理器
给定节点40的LCM 500可以自动地与其他节点40的其他LCM 500一起工作以自动地控制云平台100的初始部署、云平台100的维护和/或云平台100的缩放。为了便于理解，下面分别描述这些功能，但应该理解，在实践中，这些功能可以重叠并且不一定是相互排斥的。下面描述与这些功能有关的示例操作，并且这些操作中的一些被示出为图4-图7中的过程流程图。LCM程序指令501包括当由处理器执行时使LCM 500实施下述操作的指令，包括例如与图4-图7中所示的操作对应的指令。
4.1云平台的初始部署
云平台100的初始部署开始于提供多个节点40，每个节点40具有操作系统映像400的副本和LCM程序指令501(其可以是操作系统映像400的部分)。通过实例化每个节点40的LCM 500(即，在每个节点40上执行LCM程序指令501)并将节点40可通信地彼此连接，可以将节点40置于就绪状态。一旦处于就绪状态，可以指示节点40中的一个(下文中，“第一节点40-1”)开始创建云平台100的过程，于是节点40开始自组装到云平台100中。
当节点40处于就绪状态时，平台创建请求被发送到第一节点40-1的LCM 500(参见图2A)。作为响应，第一节点40-1开始云平台100的自组装，例如通过执行操作，诸如图4中示出的操作。具体地，图4中示出的过程可以由第一节点40-1的LCM 500实施(即，接收到平台创建请求的节点40)。
现在将描述图4。在框601中，LCM 500例如从管理员或其他管理实体接收平台创建请求。平台创建请求至少包括开始部署云平台100的指令。平台创建请求还可以包括云平台100的资源信封的标识，诸如，例如，将要成为云平台100的部分的其他节点40的标识。平台创建请求还可以包括一些通用的平台范围的参数，诸如目标容错级别。在一些示例中，选择节点40中的哪一个接收平台创建请求并不重要，因为节点40中的任何一个可以能够处理该请求(回想一下，所有节点40可以提供有包括LCM程序指令501的相同操作系统映像400)。
响应于接收到平台创建请求，在框602中，LCM 500创建DKVS 30。例如，如果使用etcd作为DKVS 30，则第一节点40-1可以建立将其自身作为唯一成员的etcd集群。
在框603中，LCM 500创建将其自身作为唯一成员的云平台100(也参见图2B)。例如，第一节点40-1的LCM 500可以通过自动地激活(取消静止)建立云平台100所需的云平台应用20的所有本地组件并运行本地配置脚本以自动地将其自身配置为承担云平台100的所有所需角色。来建立云平台100。
在框604中，在建立云平台100之后，第一节点40-1开始邀请应该成为云平台100的部分的其他节点40(例如，如在平台创建请求中标识的)加入平台100。特别地，第一节点40-1将加入平台请求发送到应该成为云平台100的部分的节点40中的每个(参见图2B)。加入平台请求可以包括节点40能够加入云平台100所需的信息，诸如，例如，第一节点40-1创建的DKVS 30的标识和加入DKVS 30的凭证(如果需要的话)。一旦其他节点40是DKVS 30的部分，他们就可以访问存储在其中的平台配置信息，节点40可以使用该平台配置信息来加入云平台100。下面描述关于这些操作的其他细节。
当节点40中的一个接收到加入平台请求时，节点40的LCM 500可以例如通过执行诸如图5中示出的那些操作，自动地开始将其自身集成到现有云平台100中的过程(即，加入平台100并将其自身配置为采用其中的角色)。具体地，图5中示出的过程可以由任何节点40的LCM 500实施，该节点40还不是接收加入平台请求的平台100的成员。
现在将描述图5。在框605中，LCM 500接收加入平台请求。
在框606中，响应于加入平台请求，LCM 500加入由第一节点40-1建立的DKVS 30。
一旦节点40已加入DKVS 30，节点40的LCM 500然后可以从DKVS 30获得当前平台配置和状态信息，并且LCM 500可以确定其应该如何配置其节点40作为框607-609中的加入平台100的部分。
具体地，在框607中，LCM 500识别其认为其节点40应该在云平台100中采用的角色。例如，LCM 500可以基于(如从DKVS 30确定的)平台100的当前状态和平台100的期望配置来识别节点40应该被配置为采用哪个角色以便最大程度地改善云平台100的状态。下面描述节点40可以如何针对其自身识别这样的角色的其他细节。
在确定其应该采用的角色时，LCM 500使用DKVS 30来与已经是平台100的成员的其他节点40和/或寻求加入平台的其他节点40协调。例如，在框608中，LCM 500确定DKVS 30中的锁是否可用于角色，并且仅在锁可用时才采用该角色。如果锁不可用，则LCM 500返回到框607以识别要实施的另一个角色。在一些示例中，LCM 500可以在识别要实施的另一角色之前等待预定量的时间。
在框609中，LCM 500获得角色的锁，然后将其自身配置为采用该角色。例如，LCM500可以例如通过运行本地配置脚本激活和配置适合于该角色的服务(参见图2C)，自动地配置节点40以承担所识别的角色。
当节点40新加入平台100时，平台100的现有成员节点40可以知道这些事件，并且可以确定它们是否以及如何应该根据新成员重新配置它们自身。现有成员节点40确定是否以及如何重新配置其自身的过程在下面关于缩放更详细地被描述。
因此，平台100以单个成员(第一节点40-1)开始，然后随着其他节点40自动地将它们自身集成到平台100中而增长。当节点40继续加入云平台100时，它们可以各自基于其他节点40的配置自动地确定它们应该如何被配置。如果需要，平台100的现有成员也可以自动地重新配置它们自身。因此，当各个节点40加入平台100时，云平台100的平台级别配置可以自动地改变和更新，其中节点40它们自己确定它们应该如何被配置。
在新加入节点40和现有节点40重新配置它们自身的两种情况下，节点40的LCM500可以使用DKVS 30来获得其他节点40的配置信息，共享它们自己的当前和/或预期配置，并且另外与其他节点40协调它们的动作。例如，DKVS 30的分布式锁定机制可以被节点40用来保留可用的角色、服务或动作。因此，DKVS 30可以充当分布式决策机制，允许各个节点40独立地控制配置它们自身，同时还彼此协调以实现期望的系统范围配置。
例如，考虑图2A-图3C，其示出了节点40自组装成云平台100的示例的示例阶段。尽管对云平台100中的角色/服务的数量不一定有限制，但为了便于描述和理解，图2和图3示出与三个角色相关联的服务：混合管理器-工作者、仅管理器(manger-only)和仅工作者(worker-only)。混合管理器-工作者节点40将具有激活的与管理器相关联的服务(下文称为“管理器服务”)和与工作者相关联的服务(下文称为“工作者服务”)两者。仅管理器节点40将具有激活的管理器服务但不具有工作者服务。仅工作者节点40将具有激活的工作者服务但不具有管理器服务。在图2和图3中，管理器服务由标记为“Manager Srvc”的框表示，而工作者服务由标记为“Worker Srvc”的框表示。在附图中，未在节点40上激活的服务(例如，已安装但静止的服务)由具有虚线的框表示，而被激活的服务由具有实线且没有阴影的框表示。
在图2A中，提供了将要形成平台100的多个节点40。在图2A示出的阶段中，每个节点40具有LCM 500的运行实例和云平台应用20(例如，管理器服务和工作者服务)的相同组件，它们都是静止的。在这种状态下，第一节点40-1例如由系统管理员提供平台创建请求。
在图2B中，响应于平台创建请求，第一节点40-1创建将其自身作为唯一成员的平台100和DKVS 30。因为此时第一节点40-1是平台100的唯一成员，所以它最初承担平台100的所有所需角色/服务，在该示例中，这意味着成为混合管理器-工作者。然后，第一节点40-1将加入平台请求发送到其他节点40。
在图2C中，第二节点40-2将其自身集成到系统中。第二节点40-2可以确定在该状态下平台100的期望配置是平台100具有一个混合管理器-工作者节点40和一个仅工作者节点40。基于期望的平台级别配置和在平台100中已经存在一个混合管理器-工作者节点40的事实，第二节点40-2可以确定它应该将其自身配置为仅工作者节点40。因此，第二节点40-2激活并且配置与工作者角色相关联的服务。
在图3A中，第三节点40-3加入云平台100。第三节点40-3可以确定在该状态下平台100的期望平台级别配置将具有三个混合管理器-工作者节点40(例如，以提供高可用性)。基于该期望配置，第三节点40-3可以确定它应该成为混合管理器-工作者，因为这将通过使平台100更接近期望配置来改善平台100。作为响应，第二节点40-2还可以决定将其自身重新配置成为混合管理器-工作者，以通过使平台100完全达到期望配置来进一步改善平台100。
在图3B中，第四节点40-4加入平台100。第四节点40-4可以确定处于该状态的平台100的期望平台级别配置将具有三个混合管理器-工作者节点40和一个仅工作者节点40(例如，以提供高可用性)。基于该期望配置，第四节点40-4可以确定它应该变成仅工作者，因为这将通过使平台100更接近期望配置来改善平台100。
剩余节点40可以继续加入平台100，其中每个节点决定它应该如何被配置，直到所有节点40都已成为平台的成员。在一些示例中，第四和后续节点40可以作为仅工作者节点40加入。在一些示例中，如图3C所示，当平台变得足够大(例如，节点40的数量超过某个阈值)或足够忙(例如，使用度量超过某个阈值)时，混合管理器-工作者节点40可以被重新配置为仅管理器角色，因为这些节点40的管理职责此时可能足够显著以降低它们也提供工作者服务的能力。
4.2云平台的缩放
云平台100的缩放意味着将节点40添加到云平台100或从云平台100移除。平台100的初始部署的一部分包括缩放过程，因为在初始部署期间，平台100从一个初始成员缩放到最终包括所有原始部署的节点40。然而，在初始部署之后也可以发生缩放，因为在那些初始部署的节点之外还添加新节点40。另外，缩放还涵盖从平台100移除节点40，这通常不作为初始部署的部分而发生。在下文中，被添加到(或试图加入)平台100的节点和从平台100移除(或试图离开)的节点40在区分它们并不重要时通常被称为“缩放事件”。
为了将节点40添加到平台100(或将节点40集成到平台100中)，必须首先例如由管理员或其他管理实体提供节点40，其中所提供的节点40具有在其上运行的LCM 500的实例和操作系统映像400的副本。一旦已经提供了节点40，将节点40添加到平台中的其余过程可以由节点40自动地处理，而没有或具有非常少的人工干预。为了使新节点40能够加入平台100，需要使新节点40和/或当前成员节点40知道彼此。在一些示例中，这可以自动地完成；例如，平台100可以具有定期维护任务以检查对其资源包络的更新(例如，新节点40)，这可以揭示新节点40的存在。在其他示例中，管理员或其他管理实体可以向平台100发送消息以通知其新节点40。响应于检测到新节点40的存在，成员节点40中的一个可以向新节点40发送加入平台请求，就像上面关于初始部署描述的加入平台请求一样。响应于加入平台请求，新节点40然后可以尝试以与在初始部署期间节点40将加入平台的方式相同的方式且如下面更详细描述加入平台100。
从平台移除节点40可以以许多方式发生，包括有意地和无意地。例如，可以通过管理员或其他管理实体向平台的待移除(to-be-removed)节点40和/或其他节点40发送命令指示待移除节点40将要从平台100的资源包络移除(下文中，“优雅移除”)，来从平台移除节点40。响应于这样的消息，平台100的剩余节点40可以制定处理节点40的移除的过程，包括例如确定剩余节点40中的任何一个是否需要重新配置它们自身，将负载从待移除节点40转移到其他节点，等等。作为另一示例，可以从平台100移除节点40，而不必预先通知其他节点40。例如，节点40可能突然关闭(故意或通过故障)。作为另一示例，在没有完全关闭节点40的同时，节点40可能经历故障或错误，该故障或错误阻止该节点起到平台100成员的作用。作为另一示例，节点40可能突然与其他节点40断开连接(故意或通过故障)。
当发生缩放事件时，这可能对作为缩放事件的主体的节点40和作为平台100的成员的其他节点40都具有重要影响。具体地，将要添加到平台100的节点40可能需要将其自身配置为集成到平台100中的部分，如下面更详细描述的。另外，不是缩放事件的主体的平台100的现有成员节点40也可能需要根据缩放事件来重新配置它们自身。具体地，当节点40新加入或离开平台100时，这可以使平台100达到其当前配置不是期望配置的状态，因此平台100的一个或多个现有成员可能需要重新配置其自身以便使平台100作为整体达到(或更接近)期望配置。
因此，作为平台100的当前成员的节点40需要知道这样的缩放事件，以使它们可以确定是否以及如果是这样，它们应该如何重新配置它们自身。因此，在一些示例中，平台100中的每个节点40的LCM 500可以被配置为监控节点40的添加或移除。具体地，作为平台100的成员的每个节点40的LCM 500可以被配置为自动地监控平台100的状态(例如，健康和配置)，包括监控哪些节点40是平台100的成员(及它们的健康状态)以及哪些节点40正在尝试加入平台100。例如，在DKVS 30中LCM 500可以找到该信息，LCM 500还可以采取其他有效步骤来查明该信息，诸如与其他节点40交换消息。基于状态信息，平台100中的每个节点40的LCM 500可以被配置为检测节点40何时加入或离开平台100。响应于检测到这样的事件，每个成员节点40可以确定是否需要重新配置其自身以考虑该变化。
在一些示例中，所有节点40同时监控缩放事件。在其他示例中，对缩放事件的监控是由一个节点40在某时实施的定期维护任务。在一些示例中，可以以不同方式监控不同类型的缩放事件；例如，节点40的添加和节点40的优雅移除可以作为由一个节点40在某时实施的定期维护任务来被监控，同时节点40的突然故障(例如，关闭、断开连接或其他故障)可以由所有节点40同时监控。
4.2.1-响应于缩放事件的节点的配置
如上所述，当发生缩放事件时，作为缩放事件的主体的节点40和平台的成员节点40都可能需要配置它们自身。特别地，当节点40新加入(或尝试加入)平台100时(无论是作为初始部署的部分，还是在部署之后)，新加入的节点40自动地配置其自身，如下面更详细描述的。另外，取决于平台100的当前配置，平台100的现有成员可能需要或可能不需要根据新加入的节点40重新配置它们自身。当节点40离开平台40时，离开的节点40不一定需要进行任何配置(例如，它可以简单地关闭)，但是平台100的现有成员可能需要或可能不需要根据平台100中的节点40的改变数量来重新配置它们自身。
如上面关于图5所描述的，新加入平台100的节点40的LCM 500可以基于其对其在平台100中应该扮演的角色的标识来确定如何配置其自身。例如，加入的节点40的LCM 500可以基于什么将改善平台100根据其当前配置来识别将要采用的角色。例如，加入的节点40的LCM 500可以根据当前条件识别平台100作为整体的期望配置，并选择将使平台100达到(或更接近)期望配置的角色。特别地，加入的节点40的LCM 500可以识别平台的期望配置，该期望配置具有等于当前在平台100中的节点40加上加入的节点40加上(在一些示例中)其他同时加入的节点40的总和的多个节点40。如本文所使用的，平台100的期望配置是基于节点40的数量将要被包括在平台100中的每个节点40角色的规范，而不必指定哪些特定节点40采用哪些特定角色。例如，平台100的期望配置可以是用于单个节点平台100的“一个混合管理器-工作者节点40”、用于双节点平台100的“一个混合管理器-工作者节点40和一个仅工作者节点”、用于三节点40平台100的“三个混合管理器-工作者节点40”，等等(参见下面的表1以获得进一步的示例)。加入的节点40的LCM 500可以将所识别的平台100的期望配置中的角色中的一个识别为其将采用的角色。在一些示例中，加入的节点40的LCM 500可以在可能的情况下尝试采用尚未由平台100的成员节点40提供的期望配置的角色中的一个。
平台100的当前成员节点40响应于缩放事件确定是否以及如果是这样应该如何重新配置其自身的过程可以类似于新加入的节点40如何确定如何配置其自身的过程。例如，当前成员节点40的LCM 500可以执行诸如图6中示出的那些操作。
在框610中，当前成员节点40检测到缩放事件，诸如向平台100添加节点40/从平台100移除节点40。例如，每个节点40的LCM 500可以通过监控DKVS 30检测到节点40已经新加入(或正在尝试新加入)平台100，或者节点40已经从平台100移除(或将要移除)。作为另一个示例，平台100的成员节点40可以监控其他成员节点40的状态(例如，健康、连接性等)，使得它们可以检测到节点40的移除。在一些示例中，平台100的成员节点40可以在缩放事件正在进行时(例如，当节点40在加入平台100的过程中时)检测到缩放事件。在其他示例中，平台100的成员节点40可以在缩放事件已经完成之后检测到缩放事件(例如，作为周期性维护任务的部分)。
在框611-615中，成员节点40的LCM 500响应于缩放事件确定它是否应该重新配置其自身，并且如果是这样，则如何重新配置其自身。在一些示例中，平台100的成员节点40可以在缩放事件正在进行时确定它们是否/如何应该重新配置它们自身(例如，当前成员节点40和加入的节点40可以同时配置/重新配置它们自身)。在其他示例中，平台100的成员节点40可以在缩放事件已经完成之后确定它们是否/如何应该重新配置它们自身(例如，加入的节点40可以首先配置它们自身，然后在此之后当前成员节点40可以确定是否需要任何重新配置)。
特别地，在框611中，LCM 500根据作为缩放事件的结果的将成为平台100的成员的节点40的数量，确定平台100的期望配置。更具体地，在缩放事件完成之后实施框611的示例中，则期望配置基于当前在平台100中的节点40的总数(其将自动地包括作为缩放事件的部分加入的任何节点40并排除作为缩放事件的部分而离开的任何节点40)。在缩放事件正在进行的同时实施框611的示例中，则期望配置基于当前在平台100中的节点40的总数加上任何加入的节点40并且减去任何离开的节点40。因为每个节点40的LCM 500具有相同的逻辑，每个LCM 500将在给定平台100的当前状态的情况下识别相同的期望配置。下面描述如何可以确定期望配置的更详细示例。
在框612中，LCM 500可以确定是否将需要重新配置平台100的任何当前成员节点40，以便在缩放事件之后平台100处于期望配置。例如，可以将当前成员节点40的配置与期望配置进行比较，以识别它们之间的任何差异。如果期望配置与当前平台100配置之间没有差异，则不需要重新配置成员节点40。如果当前平台100配置是期望配置的子集(即，相对于期望配置，当前配置缺少一个或多个角色但是当前配置中没有无关角色)，则不需要重新配置成员节点40，因为新加入的节点40可以能够满足缺失的角色。如果当前平台配置包括无关角色，则需要重新配置成员节点40以移除无关角色(并且还补充缺少的角色)。
在一些示例中，可以预先确定平台100的哪些状态转换LCM 500将需要重新配置成员节点40，而哪些不需要。例如，假设为表1的示例期望配置(如下所述)，则仅当平台100中的节点40的数量从两个或更少转换为三个或更多(反之亦然)或者当节点40的数量从X-1或更少转换为X或更多(反之亦然，其中X是指定阈值)时，才需要重新配置成员节点。在这样的示例中，LCM 500可以简单地通过确定作为缩放事件的结果已经发生(或正在发生)的状态转换是否是需要重新配置的指定状态转换的列表中的一种，来确定是否需要重新配置成员节点40。
在框612中，在一些示例中，如果至少一个成员节点40(任何节点40)将需要被重新配置，则该过程继续到框613；如果将不需要重新配置成员节点40，则该过程可以结束并且成员节点40可以保持其当前配置。在其他示例中，如果平台的当前配置中的无关角色中的一个与实施该过程的LCM 500的成员节点40的当前角色匹配，则该过程继续到框613；否则，针对该节点40该过程结束。
在框613中，LCM 500识别其节点40的所需角色。特别地，每个成员节点40的LCM500可以将在期望配置中指定的角色中的一个识别为其将采用的角色。
为了确保响应于缩放事件在平台100中采用期望配置，节点40可以在它们的角色选择中经由DKVS 30彼此协调。例如，节点40可以使用DKVS 30的分布式锁定机制来在它们之间分配角色。例如，每种类型的角色(例如，混合管理器-工作者、仅管理器、仅工作者等)可以在分布式锁定机制中被分配特定数量的锁，该数量对应于在期望配置中指定的该类型的角色的数量。在这样的示例中，节点40在将其自身配置为采用角色之前必须首先保留角色的锁，并且可以不采用其未保留锁的角色。因此，在该示例中，每个当前成员节点40和每个新加入节点40(如果有的话)可以通过保留与该角色相关联的锁来选择其角色。这可以确保最终补充所需配置的所有角色。
因此，在框614中，LCM 500可以尝试获得其已选择的角色的锁，并且这样做LCM500确定锁是否可用。如果锁可用，则过程继续到框615。如果锁不可用，则过程循环回到框613，其中节点40选择其可以尝试获得锁的另一角色。在一些示例中，LCM 500可以在返回到框613之前等待预定的时间量。例如，如果在期望配置中存在五个仅工作者角色，并且四个节点40已经获得仅工作者角色的锁，那么试图获得仅工作者角色的锁的下一个(第五)节点40将发现锁可用，而试图获得仅工作者角色的锁的后续(第六)节点40将发现锁不可用。在一些示例中，未参与重新配置的节点40(例如，在框612中回答“否”的节点40)可以在其他节点40尝试锁定角色之前自动地获得(或保持，如果它们已经具有锁)其当前角色的锁，而参与重新配置的节点40(例如，在框612中回答“是”的节点40)可以在节点40尝试锁定新角色之前放弃其当前角色上的任何锁。
在一些示例中，当前成员节点40可以偏向寻求保持其当前配置的角色，如果该角色是在期望配置中找到的角色并且如果锁可用于该角色。换句话说，当前成员节点40可以首先尝试保留其当前配置的角色的锁，并且可以仅在其当前角色没有剩余的锁时考虑其他角色。这可以有助于减少成员节点40之间不必要的角色改变，其可能影响平台100的性能。另外，在成员节点40确定是否/如何重新配置它们自身的同时加入的节点40确定如何配置它们自身的一些示例中，当前成员节点40可以在保留锁时优先于新加入的节点40(例如，所有成员节点40在允许加入的节点40选择锁之前选择它们的锁)，这可以有助于防止新加入的节点40不必要地强制当前成员节点40改变角色。
在框615中，节点40获得角色的可用锁，于是节点40例如通过执行与角色相关联的自动配置脚本来开始自动地重新配置其自身以采用角色的过程。
尽管上面的描述有时侧重于在某时单个节点40加入或离开平台100的示例，但是应理解，在一些示例中，多个节点40可以同一时间加入或离开平台100。特别地，在确定平台100的期望配置作为确定采用什么角色的部分时，每个节点40可以不仅考虑其自身和当前成员节点40，而且还考虑同时加入平台100的所有节点40。例如，如果两个节点40是平台的当前成员并且另外两个节点40试图同时加入平台，则所有这些节点40可以确定四节点期望配置(两个当前成员加上两个加入的节点)。
4.2.2-平台的期望配置
如上所述，在一些示例中，LCM 500可能需要确定云平台100的期望配置作为确定如何配置或重新配置其自身的部分。在这样的示例中，云平台100的期望配置可以取决于作为缩放事件的结果的在平台100中或将在平台100中的节点40的数量。例如，单个节点40期望配置不同于双节点期望配置，该双节点期望配置不同于三节点40期望配置，等等。在一些示例中，云平台100的期望配置还取决于平台100范围参数，诸如期望的容错。例如，具有一个节点的指定容错的三节点40期望配置可以与没有指定容错的三节点40期望配置不同。
在一些示例中，每个LCM 500可以通过搜索预先指定的期望配置的列表来识别期望配置。列表可以包括在每个节点40的LCM程序指令501中，并且可以至少基于节点40的数量被索引(即，键控)。在其他示例中，每个节点40的LCM 500可以包括用于至少基于节点40的数量确定运行中(on-the-fly)的期望配置的逻辑。
在LCM程序指令501包括预先指定的期望配置的列表(或多个列表)的示例中，列表可以采用任何形式，诸如表、阵列、关联列表、密钥值存储等。如上所述，列表可以至少通过多个节点40被索引。例如，LCM 500可以搜索这样的列表以找到与节点数量相关联的期望配置，该节点数量等于当前在平台100中的节点40加上当前尝试加入平台100的任何节点40减去当前尝试离开平台100的任何节点40的数量。另外，列表还可以通过指定的平台范围配置参数(诸如目标容错)和/或任何其他参数来索引。在索引包括指定的目标平台配置参数的示例中，这些可以例如被指定给平台创建请求中的第一节点40-1，并且第一节点40-1可以将该信息记录在DKVS 30中，后续节点40可以从DKVS 30获得该信息。
表1示出通过节点的数量索引的平台100的期望配置的列表的一个可能示例。在表1的示例列表中，假设期望具有容错为一个的(例如，这可以被指定为目标配置参数)高可用性，并且因此可能时期望具有至少三个管理器角色。在表1的示例列表中，还假设期望具有最少数量的管理器角色，如果可能的话，受到上述维持高可用性的约束。在表1的示例列表中，还假设期望实施管理器服务的节点40也实施工作者服务(即，是混合管理器-工作者)，直到系统的大小变得太大(例如，节点40的数量超过节点40的指定阈值数量，在表中表示为X)(参见图3C)。
表1
在每个节点40的LCM 500确定运行中的期望配置而不通过咨询预先指定的列表的示例中，LCM 500可以包括用于进行这种确定的逻辑。该逻辑可以包括可以根据输入参数(诸如节点40的数量)应用的指定规则，以导出平台100的期望配置。例如，该逻辑可以包括当不需要或不可能实现高可用性时仅包括一个管理器角色的规则。作为另一个示例，该逻辑可以包括如下规则：当高可用性被指定并且是可能的时准确地包括对于高可用性必要的最小数量的管理器角色。作为另一个示例，该逻辑可以包括如下规则：始终在混合管理器-工作者节点40中实现管理器服务，直到平台100的大小越过指定阈值(例如，节点的数量满足/超过阈值X)，或者直到管理器节点40的性能下降到低于指定阈值，或者系统上的负载变得足够大。
4.3-云平台的维护
平台100中的每个节点40的LCM 500可以自动地实施平台的维护任务。如本文所使用的，“维护任务”包括根据指定的调度产生的计划维护任务(例如，定期维护任务)以及响应于计划外的错误、故障或其他情况而产生的反应维护任务两者。
特别地，LCM 500可以使用DKVS 30经由分布式决策来协调哪些节点40将实施哪些维护任务。例如，当LCM 500认为需要实施维护任务并且能够实施维护任务时，LCM 500可以尝试获取DKVS 30中的任务的锁，以确保该任务尚未被另一个节点40实施。如果LCM 500能够获得锁，则它继续并实施任务。在计划或定期维护任务的情况下，在一些示例中，每个LCM500可以知道何时应该基于LCM程序指令501中指定的调度来实施这样的任务。在计划外任务的情况下(例如，修复错误、故障、其他情况)，可以通过监控平台100的状态由LCM 500中的任何一个检测引起任务的条件。如本文所使用的，平台100的状态可以包括平台100的配置(例如，多少个节点，节点分配了什么角色，什么服务被激活以及在哪些节点上等)以及平台100的健康(例如，有没有任何节点或服务经历错误或故障或其他不健康状况)两者。
例如，LCM 500可以执行图7中示出的示例操作。
在框616中，LCM 500确定是否需要实施维护任务(计划的或反应的)。特别地，LCM500可以通过监控任务调度或队列和/或监控平台100的状态来确定是否需要实施维护任务。例如，LCM 500可以通过监控在LCM程序指令501中指定的任务的调度和/或在DKVS 30中保持的任务队列来确定是否需要实施计划的维护任务。另外，LCM 500可以通过监控平台100的状态来决定是否需要实施反应维护任务。例如，LCM 500可以基于平台100的当前状态周期性地决定是否存在可以采取来改善平台100的状态的任何动作。如果存在这样的动作，则LCM 500可以考虑将该动作为需待实施的维护任务。可以改善平台的检测动作可以包括检测对平台100产生不利影响的错误、故障或其他情况，并且如果检测到这种情况，则自动地确定是否可以采取动作来(完全或部分)修复该情况。当LCM 500已经识别出需待实施的维护任务时，LCM 500前进到框617。
例如，假设节点40上的服务经历错误或发生完全故障。这样的发生事件可以作为保证(warrant)修复动作的情况被另一个节点40的LCM 500检测到，然后检测LCM 500可以确定将改善平台100(即，修复故障)的动作，诸如激活另一个节点40上的故障服务的另一个实例。因此，LCM 500可以将激活故障服务的另一个实例识别为需待实施的维护任务，并且可以进行到该任务上的框617。
作为另一个示例，假设整个节点40发生故障或否则与平台的其余部分断开连接。这样的发生事件可以作为保证修复动作的情况被另一个节点40的LCM 500检测到，然后检测LCM 500可以确定将改善平台100(即，修复故障)的动作，诸如成员节点40将其自身重新配置为特定角色和/或承担先前由故障节点40服务的负载的一部分。因此，LCM 500可以将重新配置成指定角色识别为需待实施的维护任务，并且可以进行到该任务上的框617。LCM500还可以将承担先前由故障节点40服务的负载的一部分识别为需待实施的另一个维护任务，并且可以进行到该任务上的框617。注意，该示例与上述缩放功能重叠，因为节点40的故障是缩放事件的一个示例。换句话说，在一些情况下，识别缩放事件并且响应于缩放事件确定需要重新配置(参见图6的框610-613)可以是确定需要实施维护任务的示例(图7的框616)。
作为另一个示例，定期维护任务可以包括询问库存发现源以查看是否已经对平台100的库存或资源包络进行了改变。每个节点40的LCM 500可以例如通过咨询任务调度知道何时该周期性任务应该实施。当实施任务的时间到达时，注意到该事实的LCM 500中的第一个可以确定需要实施维护任务，并且可以进行到框617。
在框617中，LCM 500确定DKVS 30的任务队列中的锁是否可用于框616中识别的任务。可以这样做以确保在同一时间多个节点40不尝试实施同样的任务。在一些示例中，在框616中识别的任务可能尚未列在DKVS 30的任务队列中(例如，如果LCM 500是第一个识别反应任务的话)，在这种情况下确定锁是否可用可包括将维护任务发布到DKVS 30中的任务队列。如果任务已经被另一个节点40保留(即，锁不可用)，则LCM 500可以返回到框616以继续监控其他维护任务。在一些示例中，LCM 500可以在返回到框616之前等待预定量的时间。如果锁可用，则LCM 500可以继续到框618。
在框618中，LCM 500获得维护任务的锁，然后实施该任务。应理解，在一些示例中，确定锁是否可用并且获得锁可以作为相同操作的部分来实施(例如，可以通过尝试获得锁来确定锁是否可用，其中得到锁指示锁可用，并且无法获得锁指示锁不可用)。
在一些示例中，在框616或617中，LCM 500还可以确定其节点40是否将能够实施任务。例如，如果节点40太忙，不具有授权等，则节点40可能无法实施任务。如果节点40能够实施动作，则LCM 500可以如上面描述的那样继续到框617或618。然而，如果节点40不能实施动作，则LCM 500可以循环回到框616并监控其他任务而不获得锁或实施任务。在一些示例中，即使节点40不能实施任务，在框617中LCM 500仍然可以检查DKVS 30以验证任务被包括在任务队列中，并且如果不是，则LCM 500可以将任务发布到任务队列。
在框616中，在一些情况下，LCM 500可以确定不能采取动作来修复所识别的状况。例如，LCM 500可能不知道针对该状况的任何修复动作。作为另一个示例，LCM 500可能知道修复动作，但是根据平台100的当前状态，修复动作当前可能是不可能的。在一些示例中，当LCM 500确定不能采取动作来修复状况时，则LCM 500不识别维护任务。
在一些示例中，当LCM 500识别出可以采取将修复所识别的状况的动作时，在某些情况下，LCM 500可以简单地自己实施动作而不是尝试获得锁以实施动作。特别地，可以实施一些不是竞争性的动作而无需获得DKVS 30中的锁。在该上下文下，如果多于一个节点40实施动作是可接受的，则该动作不是竞争性的。因为非竞争性动作可以(并且在某些情况下应该)由多个节点40实施，所以不需要经由锁定机制为一个节点40保留动作。非竞争性动作的示例是节点40重新配置其自己的服务中的一种或多种以反映另一个节点40上的另一个服务的变化，诸如另一个服务的位置的变化(一些服务取决于其他服务的位置和配置)。这样的动作不是竞争性的，因为每个节点40响应于这样的事件而重新配置其自己的服务是可接受的(在某些情况下，是期望的)。
5-示例处理器可执行指令
图8示出存储在非暂时性机器可读介质5000上的示例处理器可执行指令。特别地，生命周期管理器(LCM)程序指令501存储在介质5000上。
LCM指令501可以包括在被执行时实例化上面描述的LCM 500的指令。特别地，LCM指令501可以包括实施上面描述为由LCM 500实施的任何或所有操作的指令，包括例如图4-图8中示出的任何示例操作。
例如，LCM指令501可以包括初始设置指令502、集成指令503、缩放指令504和维护指令505。初始设置指令502可以包括实施图4的操作的指令。集成指令503可以包括实施图5的操作的指令。缩放指令504可以包括实施图6的操作的指令。维护指令505可以包括实施图7的操作的指令。
例如，初始设置指令502可以包括指令，该指令使节点40响应于接收到平台集群创建请求而自动地：建立包括节点40作为成员的云平台100；并且邀请其他节点40加入云平台100。在一些示例中，平台100的建立包括自动地建立用于在节点40之间传送平台100的状态的分布式密钥值集群。
例如，集成指令503可以包括使节点40响应于接收到加入云平台100的邀请而自动地将相应节点40集成到云平台100中的指令。在一些示例中，将相应节点40自动地集成到云平台100中包括自动地加入与云平台100相关联的分布式密钥值集群。在一些示例中，将相应节点40自动地集成到云平台100中包括基于云平台100的当前配置自动地确定在相应节点40上激活云平台100的哪些服务。在一些示例中，确定在相应节点40上激活云平台100的哪些服务包括自动地：基于第二云平台100的当前配置识别相应节点40的角色，并选择激活与所识别的角色相关联的云平台100的那些服务。
例如，缩放指令504可以包括指令，该指令使节点40响应于检测到云平台100的配置的变化而自动地：确定改变相应节点40的角色是否将改善平台100的配置，并且响应于确定改变相应节点40的角色将改善平台的配置，尝试改变相应节点40的角色。
例如，维护指令505可以包括指令，该指令使节点40监控平台100的状态，基于该状态确定是否存在将改善平台100的状态的动作，并且响应于识别出将改善平台100的状态的动作，尝试实施该动作。在一些示例中，维护指令505可以包括指令，该指令使节点40响应于检测到平台100的给定服务的健康的变化而自动地确定相应节点40是否应该激活给定服务。在一些示例中，维护指令505可以包括指令，该指令使节点40自动地：监控平台100的平台任务列表以用于需待实施的维护任务，并且响应于识别出需待实施的维护任务，尝试实施该维护任务。
6-其他定义
如本文所使用的，“提供”项目意味着拥有和/或控制项目。这可以包括，例如，从其构成材料形成(或组装)一些或全部项目和/或获得对已经形成的项目的拥有和/或控制。
在本公开通篇和所附权利要求中，偶尔可能提及“多个”项目。对“多个”的这种提及意味着任何大于或等于1的整数。当以这种方式使用“多个”时，为了语法一致性，描述项目的单词可以以复数形式书写，但是这不一定意味正在提及多个项目。因此，例如，尽管使用了复数形式，诸如“多个有源光学装置，其中有源光学装置......”的短语可以包含一个有源光学装置和多个有源光学装置两者。
在提及一些项目时可能使用短语“多个”的事实不应被解释为意味着当提及另一个项目时省略短语“多个”就意味着该项目一定是单数或一定是复数。
特别地，当使用冠词“一”和“所述”提及项目而没有任何明确的单数或多数的指示时，这应该被理解为意味着存在该项目中的“至少一个”，除非另有明确说明。当以这种方式使用这些冠词时，为了语法一致性，描述项目的词语可以以单数形式书写，并且对项目随后的提及可以包括定代词“所述”，但这并不一定意味着只有一个项目被提及。因此，例如，尽管使用了单数形式和定代词，诸如“光学插座，其中所述光学插座......”的短语可以包含一个光学插座和多个光学插座两者。
有时，短语“和/或”在本文中与项目列表结合使用。该短语意味着可以包括列表中的项目的任何组合(从单个项目到所有项目以及其间的任何排列)。因此，例如，“A、B和/或C”意味着“{A}、{B}、{C}、{A，B}、{A，C}、{C，B}和{A，C，B}中的一个”。
以上参考各种示例的流程图描述了各种示例的过程。在说明书和所示的流程图中，为了便于描述，以特定顺序阐述操作。然而，应理解，一些或所有操作可以以与所描述的顺序不同的顺序实施，并且一些或所有操作可以同时(即，并列)实施。
虽然已经参考前述示例示出和描述了以上公开，但是应理解，在不脱离本公开的精神和范围的情况下，可以做出其他形式、细节和实施方案。

Claims (20)

1.一种系统，包括：
多个节点，每个节点包括处理器和存储操作系统映像的副本的非暂时性机器可读介质，
其中所述操作系统映像的每个副本包括：
云平台应用的最小工件集；和
生命周期管理器程序指令，在由所述节点中的任一个执行时实例化相应节点的生命周期管理器，所述生命周期管理器用于：
响应于接收到平台集群创建请求，自动地：
建立包括作为唯一成员的所述相应节点的、所述云平台应用的云平台；并且
邀请其他节点加入所述云平台；并且
响应于接收到加入由所述节点中的另一个建立的、所述云平台应用的已建立的云平台的邀请，自动地将所述相应节点集成到所述已建立的云平台中。
2.如权利要求1所述的系统，
其中所述生命周期管理器用于在建立所述云平台时自动地建立用于在所述节点之间传送所述云平台的状态的分布式密钥值集群。
3.如权利要求1所述的系统，
其中所述生命周期管理器用于在将所述相应节点集成到所述已建立的云平台中时自动地加入与所述已建立的云平台相关联的分布式密钥值集群。
4.如权利要求1所述的系统，
其中所述生命周期管理器用于在将所述相应节点集成到所述已建立的云平台中时基于所述已建立的云平台的当前配置来自动地确定在所述相应节点上激活所述云平台应用的哪些服务。
5.如权利要求1所述的系统，
其中所述生命周期管理器用于在将所述相应节点集成到所述已建立的云平台中时自动地：
基于所述已建立的云平台的所述当前配置和期望配置来识别所述相应节点的角色，并且
选择在所述相应节点中激活与所识别的角色相关联的、所述云平台应用的那些服务。
6.如权利要求1所述的系统，
其中所述生命周期管理器用于在集成到所述已建立的云平台时自动地监控将被实施的维护任务，并且响应于识别将被实施的维护任务，尝试通过所述已建立的云平台的分布式密钥值库来保留所述维护任务。
7.如权利要求6所述的系统，
其中所述生命周期管理器用于在监控将被实施的维护任务时自动地监控所述已建立的云平台的任务队列，以获得需将被实施的维护任务。
8.如权利要求6所述的系统，
其中所述生命周期管理器用于在监控将被实施的维护任务时自动地监控所述已建立的云平台的状态，并基于所述已建立的云平台的所述状态检测计划外的维护任务。
9.如权利要求1所述的系统，
其中所述生命周期管理器用于监控缩放事件，并且响应于检测到缩放事件，自动地确定所述相应节点是否以及如何应该根据所述缩放事件重新配置所述相应节点自身。
10.如权利要求1所述的系统，
其中所述生命周期管理器用于在集成到所述已建立的云平台时，响应于检测到所述已建立的云平台的给定服务的状态变化而自动地确定所述相应节点是否应该根据所述给定服务的所述状态变化采取动作。
11.一种存储操作系统映像的非暂时性机器可读介质，包括：
云平台应用的最小工件集；和
生命周期管理器程序指令，在由节点的处理器执行时使所述节点实例化生命周期管理器，所述生命周期管理器用于：
响应于接收到云平台创建请求，自动地：
建立包括作为唯一成员的所述节点的、所述云平台应用的云平台；并且
邀请其他节点加入第一云平台；
响应于接收到加入所述云平台应用的已建立的云平台的邀请，自动地将所述节点集成到所述已建立的云平台中。
12.如权利要求11所述的非暂时性机器可读介质，
其中所述生命周期管理器用于在将所述节点自动地集成到所述已建立的云平台中时，基于所述已建立的云平台的当前配置来自动地确定在所述相应节点上激活所述云平台应用的哪些服务。
13.如权利要求11所述的非暂时性机器可读介质，
其中所述生命周期管理器用于在将所述节点集成到所述已建立的云平台中时自动地：
基于所述已建立的云平台的所述当前配置和期望配置来识别所述节点的角色，并且
选择在所述节点中激活与所识别的角色相关联的、所述云平台应用的那些服务。
14.如权利要求11所述的非暂时性机器可读介质，
其中所述生命周期管理器用于在集成到所述已建立的云平台时自动地监控将被实施的维护任务，并且响应于识别将被实施的维护任务，尝试通过所述已建立的云平台的分布式密钥值库来保留所述维护任务。
15.如权利要求11所述的非暂时性机器可读介质，
其中所述生命周期管理器用于监控缩放事件，并且响应于检测到缩放事件，自动地确定所述相应节点是否以及如何应该根据所述缩放事件重新配置所述相应节点自身。
16.一种方法，包括：
生成操作系统映像，所述操作系统映像包括云平台应用的最小工件集和用于实例化生命周期管理器的机器可读指令；
在多个节点上安装所述操作系统映像的副本，每个节点包括处理器和非暂时性机器可读介质；以及
向所述节点中的一个发送云平台创建请求，
其中，针对所述节点中的每个，所述生命周期管理器用于：
响应于接收到所述云平台创建请求，自动地：
建立包括作为唯一成员的相应节点的、所述云平台应用的云平台；并且
邀请其他节点加入所述云平台；
响应于接收到加入由所述节点中的另一个建立的、所述云平台应用的已建立的云平台的邀请，自动地将所述相应节点集成到所述已建立的云平台中。
17.如权利要求16所述的方法，
其中所述生命周期管理器用于在将所述节点自动地集成到所述已建立的云平台中时，基于所述已建立的云平台的当前配置来自动地确定在所述相应节点上激活所述云平台应用的哪些服务。
18.如权利要求16所述的方法，
其中所述生命周期管理器用于在将所述节点集成到所述已建立的云平台中时自动地：
基于所述已建立的云平台的所述当前配置和期望配置来识别所述节点的角色，并且
选择在所述节点中激活与所识别的角色相关联的、所述云平台应用的那些服务。
19.如权利要求16所述的方法，
其中所述生命周期管理器用于在集成到所述已建立的云平台时自动地监控将被实施的维护任务，并且响应于识别将被实施的维护任务，尝试通过所述已建立的云平台的分布式密钥值库来保留所述维护任务。
20.如权利要求16所述的方法，
其中所述生命周期管理器用于监控缩放事件，并且响应于检测到缩放事件，自动地确定所述相应节点是否以及如何应该根据所述缩放事件重新配置所述相应节点自身。
CN201811563133.4A 2017-12-20 2018-12-20 用于云平台的分布式生命周期管理 Active CN109947557B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/849,203 US10587463B2 (en) 2017-12-20 2017-12-20 Distributed lifecycle management for cloud platforms
US15/849,203 2017-12-20

Publications (2)

Publication Number Publication Date
CN109947557A true CN109947557A (zh) 2019-06-28
CN109947557B CN109947557B (zh) 2023-09-29

Family

ID=64746133

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811563133.4A Active CN109947557B (zh) 2017-12-20 2018-12-20 用于云平台的分布式生命周期管理

Country Status (3)

Country Link
US (2) US10587463B2 (zh)
EP (1) EP3502893B1 (zh)
CN (1) CN109947557B (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111610985A (zh) * 2020-05-13 2020-09-01 麒麟软件有限公司 一种国产平台上的kubernetes集群快速部署方法
WO2021109750A1 (zh) * 2019-12-02 2021-06-10 中兴通讯股份有限公司 节点管理方法、装置、设备、存储介质和系统
CN113032361A (zh) * 2021-03-11 2021-06-25 北京三快在线科技有限公司 一种数据库配置的变更方法、装置、电子设备及存储介质

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10671143B2 (en) * 2018-01-11 2020-06-02 Red Hat Israel, Ltd. Power management using automation engine
US11436113B2 (en) * 2018-06-28 2022-09-06 Twitter, Inc. Method and system for maintaining storage device failure tolerance in a composable infrastructure
WO2020117684A1 (en) 2018-12-03 2020-06-11 Salesforce.Com, Inc. Testing engine for automated operations management
GB2592631B (en) * 2020-03-04 2022-03-16 Metaswitch Networks Ltd Performing Lifecycle Management
US11620254B2 (en) * 2020-06-03 2023-04-04 International Business Machines Corporation Remote direct memory access for container-enabled networks
US11550633B2 (en) * 2020-10-31 2023-01-10 Nutanix, Inc. Intra-footprint computing cluster bring-up
US11693703B2 (en) 2020-12-09 2023-07-04 Dell Products L.P. Monitoring resource utilization via intercepting bare metal communications between resources
US11934875B2 (en) 2020-12-09 2024-03-19 Dell Products L.P. Method and system for maintaining composed systems
US11698821B2 (en) * 2020-12-09 2023-07-11 Dell Products L.P. Composable information handling systems in an open network using access control managers
US11809912B2 (en) 2020-12-09 2023-11-07 Dell Products L.P. System and method for allocating resources to perform workloads
US11704159B2 (en) 2020-12-09 2023-07-18 Dell Products L.P. System and method for unified infrastructure architecture
US11675625B2 (en) 2020-12-09 2023-06-13 Dell Products L.P. Thin provisioning of resources using SCPS and a bidding system
US11604595B2 (en) 2020-12-09 2023-03-14 Dell Products L.P. Data mirroring and data migration between storage volumes using system control processors
US11675665B2 (en) 2020-12-09 2023-06-13 Dell Products L.P. System and method for backup generation using composed systems
US11928515B2 (en) 2020-12-09 2024-03-12 Dell Products L.P. System and method for managing resource allocations in composed systems
US11853782B2 (en) 2020-12-09 2023-12-26 Dell Products L.P. Method and system for composing systems using resource sets
US11809911B2 (en) 2020-12-09 2023-11-07 Dell Products L.P. Resuming workload execution in composed information handling system
US11586466B2 (en) * 2021-01-20 2023-02-21 EMC IP Holding Company LLC Centralized high-availability flows execution framework
US11675916B2 (en) 2021-01-28 2023-06-13 Dell Products L.P. Method and system for limiting data accessibility in composed systems
US11797341B2 (en) 2021-01-28 2023-10-24 Dell Products L.P. System and method for performing remediation action during operation analysis
US11687280B2 (en) 2021-01-28 2023-06-27 Dell Products L.P. Method and system for efficient servicing of storage access requests
US11768612B2 (en) 2021-01-28 2023-09-26 Dell Products L.P. System and method for distributed deduplication in a composed system
US11265236B1 (en) 2021-02-08 2022-03-01 Sap Se On-demand outages notification in a cloud environment
US11595280B2 (en) 2021-02-08 2023-02-28 Sap Se Detecting outages in a cloud environment
US11570074B2 (en) 2021-02-08 2023-01-31 Sap Se Detecting outages in a multiple availability zone cloud environment
US11570075B2 (en) 2021-02-08 2023-01-31 Sap Se Reverse health checks
WO2022183245A1 (en) * 2021-03-04 2022-09-09 Lorenzo Modesto A hyper-scale cloud environment standard control deviation remediation application
US20230004413A1 (en) * 2021-07-02 2023-01-05 Vmware, Inc. Distributed autonomous lifecycle management of hypervisors in a virtualized computing system
US11740976B2 (en) * 2021-07-15 2023-08-29 Cisco Technology, Inc. Crash-consistent clone generation in a distributed file system
US11947697B2 (en) 2021-07-22 2024-04-02 Dell Products L.P. Method and system to place resources in a known state to be used in a composed information handling system
US11928506B2 (en) 2021-07-28 2024-03-12 Dell Products L.P. Managing composition service entities with complex networks
US11900172B2 (en) 2021-07-30 2024-02-13 Nutanix, Inc. Computing cluster bring-up on public cloud infrastructure using expressed intents
WO2023229691A1 (en) * 2022-05-25 2023-11-30 Hewlett Packard Enterprise Development Lp System wear leveling

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102404385A (zh) * 2011-10-25 2012-04-04 华中科技大学 面向高性能计算的虚拟集群部署系统和部署方法
US20120102486A1 (en) * 2011-12-22 2012-04-26 Software Ag Distributed cloud application deployment systems and/or associated methods
CN102831156A (zh) * 2012-06-29 2012-12-19 浙江大学 一种云计算平台上的分布式事务处理方法
WO2014121510A1 (zh) * 2013-02-08 2014-08-14 华为技术有限公司 实现云计算网络防攻击的方法、设备和网络
CN105144138A (zh) * 2013-04-16 2015-12-09 惠普发展公司，有限责任合伙企业 分布式事件关联系统
US20160254957A1 (en) * 2013-10-30 2016-09-01 Hewlett Packard Enterprise Development Lp Facilitating autonomous computing within a cloud service
CN106101212A (zh) * 2016-06-08 2016-11-09 四川新环佳科技发展有限公司 云平台下的大数据访问方法
US20160366233A1 (en) * 2015-06-10 2016-12-15 Platform9, Inc. Private Cloud as a service
US20170093964A1 (en) * 2015-09-25 2017-03-30 International Business Machines Corporation Self-expanding software defined computing cluster
CN106850269A (zh) * 2016-12-29 2017-06-13 曙光信息产业(北京)有限公司 一种云平台的管理系统
CN107426034A (zh) * 2017-08-18 2017-12-01 国网山东省电力公司信息通信公司 一种基于云平台的大规模容器调度系统及方法

Family Cites Families (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6047323A (en) * 1995-10-19 2000-04-04 Hewlett-Packard Company Creation and migration of distributed streams in clusters of networked computers
US6460082B1 (en) * 1999-06-17 2002-10-01 International Business Machines Corporation Management of service-oriented resources across heterogeneous media servers using homogenous service units and service signatures to configure the media servers
US9081620B1 (en) * 2003-09-11 2015-07-14 Oracle America, Inc. Multi-grid mechanism using peer-to-peer protocols
CN100340084C (zh) * 2004-04-28 2007-09-26 联想(北京)有限公司 一种实现设备分组及分组设备间交互的方法
US7978631B1 (en) * 2007-05-31 2011-07-12 Oracle America, Inc. Method and apparatus for encoding and mapping of virtual addresses for clusters
US8886609B2 (en) * 2010-12-17 2014-11-11 Microsoft Corporation Backup and restore of data from any cluster node
US8997078B2 (en) * 2011-04-12 2015-03-31 Pivotal Software, Inc. Release lifecycle management system for a multi-node application
US9641394B2 (en) * 2012-01-30 2017-05-02 Microsoft Technology Licensing, Llc Automated build-out of a cloud-computing stamp
US9047133B2 (en) 2012-03-02 2015-06-02 Vmware, Inc. Single, logical, multi-tier application blueprint used for deployment and management of multiple physical applications in a cloud environment
EP2859460A4 (en) 2012-06-08 2016-01-06 Hewlett Packard Development Co TESTING AND MANAGING CLOUD COMPUTING APPLICATIONS
EP2859439A4 (en) * 2012-06-08 2016-03-30 Hewlett Packard Development Co CLOUD APPLICATION DEPLOYMENT
US9363270B2 (en) * 2012-06-29 2016-06-07 Vce Company, Llc Personas in application lifecycle management
WO2014058411A1 (en) 2012-10-08 2014-04-17 Hewlett-Packard Development Company, L.P. Hybrid cloud environment
US9658983B1 (en) * 2012-12-14 2017-05-23 Amazon Technologies, Inc. Lifecycle support for storage objects having multiple durability levels specifying different numbers of versions
CN103164286A (zh) * 2013-03-12 2013-06-19 无锡云动科技发展有限公司 云计算平台部署的实现方法、资源管理器、云计算系统
EP3063655A4 (en) * 2013-10-30 2017-08-30 Hewlett-Packard Enterprise Development LP Management of the lifecycle of a cloud service modeled as a topology
US10476760B2 (en) * 2013-10-30 2019-11-12 Oracle International Corporation System and method for placement logic in a cloud platform environment
EP3063657B1 (en) * 2013-10-30 2021-12-01 Hewlett Packard Enterprise Development LP Monitoring a cloud service modeled as a topology
US9817703B1 (en) * 2013-12-04 2017-11-14 Amazon Technologies, Inc. Distributed lock management using conditional updates to a distributed key value data store
US10235404B2 (en) * 2014-06-25 2019-03-19 Cohesity, Inc. Distributed key-value store
WO2016025321A1 (en) 2014-08-13 2016-02-18 OneCloud Labs, Inc. Replication of virtualized infrastructure within distributed computing environments
US10346267B2 (en) * 2014-10-31 2019-07-09 Red Hat, Inc. Registering data modification listener in a data-grid
US9762585B2 (en) * 2015-03-19 2017-09-12 Microsoft Technology Licensing, Llc Tenant lockbox
US9954949B2 (en) * 2015-04-30 2018-04-24 Hewlett Packard Enterprise Development Lp Cloud images
US9848041B2 (en) * 2015-05-01 2017-12-19 Amazon Technologies, Inc. Automatic scaling of resource instance groups within compute clusters
US10079880B2 (en) * 2015-06-07 2018-09-18 Apple Inc. Automatic identification of invalid participants in a secure synchronization system
US9921885B2 (en) * 2015-06-19 2018-03-20 Vmware, Inc. Resource management for containers in a virtualized environment
US10073689B2 (en) * 2015-07-31 2018-09-11 Cisco Technology, Inc. Managing application lifecycles within a federation of distributed software applications
US10303461B2 (en) * 2015-09-30 2019-05-28 Oracle International Corporation Composite instance patching
US20180006881A1 (en) * 2016-06-30 2018-01-04 Microsoft Technology Licensing, Llc Fault-Tolerant Configuration of Network Devices
US20180173526A1 (en) * 2016-12-20 2018-06-21 Invensys Systems, Inc. Application lifecycle management system
US11146620B2 (en) * 2017-09-14 2021-10-12 Cisco Technology, Inc. Systems and methods for instantiating services on top of services
US10721095B2 (en) * 2017-09-26 2020-07-21 Oracle International Corporation Virtual interface system and method for multi-tenant cloud networking
US10728135B2 (en) * 2017-10-13 2020-07-28 Keysight Technologies, Inc. Location based test agent deployment in virtual processing environments
US10534629B1 (en) * 2017-10-31 2020-01-14 EMC IP Holding Company LLC Virtual data management services

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102404385A (zh) * 2011-10-25 2012-04-04 华中科技大学 面向高性能计算的虚拟集群部署系统和部署方法
US20120102486A1 (en) * 2011-12-22 2012-04-26 Software Ag Distributed cloud application deployment systems and/or associated methods
CN102831156A (zh) * 2012-06-29 2012-12-19 浙江大学 一种云计算平台上的分布式事务处理方法
WO2014121510A1 (zh) * 2013-02-08 2014-08-14 华为技术有限公司 实现云计算网络防攻击的方法、设备和网络
CN105144138A (zh) * 2013-04-16 2015-12-09 惠普发展公司，有限责任合伙企业 分布式事件关联系统
US20160254957A1 (en) * 2013-10-30 2016-09-01 Hewlett Packard Enterprise Development Lp Facilitating autonomous computing within a cloud service
US20160366233A1 (en) * 2015-06-10 2016-12-15 Platform9, Inc. Private Cloud as a service
US20170093964A1 (en) * 2015-09-25 2017-03-30 International Business Machines Corporation Self-expanding software defined computing cluster
CN106101212A (zh) * 2016-06-08 2016-11-09 四川新环佳科技发展有限公司 云平台下的大数据访问方法
CN106850269A (zh) * 2016-12-29 2017-06-13 曙光信息产业(北京)有限公司 一种云平台的管理系统
CN107426034A (zh) * 2017-08-18 2017-12-01 国网山东省电力公司信息通信公司 一种基于云平台的大规模容器调度系统及方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
张新朝等: "基于OpenStack云平台虚拟集群环境的部署", 《闽南师范大学学报(自然科学版)》 *
张新朝等: "基于OpenStack云平台虚拟集群环境的部署", 《闽南师范大学学报(自然科学版)》, no. 01, 30 March 2015 (2015-03-30) *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021109750A1 (zh) * 2019-12-02 2021-06-10 中兴通讯股份有限公司 节点管理方法、装置、设备、存储介质和系统
CN111610985A (zh) * 2020-05-13 2020-09-01 麒麟软件有限公司 一种国产平台上的kubernetes集群快速部署方法
CN111610985B (zh) * 2020-05-13 2023-05-05 麒麟软件有限公司 一种国产平台上的kubernetes集群快速部署方法
CN113032361A (zh) * 2021-03-11 2021-06-25 北京三快在线科技有限公司 一种数据库配置的变更方法、装置、电子设备及存储介质
CN113032361B (zh) * 2021-03-11 2022-12-30 北京三快在线科技有限公司 一种数据库配置的变更方法、装置、电子设备及存储介质

Also Published As

Publication number Publication date
US11424981B2 (en) 2022-08-23
US10587463B2 (en) 2020-03-10
US20200177451A1 (en) 2020-06-04
US20190190778A1 (en) 2019-06-20
CN109947557B (zh) 2023-09-29
EP3502893A1 (en) 2019-06-26
EP3502893B1 (en) 2020-09-09

Similar Documents

Publication Publication Date Title
CN109947557A (zh) 用于云平台的分布式生命周期管理
US11593149B2 (en) Unified resource management for containers and virtual machines
CN105389243B (zh) 一种容器监控方法和装置
CN104081353B (zh) 可缩放环境中的动态负载平衡
CN102103518B (zh) 一种在虚拟化环境中管理资源的系统及其实现方法
US10783046B2 (en) Executing resource management operations in distributed computing systems
US10387179B1 (en) Environment aware scheduling
US11520506B2 (en) Techniques for implementing fault domain sets
CN109313564A (zh) 用于支持多个不同租户的高度可用虚拟桌面的服务器计算机管理系统
US20070206611A1 (en) Effective high availability cluster management and effective state propagation for failure recovery in high availability clusters
US20060095435A1 (en) Configuring and deploying portable application containers for improved utilization of server capacity
EP2791786A1 (en) Increasing availability of stateful applications
EP1665047A2 (en) Managing processing within computing environments including initiation of virtual machines
WO2013122815A1 (en) Coordination of processes in cloud computing environments
US11726764B2 (en) Upgrade systems for service domains
US9959157B1 (en) Computing instance migration
JP5476481B2 (ja) ノード故障の対処
Perarnau et al. Distributed monitoring and management of exascale systems in the Argo project
CN106296530A (zh) 针对非聚合基础设施的信任覆盖
CN104350464B (zh) 虚拟化集成调用以提供对虚拟命名空间中的资源的访问权
WO2012164570A1 (en) Method of managing usage rights iν a share group of servers
CN111221620B (zh) 存储方法、装置及存储介质
US20230161643A1 (en) Lifecycle management for workloads on heterogeneous infrastructure
US11689578B2 (en) System and method for embedding external infrastructure services into management nodes
US9256857B2 (en) Scheduling start-up and shut-down of mainframe applications using topographical relationships

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant