So Cisco has been on the forefront in leading Fibre Channel Over Ethernet (FCoE) in ANSI standard bodies along with Data Center Bridging (DCB) standards for lossless Ethernet in IEEE. We were the also the first company to productize a FCoE Network Switch for data center by introducing Nexus 5000 in March 2008.
We didn’t stop there, we were also the first company to introduce Unified Network Fabric and FCoE architecture integrated with compute and virtualization with our Unified Computing System earlier this year.
Nexus 5000 has been shipped to more than one thousand customers so far with more than 35% systems shipped with FCoE licenses. Several of these customers have deployed FCoE in production.
While some are trying to come up visions & announcing their future dreams to unify LAN & Storage and others are questioning FCoE technology readiness, Cisco is busy helping customers make tagible benefits of a Unified Data Center and FCoE a reality working with our eco-system of industry partners.
Continuing on this industry lead responsibly , tomorrow we are featuring one of our valued customer Derek Masseth, Sr Director of IT at University of Arizona to share his FCoE production deployment experience, lessons learned and the benefits he realized.
We will also be discussing our storage strategy, FCoE deployment best practices & roadmap to a truly Unified Data Center to address the current and future business challenges.
For our part, we have just posted a new white paper on FCoE Initialization Protocol, which was defined as part of FC-BB-5. FCoE Initialization Protocol supports many of the same functions as FIP in the Fibre Channel world (Fabric LOGIn, Fabric DISCovery, Exchange Link Parameters) in order to establish and maintain the virtual link between an FCoE End Node and an FCoE Forwarder (FCF) such as the Cisco Nexus 5000 that defines the edge of the fibre channel fabric. Amongst other things, that lets us build more sophisticated network topologies as we deploy an FCoE based unified fabric. Up to this point, End Nodes have had to be directly attached to the FCF; however, with FIP, you can have intermediate “passthrough” switches between the End Node and the FCF (as long as they meet certain criteria, laid out in the white paper). A quick example of where this might be helpful is a blade server chassis, where you might not want the cost and/or complexity of a full FCF in the chassis, but do want a switch that can serve as an FCoE passthrough to properly forward the FCoE traffic to an FCF.
Finally, its nice to hear from customers on the topic. To that end, Derek Masseth, Senior Director for Infrastructure Services at the University of Arizona, will be joining us on a webcast tomorrow to discuss his experiences with deploying unified fabric in his environment. The balance of the webcast will give you an update on some other goings on with storage as well as some new products on the horizon.
The Webcast is tomorrow, Tuesday, September 29, 2009, 10:00-11:00 a.m. PDT. It can be accessed at http://tools.cisco.com/cmn/jsp/index.jsp?id=90342 (no registration required, just go to the URL at 10:00 a.m. PDT and select “Play” to launch the live presentation).
With some recent upgrades to our Cisco MDS family of storage networking switches, I think its a good time to revisit strategies for protection against data loss, since it’s always a top of mind in any data center. While there are certainly a number of ways of preventing data loss, I think one of the coolest is EMC’s RecoverPoint solution. Moving beyond traditional approaches such as backups, snapshots or mirroring, RecoverPoint uses continuous data protection technology (CDP) to let you roll-back to any point in time.
One of the features I really like is the ability to create application-aware “bookmarks” for applications that are constantly generating I/O, so you can roll back to a point where the application is in a consistent state.
RecoverPoint takes advantage of a Cisco MDS feature called SANTap. Essentially, SANTap takes each write I/O and mirrors it to the connected RecoverPoint Appliance (RPA). Because this is done at the fabric level, is completely transparent to the host and because the splitting is done out-of-band, it does not impact availability and integrity of the host I/O or application performance.
In support of this solution, Cisco is introducing the MDS 18/4 Multiservice Module (18 x 4GB FC, 4 x GbE, next-gen service engine) and the MDS 9222i Multiservice Modular Switch (18 x 4GB FC, 4 x GbE, next-gen service engine, 1 expansion slot). Both platforms are fabric speed agnostic, so it does not matter if the host initiating I/O is 4GB attached, 8GB attached or FCoE attached.
For a good summary of the solution, check out this video featuring Paolo Pio from Cisco and Rick Walsworth from EMC:
Join us for a live Internet TV broadcast featuring our special guest Derek Masseth, Senior Director for Infrastructure Services at the University of Arizona, who will share his experience how the university united its data center using Fibre Channel over Ethernet (FCoE) to create a Unified Fabric.
Update: The Amazon VPC example I originally gave in this post was confusing and in fact possibly incorrect in some ways. I have removed it.
Recently I posted a video explaining how we at Cisco look at the differences between internal and external clouds, versus private and public clouds. In short, Cisco believes that internal and external clouds describe where the resources underlying the cloud service reside. Private and public clouds describe where the cloud is defined and governed. Both of these definitions are from the cloud service user’s perspective, which is the perspective we believe matters most when rationalizing cloud investments.
I highly recommend that you follow the link and view the video, as I did a much better job describing the topic there than I have words to in this post.
The post resulted in a well formed response that I thought was worth reviewing. (Two well formed responses, actually, but my response to the other will have to wait until a later day.)
The response was from my good friend Sam Charrington, VP of Product Management and Marketing at Appistry. In Sam’s post, he took issue with my focus on control as the core issue behind the private/public differential: