Cebreros - Fotolia
Brocade has survived and thrived under the weight of Cisco's competition. Indeed, despite Cisco's mighty network market presence, it has proved ineffective in getting to the top of the storage networking tree. So why hasn't Cisco been able to impose market dominance on Brocade?
In its November Q1 report last year, Cisco showed an estimated 4% year-on-year drop in storage networking revenue. This was its second quarterly decline in a row, with the previous quarter showing an estimated 14% decline. The previous four quarters had all exhibited year-on-year storage networking revenue growth.
Cisco did something (or didn't do something) that caused its storage network revenue to go south. One thing it didn't do was to upgrade its 4 Gbps FC switches and directors to 8 Gbps. Brocade was quick to do this, however, and appears to have reaped the benefit.
Instead, Cisco has focused on integration of FC-based SAN storage networking with the emerging FCoE concept, and introduced a thumping great big switch --the Nexus 10000 -- that functions as a data centre networking hub interconnecting servers, networked storage and access to external networks.
This is the Cisco endgame -- Ethernet everywhere -- but Cisco is discovering that its customers aren't going there until FCoE is good and ready and 8 Gbps FC is available.
Meanwhile, Brocade has introduced its own data centre switch, the DCX, and espoused FCoE support.
Fibre Channel storage networking doesn't drop data frames and has a predictable latency, so much so that an FC link failing to keep to those latencies can cause applications to fail. In contrast, Ethernet and Ethernet-using applications are built to recover from dropped packets and live with variable latencies. That's why iSCSI Ethernet storage uses TCP/IP protocols that detect dropped packets and cause them to be resent.
But FCoE doesn't use TCP/IP, which means a data centre Ethernet (DCE) strategy needs to be formulated, standardised and then appear in Ethernet networking products such as routers, switches and network interface cards (NICs). FC host bus adapter (HBA) vendors, such as Emulex Corp. and QLogic Corp., have developed new interface cards -- called converged network adapters (CNAs) -- that combine standard NIC functionality with FCoE, as well as end-to-end FCoE storage networking between servers.
It's all good stuff, but no customer is going to seriously implement this until DCE is a formal standard with DCE-supporting, end-to-end networking components. FCoE means an all-Ethernet data centre network scheme without the need for a separate FC storage network, but until you can see a migration path from your FC infrastructure to an Ethernet infrastructure, you won't decide on an FCoE migration.
Brocade understood this well -- it sat back, announced FCoE support and said it would wait until the standard exists with a certified kit before rushing full tilt into FCoE. Meanwhile, for those of you needing more SAN throughput, here are 8 Gbps FC products.
In addition, by bidding for and closing the acquisition of Ethernet networking supplier Foundry Networks Inc., Brocade demonstrated its Ethernet credentials. It wasn't saying "Don't buy FCoE yet" because it didn't support FCoE, but because it didn't believe an FCoE infrastructure was anywhere near ready, and most of its customers agreed.
Cisco has been much quicker off the mark than Brocade with VMware server virtualisation support, but this didn't give its storage networking revenue a boost or hasn't so far. Cisco has an investment in VMware and been integrating its Ethernet switches with VMware, even going so far as to create a software switch running as a virtual machine (VM).
One thing Cisco hasn't done is to show how its MDS FC SAN fabric infrastructure functions will be implemented in Ethernet switches, virtual SANs and so on. Is there a VMware play going on here behind the scenes? SAN virtualisation and SAN system applications have to execute somewhere. If they don't run in the fabric directors, they could run in a super controller at the front of the storage -- the tack taken by Hitachi Data Systems' USP -- or in a server hooked into the network link between SAN-accessing servers and the SAN storage, which is the approach of IBM Corp.'s SAN Volume Controller.
Could Cisco be thinking of running these functions as VMs inside a server or integrated in some other way with ESX? Brocade is introducing its own HBAs and the sales pitch here is that, by being better integrated with Brocade SAN switches, customers will get a better quality of SAN service from them than from third-party HBAs. Cisco doesn't have its own HBA play. However, it may be looking at the server/HBA-SAN fabric integration strategy of Brocade and thinking it can do the same with virtual server/storage Ethernet integration, as shown by its virtual Ethernet switch.
The odd thing is that Cisco is relatively quiet on the storage front. There will be more FCoE demos and educational initiatives this year and the 8 Gbps FC transition will continue, but nobody expects 16 Gbps FC products. In addition, FCoE is a 2010 and later play, so what's actually going to happen in storage networking? The iSCSI area is relatively stable with Ethernet getting faster and being positioned as a non-data centre method of storage connectivity. It's already undergone VMware integration and Cisco appears to have little focus on it.
Both Brocade and Cisco need to start offering customers a coherent roadmap of how FC SAN functions will migrate to the FCoE Ethernet storage networking world, one in which accessing servers will be virtualised with VMware and Microsoft Corp.'s Hyper-V.
Microsoft is the elephant in the room of server virtualisation, and with Cisco cozying up to VMware, Brocade might just see Hyper-V integration as a natural tactic. We could expect Cisco to produce a virtual switch for Hyper-V to pre-empt this but, then again, with Cisco being relatively quiet about its storage networking plans, who knows. Ever get the feeling that storage networking is in limbo?
Chris Mellor, storage editor, The Register.