ONOS動態擴容面臨的難點與解決方案
一、ONOS的一致性保障
ONOS主要包括兩類一致性機制，最終一致性和強一致性，最終一致性采用樂觀異步復制和基于Gossip的熵減方式來實現，樂觀異步復制可以高效的實現最終一致，但是一旦集群中發生節點脫離集群或者重啟的情況整體集群就會出現越來越失序的現象，基于Gossip的熵減方案就是為了解決此類問題，集群中的節點定期(通常間隔三到五秒)地隨機選擇一個節點進行數據同步，大多數情況下，熵減互動是平常的，因為每個控制器已經知道發生在網絡中的每一個事件。 但是當一個控制器狀態稍微漂移時，這個機制很快就會檢測到這個狀態，并使控制器重新同步。 這種方法還具有快速將新加入的控制器和其他的控制器進行同步的好處。 新加入的控制器與現有控制器之間的***次熵減互動將很快實現節點同步，而不需要單獨的備份/發現機制。
在動態擴容的情況下，動態節點的加入會對最終一致性產生影響，表現為新的節點加入集群，在和其他節點的熵減交互以及樂觀復制中最終和整體集群達到一致。這部分涉及的子系統包括Device和Link子系統。
而Device，Link子系統也會影響到Topo子系統，所以在進行節點動態擴容時，新加入節點在實現最終一致的過程中如果不承載業務的話影響較小。
強一致性的保障通過Raft算法來實現，ONOS考慮到容錯和性能的通盤考慮，選擇了分區機制和備份冗余機制。
分區機制是指ONOS對任意一個支持強一致性的分布式原語(主要包括其分布式數據結構)支持分區機制，而在每一個分區中支持多個節點之間的備份冗余，實現了CAP理論的折衷性考慮。
二、ONOS邏輯時鐘
在分布式系統中時鐘是個重要的概念，ONOS選取了以MasterShip Term和本地事件序列號的方式來進行統計。其理論依據如下：
- 網絡控制器的控制離不開設備，所有的網絡事件都是最終都能關聯到設備上
- MasterShipTerm是全局強一致的，依賴這個數據做時鐘的可靠性高
- 控制器依賴從設備收上來的信息來發出網絡事件，而真正拋出事件的只有Master，Master維護著對應設備上報事件的序列號，在每一個Term周期內從0開始單調遞增
三、動態擴容對強一致性的影響
當前ONOS大部分子系統都采用的是強一致性的方式，包括：FlowRule, Host, MasterShip等，其中MasterShip是整體集群數的強一致，其他子系統是基于Partition內部節點的強一致。所以ONOS集群的宕機風險和Partition Member數量有關，如果Partition Member只有三個節點，那么兩臺設備宕機就會造成系統問題。
在節點動態加入集群的場景下，***的問題是要防止出現腦裂，所謂腦裂就是一個集群中同時出現兩個Leader的場景，在集群節點減少的情況下不會出現,但是在集群添加節點時會出現這種場景，如下圖所示：
在上圖所示的場景之下，假如新的Server先以新配置啟動，而舊的Server逐步以新配置運行，此時會存在新配置的大多數和舊配置的大多數共存的情況，操作不慎會導致集群存在兩個Leader進而腦裂的情況。
ONOS的raft算法采用Copycat實現，其支持動態節點的加入，但是這個方法不同于Raft論文中提到的兩階段添加的方案，而是采用了單節點添加方案來避免出現腦裂的情況，這樣使得方案更簡單但是相對操作會麻煩一些。另外在新加入節點開始進行數據同步時，業務要盡量避免寫入。以免影響讀寫性能。
四、ONOS帶狀態重啟
帶狀態重啟也是生產環境中非常重要的一點。ONOS大部分分布式數據結構都是支持持久化的，部分不支持的主要是最終一致性數據結構。 這其中ECMap必須配置持久性選項才能將條目寫入磁盤，否則在集群關閉時會丟失。
但是大多數分布式原語(強一致性)使用了Raft集群，并且它們是持久化的。 ConsistentMap，ConsistentTreeMap，DocumentTree，DistributedSet，LeaderElector以及這些基元的所有Async *版本都使用單個Raft分區或所有Raft分區。 這些原語有效地由持久的復制日志支持，該日志將從該/ data目錄中讀取，并在重新啟動群集時重播。
