[Spread-users] Multi-homed multi-segment
Jonathan Stanton
jonathan at spread.org
Thu Oct 16 14:01:16 EDT 2008
Hi,
OK. I think I understand the setup. You are running 3 separate daemon
configuration instances (separete spread.conf setting a different
spread port number and listing different hosts)
so each master is in one of the instances and each slave is in only one.
This definitely works to create 3 separate spread rings that each work on
their own, but since the master computers can join all 3 spread networks
they can receive and send messages on all of the rings.
What you lose with this setup is the ability to get ordering and delivery
guarantees for messages accross the rings (i.e. if a node on ring 1 sends
message A and a node on ring 2 sends a message B at the same time, you do
not get a guarantee that the masters (3 of them) who are listening to
all of the rings see those messages in teh same order (A then B or B then
A) If you are only using Reliable and FIFO service (not Agreed or Safe)
then this is probably fine for you.
So if that works for you then I think this probably is the best setup for
what you are trying to do.
One final note inline below:
On Thu, Oct 16, 2008 at 07:27:03AM +0100, Adrian Revill wrote:
[...]
> This does have the restriction that the application has to use the
> socket connection and not the tcp connection. This is because two spread
> daemons will not bind to 127.0.0.1 at the same time, even if they are on
> different ports.
This should not be a problem. I just tried to run 2 spread daemons on the
same node ( I just used one for this test but it will be the same for
larger configs) with the following configurations:
Daemon 1 ran with config:
Spread_Segment 192.168.1.255:4750 {
goldberry 192.168.1.119 {
D 192.168.1.119
C 127.0.0.1
}
}
Daemon 2 ran with config:
Spread_Segment 192.168.1.255:4850 {
goldberry 192.168.1.119 {
D 192.168.1.119
C 127.0.0.1
}
}
Note the only difference is the port number. Both of these were able to
bind to 127.0.0.1 at different ports and receive client connections on
them.
Is that the problem you ran into?
Cheers,
Jonathan
>
>
>
> Jonathan Stanton wrote:
> >Can you say more about why you are trying to use this configuration?
> >
> >I can think of three scenarios for this (maybe there are others)
> >
> >1) You want to use a "multi-path" fault-tolerance setup where spread
> >runs rings on two separaet ethernet segments, and if one goes down
> >(switch failure) Spread continues working by using the other network.
> >
> >In this case, Spread does not natively support that model. A number of
> >years ago a patch was written to add multi-path support to Spread
> >(against 3.16 and I heard it was ported to 3.17 versions). We
> >host a copy for download from our website, and link to it from the
> >development page. I don't see the link currently, but you can still get
> >the file at:
> >
> >http://www.spread.org/files/multipath_3.16.1-5.tar.gz
> >
> >This would definitely require some work to update it to the 4.0 code and
> >clean it up for use, but at the time it was used by several groups for
> >FT setups. I don't know if anyone on the list has current experience
> >with it.
> >
> >2) You want to utilize the 2 separate ethernet interfaces to gain
> >performance (i.e messages/second ).
> >
> >In this case it won't work. Spread assumes that each segment is a
> >separate broadcast domain with unique machines on it. So every packet
> >will be forwarded to all of the segments. So the result would be
> >c1-master3 getting each packet twice, once on each interface.
> >
> >
> >3) You want to allow each spread daemon to listen on either interface
> >for packets destined for it (whether client or daemon), but you don't
> >need to replicate the sending of packets (as in case 1)
> >
> >In this case Spread currently supports this. In this case you just have
> >one Spread_Segment with all of the machines listed, For each one list
> >both interfaces in the multi-home setup (like you have below)
> >
> >If you do have some machines actually on a separate segment, you can
> >list additional segments with those machines, but each physical machine
> >(with 1 or more interfaces) is only listed once in the configuration.
> >
> >This setup can work better with a multicast address instead of a
> >broadcast address for the segment (replace 172.1.255.255 with 226.5.2.3
> >-- or any valid multicast address)
> >
> >
> >If you had a different goal in mind, pleaes let us know and I can see
> >whether it's possible with Spread or not.
> >
> >Cheers,
> >
> >Jonathan
> >
> >
> >On Tue, Sep 23, 2008 at 06:33:58PM +0100, Adrian Revill wrote:
> >
> >>Yes you are right, im sorry i copied the wrong spread.conf
> >>
> >>It should read
> >>Spread_Segment 172.1.255.255:4800
> >>{
> >>
> >> c1-master3 172.1.0.12 {
> >> 172.1.0.12
> >> 172.2.0.22
> >> 127.0.0.1
> >> }
> >> c1-quad-1 172.1.3.1
> >>}
> >>
> >>Spread_Segment 172.2.255.255:4800
> >>{
> >> c2-master23 172.2.0.22 {
> >> 172.1.0.12
> >> 127.0.0.1
> >> 172.2.0.22
> >> }
> >> c2-opto-2 172.2.2.2
> >>}
> >>
> >>
> >>
> >>John Robinson wrote:
> >>
> >>>Adrian Revill wrote:
> >>>
> >>>>Hi
> >>>>I have a server that has 2 NICs (172.1.x.x and 172.2.x.x) and i need
> >>>>to run a daemon that can be a member of the two segments on each NIC
> >>>>
> >>>>I can only get master3 to appear as member of the 172.1.255.255 segment.
> >>>>
> >>>>Does anyone know how to be able to get master3 to be a member of both
> >>>>segments?
> >>>>
> >>>>I have tried
> >>>>
> >>>>Spread_Segment 172.255.255.255:4800
> >>>>
> >>>Shouldn't that be 172.1.255.255:4800 ?
> >>>
> >>>/jr
> >>>---
> >>>
> >>>>{
> >>>> c1-master3 172.1.0.12 {
> >>>> 172.1.0.12
> >>>> 172.2.0.22
> >>>> 127.0.0.1
> >>>> }
> >>>> c1-quad-1 172.1.3.1
> >>>>}
> >>>>
> >>>>Spread_Segment 172.2.255.255:4800
> >>>>{
> >>>> c2-master3 172.2.0.22 {
> >>>> 172.1.0.12
> >>>> 127.0.0.1
> >>>> 172.2.0.22
> >>>> }
> >>>> c2-opto-2 172.2.2.2
> >>>>}
> >>>>
> >>>>
> >>>>
> >>>>______________________________________________________________________
> >>>>This email has been scanned by the MessageLabs Email Security System.
> >>>>For more information please visit http://www.messagelabs.com/email
> >>>>______________________________________________________________________
> >>>>
> >>>>_______________________________________________
> >>>>Spread-users mailing list
> >>>>Spread-users at lists.spread.org
> >>>>http://lists.spread.org/mailman/listinfo/spread-users
> >>>>
> >>>______________________________________________________________________
> >>>This email has been scanned by the MessageLabs Email Security System.
> >>>For more information please visit http://www.messagelabs.com/email
> >>>______________________________________________________________________
> >>>
> >>______________________________________________________________________
> >>This email has been scanned by the MessageLabs Email Security System.
> >>For more information please visit http://www.messagelabs.com/email
> >>______________________________________________________________________
> >>
> >>_______________________________________________
> >>Spread-users mailing list
> >>Spread-users at lists.spread.org
> >>http://lists.spread.org/mailman/listinfo/spread-users
> >>
> >
> >
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
--
-------------------------------------------------------
Jonathan Stanton jonathan at spread.org
Spread Group Messaging www.spread.org
Spread Concepts LLC www.spreadconcepts.com
-------------------------------------------------------
More information about the Spread-users
mailing list