网络转发设备用于传输流量，不同类型的流量对网络的需求是不同的。数据中心中有三大类资源，计算、存储和网络，之前讲过的数据网络都是用来传输用户到用户的应用流量的，这类流量对于网络的容忍度比较高，丢包多一点、时延高一点或者抖动大一点都没什么关系，以太网+TCP/IP的协议栈基本上统治了数通网络领域，而这套协议栈用于存储资源间或者是计算资源间的通信却很不合适。存储业务对于丢包几乎是零容忍的（想想你存了一大笔钱，然而在银行数据库写存储时，账户上的数字少了个0会是个多大的灾难），而以太网和IP都是尽力而为的，传输控制需要依靠高层的TCP去做，这种端到端的重传和流控显然不能满足存储对丢包率的要求。同样，一些高性能计算（HPC，High Performance Computing）的业务对于时延几乎零容忍（如高频交易，导弹轨迹拟合等等），要求底层网络能够达到总线级的传输性能，因此尽力而为的以太网和IP同样难以支撑HPC流量的传输。
因此，数据中心中往往需要为计算、存储的流量专门布网，跑着特定的独立于以太网+TCP/IP的协议栈。对于HPC流量，通常使用IB网络（Infinite Band，无限带宽网络）进行高带宽、低时延的传输，对于存储流量，则通常使用FC网络（Fibre Channel，光纤通道网络）进行高带宽、无丢包的传输。下图给出了数据中心中业务网络组网的简化模型。
三张独立的网络往往意味着远超3倍的CAPEX/OPEX，整合势在必行。而三种网络的协议栈不同，要实现整合必须使用一个通用的承载协议。由于部署的广泛性的和丰富的整合经验（PPPOE，FRoE，IPoE），以太网成为了承载协议的理想选择。随着DCB（Data Center Bridge，802.1）协议集的发展，以太网的特性得到了相当的扩充—PFC（Priority Flow Control，802.1Qbb）提供了基于通道的无丢包机制，ETS（Enhanced Transmission Selection，802.1Qaz）提供了灵活的带宽调度机制，CN（Congestion Notification，802.1Qau）提供了路径拥塞通知机制。具备这些优良的特性，通过以太网来整合数据、存储网络已经成为了业界的普遍共识。至于IBoE（貌似还有人提过EoIB），目前还很不成熟，虽然很早美国就有人提请过专利（US8165138），不过相关产品和宣传都很少，作者对IB不是很了解，有兴趣的读者可以找一找这篇专利看一下。
这个专题我们就来讲一讲FCoE（Fibre Channel over Ethernet，ANSI T11），其演化思路是先整合接入层，再改造汇聚/核心层，以做到端到端的数据、存储整合，如下图所示。
1) FCoE
要了解FCoE，得先来看看FC长什么样子。FC是一套完整的协议栈，有着自己的物理层规范FC-0和FC-1。向上的FC-2P负责帧封装，并通过Buffer-to-Buffer Credit这种可靠传输机制来实现链路层面上的无丢包，功能上类似于TCP滑动窗口。存储节点通过HBA网卡支持FC，其中的FC端口被称为VN_port，每个VN_port都有一个24位的FC-3层地址FCID。FC中不需要进行链路层寻址，通信节点将以FCID作为源/目的地址，FC Switch间交互FSPF（Fibre Channel Shortest Path First，光纤通道最短路径优先）形成转发表，根据目的FCID进行寻址，所以说FC Switch在本质上是一台路由设备。FC-2M夹在FC-2P和FC-3两层之间，负责多个FCID地址的复用。
每个FC结点都有64位的WWN（Wold Wide Name），结点上的每个端口都有64位的WWPN（World Wide Port Name），对FC网络中的元素进行全球唯一的标识，相当于以太网中的MAC地址，只不过FC Switch并不用它来进行寻址。FC结点使用周知的FCID地址FFFFFE向Login Sever发送 FLOGI（Fabric Login，交换网登录）消息以自动获取FCID，这一过程类似于IP中的DHCP。FC获得FCID后要向地址为FFFFFC的Name Server发送PLOGI（Port Login，端口登录）消息，Name Server记录下WWN/WWPN和FCID的映射关系后回复确认消息。此时通信还不能直接开始，类似于TCP握手，源FC还需要通过PLOGI消息与对端进行FC-4层的协商，协商过后应用层才能开始进行通信。FC中也有类似于IP中DNS的名字解析机制，结点/端口命名可以使用基于字符串的Symbolic Port Name，Name Server中会记录Symbolic Port Name与FCID的映射关系，其他端口可以向Name Server查询已登录的端口信息。上述交互过程如下图所示。
可见，FC的通信过程与IP还是有着很多类似的机制的，最主要的区别是FC只使用FCID进行寻址，结点/端口标识WWN/WWPN并不出现在通信的数据帧中，这里的原因也很简单——64位的WWN/WWPN太长了，会影响FC的转发效率。将FC整合到以太网中，做法是使用Ethernet的帧头去代替FC-2，保留上层的FC-3和FC-4，FCOE协议栈和数据封装如下所示。这里提一句，FCoE将服务器的FC结点称为ENode，FCoE交换机称为FCF。
FCoE网络中，服务器通过一块CNA网卡同时支撑IP和FC-3两套协议，相当于HBA和Ethernet NIC的合体。FCoE的以太网类型是0x8906，其外层MAC地址的写法比较讲究，后续通过具体的通信流程进行介绍。外层的VLAN对于FCoE来说同样非常关键，其原因主要有二：首先，FCoE流量必须在无损无丢包的以太网链路上进行传输，这完全依赖于PFC和ETS机制，而这两种机制都需要根据VLAN标签来对流量进行分类，因此FCoE流量必须承载在特定的VLAN中；其次，FCF要实现存储网络内部的虚拟化，需要使用不同的VLAN来承载不同VSAN（Virtual Storage Area Network）的流量。那么外层以太网封装时具体该使用哪个VLAN呢？这就要看FCoE的控制平面了。
FCoE使用FIP（FCoE Initialization Protocol）作为控制平面协议，其以太网类型为0x8914。FIP主要负责以下三个工作：
✔ VLAN发现。FIP在Native VLAN中通过VLAN发现报文与邻居协商后续FIP信令和FCoE流量所使用的VLAN，其缺省值为1002。
✔ FCF发现。FCF在所有FCoE VLAN内定期组播发现通告报文，使得当前VLAN内的所有的ENode发现自己。
✔ FLOGI/PLOGI。与FC中相应过程一样，FCF作为Login Server为ENode分配FCID，同时作为Name Server记录ENode的登录信息。
经过上述三个阶段后，FCoE网络的初始化工作就完成了，FCoE流量得以无损地在以太网中传输。下面来看一个多跳FCoE网络中典型的报文转发流程。
由于FCF本质上是一台路由设备，因此FCoE报文经过FCF转发时FCID不变，而外层的MAC地址会逐跳地改写。我们知道IP和MAC是通过ARP协议联系在一起的，那么FCID和MAC该如何映射呢？FCoE为ENode规定了如下的映射方法：使用FC-MAP填充MAC地址的高24位，低24位填充为FCID，得到FPMA作为自己的以太网地址，而弃用CAN网卡出厂时的MAC地址。其中FC-MAP为FIP的FCF发现阶段中，FCF告诉ENode的信息，每个VSAN内部的ENode都使用相同的FC-MAP，不同的VSAN使用不同的FC-MAP。而对于FCF来说，不进行这种转换，直接使用本机MAC地址FCF-MAC进行外层以太网封装。同一个VSAN内的报文都在同一个VLAN内传输，FCF进行per VLAN的MAC地址学习，保证了VSAN间的隔离，不同VLAN的优先级不同，通过PFC和ETS进行差异化的传输控制。
单跳FCoE的转发更为简单一点，负责接入的FCF收到FCoE流量后，根据FCID进行寻址，然后直接转换成FC-2的帧格式在FC网络中进行传输，这里就不再画图说明了。
有一个问题就是，当服务器中部署虚拟机的时候，FCF不再是FCoE接入网络的第一跳，很多FIP的交互过程就实现不了，而FC网络也面临着这个问题。FC网络给出的解决办法是NPIV/NPV，NPIV部署在服务器中作为ENode和FCF之间的代理，为下挂的多个虚拟机ENode完成FLOGI/PLOGI过程，而NPV则将NPIV的功能放到了以太网交换机上。NPIV/NPV的示意图如下所示。同样地，FCoE也可以配合NPIV工作实现虚拟机的FCoE接入。Cisco 5k已经对FCoE提供了支持，但作者不清楚VN-TAG网卡跟NPIV是否已经做了集成，如果答案是确定的，那么VN-TAG相比于VEPA的优势可就不是一点半点了。
相比于之前讲到的其他技术领域，FCoE在数据中心IO整合这块基本上是一枝独秀，没有看到其它类似的有竞争力的技术，包括Cisco、Juniper、Broadcom、Huawei和H3C等都已经支持了FCoE，厂家们罕见的站在了同一个队伍中。可以说，FCoE的生态布局已经完成，未来几年应该也不会有谁能够撼动它的位子，FCoE今后的步子会越迈越大，以太网将对FC网络实现全面的收编。
腾讯云开发者
