Supermicro’s macro Microblade: That chassis is… huge

Review Supermicro has a neat new product it calls “Microblades”. Supermicro has made blade servers for some time, and Microblades are blade servers, but smaller. Supermicro sent a chassis and a pair of blades over for review.

Each vendor has its own approach to server management, be that blade management or baseband management controllers, and Supermicro has chosen an interesting balance between features and cost. Supermicro has always focused on affordability by cutting back on what it sees as niche features while still maintaining the most in demand feature sets.

For baseband management controllers, this has worked to Supermicro’s advantage. If you buy a Supermicro server (or blade) with a baseband management controller, you’ll get an IPMI and Redfish compatible server management plane that doesn’t require you to pay extra for an IPKVM licence.

While the IPKVM licence to allow remote control of a server through the baseband management controller might not be a big expense on a 4 CPU server with 3TB of RAM, they get noticeable at the small end. Think about having to pay $500 to enable IPKVM functionality in iLO on your $500 HP Microserver. (I’m not bitter, really.)

The Supermicro approach to blades

Supermicro has taken a similar approach to the feature capabilities of its blades. The result is remarkable affordability. The flip side is that one of the major use cases for blades – the automation and centralisation of management – isn’t possible with software from Supermicro itself.

A Supermicro blade enclosure is really not that different from anyone else’s. It’s a box into which you place blade servers. On the other end of the unit are power supplies, and the ability to connect one or more management and switch modules, depending on the size of the chassis you purchased.

In the case of the Microblade chassis you can have three basic configurations. The first is a 3U chassis that can support up to 14 blades, with one management module and two switch modules. The second configuration is a 6U chassis that can support one management module and up to 4 switch modules. The last is a 6U chassis that can support up to two management modules and up to two switch modules.

The management module offers control over the whole of the chassis through a web interface. From here one can control basic elements of the various connected devices. This includes powering on or off, updating firmware, remote controlling and monitoring.

One of the little things that really tickled me was the awareness of power that the management module had. It is aware of how much power devices can consume and, for example, refused to let me power up both blades until I had plugged in at least two of the power supplies. Supermicro’s blades also have the ability to set power policy if too many power supplies fail. You can power off certain blades or throttle most of them. You can even set a power cap on a per-blade basis.

To me, this is pretty neat stuff, but it’s all pretty basic as far as blades go. (Which just goes to show how often I work with blade chassis.) Supermicro’s offering here are where Dell, HP and Cisco were several years ago, and for most use cases that’s perfectly fine.

What Supermicro doesn’t offer is a multi-chassis management software solution. Each chassis is its own universe in Supermicro’s world. The lack of that management solution also means there is Supermicro software for provisioning blades. If you want to load up operating systems or configure the switches you have to do that manually or through third party software.

This lack of management software won’t win a lot of friends in the hard-boiled legacy infrastructure community, but it’s not really much of an impediment to the hyperscale types. They’re all about provisioning through PXE booting and are used to working with “dumb nodes”.

For hyperscalers IPKVM capability combined with the chassis-based power management and monitoring is already a cut above what they’re used to. Normally, hyperscalers won’t want to pay for the extra gubbins. They won’t be buying Supermicro’s traditional blade solutions.

But they just might buy these Microblades.

A dense mass

For reasons I will never fully understand, Supermicro sent me a 6U chassis to test two blades. This gave us lots of opportunity to appreciate just how damned huge this Microblade chassis is. And it’s huge. It’s bigger than huge.

At 265mm x 449mm x 875mm (10.43″ x 17.67″ x 34.45″), it may be the single largest thing you can put onto a rack, and it probably isn’t going to fit onto most racks. The chassis alone, with just power supplies and no blades, is over 90kg (200lbs).

Moving a Supermicro server is a two-man job unless you employ Hodor, or if your organisation takes the term “forklift upgrade” literally.

And then you add blades. The blades themselves are compact at 1.2″ x 4.94″ x 23.2″ (30.48mm x 125.48mm x 589.28mm). Up to 28 blades can be put into a 6U chassis.

The blades come in flavours. One variant crams 4x Intel Avoton Atom nodes into a single blade. Each Avoton node can have 32GB of RAM each and 1x 2.5″ drives per node. That’s 112 Avoton nodes (896 cores) crammed into 6U.

The two blades Supermicro sent me were 2x Xeon-based blades, one with Xeon v4 chips and one with Xeon v3 chips. These blades will support Xeon E5 2695 CPUs with have 18 cores (36 threads) per chip.

28 blades each with 2 Xeon E5 2695 CPUs, 256GB of RAM and 2x 4TB 2.5″ SSDs would provide 2016 logical cores, 7,168TB of RAM and 448TB of storage in 6U. I don’t want to know the cost because I’d bet it rivals my house.

I remember when that kind of compute would have taken half a continent. Now it fits under my testlab table.

Practical considerations

Other than the size of the Microblade chassis (did I mention it’s enormous and heavy?) I was able to glean a few useful impressions from my time reviewing the device. Perhaps the most important thing to remember is that the switch modules don’t automatically power on when you plug in the device.

I realize it is probably revealing of my personal idiocy, but I banged away at that thing for a day before I realised the reason I couldn’t see any of the nodes was that the dang switch wasn’t turned on. The command module doesn’t use the switch. It has its own NIC. So you can cheerfully log into the management UI and even remote control blades all without the switch being turned on.

Without the switch turned on, the unit isn’t all that loud. No more than my 10GbE switch, for example. When we turned on the switch module, however, the unit was so loud that the lab’s cat jumped three feet straight into the air, kicked in the warp drive, and disappeared in a howl of protest.

Do not engage Microblade chassis switch without hearing protection. Do not do.

Swapping blades around is pretty easy, and the unit seems to remember settings for them. If I configured power thresholds for a blade they seemed to bind to the blade, not the slot in the chassis, so when I started moving the blades about the settings followed.

The chassis seems to be perfectly okay with you playing musical power supplies while the thing is lit up. I didn’t have redundant command modules or switches, so I can’t tell you anything about how it deals with changing those out.

Parting thoughts

Overall, my impression of the Microblade solution is good. To be honest, I’d like to see a multi-chassis management platform with some way to provision blades in a reasonably automated fashion. Given how Supermicro works, that will likely come from a third party, but perhaps Supermicro should get busy on partnering and listing those partners on its blade chassis webpages.

Other than that niggle, however, it does what it says on the (very large) tin. If you want to cram a whole lot of oomph into a very small space, this will do. It doesn’t quite have the density of HP’s Moonshot chassis, but it has more flexibility as regards the type of blades.

In all, it’s very Supermicro. It is just that little bit more than good enough and it’s up to you fill in the rest. And with that, I must be off: I really should go find the cat. ®

Sponsored:
Best practices for writing a successful NSF MRI grant proposal