Automatic VM Allocation for Scientific Application

Transcription

1 SC-BDA, Singapore, December IEEE 18th International Conference on arallel and Distributed Systems Automatic VM Allocation for Scientific Application Sarunya umma, Tiranee Achalakul Department of Computer Engineering King Mongkut s University of Technology Thonburi Bangkok, Thailand sarunya.pumma@gmail.com, tiranee@cpe.kmutt.ac.th Abstract Cloud has been the main technology utilized as a high performance computing (HC) platform. The characteristics of cloud can satisfy a large scale processing required by scientific applications, which are mostly computeintensive with big data. Cloud can also reduce the computing cost through sharing and virtualizing of resources. In the cloud, a large number of virtual machines (VM) can be generated on demands. In order to obtain the optimal cost and high efficiency in the task execution on the public cloud, the suitable amount of virtual machines should be properly determined prior to the start of the computation. Moreover, the application should be effectively partitioned and distributed onto the virtual machines. In this paper, we propose an automatic mechanism to allocate the optimal numbers of resources in the cloud. The novel resource estimation model and scheduling algorithm are presented. We select an analytic application with high level of computations in the field of epidemic forecast to demonstrate the use of the designed mechanism. Experimental studies have been conducted to examine the resource prediction accuracy and the scalability of running the application on the cloud. Keywords-cloud computing; scheduling algorithm; resource estimation; resource allocation; regression I. INTRODUCTION At present, cloud computing [1] is getting more popular because of its ability to provision computer resources for users automatically within a short time. It combines computer resources, such as CU, memory, and storage, into a virtual resource pool. Computing resources can be allocated according to the user s requirement. No only, the resources can be accessed from anywhere via the Internet, but users can also be charged by utilization rate of the computing power, bandwidth, and storage. Hence, cloud computing can satisfy the immediate need of low cost computing resources. Cloud resources can be utilized to build a high performance computing (HC) [] platform which supports the execution of various scientific applications. The issue of excessive execution time in such applications can be alleviated using a cloud solution by way of dynamic resource allocations. In the cloud, users can increase or decrease the number of virtual machines used anytime during the execution. If execution time needs to be reduced, more machines can be temporary bought. Moreover, this ondemand service allows the users to save cost and only pay for the usage time using the pay-as-you-go model. rocessors utilization can also be improved and energy will Li Xiaorong Institute of High erformance Computing Agency for Science, Technology and Research Singapore lixr@ihpc.a-star.edu.sg not be wasted. Scientific computing in the cloud thus has gained popularity in the past few years. In order to process the scientific applications efficiently, the optimal number of resources should be determined before the execution starts. If the number of allocated machines is excessive, execution efficiency will drop, while insufficient resources will affect the execution performance. Moreover, a good job partitioning and scheduling methods are needed to balance the workload among all participated machines. In this paper, we present a mechanism that can estimate an appropriate number of VMs in the cloud for a scientific application and schedule sliced tasks to be executed on machines efficiently. We have adopted an epidemic forecast model as an example to test the performance of our designed mechanism. The rest of this paper is structured as follows: Section summarizes the related works, Section 3 describes the overview of the SEIR-based epidemic forecast application, Section 4 introduces our proposed mechanism, Section 5 shows the experimental results and Section 6 presents the conclusion. II. RELATED WORK The related works in VM allocation are presented in this section. In [3], Ostermann et. al. have proposed a mechanism in which the cloud management component determines the types of additional instances that have the best price/performance ratio. However, the optimum number of machines, which is based on the userís input, was not considered. The benefit of a good resource allocation method is discussed in the research by Yazir et. al. [4]. In this work, under/over-utilization of computational resources is avoided through the use of dynamic resource allocations. The Autonomous Node Agents, which are distributed onto machines, configure and manage the virtual machines by using a set of policies to preserve the efficiency of the executions. On the cloud, several pricing options are available including the on-demand instance purchasing and the resource auctioning. Lin, et. al. [5] has presented the efficient mechanism to dynamically allocate cloud resources for the auction method. The marginal bid has been applied to their approach for determining the appropriate resources. Furthermore, Chang et. al. [6] investigated the resource prediction for executing the general scientific applications on the cloud. Workflow structures are categorized into batch /1 $ IEEE DOI /ICADS

2 SC-BDA, Singapore, December 01 task and single-task types. Depending on the type, the approximation algorithm will estimate the number of VMs that should be used in the processing. This method is generalized and may not be able to handle some scientific applications with large and complex workflows. In this paper, our contribution is an automatic mechanism for resource allocations. We design a scalable method which automatically scales up and determines the optimal amount of resources according to usersí requirements of application performance. An automatic job partitioning and scheduling are also proposed. The experimental test-bed is a private cloud. For an example application, we use an epidemic forecast model, where parameters estimation step requires excessive computing resources. Our mechanism can improve the execution performance as shown in the rest of the paper. III. THE OVERVIEW OF EIDEMIC FORECAST This section describes an overview of the epidemic forecast. The application provides the predictive information about disease outbreaks by simulating epidemic behavior using the historical data and statistical data of a disease. The mathematical model for the epidemic forecast, called SEIR [7], is utilized to perform the simulation. The epidemic forecast comprises phases; parameter estimation and SEIR-based simulation as described in our previous work [8]. arameters estimation determines the appropriate values for input parameters, which are contact rate (), exposed period (E), infected period (I), and death rate (), and initial number of exposed individuals (). SEIRbased simulation calculates the number of individuals in epidemic states for each city in the specified time period. Epidemic arameter Estimation Algorithm Input: opulation Data, Actual Data Output: Optimized set of parameters for a disease 1 Set initial population and geographical data Set initial upper and lower bound for parameters 3 FOR ALL COMBINATION (, E, I, α, β) // 5-nested loops 4 FOR EACH Time (day) 5 Update the number of individuals in epidemic states using SEIR model 6 FOR EACH Time (day) 7 Compute least square error 8 END FOR 9 Select the least error and the optimized parameters Figure 1. Epidemic arameter Estimation Algorithm. The parameter estimation phase requires a large amount of computational power to obtain the estimated set of parameter values within a reasonable amount of time. The algorithm consists of 5 nested-loops for 5 parameters,, E, I,, and, as shown in Fig. 1. Each parameter has the upper and lower bounds called max and min. These bounds control the size of the parameters search space. In our initial experiment, the estimation process could take up to 1 hours. Therefore, we design a scalable method which distributes the parallel tasks to the cloud resources effectively in order to reduce the execution time. The method described in the next section allows users to create multiple VMs and run the analytic applications in a scalable manner. IV. METHODOLOGY In our research framework, we utilized a private cloud as an experimental platform and developed the automatic mechanism for appropriate computational resources allocation of data analytics applications. Two types of virtual machines are used. The shared instance works as a master node with a scheduler installed. The general instance works on the calculation. The overall sequence of execution is described as follows: A shared instance calls the scheduler to determine the job execution sequence. The scheduler will then gather the information on resource availability in the cloud. The scheduler will calculate a number of tasks to be run on each VM using the multiple-loop decomposition algorithm (Fig. ). Tasks will be distributed to general instances based on the schedule. All VMs will execute their assigned load simultaneously. Remote Secure Shell (RSH) is used for delegating works to machines. After all tasks are executed, each VM will store the output file in a shared repository. The results from VMs will be consolidated and the estimated parameters will be determined as the final results. The scheduler is created on the shared instance and it is responsible for 1) determining an appropriate number of VMs to be generated (resource estimation), and ) partitioning application and scheduling tasks to be run on VMs automatically (task partitioning and scheduling). The details of the steps will be described in the following subsections. A. Resource Estimation In order to estimate resource, we developed a predictive model based on the application s computational complexity. The model indicates a relationship between execution time and the input variables. The framework can be separated into 4 main parts: computational complexity analysis, coefficient calibration, accuracy calculation, and model usage. 1) Computational Complexity Analysis The time used to complete the execution can be predicted by calculating the sequential complexity [9] of an analytic algorithm as a function of parameters. Every term in the function is multiplied by proper coefficients in order to weigh the importance of that term in the algorithm. The execution of the epidemic forecast on the cloud can be separated into job partitioning, parameter estimation, and result gathering as described below: a) Job partitioning: The job partitioning process determines the amount of appropriate workload on VMs. A schedule can be created using -nested loops over the number of processors or (details of the partitioning algorithm will be presented in Fig. ). Thus, to create a schedule, the execution time is 89

3 SC-BDA, Singapore, December 01 where T J = C + 1 C (1) T J = total execution time of job partitioning = number of VM C 1 and C are coefficients b) arameter estimation: The parameter estimation process consists of 5 nested-loops i.e., E, I,, and, as shown in Fig. 1. The number of iterations in each loop is defined by a minimum (min) boundary, maximum (max) boundary, and incremental step. We will represent each loop as, E, I,, and, respectively. The computational time can be defined as: T = λeiαβ 1 () where, E, I,, and are contact rate, exposed period, infected period, and death rate, and initial number of exposed individuals, respectively. The calculation inside the nested-loops includes initializing parameters, creating objects, updating the number of individuals in different epidemic states using the SEIR model and disease parameters, and comparing the simulated result to actual data and computing error. Notice that the number of iterations for the last steps depends on the finish time (F), i.e. simulation time. The computational time can be defined as follows: T = E + I + F + FE + FI (3) where E and I are exposed period and infected period, respectively. The sequential complexity of parameter estimation is: T E = T1 T = C3λE Iαβ + C4λEI αβ + C5λEIαβF + C6 λe IαβF + C7λEI αβf (4) where T E = total execution time of parameter estimation and C i (3 i 7) are coefficients. Since parameter estimation is performed in the cloud, the total execution time of parameter estimation will be reduced when the number of VMs is increased. That means, execution time varies inversely with the number of VMs. Thus, the total execution time of parameter estimation in the cloud can be defined as: T C TE λe Iαβ λei αβ λeiαβf = = C3 + C4 + C5 + λe IαβF λei αβf + C6 + C7 (5) where T C = total execution time of parameter estimation on cloud c) Result gathering: After the execution is finished, the host machine will combine the results into the same file and compare them. The execution time can be defined as follows: T R = C 8 (6) The total execution time to perform parameter estimation in the cloud is the sum of T J, T C, and T R. The overhead of creating VMs should be counted in the execution time, thus we added one more constant term. Therefore, the predictive model is shown as follows: λe Iαβ λei αβ λeiαβf T = C1 + C + C3 + C4 + C5 λe IαβF λei αβf C 6 +C 7 +C (7) 8 ) Coefficient Calibration In order to complete the predictive model presented in the previous section, the coefficients, C 1, C,, and C 8 have to be derived. We have collected 100 experiment records with different random sets of inputs in order to measure the execution time of parameter estimation. We utilize linear regression by applying the least-square fitting [10] technique. The least-square fitting attempted to fit the curve to the set actual data as much as possible. Our predictive model is a polynomial equation, for example; y 1 = C 1 x 11 + C x C m x 1m, which can be transformed into vector form as follows y1 C1 x11.. x1m = : : : : : y n Cn xn 1.. xnm (8) where n represents number of data records, and m represents number of terms in a model The least-square solution is shown as follows: T 1 T C = ( x x) x y (9) Our model has n and m equaling 100 and 8, respectively. The coefficients that we have obtained are presented below: C 1 = -1.14e+01, C = 1.70e-01, C 3 = -4.76e-0, C 4 = -1.63e-01, C 5 =.3e-06, C 6 = 3.4e-04, C 7 = 1.17.e-03, C 8 =.37e+0 Therefore, the model that we obtained is: T = (1.14e+ 01) + (1.70e 01) (4.76e 0) λe Iαβ + (.3e 06) λeiαβf (1.63e 01) λei αβ + (3.4e 04) λe IαβF +(1.17.e 03) λei αβf + (.37e + 0) (10) 3) Accuracy Calculation In order to measure the accuracy of the predictive model, we plot the predictive results against actual data obtained from the experiment. R-square [11], which is a value that indicates a predictive efficiency, is also calculated. The accuracy is considered high with the R-square is closer to 1 (100%). The R-square of our model is 99.5%, which is high. Hence, this model is proper to be used for determining the number of VMs. 4) Model Usage The obtained model can be used execution time prediction. To use the model for predicting the number of VMs, the expected estimation time must be assigned. From equation 10, we multiply both side of equation by as shown below. (1.70e 01) 3 (1.14e + 01) +[(.37e + 0) T] 830

4 SC-BDA, Singapore, December 01 +λeiαβ[ (4.76e 0)E (1.63e 01)I + (.3e 06)F +(3.4e 04)EF + (1.17e 03)IF] = 0 (11) MATLAB is then used to solve the cubic polynomial equation. The predicted number of VMs may vary from 1 to 48, which is the size of the resource pool in our test-bed. B. Task partitioning and scheduling In this section, we describe the multiple-loop decomposition algorithm that is used to the parallelize parameter estimation process and schedule workloads onto multiple VMs. The multiple-loop decomposition algorithm divides the number of total iterations, which we will call task, to VMs equally. It calculates the min and max boundaries of each loop for each VM and assigns a set of min and max values, which are min, max, min E, max E, min I, max I, min, max, min, and max, to VMs. Notice that each VM may have more than 1 set of min and max boundaries assigned. The algorithm starts by dividing the outermost loop, loop, and determines if there are remaining tasks. It will calculate the min and max values of -loop for each VM and assign the set of min and max boundaries to VMs. Note that the min and max bounds of other loops are still the same. In the case that the remaining tasks exist, it will calculate the second boundaries set. First, it will set the min and max boundaries of remaining tasks from the previous calculation as the boundaries of -loop for the next computation. Then, it will divide the inner loop, which is E-loop, by using the same calculation method. Only the boundaries of E-loop are changed, the rest are still the same. The algorithm will repeatedly perform the calculation and assign the set of values to VMs until there are no remaining tasks or all loops are partitioned. The sequence of the algorithm is shown in Fig.. Multiple Loop Decomposition Algorithm Input: Loops boundaries and incremental step Output: Schedule (Set of boundaries) 1 Set initial min loop, max loop and steps loop FOR EACH loop 3 Calculate total task, number of task on each machine, and remaining task 6 IF Total task more than number of machine THEN 7 Set the boundaries set to each VM 8 IF There has no remaining tasks THEN 9 BREAK 10 ELSE 11 IF This is the last loop THEN 1 Set the remaining task to VMs 13 ELSE 14 Set min loop = min remain and max loop = max remain 15 END IF 16 END IF 17 ELSE IF There is only 1 task and this is the last loop 18 Set the boundaries set to each VM 19 ELSE IF Total task is less than number of machine 0 Set the remaining task to VMs 1 END IF END FOR 3 FOR EACH /*Create schedule*/ 4 Append command of each VMs to the schedule 5 FOR EACH /*Create execution script for VMs*/ 6 FOR EACH Set of boundaries 7 Create execution script for VMs 8 END FOR Figure. Multiple Loop Decomposition Algorithm. From Fig., the calculation methods are as follows: 1) Calculate total task max loop min loop Total = + 1 steploop where Total is total number of task loop is or E or I or or loop max loop is maximum boundary of that loop min loop is minimum boundary of that loop step loop is incremental step of that loop ) Calculate number of tasks on each machine (1) T = Total / N (13) where T is number of tasks on each machine, and N is number of machine 3) Calculate remaining task R = Total% N (14) where R is number of task on each machine 4) Set the boundaries set to each VM: It will calculate only the min and max of loop, thus the min and max bounds of other loops are not changed. All VMs will be assigned the value of boundaries. min loop ; M = 0 min = max 1 + steploop ; M 0 (15) max = steploop ( T 1) + min (16) where M is machine number min is minimum boundary of loop on machine M max is maximum boundary of loop on machine M 5) Set the remaining task to VMs: It will calculate only the min and max of loop, thus the min and max bounds of other loops are not changed. Only VMs that has M < R will be assigned the value of boundaries. min = max 1 + step loop ; M < R (17) max = steploop ( T 1) + min ; M < R (18) V. EXERIMENTS AND RESULT In this section, we present the results of #VM (Number of VMs) prediction, which is a major part in automatic resource allocation mechanism. Two experiments were performed. The first experiment discusses the scalability of the parallel algorithm for parameter estimation in epidemic forecast when executed on the cloud environment. The second experiment shows the accuracy of the resources estimation prediction. The speedup and efficiency indicators are also discussed. 831

5 SC-BDA, Singapore, December 01 All experiments were performed on the private cloud of the Institute of High erformance Computing, Agency for Science, Technology and Research, Singapore (A*STAR IHC). The cloud s specification can be described as follows: the cloud consists of 4 physical machines, where each machine has hex-cores Intel Xeon rocessor X5650 (.66 GHz and 1 MB cache) with hyper-threading, 4 GB memory, TB of hard disk, and Intel 8574L Gigabit Ethernet. The resources of these machines are combined in the resource pool, called Host machine. The host machines employ CentOS 6. as the operating system and Xen [1] as the cloud hypervisor. In the resource pool, all virtual machines (VMs) are homogeneous. The guest domain or virtual machine operating system is Ubuntu There are types of virtual machine which are called general instance and shared instance. General instance has 1 GB virtual memory, 1 virtual CU core, and 8 GB storage block. This type of instance is created for the computation of parameter estimation. The maximum number of general instances that can be created is 48. The shared instance has more storage space than the general instance since it is the shared repository which stores input data, output data, executable files and execution scripts. This type of instance has 1 GB virtual memory, 1 virtual CU core, and 30 GB storage block. VMs are mounted on the shared repository using network file system (NFS). The directory paths of shared folders on all VMs are the same. Therefore, file transmissions between machines can be done by reading and writing files on the shared directory. The shared instance is also the master machine that controls the execution. Finally, complete content and organizational editing before formatting. lease take note of the following items when proofreading spelling and grammar: A. Scalability Analysis for SEIR-based arameter Estimation Algorithm This experiment is designed to observe the scalability of the parameter estimation module in epidemic forecast. The number of VMs used was between 1 and 48. Three sizes of input parameters that represent different levels of processing time were also used: small, medium and large. The experimental results are shown in TABLE I. From TABLE I., the processing time of parameter estimation with small, medium and large input sizes on a single machine were 583 seconds,,847 seconds, and 45,940 seconds, respectively. For the scalability result of a small input size, the speedup of 6.5 was observed when 48 machine cores were used. The efficiency of 55.1% was low. For a small problem size, there might not be enough work to keep all processors busy and thus the speed up dropped significantly from the ideal number. From the plot, the speedup started to tail off after 5 cores were deployed. Adding more processor after this point would not gain performance enhancement. For the medium and large input sizes, parallelization was able to boost up the execution speed for up to approximately 44 times when 48 cores were used. The efficiency was more than 90%. Moreover, the measured execution time was close to the ideal time, which indicated a small computational overhead. In conclusion, the results in this section show that the parallelization and VMs scheduling methods designed for our epidemic forecast model are efficient. TABLE I. ERFORMANCE OF ARAMETER ESTIMATION ON THE RIVATE CLOUD Small Input Size VM Execution time (s) Ideal Speedup Efficiency (%) Medium Input Size VM Execution time (s) Ideal Speedup Efficiency (%) 1,847 11,606 11, ,743 5, ,936, ,503 1, Large Input Size VM Execution time (s) Ideal Speedup Efficiency (%) 1 45,940 3,130, ,581 11, ,915 5, ,938, ,534 1, , B. Experiments and Results on rediction of Optimal Number of VMs In many cases, the execution of scientific applications has to be finished within a limited timeframe. Otherwise, the results may no longer be useful. In our prediction model, we allow the users to specify the time constraint for task completion and then the appropriate number of VMs is given as a result. The results from the prediction model are then compared with the actual numbers from the experiments. In the experiment, We have specified 3 values of the time constraint (T) for the epidemic forecast s parameter estimation, which were 1,500 seconds (about 30 minutes), 3,000 seconds (about 1 hours), and 1,600 seconds (6 hours). The prediction model was used to estimate the optimal number of VMs required for each experimental test case. The predicted number of VMs was then compared with the actual number of VMs required to satisfy the expected 83

6 SC-BDA, Singapore, December 01 execution time. The accuracy of the prediction was determined by using the percentage difference between the actual and the predictive numbers. In addition, the actual execution time was measured and presented in TABLE II. TABLE II. THE REDICTIVE RESULTS OF THE RESOURCE ESTIMATION MODEL T (s) Small Medium Large A Actual A Actual A Actual #VM a #VM b Time c #VM a #VM b Time c #VM a #VM b Time c 1, , ,534 3, , ,847 1, ,847 3,130 a. #VM is the predicted number of VMs, b. A#VM is the actual number of VMs, c. Actual Time is the actual execution time The prediction results of the optimal resource estimation model were shown in TABLE II. In a case of a small input size, using one VM is sufficient for all specified time constraints. The actual execution time was measured at 583 seconds on a single machine, which was smaller than the time constraints set in all cases. The number of required VMs calculated from our predictive model yield the result of 1, which is the same as the actual number of VM required in the actual execution. In a case of a medium input size, the predictive model also gave good results for all cases of the time constraints. The acceptable error rate of 1.5 % was observed when the time constraint was set to 1,500 and 3,000 seconds. In a case of a large input size, the observed prediction error was 6.67%, when the value of T was set at 1,500 seconds. We suspected that all the errors was caused by the availability of the machine in the experimental platform. When the time constraint was small and a large input size was needed to be computed, a large number of VMs were required to meet the constraint. We ran our experiment on a non-dedicated platform and when a large number of processing cores were required, some cores may be partially utilized by other software during our experiments causing the discrepancy. When the time constraint was set at a more reasonable number, our predictive model was rather accurate. With a good accuracy, we believe that our predictive model and resource estimation framework can be utilized by most scientific applications. The scientist can follow our framework to form an estimation model. The model can then be used to predict the number of required VMs that will deliver the result within the specified time constraint. The execution time and appropriate number VMs can also be estimated for a larger input size than those in the actual experiments. The estimation model will especially be useful when a public cloud with an excessive number of resources is utilized. For example, if the expected execution time is set at 0 seconds, the predictive model may estimate that over 70 machines will be required. The users may then purchase enough computing time from the public cloud to meet the requirement. Moreover, our prediction framework can also predict the execution time, given the input parameters and the number of VMs used. The information on estimated execution time can be used for VMs purchasing decision. For example, in a case where a user has a budget to purchase 75 VMs on a public cloud, the estimated execution time of around 759 seconds can be given by our model. VI. CONCLUSION In this paper, we have presented the automaic machanism for allocating the optimal number of VMs for applciations in the cloud. The mechanism includes resource estimation and workload scheduling. Our proposed procedure aims at speeding up the execution time for scientific applciations. The experimental results show that the execution performance of the parameter estimation step in epidemic forecast is scalable. The speedup gained on the cloud is also significantly improved, while the efficiency is acceptable. Moreover, the accuracy of the resource estimation model is high implying that the model can be used to predict the optimal resources effectively. In addition, our mechanism can be adopted to other scientific applications. The developers can follow our framework in deriving the applciation complexity and the prediction models. Using our method, the high prediction accuracy can be achieved in any specific applciations. REFERENCES [1]. Mell, and T. Grance, The NIST definition of cloud computing, Computer security division, National Institute of Standards and Technology, September 011. [] R. Buyya, C. S. Yeo, S. Venugopal, J. Broberg and I. Brandic, Cloud computing and emerging IT platforms: vision, hype, and reality for delivering computing as the 5th utility, in Future Generation Computer Systems, vol. 5, issue 6, pp , June 009. [3] S. Ostermann, R. rodan, and T. Fahringer, Extending grids with cloud resource management for scientific computing, IEEE/ACM International Conference on Grid Computing, 009. [4] Y. O. Yazir, C. Matthews, and R. Farahbod, Dynamic resource allocation in computing clouds using distributed multiple criteria decision analysis, IEEE 3rd International Conference on Cloud Computing, 010. [5] W. Lin, G. Lin, and H. Wei, Dynamic auction mechanism for cloud resource allocation, IEEE/ACM 10th International Conference on Cluster, Cloud and Grid Computing, 010. [6] F. Chang, J. Ren, and R. Viswanathan, Optimal Resource Allocation in Cloud, IEEE 3rd International Conference on Cloud Computing, 010. [7] O. Bjørnstad, 005, SEIR model, Retrieved from [8]. Sukcharoen, S. umma, O. Mongkolsermporn, T. Achalakul, and L. Xiaorong, Design and analysis of a cloud-based epidemic simulation framework, IEEE 9th International Conference on Electrical Engineering / Electronics, Computer, Telecommunications and Information Technology (ECTI-CON 01), pp. 1-4, May 01. [9] S. Arora, and B. Barak, Computational complexity: A modern approach, Cambridge University press, 009. [10] B. Noble, and J. W. Daniel, Applied linear algebra, 3rd ed., renticehall, Englewood cliffs, NJ, [11] D. C. Montgomery, Design and analysis of experiments, International version, 7th ed., Wiley, 008. [1] D. Chisnall, The definitive guide to the Xen hypervisor. rentice Hall International,