現在人生覺得被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, 肚子很餓, 所以脾氣不好～
2014年3月15日 星期六
2014年3月14日 星期五
NSX Service Composer
一個人在一個區域做一個什麼都連在一起的產品, 實在有點吃不消. 但是人生就是這個樣子, 沒事抱怨一下也就算了, 畢竟生活的現實還是需要去面對的, 最近除了花時間在工作的項目之外, 最多時間還是跟女兒玩, 其他的事情也沒太多搭理.
最近獲得了一個喘息的時間, 飛到新加坡參加了NSX vSphere的培訓, 終於可以有時間充充電, 以免老是在放電的狀態. 已過去在Nicira的工作經驗, 這個培訓並不是一個太艱難的內容, 尤其是在所謂網絡虛擬化的內容上, 但是課程內容我感到最有興趣的NSX Service Composer的功能. 這個在過去我並沒有太專心放心思在這個功能上. 因為我也拿不到第三方相對應的方案, 所以放在我工作計劃角落很久了, 沒有去太在意它.
在2013的VMworld, VMware宣布了新的EcoSystem. 到了今年, 可以預期的是, 這個生態環境的集成已經陸陸續續開始要Get Ready, 所以Service Composer也快要可以到登場的時候, 當然本次的培訓也納入這個元素, 實際上機操作了一下, 感覺也就更為深刻.
什麼是Service Composer, 今天我所能提供的第一步消息就是第三方的安全方案集成. 過去在安全領域的經驗裡, 鮮少有廠家願意談太多第三方集成方案的生態環境, 因為大家各自有一片專業領域需要protect. 對於VMware來說, 它是一個虛擬infrastructure的廠家, 急需要的在這個基礎建設上, 融入更多的功能元素提供給他的用戶群, 但是自己本身又不具備L4以上的安全能力, 所以催生了這個元件的產生. 這個元件並不是要讓VMware成為一個安全產品的公司, 而是提供給他的用戶更多的選擇在這個基礎上, 就像寶馬的車如果只給你冷氣, 不給你音響和電動座椅, 你可能會氣到七竅生煙, 還會咒罵他賣得很貴.
廢話說太多了, 到底Service Composer想做些什麼事？ 簡單的來說, 就是集成第三方的功能完成ACL的判斷, 有時我會叫他是個ACL Orchestration. 假設今天我要集成一個防毒系統;
1) 先註冊防毒系統的管理平台到vCenter和NSX-V Manager (僅限於VMware NSX生態環境內的合作夥伴).
2) 部署防毒系統的Agent到vSphere Hypervisor上, 這主要是在分散式的環境下, 可以在本地就直接execution, 無需再拉到北向的filter engine, 這個好處就跟分散式網路一樣, 卸載北向壓力, 減少昂貴Box的採購.
3) 建立Security Group 1 確認策略保護的目標, 並在建立一個Security Policy去調用第三方的集成功能. ( 當發現安全威脅的時候, 第三方的功能會提供結果標簽供系統參考 )
4) 建立Security Group 2, 確認當安全系統發生告警時, 能根據所提供的標簽把有風險的virtual machine放進到動態的成員名單內. 在建立一個Security Policy, 告知系統當成員名單需要被執行隔離(Quarantine )
5) 當防毒系統將病毒清理之後, 第三方掃毒引擎會remove 標簽, 此時virtual machine會被釋放回到一般的工作區域.
以上大概是先建立腳本, 然後再腳本之內, 先對應的策略可以動態被建立, 並且根據實際狀況進行動態的工作執行. 所以由此可以簡化在相關問題發生的時候, Compsor可以依據你所設定的腳本, 進行程式化的動態工作. 對於安全功能自動化來說, 這組件算是降低了管理員的壓力, 也更能彰顯VMware基礎建設的價值, 不然老是被人家嫌軟件貴, 心裏也不是太好受.
最近獲得了一個喘息的時間, 飛到新加坡參加了NSX vSphere的培訓, 終於可以有時間充充電, 以免老是在放電的狀態. 已過去在Nicira的工作經驗, 這個培訓並不是一個太艱難的內容, 尤其是在所謂網絡虛擬化的內容上, 但是課程內容我感到最有興趣的NSX Service Composer的功能. 這個在過去我並沒有太專心放心思在這個功能上. 因為我也拿不到第三方相對應的方案, 所以放在我工作計劃角落很久了, 沒有去太在意它.
在2013的VMworld, VMware宣布了新的EcoSystem. 到了今年, 可以預期的是, 這個生態環境的集成已經陸陸續續開始要Get Ready, 所以Service Composer也快要可以到登場的時候, 當然本次的培訓也納入這個元素, 實際上機操作了一下, 感覺也就更為深刻.
什麼是Service Composer, 今天我所能提供的第一步消息就是第三方的安全方案集成. 過去在安全領域的經驗裡, 鮮少有廠家願意談太多第三方集成方案的生態環境, 因為大家各自有一片專業領域需要protect. 對於VMware來說, 它是一個虛擬infrastructure的廠家, 急需要的在這個基礎建設上, 融入更多的功能元素提供給他的用戶群, 但是自己本身又不具備L4以上的安全能力, 所以催生了這個元件的產生. 這個元件並不是要讓VMware成為一個安全產品的公司, 而是提供給他的用戶更多的選擇在這個基礎上, 就像寶馬的車如果只給你冷氣, 不給你音響和電動座椅, 你可能會氣到七竅生煙, 還會咒罵他賣得很貴.
廢話說太多了, 到底Service Composer想做些什麼事？ 簡單的來說, 就是集成第三方的功能完成ACL的判斷, 有時我會叫他是個ACL Orchestration. 假設今天我要集成一個防毒系統;
1) 先註冊防毒系統的管理平台到vCenter和NSX-V Manager (僅限於VMware NSX生態環境內的合作夥伴).
2) 部署防毒系統的Agent到vSphere Hypervisor上, 這主要是在分散式的環境下, 可以在本地就直接execution, 無需再拉到北向的filter engine, 這個好處就跟分散式網路一樣, 卸載北向壓力, 減少昂貴Box的採購.
3) 建立Security Group 1 確認策略保護的目標, 並在建立一個Security Policy去調用第三方的集成功能. ( 當發現安全威脅的時候, 第三方的功能會提供結果標簽供系統參考 )
4) 建立Security Group 2, 確認當安全系統發生告警時, 能根據所提供的標簽把有風險的virtual machine放進到動態的成員名單內. 在建立一個Security Policy, 告知系統當成員名單需要被執行隔離(Quarantine )
5) 當防毒系統將病毒清理之後, 第三方掃毒引擎會remove 標簽, 此時virtual machine會被釋放回到一般的工作區域.
以上大概是先建立腳本, 然後再腳本之內, 先對應的策略可以動態被建立, 並且根據實際狀況進行動態的工作執行. 所以由此可以簡化在相關問題發生的時候, Compsor可以依據你所設定的腳本, 進行程式化的動態工作. 對於安全功能自動化來說, 這組件算是降低了管理員的壓力, 也更能彰顯VMware基礎建設的價值, 不然老是被人家嫌軟件貴, 心裏也不是太好受.
訂閱：
文章 (Atom)