現在人生覺得被SDN這個名詞搞的很煩, 因為我心中想的目標跟大家在談的內容已經開始背道而馳了. 我終於可以理解Martin過去跟我說的, “ I know nothing about SDN ". ＠＠ 當時我只能用訝異去看待這個Openflow協議主要發起人之一回應.
過去我嘗試去跟我所在區域市場的人群們, 釐清可production思考的方向的時候, 我發現多數群眾們已經進入宗教式狂熱並超越我的理解範圍, 這感覺就像是數年的市場討論"雲“ 這個議題, 就算到今天為止, 我相信眾人依然無法解釋何謂"雲", 在數年後, 可能大家也依然無法解釋他們今天所談的SDN到底是什麼東西, 能真正在生產環境上幹些什麼事？
如果你要用Openflow解釋SDN, 那Openflow的最早發起團隊已經告訴你哪是一條行不通的路, 他們只是在學術上提供一個新的控制協議, 但是他們並沒有提供你一個Network Operation System. 如果你看過我在這個時間點之前所寫的文章, 我希望你能在這一時先全部忽略掉, 因為在這篇文章的這一秒開始, 我完全想用一個技術人員的思考模式來解釋這個主題, 而不是一個廠商代表.
關於Software Defined Network這個議題, 我想用一個計算機的架構來解釋這個部分. 基本上, 計算機上有幾個重要的單元, 如：中央處理器（CPU), 動態記憶體 (DRAM), 匯流排 (Bus) 和 I/O單元. 如果把這些原件套入到SDN的範圍之內;
中央處理器 - Openflow Controller
I/O - 就如日常使用的輸入/輸出裝置, Openflow協議就如這個I/O行為一樣, 在北向進行指令下達或是收集更新資訊
以上我個人稱之為母體, 沒有母體進行運算, 根本不可能有結果產生. 但是母體產生的結果, 並需要有元件執行~
動態記憶體 - 也就是運算的結果會被store在這, 這個地方也就是網路設備的FIB, 網絡設備必須要有這個訊息才能執行需要的工作.
匯流排 - 也就是元件之間通信的渠道, 這實際網絡的配置上就是你的cable.
所以我們拼湊一下以上的原件:
CPU <--- I/O指令---> 網路設備1 (<-動態記憶體示意)----|
|----------> 網絡設備2 ------------------------|----| 匯流排連線
|----------> 網絡設備3-------------------------|----|
|----------> 網絡設備n-------------------------|----|
你可以發現到, 所有運算的的壓力全部落在北向的CPU組件. 但是回到Openflow最初的概念理念, 正是要最佳化網絡設備的轉發能力, 所以才把運算單元全部脫鉤到北向去嗎？就這個點來說, 是沒有錯. 但是就一個面來說, 這個點並沒有考慮到運算壓力的問題. 不是把轉發表算一算丟給設備就算了, 後面還有一缸子的狀態需要被維持或是更新或是繼續演算, 如果運算單元不aware這個狀態, 那一堆網路標準協議上的工作機制不就作廢? 大型網絡的運作最好有這麼容易簡化. 你以為道士拿個鈴甩一甩, 行屍就會乖乖的一直跳嗎？他要是沒有維持其中的狀態的話, 行屍很快就變殭屍把你吃掉.
到此為止, 如果你看懂我想表達的意思, 你大概可以理解, 現在市場上談的SDN多半都是道行不深的神棍在招攬生意. 其實回頭再看這件事, 這因該不是一門所謂網絡技術的學問, 而是一門distribution computing的科學. 當你把運算單元集中化之後, 如何重新分散運算單元的演算. 就像我給你一顆超級CPU, 可能有一百個內核, 對你來說跟一般CPU沒有兩樣, 因為操作系統根本不支援. 所以當我們在看一個SDN議題的時候, 其實看端出來的菜, 就可以判斷這是道士還是神棍. 講的是一個不能落地的框架, 還是一個有目標的場景. 用的是一個符合運算科學的邏輯架構, 還是一個胡說八道市場訊息. 我想看官門自己需要多琢磨一下.
對不起, 我激動了~ 因為飛機delay, 肚子很餓, 所以脾氣不好～
沒有留言:
張貼留言