It's not going to be this easy to bridge Fibre Channel and Ethernet!

Before the holidays, I posed a question on Google+ that generated quite a bit of interest and feedback. Now that it has settled down a bit I’d like to summarize the unresolved elements to make FCoE truly a world-class storage interconnect.

Setting the Stage

FCoE has been a controversial topic in both storage and networking, and for good reason. No one would deny that Ethernet is not an ideal transport mechanism for block storage I/O. “Porting” Fibre Channel to run on Ethernet networks has been a supreme technical challenge, and many companies and individuals have labored long and hard to make FCoE a reality.

Now that FCoE is specified in the standard and has been deployed in production environments, the question turns to its future. Will it take off and seize the mantle of dominance currently held by what I like retroactively to call “Fibre Channel over Fibre Channel?” Will they coexist for the next decade, with FCoE mainly deployed in “block” environments such as Cisco UCS? Or will FCoE ultimately fail to catch on, displaced by some other storage protocol like plain FC, iSCSI, NFS, or something entirely different?

The data center needs a flexible new protocol to meet the needs of virtual environments, and convergence of storage and data networking makes a great deal of sense in these environments. This was the root of my question, and I ask it in all earnestness.

My question: What elements remain unresolved to make FCoE truly world-class? What should the vendors be prioritizing? Here are the answers I received.

Technical Considerations

Link Aggregation on CNA’s

Converged network adapters (CNA’s) allow multiple protocols to access a single Ethernet connection, but some also include multiple ports that can be aggregated. In traditional Ethernet networks, link aggregation is a respectable approach for performance and availability. But storage networks have traditionally relied on host-based MPIO software, and these features are mutually exclusive. The zeitgeist seems to be a recommendation to avoid link aggregation on CNA’s that are used for storage networks.

How Do You Handle Virtual Machine Mobility?

As I described recently, virtual machine mobility is a major technical challenge for existing networks. The VMware proposal, the VXLAN, seems to be gaining traction right now. But this is only a solution for data networking. How will FCoE SANs handle virtual machine mobility? This remains unresolved as far as I can tell, though Ethernet switch vendors have come up with their own answers. Brocade demonstrated just such a solution at Networking Field Day 2, and I know that others have answers as well. But will there be an interoperable industry solution?

How Should FCoE Be Implemented Over Longer Distances?

Fibre Channel has traditionally relied on routers and other protocols (FCIP and iFCP) to span distances, but FCoE raises the possibility of native traversal. While it is certainly possible to span distances with FCoE, this is definitely not a recommended or supported idea. Without TCP/IP, or any routing mechanism, it’s just a bad idea. But I imagine that it won’t be long before vendors decide to give it a go anyway.

Implementation Considerations

Is TRILL Required for FCoE Networks?

This has been one of my own questions since the very beginning. Clearly, edge only FCoE works just fine without TRILL. But as networks become more complicated, and virtual machines move, it seems an awfully good idea to have some protocol to alleviate East-West routing concerns. I feel much better with TRILL (or some similar Ethernet fabric technology) in a complicated FCoE network.

Should All Switches Be Full FC Forwarders?

There are number of ways to implement FCoE on Ethernet network, and not all involve building a full Fibre Channel stack in each switch. While many (including myself) assumed that FCoE implied Fibre Channel forwarding in all switches, this is clearly not the direction taken by vendors, at least initially. Perhaps the current “Ethernet forwarding” approach is only a stepping stone, or perhaps it will emerge as the dominant FCoE standard.

How Will OpenFCoE and LoM Be Used?

OpenFCoE is a software solution allowing FCoE to be run without a CNA. If this became popular, it wouldn’t be long before data center architects began looking at LAN on Motherboard (LoM) and even 10GBASE-T as a potential SAN alternative. Will this be used in the long run? It could happen, but it’s certainly not something that’s here at the moment. But OpenFCoE is a real player, especially with Intel’s backing.

How Will Technologies like Zoning Interoperate?

Many networkers are just now beginning to see the true complexity of Fibre Channel SANs. Although interoperability of higher-level Fibre Channel functions between vendors has never been a priority in “FC over FC” SANs, Ethernet could change things. I would not be at all surprised to see a groundswell of customer support demanding greater levels of interoperability from FCoE than from FC, and zoning and VSAN is the likely first beachhead.

The Big Question: When Will We See the “Killer App” For FCoE

Just about everyone agreed that the real challenge for FCoE is market acceptance. Customers aren’t yet demanding FCoE, and vendors are finding it hard to articulate a compelling case to move from “tried-and-true” FC. Convergence, cost savings, and performance have all been put forth, but customers aren’t biting. Perhaps they just need a little time and a little more proof.

This post relies extensively on feedback from a number of people, including Ivan Pepelnjak, Tony Bourke, J Metz, Dmitri Kalintsev, Derick Winkworth, David Hardaker, Juan Lage, and Corey Hines.

© sfoskett for Stephen Foskett, Pack Rat, 2012. |
Eight Unresolved Questions About FCoE


This post was categorized as Enterprise storage, Everything, Gestalt IT, Virtual Storage. Each of my categories has its own feed if you’d like to filter out or focus on posts like this.

© Stephen Foskett for Gestalt IT, 2012. | Eight Unresolved Questions About FCoE
Read more posts categorized as Storage

A Compelling Product

At its core, Compellent is a storage software company. Their Storage Center software creates a “virtual storage array” from standard building blocks. The resulting storage product is one of the most flexible and (excuse the pun) compelling midrange storage systems on the market. Consider the following roundtable discussion from our recent Tech Field Day event in Seattle, which includes a discussion of Compellent’s products and technologies by independent voices in the industry:

Podcast: Play in new window | Download (Duration: 8:59 — 102.7MB)

Compellent’s Storage Center scales up, adding additional storage capacity to existing arrays without disruption and integrating this added bandwidth and capacity seamlessly. Compellent also has an impressive tiered storage and thin provisioning story, since data blocks are virtualized and can be moved between tiers dynamically. Full-featured integrated snapshot technology completes the picture, adding data protection credentials.

Compellent’s scale-out story is impressive as well, but is more about replication and virtualization than the clustering technology used by others, including Dell’s EqualLogic. Compellent’s newly-introduced Live Volume can be thought of as a volume manager for virtual servers, allowing their storage to exist simultaneously on two different storage arrays. Supporting VMware vSphere, Microsoft Hyper-V, and Citrix XenServer, Compellent claims that Live Volume enables a “grid of Compellent arrays”, but it’s not the sort of scale-out grid one would get from EMC’s recently purchased Isilon, HP’s LeftHand, Dell’s Compellent, or NAS specialist Panasas. It’s more of an active-active mirror of storage than a true cluster. Learn more about Live Volume in the following video by Rodos:

Let’s also take a moment to consider the hardware Compellent currently uses: They deploy and sell this software on SuperMicro servers with Xyratex disk enclosures, and Seagate hard disk drives, and connect everything with QLogic, Emulex, and Brocade storage networking gear. This is all pretty much standard-issue for storage vendors: Most no longer produce their own controllers or disk enclosures, and the standard components Compellent uses can be swapped from other sources if needed.

Compellent’s Mid-Market Strategy

Compellent has not traditionally competed in the stratosphere of enterprise storage dominated by EMC’s Symmetrix V-Max, the HDS/HP USP/VSP, and (to a lesser extend) the HP 3PAR InServ. Instead, the Minneapolis-based company has been happy to sell into the fat middle of the market, and has gained a loyal following in smaller-but-still-impressive enterprises. Nowhere is this more evident than at Compellent’s annual “C-Drive” customer conference: It’s amazing, really, for a smallish storage company to have such a devoted user base!

Although they offer two NAS front-ends, Compellent is a block storage player through and through. Their “Storage Center with NAS” offering is decidedly low-end, employing Windows Storage Server 2008 on a 1U server for SMB and NFS connectivity. The newer and more-impressive zNAS is based on the OpenSolaris operating system, including ZFS a friendly interface “co-developed” with Nexenta. Neither product is an in-house Compellent design, nor are they competitive in the high-end “big data” market touted by NAS leaders EMC, NetApp, and BlueArc.

Compellent’s Fit Within Dell

Assuming the acquisition goes through, attention will turn to the fit for Compellent’s Storage Center technology and marketing within Dell. What will Dell get for three quarters of a billion dollars? What will it mean to the enterprise storage market as a whole?

Dell’s EqualLogic acquisition, though expensive, is now widely seen as a success. The Round Rock management team allowed EqualLogic the freedom to develop and compete, while bolstering their hardware and manufacturing story with commodity components. The combination has become a dominant plater in the mid-market iSCSI storage space, and Dell is likely to attempt a repeat of that strategy here. It was widely rumored that 3PAR management preferred Dell’s to HP’s offering based on a promise of similar autonomy.

We assume Dell would replace the EMC-sourced CLARiiON with Compellent in their midrange storage arsenal, replacing the SuperMicro servers. Although Compellent would likely be allowed to develop and grow within the Dell umbrella, there is substantial overlap with the existing EqualLogic line. One would expect Compellent to focus more on Fibre Channel and FCoE (which they recently delivered), though iSCSI support is unlikely to be dropped. A longer-term strategy would see EqualLogic and Compellent combining their midrange storage IP and management team within Dell.

Considering their success selling CLARiiON block storage, Dell’s acquisition would strap a rocket to Compellent’s sales. Once the Dell hardware is grafted in, profits will grow substantially as well. This is a major win for Dell, which needs the kind of margins that only in-house IP can drive. The price is right, the market is ready, and the fit is solid.

What Comes Next

Some are suggesting that this is the end of the storage acquisition parade, but many holes remain. Dell still lacks enterprise NAS, data deduplication, and cloud storage success, and companies like Oracle have only just begun to bulk up their storage strategies. Dell’s acquisitions of Ocarina and Exanet have yet to pay dividends, likely driven by the immaturity of those products. One would not be at all surprised if they continued shopping in the storage space: Panasas, BlueArc, Sepaton, FalconStor, and Overland all look ripe for purchase. Although Compellent is a win for Dell, it is not likely to be their last acquisition.

Disclosure: Compellent sponsored and presented at Gestalt IT’s Tech Field Day 3.

© Stephen Foskett for Gestalt IT, 2010. | Thoughts On A Dell Acquisition Of Compellent
Read more posts categorized as Exclusive, Featured, Storage, Top Story

Before going into details, you need to know some FC and FCoE port terminology:

In the simplest FCoE topology, a server with CNA (converged network adapter; a card that can send both Ethernet and FCoE traffic over the same gigabit Ethernet uplink) is connected to an FCoE-enabled switch, which has a direct connection into the legacy FC network.

The muddy waters start to appear when you have to insert intermediate switches between the servers (VN_ports) and legacy FC fabric. HP and NetApp work with the assumption that the intermediate switches don’t run FC protocol stack and only support Data Center Bridging (DCB) standards. Congestion control becomes mandatory in large networks and network stability is of paramount importance (thus NetApp’s recommendation to use TRILL).

Cisco, on the other hand, is pushing another design: every intermediate switch is a full-blown FC switch, running full FC protocol stack and participating in FSPF (FC routing). In this case, you don’t need congestion control (congestion is handled by the FC protocol stack) and you totally bypass bridging, so you don’t care whether bridging uses spanning tree, TRILL or something else.

The truly confusing part of the whole story: both designs (and any combination of them) are valid according to the FC-BB-5 standard; I’ll try to point out some of their benefits and drawbacks in future posts. FIP snooping and NPIV/VNP_ports in FCoE environment are covered in the next post.

If you liked this explanation and would like to get a more thorough introduction to new LAN, storage and server virtualization technologies, register for my Data Center 3.0 for Networking Engineers.

© Ivan for Gestalt IT, 2010. | Multihop FCoE 101
Read more posts categorized as All, Networking

“Bridging versus routing” brings us to the perennial networking debate: Are low-level protocols better?

Unless you’re “in the know”, terms like “layer 2″ can seem mysterious, making it all the more plausible when someone touts the benefits. It seems logical: “Bare-metal” communication must be better, faster, and cheaper than higher-level “everything over IP” approaches, right? But it’s not quite that simple.

This piece assumes you know something about the OSI model.

Ivan Pepelnjak posted a great overview of the “bridging versus routing” debate (Bridging and Routing: is there a difference?), and Marko Milivojevic posed the question in response: “I’m one of those who doesn’t understand the whole L2 obsession of the modern networking world, but…”

It really is an obsession: Data communications folks continually argue about the merits and trade-offs between high-level network protocols and low-level communications. We hear it in storage all the time: FCoE proponents assume performance benefits, and AoE fans add cost advantages to the mix. But many of these claims are unsubstantiated, and iSCSI and NAS protocols like SMB and NFS just keep rolling forward. If storage over IP is so bad, why does iSCSI work (and perform) so well?

One thing often missing in the “layer 2″ arguments is what’s missing when you skip the network layer. There’s a reason IP is so widespread: It may not be the best protocol ever, but it works really well in a huge variety of situations and there is a vast pool of associated technologies that can be drawn upon when using it.

IP can run over just about anything, from FireWire to SONET, so any protocol using IP can (theoretically) run there, too. I’ve run iSCSI over Wi-Fi and WAN links, and it works great out of the box with 10 Gb Ethernet. Protocols that are tightly linked to a layer-2 protocol face stiff challenges when moving to different data links. Witness the difficulty moving Fibre Channel to 10 Gb Ethernet, including all those data center bridging technologies. In fact, when faced with the challenge of long-distance Fibre Channel SAN communication, encapsulation over IP was a natural choice.

IP also has a myriad of wonderful technologies to choose from. The creators of iSCSI were able to pull authentication, encryption, lossless communication, and many other features straight from the existing toy box. Developers of new non-IP protocols have to invent their own solutions to these problems, often with disastrous results. Why reinvent the wheel? Just apply a little CHAP, some IPsec, and roll it in TCP and you’re done!

Photo credit: “Akashi Kaikyo Bridge 明石海峽大橋” by Shenghung Lin

© Stephen Foskett for Gestalt IT, 2010. | The Lure of Layer 2
Read more posts categorized as Networking, Storage

Background

Building arrays from pure memory isn’t new; Texas Memory Systems have had the RamSan series of products on the market for some time now (and there are others out there).  Of course, the problem for many large organisations is how to make use of such an expensive and relatively small device.  There are plenty of use cases where flash/SSD may be useful, however (a) it is difficult to target exactly which applications and (b) for those applications that can be identified, potentially only part of the data will benefit from acceleration.

One solution has been to follow the route of the traditional vendors and add SSD as an extra device within the same hardware chassis.  This isn’t a solution to using SSD but rather a sticking plaster over the problem; the SSD may give better read performance but it is unlikely that writes will be accelerated to the level justified by the additional costs of the SSD device itself.  In addition, the SSD is sitting behind a traditional storage array.  Vendors such as EMC, IBM and Hitachi have spent millions of man-hours and hundreds of millions of dollars on software developments to help smooth the impact and manage the unpredictable performance of hard drives.  Remember that when an I/O request is received, the storage array has no idea where a mechanical device like a hard drive is positioned and so cache, algorithms and that other clever intellectual property have been used to mask these physical inadequacies.

However, despite vendors’ best efforts, spikes and unpredictable response times do occur and there’s no way to remove them and guarantee completely consistent I/O responses.

The Violin Approach

So what happens if you can remove the cost issues and buy an SSD-based array for the same price as tier 1 storage?  This is the route Violin Memory are taking to market – make the SSD storage array as closely priced to tier 1 arrays as possible.  Remove the thought process and complications of determining what to place on SSD by making the price argument irrelevant.

In reality, Violin haven’t reached that price parity yet; prices are quoted around the $20/GB mark, which is around double what I’d expect to see for tier 1 storage (depending on volume).  However it is in the order of magnitude where organisations can look at those troublesome applications that decide that the cost of additional servers, disk spindles or re-writing the application is outweighed by simply moving the application to a Violin SSD device.

I think this is the ultimate tipping point for SSD use; where the cost of improving application performance is exceeded by the cost of moving to SSD, then SSD will win.  Where improving application performance is justified by increased business advantage, the business case is written.

Tech Specs

OK, let’s have a look at the technical specifications for the techies amongst you.  Firstly, today’s device capacity sits at 10TB in 3U and is expected to grow to 20TB in Q3.  I’ve also been told that this capacity is expected to be close to 5x greater by the end of 2010, which means 100TB of memory-based storage in a 3U unit.

The 3200 supports PCIe (x4 & x8)  as well as 4/8Gb Fibre Channel and 10Gb iSCSI and FCoE.  Latency is less than 100 microseconds.

Violin array use VIMMs (Violin’s name for their flash memory cards.  These are grouped together into 1TB units, using RAID-5 technology to manage failures.  Maintenance can be performed online periodically to replace failed VIMM devices.

There’s one major issue with Flash/memory-based arrays that Violin claim to have addressed.  That is the issue of degraded performance over time.  Have a look at the following graphic, showing saturated workload on the Crucial C300 versus X25M from Intel.  This graph and the associated review can be found on Anandtech’s website here.  Very quickly with heavy use, the performance for these devices drops off.  Violin claim their array doesn’t suffer similar issues and can deliver sustained performance.  Of course, we can believe that statement once we’ve seen a review of the product delivering the performance as promised.

Futures

A 10/20TB capacity in 3U isn’t huge by today’s standards.  If Violin Memory can deliver on their promises and bring a 3 to 5-fold increase in performance by year end (with a continual reduction in price) then things start to look interesting.  I’d like to see the results of some long-term stress tests on the 3200 series devices.  I have some more material to post in the coming days, once I can validate what’s open and not under NDA/embarbgo.  In the meantime, here are some questions to ponder:

• Do I have any I/O bound applications?
• Can I measure/determine my I/O bound applications?
• Is there direct businss advantage from increasing I/O throughput?

If you can start answering yes to the above questions, then perhaps SSD-based arrays are for you.

© Chris for Gestalt IT, 2010. | Violin Memory Inc Release New All-SSD Array
Read more posts categorized as Featured, Storage

What is a surprise, is that Cisco has moved into the Server market. The convention has been that Intel server market was saturated, with reasonable profit margins and a cosy competition between Dell / HP and maybe even IBM.

Leverage what you are good at, and steal someone else’s ideas

Obviously, Cisco is good at networking and ethernet. So they developed some networking and made the Nexus 5000, 2000 and CNA adapters to produce a Top of Rack networking ecosystem. That’s an easy thing to do and has a great marketing pitch. How so ? Easy. It’s the same story that Infiniband has been putting around for the last ten years. Better management, ease of use and administration blah blah. Lets take the Infiniband goodness, do it on Ethernet and, voila, customers can understand Top of Rack networking. None of that “new” technology around here, give me ethernet. (Lets pretend that this DCB ethernet is _really_ “good old Ethernet” even though it’s a long way from the original Ethernet standard).

Cisco hasn’t been able to shake Brocade from it’s number one position, so they sent a team of engineers out to form a company to build Fibrechannel over Ethernet. Give a bunch of cash, no corporate interference and you get … Nuova Systems. Buy them back after two and half years and you’ve got yourself a “new” technology that bridges all those FibreChannel networks into your core competency. AND you take out the number one competitor at the same time. Awesome leverage of what you are good at.

Oh, and FCoE has been in the works for years. No one was much interested in actually spending money until Cisco decided to “leverage” it.

A Little Geek Fairy Dust

But we need more. We need a little magic on the motherboard. Gluing Intel chips to a motherboard isn’t going to make a good story to those server geeks who care about Northbridge chipsets, front side bus and memory access rates. They aren’t going to change vendors unless we have a little something for them. Cisco did a little deal with Intel, who rummaged around in their drawer of unfinished toys and produced the ‘memory doubler’ and some fancy new I/O chips. Maybe Cisco promised to buy some more Intel i960 chips to put into some networking gear in return. Whatever. Pure ‘unobtainium’. Perfect.

Operational Costs – The Management Pitch

What’s missing ? Of course, the pitch to the “business man”. You see, you aren’t going to get 30% market share in a short period of time by relying on geeks to change vendors. The corporate emphasis on risk reduction and change management means most geeks can’t face the paperwork for change.

And that’s called selling from the bottom up. You have to have a story that sells from the management down as well. The story that you pitch to CIO so that he heads on down to the geeks and says “We need to look at some of that Cisco servers, why aren’t we looking at them”, or, at the very least, “I’ve heard good things about Cisco servers, we can try them out” – which means some risk and change is possible.

That’s easy, we wrap some management software that makes it look like you are “in control” or “lower the deployment” cycle, or “reduce operational costs”. The best part of this software is that it can be a “Powerpoint release”, it doesn’t have to be real.

What ? Is that a bit harsh ? OK, so when was the last time you had a “management platform” that really worked ? Uh huh, Not so much. Most likely you are still looking to replace what you already have. Check out Cisco CS-MARS, or HP Openview, or BMC Patrol for background data.

One more thing

The last thing that Cisco put into those servers was a bit of BIOS magic. No one normally wants to change much in the server platform, there is no money in it. But Cisco made their servers stateless. Optional feature to be sure, but you can load the BIOS, MAC Address, WWN etc etc from a central server. That’s very different.

Cynical

So when I look at the Cisco UCS server strategy, I don’t see too much innovation. I see some cynical marketing that allows Cisco to make a good pitch to customers. Every feature is carefully targeted to “manage your buying objections” and get the sale. Too much innovation would scare the customers away or create uncertainty but enough innovation to get good differentiation and give your entrance into an existing market a good chance to succeed. You can bet that Cisco has a carefully crafted answer for every question you ask them so that they can close the deal.

The EtherealMind View

With that said, I like Cisco UCS strategy very much. It looks to me like the first visible innovation in Server Hardware in five years or more. Instead of racing to bottom for the cheapest price to glue Intel chips on a motherboard, Cisco is attempting to move into the high end of the market. To open that market against HP and IBM requires more than just competing. Cisco MUST be different.

Even better, Cisco is only moving into the high end Data Centres. That leaves them the low end for later, when they want revenue or volume growth. The shareholders will like those numbers.

What I also find interesting is that Cisco continues to “double down” on the strategy. They spent USD$250 million to buy Nuova (after they VC funded it as a startup with Cisco engineers). They’ve spent USD$250 million on the joint marketing venture with EMC / VMware. And probably spent the same amount again building the internal organisation, startup marketing and hiring headcount. Add the same again to get production and manufacturing costs before a single sale is made. This will help to get some big deals done so that the sales people can point out how successful they have been. This is vital to crossing the chasm so that mainstream corporates will start to buy UCS.

And UCS has some excellent features for administration and the management tools might actually deliver results and changes to the industry in the near future. The integration with VMware, especially Nexus 1000, provides a lot of functionality that is needed for large scale build outs.

But the product is very carefully designed, feature selected, just-enough-innovation and features to make you think about the product and seriously consider it. Even the grey colour is selected to be non offensive.

That’s not innovation, that’s just marketing.

© Etherealmind for Gestalt IT, 2010. | Cisco UCS Servers – A Little Bit of Cynical Marketing Magic Can Go a Long Way
Read more posts categorized as Featured, Networking, Server Virtualization

Do you know me?

Visitors to the Fibre Channel Industry Association (FCIA) booth at Storage Networking World in Orlando were greeted by a strange symbol (pictured above). It was included in the FCIA  Fibre Channel roadmap presentation as well. The group even made identifying the symbol a requirement to enter their door prize drawing.

But what is the symbol exactly? I was amused to get some puzzled looks (and no correct answers) when I polled a number of industry insiders. One even asked about the symbol when I included it in a blog post about Microsoft’s lack of FCoE support.

I guess everything needs a symbol nowadays, and Fibre Channel over Ethernet (FCoE) is no exception. Yes, this is the FCIA’s new FCoE symbol.

Fibre Channel plus Ethernet equals FCoE

Breaking it down, we might recognize the unofficial but widespread symbol of Ethernet (glance at the back of your PC or the box your switch or router came in) in the background with a double-ended single-bladed arrow superimposed. That arrow is apparently the new symbol for non-Ethernet Fibre Channel (FC).

Aren’t you glad you asked?

© Stephen Foskett for Gestalt IT, 2010. | FCoE Symbolism
Read more posts categorized as Storage

FCoE is taking enterprise storage by storm, but where is Microsoft?

Microsoft is a controversial company, generating a mix of criticism and praise everywhere they are involved. Although I’m definitely a Microsoft skeptic, I’ve been pleased by much of the work they have done in my field of enterprise storage. Their client-side (“initiator” to us storage folks) work has been especially notable, making me wonder why no other operating system vendor has as diverse and full-featured storage support as Microsoft. I would go so far as saying that the iSCSI SAN revolution would not have happened if not for the folks up in Redmond.

Enterprise storage is in the midst of another shift these days. iSCSI moved low-end and midrange servers to SANs by leveraging Ethernet for connectivity. Now, the storage and networking industry is pushing to do the same for high-end Fibre Channel SANs, bringing Fibre Channel over Ethernet (FCoE) to life before our eyes. Although users are not yet on board, the dominance of FCoE seems almost certain to many industry watchers.

Where Is Microsoft?

But where is Microsoft when it comes to FCoE? I see no public statements of support for the protocol. I see no participation in FCoE standards-setting (though the company did recently join the FCIA as an “Observer”). Most importantly, I see no software features developing solid enterprise support for FCoE within the Windows operating system. Put simply, Microsoft does not seem to be participating in FCoE development, either on the initiator or target side.

Some may say Microsoft doesn’t need to get involved. After all, most FCoE integration will rely on third-party hardware and drivers that appear to be standard Fibre Channel HBAs to Windows. But this argument is spurious: Microsoft never got very involved in Fibre Channel either, and the confusing state of third-party FC SAN connectivity in Windows is a stark contrast to the solid and reliable iSCSI initiator. The fact that Microsoft embraced iSCSI while allowing third parties to “own” FC is an indictment of their stance towards FCoE.

Then there is Microsoft’s FCoE  logo program. In March, I was pleased to note that Microsoft would at least add FCoE to their Windows Logo program. Yet there has been no sign of the Logo Kit, promised for December, and just one mention of this program in the last year: Microsoft delayed enforcement of FCoE Logos until December of 2010. As far as an outside observer would know, Microsoft hasn’t moved forward with even the most basic FCoE support, a Logo program, in a year.

I am not suggesting that Microsoft must develop software FCoE targets. In fact, a Microsoft FCoE target might prove to be counter-productive, discouraging storage vendors from competing. A software initiator would be welcome, but the high-end target audience makes this less critical than for iSCSI. Instead, Microsoft should begin to develop a converged I/O framework around the DCB standards, including a detailed FC and FCoE integration architecture for third-party hardware and software.

Unacceptable

The current state of affairs is simply unacceptable. Consider the systems using FCoE: Many criticize Microsoft’s presence in the data center at all, but no one can deny their power there. Microsoft Windows Server powers most enterprise compute tasks today, running on almost three quarters of data center servers. Windows Server will almost certainly be the leading user of Fibre Channel over Ethernet connectivity.

On the other side of the equation, storage and networking vendors from EMC and NetApp to Cisco and Emulex are pushing hard for the FCoE transition. Regardless of end user indifference, FCoE will dominate SAN deployments in the next few years. It’s a question of “when” not “if”  - DCB and FCoE will take the data center by storm.

Certainly, Microsoft can simply allow the FCoE ship to sail without them on board. They can allow third-party HBA/CNA, server, and networking vendors to bring FCoE support to Windows. But this represents a massive missed opportunity for the company and a capitulation in the high end of the enterprise market. Microsoft must immediately move to take leadership in FCoE: Add corporate resources, step up standards efforts, publish the Logo Kit, and develop a framework of support.

Disclaimer: I am a Microsoft MVP in the area of storage. Their kind treatment of me obviously didn’t color my perception of them with regards to FCoE. I also have an NDA with Microsoft, and they have briefed me on future Windows Server and storage developments. Nothing in this post should be construed to reveal the company’s future plans.

© Stephen Foskett for Gestalt IT, 2010. | Where Is Microsoft’s FCoE Support?
Read more posts categorized as Storage

Last Friday (April 9th), I and the rest of the Gestalt IT tech field day delegates were invited by Cisco to get a briefing on Cisco’s Unified Computing System or in short “UCS”. Basically this is Cisco’s view that builds on the notion that we are currently viewing a server as being tied to the application, instead of seeing the server as a resource that allows us to run that application.

Anyone in marketing will know that the next question being asked is “What is your suggestion to change all that?”, and Cisco’s marketing department didn’t disappoint us and tried to answer that question for us. The key, in their opinion, is using a system consisting of building blocks that allow me to to give customers a solution stack.

As the trend can be spotted to go towards commodity hardware, Cisco is following suit by using industry standard servers that are equipped with Intel Xeon processors. Other key elements are a virtualization of services, a focus on automated provisioning and unification of the fabric by means of FCoE.

What this basically means is that you order building blocks from Cisco in the form of blade servers, blade chassis, fabric interconnects and virtual adapters. But instead of connecting this stuff up and expanding my connectivity like I do in a standard scenario, I instead wire my hardware depending on the bandwidth requirements and that’s pretty much it. Once I am done with that, I can assign virtual interfaces as I need them on a per blade basis, which in term removes the hassle of plugging in physical adapters and cabling all that stuff up. In a sense it reminded me of the take that Xsigo offered with their I/O director, but with the difference that Cisco uses FCoE instead of Infiniband, and with Cisco you add the I/O virtualization to a more complete management stack.

The management stack

This is in my opinion the key difference. I can bolt together my own pieces of hardware and use the Xsigo I/O director in combination with VMware and have a similar set-up, but I will be missing out on one important element. A central management utility.

This UCS unified management offers me some advantages that I have not seen from other vendors. I can now tie the properties to the resources that I want, meaning that I can set up properties tied to a blade, but can also tie them to the VM or application running on that blade in form of service profiles. Things like MAC, WWN or QoS profiles are defined inside of these service profiles in an XML format and then applied to my resources as I see fit.

Sounds good, but…..?

There is always a but, that’s something that is almost impossible to avoid. Even though Cisco offers a solution that seems to offer some technical advantages, there are some potential drawbacks.

• Vendor lock in: This is something that is quite easy to see. The benefit of getting everything from one vendor also means that my experience is only as good as the vendors support is in case of trouble. Same thing applies when ordering new hardware and there are unexpected problems somewhere in the ordering/delivery chain
• The price tag: Cisco is not know to be cheap. Some would even say that Cisco is very expensive, and it will all boil down to one thing. Is the investment that I need to make for a UCS solution going to give me the return on invest? And is it going to do that anytime soon? Sure it can reduce my management overhead and complexity, sure it can lower my operational expense, but I want to see something in return for the money I gave Cisco and preferably today, not tomorrow.
• Interoperability with my existing environment: This sort of stuff works great when you are lucky enough to create something new. A new landscape, a new data center or something along those lines. Truth is that usually we will end up adding something new to our existing environment. It’s great that I can manage all of my UCS stack with one management interface. But what about the other stuff? What if I already have other Cisco switches that are not connected to this new UCS landscape? Can I manage those using the built in UCS features? Or is this another thing that my admins have to learn?
• The fact that UCS is unified does not mean that my company is: In smaller companies, you have a couple of sysadmins that do everything. They install hardware, configure the operating system, upload firewall policies to their routers and zone some new storage. So far so good, I’ll give them my new UCS gear and they usually know what goes where and will get going. Now I end up in the enterprise segment where I talk to one department to change my kernel parameters, a different to configure my switch port to auto-negotiate and the third one will check on the WWN of my fibre-channel HBA to see if this is matching to the one configured on the storage side. Now I need to get all of them together to work on creating the service profiles, although not all will be able to work outside of their knowledge silo. The other alternative would be to create a completely new team that just does UCS, but do I want that?

Besides the things that are fairly obvious and not necessarily Cisco’s fault, I think that Cisco was actually one of the first companies to go this way and one of the first to show an actual example of a federated and consolidated solution. Because that is what this is all about, it’s not about offering a piece of hardware, it’s about offering a solution. Initiatives like VCE and VCN only show us that Cisco is moving forward and is actually pushing towards offering complete solution stacks.

My opinion? I like it. I think Cisco have delivered something that is a usable showcase, and although unfortunately I have not been able to actually test it so far, I do really like the potential it offers and the way it was designed. If I ever get the chance to do some testing on a complete UCS stack, I’ll be sure to let you know more, but until then I at least hope that this post has made things a bit clearer and removed some of the questions you might have. And if that’s not the case, leave a comment and I will be sure to ask some more questions on your behalf.

Disclaimer: The sponsors are each paying their share for this non-profit event. We, the delegates, are not paid to attend. Most of us will take some days off from our regular job to attend. What is paid for us is the flight, something to eat and the stay at a hotel. However as stated in the above post, we are not forced to write about anything that happens during the event, or to only write positive things.

© Bas for Gestalt IT, 2010. | Gestalt IT Tech Field Day – On Cisco and UCS
Read more posts categorized as Featured, Server Virtualization

We have no confirmation from Cisco, it could just be rumour but it sure sounds like it could be true and it makes sense. After all, HP and Cisco have been trading blows for the last two years and progressively escalating the war. Once the Acadia / VCE project was announced, it was clear where Cisco is planning to go.

It’s my opinion that HP started the fight about three or four years ago when they restarted their Procurve networking products.

ProCurve – why did HP start ProCurve ?

HP set out to make low cost Ethernet switches that directly connected to a core Cisco network. They even convinced Cisco to license their CDP technology which reassured the network engineers that somehow Cisco approved of this new equipment.

More recently the ProCurve product grew to include chassis based switches that had some serious routing capability. At that point, it was clear that HP means to take on Cisco. Cisco regards those core ethernet switches as their own market and no one else should be in that space.

HP bought 3Com

While HP only had switches, Cisco resellers could always position their “portfolio”. That is, not only does Cisco have switches, but routers, security appliances, management software, WAN equipment and the whole show.

But after HP integrates 3Com, they have the whole portfolio too. In fact, not a very good one since 3Com equipment is not exactly recognised as quality. Most importantly, the people who design networks and layout strategy remember being completely shafted by 3Com in the early 2000′s and they haven’t forgotten.

So, now HP has a complete portfolio. It needs money and time to build this portfolio into a quality product offering (because the current product isn’t ready for the big time e.g. here). The HP ProCurve has a solid reputation for cheap and cheerful (and NOT enterprise grade).

So Cisco did some servers

As part of the FCoE push, Cisco released a bunch of Intel servers. Ultimately, the actual servers are a me-too product with some cute finishing touches. That is, if you glue Intel chips to a motherboard, you don’t get a lot of profit margin, Intel does. And this isn’t a strategy that Cisco has done before.

Several people/pundits have queried whether Cisco has been forced into servers. I maintain that Cisco had to respond to HP entering the network space. They have added some Cisco sauce by applying a network technology to their platform disguised as FCoE. This means they have a good marketing strategy, a differentiator for the customer.

it’s possible that this was the intent all along. Ditch HP before their network strategy is mature and enter the server space with a strong offering. They’ve got EMC for storage, and partnerships with all the majors such as Intel, VMware, Microsoft etc.

What Level?

The one partnership that matters between Cisco and HP is the “Gold Partner Status”. This entitles HP to preferential purchase price, deep technical support integration and many other benefits. If Cisco removes this partnership, then HP can no longer compete in the open market on price (unless they make a loss) or technical support.

But there are other partnership programs that have various names. Global partners, Corporate Partners, Strategy partners or whatever. They change quite often and they don’t have much impact at customer level. If Cisco is removing HP from one these programs, we won’t see much of a change.

Dell dumped too ?

Network World has reported that Cisco is planning to kill it’s partnership with Dell. Combine this with the HP termination and we might have a trend. John Chambers has been known to make big bets in the past, and this might be something they need to do.

Losing share in the telecomms area

Cisco has also been losing marketshare in the Telecomm / Service Provider space. This is where the really big money is, with millions spent on just a few projects. Juniper and Huawei are taking big chunks out of Cisco’s customer base. Does this leave Cisco with a revenue hole in a couple of years ?

“Forward Planning”

So, if it’s true, the Cisco is planning to move up the stack and sell Intel servers. Further, they mean to take HP head on in the existing customer base. It’s an aggressive move but a perfect time to do it.

First, HP ProCurve networking needs a couple of years to mature and stabilise. Second, HP Management is busy digesting their acquisition of EDS (which is having problems due to low profit margins in the EDS business) and may not be able to cope with a head on fight. Third, HP people are disorganised due to the number of re-organisations, cutbacks, and acquisitions.

As a customer, I’m delighted. I’m expecting to see price cuts and improved service. Cisco has been light on new features for the last couple of years and steadily increasing prices. HP has become fat and comfortable with it’s incumbent status.

Bring it on.

© Etherealmind for Gestalt IT, 2010. | What might it mean if Cisco Dumps HP As Certified Partner ?
Read more posts categorized as Featured, Networking