IBM

You are currently browsing articles tagged IBM.

VMware, This is Wrong

Thursday, May 28, 2009 in Microsoft, Virtualization by slowe | 11 comments

UPDATE: VMware has clarified their position; they will allow competitors to exhibit at VMworld. The text in the exhibitors agreement was legalese—supposedly consistent with other major vendor-sponsored conferences—meant to give them an out in the event an exhibitor behaves inappropriately.

I sincerely hope that Brian Madden is wrong about the recent change to vendor policies for VMworld.

This is exactly the wrong thing to do in this sort of competitive landscape. You know, earlier this week on the Virtual Thoughts podcast, I was defending VMworld’s move into the territory of their former ISVs with products like vCenter Data Recovery, vCenter Chargeback, and vCenter ConfigControl. After all, VMware is a publicly owned company, and they have to show value to their shareholders. But this? This doesn’t have anything to do with showing value to the shareholders. This is like a spoiled little kid saying, “This is my sandbox, and you can’t play in it.”

What are you going to do, VMware? Let’s see, you’re expanding into the territory formerly handled by many of your ISVs, and now you’re blocking access to competing products at VMworld. So who will be at VMworld? Let’s see…

  • Vizioncore can’t come, because vRanger Pro overlaps functionality VMware will provide in vCenter Data Recovery. And vFoglight overlaps with CapacityIQ.
  • VKernel can’t come; again, they overlap with CapacityIQ.
  • As Brian Madden mentioned, Quest won’t be there due to a conflict with VMware View.
  • Microsoft won’t be there, because they won’t be able to talk about Hyper-V. True, they could come and not talk about Hyper-V, but I suspect they’ll also act like a spoiled child by saying, “If we can’t play by our rules, we won’t play at all.” Hmm…considering 90-95% of all the workloads running on VMware are Microsoft Windows, that’s an interesting situation to create. Oh, and VMware: are you prepared to be excluded from Tech-Ed too?
  • Ditto for Citrix. And probably ditto for being allowed to exhibit at Synergy. So much for VMware vSphere being the best platform on which to run XenApp—you won’t get the chance to make that claim!
  • Leostream? Nope—conflicts/overlaps with VMware View.
  • What about Hyper9? Not sure, vCenter Server 4.0 does provide a Search feature now, so that could potentially preclude Hyper9 from coming, too.
  • Surely Veeam could come, but they can’t talk about Veeam Backup (conflicts with vCenter Data Recovery).
  • esXpress? Nope.
  • Hardware vendors—IBM, HP, Dell—will be there.
  • Storage vendors—EMC, NetApp, HP, Compellent, Dell—will be there.
  • Networking vendors like Cisco and HP will be there. Unless VMware thinks that HP’s networking functionality isn’t complementary enough to its own virtual networking functionality…

I’m sure that I’ve overlooked some companies, but it sounds to me like the vast majority of the third-party ISVs now find themselves precluded from exhibiting at VMworld, in addition to finding themselves competing head-to-head with VMware in their own markets. Looks like the exhibit hall is going to be a lot less crowded this year!

Is VMware the new Microsoft? I’ll let you answer that one on your own.

Disclaimer: Before anyone jumps the gun and says otherwise, note that these opinions are mine, and are not endorsed by my employer or any vendor or other organization.

Tags: , , , , , , , , , , ,

Implementing IBM BladeCenter Open Fabric Manager

Thursday, May 7, 2009 in General by adelp | 4 comments

By Aaron Delp
Twitter: aarondelp
FriendFeed (Delicious, Twitter, & all my blogs in one spot): aarondelp

A few months ago I implemented the Basic version IBM’s BladeCenter Open Fabric Manager (BOFM) and I wanted to share some of my notes with everyone. It has been awhile so this is very high level; most of the small details have since fallen out of my head.

If you don’t know what Open Fabric Manger is, BOFM allows you to virtualize the FC and Ethernet connections coming from a blade server. BOFM is IBM’s response to HP’s Virtual Connect.

In very simple terms, BOFM overrides the default adapter Ethernet MAC and FC WWN’s and replaces them with MAC’s and WWN’s that are generated by BOFM at the BLADE SLOT level. If you have a blade in the first slot in a chassis and you replace the blade, the MAC and WWN stays the same because OFM will again over ride the defaults on the replacement.

BOFM is offered in two versions, the Basic version and the Advanced version. The Basic version is implemented in the BladeCenter Advanced Management Module and provides BOFM functionality for that chassis and provides slot level redundancy only. Each blade slot in the chassis has a profile and this profile is static.

Advanced BOFM takes this concept a step farther. Advanced BOFM is a plug-in to IBM Director and allows management of multiple chassis from a single location. Furthermore, it also allows for a “hot-spare” blade. A profile on a slot can be copied to another slot in the case of a failure. I did not implement this feature but I will include a link to a GREAT document at the end of this article that explains the hot spare process.

Why is BOFM a good thing? The main reason for BOFM is one time set up of the network and storage. If you work for a large organization where a network team is required to configure the Ethernet ports and a SAN team is required to configure the FC ports, replacement of parts requires interaction with other team members that may or may not be available for changes on short notice. Also, if your organization utilizes change control then tickets may have to be generated, meetings, approvals… all that fun stuff that comes with Enterprise administration with multiple teams.

What does BOFM bring to virtualization? The answer is it depends. If you are using VMWare and you are running HA and DRS in your cluster, does it make sense to have a blade sitting idle in the chassis doing nothing because it is a hot spare? No, it doesn’t. That blade should be in the cluster participating and providing resources. If you are using VMWare in a non-HA and non-DRS environment or some other “stand alone” virtualization product, it could make sense because you would like another blade to fail over and be back up and running as quickly as possible.

Useful BOFM Links:

BOFM Manual

BOFM Technical Doc (explains Advanced BOFM and hot spare set up)

BOFM File Reference (Go under Reference -> Components -> Configuration File)

Tags: , ,

A Collection of Viewpoints on Cisco UCS

Friday, April 3, 2009 in Networking, Virtualization by slowe | 9 comments

A couple of weeks have passed since the announcement of Cisco’s Unified Computing System (UCS), and in that timeframe I’ve collected a number of links to articles and blog posts about UCS. I thought I’d collect them here and try to get a feel from all of the various viewpoints where the industry stands on UCS.

I’ll start with Robin Harris aka StorageMojo and his initial take on UCS. The one thing that jumped out at me about his article was this statement:

If IBM, HP and Sun aren’t meeting today to plot a radical, Cisco margin destroying open-source router & low-cost switch counterattack – like Seagate, HP and IBM performed on Quantum’s DLT – they’re idiots.

This seems to validate the strategy outlined by Sun and sheds new light—for me, at least—on the potential motivations for IBM to acquire Sun and, thus, Sun’s intellectual property. Is Big Blue’s move to acquire Sun a precursor to a strike against the heart of Cisco’s routing and switching business? And how would Cisco respond to just such a move?

Massimo Re Ferre’ of IT 2.0 approaches UCS from a different angle. According to Massimo, if you stop and really look at what you get from UCS, it’s not terribly different from what you can get from other vendors. In fact, if you separate out the unified fabric, there really isn’t a whole lot to distinguish UCS from other, similar solutions from HP, IBM, Dell, and Sun. And if you think about it, he’s right—it’s really only the unified fabric, along with the fabric extenders in the chassis and the single point of management, that differentiate the platform.

Therein lies the problem. Massimo points out a couple of potential problems with unified fabric (security and political/organizational challenges). If unified fabric doesn’t fly, then UCS is grounded too. And industry excitement over FCoE isn’t exactly the greatest in the world. Chris Evans aka The Storage Architect makes clear his feelings about FCoE in this post:

FCoE is a Cisco strategy to own the data centre, nothing else. As the recession bites, it would be a brave soul who could justify the disruption and additional spend, for very little gain.

FCoE is hardly a forgone conclusion, and given that so much of UCS’ value is tied up in the unified fabric and the results that come from it, that makes UCS awfully vulnerable.

Not everyone thinks that FCoE makes the UCS vulnerable, by the way; technology evangelist Christopher Kusek thinks the future will be a unified one:

The Data center has spoken and it’s answer is True unification.

Burton Group analyst Drue Reeves says that this was a move Cisco had to make:

In the end, UCS was a move Cisco had to make to ward off competition AND increase shareholder value. Cisco has a strong brand, enterprise credibility, the technical chops and finances to pull it off. Is UCS a business risk? Sure. But the greater risk for Cisco is to do nothing.

Perhaps, perhaps not. Given that UCS relies so heavily on FCoE, wouldn’t it have made sense for Cisco to push the FCoE train along by providing FCoE interconnects for blade servers from HP and IBM? Of course, this is supposing that CNAs would be available for HP and IBM blades, but I’m sure that this is something Cisco could have helped guarantee. This route would have broadened the market for FCoE and the unified fabric and simultaneously establishing Cisco as the FCoE leader (as if they weren’t already). Then, when really game-changing stuff like the SR-IOV-enabled adapters like “Palo” were available, Cisco could have taken the leap into the compute space and played the unified management card. That seems like a less risky approach to me. But hey, what do I know?

Tags: , , , , , , , ,

Blades and Virtualization Aren’t Mutually Exclusive: Part Four, HP Traditional Expansion Options

Monday, February 16, 2009 in Virtualization by adelp | 20 comments

By Aaron Delp

Welcome to Part 4 in our series on blades and virtualization. Please note that I will be covering the HP virtualized I/O offerings in a near future post. I plan to cover Virtual Connect, Flex-10, and the BL495 blade at that time.

As always, let’s start by reviewing the hardware specification we will be using to compare the rack servers against the blade servers. Here are the portions of the spec that concern us:

  • A minimum of 32 GB memory – As many have commented and my own studies have shown, memory is usually the first limiting factor. The more memory you can install in the system, the better.
  • 2 on-board NICs + some combination of expansion cards (FC, iSCSI, NIC, 10Gb)

As we did for the IBM side, let’s start with memory. The maximum amount of memory available on the DL360 is currently 64GB when using 8GB DIMMS in each of the eight slots. The BL460c has the same memory configuration (8 slots), but has a few caveats depending on the processor power consumption. According to the HP Product Bulletin Tool, if the processor is 80W or below, then the max amount of memory is 64GB (8x8GB). If you would like to use processors above 80W, then the maximum amount of memory is 48GB in a 6x8GB configuration. Which processors take above 80W you ask? As of this writing, there are only 2 processors in this category, the 3.0GHz Quad Core (Intel X5450 chip, not the E5450 chip!) and the 3.16GHz Quad Core (Intel X5460).

As with the IBM solution, I will explore four possible transport technologies for virtualization: 10Gb, iSCSI, FC, and NFS. I will also fill any remaining expansion slots with 1Gb Ethernet ports. Just like the IBM Chassis, we have a maximum of eight expansion ports.

HP expansion is a little more straightforward than IBM. Bays 1 & 2 connect to the blade on-board NICs and must be populated with an Ethernet compatible switch. An HP BL460c blade has two expansion slots, labeled Mezzanine 1 & 2. Bays 3 & 4 on the chassis connect to the adapter in Mezzanine Slot 1 on the BL460c Blade. Bays 5-8 connect to Mezzanine bay 2 on the blade. If a dual port card is placed in Mezzanine 2, only Bays 5 & 6 will be active. A four port card is required (Ethernet is the only 4 port card currently) to access all four switch bays.

The only exception to the above port mappings is 10Gb. Like the IBM 10Gb switch, the HP 10Gb switch is a “double wide” switch. For dual 10Gb in the HP chassis, one switch must be placed in Bays 5/6, the other in Bays 7/8.

Here are the possible configurations given the port mappings above:

BL460c blade with 10Gb & 4 NICs:

Dual On board NICs Bays 1 & 2 (Ethernet switches)
Mezz 1 – Dual Port NIC Bays 3 & 4 (Ethernet Switches)
Mezz 2 – Dual Port 10Gb Card 5/6 – 10Gb switch & 7/8 10Gb switch

 

BL460c blade with 10Gb, 2 NICs, and 2 FC:

Dual On board NICs Bays 1 & 2 (Ethernet switches)
Mezz 1 – Dual Port FC Card Bays 3 & 4 (FC Switches)
Mezz 2 – Dual Port 10Gb Card 5/6 – 10Gb switch & 7/8 10Gb switch

 

BL460c blade with FC & 6 NICs:

Dual On board NICs Bays 1 & 2 (Ethernet switches)
Mezz 1 – Dual Port FC Card Bays 3 & 4 (FC Switches)
Mezz 2 – Quad Port 1Gb Card Bays 5-8 Ethernet switches

 

BL460c blade with iSCSI & 6 NICs:

Dual On board NICs Bays 1 & 2 (Ethernet switches)
Mezz 1 – Dual Port iSCSI Card Bays 3 & 4 (Ethernet Switches)
Mezz 2 – Quad Port 1Gb Card Bays 5-8 Ethernet switches

 

BL460c blade 8 NICs:

Dual On board NICs Bays 1 & 2 (Ethernet switches)
Mezz 1 – Dual Port 1Gb Card Bays 3 & 4 (Ethernet Switches)
Mezz 2 – Quad Port 1Gb Card Bays 5-8 Ethernet switches

 

As you can see from the tables above, HP has a nice round portfolio without any holes. In the next section we will be covering the IBM virtualized I/O solutions.

Tags: , , , ,

Blades and Virtualization Aren’t Mutually Exclusive: Part Three, IBM Traditional Expansion Options

Friday, February 13, 2009 in Virtualization by adelp | 15 comments

By Aaron Delp

UPDATE:  I have made some corrections to the 10GB and iSCSI sections based on feedback.  Thank you!

Welcome to part 3 of my series on blades and virtualization. I will be breaking the expansion articles into four parts: traditional IBM options, traditional HP options, virtualized IBM options, and virtualized HP options. By “virtualized options” I mean the IBM and HP blade I/O virtualization solutions (like IBM Blade Open Fabric Manager and HP VirtualConnect), not a server configuration that will run virtualization. Today, we will be covering IBM traditional options.

Let’s take a second to revisit a portion of our hardware standard we have been using for the power series and make a few additional notes. Here is the spec again:

  • A minimum of 32 GB memory – As many have commented and my own studies have shown; memory is usually the first limiting factor. The more memory you can install in the system, the better.
  • 2 on-board NICs + some combination of expansion cards (FC, iSCSI, NIC, 10Gb)
  • 2 x 146GB, 10k SAS drives (except the IBM HS21XM blades which only support one HD)

I will get into the expansion options in a second, but let me start with the memory since this is the area most people are concerned about. With the recent addition of 8GB DIMMS to the HS21XM product line, the HS21XM now supports 64GB of memory. The IBM 3550 supports a max of 32GB and even the IBM 3650 only supports 48GB. If memory is your concern, the IBM blade is actually the BEST fit for virtualization.

Another area of concern is the fact that the HS21XM only supports one hard disk. If you would like to boot the OS from a local disk, this can be an issue. IBM also offers the dual solid state drive in a RAID-1 configuration but both platters are mounted in the same enclosure so if you lose one, you need to replace them both. We know because it happened to one of our customers. In the end that doesn’t make sense either. I don’t see the actual ESX build as critical in a VirtualCenter environment so I usually don’t worry about it excessively.

The expansion cards can get a little tricky depending on the configuration. For virtualization I see four possible options to fill out the blades to meet our needs. They are FC, 10Gb, iSCSI, and NFS. We will fill any remaining expansion with Ethernet 1GB ports to provide as much connectivity as possible.

Above is a picture of an IBM BladeCenter H Chassis from the rear, highlighting the expansion bays. Bays 1 and 2 connect to the onboard Ethernet so the switches must be Ethernet compatible. Bays 3 and 4 connect to the first expansion card on the IBM Blade, often called the CFFv form factor. The v in CFFv stands for “vertical” meaning this card will talk to the vertical expansion switches.

Bays 7-10 often cause much confusion.  They are positioned horizontally in the chassis and connect to any CFFh (h for horizontal, get it?) card on a blade. A number of different switches can be inserted into these bays. The first one is the easiest one, the 10Gb switch.  The first switch would go in bay 7.  The second would go in to bay 9.  Each switch would connect to a port on the dual port 10Gb card.

UPDATE: You can also do a 4x10GB configuration by adding 2 more 10GB switches in Bays 8 and 10.  You will then need the 4 port 10GB card instead of the 2 oprt 10GB card.  I have updated the charts below to reflect the MAXIMUM number of connections.  You can of course go with less.

The second option for Bays 7-10 involves something called the MSIM (Multi-Switch Interconnect Module). This option will allow the FC, iSCSI, and NFS configurations. The MSIM is an adapter that divides the High Speed Bays into Bays 7 to 10 shown above. To take advantage of all four bays, two MSIM’s divide both High Speed Bays and you will need a four port CFFh card to map to all four bays.

The above information yields the following switch and blade expansion card combinations:

Blade with 10Gb & 4 NICs (no MSIM’s – 4 NICs and 4 10Gb per blade):

Dual On board NICs

Bays 1 & 2 (Ethernet switches)

Dual Port Cffv NIC

Bays 3 & 4 (Ethernet Switches)

Dual Port 10Gb Card

Bays 7,8,9,10 (10Gb switches)

 

Blade with 10Gb, FC & Eth (no MSIM’s – 2 NICs, 2 FC and 4 10Gb per blade):

Dual On board NICs

Bays 1 & 2 (Ethernet switches)

Dual Port Cffv FC Card

Bays 3 & 4 (FC Switches)

Dual Port 10Gb Card

Bays 7,8,9,10 (10Gb switches)

 

Blade with FC Option #1 (requires 2 MSIM’s – 2 FC and 6 NICs per blade):

Dual On board NICs

Bays 1 & 2 (Ethernet switches)

Dual Port Cffv FC Card

Bays 3 & 4 (FC Switches)

Quad Port Cffh NIC

Bays 7,8,9,10 (Ethernet switches)

 

Blade with FC Option #2 (requires 2 MSIM’s – 2 FC and 6 NICs per blade):

Dual On board NICs

Bays 1 & 2 (Ethernet switches)

Dual Port Cffv NIC

Bays 3 & 4 (Ethernet Switches)
Dual NIC and Dual FC Cffh Card

Bays 7,9 (Ethernet) & 8,10 (FC)

 

Blade with NFS or software iSCSI (2 MSIM’s – 8 NICs per blade):

Dual On board NICs

Bays 1 & 2 (Ethernet switches)

Dual Port Cffv NIC

Bays 3 & 4 (Ethernet Switches)

Quad Port Cffh NIC

Bays 7,8,9,10 (Ethernet switches)

 

You will notice that only 3 of the 4 options are given. Hardware-based iSCSI is missing. That is because IBM has a hole in their portfolio. The IBM iSCSI card is the older form factor that if used on an HS21XM blade it doesn’t allow any other card. So, you end up with 2 NICs and 2 iSCSI. This isn’t acceptable and isn’t a valid option.

So what do you think? I believe that any of the above configurations will suit virtualization nicely given a proper design. I look forward to your thoughts as we continue on to the next article, HP traditional expansion.

Tags: , , , ,

Alas, BladeVault is No More

Sunday, February 8, 2009 in General by slowe | 4 comments

It doesn’t take long these days: yesterday the bladevault.info and bladevault.com domains, owned by friend and colleague Aaron Delp, expired. Today they were picked up by an unknown registrant and are serving up ads.

Fortunately, Aaron’s moved most of his content over to his new blog, and is also contributing great blade-related material here, such as these two recent articles:

Blades and Virtualization Aren’t Mutually Exclusive: Part One, HP Power Sizing
Blades and Virtualization Aren’t Mutually Exclusive: Part Two, IBM Power Sizing

Aaron’s already told me that there’s more in store for this series of articles, and I’m looking forward to his continued analysis of the benefits of blades and virtualization together.

So, if you visit bladevault.info and can’t find what you’re looking for, have a trip over to Aaron’s new blog home and look there. Farewell, BladeVault…

Tags: , , ,

Blades and Virtualization Aren’t Mutually Exclusive: Part Two, IBM Power Sizing

Saturday, February 7, 2009 in Virtualization by adelp | 6 comments

By Aaron Delp

This is the second part of a series of articles on Blades and Virtualization. The first article is found here. Today, I will present IBM rack servers versus blade servers and explore the power consumption for each.

In case you need it again, here is the hardware platform I will be using as the standard:

  • 2 x E5450 3.0 Ghz quad-core processors
  • 32 GB memory in an 8 x 4GB configuration
  • 2 on-board NICs
  • Additional quad NIC card for a total of 6 NICs
  • Dual FC card (assuming FC SAN storage for VMs but it could easily be NFS or iSCSI as well)
  • 2 x 146GB, 10k SAS drives (except the IBM HS21XM blades which only support one HD)

Here is the link to the IBM System x and Blade Power Configuration Tool I used for the numbers below. Using the hardware specifications above, I will be comparing the IBM System x 3550 server against the IBM HS21XM blade server.

Let me start by giving you a little history of the IBM Power Tool and note some limitations that may skew these results slightly. In case you haven’t used it before, the IBM tool is a little rough around the edges. Not all of the products and configurations are included in the tool. The Power Tool was started as a side project by some members of the IBM Brand Team a few years ago and was picked up by IBM as a product. Although I knew the original authors before they moved on to other jobs, I am not sure who keeps it up to date today.

The System x 3550 calculations are pretty accurate but the IBM Blade Center calculations are missing a few pieces. The tool will only allow for up four switches in the chassis. Even though you can configure two MSIM’s to enable the additional switch bays, you can’t choose the additional switches in the tool. Also, the IBM Blades section of the tool won’t allow for the CFFh expansion card that would attach to the switches. So, these calculations are missing four switches per chassis and one expansion card per blade. Not a big deal but I wanted to point it out. Also, please remember that all calculations assume 100% utilization of the server(s).

With all of that out of the way, what does a fully loaded IBM chassis look like compared to rack servers? An IBM BladeCenter H Chassis holds fourteen servers so we will begin there:

14 Servers (Full IBM Chassis)

3550’s

HS21XM’s

% Savings

Total System Power Input (W)

7028

4869

30.72

Total System Input Current (A)

33.6

23.41

30.33

Total System BTU/Hr

23954

16614

30.64

Total System VA Rating

7168

5098

28.87

 
As you can see, from a power perspective, the IBM blades are pretty impressive! We are looking at approximately 30% savings in all areas versus IBM rack servers. Let me be very clear on one point though: I am not stating that IBM blades are more power efficient than HP blades (I know that comparison is right around the corner for many of you). For many reasons that I won’t go into here, I don’t believe you can make a jump to that conclusion based on the numbers. I am stating that IBM blades are more efficient than IBM rack servers, nothing more.

How about a chassis that is half full with seven servers?

7 Servers (Full IBM Chassis)

3550’s

HS21XM’s

% Savings

Total System Power Input (W)

3514

2732

22.25

Total System Input Current (A)

16.8

13.14

21.79

Total System BTU/Hr

11977

9324

22.15

Total System VA Rating

3584

2873

19.83

 
We are seeing 20% or greater with a half full chassis. Again, the numbers are very nice.

Lastly, what is the breakeven point? For the IBM blades the breakeven point is four servers.

4 Servers (Full IBM Chassis)

3550’s

HS21XM’s

% Savings

Total System Power Input (W)

2008

1805

10.10

Total System Input Current (A)

9.6

8.68

9.58

Total System BTU/Hr

6844

6159

10.00

Total System VA Rating

2048

1907

6.88

 
The most interesting bit of information I find with these numbers is the difference the fourth blade makes. With three blades, you have slightly negative percentages (the rack servers are better). But, add the fourth blade and you are suddenly saving somewhere near ten percent. I find that odd.

My conclusion this time is a cut and paste of last time (almost literally!). As with any consolidation project, there is a breakeven point with blade servers where the initial investment begins to pay off. Also, like virtualization, the more blades (or virtual machines) you add to the environment, the more savings you will see.

The next article will focus on the expansion abilities of both the IBM and HP blade servers. I know that expandability is a big concern for many readers, so stay tuned for Part 3!

Tags: , , , ,

Blades and Virtualization Aren’t Mutually Exclusive: Part One, HP Power Sizing

Wednesday, February 4, 2009 in Virtualization by adelp | 21 comments

By Aaron Delp

I have seen a lot of misconceptions recently when it comes to blade servers and virtualization. Many seem to think that if you are using blades you can’t use virtualization. Most recently, someone shared this article with me. I couldn’t disagree with this viewpoint more. I will explore the reasons why in the next few articles. For today’s article, I will present a foundation for comparison and I will use this basis going forward.

Bar none, the most common misconception surrounding blades is power consumption. Many think that blade servers consume more power than their rack mount counterparts. If you have ever seen a fully loaded blade chassis, I can see why many come to this conclusion. They are loud, move a ton of air, and require larger power circuits that many people don’t normally see in a data center (“Look at the size of that plug! This thing must be a power monster!”).

But, if you are installing more than a few servers, this isn’t true. First, let me present my basis for comparison and the tools I will be using. I have chosen a middle of the road VMware ESX configuration that is supported by both IBM and HP. Here is the configuration:

  • 2 x E5450 3.0 Ghz quad-core processors
  • 32 GB memory in an 8 x 4GB configuration
  • 2 on-board NICs
  • Additional quad NIC card for a total of 6 NICs
  • Dual FC card (assuming FC SAN storage for VMs but it could easily be NFS or iSCSI as well)
  • 2 x 146GB, 10k SAS drives (except the IBM HS21XM blades which only support one HD)

Here are the links to both the IBM and HP Power Tools:

Using the above configuration and tools yielded an IBM System x 3550 and HP DL360 in the rack mount category and the IBM HS21XM and HP BL460c in the blade category. I will cover HP today and IBM in a subsequent article.

If you plug the above specs into the DL360 tool and multiply by sixteen to equal the number of servers in a chassis you will get the results below. I then ran the HP Blade System Sizer tool and filled the chassis with an equivalent spec. In order to properly populate the blades with the expansion cards, I was required to also add all of the switches. I added six VirtualConnect Ethernet and two VirtualConnect FC switches. I also assumed the max number of power supplies and fans in all calculations. Both tools assume 100% utilization of all resources.

16 Servers (Full HP Chassis)

HP DL360’s

HP BL460c’s

% Savings

Total System Power Input (W)

7904

6021

23.82

Total System Input Current (A)

40

29.54

26.15

Total System BTU/Hr

26976

20530

23.89

Total System VA Rating

8432

6143

27.14

As you can see, even with the addition of eight switches in the blade chassis, you still save in excess of 20% in all areas. Pretty impressive no matter what you are running on the blades!

What if the chassis isn’t entirely full? How about 8 blades?

8 Servers (Half HP Chassis)

HP DL360’s

HP BL460c’s

% Savings

Total System Power Input (W)

3952

3396

14.06

Total System Input Current (A)

20

16.66

16.70

Total System BTU/Hr

13488

11579

14.15

Total System VA Rating

4216

3465

17.81

Still very nice results! Again, even with the switches in the blade chassis, you are saving in excess of 14% in all areas. The main story to tell here is this: the more populated the chassis, the more savings you will see.

What is the breakeven point from a power perspective with HP blades? The answer currently is five. Any less and the overhead of the chassis becomes a factor. Here are the numbers with five blades.

5 Servers (Half HP Chassis)

HP DL360’s

HP BL460c’s

% Savings

Total System Power Input (W)

2470

2361

4.41

Total System Input Current (A)

12.5

11.58

7.36

Total System BTU/Hr

8430

8052

4.48

Total System VA Rating

2635

2409

8.57

In conclusion, as with any consolidation project, there is a breakeven point with blade servers where the initial investment begins to pay off. Also, like virtualization, the more blades (or virtual machines) you add to the environment, the more savings you will see.

Thank you for your time! I will be covering the IBM comparison in the near future, so check back regularly.

Tags: , , , , ,

P2V With IBM Blades

Monday, November 3, 2008 in Virtualization by slowe | 3 comments

A colleague and a customer passed me some information late last week about performing physical-to-virtual (P2V) conversions on with blades in an IBM blade chassis. (This was with an older BladeCenter chassis, not the BladeCenter H chassis.)

Apparently, if you run a P2V on a blade in the chassis without first selecting the blade on the chassis’ KVM, then the resulting virtual machine does not have a CD-ROM drive. Users will have to shutdown the VM, add the CD-ROM drive to the VM, and then boot it back up again.

I’m guessing this is because access to the chassis’ shared CD-ROM drive is handled via the KVM. In any case, keep this in mind if you are performing P2V operations with older IBM blades.

This behavior was noticed using VMware Converter. I don’t have any information on whether other P2V products are similarly affected, but I suspect that they would be.

Thanks to Chauncey and Keith for the heads-up.

Tags: , , ,

New Blog

Thursday, January 31, 2008 in General by slowe | 2 comments

A friend and colleague of mine recently launched a blog of his own, The Blade Blog.  If the useful information that’s been posted there so far is any indication, this will be a definite addition to your RSS subscriptions.  Keep up the good work, Aaron!

UPDATE:  After some great feedback on the launch of his site, Aaron’s moved away from Blogger to a hosted WordPress solution and has gotten a new domain name.  You can now find Aaron at the Blade Vault.  More information and updated URLs available here and here.

Tags: , , ,

« Older entries