Policy controlled semi-autonomous infrastructure management

Embodiments of the present disclosure may relate to an apparatus for infrastructure management with an interface to receive a plurality of telemetry signals from first one or more infrastructure components of an infrastructure; and a policy controlled semi-autonomous (PCSA) infrastructure evaluator coupled with the interface, where the PCSA infrastructure evaluator includes a machine-learning (ML) model of service level metric (SLM) deviation by second one or more application or infrastructure components of the infrastructure and the PCSA infrastructure evaluator is to: determine a deviation from a SLM of third one or more infrastructure components based at least in part the ML model and one or more of the plurality of telemetry signals; and send a message, based at least in part on the deviation from the SLM. Other embodiments may be described and/or claimed.

FIELD

Embodiments of the present disclosure generally relate to the field of computer and network infrastructure management and, more particularly, to semi-autonomous control of network infrastructure resources.

BACKGROUND

Typically, legacy or cloud data centers, edge computing systems, and network function virtualization (NVF) infrastructure (NFVI) systems have capacity (e.g., processor cores, memory, network data throughput, data storage) allocated to various functions and/or clients before use in a static manner. This may result in inefficient utilization of hardware resources.

DETAILED DESCRIPTION

Embodiments of the present disclosure may relate to an apparatus for infrastructure orchestration (including network infrastructure) management with a network interface to receive a plurality of telemetry signals from first one or more infrastructure components of an infrastructure and a policy controlled semi-autonomous (PCSA) infrastructure evaluator coupled with the network interface, where the PCSA infrastructure evaluator includes a machine-learning (ML) algorithm, a plurality of ML algorithms, and/or one or more ML models. In some embodiments, one or more of the ML algorithms and/or ML models may model the infrastructure utilized and/or one or more “services” that may include a desired service level agreement (SLA) or service level objective (SLO). In some embodiments, the term service level metric (SLM) may be used to refer to a SLA, a SLO, and/or one or more SLA parameters or SLO parameters. In some embodiments, the one or more “services” (e.g., SLA and/or SLO) may be inserted by a user or administrator, or may be inserted automatically by an application representing a set of “services”, applications, virtual network functions (VNFs), containers, micro-services, functions, and/or any other suitable service that may be executed on the infrastructure monitored by the PCSA infrastructure evaluator. In some embodiments, a container may include but not be limited to an isolated user-space instance (e.g., as provided by a kernel in operating-system-level virtualization). In some embodiments, the “services” may also include a desired resource allocation. In various embodiments, the infrastructure telemetry may be “compacted” to include only those signals holding information pertinent to a potential SLA deviation by second one or more components of the infrastructure. In some embodiments, the PCSA algorithms may derive an indication of existing or imminent SLA deviation from the compacted telemetry, one or more infrastructure and service models (optional), and the desired SLA. In some embodiments, the PCSA infrastructure evaluator may be to determine a deviation from a SLA of third one or more infrastructure components based at least in part the ML model, one or more of the plurality of telemetry signals, and one or more SLA parameters; and send a message to a predefined entity. In some embodiments, the predefined entity may be selected from a group that includes an orchestrator, a cloud computing fabric controller, a network functions virtualization (NFV) orchestrator (NFVO), a virtualized infrastructure manager (VIM), an operations support system (OSS), a business support system (BSS), or an application (e.g., an Element Management System (EMS), a VNF Manager (VNFM), or some other management application), based at least in part on an actual or imminent deviation from the SLA or SLO. In some embodiments, the message may include a recommended action; the telemetry signals may include one or more of processor telemetry signals, operating system telemetry signals, virtual switch telemetry signals, storage subsystem telemetry signals, host bus adapter (HBA)/network interface card (NIC) telemetry, platform telemetry (e.g., temperature, fan state, baseboard management controller (BMC) state), physical switch or router telemetry, and/or any other suitable telemetry signals; the resource requirements may include one or more requirements or commitments of a number of processor cores, a cache capacity, a memory capacity, a memory bandwidth, a network data communication throughput capacity, or a storage capacity of the third one or more network components of the network infrastructure; and/or the SLA/SLO requirements may include transactions per second, input/output (IO) operations per second, network packets per second, network bandwidth, remote procedure calls (RPCs) per second, and/or any other suitable requirements. In some embodiments, one or more of the SLA/SLO requirements may be set or determined as a function of an allocated resource set. In some embodiments, telemetry may include but not be limited to any communication indicating a parameter about a component of the infrastructure.

FIG. 1depicts a block diagram of an apparatus100that includes a policy controlled semi-autonomous (PCSA) infrastructure evaluator102, in accordance with various embodiments. In some embodiments, the PCSA infrastructure evaluator102may receive telemetry signals from a telemetry collector104. Although the telemetry collector104is shown as being separate from the PCSA infrastructure evaluator102, the telemetry collector104may be a part of the PCSA infrastructure evaluator in some embodiments. In some embodiments, the telemetry collector104may be or include a network interface. In various embodiments, the telemetry collector104may collect telemetry signals from one or more infrastructure components. In some embodiments, the telemetry collector104may collect telemetry signals from a group of servers106and/or other network components such as a switch108. In various embodiments, the telemetry signals may include one or more of processor telemetry signals, operating system telemetry signals, virtual switch telemetry signals, storage subsystem telemetry signals, host bus adapter telemetry signals, network interface card telemetry signals, platform telemetry signals, physical switch telemetry signals, router telemetry signals, or any other suitable type of telemetry signals. In some embodiments, the telemetry signals may include one or more of a packet loss metric or a collision metric that provides a count, a count per unit time, any other suitable measurement of cache resources collisions, central processing unit (CPU) resource utilization, memory utilization, and/or a counter relating to any other suitable metric. Although the PCSA infrastructure evaluator102is shown to be separate from other elements of the apparatus100, in some embodiments, the PCSA infrastructure evaluator102may co-reside with one or more of the other components of the apparatus100and/or network coupling between the PCSA infrastructure evaluator102and one or more other components may be virtual or based on an application programming interface (API).

In some embodiments, the group of servers106may include a first server110, a second server112, and a third server114. In some embodiments, a virtual machine monitor (VMM)116, a container118(e.g., a Docker container), and/or a virtual machine (VM) firewall120may run on the first server110. In some embodiments, a VMM122may run on the second server112. In various embodiments, one or more VMs, such as a first VM124may run on the VMM122. In some embodiments, a load balancer VM126may run on the VMM122and/or the second server112. In some embodiments, a VMM128may run on the third server114. In various embodiments, one or more VMs, such as a second VM130and a third VM132may run on the VMM128. In some embodiments, one or more of the VMM116, the VMM122, and/or the VMM128may be a hypervisor. Although a single container118is shown for clarity, it should be understood that multiple containers may be included in various embodiments and/or that any suitable combination of containers and/or VMs may be used.

In some embodiments, one or more components running on one or more of the servers in the group of servers106may be communicatively coupled with and/or may provide services to components running on one or more of the other servers. In some embodiments, the VM firewall120may act as a firewall for components running on the first server110, as shown with respect to the container118, but may also act as a firewall for components running on the second server112and/or the third server114such as for the first VM124, the second VM130, and/or the third VM132via the load balancer VM126. In various embodiments, one or more of the servers in the group of servers106may include an environment abstraction layer (EAL) (e.g., with a first data plane development kit (DPDK)134on the second server112and/or a second DPDK136on the third server114). In some embodiments, the EAL may provide a generic interface to low-level resources such as hardware and memory space, and may hide the environment specifics from applications and libraries. In some embodiments, the EAL may provide one or more services that may include DPDK loading and launching, support for multi-process and multi-thread execution types, core affinity/assignment procedures, system memory allocation/de-allocation, atomic/lock operations, time reference, peripheral component interconnect (PCI) bus access, trace and debug functions, CPU feature identification, interrupt handling, and/or alarm operations. In some embodiments, the PCSA infrastructure evaluator102may receive one or more policy parameters (e.g., SLA, SLO, and/or resource requirements) from a policy manager142directly or via an orchestrator140. In some embodiments, one or more of the one or more policy parameters may correspond to a higher-level policy (e.g., a network level policy or a datacenter level policy) that may relate to infrastructure used to implement more than one SLA. In some embodiments, the PCSA infrastructure evaluator102may receive one or more parameters or models pertinent to the infrastructure used, directly from the infrastructure (e.g. reading BMC or inventory database), from the orchestrator140, and/or from the administrator. In some embodiments, one or more of the one or more policy parameters may correspond to a policy that defines scale up, scale down, and/or a self-healing policy. Such a policy may also include a maximum number of servers that may be consumed in order to create a new virtual machine or container, a maximum percentage of a total number of servers that may create a new virtual machine or container, a maximum rate of instantiation of virtual machine or container instances, or any other suitable higher-level policy. Correspondingly, a scale down policy may include a minimal infrastructure set to host a “service” or application. That policy may reside within the PCSA infrastructure evaluator102or with the orchestrator140, for example, and may be accessible to the orchestrator140and/or the PCSA infrastructure evaluator102in some embodiments. In some embodiments, one or more of the one or more policy parameters may correspond to one or more permission policies that may establish whether permission is required before the PCSA infrastructure evaluator102and/or the orchestrator140may take a particular action (e.g., sending a message from the PCSA infrastructure evaluator102to the orchestrator140directing a change in resources; or directing, by the orchestrator140, one or more components of the infrastructure to take an action). In various embodiments, the higher-level policy may include, but not be limited to, a manner in which one or more components of the infrastructure (e.g., one or more servers or features thereof in the group of servers106) are to be operated. In some embodiments, the higher-level policy may include, but not be limited to, a manner in which disaggregated resources (e.g., compute, storage, memory, network, and any other suitable resources) are to be operated. In various embodiments, the higher-level policy may include, but not be limited to, a manner in which one or more components of the infrastructure are to be operated in relation to an application and/or a SLM.

In various embodiments, the orchestrator140may be in data communication with the group of servers106, the policy manager142, and the PCSA infrastructure evaluator102. In some embodiments, a management application144may be in data communication with the policy manager142over a network146, that may be a cloud computing network. In some embodiments, cloud computing may refer, but not be limited, to an information technology paradigm, a model for enabling ubiquitous access to shared pools of configurable resources (such as computer networks, servers, storage, applications and services), which can be rapidly provisioned with minimal management effort, often over the Internet. Although a single management application144is shown for clarity, it should be understood that multiple management applications may be included in various embodiments. In various embodiments, the PCSA infrastructure evaluator102may be in data communication with the management application144. In some embodiments, the capabilities (e.g., storage, processing, memory) of one or more servers in the group of servers106may be communicated to the orchestrator140and/or the policy manager142(e.g., by using enhanced platform awareness (EPA) parameters as exemplified in OpenStack open source or by following an Information Model (IM) or Data Model (DM), as prescribed by the European Telecommunications Standards Institute (ETSI) and/or the Organization for the Advancement of Structured Information Standards (OASIS) Topology and Orchestration Specification for Cloud Applications (TOSCA)). In some embodiments, the orchestrator140may be a network functions virtualization (NFV) orchestrator (NFVO).

In some embodiments, the PCSA infrastructure evaluator102may include one or more ML algorithms and/or one or more ML models150. In some embodiments, the ML model150may be a model of SLA deviation for some VM or Container or micro service or Function-as-a-Service (FaaS) or of a more complex set of components corresponding to a Network Service (NS) or other “service” or larger application comprised of a set of such components executed by one or more infrastructure components (e.g., components of the group of servers106and/or the switch108.) In various embodiments, the ML model150may include weighting parameters that may be for an artificial neural network (ANN) or any other suitable type of ML model. In some embodiments, the ML model150may be trained during a training phase to identify telemetry signals and/or other data to be included in the ML model150and/or weights to be associated with the telemetry signals and/or other data. In various embodiments, the ML model150may be a binary classification model, a multiclass classification model, a regression model, or any other suitable type of ML model. In some embodiments, the PCSA infrastructure evaluator102and/or one or more other infrastructure elements (e.g., server110,112,114or other infrastructure components such as a physical switch and/or one or more storage nodes), may include a filter, not shown for clarity, to filter the plurality of telemetry signals received from the telemetry collector104based at least in part on the ML model150to determine a subset of the telemetry signals that may be used in one or more further determinations or actions by the PCSA infrastructure evaluator102. In some embodiments, only those telemetry signals that contribute to an ability of the PCSA infrastructure evaluator102to determine the SLA/SLO deviation may be generated by the infrastructure components, thereby reducing the load on those elements as well as on the infrastructure used to convey these signals to the telemetry collector104and/or the PCSA infrastructure evaluator102itself. In some embodiments, an ML algorithm in the PCSA infrastructure evaluator102, based on the training phase or from other sources, pertinent to the infrastructure used and/or SLA/SLO and/or applications or services run, may be used to determine the set of telemetry signals to be created and/or collected. In some embodiments, a minimal set of telemetry signals required for determining SLA/SLO deviation may be used and/or created.

Although the PCSA infrastructure evaluator102may be described with respect to an SLA or an SLO, it should be understood that the PCSA infrastructure evaluator102may perform actions based at least in part on and/or with respect to any suitable type of SLM in various embodiments, such that discussion of an SLA and/or deviation from an SLA should also be understood to apply to an SLO or deviation from an SLO in some embodiments. In various embodiments, the PCSA infrastructure evaluator102may determine a deviation from a service level agreement (SLA) based at least in part on the ML model150, one or more of the plurality of telemetry signals received from one or more infrastructure components and/or network components, and one or more SLA, SLO, and/or policy parameters. In some embodiments, the SLA may include one or more performance, responsiveness, utilization efficiency, security or other metrics of the SLA or SLO requested (e.g., as listed above). In some embodiments, the PCSA infrastructure evaluator102may also use a suitable algorithm (ML or not) to modify the infrastructure resources requested or committed (e.g., of one or more of a number of processor cores, a cache capacity, a memory capacity, a memory bandwidth, a network data communication throughput capacity, a storage capacity of one or more servers of server group106, or any other suitable metric). In various embodiments, the PCSA infrastructure evaluator102may modify the infrastructure resources directly or indirectly (e.g., by issuing an indication or sending a message to the orchestrator140) to modify one or more resources allocated to an application element in order to scale up, scale down, or migrate for preserving the desired SLA or SLO or deviating from it based on a given policy. In some embodiments, the PCSA infrastructure evaluator102algorithm may take into account a corresponding level of scale up or scale down of any given application component to achieve a new desired SLA or SLO level due to user or administrator input, or due to a change in the overall application (e.g., NS) load (e.g., number of requests, number of packets, number of RPC, and/or any other suitable metric). In some embodiments, the PCSA infrastructure evaluator102may receive one or more SLA parameters from the policy manager142via the orchestrator140that may correspond to the requirements and/or commitments of the SLA. In other embodiments, the policy manager142may directly interact with the PCSA infrastructure evaluator102. In various embodiments, the PCSA infrastructure evaluator102may receive SLA parameters that may correspond to the requirements and/or commitments of more than one SLA, and in such embodiments, the PCSA infrastructure evaluator102may receive a plurality of SLA identification parameters, where each SLA identification parameter may be associated with a subset of the received SLA parameters (e.g., a first SLA identification parameter may be associated with a first subset of performance parameters, responsiveness parameters, utilization efficiency parameters, security parameters, and/or any other suitable metric of the SLA or SLO requested (as listed above), and a second SLA identification parameter may be associated with a second subset of performance parameters, responsiveness parameters, utilization efficiency parameters, security parameters, and/or any other suitable metric of the SLA or SLO requested (as listed above)).

In some embodiments, the PCSA infrastructure evaluator102may determine the deviation from the SLA based at least in part on the filtered subset of the telemetry signals (e.g., telemetry compaction). In some embodiments, the PCSA infrastructure evaluator102may determine the deviation from the SLA based at least in part on one or more of the one or more SLA parameters and/or may recommend action directly to the infrastructure or to the orchestrator140based at least in part on one or more of the one or more policy parameters. In some embodiments, input parameters to the ML model150may include one or more telemetry signals, one or more SLA parameters, and/or one or more policy parameters.

In various embodiments, the ML model150may generate one or more outputs based at least in part on the input parameters. In some embodiments, the one or more outputs of the ML model150may include one or more SLA deviation outputs. In various embodiments, the one or more SLA deviation outputs may include one or more deviation indicators and/or deviation probabilities. In some embodiments, the SLA deviation outputs may include one or more time values (e.g., 75% probability of deviating from a storage requirement in 10 seconds.) In some embodiments, the one or more deviation indicators and/or deviation probabilities may be associated with one or more of the one or more SLA parameters (e.g., 85% probability of deviating from a network bandwidth requirement of a first SLA). In various embodiments, the PCSA infrastructure evaluator102may determine deviation from the SLA in an application agnostic manner, where the PCSA infrastructure evaluator102may not know or take into account any of the particular applications or VNFs being run on the infrastructure under one or more SLAs. In some embodiments, deviation may include, but not be limited to, one or more components of the infrastructure exceeding a fixed resource limit.

In some embodiments, the PCSA infrastructure evaluator102may determine deviation from one or more SLAs in an application aware manner, where the PCSA infrastructure evaluator102may determine the deviation from an SLA based at least in part on one or more application parameters and/or application models (e.g., including some description of inter-component dependency and/or inter-performance relationships) or VNF parameters (e.g., an application type identifier and/or one or more telemetry signals from an application or VNF.) In some embodiments, the input parameters to the ML model150may include one or more of the application or VNF parameters. In some embodiments, the PCSA infrastructure evaluator102may determine the deviation from the SLA based at least in part on parameters from more than one application and/or VNF.

In some embodiments, the PCSA infrastructure evaluator102may send a message to one or more of the orchestrator140, a cloud computing fabric controller, not shown for clarity, a virtualized infrastructure manager (VIM), not shown for clarity, an operations support system (OSS), not shown for clarity, a business support system (BSS), not shown for clarity, the management application144, or any other suitable network component, based at least in part on the deviation from the SLA. In some embodiments, the message may include a recommended action (e.g., creation of a new VM or container instance or migration of an existing VM or container instance). In some embodiments, the recommended action may specify the type of identity of a VM to be created, scaled up, or scaled down and by how much. In various embodiments, this may be useful when an application is to scale by a certain amount and the PCSA infrastructure evaluator102, aided or unaided, may determine which component of the application needs to scale and by how much to achieve the overall application desired SLA under a given policy. In some embodiments, the PCSA infrastructure evaluator102may determine the recommended action based at least in part on one or more outputs of the ML model150. In some embodiments, the ML model150outputs may include one or more parameters that may correspond to one or more recommended actions (e.g., instantiate a new VM for a first SLA). In some embodiments, the deviation may be a predicted future deviation at a first time and the PCSA infrastructure evaluator102may be to send the message at a second time before the first time. In some embodiments, the message may include a statistics update for one or more of the one or more infrastructure or network components. In various embodiments, the PCSA infrastructure evaluator102may be to determine whether permission is required for the recommended action based at least in part on one or more of the one or more policy parameters (e.g., a policy parameter indicating that no more than a predefined percentage of servers may instantiate new VM or container instances), and the message may include a permission required indicator in response to a determination permission is required. In some embodiments, this may prevent too large a portion of the infrastructure from reacting to desired or spurious changes and engulfing the whole infrastructure in an uncontrolled action (either spinning up or down too many elements at once).

In some embodiments, the orchestrator140or some other component of the apparatus100(e.g., the management application144) may direct one or more components operating on the group of servers106to take an action (e.g., create a new VM or container instance or migrate an existing VM or container instance) based at least in part on the message from the PCSA infrastructure evaluator102. In various embodiments, this may be performed in a semi-autonomous manner, where the orchestrator140may direct one or more infrastructure components to take an action without further approval (e.g., from the user, administrator, a policy manager, a higher level of resource allocation, or an orchestration or service orchestration entity) in response to such a message from the PCSA infrastructure evaluator102. As discussed above, in some embodiments, further approval may be required in some situations (e.g., where the permission required indicator indicates permission is required) before the orchestrator140may direct one or more infrastructure components to take an action. In some embodiments, the PCSA infrastructure evaluator102may take some actions without further approval and other actions after further approval (e.g., from the user, administrator, a policy manager, a higher level of resource allocation, or an orchestration or service orchestration entity), based at least in part on one or more permission policies, such that the PCSA infrastructure evaluator102may operate in a semi-autonomous manner. In various embodiments, the PCSA infrastructure evaluator102or the orchestrator140may notify the user, administrator, a policy manager, a higher level of resource allocation, or an orchestration or service orchestration entity of the action recommended and/or executed without an explicit permission from any of those higher layers (e.g., the policy manager142, the management application144, or a human operator). In various embodiments, the orchestrator140may manage one or more infrastructure components of the group of servers106and/or other infrastructure components of the apparatus100based at least in part on the PCSA infrastructure evaluator102generated messages.

FIG. 2depicts a block diagram of a system200that includes a PCSA infrastructure evaluator202that may be associated with a network functions virtualization infrastructure (NFVI)204, in accordance with various embodiments. In some embodiments, the NFVI204may include hardware resources (e.g, compute, storage, and/or network resources) and a virtualization layer and/or Containers and/or FaaS or other types of compute applications. In some embodiments, one or more network services206may run on the NFVI204and/or be in communication with the NFVI204. In some embodiments, the virtualization layer of the NVFI204may present virtual compute, virtual storage, and/or virtual network resources to the network services206such that they may run on the hardware resources of the NFVI204indirectly through the virtualization layer. In some embodiments, the network services206may include a first virtual network function (VNF)208, a second VNF210, and a third VNF212. In some embodiments, one or more of the network services206may be evolved packet core services or other wireless telecommunications services. In some embodiments, the network services206may include a PGW, a SGW, a HSS, and/or a mobility manager. In some embodiments, the network services206may include one or more software defined networking (SDN) services. In various embodiments, the PCSA infrastructure evaluator202may include a ML model214, a resource analyzer216, and/or a network service analyzer218. In some embodiments, the ML model214may be a binary classification model, a multiclass classification model, a regression model, or any other suitable type of ML model. In various embodiments, the ML model214may include some or all of the functionality described with respect to the ML model150ofFIG. 1and/or may be configured in a similar manner to the ML model150.

In some embodiments, the resource analyzer216may receive a first set of one or more telemetry signals from the NFVI204and the network service analyzer may receive a second set of one or more telemetry signals from the network services206(e.g., from VNF208, VNF210, and/or VNF212). In various embodiments, the resource analyzer216may analyze the first set of one or more telemetry signals based at least in part on the ML model214and/or the network service analyzer218may analyze the second set of one or more telemetry signals based at least in part on the ML model214. In various embodiments, the ML model214may use a combination of network service signals and/or application awareness coupled with infrastructure based indication from the NFVI204as processed by the resource analyzer216to provide better insight, finer granularity, and/or a more refined indication or recommendation as to the action taken based on the combination of the network service analyzer218and resource analyzer216analysis. In various embodiments, the ML model214may include weighting parameters associated with an ANN or any other suitable type of ML model. In some embodiments, the ML model214may be trained during a training phase, and may incorporate weighting factors associated with one or more interactions between different network services (e.g., between the first VNF208and one or more of the second VNF210or the third VNF212).

In some embodiments, the PCSA infrastructure evaluator202may determine one or more actions based at least in part on a policy input (e.g., from a policy manager such as policy manager142), and one or more determinations from the resource analyzer216and/or the network service analyzer218. In some embodiments, the PCSA infrastructure evaluator202may determine a deviation from a SLA based at least in part on the ML model214, one or more SLA parameters, and one or more telemetry signals received from the network services206and/or the NFVI204. In some embodiments, the PCSA infrastructure evaluator202may send a message to an orchestrator220based at least in part on the determined one or more actions and/or the determined deviation. In some embodiments, the orchestrator220may direct one or more components operating on the NFVI204to take an action (e.g., create a new VM or container instance or migrate an existing VM or container instance) based at least in part on the message. In some embodiments, the PCSA infrastructure evaluator202may take one or more additional or alternative actions similar to those described with respect to the PCSA infrastructure evaluator102ofFIG. 1, and/or the orchestrator220may take one or more additional or alternative actions similar to those described with respect to the orchestrator140ofFIG. 1.

In various embodiments, the ML model150ofFIG. 1and/or the ML model214ofFIG. 2may be statically configured after they have been trained, but may still allow for detection of telemetry signal patterns with respect to the PCSA infrastructure evaluator102and/or the PCSA infrastructure evaluator202that may correspond to a deviation from a SLA. In other embodiments, the ML model150and/or the ML model214may be dynamically configured and/or may continue to be updated by processes internal to the PCSA infrastructure evaluator102and/or the PCSA infrastructure evaluator202(e.g., other components of a ML model) or external to the PCSA infrastructure evaluator (e.g., by policy manager142).

In various embodiments, a number of exemplary patterns (e.g., known good and/or known bad patterns) may be set by default in the ML model150and/or the ML model214. In some embodiments, the exemplary patterns may allow the PCSA infrastructure evaluator102and/or the PCSA infrastructure evaluator202to react in advance of potential deviations from an SLA based on past learning. In some embodiments, processing by the ML model150and/or the ML model214may be performed with one or more observed parameters that may include continuous tracking of telemetry signals that may be event generated and/or correlation of telemetry signals accumulated in a predefined time period. In some embodiments, the PCSA infrastructure evaluator102and/or the PCSA infrastructure evaluator202may weight telemetry signals per predefined time interval, may detect possible deviations based on signature recognition of received telemetry signal patterns, and/or may include any other suitable working mode.

FIG. 3is a flow diagram of a technique300of infrastructure control with a policy controlled semi-autonomous infrastructure evaluator (e.g., PCSA102or PCSA202), in accordance with various embodiments. In some embodiments, some or all of the technique300may be practiced by components shown and/or described with respect to the apparatus100ofFIG. 1, the system200ofFIG. 2, the computing device400ofFIG. 4, or some other component described with respect toFIGS. 1-2and/orFIGS. 4-5.

In various embodiments, at a block302, the technique300may include receiving a plurality of telemetry signals from one or more infrastructure components at a PCSA infrastructure evaluator (e.g., PCSA infrastructure evaluator102or202). In some embodiments, the technique300may include filtering the telemetry signals (e.g., by the PCSA infrastructure evaluator, by the telemetry collector104, at the source on the infrastructure element, or by using another algorithm (e.g. ML algorithm) to determine a priori the telemetry signals appropriate for the action/decision or SLA/SLO deviation and generating just those signals at the infrastructure source) to determine a subset of the telemetry signals that may be used in one or more further determinations or actions.

In some embodiments, at a block304, the technique300may include receiving one or more SLA parameters at the PCSA infrastructure evaluator (e.g., from policy manager142, from the orchestrator140, directly from a user/administrator, or through some other programmatic interface). In some embodiments, at a block306, the technique300may include receiving one or more policy parameters at the PCSA infrastructure evaluator (e.g., from policy manager142, from the orchestrator140, directly from a user/administrator, or through some other programmatic interface). In various embodiments, at a block308, the technique300may include determining a recommended action based at least in part on a machine learning model or algorithm (e.g., ML model150or214), one or more of the plurality of telemetry signals, and one or more of the one or more SLA parameters. In some embodiments, at a block310, the technique300may include determining whether permission is required for the recommended action based at least in part on one or more of the one or more policy parameters. In various embodiments, at a block312, the technique300may include sending a message to one or more of an orchestrator, a cloud computing fabric controller, a network functions virtualization orchestrator, a virtualized infrastructure manager, an operations support system, a business support system, or a management application, where the message includes the recommended action. In some embodiments, at a block314, the technique300may include performing other actions. Although much of the technique300is described with respect to an SLA and SLA parameters, it should be understood that the technique300may also apply to an SLO or any other SLM, including SLO parameters and deviation from an SLO in some embodiments.

FIG. 4illustrates a block diagram of an example computing device400suitable for use with various components ofFIGS. 1-2, and/or the technique300ofFIG. 3, in accordance with various embodiments. For example, the computing device400may be, or may include or otherwise be coupled to, apparatus100, PCSA infrastructure evaluator102, ML model150, PCSA infrastructure evaluator202, ML model214, resource analyzer216, and/or network service analyzer218. As shown, computing device400may include one or more processors or processor cores402and system memory404. For the purpose of this application, including the claims, the terms “processor” and “processor cores” may be considered synonymous, unless the context clearly requires otherwise. The processor402may include any type of processors, such as a central processing unit (CPU), a microprocessor, and the like. The processor402may be implemented as an integrated circuit having multi-cores, e.g., a multi-core microprocessor. In some embodiments, processors402, in addition to cores, may further include hardware accelerators, e.g., hardware accelerators implemented with Field Programmable Gate Arrays (FPGA). The computing device400may include mass storage devices406(such as diskette, hard drive, non-volatile memory (NVM) (e.g., compact disc read-only memory (CD-ROM), digital versatile disk (DVD), any other type of suitable NVM, and so forth). In general, system memory404and/or mass storage devices406may be temporal and/or persistent storage of any type, including, but not limited to, volatile and non-volatile memory, optical, magnetic, and/or solid state mass storage, and so forth. Volatile memory may include, but is not limited to, static and/or dynamic random access memory (DRAM). Non-volatile memory may include, but is not limited to, electrically erasable programmable read-only memory, phase change memory, resistive memory, and so forth.

The computing device400may further include I/O devices408(such as a display (e.g., a touchscreen display), keyboard, cursor control, remote control, gaming controller, image capture device, and so forth) and communication interfaces410(such as network interface cards, modems, infrared receivers, radio receivers (e.g., Bluetooth), and so forth).

The communication interfaces410may include communication chips (not shown) that may be configured to operate the device400in accordance with a local area network (LAN) (e.g., Ethernet) and/or a Global System for Mobile Communication (GSM), General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA), Evolved HSPA (E-HSPA), or Long-Term Evolution (LTE) network. The communication chips may also be configured to operate in accordance with Enhanced Data for GSM Evolution (EDGE), GSM EDGE Radio Access Network (GERAN), Universal Terrestrial Radio Access Network (UTRAN), or Evolved UTRAN (E-UTRAN). The communication chips may be configured to operate in accordance with Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Digital Enhanced Cordless Telecommunications (DECT), Evolution-Data Optimized (EV-DO), derivatives thereof, as well as any other wireless protocols that are designated as 3G, 4G, 5G, and beyond. The communication interfaces410may operate in accordance with other wireless protocols in other embodiments. In various embodiments, computing device may include a ML model452that may be configured in similar fashion to the ML model150described with respect toFIG. 1or the ML model214described with respect toFIG. 2. In some embodiments, the ML model452may be coupled with other components of the computer device400.

The above-described computing device400elements may be coupled to each other via system bus412, which may represent one or more buses. In the case of multiple buses, they may be bridged by one or more bus bridges (not shown). Each of these elements may perform its conventional functions known in the art. In particular, system memory404and mass storage devices406may be employed to store a working copy and a permanent copy of the programming instructions for the operation of various components of computing device400, including but not limited to an operating system of computing device400, one or more applications, and/or operation associated with computing device400serving as PCSA infrastructure evaluator102, ML model150, PCSA infrastructure evaluator202, ML model214, resource analyzer216, and/or network service analyzer218, collectively denoted as computational logic422. The various elements may be implemented by assembler instructions supported by processor(s)402or high-level languages that may be compiled into such instructions. In some embodiments, the computing device400may be implemented as a fixed function ASIC, a FPGA, or any other suitable device with or without programmability or configuration options.

The permanent copy of the programming instructions may be placed into mass storage devices406in the factory, or in the field through, for example, a distribution medium (not shown), such as a compact disc (CD), or through communication interface410(from a distribution server (not shown)). That is, one or more distribution media having an implementation of the agent program may be employed to distribute the agent and to program various computing devices.

The number, capability, and/or capacity of the elements408,410,412may vary, depending on whether computing device400is used as a stationary computing device, such as a set-top box or desktop computer, or a mobile computing device, such as a tablet computing device, laptop computer, game console, or smartphone. Their constitutions are otherwise known, and accordingly will not be further described.

In some embodiments, ML model452may be included with computational logic422or hardware accelerators of processor402. For some embodiments, at least one of processors402may be packaged together with computational logic422configured to practice aspects of embodiments described herein to form a System in Package (SiP) or a System on Chip (SoC).

In various implementations, the computing device400may comprise one or more components of a data center, a laptop, a netbook, a notebook, an ultrabook, a smartphone, a tablet, an ultra mobile PC, or a mobile phone. In some embodiments, the computing device400include one or more components of a server. In further implementations, the computing device400may be any other electronic device that processes data.

FIG. 5illustrates example computer-readable storage medium502having instructions configured to practice all or selected ones of the operations associated with the computer device400, earlier described with respect toFIG. 4; the apparatus100and/or the PCSA infrastructure evaluator102described with respect toFIG. 1; the PCSA infrastructure evaluator202described with respect toFIG. 2; and/or the technique300ofFIG. 3, in accordance with various embodiments. As illustrated, computer-readable storage medium502may include a number of programming instructions504. The storage medium502may represent a broad range of non-transitory persistent storage medium known in the art, including but not limited to flash memory, dynamic random access memory, static random access memory, an optical disk, a magnetic disk, etc. Programming instructions504may be configured to enable a device, e.g., computer device400, PCSA infrastructure evaluator102and/or other components of the apparatus100, and/or PCSA infrastructure evaluator202in response to execution of the programming instructions504, to perform, e.g., but not limited to, various operations described for the ML model150, the ML model214, the resource analyzer216, the network service analyzer218, the computer device400ofFIG. 4, or operations shown and/or described with respect to technique300ofFIG. 3. In alternate embodiments, programming instructions504may be disposed on multiple computer-readable storage media502. In an alternate embodiment, storage medium502may be transitory, e.g., signals encoded with programming instructions504.

Referring back toFIG. 4, for an embodiment, at least one of processors402may be packaged together with memory having all or portions of computational logic422configured to practice aspects shown or described for the PCSA infrastructure evaluator102and/or other components of the apparatus100shown inFIG. 1, PCSA infrastructure evaluator202ofFIG. 2, or operations shown or described with respect to technique300ofFIG. 3. For an embodiment, at least one of processors402may be packaged together with memory having all or portions of computational logic422configured to practice aspects described for the PCSA infrastructure evaluator102and/or other components of the apparatus100shown inFIG. 1, PCSA infrastructure evaluator202ofFIG. 2, or operations shown or described with respect to technique300ofFIG. 3to form a System in Package (SiP). For an embodiment, at least one of processors402may be integrated on the same die with memory having all or portions of computational logic422configured to practice aspects described for the PCSA infrastructure evaluator102and/or other components of the apparatus100shown inFIG. 1, PCSA202ofFIG. 2, or operations shown or described with respect to technique300ofFIG. 3. For an embodiment, at least one of processors402may be packaged together with memory having all or portions of computational logic422configured to practice aspects of the PCSA infrastructure evaluator102and/or other components of the apparatus100shown inFIG. 1, PCSA202ofFIG. 2, or operations shown or described with respect to technique300ofFIG. 3to form a System on Chip (SoC).

Machine-readable media (including non-transitory machine-readable media, such as machine-readable storage media), methods, systems and devices for performing the above-described techniques are illustrative examples of embodiments disclosed herein. Additionally, other devices in the above-described interactions may be configured to perform various disclosed techniques.

EXAMPLES

Example 1 may include an apparatus for infrastructure management, comprising: an interface to receive a plurality of telemetry signals from first one or more infrastructure components of an infrastructure; and a policy controlled semi-autonomous (PCSA) infrastructure evaluator coupled with the interface, wherein the PCSA infrastructure evaluator includes a machine-learning (ML) model of a service level metric (SLM) deviation by second one or more infrastructure components of the infrastructure, and the PCSA infrastructure evaluator is to: determine a deviation from the SLM of third one or more infrastructure components of the infrastructure, based at least in part the ML model and one or more of the plurality of telemetry signals; and send a message to fourth one or more infrastructure components of the infrastructure based at least in part on the deviation from the SLM.

Example 2 may include the subject matter of Example 1, wherein the fourth one or more infrastructure components of the infrastructure are selected from a group that includes an orchestrator, a cloud computing fabric controller, a network functions virtualization (NFV) orchestrator (NFVO), a virtualized infrastructure manager (VIM), an operations support system (OSS), a business support system (BSS), or a management application.

Example 3 may include the subject matter of any one of Examples 1-2, wherein the deviation is a predicted future deviation at a first time and the PCSA infrastructure evaluator is to send the message at a second time before the first time.

Example 4 may include the subject matter of any one of Examples 1-3, wherein the message includes a recommended action.

Example 5 may include the subject matter of Example 4, wherein the recommended action includes one or more of creation of a new virtual machine (VM) or container instance, migration of an existing VM or container instance, scaling up of existing resources, or scaling down of existing resources.

Example 6 may include the subject matter of Example 4, wherein the PCSA infrastructure evaluator is also to determine fifth one or more infrastructure components to scale up, scale down, or duplicate based at least in part on one or more of an additional SLM or an updated SLM, wherein the recommended action is based at least in part on the determined fifth one or more infrastructure components.

Example 7 may include the subject matter of any one of Examples 4-6, wherein the PCSA infrastructure evaluator is also to determine whether permission is required for the recommended action based at least in part on one or more policy parameters of one or more infrastructure management policies, wherein the message includes a permission required indicator in response to a determination permission is required.

Example 8 may include the subject matter of any one of Examples 1-7, wherein the telemetry signals include one or more of processor telemetry signals, operating system telemetry signals, virtual switch telemetry signals, storage subsystem telemetry signals, host bus adapter telemetry signals, network interface card telemetry signals, platform telemetry signals, physical switch telemetry signals, or router telemetry signals.

Example 9 may include the subject matter of any one of Examples 1-8, wherein the SLM includes one or more of transactions per second, input/output (TO) operations per second, network packets per second, network bandwidth, or remote procedure calls (RPCs) per second.

Example 10 may include the subject matter of any one of Examples 1-9, wherein the SLM includes one or more resources requirements or commitments of a number of processor cores, a cache capacity, a memory capacity, a memory bandwidth, a network data communication throughput capacity, or a storage capacity of the third one or more network components of the network infrastructure.

Example 11 may include the subject matter of any one of Examples 1-10, wherein the deviation from the SLM is also based at least in part on one or more application parameters or virtual network function (VNF) parameters.

Example 12 may include the subject matter of any one of Examples 1-11, wherein the PCSA infrastructure evaluator is to determine the deviation from the SLM based at least in part on a compacted set of telemetry signals.

Example 13 may include the subject matter of Example 12, wherein the PCSA infrastructure evaluator is also to filter the plurality of telemetry signals from the first one or more infrastructure components to determine the compacted set of telemetry signals.

Example 14 may include the subject matter of Example 12, wherein the plurality of telemetry signals from the first one or more infrastructure components is the compacted set of telemetry signals.

Example 15 may include the subject matter of any one of Examples 1-14, wherein the SLM is a service level agreement (SLA) or a service level objective (SLO).

Example 16 may include a method of infrastructure control comprising: receiving a plurality of telemetry signals from one or more network components at a policy controlled semi-autonomous (PCSA) infrastructure evaluator; receiving one or more service level metrics (SLMs) at the PCSA infrastructure evaluator; determining, by the PCSA infrastructure evaluator, a recommended action based at least in part on a machine learning model of a SLM deviation and one or more of the plurality of telemetry signals; and sending, by the PCSA infrastructure evaluator, a message to one or more of an orchestrator, a cloud computing fabric controller, a network functions virtualization (NFV) orchestrator (NFVO), a virtualized infrastructure manager (VIM), an operations support system (OSS), a business support system (BSS), or a management application, wherein the message includes the recommended action.

Example 17 may include the subject matter of Example 16, further comprising determining, by the PCSA infrastructure evaluator, a predicted future deviation from one or more of the SLMs at a first time, wherein determining the recommended action is based at least in part on the predicted future deviation and wherein sending the message occurs at a second time before the first time.

Example 18 may include the subject matter of any one of Examples 16-17, wherein the recommended action includes one or more of creation of a new virtual machine (VM) or container instance, migration of an existing VM or container instance, scaling up of existing resources, or scaling down of existing resources.

Example 19 may include the subject matter of any one of Examples 16-18, further comprising receiving one or more policy parameters of one or more network infrastructure management policies at the PCSA infrastructure evaluator, wherein determining the recommended action is also based at least in part on one or more of the one or more policy parameters.

Example 20 may include the subject matter of Example 19, further comprising determining, by the PCSA infrastructure evaluator, whether permission is required for the recommended action based at least in part on one or more of the one or more policy parameters, wherein the message includes a permission required indicator in response to a determination that permission is required.

Example 21 may include the subject matter of any one of Examples 16-20, wherein the plurality of telemetry signals include telemetry signals from a plurality of servers.

Example 22 may include the subject matter of any one of Examples 16-21, wherein the telemetry signals include one or more of processor telemetry signals, operating system telemetry signals, virtual switch telemetry signals, storage subsystem telemetry signals, host bus adapter telemetry signals, network interface card telemetry signals, platform telemetry signals, physical switch telemetry signals, or router telemetry signals.

Example 23 may include one or more non-transitory computer-readable media comprising instructions that cause an apparatus for infrastructure management, in response to execution of the instructions by the apparatus, to: determine a deviation from a service level metric (SLM) based at least in part on a machine-learning (ML) model of a SLM deviation and one or more of a plurality of telemetry signals; and send a message to one or more of an orchestrator, a cloud computing fabric controller, a network functions virtualization (NFV) orchestrator (NFVO), a virtualized infrastructure manager (VIM), an operations support system (OSS), a business support system (BSS), or a management application, based at least in part on the deviation from the SLM.

Example 24 may include the subject matter of Example 23, wherein the deviation is a predicted future deviation at a first time and the instructions are to cause the apparatus to send the message at a second time before the first time.

Example 25 may include the subject matter of any one of Examples 23-24, wherein the message includes a recommended action.

Example 26 may include the subject matter of Example 25, wherein the recommended action includes one or more of creation of a new virtual machine (VM) or container instance, migration of an existing VM or container instance, scaling up of existing resources, or scaling down of existing resources.

Example 27 may include the subject matter of any one of Examples 25-26, wherein the instructions are also to cause the apparatus to determine whether permission is required for the recommended action based at least in part on one or more policy parameters, wherein the message includes a permission required indicator in response to a determination permission is required.

Example 28 may include the subject matter of any one of Examples 23-27, wherein the telemetry signals include one or more of processor telemetry signals, operating system telemetry signals, virtual switch telemetry signals, storage subsystem telemetry signals, host bus adapter telemetry signals, network interface card telemetry signals, platform telemetry signals, physical switch telemetry signals, or router telemetry signals.

Example 29 may include the subject matter of any one of Examples 23-28, wherein the SLM includes one or more of a number of processor cores, a cache capacity, a memory capacity, a memory bandwidth, a network data communication throughput capacity, or a storage capacity.

Example 30 may include the subject matter of any one of Examples 23-29, wherein the deviation from the SLM is also based at least in part on one or more application parameters or virtual network function (VNF) parameters.

Example 31 may include an apparatus for infrastructure control comprising: means for receiving a plurality of telemetry signals from one or more network components; means for receiving one or more service level metrics (SLMs); means for determining a recommended action based at least in part on a machine learning model of a SLM deviation and one or more of the plurality of telemetry signals; and means for sending a message to one or more of an orchestrator, a cloud computing fabric controller, a network functions virtualization (NFV) orchestrator (NFVO), a virtualized infrastructure manager (VIM), an operations support system (OSS), a business support system (BSS), or a management application, wherein the message includes the recommended action.

Example 32 may include the subject matter of Example 31, further comprising means for determining a predicted future deviation from one or more of the SLMs at a first time, wherein the means for determining the recommended action is to determine the recommended action based at least in part on the predicted future deviation and wherein the means for sending the message is to send the message at a second time before the first time.

Example 33 may include the subject matter of any one of Examples 31-32, wherein the recommended action includes one or more of creation of a new virtual machine (VM) or container instance, migration of an existing VM or container instance, scaling up of existing resources, or scaling down of existing resources.

Example 34 may include the subject matter of any one of Examples 31-33, further comprising means for receiving one or more policy parameters of one or more network infrastructure management policies, wherein the means for determining the recommended action is also to determine the recommended action based at least in part on one or more of the one or more policy parameters.

Example 35 may include the subject matter of Example 34, further comprising means for determining whether permission is required for the recommended action based at least in part on one or more of the one or more policy parameters, wherein the message includes a permission required indicator in response to a determination that permission is required.

Example 36 may include the subject matter of any one of Examples 31-35, wherein the plurality of telemetry signals include telemetry signals from a plurality of servers.

Example 37 may include the subject matter of any one of Examples 31-36, wherein the telemetry signals include one or more of processor telemetry signals, operating system telemetry signals, virtual switch telemetry signals, storage subsystem telemetry signals, host bus adapter telemetry signals, network interface card telemetry signals, platform telemetry signals, physical switch telemetry signals, or router telemetry signals.

Example 38 may include the subject matter of any one of Examples 1-15, wherein the first one or more infrastructure components and the third one or more infrastructure components are the same.

Example 39 may include the subject matter of any one of Examples 1-15, wherein the second one or more infrastructure components and the third one or more infrastructure components are the same.

Example 40 may include the subject matter of any one of Examples 1-15, wherein the first one or more infrastructure components, the second one or more infrastructure components, and the third one or more infrastructure components are the same.