精品国产一级在线观看,国产成人综合久久精品亚洲,免费一级欧美大片在线观看

當前位置:虛擬化行業動態 → 正文

SDN控制器究竟在干啥?

責任編輯:editor005 作者:xinwu |來源:企業網D1Net  2015-07-14 14:17:42 本文摘自:簡書網

一提到SDN,大家就會想到南北向接口,南向接口負責和交換機的交互,北向接口負責和各種應用的交互,SDN控制器穩坐中間,運籌帷幄,決勝千里。在博主看來,這只是SDN的冰山一角。對這個問題比較全面的闡述出現在OpenStack Silicon Valley上Martin Casado的一次演講。雖然這次演講的主題是數據中心的策略管理(Policy for the Cloud Frontier),但Martin在演講中定義的三個方面卻實實在在是所有SDN系統需要解決的最基本的三個問題。

  1. 南向接口

這個方面很好描述,交換機來自不同的廠家,控制器來自不同的廠家,如何讓它們互聯互通?本質上,這不是一個技術問題,而是不同廠商的利益問題。ONF的OpenFlow和OF-Config,Cisco的OpFlex,甚至有些廠家使用XML/Json + REST API。根據目前的情況,要建立南向接口標準困難重重。

OpenFlow + OF-Config是目前最好的選擇,標準相對而言最完善,開源的實現最完整并且已經有廠家開始開始支持OpenFlow1.3和1.4了。基于OpenFlow的系統已經在Google得到了部署[link]。

對于OpFlex和ACI,博主還呈觀望態度。如果沒有Cisco之外的其他交換機廠商支持,用戶仍然會陷入vendor lock-in的窘境,希望通過SDN節省成本可能會比較困難。

對于采用XML/Json + REST API作為南向接口,博主并沒有特別強烈的偏好。不少云服務提供商的網絡就是用REST API從控制器向交換機推送配置的。唯一的問題是:這種集中的配置管理其實只是包裝在傳統網絡上面的一個feature,交換機之間仍然通過傳統的二層三層協議互聯互通。這種方案不會節省網絡部署和運維的成本,相反,由于這個新的feature,企業可能還要購買額外的軟件,聘請額外的工程師圍繞這個新feature進行開發和維護。這也從一個側面解釋了為什么有些企業部署所謂的SDN之后,成本反而增加:它們SDN的不徹底。

2. 分布式的狀態管理

也許大家會問:SDN都集中控制了,哪里需要分布式的狀態管理呢?但事實上,這是一個非常棘手的問題。博主會在之后的文章里詳細討論這個問題,這里給大家舉個例子先:試想在SDN網絡中的一條link突然斷了,交換機將這個事件通知了SDN控制器。SDN控制器決定將所有經過這條link的流轉移到另外一條路徑上,換言之,僅僅斷掉一條link,新舊路徑上的每一個交換機都需要做出相應的更新。更復雜的問題是:SDN控制器應該以怎樣的順序來更新眾多的交換機呢?由于SDN控制器和各個交換機的通信延時,控制平面的擁塞狀況,交換機CPU的負載不同,SDN控制器發給各個交換機的Flow_Mod會無序的生效。那么,在流表被更新的這段時間,網絡便處于一個完全無法描述的狀態。擁塞丟包,路由黑洞都可能在這段時間發生。如果這段時間足夠的短,整個網絡馬上從上一個穩定的狀態進入到下一個穩定的狀態,大家也需可以接受。但是如果由于某些原因,這次狀態變化失敗,我們是否允許網絡處于一個未知的中間狀態?我們是否需要像數據庫那樣支持網絡狀態的回滾?通過這個簡單的例子,我們已經發現,要維持SDN控制器和網絡中所有交換機的狀態保持同步是一件非常困難的事情。如何解決這個問題,博主會在稍后的博文中分享一些教訓。

3. 用戶模型到轉發模型的映射

正如Martin所說,這個問題是SDN中最難也是最容易被忽略的一個問題。我們不妨集體腦補一個場景,看看這究竟是一個什么樣的問題:博主我剛剛用最高大上的SDN技術搭建了一個支持多租戶的數據中心(multi-tenancy datacenter)。我很開心的迎來了第一個租戶(tenant),這個租戶的要求是建立一個擁有2 臺web服務器和1臺數據庫服務器的網站。web 服務器和數據庫屬于不同的子網,在web服務器之前需要部署一個防火墻。web和數據庫之間只允許在TCP端口1234上進行通訊。要命的是,這個租戶希望自己能夠一站式的完成所有以上的配置。我們仔細想想這個要求意味著什么。首先,SDN控制器要允許不同的租戶登錄,并且每個租戶僅僅能夠看到和配置自己的網絡及服務。其次,SDN控制器需要定義一套配置語言,并且這套語言僅僅需要描述業務邏輯,和底層網絡沒有絲毫的關系。再次,在租戶定義完成之后,不論實際網絡的拓撲是什么樣子,SDN控制器都需要把租戶的配置轉變為網絡中實實在在的流表。在上面的這個例子中,SDN控制器甚至需要部署防火墻等網絡服務。有些數據中心是使用專門的硬件來履行這些網絡服務的,那么SDN控制器就一定要準確的計算和更新流表,確認網絡流量會沿著正確的路徑經過這些硬件服務節點。

在設計SDN系統時,還存在一些更難的問題,比如高可靠性(high availability),自動化部署(zero-touch provisioning),無丟包升級(hit-less upgrade)等等。之后的博文中會陸續涉及。在這里博主只想強調:要設計一個最最基本的SDN系統,這里所提到的三個方面是一定要仔細斟酌,設計和施工的。

關鍵字:SDN用戶模型從控制器

本文摘自:簡書網

x SDN控制器究竟在干啥? 掃一掃
分享本文到朋友圈
當前位置:虛擬化行業動態 → 正文

SDN控制器究竟在干啥?

責任編輯:editor005 作者:xinwu |來源:企業網D1Net  2015-07-14 14:17:42 本文摘自:簡書網

一提到SDN,大家就會想到南北向接口,南向接口負責和交換機的交互,北向接口負責和各種應用的交互,SDN控制器穩坐中間,運籌帷幄,決勝千里。在博主看來,這只是SDN的冰山一角。對這個問題比較全面的闡述出現在OpenStack Silicon Valley上Martin Casado的一次演講。雖然這次演講的主題是數據中心的策略管理(Policy for the Cloud Frontier),但Martin在演講中定義的三個方面卻實實在在是所有SDN系統需要解決的最基本的三個問題。

  1. 南向接口

這個方面很好描述,交換機來自不同的廠家,控制器來自不同的廠家,如何讓它們互聯互通?本質上,這不是一個技術問題,而是不同廠商的利益問題。ONF的OpenFlow和OF-Config,Cisco的OpFlex,甚至有些廠家使用XML/Json + REST API。根據目前的情況,要建立南向接口標準困難重重。

OpenFlow + OF-Config是目前最好的選擇,標準相對而言最完善,開源的實現最完整并且已經有廠家開始開始支持OpenFlow1.3和1.4了。基于OpenFlow的系統已經在Google得到了部署[link]。

對于OpFlex和ACI,博主還呈觀望態度。如果沒有Cisco之外的其他交換機廠商支持,用戶仍然會陷入vendor lock-in的窘境,希望通過SDN節省成本可能會比較困難。

對于采用XML/Json + REST API作為南向接口,博主并沒有特別強烈的偏好。不少云服務提供商的網絡就是用REST API從控制器向交換機推送配置的。唯一的問題是:這種集中的配置管理其實只是包裝在傳統網絡上面的一個feature,交換機之間仍然通過傳統的二層三層協議互聯互通。這種方案不會節省網絡部署和運維的成本,相反,由于這個新的feature,企業可能還要購買額外的軟件,聘請額外的工程師圍繞這個新feature進行開發和維護。這也從一個側面解釋了為什么有些企業部署所謂的SDN之后,成本反而增加:它們SDN的不徹底。

2. 分布式的狀態管理

也許大家會問:SDN都集中控制了,哪里需要分布式的狀態管理呢?但事實上,這是一個非常棘手的問題。博主會在之后的文章里詳細討論這個問題,這里給大家舉個例子先:試想在SDN網絡中的一條link突然斷了,交換機將這個事件通知了SDN控制器。SDN控制器決定將所有經過這條link的流轉移到另外一條路徑上,換言之,僅僅斷掉一條link,新舊路徑上的每一個交換機都需要做出相應的更新。更復雜的問題是:SDN控制器應該以怎樣的順序來更新眾多的交換機呢?由于SDN控制器和各個交換機的通信延時,控制平面的擁塞狀況,交換機CPU的負載不同,SDN控制器發給各個交換機的Flow_Mod會無序的生效。那么,在流表被更新的這段時間,網絡便處于一個完全無法描述的狀態。擁塞丟包,路由黑洞都可能在這段時間發生。如果這段時間足夠的短,整個網絡馬上從上一個穩定的狀態進入到下一個穩定的狀態,大家也需可以接受。但是如果由于某些原因,這次狀態變化失敗,我們是否允許網絡處于一個未知的中間狀態?我們是否需要像數據庫那樣支持網絡狀態的回滾?通過這個簡單的例子,我們已經發現,要維持SDN控制器和網絡中所有交換機的狀態保持同步是一件非常困難的事情。如何解決這個問題,博主會在稍后的博文中分享一些教訓。

3. 用戶模型到轉發模型的映射

正如Martin所說,這個問題是SDN中最難也是最容易被忽略的一個問題。我們不妨集體腦補一個場景,看看這究竟是一個什么樣的問題:博主我剛剛用最高大上的SDN技術搭建了一個支持多租戶的數據中心(multi-tenancy datacenter)。我很開心的迎來了第一個租戶(tenant),這個租戶的要求是建立一個擁有2 臺web服務器和1臺數據庫服務器的網站。web 服務器和數據庫屬于不同的子網,在web服務器之前需要部署一個防火墻。web和數據庫之間只允許在TCP端口1234上進行通訊。要命的是,這個租戶希望自己能夠一站式的完成所有以上的配置。我們仔細想想這個要求意味著什么。首先,SDN控制器要允許不同的租戶登錄,并且每個租戶僅僅能夠看到和配置自己的網絡及服務。其次,SDN控制器需要定義一套配置語言,并且這套語言僅僅需要描述業務邏輯,和底層網絡沒有絲毫的關系。再次,在租戶定義完成之后,不論實際網絡的拓撲是什么樣子,SDN控制器都需要把租戶的配置轉變為網絡中實實在在的流表。在上面的這個例子中,SDN控制器甚至需要部署防火墻等網絡服務。有些數據中心是使用專門的硬件來履行這些網絡服務的,那么SDN控制器就一定要準確的計算和更新流表,確認網絡流量會沿著正確的路徑經過這些硬件服務節點。

在設計SDN系統時,還存在一些更難的問題,比如高可靠性(high availability),自動化部署(zero-touch provisioning),無丟包升級(hit-less upgrade)等等。之后的博文中會陸續涉及。在這里博主只想強調:要設計一個最最基本的SDN系統,這里所提到的三個方面是一定要仔細斟酌,設計和施工的。

關鍵字:SDN用戶模型從控制器

本文摘自:簡書網

電子周刊
回到頂部

關于我們聯系我們版權聲明隱私條款廣告服務友情鏈接投稿中心招賢納士

企業網版權所有 ©2010-2024 京ICP備09108050號-6 京公網安備 11010502049343號

^
  • <menuitem id="jw4sk"></menuitem>

    1. <form id="jw4sk"><tbody id="jw4sk"><dfn id="jw4sk"></dfn></tbody></form>
      主站蜘蛛池模板: 正镶白旗| 桐庐县| 永修县| 中方县| 新巴尔虎右旗| 汤原县| 济源市| 靖安县| 肇东市| 达拉特旗| 溧阳市| 武邑县| 兴隆县| 沙河市| 洪雅县| 睢宁县| 申扎县| 白山市| 博乐市| 建阳市| 广水市| 阜康市| 花莲市| 清苑县| 张家口市| 青铜峡市| 博客| 左云县| 镶黄旗| 芒康县| 永寿县| 汉寿县| 襄汾县| 锦屏县| 青浦区| 宝丰县| 武陟县| 瑞昌市| 金寨县| 铅山县| 郓城县|