ONOS的發(fā)布直面OpenDaylight進(jìn)行挑戰(zhàn)洋只，直接將SDN領(lǐng)域兩大陣營（運(yùn)營商和設(shè)備商）的競爭瞬間升級粪般，之所以O(shè)NOS能做到這一點(diǎn)，首先夫凸，ONOS的定位就是要為運(yùn)營商提供敏捷和靈活的大規(guī)模部署能力甜攀，避開了設(shè)備商圍繞著OpenDaylight展開的品牌保衛(wèi)戰(zhàn)秋泄。另外，ONOS實(shí)現(xiàn)了高可用规阀、可擴(kuò)展的系統(tǒng)設(shè)計(jì)方案恒序，基于此基礎(chǔ)上對系統(tǒng)的層次結(jié)構(gòu)以及網(wǎng)絡(luò)實(shí)體進(jìn)行高度抽象，這種優(yōu)秀的設(shè)計(jì)和高度的抽象保障了系統(tǒng)的演進(jìn)和能夠被優(yōu)化得更快更有效姥敛。這篇文章主要探尋ONOS在HA和Scale-out的設(shè)計(jì)上的一些蛛絲馬跡。
首先回憶一下SDN定義的三個特性：控制平面和數(shù)據(jù)平面的分離瞎暑、邏輯上集中控制彤敛、開放的編程接口，然后再看ONOS的系統(tǒng)架構(gòu)了赌，可以看出ONOS的架構(gòu)與這三個特性清晰的對應(yīng)墨榄。如圖1所示，在南向接口層勿她，采用協(xié)議插件以實(shí)現(xiàn)控制平面與數(shù)據(jù)平面的分離袄秩；在北向接口層，提供一套應(yīng)用編程接口以實(shí)現(xiàn)網(wǎng)絡(luò)的可編程性的應(yīng)用接口逢并；在東西向的擴(kuò)展上之剧，通過分布式集群的方式以實(shí)現(xiàn)邏輯上集中控制。
我們在SDN系統(tǒng)中討論的當(dāng)網(wǎng)絡(luò)系統(tǒng)一旦涉及分布式砍聊，其復(fù)雜性就會急劇上升背稼。一方面，在分布式情況下玻蝌，系統(tǒng)中數(shù)據(jù)又呈現(xiàn)不同的狀態(tài)和特性蟹肘，比如對數(shù)據(jù)的一致性词疼、實(shí)時性的需求不同，在性能和可用性方面做更多的工作帘腹；另一方面贰盗，需要考慮系統(tǒng)容錯（單點(diǎn)故障）、災(zāi)難恢復(fù)和系統(tǒng)擴(kuò)展（節(jié)點(diǎn)的增加/刪除）阳欲，因?yàn)橄到y(tǒng)中任何一個節(jié)點(diǎn)的狀態(tài)變化舵盈，需要所有其他節(jié)點(diǎn)做相應(yīng)的調(diào)整。
一致性主要分為兩種類型胸完。一種是強(qiáng)一致性书释，其要求當(dāng)一個實(shí)例更新網(wǎng)絡(luò)狀態(tài)時任何實(shí)例隨后的讀操作都返回最近更新的數(shù)值；另一種是最終一致性赊窥，當(dāng)系統(tǒng)保證如果沒有新的狀態(tài)更新時爆惧，最終所有的實(shí)例都能獲得最后的更新保持最終狀態(tài)一致，中間允許讀取操作延后一段時間锨能。兩者比較而言扯再，最終一致性是一種特殊的弱一致，而強(qiáng)一致性將導(dǎo)致分布式數(shù)據(jù)管理的復(fù)雜性和延時址遇。
在ONOS系統(tǒng)中熄阻，如?表1所示，Distributed?Core模塊負(fù)責(zé)狀態(tài)管理倔约，進(jìn)行拓?fù)渫貉场⒁鈭D、鏈路資源等存儲管理浸剩，這些數(shù)據(jù)屬性可根據(jù)ACID和BASE(Basically?Available,?Soft-state,?Eventual?consistency)的性質(zhì)進(jìn)行劃分钾军。根據(jù)這些數(shù)據(jù)的特性，可以參用不同的協(xié)議來滿足不同的需求绢要。
強(qiáng)一致性要求數(shù)據(jù)在某個節(jié)點(diǎn)更新后吏恭，在這之后其它副本節(jié)點(diǎn)上獲得該數(shù)據(jù)最新的更新，這種可以通過分布式事務(wù)協(xié)議(Paxos)來實(shí)現(xiàn)重罪，例如分布式鎖樱哼。在對Switch-Controller映射關(guān)系進(jìn)行更新時，必須是強(qiáng)一致性的剿配，示意圖如圖2所示搅幅；弱一致性保證數(shù)據(jù)在一定時間窗口之后可以讀到更新的數(shù)據(jù)，存在“不一致窗口”呼胚。最終一致性是弱一致性的一種特例盏筐，保證客戶端能夠讀取到某操作對系統(tǒng)特定數(shù)據(jù)的更新，“不一致性窗口”的大小依賴于系統(tǒng)負(fù)載砸讳、副本數(shù)琢融。最終一致性模型又包括Causal Consistency(因果一致性)界牡、Session Consistency(會話一致性)等模型的劃分，像如圖3所示的網(wǎng)絡(luò)狀態(tài)最終一致性就是一個典型場景漾抬，在初期的ONOS版本中主要可以通過Gossip協(xié)議實(shí)現(xiàn)宿亡，使用了基于anti-entropy實(shí)現(xiàn)。
ONOS在系統(tǒng)的可用性和可擴(kuò)展性方面做了大量工作纳令。我們知道挽荠，單一節(jié)點(diǎn)的處理能力有限，例如計(jì)算資源和數(shù)據(jù)流量等方面會成為瓶頸平绩，而且會形成網(wǎng)絡(luò)的單點(diǎn)故障圈匆。為了提高系統(tǒng)的可用性，避免在系統(tǒng)某一個節(jié)點(diǎn)發(fā)生故障捏雌，導(dǎo)致系統(tǒng)無法正常運(yùn)行跃赚，這時就需要更多的副本(Replica)節(jié)點(diǎn)。當(dāng)系統(tǒng)中存在多個副本時性湿，系統(tǒng)需要保證副本數(shù)據(jù)的一致性纬傲。ONOS根據(jù)其數(shù)據(jù)的不同性質(zhì)，采取不同的同步和復(fù)制策略：全復(fù)制（Fully Replicated）肤频、主從復(fù)制（Master-Slave Replicated）和分片（Partitioned/Distributed）叹括。如圖4所示，Network Toplogy是實(shí)時性要求不高的數(shù)據(jù)宵荒，利用gossip協(xié)議汁雷，采用樂觀復(fù)制的方式在各個節(jié)點(diǎn)進(jìn)行同步。
實(shí)際上ONOS從prototype 1到prototype 2在分布式管理上有了很大變化报咳，比如用Hazelcast取代zookeeper的一些職責(zé)侠讯，而在onos 1.1.0版本中，使用Raft替代Hazelcast少孝。因此這篇文章只是初步的了解ONOS系統(tǒng)在分布式構(gòu)建下的一些數(shù)據(jù)特性继低，以及如何保證數(shù)據(jù)一致性所采用的算法熬苍、協(xié)議稍走。這里我們不禁會提出另外一個問題：為什么不用Zookeeper，而選擇了Hazelcast?最后又選擇了Raft?
想要和本文作者進(jìn)行問題交流可以加入交流群：194240432
