Lighthouse20100120
-
Upload
sureddy -
Category
Technology
-
view
350 -
download
0
Transcript of Lighthouse20100120
![Page 1: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/1.jpg)
Rich Miller Surendra Reddy
Infrastructure 2.0 Working Group January 20, 2010
Lighthouse: Intercloud Metadata Service
![Page 2: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/2.jpg)
Agenda
• Intercloud & Lighthouse Objectives
• Use cases (as drivers & definition)
• Lighthouse Requirements & Concepts
• Available technologies & standards
• Architectural Guiding Principles
• Call(s) to action
![Page 3: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/3.jpg)
Intercloud & Objectives
![Page 4: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/4.jpg)
Intercloud
Requires the dissemination & exchange of operational metadata - among clouds, - between cloud services and consumers of their services.
![Page 5: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/5.jpg)
Lighthouse
![Page 6: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/6.jpg)
Lighthouse
Where to start? • Agreement on identification, location
and ID-Loc resolution • A registry for the discovery and
description of intercloud constituents • A mechanism for the delivery of cloud
service descriptive & operational data • A governance structure for
admission & ejection, assurance, permissions & entitlements
![Page 7: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/7.jpg)
Lighthouse
The concept: • Each member takes responsibility for
its own metadata access services • Membership in a communal registry of
metadata access services, with identification – location resolution
• Agreement on mechanisms for - pub/sub/search/query - asynchronous message delivery
![Page 8: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/8.jpg)
Lighthouse Scope
Scope is limited to providing the Service Access Point and related metadata to service Consumers
![Page 9: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/9.jpg)
Use Cases
![Page 10: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/10.jpg)
Intercloud: Use Case #1
• Customer A, EDA company, seeks a list of IaaS services which claim to provide:
• cloud data management • Linux OS image management
• Queries the Intercloud registry, returns IDs of services that meet criteria
• Searches IaaS service metadata to make selection • Access the Service Access Point (SAP) of a
vendor to validate claims • Subscribes to Service Access Point for receipt of
service announcements, rate changes, etc
![Page 11: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/11.jpg)
Intercloud: Use Case #2
• Customer B, an insurance company, seeks a single IaaS provider to continuously satisfy service requirements (constraints)
• E.g. latencies, geography, SLAs etc. • Queries the Intercloud registry,
returns IDs of services that meet criteria • Searches IaaS metadata to make selection • Access the SAPs of vendor to create
Cloud Service Account Instance • Subscribes to SAP for receipt of relevant
requirement-specific metadata • Takes specific actions based on timely notifications
(near realtime alerts) via Service Provider APIs and management functions
![Page 12: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/12.jpg)
Intercloud: Use Case #3
• Customer C, a globally distributed online service looking for an IaaS Providers in Europe and in USA with specific SLAs. • Using the Intercloud registry, locates services
meeting needs in two locations. • Identifies alternative providers for the business
continuity (DR, backup, …) functions. • Customer C’s application management system
subscribes to failure events & performance sensors from the IaaS providers.
• Based monitored event/sensor feeds, C’s service monitoring application dynamically scales up/down the resources (computing, networking, and storage) to their applications
![Page 13: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/13.jpg)
Intercloud: Use Case #4
• Customer D, a financial services company, runs applications that are either (or both)
• latency sensitive • throughput sensitive
• After selecting IaaS provider: • Sets up the virtual network between on-premise
data center and the IaaS provider cloud. • Customer D runs their own application mobility
controller within their data center. • Application Mobility Controller subscribes to
IaaS and data center metadata related to: • traffic flows, performance metrics • log feeds from the IaaS cloud service.
![Page 14: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/14.jpg)
Intercloud: Use Case #5
• PaaS E, a security broker service, provides an anti-phishing service for e-mail: “whitelist”, analytics and forensics
• Operates on behalf of domain holders • A list management and forensics for multiple
receiver services (e.g. web mail services) • After establishing service w/ receiver:
• Each receiver establishes a metadata access point (MAP) regarding failed email
• PaaS E publishes notifications of phishing attempts to subs, on behalf of domain holder
• All new events and changes in state/status distributed as pub/sub metadata
![Page 15: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/15.jpg)
Lighthouse: Requirements & Concepts
![Page 16: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/16.jpg)
Lighthouse Requirements
• Defines a dynamically extensible set of identifiers and metadata
• Automatically aggregates and associates real-time info from many different sources
• Provides real-time pub/sub/search mechanism for data regarding cloud instances, their state and their activities
• Scales for cloud to cloud coordination
![Page 17: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/17.jpg)
Lighthouse Concept
Autonomous Metadata Access Point
• All interested and authenticated cloud services, acting in ‘good faith’, provide their own Metadata Access Point.
• A Metadata Access Point publishes to the intercloud community any information about itself.
![Page 18: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/18.jpg)
Lighthouse Concept
A Registry of Registries
• Identity and location of individually and autonomously managed Metadata Access Services
• Authoritatively establishes the status of any individual cloud service and its standing within the Intercloud community
![Page 19: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/19.jpg)
Lighthouse Concept
Process / Event Coordination
• All 'interested' consumers of a cloud’s MAP Service may subscribe to metadata updates that result in a 'property' change
• Many systems can coordinate through a Metadata Access Protocol with no in-depth knowledge of each other's APIs
![Page 20: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/20.jpg)
Lighthouse Concept
Share operational metadata
• Near Real-time
• Cloud Information Service + Cloud Operations Coordination
![Page 21: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/21.jpg)
Intercloud Registry: Features
• Discovery of a registry’s specific interfaces / capabilities
• Auditable logging mechanism • For element / value changes • For publishing event
![Page 22: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/22.jpg)
Intercloud Registry: Features
Forms of Search & Query • search and report of items based on
(…) • comparison of object to ‘checklist’ of
elements and parameters • ‘standing’ search/query established as
subscription • query and retrieval of items based on
published / recognized (?) data scheme
![Page 23: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/23.jpg)
Intercloud Registry: Operational
• Distributed MAP Servers: Each Cloud Service is responsible for establishing and administering • its own Registry Server, or • publication of metadata by a trusted party
• Authoritative compilation of Registries (and, therefore, of Cloud Services) • Unambiguous identification • Authentication method associated with ID
![Page 24: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/24.jpg)
Available Standards
![Page 25: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/25.jpg)
Current Standards/Protocols
Federated UDDI Registry • Pros:
• Federated UDDI consisting of multiple repositories that are synchronized periodically.
• Federated UDDI is an efficient solution for service discovery in distributed service networks.
• Cons: • too expensive to replicate frequently updated
information • it is hard to directly utilize this approach to support
discovery of dynamic information • Governance nightmare…
![Page 26: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/26.jpg)
Current Standards/Protocols
Service Location Protocol (SLP) • Pros:
• agent based service discovery framework • designed for service discovery in for local area
network • extensions to SLP proposed aiming to the WAN
environment • Cons:
• Not suitable for wide area network environment • unsuitable for Cloud environment due to the scale
and distribution complexities involved.
![Page 27: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/27.jpg)
Current Standards/Protocols
IF-MAP • Pros:
• Client-Server based, real-time pub/sub/search • Designed to disseminate network security info on
objects & events (dynamic state and activity data) • Easily extensible to components other than network
and security components • XML-based SOAP protocol • Supports standardized, dynamic data interchange • Provides an uniform mechanism to securely
discover, consume, and manage a single management domain’s metadata.
![Page 28: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/28.jpg)
Current Standards/Protocols IF-MAP (continued) • Cons:
• SOAP based only, heavy messaging structure • Scale for Cloud • Need lot of extensions to existing metadata model • IF-MAP access point becomes a central authority
• TBD • Federation to support intercloud scale? • Wider range of protocols / RESTful interface? • A MAP-to-MAP (P2P) approach to bi-directional
pub/sub? • Asynch messaging queues? • “Economical” message encoding system ?
hierarchical, binary, self-describing
![Page 29: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/29.jpg)
Current Standards/Protocols Other Standards/Protocols to Consider
• WebDAV/DASL • DAV Provides Versioned Metadata
Access of Resources • DASL: Provides Searching and Location
![Page 30: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/30.jpg)
Current Standards/Protocols And, what about asynchronous messaging? • AMQP • Session Initiation Protocol (SIP) • XMPP • HTTP • JMS
Not to mention message encoding… • ASN.1 • FUDGE • …
![Page 31: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/31.jpg)
Lighthouse: Architectural Model
![Page 32: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/32.jpg)
Lighthouse: Metadata Model
![Page 33: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/33.jpg)
Lighthouse: Conceptual Architecture 1
CSP MAP
Cloud Service Provider
Metadata Access Point
CSP CSP
IC-MAP "
InterCloud Registry
IC Registry Metadata
Access Point
![Page 34: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/34.jpg)
Lighthouse: Conceptual Architecture 2
CSP IC
MAP
Cloud Service Provider
CSP
CSP
IC-ROOT
IC Metadata
Access Point
InterCloud Registry "
IC Registry Metadata
“Root Server”
![Page 35: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/35.jpg)
Rich Miller Surendra Reddy
Infrastructure 2.0 Working Group
Lighthouse: Call(s) to Action
![Page 36: Lighthouse20100120](https://reader035.fdocuments.us/reader035/viewer/2022081401/557a5f1cd8b42a6e5a8b5111/html5/thumbnails/36.jpg)