Transcript SCORE: A Scalable Architecture for Implementing Resource

Testbeds Breakout
•
•
•
•
•
•
•
Tom Anderson
Jeff Chase
Doug Comer
Brett Fleisch
Frans Kaashoek
Jay Lepreau
Hank Levy
•
•
•
•
•
•
Larry Peterson
Mothy Roscoe
Mehul Shah
Ion Stoica
Joe Touch
Amin Vahdat
1
GENI Requirements
• Virtualizable
– So users can share infrastructure
•
Programmable
– So users can provide arbitrary functionality
• Supports painless user opt-in and opt-out
– So we can get real workload
• Federation
– So new devices, clusters, edge networks can be plugged in
• Software development support
– So we can make our stuff real and available to each other
– So we can build on each other's work; this includes
(especially) management software
2
Questions
• What do we need?
• How can we contribute to substrate?
• What basic services can we provide?
3
What do we need? (1)
• Significant storage and computation
infrastructure  make it possible to deploy
Google and Yahoo like services
 20-30 clusters
 > 256 node per cluster
 > 256 TB per site
• Many smaller clusters with heterogeneous
connectivity  make it possible to deploy
Akamai like services
• Others: 1000s of hosts, sensor nodes, mobile
devices, embedded devices
4
What do we need? (2)
• Allow users to easily opt-in and opt-out with
their resources to/from the testbed
• Enable testbed to organically grow to include
–
–
–
–
Wireless networks
Sensor networks
Community Networks
…
5
How can we contribute to substrate? (1)
• Provide a “virtual network system”
abstraction:
– Virtualize all resources: CPU. Memory, storage,
network
– Virtualization within constraints (e.g., 20 ms delay,
2 Mbps links)
• Challenge: Map virtual system networks onto
physical resources while meeting time and
resource constraints
6
How can we contribute to substrate? (2)
• Resource management & allocation
– How to allocate resources (virtual network
systems) when testbed is oversubscribed?
• Challenge: Develop flexible policies and
mechanisms
– E.g., reservation in both time and space, marketbased allocation, …
7
How can we contribute to substrate? (3)
• Support for auditing, debugging
– How to discover users with malicious intend,
misconfigurations, bugs?
• Challenges:
– Efficient and scalable infrastructure that at limit
would allow all nodes to log all messages, virtual
machine checkpoints, etc
– Extensible monitoring infrastructure; provide
hooks for users to add their own monitoring or
logging code
8
What services can we provide? (1)
•
•
•
•
•
PKI infrastructure
Certification authority
Auditing services
Name server (DNS++)
Resource location and discovery
9
What service can we provide? (2)
•
•
•
•
•
•
•
•
•
•
Citeseer
Source forge
Usenet news
arXiv.org
Conference submission
Fastlane
Data distribution service
Spam filters
Distributed firewalls
Open search engine (Open Google?)
10
11
Goals
• Flexibility/Control
• Isolation
• Realism
• Fairness
• Security
• Support for tracing, replaying
12
What should a Testbed Include?
• PlanetLab++
– Large number of node (1000s), heterogeneous connectivity
• Optical networks
• Sensor nodes
• Mobile hosts (PDAs, Phones, etc)
• Data centers (Google, Yahoo, part of the Internet
fabric)
13
•
•
•
•
•
•
Soft-radios
Four classes of wireless
All things for all people is difficult
Configurable testbeds
Heterogeneous separate testbed
What’s it at this site?
– Storage to do management
• Contribute with software, maintain and
support
• Operational and manage this
14
What we need?
• Sensornodes
• Open environment
– Organically evolve testbeds
• Distribution, heterogeneity, scale
15
What else we need (Software)?
• Databases
16
How can we contribute?
• Management?
17
Flexibility
• Need to be have complete control on
infrastructure node
–
–
–
–
Run various OSes
Port numbers
Real-time
Root privileges
18
Isolation
• One user shouldn’t be able to interfere with
the experiments of other users
• At multiple levels
–
–
–
–
CPU
Memory
Disk
Bandwidth (both outgoing and ingoing)
19
Realism
• Real users, real applications
• Negotiate with ISPs to send traffic across
testbed
– How to guarantee that ISPs traffic won’t be
screwed
• Recreate catastrophic failures, attacks
20
Security
• Prevent using testbed to initiate attacks
– Malicious users
– Misconfigurations
• Challenge: minimal impact on flexibility,
performance
21
Management
• How to allocate resources to users in a fair
and easy to understand (predictable?) way
• Flexible polices and mechanisms
– Reservation in both time and space
– Biding, trading resources
– Economic-based allocation
22
Support for tracing, replaying
• Ideally, log everything:
– Traffic
– Virtual machine checkpoints
• Enable replaying, forensic
• Hard
23
• Virtualized testbeds
– Network and edge devices network
– Virtual machine and virtual network
– Virtualization within constraints (20ms)
• Abstract away heterogeneous software
• Specify requirements  map on real
resources
24
• Auditing/logging
• Flexible monitoring
• Secure hooks for monitoring
25
Extensible testbeds
• Flexible routing infrastructure
• Integrate everything
• Community networks
• Useful control system
26
• Resource allocation
• Model for incentives
• Incentives to X add resources
•
•
•
•
•
PKI infrastructure
Certified authority
Auditing services
Name servers
Resource location and discovery
27