As many of you know, my company recently acquired some very nice lab gear for customer demonstrations and proof of concept work. Many of my peers already know the UCS systems inside and out but I really need hands on to "get it".
As I learn the UCS system I will share my experiences here. My perspective is to share what is different (good and bad) about UCS compared to the IBM and HP Blade products. Before anyone asks, I will only be covering IBM and HP. If you have additional experiences, please share them in the comments. I also have no intention of picking sides. At the end of the day I sell and support all of the above systems and I can get the job done with all of them. They all have their own unique strengths and weaknesses that I intend to highlight.
In case you aren't familiar with what UCS is, I suggest you take a look at Colin's post over on his blog. He does a great job putting all the pieces together. Plus, I'm going to steal a few of his graphics. (thanks Colin!!)
A UCS system consists of one or more chassis and a pair of Cisco 6120 switches that provide both the 10GB bandwidth to the blades as well as the management of the system. The last part of that statement is the key to understanding how UCS is currently different from the competition. I define management in this example as the control of the blade hardware state. This includes identification, power on, power off, remote control, remote media, and the virtual I/O assignments for MAC and WWPN's.
By moving the management from the chassis level to the switch level, the solution can now take advantage of a multi-chassis environment. Here's a simple modification of Colin's diagram to illustrate this point.
(UPDATED!) What are the limitations to the Cisco UCS model?
Someone asked in the comments how this scales. Honestly that was a great question. I'm still learning Cisco and I was wrapped up in making it work. Let's take a look at that. Currently you can have up to 8 chassis per pair of UCS Managers (Cisco 6100's). That number will increase in the upcoming weeks and eventually the limit will top out at 40. But, the more realistic limitation is either 10 or 20 depending on the number of FEX uplinks from the chassis to the 6100's unless you are using double wide blades. If you don't understand what that means right now, don't sweat it. I'll be posting about that shortly.
(UPDATED) What if you need to manage more than the chassis limitations today?
If you need to go above the limit, then you have two options. The first option is to purchase another pair of 6100's to create another UCS System and they will be independent of each other. The second option is provided by BMC software. This will allow you to manage more chassis and the solution also provides additional enhancements. I admit I know little to nothing about the product so I'll just post the link from the comments and you can take a look. The brain mapping for that would like this.
How do you get into the brains?
Each 6120 has an ip address and both 6120's are linked together to create a clustered ip address. The clustered ip is the preferred way to access the software. The clustering is handled over dual 1GB links labeled L1 and L2 on each switch. They are connected together like this:
Cisco uses a program to manage this environment called creatively enough, Cisco UCS Manager or UCSM. To access UCSM, point a browser at the clustered ip address. Once authenticated, you will be prompted to download a 20MB java package (yes it is java, yuck!). Here is a pic of ours with both chassis powered up.
Notice that both chassis are in the same "pane of glass". This allows for management of all the blades from one interface and the movement of server profiles (covered later) from one chassis to another within the same management tool.
How does this compare to IBM?
IBM is a two part answer.
IBM Part One - Single Chassis Interface in AMM
IBM uses a module in each BladeCenter chassis called the Advanced Management Module (AMM). There can be up to two AMM's in each chassis. If there are two AMM's, one is active and the other is passive. They share the configuration and a single ip address on the network. In the case of failure of the primary, the passive module becomes active and communication resumes on the original ip address. The AMM will control power state, identification, virtual media and remote control out of the box. Virtual I/O (both WWPN and MAC) is an additional purchased license in the AMM. The product is called the Blade Open Fabric Manager (BOFM). I don't know if BOFM supports 10GB but I know it supports 1GB ethernet and 2/4GB FC. This is what it would look like with brains in place:
As you can see, each chassis is managed individually. In my experience, this is the most common configuration I have seen.
IBM Part Two - Multiple Chassis Management with IBM Director
IBM does have a free management product called IBM Director that can pull all this together into a single pane of glass. The blade administration tasks are built into the interface and virtualized I/O is handled through the Advanced BladeCenter Open Fabric Manager. Advanced BOFM is a Director plug-in and is a fee based product. Logically it would look something like this:
The downside to this solution is you now have another server in your environment to manage. In my experience Director is a little flaky at times but I also haven't tried the newest version which is a redesign to address many of the issues.
How does this compare to HP?
HP is a two part answer as well. I haven't implemented HP's Virtual Connect over multiple chassis so I will ask that if you know this answer and can throw some links my way, please do and I will update this section.
(UPDATED!) HP Part One - Single Chassis Interface in Onboard Administrator (OA)
HP's approach is very similar to IBM. HP's management modules are called the Onboard Administrator and there can be a maximum of two in each chassis. HP is different from IBM because each module requires an ip address. At any given time one ip address is active and one ip address is passive. If you access the passive module on the network, it will tell you that you are on the passive module and instruct you connect to the active module. Like the IBM AMM, the OA will control all basic functions such as power state, identification, virtual media, and remote control. Like IBM, HP has a separate product for virtual I/O called Virtual Connect. Unlike the IBM and Cisco products, HP's Virtual Connect is implemented at the I/O module level. The only way to achieve virtual I/O is to purchase the HP I/O modules. HP's brain mapping is a little different than IBM because you can connect up to four chassis into one interface. Since you probably won't be able to power more than four chassis in a rack, think of it as consolidation at the rack level.
(UPDATED!) HP Part Two - Multiple Chassis Interface in HP Insight Tools
After you get to four chassis, HP Insight Tools need to be brought in to fulfill the needs. Based on the comments below it appears that two products will fit the bill. To manage the chassis and blade functions you will need Insight Dynamics VSE Server Suite and to manage the virtual I/O you will need the Virtual Connect Enterprise Manager product. Both the Insight Dynamics VSE Server adn the Virtual Connect Enterprise Manager is fee based.
Summary
(If you made it this far, I'm impressed!) Cisco's approach feels very "up to date". I really like the idea of not having to add another server (and additional fees for virtualized I/O) to the environment for management of the products. By moving all of the management centrally to the switches you are better able to see the environment and implement a multi-chassis/multi-rack solution. IBM and HP offer a similar solution that has grown over time but the roots of the interface are in single chassis/rack management. But, at the end of the day both IBM and HP offer a centralized management solution.
Thoughts? Concerns? Please leave a comment!
