Provisioning applications using an active and available inventory

Abstract

A computer system pulls observability data (metrics, logs, events, alerts, inventory) for multiple components from a remote server, which may be part of a cloud computing platform. The components may be application instances, containers, storage volumes, pods, or other components. The computer system derives utilization metrics for each component and for each of one or more types of computing resources (compute, memory, and storage). The utilization metrics are compared to the available inventory of computing resources to obtain an active and available inventory (AAI). Components may be redeployed and allocated reduced computing resources based on the AAI. Components may be grouped into clusters, and components may be consolidated into a reduced number of clusters based on the AAI. Applications may be provisioned and deployed on clusters in groups of different types (points, triangles, lines, graphs) with different runtime requirements based on location, latency, hardware resources, and / or round-robin allocation.

Description

[Technical Field]

[0001] This invention relates to provisioning applications using an active and available inventory. [Background technology]

[0002] Whether it's processing e-commerce, streaming content, providing backend data management for mobile applications, or any other service, modern enterprises require massive computing resources, including processor time, memory, and persistent data storage. The amount of computing resources changes over time. Modern computing environments can dynamically scale up and down to adapt to changing usage. Kubernetes, for example, is a common orchestrator for adding and removing application instances based on usage. Modern computing environments can be managed by many people, further increasing the opportunities to add or remove application instances and other components of the computing environment.

[0003] Enabling automated application deployment in complex computing environments would represent an advancement in this field. [Overview of the project] [Means for solving the problem]

[0004] The device comprises a computing device including one or more processing devices and one or more memory devices operably coupled to one or more processing devices. The one or more memory devices, when executed by one or more processing devices, store executable code that causes one or more processing devices to receive specifications for one or more application instances, including both (a) one or more computing resource requirements and (b) one or more cluster runtime requirements. The executable code causes one or more processing devices to identify one or more clusters of one or more hosts that satisfy (a) and (b) for each application instance of one or more application instances, and to deploy one or more application instances to one or more hosts.

[0005] To facilitate understanding of the advantages of the present invention, a more specific description of the invention, which has been briefly outlined above, is provided by reference to specific embodiments shown in the accompanying drawings. With understanding that these drawings only illustrate typical embodiments of the invention and should therefore not be considered limiting its scope, the invention is described and explained more specifically and in detail by using the accompanying drawings. [Brief explanation of the drawing]

[0006] [Figure 1] Figure 1 is a schematic block diagram of a network environment in which the discovery of an active and available inventory (AAI) can be performed according to one embodiment.

[0007] [Figure 2] Figure 2 is a schematic block diagram showing components for collecting and processing log data according to one embodiment.

[0008] [Figure 3] Figure 3 is a schematic block diagram showing the source of provisioning data according to one embodiment.

[0009] [Figure 4] Figure 4 is a schematic block diagram showing components for processing log data to obtain AAI according to an embodiment.

[0010] [Figure 5] Figure 5 is a process flow diagram of a method for collecting provisioning data according to an embodiment.

[0011] [Figure 6] Figure 6 is a process flow diagram of a method for deriving AAI according to an embodiment.

[0012] [Figure 7] Figure 7 is a schematic block diagram showing the derivation of relationships between components according to an embodiment.

[0013] [Figure 8] Figure 8 is a schematic block diagram of the topology of components in a network environment according to an embodiment.

[0014] [Figure 9] Figure 9 is a process flow diagram of a method for identifying relationships between components according to a manifest and dynamic provisioning data according to an embodiment.

[0015] [Figure 10] Figure 10 is a process flow diagram of a method for identifying session relationships between components according to an embodiment.

[0016] [Figure 11] Figure 11 is a process flow diagram of a method for identifying access relationships between components according to an embodiment.

[0017] [Figure 12]FIG. 12 is a process flow diagram of a method for identifying network relationships according to one embodiment.

[0018] [Figure 13] FIG. 13 is a process flow diagram of a method for generating a topological representation according to one embodiment.

[0019] [Figure 14A] FIG. 14A is an exemplary representation of a topology according to one embodiment.

[0020] [Figure 14B] FIG. 14B is an exemplary diagram of application data according to one embodiment.

[0021] [Figure 14C] FIG. 14C is an exemplary diagram of cluster data according to one embodiment.

[0022] [Figure 14D] FIG. 14D is an exemplary diagram showing the importance of storage volumes according to one embodiment.

[0023] [Figure 15] FIG. 15 is a diagram showing data used to redeploy an application and perform cluster integration according to one embodiment.

[0024] [Figure 16A] FIG. 16A is a diagram showing an exemplary redeployment of an application and cluster integration according to one embodiment. [Figure 16B] FIG. 16B is a diagram showing an exemplary redeployment of an application and cluster integration according to one embodiment. [Figure 16C] FIG. 16C is a diagram showing an exemplary redeployment of an application and cluster integration according to one embodiment.

[0025] [Figure 17A] Figure 17A is a process flow diagram of an exemplary method for performing application redeployment according to one embodiment.

[0026] [Figure 17B] Figure 17B is a process flow diagram of an exemplary method for performing application redeployment according to one embodiment.

[0027] [Figure 18] Figure 18 is a process flow diagram of a method for integrating clusters according to one embodiment of the present invention.

[0028] [Figure 19] Figure 19 is a process flow diagram of a method for identifying candidate cluster mergers.

[0029] [Figure 20] Figure 20 is a schematic block diagram showing a topological modification according to one embodiment.

[0030] [Figure 21] Figure 21 is a process flow diagram of a method for locking a topology according to one embodiment.

[0031] [Figure 22] Figure 22 is a process flow diagram of a method for preventing topology changes according to one embodiment.

[0032] [Figure 23] Figure 23 is a process flow diagram of a method for detecting topology changes according to one embodiment.

[0033] [Figure 24] Figure 24 is a schematic diagram showing the deployment of multiple applications on multiple clusters according to one embodiment.

[0034] [Figure 25] Figure 25 is a schematic block diagram showing a cluster specification according to one embodiment.

[0035] [Figure 26] Figure 26 is a schematic block diagram showing a dot application specification according to one embodiment.

[0036] [Figure 27] Figure 27 is a schematic block diagram showing a triangular application specification according to one embodiment.

[0037] [Figure 28] Figure 28 is a schematic block diagram showing the line application specifications according to one embodiment.

[0038] [Figure 29] Figure 29 is a process flow diagram of a method for provisioning a dot application according to one embodiment.

[0039] [Figure 30] Figure 30 is a process flow diagram of a method for provisioning a triangular application according to one embodiment.

[0040] [Figure 31] Figure 31 is a process flow diagram of a method for provisioning a linear application according to one embodiment.

[0041] [Figure 32] Figure 32 is a process flow diagram of a method for provisioning a graph application according to one embodiment.

[0042] [Figure 33] Figure 33 shows the division of a graph application into line and triangle applications according to one embodiment.

[0043] [Figure 34] Figure 34 is a schematic block diagram of an exemplary computing device suitable for carrying out the method according to an embodiment of the present invention. [Modes for carrying out the invention]

[0044] Figure 1 shows an exemplary network environment 100 in which the systems and methods disclosed herein may be used. The components of the network environment 100 may be connected to one another by networks such as a local area network (LAN), a wide area network (WAN), the internet, a chassis backplane, or other types of networks. The components of the network environment 100 may be connected by wired or wireless network connections.

[0045] The network environment 100 includes multiple servers 102. Each server 102 may include one or more computing devices, such as a computing device having some or all of the attributes of computing device 3400 in Figure 34. Each server 102 lacks an agent to coordinate the execution of management tasks. The systems and methods described herein enable the execution of an active and available inventory (AAI) determination for servers 102 that lack an agent to assist in AAI determination.

[0046] As used herein, “Active and Available Inventory” (AAI) refers to the computing resources available for allocation to application instances. Computing resources include some or all of the storage on the physical storage devices installed in Server 102, the memory of Server 102, the processing cores of Server 102, and the networking bandwidth of network connections between Server 102 and other Server 102 or computing devices.

[0047] Computing resources may also be allocated within a cloud computing platform such as Amazon Web Services (AWS), Google Cloud, Azure, or other cloud computing platforms. Cloud computing resources may include physical storage, processor time, memory, and / or networking bandwidth purchased in units specified by the provider on the cloud computing platform.

[0048] In some embodiments, some or all of the servers 102 can function as edge servers in a telecommunications network. For example, some or all of the servers 102 may be coupled to baseband units (BBUs) 102a that provide conversion between high-frequency signals output and received by antennas 102b and digital data transmitted and received by the servers 102. For example, each BBU 102a may perform this conversion according to a cellular radio data protocol (e.g., 4G, 5G, etc.). Servers 102 functioning as edge servers may have limited or heavy computing resources, making it impractical for them to run agents to collect data for AAI acquisition. Similarly, if there are many servers 102, installing agents for data collection is a time-consuming task.

[0049] The orchestrator 106 provisions computing resources to one or more different application executable file application instances according to a manifest that defines the computing resource requirements for each application instance. The manifest can define dynamic requirements that define scaling up of the number of application instances and corresponding computing resources based on usage. The orchestrator 106 may include or work with utilities such as Kubernetes to perform dynamic scaling up and down of the number of application instances.

[0050] The orchestrator 106 runs on a separate computer system from the server 102 and connects to the server 102 using a network that requires the use of a destination address for communication, such as Ethernet protocol, Internet Protocol (IP), Fibre Channel, or other protocols including any higher-level protocols built on the aforementioned protocols such as User Datagram Protocol (UDP) or Transport Control Protocol (TCP).

[0051] The orchestrator 106 can work with the server 102 to initialize and configure the server 102. For example, each server 102 can work with the orchestrator 106 to obtain a gateway address to be used for outbound communications and a source address assigned to the server 102 for use for inbound communications. The server 102 can work with the orchestrator 106 to install an operating system on the server 102. For example, a gateway address and a source address may be provided, and the operating system may be installed using the method described in U.S. Patent Application No. 16 / 903,266, “AUTOMATED INITIALIZATION OF SERVERS,” filed June 16, 2020, which is incorporated herein by reference in its entirety.

[0052] The orchestrator 106 may be accessible via the orchestrator dashboard 108. The orchestrator dashboard 108 may be implemented as a web server or other server-side application accessible via a browser or client application running on a user computing device 110, such as a desktop computer, laptop computer, mobile phone, tablet computer, or other computing device.

[0053] The orchestrator 106 can work with server 102 to provision computing resources for server 102 and instantiate components of a distributed computing system on server 102 and / or cloud computing platform 104. For example, the orchestrator 106 can take manifests that define the provisioning of computing resources to components such as cluster 111, pod 112 (e.g., Kubernetes pods), container 114 (e.g., DOCKER containers), storage volume 116, and application instance 118, and instantiation of those components. The orchestrator can then allocate computing resources and instantiate the components according to the manifests.

[0054] The manifest can define requirements such as network latency requirements, affinity requirements (same node, same chassis, same rack, same data center, same cloud region, etc.), anti-affinity requirements (different nodes, different chassis, different racks, different data centers, different cloud regions, etc.), as well as minimum provisioning requirements (number of cores, amount of memory, etc.), performance or quality of service (QoS) requirements, or other constraints. Thus, orchestrator 106 can provision computing resources to meet or nearly meet the requirements of the manifest.

[0055] Component instantiation and management may be performed by workflows. A workflow is a set of tasks, executables, configurations, parameters, and other computing functions that are predefined and stored in the workflow repository 120. A workflow may be defined to instantiate each type of component (cluster 111, pod 112, container 114, storage volume 116, application instance, etc.), monitor the performance of each type of component, repair each type of component, upgrade each type of component, replace each type of component, make copies (snapshots, backups, etc.), restore each type of component from copies, and perform other tasks. Some or all of the tasks performed by a workflow may be implemented using Kubernetes or other utilities to perform some or all of the tasks.

[0056] The orchestrator 106 can instruct the workflow orchestrator 122 to perform tasks related to components. In response, the workflow orchestrator 122 retrieves the workflow corresponding to the task (e.g., task type and component type such as instantiation, monitoring, upgrade, replacement, copy, restore) from the workflow repository 120. The workflow orchestrator 122 then selects worker 124 from the worker pool and instructs worker 124 to perform the workflow with respect to server 102 or cloud computing platform 104. The instruction from orchestrator 106 can specify a particular server 102, cloud area or cloud provider, or other location for executing the workflow. Worker 124, which may be a container, then performs the functionality of the workflow with respect to the location instructed by orchestrator 106. In one embodiment, worker 124 can also perform the task of retrieving the workflow from the workflow repository 120 as instructed by the workflow orchestrator 122.

[0057] In one embodiment, the container implementing worker 124 is located remotely from server 102 where worker 124 implements the workflow. Worker 124 can further execute some or all of the workflow even without an agent installed on server 102 or cloud computing platform 104 programmed to work with worker 124 to execute the workflow. For example, worker 124 can establish a secure command-line interface (CLI) connection to server 102 or cloud computing platform 104. For example, it can send commands and verify the completion of commands on server 102 or cloud computing platform 104 using a secure shell (ssh), remote login (rlogin), remote procedure call (RPC), or other interface provided by the operating system of server 102 or cloud computing platform 104.

[0058] One workflow may include monitoring the computing resource usage by each component (hereinafter referred to as the "monitoring workflow"). The monitoring workflow may be periodically invoked by orchestrator 106 for each component, or it may be a persistent process that runs periodically with periods of inactivity in between.

[0059] The monitoring workflow may include establishing a secure connection to each component, reading one or more log files from each component, and passing the log files to the vector log agent 126. The vector log agent 126 can perform initial processing on the data in the log files to obtain enriched data. The processing by the vector log agent 126 may include enriching the data in the log files (for example, providing contextual information such as components, time, source server 102, hosting container 114 identifiers, cluster 111, pod 112, virtual machines, and units of computing resources on the cloud computing platform 104), executing map-reduce functions on messages in the log files, combining messages in the log files into an aggregated representation of messages, and other functions. The vector log agent 126 can process the log files according to one or more vector remapping language (VRL) statements. The vector log agent 126 can run independently of the worker 124, or the monitoring workflow may include running an instance of the vector log agent 126. For example, each monitoring workflow corresponding to the type of component that the monitoring workflow is configured to monitor may include a set of VRL statements. In that case, each monitoring workflow may include processing log files according to the VRL statements of the monitoring workflow.

[0060] The enhanced data output by the vector log agent 126 can be stored in the log store 128. The log processor 130 reads the enhanced data from the log store and derives the Active and Available Inventory (AAI), which is a list of computing resources available for allocation to components. How the log processor 130 obtains the AAI is described in more detail below. The log processor 130 passes the AAI to the orchestrator 106. The orchestrator 106 can use the AAI to perform various functions on components, such as adding, deleting, or redeploying to a different location.

[0061] Figure 2 illustrates the collection of log files 200 from various components. Log files 200 can be collected using the monitoring workflow of each component or other methods for collecting log files. Log files 200 may include log files generated by the operating system 202 running on server 102. Alternatively, the cloud computing platform 104 may generate log files 200 describing the state of units of computing resources and / or executable files running on the cloud computing platform 104. Virtual machines on which components run may also generate log files 200. In the following description, log files 200 are referred to with the understanding that any observable data represented as log files or other formats can be collected and processed in a similar manner. In particular, metrics, events, alerts, inventory, and other data may be collected instead of or in addition to log files 200 and processed in a similar manner to log files 200.

[0062] Cluster 111 is a collection of hosts managed as units (units of servers 102 and / or one or more computing resources on the cloud computing platform). Each host includes a master running on one of the hosts, which manages the deployment of pods 112, containers 114, and application instances 118 on the hosts of the cluster. The master manages scaling up, scaling down, and redeploying the application instances 118. As used herein, actions performed by and on Cluster 111 may be understood as being performed by or on the master that manages Cluster 111. Each Cluster 111 may generate one or more log files 200 that describe the operation of Cluster 111.

[0063] Kubelet204 is a Kubernetes agent that runs on a node and implements instructions from server 102 or cluster 111 on a cloud computing platform to instantiate, monitor, and manage pods 112. Each Kubelet204 can generate one or more log files 200 describing the operation of Kubelet204 and each pod 112 running within it. A pod 112 is a group of one or more containers 114 that have shared storage, network resources, and an execution context. A pod 112 can generate one or more log files 200 describing the state of the pod 112 and the execution of its containers 114. Each container 114 can generate one or more log files 200 describing the execution of the container and any application instances 118 running within it. Each application instance 118 can also generate one or more log files describing the operation of the application instance 118. The storage volume 116 may be a unit of virtualized storage, and the storage manager implementing the storage volume 116 may also generate one or more log files 200 that describe the operation of the storage volume 116.

[0064] Log files 200 are pulled from the server 102 or cloud computing platform 104 where they are stored and processed by the vector log agent 126 to generate enhanced data. The enhanced data is processed by the log processor 130 to obtain the AAI. The orchestrator 106 receives the AAI and manages the provisioning of unused computing resources identified in the AAI for use by the components.

[0065] Referring to Figure 3, the data contained in the log file 200 may be related to provisioning data 300 in order to obtain AAI. Provisioning data 300 includes identifiers of components instantiated by the orchestrator 106 and allocation data indicating the computing resources allocated to each component. For example, on-premises provisioning data 302 may describe provisioning for one or more servers 102. For example, on-premises provisioning data 302 may include multiple entries, each containing a node identifier (i.e., an identifier for server 102), a compute allocation (e.g., the number of processor cores), a memory allocation (e.g., megabytes (MB), gigabytes (GB), or other units of memory), a storage allocation (e.g., megabytes (MB), gigabytes (GB), or other units of storage), and a component identifier to which the allocation belongs (e.g., an identifier for cluster 111, pod 112, container 114, storage volume 116, or application instance 118). Component identifiers may take the form of universally unique identifiers (UUIDs) that are centrally assigned to all components belonging to a common namespace by an orchestrator 106 or other central component. An entry can refer to multiple components. For example, provisioning can be performed at the cluster 111 level so that all pods 112, containers 114, storage volumes 116, and application instances 118 of cluster 111 are referenced in the cluster 111 entry.

[0066] Provisioning data 300 may further include cloud provisioning data 304. Cloud provisioning data 304 may describe provisioning for one or more units of computing resources on the cloud computing platform 104. Cloud provisioning data 304 may include multiple entries, each containing a unit identifier that identifies a unit of cloud computing resources. The identifier of the unit of computing resources may further identify the cloud computing provider (e.g., AWS, Azure, Google Cloud), the area of ​​the cloud computing platform 104, and / or other data. Each entry may further include data describing the compute, memory, and storage allocations. Each entry may further include identifiers of one or more components to which the allocation belongs, as described above with respect to on-premises provisioning data 302.

[0067] Note that the on-premises provisioning data 302 and cloud provisioning data 304 are dynamic. The orchestrator 106 can scale up and down the number of application instances 118 of any given executable file, as well as the number of pods 112, containers 114, and storage volumes 116 used by the application instances.

[0068] In addition to provisioning data 300, AAI may also be determined using other data such as hardware inventory data 306 and cloud inventory data 308. Hardware inventory data 306 may include an entry for each server 102. Each entry may indicate the available compute (e.g., total number of processing cores, graphics processing unit (GPU) cores, or other compute components), memory, and storage on server 102, as well as the node identifier of server 102. Cloud inventory data 308 similarly includes entries that include identifiers for units of cloud computing resources, as well as the available compute, memory, and storage for that unit. Hardware inventory data 306 and cloud inventory data 308 may indicate current availability, i.e., entries may be deleted or flagged as unavailable in response to a server 102 or cloud computing platform 104 referenced by an entry becoming unavailable due to failure or lack of network connectivity. Whether server 102 or cloud computing platform 104 is available can be determined by performing health checks, sending ping messages, measuring traffic latency, detecting failed network connections, or any other method for determining the status and accessibility of computing devices.

[0069] Figure 4 illustrates a method for calculating AAI. Log file 200 contains multiple log messages 400. Each message may contain a text string containing values ​​such as a component identifier and a usage value. The entry identifier may also be obtained from the directory location of the log file or from the name of the log file. The usage value may include an indicator of processor time spent executing the component identified by the entry identifier, the amount of memory occupied by the component identified by the component identifier, and some or all of the amount of storage used (e.g., written) by the component identified by the component identifier. For example, there may be separate entries, each showing distinct information with respect to the component identifier, i.e., one entry showing processor time and another entry showing memory used. In one embodiment, log message 400 contains one or more usage values, and another log message 400 contains a process identifier and a component identifier that runs the process identified by the process identifier.

[0070] Log messages 400 are processed by vector agent 126 to obtain enhanced data 402. For example, items in enhanced data 402 may include a component identifier and its usage metrics (processor time, memory, storage). Vector agent 126 can obtain enhanced data 402 by executing one or more VRL statements on log messages 400. For example, log message 400 that associates a process identifier with a usage value may be mapped by vector agent 126 to a log message that associates the process identifier with a component identifier. Vector agent 126 can execute a map-reduce function to aggregate the usage values ​​into aggregated usage metrics for the component identifier.

[0071] Next, the enhanced data 402 is processed by the log processor 130 together with the provisioning data 300 to obtain the active and available inventory (AAI) 406. For example, the provisioning data 300 may include provisioning entries 404 that include the node identifier of server 102 or the identifier of a unit of computing resources within the cloud computing platform. Each provisioning entry 404 may include a component identifier, i.e., the identifier of a cluster 111, a pod 112, a container 114, a storage volume 116, or an application instance 118. Each provisioning entry 404 may include an allocation, i.e., a value indicating the compute, memory, and / or storage allocated to the component identified by the component identifier.

[0072] Therefore, the log processor 130 can obtain one or more provisioning entries 404 containing component identifiers and entries in enhanced data 402 containing the same component identifiers. For a given computing resource on a host (a unit of computing resources in a server 102 or cloud computing platform 104), U(t,i) represents the utilization rate of that computing resource reported for component i at a given time (t), P(t,i) represents the current allocation of that computing resource to component i, and T represents the inventory of that computing resource available on the host. Therefore, the AAI of that computing resource on the host is

number

number

[0073] Figures 5 and 6 show methods 500 and 600, respectively, that may be performed using the network environment 100 to obtain AAI. Methods 500 and 600 may be performed by one or more computing devices 3400 (see description of Figure 34 below), such as one or more computing devices running the orchestrator 106 and / or log processor 130.

[0074] Specifically, referring to Figure 5, Method 500 may include step 502 to obtain component identifiers for statically defined components, such as those referenced in a manifest taken by Orchestrator 106. Method 500 may also include step 504 to obtain component identifiers for dynamically created components. Dynamically created components may be those instantiated to scale up capacity. Dynamically created components may be created by Orchestrator 106 or KUBERNETES. Component identifiers for dynamically created components can be obtained from log files 200 generated by KUBERNETES, i.e., the KUBERNETES master, Kubelet, or other components of the KUBERNETES installation that perform component instantiation. Note that dynamically created components may also be deleted. Therefore, the current set of component identifiers obtained in steps 502 and 504 may be updated to remove component identifiers for those dynamically deleted due to scaling down, host failure, or other events.

[0075] Method 500 may include a step 506 to obtain static provisioning for each component identifier of each statically defined component, and a step 508 to obtain dynamic provisioning for each component identifier of each dynamically created component. Provisioning for each component identifier may include a host identifier (an identifier for server 102 or a unit of computing resources on the cloud computing platform), as well as an allocation of one or more computing resources (computation power, memory, and / or storage). Method 500 may further include a step to obtain the total available inventory. The total available inventory may include the inventory of each currently available (operating and accessible via network connectivity) host. The inventory of each host may include the total processor cores, memory, and / or storage capacity.

[0076] Referring to Figure 6, method 600 may include step 602 for deriving usage data for each component identifier identified in steps 502 and 504. As described above, step 602 for deriving usage data may include steps of retrieving log file 200, enriching log file 200 to obtain enhanced data 402, and aggregating the enhanced data 402 to obtain usage metrics for each component identifier.

[0077] Method 600 may include step 604 for deriving usage data for each host. For example, the usage metrics for each component running on each host can be aggregated (e.g., summed) to obtain the total metrics for each host, namely total computing power usage, total memory usage, and total storage usage. As used herein, “computing power” may be defined as the amount of processor time used, the number of processor cycles used, and / or the percentage of processor cycles or time used.

[0078] Method 600 may include step 606, which retrieves static and dynamic provisioning data for each component identifier (see descriptions of steps 506 and 508) and an inventory for each host (see description of step 510). The AAI can then be derived (608). As described above, step 608 may include calculating some or all of the AAI(t), O(t, i), and O(t) for each computing resource (computation power, memory, storage) of each host.

[0079] Method 600 may further include step 610 of modifying the provisioning in the network environment 100 using AAI. A non-exclusive list of modifications may include: Provision additional components (cluster 111, pod 112, container 114, storage volume 116, and / or application instance 118) to utilize the computing resources identified in AAI according to the manifest. • Redeploy components to different hosts to more strictly meet performance, quality of service, affinity, anti-affinity, latency, or other requirements outlined in the manifest. Remove components that are not being used sufficiently. Remove underutilized components that are distributed across multiple servers 102 or multiple units of computing resources within the cloud computing platform 104, and redeploy some or all of the underutilized components on a reduced number of hosts. - Redeploy underutilized components (e.g., (O(t,i) / P(t,i))<0.5) to server 102 or cloud computing platform 104, which have higher latency and / or fewer computing resources than the current host of the underutilized component. - Redeploy the overutilized component (e.g., (O(t,i) / P(t,i))<0.9) to server 102, which has lower latency and / or more computing resources than the current host of the overutilized component.

[0080] Referring to Figure 7, the log processor 130, the orchestrator 106, and / or any other component may further process the provisioning data 300 and log files 200 to identify relationships between component identifiers. For example, the provisioning data 300 may indicate a hosting relationship 700. As used herein, “hosting relationship” means a component running on or within another component, such as a server 102, a cluster 111 or pod 112 hosted by a unit of computing resources of the cloud computing platform 104, a container 114 running in the pod 112, or an application instance 118 running in the container. A storage volume 116 may be considered a hosting relationship 700, i.e., a relationship hosted by the container 114 or pod 112 on which the storage volume 116 resides. The hosting relationship 700 may be derived from instructions in a manifest that define the instantiation of a second component on a first component, thereby defining the hosting relationship 700 between the first component and the second component. The hosting relationship may be derived from log file 200 in a similar manner, namely, the record of instantiating the second component on the first component establishes the hosting relationship between the first and second components.

[0081] Provisioning data 300 may further indicate environment variable relationships 702. The manifest may include instructions to configure one or more environment variables of the first component to reference the second component, for example, the first component may be configured to use the services of the second component or to provide services to the second component. Log file 200 may record the configuration of one or more environment variables of the first component to reference the second component in a similar manner.

[0082] Provisioning data 300 may further indicate the network relationship 704. The manifest may include instructions to configure the first component to use an IP address or other type of address belonging to the second component, thereby establishing a network relationship 704 between the first and second components. The log file 200 may similarly record that the first component has been configured to refer to the address of the second component. The step 704 of establishing the network relationship may be a multi-step process comprising: 1) determining that the first component is configured to use a first address; and 2) mapping the first address to an identifier of the second component.

[0083] As described above, provisioning data 300 is dynamic and can change over time. Therefore, some or all of the hosting relationships 700, environment variable relationships 702, and network relationships 704 may be re-derived at a fixed recurring period or in response to the detection of records in log file 200 indicating actions that may affect any of these relationships 702-704.

[0084] The log file 200 may also be evaluated to identify other types of relationships between components. For example, the log file 200 may be evaluated to identify session relationships 706. When a first component establishes a session at the application level to use an application instance 118, which is a second component or is hosted by a second component, one or more log files 200 generated by the second component may record this fact. Thus, to obtain the current session relationships 706 between a pair of components, the log file 200 can be analyzed to identify the creation and termination of sessions.

[0085] Log files 200 may be evaluated to identify access relationships 708. When a first component accesses a session of an application instance 118 that is a second component or is hosted by a second component, one or more log files 200 generated by the second component may record this fact. Access may include generating a request for a service provided by the second component, reading data from the second component, writing data to the second component, or other interactions between the first and second components. Thus, log files 200 can be analyzed to identify access by the first component to the second component. Whether access indicates a current access relationship can be handled in various ways. That is, an access relationship 708 may be created between the first and second components and accessed by the second component in response to identifying a record of access, and this access relationship may (a) be maintained as long as the first and second components exist, or (b) be deleted if no access is recorded in log files 200 over a threshold period.

[0086] The log file 200 may be evaluated to identify network connection relationships 708. For example, when a first component establishes a network connection to a second component, the log files 200 of one or both of the first and second components may record this fact. Thus, by analyzing the log file 200, the establishment of a network connection between the first and second components and the termination of a network connection between the first and second components (if any) can be identified. In this way, all active network connections between components can be identified as network connection relationships 710. A network connection relationship 710 may be created between the first and second components in response to the identification of the creation of a network connection between the first and second components, and the network connection relationship 710 may (a) be maintained as long as the first and second components exist, (b) be deleted when the network connection is terminated, or (c) expire if a new network connection is not established within a threshold time after the termination of the network connection.

[0087] Network connection relationship 710 is sometimes distinguished from network connection relationship 704 in that network connection relationship 710 refers to an actual network connection, whereas network connection relationship 704 refers to configuring the first component using the network address of the second component, regardless of whether a network connection has been established or not. In some embodiments, only network connection relationship 710 is used.

[0088] Referring to Figure 8, the log processor 130, orchestrator 106, and / or any other component may further generate a topology representation 800. The topology 800 can be represented as a graph containing nodes and edges. Each node may also be a component identifier of a component. A component may include a host 802 (e.g., server 102, or a unit of computing resources in a cloud computing platform), a cluster 111, a pod 112, a container 114, a storage volume 116, an application instance 118, or other components. Edges of the topology connect nodes and represent relationships between nodes, such as hosting relationships 700, environment variable relationships 702, network relationships 704, session relationships 706, access relationships 708, and network connectivity relationships 710. Edges may be unidirectional, indicating that a first node depends on a second node to function correctly, but the second node does not depend on the first node. Edges may be bidirectional, indicating that a first node and a second node depend on each other. For example, a hosting relationship 700 may be unidirectional, indicating the dependency of the second component on the first component, which is a host to the second component. Since both components must function for a network connection to exist, a network relationship 704 or network connection relationship 710 may be bidirectional.

[0089] Figure 9 shows a method 900 for processing provisioning data 300. Method 900 may be performed by the log processor 130, the orchestrator 106, and / or any other component. Provisioning data 300 is retrieved (902). The retrieval step 902 may include the step of pulling provisioning data from the manifest ingested by the orchestrator 106 and the step of pulling the log file 200 from the component as described above with respect to Figure 2. The retrieval step 902 may include an augmentation step in which the data from the manifest and / or log file 200 is processed by the vector log agent 126 to add additional information, to perform a map-reduce operation, or to perform other operations. For example, the augmentation step may include adding a source identifier for the log file 200, the directory location of the log file 200, or other data to facilitate associating the data in the log file 200 with a specific component identifier. The retrieval step 902 may include a step of processing the manifest and / or log file 200 according to one or more VRL statements.

[0090] Method 900 may include a step 904 for extracting hosting relationships 700. The step for extracting hosting relationships 700 may include a step for parsing a statement of the form "<instantiation instruction>...<host component identifier>...<hosted component identifier>". For example, there may be a set of keywords indicating an identifiable instantiation, and the identifiers of the host component and the hosted component can be obtained by processing a line of code or log message containing these keywords. Then, a hosting relationship 700 can be created that references the identifiers of the host component and the hosted component.

[0091] Step 904, which extracts hosting relationships, may further include a step of deleting a hosted component or a hosting relationship 700 from which a hosted component has been deleted. Log messages containing instructions to delete a component can be identified, the identifier of the deleted component can be extracted, and any hosting relationships 700 that reference the identifier of the deleted component can be deleted.

[0092] Method 900 may include a step 906 for extracting environment variable relationships 702. The step for extracting environment variable relationships 702 may include a step for parsing a statement of the form "<configuration instruction>...<configured component identifier>...<referenced component identifier>". For example, a set of keywords may be found in an instruction or log message relating to the setting of an environment variable. These keywords can be identified, and the lines of code or log messages containing these keywords can be processed to identify the configured component, i.e., the identifier of the component whose environment variable is set, and the referenced component, i.e., the identifier of the component referenced by the environment variable of the configured component. Then, an environment variable relationship 702 can be created that references the identifiers of the configured component and the referenced component, and optionally one or more environment variables of the configured component, which are configured to reference the referenced component.

[0093] The statement in log file 200 that creates environment variable relation 702 can modify a previously existing environment variable relation. For example, environment variable relation 702 can record the name of an environment variable for a configured component. The first environment variable relation 702 for a configured component, which includes the variable name, may be deleted in response to a subsequently identified environment variable relation 702 for the configured component that references the same variable name. An exception to this technique may be implemented when an environment variable can store multiple values. For example, an explicit delete command containing the variable name, the configured component identifier, and the referenced component identifier is required before deleting environment variable relation 702 containing the variable name, the configured component identifier, and the referenced component identifier.

[0094] Method 900 can include step 908 of extracting network relationship 704. The step of extracting network relationship 704 can include the step of parsing sentences in the form of "<network configuration instruction>...<configured component identifier>...<IP address, domain name, URL, etc.>" and sentences in the form of "<address assignment instruction>…<referenced component identifier>...<IP address, domain name, URL, etc.>", and these sentences may be located at different positions within manifest or log file 200. For example, a set of keywords may be found in instruction sentences or log messages related to assigning a network address to a referenced component and configuring a component configured to communicate with the address of the referenced component. These keywords can be identified, and code lines or log messages containing these keywords can be processed to identify the network addresses and identifiers of the configured component and the referenced component, that is, the referenced component is the component to which the network address is assigned, and the configured component is the component configured to use that network address to send data to and / or receive data from the referenced component.Then, referring to the identifiers of the configured component and the referenced component, network relationship 704 may be created, optionally including the network address. Additional information can include the protocol used, port number, network relationship (e.g., whether the referenced component functions as a network gateway, proxy, etc.).

[0095] Statements in log file 200 may modify the configuration of a configured component so that it uses the network address of a different referenced component. Such statements may be parsed, and a new network relationship 704 may be created in the same manner as described above. Previously created network relationships 704 for a configured component may be deleted or may remain. For example, there may be an explicit instruction to delete the configuration of a configured component so that it uses the network address of a referenced component referenced by a previously created network relationship 704. In response to the recording of the execution of such an instruction, the previously created network relationship 704 may be deleted.

[0096] Figure 10 shows a method 1000 for extracting session relationships 706. Method 1000 may be performed by a log processor 130, an orchestrator 106, and / or any other component. Method 1000 includes a step 1002 for retrieving a log file 200. Step 1002 for retrieving a log file 200 may include a step for pulling the log file 200 from the component as described above with respect to Figure 2. Step 1002 for retrieving may include an enhancement step in which the data from the log file 200 is processed by the vector log agent 126 in order to add additional information, to perform a map-reduce operation, or to perform other operations. For example, the enhancement step may include adding a source identifier for the log file 200, a directory location for the log file 200, or other data to facilitate associating the data in the log file 200 with a specific component identifier. Step 1002 for retrieving may include a step for processing the log file 200 according to one or more VRL statements.

[0097] Method 1000 may include step 1004 of retrieving session setup messages from log file 200 before or after any enhancement step of log file 200. The session setup messages may be messages indicating that the session has started successfully and may include identifiers for server components (i.e., components providing services) and client components (i.e., components requesting services).

[0098] Method 1000 may include step 1006 of retrieving a session termination message from log file 200 before or after any enhancement step of log file 200. The session termination message may indicate that the session has ended in response to any of the following: a command from the client component, a command from the server component, expiration of a timeout period, failure of an intermediate component or network connection between the client component and the server component, restart or failure of the client component or server component, or any other cause. The session termination message may also include identifiers for the server component (i.e., the component providing the service) and the client component (i.e., the component requesting the service). If the session termination is due to a failure (network connection, intermediate component, client component, or server component), only the server component or client component may be referenced in the log message. In such a case, all session relationships referencing the component referenced in the log message may be considered terminated and deleted.

[0099] Method 1000 may include a step 1008 to update session relationship 706 by adding a session relationship 706 corresponding to the session identified in the setup message as being created. Session relationship 706 may include identifiers for server and client components and other information such as a timestamp from the setup message, an identifier for the session itself, the session type, or other data.

[0100] Step 1008, which updates session relationships 706, may include the step of deleting session relationships 706 that correspond to sessions identified as terminated in session termination messages (including failure messages). For example, if a session has a unique session identifier, session relationships 706 containing the session identifier included in the session termination message can be deleted. Alternatively, if a session termination message refers to a set of client identifiers and server component identifiers, session relationships 706 containing the same client identifiers and server component identifiers can be deleted. In some embodiments where a session has a known time to live (TTL), session relationships 706 can be deleted based on the expiration of the TTL, regardless of whether a session termination message corresponding to the session relationship has been received.

[0101] Figure 11 shows a method 1100 for extracting access relationships 708. Method 1100 may be performed by a log processor 130, an orchestrator 106, and / or any other component. Method 1100 includes a step 1102 for retrieving a log file 200. Step 1102 for retrieving a log file 200 may include a step for pulling the log file 200 from the component as described above with respect to Figure 2. Step 1102 for retrieving may include an enhancement step in which the data from the log file 200 is processed by the vector log agent 126 in order to add additional information, to perform a map-reduce operation, or to perform other operations. For example, the enhancement step may include adding a source identifier for the log file 200, a directory location for the log file 200, or other data to facilitate associating the data in the log file 200 with a specific component identifier. Step 1102 for retrieving may include a step for processing the log file 200 according to one or more VRL statements.

[0102] Method 1100 may include step 1104 of extracting access relationships 708 from log file 200 either before or after enriching log file 200. Access relationships 708 can be identified in various ways, such as by parsing log messages in the server component's log file 200 that indicate a request from a client component (i.e., a component requesting a service), log messages in the client component's log file 200 that indicate a request from the client component to the server component, or log messages of another component that store the results of access requests from the client component to the server component. Access relationships 708 may include, for one or both of (a) each request from the client component to the server component and (b) each response from the server component to the client component, an identifier for the server component, an identifier for the client component, and one or more timestamps or other metadata.

[0103] Method 1100 may include step 1106 of identifying expired access relationships 708. Expired access relationships 708 may be defined as those whose most recent timestamp (for requests and / or responses) is older than a threshold time, e.g., one minute, five minutes, one hour, one day, etc. The threshold time may be unique for each type of component; for example, an instance 118 of one application may have a different threshold than an instance of another application. The threshold time may be automatically derived as a multiple of the average time between requests for each client of the server component.

[0104] Next, method 1100 may include a step 1108 to update the access relationships 708 to add the access relationships detected in step 1104. The step 1108 to update the access relationships may include a step to remove expired access relationships. The step 1108 to update the access relationships may include a step 708 to consolidate the access relationships. For example, if a pair of access relationships 708 refer to the same server and client component identifier, the access relationships 708 may be combined into a single access relationship 708 that contains the most recent timestamp of the pair of access relationships 708. The access relationships 708 may contain records of access requests and / or responses between the client and server components, and the records of pairs of access requests are combined during consolidation. Alternatively, each access relationship 708 may contain statistical characteristics of past requests and / or responses, and the consolidated access requests may contain a combination of the statistical characteristics of the pair of access relationships 708. In one embodiment, the consolidation is performed before step 1106, which identifies expired relationships.

[0105] Figure 12 shows a method 1200 for extracting network connectivity relationships 710. Method 1200 may be performed by a log processor 130, an orchestrator 106, and / or any other component. Method 1200 includes a step 1102 for retrieving a log file 200. Step 1202 for retrieving a log file 200 may include a step for pulling the log file 200 from the component as described above with respect to Figure 2. Step 1202 for retrieving may include an augmentation step in which the data from the log file 200 is processed by the vector log agent 126 to add additional information, to perform a map-reduce operation, or to perform other operations. For example, the augmentation step may include adding a source identifier for the log file 200, a directory location for the log file 200, or other data to facilitate associating the data in the log file 200 with a specific component identifier. Step 1202 for retrieving may include a step for processing the log file 200 according to one or more VRL statements.

[0106] Method 1200 may include step 1204 of retrieving connection setup messages from log file 200 before or after any enhancement step of log file 200. Session setup messages may be a record of handshake messages or other message exchanges indicating that a network connection has been successfully established between the first and second components.

[0107] Method 1200 may include step 1206 of retrieving connection termination messages from log file 200 before or after any enhancement step of log file 200. Connection termination messages may indicate that the network connection has terminated in response to any of the following: a command from the client component, a command from the server component, the expiration of a timeout period, a failure of an intermediate component, or the network connection between the client component and the server component, or any other cause. In one embodiment, session termination messages may include messages indicating a failure of the physical link between the first component and the second component, a restart of the first or second component, and a failure or restart of the component hosting the first or second component.

[0108] Method 1000 may include a step 1208 for identifying expired network connection relationships 710. The step 1208 for identifying expired network connection relationships 710 may include identifying (a) a pair of components for which a network connection relationship 710 exists, (b) a pair of components for which there is no current network connection as indicated by a connection termination message, and (c) a pair of components for which a predetermined period has expired since the last connection termination message was received. With respect to (c), some connections have a predetermined TTL, and a network connection relationship 710 expires when a predetermined period longer than the TTL has expired since the last connection setup message for a pair of components.

[0109] As an alternative to the above method, all network connection relationships 710 expire as soon as the network connection represented by the network connection relationship 710 terminates due to TTL expiration or explicit termination as indicated in the connection termination message.

[0110] Method 1200 may include step 1210 to update network connection relationships 710 by deleting expired network connection relationships 710 and adding new network connection relationships 710 indicated by connection setup messages from step 1204. A first component and a second component may have multiple network connection relationships, such as connections to different ports by different applications. Therefore, there may be a separate network connection relationship 710 for each network connection, or a single network connection relationship 710 may be created to represent all network connections between a pair of components. A network connection relationship 710 may include data describing each connection (such as a setup timestamp, protocol, and port). This data may be updated to remove the data describing the connection when the connection ends. Similarly, a network connection relationship 710 may be updated to add data describing the connection between the pair of components represented by the network connection relationship 710 when the connection is set up.

[0111] Referring to Figures 13 and 14A to 14D, the illustrated method 1300 can be used to generate a visual representation of the topology displayed on a display device such as a user device 110 via the orchestrator dashboard 108.

[0112] Referring specifically to Figures 13 and 14A, method 1300 may be performed by the orchestrator 106, and the visual representation 1400 may be provided to the user computing device 110 via the orchestrator dashboard 108. The user computing device 110 can then display the visual representation 1400, receive user interactions with the visual representation 1400, and report the user interactions to the orchestrator 106 for processing. The user can request the generation of the visual representation 1400 via the orchestrator dashboard 108. The acquisition and processing of provisioning data 300 and log files 200 for generating the visual representation may be performed in response to a request from the user.

[0113] Method 1300 may include step 1302 of extracting component identifiers from provisioning data, as described above. Each component identifier is then used as a node in the graph. Method 1300 may then include step 1304 of adding nodes-to-node edges for hosting relationships 700 between the component identifiers represented by the nodes. Method 1300 may include step 1306 of adding nodes-to-node edges for environment variable relationships 702 between the component identifiers represented by the nodes. Method 1300 may include step 1308 of adding nodes-to-node edges for network relationships 704 between the component identifiers represented by the nodes. Method 1300 may include step 1310 of adding nodes-to-node edges for session relationships 706 between the component identifiers represented by the nodes. Method 1300 may include step 1312 of adding nodes-to-node edges for access relationships 708 between the component identifiers represented by the nodes. Method 1300 may include step 1314 of adding an edge between nodes for a network connectivity relationship 710 between component identifiers represented by nodes. The relationships between components described herein are illustrative, and Method 1300 may include adding an edge for other types of relationships between components.

[0114] Next, a visual representation 1400 of the topology represented by the graph may be displayed (1316). An exemplary visual representation 1400 is shown in Figure 14. The graphical elements may be displayed to represent components such as a host 802, a pod 112, a container 114, a storage volume 116, and an application instance 118. The graphical elements may include images and / or text, such as the UUID of each component.

[0115] A visual representation 1400 may include lines 1402 between graphic elements representing components, where lines 1402 represent the edges of the graph. Lines 1402 may be color-coded, with each color representing a relationship type 702-710. A pair of components may have multiple relationships, such as some or all of the environment variable relationships 702, network relationships 704, session relationships 706, access relationships 708, and network connectivity relationships. Separate lines 1402 may be displayed to represent each type of relationship, or a single line may represent all relationships between components represented by a pair of graphic elements.

[0116] A graphic element or line 1402 may be extended with additional visual data that describes the component or relationship represented by the graphic element or line 1402. For example, the additional visual data may be displayed when the graphic element or line 1402 is clicked, when hovering over the graphic element or line 1402, or during other interactions. The additional data may be collected from log 200 and may include component usage and / or AAI data as described above.

[0117] For example, for a graphic element representing host 802, additional data may include status 1404 (e.g., up, critical, down, unreachable), as well as host AAI data such as available and / or used computing power 1406 (e.g., processor cores, processor time, processor cycles), available and / or used memory 1408, and available and / or used storage 1410. For a graphic element representing storage volume 116, additional data may include status 1412, available storage 1414 and / or storage usage, as well as IOP (input / output operation) usage 1416 and / or availability. For a graphic element representing cluster 111, pod 112, container 114, or application instance 118, additional data may include status 1418, computing power usage 1420, memory usage 1422, and storage usage 1424. For cluster 111 and / or pod 112, the compute usage 1420, memory usage 1422, and storage usage 1424 may be aggregated from all the compute resources used by cluster 111 and / or pod 112, including all containers 114, application instances 118, and storage volumes 116, as well as cluster 111 and / or pod 112 itself.

[0118] For line 1402, additional data may include data describing one or more relationships represented by line 1402, such as a list of each type of relationship 700-710 represented by the line, the status 1426 of each relationship, and the usage 1428 of each relationship. Relationship usage may include, for example, the amount of data transmitted over a network connection, the number or frequency of requests to a session or access relationship, network connection latency, response latency to requests to a session or access relationship, or other data.

[0119] The graphic element or line 1402 may also be extended by an action menu 1430, for example, in response to user interaction with the graphic element or line 1402. The action menu 1430 may include a graphic element that, when selected by the user, invokes one or both of the following actions: (a) an action that modifies the information shown in the visual representation 1400, and (b) an action that performs an action on the component represented by the graphic element or line 1402. For example, the action menu 1430 may include elements for invoking actions such as deleting a component, restarting a component, creating a relationship 702-710 between a component and another component, creating a snapshot or backup copy of a component, duplicating a component, copying a component, or other actions. Thus, the method 1300 may include a step 1318 that receives interaction with the visual representation 1400 of the topology, and a step that, accordingly, performs actions such as a step 1320 that modifies the information shown in the visual representation and / or a step that modifies the component represented by the visual representation of the topology. Actions invoked on a component may also be performed on other components, such as those hosted by that component. For example, an action invoked for cluster 111 may be performed on all pods 112, containers 114, storage volumes 116, and application instances 118 hosted by cluster 111.

[0120] Figure 14B shows an application browsing interface 1432 that may be displayed to the user, for example, using data obtained according to Method 1300 or some other technique. The application browsing interface 1432 may contain one or more cluster elements 1434 representing cluster 111. The user can select one of the cluster elements 1434 to invoke the display of additional information about cluster 111. For example, a display of one or more namespace elements 1436, such as a list of names in the namespace of cluster 111, where each name represents a component 112, 114, 116, 118 of cluster 111, or other variables, services, or other entities that can access the components of cluster 111. Interface 1432 may display a selector element 1438, by which the user can enter criteria for filtering or selecting names from the namespace of cluster 111. For example, users can select based on the version (e.g., which HELM release of Kubernetes the component belongs to or was deployed with), the type of application (database, web server, etc.), executable image, instantiation data, or any other criteria.

[0121] For each application instance 118 that meets the criteria entered by the user in the selector element 1438, the application browsing interface 1432 can display various information items of the application instance 118. Exemplary information items may include the daemon set 1440a, deployment data 1440b, stateful set 1440c, replica set 1440d, configuration map 1440e, one or more secrets 1440f, or other data 1440g. Some or all of the items may be selected by the user to invoke the display of additional data. For example, the user can invoke the display of pod data 1442 for the pod 112 hosting the application instance 118, container data 1444 describing the container 114 hosting the application instance 118, persistent volume claim (PVC) data 1446 for the storage volume 116 accessed by the application instance 118, and volume data 1448 describing the storage volume 116 accessed by the application instance 118.

[0122] For each element selectable in the application browsing interface 1432, selecting that element allows you to invoke a display of the elements associated with that element, and also invoke a display of real-time data for each element, such as any of the observable data for each element (e.g., log data 200) that can be collected, processed (aggregated, formatted, etc.), and displayed when observable data is generated for each element.

[0123] Figure 14C shows yet another interface 1450 that can be used to visually represent the topology and incoming user input in order to call for displaying additional information about cluster 111, hosts 1452 running one or more components of cluster 111, and a storage device 1454 on one of the hosts 1452. Interface 1450 may include a cluster element 1456 representing cluster 111, a namespace element 1458 representing the namespace of cluster 111, a composite application element 1460 representing two or more application instances 118 collaborating to define a bundled application, and a single application element 1462 representing a single application instance 118.

[0124] Selecting given elements 1456, 1458, 1460, and 1462 allows you to invoke the display of additional information; that is, selecting the cluster element 1456 allows you to invoke the display of the namespace element 1458, selecting a name from the namespace element 1458 allows you to invoke the display of the composite application element 1460, and selecting a name from the composite application element 1460 allows you to invoke the display of the single application element 1462.

[0125] Selecting a single application element 1462 allows you to invoke a display of data describing the application instance 118, which is represented by a single application instance 118. For example, the data may include other data such as element 1464 indicating configuration map data, element 1466 indicating various sets (replica set, deployment set, stateful set, daemon set, etc.), element 1468 indicating secrets, or any observability data of the application instance 118.

[0126] Selecting elements 1462, 1464, and 1466 allows you to display additional data, such as pod element 1470 containing data describing pod 112, PVC element 1480 describing the PVC, and volume element 1482 describing storage volume 116 (including data describing the amount of data used by storage volume 116 and the storage device that stores the data of storage volume 116).

[0127] Interface 1450 can be used to assess the importance of components in cluster 111. For example, selecting namespace element 1458 can invoke the display of aggregated data 1484, such as aggregated logs (e.g., log files joined by arranging messages in log files chronologically), aggregated metrics (aggregated processor usage, memory usage, storage usage), aggregated alerts and / or events (e.g., combined events and / or alerts ordered by occurrence time), and aggregated access logs (e.g., enabling tracking of user behavior regarding cluster 111 or components of cluster 111). Aggregated data 1484 can be used in combination with topology data described in U.S. Patent Application No. 16 / 561,994, filed September 5, 2019, entitled "PERFORMING ROOT CAUSE ANALYSIS IN A MULTI-ROLE APPLICATION," which is incorporated herein by reference in its entirety, to perform root cause analysis (RCA).

[0128] Selecting a single application element 1462 allows you to invoke a display of the importance 1486 of the application instance 118 represented by that single application element 1462. The importance 1486 may be a metric that is a function of the number of other application instances 118 that depend on application instance 118, for example, having a relationship of 700-710 with application instance 118. The importance 1486 may also include the "blast radius" of application instance 118 (see Figure 14D and its corresponding description).

[0129] Selecting pod element 1470 allows you to invoke a display of the pod density 1488 (e.g., the number of pods) of the host running pod 112 represented by pod element 1470. The pod density 1488 can be used to determine the importance of the host and whether the host may be overloaded.

[0130] Selecting the PVC element 1480 allows you to access a display of the volume density 1490 (e.g., the number of storage volumes 116, the total size of the storage volumes 116) stored on the storage device or individual storage devices of the host. The volume density 1490 may be used to determine the importance of the host and whether the host's storage devices may be overloaded.

[0131] Figure 14D shows yet another interface 1492 that may be used to visually represent the topology. Interface 1492 may include a visual representation of the illustrated components. A storage device 1494 (e.g., a hard disk drive, a solid-state drive) stores data from the storage volume 116 and is used by an application instance 118 that may have one or more relationships, e.g., relationships 700-710, with other application instances 118, and the other application instances 118 themselves have relationships 700-710 with the other application instances. In particular, one or more application instances 118 that are not running on the same host as the storage volume may be represented in interface 1492. Interface 1492 may also be a “blast radius” representation showing the impact of a failure of the storage device 1494 on other application instances 118, or on other components of cluster 111 or one or more other clusters 111 that contain the storage volume 116.

[0132] Referring to Figures 15-19, AAI can be used to reduce the computing resources allocated to components within the network environment 100 based on the computing resource usage by the application instance 118. The cloud computing platform 104 may charge for purchased computing resources regardless of actual usage. Therefore, AAI can be used to identify changes in the application instance deployment to reduce the computing resources purchased.

[0133] Specifically, referring to Figure 15, the orchestrator 106 or another component can calculate the cluster host inventory 1502a-1502c for each of the multiple clusters 111a-111c. The cluster host inventory 1502a-1502c is the number of processing cores, the amount of memory, and the amount of storage on the server 102 assigned to a particular cluster 111a-111c. In the case of the cloud computing platform 104, the cluster host inventory 1502a-1502c may include the computing power, memory, and storage of the cloud computing platform assigned to clusters 111a-111c.

[0134] The orchestrator 106 or another component may further compute cluster provisioning 1504a-1504c for each cluster 111a-111c. Cluster provisioning 1504a-1504c is the computing resources (computation power, memory, and / or storage) allocated to the components within cluster 111a-111c (e.g., pods 112a-112c, container 114, storage volume 116, or application instances 118a-118l). In some cases, cluster provisioning 1504a-1504c is identical to the cluster host inventory 1502a-1502c and is omitted. In other examples, cluster provisioning 1504a-1504c includes the computing resources allocated to the individual components of cluster 111a-111c (pods 112a-11c, storage volume 116, application instances 118a-118l).

[0135] The orchestrator 106 or another component may further calculate cluster usage 1506a-1506c for each cluster 111a-111c. Cluster usage 1506a-1506c for clusters 111a-111c may include, for each computing resource (computation power, memory, storage), the total usage of that computing resource by all components within clusters 111a-111c, including the cluster itself. Cluster usage 1506a-1506c can be obtained from log file 200 as described above. Cluster usage 1506a-1506c for clusters 111a-111c may include a list of the amount of each computing resource used by the individual components of clusters 111a-111c and clusters 111a-111c itself.

[0136] The orchestrator 106 or another component may further compute cluster AAI 1508a-1508c for each cluster 111a-111c. Cluster AAI 1508a-1508c may include the AAI(t), O(t,i), and O(t) computed as described above, except that the hardware inventory is limited to the cluster host inventory 1502a-1502c, and only the usage of components within clusters 111a-111c and the cluster itself is used for the computation.

[0137] Figure 16A is a simplified diagram of available computing resources and their usage. Each bar in Figure 16A represents either the amount of computing resources (hardware inventory 1502a-1502c, cluster AAI 1508a-1508c) or the usage of computing resources (application instances 118a-118l). The illustrated representation is simplified in that other usages (pods 112a-112c, storage volume 116, clusters 111a-111c themselves) are omitted, and only one computing resource is represented, although these usages and computing resources may actually be included. As is clear, each cluster has an amount of computing resources for cluster AAI 1508a-1508c, which represents the difference between the cluster host inventory 1502a-1502c and the usage by the various components of each cluster 111a-111c.

[0138] Continuing with Figure 16A, and then referring to Figure 16B, one or more components may be redeployed from one cluster 111a-111c to another cluster. For example, application 118d on cluster 111a consumes far more computing resources than other applications 118a-118c on cluster 111a. In contrast, cluster 111b has cluster AAI1508b with sufficient computing resources to host application 118d. Therefore, application 118d can be redeployed onto cluster 111b.

[0139] In a cloud computing environment 104 where computing resources are virtualized, the amount of cluster host inventory 1502a to 1502c in some or all of the clusters 111a to 111c can be reduced, thereby reducing the amount charged for cluster host inventory 1502a to 1502c. In particular, the usage of cluster host inventory 1502a is significantly reduced by eliminating the usage of application instance 118d, so significant cost reductions can be achieved by reducing cluster host inventory 1502a.

[0140] The redeployment of application instance 118d to another cluster 111b is permitted provided that one or more constraints are met. If these constraints are not met, the redeployment may be prevented. For example, there may be a requirement that the receiving cluster 111b has a sufficient amount of computing resources (computation power, memory, and storage) to receive application instance 118d. There may be a requirement that moving application instance 118d to cluster 111b does not violate any affinity requirements regarding application instances 118a-118c remaining on the original cluster 111a. There may be a constraint that moving application instance 118d to cluster 111b does not violate any anti-affinity requirements regarding application instances 118e-118h running on the receiving cluster 111b. Redeploying application instance 118d to the receiving cluster 111b may involve adding application instance 118d to pods 112c and 112d in the receiving cluster 111b, or creating a new pod on the receiving cluster 111b.

[0141] The redeployment of application instance 118, for example application instance 118d in the illustrated example, may include redeploying application instance 118 from server 102 to cloud computing platform 104, or vice versa. For example, application instance 118d may be hosted on cloud computing platform 104. Application instance 118d may be moved to server 102 if it is using an amount of computing resources exceeding a threshold, would have higher performance if hosted locally on server 102, and would be less expensive if billing from cloud computing platform 104 for application instance 118d were removed. Similarly, application instance 118 with usage below a minimum threshold can be moved from server 102 to the cloud to provide local computing resources on server 102 to application instances on cloud computing platform 104 with usage exceeding a maximum threshold.

[0142] Referring to Figure 16C, in another example, cluster consolidation may be performed by moving all application instances 118a-118d, which may be deployed to one or more other clusters 111b, 111c, subject to any affinity and anti-affinity constraints and provided that the other clusters 111b, 111c have sufficient cluster AAI 1508b, 1508c. In that case, the entire cluster host inventory 1502a may be deleted along with the corresponding cost of the cluster host inventory 1502a.

[0143] Figure 17A shows an exemplary method 1700a that can be performed by the orchestrator 106 or another component to redeploy an application instance 118 to a different cluster 111. To facilitate understanding of the method, refer to the components shown in Figure 15 as a non-limiting example. In particular, any number of clusters 111 hosting any number of components can be handled according to method 1700a.

[0144] Method 1700a may include step 1702 determining the usage and cluster AAI of each cluster 111, such as the usage of components 1506a-1506c for multiple clusters 111a-111c and the cluster AAI 1508a-1508c for multiple clusters 111a-111c. Method 1700a may also include step 1704 identifying candidate redeployments. Step 1704 identifying candidate redeployments may be limited to evaluating the usage of application instance 118 for cluster AAI of cluster 111 in order to determine whether redeployment is possible. A candidate redeployment may include transferring a specific application instance 118 (e.g., application instance 118d) to a receiving cluster 111 (e.g., cluster 111b) that has enough cluster AAI to receive application instance 118. A candidate redeployment may include replacing the first application instance 118 on the first cluster 111 with a second application instance on the second cluster 111, where the second cluster has a larger host AAI than the first cluster and the first application instance 118 has greater usage than the second application instance 118. A candidate redeployment may also include removing the first application instance 118 on the first cluster 111, where the second application instance 118 on the second cluster 111 is load-balancing with the second application instance 118, and the second cluster 111 has sufficient cluster AAI to receive the usage of the first application instance 118, and possibly a larger cluster AAI than the first cluster 111. When identifying candidate redeployments (1704), multiple application instances 118 of cluster 111 that have affinity constraints with each other may be treated as a single unit; that is, the receiving cluster 111 must have enough cluster AAI to receive all of the multiple application instances 118.

[0145] Method 1700a may include step 1706 for filtering candidate redeployments based on constraints such as anti-affinity requirements, latency requirements, or other requirements. For example, if redeploying application instance 118d to cluster 111b violates the anti-affinity constraint of application instance 118d with respect to application instance 118e, such redeployment of application instance 118d is filtered out in step 1706. Similarly, if redeploying application instance 118d to cluster 11b exceeds the minimum latency required of application instance 118d with respect to application instances 118i-118l in cluster 111c, such redeployment is filtered out in step 1706. The anti-affinity and latency requirements are merely illustrative, and other constraints may be imposed in step 1706.

[0146] Method 1700a may include a step 1708 that calculates the cost reduction achievable by a candidate redeployment, i.e., how much the cluster host inventory 1502a-1502c of the cluster modified by the candidate redeployment can be reduced if the candidate redeployment is performed. If it is found that the cost reduction is greater than a minimum threshold, the candidate redeployment is performed by transferring, replacing, or deleting the candidate redeployment (1712). A redeployment involving moving application instance 118 from a first cluster 111 to a second cluster 111 may include installing the new application instance 118 on the second cluster (creating a container and installing application instance 118 into the container), stopping the original application instance 118 on the first cluster 111, and starting the new application instance 118 on the second cluster 111. Other configuration changes may be required to configure other components to access the new application instance 118 on the second cluster 111.

[0147] Method 1700a may further include step 1714 of reducing the amount of cloud computing resources used by one or more clusters 111. For example, in the example in Figure 16B, the computing resources allocated to cluster 111a may be reduced after application instance 118d is redeployed to cluster 111b. The reduction may be such that the cluster AAI for each cluster 111 is reduced to zero or a non-zero threshold (e.g., a percentage of the usage of components deployed to each cluster), assuming that the usage of components in the redeployed cluster remains the same as the usage values ​​used to calculate the cluster AAI for cluster 111.

[0148] Figure 17B shows an alternative method 1700b for redeploying application instance 118. Method 1700b is performed by orchestrator 106 or other components and allows application instance 118 to be redeployed to a different cluster 111.

[0149] Method 1700a may include step 1702, which determines the usage of each cluster 111 and cluster AAI, such as the usage of components 1506a to 1506c for multiple clusters 111a to 111c and cluster AAI 1508a to 1508c for multiple clusters 111a to 111c.

[0150] Method 1700a may include step 1704 of replanning the placement of components using the computing resource usage of the components instead of provisioning requirements. When components 111, 112, 114, 116, and 118 in the network environment 100 are first instantiated, the orchestrator 106 may perform a planning process to place the components based on the required computing resources, affinity requirements, anti-affinity requirements, latency requirements, or other requirements. The orchestrator 106 further attempts to improve the performance of the components working together by reducing latency and using computing resources as efficiently as possible.

[0151] As an example, orchestrator 106 may use a planning algorithm such as that disclosed in U.S. Patent No. 10,817,380B2, filed October 27, 2020, entitled "IMPLEMENTING AFFINITY AND ANTI-AFFINITY CONSTRAINTS IN A BUNDLED APPLICATION," which is incorporated herein by reference in its entirety. In contrast to the initial planning, the provisioning requirement in step 1716 for each component may be set to the computing resource usage measured for each component as described above using log data pulled from the component's host. Alternatively, the provisioning requirement may be set to an intermediate value between the provisioning of the component as defined in the manifest and the usage measured for that component, such as usage scaled by a number greater than 1, such as a number between 1.1 and 2.

[0152] The result of step 1716 may be one or more plans that define where each component will be located (e.g., which server 102, or which unit of computing resources in the cloud computing platform, which pod 112, or which cluster 111). The cost savings achieved by each plan can be calculated (1708) and evaluated (1710) to determine whether the plan provides at least a threshold reduction in computing resource allocation compared to the current configuration of the components, based on the usage of each component measured in step 1702. As described above, reducing the allocation of computing resources results in cost savings for the cloud computing platform 104.

[0153] If so, one of the plans may be implemented, such as the plan that provides the greatest cost savings (1712). Step 1712 of implementing the plan may include moving the components one at a time to the locations defined in the plan in order to avoid interruptions, or pausing all components, redeploying the components as defined in the plan, and restarting all components. Redeploying each component may be done as described above with respect to step 1712 of method 1700a.

[0154] Following or during the redeployment implementation 1712, method 1700b may include a step of reducing the cloud computing resources 1714 allocated from the cloud computing platform. The reduction may be such that, assuming that the usage of the cluster components after redeployment remains the same as the usage values ​​used to calculate the cluster AAI of cluster 111, the cluster AAI of each cluster 111 is reduced to a zero or non-zero threshold (e.g., a percentage of the usage of each cluster after redeployment) for one or more computing resources (computation power, memory, storage).

[0155] Figure 18 shows an alternative method 1800 for redeploying application instances 118 to consolidate the number of clusters 111 in the original configuration, such as the illustrated reduction of clusters shown in Figures 16A and 16C. Method 1700b may be performed by the orchestrator 106 or another component.

[0156] Method 1800 may include step 1802, which determines the usage of each cluster 111 in the original configuration and the cluster AAI, such as the usage of components 1506a-1506c for multiple clusters 111a-111c and the cluster AAI 1508a-1508c for multiple clusters 111a-111c.

[0157] Method 1800 may include a step 1804 that attempts to identify the merger. Merging is the process of placing components of multiple clusters into a subset of multiple clusters, excluding one or more clusters and one or more hosts from the multiple clusters. A method for attempting to identify the merger is described below with reference to Figure 19.

[0158] If an integration is found (1806), the integration can be performed (1808). If multiple integrations are found, the integration that achieves the highest cost reduction can be performed (1808). The integration may include a plan that defines the location of each component on the remaining cluster 111. Thus, components may be re-instantiated, configured, and started on the remaining cluster. In one embodiment, only components that are in a different location in the plan compared to their original configuration are redeployed to the different location. While the integration is being performed, the original components may be shut down. Alternatively, components may continue to operate until the plan is performed (1808) and migrate one at a time.

[0159] Computing resources allocated to clusters removed as part of the integration implementation 1808 may be reduced (1810). For on-premises equipment, server 102 may be taken offline or allocated for other purposes. With respect to units of cloud computing resources on the cloud computing platform 104, payment for the use of one or more units of cloud computing resources allocated to the removed cluster may be terminated, or other actions may be taken to terminate the acquisition of one or more units of cloud computing resources.

[0160] Figure 19 shows a method 1900 that may be used to identify potential cluster consolidation. Method 1900 may be performed by the orchestrator 106 or another component. Method 1900 may include treating each cluster 111 as a “target cluster” (1902) and replanning 1904, excluding the target cluster 111, i.e., without the cluster host inventory currently assigned to the target cluster 111. The replanning may be performed with respect to the cluster host inventory of clusters 111 other than the target cluster 111 (“remaining clusters”), as described above with respect to step 1716 of Method 1700b. As described above, the replanning may include identifying the location of each component on the hosts of the remaining clusters using a planning algorithm such as that disclosed in U.S. Patent No. 10,817,380B2, where each component is allocated computing resources of at least the same size as the usage of each component, and where each component's location satisfies any affinity, anti-affinity, latency, or other requirements with respect to the locations of other components.

[0161] If it is found that no plan exists to exclude target cluster 111 (1906), method 1900 terminates with respect to target cluster 111. If one or more plans are found to exist, each plan is added to the set of candidate mergers (1908).

[0162] After processing each cluster 111 as a target cluster, if one or more plans are found to exclude a target cluster, method 1900 may be recursively iterated using the set of clusters 111 that have excluded the target cluster. For example, suppose there are clusters 111a to 111f, and a plan is found to exclude the cluster host inventory of cluster 111a. Method 1900 may be repeated to determine whether the cluster host inventory of any of clusters 111b to 111f can be excluded. This process may be repeated until method 1900 no longer identifies any possible mergers.

[0163] Each cluster 111 is processed as a target cluster, and after any recursive iterations are performed, the result is either that there are no possible candidate mergers, or that there is one or more candidate mergers. If there are multiple candidate mergers, in step 1808, the candidate merger that provides the greatest billing reduction may be selected to be implemented.

[0164] Referring to Figure 20, as stated throughout the above description, the topology is dynamic. The components of topology 2000 (cluster 111, pod 112, container 114, storage volume 116, and application instance 118) can change at any time. Factors for change include automatic scaling up or down of components based on usage by the orchestrator 106, such as using tools like Kubernetes. Specifically for each cluster 111, Kubernetes manages the scaling up or down of the number of pods 112 and their corresponding containers 114, storage volume 116, and application instances, either independently or in cooperation with the orchestrator 106. Administrators can also manually add or remove components and the relationships between components.

[0165] For example, as indicated by the dotted line representation, pod 112, container 114, storage volume 116, and application instance 118 can be added. Similarly, components and relationships marked with "X" (represented by line 2002) represent components and relationships between components that can be removed from topology 2000.

[0166] In production facilities where stability is critical, changes to Topology 2000 may be prohibited or subject to one or more restrictions to mitigate the risk of changes that could cause crashes, overloads, or other types of instability.

[0167] Referring to Figure 21, for example, the illustrated method 2100 may be performed by the orchestrator 106 in cooperation with the orchestrator dashboard 108 or some other component. Method 2100 may include step 2102 of receiving a topology lock definition, such as from a user device 110 via the orchestrator dashboard 108. The topology lock definition can define the scope of the topology lock, for example, an entire topology, a specific cluster 111 or set of clusters 111, a specific host or set of hosts (a unit of computing resources on server 102 or cloud computing platform 104), a host located in a specific geographical area or facility, a specific area of ​​cloud computing platform 104, or other definitions.

[0168] The topology lock definition may further include restrictions on specific types of components (cluster 111, pod 112, container 114, storage volume 116, application instance 118) or specific types of relationships. With respect to application instance 118, the restriction may refer to a specific executable or an instance of a class of executables. The restriction may specify that for a particular type of component, an instance of a particular executable, or a particular type of relationship, (a) its number cannot change, (b) its number cannot increase, (c) its number cannot decrease, (d) its number cannot increase faster than a predetermined rate, or its number cannot decrease faster than a predetermined rate.

[0169] Method 2100 may include step 2104 of receiving a topology policy for each topology lock definition. The topology policy defines the actions to be taken for either (a) preventing a violation of the topology lock definition, or (b) handling a violation of the topology lock definition, or both.

[0170] Method 2100 may include step 2106, which configures some or all of the orchestrator 106, the workflows in the workflow repository 120, or other components in order to implement each topology lock definition and its corresponding topology policy.

[0171] For example, the use of a workflow to instantiate or de-instantiate (i.e., delete) a certain type of component may be modified to reference a topology lock and a corresponding topology policy that reference that type of component, so that, if required by the corresponding policy, the instantiation or de-instantiation of that type of component is not permitted to be completed in violation of the topology lock. In another example, a workflow that violates a topology lock would generate an alert.

[0172] In another example, container 114 may be configured to reference a container network interface (CNI), container runtime interface (CRI), or container storage interface (CSI) that is invoked by container 114 during instantiation and / or startup. One of the CNI, CRI, or CSI may be an orchestrator agent and may be modified to respond to the instantiation of container 114 hosting application instance 118 that is changing topology locks, thereby (a) preventing instantiation if required by the corresponding topology policy, or (b) generating an alert.

[0173] The above examples are merely examples of how topology locking can be enforced, and any other aspect of instantiation or de-instantiation of a component may be modified to include evaluating whether the instantiation or de-instantiation violates topology locking and taking the action required by the corresponding topology policy.

[0174] For example, Figure 22 shows a method 2200 for preventing a topology lock violation with a corresponding topology policy. Method 2200 may be performed by the orchestrator 106, CRI, CNI, CSI, or other components. Method 2200 includes step 2202 of receiving a request to create a component. Note that requests to delete components may be handled similarly.

[0175] A request may be evaluated in relation to topology locks and corresponding policies (2204). For example, step 2204 may include evaluating whether the request is to create a component in a part of the topology referenced by the topology lock (such as a specific cluster 111, a specific set of servers 102, a specific region or data center, or a specific region of a cloud computing platform), and whether the component is of a type referenced by the topology lock. Step 2204 may include evaluating whether a request to create or delete a component is a prohibited action of the topology lock. For example, if changes are not allowed, a request to create or delete a component is prohibited. If only decreases are prohibited, a request to create a component may be allowed. If rate-limited increases are allowed, step 2204 may include evaluating whether creating a component exceeds the rate limit. If the request is to delete a component and only increases are prohibited, a request to delete a component may be allowed. If rate-limited decreases are allowed, step 2204 may include evaluating whether deleting a component exceeds the rate limit.

[0176] If it is determined that the request to create or delete is permitted (2206), the request is carried out (2210). If it is not permitted, method 2200 may include a step to block the carrying out of the request. The block may include one or more of the following: • Complete the workflow necessary to fulfill the request. • Prevent CNI, CRI, or CSI from completing the setup of the components being created or the containers hosting those components.

[0177] It should be noted that the creation or deletion of relationships between components may be handled similarly. A request to create or delete a relationship may be evaluated against one or more topology locks (2204) and, if not permitted according to the topology locks, may be enforced (2210) or blocked (2208). Blocking may be enforced using a modified workflow, CNI, CRI, or CSI. Blocking may also be performed in other ways, such as blocking network traffic to set up a session relationship 706, an access relationship 708, or a network connectivity relationship 710.

[0178] Figure 23 shows method 2300 for handling topology locks and corresponding policies. Method 2300 may be executed by orchestrator 106 or other components. Method 2300 may be executed in addition to or as an alternative to method 2200. For example, a policy responding to a topology lock may specify that changes that violate the topology lock should be blocked so that method 2200 is enforced. A policy responding to a topology lock may also specify that a topology lock violation should be detected after it occurs and an alert should be issued or the violation should be reversed so that method 2300 is enforced.

[0179] Method 2300 may include a step 2302 to generate the current topology of the installation, such as Method 1300 in Figure 13 or some other technique. Method 2300 may also include a step 2304 to compare the current topology with a previous topology of the installation at a previous point in time, either at the time of initial instantiation of the installation or at a point after the initial installation. For example, the previous topology may be a topology that existed at a first time or before the topology lock was created, and the current topology is obtained from provisioning data 300 and / or log files 200 generated at a second time after the first time.

[0180] A topology lock can have a range smaller than the entire topology (see the description in step 2102 of Method 2100). Therefore, in step 2304, only the portion of the current topology corresponding to that range can be compared with the portion of the previous topology. A topology lock may be restricted to components of a specific type, such that only components of the current topology having a specific type are compared in step 2304. If the topology lock refers to a type of relation, the relation of that type in the current topology and the previous topology may be compared.

[0181] Method 2300 may include a step 2306 that evaluates whether the current topology violates one or more topology locks relative to the previous topology. For example, whether a new component of a particular type has been added to part of the installation (e.g., cluster 111, server 102, data center, cloud computing area). For example, the component identifiers of each component of each type referenced by the topology locks may be compiled relative to the current and previous topologies. It may be possible to identify component identifiers of the current topology that are not included in the component identifiers of the previous topology. Similarly, if the topology locks prevent deletion, component identifiers of the previous topology that are not present in the current topology may be identified.

[0182] If a topology lock refers to a relationship type, each relationship in the current topology is checked to see if it matches a relationship in the previous topology, i.e., if it has the same component identifier and type as the relationship in the previous topology. A relationship for which there is no corresponding patch in the previous topology may be considered new. Similarly, a relationship in the previous topology that does not match in the current topology may be considered deleted. In step 2306, it can be determined whether a new or deleted relationship violates the policy.

[0183] For a topology lock violated in step 2306, method 2300 may include step 2308, which evaluates the topology policy corresponding to this topology lock. The actions specified in the topology policy can then be performed. For example, if the policy is found to require reverting a change that violates the topology lock (2310), method 2300 may include calling a workflow to revert the change (2314). The workflow may be one that removes the component or relationship that violates the topology lock. Such a workflow may be the same workflow used to remove that type of component or relationship when scaling down due to insufficient usage. The workflow may be a set of steps to remove the component or relationship in an orderly and uninterrupted manner, namely, steps to process pending transactions and migrate the workload to another component. If a component or relationship is removed in violation of a topology lock, the workflow may re-instantiate the component or relationship. The workflow for re-instantiating the component or relationship may be the same workflow used to create an initial instance of that type of component or relationship, or to scale up the number of that type of component or relationship.

[0184] If a topology lock is indicated by a topology policy, method 2300 may include step 2312 to generate an alert. The alert may be directed to user device 110 or an administrator's user account, the individual who invoked the change to the policy that violates the topology lock, or another user. The alert may convey information such as the violated topology lock, the number of components or relationships that violated the policy, a graphical representation of the change to the policy (see, for example, the graphical representation in Figure 20), or other data.

[0185] Referring to Figure 24, the application instances 118 can have various relationships with one another. As described herein, the application instances 118 can be classified as either dot application instances 2400, triangle application instances 2402, line application instances 2404, or graph application instances.

[0186] Dot application instance 2400 is an application instance 118 that has no relationship (e.g., relationships 700-710) with other application instances 118. For example, application instance 2400 may be an instance of an application that provides a standalone service. Dot application instance 2400 may be an application instance that does not have any particular type of relationship with other application instances 118. For example, dot application instance 2400 may lack a hosting relationship 700, an environment variable relationship 702, or a network relationship 704 with another application instance 118. In some embodiments, one or more of the session relationship 706, access relationship 708, and network connectivity relationship 710 may still exist with respect to dot application instance 2400 and another application instance 118.

[0187] A triangular application instance 2402 includes at least three application instances 118, all of which are related to each other, such as one of relations 700-710. While the term “triangular application instance” is used throughout, it should be understood as including any number of application instances 118, each of which depends on all the other application instances 118.

[0188] In an example of a triangular application instance 2402, the application instances 118 may be replicas of each other, with one of them being the primary replica handling production requests, and two or more other application instances 118 being backup replicas mirroring the state of the primary replica. Therefore, each change to the state of the primary replica must be propagated to and verified by each backup replica. To determine whether a backup replica should become the primary replica, health checks may be performed by the backup replicas on each other and on the primary replica. Thus, the above relationship between the primary replica and backup replicas constitutes a triangular application instance 2402. In the illustrated example, each application instance 118 in the set of triangular application instances 2402 runs on a different cluster 111.

[0189] A linear application instance 2404 includes multiple application instances 118 arranged in a pipeline such that inputs to a first application instance result in corresponding outputs received as inputs to a second application instance, and this is also true for any number of application instances. As an example, the application instances 118 of linear application instance 2404 may include a web server, a backend server, and a database server. A web request received by the web server can be translated by the web server into one or more requests to the backend servers. The backend servers can process one or more requests, which may require one or more queries to the database server. The responses from the database servers are processed by the backend servers to obtain responses to be sent to the web server. The web server can then generate a web page containing the responses and send the web page as a response to the web request. In the illustrated example, each application instance 118 in the set of linear application instances 2404 runs on a different cluster 111.

[0190] Graph application instance 2406 includes multiple application instances 118, including line application instances 2404 and / or triangle application instances 2402, which are connected by one or more relationships, such as one or more relationships 700-710. For example, application instance 118 of the first line application instance 2404 can receive the output of application instance 118 of the second line application instance 2404, thereby creating a branch. Similarly, application instance 118 of the first set of triangle application instances 2402 can generate an output that is received by application instance 118 of line application instance 2404 or another set of triangle application instances 2402. Application instance 118 of the first set of triangle application instances 2402 can receive an output from application instance 2404 or another set of triangle application instances 2402.

[0191] Referring to Figure 25, cluster 111 may have a corresponding cluster specification 2500. The cluster specification 2500 may be created before or after the creation of cluster 111 and contains information that helps provision components (pods 112, containers 114, storage volumes 116, and / or application instances 118) on cluster 111.

[0192] For example, the cluster specification 2500 for cluster 111 may include the cluster identifier 2502 and the location identifier 2504 for cluster 111. The location identifier 2504 may include either or both a name assigned to the geographical area where one or more hosts running cluster 111 are located, and data describing the geographical area where one or more hosts are located, such as a city, state, country, zip code, or the name of some other political or geographical entity. The location identifier 2504 may include coordinates (latitude and longitude or Global Positioning System) describing the location of one or more hosts. If there are multiple geographically dispersed hosts, the location identifier 2504 may include the location of each host (a political or geographical name and / or coordinates).

[0193] The cluster specification 2500 may include a list of computing resources 2506 for one or more hosts. Computing resources may include the number of processing cores, the amount of memory, and the amount of storage available on one or more hosts. For example, the computing resources may include the cluster host inventory of cluster 111 as described above. If cluster 111 already hosts one or more components, the computing resources 2506 may additionally or alternatively include cluster AAIs of one or more hosts as defined above.

[0194] Referring to Figure 26, the dot application specification 2600 may include an identifier 2602 for the application instance 118 created in accordance with the dot application specification 2600. The dot application specification 2600 may include one or more runtime requirements 2604. For example, runtime requirement 2604 may include a location requirement 2606. For example, location requirement 2606 may include the name of a political or geographical entity in which the host running the application instance 118 must be located. Location requirement 2606 may specify the coordinates in which the host running the application instance 118 must be located and a radius centered on those coordinates.

[0195] The runtime requirement 2604 may further include the availability requirement 2608. The availability requirement 2608 may be a value from a set of possible values ​​that indicate the required availability of the application instance 118 in the dot application specification 2600. For example, such values ​​may include "high availability," "intermittent availability," and "low availability." The orchestrator 106 can then interpret the availability requirement 2608 when selecting a host for the application instance 118 and configuring the application instance 118 on the selected host.

[0196] The runtime requirement 2604 may further include the cost requirement 2610. The cost requirement 2610 may specify the allowed cost for running the application instance 118 of the dot application specification 2600. For example, a cloud computing provider may charge for some or all of the computing power (e.g., processor cores), memory, and storage used by the application instance 118. Thus, the cost requirement 2610 may specify the maximum amount that can be spent running the application instance 118, such as the amount that can be spent per day, month, or other period.

[0197] The dot application specification 2600 may further include compute resource requirements 2612 that specify the amount of processing power, memory, and / or storage required to run an application instance 118 of the dot application specification 2600. The compute resource requirements 2612 may be statically defined or dynamic, and may include, for example, a note indicating that provisioning may be dynamically changed based on initial provisioning requirements and usage (see, for example, Figures 15-19 above).

[0198] The dot application specification 2600 may further include tolerance 2614, which specifies whether an exception to either of the requirements 2604 or 2612 described above is permitted. For example, tolerance 2614 may indicate that application instance 118 of dot application specification 2600 should not be deployed unless all of requirements 2604 and 2612 are met. Tolerance 2614 may also indicate that if no cluster 111 that meets requirements 2604 and 2612 is found, application instance 118 may be deployed to the nearest alternative ("best fit"). The tolerance may indicate an acceptable deviation from either requirement 2604 or 2612 if no cluster 111 that meets requirements 2604 or 2612 is found.

[0199] The dot application specification 2600 defines the provisioning of application instance 118 of the dot application specification. Other parameters that define the instantiation and configuration of application instance 118 on the selected host may be included in the manifest taken up by the orchestrator 106, in addition to the dot application specification 2600. Alternatively, the dot application specification 2600 may be part of the manifest.

[0200] Referring to Figure 27, the triangular application specification 2700 may include identifiers 2702 for a set of application instances 118 created according to the triangular application specification 2700. The triangular application specification 2700 may include one or more runtime requirements 2704. For example, runtime requirement 2704 may include location requirements 2706. For example, location requirement 2706 may include the name of a political or geographical entity where the hosts running the set of application instances 118 must be located. Location requirement 2706 may specify coordinates and a radius around the coordinates where one or more hosts running one or more application instances 118 in the hierarchy must be located. Location requirement 2706 may include an individual location for each application instance 118 in the set of application instances 118.

[0201] The runtime requirement 2704 may further include the availability requirement 2708. The availability requirement 2708 may be a value from a set of possible values ​​that indicate the required availability for the set of application instances 118 of the triangular application specification 2700. For example, such values ​​may include "high availability," "intermittent availability," and "low availability." The orchestrator 106 can then interpret the availability requirement 2708 when selecting a host for the set of application instances 118 and configuring the set of application instances 118 on the selected host. The availability requirement 2708 may include individual availability requirements for each application instance 118 in the set of application instances 118.

[0202] The runtime requirement 2704 may further include the cost requirement 2710. The cost requirement 2710 may specify the allowed cost for running a set of application instances 118 of the triangular application specification 2700. For example, a cloud computing provider may charge for some or all of the computing power (e.g., processor cores), memory, and storage used by each application instance 118 in the set of application instances 118. Thus, the cost requirement 2710 may specify the maximum amount that can be spent running a set of application instances 118, such as the amount that can be spent per day, month, or other period. The cost requirement 2710 may include individual cost requirements for each application instance 118 in the set of application instances 118.

[0203] Runtime requirement 2704 may further include latency requirement 2712. Since each application instance 118 in a set of application instances 118 depends on all other application instances in the set, for it to function properly, the latency may need to be below a specified maximum latency in terms of time, such as 10ms, 20ms, or some other time value. Latency requirement 2712 may be specified for each pair of application instances 118 in the set, i.e., the maximum allowable latency between application instances 118 in each possible pair of application instances 118.

[0204] The triangular application specification 2700 may further include compute resource requirements 2714 that specify the amount of processing power, memory, and / or storage required to run each application instance 118 in the set of application instances 118 of the triangular application specification 2700. The compute resource requirements 2714 may be statically defined or dynamic, and may include, for example, an annotation indicating that provisioning may be dynamically changed based on initial provisioning requirements and usage (see, for example, Figures 15-19 above).

[0205] The triangular application specification 2700 may further include a replication requirement 2716 that specifies the number of application instances 118 included in the set of application instances, for example, a value of 3 or more. Therefore, if application instance 118 fails, the orchestrator 106 creates a new application instance 118 to satisfy the replication requirement 2716.

[0206] The triangular application specification 2700 may further include a tolerance 2718 that specifies whether an exception to any of the above requirements 2704, 2714, or 2716 is permitted. For example, tolerance 2718 may indicate that application instance 118 of triangular application specification 2700 should not be deployed unless all of requirements 2704, 2714, and 2716 are met. Tolerance 2718 may indicate that if no cluster 111 that meets requirements 2704, 2714, and 2716 is found, application instance 118 may be deployed to the nearest alternative ("best fit"). The tolerance may indicate an acceptable deviation from any of requirements 2704, 2714, or 2716 if no cluster 111 that meets requirements 2704, 2714, or 2716 is found.

[0207] The triangular application specification 2700 defines the provisioning of a set of application instances 118. The instantiation and configuration of each application instance 118 on a selected host, as well as the creation of any relationships 700-710 between the application instances 118, may be performed in accordance with the triangular application specification 2700, in addition to the manifest taken up by the orchestrator 106. Alternatively, the triangular application specification 2700 may be part of the manifest.

[0208] Referring to Figure 28, a linear application specification 2800 can contain multiple tier specifications 2802. Each tier specification 2802 corresponds to a different tier within the pipeline defined by the linear application specification 2800. Each tier specification 2802 can include a specification of the type of application instance 118 to be instantiated for that tier. Each tier can contain multiple application instances 118 of the same or different types.

[0209] Each hierarchical specification 2802 may include identifiers 2804 for one or more application instances 118 created in accordance with the hierarchical specification 2802. A hierarchical specification 2802 may include one or more runtime requirements 2806. For example, a runtime requirement 2806 may include a location requirement 2808. For example, a location requirement 2808 may include the name of a political or geographical entity in which one or more hosts running one or more application instances 118 of the hierarchy must be located. A location requirement 2808 may specify coordinates and a radius centered on those coordinates in which all hosts running one or more application instances 118 of the hierarchy must be located. A location requirement 2808 may include individual locations for one or more application instances 118 of the hierarchy.

[0210] The runtime requirement 2806 may further include availability requirements 2810. Availability requirements 2810 may be values ​​from a set of possible values ​​that indicate the required availability for one or more application instances 118 in the hierarchy. For example, such values ​​may include "high availability," "intermittent availability," and "low availability." The orchestrator 106 can then interpret the availability requirements 2810 when selecting one or more hosts for one or more application instances 118 in the hierarchy and configuring one or more application instances 118 on the selected hosts. Availability requirements 2810 may include individual availability requirements for each application instance 118 of the one or more application instances 118.

[0211] The runtime requirement 2806 may further include the cost requirement 2812. The cost requirement 2812 may specify the allowed cost for running one or more application instances 118 in the tier. For example, a cloud computing provider may charge for some or all of the computing power (e.g., processor cores), memory, and storage used by each of the one or more application instances 118. Thus, the cost requirement 2812 may specify the maximum amount that can be spent running one or more application instances 118 in the tier, such as the amount that can be spent per day, month, or other period. The cost requirement 2812 may include individual cost requirements for each of the one or more application instances 118 in the tier.

[0212] Runtime requirement 2806 may further include latency requirement 2814. Latency requirement 2814 may either or both (a) define the maximum allowable latency between multiple application instances in the same tier, and (b) define the maximum latency for application instances 118 in preceding and / or succeeding tiers.

[0213] The tier specification 2802 may further include compute resource requirements 2816 that specify the amount of processing power, memory, and / or storage required to run each application instance 118 of the tier. The compute resource requirements 2816 may be statically defined or dynamic, and may include, for example, an annotation indicating that provisioning may be dynamically changed based on initial provisioning requirements and usage (see, for example, Figures 15-19 above).

[0214] The tier specification 2802 may further include a tolerance 2818 that specifies whether an exception to either of the requirements 2806 or 2816 described above is permitted. For example, tolerance 2818 may indicate that one or more application instances 118 of the tier should not be deployed unless all of requirements 2806 or 2816 are met. Tolerance 2818 may indicate that if no cluster 111 that meets requirements 2806 or 2816 is found, one or more application instances 118 may be deployed to the nearest alternative ("best fit"). Tolerance may indicate an acceptable deviation from either requirement 2806 or 2816 if no cluster 111 that meets requirements 2806 or 2816 is found.

[0215] As described above, the graph application instance 2406 includes multiple application instances 118, which in turn include multiple line application instances 2404 and / or triangle application instances 2402. Therefore, the specification of the graph application instance may include a set of specifications 2700, 2800 of the line application instances 2404 and / or triangle application instances 2402 that constitute the graph application instance.

[0216] Figure 29 shows a method 2900 for deploying a dot application instance 2400. Method 2900 may be performed by an orchestrator 106. For example, the orchestrator 106 may invoke the execution of a workflow from the workflow repository 120 by a worker 124 to perform some or part of method 2900. Method 2900 may be performed in response to the orchestrator 106 receiving a dot application specification 2600 from a user, or as part of a manifest.

[0217] Method 2900 may include a step 2902 to determine the computing resource requirements 2612 for the dot application instance 2400, and a step 2904 to determine one or more runtime requirements 2604 for the dot application instance 2400. Method 2900 may then include a step 2906 to evaluate the cluster specifications 2500 of the available clusters 111, and determine whether any of the clusters 111 have sufficient computing resources 2506 to satisfy the computing resource requirements 2612 and also satisfy the runtime requirements 2604. As described above, the available computing resources to be evaluated may be either the cluster host inventory of the clusters 111, or the cluster AAI of the clusters 111 on which one or more components are already running.

[0218] If one or more matching clusters are found in step 2906, method 2900 may include a step of deploying the application instance 118 corresponding to the dot application instance 2400 to one of the one or more clusters. If multiple clusters are found in step 2906, one cluster 111 may be selected based on one or more criteria such as geographical proximity, performance, available cluster inventory or cluster AAI, or other criteria.

[0219] If no matching cluster 111 is found in step 2906, method 2900 may include step 2910, which evaluates whether the dot application specification 2600 defines an acceptable range 2718. Step 2910 may further include evaluating whether any of the available clusters 111 are within the acceptable range defined for the compute resource requirement 2612 and / or runtime requirement 2604 of the dot application specification 2600. If the dot application specification 2600 does not provide an acceptable range, or if cluster 111 is not within the defined acceptable range, the operation fails (2914), and an error message may be returned to the user, orchestrator 106, log file 200, or other destination.

[0220] If the dot application specification 2600 provides an acceptable range and / or if there are one or more clusters 111 that fall within any defined acceptable range, a compromise cluster 111 may be selected (2912). The compromise cluster 111 may be the cluster 111 that most strictly matches one or both of the compute resource requirements 2612 and the runtime requirements 2604. For example, from among the clusters 111 that have a cluster host inventory and / or cluster AAI that meet the compute resource requirements 2612, the cluster 111 that most strictly meets the runtime requirements 2604 may be selected. For example, the runtime requirements 2604 may be ranked such that the cluster 111 that meets the highest-ranked runtime requirement 2604 is selected (2912). Once a compromise cluster is selected, the application instance 118 of the dot application instance 2400 is deployed on the compromise cluster (2908).

[0221] Figure 30 shows a method 3000 for deploying a triangular application instance 2402. Method 3000 may be executed by the orchestrator 106. For example, the orchestrator 106 may invoke the execution of a workflow from the workflow repository 120 by the worker 124 to execute some or part of method 3000. Method 3000 may be executed in response to the orchestrator 106 receiving a triangular application specification 2700 from a user, or as part of a manifest.

[0222] Method 3000 may include a step 3002 to determine the computing resource requirements 2714 for the triangular application instance 2402, and a step 3004 to determine one or more runtime requirements 2704 for the triangular application instance 2402. Method 3000 may then include a step 3006 to evaluate the cluster specifications 2500 of the available clusters 111, and determine whether any of the clusters 111 have sufficient computing resources 2506 to satisfy the computing resource requirements 2714 and also satisfy the runtime requirements 2704. The evaluation in step 3006 may be performed for each application instance 118 of the triangular application instance 2402, and for each application instance 118, identify any cluster 111 that has sufficient computing resources 2506 and satisfies the runtime requirements 2704 for that application instance 118.

[0223] Next, any matching cluster 111 identified in step 3006 can be further evaluated to determine the inter-cluster latency of the matching cluster 111 (3008). The inter-cluster latency may have been previously calculated and obtained, or it may have been tested as part of step 3008.

[0224] Method 3000 may then include a step 3010 to evaluate whether any cluster group can be found among matching clusters that satisfy the latency requirement 2712 of the triangular application instance 2402. For example, if the application instances 118 of the triangular application instance 2402 are designated as A, B, and C, then the matching cluster group is cluster C, which matches the compute resource requirement 2714 and runtime requirement 2704 of application instance A. A Cluster C matches the compute resource requirements 2714 and runtime requirements 2704 for application instance B. Band a cluster C that matches the computing resource requirements 2714 and runtime requirements 2704 of application instance C C which includes, and the latency between each of these clusters (between C A and C B and between C B and C C and between C A and C C and between C

[0225] If one or more matching cluster groups are found in step 3010, method 3000 can include step 3012 of deploying application instance 118 of triangular application instance 2402 onto one of the clusters 111 of one or more matching cluster groups. If multiple cluster groups are found in step 3010, one cluster group can be selected based on one or more criteria such as average inter-cluster latency, geographical proximity, performance, available cluster inventory or cluster AAI, or other criteria.

[0226] If no matching cluster is found in step 3006 or the number of matching clusters is less than the number required to implement triangular application instance 2402, method 3000 can include step 3014 of evaluating whether triangular application specification 2700 defines an acceptable range 2718. Step 3014 can further include evaluating whether any of the available clusters 111 are within the acceptable range defined for the computing resource requirements 2714 and / or runtime requirements 2704 of triangular application specification 2700. If triangular application specification 2700 does not provide an acceptable range or the clusters 111 are not within the defined acceptable range, the operation fails (3018) and an error message can be returned to the user, orchestrator 106, log file 200, or other destination.

[0227] If the triangular application specification 2700 provides an acceptable range and / or if there are clusters 111 that fall within any defined acceptable range, one or more compromise clusters 111 can be selected (3016). A compromise cluster 111 may be the cluster 111 that most closely matches one or both of the compute resource requirements 2714 and the runtime requirements 2704. For example, from among the clusters 111 that have a cluster host inventory and / or cluster AAI that meet the compute resource requirements 2714, the cluster 111 that most closely meets the runtime requirements 2704 can be selected. For example, the runtime requirements 2704 may be ranked such that the cluster 111 that meets the highest-ranked runtime requirement 2704 is selected (3016). Any compromise clusters selected in step 3016 can then be processed in step 3008, which may include processing the compromise clusters together with any matching clusters identified in step 3006.

[0228] If no matching cluster group is found in step 3010, method 3000 may include step 3020, which evaluates whether the triangular application specification 2700 defines an acceptable range 2718 with respect to the latency requirement 2712. Step 3020 may further include evaluating whether any of the inter-cluster latencies of any of the non-matching cluster groups are within the defined acceptable range for the latency requirement 2712. If the triangular application specification 2700 does not provide an acceptable range, or if the cluster group is not within the defined acceptable range, the operation fails (3018), and an error message may be returned to the user, orchestrator 106, log file 200, or other destination.

[0229] If the Triangle Application Specification 2700 provides an acceptable range and / or if there is at least one cluster group that falls within any defined acceptable range, a compromise cluster group is selected (3022), and the application instance 118 of the Triangle Application Instance 2402 may be deployed on cluster 111 of the selected compromise cluster group. The compromise cluster group may also be the cluster group that most closely matches the latency requirement 2712. If one or more cluster groups include the compromise cluster selected in step 3016, step 3022 for selecting a compromise cluster group may also include a step of evaluating the combination of inter-cluster latencies for each cluster group and how closely each cluster in each cluster group meets the compute resource requirement 2714 and runtime requirement 2704.

[0230] Figure 31 shows a method 3100 for deploying a line application instance 2404. Method 3100 may be performed by an orchestrator 106. For example, the orchestrator 106 may invoke the execution of a workflow from the workflow repository 120 by a worker 124 to perform some or part of method 3100. Method 3100 may be performed in response to the orchestrator 106 receiving a line application specification 2800 from a user, or as part of a manifest.

[0231] Method 3100 may include a step 3102 to determine the computing resource requirements 2816 for the line application instance 2404, and a step 3104 to determine one or more runtime requirements 2806 for the line application instance 2404. Method 3100 may then include a step 3006 to evaluate the cluster specifications 2500 of the available clusters 111, so that it can determine whether any of the clusters 111 have sufficient computing resources 2506 to satisfy the computing resource requirements 2816 and also satisfy the runtime requirements 2806. The evaluation in step 3106 may be performed for each application instance 118 of the line application instance 2404, and for each application instance 118, any cluster 111 has sufficient computing resources 2506 and satisfies the runtime requirements 2806 for that application instance 118.

[0232] Next, the groups of matching clusters 111 identified in step 3106 can be evaluated (3108) to determine the cost function for each group of matching clusters. The cost function for a group of clusters may include an evaluation of monetary costs, such as the total monetary cost of deploying application instances 118 of line application instances 2404 on the clusters 111 of the group, or the monetary cost of deploying the most resource-intensive application instances 118 of line application instances 2404. For example, an application instance 118 hosting a database is the most resource-intensive for most applications, and as a result, the cost function may be limited to evaluating the monetary cost of deploying an application instance 118 hosting a database on a cluster 111 of a given cluster group that satisfies the computing resource requirements 2816 and one or more runtime requirements 2806 for the application instance 118 hosting a database.

[0233] Method 3100 may then include a step 3110 to evaluate whether there are any cluster groups that match the selection criteria. For example, the selection criteria may be a cost function of any cluster groups that fall below a predetermined threshold.

[0234] If one or more matching cluster groups are found in step 3110, method 3100 may include step 3112 to deploy the application instance 118 of line application instance 2404 onto one of the clusters 111 of the one or more matching cluster groups. If multiple cluster groups are found in step 3110, one cluster group can be selected based on one or more criteria such as cost function, mean inter-cluster latency, geographical proximity, performance, available cluster inventory or cluster AAI, or other criteria.

[0235] If no matching clusters are found in step 3106, or if the number of matching clusters is less than the number required to implement the line application instance 2404, method 3100 may include step 3114 to evaluate whether the line application specification 2800 defines a tolerance 2818. Step 3114 may further include evaluating whether any of the available clusters 111 are within the tolerance defined for the compute resource requirements 2816 and / or runtime requirements 2806 of the line application specification 2800. If the line application specification 2800 does not provide a tolerance, or if cluster 111 is not within the defined tolerance, the operation fails (3118), and an error message may be returned to the user, orchestrator 106, log file 200, or other destination.

[0236] If the Line Application Specification 2800 provides an acceptable range and / or if there are clusters 111 that fall within any defined acceptable range, one or more compromise clusters 111 can be selected (3116). A compromise cluster 111 may be the cluster 111 that most closely matches one or both of the compute resource requirements 2816 and the runtime requirements 2806. For example, from among the clusters 111 that have a cluster host inventory and / or cluster AAI that meet the compute resource requirements 2816, the cluster 111 that most closely meets the runtime requirements 2806 can be selected. For example, the runtime requirements 2806 may be ranked such that the cluster 111 that meets the highest-ranked runtime requirement 2704 is selected (3116). Any compromise clusters selected in step 3116 can then be processed in step 3108, which may include processing the compromise clusters together with any matching clusters identified in step 3106.

[0237] If no matching cluster group is found in step 3110, method 3100 may include step 3120, which evaluates whether the line application specification 2800 defines an acceptable range 2818 with respect to the cost requirement 2812. Step 3120 may further include evaluating whether the cost function of any of the non-matching cluster groups is within the defined acceptable range for the cost requirement 2812. If the line application specification 2800 does not provide an acceptable range, or if the cluster group is not within the defined acceptable range, the operation fails (3118), and an error message may be returned to the user, orchestrator 106, log file 200, or other destination.

[0238] If the line application specification 2800 provides an acceptable range and / or there is at least one cluster group that falls within any defined acceptable range, a compromise cluster group can be selected (3122), and the application instance 118 of the line application instance 2404 can be deployed on the cluster 111 of the selected compromise cluster group. The compromise cluster group may be the cluster group that most closely matches the latency requirement 2712. If one or more cluster groups include the compromise cluster selected in step 3116, selecting a compromise cluster group may also involve evaluating the combination of inter-cluster latencies for each cluster group and how closely each cluster in each cluster group meets the compute resource requirement 2816 and runtime requirement 2806.

[0239] Figures 32 and 33 illustrate a method 3200 for deploying a graph application instance 2406. Method 3200 may include a step 3202 of splitting the graph application instance 2406 into one or more triangular application instances 2402 and line application instances 2404, as shown in Figure 33. The splitting 3202 may be performed considering the specifications of the graph application instance 2406, including explicitly defined triangular application specifications 2700 and / or line application specifications 2800. The splitting may also include parsing a graph representing the application instance 118 of the graph application instance 2406 to identify the triangular application instances 2402 and line application instances 2404.

[0240] Method 3200 may include steps to provision and deploy a triangular application instance 2402 according to Method 3000, etc. Method 3200 may also include steps to provision and deploy a linear application instance 2404 according to Method 3100, etc.

[0241] Methods 3000 and 3100 may be modified in one or more ways when deploying the graph application instance 2406. Method 3000 includes a step 3010 to evaluate whether there is a matching cluster group, and Method 3100 includes a step 3110 to evaluate whether there is a matching cluster group. In the case of Method 3200, a “matching cluster group” can be defined as a matching cluster group that includes clusters of each application instance 118 of all triangular application instances 2402 and line application instances 2404 of the graph application instance 2406. Thus, in some embodiments, the matching cluster group must simultaneously satisfy the requirements of all triangular application instances 2402 and line application instances 2404 of the graph application instance 2406. In the alternative method, the triangle application instance 2402 and line application instance 2404 of graph application instance 2406 are processed one at a time, from the largest to the smallest (by the number of application instances 118), or in some other order. In either method, if it is not possible to provision any set of triangle application instance 2402 or line application instance 2404, i.e., if the operation fails (3018, 3118), method 3200 fails for the graph application instance. Alternatively, partial failure may be permitted so that the first part of the triangle application instance and / or line application instance 2404 is deployed even if the second part cannot be deployed.

[0242] Figure 34 is a block diagram of an exemplary computing device 3400. The computing device 3400 can be used to perform various procedures as described herein. The server 102, orchestrator 106, workflow orchestrator 122, vector log agent 126, log processor 130, and cloud computing platform 104 may each be implemented using one or more computing devices 3400. The orchestrator 106, workflow orchestrator 122, vector log agent 126, and log processor 130 may be implemented on different computing devices 3400, or a single computing device 3400 may host two or more of the orchestrator 106, workflow orchestrator 122, vector log agent 126, and log processor 130.

[0243] The computing device 3400 includes one or more processors 3402, one or more memory devices 3404, one or more interfaces 3406, one or more mass storage devices 3408, one or more input / output (I / O) devices 3410, and a display device 3430, all of which are coupled to a bus 3412. The processor 3402 includes one or more processors or controllers that execute instructions stored in the memory devices 3404 and / or mass storage devices 3408. The processor 3402 may also include various types of computer-readable media, such as cache memory.

[0244] The memory device 3404 includes various computer-readable media such as volatile memory (e.g., random-access memory (RAM) 3414) and / or non-volatile memory (e.g., read-only memory (ROM) 3416). The memory device 3404 may also include rewritable ROM such as flash memory.

[0245] The mass storage 3408 includes various computer-readable media such as magnetic tape, magnetic disks, optical disks, and solid-state memory (e.g., flash memory). As shown in Figure 34, a specific mass storage is a hard disk drive 3424. Various drives can also be included in the mass storage 3408 to enable reading from and / or writing to various computer-readable media. The mass storage 3408 includes removable media 3426 and / or non-removable media.

[0246] I / O devices 3410 include a variety of devices that enable data and / or other information to be input to and retrieved from computing device 3400. Exemplary I / O devices 3410 include cursor control devices, keyboards, keypads, microphones, monitors or other display devices, speakers, printers, network interface cards, modems, lenses, CCDs or other image capture devices, and the like.

[0247] The display device 3430 includes any type of device capable of displaying information to one or more users of the computing device 3400. Examples of display devices 3430 include monitors, display terminals, and video projection devices.

[0248] Interface 3406 includes a variety of interfaces that enable the computing device 3400 to interact with other systems, devices, or computing environments. An exemplary interface 3406 includes any number of different network interfaces 3420, such as interfaces to a local area network (LAN), a wide area network (WAN), a wireless network, and the internet. Other interfaces include a user interface 3418 and a peripheral interface 3422. Interface 3406 may also include one or more peripheral interfaces, such as interfaces for printers, pointing devices (mouse, trackpad, etc.), keyboards, etc.

[0249] Bus 3412 enables the processor 3402, memory device 3404, interface 3406, mass storage device 3408, I / O device 3410, and display device 3430 to communicate with each other and with other devices or components coupled to bus 3412. Bus 3412 represents one or more of several types of bus structures, such as the system bus, PCI bus, IEEE 1394 bus, and USB bus.

[0250] For illustrative purposes, programs and other executable program components are shown herein as separate blocks, but such programs and components may reside in different storage components of computing device 3400 at different times and be understood to be executed by processor 3402. Alternatively, the systems and procedures described herein can be implemented in hardware, or in a combination of hardware, software, and / or firmware. For example, one or more application-specific integrated circuits (ASICs) can be programmed to perform one or more of the systems and procedures described herein.

[0251] The above disclosures refer to accompanying drawings illustrating specific embodiments that form part of this specification and can be used to implement this disclosure. It is understood that other embodiments may be used and structural modifications may be made without departing from the scope of this disclosure. References to “one embodiment,” “an embodiment,” and “an example embodiment” in this specification indicate that the described embodiments may include certain features, structures, or characteristics, but not all embodiments may include certain features, structures, or characteristics. Furthermore, such phrases do not necessarily refer to the same embodiment. Furthermore, where certain features, structures, or characteristics are described in relation to an embodiment, it is considered to be within the knowledge of those skilled in the art that such features, structures, or characteristics may be affected in relation to other embodiments, whether or not they are explicitly stated.

[0252] Embodiments of the systems, devices, and methods disclosed herein may include or utilize a dedicated or general-purpose computer, including, for example, one or more processors and system memory, as described herein. Embodiments within the scope of this disclosure may also include physical and other computer-readable media for transporting or storing computer-executable instructions and / or data structures. Such computer-readable media may be any available media accessible by a general-purpose or dedicated computer system. A computer-readable medium that stores computer-executable instructions is a computer storage medium (device). A computer-readable medium that transports computer-executable instructions is a transmission medium. Thus, embodiments of this disclosure may include, but are not limited to, embodiments of at least two distinctly different types of computer-readable media, namely computer storage media (devices) and transmission media.

[0253] Computer storage media (devices) include RAM, ROM, EEPROM, CD-ROM, solid-state drives ("SSDs") (e.g., RAM-based), flash memory, phase-change memory ("PCM"), other types of memory, other optical disk storage, magnetic disk storage, or other magnetic storage devices, or any other media that can be used to store desired program code means in the form of computer executable instructions or data structures and can be accessed by a general-purpose or dedicated computer.

[0254] Embodiments of the devices, systems, and methods disclosed herein may communicate over a computer network. “Network” is defined as one or more data links that enable the transfer of electronic data between computer systems and / or modules and / or other electronic devices. When information is transferred to or provided to a computer over a network or another communication connection (either hardwired, wireless, or a combination of hardwired and wireless), the computer appropriately recognizes the connection as a transmission medium. The transmission medium may be used to carry desired program code means in the form of computer-executable instructions or data structures and may include networks and / or data links accessible by a general-purpose or dedicated computer. Such combinations should also fall within the scope of a computer-readable medium.

[0255] Computer executable instructions include, for example, instructions and data that, when executed by a processor, cause a general-purpose computer, a dedicated computer, or a dedicated processing unit to perform a specific function or group of functions. Computer executable instructions may be, for example, binary, intermediate format instructions such as assembly language, or source code. While this subject matter is described in language specific to structural features and / or methodological acts, it should be understood that the subject matter as defined in the attached claims is not necessarily limited to the features or acts described above. Rather, the described features and acts are disclosed as exemplary forms of implementing the claims.

[0256] Those skilled in the art will understand that the Disclosure may be implemented in network computing environments having many types of computer system configurations, including in-dash vehicle computers, personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, tablets, pagers, routers, switches, and various storage solutions. The Disclosure may also be implemented in a distributed system environment in which both local and remote computer systems linked over a network (by hardwired data links, wireless data links, or a combination of hardwired and wireless data links) perform tasks. In a distributed system environment, program modules may reside in both local and remote memory storage.

[0257] Furthermore, where appropriate, the functions described herein may be performed by one or more of the hardware, software, firmware, digital components, or analog components. For example, one or more application-specific integrated circuits (ASICs) may be programmed to perform one or more of the systems and procedures described herein. Throughout this specification and the claims, specific terms are used to refer to specific system components. Components may be referred to by different names, as will be understood by those skilled in the art. This specification is not intended to distinguish between components that have different names but no different functions.

[0258] It should be noted that the sensor embodiments described above may include computer hardware, software, firmware, or any combination thereof to perform at least some of their functions. For example, a sensor may include computer code configured to run on one or more processors and may include hardware logic / electrical circuits controlled by the computer code. These exemplary devices are provided herein for illustrative purposes only and are not intended to limit the scope of the invention. Embodiments of the Disclosure may be implemented in further types of devices as are known to those skilled in the art.

[0259] At least some embodiments of this disclosure relate to computer program products that include such logic (for example, in the form of software) stored on any computer-enabled medium. When such software is executed on one or more data processing devices, it causes the devices to operate as described herein.

[0260] While various embodiments of this disclosure have been described above, it should be understood that these are merely examples and not limiting. It will be apparent to those skilled in the art that various modifications in form and detail can be made without departing from the spirit and scope of this disclosure. Therefore, the breadth and scope of this disclosure should not be limited by any of the exemplary embodiments described above, but should be defined only in accordance with the following claims and their equivalents. The above description is provided for illustrative and explanatory purposes only. It is not intended to be exhaustive or to limit this disclosure to the exact forms disclosed. Many modifications and variations are possible in light of the above teachings. Furthermore, it should be noted that any or all of the alternative embodiments described above may be used in any desired combination to form additional hybrid embodiments of this disclosure.

Claims

1. (a) a specification for one or more application instances is received, which includes both one or more computing resource requirements and (b) one or more cluster runtime requirements, where each of the one or more cluster runtime requirements defines the requirements that permit the execution of the application instance; For each of the one or more application instances, identify one or more clusters associated with one or more hosts that satisfy (a) and (b); and, The one or more application instances are deployed on the one or more hosts associated with the one or more identified clusters. Structured in such a way Device.

2. The one or more application instances include three or more application instances, The one or more clusters include three or more clusters, The one or more cluster runtime requirements include latency requirements for the latency between each possible pair of clusters in the three or more clusters, The apparatus according to claim 1.

3. The one or more application instances include two or more application instances arranged in a hierarchical manner. The one or more clusters include two or more clusters, The one or more cluster runtime requirements include a cost function for at least one of the two or more clusters. The apparatus according to claim 1.

4. The cost function is the cost of hosting the most resource-intensive of the two or more application instances. The apparatus according to claim 3.

5. Of the two or more application instances mentioned above, the most resource-intensive one is the database application instance. The apparatus according to claim 4.

6. The one or more computing resource requirements include processing capacity requirements, The apparatus according to claim 1.

7. The one or more computing resource requirements include a memory requirement. The apparatus according to claim 1.

8. The one or more computing resource requirements include storage requirements, The apparatus according to claim 1.

9. The aforementioned device further, If it is determined that none of the available clusters meet the one or more computing resource requirements and the one or more cluster runtime requirements, (c) It is determined that the above specification defines an acceptable range, and (c) is configured to identify one or more clusters in response to (c), The apparatus according to claim 1.

10. The one or more cluster runtime requirements include location requirements, The apparatus according to claim 1.

11. The one or more cluster runtime requirements include availability requirements, The apparatus according to claim 1.

12. The above specifications are, DotApplication instance, Triangular application instance, and Line application instance Define one or more of the following: The apparatus according to claim 1.

13. The aforementioned one or more hosts are servers. The apparatus according to claim 1.

14. The one or more hosts mentioned above are part of a cloud computing platform. The apparatus according to claim 1.

15. The computer system receives specifications for multiple application instances, wherein the specifications include (a) one or more computing resource requirements and (b) one or more cluster runtime requirements, each of which defines the requirements that permit the execution of the application instance; Dividing the aforementioned multiple application instances into two or more groups of two or more different types; and, For each of the two or more groups mentioned above: The computer system identifies one or more clusters associated with one or more hosts that satisfy (a) and (b) for each application instance in each group; and, The computer system includes deploying one or more application instances of each group on one or more hosts associated with the identified one or more clusters, method.

16. The two or more different types include a triangular application instance, The method according to claim 15.

17. The two or more different types include a linear application instance, The method according to claim 15.

18. The two or more different types include a triangular application instance and a line application instance, The method according to claim 15.

19. The one or more cluster runtime requirements include one or more first runtime requirements for a first type among the two or more different types, and one or more second runtime requirements for a second type among the two or more different types. The one or more second runtime requirements described above are different from the one or more first runtime requirements described above. The method according to claim 15.

20. The one or more first runtime requirements include inter-cluster latency requirements, The one or more second runtime requirements include cost requirements, The method according to claim 19.

Images