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
