https://www.sdnlab.com/19781.htmlhtml
控制器集群主要有两个子系统支撑，一个是Distributed Data Store，一个是Remote RPC Connector。Distributed Data Store作控制器集群的Data Store同步，而Remote RPC Connector负责远程过程调用，即当RPC请求到Follower时，Follower会将该请求转向Leader控制器，对于用户而言，由谁提供RPC返回值是透明的。
二、控制器集群是基于分布式编程接口库AKKA，而AKKA是基于actor模型实现的并发处理框架。基于事件驱动的并发处理模型，每个actor拥有本身的属性和操做，避免了一般状况下由于多个线程之间要共享属性（数据）。
三、数据同步分为DataStore与Remote RPC的数据同步，基本原理为先将操做的数据保存为一堆的快照，等操做确认无误后再提交至数据库
四、DataStore中有一个术语为Shard（数据树碎片），将数据库分为多个数据树碎片（shard），初始状态时包括inventory、topology、toaster、toaster，能够在distribution-karaf-0.3.3-Lithium-SR3/configuration/initial/module-shards.conf中看的这4个shard。每一个模块能够分布在不一样的shard上。各自的shard有各自的leader和follower选举结果，好比inventory的leader在vm1，而topology的leader在vm2上。
五、当inventory-leader的datastore数据发生变化时，会自动同步给其余follower。
六、Raft一致性算法选举过程状态图以下:
七、当北向REST API 发送一个RPC请求至控制器时，经过RPC路由，由Leader作出反馈，此过程对应用户而言是位置透明的。
八、集群的代码实现结构大体以下:
node
3、openflow与控制器集群
Opendaylight控制器支持两种版本的OpenFlow协议，OpenFlow 1.3和OpenFlow 1.0。在控制器集群中，二者的区别有：算法
一、OpenFlow 1.3
在OpenFlow的1.3中，每一个交换机被链接到属于集群的每一个控制器节点。交换机分配到如下每一个控制器节点角色之一：数据库
- Master----全部的同步和异步消息被发送到主控制器节点。此节点有交换机的写入权限。
- Slave----仅同步消息发送到该控制器节点。此节点只有交换机的读权限。
- Equal----当该角色被分配给控制器节点，该节点具备与主节点相同的特权。默认状况下，控制器首先链接到交换机时被赋予Equal的角色。
二、 OpenFlow 1.0
由于OpenFlow 1.0不支持角色，链接到集群的交换机任什么时候候只链接一台控制器节点，好比采用floating/virtual IP address形式。当交换机链接的控制器节点down机了，交换机会自动的链接到另外的控制器节点，固然这个控制器节点是被选举出来的Leader节点（做为inventory-operational-shard 的leader）。编程
就像OpenFlow 1.3同样，在控制器节点上的每个datastore被分红了shards碎片，其中的某一个shards碎片做为leader。经过配置floating/virtual IP address，交换机链接到inventory-operational shard leader 驻留的控制器节点（master node）。网络
三、 集群中的流表修改操做
in-memory datastores中有两种类型：config 和 inventory，同时在每个datastores都有四个shards驻留：default, inventory, toaster, and topology，注意修改流表会同时涉及config and operational datastore 的inventory碎片。并发
修改流表时：
1）增长流表的请求被路由到inventory-config-shard leader驻留的主控制器节点。
2）当inventory-config-shard leader收到流以后，leader会备份该流，而后提交到datastore。
3）当流被提交到datastore时会发出一个通知(notification)，同时增长流的RPC(远程过程调用)会发往remote RPC connector。注意：全部的交换机的RPC都是注册在了主控节点上（master node）。
4）Remote RPC connector定位出master node而且转发增长流的RPC到master node上。
5）当master node的RPC component接受到该增长流的RPC，会将该RPC转发至OpenFlow plug-in，OpenFlow plug-in将该RPC转发给交换机。
6）在此背景下，Statistics Manager统计数据管理器经过执行流按期轮询交换机，经过对交换机执行流量等统计数据的RPC。统计数据管理器仅在主节点上启用。
7）交换机对此RPC作出反馈（采用notifications），该notifications只发往master node。
8）当该notifications被接受到，Statistics Manager增长该流到inventory-operational datastore。app
四、经过Mininet模拟链接到odl集群中的相关命令
1）查看交换机链接了哪些控制器负载均衡
Java框架
sudo ovs-vsctl list CONTROLLER
| 1 |
sudo ovs-vsctl list CONTROLLER |
2）采用openflow1.3链接控制器
Java
sudo mn --topo single,3 --mac --controller=remote,ip=192.168.7.108,port=6653 --switch ovsk,protocols=OpenFlow13
| 1 |
sudo mn --topo single,3 --mac --controller=remote,ip=192.168.7.108,port=6653 --switch ovsk,protocols=OpenFlow13 |
3）步骤2）只是启动了mininet的1.3版本，还须要对交换机进行配置
Java
ovs-vsctl set bridge s1 protocols=OpenFlow13
| 1 |
ovs-vsctl set bridge s1 protocols=OpenFlow13 |
4）查看openflow1.3流表
Java
xterm s1 ovs-ofctl dump-flow s1 -O OpenFlow13
| 1 2 |
xterm s1 ovs-ofctl dump-flow s1 -O OpenFlow13 |
4、点滴记录
一、OpenFlow1.2 开始支持多控制器
OpenFlow 1.2引入多控制器的理念，但愿经过多个控制器的协同工做提升全网的可靠性。
-----OpenFlow交换机在其初始化时，即与一至多个配置好的控制器创建链接。多个控制器之间能够提供负载均衡能力和快速故障倒换，同时增长角色类消息用于控制器之间协商主备关系
-----控制器的角色在缺省状况下为EQUAL，在此状态下的控制器能够响应来自OpenFlow交换机发来的请求；控制器角色也能够设为SLAVE，在此状态下控制器只负责监听，不响应交换机发送的消息；另外，控制器还能够是MASTER角色，这种状态下的控制器行为与EQUAL相似，惟一的差别在于系统中只能有一台MASTER。
二、OpenFlow 1.3增长了两个controller-to-switch消息
-----Role-Request：用于控制器向其OpenFlow通道进行角色的设置或查询
-----Asynchronous-Configuration：用于控制器设置或查询异步消息的附加过滤器，通常用于多控制器的链接创建
三、mininet构建mininet大型网络集群
mn --cluster localhost,server1,server2
四、Li版SR2标记odl的集群bug，openflowplugin出现多台控制器同时操做交换机致使冲突的bug。
https://bugs.opendaylight.org/show_bug.cgi?id=4105
https://www.sdnlab.com/community/article/103
五、odl采用RAFT协议进行集群选举，而根据RAFT协议，三节点是可以进行集群部署的最小配置，也便是odl要实现HA，至少是三个节点。
六、从lithium版本开始，在karaf中，会存在odl-openflowplugin-nsf-services-li与odl-openflowplugin-nsf-services这样两种类似的feature，它们的内在区别就在于，-li后缀所标识的feature，是lithium版本针对于openflowplugin在helium版本上存在的问题而进行新设计后的实现，像EntityOwnershipService就只在新设计的openflowplugin被实现了。若是要测试新版本的openflowplugin，则要注意安装-li后缀的特性。
具体的作法就是，针对于一个由openflow:dpid所标示的of设备，每一个集群实例上的ofplugin都注册本身为candidate，利用raft的选主机制，选出一个ofplugin作为主，ofplugin获得升主通知后，就做为该设备的rpc owner，并经过openflow的role request消息设置本身为master，其余raft follower实例则设置本身为slave，这样就在必定程度上解决了不支持主备的问题。
entityowner这个服务是一个通用的服务，其余app也能够本身注册一个全集群惟一的entity，从而实现多集群实例下的选主操做，并在主故障时，处理新主实例的升主操做，提升app的可用性。具体的使用办法是在本身app的yang模型里，增长对entityownerservice的引用。
七、在验证过程当中，我遇到了bug4473这个lithum design中存在的不兼容ovs 2.4.0的table feature消息中的nxm扩展的问题，会致使of设备不能被加进到inventory数据库中，这个问题暂时还未被fix，你们在使用中，能够注意降级，避免浪费时间定位。