SDSAN（Software Defined Storage Area Network，軟件定義存儲網絡）是用控制器去控制存儲流量的技術，由于FC技術門檻比較高市場比較穩定，而FCoE尚在推廣階段，因此軟件定義的風潮尚未大幅波及到SAN領域。不過，隨著SDN Fabric技術的蓬勃發展，可以預言SDSAN技術會成為補齊云中Convergent IO網絡的重要一環。
SAN的代表技術有iSCSI，FCIP/IFCP，FC與FcoE。iSCSI 、FCIP/IFCP均實現在TCP層以上，與底層網絡直接關系不大，目前SDSAN主流的思路都是通過控制器來實現對FC、FcoE的自動部署與集中控制。關于FC與FcoE的詳細介紹，請讀者參考之前的文章“新三網融合——計算存儲與網絡”。簡單地來說，存儲設備會在通信前發一些控制信令向網絡進行注冊，通信開始后網絡根據設備的位置進行路由。從SDN實現的宏觀角度來分析，無非就是控制器收集信令，形成存儲網絡的全局視圖，再下發轉發表指導存儲流量的路由。
目前，SDSAN的實現大多數處于概念驗證階段，國內華為號稱用Agile Controller+CE做到了FcoE的集中式控制，不過實際上現在國內就為此愿意買單的人估計極少，也就是花錢研發賺吆喝而已。老外對SDSAN的概念接受度應該比國內的接受度高得多，JedaNetwork是美國一家專門做SDSAN的創業公司，雖然也是做FcoE的集中式控制，不過估計產品實現上要專業的多。鑒于這個技術具有足夠的前瞻性和未來重要的市場地位，兩家的產品都沒有具體的技術資料出來，本文會從近年來少數幾篇涉及到SDSAN的論文中進行簡要的總結，希望對讀者能有所啟示。
1）NEC Advanced FcoE[1]
這是作者看到有SDSAN影子的最早的資料。AFCoE對當時單跳FcoE的實現提出了兩個不足：1.所有的流量都經過FCF，很容易成為流量的瓶頸。2. DCB不支持丟包數據重傳（目前DCB已不存在這個問題）。于是AFCoE通過Legacy Ethernet Swtich+FCC（FC Controller）的方式解決了可擴展性的問題，通過在server端部署gateway的方式去實現快速重傳。Gateway的實現我們不去關注，來看一看NEC是怎么通過Legacy Ethernet DCB Swtich來實現FCoE的，其組網和通信機制如下左右兩圖所示。
其實AFCoE的原理非常簡單，server或者storage送出FIP信令（包括FLOGI和PLOGI），被DCB Switch直接泛洪給FCC Server，FCC負責模擬FCF向server或者storage回復FIP消息，與之建立virtual link，并記錄PORT，MAC，FCID間的映射關系。通信開始后，FCC根據映射，模擬FCF進行FCoE流量的轉發以及源目MAC地址的改寫。
其實嚴格意義上來講，上述的AFCoE并不算是SDN，FCC可以看做通過inband方式部署在網絡中的一個FCF的軟件代理，而且由于是只涉及一個FCF所以也談不上什么全局視圖和存儲流量調度。于是，NEC當時說要AFCoE要結合OpenFlow實現端到端FcoE，如下圖所示，這就是真正意義上的SDSAN了，不過后續具體推動到什么程度，沒有看到資料也不得而知。
2）Fujitsu OpenFlow FcoE solution[2]
與AFCoE類似，Fujitsu也是提出了一個邊緣FcoE組網的SDN解決方案。Fujitsu對OpenFlow的Match域進行了擴展，使得OF Switch能夠識別FcoE的相關字段（如FCID）從而可以據此進行Storage流量的轉發。其原理如下圖所示。
圖中，網絡中仍然存在FCF，sever和storage直連的淺藍色盒子為擴展后的OpenFlow交換機，結合Controller充當一個FIP Snooper。當server或storage發出FLOGIN Request后，OF交換機將其交給Controller，Controller記錄下PORT，Enode_MAC和FCF MAC間的映射關系，構建server和storage的LOGIN Table，并指導交換機將該消息傳給FCF。FCF回復FLOGIN Accept消息后，OF交換機將其交給Controller，Controller記錄下FCID和FPMA，結合LOGIN Table中的信息形成forward table（主要目的的匹配以及MAC地址的修改），并下發給OF交換機指導storage流量的轉發，上述兩張表的形成規則以及控制器的處理邏輯如下所示。
FIP過程結束后，Storage流量開始傳遞。對于不同OF交換機下server或storage間的通信，OF交換機轉發給FCF，再有FCF轉發到另一臺OF交換機上；對于同一OF交換機下server或storage間的通信，該OF交換機直接按照控制器下發的forward table完成轉發，不再迂回經過FCF，一定程度上解決了FCF上的流量瓶頸問題。
這個方案相比于AFCoE，已經向真正的SDSAN邁出了一大步，不過仍存在以下三個問題：
FIP需要通過Keep Alive消息來維持server/storage間virtual link的狀態，這部分信令如果都交給控制器處理的話是一個很大的開銷，因此當網絡中節點較多時，可能需要將FIP Keep Alive的處理offload到交換機本地進行實現。雖然基于FCoE的幀格式對OpenFlow交換機進行了擴展，然而OpenFlow交換機仍然不支持DCB的某些無丟包特性，因此數據平面離真正的SDSAN還有差距。實現了FCoE的邊緣接入，然而對Storage流量的端到端傳輸并未做集中式的控制。3）Huawei CSN[3]
相比于FCoE，FC的技術其實更為成熟，其簡易的架構如下左圖所示。因此相比于SD FCoE，更為徹底的SDSAN其實應該是SD FC。雖然華為在Agile Controller中說的是對FCoE進行集中式控制，但是華為聯合南京大學在去年發表了一篇論文對SD FC進行了初步的探討與設計，其架構如下右圖所示，論文中將其命名為CSN（Controller-based FC Storage Network）。
CSN架構中，通過對FC交換機的軟件進行升級，使得其上電后立即與FFC（FC Fabric Controller）建立TCP連接，并交互FC的控制信令。控制信道建立和傳輸過程如下左圖所示，控制信令消息類型如下右圖所示。其中第1類消息維護控制信道的狀態，第2類消息處理Server或Storage的登錄，第3類消息用來收集FC網絡拓撲，第4類消息用來更新FC網絡路由表。
FC交換機連接上FFC后，將Server或Storage的FLOGI和PLOGI請求通過控制信道轉交給FFC，FFC封裝回復消息通過交換機回傳Server或Storage，并記錄下Server或Storage的位置信息、身份信息。除了Server或Storage的信息以外，FC網絡的拓撲信息對于SDSAN來同樣重要，為實現該信息的收集，FC交換機會在本地進行鄰居探測，新檢測到的、斷掉的FC鏈路將分別通過EPort UP和EPort Down請求發送給FFC，FFC發送相應的確認消息進行確認。擁有了全局信息后，FFC即可通過FSPF算法計算Storage流量的端到端路徑，并通過Routing Table消息通知FC交換機。、
CSN是一個比較完整的SDSAN方案，其架構的通用性能夠使其應用到任意的SAN網絡中，對數據平面也不需要任何的修改，是SD FCoE的重要演進方向，估計華為Agile Controller對FCoE的處理也是如出一轍的。
SDSAN在國內目前仍看不到明顯的市場需求，不過拍腦門想就知道，存儲網絡的SDN化那是遲早的事，希望以后能看到業界或者學術界更為成熟的數據平面和控制平面的解決思路。
作者簡介：
張晨，北郵研究生，北京郵電大學信息與通信工程學院未來網絡理論與應用實驗室（FNL實驗室），網絡與交換技術國家重點實驗室
主要研究方向：SDN、虛擬化、數據中心
個人博客：sdnv.xyz
個人郵箱：[email protected]
京公網安備 11010502049343號