最近覺得被SDN這個詞搞得很煩，因爲我心中想的目標跟大家在談的內容已經開始背道而馳了。我終於可以理解Martin過去跟我說過的：“Iknow nothing about SDN”。當時我只能用驚訝去看待這個Openflow協議主要發起人之一對SDN的迴應。
過去我嘗試去跟我所在區域市場的朋友理清可用於生產的SDN的方向時,發現多數朋友已經進入宗教式狂熱並超越我的理解範圍，這種感覺就像是多年以來關於“雲計算”的探討。就算到今天爲止，我相信大多數人依然無法解釋什麼是“雲”。再過多年後，大家可能依然無法解釋他們所談的SDN到底是什麼，能真正在生產環境中做些什麼？
如果你要用Openflow來解釋SDN，那Openflow的最早發起團隊已經告訴你那是死路一條，他們只是在學術上提供一個新的控制協議，但他們並沒有提供你一個網絡操作系統。如果你看過我之前所寫文章，我希望此時你能全部丟棄，因爲在這篇文章的這一秒開始，我想完全用一個技術人員的思考模式來解釋這個主題，而不是作爲一個廠商代表。
關於軟件定義網絡這個議題，我想用一個計算機的架構來解釋這部分。基本上，計算機上有幾個重要的組件，如：中央處理器（CPU)、內存(DRAM)、總線(Bus) 和 I/O模塊。如果把這些組件套入到SDN的範圍之內就是：中央處理器就是Openflow控制器，I/O模塊就是如日常使用的輸入/輸出模塊，Openflow協議就如同I/O行爲一樣，在北向進行指令下達或是收集更新信息。以上我稱之爲母體，沒有母體進行運算，根本不可能產生結果。但是母體產生的結果，也還是需要有組件來執行才行。內存也就是存儲運算結果的地方，也就相當於網絡設備的FIB(forwarding information database)，網絡設備必須要有這個信息才能執行需要的工作。總線也就是元件之間通信的通道，這在網絡的世界裏就是線纜。
所以我們拼接一下以上的組件：
CPU <--- I/O指令---> 網絡設備1 (<-內存示意)----|
|----------> 網絡設備2------------------------|----| 網絡連線
|----------> 網絡設備3-------------------------|----|
|----------> 網絡設備n-------------------------|----|
你可以發現：所有運算的壓力全部落在CPU組件上，但是回到Openflow最初的理念，正是要優化網絡設備的轉發能力，才把運算單元全部放到北向去嗎？就這個點來說沒有錯。但是就一個面來說，這個點並沒有考慮運算壓力的問題。不是把轉發表算一算丟給設備就算了，後面還有大量的狀態需要被保持或是更新或是繼續演算，如果運算單元不知道這個狀態，那一堆網絡標準協議上的工作機制不就作廢了? 我們當然希望大型網絡的運作如此易於簡化，不過你以爲道士拿個鈴鐺甩一甩，行屍就會乖乖的一直跳嗎？他要是沒有持續維持其中的狀態的話，行屍很快就變成殭屍把你吃掉。
到此爲止，如果你看懂我想表達的意思，你大概可以理解現在市場上談的SDN多半都是道行不深的神棍在招攬生意。其實回頭再看這件事，這應該不是一門所謂網絡技術的學問，而是一門分佈式計算的科學。當你把運算單元集中化之後，如何重新分散運算單元的演算，就像我給你一顆超級CPU，可能有一百個內核，對你來說跟一般CPU沒有兩樣，因爲操作系統根本不支持。所以當我們再看SDN議題的時候，其實看端出來的菜，就可以判斷這是道士還是神棍所爲；講的是一個不能落地的框架，還是一個有目標的場景；用的是一個符合運算科學的邏輯架構，還是一個胡說八道的市場信息，我想看官們自己需要多琢磨一下。
對不起，我有些激動了~ 因爲飛機延誤了，肚子咕咕叫，所以脾氣不好，見諒～
作者：陳建民，曾任Nicira亞太區技術顧問，2012年VMware收購Nicira之後，現任VMware 網路虛擬化平臺工程師，專精於資訊中心基礎建設規劃及內容應用安全。掃描下面的二維碼訂閱“中國雲夢”微信公衆號後，回覆“10033”閱讀該文。
