efficient application placement in a dynamic hosting platform

29
Ef cient Application Placement in a Dynamic Hosting Platform Zakaria Al-Qudah, Hussein A. Alzoubi, Mark Allman, Michael Rabinovich, Vincenzo Liberatore Case Western Reserve University Proceedings of the 18th international conference on World wide web 1

Upload: sian

Post on 25-Feb-2016

64 views

Category:

Documents


2 download

DESCRIPTION

Efficient Application Placement in a Dynamic Hosting Platform. Zakaria Al- Qudah , Hussein A. Alzoubi , Mark Allman, Michael Rabinovich , Vincenzo Liberatore Case Western Reserve University Proceedings of the 18th international conference on World wide web . Outline. Introduction - PowerPoint PPT Presentation

TRANSCRIPT

Efcient Application Placement in a Dynamic Hosting Platform

Efcient Application Placement in a Dynamic HostingPlatformZakaria Al-Qudah, Hussein A. Alzoubi, Mark Allman, Michael Rabinovich, Vincenzo Liberatore

Case Western Reserve University

Proceedings of the 18th international conference on World wide web 1OutlineIntroductionMotivationArchitecture overviewPlacement MechanismsExperimentsRelated workFuture work and conclusionComments

2IntroductionWeb hosting has become a $4Billion industry [27] and a crucial part of Web infrastructure.The current prevalent practice:Allocating (or providing facilities for) xed amounts of resources to customers.However, in the near future:Dynamic hosting.A hosting platform maintains a shared pool of resources.Reassigns these resources among applications to absorb demand spikes for dierent applications at dierent time. Advantages:Better resource utilizationLower cost through the economy of scale.3[27] Yankee groups SMB survey suite oers the most comprehensive view of the SMB market. CRM Today. http://www.crm2day.com/content/t6_librarynews_1.php?news_id=116800, 2005.Approach to implement dynamic hostingMost research work of dynamic hosting focus on:Application placement algorithm:Dynamic placement of a variable number of application instances on physical servers.Decide on the number and location of the application instances.This paper focused on:An ecient way to enact these decisions once they are made.The agility of hosting platformE.g. in the case of a ash crowd if the platform decides to add more resources to an overloaded application, we would like this decision to be enacted as fast as possible.The authors call it orthogonal question.4MotivationMotivation:Application placement takes in the order of minutes and, as we show, is resource intensive.Minimize the rate of application placements to reduce their eects?Goal:Reduces dramatically these costs.Enable a new class of more agile application placement algorithms.5Architecture Overview(1)Targeting web application:Three-tier applications: Web tier, an application tier, and the back-end database tierResource allocation methods in shared hosting platform:One physical machine Only one applicationCentral controller may switch a machine from one application to another.One physical machine Many applicationsShare resource at the level of OS processes.Running each application instance inside its own virtual environment and sharing physical machines.Basic execution unit:Application server(e.g. an Apache instance).Abbr. : AppServ or Application6 We believe our techniques should also be useful in virtualized environments and plan to explore them in this context in the future.6Architecture Overview(2)7

Placement MechanismsIntroduce and compare many placement mechanisms including the new one the author proposed8Placement Mechanisms(1)Regular StartupRegular Startup:This motivates our search for more ecient application placement techniques.Mechanism:Pre-deploy all applications everywhere, and simply start and stop AppServ instances as needed.Disadvantage:High startup timeHigh resource consumption9Placement Mechanisms(2)Run-EverywhereRun-Everywhere:A straightforward alternative to regular startupMechanism:Run an instance of every application on every available server machine.Simply direct requests to application instances designated to be active.Disadvantage:Overhead:OS cannot distinguish active and idle application.E.g. AppServ performing regular housekeeping that makes them appear active to the OS.10Placement Mechanisms(3)Suspend/ResumeSuspend/Resume:Improve from Run-everywhereMechanism:Allowing the platform to explicitly indicate which AppServs should be active/idle.The local controller responds to the Start() and Stop() commands by issuing SIGCONT and SIGSTOP signals respectively to the designated process.Issues:How to make idle application consume minimal resourceHow to minimize the time from suspend to resume.11Placement Mechanisms(4)Enhanced Suspend/ResumeEnhanced Suspend/Resume:Enhance the agility of suspend/resume Issues and Approaches:When paging-in the memory pages of a resumed process, the operating system brings them into main memory on-demand (i.e., only when the resumed process generates a page fault). CPU-bound and I/O-bound.Sol: Pre-fetch the memory pages of the process to be resumed in bulk before waking it up with the SIGCONT signal.Need to modify OS kernel.12Placement Mechanisms(4)Enhanced Suspend/ResumeIssues and Approaches(cont):A resumed process will be delayed if the operating system needs to free memory to accommodate the resumed AppServ.Suspend AppServ still consume memory.Sol: We free this memory by pre-purging entire suspended AppServ from memory to disk.A recently suspended AppServ will not be activated for a long (in computing terms) time.Bulk pre-purging is likely to place all pages of the AppServ on disk close to each other.The activation should be faster because of fewer disk head movements.

13PerformanceShow all application placement mechanisms performanceRegular StartupRun-EverywhereRegular and Enhanced Suspend/Resume 14TestbedHosting Server*12.8 GHz Intel Pentium 4 CPU512 MB of memory Linux kernel 2.6.21.Two disks:one hosting a large swap area (13 GB)and the other holding the application les.Application Server(Execution Unit)JBoss15Testbed(cont)Three sub-applications:TPC-W with 1000 items----Represent real applicationsThe transactional Web e-Commerce benchmark TPC-WA synthetic application that imposes a tunable CPU loadDenes a single request type that contains a loop consuming a number of CPU cycles.A synthetic application with a tunable memory footprintOne type initializes a large static array of characters on the rst request and then touches all those characters on subsequent requests.The other is a null request.Request Generator:wget(http://www.gnu.org/software/wget/)Note:All experiments in this section are repeated ten times16

ExperimentRegular Startup(1)Objective: observe startup delay when CPU Load is increasing.Steps: We start a copy of JBoss containing all our test applications.Apply a certain request rate to the CPU-bound application to generate the desired CPU load.Start a second instance of JBoss and observe its startup delay.Startup time = the time Jboss reports ready-Local controller receives the Start() message.17Conclusion:Startup delay is high when CPU load is high.Imagine when you want to assign an memory intensive application to this machineExperimentRegular Startup(2)Objective: observe resource consumption when a new instance starts.Step:Start an AppServs on an idle machine.Observe CPU usage and I/O wait.About I/O wait:Dened as the percentage of time that the CPU was idle during which the system had an outstanding disk I/O request.Implication of disk usage.18

Conclusion:Regular startup may consume huge resources.ExperimentRun-EverywhereObjective:Observe resource consumption of idle applicationsSteps:We start a JBoss instance and wait until it reports startup completion.Monitor the overall CPU and disk usage on the server for the next 100 seconds before we start another JBoss instance.19

Conclusion: AppServs never become truly idle from the OSs perspectiveExperiment: Regular and Enhanced Suspend/ResumeObjective: observe how free memory space affect Resume delay in two approaches.Steps for two approaches:

Resume delay:From: Send out resume messageTo: Completion of a small application request to indicate that the application instance is active.

20Experiment: Regular and Enhanced Suspend/Resume(1)21

For Regular one:Non-enhanced resume process requires CPU cycles for page fault processing, CPU scheduling, and freeing memoryFor Enhanced one:Pre-purge to avoid freeing memory.Pre-fetch to avoid page fault processing

Experiment: Regular and Enhanced Suspend/Resume(2)Suspend/resume and enhanced suspend/resume operations are disk intensive.Need to bring a large number of pages into main memory.Why Enhanced one use less time?It stores application pages on disk together so that they arebrought back faster.22

Prefetching overheadRecall:A synthetic application with a tunable memory footprintOne type initializes a large static array of characters on the rst request and then touches all those characters on subsequent requests.Prefer Enhanced oneThe other is a null request.Prefer Regular one.23Contributing FactorsGoal:Experimentally characterize the contributions of each element to the overall performance enhancement

24

Hosting Platform AgilityGoal: Compare the speed to relieving hotspot of each mechanisim.Testbed:Two hosting serversBase server: hosts an application initially.Support server: Activate an application instance when the base server becomes overloaded.Switch: Nortels Alteon 2208 Application Switch(Layer 4 switch)25

Related workThere are different approaches target different resource-sharing environmentsEach application runs in dedicated virtual machine[2][10]But previous placement works are mostly focus on deciding the number and location of the replicas.

About the agility of hosting platform:Previous work addressing this environment [25, 13] recognized the costs of changing application placement but focused on minimizing the placement changes.

26[2]A. Awadallah and M. Rosenblum. The vmatrix: A network of virtual machine monitors for dynamic content distribution. In 7 th WCW, 2002.[10] X. Jiang and D. Xu. Soda: A service-on-demand architecture for application service hosting utility platforms. In 12th HPDC, 2003.Future workPrefetching policies:We discuss before:Simply prefetches an entire AppServ process into memory.Way to improvement:Snapshot prefetchingPrefetches only the part of the application that was actually accessed in memory the previous time the application was active.

27ConclusionsThis paper discusses the issue of efficiency of application placement in a shared web hosting platformThey improve the agility when facing a hotspotFrom their experiments they shows:Regular startup is time and resource consumingRun-everywhere is not practicalTheir placement mechanism: enhanced suspend/resume reduce lots of time and overhead.28CommentsAdvantage:This paper have lots of good experiments that we can learn.Disadvantage:Need to modify OS kernel to implement.Way to think:What if we bring this idea to Cloud computing system?29