Hugo Mills wrote:
> On Wed, Sep 16, 2009 at 02:13:45PM +0100, Chris Simmonds wrote:
>> Hi and thanks to everyone who replied. I'm busy researching some
>> possibilities at the moment. However, just to clarify, the issue is high
>> availability among the 50 or so nodes so that any node can go down and
>> come back up again without impacting any of the others. There are no
>> servers as such, each node is potentially both a server and a client so
>> that if using a traditional database there needs to be some mechanism to
>> elect a master server if the current master goes down. The trickiest
>> case is if the network gets disrupted such that you get two separate
>> segments for a while - each with their own master - which then get
>> joined together again. On the other hand the amount of data is quite
>> small - maybe a thousand rows in SQL terms. Actually it doesn't have to
>> be SQL at all, I'm just using that as an example.
>
> You also don't specify the robustness requirements: of your 50
> servers, how many would you expect to be able to lose before data gets
> lost? You talk of one at a time going down and coming back up, but is
> it really a matter of a few vanishing at any one time, or could they
> all go at the same time?
>
> Can you give more details of why these machines are ephemeral? Are
> they on unreliable network connections? People's desktops at work?
> General purpose publically-accessible machines?
>
> What problem are you trying to solve with this system?
>
> Hugo.
>
Hi Hugo,
The application is theoretical at the moment, but the requirement comes
from a factory floor information system with multiple data entry points.
The HA part is optional, but as it is the most interesting part that is
the thing I have been concentrating on. However, I can see other
applications where there is a group of peers sharing a common data
store, for example a group of autonomous robots: if one trips up or gets
lost the others can carry on without it. Loads of fun!
