300 likes | 474 Views
VirtualPower : Coordinated Power Management in Virtualized Enterprise Systems. For seminar. Hyunsik Choi Distributed Computing & Communication Lab. (URL: http://dcclab.sogang.ac.kr) Dept. of Computer Science Sogang University Seoul, Korea Tel : +82-2-3273-8783
E N D
VirtualPower : Coordinated Power Management in Virtualized Enterprise Systems For seminar Hyunsik Choi Distributed Computing & Communication Lab. (URL: http://dcclab.sogang.ac.kr) Dept. of Computer Science Sogang University Seoul, Korea Tel : +82-2-3273-8783 Email : hschoi@sogang.ac.kr
Contents • Introduction • Managing Virtualized Systems • VirtualPower Architecture • Evaluation Methodology • Policy Based Coordination • Conclusion and Future Works
Introduction • Needs for Power Management • Power delivery and cooling limitations in datacenter environment • Cost of power and cooling capabilities in datacenter
Introduction • Aspect of future datacenter environment • Proliferation of virtualization techniques into the enterprise domain • Interplay of power management and virtualization (continue) • Soft and Hard power scaling • Independence and Coordination • Flexibility in management
Introduction • Soft and Hard power scaling (continued) • Soft power scaling • Hypervisor’s ability to limit hardware usage by guest VM • Hard power scaling • Hardware support such as processor frequency scaling • To be effective, virtualization layer power management must exploit both of these methods. • VPM states to ensure that each guest VM runs its own independent power management method
Introduction • Independence and Coordination (continued) • Independence of each guest VM operating system and application • Possible to integrated them, if they can meet application requirements • A necessary element of power management is the need to coordinate between VM-level solutions and global goals that concern platform-, rack-, and then datacenter-level power consumption. • VPM channels to deliver VM power management actions
Introduction • Flexibility in management (continued) • Multiple generations of equipment with different attributes and management capabilities • Various applications that have distinct requirements expressed by Service Level Agreements (SLAs). • Needs for dynamic power management policies • To effectively address virtualized environments, it is important to give administrators the flexibility to provide their own power management policies. • VPM rules to make actual power management decisions • VPM mechanisms to provide basis of heterogeneous platform power management
Managing Virtualized Systems • Impact of virtualization on the power management landscape of enterprise systems • Obstacles and solutions dealing with virtualization (Continue) • Scalable enterprise environments • Leveraging guest VM policies • Limitations of hardware management
Managing Virtualized Systems • Scalable enterprise environments (Continued) • Disassociation between the virtual resources and physical ones • Increased heterogeneity due to the platform update operations • VM power management policies cannot deal with such changes. • Soft VPM state to have consistent view of hardware resources so that maintain independence and isolation properties
Managing Virtualized Systems • Leveraging guest VM policies (Continued) • Direct access of VM level policies to physical resources • Negates the notion of virtualized hardware resources • Threatens performance isolation properties • Might be malicious • Use the VM level policies as hints rather than executable command. • The hints are updated to the VPM channels through ACPI interface, and then the VPM rules would reflect the hints to the actual power management decision.
Managing Virtualized Systems • Limitations of hardware management (Continue) • Resource sharing problem • Time domain multiplexing which sets components to the hardware states • Needed to be done quickly • Might be malicious in multi-core platform • A set of VPM mechanisms for VPM rules that exploit both soft and hard power scaling techniques.
VirtualPower Architecture • Organization of a physical machine
VirtualPower Architecture • Organization of two physical machines
VirtualPower Architecture • General view • Domain 0 : accommodates most of its functionality • VPM mechanisms, VPM rules • To access hardware resource information easily • To take advantage of control plane functionality such as VM creation and migration • Hypervisor : accommodates monitoring functionality • VPM channels • VM level : accommodates VM power management policy • VPM states
VirtualPower Architecture • VPM states • Power management policies of guest VMs. • VPM is designed to permit guest VM polices to run in both power manageable or non-manageable systems. • Each VM in VPM system has soft VPM states. • Include set of performance state. • Used by VPM rules and mechanisms to apply current state to policy decision. • Available in heterogeneous environment.
VirtualPower Architecture • VPM channels • Bridges which deliver soft VPM states update to VPM rules. • VPM rules re-package them as VPM events including timestamp, soft VPM states, and actual performance states of resources. • VPM events is available to the VPM rules in Domain 0. • Implemented via hypercalls and Xen event channel.
VirtualPower Architecture • VPM mechanisms • Base level for online power management by VPM rules • Mechanisms supported by VPM (Continued) • Hardware scaling • Soft scaling • Consolidation • Hardware scaling • Varies across different platform and device architectures. • Depends on VM-level resource sharing • A VPM mechanism permits VPM rules to set the hardware states to be used during the execution of a particular guest.
VirtualPower Architecture • Soft scaling (continued) • Hardware scaling is not always possible with smaller benefits. • Resource scheduling. • Needs to modify the hypervisor’s scheduling attribute. • Results in substantial power benefits. • Possible to idle power management • Adjusts time slice allotted virtual CPU. • Issue : What is going to happen, if a VM requests a reduced processor frequency, because it expects to observe little of no performance degradation for its current memory-bound application workload? • Expected CPU allocation and performance loss. • Works with feedback loops based on state-based guidance.
VirtualPower Architecture • Consolidation (continued) • Resource sharing is possible, due to the soft scaling capability and managing independence. • In multiple resources environment, it is possible to consolidate allocations into specific resources with other resources to be idle. • Substantial power benefits would be derived. • There likely exist physical resources that are more power efficient for certain workloads in datacenter environment. • By combining soft scaling with VM re-mapping, it is possible to map virtual resources to efficient physical resources.
Evaluation Methodology • Experimental setup • Test bed • Identical dual core Pentium 4 machines • Inter Netburst microarchitecture • 3GB memory • Gigabit network cards • 80GB hard disk drive • Power data • Obtained from Extech 380801 power analyzer • Sampling rate : 2Hz
Policy Based Coordination • Hierarchical power management policies • local policy(PM-L) • global coordination policy(PM-G) • PM-L Policies : Platform Management • Goal • Minimizing power consumption while maintaining desired performance of application • Throttling power consumption for certain period time, due to thermal events or transient power delivery issues • Managing through planning based on monitoring historical trends in power management request behavior
Policy Based Coordination • PM-L Policies : Platform Management • Minimizing power in the presence of QoS constraints • Power trace of transactional application • Power drop : normal case • Power oscillation : adjustment from the feedback after power management request
Policy Based Coordination • PM-L Policies : Platform Management • Minimizing power in the presence of QoS constraints • RUBiS experimental result • Performance drop & power saving when using PM-L policy • Not much power saving compared to performance drop due to the on-demand governor used by RUBiS VM
Policy Based Coordination • PM-L Policies : Platform Management • Power Throttling with VPM mechanisms • Transactional workload management • When single dual core platform executing two transactional VMs • Significant power reduction when both VMs are set to VPM state 4 • VPM state 4 : A VM allocate the lowest frequency of its processor.
Policy Based Coordination • PM-L Policies : Platform Management • Power Throttling with VPM mechanisms • RUBiS management • Performance drop & power saving when using PM-L policy • From the figures described in this slide and previous slide, the need to utilize both hard and soft scaling can be highlighted again.
Policy Based Coordination • PM-L Policies : Platform Management • VirtualPower enabled power planning • Power tradeoffs of a planning policy • When a large batch job arrives after 700 seconds • No plan • sudden power increase which may exceed desired throttling point • Plan based on predicted behavior • Provide additional performance before the job arrives • Planning makes it possible to manage throttling point.
Policy Based Coordination • PM-G Policies : Global coordination • Soft scale-enabled consolidation • Consolidation with sleep states • When VMs are consolidated on a PM, power consumption is reduced.
Policy Based Coordination • PM-G Policies : Global coordination • Exploiting heterogeneity in power management • Power management heterogeneity • When there are some machines that support hardware scaling, while others do not • With varying processing rate, the benefits of hardware scaling support can be observed from the graph.
Policy Based Coordination • PM-G Policies : Global coordination • Resource heterogeneity exploitation with VPM states • Consolidation with heterogeneity • Migration can be operated to find an efficient hardware resource. • Through the chain of migration, VM may find better PM. • After finding better resource, VM would request reduced performance states. • Test bed • Two Pentium physical machines • Four VMs
Conclusion and Future Works • Power management in virtualized systems • Transparently leverage existing application policies • Deal with heterogeneity in hardware / manageability • Maintain isolation and independence • Obtain power savings with VM resource sharing • Future Works • Distributed power throttling – VPM tokens • Idle power management – additional VPM C-states • Efficient soft scale consolidation – hardware extension