a multi level meta object protocol for fault tolerance in
play

A Multi-Level Meta-Object Protocol for Fault- Tolerance in Complex - PowerPoint PPT Presentation

A Multi-Level Meta-Object Protocol for Fault- Tolerance in Complex Architectures Franois Taani ( * ) , Jean-Charles Fabre, Marc-Olivier Killijian LAAS-CNRS ( ( * ): Now at Lancaster University) DSN'2005, The International Conference on


  1. A Multi-Level Meta-Object Protocol for Fault- Tolerance in Complex Architectures François Taïani ( * ) , Jean-Charles Fabre, Marc-Olivier Killijian LAAS-CNRS ( ( * ): Now at Lancaster University) DSN'2005, The International Conference on Dependable Systems and Networks , Yokohama, Japan, June 28 - July 1, 2005

  2. Motivating Example: Replication & Multithreading  Goal : Transparent replication of a CORBA server  multi-layer: POSIX (OS) + CORBA (middleware)  multithreaded: concurrent processing of requests  thread pool: upper limit on concurrency  Problem 1 : state capture / restoration replication  application state CORBA  middleware + OS state OS 2

  3. Motivating Example: Replication & Multithreading  Goal : Transparent replication of a CORBA server  multi-layer: POSIX (OS) + CORBA (middleware)  multithreaded: concurrent processing of requests  thread pool: upper limit on concurrency  Problem 1 : state capture / restoration replication  application state CORBA  middleware + OS state OS  Problem 2 : control of non-determinism  assumption: multi-threading only source of non-determinism  how to replicate non-deterministic mutex decisions? 3

  4. Enforcing Determinism: OS Only  The same lock allocation can be enforced on all replicas.  All replicas reach the same state.  Only a small subset of the lock allocations impacts determinism. network application application middleware middleware OS FT OS FT Replication of every up to 203 synch. operations non-deterministic decision per request in middleware  highly inefficient (ORBacus) [TAO: 52 , omniORB: 64 ] 4

  5. Smart Multi-Level Reflection  With middleware and application semantics:  OS-level actions can be given a higher level semantic .  This semantic allows optimal use of OS level reflection. application application FT FT middleware middleware OS OS Combining information obtained at different levels greatly Reification of application Only 3 of the synch. operations & middleware activity made by the middleware need increases the efficiency of crosscutting mechanisms. to be replicated (ORBacus). (Here: only 1.5% of MD synch. activity actually needs to be replicated.) 5

  6. The Vision meta-level reflection base-level family of mechanisms application fault-tolerance MOP generic middleware (Meta-Object “glue” Protocol) OS meta-interfaces 6

  7. The Problem How to design & implement such a meta-object protocol? application application fault-tolerance ? middleware OS OS 7

  8. Outline  Motivating Example: Reflection and Replication  A New Multi-Level MOP: Concepts & Design  Practical Application: CORBA & Linux 8

  9. Implementing Multi-Level Reflection  Goal : To provide a multi-reflective framework for the fault- tolerance of complex, non-reflective industrial platforms  Challenges :  Requirements : What kind of information is needed for fault tolerant mechanisms? Where should this information be found?  Design : How to design a multi-level meta-object protocol that supports multi-level reflection?  Instrumentation : How to instrument an industrial, non- reflective platform in a non-invasive, transparent way? 9

  10. Implementing Multi-Level Reflection  Goal : To provide a multi-reflective framework for the fault- tolerance of complex, non-reflective industrial platforms  Challenges :  Requirements : What kind of information is needed for fault tolerant mechanisms? Where should this information be found?  Design : How to design a multi-level meta-object protocol that supports multi-level reflection?  Instrumentation : How to instrument an industrial, non- reflective platform in a non-invasive, transparent way? 10

  11. Requirements  Meta-interface for non-determinism [DSN-2003] interface MetaRequestLifecycle { /** Communication **/ fault-tolerance requestHasBeenReceived (RequestID); replyHasBeenSent (RequestID); MOP /** Control Path **/ requestBeforeApplication (RequestID); requestAfterApplication (RequestID); /** Synchronisation **/ requestBeforeContentionPoint (RequestID, RequestContentionPoint); requestAfterContentionPoint (RequestID, RequestContentionPoint); }; 11

  12. Requirements  Multi-level nature of the meta-interface Request before Request after Appli. ... Application Application fault-tolerance meta-model ... Middleware pre-processing request in post-processing application Request request request Contention Point (locks) ... Reception End Reply Start request reception sending of reply Reception Start Reply End OS 12

  13. Implementing Multi-Level Reflection  Goal : To provide a multi-reflective framework for the fault- tolerance of complex, non-reflective industrial platforms  Challenges :  Requirements : What kind of information is needed for fault tolerant mechanisms? Where should this information be found?  Design : How to design a multi-level meta-object protocol that supports multi-level reflection?  Instrumentation : How to instrument an industrial, non- reflective platform in a non-invasive, transparent way? 13

  14. Semantics and Architecture  Motivating Example : middleware non-determinism  request contention points (mutex operations) must be intercepted at OS level  but not all mutex operations (otherwise highly inefficient)  question : How to distinguish between mutexes that are relevant and those that are not?  Proposal : use of semantic context  We need to understand the purpose of OS level mutex operations in the more general context of the whole system activity  Approach: to trace the computation process that results in a low level OS operation being called 14

  15. Meta-markers  To trace semantic contexts, a mechanism is needed to transport information between different abstraction levels (software layers)  A mechanism encountered in plants : in periods of droughts the root system communicates with the foliage using dedicated chemical substances call phytohormones  Phytohormones travel through the sap  Design based on this metaphore.  Sap = threads  Phytohormones = metamarkers no water 15

  16. Inter-Level Communication with Meta-Markers thread execution path interception dormant meta-marker higher is attached level to thread meta-marker remains meta-marker transparent gets activated and modifies low level system lower behaviour level meta-level base level 16

  17. Using Meta-Markers for MOP Design  Meta-markers can be used to design a multi-level MOP  Example: synchronisation facet for middleware determinism interface MetaRequestLifecycle { ... /** Synchronisation **/ requestBeforeContentionPoint (RequestID, RequestContentionPoint); requestAfterContentionPoint (RequestID, RequestContentionPoint); };  Two issues to be solved by meta-markers:  P1 : the global semantic context of mutex creation must be captured by meta-markers  P2 : meta-markers must insure a correct instrumentation of the selected mutexes 17

  18. Capturing Semantics  Problem P1 is solved by source code annotation of semantic joint points: init_and_run_middleware (..) { init_and_run_middleware (..) { MutexesAreRelevant metaMarker () ; Mutexes creates here metaMarker .attachToThread() ; are relevant for init_request_queue (..) ; init_request_queue(..) ; determinism metaMarker .detachFromThread() ; init_some_refcount_object (..) ; init_some_refcount_object (..) ; ... ... Mutexes creates here run_ORB (); run_ORB (); are not . } } 18

  19. Meta-Markers as Meta-Mutex Factories middleware meta marker thread execution MutexesAre path Relevant meta-marker creates new a new mutex creation is mutex and intercepted attaches it to a meta-mutex meta-mutex mutex meta-level base level OS newly created mutexes are released into the OS among other non-instrumented mutexes 19

  20. Back to the Meta-Interface interface MetaRequestLifecycle { meta-markers to /** Communication **/ instrument requestHasBeenReceived (RequestID); appropriate sockets replyHasBeenSent (RequestID); /** Control Path **/ meta-markers to requestBeforeApplication (RequestID); transport request IDs requestAfterApplication (RequestID); /** Synchronisation **/ requestBeforeContentionPoint meta-markers to (RequestID, RequestContentionPoint); instrument requestAfterContentionPoint (RequestID, RequestContentionPoint); appropriate mutexes }; 20

  21. Implementing Multi-Level Reflection  Goal : To provide a multi-reflective framework for the fault- tolerance of complex, non-reflective industrial platforms  Challenges :  Requirements : What kind of information is needed for fault tolerant mechanisms? Where should this information be found?  Design : How to design a multi-level meta-object protocol that supports multi-level reflection?  Instrumentation : How to instrument an industrial, non- reflective platform in a non-invasive, transparent way? 21

  22. Implementation  Multilevel interception framework to control non-determinism; 8000 LoC C++; based on CORBA and POSIX only; platform independent. ML-coordination application replication request, contention point ORBacus interception mutex, thread, socket Linux use dependencies 22

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend