Black-box and Gray-box Strategies for Virtual Machine Migration

Transcription

1 Full Review On the paper Black-box and Gray-box Strategies for Virtual Machine Migration (Time required: 7 hours) By Nikhil Ramteke Sr. No

2 1. Introduction Migration is transparent to application and all modern VM supports it. Currently migration is handled manually. Migration may require other VM to shuffle for load balance. While load balancing CPU, N/W & memory issue arise. Paper deals with black-box and gray-box strategies. Technique include Monitoring system resource usage, Hotspot detection, Determine new mapping, Initiate necessary migration. Black-box monitoring : Observes each VM from outside Gray-box monitoring: Observes OS- level statistics. Sandpiper can support either Black-box or Gray-box or both simultaneously using following 2 algorithms Hotspot detection algorithm: when to migrate, Hotspot migration algorithm: what, where to migrate + how much resource allocation is to be done at new location. 2. Background and System Overview Current provisioning allocates more or less CPU s according to need but don t move VM s practically. If VM is moved, application won t know it, so its better option rather to move application. Sandpiper: tool which moves VM s across servers in data-center depending on resource usages of CPU, N/W interface and disk/memory. Top-down Architecture of Sandpiper Physical Machine (PM) Virtual Machine Monitor (VMM) VM s with special component called nucleus which runs in special VM called DOM-0

3 Nucleus gathers information about statistics over each server using monitoring engine. It delivers this information to Sandpiper control panel (SCP) SCP collets information from all VM s on each PM, and checks the resources usage if crossing some threshold value. IF so, then it computes what to move, where to move and then how much resources should be granted to move VM, and if all condition satisfies, it moves VM to another feasible location. 3. Monitoring and Profiling in Sandpiper Unobtrusive Black-box Monitoring Monitoring engine in nucleus periodically reports to SCP with resource usage statistics. Either hypervisor or DOM-0 can act as IO monitor and can thus collect the statistics and CPU usage can be tackled by observing the CPU scheduling movements by using XenMon. Domain-0 overhead is distributed on all rest of the VM s equally. Domain-0 has N/W interface driver of Xen. Other domain attaches to driver through VFR and then monitoring engine can measure the N/W usage. Memory utilization is known to OS within each VM. Shadow page table is used for getting this info but it causes lots of overhead. Alternative can be to use swap activity observation, i.e. measure memory usage by read/write statistics. Gray-box Monitoring Black-box strategy can t move inside the VM to gather the statistics. Gray-box monitoring implements a daemon process which moves into the VM and collects the statistics through logs, DB servers etc, and thus can detect SLA violation easily.

4 Profile Generation Profile engine receives information; compute usage profile for each VM & PM, then maintains the history of it. Black-box: maintains profile of CPU utilization, N/W bandwidth and swap rate. Gray-box: maintains profile of memory utilization, service time, required drop rate and incoming request rate. Profile contains the distribution of usage of resources. This profile is used for futures resource requirements and for decisions of migration of VM s. The time-series profile is abstraction of the profile mentioned above and is used for hotspot detection. 4. Hotspot Detection Hotspot detection algorithm makes decision to migrate VM or not. If some threshold value is crossed, this algorithm is invoked. Black-box works per-pm and Gray-box works per-vm. Algorithm is invoked on at least k+1 out of n violations of threshold. (Threshold) α (1/ migration) α (server utilization) Time-series is used to predict the future values. 5. Resource Provisioning Before migration, resources availability is checked. Black-box provisioning CPU and N/W bandwidth values are predicted by observing the trailing values over certain time window. VM can get more to what it has been allocated only if other VMs are underutilized. (Not applicable to memory issue.) If all VM s are fully utilized, VM that is expecting more has to be satisfy with its own shear fully, and this statistics can be further used for future value prediction by adding some +Δ value to original shear.

5 Gray-box Provisioning It uses information in the logs to estimate peak uses. Peak can be measured even if resource is being fully utilized. Incoming requests= serviced request + dropped request. Let w-cpu weight given to VM, then weight w = + λpeak λpeak, >1 =, h N/W usage= peak arrival rate X required file size. 6. Hotspot Migration Migration algorithm determines new allocation/mapping (NP-hard) and migration mechanism is applied iteratively, It requires N/W bandwidth and thus affects the performance. Capturing multidimensional loads Overall load of VM = volume Migration Phase PM s and VM s are ordered a/c to volume. While(utilization of all resources of PM < threshold) { For all VM s Check if any server has sufficient volume to accommodate it If (yes) move it Else move to next VM (current VM requirement can t be satisfied) } Swap If migration fails, its alternative While(hotspot is resolved or all VM s are visited) { -Consider the highest loaded VM

6 -Consider the lowest loaded server and consider k VM s on it such that after their migration server lefts behind with sufficient volume to accommodate highest loaded VM. -swap the k VM s and highest loaded VM. } 7. Implementation and Evaluation Black-box monitoring requires access to Dom-0 Gray box has 2 components A Linux OS daemon (runs on Each VM) Apache daemon (log analyzer + Dispatcher) Migration Effectiveness Due to move of highest loaded VM, while data transfer, transfer load is maximized. Virtual Machine Swaps If there is high average utilization, migration chances increases due to swap with penalty of more overhead. Mixed Resource Workload Takes care of each resource hotspot individually and resolves the hotspot. Gray v. Black: Memory Allocation Black-box can directly measure memory usage, while Gray-box has that capability and thus can detect memory over provisioning which in turns reduces the swapping. Gray v. Black: Apache Performance Black box don t have good statistics to fulfill the resources needs, while Gray-box has application level access and thus can better understand the needs, and it helps to improve the migration decision. Prototype Data Center Evaluation Sandpiper can deal with multiple hotspots together, overloaded servers are processed during migration phase also.

7 System Overhead and Scalability CPU and IO overhead of tool: negligible. Time for placement algorithm- increases with increase in number of VM s, distributed computation is suggested as solution. Stability during Overhead If half of the servers are overloaded, hotspots can be resolved with one migration per machine, otherwise swaps are required and can be managed till certain extent, after which Sandpiper quits resolving. Tuning Sandpiper Setting Threshold: If threshold is kept high, then migration overhead may violate SLA. (75% for CPU and N/W is suggested) Sustained Overload Requirement: Sandpiper doesn t have choices for different measurement interval, and committed unsurely about Δ factor. 8. Related work Background of Migration. Comparison of Sandpiper with Dedicated hosting and Shared hosting. 9. Conclusion: Migration is good solution to enhance the performance of virtualization Black-box: can deal with simultaneous hotspot which can come in package of multiple hotspots. Gray-box: increases the responsiveness of Sandpiper. Sandpiper: good establishment with nice mechanisms. Little more work with uncertainty of some parameters can take tool at very high level.

8 Further research: Xen is yet to implement a fair-scheduler. Can it be Solution? : Why don t we start will all CPU s giving 0 weight and then scale upwards as needed? Of course there will be higher limit on the server threshold, in case, some higher priority server feels to get CPU and getting less than its peak weight, other CPU processes which are over utilizing can be then shifted to new place or rescheduled. It will save time for checking the boundaries of other CPU every time while asking for more. We need to schedule only when overall CPU usage is at peak. So there is no need of computing and observing time slice frequently which may save lots of overhead. Swapping deals with 2 servers only, can be extended with multiple servers. Work is going on with automatic determination of whether to migrate VM or to replicate it for more resource generation. Limitation: Sandpiper works only on Xen architecture. Sandpiper works only for FIFO virtual machine monitor. While migration swap phase can t consider more than 2-servers. Suggestions: All storage is assumed to be on N/W file system, thereby eliminating need to move disk state during VM migration. Comment: Can it really be entertained? Doesn t it try to skip count of overhead caused due to it? Do we really need to give the separate VM for nucleus? Can t it be managed with some application to be hosted on some low overhead sever? Anyway the CPU and IO load results are negligible, so won t affect much in fully overloaded situation.

9 I didn t understand Explanation of 7.6 Fig. 5 I didn t like: Xen allocates USER SPECIFIED memory to each VM and requires the OS within VM to manage that memory. Spelling mistake on 5 th page, 1 st column, 2 nd row, back-box black-box Fig.3 is not clear with X, Y parameters. Explanation of last 2 paragraphs in point 8. I like: Rest all things.