Escalonamento orientado por qualidade de serviço em infraestruturas de computação na nuvem.

Abstract

The Cloud Computing model of infrastructure as a service (IaaS, from Infraestructureas a Service) has increasingly become the main choice for provisioning computing infrastructure. As a result, the diversity of workloads submitted by users also grows. This feature, coupled with the heterogeneity of the complex infrastructures used to run these workloads, make resource management one of the main challenges for large-scale cloud computing providers. To increase the use of resources (consequently profitability) and satisfy the different needs of users, providers can offer multiple classes of service. These classes are distinguished by the promised quality of service (QoS), which is commonly defined in terms of service level objectives (SLO) established in a service level agreement (SLA , from the English Service Level Agreement). On the other hand, providers are subject to the payment of penalties in case of breaches of the SLAs. Resource management is divided into stages with well-defined responsibilities. These steps operate together in order to avoid over-provisioning scenarios (keeping costs as low as possible) and under-provisioning (keeping QoS at acceptable levels). The scheduling activity is responsible for defining which requests must have resources allocated at a given time and which servers must provide these resources. In the context of large-scale providers, priority-based scheduling policies are generally used to ensure that requests for different classes of service receive promised maQoS. Higher priorities are associated with classes whose promised QoSs are higher. If necessary, resources allocated to requests with lower priorities can be preempted to allow requests with higher priorities to be executed. However, in this context, the QoS delivered to requests during periods of resource contention may be unfair for certain requests. In particular, requests with lower priorities may have their resources preempted for how to give others with higher priorities, even if the QoS delivered to the latter is above the desired level, and the QoS of the former is below expected. In addition, requests with the same priority and competing for the same resource can experience very different QoSs, since some of them can always be executed while others remain always pending. This work presents a scheduling policy that is guided by the QoS promised for the requests. This follows a new preemption approach in which any request whose current QoS is exceeding its respective target may have its resources preempted for the benefit of others with QoS below the target (or that are closer to having their SLOs not satisfied). The benefits of using a QoS-oriented policy are: (i) it keeps the QoS for each request as high as possible, considering their respective goals and available resources; and (ii) it minimizes the variance of the QoS delivered for requests of the same class, promoting fair provisioning. These characteristics allow the definition of SLAs that are more appropriate and that are in agreement with the main public cloud providers. The proposed policy was evaluated through comparisons between its results and those obtained with a scheduler that represents the state of practice, based on priority. This comparison was made by simulation experiments — validated by measurement experiments fed by samples of the execution tracks of a production system. Overall, QoS-driven scheduling delivers better service than priority-based, especially when resource contention is not as high. The similarity of QoS delivered for requests from the same class was also much higher when QoS-oriented scheduling was used, particularly when not all requests received the promised QoS. In addition, based on the current practice of large public providers, the results showed that the penalties incurred for using the priority-based scheduler can be, on average, up to approximately 2 times higher than those incurred by the QoS-driven scheduler. , the operating cost of the QoS-oriented scheduler was approximately 15 times higher. However, there is still room for the implementation of optimizations, such as a cache mechanism already implemented in the base-a-priority scheduling. The new policy still proved viable to be implemented in a real system. The metrics used by your scheduler have been defined so that the policy operates on the system without interfering with the way users interact as they do.