基于控制中心的新型SAN架構的設計與實現

陸一飛　張震偉　陶　軍　唐　玲

1(南京理工大學計算機科學與工程學院　南京　210094)2(華為技術有限公司南京華為研究所　南京　210012)3　　　(東南大學計算機科學與工程學院　南京　210096) (luyifei@njust.edu.cn)

?

基于控制中心的新型SAN架構的設計與實現

陸一飛1張震偉2陶軍3唐玲1

1(南京理工大學計算機科學與工程學院南京210094)2(華為技術有限公司南京華為研究所南京210012)3(東南大學計算機科學與工程學院南京210096) (luyifei@njust.edu.cn)

摘要隨著互聯網技術的快速發展，數據的爆炸式增長，存儲系統的軟硬件緊耦合設計嚴重地限制了存儲技術的發展，也越來越無法滿足移動互聯網和大數據時代下對存儲系統快速、多變的需求.軟件定義網絡(storage defined network, SDN)作為一種新的網絡架構，更適合下一代數據中心的發展.在SDN思想基礎上，提出了一種基于控制中心的新型SAN架構(controller-based SAN, CSN)，該架構分離FC交換機的協議控制面和數據面，將FC協議的控制功能和分布式服務功能部署在控制器中，隨后詳細闡述了該架構的控制器設計、通信機制和整體機制的設計與實現.在CSN基礎上，又提出了按需可用帶寬優先路由協議.最后，通過實際開發環境驗證該架構的可行性.通過實驗測試，得出CSN下服務器能夠更快地與存儲服務器建立連接，并且存儲網絡具有更高的吞吐量、更快的收斂性、更好的可靠性和可擴展性，此外，還對中心控制器的CPU、內存和帶寬進行壓力測試.

關鍵詞FC協議；存儲區域網絡；存儲區域網絡架構；軟件定義存儲網絡；控制器

隨著Internet和網絡技術的飛速發展，特別是數據中心網絡的興起，信息系統的數據呈爆炸式增長，數據的高速訪問和平滑簡單的擴容要求日益迫切.目前，業界使用專門的存儲區域網絡(storage area network， SAN)[1]支持服務器與存儲設備之間的數據高速傳輸.SAN一般使用光纖通道(fibre channel, FC)[2]技術，其擁有自動尋址、設備發現、狀態變更通知等先進的存儲機制，為發起端設備(服務器系統)和目標端設備(存儲器系統)之間的數據交換提供了便利.一般使用FC的SAN(FC-SAN)傳輸速度可以達到4 Gbps，8 Gbps或者更高的16 Gbps.近年來基于以太網FC的SAN(FCoE-SAN)[3]也在快速地發展和應用.本文只討論FC-SAN下的相關研究.

軟件定義網絡(software defined network, SDN)[5]技術通過分離網絡設備的控制面與數據面，將控制功能從網絡設備中分離出來，形成集中化的控制中心(控制器).網絡設備維護流表結構，數據分組按照流表進行轉發，而流表的生成、維護、配置則由中心控制器管理.當前，控制中心對交換機的控制主要通過OpenFlow協議[6]實現.

SDN技術為研發網絡新應用和未來互聯網技術提供了一種新的解決思路.FC-SAN架構下網絡側的功能較為復雜，如果利用SDN技術把FC-SAN的控制面功能放到控制中心，就能極大地減輕網絡復雜度，提高數據面的轉發能力.這種基于SDN的存儲網絡解決方案稱為軟件定義存儲網絡(software defined storage network, SDSN)[7]，這個概念首先由Jeda公司在2013年的SNIA[8]開發者大會上提出，隨后SDSN思想迅速成為存儲界關注的焦點.

本文在SDN思想基礎上，創新性地提出了將FC協議與控制器相結合的新型SAN架構：基于控制中心的SAN架構(controller-based SAN， CSN).CSN分離FC交換機的FC協議控制和數據轉發功能，將FC協議的控制機制和分布式服務部署在FC交換網控制器(FC fabric controller， FFC)，使存儲網絡具有靈活控制機制的同時，還擁有高可靠性、擴展性以及更高的網絡性能.

本文的主要貢獻有2點：

1) 有別于傳統FC-SAN，本文將FC協議的控制面協議和分布式服務在FFC中實現，設計了控制器和FC交換機間的通信機制，使存儲網絡具有更加的靈活性、可靠性和擴展性.

2) 利用FPGA開發板實現了FC協議和CSN架構，并通過實驗驗證了CSN架構的優勢.

1相關研究

1.1FC-SAN協議

FC協議是SAN的事實標準.FC交換機通過E端口的分布式服務形成存儲交換網，而交換網又為整個網絡提供名字服務(name server, NS)和分區服務(zone)等分布式服務，如圖1所示.服務器和存儲通過注冊過程登錄到交換網.

Fig. 1　The architecture of FC-SAN.圖1　FC-SAN架構

NPort登錄[9]是指NPort端口注冊到交換機和注冊到NS過程.一般來說，該過程有2步：①NPort發送FLOGI到 FC交換機，FC交換機返回的ACC(accept)報文，該ACC報文中向NPort分配了一個FC ID(FC identity)，并規定鏈路間的服務類型等參數；②NPort發送PLOGI報文到FC交換機，向NS注冊登記.具體過程如圖2所示：

Fig. 2　Process of NPort login.圖2　NPort注冊過程

交換網的配置[10]是指FC交換機間的EPort連接時建立連接和生成路由的過程.交換網配置過程一般分為5步：EPort端口間交換鏈路參數、協商交換機能力、主交換機選擇、域ID分配以及FSPF(fabric shortest path first)路由算法，如圖3所示.另外還有些其他高級功能也會在交換網配置過程中實現，譬如zone的合并、分布式名字服務等.總體來看，交換網配置是一個漫長和復雜的過程，最終生成交換網的路由.

Fig. 3　Process of EPort protocol.圖3　EPort協議過程

在FC協議中，NPort登錄時服務器信息記錄在NS中，在服務器間通信時需要通過分布式的查詢服務獲取對端的信息，所需的時間較長.同時，交換網配置過程不僅所需的收斂時間較長，而且其中FC交換機一旦變化就需要重新進行主交換機選擇等步驟，對網絡性能影響較大.本文提出的CSN架構主要是優化這部分協議.

1.2相關研究

文獻[11]中分析了FCoE-SAN下的數據流都要通過FCoE轉發者(FCoE forwarder， FCF)，限制了FCoE-SAN的網絡規模.因此在文獻中提出了一種在網絡邊緣交換機分離FCoE數據幀的方法(AFCoE)，數據幀分為用戶面幀和控制面幀，數據面幀通過以太網交換機轉發，而用戶面幀被傳輸到控制服務器中處理.這種方法可以在一定程度上緩解FCF的壓力，從而增加FCoE-SAN的規模，但是這種方法只把FCoE的控制面幀轉移到控制器，用戶面幀還是要經過FCF，而控制幀只占所有數據幀中的很小部分，因此該方法對于緩解FCF的壓力比較有限.

Jeda公司在2013年的SNIA開發者大會上提出基于SDN思想的SDSN方案[12],該方案在FCoE-SAN網絡中分離FCoE交換機的控制層和數據層，并使用軟件交換網控制器(fabric network controller, FNC)替代物理FCoE-SAN中的網絡控制層，建立更加靈活、可擴展性更強的動態存儲網絡.FNC以VMware虛擬機的形式提供服務，與服務器、存儲服務器和交換機交互以獲取所需信息.另外，FNC對邊緣交換機添加ACL規則，以此優化數據流的轉發，提高存儲網絡性能.

文獻[13]在FCoE-SAN環境下，利用SDN思想對FCoE協議的部分控制進行分離，將其中的FIP報文轉發到控制器，而其余的報文轉發到FCF.控制器通過分析FIP報文記錄服務器的位置，然后對邊緣以太交換機下發新的轉發表，優化數據流路徑，數據流不再通過FCF處理.該文獻也討論了OpenFlow協議在此的作用.

以上的研究都聚焦于SDSN研究，但都只通過改變邊緣交換機的轉發表優化數據流，而且，只分離了FCoE協議中的部分控制報文(如FIP報文或部分控制幀).另外，目前的研究都聚焦于融合網絡，即FCoE-SAN，它的特點在于架構簡單但是規模很大，這與FC-SAN有一定的區別.最后，以上的研究都沒有對控制器的處理能力進行分析.

本文聚焦于基于SDN思想的FC-SAN研究，分離FC協議本身的控制面流量和數據流量，并且將FC協議和分布式服務在控制器中處理，以此簡化FC協議的實現，建立更加靈活、可擴展性更強的存儲架構.

2基于控制中心的SAN架構

傳統的FC-SAN架構下存在交換網配置復雜、網絡收斂速度慢和各硬件廠商間的設備不兼容等問題.同時，FC交換機需要實現各種功能，如分布式名字服務、分布式分區功能和路由功能等，因此交換網中FC交換機的變更(功能增加、節點的增刪)會對整個網絡帶來較大的變動，網絡控制流量大量增加，影響網絡傳輸性能，網絡管理異常復雜.為了改善這些問題，本文基于SDN思想提出CSN架構.

2.1CSN整體架構

CSN架構在傳統的FC-SAN基礎上增加了控制器FFC，FFC與FC交換機通過專門的管理網絡(以太網)連接，且通過TCP協議進行通信，服務器和FC交換機間、FC交換機間的鏈路不變，仍然使用FC鏈路.

CSN架構如圖4所示：

Fig. 4　The architecture of CSN.圖4　CSN架構

Fig. 5　The function modules of FFC.圖5　FFC功能模塊

在CSN架構下，FC交換機保留了原有的數據面處理功能、增加了FC代理模塊，該模塊包括了簡化FC協議處理功能和通信功能.簡化FC協議功能負責解析FC交換機收到的FC控制報文，并根據需要配置交換機或者將報文轉交給通信模塊處理.通信模塊負責建立和維護與FFC的TCP鏈路，同時對FC控制報文進行封裝和解封裝.

FC交換機將收到或自身產生的FC控制協議消息轉發給控制器，控制器收到FC報文后進行應答，下發到FC交換機，FC交換機根據情況保留該應答報文或者轉發給服務器.

2.2控制器設計

FFC作為CSN架構的核心，由軟件實現并部署在專門的主機設備上.FC協議棧、路由協議和分布式服務都要在FFC上實現，也即FFC是整個網絡的控制中心.

FFC的功能模塊如圖5所示，它的功能模塊包括TCP通信模塊、控制報文解析器、FFC處理單元和FFC信息庫.TCP通信模塊負責與FC交換機通信，它們之間通信的TCP報文中封裝了控制信息和FC控制報文，因此，需要報文解析器對收到的TCP報文進行解析，并將解析后的報文遞交給FFC處理單元.FFC處理單元和FFC信息庫是控制器的核心模塊.FFC處理單元包含多個子單元，分別處理解析器遞交來的報文，如TCP通信處理子單元會處理TCP鏈路的建立、保活和關閉；NPort協議處理子單元維護FC協議中的NPort登錄和登出等控制信息；EPort協議處理子單元維護EPort啟動和關閉等控制信息；名字服務處理子單元為FC交換網中的名字服務器，記錄了交換網中的所有NPort信息；路由處理子單元負責生成和維護交換網的路由.FFC處理單元處理后的相關信息會保存至FFC信息庫中，生成節點信息庫和交換網信息庫，其中的全局拓撲信息庫為路由計算提供依據，最終形成路由表并下發給FC交換機.

2.3CSN通信機制

CSN架構下，FFC與FC交換機間通過以太鏈路進行通信，它們間的通信根據功能不同，可以分為2類：FC交換機和FFC間建立和維護TCP連接的通信；轉發FC協議報文的通信.

在FC交換機啟動時，與FFC間通過3次握手建立TCP連接，其中FC交換機端為客戶端，FFC為服務器端.同時，為了維護TCP連接，FFC會周期性向FC交換機發送保活報文.FC交換機收到后，同樣返回保活報文，當控制器或者FC交換機連續3次沒有收到該報文時，表示對端失效，釋放相關資源.

由于FC交換機與FFC間使用TCP協議，當FC交換機與FFC間傳輸FC控制報文時，需將把FC報文封裝成TCP報文，當然，FC交換機和FFC收到TCP報文時，也需要解析報文得到FC報文或其他控制報文.FC交換機與FFC間的TCP報文封裝格式如圖6所示：

Fig. 6　TCP encapsulation format of FC packet.圖6　TCP封裝FC報文格式

其中，Type字段大小為1 B，表示TCP報文中數據的類型.目前，我們把FC交換機與FFC通信過程的報文分為4類：1)FC交換機與FFC間的控制報文；2)NPort端口登錄時產生的控制報文；3)EPort開啟關閉時產生的控制報文；4)控制器向FC交換機下發的流表報文.

Command字段大小為1 B，表示每種類型下的操作符，具體的含義如表1所示.Length字段表示包括Type和Command字段在內的整個數據字段的長度，是以4 B為單位.Data字段在不同Type和Command數值下有不同的格式，在此不再詳述.

Table 1　Meaning of Type and Command Field

目前，控制器只向FC交換機下發整個路由轉發表操作，并沒有區分增加流表、刪除流表等操作，這部分內容會在以后的研究中改進.

從上面的通信機制描述可以看出，FC交換機和FFC間的通信協議與SDN中的OpenFlow協議有些類似，都是在交換機和控制器間建立連接、維護鏈路，并且可以下發轉發表(路由表)，但是本文并沒有使用成熟的OpenFlow協議，原因是：1)OpenFlow協議中目前還沒有控制存儲數據流的方法；2)FC協議中雖然有類似IP和MAC地址的概念，但這些字段的大小跟IP和MAC有差異，OpenFlow的流表結構不適用于FC-SAN；3)CSN中的通信機制是基于TCPIP的一個獨立模塊，這種方式更利于在傳統的FC交換機上進行補丁升級，而不需要另外重新設計支持OpenFlow協議的設備.

2.4CSN整體機制的設計與實現

FC交換機啟動時需要跟FFC建立TCP連接.當建立TCP連接后，FC交換機會向FFC發出登錄請求報文，請求報文中包含了自身的信息和向FFC請求域標識(identity， ID)信息.FFC收到請求后，返回登錄請求應答報文，向FC交換機分配域ID.同樣，當FC交換機或者FFC關閉時，會發出登出請求報文、對端回復登出應答報文，然后釋放自身相關的信息，如內存空間、域ID等.在此期間，FFC和FC交換機間會周期性地發送保活報文交互信息.具體過程如圖7所示：

Fig. 7　Interactive process between FC switch and controller.圖7　FC交換機和控制器交互過程

登錄請求報文和登錄應答報文如表2和表3所示.登錄請求報文中Type，Command和Length字段前面已經做了描述.會話ID用來唯一表示此次請求過程，FFC的請求應答報文的會話ID跟此值一致.交換機名字指交換機的全球范圍節點名字(world wide node name, WWNN)[14]，用來唯一標識FC交換機.如果FC交換機申請某個具體域ID，則域ID字段設為想申請的域ID值，否則域ID字段置為0，表示向FFC請求分配域ID.端口數量字段表示該FC交換機擁有的端口數量.端口信息字段又包含了端口索引、端口類型、端口速度等字段.

Table 2　Login Request Packet

Table 3　Login Request ACK Packet

登錄請求應答報文中會話ID跟登錄請求報文中的會話ID一樣.應答碼為200時，表示接受登錄請求(ACC)，此時，域標識字段值表示FFC為FC交換機分配的域ID；應答碼為201時，表示拒絕登錄請求(RJT)，域ID字段無效.

FC交換機的登出過程與上面描述類似，登出請求報文和登出請求應答報文在此不再詳述.

FC交換機登錄和登出之間，FFC會周期性地(本文實現中設為2 s)向FC交換機發送保活報文，FC交換機收到保活報文后同樣返回保活報文，如果控制器或者FC交換機連續3次沒有收到保活報文，則認為對端失效，會發出登出請求報文，并釋放本端的相關資源.表4所示為FC交換機發送給控制器的保活報文.

Table 4　Keep-alive Packet

保活報文中的Type，Command和Length字段不再詳述，交換機名字唯一表示了保活通信中的FC交換機，序列號表示保活報文發送的順序，該值越大表示保活報文越新.其他信息字段作為預留，在后面的研究中使用.

2) 服務器端NPort注冊和注銷

在NPort的注冊過程中，NPort發出FLOGI報文，FC交換機收到后解析該報文，收集相關信息生成NPort FLOGI請求報文，封裝后轉發給FFC，FFC收到后解封裝得到NPort的注冊信息，為NPort分配FC ID和參數配置等信息，并返回NPort FLOGI應答報文.FC交換機收到NPort FLOGI應答報文，如果返回的是ACC報文，解析出其中的參數信息，對相應的FPort進行配置，并轉發ACC報文到NPort.同樣，NPort注銷過程也類似，FC交換機需要對NPort LOGO報文進行重新封裝，并在最后釋放FPort和控制器中的相關資源配置.

NPort的注冊和注銷過程如圖8和圖9所示.

Fig. 8　Login process of NPort.圖8　NPort注冊過程

Fig. 9　Logout process of NPort.圖9　NPort注銷過程

NPort注冊中，NPort發出的其他FC控制報文(如PLOGI報文等)，FC交換機收到后不做處理，直接封裝成TCP報文轉發給FFC，由FFC進行應答.

NPort FLOGI請求和應答報文格式如表5和表6所示.在請求報文中需要攜帶FC交換機的名字和與NPort對應的FPort索引信息，另外，在請求報文中還需要NPort的全球范圍端口名字(world wide port name, WWPN)[14]、FC ID(如果需要申請某個FC ID，則FC ID字段填寫該值，否則FC ID字段置為0)和該NPort的參數信息.在應答報文中會攜帶應答碼、分配給NPort的FC ID和相關配置參數.

Table 5　NPort FLOGI Request Packet

Table 6　NPort FLOGI Request ACK Packet

3) 交換網的配置和維護

在CSN架構下，FC交換機間不再使用FC協議的EPort機制[10]，而是在FFC中實現交換網的配置和路由功能.FC交換機在開機初始化時會向FFC注冊，這樣FFC就獲得了全局的FC交換機信息.隨后，通過EPort啟動時的注冊過程，FFC就獲得了FC交換機間的連接關系，至此，FFC獲得了交換網的全局拓撲結構，最終通過路由協議計算出交換網的路由.

FC交換機間EPort連接時，會通過端口的交互得知端口是EPort，并且也可得知對端FC交換機名字.隨后，FC交換機向FFC發送EPort啟動請求報文，該報文中攜帶了該EPort的參數(FC交換機ID、端口索引、端口帶寬、緩存大小等)和對端FC交換機名字.FFC收到EPort啟動請求報文后，返回EPort啟動請求應答報文，報文內容包括協商后的帶寬、緩存大小等.最后，FFC通過全局的路由計算，向所有FC交換機下發新的路由表報文.該過程如圖10所示：

Fig. 10　Fabric configuration process.圖10　交換網配置過程

EPort啟動請求報文如表7所示.EPort啟動請求報文包括了自身交換機名字(交換機Name_1)和對應EPort的端口索引、對端FC交換機名字(交換機Name_2)和對應EPort的端口索引以及該EPort中的參數(包括鏈路速率、緩存等).EPort啟動請求應答報文在此不再贅述，如表8所示.

Table 7　EPort UP Request Packet

Table 8　EPort UP Request ACK Packet

在CSN架構下，交換網的路由算法使用FC協議中基于最短路徑的FSPF算法，在此不再介紹該算法.表9是路由表報文格式，其中最重要的是路由表項，路由表項包括FC ID、前綴和接口索引，該表項類似于傳統網絡中的路由表.

Table 9　Routing Table Packet

4) FFC性能優化

FFC作為CSN架構的控制中心，一旦出現問題會對整個網絡造成不可估量的危害，因此有必要對影響FFC性能的因素進行評估優化.由FFC的功能模塊可以知道FFC有2個服務對象：FC交換機和服務器存儲服務器.因此，主要從FC交換機和服務器存儲服務器數量2個方面考慮對FFC的性能影響.

① 我們知道，FC-SAN網絡的建設成本很高，維護的難度和費用較大，因此，在企業的存儲網絡中只有特別重要的應用(如重要的審批流程、財務應用等)才會使用高速穩定的FC-SAN，其他應用會使用相對便宜的IP-SAN.這就決定了FC-SAN的規模不大，FC交換機的數量不會很多，在此我們不考慮FC交換機同步登錄對FFC的影響，而主要優化FFC與FC交換機維護連接的開銷影響，即定期發送keep-alive報文的影響.在此，我們在設計keep-alive機制時，該報文是由FFC主動發出，FC交換機收到后回復，因此，可以通過建立keep-alive發送規則避免同時收發keep-alive報文影響FFC的性能.

keep-alive發送規則：假定發送keep-alive報文的周期為T，FC交換機的數量為N，則FFC每隔TN的時間發送keep-alive報文給其中一臺FC交換機.

② FC-SAN的規模雖然不大，但是其中的服務器數量肯定要遠大于FC交換機的數量，因此我們必須要針對網絡中的服務器數量進行壓力測試.這部分工作將在第4節的實驗6中做詳細的分析.

3COBF路由

SAN是一種專注于信息存儲、訪問和管理的高速網絡，它采用高速通道連接服務器和存儲系統以此獲得較高的傳輸速率，但是在SAN中使用的路由協議為最短路徑協議，這種路由協議僅考慮使用最小跳數作為路由判據，并沒有考慮利用鏈路的可用帶寬來提高網絡整體傳輸效率，因此，本節我們在CSN架構的基礎上提出了按需可用帶寬優先(CSN-based on-demand bandwidth-available first，COBF)的路由協議.

COBF路由協議在CSN的FFC端實現，并且以路徑上的可用帶寬作為選擇路由的判據，其COBF路由判據MCOBF定義如下：

定義1. 對于某條路徑，COBF路由判據的數學定義為

其中，p表示網絡上的一條路徑，l是路徑p上的一條鏈路，la為鏈路l上的可用帶寬，α為常量，在此α=1.0.

在此鏈路的含義是FC交換機端口間的連線，因此，鏈路的可用帶寬是指鏈路兩端交換機端口的可用轉發速率的最小值，即la=min{rm,rn}，其中rm，rn分別是鏈路兩端FC交換機端口的可用轉發速率.FC交換機端口的可用轉發速率在CSN架構下可以通過FC交換機定期上報獲取，在此，我們擴展了CSN中的保活報文，在保活報文中增加了交換機端口的可用轉發速率，擴展后的保活報文如表10所示：

Table 10　Keep-alive Packet of COBF

至此，CSN架構中的FFC端就具有了計算路由的所有信息.對于每個路由請求，FFC可以計算出服務器和存儲間每條路徑的路由判據，選出路由判據最小值的路徑為最終的路由，并向FC交換機下發路由轉發表.

4實驗和測試

4.1驗證環境

CSN架構的驗證環境包括了4塊FPGA開發板、4臺PC機、1臺FFC、1臺服務器和1臺存儲設備，組成了如圖11的驗證環境，其中驗證環境中所用的設備清單如表11所示.FPGA開發板與PC機通過PCI-E擴展槽連接，實現了FC交換機功能，其中FPGA開發板主要實現交換機的端口和數據轉發功能，PC機實現交換機的CPU功能.同時，PC機通過自身的以太網卡連接到FFC.FPGA板卡上收到的FC控制報文轉交給PC機中FC代理模塊，FC代理模塊對FC報文簡單處理并重新封裝后通過TCP通信模塊轉發給FFC.

Fig. 11　CSN test environment.圖11　CSN驗證環境

Device∕SoftwareManufacturerandModelOSNumberServerHuaweiTecalRH2285V2VMwareESXi5.04StorageHuaweiOceanStorS22001PCLenovoThinkCenterSeriesUbuntu12.04∕WindowsXP5FPGABoardStratixIVEP4SGX2304IometerIometer1.1.01

4.2實驗分析

在CSN架構下，FC交換機上數據面的處理跟傳統的FC-SAN是一樣的，都是通過路由表轉發數據，因此這部分實驗主要是針對FC協議的控制層面.這部分測試CSN架構下交換網絡的延遲、收斂速度、數據轉發吞吐量和針對FFC的壓力測試.實驗結果都是重復10次實驗的平均值.

實驗1. NPort注冊時間

該實驗測試FC-SAN和CSN架構下服務器NPort注冊時間的差異.NPort的注冊時間是指NPort發出FLOGI報文到發送向存儲設備登錄的PLOGI報文的間隔.FC-SAN架構下的NS是分布式服務，服務器和存儲位置的不同對NPort注冊時間有較大的影響，因此，該實驗針對圖12中的3種場景進行測試.實驗結果如圖13所示.

Fig. 12　NPort login scenes.圖12　NPort注冊場景

Fig.13　NPort login time for three scenes.圖13　3種場景下的NPort注冊時間

從圖13可以看出，單跳場景下CSN架構的NPort注冊時間要高于FC-SAN架構，這是由于NPort注冊時CSN架構下NPort需要與控制器進行交互，這比NPort直接與FC交換機交互的時間要長.在其他2種場景下，傳統FC-SAN架構下的注冊時間要明顯高于CSN架構下的注冊時間，這是由于服務器跟存儲通信時需要獲得全網的NS功能，而此功能在FC-SAN架構下是分布式的，類似于TCPIP中的域名服務，當FC交換機本地沒有存儲的信息時，需要通過查詢的方式獲得，服務器與存儲間的距離(跳數)越遠，查詢時間也越久.而CSN架構下，NS功能部署在控制器中能直接獲取，因此，在3種場景下，CSN架構的NPort注冊時間基本不變.

實驗2. 交換網初始化

Fig. 14　Network initialization time.圖14　網絡初始化時間

這部分實驗測試FC-SAN和CSN架構下交換網初始化所需的時間.交換網初始化時間是指FC交換機上電到整個交換網路由收斂完成所需的時間，即FC交換機啟動完成并獲得了全局路由轉發表的時間.為了把其他影響因素去除，這部分實驗并沒有把服務器和存儲設備連接到網絡中.

本次實驗分4種情況：只開啟1臺FC交換機、同時開啟2臺FC交換機、同時開啟3臺FC交換機和同時開啟4臺FC交換機，分別記錄下最終的交換網初始化時間，結果如圖14所示.從圖14看出，單臺FC交換機時，CSN架構所需時間要略多于FC-SAN所需時間，這是因為CSN下FC交換機需要向FFC注冊并通過FFC下發路由表，而傳統的FC-SAN不要執行路由協議等操作；在多于2臺FC交換機下，CSN架構的網絡初始化時間要比FC-SAN架構小，原因是FC-SAN架構下交換網初始化需要全局交換信息，選舉主交換機和執行FSPF路由分布式算法等步驟，而CSN下的路由只在FFC上計算完成，因此CSN下的網絡初始化時間要比FC-SAN架構小，而且網絡規模越大，CSN架構的優勢更加明顯.

實驗3. FC交換機增加

這部分實驗測試隨著FC交換機的增加，交換網路由收斂時間的變化.該實驗同樣沒有把服務器和存儲連接到交換網中.實驗中，FC交換機從1臺增加到4臺，交換網路由的收斂時間變化如圖15所示：

Fig. 15　Routing convergence time when increasingthe number of FC switches.圖15　FC交換機增加時路由收斂時間

從圖15可以看出，在只有1臺FC交換機情況下，FC-SAN下的收斂時間要略小于CSN架構下的時間，原因在實驗2中已經闡述.但是隨著FC交換機的增加，FC-SAN架構下的路由收斂時間要明顯多于CSN架構下所需的時間，而且網絡規模的越大，兩者的收斂時間差別越大，這是由于FC-SAN架構下需要執行復雜的分布式交互，且需要通過全局泛洪的方式計算路由，所用時間較多.而CSN架構下，FC交換機只需要向控制器進行注冊，使控制器擁有全網的拓撲結構，使用集中式路由計算就可以得出全局路由，所用時間較少，CSN下的路由計算時間主要受FFC本身計算性能等因素的影響.

實驗4. 刪除FC交換機

該部分實驗測試在FC-SAN和CSN架構下，4個FC交換機刪除其中1個FC交換機時對交換網路由的影響.由于在FC-SAN架構下，有主FC交換機的概念，所以該部分實驗分別刪除主FC交換機和非主FC交換機得到交換網路由的收斂時間，測試結果如圖16所示.

從圖16看出，刪除主FC交換機對FC-SAN的影響較大，因為刪除主FC交換機后需要重新通過泛洪的方式選舉主FC交換機，因此，所需的網絡收斂時間更長.在刪除非主FC交換機時，FC-SAN架構所需收斂時間也要大于CSN架構，因為刪除FC交換機后需要擴散鏈路狀態信息，并重新計算路由.而這部分時間在CSN下是不需要的，CSN下刪除FC交換機只需要執行FC交換機的登出請求過程，并在FFC重新計算全網路由，時間較短.

Fig. 16　Routing convergence time when shutdownFC switch.圖16　FC交換機刪除時網絡路由收斂時間

實驗5. 網絡吞吐量

該部分實驗針對FC-SAN和CSN兩種架構，在CSN下針對CSN的FSPF和COBF路由，分別標識為CSN-FSPF和CSN-COBF.在圖12(c)的環境下測試交換網整體吞吐量.該實驗過程包括交換網初始化，然后連接服務器和存儲，最后服務器通過Iometer[15]工具讀寫存儲中數據，并且在讀取過程中斷開非主FC交換機鏈路和主FC交換機鏈路.整個實驗過程中記錄下交換網整體的吞吐量，實驗結果如圖17所示：

Fig. 17　Throughput of fabric.圖17　交換網吞吐量

從圖17可以看出，在網絡初始化和讀寫存儲中數據時，FC-SAN和CSN-FSPF的最大吞吐量基本一致，這也表明CSN架構對網絡數據面的轉發并沒有太大的影響;而當使用CSN架構下COBF路由時，網絡的最大吞吐量要比FC-SAN和CSN-FSPF高10%左右.當斷開非主FC交換機鏈路時，CSN-FSPF和CSN-COBF架構下的吞吐量恢復速度要比FC-SAN架構更快.而斷開主FC交換機鏈路時，FC-SAN網絡吞吐量的恢復需要更多的時間.因此我們可以看出，CSN架構可以對存儲網絡進行更合理的路由規劃、獲得更優的吞吐量，同時該架構反應更加靈敏、控制更加高效和靈活.

實驗6. FFC壓力測試

CSN架構中的核心為FFC，一旦FFC的性能下降或者失效，將影響整個存儲網絡的性能，甚至崩潰.因此，這部分實驗我們將對FFC進行壓力測試.本實驗中FFC控制器的配置如表12所示，存儲網絡中有4臺FC服務器，分別接入4臺FC交換機.該實驗主要通過增加服務器并發啟動的數量來測試FFC的CPU、內存和帶寬利用率變化情況.由于實驗室的服務器數量有限，因此實驗中通過虛擬機來代替物理服務器，一共創建了20臺虛擬機.實驗時通過同時打開1～20臺虛擬機，在FFC控制器中記錄CPU、內存和網絡帶寬的瞬時利用率最大值，并通過重復10次實驗，得到瞬時利用率最大值的平均值和10次實驗瞬時利用率的最大值，同時記錄下FFC穩定狀態下的各項指標利用率，得到實驗結果如圖18所示.

Table 12　Hardware of FFC

Fig. 18　Stress Testing of FFC.圖18　FFC壓力測試

圖18(a)(b)(c)可以看出，隨著服務器數量的增加，CPU、內存和網絡帶寬的瞬時最大值利用率也隨之增加；但是在服務器數量較少時，CPU和網絡帶寬的利用率變化較少，隨著服務器數量增加，利用率增加得較快，而內存利用率基本隨著服務器數量的增加而增加.

圖18(d)表示服務器登錄完成后，FFC的穩態利用率變化情況.CPU和網絡帶寬的利用率變化不大，而內存利用率輕微增加，這主要是因為在穩態情況下FFC的開銷主要是用于FFC和FC交換機間的通信，本實驗中交換機數量沒有變化，因此CPU、帶寬的使用開銷變化不大.而內存利用率稍微增加則主要是因為隨著服務器的增加，FFC中記錄服務器的信息也相應增加，因此內存利用率增加.

通過以上的測試我們可以得出，在大量服務器并發啟動的過程中，對FFC的CPU、內存和網絡帶寬都會有影響，但是影響較大的是內存和CPU，這可以通過增加內存和優化FFC處理代碼等手段緩解；另外，通過增加FFC的數量并采用已有的負載均衡方案，也能得到較好地解決.

5結論和展望

本文研究存儲網絡中的FC-SAN架構和SDN技術，并基于SDN提出了一種基于中心控制器的新型存儲架構，分析了CSN對FC-SAN的改進；隨后詳細描述了CSN架構下控制器功能、FC協議改進和通信機制等內容，并設計了基于CSN的按需可用帶寬優先路由協議；最后，通過實際的驗證平臺測試了CSN架構下的整體性能，不管是FC交換機的增刪或者是交換網的初始化，CSN架構下交換網路由的收斂時間要明顯優于原有FC-SAN架構，而且網絡規模越大優勢也越明顯，同時，在COBF路由協議CSN架構能夠獲得更高網絡吞吐量，最后對CSN的核心部件FFC進行了壓力測試.

本文下一步工作希望對CSN架構的功能進行改進和增加，在FFC下發路由時支持增刪功能；在控制器中增加FC協議的其他一些功能，如分區功能，使得整個CSN架構功能更加完善.另外，我們將針對FCoE-SAN環境，對CSN架構進行改造，使其支持FCoE協議，并在FCoE-SAN環境下進一步優化FFC的性能，使其能在大規模網絡下工作.最后，修改OpenFlow協議使其能夠在FCFCoE環境下工作.

參考文獻

[1]Vladmir V, Riabov. Storage Area Networks (SANs)[G/OL] //The Internet Encyclopedia, Volume 3. Hoboken, NJ: John Wiley & Sons, 2004: 329-338 [2015-01-10]. http://onlinelibrary.wiley.com/doi/10.1002/047148296X.tie164/abstract

[2]T11 Technical Committee. Fibre channel[S/OL]. 2014 [2015-01-10]. http://www.t11.org/t11/als.nsf/v2guestho me766kx?OpenForm

[3]T11 Technical Committee. Fibre channel over Ethernet (FCoE)[S/OL]. 2012 [2015-01-10]. http://www.t11.org/fcoe

[4]Wu Longfei. The research of fibre channel over Ethernet storage technology[D]. Wuhan: Huazhong University of Science and Technology, 2013 (in Chinese)(吳龍飛. 以太網光纖通道存儲技術的研究[D]. 武漢: 華中科技大學, 2013)

[5]Open Networking Foundation. Software-defined networking: The new norm for networks[EB/OL]. (2012-04-13) [2015-01-10]. https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf

[6]Open Networking Foundation. OpenFlow switch specifica-tion: Version 1.0.0[EB/OL]. (2009-12-31) [2015-01-10]. https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.0.0.pdf

[7]Jeda Networks. Software defined storage networks: An introduction[EB/OL]. (2012-12-05) [2015-01-10]. http://www.jedanetworks.com/wp-content/uploads/2012/12/Jeda_Networks_SDSN.pdf

[8]SNIA: Storage networking industry association[EB/OL]. 1997 [2015-01-10]. http://snia.org

[9]T11 Technical Committee. Fibre channel framing and signaling (FC-FS-2)[S/OL]. 2007 [2015-01-10]. http://www.t11.org/ftp/t11/admin/project_proposals/03-092v0.pdf

[10]T11 Technical Committee. Fibre channel-switch fabric-5 (FC-SW-5)[S/OL]. 2009 [2015-01-10]. http://www.t11.org/ftp/t11/member/fc/sw-4/05-785v1.pdf

[11]Kamiya S, Ichino K, Yasuda M，et al. Advanced FCoE: Extension of fiber channel over Ethernet[C] //Proc of the 3rd Workshop on Data Center—Converged and Virtual Ethernet Switching in ITC’11. New York: ACM, 2011: 1-8

[12]Jeda Networks. Virtualizing the SAN with software defined storage networks[EB/OL]. (2014-03-14) [2015-01-10]. http://www.jedanetworks.com/wp-content/uploads/2014/03/140226-wp-Virtualizing-SDSN-FINAL.pdf

[13]Shiraki O, Nakagawa Y, Hyoudou K, et al. Managing storage flows with SDN approach in I/O converged networks[C] //Proc of the 5th IEEE MENS Workshops in 2013 GLOBECOM. New York: IEEE Communications Society, 2013: 890-895

[14]World wide name[EB/OL]. (2014-12-26) [2015-01-10]. http://en.wikipedia.org/wiki/World_Wide_Name

[15]Iometer[EB/OL]. 2003 [2015-01-10]. http://www.iometer.org

Lu Yifei, born in 1982. Received his PhD degree from the School of Computer Science and Engineering, Southeast University in 2010. Lecturer. His main research interests include data center network, cloud computing, big data and SAN.

Zhang Zhenwei, born in 1982. Received his master degree from Nanjing University of Posts and Telecommunications. Senior engineer in Huawei Nanjing R&D Center. His main research interests include SAN, big data and distributed computing (zhang zhenwei@huawei.com).

Tao Jun, born in 1975. PhD and associate professor, PhD supervisor. His main research interests include network architec-ture, wireless network technology(WSN, VANET, WMN, WMN), information economics, network resource allocation technology, network multimedia technology and trustworthy network (juntao@seu.edu.cn).

Tang Ling, born in 1986. Received her PhD degree in electronic science and engineering from Southeast University, Nanjing, China, in 2013. Member of IEEE. Her current research interests include cooperative communications, cloud computing and networking (ling.tang@njust.edu.cn).

Design and Implementation of New SAN Architecture Based on Controller

Lu Yifei1, Zhang Zhenwei2, Tao Jun3, and Tang Ling1

1(SchoolofComputerScienceandEngineering,NanjingUniversityofScienceandTechnology,Nanjing210094)2(HuaweiNanjingResearchInstitute,HuaweiTechnologiesCo.Ltd,Nanjing210012)3(SchoolofComputerScienceandEngineering,SoutheastUniversity,Nanjing210096)

AbstractWith the rapid development of Internet technology and the explosive growth of data, the storage system designed by tightly coupled hardware and software is limiting the development of storage technology severely, and unable to meet the fast changing needs in the mobile Internet and big data era increasingly. Software defined network (SDN) as new network architecture is more suitable for the development of the next-generation data centers. This paper proposes a new controller-based storage area network (SAN)—CSN architecture using the idea of SDN technology. CSN decoupling protocol control plane of FC switch from data plane deploys protocol control plane and distributed functions in the controller. At first, we introduce the architecture of CSN and discuss the specific design of controller for CSN in this paper. Then, the implement of communication and overall mechanism are described in detail. After that, CSN-based on-demand bandwidth-available first routing protocol is introduced and discussed. Finally, we verify the feasibility through the actual development environment. As a result of several experiments, server can establish a connection with the storage more quickly in CSN, and furthermore, CSN has better throughput and faster convergence, as well as more reliability and scalability. In addition, stress testing is conducted in the central controller for CPU, memory and bandwidth.

Key wordsFC protocol; storage area network (SAN); SAN architecture; software defined storage network (SDSN); controller

收稿日期：2015-01-12；修回日期：2015-06-23

基金項目：國家自然科學基金項目(61370209);江蘇省青年自然科學基金項目(BK20140797)

中圖法分類號TP393

This work was supported by the National Natural Science Foundation of China (61370209) and the Natural Science Foundation for Youth of Jiangsu Province of China (BK20140797).