Blade Network Technologies, which claims 48% of the world blade chassis Ethernet switch market -- Dell, Hewlett-Packard, IBM and NEC all take its products -- will provide network plumbing and equip its switches to carry whatever Ethernet-based traffic the servers it connects to networks want to send and receive.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
FCoE depends upon a lossless and low-latency Ethernet because Fibre Channel endpoints rely on a fast and sure network. Blade Network Technologies' top-of-rack switches support the draft CEE standard and will support the full CEE standard via a software update. But they won't include a Fibre Channel over Ethernet stack because they don't need it. The only thing the switches do with FCoE frames is detect them and route them.
We could envisage a data centre backbone Ethernet switch that needed an FCoE stack if it provided storage-area network (SAN) management functions, such as virtualising the SAN storage pool or providing some kind of virtual FCoE SAN infrastructure. However, if Ethernet switches merely pass on FCoE frames to storage arrays with native Fibre Channel over Ethernet interfaces, they won't need their own FCoE stack.
Charles Ferland, vice president, EMEA at Blade Network Technologies, said the same is true for IP SANs (iSCSI). All the switch has to do within an IP SAN is to route iSCSI frames to the right destination. It doesn't get involved in the nuts and bolts of IP SAN storage. Ditto with Remote Direct Memory Access (RDMA) iWRAP frames for server clustering. In all three cases, it's the responsibility of the Ethernet endpoints to create outgoing frames and to receive, understand and act on the messages in incoming frames.
The storage angleThe summarised FCoE story from Blade Network Technologies is that the company's Ethernet is a pretty smart network, but it wants nothing to do with frame contents.
From a storage perspective, this would imply that Fibre Channel SAN users with SAN storage management in the fabric won't be able to move to Fibre Channel over Ethernet unless that functionality can move to FCoE-capable platforms. Of course, they could continue to use these physical Fibre Channel-based products in an FCoE world by adding FCoE gateways to them. But then they wouldn't get the benefits of having storage and general networking converged onto Ethernet. That would make FCoE impractical for them.
Customers using IBM's SAN Volume Controller (SVC) to carry out storage-area network management functions will need to add FCoE interfaces to SVC so it can send and receive FCoE traffic. SAN Volume Controller will also need a full FCoE stack implemented so it can continue its SAN storage management activities in the FCoE world. SAN Volume Controller has to become a Fibre Channel over Ethernet endpoint. It could continue to talk Fibre Channel to the SAN, but the FCoE logic is that it has to talk FCoE so customers can enjoy the full benefits of network convergence.
That means the SAN fabric switch or director it's attached to also has to talk FCoE. I' sure we'll see SAN Volume Controller connect via FCoE to the FCoE SAN fabric switches and directors coming out of Brocade's DCX line and to Cisco Nexus switches.
Logic says Cisco must either migrate its MDS 9000 Series SAN director functionality to Nexus, or add FCoE input and output modules to the MDS 9000 so it can talk FCoE to back-end storage arrays.
Suppliers of storage arrays into Fibre Channel SANs will have to add native FCoE interfaces to their products, which means getting an FCoE stack from somewhere.
Unless EMC revs its InVista software to support Fibre Channel over Ethernet, this seemingly moribund product will turn into a coffin for EMC's in-fabric SAN management hopes. But the writing was probably on the wall for InVista as soon as EMC and its VMware unit started playing server virtualisation and storage footsie with Cisco and its Unified Computing System (UCS) system. What about Hitachi Data Systems and its virtualising Universal Storage Platform V (USP V) and USP VM controllers? These will also need FCoE interfaces so they won't be left out in the Fibre Channel cold.
This train of thought also says that Ethernet switch suppliers with no storage networking smarts won't add SAN storage management functionality to their switches, leaving that field to Brocade and Cisco. Blade Network Technologies, Juniper Networks and other Ethernet suppliers won't compete with Brocade and Cisco by adding SAN storage management functions to their products. SAN storage management functionality running on products attached to FCoE switches or inside them will be a minority sport played by Brocade, Cisco and IBM.
Once the physical Fibre Channel fabric directors have an FCoE capability added to them and can talk to storage arrays or tape libraries with native FCoE interfaces, or their SAN management functions migrate elsewhere, customers can start ripping up Fibre Channel cables and replacing them with Ethernet. And that's the end of my mischief.
Chris Mellor is storage editor with The Register.