[Spread-users] Communicating between 130 hosts with Spread
jschultz at spreadconcepts.com
Wed Jul 31 18:11:06 EDT 2013
A spread deployment can usually handle thousands of clients served by at most a few tens of daemons. We typically do not recommend casual users to try running Spread deployments bigger than say 40 daemons or so (especially across a WAN) and even that size is usually massive overkill for most applications.
The primary advantage of running a daemon on the same machine as client applications is that the client-daemon communication doesn't go over the network. This means less traffic on your network and also that certain kinds of faults can't really happen (e.g. - network partitions, only one side of the connection abruptly fails, etc.) and/or are more easily and quickly detected. Furthermore, on *nix systems you can use IPC rather than TCP, which is less intensive on the CPU. Also, the more daemons you have then the more distributed the load of the system (i.e. - handling clients) can be across all the daemons.
Which structure of deployment is best for you depends on particulars such as what kind of throughput in Mb/s and msgs/s you expect to go through the system in total, how much redundancy you want in each site, what do you want to happen if the WAN partitions, etc.
As a rough guess at what might work for you, assuming your application isn't all that demanding, I'd guess that one Spread segment for your central office and one for each remote site each containing a few (e.g. - 3) daemons would suffice. Clients would (remotely) connect to one of the daemons at their local site, potentially failing over within a site if a daemon is down or even to another site if all the daemons in its site are down.
There's little need to get too fancy with depending on the network structure, VLANs, multicast, etc. Just run each spread segment in a LAN and so long as all the daemons in the system can talk point-to-point with all the other daemons in the system and your clients can reach their daemons then that would likely work for you.
If you are having lots of trouble or have more demanding needs than I guessed, then my company, Spread Concepts LLC, offers support contracts and would be happy to work with you on your particular problems.
PS - Does ATC stand for Air Traffic Control?
John Lane Schultz
Spread Concepts LLC
Cell: 443 838 2200
On Jul 31, 2013, at 5:23 PM, Jim Hague wrote:
We're looking into using Spread for distributing ATC surveillance data from a
central servers to a fleet of about 130 workstations. Most of these (~90) are
in the same building as the servers, on 3 different VLANs, but the rest are
distributed between 4 remote sites (one sharing one of the central VLANs, the
others with their own VLAN), with WAN connection to the centre.
Obviously we need the link to be reliable and highly available.
I've done some limited experiments with a couple of machines, configuring them
as described in the User Guide, and I like the look of Spread - it seems to
fit our requirements nicely. However, the User Guide talks about a maximum of
128 hosts/daemons per network segment and an overall limit of 128
So, an overall limit of 128 hosts would seem to suggest Spread might not the
thing after all.
However, I'm not clear from the User Guide as to whether it is
sensible/possible to have multiple hosts on a VLAN sharing a daemon, and if so
what the pros and cons of this might be. If possible/sensible, I envisage a
pool of hosts sharing a number of daemons, so that if a daemon-less hosts
loses the daemon it is using,, it can change to another in the pool.
I'm a near-complete newbie with Spread. Can someone more learned give me a few
jim.hague at laicatc.com Never trust a computer you can't lift.
LAIC Aktiengesellschaft +44 1865 980647 Mob +44 7941 697732
This message contains confidential (and possible privileged) information and
is for the named addressee or its intended recipients and others may not,
disclose, distribute, copy or use it. If you have received this
communication in error please:
1. tell LAIC either by return e-mail or by telephoning us on
+44 (0) 1342 321 873; and
2. delete the e-mail message and any copies.
Whilst we have taken steps to ensure that this message (and any attachments
or hyperlinks contained within it) are free from computer viruses and the
like, the recipient is responsible for ensuring that it is actually virus
free before opening it.
Spread-users mailing list
Spread-users at lists.spread.org
More information about the Spread-users