M. Sean McGee

Now in our second year of shipping Cisco Unified Computing System (UCS) blade servers, it seems that most of our 1700+ UCS customers are migrating to Cisco blades from HP blades. Two teammates of mine, Jeff Allen (Twitter) and Doron Chosnek (Twitter), have developed a process to help these customers migrate from HP blade servers to Cisco UCS blade servers in a matter of minutes. Their migration process, based on publicly available documentation from HP and Cisco, allows a UCS customer to move the “server identity” of the retired HP blade server to the newly deployed Cisco UCS blade server. For a discussion of what the “server identity” is, see this previous blog entitled “The State of Statelessness: Cisco UCS vs. HP Virtual Connect“.         

Click Picture to Enlarge

Doron and Jeff accomplish this HP-to-Cisco migration by extracting the server identity information out of HP Virtual Connect and then importing that server identity information into Cisco UCS Manager. Fundamentally, they export an HP Virtual Connect Server Profile and import it into Cisco UCS Manager as a Cisco UCS Service Profile.     

 Server identity migration can be done seamlessly from HP to Cisco because Cisco’s UCS Service Profile is a superset of HP’s Virtual Connect Server Profile. Cisco manages ~96 server identity settings while HP only manages ~12 server identity settings. The reverse process, migrating Cisco-to-HP, would be difficult (if not impossible), since HP supports so few server identity settings in comparison to Cisco. I’ve provided an updated Cisco UCS vs. HP BladeSystem server identity comparison below. See Table 1.        

 In the following video, Doron and Jeff demonstrate their process by migrating a workload from an HP BL460c to a Cisco B200 M1 server. In their setup, both the HP blade and the Cisco blade have access to the same Ethernet and Fibre Channel networks. The soon-to-be-retired HP blade is booting from SAN. During the migration, WWN and MAC addresses, boot from SAN target and LUN number, etc. are taken from the HP server and given to the Cisco server. Since the FC network and storage controller see the same server identity on the new UCS blade, this allows the Cisco blade to immediately boot from the same FC LUN that the retired HP server was booting from. The result for the customer is an upgraded server running the same instance of the operating system with no changes required on the LAN or SAN.       

UCS Documentation References:
Overview of Cisco UCS Manager
Cisco UCS Manager CLI Command Reference Guide        

____        

Table 1: Comparison Chart Showing User Interfaces Required To Configure A Server (click table to enlarge)        

Tweet This Post

I have a very convoluted family background – from being a long, lost relative of the late Marie Antoinette to being an ashamed relative of a modern day actor that can’t seem to stay out of jail.  Somewhere in between, I have a whole slew of relatives with the last name of “Wagonseller”.  As you may have guessed, they sold wagons and buggies powered by horses.  I’ve often wondered what it must have been like to be a “Wagonseller” during the years after October 1, 1908 – the day the Ford Model T was introduced.  I can just imagine all the fear, uncertainty, and doubt (FUD) my long lost family members were probably spouting as a result of having to compete with Ford’s entrance into the transportation industry in North America with a product that was destined to be a market changer.  

Well, an article recently published by one of Cisco’s competitors (http://h20338.www2.hp.com/enterprise/us/en/messaging/realstory-cisco-datacenter-view.html) made me think of my family, the Wagonsellers.  As I was reading the article, I kept laughing out loud because I could just picture the Wagonsellers writing a similar article out of fear of the newly released automobile. Their article would have just enough truth mixed in with the FUD to make it sound legitimate but, ultimately, it would argue points that are either based on non-shipping products or argue points that are completely irrelevant to a new architecture design. To help you understand what I mean in regards to “just enough truth to make it sound legitimate”, I’ve written the article below in memory of my long, lost relatives, the Wagonsellers.  

======================================================================
The Usual Disclaimer… I work for Cisco. Opinions expressed here and in any corresponding comments are my personal opinions, not those of Cisco.
======================================================================  

July 1910 – The automobile manufacturers have been in full gear since late 1908 touting their first attempt at a transportation vehicle, the so called Under-carriage Combustion System automobile (herein referred to as “UCS automobile”). Now that UCS automobiles have been in the market for a little over one year, we thought it would be useful to take a closer look at the facts, separated from the marketing hyperbole. While in theory UCS automobiles compete with the Horse Powered buggy (herein referred to as “HP buggy”), the leadership of horse powered transportation has been validated by centuries of innovation, real world experience, and market leadership.  

Please consider the following facts:  

Fact 1: The UCS automobile lacks the real world validation points that the HP buggy delivers.

The market leadership and scale demonstrated by the HP buggy far outpaces anything the UCS automobile can muster and gives customers the peace of mind that is represented by this real world validation:  

#1 in buggies: HP buggies have a commanding lead in the transportation market, with a 56.1% revenue share, and a 53.1% unit share. HP buggies have led the transportation market for 14 consecutive quarters. The UCS automobile has yet to break out of the “Others” category in the “Transportation Today” market data.
2M+ Buggies Shipped. More than 2 Million HP buggies have shipped since tracking buggy selling began in 1854, shipping more than International Buggy Manufacturer and Discount Equine Lading Line COMBINED during this time.
3M+ virtual horse hoofs (called shoes) shipped. 24% of all horse shoes worldwide are made for horses pulling HP buggies. The UCS automobile claims shipment of only 1 million of a new, unproven, “tire” contraption that uses AIR instead of tried-and-true metal used in our world-famous HP buggy horse shoes.
4K+ Buggy reference. A recent HP buggy reference consisted of 4352 HP buggies, 8704 horses, and 34,816 horse shoes.  

Fact 2: HP buggies deliver 5x the bed width and 4x the number of real horses than the comparable UCS automobile allowing HP buggies to deliver 4x the hay bale hauling capacity and unlimited miles per gallon.

Requirements: Haul as many bales of hay as possible per trip.  

Fact 3: The HP buggy can simplify transportation by hauling up to 16 bushels of corn with just 1 part versus at least 481 total parts for the UCS automobile to accomplish the same thing.

Fact 4: The UCS automobile design that uses petroleum fuel in a combustion engine forces trade-offs between speed and gas mileage.

Speed limits gas mileage: In order to reach the claimed average speed of 65 miles per hour, the driver is forced to consume the stored petroleum at a faster rate. The faster the driver drives, the less distance they can go before needing to re-fuel.  

Gas mileage limits speed: To deliver the promised gas mileage efficiency, drivers are prevented from driving at the maximum speed that the UCS automobile allows. 

Refilling the gas tank requires additional 3^rd party fuel adding cost and complexity to each trip.  

It was reported that a horse expert predicted the need for a UCS automobile design change to address increase gas mileage requirements for hauling larger workloads.
(Our “horse expert” was paid by us to conduct custom testing designed to validate our marketing message.)  

Fact 5: The HP buggy delivers advantages in cooling and air flow, critical for passenger comfort.

Air flow: Due to the speed of the UCS automobile design, passengers may be forced to endure 6.2x more air flow than with the HP buggy design. HP buggy’s don’t force passengers to travel at speeds more than 9 miles per hour which prevents air flow from tangling hair and prevents “bug in teeth” syndrome. Also, since the HP buggy moves at a slower speed, air resistance is less and less hay is consumed by the HP buggy equine propulsion system leading to dramatic cost savings.  

Cooling: The HP buggy delivers fresh, cool air to occupants at all times during the voyage. The UCS automobile has only recently added something called “air conditioning” that requires the occupant cabin to be completely enclosed, which may lead to suffocation of the passengers due to a lack of fresh oxygen.  

Choice of hay, grass, and grain power: The UCS automobile’s use of a single source of fuel for their combustion system, gasoline, makes it much more complex to refuel between trips. The HP buggy was designed with the choice of hay, grass, grain, old apples, etc. as options for fueling the equine propulsion system.  

Fact 6: The HP buggy manufacturers have an unmatched supply chain.

HP buggies are the leading method of transportation for riders of all ages around the world. HP buggies are also the leading transportation method for both small and large business. The supply chain used by HP buggy manufacturers enables “economies of scale” (horse shoes, hubs and spokes, cloth wagon covers, planting/growing/distribution of feed and grain) that the UCS automobile manufactures can not match. The HP buggy manufacturers are absolutely committed to offering the broadest choice of equine transportation methods based on industry standard horse breeding methodologies to address the wide range of passenger requirements.  

Fact 7: The HP buggy delivers so much more than a UCS automobile can by itself.

The HP buggy brings added advantages to the table that are simply not included with the UCS automobile such as:  

• Equine waste can be used as garden fertilizer.
• When the buggy is not needed, the horses can be used for plowing and hauling
• Hay rides on HP buggies are great for entertaining guests

Bottom-line: The equine-drawn-carriage strategy as embodied by the HP buggy fits into your existing transportation processes and barn infrastructure (including the ability to drive HP buggies on the new roads built for UCS automobiles), offering end-to-end integration of horse, buggy, passenger, and hay hauling capacity. The HP buggy leadership in the transportation industry has been built over centuries of innovation (beginning with the invention of the wheel), experience, and leadership.  

.  

Advertisement

   

Tweet This Post

I’ve got two questions for you…

Question #1:
If you were designing a datacenter full of rack servers, would you deploy two Ethernet switches, two Fiber Channel switches, and two rack managers for every 16 rack servers?  Of course you wouldn’t!  You’d be at risk of losing your credibility.

Question #2:
If you wouldn’t do it for rack servers, why do the legacy blade server vendors want you to deploy that design when you buy their blade servers?

I can tell you why – it’s a result of the “mini rack” approach to blade server design.

I currently work for Cisco, but I spent over a decade at HP/Compaq in their Server Engineering Business Unit.  I can remember the first discussions of blade servers at Compaq in the early 2000s…the discussions that led to the development of their first blade chassis (the Compaq (now HP) e-Class blade enclosure).  My involvement back then was related to the mini-switches that we would eventually build to go inside the e-Class blade enclosure.  The e-Class had two mini layer 2 Ethernet switches used for connecting the 20 blade servers to the external network.  After the e-Class release came the p-Class architecture with its two mini-Ethernet switches and two mini-Fiber Channel modules for its 8/16 blade servers.  HP then re-architected the chassis design by adding lots more I/O bays and released the current blade chassis design, the c-Class. c-Class comes with up to 8 mini-Ethernet and mini-Fiber Channel switches and two mini-rack managers, called Onboard Administrator (OA), for 16 blade servers.

So the progression was:

♦ e-Class had 20 servers, 1 switch, and 1 enclosure manager
♦ p-Class had 8 servers, 4 I/O modules, and no enclosure manager
♦ c-Class has 16,  8 I/O modules, and 2 enclosure managers

Are you seeing the pattern yet?  Slowly, the infrastructure overhead – number of required modules and number of management interfaces/IP address – to deploy 16 blade servers has grown over the last three generations of HP blade servers. HP c-Class’s best case scenario has a whopping 6:16 ratio – 4 I/O modules and 2 OA modules for 16 blade servers. The worst case ratio is 10:16 – 8 I/O and 2 OA for 16 blade servers.

The mini-rack mindset originates from the early days of blade server chassis design.  Let me walk you through the thought process that results in this mindset:

<follow along in graphic labeled “How should I architect a blade server”>
“I need to architect “blade servers” for my customer. <phase 1> I guess I should start by looking at a legacy rack full of servers as a point of reference.  What components do I see?  I see that typical racks have two Ethernet switches, two Fiber Channel switches, and multiple PDU’s.  In addition, separate central management servers (e.g. HP SIM) must be configured, clustered, and maintained in the datacenter to manage the other rack servers, and shared PDUs. Well, <phase 2> I guess I’ll make miniature versions of each of these components for every 16 servers and <phase 3> I’ll put these components inside the sheet metal (blade chassis) with the blade servers themselves.  This arrangement worked for racks for years so it must be the best design.  <phase 4> Unfortunately, this creates lots of management overhead and complexity so I guess I’ll write extra management software to solve the problem my design created.”

The end result of this line of thinking is the “mini-rack” mindset is; lots of mini-racks in your data center and all the management overhead and complexity associated with a bunch of mini-racks.

Every time you add another 16 blade servers with Enet and FC connectivity, you need to add the overhead of a minimum of SIX infrastructure modules – 2 mini Enet switches, 2 mini FC switches, and 2 Onboard Administrators. I’ll admit… as a member of the blade server engineering community, I helped perpetuate this mindset.  But we didn’t really see an alternative.  We were stuck between the choice of too many cables (passthru) and too many mini-switches.

Side Note: Does HP’s Virtual Connect product really solve the problem of too many switches? I don’t want to rat hole in this post so I’ll save that for another blog post in the near future.  Short answer is: unfortunately, no it doesn’t.

So what’s your alternative to the mini-rack architecture?
Cisco Unified Computing System (UCS)

Cisco didn’t approach blade server architecture design as a “me too mini-rack”.  Cisco has never been a “me too – let’s run off the cliff together – company”.  Cisco has built its reputation as a company that delivers innovative products and solutions that set the example in the industry.  Cisco has always been an industry leader, not a follower.  So, how did Cisco “lead” with their approach to blade server architecture?  Cisco said “We don’t want a mini-rack.  We want a logical, expandable blade chassis that provides all the key benefits of blade servers (reduced power & cooling, reduced foot print, reduced cabling) but with the infrastructure design simplicity that’s BETTER than that of the original rack server architecture.  When the logical blade chassis needs to be expanded to accommodate more blade servers, there WILL NOT be an increase in management overhead. There will just be an increase in available server hardware for the same management interface to manage.”

Cisco’s blade server architecture is designed around a pair of clustered ‘top of rack’ blade chassis managers that includes all the management functionality for blade chassis hardware, blade server hardware, switching hardware, Ethernet and Fiber Channel connectivity, server identity management, and control plane integration with VMware vCenter.  Cisco calls these devices “Cisco UCS 6100 Fabric Interconnects”.  Since all this functionality is delivered in a device that sits outside of the physical blade chassis, Cisco’s blade chassis has been simplified to provide the original intended benefits of blades – reduced power & cooling, reduced cabling, reduces server foot print – but without the management overhead nightmare forced onto the customer by the legacy mini-rack mindset.

Example of Cisco's Single Logical Blade Chassis with 80 blade servers under one UCS Manager

For example, Cisco’s Fabric Interconnects provides the functionality of HP’s Onboard Administrator, HP Virtual Connect Ethernet, HP Virtual Connect Fiber Channel, HP Virtual Connect Manager, HP Virtual Connect Enterprise Manager, and many aspects of HP SIM, all in a single, clustered-for-redundancy device that can be used for multiple blade chassis.  So, you configure these Fabric Interconnects (and three IP addresses) once.  Then you just plug in blade chassis as you need additional blade servers.  It’s a modular, expandable blade chassis design.  That’s why I call it a “single logical blade chassis”.  You can expand it anytime you want without adding more interfaces to manage. You plug in the chassis, the chassis is auto-discovered and the blade servers show up in the management interface. It really can’t get any easier.

Side Note: So how does Cisco UCS reduce cables without putting little switches in every blade chassis?  Cisco’s distributed switch architecture allows the fabric interconnects to extend their ports inside of each blade chassis. As a result, adding more blade chassis does not add more switches – it only adds more logical ports on the fabric interconnects for each server. Again, I don’t want to rat hole so I’ll save this conversation for another blog post.

As an example of the mini-rack architecture vs. Cisco UCS blade server architecture, let’s look at it just from an IP address overhead perspective. Here’s an 80 blade example for both HP and Cisco. The examples show the minimum number of infrastructure devices (redundant) and their required management IP addresses:

HP Bladesystem: 5 HP BladeSystem Enclosures with 2 x VC Enet, 2 x VC FC, and 2 x Onboard Administrators (80 server blades)

♦ 10 x IPs for Onboard Administrators
♦ 10 x IPs for Virtual Connect Ethernet (Flex-10) modules
♦ 5 x IPs for Virtual Connect Manager cluster address (optional but typical)
♦ 10 x IPs for Virtual Connect Fiber Channel modules

Total: 35 Management IP addresses for 80 HP server blades

Cisco UCS: 10 Cisco UCS Chassis with 2 x Fabric Interconnects (80 server blades)

♦ 2 x IPs for Fabric Interconnects
♦ 1 x IP for Fabric Interconnect cluster address

Total: 3 Management IP addresses for 80 Cisco server blades

HP’s 35 Management IP addresses vs. Cisco’s 3 Management IP addresses demonstrates the fundamental architectural differences in management philosophy between the two approaches.

Summary:

Cisco’s outside-the-box engineering has resulted in a brand new blade architecture. Cisco has just developed the first “automobile” class blade server architecture and the legacy “horse-n-buggy” blade server vendors are scrambling. My expectation is that the legacy blade vendors will, eventually, follow Cisco’s lead and come out with new blade architectures that get rid of all the management complexity. In the meantime, they will try to hide the complexity using more layers of management software.

Tweet This Post

One of the many industry buzz words these days is “Stateless”. Unfortunately, even within data center technology circles, the term “stateless” or “stateful” can refer to many different things. In this blog post, the “state” that I am referring to is the “server configuration state”… defined as a collection of settings and identifiers used for deploying a new server in the data center. What the “state” ends up representing is the “identity” of a particular server. The identity of a server is not just an IP address or a hostname. That’s about like saying that my identity is “M. Sean McGee”. No, that’s not my identity; that’s just my name. My name is one of many things that make up my identity. Other things that make up my identity are: mailing address, email addresses, family & friends, likes & dislikes, hobbies, social security number (ugh), telephone number, certifications, etc. The collection of all those things makes up my identity. It’s the collection of those things that, together, make me very unique from every other human on the planet. It’s the same with a server.

A server’s identity is made up of a collection of configuration settings on the server hardware, as well as, the configuration settings on the network and storage devices that it’s connected to.

As an example, see Figure 1. This server’s identity is made up of its RAID settings, disk scrub settings, number of HBAs, HBA WWNs, FC boot parameters, HBA firmware, FC fabric assignments, QoS settings, NIC speed, VLAN assignments, number of NICs, NIC firmware, remote keyboard/video/monitor IP address, server UUID, boot order, IPMI settings, BIOS firmware, BIOS settings, etc. I think you get the idea. It’s a LONG list of “points of configuration” that need to be configured to give this server its identity and make it unique from every other server within your data center.

So where are all those points of configuration kept in your environment? I would imagine that some are kept in the hardware of the server itself (like BIOS firmware version, BIOS settings, boot order, FC boot settings, etc.) while some settings are kept on your network and storage switches (like VLAN assignments, FC fabric assignments, QoS settings, ACLs, etc.)

Let’s play “what if?” for a minute.

What if you could keep all those settings in one place instead of 15 different places?
What if you could configure all these settings independently of the physical server?
What if you could assign this identity to any physical server with the click of a mouse?
you could replace a failed motherboard and NOTHING changed from the perspective of the OS?
What if you could replace a failed HBA without bugging the SAN admin to re-zone new WWNs?
What if you could stop paying for 4 hour server hardware warranty because you could failover to a spare physical server with a click of a mouse and an OS reboot?
What if you could do all this remotely from Aruba while your servers are in Alaska?

Let’s go back to “stateless”. Within the context of this discussion, “stateless” means that the physical server doesn’t own the server’s identity. The architecture owns the identity. The identity is assigned to a physical server to use until the admin decides to move the identity to a different physical server. Since the physical server doesn’t retain any ‘state’ for any particular server identity, the servers are said to be “stateless”.

Side Note: Boot from SAN helps complete the ‘stateless’ scenario. If you are booting from local disks, your server is not truly stateless since there is a state stored on the local HDDs. You don’t HAVE to adopt BfS, but you give up some benefits (like replacing a failed server in Alaska with a click of the mouse while lying on the beach in Aruba). As a result, many customers find that migrating to boot from SAN allows them to fully utilize the power of ‘statelessness’.

 Now that we have level set on what “statelessness” means and what a Cisco UCS Service Profile is, it’s time to tackle the topic: Who does “statelessness” better? Cisco or HP?

HP was the first mainstream x86 server vendor to deliver the concept of managing a portion of a server’s identity using something called a Virtual Connect Server Profile. (Side note: As a former engineer in HP’s BladeSystem development group, I participated in the design and delivery of Virtual Connect.) Virtual Connect allowed the server admin to assign VLANs and MACs to NICs, WWNNs and FC fabrics to HBAs, configure FC boot parameters, and assign serial number and UUID.  This was a good start… but what about the rest of the server’s identity? What about the rest of the server’s “state”? What about BIOS/NIC/HBA/iLO firmware? What about IPMI or advanced NIC settings or QoS or boot order or RAID settings or NIC Teaming or all of the other items that I have to configure in conjunction with the deployment of a server?

Cisco delivers at least eight times the number of managed settings in a UCS Service Profile when compared to what HP delivers in a Virtual Connect Server Profile.

 Here’s the comparison chart (updated 2010-08-27):

Click to Enlarge

Summary:
In all honesty, I am sold on the usefulness of statelessness. I’ve seen it deployed with huge success at a multitude of customers over the past several years. Centralizing AS MANY server configuration ‘knobs and buttons’ can only lead to quicker, more efficient, and more error-free server deployments. This allows the Server, LAN, and SAN teams to effectively coordinate the roll out of a new server with minimal effort. No one has to go look in 15 different locations to collect all the configuration information for a server to make sure it was done right or to troubleshoot a problem down the road. Cisco’s UCS Service Profile delivers this capability to customers today and delivers more than 8 times the features than HP.  And… we’re just getting started, folks. J

Tweet This Post