## 2 Resource Allocation Model  
Consider a set \(S=\{1,\ldots,m\}\) of \(m\) available resources, where \(T_{r}\) is the total amount of a resource \(r\) available in the cloud. In our allocation model, the resources are considered as servers. Each resource type \(r\) is modeled as a single server \(S_{r}\), and each server has a single queue \(Q_{r}\) of user jobs that require the specific resource. The queue lengths are considered large enough to accommodate all the possible user requests per resource. The jobs enter a queue \(Q_{r}\) to request a resource type according to a Poisson arrival process with rate \(\lambda_{r}\). The service time (the time required for a job to obtain a certain resource) is exponential with mean \(1/\mu\). A cloud has an infinite number of users and each user executes a number of jobs. Each job is described by its demand vector \(V_{i}=\{V_{i1},V_{i2},\ldots V_{im}\}\). The demand vector shows the amount of each resource demanded by each job. A job's _job dominant resource_, is the most necessary resource for this job. For example, some jobs are CPU-intensive, while others require more memory. This notion has been introduced in a number of papers (for example, see References [32; 33]). The _dominant server queue (DSQ)_ is the queue of the dominant resource server. All the jobs requiring a dominant resource enter the DSQ before entering any other queue to ask for other resources. In the example of Figure 1, the DSQ is \(Q_{1}\). The remaining queues correspond to non-dominant resources. A vector in the form \(\mathbf{K}=(K_{1},K_{2},\ldots,K_{m})\) expresses the cloud's state. Here, \(K\) is the amount of available resources in every server. Let us consider the conditional probability of moving from state \(\mathbf{K}\) to \(\mathbf{K}^{\prime}\), denoted as \(p(\mathbf{K},t+\delta\mid\mathbf{K},t)\), where \(\delta\) is a very short period, enough to accommodate only one change of state. The overall probability of reaching a state \(\mathbf{K}^{\prime  
Let us consider a system has the 3 most important resources, that is, CPU, RAM, and disk. A _resource allocator_ (see Figure 2) is used; the resource allocator is a central system that handles a queue system. Generally, the resource allocator has \(m\) queue systems or classes, each having a structure similar to the one shown in Figure 1. A class is characterized by the dominant resource. Each class has \(m\) queues, one for each resource. For our example, \(m=3\). Thus, the total number of queues in the system \(m^{2}\). Obviously, the dominant resource is different for each queue system and each system handles and allocates a percentage of the overall available resources. We use \(b_{i}\) to refer to this percentage for each queue. In the example of Figure 1, \(b_{1}\) is the percentage of the dominant queue (in our example \(Q_{1}\)) and \(b_{2}\), \(b_{3}\) are the percentages for the remaining queues (\(Q_{2}\) and \(Q_{3}\) for our example). When a job requires resources, its dominant resource is examined and it is assigned to the proper queue system, the one with the dominant resource as DSQ. Thus, a job requests resources starting from DSQ and then it \"moves\" accross the other queues to request the remaining resources. Then, it may \"return\" back to DSQ to request more resources. Mathematically, for the queue system of Figure 1, this behavior is modeled by the following equations:  
\[ \begin{split}\lambda_{1}&=\lambda+(\mu_{2}+\mu_{3 })b_{1}\\ \lambda_{2}&=b_{1}\lambda_{1}\\ \lambda_{3}&=b_{2}\lambda_{2},\end{split}  \tag{4}\]  
where \(\lambda\) denotes the total number of rate of all the jobs with \(Q_{1}\) as their DSQ. The \(b_{j}\)'s have to be regularly recalculated, as resources are allocated and de-allocated. Therefore, by employing a queuing system, our resource allocation scheme is able to estimate the maximum job arrival rate that the system can afford.