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?
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.
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
}
On Thu, May 13, 2010 at 5:15 PM, Steven Dake <sd...@redhat.com> 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 <sd...@redhat.com>
> > 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
> > <falanclus...@gmail.com>
> > > 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
> > > <sd...@redhat.com> 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
> > > kerd...@gmail.com
> > > (303) 997-2823
> >
> >
> >
>
>
_______________________________________________
Openais mailing list
Openais@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/openais
