Proactive vs. Reactive

標籤：

前不久一個研究SDN的博士生和博主抱怨說：現在開源的SDN控制器效能都好差啊，每秒鐘2K個新流就會提示packet-in太多，停止工作。博主問他是如何定義一個流的，他說用TCP 5 tuple。博主又問他是怎麼產生那麼密集的packet-in的，他說是用一台伺服器直接向SDN控制器發packet-in。博主接著問那台伺服器和SDN控制器的配置，他說伺服器是8核，SDN控制器是4核。博主沒有繼續問更多的問題，而是在想：是什麼原因讓人們設計出這樣的實驗？如果這個實驗的資料正確，那麼又意味著什麼呢？

直到今天，不少人對SDN和OpenFlow都抱有兩個誤解。第一，採用OpenFlow的SDN控制器是在per flow的更新流表。第二，每個flow有自己的生命週期，控制器只為active flow更新流表，其餘的表項則會被刪除。之所以是誤解，是因為任何一個版本的OpenFlow標準都沒有說per flow的更新，更沒有說只為active flow更新流表。事實上，OpenFlow僅僅定義了控制器和交換器之間的一種介面，根本沒提要如何使用這些介面。

一個非常有趣的問題是：人們為什麼會對SDN和OpenFlow有以上的誤解？首先，OpenFlow這個名字非常糟糕，它本身似乎在暗示人們這個協議是per flow的，但事實根本不是這樣。如果有機會為這個協議重新起名，OpenTable會更合適，因為它本質上是開放了交換器裡的各種流表，SDN控制器可以編輯這些流表。

另外OpenFlow協議本身需要交換器採取match+action的方式進行轉寄，而不是傳統的2層+3層+TCAM的轉寄方式。這個轉寄方式的轉變是造成人們產生以上誤解的一個重要原因。在早期的OpenFlow實踐中，人們發現在現有的硬體ASIC上很難採取wildcard match+action的轉寄方式。最立竿見影的在硬體上部署SDN的方案是僅僅利用ASIC上的TCAM表，因為這張表支援wildcard match，支援drop，forward，broadcast，copy to CPU等多種action。TCAM表與OpenFlow協議的轉寄方式有著最直接的對應的關係。於是市場上就出現了早期的支援OpenFlow的交換器：它們支援OpenFlow協議，將OpenFlow的每一個Flow Modification Message轉變為相應的TCAM表項。這對SDN和OpenFlow的普及有非常積極的影響。但它有一個問題：TCAM實在是有些貴，導致即便到了今天，最成熟的ASIC也只支援3K-4K的TCAM表項，這麼小的表最多隻能做做demo，規模部署根本是天方夜譚。天才的SDN先驅們想到一個辦法來克服TCAM表過小的問題，那就是採用reactive的方式來編寫TCAM。通俗來說就是：只儲存那些active流的表項，那些不再active的表項都會因為逾時而被刪除。具體的做法是：對於每個新流的第一個包，交換器不知道該如何處理，於是交換器會向控制器發送一個packet-in，控制器收到這個packet-in之後，計算路徑並通過Flow_Mod告訴各個交換器如何轉寄這個新流。如果與這個流相關的各個表項在一段時間內沒有見到新包，這個流被認為已經結束，相關的表項被從TCAM表中清除。這個reactive的辦法確實從一定程度上解決了TCAM表過小的問題。不過SDN的後繼者們卻忘記了TCAM過小是因，reactive是果。如果一個初學者剛剛讀完OpenFlow spec，他可能會想當然的以為SDN by design就是reactive的，而忽視了去探尋reactive的原因。事實上OpenFlow spec和是不是reactive沒有任何關係。

曆史講到這裡，我們再返回頭看看文章開始的那個實驗。不難發現，實驗設計者在潛意識中就想當然的認為OpenFlow是per flow的並且是reactive的！帶著這樣的假設設計實驗本身就不科學。很遺憾，這兩個不正確的假設仍然在不少SDN研究者的腦子雷根深蒂固，於是在實驗中，他們會依靠產生不同的TCP 5 tuple來類比大量新流。在工業界中，這樣的誤解會少很多，因為在設計任何一個SDN產品之前，人們會評估設計的瓶頸：如果每一個新的TCP 5 tuple都會引起packet-in的話，SDN控制器肯定會成為系統瓶頸，這種系統設計會被毫無疑問的在第一時間拋棄。我們從來沒有聽說過哪個廠商公布他們的控制器處理packet-in的能力，不是因為這是他們的機密，而是因為系統的穩定程度在設計上就與新流產生的速度無關，根本就沒有人關心這個測試結果。

分析到這裡，我們已經知道reactive的模式雖然在一定程度上解決了由於TCAM過小帶來的問題，但也讓SDN控制器成為了系統的瓶頸。如果文章最初的那個實驗資料是正確的，那麼reactive的SDN控制器根本無法控制大規模的網路和流量。在這種情況下，也許會有人建議去研究如何提高SDN控制器的效能，使其不再成為瓶頸。但這樣便是典型的捨本逐末，解決一個本來可以不存在的問題。試想，如果TCAM足夠大，人們還會採用reactive的方式來設計SDN系統嗎？顯然不會。與之相對應，proactive會成為一個更合理的方式，即：在新流還沒有來到之前，就把相應的表項編輯好，這樣，新流出現就不會引起packet-in了。

看到這裡，也許有朋友會問：1) SDN控制器怎麼知道會有什麼流產生？2) TCAM只有那麼大，如果在新流產生之前就主動的編輯好流表，怎麼裝得下？

其實這兩個問題都是偽問題，之所以把它們列在這裡是為了讓文章的邏輯保持連貫。提出問題1的人仍然在局限在SDN是per flow的誤解裡面。除非人為的調度，SDN控制器永遠不會聰明到能夠猜出會有什麼新流產生。但是沒關係，問題的關鍵不在於知道會有什麼新流產生，而在於知道各個裝置在哪裡。互連網發展到今天，從來都不是per flow轉寄，而是per device轉寄！傳統的二層交換器需要學習(vlan, mac)到port的映射，其實就是在學習各個device在哪裡。只要知道mac1在port1，不管什麼flow，只要是去mac1的就轉寄到port1。同樣的邏輯可以非常自然的推廣到SDN裡面，控制器可以學習各個device在哪裡，並且告知網路中的交換器們如何達到各個裝置。學習的渠道可以很多，比如ARP，LLDP，LACP等等。學習mac不過癮，還可以學IP。總之，如果把per flow的mental model轉變為per device的mental model，SDN系統設計的一切都會變得自然很多。

問題2是一個更大的偽問題。正如在之前的段落中介紹的那樣，SDN的先驅們非常理想化的設計了OpenFlow協議，後來發現只有昂貴TCAM才能夠和OpenFlow協議產生比較直接的對應，於是OpenFlow和TCAM才成為難兄難弟，總是成雙成對的出現。問題是：我們的目的是用集中控制的方式簡化網路管理，為什麼一定要用TCAM？又為什麼一定要用OpenFlow？這才觸及到問題的本質。

博主的答案是：我們不一定要用TCAM，我們也不一定要用OpenFlow。一切都是design choice，只有不同的選擇，沒有最好的選擇。比較有代表性的是學院派和工業界的選擇。學院派以Nick McKeown教授為代表，主張徹底重新設計硬體交換晶片[link]，使其完全適應OpenFlow協議。工業界的做法沒有那麼激進：cisco設計了ACI和OpFlex，讓協議適應硬體ASIC；BigSwitch沿用了OpenFlow，但是只使用TCAM存放複雜的規則，而用L2和L3的表來存放一般的轉寄規則，在最大程度上規避了TCAM大小的局限。在多方的共同努力之下，SDN和OpenFlow設計之初的種種限制正在成為曆史，reactive的系統設計也完成了它的曆史使命。現在實用的proactive的SDN系統大概長這個樣子：1) SDN控制器不斷學習網路中的各種裝置，包括交換器，鏈路，伺服器，虛擬機器等等，2) 管理員通過某種語言配置業務關係，比如multi-tier application和service chaining。3) SDN控制器翻譯使用者配置並且通過南向介面編輯交換器中的L2，L3表，這裡的表項不是per flow的，而是per device的。SDN控制器同樣通過南向介面將租戶的商務邏輯轉變為TCAM表項，這裡的表項更複雜，可能需要匹配source+destination以及L4的某些欄位。

採用proactive的方式設計SDN系統還有一個更大的好處是它極大的簡化了High Availability(HA)的設計，讓SDN控制器不再成為整個系統的單點故障(single point of failure)。以後的文章會對這一點進行深入討論。

講了這麼多，博主只是在傳達一個資訊：採用reactive的方式設計SDN系統是有曆史原因的。現在這些原因都已經不再存在，proactive的SDN系統設計已經成為主流。

Proactive vs. Reactive