CCALoop

1
CCALoop -A Scalable Distributed CCA
Framework- Kosta Damevski University of
Utah
2
Motivation

• Large scientific simulations may use a number of
  distributed computing resources
• For dynamic simulation management, a framework
  exists on each separate computing resource
• (e.g. clusters, interconnected SMPs, etc.)
• Component numbers can get large
• instantiable and instantiated
• parallel components

3
Overview of a CCA Framework

• Framework configures the components in a
  simulation, then gets out of the way of the
  simulations execution
• Primary use is to be updated and queried by users
  (via GUI) and by instantiated components at
  runtime
• Other nice features of a framework
• Multiple GUI support
• Parallel Components

4
Existing Implementation - SCIRun2

• Master/slaves design
• Master framework is central repository for all
  framework data
• GUI connects only to master framework (can also
  connect remotely)
• Master framework manages all slave frameworks
• Problems
• Master framework is a single point of failure
• No scalability on significant increases in
  components or nodes

5
CCALoop Design Goals

• Functional distributed CCA framework
• Scalability
• Support multiple GUI
• Fault-tolerance on limited framework node failure
• Parallel components

6
CCALoop Design

• Frameworks are arranged in a ring-like structure
  with pointers to predecessor and successor
• Each node is assigned an identifier in a limited
  space
• Hash the ComponentID to store and query data
• Store component data into a framework node that
  is the successor of the hash of the component
  type
• One hop queries of any data item provide low
  latency

7
CCALoop Design
Hash Values 26 - 50
50
Hash Values 1 - 25
75
25
Hello Component
Hash Values 51 - 75
Hash Values 76 - 100(0)
0
Hash(Hello Component) 12
8
CCALoop Design

• Based on the hash value, each data item maps to
  the node that is the successor in the ID space
• Hence this node is "responsible" for a
  component's data, even though the component
  instance may be physically present elsewhere
• Thus we spread the load across the network by
  having each node store information about a
  fraction of the total data items

9
One Hop Queries

• It takes just one hop across the ring to reach
  the framework node that has the required
  information
• Same latency as master/slave approach
• To enable one hop lookup each node in the ring
  has knowledge about all the other nodes
• We assume that the framework nodes will not be
  entering and leaving the system at a rapid rate

10
Example Query Scenario
Hash Values 26 - 50
50
Hash Values 1 - 25
75
25
25
B
lookup(B)
0
Hash Values 51 - 75
Hash Values 76 - 100(0)
Say Hash(B) 66
11
Slice Leader Mechanism

• The total ID space is divided into a number of
  slices
• Each slice has a slice leader (if that slice has
  nodes in it)
• Other nodes in the slice (cohorts) communicate
  through the slice leader to broadcast messages to
  the entire network

12
Slice Leader Mechanism

• ID Space 100
• Number of Slices 3

50
63
38
25
75
13
88
0
7
13
Message Broadcast
50
63
38
25
75
13
88
0
7
Message originates at node 7.
14
Fault Tolerance

• Fault tolerance is achieved by replicating the
  data in it's k successors
• In this way when a node fails, the successor will
  be able to take the load of the dead node
• Requires no adjustment in the querying mechanism

15
Summary

• Framework scalability may become an issue for
  distributed frameworks
• Larger simulations
• Numerous computing resources
• Parallel components
• A more sophisticated mechanism (in CCALoop) to
  organize distributed frameworks yields
• similar latency
• scalability and fault tolerance

16

• Questions / Comments ?