![](https://csdnimg.cn/release/download_crawler_static/12159017/bg4.jpg)
The ClusteringConfiguration represents information about the cluster. The information it provides
would roughly be the following:
What are the members in the cluster?
Which shards live on each node?
What data goes in each shard?
The ClusteringService would have the following responsibilities:
Read the cluster configuration. Where it reads the cluster configuration from should not
matter. Initially, we could even read the configuration from the file system. Over time, we could
have a "primary" node come up with a cluster configuration, and distribute it to the other
Resolve the node name to the actual host name/ip.
Maintain a registration of components that are interested in being notified of member status
The DistributedDataStore would have the following responsibilities:
Implement the DOMStore so that we could replace the InMemoryDataStore with the
Create the local shard actors in accordance with the cluster configuration.
Create the listener wrapper actors when a consumer registers a listener.
which contains some of the data in the system. A Shard being an
actor, communication with it would be by means of messages. The messages passed to a shard
would be very similar to the operations on the DOMStore interface.
in accordance with akka-persistence, it is a special actor which
message will log it to a journal. This journal along with snapshots would
be used as a method to recover the state of the DataStore. The state of the Shard would be
maintained in an InMemoryDataStore object.
The MD-SAL DataStore supports a three phase commit. The Shard, therefore, also provides the
functions of the ThreePhaseCommitCohort.
A ShardTransaction would be an actor which wraps an InMemoryDataStoreTransaction. Any
operation that needs to be done on a transaction, namely, ""read"", ""write"", ""delete"", and
""ready"" would be fronted by the ShardTransaction. The ShardTransaction will also maintain the
state of any writes/deletes that happen on a transaction. This state will be called the
"transactionLog". The transactionLog would then be used during commits to persist a transaction to
a journal. The journal will be written onto the disk using the persistence module of Akka. The
journal will then be used when a controller shards up to reconstruct the state of a shard.
The TransactionProxy will hold a reference to a collection of remote ShardTransaction actors, and
when returned to the consumer of the DistributedDataStore, could be used to invoke the
transaction operations on any remote ShardTransaction object depending on the instance identifier
The ListenerWrapper is an actor that would represent a local data change listener. It would be
created as a remote actor on the node where the Data Change registration is done.
The ListenerProxy represents a remote data change listener. When the local Shard issues a data
change notification, it is the responsibility of the ListenerProxy to send that data change notification
over to the remote ListenerWrapper actor.
A ShardCommitCohort would be an actor which wraps the InMemoryDataStoreCommitCohort. Any
operation that needs to be done on a three phase commit cohort, namely, "canCommit",
"preCommit", "commit", and "abort" would be fronted by the ShardCommitCohort.
ThreePhaseCommitCohortProxy
The ThreePhaseCommitCohortProxy holds a reference to a collection of ShardCommitCohorts. It
implements the DOMStoreThreePhaseCommitCohort interface and any operation done on the proxy
is invoked on every ShardCommitCohort in the collection.
The following OSGi bundles must be created:
MD-SAL InMemoryDataStore Implementation (This needs to be moved out of sal-dom-broker.)
MD-SAL Clustering Service API and implementation
MD-SAL Distributed DataStore, Remote Rpc Provider, and Remote Notifications
Cluster configuration defines the members (nodes) of the cluster and what lives within it. This configuration can be static or
dynamic. To make things simple, we could go with a static configuration for Helium. The configuration could be defined in a file or
files which could be put in the ODL distribution. When the ODL controller is started, the configuration file could be passed to it.
When the MD-SAL Clustering Service bundle comes up, it could look at which specific configuration needs to be loaded, reads it
from disk, and initializes itself.
Clustering configuration would be as follows:
OpenDaylight Controller:MD-SAL:Architecture:Clust... https://wiki.opendaylight.org/view/OpenDaylight_C...
4 of 17 11/23/18, 4:40 PM