I’d like to understand why companies feel that blade servers are worthwhile investments. I recognise the arguments for higher density computing within standard rack enclosures, and moving “profiles” between enclosures, etc. These arguments aren’t much different from those used to justify virtualisation – and for what it’s worth, I completely agree with those arguments.
Where I get puzzled with blades though is that I see it as being essentially virtualisation at the wrong layer – at a deeper hardware layer than VMware other hypervisor style virtualisation. Looking at say, ESX as an example, we virtualise on a host and then provide a very generic hardware profile to the guests, and the guests share the hardware resources available.
Blades are essentially the same – but rather the sharing to me seems subtly different. Or to be more precise, the sharing seems to be less isolated. A blade can cock up and cause issues with other blades or the blade chassis – NIC, FC. Within a virtualised environment, this is much more difficult, from my observation at least. I can’t remember the last time I saw a single VM encounter such a significant issue that it took out an entire ESX server in an uncontrolled way.
Have I seen blades and blade servers do that? Yes.
So here are my general questions:
(a) Are blade systems as “reliable” as virtualisation systems?
(b) Other than providing a higher compute density, do blade servers provide more functionality than virtualisation systems?
(c) For users of blade servers – would you consider them to be more or less reliable than server virtualisation?
Don’t get me wrong, I’m not dissing blade servers, and I remain open-minded about them. But I need to understand them a little better than I currently do, and I’m open to having experts cite some “killer” examples of why my concerns are unfounded.
No related posts.
I think you’re considering the benefits of blade at the wrong layer, it’s not really a competitor to virtualisation, but a tool which compliments virtualisation while overlapping in some areas.
The primary benefits of blades for me are (in no particular order):
* Reduced physical cabling to top of rack switches
* Reduced power cabling (and normally, power consumption due to efficient PSUs)
* Ease of physical provisioning (push in the blade to a free slot, no cables + rackmount needed)
* Better support for technologies like PXE and remote KVM to ease administration and provisioning of new resources
However, most people don’t receive the benefits of blades because of things like their purchasing and provisioning policies. For example, it may take 3 months to get approval to buy a blade at $2000, or 3 months to get a $20000 new chassis full of blades approved – any IT manager is going to buy the $20000 full chassis in that situation, and go through the purchasing process less often.
Or the networking team may not like the network switches that the blade chassis comes with, and treat them as little islands of networking, adding layers of complexity to the configuration, or even worse, force the blade chassis to use an ethernet break-out box with 16 cables, 2 to each blade from the rack switches, rather than a pair of switches in the chassis.
Things like these can have a pretty big impact on the overall benefits of blades – they’re a good technology, but with some “softer” reasons why they sometimes don’t fit with a users’ environment.
Preston, like you I’ve seen entire blade enclosures experience problems and create an outage for multiple blades so your proposition that blades are putting too much into one basket is valid to the extent blades are deployed in any given data center.
Like anything else, jumping whole scale into blades is probably not a good idea for anyone. With careful planning and design I think blades are a fit for shops with large numbers of servers. In smaller shops they may make sense for QA/Dev or applications which aren’t business critical or even essential.
As Ewan points out, blade architectures can also create a highly distributed and complex networking (both LAN and SAN) infrastructure but realistically blade enclosure switch modules shouldn’t be considered as anything but top of rack switches deployed more densely.
Given the consolidation ratios possible with current hardware and hypervisors blade servers are probably less attractive, all things considered, than they were 5 years ago.
Late reply, I know.
I’m a sysadmin at a company working almost exclusively with x86 HP servers; we got aobut 100 servers, mostly DL380 G4, G5 and some G6. Our usual configuration for a rack of servers is:
- 42U APC Rack
- top of rack: 2 cisco switches, and 1 U free between them for cables. each switch with single power connection, each switch on a different UPS
- 19 servers DL380 (2U, 2 sockets, 8 SFF disks). each server with network teaming between the two switches in case a UPS takes down have the power.
For each server we have minimum: 2 power cables, 2 network cables, 1 network cable for iLO; that’s a minimum of 75 cables. If we also add FC connections for servers, that adds another 2 Fiber cables for each server.
If we’d be using DL360 (1U, 2 sockets, fewer disks); we could fit 39 servers in a rack with a number of cables of 150, we don’t use DL360 because we’re not that fond of them, and we are not even sure that we could manage that density of cables in the back of the rack, we already have enough problems with DL380, those cables have a suicidal tendency of mangling together, no matter how much we try to organize them; also they manage to pile up in front of exhaust fans so we’re not sure if they don’t affect negatively the airflow.
With c7000 chassis from HP we get:
- 16 blades with 2 sockets, 2 SFF disks
- “built in” cisco switches with gigabit connections to each of blades; which (i think) benefit from power load balancing built into chassis.
- “built in” (optional) cisco MDS switch to each server
- centralized iLO for all blades.
And all this in: 8U (I think); and the number of cables: 6 power lines, let’s say 2 uplinks per network switch, so 4 ethernet cables; and let’s say 2 uplinks for each FC switch, another 4 cables. Almost one rack worth of regular servers in 20% occupied space.
From a sysadmin point of view I get a fully redundant server without me messing with all those pesky cables, and worrying not to pull the wrong cable when I make an upgrade and I have to take the server out. Also, most of the servers are app servers, so a RAID1 of 2 146GB servers is enough; also, for DB workloads, two sockets populated with quad core is a lot of fire-power, and at that level you are probably not using internal disks, so the integrated MDS is a provides an easy to use robust FC connection. Working with a rack full of servers connected to FC I think it’s nightmare, you have to worry about too many fragile fiber cables each time you install or remove a server.
So, from my point of view, blades are appropriate for majority of real life scenarios, while increasing density, and removing cabling complexity.
On the other hand, increased density == increased heat; so cooling is a problem. For a diverse environment you can lower the impact by placing a chassis with “cooler” equipments, such as tape libraries; or old servers (think 4U-8U) that do not output that much heat.
The only worry I have is that one chassis has a system wide fault it takes down 16 servers; and that means a lot of services down. This is the only reason why we’re not that into blades; but for lower importance workloads we’re happy to use them and at least don’t worry about the cabling workload.
[...] yes to this. But I was still curious – as you may be aware, I’ve had some questions about blade servers in the past; and other than offering better rack density I see them having no tangible benefits. (Then again, I [...]