February 26, 2008

Cisco & Microsoft: Optimizing the Branch Together

Some people make friends easily. Others find it a hard thing to do. Still more people are challenged to keep their friends over time.

Today Cisco and Microsoft announced that they're working hard to address some of the key IT challenges our most important friends have -- our customers. Specifically in this announcement, our mutual branch IT customers and their end users.

What did the companies announce?

Windows Server 2008 (specifically Windows Server 2008 Server Core), will be hosted on upcoming versions of virtualized Cisco WAAS appliances later this year.

What makes that so interesting to our customers?

Several things:

1) The ability to flexibly design branch office IT architectures to meet information and business requirements, while actively lowering management cycles and cost.

2) Reducing IT devices in the branch, while still delivering required end user experience and local services (can you say print server, DNS, DHCP?)

3) Leveraging the network, and the benefits of WAN optimization (Cisco WAAS) coupled with virtualization, to enable the ideal mix of local branch and centralized data center services. Selectable by the customer.

What are people saying about this?

Here's one point of view: http://www.informationweek.com/story/showArticle.jhtml?articleID=206900159

And here's another from Microsoft's Windows Server branch team, posted today: http://blogs.technet.com/windowsserver/archive/2008/02/26/check-out-the-latest-branch-solution-powered-by-windows-server-2008.aspx

What are Microsoft and Cisco execs saying about it? See them yourself in video: http://www.cisco.com/go/microsoftalliance

If you're in Los Angeles, CA tomorrow for the Microsoft Windows Server 2008 launch, or in another of the 250+ cities where events are occuring, you can see this for yourself: http://www.microsoft.com/heroeshappenhere/default.mspx.

We'd be keen to hear your thoughts on this integrated solution from Cisco and Microsoft, too. Send us a reply with your thoughts...

Mark Weiner

Marketing Director, Data Center Solutions

Posted by Mark Weiner at 06:30 PM Permalink | Comments (1) | TrackBacks (0)

The Role of the Network in the Data Center

I read a few days ago and commented back on Robin Bloor's blog about the role of the network in the data center. Robin has a very interesting opinion and we had a good dialog about how the role of the different devices in the data center are most likely to evolve. Take a read here.

Additionally this article was then followed up with a rather telling piece from Information Week linked in here.

Between these two, and I am sure a host of others I feel very confident re-affirming the statement I made in Robin's rather eloquent write-up.

You need servers, storage, and networks in order to process workload, store the results, and communicate it to another user, server, or application. A deficient infrastructure in any of them reduces the efficacy of all of them.

I always had this theory though - Whenever a network transport is faster than a server bus speed the peripheral connecting to that bus will go from a parallel connection to a serial one to a shared/packetized one.

Printers, Hard Drives, CPU-CPU Interconnect, and potentially even memory will follow this theorem. Thus over time all of the elements necessary to process an IT workload will be not only interconnected by a common fabric, but more importantly connected with a layer of abstraction (hypervisors anyone?) that will make any resource available to any workload at any time.

Posted by Douglas Gourlay at 02:55 PM Permalink | Comments (0) | TrackBacks (0)

TrustSec - Secret Weapon for Flattening Networks

Ever feel like Doctor Evil? You know those scenes where the 'secret weapon' is about to be revealed? Am a personal fan of Sharks with Laser Beams on their foreheads... but notwithstanding those are hard to get into the office on Tuesday afternoons I'll settle for today's secret weapon- Cisco TrustSec.

Colin McNamara did a quick write-up on his blog here. that talks a bit about how TrustSec works to provide a layer of abstraction between the users address and the users security policy. (editorial note: you can replace user with server, application, VM, etc)

Why is this important? Well remember the good ol' days? Not back so far as to when we walked along train-tracks with BB Guns whistling 'Stand By Me' but more the days when we used the 3rd Octet of the subnet to equal the VLAN number which in turn mapped to the HSRP group number and then mapped to the subinterface number in a classic campus design? Those days were simple! We didn't have 15-500 different groups of security with segmentation rights and per-user policy and such.

TrustSec helps us get back to that simple concept of building the network you need with the addressing structure you want, then overlaying hte right policy and segmentation implementation in a scalable and manageable way.

This means you can build a flatter network. One where we could all be on the same subnet, yet have differentiated policies. This then lends itself very easily to a world of VM portability where the security policy moves with the VM.

Thus, the secret weapon :) Thoughts? I'll be interested to hear the feedback as people 'cowboy up' and try this technology out in labs and such...

Posted by Douglas Gourlay at 01:20 PM Permalink | Comments (0) | TrackBacks (0)

February 21, 2008

Why You’ll Want This Switch, Part 2

So, if bigger/faster/denser is not the reason to drop a Nexus 7000 in your network, why is a compelling reason?

In my last post, I touched on NX-OS, as the foundation for many of the cool things the Cisco Nexus can do now and in the future. One of those areas is operational continuity. We have the component redundancy that’s table stakes in a next-gen platform with redundant power, fans, supervisors and fabric modules, but we wanted to raise the bar in terms of protecting the network services this platform delivers—what we call a zero service disruption architecture. We don’t just want highly available hardware; we want highly available network services, because that’s what really counts.

One design decision we made was to loosely couple the control plane and the data plane, so we can do things like in-service software upgrade without disrupting packet forwarding—we can even do firmware upgrades to the I/O modules without disrupting packet forwarding.

One of the cooler features on the Cisco Nexus is stateful process restart. With NX-OS, we can re-start individual processes in a way that maintains state data, so, for instance, if you need to restart spanning tree, the system will maintain state data, so you can avoid the resulting chaos of having to re-learn addresses and re-establish the topology. Along those same lines, the Cisco Nexus also has checkpoint/rollback functionality, so if you push out a change that does not work as expected, instead of having to troubleshoot it in real time, you can simply rollback to the previous working config.

Finally, from the Department of Attention to Detail, we even short-pinned the fabric modules (i.e. the input pins are shorter than the output pins). Why should you care? Well, in case someone accidently yanks out the wrong fabric module, the input pins will disengage first, to stop receiving new packets, and the fabric module is fast enough to empty before the output pins have disengaged. And the system will automatically adjust to the new fabric capacity and keep humming along.

So, there are just a few of my favorite features—things I wish I had when I ran data center networks. For more info, check out this whitepaper: http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9402/ps9512/White_Paper_Continuous_Operations_High_Availability.html

Posted by Omar Sultan at 04:26 PM Permalink | Comments (0) | TrackBacks (0)

February 20, 2008

Can we agree on how to measure performance?

Recently there was a posting from an irrationally exuberant vendor employee about the Nexus 7000. Brad Reese from Network World commented on it a bit here. While engaging in a bit of a written riposte it occurred to me that maybe we need some clearer idea, as an industry, on how to consistently measure performance.

I have heard for years of Cisco Math, Cabletron Math, etc... well, today, I would like to propose that maybe we can all find some way to agree on 'math'. After all, even though not that mathematically inclined I heard once that math is an absolute truth.

So here is my cut at 'the rules' for stating your bandwidth on a switch....

1) Do not double count per-slot bandwidth. i.e. if a slot has 40Gbs of bandwidth and can support 4x10GbE interfaces worth of traffic, then it is 40Gb of bandwidth. I agree that this is 40Gb IN and 40Gb OUT, but alas its still 40Gb.

2) Double-Count a switch fabric. i.e. a 10-slot chassis with 100Gb per slot to every slot with no blocking in the fabric would be a 2Tb switching fabric. I think that this double-counting here has meaning: it is the actual capacity of the fabric, and it does let the casual observer get an indication as to why then a 10-slot 2TB Modular switch is better than 10 separate 20-port 10GbE switches. (try building those 20-port configs into one multi-stage fabric offering 100 host facing 10GbE ports and you'll see what I am talking about....)

3) Don't separately count the local switching capacity on a line-card. Yes, most all switches nowadays that are modular have distributed forwarding in some form or fashion at the high-end. Don't go counting that too. That's like saying- "well, ya see... I have 10-slots in that there chassis. I have 10 10GbE ports on each line card and a 100Gb to the fabric. I can forward from port 1 to port 10 without crossing that fabric. So thus I have 400Gb fabric on each line card and a 2Tb main fabric. So I get 10 linecards at 400Gb each or 4Tb and a central 2Tb so I have a 6Tb switch." I don't do this, please don't also do this... it's just poor form... not to mention pretty incomprehensible to most customers...

4) Packet Per Second forwarding rates. Again, single count them. Just because the packet goes in and comes out of a forwarding engine (or the header does if its not an inline FE) doesn't mean you get to count it twice... If you can do wire-rate at 10GbE thats roughly 15Mpps @ 64byte frames. btw- a highly unrealistic model as I have never seen an all 64-byte frame data flow in any production network.

5) Aggregate PPS forwarding rates- if you have 100Mpps on each of 10 line cards then you can do up to 1000 Mpps or 1Bpps. Simple...

6) Fabric Redundancy- if your switch has all fabrics ACTIVE and all are utilized count both, or all 5 or all 8, etc. If there is a N+1 model or 1+1 model and the spare is NOT utilized unless there is an outage, don't count it. Be prepared to prove this btw as I see this one getting messed around with a lot... Also data sheets should state the performance of a single-fabric and of a fully loaded fabric.

7) Oversubscription- I like oversubscription personally. I find that it lets you increase density and balance density and performance with cost to maximize the number of devices connected to a single network node. But not withstanding the philosophy of oversubscription if you are purposefully oversubscribing something somewhere, i.e. you have a module that has 8 ports of 10GbE with a 40Gb Switch fabric connection, call that out in the data sheet. Call it: Fabric Interconnect speed or something. It's not a sin: it's a way to increase the ports and accepts the reality that not all ports are active at the same time. I would recommend vendors put the right counters in though so customers can know when oversubscription is failing them....

8) Lifecycle Capacity. Some switching platforms are designed with 'headroom'. i.e. You know you can add a higher performance switching fabric or forwarding engine in the future lifecycle of a platform. Since this is important for customers to know in order to make a longer term investment decision it should be annotated, based on the same ways of counting described above, but also flagged as something that the platform WILL deliver in its LIFETIME so it is understood as a future deliverable but one the vendor is guaranteeing their customers and potential customers that they will absolutely deliver.

Allright, I may come back and add some more thoughts to this today and tomorrow as they hit me. But does this make sense?

Posted by Douglas Gourlay at 05:01 AM Permalink | Comments (2) | TrackBacks (0)

February 18, 2008

An eloquent update on NX-OS

Michael Morris who is a frequent blogger on Network World's site just wrote this analysis of the NX-OS operating system. Michael's Article.

I agree with Michael about the VDC's and their role as one of the key differentiating technologies in the SW stack. What is neat to analyze is, "What does it take to do this?" i.e. if another company wanted to release this type of feature and technology into their product line what would it take? In business school they would call this "sustainable competitive advantage". Something every business wants to have :)

In order to build VDCs it would generally take a complete re-architecture and redesign of the entire software stack and operating system. Given NX-OS has 6 Million lines of code (I always picture Doctor Evil from Austin Powers with his pinky at the corner of his mouth when I say this...) this would be a 3-4 year project for almost any company. They would have to implement an OS with endian-independent code, modular processes, multi-threaded processes for scalability, and the software engineering diligence to develop the stateful process restart technologies. (the diligence is the real hard part)

Posted by Douglas Gourlay at 06:11 AM Permalink | Comments (4) | 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)

I just could not resist...

Saw Brad Reese dignify this posting by a product manager from another company.

So had to put pen to paper, mightier than a sword it is, and take a few swings at it.... as well as invite anyone who has any questions, concerns, doubts, or just wants a good micro-brew to come by the NANOG Beer and Gear event Monday, February 18th at 5:30 - 7:45pm to not only check out the new Nexus 7000 (arriving in person) but also, and more importantly meet some of our key engineering leadership and architects that will be there (also in person) to answer any questions you have about architecture, design, operations, and clearing up any vendor-speak. Get the info straight from the team that built it- including Dino Farinacci, Cisco Fellow and Software Engineer as well as Venu Venugopal who leads the L3 Software development on NX-OS.

For more information on NANOG, one of my favorite events with real people, doing real things, with REALLY large networks check it out here. Nanog Site.

Posted by Douglas Gourlay at 09:14 AM Permalink | Comments (0) | TrackBacks (0)

February 11, 2008

Key Nexus Hardware Features

Michael Morris who maintains an eloquent blog at Network World on the Cisco Subnet wrote this blog entry about some of the hardware features of the Cisco Nexus 7000. Michael's Article. (I say this even though he doesn't like the name...yet :) It will grow on him I am sure....

It's a solid write-up that details some of the key architectural silicon based hardware differentiators of this system. Michael is correct that the Nexus 7000 is hardware capable of supporting FIbreChannel within its Silicon, Hardware, and Software architectures although at this time we do not have plans to release a FC interface module. We have such a significant investment in the MDS, and many many customers worldwide plus the inband storage services like Storage Volume Virtualization, Encryption of Data at Rest, Data migration and Mobility, etc that it makes the most sense to continue to preserve our customers investment in this key platform (a rather unique value proposition given other companies have gone through 5 storage directors in the same time frame :).

Michael, have you explored the software architecture with stateful process restart or graceful system operations and the role of fully modular, multi-process, multi-threaded operating systems? Am happy to have a discussion with you on this at any time.

Posted by Douglas Gourlay at 09:55 AM Permalink | Comments (2) | TrackBacks (0)

February 08, 2008

Colin on Usability

I saw this post hit today on Colin McNamara's Blog here.

Colin writes about key usability features on the Nexus 7000 from an operational perspective after his hands on time with it at last weeks SE Virtual Team meeting. I especially like Colin's suggestions for us to continue improving the product line. Thank you.

If anyone else has any improvement suggestions from a usability or operations perspective please let us know - either on your blog (I will link it), our blog, or via an email is fine.

Colin, keep an eye out on your mailbox for a nice new Cisco Nexus Fleece coming your way.

Posted by Douglas Gourlay at 10:43 AM Permalink | Comments (0) | TrackBacks (0)

February 07, 2008

Expecting and Getting More from Your Data Center

Green is definitely the new black. Much more than a just a trendy fad, though, it’s an important business concern that is driving not just good corporate citizenship, but also innovations in how we approach technology and processes. And the data center is at the heart of this opportunity.

Blade Watch http://www.bladewatch.com/2008/01/23/how-can-we-evolve-the-way-we-use-the-data-center/ recently reported that according to IDC, energy and cooling expenses will grow eight times faster than purchasing costs of new servers through 2010. They go on to quote Christian Bertrand, ME Business Development & Support Director at APC-MGE as saying, “Building completely new data centers might be cheaper than reorganizing conventionally-built ones, even in the medium term.”

Ron Hughes also wrote recently in Data Center Journal http://datacenterjournal.com/index.php?option=com_content&task=view&id=1467&Itemid=43, that “Any design or operating decision that we make to save energy needs to be analyzed to see what impact it will have on reliability and redundancy.” We couldn’t agree more. It’s not just about diluting capacity and utilization for the sake of green, it’s about getting smarter and more strategic about design. It’s about making servers, storage, and networking work together to support the optimum processing of IT Workload in as efficient a way as possible, both run-time efficiency and life-cycle efficiencies.

As we develop our data center portfolio, we are looking at power and cooling, as well as capacity and utilization and more importantly how they impact everything around them because of the networks traits of ubiquity, scalability, and neutrality. Another key aspect of this newest data center innovation is that it is a key enabler of virtualization. Where organizations rolled out server virtualization they became memory bound on their servers, then I/O bound, and then CPU bound. But without virtualizing their network and without virtualizing their storage the full benefits of overall efficient resource utilization cannot be realized. And therein lies the key to data center transformation. InfoWorld http://weblog.infoworld.com/yager/archives/2008/01/selfaware_virtu.html?source=rss
correctly states that the big challenge for IT is matching solutions to requirements and points to virtualization as a way to address some of those challenges. But it also suggests that operating systems and virtualized infrastructure solutions are incapable of knowing what your applications need and allocating the right resources without requiring a great deal of observation and scripting.

For organizations that are aligning themselves around a Data Center 3.0 model, the technologies and infrastructure that enable virtualization also enable greater visibility and control. By Sensing Application Demand, Facilities Capacity, Server Performance then enabling the entire infrastructure to Respond in a coordinated fashion: building a SERVICES centric model rather than just a Server centric model of virtualization. This enables the software provisioning of any resource and workload and the ability to map workload to the resources best capable of supporting it at that point in time.

Posted by Douglas Gourlay at 12:54 PM Permalink | Comments (0) | 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?

Posted by Douglas Gourlay at 12:35 PM Permalink | Comments (1) | TrackBacks (0)

February 01, 2008

WHY YOU’LL WANT THIS SWITCH, PART 1

As I Google “Cisco Nexus” and look through the articles, it is a rare article that doesn’t mention the “15 terabit” number within the first couple of sentences. I can certainly understand this because its a sexy number and its an easy way to quantify the engineering goodness baked into this platform. But, to be honest, if, after spending all this time, money and effort on a new platform, all we could talk about was speeds and feeds, it would be a little sad.

Ironically, the reason I think folks will want a Nexus are a couple of areas that have not gotten much press so far. The first of these “secret weapons” is NX-OS, which has actually been a source of some trepidation. So, first off, “new” is a bit of a misnomer. What we did was start with the proverbial clean sheet and design an OS explicitly for the data center. We had the latitude and R&D capability to cherry-pick from the Cisco technology pantry and build from scratch as appropriate. So, we chose SAN-OS, which has been running for over 4 years in some of the most demanding enterprise data centers out there, as the foundation. Likewise, our layer 3 code, from our Procket acquisition, has been deployed with several major service providers for a number of years. Finally, our layer 2 code was written with the same team that made the Catalyst so successful.

As you can see, we took a very modular approach to building the OS, which is one of the reasons we can successfully integrate these components. In fact, I believe that the fact that NX-OS is a extremely granular and modular OS built atop a secured Linux kernel will appeal to the vast majority of customers. If offers a number of advantages in terms of flexibility, stability and extensibility that other folks will be hard pressed to meet. And, by the way, we wrapped all this in an IOS-like CLI so ramp-up time for staff is minimal. OK, I’m a bit biased, but I think we have hit the mark in terms of giving you operational and functional consistency with the existing Catalyst family, while also giving you an OS that will grow with you the next decade or so.

But we’re not done yet. The framework of NX-OS also allows us to break new ground in terms features and functionality. One of the coolest new features are Virtual Device Contexts (yes, the engineers named this one). The NX-OS brings hypervisor-like functionality to the Nexus, so you can deploy multiple virtual switches on a single physical platform. This lets you support multiple environments on a single switch, say dev and production, or different lines of business with different business polices. VDCs also allow you to segment your environment to keep your security and compliance folks happy. In short, VDCs allow you to drive higher return out of your investment through more efficient utilization and greater flexibility.

That’s about it for now—you can go to http://www.cisco.com/go/nxos for more details. Next time, I’ll dig into exactly what “zero service disruption” means.

Posted by Omar Sultan at 12:22 PM Permalink | Comments (2) | TrackBacks (0)