Efficient Application Placement in a Dynamic Hosting Platform

1
Efficient Application Placement in a Dynamic
Hosting Platform

• Zakaria Al-Qudah CWRU
• Hussein Alzoubi CWRU
• Mark Allman ICSI
• Michael Rabinovich CWRU
• Vincenzo Liberatore - CWRU

2
Target Environment Dynamic Hosting

• General components
• App servers
• Local controllers
• Central controller
• Request router
• Measurement modules

3
Our Problem Enactment of resource allocation
decisions

• Starting applications is slow and
  resource-intensive
• Causes loss in system responsiveness
• Limits flexibility of resource allocation

4
Option 1 Run Everywhere

• Run an instance of every application on every
  machine
• Send requests only to those intended to be active
• Intuition idle application instances should not
  consume resources

5
Run-Everywhere Results

• Conclusion Run-everywhere is impractical

6
Option 2 Explicit Suspend/Resume

• What was the problem of run-everywhere?
• OS couldnt tell active applications from idle
  ones due to the periodic application maintenance
• Solution explicitly convey this information to
  the OS
• Suspend idle applications with SIGSTOP
• Resume to activate with SIGCONT

7
Still inefficiencies
Much better!

• On-demand page-in
• OS brings a page to memory only when its
  referenced ? context switching
• On-demand page-out
• Full memory at the time of page-in ? resumption
  waits for page-out
• On-demand eviction of memory pages to disk
• Piecemeal eviction ? process state spreads over
  many disjoined locations on disk

8
Enhanced Suspend/Resume

• Bring all the process pages at once from disk to
  memory (prefetching)
• Whenever an application is suspended, evict it
  out of memory at once (pre-purging)
• This keeps process state in few contiguous places
  on disk

Prefetching/prepurging ancient swapping!
but only for application placement
9
Performance Evaluation Startup time
10
Performance Evaluation Resource consumption
11
Prefetching overhead
12
Performance Evaluation Contributing factors
13
End-to-end responsiveness Experiment setup
14
End-to-end responsiveness - results
15
End-to-end responsiveness (contd)
16
Limitations of Suspend-Resume

• Consequences of bad programming practices are
  more pronounced
• Less useful for clustered applications
• Re-joining the cluster takes long time
  (regardless of how applications are started)

17
Future work Virtualization

• Various technologies
• OS-level (e.g., OpenVZ)
• Hardware-level (e.g., VMware)
• Vary in performance overhead and offered features
  (arguably!)
• Degree of performance/fault/security isolation
• Ability to run heterogeneous OSes on the same
  hardware
• Similar suspend-resume issues might apply
• Bulk prepurging
• Bulk prefetching

18
Summary

• Most existing work on dynamic hosting focuses on
  resource allocation decisions
• We focus on efficient enactment of these
  decisions
• Examined several alternatives for application
  placement
• Deployment from scratch
• Run-everywhere
• Suspend-resume
• Enhanced suspend-resume
• Swapping for application placement
• Normal paging for active tasks
• Enhanced suspend-resume is significantly more
  efficient