VM /ETC

Archive for the ‘blades’ Category

Who Dat? Who Dat? Who Dat virtualizin’ on BladeCenter S ?

I posted last year about the NFL’s use of virtualization at the Super Bowl, and I wrote my beloved Atlanta Falcons in case they needed help when the NFL made it’s  decision to standardize on IBM Blades for all 32 teams. This year, Kevin Houston, a fellow Softchoice employee and author of the increasingly popular bladesmadesimple.com blog, has posted on how the ‘09 NFC Champion New Orleans Saints have capitalized on these very technologies during the season.

Houston writes:

“Other than the obvious threat of having to relocate or evacuate due to the weather, the Saints’ constant travel required them to search for a portable IT solution that would make it easier to quickly set up operations in another city.  The Saints were a long-time IBM customer, so they looked at the IBM BladeCenter S for this solution, and it worked great.  (I’m going to review the BladeCenter S below, so keep reading.)  The Saints consolidated 20 physical servers onto the BladeCenter S, virtualizing the environment with VMware.   Although the specific configuration of their blade environment is not disclosed, IBM reports that the Saints are using 1 terabyte of built-in storage, which enables the Saints to go on the road with the essential files (scouting reports, financial apps, player stats, etc) and tools the coaches and the staff need.  In fact, in the IBM Case Study video, the Assistant Director of IT for the New Orleans Saints, Jody Barbier, says, “The Blade Center S definitely can make the trip with us if we go to the Super Bowl.”  I guess we’ll see.  Be looking for the IBM Marketing engine to jump on this bandwagon in the next few days.”

Be sure to read Houston’s entire post for more about the many features of IBM BladeCenter S

Maybe the S model of IBM BladeCenter stood for “Saints” all along!?

During the UCS Bootcamp in San Jose, Cisco made it clear that the value proposition of UCS is the Stateless Model. Unlike traditional server deployment use of the Service Profile (I covered the Opt-In Model earlier in this series), the Stateless Model allows the physical hardware to become generic and, since the operating system and application resides on the SAN, a server personality duplicated and restarted from blade to blade.

Cisco’s definition of Statelessness:

“In Unified Computing system (UCS) the underlying hardware (or server) can be made completely transparent to the OS or applications that run over it. The kind of environment which an OS or application requires can be moved from one server to another or can be changed very easily. This is made possible by moving resources, such as MAC addresses, WWN values, IP addresses, UUID, firmware versions and even server BIOS, from one server to another at the time of deploying the server. This is accomplished by using the concept of Service profiles; which is like software definition of a server. The concept of stateless computing facilitates much greater scalability and can be used in conjunction with virtualization to achieve maximum data center utilization.”

One of the labs during the week showcased the Stateless Model in action, so what better way to help explain this feature then to walk through it again for all to understand?

The Stateless Model Lab Overview

Quoting the lab introduction, the purpose of the lab was to:

“.. demonstrate the statelessness by booting an OS off of a SAN LUN.  The SAN connectivity and masking is specified by World Wide Names that are associated with the service profile.  When your service profile moves from one blade to the next, you will be booting the exact same SAN based OS. No configuration outside of UCS will ever be required at this time.”

The following overview is of the UCSM configurations performed in the lab. Once again, this is not a “how to” but is instead intended to provide insight into the process and advantages of the UCS Stateless Model.

Read the rest of this entry »

As a class and in smaller groups, I’ve participated in several discussions trying to understand UCS connectivity and communication both internally and externally to the LAN and the SAN. This post summarizes several diagrams and drawings from whiteboards, my notes, and the bootcamp manual to explain what hardware communicates with which protocol, and how redundancy and fail over works in Cisco’s Unified Compute System. If you are comparing UCS to other blade centers some details mentioned will jump out at you. I’ll conclude with some thoughts on these items.

Again I am using terminology and acronyms established in my post from day 1. Review that post if necessary.

The following diagram illustrates the current connectivity between the UCS Blades, Fabric Extenders (FEX), and the Interconnects. The diagram only includes a single chassis, a single half height blade, and a single full height blade for simplicity while covering all scenarios. Duplicate the same connectivity for each blade inside the chassis, and duplicate connectivity of 2 more FEX for each additional chassis in the solution. As shown, the 2 Interconnects can manage up to 20 different chassis if model 6140 and up to 10 chassis if model 6120. (The max number of chassis can not be achieved because 2 FCoE cables are being used to the Interconnects) Read the rest of this entry »

Day 2 in San Jose, CA at the Cisco UCS partner Bootcamp focused around using the UCS Manager (UCSM). We dove deeper into UCSM navigation and explored the various objects found in the web browser Java interface. There was a discussion about the process to upgrade UCS component firmware, and the day concluded with an exercise on assigning “basic Opt-In” Server Profiles to blades in order to install an operating system.  This post will touch on the last two topics as the objects are self explanatory (for the most part) once in the Java interface, and then conclude with some screen shots showing the application of a profile and the installation of ESX 4 on a Cisco blade via the UCSM.

I am using terminology and acronyms established in my post from day 1. Review that post if necessary.

Upgrading Firmware

For those familiar with management of bladecenter chassis, blades, and modules from the leading manufacturers today UCS hardware is a bit of change. Specifically, the “management module” is not found in the chassis. Management is instead performed on the Interconnect switches via the UCSM GUI or CLI. Administrators used to configuration, troubleshooting, and upgrading hardware at the chassis level could be surprised to learn that even though there is a Chassis Management Console (CMC), it is not directly accessible without a special connector possessed only by TAC or authorized Cisco Partners. UCSM controls the CMC and orders it to make the configuration changes.

Once configured, a web browser is pointed at the switch ip address and all components are upgraded from there.

Firmware upgrades can be performed via the CLI, but using the UCSM GUI makes the entire process, from downloading the update bundle to applying individual component upgrades, much easier.

All of the following can be upgraded from the UCSM:

• Mezzanine Cards (IOMs)
• Blade BMC
• Blade BIOS
• Chassis CMC
• Interconnect switches
• Blade LSI RAID controller

The upgrade bundle download is initiated from the UCSM and then is viewable in the interface, and the installable images can be assigned to the hardware.

Deploying Server Profiles

Read the rest of this entry »

Day 1 of the Cisco UCS Bootcamp partner training was mainly an introduction to the hardware, but also established the concept of UCS Server Profiles and Statelessness. Converged Network Fabric and the Cisco’s CNA (Converged Network Adapters) models were covered, and the day ended with a lab exploring the UCSM (Unified Compute System Manager).

I promised to report in the style of the “For Dummies” series. To do that I am going to borrow the common feature “The Part of Tens” always found at the end of those books. The “Tens” are usually a list of concepts suggested for further research. I’m going to use this more as a list of what “sticks” with me from the bootcamp topics. As in the books I hope I motivate VM /ETC readers to research further. If you count My “Tens” it might not even equal 10 items – no promises. I’ll add some opinion and scenario when motivated to do so.

Many others already have provided technical details on the Cisco chassis, blades, modules, adpaters, and the other components, and I’m not about to add anything new to what is already known. In fact, I found myself supplementing what I was being told in class by cross checking various blogs ande other documntation already on the web. Nevertheless, the first “Tens” covers the overview of the UCS parts and concepts.

Read the rest of this entry »

Like Scott Lowe earlier in the year, I am in Silicon Valley this week attending Cisco’s UCS Bootcamp training for partners. This post starts a series I will publish as I learn about the Unified Compute System (UCS). Instead of focusing on the technical details of the UCS blade chassis, servers, and it’s various components I plan to maintain a solution oriented, comparison focus in my reports. That is, my intent this week is to answer some questions that many VMware admins have (based on my own conversations) about what makes Cisco UCS a solution to be considered. Put simply – Most administrators understand the benefits of consolidating data center hardware with blades, but why is Cisco’s solution unique?

Some questions I hope to answer:

• Why would an IT shop benefit from deploying UCS blades over other established blade chassis and server hardware solutions already available today?
• What’s the big deal with FCoE and why would I want to use it over iSCSI or NFS?
• Does Cisco really want to sell IT Departments all the hardware in the datacenter?
• What administrative, configuration, and logistical changes does UCS create for VI administrators, and is UCS the best choice for VMware?

I plan to relay what I discover this week in the way that the popular instruction series “For Dummies” tackles technical subjects. VM /ETC readers should understand a major difference from the book series: the guy writing these posts is actually one of the “dummies” too.

I’m also going to point out that I have no hands on experience with UCS and Cisco Blades yet, and for the most part I am reporting in good faith about the material presented to me by Cisco and from the experience of the hands on labs I perform. I will attempt to link to others like Scott that have been able to set up this hardware and have blogged about the technical details.

Cisco’s announcement of their Unified Computing System (UCS) has definitely been the biggest news this week. Self proclaimed to “unleash the power of virtualization”, the Cisco UCS is an “innovative architecture [that] integrates compute, networking, and virtualization in a single platform.” Although the Cisco UCS looks, feels, and behaves mostly like a chassis full of blade servers on the surface, it is apparently a revolutionary system tailored for virtual infrastructure and cloud services.

I’m late to blog on this topic this week so I’ll provide some quick links and quotes to some of the posts that I found especially helpful and informative from a virtualization perspective. Be sure to follow all the links and read these posts in full.

Click the image to the right for a larger view of the UCS diagram. Read the rest of this entry »