On Thu, 2010-05-20 at 10:17 -0700, Alan Jones wrote:
> I have a prototype of this working. However, I have some questions
> about the 1.2.1 code:
> Why is broadcast_use an attribute of totem_config and not
> totem_interface?
With broadcast, it would be possible for a cross connected switch from
two separate interfaces to collide, causing all sorts of problems. So
with broadcast, redundant ring doesn't work.
> What is the "ip_port - 1" about in binding mcast_send line 1513
> totemudp_build_sockets_ip()?
> It seems that ip_port would be correct. I don't know why it works.
The linux kernel (and probably all other kernels) does not allow binding
two sockets to one port on one interface. Because of how totem works,
we need two sockets (one for sending the token, one for sending
multicast). We want to ensure the token gets through even if the
multicast transmit buffer is full in the kernel.
My expertise with sockets was non-existent when I wrote the initial code
and has improved since then.. Perhaps in the future we can look at
merging the send and receive sockets - but atm it would break binary
compat.
> Note, the obj database would not allow me to have multiple peeraddr
> fields, so I used a list (see below).
> Alan
>
> interface {
> ringnumber: 0
>
> # The following values need to be set based on your
> environment
> bindnetaddr: 10.25.208.0
> udpucast: yes
> peerlist: 10.25.210.178,10.25.210.179
> mcastport: 4000
> }
>
A better option might be
peerlist {
nodeip: 10.25.210.178
nodeip: 10.25.210.179
}
Also there is already a transport key, called "transport". Current
transports are udp, iba. third one should be udpu, rather then a new
udpucast option.
Would you mind sending a patch? If you currently implement the code in
totemudp.c, make sure to make a new transport called totemudpu.c :)
Regards
-steve
>
> On Thu, May 13, 2010 at 5:15 PM, Steven Dake <[email protected]> wrote:
> ya looks good
>
>
> On Thu, 2010-05-13 at 16:15 -0700, Alan Jones wrote:
> > Hi Steve,
> > I'd like to work on the configuration option from this
> thread.
> > Please comment on my proposed corosync.conf excerpt:
> >
> > interface {
> > ringnumber: 0
> > udpucast: yes
> > peeraddr: 192.168.9.1
> > peeraddr: 192.168.9.2
> > udpuport: 4000
> > }
> >
> > My thinking is that you could include the local node to
> preserve
> > identical conf files.
> > Regards,
> > Alan
> >
> >
> > On Mon, Feb 22, 2010 at 10:45 AM, Steven Dake
> <[email protected]>
> > wrote:
> > We are kicking around the idea of a new transport
> mode called
> > "udpu".
> > Instead of requiring multicast, if a node needs to
> multicast,
> > it will
> > send a unconnected datagram UDP message to all nodes
> in the
> > configuration. In this model, the user would
> specify a list
> > of nodes
> > that "could be" cluster members (rather then a
> multicast
> > address and
> > port).
> >
> > The advantage of this model is that it doesn't
> depend on
> > multicast
> > configuration by the network admins, etc. The
> disadvantage is
> > that it
> > would far less performant since the reason totem
> performs so
> > well is
> > that it depends on switch hardware to perform copies
> to each
> > node rather
> > then relying on the operating system to do that
> work.
> >
> > Regards
> > -steve
> >
> >
> > On Mon, 2010-02-22 at 10:45 -0700, hj lee wrote:
> > > Hi,
> > >
> > > Currently I use TCP only for token transmit in
> operational
> > mode. The
> > > UDP is still used same as before in all other
> modes and also
> > for
> > > multicast messages. So the change for this work is
> minimal
> > and most
> > > changes are in udp layer. Using TCP completely
> will require
> > more work
> > > and bigger changes.
> > >
> > > hj
> > >
> > > On Fri, Feb 19, 2010 at 11:25 AM, Alan Jones
> > <[email protected]>
> > > wrote:
> > > The solution I would like to consider is
> configuring
> > a list of
> > > static peer addresses without
> > > multicast. To that end I would like to
> evaluate
> > HJ's patch
> > > for using TCP.
> > > It is not one cluster admin that I would
> have to
> > train, but a
> > > potential large number of
> > > customers for a product. From the
> customer's
> > prospective my
> > > product will already
> > > introduce an "extra" floating regular IP.
> If we ask
> > for a
> > > multicast address and port as
> > > well I fear the product may be perceived
> as too
> > complex,
> > > particularly for a customer that
> > > intends to deploy a large number of small
> clusters.
> > > Alan
> > >
> > >
> > >
> > > On Thu, Feb 18, 2010 at 10:21 PM, Steven
> Dake
> > > <[email protected]> wrote:
> > > Totem as is implemented in
> corosync is not
> > designed
> > > for large scale
> > > rejection of messages because
> administrators
> > want
> > > unique clusters on the
> > > same multicast address and port.
> Corosync
> > will have
> > > very poor
> > > performance characteristics in
> this model
> > and spew a
> > > ton of warnings and
> > > also not scale particularly well.
> Best to
> > get the
> > > cluster admin to
> > > configure the cluster's ports.
> > >
> > > I really cannot recommend at all
> using the
> > secure key
> > > to uniquely
> > > identify clusters.
> > >
> > > Regards
> > > -steve
> > >
> > >
> > > > Requiring the user to configure
> each
> > cluster's
> > > membership is less
> > > > onerous and is
> > > > required for other components of
> my
> > solution.
> > > > Can you forward your patch for
> TCP?
> > > > Alan
> > > >
> > >
> > >
> > >
> > > --
> > > Peakpoint Service
> > >
> > > Cluster Setup, Troubleshooting & Development
> > > [email protected]
> > > (303) 997-2823
> >
> >
> >
>
>
>
_______________________________________________
Openais mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/openais
