Joint Fault Tolerant CORBA Submission

1
Joint Fault Tolerant CORBA Submission

• Initial Submission Presentation
• Burlingame - 13th November 1998
• Chris.Smith_at_uab.ericsson.se

2
Submitting Companies

• Ericsson
• Iona Technologies
• Nortel Networks
• supported by
• Alcatel

3
Philosophy

• No special protocols
• FT should be achieved using IIOP
• No IDL changes required
• FT implementations of existing apps with
  unchanged IDL
• Fault Tolerance servers transparent to clients
• Client application doesnt need to know
• ORB doesnt need extra code/interceptors
• IIOP changes should be included in vanilla IIOP
• No single points of failure
• No Magic!

4
Standardization vs. Flexibility

• Many strategies of Fault Tolerance
• No best answer
• Often hand craft, or specialize, for particular
  application
• What We Dont Want
• Framework which is too prescriptive
• Large no. of interfaces with only small value-add
• Difficult compromises to be made
• For Fault Tolerance, err towards retaining
  flexibility rather than standardization

5
General Approach

• Support replicated object references in IIOP
• Supports tolerance to Process faults, Processor
  faults and Network faults
• Avoid specifying Prescriptive Replication
  Framework
• (Unless a generic framework can be found whose
  value-add outweighs its inflexibility)
• Many Fault Tolerance Toolkits using specific
  techniques can be built on top of the mechanisms
  proposed

6
Overview
Replica Object
State Sharing Consistency
Replica Object
Enhanced IIOP
Replica Object
Client
Group Constitution
7
Why Have Replicas

• Fault Tolerant use of IIOP must tolerate
• Process Failure
• Processor Failure
• Network Failure

Replica
Client
Replica
Replica
Client
Replica
Client
Replica
8
Addressing for IIOP with Fault Tolerance (1)
Basic IIOP Addressing
Object Type
No. of Profiles
Profile 1
Profile Body
TAG_INTERNET _IOP
No. of Components
Object Key
Port
Host
IIOP Version
Component 1
9
Addressing for IIOP with Fault Tolerance (2)
Using Multiple Profiles to address multiple
replicas in a single IOR
Object Type
No. of Profiles
Profile 1
Profile 2
Profile Body
TAG_INTERNET _IOP
Profile Body
TAG_INTERNET _IOP
Object Key
Port X
x.x.x.1
IIOP Version
Object Key
Port Y
x.x.x.2
IIOP Version
10
Addressing for IIOP with Fault Tolerance (3)
Using TAG_ALTERNATE_IIOP_ADDRESS to address
multiple replicas in a single IOR
Object Type
No. of Profiles
Profile 1
Profile Body
TAG_INTERNET _IOP
Object Key
Port X
x.x.x.1
IIOP Version
No. of Components
Component 1
TAG_ALTERNATE_ IIOP_ADDRESS
x.x.x.2
Port Y
11
Using IIOP with Fault Tolerance (1)

• Current IIOP specification does not say
• What to do if a client encounters an IOR with
  multiple TAG_INTERNET_IOP profiles
• That clients must use TAG_ALTERNATE_IIOP_ADDRESS
  components if it finds them, and in what way to
  use them
• Need new statements in IIOP specification to
  state usage of either technique

12
Using IIOP with Fault Tolerance (2)

• What do I do with a replicated IOR?
• 1) Select first TAG_INTERNET_IOP profile from
  IOR, and try to use it.
• 2) If the endpoint specified in the profile body
  is unreachable, or if a OBJECT_NOT_EXIST is
  received, then try the next profile.
• 3) Repeat until successful - if no profiles are
  successful, report COMM_FAILURE.
• Note that comm failure during invocation (i.e.
  after connection is setup) should be reported to
  client.

13
Fault Tolerant enhancement to IIOP

• Using Multiple Profiles
• ? May break current implementations that use
  multiple profiles for other reasons
• ? IORs get very big, very quickly
• Using TAG_ALTERNATE_IIOP_ADDRESS
• ? No implementations using this (yet)
• ? IORs smaller
• ? Object Key shared across replicas, so replicas
  must use the same ORB (since Object Key format is
  ORB specific)

14
Replica Group Constitution Management (1)

• Dont want to be too prescriptive
• Flexibility is vital
• Keep lightweight
• Provide standardization of mechanisms where
  necessary for interoperability
• Enable toolkits and frameworks on top of FT
  standard

15
Replica Group Constitution Management (2)

• Make Groups Explicitly using CORBA
• ? Group Constitution not Fault Tolerant
• ? Need special mechanism for Group
  Infrastructure
• ? Can have ORB heterogeneity in replica group
• ? Fault Scenarios during Group Mgmt. will be
  very complex
• ? Real Interoperability between het. Replicas
  unlikely
• ? Change in group membership well supported
• Make Groups Implicitly
• ? No need for special mechanisms
• ? No ORB Heterogeneity in replica group
• ? Applications using database etc. very easily
  replicated
• ? Change in group membership not well supported

16
Configuring Object Replicas (1)
Host 1
Configure - Object also available at x.x.y.2
x.x.x.1
Replica Object
ORB
Client
Host 2
Configure - Object also available at x.x.x.1
Replica Object
x.x.y.2
ORB
17
Configuring Object Replicas (2)

• Proposed Configuration is at deployment time -
  i.e. unspecified
• Working on possible POA Policy to specify
  alternate locations of Objects
• Provides some application control
• More fine grained control of which objects are
  replicated

18
State Sharing and Synchronization

• Many mechanisms used
• RDBMS
• ODBMS
• Runtime data-sharing
• Standardization unnecessary
• Persistent State Service (PSS) may be useful to
  applications
• No IDL necessary

19
Availability
Client-side POA Policy to hint at what
Availability is desired.
FT Daemon/ Gateway
Client
1 Object Reference
Replica
Replica
Cold Standby (10)
Active Replicas (10000)
Replica
Replica
20
Not Currently Covered

• Fault Detection
• Maybe some IDL-compiler generated ping to other
  replicas for ease of server side implementation
• Fault Collection
• Maybe use Notification Service, and provide some
  classification of CORBA faults
• Failure Recovery
• Dont do anything automatic - fault scenarios
  will typically involve processor failure, network
  separation etc.

21
Summary

• Client Transparency is vital
• Propose enhancements to IIOP
• Clients communicate with FT servers
• Tolerate Network, Processor, Process Failure
• Dont overspecify Framework
• Allow easy replication for existing
  applications
• Enable toolkits/FT services