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
