Hi,
I thought I’d post my latest project. I use a bunch of Raspberry Pi compute modules as servers and decided to build myself a custom blade server to host them. This is replacing a bunch of old Intel rack mount servers on my home network - it’s a lot less power hungry! It’s been through a few iterations and is now working really well. This is the server:
It’s a 2U rack mountable unit, in an off-the-shelf ABS case with some custom 3D printed parts. The server takes up to 10 of these blades:
It’s got gigabit Ethernet, USB-A and HDMI on the front and an NVMe SSD slot on the board, along with an SD card slot and a battery backed real time clock. There’s a little OLED on the front displaying information about the blade, including the name and IP address to make it easy to identify for maintenance. There’s also an RP2040 on it for management.
The blades plug in to a custom backplane which provides power and centralised management. There’s an LCD front panel providing basic tools for powering on and off blades and status information, and another compute module which acts as a management web server. It can be used to upload flash images to the blades via the backplane, and provides serial console access to the blades through the web interface.
I’ve been using this for a while now and was wondering if other folks out there are interested in it? It would be quite quick and easy for me to turn this into a product for sale if there was a market out there for it.
Please let me know any comments or suggestions you have, any feedback is appreciated!
Alastair
The backplane sounds interesting.
I’m guessing it doesn’t facilitate card-to-card data transfer (using something like a virtual NIC) since you’ve got everyone going to it’s own switch port (also a guess on my part)?
It seems like if you can use the backplane’s bus to update firmware, it might be able to move other data?
No matter how you slice it, this is pretty cool.
Thank you! Yes, you’re correct on your guesses. There’s blade to backplane/management server comms, but no direct blade to blade comms. As I’ve mentioned on a couple of other replies, it’s definitely possible to do a version of this where the Ethernet comes from the blade to the backplane over the PCI-e connector and into a switch on the backplane, so that you’d have all the switching done on-board and a single uplink port. It’s a much more complicated project to do though so not something I’ve tackled yet.
The blade uses PCI-e card edge connectors as they’re cheap, and I route UART0 (GPIO 14/15) and the USB from the compute onto this. There’s a USB switch IC on the blade which can route the CM’s USB output to either the host port on the front of the blade or through the backplane. The UARTs and USB are connected through switches on the backplane into the management module. The blades also have RP2040s on them which are connected to various pins on the compute modules, and the management module can talk to these using I2C. It’s able to use this for doing stuff like restarting the CM into provisioning mode, and for reporting status information. The RP2040 is connected via I2C to both the compute module on the blade and the backplane’s management module, so can be used for exchanging status information from within Linux on the blade with the management module. That’s how I get out status, temperature etc info. There’s no reason this couldn’t be used for other stuff too, and in theory could be used to exchange inter-blade data at I2C data rates.
The connector also passes out the RP2040’s UART and SWD as I use this to flash the firmware into the RP2040. I haven’t switched this into the backplane but in theory it could be too.
Very interesting. Thanks for the detailed reply. What a cool idea!