Database Reference
In-Depth Information
The rest of the chapter is organized as follows. A three-pool cloud architecture is
described in Section 18.2. Our performance analysis approach will be based on the
system described in Section 18.2. The main idea of interacting submodels approach
is presented in Section 18.3. Analytic-numeric solutions of the interacting submodels
and comparison with monolithic model solutions are presented in Section 18.4. Section
18.5.2 presents discussions on the proposed approach, possible extensions and some
highlights on related research. Finally, this chapter is concluded in Section 18.6.
18.2 A THREE-POOL CLOUD ARCHITECTURE
We consider an IaaS cloud where PMs are grouped into multiple pools based on
power consumption and response time characteristics. Specifically we consider three
pools: hot, warm, and cold. Figure 18.1 shows the overall architecture and request
provisioning steps. In the hot pool, all PMs are running and VMs need to be config-
ured and deployed as per user request. In contrast, PMs in the warm pool are turned
on but not running. Warm PMs initially remain in a power-saving/sleep mode and
they are turned on whenever a deployment request comes. Thus, provisioning a VM
in the warm pool requires additional delay compared with PMs in the hot pool. PMs
in the cold pool are initially turned off. Hence, provisioning a VM in the cold pool
requires additional delay. Notice that, power consumption of a hot PM is maximum,
whereas the power consumption of a cold PM is minimum. Grouping the PMs in
multiple pools helps the provider to maintain a tradeoff in service offering, based on
power consumption and response time characteristics [9].
We assume that the service requests are homogeneous and each request is for one
VM instance with specific CPU, RAM, and disk capacity. Throughout this chapter,
we use the term job to denote a service request. When a request arrives, Resource
Provisioning Decision Engine (RPDE) tries to find a PM from the hot pool that can
accept the request. If all the PMs in hot pool are already busy in running jobs, RPDE
tries to find a PM from the warm pool. If no such PMs are available in the warm
pool, RPDE tries to find a cold PM that can accept the job. A request is rejected if
none of the PMs in the hot/warm/cold pool can accept the request. The elapsed time
Provisioning response delay
VM
deployment
Provisioning
decision
Actual service
Out
Arrival
Queuing
Instantiation
Resource
provisioning
decision
engine
Run-time
execution
Job rejection
due to buffer full
Job rejection due to
insucient capacity
FIGURE 18.1
Request provisioning steps in a three-pool cloud architecture.
Search WWH ::




Custom Search