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化那是迟早的事，希望以后能看到业界或者学术界更为成熟的数据平面和控制平面的解决思路。
本文转自d1net（转载）
