Storage Area Networking Category Archives

May 10, 2008

Invitation to Webcast on SAN Innovations

Cisco will be hosting a webcast on Innovations for Next Generation SAN Architectures including FCoE. Plus, we'll have a special message from our storage partner, EMC.

I invite you all to join to learn about our strategic direction for the MDS 9000 product line.

Posted by Deepak Munjal at 04:29 PM Permalink | Comments (0) | TrackBacks (0)

May 05, 2008

Start Believing the Hype

I continue to read posts from those who doubt that FCoE can succeed. That it is a major conspiracy amongst Fibre Channel vendors to keep Fibre Channel alive because iSCSI is eating into their market or as a way to churn the base by forcing customers to upgrade to shiny new gear.

Then there are the Fibre Channel proponents who believe no other network technology can come close to delivering the quality or perfomance that it can deliver and it is best to keep two separate networks indefinitely.

The reality is probably somewhere in between.

Fibre Channel succeeded when it did because no other network offered similar bandwidth nor the lossless capability that storage traffic requires. But as Fibre Channel networks continued to grow and become more strategic, the cost of maintaining two large networks was fast becoming unacceptable in these cost-conscious times.

But things have changed. Ten gigabit ethernet is here and prices for both switches and adaptors have come down in price to where it is now attractive enough to deploy everywhere. Also, Ethernet continues to mature and can now deliver a lossless capability through a new set of standards-based features called Data Center Ethernet.

With high-performance 10GbE switches enabled with Data Center Ethernet like the Cisco Nexus 5000, FCoE can now be realistically deployed in the server access layer with confidence that it can perform as well as Fibre Channel and still provide the benefits of a converged network that include simplified cabling, reduced hardware costs, and lower operations expenses.

Posted by Deepak Munjal at 04:10 PM Permalink | Comments (0) | TrackBacks (0)

April 18, 2008

Cisco MDS 9500 Continues to Innovate

As Doug mentioned in his recent blog:

http://blogs.cisco.com/datacenter/2008/03/fcoe_fibrechannel_ethernet_eag.html

the MDS platform is here to stay. There have been a lot of announcements from Cisco recently on Nexus, FCoE, and Data Center Ethernet and that's certainly important news. However, the MDS quietly continues to innovate in the Fibre Channel market while maintaining a leadership position in Director market share (Dell'Oro CQ407).

According to Gartner, there is over $50B in installed base of Fibre Channel switching and storage equipment and it is unlikely to be obsoleted anytime soon.

FCoE offers a very important value proposition to consolidating I/O on servers that tradionally have several different interfaces and cables. To be sure, most of the complexity of running two parallel networks is at the server access layer where 80% of the ports typically exist and where there is the most concentration of cables.

However, storage arrays, tape drives, VTLs, FICON, and other Fibre Channel assets will continue to use standard Fibre Channel attachments and will likely require upgrades to 8G soon.

The MDS 9500 Director, announced in 2002, with support for 1/2/4G Fibre Channel will deliver on this requirement by delivering 8G interfaces without requiring a forklift upgrade.

And as servers begin to use FCoE to attach to the Fibre Channel SAN, the MDS 9500 will also offer FCoE line cards to ensure there is interoperability between both environments.

Investment protection is the ulitimate form of innovation.

Posted by Deepak Munjal at 11:11 AM Permalink | Comments (0) | TrackBacks (0)

April 16, 2008

The Anti-FCoE Sentiment

One more anti-FCoE post , this time from Greg Ferro, who seems to be a supporter of storage over IP.

I am not yet sure I understand why people who should support FCoE (i.e. the networking community) are taking side against it, while the strongest supporters seem to be coming from the storage community. I do not even understand why we should take any sides at all, but I think it's important to clarify the facts and let readers make the final call.

There is one piece of the post that is important to correct, and it's the one that talks to the "reasons not to use FCoE." Let's go line by line:

* FCP endpoints are inherently costlier than simple NICs – the cost argument (initiators are more expensive)

This is absolutely true, but the comparison is not correct. You should be comparing FCoE cards with TOE (TCP Offload Engine) cards or iSCSI HBAs. If you do that comparison, you immediately realize that the cost advantage is on the FCoE side. The iSCSI adapters are priced anywhere between $1,000 and $2,000 and they are mostly 1GE today.
With FCoE you can also opt for a software only implementation (much lighter stack than iSCSI/TCP/IP.) If you do that, the cost is reduced because you can use a regular 10GE NIC ($799 list price) to run FCoE with a software stack.

* The credit mechanisms is highly unstable for larger networks (check switch vendors planning docs for the network diameter limits) – the scaling argument

The credit mechanism is a link-level flow control mechanism and has nothing to do with the size of the network. Fibre Channel networks are small because the domain ID field in FC frames is a 8-bit field. This means that you cannot have FC SANs with more than 255 Domain IDs (i.e. switches.) If you use VSANs you can multiply that by the number of VSANs (up to 4000.) I do not think this is a "real" problem. I never heard single storage administrator complaining about the size of their FC SANs; the problems are usually elsewhere.
Besides all that, FCoE does not use credits as Ethernet is the transport protocol.

* The assumption of low losses due to errors might radically change when moving from 1 to 10 Gb/s – the scaling argument

There is no "assumption" of "low losses". FCoE runs on top of a "lossless Data Center Ethernet" network, which is the real differentiator. Data Center Ethernet (as pointed out by Cisco and Dell in previous posts) will benefit any kind of storage traffic over IP, be that FCoE, iSCSI or NAS (CIFS/NFS)

* Ethernet has no credit mechanism and any mechanism with a similar effect increases the end point cost.

Ethernet has had the standard PAUSE mechanism defined for a long time and you have been paying for it with every single NIC or switch that you purchased over the past few years. We have just never found the right application for using it. 802.1Qbb expands the use of PAUSE by defining PFC (Priority-based Flow Control) which allows network nodes to selectively decide which types of traffic should be lossless and which ones should not.
On a more theoretical note, if all of Ethernet became lossless by deploying PAUSE (I am far from suggesting this is the right thing to do) the cost of end points (and switch ports) would be lower because in a lossless environment buffers can be sized more easily than in a best-effort network, where you have to size buffers according to the maximum size of bursts that you would like to support.

* Building a transport layer in the protocol stack has always been the preferred choice of the networking community – the community argument

Once again, very true, but it is not the real point. This is not about the networking community in isolation, but the broader data center community, which includes the storage administrators, who for the better or the worse, do their job with Fibre Channel today and would like to find the smoothest and simplest way to leverage Ethernet without putting their jobs at risk.

* The “performance penalty” of a complete protocol stack has always been overstated (and overrated). Advances in protocol stack implementation and finer tuning of the congestion control mechanisms make conventional TCP/IP performing well even at 10 Gb/s and over.

True, but I think it is difficult to argue that more protocols are better than less protocols in terms of performance. Always remember that "perfection is achieved not when there is nothing left to add, but there is nothing let to take away."

* Moreover the multicore processors that become dominant on the computing scene have enough compute cycles available to make any “offloading” possible as a mere code restructuring exercise (see the stack reports from Intel, IBM etc.)

All true, but once again, not necessary. The issue is not TCP, but the fact that iSCSI is a different beast than FC and the storage community does not necessarily like it (if they did, do you think they are all so "blind" not to see the oportunity with iSCSI; they must be smarter than that!)

* Building on a complete stack makes available a wealth of operational and management mechanisms built over the years by the networking community (routing, provisioning, security, service location etc.) – the community argument

This is a very good argument and I agree with it, but once again, it's a benefit that has not reasonated well with the storage community so far. We need to keep in mind that storage folks have a job to do and have been doing it just fine so far. iSCSI is better, no argument there, but it's different and not necessarily simple to understand and use for someone, who is already familiar with FC. Also, it's one more thing to deal with and people are not just going to rip and replace FC because iSCSI is better. FCoE gives them a migration path and over time might make even iSCSI easier to adopt.

* Higher level storage access over an IP network is widely available and having both block and file served over the same connection with the same support and management structure is compelling – the community argument

Very true, but let's not forget that the large majority of storage traffic is local, where Ethernet represent a unifying transport as much as IP does. Data Center Ethernet is the key enabler for unified fabric, which translates in benefits for all of the storage transports.

* Highly efficient networks are easy to build over IP with optimal (shortest path) routing while Layer 2 networks use bridging and are limited by the logical tree structure that bridges must follow. The effort to combine routers and bridges (rbridges) is promising to change that but it will take some time to finalize(and we don’t know exactly how it will operate). Untill then the scale of Layer 2 network is going to seriously limited – the scaling argument

There are two things to consider here:
(1) Data Center Ethernet includes the ability to run alternative topology selection protocols that enhance the scalability of layer 2 domains by ultimately removing the STP (Spanning Tree Protocol,) and
(2) To benefit of the FCoE value proposition all you need is an access layer switch (I would suggest the Cisco Nexus 5000 ;-) ) The rest of the infrastructure (Ethernet and FC) remains unchanged.

Almost every Fortune 1,000 company has a large installed base of FC storage arrays and SANs. FCoE allows new servers to utilize the existing infrastructure with few cables, adapters, etc… without incurring any performance penalty. It is not a realistic scenario for people to rip out all of these storage arrays and replace them with iSCSI targets, or go through and upgrade each array to make it iSCSI enabled (load new firmware, plug in more Ethernet cards in the array, expand out the Ethernet network to accommodate all the new array ports, etc…).

Once again, this is about building a Unified Fabric over Ethernet and allow for the smoohest, realistic transition possible. iSCSI and FCoE should not be positioned as alternatives as they address and solve different problems.

Posted by Dante Malagrino at 08:21 AM Permalink | Comments (3) | TrackBacks (0)

April 08, 2008

Cisco Nexus 5000: The human side of technology

What a long day! At least for my team. The Unified Fabric launch and the introduction of the Cisco Nexus 5000 was a significant one for Cisco, and certainly had quite a big impact on my team. But this is not the "human" side that I wanted to talk about...

One thing that has come up quite a lot in my briefings today is the human side of implementing a Unified Fabric in the Data Center, i.e. the impact that network unification would have on existing teams and ultimately on individuals.

One thing that I believe to be a key differentiator for the Unified Fabric is its "transitionary" nature. Network convergence can not be a revoluton, but it needs to be a gradual evolution of Data Center networks. I certainly believe that the organizations that will be able to take advantage of this architectural evolution faster will also be the ones that will see the biggest returns and the biggest gains in competitive advantage, but at the same time I understand the concern that some people have expressed to me on how this technology might impact existing organizations.

Out of the four main pillars that were presented by Soni Jiandani during the press conference this morning, there are two that certainly speak to backward compatibility and preservation of existing management best practices: Data Center Ethernet and Fibre Channel over Ethernet.

Data Center Ethernet is a collection of standard-based extensions to Ethernet, while Fibre Channel over Ethernet is the simplest possible way to transport storage and data traffic on the same physical link. More specifically, FCoE is pure encapsulation of Fibre Channel into Ethernet packets and because of that, it does not change the existing management architectures.

Because of how these fundamental elements of Unified Fabric have been designed and implemented, it will be possible for an IT organization to leverage the benefits of Unified Fabric while continuing to operate in the very same way they are operating today (storage admin manages storage, network admin manages the network.)

Technology is important, but it will fail if it does not take into account the impact on people. With the Unified Fabric, this was part of the design.

Posted by Dante Malagrino at 08:56 PM Permalink | Comments (0) | TrackBacks (0)

Securing Data at Rest

This week brought a couple of important announcments from HP and EMC supporting Cisco's Storage Media Encryption (SME) technology.

http://www.byteandswitch.com/document.asp?doc_id=150282&WT.svl=news2_1

http://www.byteandswitch.com/document.asp?doc_id=124653

Of course there are many existing approaches to encrypting data at rest. Many tape drive vendors offer this capability and there are appliance vendors that do the same. But just like other intelligent storage services that once resided on a host, an appliance, or a target device, encryption services will likely migrate to the network.

Services such as SAN routing, SAN extension, and Storage Virtualization are increasingly being deployed in the network fabric eliminating the need to support multiple devices and multiple administrative models. Fewer devices also mean lower power consumption.

Encrypting data at rest should be no different. Leveraging the MDS 9222i or the 18/4-port Multiservice Module (MSM) on the MDS 9500 Director, SAN administrators can deploy a non-disruptive, heterogenous solution that scales with increasing network speeds.

What do you think? Where should encryption services typically be placed in a SAN? Should the network fabric provide this service or should customers continue to deploy multiple appliances to deliver the same solution?

Posted by Deepak Munjal at 08:46 AM Permalink | Comments (0) | TrackBacks (0)

March 27, 2008

FCoE, FibreChannel, Ethernet, Eagles, and Parrots

I had a discussion with some folks today who told me that customers wondered what Cisco's position on FibreChannel was. One of our FC competitors was telling them that we are 'getting rid of' the Cisco MDS 9500 Storage Director in favor of the Nexus 7000, etc. I am reminded again of another of my favorite Winston Churchill quotes (yes, am a fan and have a book of them)

"When the eagles are silent, the parrots begin to jabber"

(Sir WInston Churchill)

I guess it's time to 'chirp up' and silence the jabber.

FibreChannel is here to stay. I joked a little in my last entry about some of the things that existed in 1998. I can guarantee 10 years from now FibreChannel will still exist, and still be deployed actively in our customers networks. It's a good protocol, it works, it works well, and it will continue to solve some network problems that even by that time I do not think Ethernet and FCoE will have evolved to deliver.

Additionally, newsflash for some companies here, customers that I have talked to really don't like changing their network equipment out every 2-3 years, most like equipment that 'has legs'. (longer ones than a parrot does btw)

FCoE will happen. Of this I am certain. But I also believe that the pragmatic adoption path of FCoE will be first on the host, then over a period of time switch to switch, and then eventually to the target. Why?

1) Hosts get churned faster than Targets
2) By running FCoE to the hosts more workload processing capability gets connected to the SAN. This means there is more data to protect and safeguard. This is GREAT for storage. The entire Storage market is predicated on 15-20% of the hosts connecting to the SAN. Fast-forward 3-5 years and imagine a world with 100% of the servers connected to the SAN. Pretty powerful!
3) Existing SAN services that Cisco has integrated into the MDS like Storage Virtualization, Encryption of Data at Rest, and Data Migration can get applied against all the corporate data in the FC SAN.
4) For Cisco customers, uniquely, this lets their existing MDS infrastructures continue to soar and interconnect with FCoE for host-access to the SAN.
5) Cisco is continuing to invest in R&D for the MDS 9500 series, delivering on a strong roadmap of innovative products that continue to lead the market in services, stability, investment protection, etc. (Will we get to 8Gb and such? Certainly, the MDS is already shipping 10Gb, if you can do 10Gb, I assure you you can do 8Gb ;) But we felt it was also important to not require 'yet another director' to get there.

I hope this helps clarify where we see FC and FCoE.

Chirp ;)

Posted by Douglas Gourlay at 12:44 AM Permalink | Comments (0) | TrackBacks (0)

May 17, 2007

A lightbulb and a SAN Director - Can you tell the difference?

In the last two of days I have received more than a couple of emails (mostly from Cisco technical sales people) about some testing that our main storage networking competitor has done to show how the power consumption of our MDS 9500 director is higher than that of their current generation of products. Everybody was giving me tons of reasons why the comparison was not correct and how real life environment were different than the test set up.

I thought about posting a very long explanation of the fallacies of such a test with all of the technical details behind that, but then I realized that there may be an easier way to explain.

I am in the midst of a small home remodeling project and I have to make a couple of decisions on lighting for the backyard. Guess what? One of the key decisions is about choosing the light bulbs (it's a bit complicated as the types of lighting are varied).

I had the option of putting multiple small light bulbs in the back yard (they consume less power, don't they?) but that would be a less desirable choice. The efficiency of many small light bulbs is significantly lower than that of one large light bulb (which has been designed to light a broad space such as my back yard) and to get the same lighting power. To get the same light from multiple small bulbs distributed around the yard I would have had to consume much more power overall. Also, with many small light bulbs distributed around the yard, I would need to pull wires all around the yard to make sure that there is enough light in each corner, which creates another set of issues (installing and protecting the wiring infrastructure, etc). And I could go on forever on why this is wrong, but I think you have got the point by now.

I am not going to make the story too long and we can certainly continue this discussion in the post session with more technically accurate arguments, but I hope this example makes the point.

Can you tell the difference between a SAN Director and a light bulb now?

Posted by Dante Malagrino at 06:50 AM Permalink | Comments (3) | TrackBacks (0)

March 30, 2007

Is The Fibre Channel Killer Born, yet?

There has been a lot of discussion on various online forums lately about the future of Fibre Channel. The piece that probably got the attention of most of us was the extremely well-written article published by Deni Connor on Network World.

I have waited a few days before posting anything as Cisco clearly has a significant stake in Fibre Channel as well as iSCSI and Ethernet technologies for the Data Center in general, not to mention our solutions for InfiniBand switching (all right, this is the last piece of sales on this posting!)

The life or death of Fibre Channel is clearly something we care about.

Aside from emotions or personal preferences, I think nobody can argue with the fact that Fibre Channel is alive and kicking. The Fibre Channel market continues to grow and all of the major players in this market (including Cisco) continue to invest aggressively in Fibre Channel R&D and sales. And this is not because we want it, but because we see a lot of demand for it. iSCSI is a valid alternative to Fibre Channel in certain environments, but it still does not represent a perfect replacement for Fibre Channel for every possible application. In theory everything you can do with Fibre Channel, can also be done with iSCSI (and InfiniBand and who knows what else,) but the problem here is not theory, it's the reality of how people use these protocols as well as the actual products and solutions that the storage industry has for customers who are building Data Centers and storage area networks today.

The question to answer is not so much whether Fibre Channel is dead or alive today, but what is going to be its future?

And the future of Fibre Channel is not solely related to the future of storage, but it is really a bigger and broader issue of how transport technologies in the Data Center will evolve. It's a given that three protocol stacks are too many for a room as big (or as small) as a Data Center. Nonetheless, neither Ethernet nor Fibre Channel nor InfiniBand in their current incarnations can seriously represent a unified transport option for the Data Center.

My opinion is that Data Center transports will converge and at that point Fibre Channel will probably be dead as well as Ethernet and InfiniBand (at least in the way we know them today) and something new will replace them and enable a simpler and more efficient connectivity of devices within the Data Center. But this is not something that happens overnight and it will probably be an evolution and not a revolution. Fibre Channel will have to agonize for quite a long time and it will not die of sudden death. As of today, I can't see any clear signs of illness, yet.

In a nutshell, death is unavoidable for protocols and technologies as well as for anything else we know, but I am not convinced that the Fibre Channel killer will be iSCSI. So the right question to answer should probably be: "Is the Fibre Channel killer born, yet?"

Posted by Dante Malagrino at 08:54 AM Permalink | Comments (4) | TrackBacks (0)

February 05, 2007

Ethernet over Barbed Wire, Arcnet, 100MB Token Ring, 100Base-VGAnylan and iSCSI …

I do about 5 executive briefing center visits a week discussing Cisco’s data center strategy. I have a beautiful slide deck highlighting the advantages of Cisco’s end-to-end data center strategy; the builds and animation are fantastic, the graphics superb, and of course my oratory is reminiscent of Lincoln’s Gettysburg address . However, inevitably I get asked a question on Cisco’s commitment to the data center and in particular., for some odd reason, our commitment to FibreChannel.

While I believe that most of this may come from competitive FUD, some of it probably arises from Cisco’s initial foray and positioning into the storage I/O market. You see, before Cisco entered into the Fibre Channel switching business, Cisco had a pretty strong position on iSCSI taking over the storage I/O business. This was not quite the Voice will be Free proclamation but certainly we had our own dogma about the direction of storage I/O. We purchased an ip storage company, co-authored the iSCSI specification and set forth to conquer the storage networking market.
As we all know, the adoption curve of iSCSI in the storage networking industry has had a much shallower ramp than was initially predicted and since then Cisco has successfully entered into the Fibrechannel storage networking market. What we learned from this experience is to rely on a Cisco strength -- to be transport agnostic -- and let the market place and our customers drive our technology focus and investment. Cisco made its name based upon providing solutions that interconnected networks over disparate technologies. This brings me to the headline of this blog. At various times Cisco has deployed or demonstrated a variety of technologies that didn’t quite pan out from a customer or market deployment model. We demonstrated Ethernet over Barbed wire (great for war zones or cattle ranches), sold lots of products with Arcnet, contemplated 100Mb Token Ring and, my favorite, developed router interfaces for 100Base-VGAnylan.
So when a customer asks me about our commitment to Fibrechannel, I say that we are as committed to Fibrechannel as long as the storage market and customers demand networked Fibrechannel connectivity. This philosophy of being transport agnostic is reflected in our current networking portfolio in the Data Center, where Cisco offers Ethernet, FibreChannel and Infiniband solutions. Ultimately the market will decide which technology (or future technology) becomes dominant.

Now can someone tell me whether I should buy a Blue Ray or HD DVD player?

Ed Chapman

Posted by Ed Chapman at 07:00 AM Permalink | Comments (0) | TrackBacks (0)

January 22, 2007

The “Power” of a SAN Switch

I was in a meeting with several individuals from a large enterprise customer in Europe a few days ago and while presenting our strategy and vision for the Data Center, one of the people in the room interrupted me (quite abruptly, I might add) and he said something that could be paraphrased like this:

“OK, I got all that stuff, but I have to make a decision by next month about upgrading my Storage Area Network and you are not helping me here. I am talking about real stuff, not the marketing fluff you are giving me and Cisco has not yet explained why I should consider your MDS directors vs. just keep going with my old stuff that works just fine, by the way!”

I wish I could have recorded the question exactly as he asked it, because that would probably give you a much better idea of how important making a business case for SAN migration was for him. I questioned him a bit more about migration and he explained that his boss (the CIO, who was in the room as well) asked him to look into Cisco to replace the existing environment (obviously the Cisco account team knew how to sell high) but he had not seen any good reasons to change the status quo yet.

I took a deep breadth and thought about how to answer that question. As good as it can possibly be, the marketing “story” was not going to make an impact quickly. The other challenge for me was that I could come up with a list of things -- having been on the MDS engineering side for quite a while -- that I could use to make strong arguments for making the move to Cisco, but I did not have the luxury of time or the audience's patience to go through all of them in detail. I only had one shot and I needed it to be the best one. With the little time I had, I decided to go for something that is very “trendy” amongst Data Center managers these days: “power efficiency”. In support of the meeting, I had brought a copy of a recent report that has just been published by the Enterprise Strategy Group (ESG) on “Building Power Efficient Solutions With Cisco MDS 9000 Directors.” This report essentially demonstrates (through actual testing) how you can run more energy efficient storage networks if you leverage some unique features of the MDS like Virtual SANs and InterVSAN routing.

I handed the ESG report to the guy and there was silence for a few seconds while he went through the document (I could tell he was just looking at the graphs, not reading the content) and I was sipping some much needed water. At the end he broke the silence and said:

“I am seeing this for the first time right now and of course I would need to read it through, but it is definitely one of the things we have been considering more and more recently. We are so concerned about our power bills that we have almost considered acquiring the energy company. It might be cheaper!”

His joke (was it a joke?) made me feel better since I knew this issue addressed a critical factor for his SAN environment and migration considerations. Though his answer was not a “Yes, I will buy your MDS directors today!” it was still a good answer for me. Amongst all the topics to highlight quickly, I knew that addressing power & cooling demands was one of the best arguments to use. I was not trying to sell him on features and gadgets; I was giving him something that was important to him and would make made him look prepared when he returned to the table to discuss with his CIO.

There were several brochures and documents and notes that were left lying in the room at the end of that customer’s visit, but no sign of the ESG report…

Posted by Dante Malagrino at 08:10 AM Permalink | Comments (3) | TrackBacks (0)