Proactive Infrastructure: The Ninja Service Platform David Culler, Eric Brewer, Anthony Joseph & Randy Katz UC Berkeley ninja.cs.berkeley.edu.
Download ReportTranscript Proactive Infrastructure: The Ninja Service Platform David Culler, Eric Brewer, Anthony Joseph & Randy Katz UC Berkeley ninja.cs.berkeley.edu.
Proactive Infrastructure: The Ninja Service Platform David Culler, Eric Brewer, Anthony Joseph & Randy Katz UC Berkeley ninja.cs.berkeley.edu Moving Away from the ‘average’ Device Server Client Infomation appliances Scalable Internet Services - millions of clients - always up Core Questions • Scalable, Highly Available Services => wellengineered, well- maintained and relatively centralized platforms – How do we preserve the distributed innovation of the personal computer era in a service-centric world • Emerging devices are diverse and highly constrained – How do we deliver powerful services on small devices? => Push services into an Active infrastructure Ninja Project Goals • Enable a service-centric world (rather than applications) – Move applications into the core of the network • Robust infrastructure for services: – – – – Scalable, highly available, and persistent Customizable: enable personal preferences (and code!) Support a wide-range of devices: pagers to PCs Easy to author despite these challenges • Universal framework for constructing and deploying services – Programming model and execution environment for scalable services – Authentication and pay-per-use services – Automatic discovery, composition and use of sub-services Ex: Personal Information Management E-Mail store AP1 AP5 PSTN IP Core Network Directory Server1 Univ-Inbox Service AP4 AP2 Directory Servern AP3 GSM Voice Mail store Laptop (VAT) • Users (will) have lots of (new) end devices • Each device has its own address, capabilities, etc. • Universal Inbox gives users control over how info reaches them • Transcoders adapt content to end device Example: Ninja Jukebox 3 .au/.mp3 player WWW Browser HTTPd service Web page with song playlists Music Directory service iSpace Music stream (.au or .mp3) 4 Pushes an index of locally available songs to the master directory. 2 CD “ripper” service Fetches track/title & artist information from an online DB. CDDB service iSpace 1 Example: Millennium Cluster Massive Cluster Clusters Gigabit Ethernet Servers Wireless PDAs Cell Phones Future Devices • Large-Scale Campus-wide Testbed • Management by Services – push monitoring service into nodes – clusterview service logs, aggregates, manages • Resource allocation by market services – banks, brokers, merchants Desktop PCs Traditional Internet Service Trusted Client https DATEK (Trust Contract) Infrastructure Services: Embedded Untrusted Interface NINJA Infrastructure Services Key Store sRMI Embeded Untrusted Client Trusted Client https https Content Filter (pseudonym) DATEK (Trust Contract) Example: One Time Passwd to pseudo-service • Cannot increasing the security level of the communications channel so decrease the value of the content. Constrained Personal Info Appliance Untrusted Gateway NINJA Key Store Personal Appl Embeded Untrusted Client Trusted Client sRMI GWY https https RMI PXY CF ST Content Filter (pseudonym) DATEK (Trust Contract) Example: Minimal Trader • Shared secret between user and keystore • keystore maps to service identity / authentication • Content filter transcodes to very concise info to pilot Uniform Access to Diverse Services NINJA Key Store Personal Appl Embeded Untrusted Client Trusted Client sRMI GWY https https RMI PXY CF ST Content Filter (pseudonym) Trade-R-us Trade-R-us DATEK (Trust Contract) Automated “Clients”, ... NINJA Key Store Personal Appl sRMI GWY RMI PXY CF ST BOT svc Embeded Untrusted Client Trusted Client https https Content Filter (pseudonym) Trade-R-us Trade-R-us DATEK (Trust Contract) Requirements Summary • • • • • Utility: scalable, highly available, reliable Support for persistent data Support for streams, not just RPC Support for automatic data transformation Support for fine-grain authentication and payment The Ninja architecture addresses these What is a Service? • Service – Highly available program (or cooperating programs) • fixed interface at a fixed location (lives in the infrastructure) • guarantees about performance, availability, consistency – Strongly typed interface • Multiple services of a given type compete • Compete on location, price, robustness, “quality”, brand name • Service Discovery Service (SDS) – Find “best” service of given type • current approach based on weighted statistical matching – Construct a “path” from client to service Impose Structure to Simplify • Bases (1M’s) – – – – – scalable, highly available persistent state (safe) databases, agents “home” base per user service programming environment • Active Proxies (100M’s) – not packet routers – bootstrap thin devices into infrastructure – soft-state and well-connected • Units (1B’s) – – – – sensors / actuators PDAs / smartphones / PCs heterogeneous Minimal functionality: “Smart Clients” Wide-Area Path Bases • A physical, administrative, and logical boundary – a collection of machines geographically co-located – administrative guarantees: no network partitions (!), constant power supply, trust within the Base • Base platform simplifies authoring of services – cluster primitives • task execution, naming, and monitoring • load balancing, failure detection, and restart – persistent data primitives and guarantees • distributed, available data structures • Hides service implementation from rest of world – granularity of services is at cluster level, not node level Base Implementation iSpace iSpace iSpace iSpace SAN Multispace cluster • iSpace: the building block of a Base – receptive execution environment – intra-Base primitives (stub generation, persistent data repository, etc.) • Multispace: cluster-wide naming and resource mgmt iSpace Execution Environment Untrusted Services Security Mgr Loader Sandbox that contains untrusted, uploaded services. Currently just the JRE’s standard appletSecurityMgr Trusted Services Service is an interface, plus objects that implement that interface. Name service, RMI stub registry, and service control API: • LoadService (URL) • interf.[ ]=ListServices • stub=GetService(name) • KillService(name) Ninja RMI KillService semantics unclear… objects vs threads? Ground up re-implementation JVM + persistent store APIs of Sun RMI. Includes authenticated, secure RMI, iSpace multicast RMI, and soon, AMRMI and VIA-RMI. JVM provides code mobility and service upload capability, plus strong typing of service interfaces. Added distributed hash table API (think Linda space) to JRE. Services names are at the granularity of the entire cluster, not individual nodes. Multispace services Multispace Loader Multispace iSpace • RMI “Redirector Stubs” assembled 1 2 – run-time compiled RMI superstub – contains all of a service’s instance’s stubs – stub selection policy • fail-over, broadcast, multicast, fork, etc. 3 – currently, idempotency and atomicity required of service instances Distributed Data Structures • Solve the state management problem once and provide high-level abstractions to service authors – Hypothesis: given a set of highly-available, scalable, persistent data structures, persistent BASE services will be much easier to construct • Example data structures: – append/truncate-only Log • system logging, generational mailstore, undo/redo logs, etc. – Hash table • web cache, search index/data, mint accounts, etc. • consistent, persistent, and highly available – Tree / Trie / Treap Active Proxy • • • • Local execution environment (interchangeable) No support for persistent data (soft state) Runs an iSpace but not a MultiSpace Bootstraps small devices into the infrastructure – could run Jini or other local discovery mechanisms – could be in a home or basestation – performs resource discovery and path creation for the device – typically well connected (while device is not) Fast Communication and I/O in Java Scalable SVC • Scalable Ninja services need full capabilities of Base devices JVM • JNI overhead too large Proc JDI? Intelligent devices – fast SAN, IO rivers – can violate type safety – chokes JVM • JDI by JIT interpositioning Streaming data – intelligent devices reflected as Java objects – JIT interprets operations on devices – data buffers bypass JVM – ex: Java AM over VIA on Myrinet Status • Several services running all the time • Release 1.0 now available – contact info: ninja.cs.berkeley.edu – Includes: • • • • NinjaRMI, including authentication iSpace/MultiSpace infrastructure SDS (soon) Several example services, including Ninja Jukebox • Active current focus: – – – – driving applications: e-mail, group calendar service discovery & path creation Java I/O and fast communication cluster-wide data structures Existing Applications • Ninja "NOW Jukebox" – Harnesses Berkeley Network of Workstations – Plays real-time MPEG-3 audio served from 110+ CD's worth of music • Voice-enabled room control – Speech-to-text Operators control room services (camera, lights, microphone) – Integration with GSM cell phones and PDA-based UI (soon) • Stock Trading Service – Accesses real-time stock data from Internet – Programmatic interface to buy/sell/trade stocks through online brokerage • NinjaFAX – Programmable remotely-accessed FAX machine service – Send/receive FAXes; authentication used for access control • Keiretsu: The Ninja Pager Service – Provides instant messaging service via Web, 1/2-way pagers, WorkPads, etc. Coming Applications • Universal Inbox – e-mail, FAX, pager, voicemail accessible anywhere – persistent data (yes we will use it!) • Infrastructure-based group calendar – handles both web and PDA access – supports disconnected operation • Universal Remote – multiple-UI control of household/room devices – automatic UI generation • Ecash Mint – Authenticated service to act as digital secure cash mint – Enable real pay-per-use services (e.g. Coke machine) Ninja Requirements Summary • Utility: scalable, highly available, reliable – Base, MultiSpace, Smart Client, NinjaRMI, and mobile code – Architecture for easy development/deployment of services • Support for persistent data – Base and persistent hash tables • Support for streams, not just RPC – Operators and wide-area paths • Support for automatic data transformation – Wide-area paths: Strong typing & Automatic Path Creation – Span spectrum of end-user devices dynamically • Support for fine-grain authentication and payment – Authenticated and pay-per-use services To Read More • http://ninja.cs.berkeley.edu • The MultiSpace: an Evolutionary Platform for Infrastructural Services, S. Gribble, Welsh, Brewer, and Culler. 1999 Usenix Annual Technical Conference. • An Architecture for a Secure Service Discovery Service, Czerwinski, Zhao, Hodes, Joseph, and Katz., MobiCom '99