運用OpenStack構建高速雲平臺

隨著OpenStack行業應用的開展，大家都在嘗試建設適應行業業務特點的OpenStack解決方案。IBM BlueBox團隊將分享一個基於OpenStack建立的高速傳輸視訊雲的解決方案。這個方案是通過整合OpenStack，Aspera和F5，最大限度解決視訊雲環境中高速資料傳輸的需求。Aspera是IBM公司的高速檔案傳輸軟體，其專利技術FASP能夠在WAN的傳輸環境下比傳統技術提升速率10x, 100x, 1000x。F5是著名的負載均衡器，在企業中有非常廣泛的應用。

我們的解決方案最初的來源於我們的客戶IoT的需求，對於怎樣把高速安全地將資料傳輸到雲中，資料傳輸是這類使用者在使用雲平臺中最基礎的要求，有資料才有業務。這讓我們意識到單純的雲平臺並不足以滿足所有的使用者，例如我們的解決方案是在基本的雲平臺上加入了快速傳輸的特性，能夠解決對大資料依賴的使用者需求，例如IoT、大資料分析平臺、視訊雲平臺和媒體行業等等。例如視訊行業4K視訊資料量，無壓縮的4K視訊1分鐘的資料已經達到了9GB，而4K Apple ProRes格式的1分鐘資料量也達到了6GB。

表1

type	Speed in bps	Speed in Bps	1 minute size
Uncompressed raw	1.2Gbps	153.6MBps	9GB
4K Apple ProRes	0.88Gbps	110MBps	6.44GB

方案設計與架構

首先我們對Aspera的加速能力做了實際的測試，評估是否適合加入雲平臺。我們在IBM softlayer共有云平臺上申請了一臺虛擬機器，資料中心選在了加州聖荷西，用於部署aspera服務。在IBM公司內部的私有云平臺上申請了一臺200Mbps頻寬的虛擬機器作為aspera client，測試結果顯示，相同1GB檔案的下載，Aspera相對於FTP傳輸的加速達到了22.5倍。此外我們在國內公有云平臺騰訊雲上也申請了一臺100Mbps的虛擬機器，資料中心選擇的是廣州，加速達到了47倍。Aspera的加速能力非常好，即使是在美國和中國經過了GFW的情況，也能達到如此的效果。同樣，我們也做了極端網路環境的測試，就是在使用家庭網路比如電信頻寬非常有限而且共享情況下，經過VPN，加速依然達到了8倍。

圖1

圖2

在經過傳輸速度驗證之後，我們做了Aspera於IBM bluebox雲平臺的整合，Aspera支援多種儲存系統，包括物件儲存Swift的支援。我們的整合解決方案如圖，既是利用OpenStack的自動彈性可擴充套件的能力來保證Aspera傳輸速度的需求，從而加速資料快速的傳輸到雲平臺。整合之後的測試結果顯示，從美國（vm）傳輸資料與原生的swift client的方式對比，也有3~4倍的加速。

圖3

在我們的解決方案中，利用到的關鍵OpenStack元件，如圖4所示：

• Neutron LBaaS Service —— 提供Load Balance管理
• F5 LBaaS agent —— neutron lbaas service driver
• F5 BigIP ——　Load balance provider， 同時支援TCP/UDP協議的load balance
• Ceilometer 和 Aodh —— 計算資源和網路資源monitor, 和autoScaling Alarm支援
• Nova scheduler —— 自定義Filter保證Aspera的網路QoS
• Nova —— Aspera計算資源
• Neutron —— Aspera網路資源
• Swift —— Aspera儲存資源
• Heat —— Resource group管理和Autoscaling policy定義，可定義的Aspera使用者管理和License管理。

圖4

圖5展示的是詳細的技術架構。

Aspera Fasp專利技術用於傳輸加速到雲平臺。Neutron的L3 agent的Floatingip提供唯一的服務訪問入口。

F5則為Aspera service提供load balance功能， aspera instances作為neutron Lbaas pool的members， F5實現了neutron lbaas virtual ip, lbaas pool, healthmonitor。Ceilometer則負責監控和處理Aspera instances的incoming 和outgoing的流量，已經CPU記憶體的使用情況，提供自定義的alarm，出發AutoScaling。

Heat提供了Resource Group的編排能力，已經AutoScaling policy的定義。自定義的resource template可以實現aspera instance啟動後的配置，包括aspera使用者管理和aspera自定義的儲存配置以及license更新等。

圖5

挑戰及debug

我們的解決方案在實施過程中也遇到了很多問題，以下分享給大家我們遇到主要的困難以及debug的過程。

一個是我們在使用F5作為lbaas provider的時候，遇到了healthmonitor檢測member的狀態為down的情況，儘管member都是正常工作的，也都是可以正常訪問的。

我們在Network Controller和network namespace進行抓包分析圖6，發現F5能夠傳送ARP request，而Instance也傳送了APR reply，但是奇怪的是Reply並沒有被髮送到F5。

圖6

通過分析neutron code和f5 agent code發現，neutron為了降低廣播對L2的ARP responder做了優化，利用了linux Kernel vxlan mode的proxy ARP和FDB功能與l2population，使得ARP responder能夠請求只能傳送到已經建立了instance的compute節點，而不是所有的compute節點都會收到ARP responder。

但是F5 lbaas agent在port建立之後，傳送的fdb entry確實廣播模式的FLOODING_ENTRY = (‘00:00:00:00:00:00’, ‘0.0.0.0’)，即需要利用到網路二層的MAC學習能力。

很幸運的是，我們發現了community在Liberty版本有了新的配置，可以去選擇設定arp_responder flage去決定是否開啟arp responder。

另外一個就是Aspera網路服務質量的問題，對於資料傳輸服務來講，穩定可靠的網路頻寬是先決條件。而且需要具有nova scheduler去支援instance的排程到具備可用頻寬的節點。很遺憾在我們做了調研之後，並沒有如上個問題那麼幸運找到可用的code patch。雖然Mitaka版本Neutron已經有了可定義的QoS，但是依然沒有對應的排程測率的實現。所以我們自主實現了，instance network QoS和基於網路頻寬的nova scheduler filter。我們的compute的虛擬化使用的是KVM，libvirt可以支援instance的網路頻寬的定義。所以我們從這點出發，我們實現了基於flavor（圖7）和host aggregate （圖8）的filter，從而能夠將指定的hosts作為網路頻寬提供的instace的network QoS.

圖7

圖8

最後一個問題就是Neutron LBaaS服務對Load Balance的支援，到目前為止Neutron LBaaS是不支援UDP協議的，但是Aspera服務卻需要TCP/UDP兩種協議同時支援，所幸的是F5的功能是支援TCP/UDP協議的，因此我們對F5 LBaaS agent做了code patch，滿足了Aspera service的特殊需求。

作者簡介：
任敏敏，目前就職於IBM，主要負責IBM雲平臺產品開發和運維工作，OpenStack社群專案的開發人員，具有豐富的OpenStack開發和運維經驗。