首先晶乔,這片文章初衷是為了自我總結(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è)很好的解決方案。
眾所周知晦墙,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)的)。
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é)步清,并不是好事要门。
在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)度控制涝婉。
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也在朝好的方向努力壁肋。
有網(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