分享程序员开发的那些事...
更新时间：2022-09-13 15:23:57
透彻了解L2技术演化的实质后，我们该接着进入到下一课程—光纤模块。从私有云计算以及SOI角度出发，我们在该模块所获得的东西是DC光纤的统一。换句话说，也就是以太网和FC必须形成一个完整的光纤而非两个相互孤立的互联。为了实现该目标，必须对互联技术做一定优化或扩展。
自2008年10千兆以太网（10Gb Ethernet，10GE）问世以来，带宽的增加使得建设DC时，能够通过更少的链路传输更多的数据，提高了系统整体吞吐量。但是单凭高速10GE链路并不能超越FC，只有“无损”的以太网才能够与FC平分秋色。当前以太网对FC的某些特性进行了改造，包括基于优先级的流控制（Priority-based Flow Control，PFC）、增强传输选择（Enhanced Transmission Selection，ETS）带宽管理、数据中心桥接交换（Data Center Bridging Exchange，DCBX）的恢复协议以及量化拥塞通知（Quantized Congestion Notification）算法。而另一方面，FC借助FCoE技术已经扩展到新一代“无损”以太网领域，所有这些进化技术一起，促成了未来统一DC光纤的诞生。
目前，10GE（基于IEEE 802.3ae）技术日趋成熟，它对现代DC的重要性更是毫无疑问。10GE将是互联模块（参见图2-2）中DC光纤融合，或者诸如FC这样异构光纤融合，非常重要和基础的部分，任何希望创建一种无处不在的统一光纤应用都必须借助以太网，因此以太网是融合的方向且再没有其他方法。
10GE减少了服务器所需的千兆以太网适配器数量，改变了DC部署的规模。随着网络带宽的增加，现在已经能够实现对DC LAN存储网络的整合（更多详细内容请参考2.6.3节）。用户已经开始感受到从GE或GE端口通道迁移到10GE的优势，包括：
增加了诸如iSCSI（更多详细内容，请参考第7章有关“iSCSI”技术的内容）这类基于IP的存储访问的部署灵活性。
优化了NAS性能。
借助10GE接入层上行链路，可以预先得知GE端口通道的实现方案，因而降低了对GE端口部署时通常必需的负载平衡散列算法的要求。
改善了服务器备份以及恢复的效率。
多核处理器架构允许同一机器承受更大和多样的负载，而服务器虚拟化要求每个服务器能够得到更多的带宽，因此，多核CPU以及服务器虚拟化也受益于10GE所带来的额外带宽。例如，套接字的大小经常会对应用造成影响，通过虚拟化服务器，单个VM网络传输将被汇聚到同一NIC上，此时，就可以利用10GE。另外，VMotion迁移（动态VMotion迁移）可以利用带宽增加的优势同时完成多个VM之间的VMotion迁移。不管怎样10GE也最适合FCoE，因为它借助高带宽的优势弥补了以太网和FC之间的差距。
说明：以太网演化并未终止于10GE，IEEE 802.3ba已经批准了40GE及100GE的标准。
仅凭10GE是不足以抗衡FC的，因为长帧在FC的世界中不受欢迎。因此，除了有高速带宽的支持外，以太网还必须具备无损性。不过真的能实现以太网的无损吗？答案是“可以”，不过要借助下列内在机制：
基于优先级的流控制（Priority-based Flow Control，PFC）
延迟删除
增强传输选择（Enhanced Transmission Selection，ETS）
数据中心桥接交换（Data Center Bridging Exchange，DCBE）
拥塞通告
基于优先级的流控制
FC是不允许出现帧丢失现象的，它使用信用的概念来实现无损控制，在FC链路初始化时，会对每个链路的缓存数进行预定义，以便每个链路的终端能够跟踪可得或未被占用的缓存，这样的链路级流控制在FC中称为缓存到缓存（Buffer-to-Buffer，B2B）流控制。B2B流控制可以控制FC帧的传输速率，能够防止传输量超过接收者的缓存范围。B2B流控制使用缓存到缓存信用数（Buffer-to-Buffer Credit，BB_Credit）作为调整帧传输速率的单元，每发送一个帧，相应可用的BB_Credit都将减1。而另一方面，每收到一个接收者就绪（Receiver-Ready，R_RDY[27]）信号，相应的BB_Credit又将加1，使得可以继续发送其他帧。当BB_Credit的值变成0时，就意味着除非收到新的R_RDY信号，否则发送端将中断帧发送。以太网则借助PAUSE帧（基于IEEE 802.3x）来达到这一目标。当接收端口（接收者）的缓存将耗尽时，它将发出一个PAUSE帧来阻止远程peer（传输者）继续发送，图2-18上部对PAUSE帧进行了说明。但是PAUSE帧机制是对整个链路进行一个PAUSE操作，不能体现粒度差别，当发送者接收到一个PAUSE帧后，它将停止该端口所有的传输行为，这样也并不符合统一DC光纤的目标。
基于IEEE 802.1Qbb标准的PFC是对PAUSE机制的增强，它在PAUSE帧中增加了一个域来标识将对哪一个优先级别（IEEE 802.1p可以设置8个级别）进行PAUSE操作。换句话说，PFC在物理以太网链路上创建了8个单独的“虚拟链路”，任意一条虚拟链路都可以自主地被停止和重启。新增的优先级粒度允许我们为链路上不同的协议传输设置不同的服务等级（Classes of Service，CoS）。例如，像FCoE（更多有关FCoE的详细内容，请参考2.6.3节的相关内容）这样的协议，要求介质级别的可靠性，不能容忍帧丢失，因此可以被映射到无丢失（有PAUSE）等级，而诸如IP这样的协议能够接受尽力而为型的帧传送效率，就可以被映射到可丢失（无PAUSE）等级。
图2-18底部展示了一个简化的PFC样例，该样例中只设置了两个等级：IP传输为CoS 0等级，FCoE传输为CoS 3等级，只有FCoE对应的CoS（优先级为3）才启动了PAUSE帧，IP传输属于另外一个CoS等级，不会受到PAUSE的影响。如果出现拥塞，不会对属于CoS 0级别的溢出帧进行PAUSE控制，这些帧会被简单丢弃，IP传输不要求无损以太网因为TCP或更高级别协议（如果使用了UDP）将会处理IP包丢失问题。
说明：PFC帧的以太域类型值为0x8808（与PAUSE帧的以太域类型值相同），Opcode的值为0x0101（PAUSE帧的Opcode值为0x0001）。
延迟删除
由于PFC将缓存需求返回给数据源，因此它不会区分网络流量的暂时性突发与长期拥塞。延迟删除位于传统以太网与PFC控制中间，它是另外一种以太网强化机制，差别在于：对于暂时性网络流量突发，延迟删除将采取PAUSE或PFC机制来减小帧丢失；而在处理长期拥塞时，则会通过帧丢弃触发更上一层拥塞控制，使得系统中只会存在短期流量突发，而不再有长期拥塞。
延迟删除可以采用每用户优先级激活，它使用代理队列来衡量网络流量突发的时间，在常规操作中，代理队列将效仿实际队列进行帧的增加或删除，当出现网络流量突发并导致实际队列达到特定阈值时，系统将向数据源发送一个PAUSE或PFC帧，此时，容量远超过实际队列的代理队列将继续接收帧，当代理队列也被填满后，系统将告知发送者释放PAUSE或PFC帧，此时，如果拥塞仍在持续，就会造成帧丢失，发生这一现象时，系统将触发TCP流量控制以保护长久流。
在出现暂时性网络流量突发状况时，实际及代理两条队列都应该快速消耗掉缓存空间以便实际队列自己能够释放PAUSE帧；如果出现持续拥塞，代理队列将贡献出所有缓存空间，并释放PAUSE帧。此时，实际队列将开始丢弃帧，并通过上层协议解决拥塞。借助延迟删除，在特定一段时间内可以使用指定的CoS流控制机制，如果超过该时间段，拥塞还依然持续，就可以采用传统的抛弃处理方法。延迟删除能够配合PFC一起对“短期拥塞”进行调节，而不必因此增加接口的物理缓存。
增强传输选择
PFC可以在一条物理链路上创建8个不同的虚拟链路类型，基于IEEE 802.Qaz的ETS能够启动对这些虚拟链路的带宽管理，它是对PFC的一个补充。ETS提供了基于带宽分配及延时的优先级处理，即根据帧的优先级将它们分配到不同的组中，然后按照一定比例将物理链路的最大可得带宽分配给这些组，ETS的目的是实现一个带严格优先级高效的两级硬件亏损加权轮循（Deficit Weighted Round Robin，DWRR）[28]调度算法。
图2-19展示了三类不同的应用传输：进程间通信（Inter-Processor Communication，IPC）、LAN及SAN（例如FCoE），这些应用传输类型拥有不同的优先级变量或CoS，比如，IPC的CoS为7，LAN传输包括了CoS 0、1、4~6，而SAN传输包括CoS2和CoS3。ETS不会关注有多少可得的传输等级，而是会将这些传输分成不同的优先级别组（Priority Group，PG），并为每个小组分配一个优先级组ID（Priority Group ID，PGID）。在我们给出的样例中，SAN传输等级（CoS 2和3）被映射到PGID 0，LAN传输等级（Cos 0、1、4~6）被映射到PGID 1，而IPC（CoS 7）的PGID则为15。
第一级调度在每个PG内部完成，第二级调度则基于分配给每个PG的带宽（BandWidth，BW）进行。本例中，50%的物理链路可得带宽被分配给了PGID 0，剩下的50%分配给了PGID 1，PGID 15是一个具有特殊意义的优先级组标号，它意味着该优先级组不受带宽限制，任何被映射到PGID 15的优先级都会使用严格的优先级调度（不由ETS负责），本例中IPC（CoS 7）就属于这一类。
说明：PGID的范围为0~15，PGID为15的优先级组不能够分配任何PG%，属于这一组的优先级不受带宽限制，PGID 8～14的值属于保留值，0到7之间（包括7）的PGID必须用作带宽分配（或限制）配置。
数据中心桥接交换
基于IEEE 802.1Qaz的DCBX是IEEE 802.1数据中心桥接（Data Center Bridging，DCB）的管理协议，属于链路层发现协议（IEEE 802.1AB），支持以太网参数的自动交换以及交换机与终端之间的发现功能。可以被交换的以太网扩展和特性参数包括：
PFC
ETS中的优先级组
拥塞通告
应用（例如FCoE）
逻辑下行链路
网络接口虚拟化
DCBX能够发现链路两端设备的能力，并检测设备配置是否匹配，如果两端设备中有一个设备未配置同时也支持端到端的配置，DCBX可以对该设备进行基本配置。两端设备可以选择希望支持的特性，以及是否接受另一端设备的配置参数。简而言之，DCBX协议有助于保持链路配置的一致性，并降低了新以太网扩展功能配置开销，DBCX可以提供以太网功能强化，但同时配置开销更低，错误也更少。
拥塞通告
无损以太网有可能产生“传染性”拥塞，蔓延到整个网络，并导致有害的线头（head-of-line，HOL）[29]阻塞，某些形式的L2端到端拥塞通告协议能够缓和这一问题。
IEEE 802.1Qau体系使用量化的拥塞通告（Quantized Congestion Notification，QCN）来定义拥塞点（Congestion Point，CP）以及重启点（Reaction Point，CP）。在模型中，在拥塞点测量拥塞规模，在重启点进行限速或背压，以控制传输规模，降低拥塞的影响。RP应该尽可能地接近拥塞源头，当产生拥塞时，CP（发生拥塞的汇聚层交换机）将向拥塞源以及RP发出通告消息，告知其当前的拥塞状态，当接收到拥塞通告消息后，位于RP的限速器或流量控制器将开始工作，减缓网络的传输速率。拥塞通告的目的是将发生在网络核心区的拥塞转移到网络边缘，以避免拥塞蔓延到网络其他部分。在网络边缘进行拥塞控制相对容易些，因为网络边缘的流量远低于网络核心区，这意味着在网络边缘更容易确定并限制那些引起上行通道拥塞的网络流。
说明：拥塞通告消息包含了一个反馈质量，采用一个6位数对其“量化”，“量化”拥塞通告也是源自于此。
如图2-20所示的一台汇聚层交换机，类似CP的功能，向两台接入层交换机，此处为RP，发送拥塞通告消息，要求它们降低网络传输的速率，以缓和网络核心区域的拥塞，防止它蔓延到全网范围，而只会对接近拥塞源附近的区域造成影响。
说明：QCN信号与PAUSE之间的差别在于PAUSE是从一跳到下一跳，而QCN拥塞通告消息是端到端的，这些拥塞通告消息被传播到拥塞源头，MDS交换机在FC上实现了一个类似机制，称为光纤通道拥塞控制（Fibre Channel Congestion Control，FCC）。
有了10GE，再加上无损以太网的扩展功能，现在以太网已经有可能与FC分庭抗礼了，但是还存在一个问题：如何整合FC及新型无损以太网来创建一个统一DC光纤呢？答案就是FCoE。
FCoE以INCITS T11光纤通道骨干（Fibre Channel Backbone，FC-BB-5）标准为基础，它能够独立本地以太网转发机制，将本地光纤通道映射到以太网上。FCoE本质上是通过以太网发送本地FC帧，同时保留了所有FC的结构，确保现有FC管理方式保持不变，对操作的影响也降至最低。换句话说，FCoE能够对任何现有本地FC SAN环境进行互换操作，避免了完全翻新式升级。FCoE依靠由无损以太网支撑的可靠的底层网络互连，借助在同一物理线缆上传输不同类型的应用数据（例如，FC和以太网），FC实现了渐进式的I/O整合及I/O统一方法。从长远看，存储模块中的服务器模块（参见图2-2）除了借助直接本地FC接入通过互连点B访问FC SAN，也应该能够通过互连点A利用FCoE直接访问FC SAN。
为什么不使用iSCSI呢？更推荐使用FCoE的主要原因是受DC整合的影响。如果是从零开始建设DC，无疑iSCSI是最理想的选择，但大多数公司已经投资并建设好了本地DC接口，因此他们对渐进式方法更感兴趣。iSCSI使用了与现有FC不同的SCSI命令映射，将本地FC与iSCSI进行整合时要求采用状态网关功能，会带来单点故障、有限可扩展等问题。此外，现有FC管理模式也必须更改成其他不同模式。为了实现整合，将现有DC完全改造成全iSCSI是不太可能的，从这点看，渐进式方法更为通用，因此FCoE更有希望。而对于中小型商务市场（Small to Medium Business，SMB）领域，在建设新的DC时，iSCSI仍然是无可替代的选择，同时对纯IP SAN而言，iSCSI也是一个不错的候选方案（更多有关iSCSI的详细内容，请参考本书第7章）。
2.6.4FCoE数据平面
FCoE实际包含两个不同的协议：FCoE协议及FCoE初始化协议（FCoE Initialization Protocol，FIP）。FCoE协议负责管理数据平面，FIP则属于控制平面协议。本节将探讨FCoE数据平面，更多FIP的内容请参考2.6.5节。
图2-21展示了一个简化的FCoE组件及架构：
FC实体（FC entity）：FC交换机元素（属于FCF）或FC栈（属于ENode）与FCoE实体之间的接口，每个FC实体包括一个单一实例，可以是VE_Port、VF_Port或VN_Port。
FCoE实体（FC entity）： FC实体与无损以太网MAC之间的接口，每一个FCoE实体包括一个或多个FCoE_LEPs。
FC交换机元素（未在图中显示）：属于体系结构实体，负责转发VF_Ports与VE_Ports之间的FC帧。
无损以太网桥接元素（未在图中显示）：以太网桥接模块，支持无损以太网MAC的基本功能。
无损以太网MAC：全双工以太网MAC，支持至少2.5KB的巨帧，并且具备拥塞扩展功能，能够避免丢失以太网帧（更多细节，请参考2.6.2节的相关内容）。
无损以太网网络：由全双工链路、以太网MAC以及无损以太网桥接组件组成的以太网网络。
虚拟F_Port（VF_Port）：FC实体中模仿F_Port的数据转发组件，在FLOGI交换成功完成后动态初始化，每一个VF_Port都与一个或多个FCoE_LEP配对。
说明：F_Port（光纤端口）是FC互连内对N_Port（节点端口）的附加端口。N_Port通过光纤登录（Fabric Login，FLOGI）建立到光纤的会话，光纤只接收那些完成登录的N_Port帧。
虚拟N_Port（VN_Port）：FC实体中模仿N_Port的数据转发组件，当FLOGI或FDISC交换成功完成后被动态初始化，每一个VN_Port都与1个FCoE_LEP配对。
说明：N_Port是FC节点端口，是FC的连接点。N_Port ID虚拟化（N_Port ID Virtualization，NPIV）使用了发现光纤服务参数（Discover Fabric Service Parameter，FDISC），向光纤登录地址0xFFFFFE发送一个请求以获得一个新的N_Port ID。
虚拟E_Port（VE_Port）：FC实体中模仿E_Port进行数据转发的组件，当ELP交换完成后被动态初始化，每一个VE_Port都与一个FCoE_LEP配对。
说明：E_Port（扩展端口）是FC交换机中通过内部交换机链路（Inter-switch Link，ISL）连接另一个FC交换机的端口。交换链路参数（Exchange Link Parameter，ELP）是FC交换机内部链路服务参数，用于交换机端口之间服务参数交换。
FCoE链路端点（FCoE_LEP）：FCoE实体的数据转发组件，负责FC帧封装/解封以及通过单个虚拟链路发送/接收封装后的帧。EN_Node的FCoE_LEP仅支持VN_Port，而位于FCF的FCoE_LEP既支持VF_Port，也支持VE_Port。
FCoE控制器：功能实体，与无损以太网MAC一起工作。与ENode相关的FCoE控制器其主要功能为实例化新的VN_Port并/或生成新FCoE_LEP；而与FCF-MAC相关的FCoE控制器其主要功能为实例化新的VE_Port并/或生成新FCoE_LEP。
FCoE终端节点（ENode）：FCoE终端节点是一个带有一个或多个无损以太网MAC的FC节点，每一个节点都配备了一个FCoE控制器，它实际上是以太网NIC内的FC HBA，通常被称为CNA（聚合网络适配器），有两种“版本”的CNA：
第一代（Gen-1）CNA：标准FC HBA与10GE NIC通过一种中间“胶合”ASIC连接在一起，在OS看来，CNA由两块独立的适配器，FC HBA以及以太网NIC组成，CNA无需改造就可以继续使用现有FC及以太网驱动器，Gen-1类型的CNA通常不具备FIP功能，因此被称为pre-FIP。
第二代（Gen-2）CNA：Gen-2型CNA是首先方案，它由单块芯片构成，能够兼容FIP。
说明：读者也可以采用软件驱动器（更多细节，请参考http://www.open-fcoe.org/）来实现FCoE，这对那些没有配备密集I/O负载但又需要经常访问FC存储阵列的服务器特别合适。
FCoE转发器（FCoE forwarder，FCF）：FCF为FC交换组件，带有一个或多个无损以太网MAC，每一个都配备了相应的FCoE控制器。每个以太网MAC拥有一个MAC地址，称为FCF-MAC地址，可以为每个FCF-MAC配置一无损以太网桥接组件。也可以为FC交换机组件配置FC光纤接口，实现本地E_Port以及F_Port的连通。如果以太网目的地址是一个FCF，该FCoE帧将被转发至相应的FCF-MAC地址，然后由FCoE_LEP对封装了的FC帧解封，FC交换机组件将基于其相应的FC目的地址或FC目标ID（Destination ID，DID）转发解封后的FC帧。如果该FC帧需要经过一个以太网端口被转发出去，系统会将该FC帧封装在一个以太网帧中，附带以太网源地址与FCF-MAC的关联，以及以太网目标地址集与到正确目标MAC的映射等信息。FCF的功能本质上与带有一个或多个以太网端口的FC交换机类似，FCF也可以选择本地FC端口。
说明：如果FCF配备的是本地FC光纤接口，那些目标地址为本地FC的帧将被当做本地FC帧通过本地FC端口经由相关FC链路转发。如果FCF-MAC配备了以太网桥（或以太网交换机），目标地址非FCF-MAC的以太网帧被接受后，将通过以太网桥按常规方式转发到相应的目标地址。
虚拟链路（Virtual Link）：虚拟链路是在无损以太网上连接到两个FCoE_LEP的逻辑链路，如图2-21所示，虚拟链路由两个终端的MAC地址对确定。也可以将虚拟链路看成无损以太网上的一条隧道，将封装好的FC帧从源MAC地址转发至目标MAC地址。
FC包含由FC-0~FC-4，5个不同功能级别的层次，FCoE中将FC-2级进一步细化成3个子级，如图2-22左边上部所示，以便能够实现更灵活地虚拟化处理。
FC-4定义了包括SCSI、IPV4及IPV6等不同上层协议（ULP）与FC的映射方式。
FC-3定义了跨越多个节点间可选的常用服务或功能。
FC-2V（FC-2—虚拟）定义了对FC帧处理，以支持上层应用。
FC-M（FC-2—多路复用器）定义了如何将FC-2P子级实例的FC帧切分成FC-2V子级实例。
FC-2P（FC-2—物理）定义了底层物理介质实际发送及接收帧的相关功能，包括帧发送及接收、CRC[30]生成及校验以及链路级别（缓存到缓存）流量控制。
FC-1定义了传输协议，包括连续编码、解码及错误控制。
FC-0定义了系统的承载介质类型。
FC-2P、FC-1以及FC-0级别定义FC物理端口功能和行为说明，这些端口包括物理N_Port（Physical N_Port，PN_Port）、物理F_Port（Physical F_Port，PF_Port）以及物理E_Port（Physical E_Port，PE_Port）等。在FCoE环境中，如图2-22右边所示，这些功能则被FCoE_LEP以及无损以太网代替了。FCoE能够保证FC_2V以及其上更高层不受影响，也说明了对于OS而言FCoE是透明度，系统可以延续一样的FC操作及管理模型。
FCoE封装如图2-22底部所示，其中FCoE的以太类型为8906h。FCoE为无状态封装及接封装备，不会影响实际FC帧，这也使得FCoE不需要网关就能与现有FC SAN集成。如果包括FCoE的帧检验序列（Frame Check Sequence，FCS）一起，则FCoE帧最大不超过2180个字节，如果不包括FCS，则最大不超过2176字节，而为了能够容纳下最大尺寸的FC帧，FCoE要求采用至少2.5KB的小巨帧。FCoE同时也能够满足以太网规定最小有效载荷不超过46KB的限制：14字节（FCoE头）+24字节（FC头）+0字节（FC有效负载）+4字节（CRC）+4字节（FCoE trailer）。固定的FCoE头及trailer字段保证了最小尺寸的FC帧总是能够产生合法的最小尺寸以太网帧。
说明：FC帧首（Start-of-Frame，SOF）定界符包含在FCoE头中，帧尾（End-of-Frame，EOF）定界符包含在FCoE trailer字段中。
在本地FC环境中，N_Port仅在连接到FC光纤的点到点链路上发送FLOGI消息。在FCoE中，ENode需要知道FCF的MAC地址才能执行FLOGI，以太网采用多路访问介质，因此FCoE使用VN_Port与VF_Port之间的点到点虚拟链路来模仿本地FC环境。不过，通过手工配置来完成VN_Port与VF_Port之间的FCoE虚拟链路建设非常麻烦，如果能交给协议来完成就太好了。这也是FIP大显身手之处。FIP帧的概念与FCoE帧不同，它采用8914h以太类型封装在以太网帧中。FIP属于FCoE控制平面，因此FIP以太类型的帧将直接发送至以太网交换机（支持FCoE）以进行处理或拦截，而FCoE以太类型的帧将立即转发到数据平面。FIP能够在数据平面FCoE数据转发开始之前，完成以下属于控制阶段的任务：
发现FCoE VLAN；
发现FCoE实体；
初始化虚拟链路；
维护虚拟链路。
发现FCoE VLAN
FCoE VLAN发现协议使用了FIP VLAN请求以及FIP VLAN通告操作，协议由ENode MAC或FCF-MAC发起，FIP VLAN请求则借助任一可得（或默认）的VLAN传送。目标MAC地址为“ALL-FCF-MAC”多路访问地址，源MAC地址为发送者的ENode MAC或FCF-MAC地址。支持FIP VLAN发现协议的FCF会监听所有VLAN上的FIP VLAN请求，FIP VLAN通告消息将会向请求FCoE操作的发起者返回所有可得VLAN的列表。
说明：每个虚拟SAN（VSAN）的FCoE传输应使用不同的VLAN，这样管理员就能确定该VSAN上的FCoE传输，并且在以太网上对其进行管理。FCoE VLAN也应该仅为特定FCoE传输服务，即不应该再负责诸如IP等其他传输。
发现FCoE实体
当FIP发现FCoE VLAN后，就该ENode以及FCF借助FIP发现协议，通过FCoE VLAN来发现彼此了。FIP发现协议支持ENode发现FCF，以便建立VN_Port到VF_Port之间的虚拟链路，也支持FCF发现ENode，以建立VF_Port到VN_Port之间的虚拟链路。在链路建立过程中，ENode和FCF都会使用发现邀请消息，FCF还会使用发现广播消息。
说明：FCF能够发送和接收发现邀请消息以及发现广播消息，ENode只能发送发现邀请消息，并接收发现广播消息。
虚拟链路初始化
一旦ENode发现了可得的FCF-MAC，就会执行FIP FLOGI以建立与FCF-MAC之间的虚拟链路，并要求获得一个FC地址（类似N_Port_ID或FC_ID）。当顺利完成FLOGI后，与FCF-MAC相关的FCoE控制器将会为该链路初始化一个VF_Port以及一个FCoE_LEP，而ENode上的FCoE控制器将会为链路初始化一个VE_Port以及一个FCoE_LEP。接下来的数据操作将使用FCoE协议以及普通的封装FC帧。
说明：在NPIV应用中，ENode能够发起一个FIP NPIV FDISC（类似FIP FLOGI）以获得额外的N_Port_ID，当某个已登录的ENode发起并与FCF-MAC相关的FCoE控制器成功完成FIP NPIV FDISC交换后，FCoE控制器将会初始化一个额外的FCoE_LEP。
另一方面，在FCF到FCD发现中，FCF-MAC将会发送一个FIP ELP给其他FCF-MAC，当成功完成ELP交换后，每个FCF-MAC的FCoE控制器也会未虚拟链路初始化一个VE_Port以及一个FCoE_LEP。
与VE_Port以及VF_Port相关的MAC地址，源自FCF协议，是由IEEE分配的全球唯一MAC地址。VN_Port能够选择两类MAC地址中的一种：服务器提供的MAC地址（Server-Provided MAC address，SPMA）或光纤提供的MAC地址（Fabric-Provided MAC address，FPMA）。如果使用SPMA，终端设备（服务器或存储）将会为每个VN_Port提供一个MAC地址；如果使用FPMA，FCF将会在FIP登录过程中（FIP FLOGI或FIP NPIV FDISC）为VN_Port分配MAC地址。推荐使用FPMA方式，该地址包括24位FCoE MAC地址前缀（MAC Address Prefix，FC-MAP）以及VN_Port的24位FC_ID的组合。例如，一个FC-MAP为0EFC00h以及FI_ID为040506h的地址组合在一起将产生一个值为0EFC00040506h的FPMA地址。
FC-MAP属于组织唯一标识符（Organization Unique Identifier，OUI），U/L位为1时表示其为本地地址，不具备全球唯一性，FC-MAP的推荐范围为0EFC00h~0EFCFFh（默认为0EFC00h）。之所以要如此确定FC-MAP的范围，是为了便于每个SAN可以分配不同的FC-MAP值，以确保能建立唯一的FPMA，从而防止了两个独立的SAN光纤在整合时会发生地址冲突。由于FC_ID是由SAN唯一确定的，因此所生成的新的FPMA在SAN也是唯一的。
维护虚拟链路
在FCoE中，VF_Port以及VN_Port或者两个VE_Port之间的虚拟链路有可能跨越了多个以太网链路以及交换机，当某个中间的以太网链路或交换机发生故障时，FCoE端口有可能并不能直接发现出现故障的链路或交换机。因为在虚拟链路中，某段物理链路的故障状态信息并不足以指明当前是否已经无法访问远程实体，因此需要启动某些增强的故障检测机制。FCoE控制器可以借助定时消息来完成虚拟链路的状态监测任务。
说明：FCoE控制器通过接收到的FIP发现消息并发送正确的FIP心跳消息来监测相关ENode中VN_Port到VF_Port间虚拟链路的状态，而对于具备VF_Port能力的FCF-MAC，FCoE控制则是通过接收到的FIP心跳消息并发送正确的FIP发现广播消息监测VN_Port到VF_Port间虚拟链路的状态。如果是具备VE_Port能力的FCF-MAC，FCoE控制则是通过接收及发送FIP发现消息监测VE_Port到VE_Port间虚拟链路的状态。
对于ENode，如果FCoE控制器能够持续接收到来自FCF的周期性组播发现公告，则认为该VF_Port正常。如果连续错过两次组播发现公告，则FCoE将认为该VF_Port已经发生故障，并反实例化相关的VF_Port/FCoE_LEP对。在FCF设备中，如果FCoE能够持续接收到来自VN_Port或ENode的周期性单播FIP心跳消息，将认为该VN_Port或ENode工作正常。如果连续错过两次FIP心跳消息，则FCoE将认为该VN_Port或ENode发生了故障，相关的FCoE_LEP也将被反实例化处理。
说明：对于ENode，当VN_Port注销后，相关的VF_Port/FCoE_LEP对也将被反实例化。如果是具备VF_Port能力的FCF-MAC，当VN_Port注销后，除非该FCoE_LEP是唯一与VF_Port相连的FCoE_LEP，否则该VF_Port/FCoE_LEP也将被反实例化处理。
如果是VE_Port与VE_Port之间的虚拟链路，将使用主动组播公告，此外，FCF会使用FIP清理虚拟链路消息来显示反实例化远程VN_Port或VE_Port。
如果读者认为前述FCoE内部工作机制过于复杂，希望本小节对你来说更容易理解一些，我们将在本小节讨论各类FCoE支持的I/O整合的过程和方案。当下的DC看起来与图2-23左边部分类似，存在以下局限：
并行以太网LAN以及FC SAN基础设施均基于各种互连媒介和协议。以太网比FC更具“全球化”，而FC更具战略意义，因为它涉及了服务器I/O以及存储访问问题。
服务器多重连接存在很多问题，包括：
增加了适配器及线缆开销。
每个连接都会增加光纤的故障点。
增加了电力及冷却成本。
增加了服务器开通的引导时间。管理复杂度，包括：
需要不同的以太网以及FC接入层或架顶式（Top-of-Rack，ToR）交换机。
以太网及FC的组合带来了多个容错管理域，增加了故障处理及诊断的复杂性。
使用完全不同的以太网与FC设备，增加了固件升级、驱动补丁及版本配置的复杂性。统一DC光纤实施的第1阶段（也是最实用的阶段）为服务器集群与接入层整合，如图2-23右边所示。我们已经了解了大部分利用服务器虚拟化技术（更多细节请参考2.3节）进行服务器整合的方法，接下来的本小节将对多适配器整合进行探讨。读者可以参照图2-23两部分进行“整合前后效果”比较。在阶段1未实施之前，每个服务器都配备了两块以太网NIC以及两块FC HBA。进行阶段1整合后，将4块服务器适配器缩减到2块CNA。而DC LAN以及SAN网络流传输也可以在同一10GE线缆上完成，不再需要使用不同线缆（1根用于以太网，1根用于本地FC）。因此原来需要8根线缆，经过整合缩减成4根，提高了高速带宽（10GE）链路的有效共享效率。
在接入层交换机这端，原来需要两个ToR以太网交换机以及两个ToR FC交换机，整合后被缩减到一对ToR交换机—一对FCF（FCoE交换机），由此简化了接入层及线缆，降低了系统总体拥有成本（Total Cost of Ownership，TCO）。同样因为从汇聚层角度（或上层）看，现有已安装好的LAN及SAN基础设施并未受到影响，保护了投资。现在由于所有服务器I/O已经整合至FCoE，并直接连接到FCoE接入层的交换机，使得接入层获得了操作一致性。来自接入层FCF到汇聚层以太网交换机的上行链路也已经升级成10GE链路。尽管阶段1仍然缺乏云IaaS所需的快速部署基础设施（统一DC光纤），但人们依然期望它成为最常见的FCoE部署起步。
图2-24展示了阶段2部署。此时，焦点已经转移到DC LAN的分布或汇聚层。原来的汇聚层交换机被迁移到服务汇聚层，被当做外部服务机箱，提供DC服务（例如，防火墙以及服务器负载平衡）。两个汇聚层FCF被安排在原来汇聚层交换机的位置，负责将遗留的DC以太网LAN改造成具备FCoE能力的无损以太网。阶段2实施为访问存储阵列提供了一定的***及冗余，既可以通过本地FC也可以借助无损以太网，使得我们离阶段3废除并行网络基础设施又近了一步。鉴于在阶段2DC光纤已经实现了某种程度的统一，因此基础设施部署会变得更加敏捷，其TCO成本也更低廉，而这也恰好是建立一个成功云计算所需要的。按需求基本快速部署非常接近自适应SOI，能够响应渐变商务需求，因而推荐在云IaaS的光纤模块（参见图2-2）完成阶段2。为了完成整个布局，服务机箱以及WAN汇聚路由都通过10GE链路连接到这个“半统一”DC光纤上，更多有关DC服务汇聚以及未来WAN的内容，请参考本书第3章。
图2-25展示了FCoE部署的第3个阶段，此时DC LAN以及SAN已经实现了网络范围统一光纤，本地FC交换机与FC存储阵列都被转换成了FCoE I/O接入。完全的统一光纤实现了一致的DC网络协议，又进一步降低了TCO。
尽管阶段3是云计算的理想场景，但某些技术仍然停留在测试阶段，在短期和中期内无论是基于感情因素还是节约投资的原因，都不可能完全废除现有的本地FC基础设施，因此阶段3也缺乏实际意义，但阶段3依然是云的理想目标，因为它代表了某些未来的目标。我们采取递增式方法，首先完成第1阶段的部署，紧接着完成第2阶段部署，最后是阶段3部署，实现最终目标。
从长远发展看，人们期望云IaaS供应商能够以他们自己的节奏从阶段2发展进入到阶段3，统一DC光纤最终有可能是阶段1及阶段2的混合，这将依赖于云IaaS服务对SOI的迫切需求究竟有几分。另一方面，新的企业DC建设可以直接进入第3阶段，实现统一的光纤网络基础以便迅速推动私有云计算服务发挥效用。更多有关FCoE的设计方案探讨请参考9.4节。
关于线缆的探讨
I/O整合对DC机架这一级带来了怎样的影响呢？适配器、交换机端口以及线缆需求的显著缩减，大大降低了电力消耗、冷却成本甚至设备占用空间，契合了绿色IT的初衷。在线缆接口这方面，已经从原来的小封装可插拔（Small Form-Factor Pluggable，SFP）技术升级到能够支持10Gbps数据速率的SFP+收发器。SFP+面板密度与SFP面板密度兼容，但能耗更低，更重要的是SFP+能够向下兼容SFP的光模块。
为了使DC机架能够适用于FCoE方案，推荐采用SFP+以及copper（CX-1）Twinax型线缆，该类线缆体积小（直径大约为6mm），能够灵活地放置在机架内，从而简化了线缆部署工作，缩短了部署时间。此外，线缆能耗更低，错误率基本可以忽略不计（10–15），更重要的是线缆成本较低。尽管线缆的距离限制为10米（33英尺），但已经足够将服务器的几个机架（大约1~5个）连接到通用ToR交换机上。
说明：尽管SFP+ CU Twinax线缆规范允许的连接距离为10米，但线缆连接距离的可选范围通常为1米、3米或5米。
机架技术
一个接入层构件被称为一个pod（机柜组），每个pod规定了连接到该网络汇聚模块的服务器数量，为了便于模块式组建，DC接入层被划分成多个pod。pod内部服务器连接由ToR接入层交换机在机架层完成，交换机再连接到网络汇聚层，这种方式有利于机架滚动式（rack-and-roll）部署，实现DC内快速服务器服务。Pod由服务器机架构成，与下述具体机架技术无关：
列末（End-of-the-row）拓扑：列末拓扑将大型直接交换机设备放置在每列服务器机柜的末端，因而需要大量线缆绑定在一起将服务器机架连接到网络机架。列末拓扑的主要优势在于只要配置少数连接点（交换机）就能控制很多服务器端口。
架顶（Top-of-the-rack）拓扑：架顶拓扑在每个服务器机架顶部放置1个或2个机架单元（Rack-Unit，RU）接入层交换机设备，实现每个机架之间服务器的连通。因为减少了机架到末端交换机之间的线缆，所以架顶拓扑的线缆利用率要优于列末拓扑，但由于架顶拓扑需要占用更多的ToR交换机，因此其管理负载要大于列末拓扑。
使用FCoE进行I/O整合缩减了服务器所需的适配器数量，也减少了服务器所需线缆数目，从而简化了列末拓扑中对线缆的管理。由于FCoE已经将本地FC扩展到了以太网，不再需要单独的ToR FC交换机，换句话说，也就是只采用一组同构的ToR FCoE交换机即可，因此这也减少了架顶拓扑中对ToR交换机的需求量。
图2-26展示了一个经过简化了的FCoE1阶段（参见图2-23）部署中采用的架顶拓扑，样例中使用了12个服务器，通过FCoE对I/O的整合，将总体线缆数从原来的56根缩减到现在的32根（缩减率大约为43%），单口适配器也从原来的48块缩减到现在的24块（50%的精简），ToR交换机从原来的4个减少到2个（50%的精简）—从DC整合观点来看不算坏，但如果放在私有云计算环境下显然很有优势。
滚动式部署。更多有关ToR架构及设计的内容，请参考9.5节的内容。
说明：如果使用双口适配器，在进行FCoE阶段1改造前，总共需要24个单元，而经过整合，所需单元数减少到12个。