Benchmarking in the Cloud - Parallel and Distributed Systems

More documents

Recommendations

Info

Something as a Service (XaaS) terminologies. Due to space limitations, here weonly mention Youseff et al. [12], who extend the three layer model with Hardwareas a Service, Data as a Service, and Communication as a Service concepts.Under Benchmarking in the Cloud, we understand the process of benchmarkingservices provided by the Cloud. A Cloud Benchmark therefore for us is abenchmark in which the SUT contains a Cloud service as component of interest.A good summary of this topic was provided in [13].3.1 Cloud ActorsTo introduce the different Cloud actors, we take a business orientated view ofCloud Computing going beyond the simple consumer/provider model. We claimthat each service layer brings its own actors who add value to the level below.Different types of actors might have different benchmark requirements for thesame SUT. To have a strong target audience, a benchmark has to address theappropriate actors.Leimeister et al. [14] argue that the actors in the Cloud form a businessvalue network rather than a traditional business value chain. We identify thefollowing actors in a Cloud-centric business value network (Figure 1): IT Vendorsdevelop infrastructure software and operate infrastructure services; ServiceProviders develop and operate services; Service Aggregators offer new services bycombining preexisting services; Service Platform Providers offer an environmentfor developing Cloud applications; Consulting supports customers with selectingand implementing Cloud services; Customers are the end-users of Cloud services.Note that [14] uses the term Infrastructure Provider for what we call ITVendor. We deviate from [14] to stress the fact that vendors that offer softwarethat enables Cloud services should also be considered part of this actor group.We also use the term Customer where others might use the term Consumer. Wedecided to adhere to [14] in this case because service aggregators and serviceplatform providers are consumers just as customers are.3.2 The System Under TestThe above definition of a cloud benchmark requires that at least one componentof interest within the benchmark SUT is a cloud service. This leads to severalimplications, which we now briefly discuss.SUT Disclosure. A common benchmark requirement is to lay open all propertiesof the involved SUT components. This requirement is no longer realisticwhen the SUT contains public cloud services. We therefore propose to considerthe following relaxation: All properties of SUT components visible to their clientsshould be laid open. In terms of white-box vs. black-box benchmarking this leadsto nearly white-box IaaS benchmarks, grey-box PaaS benchmarks and blackboxSaaS benchmarks. Overcoming the SUT disclosure issue was also recentlydiscussed by the SPEC OSG Cloud Computing Workgroup. Their White Paper[15] provides further information.
Fig. 1. Cloud Actors and their Value NetworkSUT Uniqueness. Traditional benchmarks run on SUT components copiedinto an isolated test environment. In a cloud environment, components are modeledas services. These are single instance entities, cannot be copied, and a clearisolation is not possible. During a benchmark run the SUT services most likelywill be shared with third party clients, and avoiding external clients is neitherpossible nor desired.Carving out a SUT. One possible approach to deal with the disclosure anduniqueness issues discussed above is to carve out a dedicated set of servers withina public cloud and have these deliver the services for the SUT. We believe thatthis will not lead to relevant results.4 Use CasesIn this section we present a list of sample use cases. The list does not intend to becomplete, but rather should help us illustrate the layers and actors defined aboveand motivate the discussion of different optimization questions. In Section 5we show how appropriate Cloud benchmarks help answer these questions, andin Section 6 we identify and discuss the most important challenges that thesebenchmarks should resolve.4.1 Simple IaaSBusinesses use Cloud IaaS for outsourcing of non-critical processes like testing,training and reference landscapes. They buy IaaS resources and install the desiredsystems, but do not use them all the time. The expected load is moderateto low, being created mainly by non-critical offline processes. Our experiencewith such scenarios shows systems with 100GB disk space, 32GB memory, and 4
Page 6 and 7: CPU cores. The average load of a ru
Page 8 and 9: of game workload characterizations
Page 10 and 11: for these nodes. We propose to use
Page 12 and 13: the limit discussed in the previous
Page 14 and 15: of production IaaS Clouds has been
Page 16: 22. Fritsch, T., Ritter, H., Schill

Benchmarking in the Cloud - Parallel and Distributed Systems

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?