290 likes | 483 Views
EDAS: Providing an Environment for Decentralized Adaptive Services. Vision. Middleware. EDAS. Peer-to-Peer. Grid-Computing. Providing a user supported grid-like infrastructure for long-term, decentralized and adaptive services Open-source project management, online communities. Challenges.
E N D
EDAS: Providing an Environment for Decentralized Adaptive Services
Vision Middleware EDAS Peer-to-Peer Grid-Computing • Providing a user supported grid-like infrastructure forlong-term, decentralized and adaptive services • Open-source project management, online communities
Challenges • Grid inspired organisational architecture • Concept of domain and virtual organisation • Decentralized management tasks via peer-to-peer techniques • Authentication and authorization • Code provisioning • Service placement and resource management • Decentralized adaptive service model • Fault tolerance • Mobility • Scalability
Outline • EDAS Architecture • Resource Management • Decentralized Adaptive Service • Agenda • Conclusion
EDAS - Architecture • Institutions, companies and also single users are willing to support a project by providing resources • How should we use their resources? • Where place the service of our project?
* 1..* Home Environment provides resources to 1 1 manages manages the execution of 1..* 1..* Node Decentralized, Adaptive Service Service Environment EDAS - Core Components • Home Environment (HE)- Connects all nodes of an administrative domain • Service Environment (SE) - Provides a distributed execution environment for services • Decentralized, Adaptive Service (DAS) - Dynamically distributed within the scope of an service environment
EDAS - Home Environment • Mediator between peers of an administrative domain and one or more Service Environments (Projects) • Monitors and manages resources of a peer set • Controlled by a Domain Manager • Add and remove peers • Assign and revoke resources to Service Environments
EDAS - Service Environment • Collect and combine system information provided by HEs • Supports automatic distribution of services • Based on load, available resources and DAS specific requirements • Controlled by a service manager • Start, stop and configure services • Accept or decline resource offers (manually or via policy rules)
EDAS -Decentralized Adaptive Service • Decentralized, Adaptive Services expand or shrink autonomoulsy depending on • Service demand • Fault tolerance reasons etc. • Could have different internal service-structure models and ideally change its service structure over time if necessary
Resource Management • Core idea: Controlled resource sharing • Home Environments offer fixed amount of resources to Service Environments • Service Environment can accept or decline resource offers • Tasks of the Home Environment • Resource monitoring of physical resources: CPU, network, memory, disk • Local Area Placement • Manage service placement at domain level • Keep service environment limits • Task of the Service Environment • Wide Area Placement • Manage service placement in scope of a project
Resource Limits at Node Level • Physical Limit • Provided by the underlying hardware • Node Limit • Bounds the resource usage of a node • Local Limit • Resources of a node assigned to a service belonging to certain SE Node A 100% reserved unassigned Node Limit Physical Limit Service B (SE 2) Local Limit Service A (SE 1) 0%
Resource Limits at Domain Level • Global Limit • The overall amount of resources dedicated to a service environment Global Limit Node D Node A Node B Node C
MBeans MBeans Resource Monitoring at Node Level • Prototype based on monitoring and management facility Java Management Extension (SDK 1.5) • Provides beans to monitor CPU and memory usage • Implemented own management bean for bandwidth Remote Manager JMX Manager Web Browser SNMP Manager Connector Level RMI Adaptor HTTP Adaptor SNMP Adaptor Agent Level Mbean Server Instrumentation Level Applications
Service A Service Placement at Domain Level Node D Node A Node B Node C • Problem • Resource demand of services can dynamically change • Restrictions • Collocation and dislocation of services at the same node • Goal • Avoid service migration if possible • Placement algorithm should balance resource usage and keep limits
Node A Node B Node C Node D Keeping Resource Limits • Problem • Resource demand of services can dynamically change but we have to keep the global limit • More time critical than service placement • Approach • Rededication of limits
Keeping Resource Limits • Solution: Diffusive load balancing algorithm • All nodes supporting a service environment at a domain are connected in small overlapping groups • Frequent exchange and balancing of free resources (free slack) • If free resources locally reach zero the global limit is reached • Additionally exchange neighbour and resource limit information to compensate failed nodes
Service Placement at Project Level • Problem • Resource demand of services can dynamically change • Resource availability can dynamically change • Restrictions • Collocation and dislocation of services at the same domain • Goal • Avoid service migration if possible • Consider network proximity
Related Approaches • Peer-to-Peer query engines • SWORD (Berkley) • XenoServer (Cambridge) • Decentralized approaches based on Peer-to-Peer Networks • Adaptive Service Placement Algorithms for Autonomous Service Networks (HP) • T. Repantis et. al: Adaptive Resource Management in Peer-to-Peer Middleware • Centralized approaches for closed systems • HP Internet Utility Farms: Quatermaster • B. Urgaonkar: Application Placement on a Cluster of Servers • CORBA based systems: Realize & MEAD
Fragment View Fragment Implementation Client Client DAS: Decentralized Adaptive Services • Based on the AspectIX Middleware CORBA ORB • Offers with Fragmented Objects a distributed object model • Fragmented Object (FO): Arbitrary set of distributed fragments • Local fragment at every node that accesses FO • FO is encapsulation unit with well-defined interface, but without any relation to a specific location. Fragmented Object
DAS: Decentralized Adaptive Services • Goal • Provide long-term running, user accessed services in dynamically changing environments • Approach • Active Object Replication • Migration support • Custom client-side interaction via smart proxy approach
DAS: Decentralized Adaptive Services • Support service development • Annotated IDL and a special IDL-Compiler (IDLFlex by Hans Reiser) to generate custom stubs and skeletons to interact with a group communication framework (Jgroups) • New method modifier • local - stub method local to the client • private - stub method is only object internally accessible • admin - credential guarded method • read - non state mutating method
Client Client DAS: Decentralized Adaptive Services • Replicas can be dynamically created and moved inside the scope of the fragmented object • Client-side fragments can be exchanged • Example Service: Version Control Service • Replicated service core holds only current file information and manages concurrent access • Files might be stored on different nodes of the Service Environment Node A Node A Replica Replica GC (Jgroups) Node A Node A Custom Fragment Custom Fragment
Research Agenda • Status Quo 10/2005 • Basic resource accounting infrastructure • Framework for decentralized adaptive service • Code loading framework based on JXTA • Integration of JXTA into AspectIX • Current work 10/2005 - 4/2006 • Implementation of EDAS infrastructure • Design and implementation of placement and resource accounting algorithms • Next steps 4/2006-9/2006 • Evaluation of algorithms • Design and implementation of a membership service as a DAS • Implementation of example services: source code repository, ...
Conclusion • Grid like infrastructure • Resource management support • Decentralized adaptive service model • Long term perspective provide a project management infrastructure like SourceForge • Further information: http://www.aspectix.org • Questions?
AspectIX Middleware • View • Stores IOR of the object • Manages active fragment interfaces • Manages the currently active fragment implementation • Fragment Interface • Automatically generated by the IDL compiler • Coordination mechanisms for safe exchange of the fragment implementation • Fragment Implementation • The real implementation of the object's functionality • Service developer may define arbitrary fragment implementation types Fragment Client View Fragment Interface Fragment Implementation
DAS: Decentralized Adaptive Services • Example Service: Version Control Service (VCS) • Replicated service core holds only information about where to find the files and manages concurrent access • Files might be stored on different nodes of the Service Environment or anywhere else • Ensures small service state and makes service easy relocatable Service Environment 3: data:getFile() Client Node 1: getFile() 2: url:getFile()
Resource Limits at Node Level • Physical Limit • Provided by the underlying hardware • Node Limit • Bounds the resource usage of a node • Local Limit • Resources of a node assigned to a service Node A 100% reserved unassigned Node Limit Physical Limit Service B (SE 2) Local Limit Service A (SE 1) 0%
Resource Limits at Domain Level • Global Limit • The overall amount of resources dedicated to a service environment Node D Node A Node B Node C