DC Architectures Category Archives
May 09, 2008
Our 101st Entry... and cool stuff I saw
This marks our 101st blog entry on the Cisco Data Center Blog. Starting back about a year or so ago with my first inaugural real post called The Fallacy of Wire Rate Switching (still one of my faves) to today when I just wanted to mention some neat companies and technologies I have seen recently:
I was at Interop the other week and caught up with some old friends and new and saw what they were up to. A few, in no order, that I personally thought were intriguing:
1) Rohati. Rohati was not exhibiting but I caught up with some good friends who started this firm and they have a very interesting approach to network services and security. It's one of those 'Why didn't I think of that!' type of products that I think when they publicly announce will be well received.
2) Compellent. Compellent makes storage arrays with integrated virtualization capabilities. I was impressed here with the ease of use they were bringing to what normally is complex and management intensive (Information Lifecycle Management, automatic block data movements to streamline drive head read/write operations, and tiered storage) They were not in my favorite booth (i.e. not ours :) but I was impressed with the knowledge their team had of their products and if someone could explain ILM to me in a few seconds and demonstrate the setup/operations with ease that goes a long way in todays compelx world.
3) Splunk. A pretty unique approach to network management and fault isolation and discovery. I like seeing innovation and think the NMS space has huge opportunities for improvement and value creation, there is a neat and novel approach here that can really help.
dg
Posted by Douglas Gourlay at 11:00 AM Permalink | Comments (1) | TrackBacks (0)
May 04, 2008
Power, Pickups and Polar Bears
Dave Ohara recently posted on his Green Data Center Blog about the efforts of network vendors to help the greening of the data center. I am still not sure we are having the right conversation around this topic, but at least we are having the conversation.
Let me give you an example. Let’s compare a Ford Focus and a Ford F-150 pickup. If we wanted to be “green”, looking at the brochures for both vehicles, the fuel economy of the Focus would be a no-brainer (35 hwy vs. 20 hwy for the F-150). But, what if we wanted to actually “do” something with our vehicle? Since I was working on the yard today, let’s say we wanted to haul 2 yards of mulch. Our F-150, with 55 cubic feet of hauling capacity can do this in one trip, while the Focus, with slightly under 14 cubic feet of cargo capacity would take four trips. So, even with the 75% better gas milage, the Focus is not automatically the right choice. The point is a simplistic one dimensional measure is not really all that meaningful. This is why a city bus can get 4 mpg and still be central a “green” strategy. The other point is that we have multiple types vehicles for a reason--so if I were a landscaper, I may drive my F-150 during the week and drive my Focus when I go tooling in Napa for the weekend. The goal is to derive the maximum value for the energy consumed, regardless of if its vehicles or data center switches.
The topic of relevant metrics brings us back to something Dave mentions in his blog: Nortel’s claims that their 45xxT switch consumes 56% less power than an “equivalent” Cisco Catalyst 3750G switch (for the sake of argument, I’ll work with the comparisons that Nortel picked). There is some confusion in the Nortel positioning paper, since the switch model and power consumption noted in the text is different than the model and power consumption noted in the table the text refers to, but I digress. The salient point is that these power values are for two switches plugged-in and idling with no connections--the assertion is that if there is such a discrepancy at idle, imagine what happens when we actually forward packets. Before I go on, a note to those of you with data centers: if you have switches in your data center that are plugged in and not doing anything, please unplug them now--it will help you with power/cooling and the polar bears will thank you too. Now, for the rest of us with data center switches that forward packets, it might be useful to see what a switch does under load.
So, earlier this year, at our request, Miercom did an analysis of a number of switches under load to see what kind of power consumption you might actually encounter in your data center. It turns out the Cisco Catalyst 3750G consumes about 140-150W (depending on packet size and choice of copper or optical uplinks) when those uplinks are driven at 100%. This is inline with the 160W maximum draw noted on the data sheet. What does the Nortel 45xxT do under load? That information is not published anywhere I could find, but perhaps we can make an approximation based on a couple of data points we do have. First, the data sheet for the Nortel 4548GT notes a maximum draw of 150W, so unless Nortel is into really over-engineering their power supplies, that is probably a fair indicator of real-world draw at max load. Second, Miercom did test the Nortel 5510 as part of the testing mentioned earlier and they found that switch drew about 125-130W at 100% uplink load against a maximum draw of 135W in the Nortel 5510 data sheet, so there does not seem to be any revolutionary power management technology at work. Third, the notes from Miercom indicate between a nominal 5% load and a 100% load, the power draw grew proportionally regardless of vendor tested. So, I think it is reasonable to deduce that the Nortel 45xxT is in the same neighborhood as the Cisco Catalyst 3750G when used to actually forward packets. Sidebar: Miercom just announced that the Cisco Catalyst 3750-E, 3560-E, 3750, 3560, and 2960 Series Switches are the first products certified in their “Certified Green” certification program.
Later in the same position paper, Nortel asserts their ERS 8610 offers energy savings of 60% over a “6500 equivalent”. There is not a lot of detail to the comparison, although there is a footnote that states “Unless noted, all product comparisons are based on vendor published maximum power ratings.”, so this seems a comparison of power supplies, not actual draw. Again, this becomes a Focus vs F-150 comparison--what exactly are we comparing and in what context--I could dig into this but I think you get the point.
I guess the moral of the story here is, when it comes to energy efficiency, there is, sadly, no one magic metric to measure goodness. Its a design function like anything else in the data center and its a matter of doing research and balancing the design parameters. Our goal is, simply, to help you make an informed decision. To that end, we have the Power Calculator to give you configuration-specific load numbers for our equipment. We then take it a step further with our Data Center Assurance Program tool on our data center design best practices website, which includes power consumption information as part of its guidance. Check them both out (you will need a cisco.com account).
Posted by Omar Sultan at 10:23 PM Permalink | Comments (0) | TrackBacks (0)
May 02, 2008
So what's a cloud....
Cloud Computing Circa 1998
Networks have historically been depicted as clouds. Why? I always wondered that. Most likely because it was an easy way to depict something ubiquitous (clouds are pretty much everywhere), something nebulous (because its form and shape changes as nodes are added and/or removed), and something powerful (clouds can become storms).
So when the term 'Cloud Computing' starts its journey skyward on the Space Shuttle named 'Hype' is what we are really talking about 'Network Computing'??? It could probably have been called that except the editorial staff at the publication by the same name would have had a few issues so to speak.
Cloud Computing = Network Computing
I think that we are a point in time where the economics and dynamics of this space are in need of a major overhaul. To effect that overhaul we need to take the economics of a network, i.e. super-linearity of value based on number of nodes connected and apply it to not just the connectivity, but to the end-to-end processing of workload, storing the results of that processing, and communicating it to other processing nodes and end users.
We are past the point where individual point solutions will suffice and charging headlong into a world where the lines get blurred. One where we don't brag about how many servers we have, but instead about how efficiently we manage them, where storage virtualization is de rigeur, not the exception, and as always the network continues to connect everything. In this world of applications becoming more network-centric and network dependent than ever we shouldn't take the abject usability of the network for granted. As my good friend Peter Linkin relayed to me today, there is a lot of engineering that goes into protocols, hardware, and software for networking and just because it works well, efficiently, and the better it works the less you care about it doesn't mean it is not critical.
I love the idea of cloud computing, the next evolution of the most network intensive architecture possible, but one that if it works well, is transparent. It's all about the transparency.
To quote the Rolling Stones, and the inimitable Mick Jagger, "Hey, Hey You, Get Off of My Cloud..." :)
dg
Posted by Douglas Gourlay at 02:14 PM Permalink | Comments (1) | TrackBacks (0)
April 21, 2008
20/20 Blogging
I just read John Rath's recent post on Data Center Links about Cisco's Data Center Vision. It really reaffirms something for me that I was sitting with some of our key data center leadership discussing today, and that is that blogging just plain works. We get feedback, broadly, in minutes and days that would takes months with 'focus groups' and other traditional marketing machinations. We hear from our customers, our partners, our competitors, and we learn what works and what doesn't- rapidly. I love it.
There has been a veritable furor and at least heart-pounding discussion on the merits of FCoE, iSCSI, FCIP, and many other acronyms. Can you imagine the T-shirt? "CISCO NEXUS: My Acronyms are better than your Acronyms! "
What our vision comes down to in the end is a simple statement: "Any application, any workload, any server, anywhere, in seconds, configured in software. "
It's a complimentary vision to many of our top-tier partners. It's one that challenges many niche companies. It's one the solves many customer challenges. It's a vision that w feel we can deliver, and we're on the trajectory to make more and more of it into a reality this year and over the next few.
dg
Posted by Douglas Gourlay at 03:23 PM Permalink | Comments (0) | TrackBacks (0)
April 09, 2008
Fibre Channel Over Ethernet: Where to Learn More?
This morning I spent some time with a collegue and friend of mine, who I deeply respect for his technical knowledge and, of course, we were discussing some of the elements of the Nexus 5000 launch that happened yesterday.
He asked me a few questions, which made me realize that we will need to do a lot of work over the next couple of months to make sure that everyone, who is involved with Data Centers, has an opportunity to learn more.
Hence, I decided to begin that process by sharing some hopefully useful tips with all of you.
To avoid building too long of a list, here are the places where I would start:
Silvano Gai has also recently written a book on Data Center Networks and Fibre Channel over Ethernet, which will be available sometime next week and as soon as that happens I will let you all know.
If you visit the FCoE.com website, do not miss the CNBC video. I love it!
Posted by Dante Malagrino at 01:12 PM Permalink | Comments (0) | TrackBacks (0)
April 08, 2008
Would you like to be the first one to hear about Cisco Data Center announcement today?
If you do, you may want to check the Cisco News Conference Live Webcast today.
Post your feedback on this blog and let's talk more about it this week.
-- Dante
Posted by Dante Malagrino at 09:15 AM Permalink | Comments (0) | TrackBacks (0)
April 07, 2008
Unified Fabric - a Myth or a Reality?
The topic of “a unified fabric” has recently been generating some buzz in the blogosphere, with both advocates and skeptics weighing in. I actually think the question of “Myth or Reality” has been answered. We currently have customers that use both InfiniBand and iSCSI to create a unified fabric and each technology has staunch supporters. So, I think we are past the question of "if" and on to the question of “when?”
So. what are the current inhibitors for broad-based adoption of a unified fabric?
Off the top of my head, I can think of a couple of points to consider:
- Architectural Intertia:There needs to be some compelling reason to change--cost, performance, features, etc
- Investment Protection: related to inertia, there needs to be a compelling reason to abandon infrastructure that is has been bought and paid for, especially if it is working well
- Operational Characteristics: unified fabric is not just an exercise in payload encapsulation, but in maintaining the correct operational characteristics, such as Fibre Channel’s losslessness
- Operations and Management Disruption: what is the learning curve for new technologies--how disruptive will they be to existing design and operations best practices
So, what do you think--in the next three years, do you see yourself considering or deploying a unified data center fabric? Why or why not?
Posted by Omar Sultan at 07:49 PM Permalink | Comments (4) | TrackBacks (0)
March 18, 2008
Data Centers Down Under
On a plane flying to Sydney to start a week long Asia Pacific Tour. Will be meeting with customers across a few parts of Asia and rushing home to paint Easter Eggs, hide them, and then wonder oddly enough a few days later where that interesting sulphur-like smell is coming from.
This week I am going to try something new for me. Yes, I know, I am years behind on technology and using the web, but am going to try to do a few video blogs of the different data centers we may see, if their are architectural differences 'Down Under', does airflow work differently in Australia? i.e. does hot air fall and cold air rise?
What will be different about data centes in APAC? Same cooling and power challenges as in the US? Will the power infrastructure be leaning toward 'dark green' i.e. sustainable, renewable, and non carbon emitting sources? Will the availability of bandiwdth have a different end-user expectation on service delivery? Can a global corporation truly effectively support their APAC employee base from centralized US data centers or are their regulatory issues and bandwidth latency issues for certain applications that mandate local presence? These are some of the things I want to determine and learn about. Does anyone have any insight into this?
I've been to many APAC data centers and met with many customers over there and it strikes me as very similar in some countries and wildly different models in others. I know our local teams have a deep partnership with our customers in Asia and a long history of supporting their business, but are their macro level trends in Asia that are different than the rest of the world?
Posted by Douglas Gourlay at 05:50 PM Permalink | Comments (0) | TrackBacks (0)
February 14, 2008
FCoE Takes Next Step to Standards Completion
So the big news is that the FCoE standard continues to move forward by adopting a common addressing structure:
http://www.primenewswire.com/newsroom/news.html?d=136174
As soon as the release hit the wire, battle lines are being drawn. On one side, you have the Fibre Channel advocates supporting the standard but hedging their bets on how quickly it will be adopted. On the other side, you have the IP advocates who ask "Why can't we just go straight to iSCSI?"
An interesting discussion is taking place here.
The reality is probably somewhere in between. The fact of the matter is that customers have invested a lot of money and time into their Fiber Channel infrastructure and they are not about to rip it out anytime soon. FCoE gives them a migration path that gets them immediate benefits of convergence while preserving their investment in hardware, applications, and processes.
No one is saying that iSCSI isn't a good idea for convergence in the data center. For many who haven't invested in Fibre Channel SANs like small and medium businesses, it's an ideal solution.
But asking a storage administrator who has been running Fibre Channel SANs for years to throw it all away and start deploying iSCSI SANs is not realistic. It will probably be simpler to upgrade the Ethernet infrastructure to support Fibre Channel through FCoE than it would be to deploy a new iSCSI SAN and assess its impact on performance, availability, and management.
Posted by Deepak Munjal at 12:50 PM Permalink | Comments (4) | TrackBacks (0)
February 04, 2008
Containing IT
James Staten from Forrester writes a very good article today at http://blogs.forrester.com/it_infrastructure/2008/02/how-big-is-your.html that talks about the high potential value of a containerized approach to IT in large megacenters. Let's start for example with a 2.5 to 5.0 MegaWatt containment unit with all cooling, power, compute, memory, and storage in there for the execution of a given amount of workload. There would be some central shared services: DNS, Central Storage, ILM, Backup, etc...
It does change the economics and the architectures. I am not sure where the right starting point is: I would imagine though if I was deploying 30MW Data Centers it is something I would look at. I was doing some calculations, back of envelope type stuff, and figuring out how we could design the optimum network for this container: one that balances power efficiency, ability to connect as many hosts as possible, and offers ubiquitous service interconnect with the global shared services.
I do think it is possible to get thousands of servers into one container, and then connect them all with 10Gb or 1/10Gb for less than 7% of the power budget. There are many ways to skin this cat though and I may have to spend some time on a whiteboard, spreadsheet, and with lots of little icons on PPT to get a few details worked out.
What do you all think of the concept of containerized data centers making their way into the core enterprise?
dg
Posted by Douglas Gourlay at 12:35 PM Permalink | Comments (1) | TrackBacks (0)
January 04, 2008
Virtual Switching in the Data Center
Heard of Virtual Switching System on the Catalyst 6500 yet? This is something that was recently tested by David Newman over at Network World, and is linked here.
I am quite excited about VSS- it is a technology that fundamentally changes the way we build data centers, period. Sure the performance is nice, but the real benefit is twofold:
1) No Spanning Tree Loops are manually created in order to effect redundant paths. No blocked links, all active, and the failover times get cut by up to 95%. As much as it upsets my friends in IEEE 802.1 I would rather design Spanning Tree OUT of my network than have it IN my network with artificial loops.
2) Reduced IP routing complexity. If every Aggregation pair of switches represents themselves to the core as one device this reduces EIGRP and/or OSPF routing topology complexity by 50%. Less devices means a smaller routing table, simpler topology, and still blazing fast failover speeds, that are actually quicker than what we had with just L3 Routing.
I wanted to extend a special thanks to the small and tight-knit group of Engineers and PM's who made this concept a reality, thanks team. This is going to change the way people design networks, simplifying them, and making them more resilient than ever.
dg
Posted by Douglas Gourlay at 11:47 AM Permalink | Comments (0) | TrackBacks (0)
A New Years Challenge...
Happy New Year to everyone! Am sitting here in not-so-sunny Northern California watching storm after storm hit and it had me wondering about Disaster Recovery a bit. I love the fact that networks connect things and that distance = options where DR is concerned.
How far apart should data centers be? How far do you usually deploy them? We all understand the issues related to SCSI timeouts and synchronous replication of storage that gates teh maximum distance for synchronous replication to the 100-200km range depending on your application.
Is it easible that companies will tier applications and dynamically move their primary execution location based on pending known natural disasters?
Is it feasible that a brownout scenario or possibility of rolling-blackouts on the power grid would be a reasonable leading indicator to trigger the movement of compute and storage resources from one location to another?
What are the other challenges that you are encountering? Are their organizational barriers to this or is DR so ingrained now that it is purely an execution issue?
dg
Posted by Douglas Gourlay at 11:38 AM Permalink | Comments (0) | TrackBacks (0)
September 23, 2007
A Unified Fabric for the Data Center?
The holy grail of data center networking has been discussed for a number of years and many have attempted to design a single technology to deliver on all of the networking requirements of data center applications. The design goal is reasonably simple: design a single data center transport that can simultaneously transmit IP and Fibre Channel traffic over a single connection. The problem is, it just isn't that simple. Data center managers expect that the transport must include sophisticated management capabilities to enable accurate depiction of what is happening within the fabric; the fabric must offer high performance and low latency, robust security; the fabric must not - absolutely ever - drop a single storage frame. Oh, and it must be able to scale to thousands – if not tens of thousands - of devices, support 10/100/1000 and 10GE attached servers, support legacy applications, be virtualizable, enable efficient utilization of IT assets, and reduce power and cooling overhead. If it can make coffee, that's a bonus. OK, the last one is a stretch, but you get the point.
It can be seen that although a number of technologies exist that could potentially address the needs of a Unified Fabric, most technologies require significant development to fully address the requirements listed above. If we take InfiniBand as an example, although it has the right performance characteristics, offers IP and Fibre Channel communications over a single interface and reduces power and cooling overhead by reducing the number of interfaces and fabric connections required to support a server, it lacks the scaling, embedded services and management capabilities that data center managers have come to expect from their Ethernet and Fibre Channel infrastructure. It also introduces one significant issue: certification against existing hardware, operating systems and applications. This latter point should not be under-estimated because even if IP-over-InfiniBand is used, hardware and software driver certification can be time consuming, costly and introduces additional complexity. To a certain extent these factors have limited adoption of the technology to high-performance computing clusters and high-performance systems such as those found on Wall Street.
One technology does however offer the promise of delivering on the promise of Unified Fabric: Ethernet. Ethernet has proven to be a survivor. It has outlasted ATM, FDDI, 100BaseVG-ANYLAN and Token Ring. It has scaled from its humble origins of shared 10Mbps, to 10Mbps switched and then on to 100Mbps, 1Gbps and 10Gbps - with 40Gbps and 100Gbps promised in the near future - without changing the frame format. Ethernet management has also evolved such that DC managers can extract information regarding traffic conditions on the network - down to individual packets if required - that assist in troubleshooting, performance monitoring, and forensic analysis. These attributes have made Ethernet the de-facto standard for the vast majority of networked devices - refrigerators and electric guitars are now available with Ethernet connections.
So, where do we go from here? There is a lot of effort going into a proposal called FCoE (Fiber Channel over Ethernet). The protocol draft (more at http://www.fcoe.com) describes a method to encapsulate a Fibre Channel frame in a regular Ethernet frame and it looks like it has wide industry support.
Certainly, this seems like an appropriate approach to solve the unification problem but this is not the first time the industry has tried to converge storage and data traffic over a single fabric. The iSCSI protocol has been around for some time but with limited success. Adoption does seem to be increasing but Fibre Channel advocates doubt its ability to deliver the performance and reliability of Fibre Channel SANs.
Are there other methods worth exploring? Is it even worth focusing so much effort on solving this problem? As one of my colleagues joked recently, "You can run fresh water and sewage in the same pipe, but why would you want to?" That might be a bit harsh but convergence of data center network fabrics would most likely lead to lower overall operational costs similar to the benefits achieved with the convergence of voice and data networks. For now, it looks like this journey will continue.
Posted by Deepak Munjal at 04:29 PM Permalink | Comments (2) | TrackBacks (0)
June 11, 2007
How will applications evolve?
When I think about Cisco and what our routers and switches and such enabled over the past 20 years I sort of home in on the Internet. It's this massive network of devices, all running consistent protocols, working together to forward data to the right destination, with the appropriate autonomy in place to allow for organic growth without stepping on too many of each others toes. As I add a router or network to the Internet the whole Internet gets more valuable (assuming I am not adding a bot-net or something of that ilk).
If I can add a router to a network and it dynamically learns its neighbors, learns what they can and cannot do, i.e. their capabilities, then automatically adapts it's own view of the world and it's own capabiltities to take advantage of what its neighbors know - why can't we do the same with services, applications, etc?
For instance- I am writing this from my Macintosh right now running Parallels with a Corporate IT image of Windows XP on Parallels on top of my Mac OS-X. I do this primarily so I can run Outlook. (I find the Entourage version inadequate for corporate daily use) In my Outlook configuration I had to statically enter the MS Exchange Server that I use. In the Exchange Server configuration it statically encodes the storage system it uses as well as the upstream MTAs it talks to. From there mail routing gets marginally more dynamic.
Why is this the case? Why doesn't my Outlook determine the closest most available Exchange Server that has access to the SAN with access to the volume housing my mail store? Why doesn't Exchange dynamically learn what mail stores are available on the SAN? Why doesn't Exchange then determine the closest, most available, MTA with the capacity to deliver the message being sent? Am not picking on Exchange because about every other application deployed in an Enterprise from Middleware to Databases to even our own Network Management and other software applications falls into the same bucket.
It strikes me that there are a lot of lessons we learned over the past several decades in how to build large and dynamically constructed networks can be applied to building large and dynamically constructed application networks. We seem to focus in on 'put a Load Balancer here, put a Firewall there' and not always on how to solve this next and somewhat higher-order problem...
Do you think Applications and Networks could ever share a common topology view of the world? That applications could talk to their default gateway routers and switches and learn what other applications and services are available? That app to app discovery and communication could be as dynamic as OSPF or BGP?
dg
Posted by Douglas Gourlay at 10:12 AM Permalink | Comments (1) | TrackBacks (0)
April 05, 2007
Can you stick a Data Center in a box?
A couple of companies have recently come out with the proposal to squeeze Data Centers in a "box" (it's a box as big as a container, but the concept is no different.) As much as I appreciate the end goal of simplifying DC deployments and management, I am not quite sure that is the right way to go,... yet.
My first reaction to Sun's introduction of the BlackBox project was that it was a nice proof of concept, but not really something an enterprise could use today. But I did not discount Sun's proposal as Sun is a company that has been historically capable of being a few years ahead of the market. And when I say ahead of the market, I do not just mean ahead of the competition, but also ahead of customers and their ability to understand, purchase and use their products. I was thus very intrigued to see their announcement of Project BlackBox last fall, but I was not really convinced that customers would buy into that so easily.
Today, I saw the announcement that Rackable Systems is doing something similar. Of course there are still little information about this, but I am not sure about how a Company that has built their reputation and market presence mostly on low-power server architectures will be able to deliver on something so much bigger as an entire Data Center in a box, where you also have storage, networks, security services, scalability services, application optimization,...
This topic was recently discussed on ZDNet with rumors that Microsoft may be an early adopter of portable Data Centers:
Portable data centers: Will Microsoft prime the demand pump? by ZDNet's Larry Dignan -- Microsoft may be giving the nascent portable data center market a lift. Data Center Knowledge via Slashdot connects a few dots–including a some from ZDNet's Mary Jo Foley–to conclude that Microsoft may be an early adopter of the portable data centers championed by Sun (right), Rackable and others. These data center in a box concepts have [...]
Anyway, my point here is not so much to critique or applaud either Sun or Rackable, but really to ask my fellow bloggers their opinion on whether or not we are ready to put DCs in a box. I think it's clear that I am personally not convinced, but before telling you why, I will probably wait to see if anybody cares enough about this to even post a comment and then I will tell you more about my thoughts...
A wonderful and peaceful Spring break to all of the readers!
Posted by Dante Malagrino at 07:37 AM Permalink | Comments (4) | 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)
March 10, 2007
Rack Switching or End of Row???
I just finished making a few slides comparing switching architectures in the data center on the LAN side. (as much as I love the SAN side let's leave it out of this discourse for a few minutes). The architectures we deploy when aggregating switches or when building a DC Core network seem pretty consistent. Most customers use a modular and highly available platform for these functions (I think, feel free to disagree).
However in the server access layer there are three or three-and-a-half predominant designs I see within the data center architecture.
1) When aggregating servers larger than 1RU or servers with a mixed amount of interface types and densities I often see an end-of-row design employed with a larger modular switch (Cat6500) or two deployed there to aggregate the servers. (Do you usually use one or two switches to aggregate them???)
2) When I have 1RU servers stacked 40 high in a rack one or two 1RU Rack Switches (like the Catalyst 4948-10G) is often used to aggregate all of these servers with Gigabit Ethernet and then run a couple 10GbE links back to the aggregation switches.
3) When using blades most customers seem to deploy blade switches. These are suualyl home-run back into the agregation tier since it is quite hard to fit more than 2-3 Blade server chassis into a rack because of thermal constraints.
3.5) Had to have my half... :) I have seen one other design deployed in larger data centers using the pass-thru module or sometimes even the blade-switch where it is aggregated into a series of rack switches. The main reason is so that the rack is a compute entity of its own accord, can be rolled in, wheels locked, powered up, and two-four fibers plugged in and its online. It really optimizes for ease-of-deployment in large-scale facilities. But at a cost trade-off.
Some questions I have-
a) How will 10GbE Servers be connected into the network? Straight into the Aggregation switches? End of Row Switches?
b) Are there other designs and architectures that you commonly see used?
Thanks!
dg
Posted by Douglas Gourlay at 10:30 AM Permalink | Comments (3) | TrackBacks (0)
February 23, 2007
What is a Data Center?
This is a question I keep getting again and again. Everyone seems to have a different answer and I would be really interested to see what other answers there are out there. Let's take this as one cut at a definition and please feel free to offer other options or cuts at it-
"A Data Center is where an organization runs its mission critical applications."
I have heard definitions based on power draw, ones based on raised floor, ones based on the presence of a storage network, etc. These usually seem to come from people who are responsible for those particular technology silos. What I like about the above is it allows an organization of any size to define its own DC large or small that is relevant to them. From there they can apply the set of technologies as necessary to solve the business problems they have: whether operational cost reductions, organizational alignment, capital asset utilization, power and cooling reduction, increasing or more efficiently using compute capacity, etc.
What other definitions should we use? Are there other ones out there that are relevant?
dg
Posted by Douglas Gourlay at 04:41 PM Permalink | Comments (5) | 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
Welcome to the First Cisco Data Center Networks Blog Entry
This is the inaugural posting on the Cisco Data Center Networks blog and, needless to say, I am much honored to be the one who writes it. Nonetheless, I would love this posting to be remembered as the one that started a series of useful and important discussions between Data Center experts (users, developers, marketers, journalists, analysts,…) rather than just the first one!
As a blogger I have always found that long, content-free, “make-everybody-happy” postings are terribly boring and end up with no comments since very few people read them and everybody hopes they get archived soon because superficial entries use (or better said abuse) bandwidth and precious time.
Everybody seems to agree that good blog postings should be concise, to the point and maybe controversial enough for people to get interested and willing to contribute to the discussion.
That’s easy to say when you are not the one having to write them! And how do you do all that when you are asked to post on your Company’s website and you want to keep your job?
I do not have the perfect answer (if anybody does, please, email me at dantem@cisco.com,) but all I can do is take my Cisco hat off when I post on the blog and (at the risk of finishing both my professional and blog career very soon) offer to the reader my personal view of what’s happening in the Data Center. Granted that is somewhat biased by the Kool-Aid I drink and it will be an opinion to be supported or challenged, but there the ownership is on the readers to keep me honest. Please, do it!
Now, as I said before, good blog postings should be concise and to the point. I think I have made my point, so I should stop this first (and hopefully not last) post here and get on the next “powerful” one…
Posted by Dante Malagrino at 07:54 AM Permalink | Comments (0) | TrackBacks (1)
