[Spread-users] New to spread and got some problems
John Lane Schultz
jschultz at spreadconcepts.com
Thu Jan 29 15:39:07 EST 2009
Sorry about confusing your and Tobias' names in the email thread.
Thursday, January 29, 2009, 1:01:25 PM, you wrote:
> Ah, splendid. Leader determinted by config file ordering? So I should
> make sure it is a less otherwise loaded machine towards the top? (or at
> least preferably ones with faster NICs...)
Yes. The earliest listed *alive* daemon in a segment in the .conf
file will be the segment leader.
The additional load incurred on a leader of a segment is usually not
significant. However, I will say that if your machines are loaded,
then Spread functions much better if you up its priority. If Spread
gets starved from CPU time, then timeouts can cause improper failure
detection, which can cause Spread to be far less responsive and
accurate (in liveness detection).
John Lane Schultz
Spread Concepts LLC
Phn: 443 838 2200
Fax: 301 560 8875
> Hi John (Jeremy here, by the way),
>> When node $x in segment $y sends a "Spread broadcast" it will first
>> send a UDP point-to-point packet to the leaders of each of the other
>> segments (who will then locally broad/multicast it within their segment)
>> and then if it needs to broad/multicast within its segment it will do
>> that too.
>> I would recommend that you use multicast addresses instead of
>> broadcast addresses for your segments wherever it is available.
>> Broadcast incurs CPU and switch bandwidth overhead on all machines /
>> ports within the subnet whereas multicast can only use CPU and bandwidth
>> on the machines / ports that have joined that IP multicast group.
> Of course. And for multicast I should make sure I use different
> (private) ranges for each cluster!
>> If you can multicast between your two datacenters, then you should
>> them all in the same segment. If you can't multicast to all of them,
>> then your .conf looks good (except you should use multicast within
>> segments instead of broadcast).
> As I say, I'd only be able to do a single multicast range with a
> router-provided tunnel (GRE in this case - both ISPs use Cisco kit). But
> I'll give unicast packets a go in the first case anyway.
>> Make sure though that every daemon can send point-to-point traffic
>> directly to every other daemon (i.e. - two distinct private (NAT'ed)
>> networks usually can't work well together using Spread w/o some kind of
>> tunnelling or default routing).
> Sure - this wouldn't be a problem for the relevant hosts in my
> datacentre scenario (as long as the firewalls are updated).
> Spread-users mailing list
> Spread-users at lists.spread.org
More information about the Spread-users