除了分發(fā)數據，ONOS集群還要負責以下的任務：
1.檢測和處理集群節(jié)點的加入和離開（由Cluster Subsystem管理）
2.為每一個設備提供一個主Controller
ONOS集群協調的一個重要工具便是Store，Store生成事件，事件被分布式儲存持久化，在集群中共享。
根據具體服務的需求，儲存的內容可以有不同的特征，如強一致性或最終一致性，這使得每個服務的儲存根據需求采用合適的分布機制。
目前ONOS主控部分采用Hazelcast以達到強一致性，而Device、Link等部分的管理使用樂觀的復制技術輔以gossip協議以確保最終一致性。
如果兩個不同節(jié)點上的子系統是相同的，子系統將會直接通過Store與另一個進行同步。但是同步的只是一部分的狀態(tài)，如，對于DeviceStore，它只知道設備的狀態(tài)而不了解其他無關的信息。目前除了拓撲管理這部分，其他所有服務都要訪問分布式儲存。
下圖展示了兩個子系統間的同步：
事件排序：
ONOS使用一個類似向量時鐘的手段以達到最終一致性。
Q：什么是向量時鐘？
A：向量時鐘是一種在分布式環(huán)境中為各種操作或事件產生偏序值的技術，它可以檢測操作或事件的并行沖突，用來保持系統的一致性。
在ONOS中，被DeviceStore和LinkStore所使用的邏輯時鐘（logical clock）實際上是一個設備自發(fā)現以來的主控權交接數組成。同時本地還有一個順序數字，每觀察到一個事件就遞增一次。至于HostStore則依賴于系統時間，但由于Host對象的特性，阻止了他們被特定的設備所綁定。
集群管理：
Cluster subsystem要處理的任務有：
目前ONOS主要依靠Hazelcast實現這部分的功能。
設備控制管理：
設備可以自由地連接到一個或多個集群中的節(jié)點，node可以有以下幾種角色：
這三種角色對應OpenFlow中的NONE、SLAVE和MASTER角色。ONOS中的mastership subsystem負責保證在給出的任意時刻，每一個設備都只有一個MASTER，而其他的則為STANDBY或NONE狀態(tài)。
節(jié)點控制周期：
一個node一開始可能是NONE角色。現在會有如下幾種情況：
1.設備沒有master綁定
2.有一個控制channel連接到設備上，并成為其master。若后面有其他node發(fā)現該設備，如果node與設備
間有連接，則成為STANDBY，否則為NONE。
如果面臨下面幾種情況，已經擁有的角色可能會被改變：
1.人為干預：管理員手動為設備設置角色
2.從設備斷開：node與設備間的控制channel斷開
3.從集群中斷開：集群分裂為兩個部分
MastershipManager通過角色的放棄（relinquishment）和再選（reelection ）確保每個設備至多有一個master。并且確保如果一個node無法正確處理設備時不參加reelection。
角色放棄：
如果遇到以下狀況，node會放棄其角色并回到NONE：
1.與設備斷開，或設備失效
2.當集群分裂時，為較小的集群的成語
3.人為設定，強制修改其角色為NONE
4.一致性檢查的失敗，如OpenFlow設備對RoleRequest返回一個錯誤
重新選舉：
如果遇到以下狀況，會重新進入選舉機制：
1.一個Master的失效（如放棄角色）
2.Master node與設備間斷開連接
3.人為對master的降級，降到STANDBY或NONE
候選節(jié)點是從現有的standby節(jié)點中選擇的，節(jié)點根據NodeID排序，這樣是為了方便放棄角色的節(jié)點能直接選擇下一個節(jié)點成為候選節(jié)點。候選節(jié)點可以選擇成為master，或選下一個候選節(jié)點。同時ONOS提供了機制去阻止無限選舉的問題。
處理集群分裂的問題：
如果集群分裂為兩個不同尺寸的部分，位于較小的集群的nodes會放棄自己的角色（或者無法放棄角色）。而位于較大的集群的node會強制為其master位于小集群的設備執(zhí)行改選。但目前ONOS無法處理兩個相同尺寸的，并且依然連接到網絡的集群。
思考：
ONOS在設備管理上的選舉機制基本上和Raft算法類似，在Raft同樣也存在三個角色，follower，leader，candidate。這樣的選舉機制理解起來非常容易（比PAXOS容易多了）。
通過node間不同狀態(tài)間的轉換，確保每一個設備都能有一個主控node，大大地提高了系統的可靠性。
至于ONOS中通過事件來同步狀態(tài)，這種事件驅動的設計在某種程度上比起命令式的更有優(yōu)勢。如果節(jié)點間不是通過傳播事件而是單純靠RPC調用交互，在效率和穩(wěn)定性上一定會打折扣。
對于分布式系統來說，Actor是一種可行的架構。ONOS目前的架構一定程度上有Actor模型的影子，關于Actor模型，可以參考這篇資料：
http://www.infoq.com/cn/articles/reactive-cloud-actors，這篇資料也介紹了響應式架構的優(yōu)點。
而ONOS通過分布式儲存保存事件，則是另一種能提高穩(wěn)定性的手段。LMAX（一種新型零售金融交易平臺）的架構就實現了這一點：
“使用基于內存的模型有一個重要問題：萬一崩潰怎么辦？電源掉電也是可能發(fā)生的，“事件”概念是問題解決的核心，業(yè)務邏輯處理器的狀態(tài)是由輸入事件驅動的，只要這些輸入事件被持久化保存起來，你就總是能夠在崩潰情況下，根據事件重演重新獲得當前狀態(tài)。很明顯，ONOS通過持久化事件，可以獲得更高的穩(wěn)定性，實為明智的選擇。
總結：本文介紹了ONOS集群管理的多個方面，并對其設計進行了思考。希望本文能讓各位在了解ONOS的內部機制的同時，領略到其設計的巧妙之處。
作者簡介：何智剛，2015至今，現為廣東的一名在校高三學生，在學習之余，主要研究Docker,OpenStack，SDN，對各種領域都有所涉獵，目標是邁向full stack。
京公網安備 11010502049343號