You may have noticed some slight disruption on the website last night, here is why. After a few weeks of planning, research and development, we've finally bought up an array of 10 mbeds to serve the mbed cloud.

One of mbeds earliest mantras is "eat your own dog food", a philosophy that has lead to us developing the core mbed libraries within the online compiler and the site from within itself.

After some great work done by the mbed community, most notably Rolf Meyer's HTTPServer and Igor Skochinsky's USB Host mass storage class, it became technically feasible to serve the mbed website from mbed hardware. The opportunity to eat our own dog food again proved too tempting.

Setup

It was clear that the mbed array needed a little assistance, and so a commercial load balancer was used to distribute the incoming request amoung the 4 webservers. Each server has it's own 16Gb USB Flash drive attached, and is dedicated to serving specific content, namely Web/Forum/Blog, the compiler, users A-K, users L-Z.

The remaining 6 mbeds are used as parallel processing nodes, each one containing the same library of standard tasks needed to keep the infrastructure going. The webservers break down the requests into serialised sub-tasks and farms them to the nodes, which are all hooked up essentially in parallel.

The initial setup employs AA NiMH batteries as the power source, which means UPS functionality is provided by design.

Installation

The existing infrastructure remains in place during this experiment so we can switch back quickly if there are any hiccups.

We unpacked the prebuilt and pretested breadboard based system that makes up the new server cluster. If the experiment goes well, this will be turned into a proper PCB implementation, with clusters of 16 mbeds.

The assembly was moved into position in the rack.

Cliff the IT guy was drafted in, partly to make sure we didn't unplug stuff we shouldn't, but also to help hook it all up, ensure there were enough network ports, power ports and so on.

The array of mbeds is installed, the four webserver/disks visible to the right, and the six nodes visible on the left. There is nothing left to do but power it up....

In thier new home, the development board powers up and is all looking good. There are a few anomilies with IP addresses which are soon resolved. The mbeds are reporting over their USB serial ports that they are functional. Last step is to flick the switch that tells the load balancer where to point incoming traffic to.

Success!

Conclusion

If it all runs well, we'll start work on PCB of mbeds that will have a backplane architecture so it can scale with the site.

The final architecture we're aiming to implement is :

The clusters will be broken down on a per function basis, so the clustering is hierarchical. We'll also look to make the load balancers based on mbed, so only the border router is dedicated non-mbed hardware.

There is a lot of work to be done still, but this is a great first step.

The changeover went a lot smoother than expected, and the mbed cloud is handling the traffic quite well.

Of course, there are both pros and cons to the new setup.

Pros:

• Adding nodes to the mbed cloud is cheap and easy
• USB stick storage is solid state - means no risk of disk failure
• Near zero boot time for servers!

Cons:

• The actual CPU power available has been reduced, so try to not make unnecessary compiles. Also, excessive compiles will run our batteries down faster
• The batteries will inevitably eventually run flat, and unfortunately the website will be unavailable while we recharge them