1 / 17

Cloud Computing Testbeds

Cloud Computing Testbeds. Why do we need them? How can we build them? What are the classes? Testbed activities going forward. Why Do We Need Them?. Systems Computing is undergoing a sea Solution: Exploit peer-to-peer technologies Widespread federation

tawana
Download Presentation

Cloud Computing Testbeds

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Cloud Computing Testbeds • Why do we need them? • How can we build them? • What are the classes? • Testbed activities going forward

  2. Why Do We Need Them? • Systems Computing is undergoing a sea • Solution: • Exploit peer-to-peer technologies • Widespread federation • Need for standardization on API’s, naming schemes • Collaborate with public agencies (NSF, EU, JGN…)

  3. The era of institutional systems research • Computer Systems Research, 1980-2010 • Dominated by desktop-scale systems • 1980-~1995: The desktop was the experimental system • Ex: Original URL of Yahoo! was akebono.cs.stanford.edu/yahoo.html • Akebono was Jerry Yang’s Sun workstation! • Named for a prominent American Sumo wrestler – Jerry had spent a term in Kyoto in 1992 • Sometimes “servers” used to offload desktops • But rarely: “Server” ca. 1990 was a VAX 11, less powerful than a SUN or DEC workstation • ~1995-~2005: Used servers primarily because desktop OS unsuitable for serious work • ~2005-: Need clusters (and more) for any reasonable experiment • The Era of Institutional Systems Research has begun

  4. Why? • Activity in 21st Century Systems Research focused on massively parallel, loosely-coupled, distributed computing • Content Distribution Networks • Key-Value Stores • Cloud Resource Allocation and Management • Wide-Area Redundant Stores • Fault Recovery and Robust Protocols • End-system multicast • Multicast messaging • Key Problem: Emergent Behavior at Scale • Can’t anticipate phenomena at scale from small-scale behavior • Hence: Moderate-to-large scale testbeds: • G-Lab, PlanetLab, OneLab,…

  5. Experimental Physics Before 1928 • Dominated by tabletop apparatus • Ex: Rutherford’s discovery of the nucleus, 1910 • Done with tabletop apparatus, shown here • Major complication: had to observe in darkened room

  6. Example: Chadwick and the Neutron • Chadwick used high-energy particles from polonium to bombard nucleus • Neutron only method to account for high-energy radiation from bombardment • Key apparatus “leftover plumbing” – pipe used to focus radiation beam • Date: February, 1932

  7. Entry of Institutional Physics • Nuclear Fission, Cockcroft and Walton, April, 1932 • Key: needed high voltages (est 250,000+ volts) to split nucleus • Room(!) to hold apparatus major constraint • Needed major industrial help (Metropolitan-Vickers)

  8. What a difference two months makes.. Cockcroft/Walton, 4/32 Chadwick, 2/32

  9. Since Then…

  10. Why Systems Computer Science is undergoing a phase change • Key: need to understand planetary-scale systems • Systems and services that run all over the planet • Critical, pervasive, robust • Modern systems do trivial things at massive scale • Ex: Would take anyone in this room roughly 1 day to build Facebook • But it would break very quickly! • Facebook now has 500M users • World has a zetabyte (1E18 bytes) of data • Doing anything at scale is very, very hard • Emergent behavior at scale • Can only understand by experimenting near scale • Requires planetary-scale testbed and deployment platform

  11. Emergent Behaviors • Behaviors that only manifest at scale or in use • Spam • Congestion in Internet routing • Flash crowds • Typically, only discovered by experiment and deployment • Key need: experiment at scale, with real users • Only place where emergent behavior is apparent

  12. How Can we Build Them? • Short version: we can’t • Yahoo’s “Clique” is 20,000 servers • Google uses “warehouse-scale computers” • Both are beyond the reach of reasonable funding. • So what can we do? • Emulation • Federation • Cooperative testbeds that grow

  13. Analogy to the Internet • Question: How would you build the world’s greatest digital library? • Answer One: • Build a massive centralized data center to hold it • Take over Kansas to host it • Massive power to power and cool it… • Answer Two: • Develop a protocol that would let one computer send files to another • Develop universal display client • Stand back and let nature take its course…

  14. Similar idea • Work with testbed organizations to develop suite of standard APIs, Access Control • NSF Global Environment for Network Innovations (GENI) • EU FIRE Initiative • JGN-II Initiative (Japan) • Major research infrastructure and testbed providers • Global Lambda Interchange Facility (GLIF) • OpenCirrus • Open Cloud Consortium • Emulab/ProtoGENI • PlanetLab/ONELab

  15. Promising Start • Slice-based Federation Architecture (GENI) • Already implemented on PlanetLab, ONELab, ProtoGENI • Attribute-Based Access Control (ABAC) • Need more work with international bodies • Standardization beginning in 2013-2014(?)

  16. Kinds of Testbeds • Small collection of moderate-to-large clusters • E.g. OpenCirrus, VICCI, ProtoGENI • Moderate-to-large collection of small clusters • PlanetLab, ONELab • Massive collection of edge devices • Million-node GENI (Seattle) • Each have different strengths, weaknesses, different applications • Massive collection of edge devices relies on end-user opt-in • Needs “killer app…”

  17. STC Activity • Collaboration with funding organizations • Collaboration with testbed providers/operators • Offer standards support where possible • Offer technical co-sponsorship where desired.

More Related