Adaptable Consistency Control for Distributed File Systems

1. Adaptable Consistency Control for Distributed File Systems Monash University Dept. of Computer Science and Software Engineering Simon Cuce simon.cuce@csse.monash.edu.au

2. Background • DFS provide additional subsystems for replication and one-copy equivalence • Replication • Availability and Performance • One-Copy Equivalence • Concurrency Control • Consistency Maintenance • Current DFS implementations • Mostly cater for one scenario • Fail to work effectively and efficiently when underlying assumptions change • Inflexible to change • Difficult to adjust and modify School of Computer Science and Software Engineering Monash University

3. Issues • DFS topologies include different • Hardware Components • Network Types • Applications and Users • Providing an effective and efficient level of service is impossible • Each has their own expected level of consistency requirements • Difficult to anticipate future scenarios • A universal approach is not feasible • Improve the process used for consistency control mechanisms • Such that extending is simplified School of Computer Science and Software Engineering Monash University

4. The Solution • Abstract the consistency control mechanism out of the application and/or OS and re-implement within a suitable framework • Provide numerous consistency control mechanisms to cater for different scenarios • Improve the mechanism of consistency control creation and management via a component-oriented architecture • Create a framework that allows for the supporting of existing and future heterogenous systems by promoting openness • Provide enough flexibility that alternative approaches can be catered for School of Computer Science and Software Engineering Monash University

5. GLOMAR • GLOMAR is that framework • Provide a mechanism to encapsulate alternative consistency control mechanisms under the one distributed file system • Provide support services to control the implementation of these encapsulated consistency control mechanisms • Provide a methodology for the simplified creation of consistency control mechanisms • Two main design elements • The Relationship Component (RC) • The component that encapsulates the consistency control functionality and scope information • The System Support Components (SSC) • Manages the RCs • Implements a RC when appropriate • Provides support services for consumption by the RC School of Computer Science and Software Engineering Monash University

6. Relationship Component • Conceptually consists of 3 elements Consistency Model, Relationship Scope and Clone List School of Computer Science and Software Engineering Monash University

7. Relationship Component • The Consistency Model • Encapsulate the algorithms used to maintain consistency • Based on file system primitives (read, write, etc) • The Clone List • Defines what replicas this RC should govern • The Relationship Scope • Used to define what conditions this RC is suited. • User defined • Resulted based on heuristic generated from the System Grader • The Relationship Component • A bound collection of a CM, a RS and a CL • And other metadata (threading, instantiation and life cycle) School of Computer Science and Software Engineering Monash University

8. System Support Components • Handles the management of RCs. • Sub components • The Interceptor • Intercept IO requests for further processing • The System Grader • Provides and constantly updates the heuristic information • The Remote Operation Interface • Handles requests from remote machines • The Clone Distribution Monitor • Provides replica name resolutions • The Relationship Component Repository • Manages and selects RC • Implements Relationship Component Processing (RCP) • The Service Manager • Allows installation of developer created services • The Executive • Mangers all events and sub systems School of Computer Science and Software Engineering Monash University

9. System Support Components School of Computer Science and Software Engineering Monash University

10. GLOMAR Implementation • Written in Microsoft .NET • ~6000 lines of code • Supports component programming • Multiple language support (for legacy CC implementations) • Support for new technologies (e.g. SOAP) • Runs as a Windows Service • Administration Console • GUI used to detail GLOMAR elements • Number of heuristic libraries supplied • Connectivity, Processor, Network, Memory School of Computer Science and Software Engineering Monash University

11. RC Implementations • Document Editing Application • Illustrate the feasibility of GLOMAR • Support for disconnection operations • Implementation • A “notepad like” application that persists per key stroke • Two RCs • ROWA (Pessimistic) • Get Latest (Optimistic) • Uses SOAP and web services • MS Outlook 2000 RC • Implement a different consistency model for different folders • Notes, DraftMail, SentMail, Inbox, Contacts, Calendar and Tasks School of Computer Science and Software Engineering Monash University

12. RC Implementations • Twin Transaction Model • PhD by Aamir Rasheed • Created by an external party • Illustrates the implementation of an advanced approach to concurrency control within a DFS • Transactional base School of Computer Science and Software Engineering Monash University