Real-time scheduling for virtual machines in SK Telecom

Size: px

Start display at page:

Download "Real-time scheduling for virtual machines in SK Telecom"

Amy Singleton
6 years ago
Views:

1 Real-time scheduling for virtual machines in SK Telecom Eunkyu Byun Cloud Computing Lab., SK Telecom Sponsored by: & &

2 Cloud by Virtualization in SKT Provide virtualized ICT infra to customers like Amazon EC2 from SKT s cloud resource pool exploiting server virtualization Resources : Servers/PC, Network, Storage, Functionalities : load balancing, security solution, back-up, Private cloud inside SKT virtualized servers, virtualized I/O Migrate IT services on legacy servers to virtualized servers Provide employees with PaaS for software development Virtual desktop infrastructure for employees

3 Cloud as Telecommunication Operator SK Telecom is a Telecommunication operator as well as a Cloud service provider One Common Cloud Computing Infrastructure Legacy Network/Telecom Services on dedicated/reliable equipments Virtual Telco General-purpose Server farms for Cloud Hosting based on virtualization technique Advantage - Scale dynamically with demand - High utilization - Easy start-up of new services Requirements 1. Guaranteeing time readiness 2. Scalability of services 3. Cost-effective secure storage

4 Case Study Virtual Telco. IMS (IP multimedia subsystems) on Cloud Delivering IP multimedia services (VoIP, VOD, Instance Message, ) requiring session initiation between participants on Internet to users connected to wireless telecom networks Launch easily Internet services on wireless network/telecom infra Application Service Session Management IP network Media Processing User Info. Database SIP Migrate servers for components into Cloud require high reliability

5 Challenges 1. Guaranteeing time readiness 2. Scalability of services 3. Cost-effective secure storage Which virtualization technique, i.e., hypervisor, is most suitable for supporting real-time VM? We choose. Xen Hypervisor best in responsiveness benchmark, open source Credit scheduler default in Xen 4.1, known to be stable Second option : Credit 2 scheduler

6 Limitation of credit scheduler (sec) 60 CPU usage(sec) Media Player VM Contention between 6 CPU-intensive VMs(weight = 256) and 1 Media player VM Real-time VM can not occupy the proper amount of CPU even though with very high weight CPU intensive VM makes use of the residual credits of non CPU-intensive (i.e. media player) VM s credits 10 0 Need improvement!! (weight)

7 Research Goal Find improved soft real-time schedulers based on stable credit scheduler Fair CPU sharing each VM occupies CPU (almost) exactly proportional to its weight + work-conserving Real-time support fast responsiveness of real-time VMs Modify credit scheduler to distinguish realtime VM and non-realtime VM Realtime VMs are marked externally and treated specially to provide fast responsiveness Co-work with

all given credits or are blocked Run Queue CPU 0 VCPU 4 VCPU 2 VCPU 7 VCPU 1 VCPU 0 VCPU 5 :

8 Preempt based scheduling BOOST > RT > UNDER > OVER Idea - Realtime VM s VCPU is inserted to the runq of a physical cpu at right after BOOST priority Non-realtime VMs can run when RT VMs consume all given credits or are blocked Run Queue CPU 0 VCPU 4 VCPU 2 VCPU 7 VCPU 1 VCPU 0 VCPU 5 : Under Priority : Over Priority : Boost Priority : RT Priority VCPU 3 VCPU 6 VCPU 8 New Job to Schedule

9 BOOST based scheduling (Min Lee, VEE 10 ) In the credit scheduler, VMs can get the highest priority (BOOST) when they receives events if they were blocked However, VMs in runq is not boosted BOOST realtime VMs always they receives external event even they are in already in runq Run Queue CPU 0 VCPU 4 VCPU 2 VCPU 7 VCPU 1 VCPU 0 VCPU 5 : Under Priority : Over Priority : Boost Priority : RT Priority External Event

10 Multi BOOST (by Korea Univ. at XenSummit, Aug, 2011) Multiple BOOSTs at the same time Driver domain and realtime VM cannot always get the highest priority DRIVER_BOOST > RT_BOOST > BOOST > RT > UNDER > OVER Run Queue CPU 0 VCPU 2 VCPU 7 VCPU 1 VCPU 0 VCPU 5 : Under Priority : Over Priority : Boost Priority VCPU 3 VCPU 6 VCPU 8 : RT Priority External Event!

Performance Evaluation VM1 (micro bench) V3

(micro bench) V3 PCPU 2 V2 V4 VM6 (micro

PCPU 4 V2 V4 RT VM (media player) PCPU 5

priority - repeat CPU-intensive computing

11 Performance Evaluation VM1 (micro bench) V3 V2 V4 VM5 (micro bench) V3 PCPU 1 V2 V4 VM2 (micro bench) V3 PCPU 2 V2 V4 VM6 (micro bench) V3 PCPU 3 V2 V4 VM3 (micro bench) V3 PCPU 4 V2 V4 RT VM (media player) PCPU 5 VM4 (micro bench) V3 PCPU 6 V2 V4 CPU Memory NET Physical server spec. AMD Phenom II X6 1055T (6 cores) 16GB Xen VM Gigabit Ethernet VCPU:4, MEM:1GB XenHypervisor Micro bench - Not set as RT priority - repeat CPU-intensive computing during random time and sleep for random time - above 98% CPU usage

CPU, Network Usages CPU usage(sec) NET usage(mb) 60 50 51.96 51.52 500 450 400 465.17 421.

12 CPU, Network Usages CPU usage(sec) NET usage(mb)

Fairness CPU sharing according to Weight 400 350 300 250 200 150 100 50 RT VM runs CPU-intensive process fully utilizing CPU 0 50.77 50.64 44.71 36.67 28.44 28.52 36.67 50.8 50.84 44.73 28.51 36.

13 Fairness CPU sharing according to Weight RT VM runs CPU-intensive process fully utilizing CPU unmodified RT VM1 VM2 VM3 VM4 VM5 VM6 weight(256)+preemption +boost+multiboost weight(512)+preemption +boost+multiboost weight(1024)+preemption +boost+multiboost weight(2048)+preemption +boost+multiboost CPU usages are proportional to weight value Fair between RTVM and no-rtvm with equal weight

Work-conserving (sec) 400 350 300 250 200 150 100 50 0 Upper bound for media player 65.951 51.958 Media Dom0 VM1 VM2 VM3 VM4 VM5 VM6 78.79% 358.661 358.645 358.791 358.97 358.098 57.314 53.689 52.

55% 52.338 53.741 14.99% 52.152 14.54% 52.381 53.699 53.712 14.98% 14.98% 52.113 14.53% 52.35 52.258 14.57% 52.377 8.81% 11.07% 31.582 39.698 39.

14 Work-conserving (sec) Upper bound for media player Media Dom0 VM1 VM2 VM3 VM4 VM5 VM % % 14.97% 14.53% 14.57% % 14.94% 14.56% 14.59% % 15.94% 15.98% 15.93% 3.43% % % % % % 14.98% % % % 11.07% no_contention unomdified weight weight+preemption weight+preemption +boost Weight for VM1~VM6 (non realtime VM) : 256 Weight for Media player VM( realtime VM) : % 14.6% 14.59% 14.6% 10.93% % 13.85% 13.85% 13.85% 13.85% 13.86% 14.39% weight+preemption +boost+multiboost

Responsiveness Test environment VM5 (micro bench) V3 V2

bench) VM3 (micro bench) VM4 (micro bench) External

15 Responsiveness Test environment VM5 (micro bench) V3 V2 V4 VM6 (micro bench) V3 V2 V4 RT VM (ping target) ping request (per 0.01sec, counts) VM1 (micro bench) VM2 (micro bench) VM3 (micro bench) VM4 (micro bench) External server V2 V2 V2 V2 V3 V4 V3 V4 V3 V4 V3 V4 CPU RAM Physical server spec. AMD Phenom II X6 1055T (6 cores) 16GB PCPU 1 PCPU 2 PCPU 3 PCPU 4 Xen Hypervisor PCPU 5 PCPU 6 NET Gigabit Ethernet Xen VM VCPU:4, MEM:1GB

16 Responsiveness (Ping RTT, Credit) The cumulative distribution of ping RTT as the number of simultaneous CPUintensive VMs increases (cumulative distribution) 1 no_contention contention_vm1 contention_vm2 contention_vm3 contention_vm4 contention_vm5 contention_vm (ping RTT, ms) All pings take only 0.5ms without contention 20% of ping takes longer than 10 ms when 7 VMs run simultaneously

17 Responsiveness (Ping RTT, modified) (cumulative distribution) no_contention contention_vm6 contention_vm6 contention_vm6 contention_vm6 +preempt contention_vm6 +rtboost +multiboost preempt+multiboost After applying our modification, all pings take only 0.5ms even with contention weight of realtime VM = 256 weight of non-realtime VM = 256 (ping RTT, ms)

18 What about Credit2 scheduler? (sec) CPU usage(sec) Media Player VM VM burn credits based on their weight Higher weight means credits burn more slowly VCPUs are inserted into the runq by credit order VM with more credits runs first Credits are reset when the next vcpu in the runqueue is less than or equal to zero 0 Achieve both fairness and work-conserving (weight)

19 Responsiveness of Credit 2 scheduler (cumulative distribution) 1 weight(256) weight(512) weight(768) weight(1024) weight(1536) weight(2048) (ping RTT, ms) For fast responsiveness, VM needs higher weight. If we want to divide CPU cycle equally between VMs? Using special policy for realtime VM is necessary.

20 Ongoing Research What if there are several realtime VMs competing limited physical server/core? Prediction based scheduling between real-time VMs Load balancing between physical cores Efficient placement policy of RTVMs between physical servers Load balancing between physical servers using live migration of VMs

21 Summary SK telecom is trying to operate Telco services on cloud resources Realtime support in hypervisor is essential Analyzed the performance of modifications of Credit scheduler of Xen hypervisor For one realtime VM per physical core, fair sharing and fast responsiveness Plan to improve for more complex and practical cases

22 Thank you Contact:

23 Comparison of hypervisers Evaluation environment Physical server : Dell R410 (Xeon 8 cores, 16GB Memory) Virtual Machine : 1 Core, 1 GB Memory, 20GB HDD Increase the number of VMs running benchmarks Benchmarks : PCMARK 2005, kernel compile, SPEC-CPU 2006 A real-time application measure the delay of the timer interrupt handling in OS of VM Measure every 5 sec. for ten minutes

24 KVM

25 Vmware ESX 4.1

26 Xen 4.0 Xen is the best one, but not sufficient Contention of non real-time VMs affects the responsiveness of real-time VM

27 Approach VM scheduler in the hypervisor is important Credit scheduler Stable (default scheduler in Xen hypervisor 4.0), SMP support Need improvement for latency-sensitive VM Credit 2 scheduler Proportional sharing according to weight of each VM Provide responsiveness to VMs with larger weights Not so stable yet, need more analysis

Supporting Soft Real-Time Tasks in the Xen Hypervisor

Supporting Soft Real-Time Tasks in the Xen Hypervisor Min Lee 1, A. S. Krishnakumar 2, P. Krishnan 2, Navjot Singh 2, Shalini Yajnik 2 1 Georgia Institute of Technology Atlanta, GA, USA minlee@cc.gatech.edu