Abstract: A system that determines whether a trigger has occurred within a cloud infrastructure. The system, in response to determining that a trigger has occurred, extracts characteristics from one or more virtual network functions (VNFs) of a service chain. The system, in response to extracting characteristics from the one or more VNFs, determines rehoming actions for each of the one or more VNFs. The system, in response to determining rehoming actions, predicts a rehoming delay or a chain downtime for each of the rehoming actions for each of the one or more VNFs. The system determines an optimal rehoming action from the rehoming actions for at least one of the one or more VNFs using the rehoming delay or the chain downtime for each rehoming action of the rehoming actions. The system performs the optimal rehoming action for the at least one of one or more VNFs.

Abstract: A system that determines whether a trigger has occurred within a cloud infrastructure. The system, in response to determining that a trigger has occurred, extracts characteristics from one or more virtual network functions (VNFs) of a service chain. The system, in response to extracting characteristics from the one or more VNFs, determines rehoming actions for each of the one or more VNFs. The system, in response to determining rehoming actions, predicts a rehoming delay or a chain downtime for each of the rehoming actions for each of the one or more VNFs. The system determines an optimal rehoming action from the rehoming actions for at least one of the one or more VNFs using the rehoming delay or the chain downtime for each rehoming action of the rehoming actions. The system performs the optimal rehoming action for the at least one of one or more VNFs.

Abstract: A method for scaling a cloud infrastructure, comprises receiving at least one of resource-level metrics and application-level metrics, estimating parameters of at least one application based on the received metrics, automatically and dynamically determining directives for scaling application deployment based on the estimated parameters, and providing the directives to a cloud service provider to execute the scaling.

Abstract: A method for scaling a cloud infrastructure, comprises receiving at least one of resource-level metrics and application-level metrics, estimating parameters of at least one application based on the received metrics, automatically and dynamically determining directives for scaling application deployment based on the estimated parameters, and providing the directives to a cloud service provider to execute the scaling.

Abstract: Examples of GPU resource sharing among distributed applications in a distributed computing environment are disclosed. In one example, a method includes receiving a first request from a first distributed application of the plurality of distributed applications for first requested GPU resources. The method may further include receiving a second request from a second distributed application of the plurality of distributed applications for second requested GPU resources. The method may also include receiving response from each of the plurality of computing nodes indicating an availability of GPU resources for each of the plurality of computing nodes. Additionally, the method may include, responsive to determining that at least one of the first and second requests can be fulfilled by at least one of the plurality of computing nodes, allocating a first set of GPU slices for the first application and allocating a second set of GPU slices for the second application.

Abstract: Examples of GPU resource sharing among applications are disclosed. In one example, a method includes receiving a first request from a first application of the plurality of applications for first requested GPU resources, and receiving a second request from a second application of the plurality of applications for second GPU resources. The method also includes, responsive to determining that the first requested GPU resources are available, allocating a first slice of the GPU resources with a first requested amount of resources to the first application and, responsive to determining that the second requested GPU resources are available, allocating a second slice of the GPU resources with a second requested amount of resources to the second application. Further, the method includes enabling the first application and the second application to execute concurrently within the first slice of the GPU and the second slice of the GPU respectively.

Abstract: Examples of GPU resource sharing among applications are disclosed. In one example, a method includes receiving a first request from a first application of the plurality of applications for first requested GPU resources, and receiving a second request from a second application of the plurality of applications for second GPU resources. The method also includes, responsive to determining that the first requested GPU resources are available, allocating a first slice of the GPU resources with a first requested amount of resources to the first application and, responsive to determining that the second requested GPU resources are available, allocating a second slice of the GPU resources with a second requested amount of resources to the second application. Further, the method includes enabling the first application and the second application to execute concurrently within the first slice of the GPU and the second slice of the GPU respectively.

Abstract: Examples of GPU resource sharing among distributed applications in a distributed computing environment are disclosed. In one example, a method includes receiving a first request from a first distributed application of the plurality of distributed applications for first requested GPU resources. The method may further include receiving a second request from a second distributed application of the plurality of distributed applications for second requested GPU resources. The method may also include receiving response from each of the plurality of computing nodes indicating an availability of GPU resources for each of the plurality of computing nodes. Additionally, the method may include, responsive to determining that at least one of the first and second requests can be fulfilled by at least one of the plurality of computing nodes, allocating a first set of GPU slices for the first application and allocating a second set of GPU slices for the second application.

Abstract: A method for scaling a cloud infrastructure, comprises receiving at least one of resource-level metrics and application-level metrics, estimating parameters of at least one application based on the received metrics, automatically and dynamically determining directives for scaling application deployment based on the estimated parameters, and providing the directives to a cloud service provider to execute the scaling.

Abstract: A method for scaling a cloud infrastructure, comprises receiving at least one of resource-level metrics and application-level metrics, estimating parameters of at least one application based on the received metrics, automatically and dynamically determining directives for scaling application deployment based on the estimated parameters, and providing the directives to a cloud service provider to execute the scaling.

Abstract: A method for scaling a cloud infrastructure, comprises receiving at least one of resource-level metrics and application-level metrics, estimating parameters of at least one application based on the received metrics, automatically and dynamically determining directives for scaling application deployment based on the estimated parameters, and providing the directives to a cloud service provider to execute the scaling.

Abstract: A method for scaling a cloud infrastructure, comprises receiving at least one of resource-level metrics and application-level metrics, estimating parameters of at least one application based on the received metrics, automatically and dynamically determining directives for scaling application deployment based on the estimated parameters, and providing the directives to a cloud service provider to execute the scaling.

Abstract: A method for scaling a cloud infrastructure, comprises receiving at least one of resource-level metrics and application-level metrics, estimating parameters of at least one application based on the received metrics, automatically and dynamically determining directives for scaling application deployment based on the estimated parameters, and providing the directives to a cloud service provider to execute the scaling.

Abstract: A method for scaling a cloud infrastructure, comprises receiving at least one of resource-level metrics and application-level metrics, estimating parameters of at least one application based on the received metrics, automatically and dynamically determining directives for scaling application deployment based on the estimated parameters, and providing the directives to a cloud service provider to execute the scaling.

Abstract: Systems, apparatuses, methods, and software that implement power budget allocation optimization algorithms in multi-processor systems, such as server farms. The algorithms are derived from a queuing theoretic model that minimizes the mean response time of the system to the jobs in the workload while accounting for a variety of factors. These factors include, but are not necessarily limited to, the type of power (frequency) scaling mechanism(s) available within the processors in the system, the power-to-frequency relationship(s) of the processors for the scaling mechanism(s) available, whether or not the system is an open or closed loop system, the arrival rate of jobs incoming into the system, the number of jobs within the system, and the type of workload being processed.

Abstract: A dynamic capacity management policy for multi-paralleled computing resources (e.g., application servers, virtual application servers, etc.) that includes one or more of a state-change component, a load-balancing component, and a robustness-control component. The state-change component delays the release (e.g., powering down of a physical server, removal from a virtual-server lease, etc.) of each computing resource for a set amount of time. The load-balancing component can work in conjunction with the state-change component to reduce the number of idle computing resources by distributing incoming requests in a manner that keeps the already-processing computing resources as full of requests as possible. The robustness-control component scales capacity as a function of the current number of requests within the system of computing resources to account for variations other than request rate, such as request size, reduced processor frequency, network slowdowns, etc., that affect processing capacity.

Abstract: Processor-management techniques that purposely alternate a processor between an operating state and a non-operating state while the processor is executing the workload. The techniques leverage the “ultra-low-power” non-operating states of many processors to provide predictable power and/or frequency control of the processor. These techniques can provide better performance than known clock-throttling and dynamic voltage and frequency scaling schemes for controlling processors.

Abstract: Example methods, apparatus and articles of manufacture to provision data center resources are disclosed. An example method includes provisioning a first portion of data center resources to operate during time intervals based on a base workload for the respective time intervals, the base workload being based on data patterns of a data center and configuring a second portion of the data center resources to operate when an actual workload exceeds a threshold corresponding to the base workload.

Abstract: A dynamic capacity management policy for multi-paralleled computing resources (e.g., application servers, virtual application servers, etc.) that includes one or more of a state-change component, a load-balancing component, and a robustness-control component. The state-change component delays the release (e.g., powering down of a physical server, removal from a virtual-server lease, etc.) of each computing resource for a set amount of time. The load-balancing component can work in conjunction with the state-change component to reduce the number of idle computing resources by distributing incoming requests in a manner that keeps the already-processing computing resources as full of requests as possible. The robustness-control component scales capacity as a function of the current number of requests within the system of computing resources to account for variations other than request rate, such as request size, reduced processor frequency, network slowdowns, etc., that affect processing capacity.

Abstract: Systems, apparatuses, methods, and software that implement power budget allocation optimization algorithms in multi-processor systems, such as server farms. The algorithms are derived from a queuing theoretic model that minimizes the mean response time of the system to the jobs in the workload while accounting for a variety of factors. These factors include, but are not necessarily limited to, the type of power (frequency) scaling mechanism(s) available within the processors in the system, the power-to-frequency relationship(s) of the processors for the scaling mechanism(s) available, whether or not the system is an open or closed loop system, the arrival rate of jobs incoming into the system, the number of jobs within the system, and the type of workload being processed.