I talk to many customers about Cisco UCS. It always boils down to these 3 talking points. If you've only got 10 minutes to talk about UCS, have this conversation.
Cisco UCS leads in the simplicity and flexibility of our fabric design. Through innovations in our ASICs on our Virtual Interface Cards (VICs) we are able to create up to 256 virtual ethernet and/or fiber channel interfaces. These connections are created in software giving you the flexibility to simply change connections without changing cables.
Down the road your applications might require a different connection architecture, and UCS allows you to do that in software. Our design is based of a pair of fabric interconnects and either a 4 port or 8 ports IO Module in the chassis. Other designs offer "choices" for the switching fabrics. In the case of Dell, they have a 93 page guide that walks you through the choices (http://www.dell.com/learn/us/en/04/shared-content~data-sheets~en/documents~poweredge_m_series_blades_io_guide.pdf). I'd argue that those are the choices you don't need to make these days. How you choose to connect things should be determined by application demands, not some piece of hardware.
Do we really want to go back to the days of choosing Token-Ring, ARCnet, FDDI, Thicknet, etc .. and then choosing NetBIOS, NetBEUI, AppleTalk, 3270SNA, IPX/SPX, etc ?? Just give me the IOPs to meet my application needs and a pathway to connect the communication.
With Cisco UCS we don’t have the concept of management consoles and agents. It's all built into our hardware from the ground up. There's no Dell OMSA or, HP Insight Management agents. No Dell Management Console (DMC), Dell ITA, or HP Insight console for Cisco UCS. All the functionality is built into the platform.
When you want to upgrade firmware, there's no complicated matrix of what needs to be updated first or what order things should be updated. It's all handled by the system.
I have a customer that used to plan an all weekend outage to upgrade their HP blade systems with Virtual Connect. The first time we upgraded their Cisco UCS system, we were done in 3 hours, and that's including the time it took to hand hold them through the process. They now have more UCS blades than they had HP systems and it still only takes a couple of hours to perform upgrades. I've got another customer that does them during the day and experiences ZERO downtime during the process.
That last thing that separates us is the statelessness of our systems. In most servers the things that define the server live on the server. Things like MAC address, UUIDs, WWPNs, WWNNs, Firmware, BIOS settings, number of Ethernet and FC interfaces, etc. If you want to examine or change the state of those items you have to boot the server, hit F1 to go into the BIOS, change things, then F10 save and exit.
Not the case with Cisco UCS.
In UCS everything is stored in the system as either a Resource Pool, or a Policy. Those are then used to define a Service Profile. The Service Profile is then "associated" with a blade or rack server and it's programmed with the state information contained in the Service Profile.
Service Profiles are portable, I can associate them with different blades or rack servers. The "identify" of the server remains the same no matter where I move it. This means other things in your infrastructure like zoning on switches, mapping of LUNS, network items tied to MACS don't have to change.
If you'd like to see Cisco UCS in action, I'd recommend watching this 1 hour demo I did a few months ago. No PowerPoint slides, just some whiteboarding and a demo of the system showing the power of Cisco UCS Unified Fabric, Simplified Management and Stateless Computing.
I just realized the middle one should really say "Converged Management" .... when I was working this out years ago, Sean McGee pointed that out and said, "Then you get the mnemonic U C S - which is easier to remember" ... :-)ReplyDelete
Thanks for the intro to UCS. We have a couple of them in my company and I still did not start learning deeply about them.ReplyDelete