OpenStack已經演變成一種被廣泛采用的云管理框架,這是顯而易見的。當openstack步入快速增長的軌道時，新一代的需求讓他們感受到，必須由有一個靈活可擴展的成熟的平臺來滿足。其中的一個要求是能夠監控在OpenStack數據中心發現的基于虛擬網絡結構的流量。
從概念上講，監控過程包括在網絡基礎設施的適當地點放置抽頭設備，并將它鏡像給流量分析儀。這些分析器可以看到相同的數據包通過這些網絡段，就像他們串聯在網絡中一樣。
一個邏輯抽頭裝置，可以簡單地使用端口鏡像功能的網絡轉換元件所組成，即使數據包穿過一個或多個交換機端口時，將它的一個副本的傳送到本交換機的另一個端口上。這種能力幾乎所有在用的物理交換機和虛擬交換機都支持。那么，它為什么仍然不能監測OpenStack虛擬網絡的狀態呢?
這個問題的答案在于了解基于云的虛擬化平臺的兩個重要網絡結構特點：多租戶和位置獨立性。前者允許可用資源和服務可以不同的用戶組之間共享。每個組被稱為一個租戶，擁有完全獨立的環境，以至于組中的成員都忽略了它們與其它租戶共同存在于一個環境的事實。
多租戶機制促使控制指令將以一種更加安全和私密的方式下發。舉例來說，租戶可以被允許創建和管理自己的虛擬網絡。至于位置的獨立性，主要是指將單個基礎設施組件的身份隱藏在虛擬化負載當中。這樣可以將虛擬機從一臺物理機動態遷移到另外一臺上面。位置獨立帶來的另一個同樣重要的，但也許不太贊賞的好處是提高了資源分配的效率。因此租戶們對他們的虛擬機運行在哪臺物理主機是毫無感知的。此外，屬于不同租戶的虛擬機可以放置在同一物理主機上。在這樣一個共享的生態系統中，它是使人感到，租戶沒有直接進入網絡底層，即由主機級的虛擬交換機，頂部的機架交換機等組成的交換矩陣。此限制避免了任何跨租戶數據泄露的可能性。不幸的是，這意味著這些交換機的端口鏡像能力也不可用。
說到流量監控在虛擬網絡支持的缺乏，OpenStack并不是唯一一個。其他的云解決方案，包括亞馬遜網絡服務(AWS)，也受上述原因的限制。然而，也有一方面優勢使得OpenStack能脫穎而出。那是開源技術!這給任何能夠和愿意引入新的能力和進入平臺的人，提供了一個機會。在Gigamon我們生活和呼吸的網絡流量的可見性，所以我們決定把它帶在自己身上，成為那個將指針向前的'人'。令我們驚訝和高興的是，我們很快就得知了，愛立信的項目組也在獨立地證明這個結論。我們的目標融合得非常完美，我們似乎很自然，也很適合我們共同解決這個問題。
我們的項目被稱為tap-as-a-service。它是一個平臺化的解決方案，設計作為Neutron的一個延伸，即OpenStack的網絡服務。TaaS可提供一個簡單的API，將使承租人(或云管理員)監測Neutron配置的網絡端口。租戶的界限分明是非常重要的，租戶只能監控自己的端口，不論是它的私人虛擬網絡或在一個共享的虛擬網絡上創建的任何端口。TAAS工作流始于tap-service實例的建立，并將有Neutron 端口為端口鏡像會話目的端口。監控虛擬機通常連接到這個端口，以消耗鏡像流量。接著，一個或多個抽頭流可以添加到tap-service實例。
一個tap流代表正在監控的一個(源)端口和一個tap-service實例之間的關聯。TAAS允許鏡像會話跨多個主機，通過遠程端口鏡像的特性，從而確保獨立保存的位置。
一個可參考的實施是今年早些時候完成的源代碼已經上傳到stackforge，OpenStack的孵化器，在一個專門的Git倉庫現在存在這個項目[ 1 ]。在溫哥華的最后一個OpenStack峰會(2015)，我們做了一個技術演示這方面的工作，包括現場演示流量使用TAAS [ 2 ]監測。該反應是非常積極的，從開發商和用戶社區的支持和關注。我們將強化功能;一些計劃的特點與OpenStack儀表板集成，虛擬機遷移的支持，預捕獲過濾和鏡像的流量速率限制等等。
同時，我們也會繼續與Neutron核心團隊討論，如何接受作為未來的OpenStack發行版的一個組成部分。
端口鏡像是一個交換層功能。tap-as-a-service已經有效地虛擬化的這種能力，使它可用于Neutro的用戶配置網絡。我們看到抗原的基本構建塊上更復雜的流量可視性解決方案可以設計一組不同的使用案例，從網絡管理和拍攝應用/網絡安全問題，數據分析和比較。
京公網安備 11010502049343號