Patent Application
20230153161
The present disclosure relates generally to workload monitoring for workload resource allocation.
Service providers offer monitoring services, or solutions, to provide users with observability resources associated with processing of workloads. These service providers often maintain networks of data centers which house devices, including servers, routers, and other devices, that provide computing resources to users. For instance, observability resources that are provided may include compute resources, networking resources, storage resources, database resources, application resources, security resources, and so forth. For instance, devices (e.g., user devices) utilizing the observability and computing resources may include computers (such as laptops, desktops, servers, smartphones, and tablets) and various other types of devices, which may include an ever-expanding array of Internet-of-Things (IoT) devices (such as cameras, door locks, doorbells, refrigerators, audio/visual systems, thermostats, and various sensors). Modern-day networks deliver various types of network architectures, such as Local-Area Networks (LANs) that are in one physical location such as a building, Wide-Area Networks (WANs) that extend over a large geographic area to connect individual users or LANs, Enterprise Networks that are built for a large organization, Internet Service Provider (ISP) Networks that operate WANs to provide connectivity to individual users or enterprises, and so forth.
The monitoring services may be utilized to track observability resource metrics (or “metrics”) associated with the computing resources. The metrics may include information about the computing resources utilized to process workloads. The computing resources may be associated with physical computing machines or virtual computing machines (or “virtual machines (VMs)”). The VMs may be scaled across physical servers in a cloud computing network. Each hardware piece of several pieces of hardware may perform a single function, or each VM of several VMs within a single piece of hardware may perform actions of one or more virtual network functions (VNFs). Containers may act as an operating system (OS) virtualization for network function virtualization. The containers may share the same host OS of a VM or run individual VNFs in an isolated manner such that each VM supports multiple containerized VNFs. The workloads may be routed to computing resources (e.g., network components (or “network devices”) in a serverless network by performing optimization of deployment locations including the computing resources.
In light of various limitations and disadvantages of monitoring computing resources that may be universally the same throughout the cloud network, instrumentation for observability of the computing resources has emerged. The instrumentation may include deploying program codes that are executed by the computing resources via processing of observability tools (e.g., Linux classic Berkeley packet filter (cBPF) programs, Linux extended BPF (eBPF) programs, etc.). The observability tools may be utilized to output information associated with utilization of the computing resources, such as whether a file is accessed by a user. The observability tools may be further utilized to identify information associated with data exchanged between various computing resources, such as devices that maintain databases, execute operating systems, and the like. The metrics may be retrieved by utilizing the observability tools to determine performance of the computing resources at runtime. However, various inefficiencies and disadvantages still exist when utilizing instrumentation for observability.
The detailed description is set forth below with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items. The systems depicted in the accompanying figures are not to scale and components within the figures may be depicted not to scale with each other.
The present disclosure relates generally to utilizing workload resources to optimize processing of workloads by network devices.
A first method described herein includes utilizing requests indicating observability metrics received in requests received from user devices to manage allocation, deployment, and execution of workloads. The requests (or “user requests”) may be received for execution of workloads based on selections (or “user selections”) indicated via user input. Workload statuses (or “workload pending statuses”) may be determined as pending, based on the user requests. One or more metrics (or “user requested metric(s)”) associated with observability (or “user requested observability”) may be indicated by the user requests. The user requested metric(s) may be utilized to deploy the workloads to one or more computing resources. The workloads may be deployed to the computing resource(s) based on determining the computing resource(s) include one or more observability computing resources (or “observability resources”) associated with the user requested metric(s). The computing resource(s) may utilize the observability resource(s) to provide various types of observability, such as compute observability, storage observability, and network observability. The computing resource(s) may utilize the observability resource(s) to transmit the user requested metric(s) based on execution of the workloads.
A second method described herein includes utilizing availability of computing resources, to manage allocation, deployment, and execution of workloads. The workloads may be deployed based on availability of observability resources, which may be determined based on availability scores associated with the observability resources. One or more computing resources may be determined based on determining with a portion (e.g., a partial portion or an entire portion) of one or more observability resources in the computing resource(s) are associated with corresponding user requested metric(s). The computing resource(s) may be associated with one or more corresponding availability scores. The computing resource(s) (or “unavailable computing resource(s)”) may be determined to be not available based on the availability score(s) being less than one or more corresponding threshold availability scores. One or more other computing resources may be determined based on determining with another portion (e.g., a partial portion or an entire portion) of one or more other observability resources in the other computing resource(s) are associated with corresponding user requested metric(s). The portion of the other observability resource(s) may include the same or fewer observability resources than the portion of the observability resource(s) provided by the unavailable computing resource(s). The other computing resource(s) may be determined further based on determining one or more corresponding other availability scores associated with the other computing resource(s). The other computing resource(s) may be determined to be available based on the other availability score(s) meeting or exceeding one or more corresponding other threshold availability scores. The workloads may be deployed to the other computing resource(s), based on the other computing resource(s) being determined to be available.
A third method described herein includes utilizing workload migrate statuses (or “migrate statuses”) to manage allocation, deployment, and execution of workloads. The migrate statuses may be associated with workloads being executed by computing resources that include observability resources. One or more computing resources (or “initial computing resource(s)) currently executing the workloads may include a portion (e.g., a partial portion or an entire portion) of one or more observability resources associated with one or more metrics. The metric(s) (or “intuited metric(s)) may be determined based on performance of execution of the workloads by the initial computing resource(s). One or more other computing resources may include another portion (e.g., a partial portion or an entire portion) of the observability resources. The portion of the observability resource(s) included in the initial computing resource(s) executing the workloads may include different observability resources than the other portion of the observability resource(s). The migrate statuses associated with the workloads may be initially determined as pending. The migrate statuses associated with the workloads may be determined as active, based on determining the other computing resource(s) that include the other portion of the other observability resource(s) are available. The workloads may be migrated from the initial computing resource(s) to the other computing resource(s) based on the migrate statuses associated with the workloads being determined as active. The workloads may be migrated from the initial computing resource(s) to the other computing resource(s) by determining one or more potential destination locations, and a next placement associated with the workloads.
A fourth method described herein includes utilizing user intent to manage allocation, deployment, and execution of workloads. User requests for execution of workloads may be received based on selections (or “user selections”) indicated via user input. The user requests may include one or more intent based descriptions. Individual ones of the intent based descriptions may be associated with one or more user requested characteristics (or “characteristics”) associated with observability for the workloads. The user requested characteristic(s) may be utilized to determine one or more metrics associated with observability. One or more computing resources may be determined based on determining the computing resource(s) include one or more observability resources of the same type (e.g., category) as the metric(s). The computing resource(s) may be determined further based on determining the observability resource(s) are of the same sub-type (e.g., sub-category) as the metric(s). The workloads may be deployed to the computing resource(s) to execute the workloads and transmit the metric(s). One or more observability processes and/or one or more metrics streams may be determined based on the user requested characteristics(s), and utilized to transmit the metric(s).
Additionally, the techniques described herein may be performed by a system and/or device having non-transitory computer-readable media storing computer-executable instructions that, when executed by one or more processors, performs the method described above.
Cloud computing has continued to evolve and become more complex in terms of how workloads are processed and managed by computing resources (or “computing resource components”) of cloud computing networks. For instance, observability technologies utilized to monitor effectiveness of computing resources that execute workloads continue to evolve. Observability technologies may be utilized to collect information associated with program execution (or “workload execution”), internal states of software being executed utilizing the computing resources, and communications exchanged between components of the computing resources. Observability technologies may utilize various techniques and tools, such as techniques and tools associated with logging, tracing, and the like.
As noted above, observability technologies traditionally were utilized to collect information associated with workload execution. However, due to limitations of observability technologies that universally provide the same type of observability for computing resources throughout a cloud network, instrumentation of the computing resources via various technologies, such as kernel technologies (e.g., extended Berkeley packet filter (eBPF) technologies) emerged. The kernel technologies are utilized to instrument kernel data structures (e.g., file descriptors, etc.) by executing program scripts via a system call. Instrumentation is utilized to optimize observability associated with the computing resources to provide various types of metrics based on execution of programs associated with instrumentation. However, various costs and limitations still exist when utilizing instrumentation to provide observability associated with execution of workloads. For example, utilizing kernel programs for observability may require additional amounts of time for, and/or result in decreased performance during, execution of the workloads by the computing resources.
This disclosure describes techniques and mechanisms for using observability to allocate and deploy workloads for execution by computing resources in a cloud network. In some examples, the workloads may be allocated and deployed to computing resources based on user requested metrics. In additional examples, workloads that are initially allocated to computing resources that are determined to have a lack of availability may be reallocated and deployed to other computing resources that provide observability that is different from the computing resources to which the workloads are initially allocated. Once workloads have been deployed to computing resources, the workloads may be redeployed to other computing resources that include more observability resources associated with the user requested metrics. In additional examples, workloads may be allocated and deployed based on intent based descriptions associated with user requested characteristics utilized to determine types of metrics for providing observability.
Generally, workloads are allocated to computing devices in cloud networks based on various types of considerations, such as business considerations (e.g., timeliness, legal/regulatory issues, asset control, global reach, etc.), technical considerations (e.g., performance, security, back-end integration, data volume, workload elasticity, etc.), ecosystem considerations (e.g., software as a service (SaaS) maturity, cloud service provider (CSP) offerings, market accessibility, etc.), and the like. This disclosure describes a workload orchestrator that allocates and deploys workloads to computing resources in cloud networks based on observability associated with workload execution.
As described herein, workloads generally are programmatic functions where pieces of code are executed by computing resources in networks, such as cloud networks. The functions may be compute functions, storage functions, and network functions. The computing resources to which the workloads are deployed may include physical computing machines (or “workstation elements”), virtual computing machines (or “virtual machines (VMs)”), containers, pods, or any other type of computing resources. The workloads may be deployed to other types of computing resources, such as network components (or “network devices”) in a serverless network by optimizing deployment locations that include the computing resources.
Thus, the workload orchestrator may receive requests (or “user requests”) associated with selections (or “user selections”) indicated by user input to user devices. The requests may indicate workloads and metrics utilized to provide observability associated with execution of the workloads. For instance, the metrics may include metrics associated with compute monitoring (or “compute metrics”), metrics associated with storage monitoring (or “storage metrics”), and/or metrics associated with network monitoring (or “network metrics”). The workload orchestrator may determine one or more computing resources including one or more observability resources associated with one or more metrics (or “user requested metric(s)”). The computing resource(s) may be determined for deployment of the workloads based on observability associated with the observability resource(s) being the same as observability associated with the user requested metric(s). The workload orchestrator may deploy the workloads to the computing resource(s) based on determining that individual ones of the observability resource(s) provide the same type of observability that is associated with one or more corresponding metrics among the user requested metric(s).
In some examples, the techniques described herein may include utilizing availability of computing resources to allocate and deploy workloads. The workloads may be initially allocated to one or more computing resource(s) that provide observability associated with one or more user requested metrics. The computing resource(s) may include one or more observability resources, with individual ones of the observability resource(s) providing the same type of observability that is associated with one or more corresponding metrics among the user requested metric(s). The workload orchestrator may determine one or more other computing resource(s) that include a portion (e.g., an entire portion or a partial portion) of the observability resource(s), based on determining the computing resource(s) are not available. The portion of the observability resource(s) in the other computing resource(s) may include fewer observability resources than in the initial computing resources(s). The workload orchestrator may allocate and deploy the workloads to the other computing resource(s), based on determining the other computing resource(s) are available.
As another example, the workload orchestrator may migrate workloads from one or more current computing resources to one or more other computing resources. The workload orchestrator may determine to migrate the workloads based on determining the current computing resource(s) include a portion (e.g., an entire portion or a partial portion) of one or more observability resource(s) associated with one or more metrics. The metric(s) (or “intuited metric(s)) may be determined based on performance of execution of the workloads by the current computing resource(s). The workload orchestrator may allocate the workloads to the other computing resource(s) based on determining the other computing resource(s) include more of the observability resource(s) associated with the user requested metric(s) than the current computing resource(s). The workload orchestrator may determine that another portion (e.g., an entire portion or a partial portion) of the observability resource(s) in the other computing resources(s) is larger than the portion of the observability resource(s) in the current computing resources(s). The workload orchestrator may migrate the workloads to the other computing resources(s).
As an even further example, the workload orchestrator may utilize intent based descriptions indicated in requests (or “user requests”) received from user devices to determine allocation and deployment of workloads. One or more characteristics associated with intent based descriptions received in one or more requests may be utilized to determine one or more metrics associated with observability. The workload orchestrator may determine the metric(s) and utilize the metric(s) to determine one or more computing resources. The computing resource(s) may be determined to allocate the workloads to the computing resource(s) based on determining the computing resource(s) include one or more observability resource(s) associated with the same type (e.g., category) of observability as the metric(s). The workload orchestrator may determine the computing resource(s) further based on the determining the observability resource(s) are associated with the same sub-type (e.g., sub-category) of observability as the metric(s). The workload orchestrator may deploy the workloads to the computing resource(s), which execute the workloads and transmit the metric(s).
While these are merely illustrative examples, other criteria or characteristics (discussed further below) may be considered when determining optimal, or optimized, computing resources on which to deploy and execute the workloads. The techniques are generally applicable to any type of cloud networks and network behavioral elements, including serverless networks. That is, the techniques for optimizing placement of workloads are generally applicable to any piece of software code that is a piece of networking behavior tailored to run in a convenient runtime environment (hardware or software) on a component in the network.
As described herein, a computing resource component may comprise any type of component, hardware-based, software-based, etc., that is capable of hosting or running a cloud network function or a serverless network function. For example, a computing resource component may comprise hardware-based devices such as a server, a router, a network switch (e.g., leaf switch, spine switch, etc.), a gateway, a network interface card (NIC), a smart NIC, a Field Programmable Gate Array (FPGA), an Application-Specific Integrated Circuit (ASIC), and/or any other hardware device capable of executing a serverless network function. The computing resource component may comprise a software-based component as well, such as a virtual machine, container, and so forth.
In some examples, the network architecture 102 may include devices housed or located in one or more data centers 104. The network architecture 102 may include devices, virtual resources, or other nodes that relay packets from one network segment to another by nodes in the computer network. The network architecture 102 may include multiple devices that utilize the network layer (and/or session layer, transport layer, etc.) in the OSI model for packet forwarding, and/or other layers. The network architecture 102 may include various hardware devices, such as routers, switches, gateways, smart NICs, NICs, ASICs, FPGAs, servers, and/or any other type of device. Further, the network architecture 102 may include virtual resources, such as VMs, containers, and/or other virtual resources.
The one or more data centers 104 may be physical facilities or buildings located across geographic areas that designated to store networked devices that are part of the network architecture 102. The data centers 104 may include various networking devices, as well as redundant or backup components and infrastructure for power supply, data communications connections, environmental controls, and various security devices. In some examples, the data centers 104 may include one or more virtual data centers which are a pool or collection of cloud infrastructure resources specifically designed for enterprise needs, and/or for cloud-based service provider needs. Generally, the data centers 104 (physical and/or virtual) may provide basic resources such as processor (CPU), memory (RAM), storage (disk), and networking (bandwidth). However, in some examples the devices in the network architecture 102 may not be located in explicitly defined data centers 104, but may be located in other locations or buildings.
The user devices 108 may establish communication connections over one or more networks 118 to communicate with devices in the network architecture 102, such as the workload orchestrator 110 and the monitoring service 114 of the network architecture 102. The network(s) 118 may include any viable communication technology, such as wired and/or wireless modalities and/or technologies. Networks 118 may include any combination of Personal Area Networks (PANs), Local Area Networks (LANs), Campus Area Networks (CANs), Metropolitan Area Networks (MANs), extranets, intranets, the Internet, short-range wireless communication networks (e.g., ZigBee, Bluetooth, etc.) Wide Area Networks (WANs)—both centralized and/or distributed—and/or any combination, permutation, and/or aggregation thereof. The user devices 108 may communicate using any type of protocol over the network 118, such as the transmission control protocol/Internet protocol (TCP/IP) that is used to govern connects to and over the Internet.
As illustrated, the user device 108 may receive one or more selections via input to the user device 108. As illustrated, the user device 108 may receive, at “1”, one or more selections via input (or “user input”) indicating the workload 112. The selection(s) may be received by the user device 108 to request execution of the workload 112, based on allocation and deployment of the workload 112 by the workload orchestrator 110.
At “2,” the user device 108 may receive one or more selections via user input indicating one or more metrics (or “requested metric(s),” “user requested metric(s)”) 116. Information (e.g., input data) associated with any of one or more of the selection(s) may be received by the user device 108 and transmitted to the workload orchestrator 110, which may utilize the requested metric(s) 116 for allocation and deployment of the workload 112. In some examples, the input data may be added to a user account (e.g., an account associated with the user 106), which may provide the user data that is transmitted to the workload orchestrator 110. Although the selection(s) indicating the workload 112 may be separate from the selection(s) indicating the metric(s) as discussed above in this disclosure, it is not limited as such. In some examples, any of the selection(s) indicating the workload 112 may be integrated (e.g., combined) together with any of the selection(s) indicating the metric(s), in any way.
The requested metric(s) 116 may include one or more compute metrics, one or more storage metrics, and/or one or more network metrics. For instance, the requested metric(s) 116 may include the compute requested metric(s) based on the user 106 determining the workload 112 is associated with compute functions. In some instances, the requested metric(s) 116 may include the storage requested metric(s) based on the user 106 determining the workload 112 is associated with storage functions. In those instances, or other instances, the requested metric(s) 116 may include the storage requested metric(s) based on the user 106 determining the workload 112 is associated with storage functions. In those instances, or other instances, the requested metric(s) 116 may include the network requested metric(s) based on the user 106 determining the workload 112 is associated with network functions.
By providing the selection(s) via the user input indicating the requested metric(s) 116, the user 106 may prioritize the requested metric(s) 116 with respect to one or more remaining metrics not indicated by the selection(s). The user 106 may determine to, based on the remaining requested metric(s) being relatively less important for purposes of managing execution of the workload 112, refrain from providing input indicating the remaining requested metric(s). In some examples, and as a result of the requested metric(s) 116 being prioritized by the selection(s), information associated with the requested metric(s) 116 provided to the workload orchestrator 110. In those examples, the information associated with the requested metric(s) 116 may be added to the user account. The information associated with the requested metric(s) 116 may be provided from the user account and to the workload orchestrator 110. The workload orchestrator 110 may utilize the information associated with the requested metric(s) 116 for allocation and deployment of the workload 112.
At “3,” the user device 108 may transmit a request (or “user request”) indicating the workload 112 and the requested metric(s) 116 to the workload orchestrator 110, via the network(s) 118. The user request may include user data from a user account (e.g., an account associated with the user), the user data including any information (or “workload information”) associated with the workload 112. The workload information may include any information utilized for execution of the workload 112, such as a workload priority, a workload identifier, a workload type, a workload version, resource consumption requirements, etc. The workload information may include data of the workload 112 to be utilized at execution of the workload 112). Additionally or alternatively to the user request, any of the workload information may be determined based on historical data associated with workload resource consumption (e.g. consumption of one or more workload resources).
In some instances, the user request may include, in the user data, information associated with the requested metric(s) 116. For instance, the user request may be utilized to determine whether to provide observability associated with individual ones of the requested metric(s) 116 based on corresponding metric information in the user request. The corresponding metric information may include a metric priority value (or “requested metric priority value”) indicating a metric priority, a metric identifier associated with the metric, a metric type value indicating a metric type, a program identifier (e.g., an identifier of a program and/or function that may be implemented/executed for determining the corresponding metric), resource consumption requirements, and any other information to be utilized for providing observability. Additionally or alternatively to the user request, any of the metric information may be determined based on historical data associated with workload resource consumption (e.g. consumption of one or more workload resources).
At “4,” the workload orchestrator 110 may receive the user request indicating the workload 112 and the requested metric(s) 116. The workload orchestrator 110 may receive, in the user request, the workload information and the metric information.
At “5”, the workload orchestrator 110 may determine a placement associated with the workload 112. To determine the placement, the workload orchestrator 110 may determine one or more potential destination locations. The workload orchestrator 110 may determine the requested metric(s) 116 based on the metric information included in the user request. In some instances, the determining of the placement may include determining one or more of computing resources (or “host(s)”) 120a-120d (collectively referred to herein as hosts 120), as the potential destination location(s). For instance, with examples in which the requested metric(s) 116 indicated via the user request include multiple requested metrics (e.g., a metric (or “compute metric”) associated with compute observability, a metric (or “storage metric”) associated with storage observability, and a metric (or “network metric”) associated with network observability) 116, the workload orchestrator 110 may determine the placement of the workload 112 as the host 120(a). The workload orchestrator 110 may determine to place the workload 112 on the host 120(a), as a destination location.
The determining of the placement of the workload 112 may include determining to allocate the workload 112 to the host 120(a), based on the host 120(a) including observability (e.g., compute observability, storage observability, and network observability) associated with each of the requested metrics 116 (e.g., the compute metric, the storage metric, and the network metric) that are indicated via the request received from the user device 108. The placement of the workload 112 on the host 120(a) may be determined based on the host 120(a) providing observability via one or more observability resources in the host 120(a). The observability resource(s) in the host 120(a) may include multiple observability resources, including one or more compute observability resources utilized to provide compute observability, one or more storage observability resources utilized to provide storage observability, and one or more network observability resources utilized to provide network observability.
At “6,” the host 120(a) may execute the workload 112. In some instances, the workload orchestrator 110 may cause the host 120(a) to execute the workload 112, such as by transmitting, to the host 120(a), the workload 112, along with and a request (or “orchestrator request”) to execute the workload 112. For instance, the host 120(a) may execute the workload 112 based on receiving the workload 112, such as by automatically executing the workload 112 upon receipt. In other instances, the host 120(a) may execute the workload 112 based on information (or “workload orchestrator information”) received from the workload orchestrator 110. The workload orchestrator information may indicate the workload 112, a priority (or “workload priority”) associated with the workload 112, the metrics 116, and/or individual priorities associated with the corresponding metrics 116. In any of the instances as discussed above, the host 120(a) may execute the workload 112 by adding a workload entry to a queue in the host 120(a), and executing the workload 112 based on the workload entry being at a top of the queue.
At “7,” the monitoring service 114 may monitor execution of the workload 112 to provide observability. Different types of observability (or “observability types”) may be provided, including compute observability, storage observability, and network observability. The monitoring of the execution of the workload 112 may include monitoring different types of performance (or “performance types”) associated with execution of the workload 112. Individual types of observability that are provided may be associated with corresponding performance types. Compute observability associated with compute performance, storage observability associated with storage performance, and network observability associated with network performance may be provided by the monitoring service 114. The monitoring metric(s) 122 may include multiple monitoring metrics 122, based on the requested metrics 116 being utilized to determine execution, by the host 120(a), of the workload 112.
In some instances, the different types of observability that are provided may include compute observability that is provided by determining one or more compute metrics of the monitoring metrics 122, storage observability that is provided by determining one or more storage metrics of the monitoring metrics 122 and network observability that is provided by determining one or more network metrics of the monitoring metrics 122. The different types of observability may be provided by transmitting, by the monitoring service 114 and to the user device 108, the monitoring metrics 122. The monitoring metrics 122 that are transmitted may include the compute metric(s), the storage metric(s), and the network metric(s).
At “8,” a user interface 124 of the user device 108 may be utilized to output the monitoring metrics 122. The user device may receive the monitoring metrics 122, including the compute metrics, the storage metrics, and the network metrics. The compute metrics, the storage metrics, and the network metrics may be displayed by a metrics interface 126 of the user interface 124.
The monitoring metrics 122 that are displayed may include monitoring metrics 122 that are monitored over a period of time (e.g., a period of time between a time at which the workload 112 begins to be executed until a time 24 hours later). Although a period of time that is 24 hours long is illustrated in
In this way, workloads may be routed to hosts in order to perform functions that are traditionally performed utilizing the hosts to execute the workloads. However, the techniques described herein include using metrics indicated by requests from user devices to determined placement of workloads indicated by the requests. By determining the placement of workloads based on metrics (e.g., requested metrics), workloads may be allocated to some hosts due to not all of the hosts including the same observability. Because providing observability may effect various aspects of the hosts, such as system performance and power consumption, and may require more complex and/or expensive hardware, utilizing the observability provided by the hosts to determine workload placement enables some, but not all, hosts to provide certain types of observability. The workloads are placed on the hosts that provide the required types of observability, while other hosts that are not utilized to execute the workloads may be utilized to provide different types of observability utilized by other workloads. Overall system efficiency and performance may be improved.
Although the workload orchestrator 110 may determine to place the workload 112 on the host 120(a) based on individual types of observability (or “matching host observability types”) provided by the host 120(a) that match corresponding types of observability (or “metrics observability types) associated with the metrics 116 as discussed above in the current disclosure, it is not limited as such. Individual host configurations may be associated with corresponding numbers of types of observability (e.g., a host may be associated with a number of the host observability types). In some examples, the workload orchestrator 110 may determine to place the workload 112 on the host 120(a) based on a number (e.g., three) of matching host observability types (e.g., host observability types that each match an observability types associated with one of the metrics 116) associated with the host 120(a) meeting or exceeding a number of matching host observability types associated with any of the remaining hosts 120 (e.g., the host 120(b) provides two host observability types, including compute observability and network observability, each of which matches one of the metrics observability types). In other examples, the workload orchestrator 110 may determine to place any workload on any host, based on the host corresponding configuration, in a similar way as for the workload 112 being place on the host 120(a).
Alternatively or in addition to utilizing the number of the matching host observability types, the workload orchestrator 110 may determine workload placement based on one or more observability priorities. Individual ones of the observability priority(ies) may be associated with corresponding metric priority values (e.g., the request metric priority values received in the user request). The workload orchestrator 110 may determine whether to utilize the metric priority value(s) to place the workload 112 on the host 120(a). In a case in which the number of the matching host observability types associated with the host 120(a) meets or exceeds the number of matching host observability types associated with any of the remaining hosts 120, the workload orchestrator 110 may determine to refrain from utilizing the metric priority values to place the workload 112. In some examples, the workload orchestrator 110 may utilize predetermined metric priority values based on the user request not including at least one metric priority value (e.g., a number of metric priority values in the user request being less than a number of the metrics 116). Individual predetermined metric priority values associated with the corresponding observability priorities may be utilized to place the workload 112, based on the corresponding metric priorities being absent from the user request. Any of the techniques utilizing the received metric priority values, as discussed herein, may be implemented in a similar way, by utilizing individual ones of the predetermined metric priority values associated with the corresponding metrics for which priority values were not received.
The workload orchestrator 110 may utilize deployment weights associated with numbers of observability types and observability priorities, to determine workload placement. The deployment weights may include one or more deployment weights (or “initial deployment weight(s)”) based on one or more weight values. In some examples, the weight value(s) may include multiple weight values, including a weight value associated with determining the workload placement based on numbers of observability in corresponding hosts 120. In those examples, the multiple weight values may include a weight value associated with determining the workload placement based on observability priorities. In some instances, the workload orchestrator 110 may determine to utilize the numbers of observability in corresponding hosts 120, but not the observability priorities, to determine the workload placement, based on the weight value associated with the numbers of observability in corresponding hosts 120 being larger than the weight value associated with observability priorities. In other instances, the workload orchestrator 110 may determine to utilize the observability priorities, but not the numbers of observability in corresponding hosts 120, to determine the workload placement, based on the weight value associated with the numbers of observability in corresponding hosts 120 being less than the weight value associated with observability priorities. In other instances, the workload orchestrator 110 may determine to utilize the numbers of observability in corresponding hosts 120, as well as the observability priorities, to determine the workload placement, based on the weight value associated with the numbers of observability in corresponding hosts 120 being the same as the weight value associated with observability priorities.
Weight values (or “requested weight value(s)”) may be received in the user request. The deployment weights may include one or more deployment weights (or “modified deployment weight(s)”) based on the requested weight value(s) and/or one or more predetermined weight values. In some examples, the requested weight value(s) may be replaced by the predetermined weight value(s) to replace the initial deployment weight(s) with the modified deployment weight(s). In other examples, the requested weight value(s) may be integrated with the predetermined weight value(s) to determine combined deployment weight(s). Individual ones of the initial requested weight value(s) may be combined with corresponding predetermined weight value(s) to determine the combined deployment weight(s) as the modified deployment weight(s). By way of example, individual ones of the combined deployment weight(s) may be an average of the corresponding initial requested weight value(s) and the corresponding predetermined weight value(s). Any of the weight values associated with the initial deployment weight(s), or the weight values associated with the modified deployment weight(s), may be implement as the weight values utilized for determining the workload placement, as discussed above.
Although the workload orchestrator 110 is separate from the monitoring service 114 as discussed above in the current disclosure, it is not limited as such. The workload orchestrator 110 may be integrated, and/or combined, with the monitoring service 114, and utilized in any of the techniques as discussed herein to implement one or more of the functions of the workload orchestrator 110 and/or the functions of the monitoring service 114.
Although workloads may be compute functions, storage functions, and network functions as discussed above in the current disclosure, it is not limited as such. Any of the techniques related to workloads as discussed herein may be implemented in a similar way for workloads including one or more types of functions, including compute functions, storage functions, network functions, and any other type of functions. Although observability includes compute observability, storage observability, and network observability as discussed above in the current disclosure, it is not limited as such. Any of the techniques related to observability as discussed herein may be implemented in a similar way for one or more types of observability, including compute observability, storage observability, network observability, and any other type of observability. Although metrics include compute metrics, storage metrics, and network metrics as discussed above in the current disclosure, it is not limited as such. Any of the techniques related to metrics as discussed herein may be implemented in a similar way for one or more types of metrics, including compute metrics, storage metrics, network metrics, and any other type of metrics.
Although the different types of observability may be associated with corresponding types of metrics that are monitored and transmitted as discussed above in this disclosure, it is not limited as such. The term “metrics,” referring to data that is utilized for managing workload execution, and the term “observability,” referring to the concept of utilizing data for managing workload execution, may be interpreted as being interchangeable for purposes of any of the techniques discussed throughout this disclosure.
Although the term “computing resource(s)” may include resources of a host that are utilized to execute workloads, and the term “observability resource(s)” may include resources of a host that are utilized to provide observability, as discussed in this disclosure, it is not limited as such. The term “computing resource(s)” may be interpreted throughout the disclosure herein to refer to one or more hosts, one or more computing resources in a host, one or more observability resources in a host, any combination of one or more resources (e.g., the computing resource(s) and/or the observability resource(s)) in a host or multiples hosts. The computing resource(s) according to any interpretation as discussed above may be utilized to implement the computing resources(s) and/or the observability resource(s) utilized in any of the techniques as discussed throughout this disclosure.
Although computing resource(s) not utilized to provide observability may be implemented separately from computing resource(s) (e.g., observability resource(s)) utilized to provide observability as discussed above in this disclosure, it is not limited as such. In some examples, the computing resource(s) not utilized to provide observability and the computing resource(s) (e.g., observability resource(s)) utilized to provide observability may be integrated and utilized to perform any techniques associated with any computing resource(s) functions and/or any observability resource(s) functions as discussed throughout this disclosure.
Although individual portions of the user interface 124 may be utilized to display the corresponding metrics as discussed above in this disclosure, it is not limited as such. In some examples, any portion of the user interface 124 utilized associated with observability that is not being monitored for the workload 202 may be omitted. The user interface 124, instead of having three portions, may include any number (e.g., 2, 4, 6, 8, 10, 20, 40, etc.) of portions, with individual ones of the portions (e.g., an upper portion and a lower portion) being utilized to display the corresponding metrics associated with the corresponding observability (e.g., the storage observability and the network observability, respectively) provided by the host 120(c). Although individual portions of the user interface 124 may be utilized to display the corresponding metrics as a bar graph as discussed above in this disclosure, it is not limited as such. In some examples, individual portions of the user interface 124 may be utilized to display the corresponding metrics in any form (e.g., a line graph, a pie graph, numerical characters,
As illustrated, at “1”-“3,” the user device 108 may perform similar functions utilizing a workload 202 and requested metric(s) 204, in a similar way as for the workload 112 and the requested metric(s) 116 at “1”-“3,” as discussed above with reference to
At “5”, the workload orchestrator 110 may determine a placement (or “initial placement”) associated with the workload 202. To determine the initial placement, the workload orchestrator 110 may determine one or more potential destination locations. The determining of the placement may include determining one or more of computing resources (or “host(s)”) 120a-120d (collectively referred to herein as hosts 120), as the potential destination location(s).
In some instances, with examples in which the requested metric(s) 116 include multiple requested metrics (e.g., a metric (or “compute metric”) associated with compute observability, a metric (or “storage metric”) associated with storage observability, and a metric (or “network metric”) associated with network observability) 116, the workload orchestrator 110 may determine the initial placement of the workload 112 as the host 120(a). The determining of the initial placement of the workload 112 may include determining to allocate the workload 112 to the host 120(a), based on the host 120(a) including observability (e.g., compute observability, storage observability, and network observability) associated with each of the requested metrics 116 (e.g., the compute metric, the storage metric, and the network metric) that are indicated via the request received from the user device 108
At “6,” the workload orchestrator 110 may determine a placement (or “next placement”) based on availability associated with the host 120(a). In some instances, the host 120(a) may be executing one or more other workloads 206. For instance, as illustrated, the workload(s) 206 being executed by the host 120(a) may include multiple workloads 206. The workload orchestrator 110 may determine the availability of the host 120(a) based on determining the host 120(a) is executing the workloads 206.
The availability of the host 120(a) may be determined by the workload orchestrator 110 and/or the host 120(a). In some cases, in which the availability of the host 120(a) is determined by the host 120(a), the workload orchestrator 110 may transmit a request (or “availability request”) to the host 120(a). The workload orchestrator 110 may receive information (or “availability information”) associated with the availability of the host 120(a) in a response (or “availability response”) received from the host 120(a).
The host 120(a) may determine the availability information based on workload information, metric information, and/or availability of various types of resources of the host 120(a). In some instances, the availability request transmitted to the host 120(a) may include workload information associated with the workload 202 and/or metric information associated with the metrics 204. The host 120(a) may determine availability of computing resources of the host 120(a) that are utilized to execute workloads (e.g., the workloads 206), and/or availability of observability resources of the host 120(a) that are utilized to provide observability. In some examples, the host 120(a) may determine the availability of computing resources of the host 120(a) at any time, such as an ongoing basis. In other examples, the host 120(a) may determine the availability of computing resources of the host 120(a), based on receiving the availability request.
Availability of the computing resources of the host 120(a) may be determined based on resources of the host 120(a) that are associated with execution of the workloads 206 and/or observability. A portion (e.g., first portion) (e.g. a partial portion of an entire portion) of computing resources of an entire portion of computing resources of the host 120(a) that are available may be determined by the host 120(a). A portion (e.g., second portion) (e.g. a partial portion of an entire portion) of observability resources of the entire portion of computing resources of the host 120(a) that are available, may be determined by the host 120(a).
The host 120(a) may transmit the availability information utilized by the workload orchestrator 110 to determine availability of the host 120(a). The availability information received from the host 120(a) may indicate any of one or more results of determinations (or “availability determinations) of availability of the host 120(a). In some examples, the availability information may indicate a result (or “computing resources availability result”) (e.g., first result) of a determination (or “computing resources availability determination”) (e.g., first availability determination) of whether an amount of available computing resources (or “available computing resources amount) (e.g., an amount (e.g., first amount) of the portion of available computing resources meets or exceeds a required resources amount (e.g., an amount of computing resources associated with execution of the workload 202, and/or a combination of an amount of computing resources associated with execution of the workload 202 and an amount of observability resources required to provide the metrics 204). The computing resources availability result may be determined as a value (e.g., first value) based on the result indicating the available computing resources amount meets or exceeds the required computing resources amount, or another value (e.g., second value) based on the result indicating the available computing resources amount is less than the required computing resources amount.
Alternatively or additionally, the availability information may indicate a result (e.g., second result) (or “observability resources availability result”) of a determination (or “observability resources availability determination”) (e.g., second availability determination) of whether an amount (or “available observability resources amount) (e.g., second amount) of the portion of available observability resources meets or exceeds the required resources amount (e.g., the amount of computing resources associated with execution of the workload 202, and/or the combination of the amount of computing resources associated with execution of the workload 202 and the amount of the observability resources required to provide the metrics 204).
The availability information may indicate positive availability based on positive results of the availability determinations. The availability information may include an availability value (or “positive availability value”) (e.g., first availability value), based on the observability resources availability result indicating that the available observability resources amount meets or exceeds the required resources amount. In some examples, the positive availability value may be included in the availability information, based on a combination of i) the observability resources availability result indicating that the available observability resources amount meets or exceeds the required resources amount, and ii) the computing resources availability result indicating that the available computing resources amount meets or exceeds the required resources amount. The workload orchestrator 110 may determine the availability of the host 120(a) as positive, based on the positive availability value.
The availability information may indicate negative availability based on negative results of the availability determinations. The availability information may include an availability value (or “negative availability value”) (e.g., second availability value), based on the observability resources availability result indicating that the available observability resources amount is less than the required resources amount. In some examples, in cases in which the available computing resources amount meets or exceeds the required resources amount, the negative availability value may be included in the availability information, based on the observability resources availability result indicating that the available observability resources amount is less than the required resources amount. In other examples, the negative availability value may be included in the availability information, based on a combination of i) the observability resources availability result indicating that the available observability resources amount is less than the required resources amount, and ii) the computing resources availability result indicating that the available computing resources amount is less than the required resources amount. The workload orchestrator 110 may determine the availability of the host 120(a) as negative, based on the negative availability value.
Alternatively or additionally to receiving the availability information in the availability response from the host 120(a), the workload orchestrator 110 may determine the availability of any of the hosts 120 (e.g., the host 120(a)) by determining the corresponding availability information for the host 120. The workload orchestrator 110 may determine the availability information based on information (or “received availability information”) in the availability response received from the host 120(a). The workload orchestrator 110 may transmit, in the availability request, an identifier (or “available computing resources amount identifier”) (e.g., first identifier) to request the available computing resources amount. The host 120(a) may transmit, in the availability response, the available computing resources amount based on determining the availability request includes the available computing resources amount identifier. In some examples, the host 120(a) may transmit, in the availability response, an amount of an entire portion of computing resources and/or an amount of a portion of the available computing resources of the host 120(a). The workload orchestrator 110 may perform the computing resources availability determination based on the received availability information (e.g., any of the received information, such as the available computing resources amount).
The workload orchestrator 110 may determine the availability information indicating the observability availability. The workload orchestrator 110 may transmit, in the availability request, an identifier (or “available observability resources amount identifier”) (e.g., second identifier) to request the available observability resources amount of any of the hosts (e.g., the host 120(a)). The host 120(a) may transmit, in the availability response, the available observability resources amount based on determining the availability request includes the available observability resources amount identifier. The received availability information may include an amount of an entire portion of observability resources and/or an amount of a portion of the available observability resources of the host 120(a). The workload orchestrator 110 may perform the observability resources availability determination based on the received availability information (e.g., any of the received information, such as the available observability resources amount). The workload orchestrator 110 may determine the availability information based on the computing resources availability determination and/or the observability resources availability determination in a similar way as discussed above for the host 120(a).
In some examples, the workload orchestrator 110 may determine the availability of the host 120(a) continuously, in real time. In some examples, the host 120(a) may transmit the availability information to the workload orchestrator 110 at predetermined time intervals (e.g., time intervals determined based on time interval indicators transmitted by the workload orchestrator 110 to the host 120(a)) (e.g., intervals of one millisecond, one second, one minute, one hours, one day, or any amount of time).
In some examples, the workload orchestrator 110 may determine the availability of the host 120(a) continuously or dynamically. In cases in which the availability information is transmitted by the host 120(a) continuously, or in other cases in which the availability information is not continuously transmitted, the host 120(a) may transmit information to the workload orchestrator 110 based on determining one or more of the first portion of the computing resources and the second portion of the observability resources of the host 120(a) are modified. The workload orchestrator 110 may determine (or “dynamically determine”) the availability of the host 120(a) based on the host 120(a) transmitting, in real-time, the availability information based on the first portion and/or the second portion being modified. By way of example, the availability information may be transmitted at a time at which modification of the first portion and/or the second portion occurs (e.g., the availability information may be transmitted within a threshold amount of time after the modification of the first portion and/or the second portion occurs). In some examples, the modification may include a modification of an amount of resources meeting or exceeding a threshold amount of resources (e.g. a percentage of resources being utilized exceeding a percentage (e.g., 10%, 20%, etc.) of resources of that type (e.g., computing or observability), and/or exceeding a percentage (e.g., 10%, 20%, etc.) of total resources of the host). The first portion of the computing resources being modified may include execution of any of one or more of the workloads (e.g., the workloads 206 and/or the workload 202) beginning, changing, and/or ending. The second portion of the observability resources being modified may include observability being added, or removed, from the host 120(a), and/or changes in observability associated with execution of one or more other workloads beginning, changing, and/or ending.
The workload orchestrator 110 may receive, from one or more other hosts (e.g., the hosts 120(b)-(d)), availability information, and/or determine availability information associated with one or more other hosts (e.g., the hosts 120(b)-(d)). The availability information associated with the hosts 120(b)-(d) may be received, and/or determined, by the workload orchestrator 110 in a similar way as for the host 120(a). In some examples, the workload orchestrator 110 may determine availability of individual ones of the hosts 120(a)-120(d) together (e.g., the determining of the availability of the host 120(a) may include determining the availability of the hosts 120(b)-120(d)). In other examples, the workload orchestrator 110 may determine the availability of the host 120(a), prior to determining the availability of any of the hosts 120(b)-120(d). In those examples, the workload orchestrator 110 may determine the availability of the host 120(a), and, based on the availability of the host 120(a) being determined to be negative, determine the availability of one or more of the remaining hosts 120 (e.g., the hosts 120(b)-120(d)).
The workload orchestrator 110 may determine, based on the availability associated with host 120(a) being negative, one or more other potential destination locations. The other potential destination locations may be determined based on the workload orchestrator 110 determining that no host among the hosts 120 is available for providing observability for all of the metrics 204. The other potential destination location(s) may include one or more remaining hosts 120 (e.g., the hosts 120(b)-120(d)). The workload orchestrator 110 may determine individual ones of the hosts 120(b)-120(d) as corresponding potential destination locations. Individual ones of the hosts 120(b)-120(d) may be determined as corresponding potential destination locations based on the corresponding availability information (e.g., the corresponding availability information associated with the corresponding hosts 120(b)-120(d) that is determined, and/or received, by the workload orchestrator 110).
The workload orchestrator 110 may modify, or refine, the other potential destination location(s) as including a portion of the remaining host(s) 120 (e.g., the hosts 120(b) and 120(c)), based on corresponding numbers of matching host observability types. In some examples, the workload orchestrator 110 may modify, or refine, the other potential destination location(s) as including the hosts 120(b) and 120(c), based on a number (e.g., two) of the matching host observability types associated with each of the hosts 120(b) and 120(c) meeting or exceeding a number of matching host observability types associated with the remaining host 120 (e.g., the host 120(c) provides one matching host observability types, including network observability).
Alternatively or additionally to utilizing corresponding numbers of matching host observability types to modify the other potential destination location(s) as including the portion of the remaining host(s) 120 (e.g., the hosts 120(b) and 120(c)), the workload orchestrator 110 may utilize metric priorities. The workload orchestrator 110 may determine an observability priority (e.g., an observability priority of the compute observability for the workload 202) associated with a metric priority value of the compute metric, an observability priority (e.g., an observability priority of the storage observability for the workload 202) associated with a metric priority value of the storage metric, and an observability priority (e.g., an observability priority of the network observability for the workload 202) associated with a metric priority value of the network metric. The next placement of the workload 202 may be determined based on the observability priorities associated with the corresponding metric priority values. The workload orchestrator 110 may modify the other potential destination location(s) as including the hosts 120(b) and 120(c) based on determining an observability priority of the network observability for the workload 202 is less than the observability priority of the compute observability and the storage observability, based on the metric priority value of the network metric being less than the metric priority value of the compute metric and the metric priority value of the storage metric. The workload orchestrator 110 may eliminate the host 120(d) as being one of the other potential destination location(s).
The workload orchestrator 110 may determine the next placement of the workload 202 based on the host 120(d) being eliminated. The workload orchestrator 110 may determine the next placement of the workload 202 utilizing the remaining hosts 120(b) and 120(c). In some instances, the workload orchestrator 110 may determine the observability priority of the storage observability for the workload 202 is greater than the observability priority of the compute observability, based on the metric priority value of the storage metric meeting or exceeding the metric priority value of the compute metric. The workload orchestrator 110 may determine the host 120(c) as the next placement of the workload 202, based on determining the observability priority of the storage observability for the workload 202 is greater than the observability priority of the compute observability.
At “7,” the host 120(c) may perform functions to execute a workload 202 based on workload placement utilizing requested metric(s) 204, in a similar way as for the host 120(a) that executes the workload 112 based on workload placement utilizing the requested metric(s) 116 at “6,” as discussed above with reference to
As illustrated, at “1,” the host 120(c) may perform functions to execute a workload 302 based on workload placement utilizing one or more requested metrics, in a similar way as for the host 120(a) that executes the workload 112 based on workload placement utilizing the requested metric(s) 116 at “6,” as discussed above with reference to
At “2,” the workload orchestrator 110 may determine a next placement associated with the workload 302. The determining of the next placement of the workload 302 may include monitoring execution of the workload 302 to determine monitoring information, determining a migrate status associated with the workload 302 based on the monitoring information, and determining the next placement associated with the workload 302 based on the migrate status.
The workload orchestrator 110 may determine to migrate the workload 302 based on various types of monitoring information. The monitoring information may be determined based on monitoring performed based on execution of the workload 302. The monitoring performed based on the execution of the workload 302 may include monitoring performance of the execution of the workload 302, and/or determining one or more monitoring metrics based on the monitoring of the performance. The initial monitoring metric(s) may be determined based on one or more requested metrics, which may be determined in a similar way as discussed above with reference to
The workload orchestrator 110 may determine and/or modify observability priorities associated with metric priority values (or “intuited metric priority values”). Individual ones of the observability priorities may be associated with corresponding intuited metric priority values associated with corresponding metric priorities. In some examples, the workload orchestrator 110 may determine one or more observability priorities in a similar way as for the determining of the observability priority(ies), as discussed above with reference to
Observability priorities may be determined based on various types of metric priority values. One or more observability priorities (or “modified observability priority(ies)”) may be determined based on the initial observability priority(ies). In some examples, the requested metric priority value(s) may be replaced by the intuited metric priority value(s) to replace the initial observability priority(ies) with the modified observability priority(ies). In other examples, the requested metric priority value(s) may be integrated with the intuited metric priority value(s) to determine combined observability priority(ies) as the modified observability priority(ies). Individual ones of the requested metric priority value(s) may be combined with corresponding intuited metric priority value(s) to determine the combined observability priority(ies). By way of example, individual ones of the combined deployment weight(s) may be a combination (e.g., an average) of the corresponding requested metric priority value(s) and the corresponding intuited metric priority value(s).
The monitoring information may include the intuited metric priority value(s) and/or any information associated with the performance of the execution of the workload 302. In some instances, the monitoring information may be utilized to determine whether to migrate the workload 302. For instance, the workload orchestrator 110 may determine a value of the migrate status associated with the workload 302 as positive, based on determining at least one observability priority associated with a corresponding type of observability that is not provided by the host 120(c) meets or exceeds observability priorities of the types of observability that are provided by the host 120(c). In some examples, the workload orchestrator 110 may determine the migrate status associated with the workload 302 as positive, further based on determining individual ones of the intuited metric priority values associated with corresponding type(s) of observability (e.g., the compute observability) that are not provided by the host 120(c) meet or exceed the intuited metric priority values that are associated with the corresponding types observability (e.g., the storage observability and the network observability) that are provided by the host 120(c).
The workload orchestrator 110 may determine the next placement for the workload 302 based on the migrate status, by refraining from comparing types of observability provided by potential destination locations that are the same as types of observability provided by a current host executing the workload 302. By way of example, the workload orchestrator 110 may refrain from comparing one or more types of observability (e.g., network observability) provided by potential destination locations (e.g., the hosts 120(b) and 120(d)) that are the same as one or more types of observability (e.g., network observability) provided by a current host (e.g., the host 120(c)) executing the workload 302. Because both of the hosts 120(b)-120(d) provide network observability, the workload orchestrator 110 may determine the next placement based on one or more types of observability (e.g., the compute observability) that are not provided by the host 120(c). The workload orchestrator 110 may determine the next placement based on the compute observability being associated with the intuited metric priority value that is greater than the intuited metric priority value associated with the storage observability.
At “3,” the workload orchestrator 110 may migrate the workload 302 based on the migrate status, in a similar way as for placing the workload 302. By way of example, the workload orchestrator 110 may migrate the workload 302 by placing the workload 302 on the host 120(b), based on determining availability of the host 120(b) is positive. The workload orchestrator 110 may place the workload 302 on the host 120(b) based on determining availability of the host 120(b) is positive, in a similar way as for placing the workload 302 on the host 120(a) at “5,” as discussed above with reference to
At “5,” the monitoring service 114 may perform similar functions utilizing a workload 202 and requested metric(s) 204, in a similar way as for the workload 112 and the requested metric(s) 116 at “7,” as discussed above with reference to
As illustrated, at “1” the user device 108 may perform similar functions utilizing a workload 402, in a similar way as for the workload 112 at “1,” as discussed above with reference to
At “3,” the user device 108 may transmit a request (or “user request”) indicating the workload 402 and the intent based description 404 to the workload orchestrator 110, via the network(s) 118. The user request may include any information (or “workload information”) associated with the workload 4012 in a similar way as for the workload 112, as discussed above with reference to
At “4,” the workload orchestrator 110 may receive the user request indicating the workload 402 and the intent based description 404. The workload orchestrator 110 may receive, in the user request, the workload information.
At “5”, the workload orchestrator 110 may determine a placement associated with the workload 402. To determine the placement, the workload orchestrator 110 may determine one or more metrics (or “intent based metric(s)”) based on the intent based description 404. By way of example, the computing resource(s), of which the intent based description 404 is indicative, may be utilized to determine (e.g., identify) the intent based metric(s), based on determining the intent based metric(s) that satisfy the intent based description 404. The workload orchestrator 110 may determine one or more potential destination locations for execution of the workload 402, based on the intent based metric(s). The potential destination location(s) may be utilized to determine the placement for the workload 402, in a similar way as for the placement for the workload 112 at “5,” as discussed above with reference to
Individual ones of the corresponding types (or “categories”) of observability may include one or more types (e.g., sub-types) (or “sub-categories”) observability. In some instances, the network observability may include a sub-type (e.g., first sub-type) of network observability and another sub-type (e.g., second sub-type) of network observability. For instance, the sub-type of network observability (or “first network observability”) may be provided by one or more hosts 120 (e.g., the host 120(a), the host 120(b), and the host 120(c)); and the other sub-type of network observability (or “second network observability”) may be provided by one or more other hosts 120 (e.g., the host 120(d)).
At “6,” the host 120(d) may execute the workload 402 in a similar way as the host 120(a) executing the workload 112 at “6,” as discussed above with reference to
At “8,” the user interface 124 may be utilized to output the monitoring metric(s) 406 in a similar way as the user interface 124 being utilized to output the monitoring metrics 122 at “8,” as discussed above with reference to
Although types of observability may be provided, along with sub-types of observability, by outputting types of monitoring metrics and/or sub-types types of monitoring metrics as discussed above with reference to
Although various techniques may be utilized as discussed with reference to
Generally, the workload orchestrator 110 may be a programmable controller that manages some or all of workload placement activities. Generally, the workload orchestrator 110 may handle at least the functions of (i) receiving user requests including metrics, metric priority values, and/or intent based descriptions, (ii) determining metrics based on intent based descriptions, and (iii) utilizing metrics of various types (e.g., requested metrics, orchestrator metrics, and/or intent based metrics), host availability, and/or numbers/priorities of observability types provided by computer resources (e.g., hosts) to determine workload placement.
As illustrated, the workload orchestrator 110 may include, or run on, one or more hardware processors 502 (processors), one or more devices, configured to execute one or more stored instructions. The processor(s) 502 may comprise one or more cores. Further, the workload orchestrator 110 may include or be associated with (e.g., communicatively coupled to) one or more network interfaces 504 configured to provide communications with the user devices 108 and other devices, and/or other systems or devices in the workload orchestrator 110 and/or remote from the workload orchestrator 110. The network interface(s) 504 may include devices configured to couple to personal area networks (PANs), wired and wireless local area networks (LANs), wired and wireless wide area networks (WANs), and so forth. For example, the network interface(s) 504 may include devices compatible with any networking protocol.
The workload orchestrator 110 may also include memory 506, such as computer-readable media, that stores various executable components (e.g., software-based components, firmware-based components, etc.). The memory 506 may generally store components to implement functionality described herein as being performed by the workload orchestrator 110. The memory 506 may store a monitoring requirements component 508 configured to manage monitoring requirements utilized for workload placement. The monitoring requirements component 508 may manage metrics of various types (e.g., requested metrics, orchestrator metrics, intent based metrics, etc.) that are utilized to determine destination locations for placement of workloads and observability types for providing observability based on workload execution.
Further, the memory 506 may store a workload placement component 510 configured to place workloads on computing resources (e.g., hosts). The workload placement component 510 may utilize potential destination locations to determine destination locations and place the workloads on the destination locations. The workload placement component 510 may place the workloads on the destination locations further based on the metrics of various types (e.g., requested metrics, orchestrator metrics, and/or intent based metrics), the host availability, and/or the numbers/priorities of observability types provided by computer resources (e.g., hosts).
Further, the memory 506 may store a metrics component 512 configured to manage metrics (e.g., metrics associated with execution of workloads) that are monitored. The metrics component 512 may receive the monitored metrics from the monitoring service 114 and utilize the monitored metrics as information for determining whether to migrate workloads. The metrics component 512 may manage the monitored metrics based on the monitored metrics being associated with corresponding workloads being executed.
Further, the memory 506 may store an observability tracking component 514 configured to track observability. The observability may be tracked for each of the hosts that are executing workloads. The observability tracking component 514 may determine any observability and/or change of observability associated with the hosts, which may be utilized to determine placement and/or migration of workloads.
The workload orchestrator 110 may further include a data store 516, such as long-term storage, that stores monitoring requirements data 518, such as data including metrics of various types (e.g., requested metrics, orchestrator metrics, intent based metrics, etc.). The data store 518 may store workload observability data 520 that indicates observability provided by hosts, including any changes in observability provided by the hosts. The data store 518 may store metrics data 522 that indicates metrics that are monitored based on execution of the workloads. The metrics data 522 may be utilized to determine whether the workloads are placed correctly or whether to migrate the workloads.
In some instances, the steps of method 600 may be performed by a device and/or a system of devices that includes one or more processors and one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations of method 600.
At 602, a workload orchestrator 110 may determine one or more computing resource metrics that are observable. The computing resource metric(s) may be associated with a workload. The computing resource metric(s) may include one or more compute metrics, one or more storage metrics, and/or one or more network metrics. The computing resource metric(s) may include requested metric(s) indicated by a user request received from a user device.
At 604, the workload orchestrator 110 may identify, as an identified host in a computing resource network, a host that is utilizable for observing the one or more computing resource metric. The host may be determined as the identified host and utilized to execute the workload, based on determining one or more types of observability associated with the host. The type(s) of observability may include multiple types of observability. The requested metric(s) may include multiple requested metrics. The workload orchestrator 110 may determine the number of the types of observability may match the number of the requested metrics. The workload orchestrator 110 may determine each of the types of observability matches a corresponding type of observability associated with a corresponding metric among the requested metrics. By way of examples, the workload orchestrator 110 may determine the types of observability include i) compute observability matching compute observability associated with a compute metric among the requested metrics, ii) storage observability matching storage observability associated with a storage metric among the requested metrics, and iii) network observability matching network observability associated with a network metric among the requested metrics.
At 606, the workload orchestrator 110 may cause the workload to execute on the identified host. The workload may be executed on the identified host, based on the workload orchestrator 110 determining availability of the identified host is positive.
While the invention is described with respect to the specific examples, it is to be understood that the scope of the invention is not limited to these specific examples. Since other modifications and changes varied to fit particular operating requirements and environments will be apparent to those skilled in the art, the invention is not considered limited to the example chosen for purposes of disclosure, and covers all changes and modifications which do not constitute departures from the true spirit and scope of this invention.
Although the application describes embodiments having specific structural features and/or methodological acts, it is to be understood that the claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are merely illustrative some embodiments that fall within the scope of the claims of the application.
