電子發燒友App
1.SDN服務鏈基本概述
由于Overlay網絡的發展，使得虛擬網絡和物理網絡分離，讓數據中心的網絡控制變得更加靈活，更具有擴展性。然而，在數據中心中，還存在很多介于虛擬網絡和物理網絡之間的中間件，如防火墻，QoS，負載均衡器等。這些中間件提供了必要的業務處理功能，即Service Function。靈活、便捷、高效、安全地調配流量到Service Function上處理，形成服務鏈（Service Function Chaining），這就是SFC項目要解決的問題。服務鏈可以理解為一種業務形式。
過去也有服務鏈的概念，但傳統的網絡服務鏈往往和網絡拓撲緊密耦合、部署復雜，在服務鏈變更、擴容時，都需要改動網絡拓撲，重新進行網絡設備的配置。而云計算環境廣泛使用虛擬化技術，具有動態性、高流動性、規模易變化、多租戶等特點，傳統網絡的服務鏈無法滿足這些需求，SDN的出現讓服務鏈又煥發了生機。因此，當前再談及服務鏈時，默認指的是SDN服務鏈。
與傳統DC中配置的網絡服務鏈相比，基于SDN的SFC具有如下的優勢：
- 傳統的網絡服務鏈往往基于手工配置，很大程度上依賴于具體的網絡拓撲，以至于網絡設備之間的耦合性很大。而基于SDN的配置，可以動態的添加或者刪除鏈表上的服務節點，不僅方便使用，而且解耦了網絡設備之間的關聯。
- 在數據流量經過鏈表的過程中，SFC還支持分類器與服務，服務與服務之間的上下文信息共享。
- 在傳統的數據服務鏈中，數據包往往要經過過次分類，即多次解包、封包的過程。而在SFC中，這個過程大大縮減，一般只需在分類一次即可，使得整個過程更便捷、更高效。2.基于OpenDaylight的服務鏈項目
2.1 Service Function Chaining 的架構及組件
OpenDaylight的SFC項目是整個控制器平臺內部的一個功能模塊。用戶可以通過控制器提供的北向API來使用的SFC的功能，例如創建、更新或者刪除Service Chain，還可以通過配置非透明的metadata數據段用來在Service Function的節點間實現數據共享。
同時，項目可以向Controller的DataStore中注冊、配置服務節點，并獲取拓撲。南向也支持Netconf，Openflow12等協議。
SFC核心組件如下：
- Classification：根據初始化的（配置好的）policy匹配數據流進行封裝，然后轉入到Service Function Chain中。
- Service Function(SF): 負責對收到的數據包進行特定功能的處理。作為一個邏輯上的組件，SF在具體實現的上可以是一個虛擬的元素，或者是嵌入在具體網絡設備上的某種功能。常見的SF有：防火墻(firewall)，WAN設備加速器，深層報文檢測(Deep Packet Inspection,DPI)，NAT等等。
- Service Function Forwarder(SFF):主要負責Service Function Chaining上的流量轉發控制。
- Service Function Chain(SFC): SFC定義了一個抽象的Service Function有序集合。經過分類后的包要依次去遍歷集合中的Service Function。比如：用戶可以配置firewall->qos->dpi三種服務來構建一條SFC。
- Rendered Service Path(RSP) : 數據包實際行走的路徑。
- Service Function Path(Service Function Path): SFP是一個邏輯概念，
它是介于SFC和RSP之間的一層抽象，有時候會將SFP與SFC等同。
2.2 ODL的SFC項目工作流原理
那么，SFC項目是怎么綜合起上述的組件進行工作的呢？
一種基于NSH封裝頭的機制是，使用ODL配置并下發一條Service Function Chain，每條Chain都有自己的標識。當host1發送數據包給host2，數據包首先會到分類器中進行篩選。分類出需要經過Service Function Chaining的數據包會進行封裝，并打上NSH頭。頭中包含了很多信息，包括走哪一條服務鏈，服務鏈有幾跳等。接著數據包會依次經過SFF，由SFF將數據包傳遞給SF或者下一跳的SFF，直到鏈的最后。
3.實驗
本篇文章旨在通過基本概念的介紹和一個SFC的實驗，幫助大家了解SFC是什么，在OpenDaylight中如何去配置基本的SFC。通過對SFC有個大致的了解，有興趣的同學可以繼續深入地去研究NSH，SFC架構及應用等知識。
3.1 實驗準備
Python導入包包括：requests,flask,netifaces,paramiko等
在Ubuntu14.04下搭建ODL環境參考：https://wiki.opendaylight.org/view/Install_On_Ubuntu_14.04
在Ubuntu下安裝Python3.4及所需包如下：
如果沒有Python3.4:
安裝一個Python3.4-pip安裝器
安裝flask包，其他包安裝類似，根據版本不同，安裝方法或者指令不一定與這里相同：
3.2 術語簡表：
- SF : Service Function
- SFF : Service Function Forwarder
- SFP : Service Function Path
- RSP : Rendered Service Path
- ODL : OpenDaylight
- SFC Agent: Service Function Chaining Agent.
3.3 基本配置和安裝：
ifconfig查看本地機器的ip，我這邊是：192.168.2.134
安裝ODL的sfc項目：git clone http://git.opendaylight.org/gerrit/sfc
樓主使用的SFC是5月份的版本：
可以git reset –-hard cd12dda6回到那個版本。
如果讀者在實驗的時候，用的是最新版本的SFC，在sfc/sfc-py/sfc/nsh/service.py腳本有很多bug，要做適當修改。這里為方便，就使用之前版本演示。
用maven構建一下項目：
mvn clean install –DskipTests
啟動ODL:
過一會兒，就可以用瀏覽器進入SFC的ui界面了：http://localhost:8181/sfc/index.html 用戶名和密碼都是:admin
剛開始進來都是空的，點擊System Info會有404也不要緊張，因為什么都沒有配置。另外，在ODL中創建SFC有兩種方式：第一，用北向的RESTAPI；第二，用UI來創建。本次實驗用將基于UI，這樣看起來比較直觀，方便理解。后續有興趣用REST來配置的參見SFC 101文檔。
3.4 開始實驗
3.4.1 啟動SFC Agent
SFC Agent是用Python腳本寫的一個仿真工具，位于SFC項目的sfc-py目錄下。在實驗的過程中，ODL在南向通過REST與Agent進行通信，即ODL通過REST將配置的信息下發給Agent，Agent根據這些信息，在數據平面仿真出相應的元素組件。使用Agent的好處就是在實驗中，簡化南向接口，易于實現實驗。
進入到sfc/sfc-py目錄下，打開start_agent.sh文件，修改默認的ip地址為本地主機ip:
也可以將127.0.0.1改成192.168.2.134。
啟動Agent:
根據上圖可以直到Agent運行的端口是5000。
3.4.2 創建Service Functiont
點擊導航欄的Service Function標簽，再點擊”Add Service Function”，填寫表格如下：
點擊Submit，在Agent端，有如下信息輸出：
表明Agent已經成功為我們創建好了SF1(firewall)。
這里有幾個地方要注意：
1.NSH頭的使用。我們這里是基于Agent的仿真實驗，沒有對分類器做配置。選True 和False都沒有關系，但是實際情況下會根據NSH頭的信息來選擇具體的路徑。具體可以研究：http://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/
2.數據平面的通信方式一定要選，這里選vxlan-gpe。要不然Agent收不到請求。
3.SFF1暫時還沒有創建，可以先填入SFF1，后面創建SFF的名字要與這里一致。
3.4.3 創建SFF
在導航菜單中點擊Service Function Forwarder，點擊”Add Service Function Forwarder”，填寫表單信息如下：
右下角的SFF dictionary“Remove”掉，后面的版本也沒有這個directory了。如下圖：
submit以后,在Agent端，SFF創建成功信息打印如下：
3.4.4 目前拓撲和工作流
3.4.5 創建Service Function Chain
在導航欄點擊Service Function Chain標簽：
- 點擊創建Service Function Chain
- 填入名字“Chain-1”,提交
- 將”firewall”的SF拖拽到右邊的Chain-1中
- 保存一下，點擊deploy，生成一條Service Function Path，命名為“Chain-1-Path-1”,這樣就創建好了Service Function Paht。
3.4.6 創建Rendered Function Path
導航欄中點擊”Service Function Paths” ,將會看到我們剛創建的SFP。
根據SFP，點擊上圖按鈕，可以生成一條RSP。如果勾上了”Symmetric path”就會另外生成一條對稱反向的RSP。
成功以后，記住RSP的兩個重要屬性“Path-ID”為63，“starting-index”為255。
這個時候我們可以看到Agent里面打印的消息：
通過從SFC 的創建到SFP，再到RSP的創建，是一個由抽象到具體的過程。從應用的角度來理解，SFC是對Service Function的一層抽象，這里的SFP是具體化每個Service Function到其對應的配置的SF(SF1)，而RSP的生成代表包具體穿過的路徑將是怎樣的。
3.4.7 發送數據包
我們將發送數據包來遍歷這條簡單的SFC，“Path-ID”為63，“starting-index”為255。打開sfc/sfc-py/sfc/目錄，運行如下命令：
python3.4 sff_client.py --remote-sff-ip 192.168.2.134 --remote-sff-port 4789 --sfp-id 63 --sfp-index 255
Agent獲取結果如下：
從上圖可以看到客戶端（Client192.168.2.134:4790）發送包到SFF，SFF然后再將包發送給SF進行處理。SF處理完再轉回給SFF，SFF再尋找下一跳，如果沒找到，判斷為鏈表末尾。
3.4.8 實驗總結
以上我們簡單的演示了一個SFC的使用實驗，只包含了一個SFF和SF。通過在ODL中使用北向UI接口配置SF的信息，配置SFF的信息并關聯相應的SF下發給Agent。在這個過程里，我們還可以刪除，修改這些節點信息，充分體現了基于SDN的服務鏈的靈活性、拓撲獨立性。
用戶需要配置服務鏈的時候，只需要通過控制器的北向接口自由組合節點成有序序列。然后使用的時候，生成一條數據包路徑，并下發即可。同時，用戶也可以配置多條服務鏈。
注意，在不修改原始python腳本的情況下，在南向使用Agent可以創建多SF掛到一個SFF上，但只能創建一個SFF。
審核編輯：郭婷
工商網監
評論