# A Framework for Proactive Resource Provisioning in IaaS Clouds
## 3 System Framework
### Over-Commit Mechanism  
Resource allocation generally focuses on fairness and efficiency in cloud computing systems. Domain Resource Fairness (DRF), which is the default approach implemented in the Apache Mesos system, tries to obtain the fair allocation of multiple resource types. But the fair allocation usually results in poor resource utilization, which means the optimal resource management could not be achieved. Therefore, this framework proposes an over-commit mechanism for physical resources to enhance the resource utilization.  
In virtual cluster computing systems, the master node hosts the processing and storage management services, and data is essentially stored and processed on slave nodes. In general, when a node is added as a slave to the virtual cluster computing system, this slave node has to register and provide its resource information to the master node. During this process, the over-commit mechanism would be triggered, and the slave node would provide dishonest information that it has more physical resources. That is, the number of virtual machines recorded in the master node exceeds the number of virtual machines which all slave nodes could actually provide. Therefore, when an application requests virtual resources for execution, the master node would offer more resources than expected. These over-committed virtual machines have to compete for actual physical resources during execution, and the resource utilization is supposed to be improved.  
Although applying the over-commit approach is beneficial for achieving better resource utilization, there are still some risks. When the amount of aggregate resources requested by virtual machines exceeds that of available resources on the over-committed physical machines, the service response time of some requests may be significantly lengthened. Hence, in order to prevent the resource over-provisioning, a mechanism is proposed to estimate an appropriate number of over-committed resources from historical executing logs.  
The number of over-committed resources is decided by a parameter called degree of over-commit. A degree of over-commit of 1 means no over-committed resources are provisioned. If the degree of over-commit is \(k\), the number of resources are over-committed \(k\) times. In the proposed system framework, a dedicated historical executing log is maintained for each application. Once an application is launched, a pair \(P_{i}(D_{i},T(D_{i}))\) is recorded where \(D_{i}\) is the degree of over-commit and \(T(D_{i})\) is the execution time. Information recorded in these historical executing logs would be referenced to estimate the appropriate degree of over-commit.  
Figure 4 shows the pseudo-code of the proposed resource estimating algorithm. When an application is launched for the first or second time, since the information recorded in the corresponded historical executing log is limited, the appropriate degrees of over-commit \(D_{app}\) would be directly set to 2 and 4, respectively. When an application is launched more than twice, \(D_{app}\) is estimated according to the binary-search-based approximation algorithm. If the largest \(D_{i}\) that has been set results in the minimal execution time, \(D_{i}\) is simply doubled to provision more over-committed resources. After several iterations, this estimating mechanism is supposed to find a stable \(D_{app}\).