首先晶乔，這片文章初衷是為了自我總結(jié)胀茵，我不會(huì)從感情上偏袒其中某個(gè)解決方案隆檀，但我確實(shí)有自己的Preference和對(duì)未來技術(shù)發(fā)展的看法。

從真正開始參與Neutron開發(fā)蒲讯，已經(jīng)有近2年的時(shí)間忘朝，起初的半年內(nèi)（Icehouse周期里），無時(shí)無刻不在修復(fù)Neutron在生產(chǎn)環(huán)境中發(fā)現(xiàn)的各類Bug判帮，其中有一些核心的問題處理比較費(fèi)時(shí)局嘁，甚至至今也沒有一個(gè)很好的解決方案。

1. DB模塊的穩(wěn)定性和性能

眾所周知晦墙，OpenStack所有的數(shù)據(jù)持久化（除了Ceilometer外）悦昵，全部依賴官方推薦的MySQL（包括Percorna、MariaDB等）晌畅，但是開源關(guān)系型數(shù)據(jù)庫引擎的擴(kuò)展性一直都是問題但指，從生產(chǎn)環(huán)境監(jiān)控中可以很容易看到，Neutron對(duì)數(shù)據(jù)庫的讀寫壓力抗楔，在OpenStack所有組件中棋凳，僅次于Nova（Keystone可以通過內(nèi)存數(shù)據(jù)庫來緩解75%以上的壓力）。其中主要是三個(gè)部分的原因连躏，一方面數(shù)據(jù)庫引擎單點(diǎn)或者HA都無能解決擴(kuò)展性問題剩岳，當(dāng)Neutron-server進(jìn)程越來越多時(shí)，就會(huì)出現(xiàn)入热，雖然有Galera集群方案拍棕，但其事務(wù)處理性能一直都是瓶頸，而且樂觀鎖機(jī)制也會(huì)導(dǎo)致API失斏琢肌（Nova有db-retry绰播，Neutron在那個(gè)時(shí)候還沒有）。第二個(gè)方面尚困，是SQLAlchemy框架本身的限制蠢箩，Python社區(qū)一直都是松耦合的純開源社區(qū)，所以導(dǎo)致很多企業(yè)級(jí)應(yīng)用所必須的框架尾组，沒有得到企業(yè)級(jí)的維護(hù)忙芒，其中首當(dāng)其沖就是SQLAlchemy，這個(gè)Python世界里排行第一的ORM解決方案讳侨，并不是一個(gè)優(yōu)秀的性能出眾的ORM方案（至少和我在Java世界里使用的hibernate，各方面都差了不止一截）奏属，記得其在0.90-0.99的每個(gè)版本都存在或多或少的Bug沒有修復(fù)跨跨，而且它的ORM引擎對(duì)SQL本身的優(yōu)化也不是特別到位。第三個(gè)方面是Neutron社區(qū)，一直以來都存在錯(cuò)用SQLAlchemy的情況勇婴，在事務(wù)處理過程中使用RPC引起不必要的事務(wù)內(nèi)協(xié)程切換忱嘹，間接增加無謂的數(shù)據(jù)庫引擎長時(shí)間維護(hù)事務(wù)的壓力，大規(guī)模環(huán)境下經(jīng)常導(dǎo)致事務(wù)Timeout耕渴、Deadlock等情況拘悦。這些情況集中于ML2和L3RouterPlugin插件的DB模塊，每個(gè)Release都有大量的Race Condition曝出橱脸，然后就是Case by Case去修復(fù)础米，雖然這種情況自從Icehouse曝出多達(dá)10-20個(gè)同樣的問題后，慢慢隨著Juno添诉、Kilo已經(jīng)修復(fù)了大多問題（本人也參與討論和修復(fù)了其中的幾個(gè)Bug）屁桑，但是，由于初期設(shè)計(jì)失誤導(dǎo)致的這種情況栏赴，在后期蘑斧，卻需要200%-300%的時(shí)間去分析和修復(fù)，讓人汗顏须眷。

2. RPC系統(tǒng)的穩(wěn)定性和性能

Neutron的控制平面是基于RPC實(shí)現(xiàn)的竖瘾，官方推薦基于AMQP0.9的RabbitMQ方案，但是大規(guī)模環(huán)境下花颗，RabbitMQ集群的擴(kuò)展性也成為了障礙捕传，雖然存在Kernel調(diào)優(yōu)和Ram Node-Disk Node的優(yōu)化方案，但一方面RabbitMQ本身對(duì)于Devops是黑盒捎稚，其次官方的指南在當(dāng)時(shí)并不清晰（后期官方也在不斷完善Best Practice之類的文檔）乐横。為了處理當(dāng)時(shí)的生產(chǎn)環(huán)境，切換到了基于ZeroMQ的分布式消息隊(duì)列今野，在Neutron項(xiàng)目中替換了RabbitMQ的方案葡公，確有奇效。

關(guān)于這個(gè)方案条霜，在Vancouver峰會(huì)上我有一個(gè)演講催什，詳細(xì)描述了一個(gè)新的分布式消息隊(duì)列系統(tǒng)。當(dāng)前宰睡，社區(qū)除了官方推薦能在小規(guī)模Region穩(wěn)定運(yùn)行的RabbitMQ蒲凶，oslo.messaging團(tuán)隊(duì)正在發(fā)展三個(gè)更有前途的希望能夠穩(wěn)定運(yùn)行在大規(guī)模環(huán)境的RPC驅(qū)動(dòng)，分別是ZeroMQ拆内、Kafka旋圆、AMQP1.0（記得是基于Apache Qpid dispatch router實(shí)現(xiàn)的）。

3. Eventlet本身

Eventlet是OpenStack依賴的greenthread管理庫麸恍，它的優(yōu)點(diǎn)是開發(fā)模型簡單灵巧，能有效重用iowait時(shí)的計(jì)算資源搀矫，缺點(diǎn)是缺少細(xì)粒度的調(diào)度控制。在OpenStack世界里刻肄，需要顯式調(diào)度的時(shí)候瓤球，需要使用eventlet.sleep。

但是基于iowait的調(diào)度粒度太粗敏弃。某些情況下卦羡，我確實(shí)需要在iowait下禁止當(dāng)前協(xié)程切換呢？還有些情況下麦到，我需要基于優(yōu)先級(jí)的調(diào)度呢绿饵？在某些特殊情況下，我需要搶占式調(diào)度呢隅要？對(duì)于大型系統(tǒng)來說蝴罪，開發(fā)模型簡單易學(xué)，隱藏了大量細(xì)節(jié)步清，并不是好事要门。

4. 集群資源協(xié)調(diào)問題

（1）Scheduler

在Neutron中，存在一個(gè)并不是特別起眼的模塊廓啊，Scheduler欢搜，這個(gè)模塊負(fù)責(zé)把Neutron core Resource和Agent進(jìn)行綁定和解綁，也就是把資源調(diào)度到不同的Agent上去配置谴轮。這個(gè)Scheduler目前常用的是DHCP炒瘟、L3、LB（負(fù)載均衡）第步。這個(gè)模塊存在一個(gè)較大的缺陷疮装，就是每個(gè)調(diào)度器都是獨(dú)立運(yùn)行，其中沒有任何資源協(xié)調(diào)粘都，導(dǎo)致在生產(chǎn)環(huán)境下廓推，我即便是有針對(duì)性地實(shí)現(xiàn)了更細(xì)粒度調(diào)度算法，也無法使得不同的調(diào)度器間進(jìn)行交互翩隧，實(shí)現(xiàn)更高層次的資源統(tǒng)一調(diào)度（比如樊展，把一組資源統(tǒng)一調(diào)度到同一臺(tái)Host，當(dāng)前無法實(shí)現(xiàn)堆生，在寫DB時(shí)會(huì)出現(xiàn)Race Condition）专缠。那個(gè)時(shí)候，我自己基于Redis開發(fā)了一個(gè)分布式鎖管理器淑仆，在各個(gè)調(diào)度器之間實(shí)現(xiàn)了統(tǒng)一的調(diào)度控制涝婉。

（2）AgentGroup

Neutron目前還沒有AgentGroup的概念，沒有辦法實(shí)現(xiàn)統(tǒng)一的集群管理和可靠的健康檢查機(jī)制（RPC+DB蔗怠，只能算Demo）嘁圈。

基于以上兩個(gè)問題省骂，都是由于Neutron項(xiàng)目內(nèi)不存在Cluster Coordination機(jī)制導(dǎo)致（雖然我實(shí)現(xiàn)了一個(gè)蟀淮，但并不通用最住，當(dāng)時(shí)還沒有Tooz），這個(gè)機(jī)制目前已經(jīng)有了一個(gè)BP（通過Tooz實(shí)現(xiàn)怠惶，但是只有我覺得可以+1涨缚，其他Reviewer并沒有反饋），而且其實(shí)Nova社區(qū)也有了ServiceGroup的參考實(shí)現(xiàn)策治，但是Neutron社區(qū)方面卻一直Delay脓魏，不知道是因?yàn)镃ore Team把握不準(zhǔn)，還是覺得這個(gè)功能比較復(fù)雜通惫，要放到M周期討論茂翔。

5. Agent Loop、External Commands

Neutron中最常用的（User Survey調(diào)研占到75%的案例）是Openvswitch和Linuxbridge履腋，其中的Agent框架都是基于Daemon-loop的輪詢機(jī)制珊燎，這套機(jī)制在大規(guī)模生產(chǎn)環(huán)境下，基本不可用遵湖，因?yàn)橐淮屋喸兊臅r(shí)間太長悔政，導(dǎo)致一些需要立即更新的端口配置延時(shí)到下一個(gè)輪詢周期，對(duì)于任一端口配置錯(cuò)誤都會(huì)導(dǎo)致full-sync延旧，系統(tǒng)開銷極大谋国。另外，所有對(duì)于虛擬網(wǎng)絡(luò)設(shè)備的配置都是通過Subprocess調(diào)用外部Command的方式迁沫，導(dǎo)致Host Kernel需要維護(hù)大量并發(fā)的Subprocess芦瘾，帶給Host Kernel很大的壓力。幸好在Liberty周期里集畅，已經(jīng)有人在實(shí)現(xiàn)基于事件的Callback機(jī)制近弟，并且我也聯(lián)合另一個(gè)Neutron開發(fā)者向社區(qū)提出了使用Netlink Library Call代替Subprocess的技術(shù)方案，還在初期討論過程中牡整，但是從Icehouse到Liberty藐吮，確實(shí)夠久的。

當(dāng)然逃贝，除了處理Neutron的一系列事故外谣辞，我還在思考這么一個(gè)問題，就是Neutron的SDN方案沐扳，到底該如何發(fā)展泥从？當(dāng)前的情況是，不停地修Bug沪摄，平均一個(gè)BP的引入會(huì)同時(shí)帶來10+的Bugs（話說回來躯嫉，DVR的引入帶來了30+的Bugs纱烘，給HP和Review BP的人狠狠點(diǎn)贊）？OpenStack提供了一個(gè)廣闊的開放的平臺(tái)祈餐，定義了業(yè)界認(rèn)可的API集合擂啥，但是，就如同存儲(chǔ)技術(shù)需要Domain Knowledge帆阳，網(wǎng)絡(luò)技術(shù)同樣需要哺壶，當(dāng)前Neutron除了其Plugin框架之外的實(shí)現(xiàn)，更多是Reference Design蜒谤，而不是大規(guī)模生產(chǎn)環(huán)境下的專用系統(tǒng)山宾。

在這個(gè)時(shí)候，也有思考過SDN和OpenStack的關(guān)系鳍徽。

1. Neutron到底是不是實(shí)現(xiàn)了SDN资锰？

這個(gè)問題不是我拋出的，而是去年就有很多云計(jì)算架構(gòu)師和網(wǎng)絡(luò)架構(gòu)師阶祭，包括一些業(yè)界專家一起在QQ群里論戰(zhàn)绷杜。其實(shí)這個(gè)問題，需要從兩個(gè)角度去看胖翰。第一接剩，從云計(jì)算技術(shù)的角度，Neutron實(shí)現(xiàn)了租戶網(wǎng)絡(luò)拓?fù)涞淖远x萨咳，確實(shí)是SDN思想的體現(xiàn)懊缺。第二，從網(wǎng)絡(luò)技術(shù)的角度看培他，Neutron僅僅是實(shí)現(xiàn)了網(wǎng)絡(luò)通路（保證網(wǎng)絡(luò)是通的鹃两，汗），還沒有針對(duì)流量的細(xì)粒度管控舀凛，職責(zé)也沒有非常清晰地分離俊扳，與現(xiàn)實(shí)世界里大量專業(yè)的SDN系統(tǒng)所實(shí)現(xiàn)的網(wǎng)絡(luò)功能相比，確實(shí)差了很遠(yuǎn)猛遍，所以要說Neutron是SDN的初級(jí)起步階段也未嘗不可馋记，所有特別是很多業(yè)界的網(wǎng)絡(luò)專家對(duì)Neutron的實(shí)現(xiàn)不屑一顧也情有可原。最新Neutron社區(qū)主導(dǎo)的項(xiàng)目懊烤，像Dragonflow梯醒、RouterVM、ML3腌紧，以及與外部SDN開源方案的互動(dòng)更為頻繁（OpenDayLight茸习、OVN等），可以看出OpenStack也在朝好的方向努力壁肋。

2. SDN技術(shù)如何定位号胚？

有網(wǎng)絡(luò)的地方籽慢，就可以有SDN發(fā)揮的余地，在我眼里猫胁，SDN技術(shù)所能應(yīng)用的領(lǐng)域箱亿，囊括了整個(gè)CT領(lǐng)域，從范圍上講杜漠，包含衛(wèi)星網(wǎng)极景、全球互聯(lián)網(wǎng)、骨干網(wǎng)驾茴、城域網(wǎng)、園區(qū)網(wǎng)氢卡、最后100M接入網(wǎng)锈至，局域網(wǎng)；從傳輸介質(zhì)上講译秦，包含雙絞線峡捡、光纖（單模、多模）筑悴、同軸電纜们拙、無線通信（微波、Wifi阁吝、2/3/4/5G移動(dòng)網(wǎng)）所形成的各類網(wǎng)絡(luò)砚婆；當(dāng)然還包括IT領(lǐng)域的DCN（數(shù)據(jù)中心網(wǎng)絡(luò)）、DCI（數(shù)據(jù)中心互聯(lián)）突勇，NFV領(lǐng)域装盯，以及在未來DT領(lǐng)域會(huì)大力發(fā)展的物聯(lián)網(wǎng)、傳感器網(wǎng)絡(luò)等等甲馋。

云計(jì)算網(wǎng)絡(luò)（比如OpenStack Neutron）環(huán)境僅僅是SDN眾多北向應(yīng)用中的一個(gè)埂奈，不需要談到SDN必談云。離開了云定躏，SDN技術(shù)還是可以在其它領(lǐng)域發(fā)亮發(fā)光账磺，反倒離開了SDN，云就更加虛無縹緲了痊远。

本文轉(zhuǎn)載自：http://www.infoq.com/cn/articles/sdn-openstack-part01