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，你們在使用中，能夠注意降級，避免浪費時間定位。