474
技術社區[雲棲]
《私有雲計算整合、虛擬化和麵向服務的基礎設施》一2.6統一數據中心光纖
2.6統一數據中心光纖
透徹了解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光纖的誕生。
2.6.110千兆以太網
目前，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的標準。
2.6.2以太網重裝上陣
僅憑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）。
2.6.3FCoE解決方案
有了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。
說明：讀者也可以采用軟件驅動器（更多細節，請參考https://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字段中。
2.6.5FCoE控製平麵
在本地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。
2.6.6FCoE與I/O整合
如果讀者認為前述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個。
最後更新：2017-08-17 11:32:21