Posted on

More on Cisco UCS, HP Matrix and ITaaS

I just finished reading Project California: a Data Center Virtualization Server – UCS (Unified Computing System) from Cisco. It gave an excellent take on Cisco’s view of how UCS benefits a datacenter. It also explains how new technologies from Intel, QLogic and Emulex all complement the Cisco gear. As a matter of fact, the first four chapters are all about the complementing technologies. Obviously, it is all twisted into a nice package that Cisco offers as their Unified Computing System. Its a great, educational geek book.

The UCS depends on several enabling technologies, like FCoE. FCoE allows you to take your existing Fibre Channel investment and send it down an ethernet channel. A big FAT 10GbE channel. The benefit here is that you can have eight cables feed everything to eight blades and have a nice neat rack. But Scott Lowe points out some limitations on his blog. Right now, it appears that Cisco’s FCoE will terminate at the top of the rack with the Nexus 5000. The book explains how iSCSI is a great alternative and you don’t even need a CNA to make that work, but you need an iSCSI interface on the storage system. So the UCS requires change at some point in the data path.

The HP Matrix is really just the C-Class blade offering coupled with the software to enable management and orchestration, both are important aspect that I believe will assist in making Cloud Computing a reality. The beauty part of the C-Class Blades is that you can keep using Fibre Channel and Ethernet as separate entities, so you don’t really need to make a change in order to use them. The problem is that it doesn’t seem that HP has a mezzanine available to provide FCoE, or some of the virtualization technologies, like SRIOV, VNTag, etc. So, if you want to jump on the FCoE bandwagon or start using some of the neat new networking toys, you will need to wait for a bit.

So, there’s some things about storage, what about networking? Well, the UCS uses what is termed a Fabric Interconnect, which is described as a multiplexer that funnels the sixteen 10GbE ports from the blades down to eight 10GbE uplink ports. I am taking this to be their version of HP’s Virtual Connect, with the added benefit of transferring all of those little Cisco features right up to the Nexus 1000-V dvSwitch. This returns control of the complete network path back to the network admins. This gives the network admins the ability to set up things like policies at the VM level. These settings will follow the VM during VMotion activities, which should allow for a more efficient network.

HP only offers Virtual Connect if you want 10GbE switching within the chassis. Don’t misunderstand me, there is absolutely nothing wrong with Virtual Connect. I have even set them up in (traditionally) Cisco networks. But there are also politics involved when choosing the networking. If HP wants to tout flexibility with interconnects, they may want to make nice with Cisco and come up with a Nexus offering. Or is this a case of Cisco taking their ball and going home to try to force people to buy UCS? I don’t know a lot about Dell Blades, but I don’t see a Cisco 10GbE there either. I used to hear the quip that all of the winders, Linux and Unix boxes are just I/O attached to the Mainframe. Is this a case of the x64 boxes being just I/O attached to the network?

As for ITaaS, both UCS and HP offer some pretty software to allow for management and orchestration. Both have their plusses and minuses (C’mon Cisco… Java? Really?!?) This could be where HP has a big leg up on Cisco. With all of their management software having the same look and feel, on-the-fly dynamic changes can take place with less sdministrator interaction. I’m not so sure CIsco can allow you to provision server, network and storage from the OS to the LUN. Like I said Cloud Computing won’t become a commonplace reality until all of the moving parts can be managed, monitored and provisioned (Orchestration). I’m still not convinced that HP software will allow me to create a RAID/Disk group and provision storage on an EMC box. I’m not so sure that Cisco will play nice in a Brocade fabric and allow for all of the Brocade specific features. And what about someone that chooses to (*GASP*) install an OS directly on the blade? I know that I can provision any hypervisor or winders or Linux on an HP blade. Can Cisco provide an interface to provision an OS directly on the hardware? How about the ability to have VMware running on a blade today, Xen next week and Linux the following week? All without an administrator mounting a CD or interacting with the installer? And how about having that VMware or Xen or Linux OS jump over to a different blade, with or without service interruption, but without manual intervention? That’s ITaaS. That’s Cloud Computing.

DISCLAIMER: I work for a company that is both an HP Partner and a Cisco Partner. These are my opinions, not theirs. Also, I did not pay for the book, but that did not influence this post either.

Posted on

Stevie’s Unified Event Management, My Cloud Shangri-La

If you know Steve Chambers you know he just moved to Cisco. Before that, he was with VMware and has been a pillar of the VI:OPS boards. He is now working on a document about Unified Event Management and in the spirit of community, he is looking for comments, suggestion, etc. He called my attention to the post via Twitter as we were discussing Splunk and it’s capabilities for “Centralized Event Aggregation” (Steve’s terms). Take a look at his post when you get a chance and make some comments. You know that I have heralded the benefits of a centralized logging server. Steve just plain gets it.

And since I mentioned Cisco, I also discovered that Cisco put out a whitepaper on their take regarding the Virtualization Blueprint for the Datacenter. Its their take on how virtualization will benefit your business.  The chart shows how a business’ agility will increase as we climb the lifecycle from consolidation to virtualization and then on to automation.

It doesn’t matter what you are using underneath of it all – VMware, Xen, Hyper-V – UCS, Matrix. It just matters that you have methods to provide centralized monitoring and centralized automation. Although centralized event monitoring and centralized automation are two different things, they are both necessary if you wish to properly monitor and manage your piece of the cloud. I’ve already said my piece on the need for centralized event monitoring and Steve lays out a sample blueprint.

Automation is the new big thing when it comes to the cloud. VMware saw that way back when and they bought Dunes almost two years ago. VMware Orchestrator (VMO) was a big buzz for a little while, but great big VMware couldn’t couldn’t pull off what teenie little Dunes could when it comes to customizing the Orchestrator. They left it in a fairly decent state for smaller businesses with VMware Lifecycle Manager, but it was a hobbled state and didn’t scale very well. You can customize VMO, but you need to be good at the Dunes interface and have a decent knowledge of JavaScripting and that kind of stuff. Even being free, its not for me. The standard release of VMO allows you to set up a facility to request, approve, provision and archive VMs. A great start, but not quite enough.

A quick search for data center orchestration reveals Cisco at the top of the list. But there are others from Novell PlateSpin, Egenera, and DynamicOps that appear to do more. What we REALLY need is a way to orchestrate/ automate the entire data center. Physical servers, VMs, storage and networking can all be provisioned, monitored and managed. Can they all be managed from a common platform? Once you can have a seamless process for provisioning, managing and monitoring every component of the data center, you will see cloud computing really take off. A user (consumer / customer) that needs an application should not care if it is deployed on a physical or virtual machine, what storage devices hold the data or the network that connects it. The user should know the basic requirements for the application and the ORCHESTRATOR should make the decisions about all of these things. The orchestrator will take a request, ask for approval and make sure the application gets deployed without making mistakes. The orchestrator will interface with the monitoring facility and change management to make sure the application is accounted-for. The orchestrator will hand off to the backup facility. The orchestrator will notify you when the application as reached end of life. That’s when we will have “Cloud Shangri-La” (My term).