This content was created for the Hydrogen release and is out-of-date and is considered deprecated. It is unlikely to be updated in the future either. Information here should be taken with that in mind. For more up-to-date information see: OpenDaylight Controller:Clustering
Latest cluster setup information is now maintained here
Setting up the cluster
The setting up of an ODP controller cluster has the following prerequisites:
- Two or more hosting machines which can run or host a controller
- Ensure that the machines, either virtual of physical, have IP connectivity among them, and have no firewalls blocking ports 7800, 12001 <some others TBD>
Once the prerequisites are met to set up the cluster:
- Elect one or more nodes to be a supernode. The clustering architecture of ODP is built to mimic the P2P networks. As the cluster nodes do not know each other, they need a way to meet and greet the others. Those nodes that perform the meet and greet functionality are called the supernodes.
- Once the supernodes are chosen, make sure to start those nodes first by running the controller with the command line:
- Once the supernodes are started, start the other nodes using the same command as in Step 2.
At this point, the cluster will be set up and running. The members of the cluster can come and go at anytime. By definition, any new node can enter the cluster assuming that at least one of the supernodes is reachable. The supernodes are only used during the initial phase to know the nodes with which a controller must form a cluster; after that phase, the controller nodes would create a full mesh with the N-1 peers in the network.
Access the cluster from the Northbound REST
From the Northbound-side, the cluster will be accessible via REST APIs. REST being stateless in nature, each request can land in any controller in the cluster, in fact it i-sides suggested to front end the cluster with an HTTP load balancer to spread the requests toward the cluster of controllers.
Access the cluster from Southbound-side
From the Southbound-side, the network elements connect to the cluster using the IP addresses of the single controller elements in order to spread the load. This is particularly true for protocols like OpenFlow (the only protocol plugin currently integrated). So, in a nutshell, each network element needs to be configured with the identity of the controller node for communication. For cases like OVSDB, where the controller cluster initiates the connection toward the network elements, the spread of the load can actually be controlled by the controller cluster itself. Documentation will be made available when this becomes available.