1 / 25

FAULT TOLERANT CORBA

FAULT TOLERANT CORBA. Presented by Sai Sudhir A. OUTLINE. Common Object Request Broker Architecture (CORBA) Its FT Extensions (FT-CORBA) for Software Fault Tolerance in Distributed Systems. Distributed Object Systems.

kizzy
Download Presentation

FAULT TOLERANT CORBA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. FAULT TOLERANT CORBA Presented by Sai Sudhir A

  2. OUTLINE • Common Object Request Broker Architecture (CORBA) • Its FT Extensions (FT-CORBA) for Software Fault Tolerance in Distributed Systems

  3. Distributed Object Systems • An application is distributed because its data, computation or users are distributed. • For scalability, heterogeneity, performance, ownership and administrative reasons. • Distributed object systems are a popular paradigm for object-oriented distributed applications. • CORBA (Common Object Request Broker Architecture)- standard architecture (middleware) for distributed object systems. • It allows a distributed, heterogeneous collection of objects to interoperate.

  4. CORBA • Basic CORBA paradigm is that of a request for services of a distributed object. • The services that an object provides are given by its interface. • Interfaces are defined in OMG's Interface Definition Language (IDL). Distributed objects are identified by object references, which are typed by IDL interfaces. • Follows a client-server model.

  5. A CORBA Request • Client holds reference to a remote object typed by the Rabbit interface. • Client makes a request, server returns the result.

  6. The ORB • The distributed service that implements the request to the remote object. • Locates the remote object on the network, communicates the request to the object, waits for the results and when available communicates those results back to the client. • Location Transparency • It implements programming language independence for the request. • The ORB does the necessary language binding. • Communication using IIOP over TCP/IP.

  7. FT-CORBA • A fault-tolerant distributed object computing middleware system. • Built on top of standard CORBA with modification to existing ORB. • Based on transparent object replication and transparent reinvocation in case of faults. • It is a specification and not an implementation.

  8. OBJECTIVES OF FT-CORBA • Support for a wide range of fault tolerance systems like server clusters, embedded applications and air traffic control. • FT depends on redundancy, fault detection and recovery. Server side objects are replicated. • Support for both active and passive object replication (redundancy).

  9. ARCHITECTURE OF FT-CORBA

  10. Redundancy through Object Groups • Object – basic unit of redundancy • Replicas of an object form an object group • Each object group has an Interoperable Object Group Reference (IOGR) • Object group abstraction provides • Replication transparency • Failure transparency

  11. Who Has Control? • Infrastructure-controlled fault tolerance Automatic creation and allocation of replicas Automatic maintenance of replica consistency More sensible for complex programs on servers • Application-controlled fault tolerance Precise control over object creation and allocation Application algorithms maintain replica consistency May be necessary for embedded systems

  12. More on IOGR • Profile S1 is the primary replica.

  13. An Example

  14. Fault Detection and Notification

  15. Fault Management • Fault Detector (Pull mechanism) Part of Infrastructure Supplier of fault reports to FaultNotifier • Fault Notifier Receives fault reports from Fault Detectors and Fault Analyzer Pushes report to registered entities using a standard Notification service. • Fault Analyzer Specific to Application Both a consumer and a supplier of fault reports

  16. Replication Manager Consists of three interfaces: • Property Manager – for reading and setting fault tolerance properties within a domain, such as replication styles. • Generic Factory – for creating replicated fault tolerant application objects. • Object Group Manager – for adding and removing objects (members) to and from object groups.

  17. Replication Styles • Cold passive replication Recovery from faults using state information and messages recorded in a message log Slowest recovery from faults • Warm passive replication Current state of the "primary" replica is transferred periodically to the "backup" replicas More rapid recovery from faults • Active replication Every replica executes the invoked methods Very rapid fault recovery

  18. Active Replication

  19. Passive Replication

  20. Logging for Active Replication

  21. Logging for Warm Passive Replication

  22. Logging for Cold Passive Replication

  23. Recovery

  24. Limitations • Deterministic behavior- Strong object replication consistency can be compromised by non-determinism. All object replicas must produce exactly same results with identical inputs. • Network Partitioning faults- Doesn’t solve N/Wing faults. • Correlated faults- Doesn’t provide protection against S/W design or programming faults. • Commission faults- Doesn’t provide protection against cases where hosts/objects may generate incorrect results caused by malicious objects.

  25. References • "Common Object Request Broker Architecture (CORBA), v2.5”, formal/01-09-01, Sep 001, Available at ftp://ftp.omg.org/pub/docs/formal/01-09-01.pdf • “Fault Tolerant CORBA Specification V1.0”, ptc/00-04-04, Apr 2000, Available at ftp://ftp.omg.org/pub/docs/ptc/00-04-04.pdf • “Naming Service Specification”, formal/01-02-65, Feb 2001, Available at ftp://ftp.omg.org/pub/docs/formal/01-02-65.pdf • “Notification Service Specification”, formal/00-06-20, Jun 2000, Available at ftp://ftp.omg.org/pub/docs/formal/00-06-20.pdf

More Related