What exactly are you trying to fix that you're thinking about a Rpi cluster?
From when I was looking at clusters, the application needs to be able to handle it. But, I have not looked at it for a few years now....
Someone will correct me, but unless you compile indi to run on a 'cluster' (ie: a real clustered computer area), then you'll be wasting your time and money.
RPI2 and Odroid C1 are more than capable of running an Indi server as it's not using that much memory or CPU power anyway.
I'm afraid that "compile for cluster" is not enough, it should be "programmed for cluster" and it is not. Resource requirements of anything except for CCD drivers are negligible and CCD drivers have "single-threaded" nature, there is nothing what can be optimized for a cluster.
BTW, single Odroid C1 with eMMC module is probably faster and cheaper than 4x RPi with SD cards. The only limitation is number (and powering) of USB ports, but even if you will use multiple computers, there is no reason to cluster them, simply use one for imager, one for guider and one for everything else.
What can make all this easier is to add some kind of service discovery technology to INDI. In servers and clients for OSX we're using Bonjour and you are (from user perspective) just connecting to available "devices", not "servers". I think, that it is the same technology as Avahi on Linux. Peter
Exactly. If there is some need for synchronization, it can be accomplished by "snooping" over INDI protocol, there is no real use for cluster. We can call it "INDI cluster"