SDN & OpenStack漫談(上)

首先,這片文章初衷是為了自我總結,我不會從感情上偏袒其中某個解決方案,但我確實有自己的Preference和對未來技術發展的看法。

從真正開始參與Neutron開發,已經有近2年的時間,起初的半年內(Icehouse周期里),無時無刻不在修復Neutron在生產環境中發現的各類Bug,其中有一些核心的問題處理比較費時,甚至至今也沒有一個很好的解決方案。

1. DB模塊的穩定性和性能

眾所周知,OpenStack所有的數據持久化(除了Ceilometer外),全部依賴官方推薦的MySQL(包括Percorna、MariaDB等),但是開源關系型數據庫引擎的擴展性一直都是問題,從生產環境監控中可以很容易看到,Neutron對數據庫的讀寫壓力,在OpenStack所有組件中,僅次于Nova(Keystone可以通過內存數據庫來緩解75%以上的壓力)。其中主要是三個部分的原因,一方面數據庫引擎單點或者HA都無能解決擴展性問題,當Neutron-server進程越來越多時,就會出現,雖然有Galera集群方案,但其事務處理性能一直都是瓶頸,而且樂觀鎖機制也會導致API失敗(Nova有db-retry,Neutron在那個時候還沒有)。第二個方面,是SQLAlchemy框架本身的限制,Python社區一直都是松耦合的純開源社區,所以導致很多企業級應用所必須的框架,沒有得到企業級的維護,其中首當其沖就是SQLAlchemy,這個Python世界里排行第一的ORM解決方案,并不是一個優秀的性能出眾的ORM方案(至少和我在Java世界里使用的hibernate,各方面都差了不止一截),記得其在0.90-0.99的每個版本都存在或多或少的Bug沒有修復,而且它的ORM引擎對SQL本身的優化也不是特別到位。第三個方面是Neutron社區,一直以來都存在錯用SQLAlchemy的情況,在事務處理過程中使用RPC引起不必要的事務內協程切換,間接增加無謂的數據庫引擎長時間維護事務的壓力,大規模環境下經常導致事務Timeout、Deadlock等情況。這些情況集中于ML2和L3RouterPlugin插件的DB模塊,每個Release都有大量的Race Condition曝出,然后就是Case by Case去修復,雖然這種情況自從Icehouse曝出多達10-20個同樣的問題后,慢慢隨著Juno、Kilo已經修復了大多問題(本人也參與討論和修復了其中的幾個Bug),但是,由于初期設計失誤導致的這種情況,在后期,卻需要200%-300%的時間去分析和修復,讓人汗顏。

2. RPC系統的穩定性和性能

Neutron的控制平面是基于RPC實現的,官方推薦基于AMQP0.9的RabbitMQ方案,但是大規模環境下,RabbitMQ集群的擴展性也成為了障礙,雖然存在Kernel調優和Ram Node-Disk Node的優化方案,但一方面RabbitMQ本身對于Devops是黑盒,其次官方的指南在當時并不清晰(后期官方也在不斷完善Best Practice之類的文檔)。為了處理當時的生產環境,切換到了基于ZeroMQ的分布式消息隊列,在Neutron項目中替換了RabbitMQ的方案,確有奇效。

關于這個方案,在Vancouver峰會上我有一個演講,詳細描述了一個新的分布式消息隊列系統。當前,社區除了官方推薦能在小規模Region穩定運行的RabbitMQ,oslo.messaging團隊正在發展三個更有前途的希望能夠穩定運行在大規模環境的RPC驅動,分別是ZeroMQ、Kafka、AMQP1.0(記得是基于Apache Qpid dispatch router實現的)。

3. Eventlet本身

Eventlet是OpenStack依賴的greenthread管理庫,它的優點是開發模型簡單,能有效重用iowait時的計算資源,缺點是缺少細粒度的調度控制。在OpenStack世界里,需要顯式調度的時候,需要使用eventlet.sleep。

但是基于iowait的調度粒度太粗。某些情況下,我確實需要在iowait下禁止當前協程切換呢?還有些情況下,我需要基于優先級的調度呢?在某些特殊情況下,我需要搶占式調度呢?對于大型系統來說,開發模型簡單易學,隱藏了大量細節,并不是好事。

4. 集群資源協調問題

(1)Scheduler

在Neutron中,存在一個并不是特別起眼的模塊,Scheduler,這個模塊負責把Neutron core Resource和Agent進行綁定和解綁,也就是把資源調度到不同的Agent上去配置。這個Scheduler目前常用的是DHCP、L3、LB(負載均衡)。這個模塊存在一個較大的缺陷,就是每個調度器都是獨立運行,其中沒有任何資源協調,導致在生產環境下,我即便是有針對性地實現了更細粒度調度算法,也無法使得不同的調度器間進行交互,實現更高層次的資源統一調度(比如,把一組資源統一調度到同一臺Host,當前無法實現,在寫DB時會出現Race Condition)。那個時候,我自己基于Redis開發了一個分布式鎖管理器,在各個調度器之間實現了統一的調度控制。

(2)AgentGroup

Neutron目前還沒有AgentGroup的概念,沒有辦法實現統一的集群管理和可靠的健康檢查機制(RPC+DB,只能算Demo)。

基于以上兩個問題,都是由于Neutron項目內不存在Cluster Coordination機制導致(雖然我實現了一個,但并不通用,當時還沒有Tooz),這個機制目前已經有了一個BP(通過Tooz實現,但是只有我覺得可以+1,其他Reviewer并沒有反饋),而且其實Nova社區也有了ServiceGroup的參考實現,但是Neutron社區方面卻一直Delay,不知道是因為Core Team把握不準,還是覺得這個功能比較復雜,要放到M周期討論。

5. Agent Loop、External Commands

Neutron中最常用的(User Survey調研占到75%的案例)是Openvswitch和Linuxbridge,其中的Agent框架都是基于Daemon-loop的輪詢機制,這套機制在大規模生產環境下,基本不可用,因為一次輪詢的時間太長,導致一些需要立即更新的端口配置延時到下一個輪詢周期,對于任一端口配置錯誤都會導致full-sync,系統開銷極大。另外,所有對于虛擬網絡設備的配置都是通過Subprocess調用外部Command的方式,導致Host Kernel需要維護大量并發的Subprocess,帶給Host Kernel很大的壓力。幸好在Liberty周期里,已經有人在實現基于事件的Callback機制,并且我也聯合另一個Neutron開發者向社區提出了使用Netlink Library Call代替Subprocess的技術方案,還在初期討論過程中,但是從Icehouse到Liberty,確實夠久的。

當然,除了處理Neutron的一系列事故外,我還在思考這么一個問題,就是Neutron的SDN方案,到底該如何發展?當前的情況是,不停地修Bug,平均一個BP的引入會同時帶來10+的Bugs(話說回來,DVR的引入帶來了30+的Bugs,給HP和Review BP的人狠狠點贊)?OpenStack提供了一個廣闊的開放的平臺,定義了業界認可的API集合,但是,就如同存儲技術需要Domain Knowledge,網絡技術同樣需要,當前Neutron除了其Plugin框架之外的實現,更多是Reference Design,而不是大規模生產環境下的專用系統。

在這個時候,也有思考過SDN和OpenStack的關系。

1. Neutron到底是不是實現了SDN?

這個問題不是我拋出的,而是去年就有很多云計算架構師和網絡架構師,包括一些業界專家一起在QQ群里論戰。其實這個問題,需要從兩個角度去看。第一,從云計算技術的角度,Neutron實現了租戶網絡拓撲的自定義,確實是SDN思想的體現。第二,從網絡技術的角度看,Neutron僅僅是實現了網絡通路(保證網絡是通的,汗),還沒有針對流量的細粒度管控,職責也沒有非常清晰地分離,與現實世界里大量專業的SDN系統所實現的網絡功能相比,確實差了很遠,所以要說Neutron是SDN的初級起步階段也未嘗不可,所有特別是很多業界的網絡專家對Neutron的實現不屑一顧也情有可原。最新Neutron社區主導的項目,像Dragonflow、RouterVM、ML3,以及與外部SDN開源方案的互動更為頻繁(OpenDayLight、OVN等),可以看出OpenStack也在朝好的方向努力。

2. SDN技術如何定位?

有網絡的地方,就可以有SDN發揮的余地,在我眼里,SDN技術所能應用的領域,囊括了整個CT領域,從范圍上講,包含衛星網、全球互聯網、骨干網、城域網、園區網、最后100M接入網,局域網;從傳輸介質上講,包含雙絞線、光纖(單模、多模)、同軸電纜、無線通信(微波、Wifi、2/3/4/5G移動網)所形成的各類網絡;當然還包括IT領域的DCN(數據中心網絡)、DCI(數據中心互聯),NFV領域,以及在未來DT領域會大力發展的物聯網、傳感器網絡等等。

云計算網絡(比如OpenStack Neutron)環境僅僅是SDN眾多北向應用中的一個,不需要談到SDN必談云。離開了云,SDN技術還是可以在其它領域發亮發光,反倒離開了SDN,云就更加虛無縹緲了。

本文轉載自:http://www.infoq.com/cn/articles/sdn-openstack-part01

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容