Featured Article
The Blade Is Mightier...
by Matthew Zito, Chief Scientist

I'll draw a line in the sand - blades are the future of servers. They are the best platform for just about everything today, and in the future, they will be the best servers for everything -- period. In fact, the things that blades are not good for today, in my mind, are the things that you shouldn't be doing with your servers to begin with.

But let's begin at the beginning: What is a blade server? A blade server is an increasingly popular type of server where servers and their infrastructure, like power, cooling, and network switches, are all combined together in a chassis. The servers themselves are typically denser than traditional servers, and since things like power and cooling are shared among a group of servers, there are efficiency gains to be found. For example, if a typical rack could hold potentially up to 35 servers plus networking equipment and power management, the same rack could hold 80 blade servers.

The value, though, isn't just in space efficiency. It's in consistency, centralized management, and scalability. Consistency is a step in the long-term vision of making the servers largely irrelevant to the running of applications and business processes. When every server is identical, infrastructure becomes hugely commoditized, because the networking equipment is identical, and the power management is easy to predict, Teams only need to keep a small pool of spare parts on hand, and how the infrastructure is going to scale becomes very predictable. In addition, each server becomes a compute unit in part of the larger clustered infrastructure. Need another web server? Pop in a blade. Need another database server? Pop in a blade. In the long term, when any particular area of the infrastructure needs more horsepower, reallocate blades from other areas to help with the processing.

A dose of reality -- despite what some of the blade vendors might have you believe: dynamic reallocation functionality doesn't come out of the box with blades . To achieve this grid vision, it takes software to handle resource allocation, SLA management, and the actual provisioning and configuration process. But whether you're looking at virtualization technologies, or automation like GridApp Clarity™ and the D2500 database appliance, the configuration consistency and standardization that comes with blade servers plays a significant part in achieving these infrastructure benefits.

The centralized management itself is also driven partially by having identical configurations, but the hardware vendor tools can typically add a lot of value, by giving information like aggregate power and cooling info, hardware status, CPU utilization, and other components. Blade server shops also get centralized remote KVM, one set of firmware upgrades to maintain, and universal power management.

All is not sunshine and roses in the blade world, however. The benefits of the blade architecture can also be its weaknesses. The biggest complaint about typical blade designs is their power and cooling requirements. While each server in a blade environment is more power efficient than its rack-mountable counterpart, the increased density can strain datacenter cooling requirements. The problem stems from the design of most datacenters that were built prior to the year 2000 (and even many being built today): they were designed with an expectation of cooling a certain number of BTUs per square foot. When they were based on typical rack-mount servers at a maximum of 35 per rack, facilities had plenty of excess cooling capacity. But when that number of shifted to possibly twice that per rack, in addition to the rapid growth in server heat production (as processors have gotten faster, they have become much hotter), suddenly datacenters are scrambling to cope. Even worse, many organizations roll out blades as part of a hardware refresh, meaning that part of the floor that's running the blades can be a "hot spot" compared to the rest of the floor, causing reliability problems and additional cooling costs.

The other issue with blades is that, inevitably, you're locking yourself into a proprietary architecture in one way or another. That is to say, blades purchased from IBM will not fit into an HP blade chassis, and Sun's blade switches won't work with Dell's blades, and so on. In fact, the hardware designs for the blades vary wildly as the various server vendors jockey for leadership in this area by focusing on particular areas, such as having the most connectivity options, or having the most powerful blades available. IBM has tried to resolve this to a certain degree by founding Blade.org, a trade and advocacy group, and opening their technology designs (which, incidentally, were co-built by IBM and Intel) to the general community. However, the other server vendors have largely gone their own way, leaving the customer in the position of picking a horse and running with it.

However, the potential benefits of blades far outweigh some of the negatives. In fact, most of the disadvantages of the blade design are not due to anything inherently wrong with the designs; the density and design are just not necessarily built to support the infrastructures around them today. But when it comes to performance, density, ease of management, and reduction in infrastructure complexity, blades can't be beat.

That's why we chose the IBM blade architecture for our D2500 database appliance. We loved the density and on-demand scalability of the blade architecture, and decided it was perfect for RAC environments. From there, we did a bake-off of the various vendors, designs, etc. and decided that the IBM BladeCenter would offer the most flexibility, highest performance, and, in general, the most elegant design. With the D2500, customers get the best of the blade architecture coupled with GridApp's management software to ease their path to RAC.

<< back