Hairy situation? Blade servers can reach where others can't Any follower of today's technology magazines will have heard a lot about Open Compute Project (OCP) servers. These are servers stripped down the bare minimum, crammed into a single chassis and managed centrally through software that provides high automation and data centre-scale orchestration. In an OCP world, cost reduction …
What about vendor lock in? Concepts such as dual sourced strategies become far harder to implement. Now I am not saying that this is not a problem in the un bladed world, but IPMI and heterogeneous monitoring and management packages have come a long way and help relive that problem. I cannot say that is the case for blades and blade enclosures. Although if you are going to deploy Blades for the sake of ease, perhaps it is right to say that you care less about the supply chain and keeping the vendor on his toes.
Also I truly dislike blades, they are in my opinion the union of the worst traits of networking, servers and storage all birthed in one bastardized package. In todays IT landscape I am pretty sure automation of network and compute and storage using COTS and API's which can be manipulated by boot images and/or then automation (puppet, chef, ansible ........) can provide the easy and prescriptive control you are assigning to blades, with a more flexible deployment pattern and less complex architecture, and likely less cost as well.
Fair enough I used to work in OCP, but my view on blades was formed well before that. It probably came about when a blade architect said to me "what do you mean you only have 4.5 KW per cabinet?"
Until I had to manage a room half full of them. Vendor lock in a described above is annoying, but not the worst trait. Wait until you have to manage firmware versions of all the chassis components, and the blades themselves. Then you discover there are firmware compatibility issues that cause a chassis to power cycle when a blade of particular version is inserted.
Or that you need to power cycle a chassis to perform an upgrade. Oh the joy of managing the contents of the chassis to do this.
I love the density and the theory of blades, but reality for those tasked with availability is not quite as rosy.
The biggest warning flag from a vendor lock in standpoint is when Cisco started selling servers. They recognise an opportunity to cup / squeeze testicles when they see it.
Power cycling chassis?? I hope you are joking. What kind of upgrade requires this?
Just to be clear, you can reboot the management modules without affecting the blades. They keep going but you lose comm via the admin module.
I have also heard of issues when inserting wildly outdated blades which end up affecting neighbors, but never the whole chassis. Please clarify your use of the term "chassis". I have dozens of customers who would bin their Blade systems if the chassis power cycled for minor updates...
I've been curious about blades for a long time, but I've been running my entire server infrastructure as virtual machines for over 10 years now. Density of nodes is irrelevant to me. Density of resource is a different issue, but it seems to me that I can cram more horsepower per U into a rack with 1U servers than with blades because the blades have lower individual performance (presumably due to cooling limitations).
I like the concept, but it just doesn't seem to add up. Maybe if you're running physical loads rather than virtual it's a clear winner. Otherwise I'll be keeping an eye on the DL360 quickspecs.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
